2018.12.14

협력적 애자일 데브옵스 팀을 만드는 5가지 원칙

Isaac Sacolick | InfoWorld
IT팀 내에서 애자일과 데브옵스를 실행할 때는 해야 할 일이 많다. 먼저 애자일팀은 스크럼 마스터 직무를 정의하고 추산 실무(estimating practices)를 추가하고, 애자일 관리 툴 사용법을 익히면서 자신의 실무를 고도화하고 평가해야 한다. 데브옵스팀도 CI/CD 파이프라인을 구현하고 자동 테스팅을 이행한 후 더 자세한 애플리케이션 수준 모니터링과 알림을 추가해야 한다.

© Getty Images Bank

그동안 애자일 및 데브옵스 관련해 IT팀의 문화와 사고방식에 대해서는 많은 조언이 있었다. 그러나 IT분야에 오랫동안 있었던 사람이라면 신속한 실무 투입을 원하는 개발팀과 인프라와 애플리케이션이 안정적으로 실행되는 것을 최우선으로 여기는 IT 운영팀 간의 갈등을 쉽게 목격할 수 있다. 결국 애자일과 데브옵스는 단순한 실무와 기술이 아니다. 이는 IT 관련 모든 사람이 '협력하는' 방식을 바꾸는 것이다.

그렇다면 IT팀이 일단 애자일과 데브옵스 변혁을 시작했을 때, 사람들이 진정으로 협력하고 있는지 어떻게 파악할 수 있을까? 팀이 어떻게 행동해야 협력과 문화, 사고방식을 개선할 수 있을까? 이러한 고민을 가진 실무자를 위해 협력적, 문화적 혁신을 이끄는 데 도움이 되는 5가지 원리를 살펴보자.

1. '올바르게' 문제 파악하고 '충분히' 대응한다
기술적 해법에 지나치게 집착한 나머지 정작 자신이 해결하고 있는 문제가 무엇인지, 이를 왜 해결하려 하는지를 망각해버리는 경우가 있다. 또는 문제를 해결하는 과정에서 핵심 인력이 대화에서 제외되는 경우도 있다. 기술적 문제만을 지나치게 고민하다가 과도하게 설계되고 너무 복잡해 이행하기조차 어려운 솔루션을 정의하기도 한다. 이런 현상은 팀이 한걸음 물러나 전략적 생각을 하지 않으면서 문제 해결에 곧바로 뛰어들 때 나타난다. 따라서 협력적인 팀이 되려면 먼저 다음과 같은 방법으로 문제 해결 절차를 결정해야 한다.

- 목표 및 목표가 중요한 이유를 정확히 서술하면서 기회를 정의 
- 해법에서 고려돼 할 이용자 요구와 가치를 이해 
- 맥락에 따라 기회를 검토하고 우선순위 결정 
- 제프 베조스의 '피자 2개 회의 규칙'을 이용하고, 문제 해결팀을 각계각층의 인력으로 구성 
- 유관 데이터를 활용하며 제약을 이해하고 현실적인 선택지를 도출
- 해결 노력을 타임-박싱(정해진 시간에 몰입)하고, 여러 선택지를 고려
- 결과 및 바람직한 다음 단계에 관해 소통 

2. 고객 외에 기술 부채에도 공격적으로 대처한다 
최고의 팀은 전략적 이니셔티브와 고객 요구 및 문제 대응, 기술 부채 대처 사이의 균형을 추구한다. 물론 이는 말로는 쉽지만 실무에서는 대단히 어렵다. 큰 소리로 불만을 제기하는 고객, 마감 시한을 강요하는 리더, 취약한 시스템과 애플리케이션의 더 빠른 패치를 원하는 보안팀이 공존하기 때문이다.

강력한 애자일 데브옵스팀은 우선순위가 높은 문제를 먼저 처리하기 위해 순서를 정하고 업무 효율을 높이는데 극도로 민감하게 대응한다. 예를 들어, 불필요한 회의를 피하고 불필요한 절차를 없애고 워크플로 자동화에 투자하는 식이다.

단, 이 경우 기술 부채가 빠듯한 비즈니스 요구 뒤로 밀려나기 쉽다. 그러나 최고의 팀이라면 기술 부채가 쌓이는 것을 허용하지 않는다. 이들은 자신의 아키텍처와 시스템이 작용하는 방식과 코드에 대한 기술력에 자부심이 있다. 이들은 노쇠한 인프라를 용납하지 않으며, 보안과 다른 위험을 걱정하는 대신 마이그레이션을 선택한다. 이들은 자신이 개발하고 있는 것과 이전에 개발한 것에 책임을 진다. 

3. 스스로 확립한 기준을 추구한다 
애자일 선언 중 하나는 “최고의 아키텍처, 요건, 및 설계는 자발적으로 조직된 팀으로부터 나온다”는 것이다. 따라서 최고의 팀은 개념 증명을 스스로 구성하고, 실험하고, 개발하는 것과, 표준적 실무, 아키텍처, 방법론을 개발하는 것 사이의 적절한 균형을 발견함으로써 이 원리를 실천한다.  

이는 보기보다 쉽지 않다. 소규모 팀이라면 일상적인 업무를 처리하는 것만으로도 힘들기 때문에 표준을 정의하고 문서화하고 전달하고 측정하는 시간이 충분치 않다. 대기업이라면 아이디어를 선택해 평가하고 다른 사람이 이를 이용하도록 하는 데, 자신의 핵심 직무를 넘어서는 소통과 협업이 필요할 수도 있다. 그러나 바로 이것이 훌륭한 애자일 및 데브옵스팀이 하는 일이다. 자발적으로 조직된 팀은 상당한 권한과 유연성을 가지므로 이를 적절하게 처리할 수 있다. 이러한 유연성에는 최고의 기준을 만들고 이를 준수할 책임을 갖는다.
 
4. KPI를 개발하고 리뷰를 통해 지속적으로 개선한다
훌륭한 팀은 언제나 프로세스, 실무, 협업의 향상을 모색한다. 핵심 성과 지표(KPI)와 개선 프로세스를 공식화함으로써 이를 달성할 수 있다. 이를 실무적으로 추진하는 방법은 다음과 같다.

- IT팀이 생산성, 품질 또는 여타 운영 원리에 영향을 주는 취약한 실무 분야와 관련해 핵심 성과 지표를 특별히 선정하고 측정
- KPI를 정기적으로 확인하고 리뷰 회의를 통해 프로세스 향상에 관한 피드백을 추가적으로 수집. 가장 중요한 피드백은 프로세스 향상을 위해 최우선 순위에 배정
- 여러 팀으로 구성된 조직이라면, 특정 KPI에서 우수한 팀이 부진한 팀에게 조언을 하도록 요청 
- KPI가 목표를 달성하면 기존 것을 배제하고 다른 개선 분야로 정기적으로 교체 

5. 소규모팀으로 문제를 해결하고 작은 성과도 함께 축하
문화와 기술을 바꾸는 과정에서 갈등이 없을 수 없다. 우선순위, 표준, 기술 플랫폼, 구현 방법론을 놓고 논쟁이 있을 것이다. 최고의 팀은 갈등을 인지하고 소규모 전문가팀으로 이를 처리하려고 노력한다. 이런 전문가팀은 갈등을 다룰 때 “A를 선택했을 때 실패하면 어떻게 하지?”라는 입장과 "최적의 방법을 어떻게 알아낼 수 있을까?"라는 고민을 모두 검토하며 신속하게 대응한다. 즉, '측정 가능한' 위험을 기꺼이 감수하고 '빠르게' 실패하는데 개방적이다. 갈등하거나 이를 방관함으로 문제가 더 악화되는 상황을 만들지 않는다.

또한, 훌륭한 팀은 작은 성취까지도 크게 축하한다. 일반적으로 많은 기업이 현재의 성공을 쉽게 망각한다. IT팀에게 기술을 더 전략적으로 이용하고, 더 빈번하게 애플리케이션을 수정하고, 더 신속하게 업무 문제를 해결하고 전반적인 이용자 경험 품질을 개선하라고 압박한다. “다음은 무엇인가?”, “더 잘할 방법은 무엇인가?”만 끊임없이 묻다가 현재 작은 성과의 가치를 무시하는 것이다. 그러나 최고의 팀은 자신의 성취를 확인하고 이해관계자와 동료가 이들의 성과를 함께 축하하도록 해 기업 전반의 문화 변화를 이끌어 낸다. ciokr@idg.co.kr



2018.12.14

협력적 애자일 데브옵스 팀을 만드는 5가지 원칙

Isaac Sacolick | InfoWorld
IT팀 내에서 애자일과 데브옵스를 실행할 때는 해야 할 일이 많다. 먼저 애자일팀은 스크럼 마스터 직무를 정의하고 추산 실무(estimating practices)를 추가하고, 애자일 관리 툴 사용법을 익히면서 자신의 실무를 고도화하고 평가해야 한다. 데브옵스팀도 CI/CD 파이프라인을 구현하고 자동 테스팅을 이행한 후 더 자세한 애플리케이션 수준 모니터링과 알림을 추가해야 한다.

© Getty Images Bank

그동안 애자일 및 데브옵스 관련해 IT팀의 문화와 사고방식에 대해서는 많은 조언이 있었다. 그러나 IT분야에 오랫동안 있었던 사람이라면 신속한 실무 투입을 원하는 개발팀과 인프라와 애플리케이션이 안정적으로 실행되는 것을 최우선으로 여기는 IT 운영팀 간의 갈등을 쉽게 목격할 수 있다. 결국 애자일과 데브옵스는 단순한 실무와 기술이 아니다. 이는 IT 관련 모든 사람이 '협력하는' 방식을 바꾸는 것이다.

그렇다면 IT팀이 일단 애자일과 데브옵스 변혁을 시작했을 때, 사람들이 진정으로 협력하고 있는지 어떻게 파악할 수 있을까? 팀이 어떻게 행동해야 협력과 문화, 사고방식을 개선할 수 있을까? 이러한 고민을 가진 실무자를 위해 협력적, 문화적 혁신을 이끄는 데 도움이 되는 5가지 원리를 살펴보자.

1. '올바르게' 문제 파악하고 '충분히' 대응한다
기술적 해법에 지나치게 집착한 나머지 정작 자신이 해결하고 있는 문제가 무엇인지, 이를 왜 해결하려 하는지를 망각해버리는 경우가 있다. 또는 문제를 해결하는 과정에서 핵심 인력이 대화에서 제외되는 경우도 있다. 기술적 문제만을 지나치게 고민하다가 과도하게 설계되고 너무 복잡해 이행하기조차 어려운 솔루션을 정의하기도 한다. 이런 현상은 팀이 한걸음 물러나 전략적 생각을 하지 않으면서 문제 해결에 곧바로 뛰어들 때 나타난다. 따라서 협력적인 팀이 되려면 먼저 다음과 같은 방법으로 문제 해결 절차를 결정해야 한다.

- 목표 및 목표가 중요한 이유를 정확히 서술하면서 기회를 정의 
- 해법에서 고려돼 할 이용자 요구와 가치를 이해 
- 맥락에 따라 기회를 검토하고 우선순위 결정 
- 제프 베조스의 '피자 2개 회의 규칙'을 이용하고, 문제 해결팀을 각계각층의 인력으로 구성 
- 유관 데이터를 활용하며 제약을 이해하고 현실적인 선택지를 도출
- 해결 노력을 타임-박싱(정해진 시간에 몰입)하고, 여러 선택지를 고려
- 결과 및 바람직한 다음 단계에 관해 소통 

2. 고객 외에 기술 부채에도 공격적으로 대처한다 
최고의 팀은 전략적 이니셔티브와 고객 요구 및 문제 대응, 기술 부채 대처 사이의 균형을 추구한다. 물론 이는 말로는 쉽지만 실무에서는 대단히 어렵다. 큰 소리로 불만을 제기하는 고객, 마감 시한을 강요하는 리더, 취약한 시스템과 애플리케이션의 더 빠른 패치를 원하는 보안팀이 공존하기 때문이다.

강력한 애자일 데브옵스팀은 우선순위가 높은 문제를 먼저 처리하기 위해 순서를 정하고 업무 효율을 높이는데 극도로 민감하게 대응한다. 예를 들어, 불필요한 회의를 피하고 불필요한 절차를 없애고 워크플로 자동화에 투자하는 식이다.

단, 이 경우 기술 부채가 빠듯한 비즈니스 요구 뒤로 밀려나기 쉽다. 그러나 최고의 팀이라면 기술 부채가 쌓이는 것을 허용하지 않는다. 이들은 자신의 아키텍처와 시스템이 작용하는 방식과 코드에 대한 기술력에 자부심이 있다. 이들은 노쇠한 인프라를 용납하지 않으며, 보안과 다른 위험을 걱정하는 대신 마이그레이션을 선택한다. 이들은 자신이 개발하고 있는 것과 이전에 개발한 것에 책임을 진다. 

3. 스스로 확립한 기준을 추구한다 
애자일 선언 중 하나는 “최고의 아키텍처, 요건, 및 설계는 자발적으로 조직된 팀으로부터 나온다”는 것이다. 따라서 최고의 팀은 개념 증명을 스스로 구성하고, 실험하고, 개발하는 것과, 표준적 실무, 아키텍처, 방법론을 개발하는 것 사이의 적절한 균형을 발견함으로써 이 원리를 실천한다.  

이는 보기보다 쉽지 않다. 소규모 팀이라면 일상적인 업무를 처리하는 것만으로도 힘들기 때문에 표준을 정의하고 문서화하고 전달하고 측정하는 시간이 충분치 않다. 대기업이라면 아이디어를 선택해 평가하고 다른 사람이 이를 이용하도록 하는 데, 자신의 핵심 직무를 넘어서는 소통과 협업이 필요할 수도 있다. 그러나 바로 이것이 훌륭한 애자일 및 데브옵스팀이 하는 일이다. 자발적으로 조직된 팀은 상당한 권한과 유연성을 가지므로 이를 적절하게 처리할 수 있다. 이러한 유연성에는 최고의 기준을 만들고 이를 준수할 책임을 갖는다.
 
4. KPI를 개발하고 리뷰를 통해 지속적으로 개선한다
훌륭한 팀은 언제나 프로세스, 실무, 협업의 향상을 모색한다. 핵심 성과 지표(KPI)와 개선 프로세스를 공식화함으로써 이를 달성할 수 있다. 이를 실무적으로 추진하는 방법은 다음과 같다.

- IT팀이 생산성, 품질 또는 여타 운영 원리에 영향을 주는 취약한 실무 분야와 관련해 핵심 성과 지표를 특별히 선정하고 측정
- KPI를 정기적으로 확인하고 리뷰 회의를 통해 프로세스 향상에 관한 피드백을 추가적으로 수집. 가장 중요한 피드백은 프로세스 향상을 위해 최우선 순위에 배정
- 여러 팀으로 구성된 조직이라면, 특정 KPI에서 우수한 팀이 부진한 팀에게 조언을 하도록 요청 
- KPI가 목표를 달성하면 기존 것을 배제하고 다른 개선 분야로 정기적으로 교체 

5. 소규모팀으로 문제를 해결하고 작은 성과도 함께 축하
문화와 기술을 바꾸는 과정에서 갈등이 없을 수 없다. 우선순위, 표준, 기술 플랫폼, 구현 방법론을 놓고 논쟁이 있을 것이다. 최고의 팀은 갈등을 인지하고 소규모 전문가팀으로 이를 처리하려고 노력한다. 이런 전문가팀은 갈등을 다룰 때 “A를 선택했을 때 실패하면 어떻게 하지?”라는 입장과 "최적의 방법을 어떻게 알아낼 수 있을까?"라는 고민을 모두 검토하며 신속하게 대응한다. 즉, '측정 가능한' 위험을 기꺼이 감수하고 '빠르게' 실패하는데 개방적이다. 갈등하거나 이를 방관함으로 문제가 더 악화되는 상황을 만들지 않는다.

또한, 훌륭한 팀은 작은 성취까지도 크게 축하한다. 일반적으로 많은 기업이 현재의 성공을 쉽게 망각한다. IT팀에게 기술을 더 전략적으로 이용하고, 더 빈번하게 애플리케이션을 수정하고, 더 신속하게 업무 문제를 해결하고 전반적인 이용자 경험 품질을 개선하라고 압박한다. “다음은 무엇인가?”, “더 잘할 방법은 무엇인가?”만 끊임없이 묻다가 현재 작은 성과의 가치를 무시하는 것이다. 그러나 최고의 팀은 자신의 성취를 확인하고 이해관계자와 동료가 이들의 성과를 함께 축하하도록 해 기업 전반의 문화 변화를 이끌어 낸다. ciokr@idg.co.kr

X