2019.07.16

데브옵스 백로그의 우선순위를 정하기 위한 7가지 질문

Isaac Sacolick | InfoWorld
많은 조직이 데브옵스 베스트 프랙티스 도입에 나서면서 버전 제어, 지속적 통합, 자동화된 테스트, 지속적인 전달, 배포 컨테이너, 코드형 인프라(Infrastructure as Code), 중앙 모니터링을 비롯해서 애플리케이션과 인프라 관리의 여러 측면을 자동화, 시스템화하는 데 투자하고 있다.
 
ⓒ GettyImagesBank

하지만 방법, 툴, 성숙도 수준이 점점 더 다양화됨에 따라 데브옵스팀과 IT 부서에서 어떤 영역을 우선순위에 둘지, 어떤 접근 방법이 가장 유리한지, 그리고 어느 정도의 성숙도면 충분한지를 판단하기가 더 이상 간단치 않은 일이 됐다.

예를 들어 애플리케이션 개발 활동이 많은 조직이라면 더 자주, 안정적으로 코드를 릴리즈하기 위해 종합적인 CI/CD(Continuous Integration and Delivery, 지속적 통합 및 전달) 구현에 관심을 가질 수 있다. 반면 개발 활동이 드문 조직은 배포 파이프라인의 일부를 자동화한 다음 모니터링을 중앙화해서 프로덕션 사고에 대한 응답 시간 개선에 초점을 둘 수 있다.

AI옵스, 마이크로서비스 관리, 보안 자동화, 멀티클라우드 환경 관리를 위한 더욱 실용적인 툴과 기타 여러 데브옵스 추세가 주류로 부상하면서 실무 측면에서 데브옵스 팀의 선택권도 다양해졌다. 따라서 데브옵스 팀은 특정 영역에 대한 투자의 이유와 투자할 부분, 규모를 우선순위화하기 위한 전략을 마련해야 한다.

이 전략을 수립하는 데 도움이 되는 7가지 질문을 소개한다.
 

1. 고객이 누구이며, 고객의 우선순위는 무엇인가?

필자가 함께 일하는 많은 데브옵스팀이 이 질문을 받으면 당황한다. 고객의 관점에서 데브옵스 목표와 우선순위를 생각해본 적이 없기 때문이다. 그러나 모든 기술 이니셔티브, 특히 데브옵스에 사용자 페르소나와 별도의 구매자 페르소나를 부여하면 초점을 맞춰야 할 부분, 해결해야 할 문제, 고려할 기술 솔루션, 최선의 자동화 구현 방법이 명확하게 드러난다.

소프트웨어 개발자라면 개발팀의 효율성을 높이는 데 목표를 두는 데브옵스 방법론(예를 들어 CI/CD)의 우선순위를 높게 둘 가능성이 높고, 운영 엔지니어라면 AI옵스와 중앙 모니터링을 더 선호할 가능성이 높다. 데브옵스 팀이 구매자 페르소나, 더 구체적으로 데브옵스 방법론을 지지하고 투자하는 조직 내의 리더 페르소나를 고려해야 하는 이유가 여기에 있다. 이들의 전략적 요구사항이 구체적이지 않다면 직접 물어야 한다.
 

2. 사용 중인 기술 운영 모델은 무엇인가?

이 두 번째 질문을 잘 이해하지 못하는 데브옵스팀이 많다. 신생 기업에 가까운 행동 양식과 역량을 확보하고자 데브옵스 방법론과 문화의 변화를 추구하는가? 아니면 엔터프라이즈 지향적인 역량과 성과 지표에 더 역점을 두는가?

예를 들어서 살펴보자. CI/CD의 지향점이 더 빈번한 릴리즈에 있는가, 아니면 더 안정적인 릴리즈에 있는가? 개발자에게 클라우드 네이티브 개발 샌드박스를 제공하는 것이 목표인가, 아니면 일관적인 개발 환경의 가동과 중지를 실현하기 위한 규격화된 인프라 배포가 더 중요한가? 인프라와 운영에 대한 기본적인 상태 확인을 구현하는가, 아니면 성능에 대한 기대치 및 기타 사이트 안정성 지표를 충족하는 데 필요한 더 견고한 모니터링 테스트를 구현하는가?

물론 많은 데브옵스팀이 모든 요소를 원한지만 실무적으로 보면 각 접근 방법에는 서로 다른 구현과 투자가 필요하다. 조직이 추구하는 문화를 이해하면 우선순위와 구현 옵션을 정하는 데 도움이 된다.
 

3. 현재 운영상의 결점은 무엇인가?

생각해야 할 또 다른 주제는 기술 부서가 경험 중인 운영상의 문제다. 비즈니스 리더들이 무엇에 관해 불평하는가? 고객과 사용자가 어떤 부분에서 어려움을 겪는가? 기술 조직의 어느 영역이 실행 관점에서 뒤처지고 있는가? 데브옵스 방식과 툴이 운영의 변화와 영향을 이끌 수 있는가?

이러한 일련의 생각은 초점 영역을 그리는 데 도움이 된다. 예를 들어 운영 중단 문제를 겪는 조직은 중앙 모니터링 및 AI옵스 구축에 관심을 가져야 하며, 배포 결과에 많은 결함이 발생한다면 자동화된 테스트부터 시작하는 것이 좋다.
 

4. 어느 부분이 성장, 확장 중인가?

데브옵스 방식을 도입하는 이유가 운영상의 결점이 아니라면 어느 활동이 성장 중이고 자동화를 통해 혜택을 얻을 수 있는지를 고려하라. 개발팀을 더 늘리는 조직이라면 새로운 개발 및 테스트 환경을 쉽게 가동하기 위해 코드형 인프라에 투자할 수 있다. 애플리케이션을 여러 클라우드 또는 지리적 위치에 배포할 수 있는 이식성이 필요한 조직이라면 컨테이너에 투자하는 편이 유리할 것이다. 애플리케이션이 비즈니스에서 수행하는 역할이 중요해지면서 사용자들이 더 높은 서비스 수준을 기대한다면 AI옵스에 우선순위를 두는 것이 좋다.

규모가 큰 조직이라면 저마다 다른 요구사항을 가진 다양한 애플리케이션이 사용되므로 이러한 유형으로 분석해 보면 모든 해답에 해당될 수도 있다. 사용자 요구 및 운영상의 결점을 위 해답과 결합하면 우선순위를 명확히 그릴 수 있을 것이다.
 

5. 협업에서 개선의 여지가 있는 부분은 어디인가?

전통적인 IT 조직의 경우 데브옵스를 통해 문화의 변화를 추구할 수 있다. 전통적인 조직에서 소프트웨어 개발팀은 코드를 더 자주 배포해야 한다는 압력을 받고 운영팀은 비즈니스 운영의 신뢰성과 성능 보장을 무엇보다 중시한다. 따라서 두 팀은 단절된다. 이러한 각자의 동인 사이에서 균형을 잡는 데 도움이 되는 데브옵스 방식은 두 팀이 공통점과 새로운 협력 방식을 찾는 데 유익하다.

각 기술 분야 간의 상호작용에 마찰이 발생하는, 정상적으로 기능하지 않는 영역을 찾아야 한다. 정상적인 운영 측면에서 애플리케이션 배포의 적합성을 검토하는 변화 자문 위원회에서 이와 같은 마찰이 빈번하게 발생한다. 이러한 회의는 요구사항과 위험을 모두 인지하고 있지는 않은 개발자에게 큰 스트레스가 될 수 있고, 애플리케이션이 모든 규정 준수 및 위험 검사를 통과하지 못한 경우 배포를 중단하거나 연기해야 하는 엔지니어링 관리자에게는 더욱 어려운 자리가 된다. 배포의 여러 측면을 자동화하면 접근 방법을 표준화하고 예상 동작을 코드에서 자동화된 동작에 맞게 바꿀 수 있다.
 

6. 기술적 부채가 일상적 운영에 영향을 미치는 부분은 어디인가?

기술적 부채라는 용어는 리팩터링해야 하는 코드부터 수명이 끝나 교체가 필요한 레거시 시스템에 이르기까지 매우 포괄적인 대상을 지칭하는 데 사용된다. 많은 기술 조직은 개발 진행을 더디게 하거나 비즈니스 운영 지원을 어렵게 하는 기술 영역을 가리킬 때도 이 용어를 사용한다.

그러나 기술적 부채는 코드와 시스템에만 존재하는 것은 아니다. 기술 운영 방식에도 존재한다. 예를 들어 지원팀이 사고 또는 요청에 대응할 때 수동 단계에 따라야 한다면 이는 기술적 부채의 산물일 가능성이 높다. 오류가 쉽게 발생하는 복잡한 운영 절차는 자동화가 필요한 영역임을 나타내는 경우가 많다. 지원 범위가 매우 제한적이거나 유일한 특정 분야 전문가의 개입이 필요한 영역도 심각한 비즈니스 위험 또는 기술적 부채를 가리킬 수 있다. 

관건은 이러한 운영을 문서화하는 것보다 자동화하는 편이 더 유리한지 여부, 그리고 새로운 데브옵스 툴이 작업을 간소화하는 데 도움이 되는 영역이 어디인가다.
 

7. 주로 다루는 핵심 성과 지표는 무엇인가?

기술 조직은 지표를 사용해서 성과를 평가하고 기술 및 업무 방식의 개선이 영향을 미치는 부분을 명확히 드러내야 한다. 기본적인 데브옵스 방법론이 구축되고 나면 데브옵스 핵심 성과 지표(KPI)를 선택해서 사용해야 한다. 이 툴로 새로운 초점 영역이 필요한 부분이 어디인지, 목표로 삼을 성숙도 수준은 어느 정도인지를 파악할 수 있다.

많은 개발 조직이 초점을 두는 KPI는 애플리케이션 배포의 빈도다. 더 빈번한 배포를 실현하기 위해 더 많은 CI/CI 파이프라인을 더 정교하게 자동화하는 방법을 택하는 조직도 있다. 그러나 배포 빈도의 상승에 따라 프로덕션에서 발견되는 결함(결함 탈출 비율)의 수도 함께 증가한다면 테스트 자동화에 더 투자해야 한다.

비슷한 맥락에서, 장시간 운영 중단이 자주 발생하는 조직이라면 평균 복구 시간을 측정할 수 있다. 중앙 모니터링, AI옵스, 자동화된 테스트, 코드형 인프라에 투자하면 이 성과 지표를 개선하는 데 도움이 된다.

KPI를 사용해서 우선순위를 정할 때 던져야 할 중요한 질문은 선택한 KPI가 비즈니스 요구사항에 부합하며 중요한 사안에 대응하는지 여부다. KPI는 데브옵스를 우선순위화기 위한 최종 툴이어야 하지만 사용자 요구사항과 전략적 우선순위, 결점, 성장 고려 사항 및 기타 데브옵스 우선순위에 영향을 미치는 다른 요소도 담아야 한다. editor@itworld.co.kr


2019.07.16

데브옵스 백로그의 우선순위를 정하기 위한 7가지 질문

Isaac Sacolick | InfoWorld
많은 조직이 데브옵스 베스트 프랙티스 도입에 나서면서 버전 제어, 지속적 통합, 자동화된 테스트, 지속적인 전달, 배포 컨테이너, 코드형 인프라(Infrastructure as Code), 중앙 모니터링을 비롯해서 애플리케이션과 인프라 관리의 여러 측면을 자동화, 시스템화하는 데 투자하고 있다.
 
ⓒ GettyImagesBank

하지만 방법, 툴, 성숙도 수준이 점점 더 다양화됨에 따라 데브옵스팀과 IT 부서에서 어떤 영역을 우선순위에 둘지, 어떤 접근 방법이 가장 유리한지, 그리고 어느 정도의 성숙도면 충분한지를 판단하기가 더 이상 간단치 않은 일이 됐다.

예를 들어 애플리케이션 개발 활동이 많은 조직이라면 더 자주, 안정적으로 코드를 릴리즈하기 위해 종합적인 CI/CD(Continuous Integration and Delivery, 지속적 통합 및 전달) 구현에 관심을 가질 수 있다. 반면 개발 활동이 드문 조직은 배포 파이프라인의 일부를 자동화한 다음 모니터링을 중앙화해서 프로덕션 사고에 대한 응답 시간 개선에 초점을 둘 수 있다.

AI옵스, 마이크로서비스 관리, 보안 자동화, 멀티클라우드 환경 관리를 위한 더욱 실용적인 툴과 기타 여러 데브옵스 추세가 주류로 부상하면서 실무 측면에서 데브옵스 팀의 선택권도 다양해졌다. 따라서 데브옵스 팀은 특정 영역에 대한 투자의 이유와 투자할 부분, 규모를 우선순위화하기 위한 전략을 마련해야 한다.

이 전략을 수립하는 데 도움이 되는 7가지 질문을 소개한다.
 

1. 고객이 누구이며, 고객의 우선순위는 무엇인가?

필자가 함께 일하는 많은 데브옵스팀이 이 질문을 받으면 당황한다. 고객의 관점에서 데브옵스 목표와 우선순위를 생각해본 적이 없기 때문이다. 그러나 모든 기술 이니셔티브, 특히 데브옵스에 사용자 페르소나와 별도의 구매자 페르소나를 부여하면 초점을 맞춰야 할 부분, 해결해야 할 문제, 고려할 기술 솔루션, 최선의 자동화 구현 방법이 명확하게 드러난다.

소프트웨어 개발자라면 개발팀의 효율성을 높이는 데 목표를 두는 데브옵스 방법론(예를 들어 CI/CD)의 우선순위를 높게 둘 가능성이 높고, 운영 엔지니어라면 AI옵스와 중앙 모니터링을 더 선호할 가능성이 높다. 데브옵스 팀이 구매자 페르소나, 더 구체적으로 데브옵스 방법론을 지지하고 투자하는 조직 내의 리더 페르소나를 고려해야 하는 이유가 여기에 있다. 이들의 전략적 요구사항이 구체적이지 않다면 직접 물어야 한다.
 

2. 사용 중인 기술 운영 모델은 무엇인가?

이 두 번째 질문을 잘 이해하지 못하는 데브옵스팀이 많다. 신생 기업에 가까운 행동 양식과 역량을 확보하고자 데브옵스 방법론과 문화의 변화를 추구하는가? 아니면 엔터프라이즈 지향적인 역량과 성과 지표에 더 역점을 두는가?

예를 들어서 살펴보자. CI/CD의 지향점이 더 빈번한 릴리즈에 있는가, 아니면 더 안정적인 릴리즈에 있는가? 개발자에게 클라우드 네이티브 개발 샌드박스를 제공하는 것이 목표인가, 아니면 일관적인 개발 환경의 가동과 중지를 실현하기 위한 규격화된 인프라 배포가 더 중요한가? 인프라와 운영에 대한 기본적인 상태 확인을 구현하는가, 아니면 성능에 대한 기대치 및 기타 사이트 안정성 지표를 충족하는 데 필요한 더 견고한 모니터링 테스트를 구현하는가?

물론 많은 데브옵스팀이 모든 요소를 원한지만 실무적으로 보면 각 접근 방법에는 서로 다른 구현과 투자가 필요하다. 조직이 추구하는 문화를 이해하면 우선순위와 구현 옵션을 정하는 데 도움이 된다.
 

3. 현재 운영상의 결점은 무엇인가?

생각해야 할 또 다른 주제는 기술 부서가 경험 중인 운영상의 문제다. 비즈니스 리더들이 무엇에 관해 불평하는가? 고객과 사용자가 어떤 부분에서 어려움을 겪는가? 기술 조직의 어느 영역이 실행 관점에서 뒤처지고 있는가? 데브옵스 방식과 툴이 운영의 변화와 영향을 이끌 수 있는가?

이러한 일련의 생각은 초점 영역을 그리는 데 도움이 된다. 예를 들어 운영 중단 문제를 겪는 조직은 중앙 모니터링 및 AI옵스 구축에 관심을 가져야 하며, 배포 결과에 많은 결함이 발생한다면 자동화된 테스트부터 시작하는 것이 좋다.
 

4. 어느 부분이 성장, 확장 중인가?

데브옵스 방식을 도입하는 이유가 운영상의 결점이 아니라면 어느 활동이 성장 중이고 자동화를 통해 혜택을 얻을 수 있는지를 고려하라. 개발팀을 더 늘리는 조직이라면 새로운 개발 및 테스트 환경을 쉽게 가동하기 위해 코드형 인프라에 투자할 수 있다. 애플리케이션을 여러 클라우드 또는 지리적 위치에 배포할 수 있는 이식성이 필요한 조직이라면 컨테이너에 투자하는 편이 유리할 것이다. 애플리케이션이 비즈니스에서 수행하는 역할이 중요해지면서 사용자들이 더 높은 서비스 수준을 기대한다면 AI옵스에 우선순위를 두는 것이 좋다.

규모가 큰 조직이라면 저마다 다른 요구사항을 가진 다양한 애플리케이션이 사용되므로 이러한 유형으로 분석해 보면 모든 해답에 해당될 수도 있다. 사용자 요구 및 운영상의 결점을 위 해답과 결합하면 우선순위를 명확히 그릴 수 있을 것이다.
 

5. 협업에서 개선의 여지가 있는 부분은 어디인가?

전통적인 IT 조직의 경우 데브옵스를 통해 문화의 변화를 추구할 수 있다. 전통적인 조직에서 소프트웨어 개발팀은 코드를 더 자주 배포해야 한다는 압력을 받고 운영팀은 비즈니스 운영의 신뢰성과 성능 보장을 무엇보다 중시한다. 따라서 두 팀은 단절된다. 이러한 각자의 동인 사이에서 균형을 잡는 데 도움이 되는 데브옵스 방식은 두 팀이 공통점과 새로운 협력 방식을 찾는 데 유익하다.

각 기술 분야 간의 상호작용에 마찰이 발생하는, 정상적으로 기능하지 않는 영역을 찾아야 한다. 정상적인 운영 측면에서 애플리케이션 배포의 적합성을 검토하는 변화 자문 위원회에서 이와 같은 마찰이 빈번하게 발생한다. 이러한 회의는 요구사항과 위험을 모두 인지하고 있지는 않은 개발자에게 큰 스트레스가 될 수 있고, 애플리케이션이 모든 규정 준수 및 위험 검사를 통과하지 못한 경우 배포를 중단하거나 연기해야 하는 엔지니어링 관리자에게는 더욱 어려운 자리가 된다. 배포의 여러 측면을 자동화하면 접근 방법을 표준화하고 예상 동작을 코드에서 자동화된 동작에 맞게 바꿀 수 있다.
 

6. 기술적 부채가 일상적 운영에 영향을 미치는 부분은 어디인가?

기술적 부채라는 용어는 리팩터링해야 하는 코드부터 수명이 끝나 교체가 필요한 레거시 시스템에 이르기까지 매우 포괄적인 대상을 지칭하는 데 사용된다. 많은 기술 조직은 개발 진행을 더디게 하거나 비즈니스 운영 지원을 어렵게 하는 기술 영역을 가리킬 때도 이 용어를 사용한다.

그러나 기술적 부채는 코드와 시스템에만 존재하는 것은 아니다. 기술 운영 방식에도 존재한다. 예를 들어 지원팀이 사고 또는 요청에 대응할 때 수동 단계에 따라야 한다면 이는 기술적 부채의 산물일 가능성이 높다. 오류가 쉽게 발생하는 복잡한 운영 절차는 자동화가 필요한 영역임을 나타내는 경우가 많다. 지원 범위가 매우 제한적이거나 유일한 특정 분야 전문가의 개입이 필요한 영역도 심각한 비즈니스 위험 또는 기술적 부채를 가리킬 수 있다. 

관건은 이러한 운영을 문서화하는 것보다 자동화하는 편이 더 유리한지 여부, 그리고 새로운 데브옵스 툴이 작업을 간소화하는 데 도움이 되는 영역이 어디인가다.
 

7. 주로 다루는 핵심 성과 지표는 무엇인가?

기술 조직은 지표를 사용해서 성과를 평가하고 기술 및 업무 방식의 개선이 영향을 미치는 부분을 명확히 드러내야 한다. 기본적인 데브옵스 방법론이 구축되고 나면 데브옵스 핵심 성과 지표(KPI)를 선택해서 사용해야 한다. 이 툴로 새로운 초점 영역이 필요한 부분이 어디인지, 목표로 삼을 성숙도 수준은 어느 정도인지를 파악할 수 있다.

많은 개발 조직이 초점을 두는 KPI는 애플리케이션 배포의 빈도다. 더 빈번한 배포를 실현하기 위해 더 많은 CI/CI 파이프라인을 더 정교하게 자동화하는 방법을 택하는 조직도 있다. 그러나 배포 빈도의 상승에 따라 프로덕션에서 발견되는 결함(결함 탈출 비율)의 수도 함께 증가한다면 테스트 자동화에 더 투자해야 한다.

비슷한 맥락에서, 장시간 운영 중단이 자주 발생하는 조직이라면 평균 복구 시간을 측정할 수 있다. 중앙 모니터링, AI옵스, 자동화된 테스트, 코드형 인프라에 투자하면 이 성과 지표를 개선하는 데 도움이 된다.

KPI를 사용해서 우선순위를 정할 때 던져야 할 중요한 질문은 선택한 KPI가 비즈니스 요구사항에 부합하며 중요한 사안에 대응하는지 여부다. KPI는 데브옵스를 우선순위화기 위한 최종 툴이어야 하지만 사용자 요구사항과 전략적 우선순위, 결점, 성장 고려 사항 및 기타 데브옵스 우선순위에 영향을 미치는 다른 요소도 담아야 한다. editor@itworld.co.kr


X