애자일 개선 : 프로세스 개선 모델의 고찰과 경험

애자일 코리아 2013년 컨퍼런스에서 발표했던 “애자일 개선 : 프로세스 개선 모델의 고찰과 경험으로부터”을 간단하게 정리해서 올려봅니다. 구성은 크게 1. 문제 배경, 2. 프로세스 개선 모델 고찰과 혁신 곡선 3. 애자일 개선 시나리오 입니다.

1. 문제 배경

2001년 애자일 선언 이후 2005년까지는 XP가 주로 알려지다가 이후에는 많은 조직에서 XP보다는 적용이 용이한 SCRUM이 인기를 얻게 됩니다. 설문결과를 보면 SCRUM이 도입된 전체 애자일 방법에서 절반 정도가 되네요) 그런데 2000년대 후반에 들어서면서 애자일 대가들 사이에서 관리 중심의 SCRUM의 한계를 제기하며 XP와 같은 개발 프랙티스의 중요성이 강조됩니다. 이들의 주장은 스크럼만으로는 프로젝트에서 개발과 품질을 다루기 못하기 때문에 기술부채(technical debt)에 발목이 잡히므로 XP와 같은 기술적 프랙티스가 필요하다는 것입니다.

XP와 SCRUM을 결합한 하이브리드 방법들이 나오고 있지만 개별 프로젝트를 위한 것이고 둘을 합쳐 놓은 정도입니다. 애자일의 탄생은 내부 프로젝트에서 빠른 SW의 출시를 위한 것이었고, 유연성과 실무적 프랙티스를 강조하는 가벼운 방법입니다. 반면 무거운 방법을 대표하는 능력 성숙도 개선 모델인 CMM (Capability Maturity Model)은 미국방성에서 소프트웨어 외주 업체에게 요구사항을 충족시키는 고품질의 SW를 납품시키기 위하여 탄생한 것입니다. 프로젝트가 아니라 업체를 단위로(=전사적) 전체 개발 라이프사이클에서의 전사적 프로세스를 정의하고 장기적 관점에서 개선하기 위한 메타 모델인 것이지요.

무거운 프로세스에 대한 거부감으로 가벼운 프로세스가 출현했을 때 둘 간의 반목은 아주 심했습니다. 서로의 존재와 장점 인정하지 않았습니다. 그런데 요즘은 CMM을 만들고 관리하는 카네기멜론 대학의 소프트웨어공학연구소(http://www.sei.cmu.edu/)도 가벼운 프로세스의 장점을 인정하고 수용하기 위한 연구를 많이 진행하고 있습니다. 이분법의 접근으로는 발전이 없기 때문입니다. 태극은 음과 양이 각각의 영역에 뿌리를 두고 강하고 약함에 따라 서로가 변화하며 상생을 할 수 있습니다. 이러한 태극처럼 애자일도 프로세스 개선 모델의 개선원리를 수용할 수 있을 것이라고 생각합니다.

 

2. 프로세스 개선 모델 고찰과 혁신 곡선

프로세스 개선 모델의 개선 원리를 살펴보기 위한 CMM 모델을 요약해서 살펴보겠습니다. 조직의 능력을 2단계부터 5단계로 구분하는데 한 단계를 올라가는데 평균 2년 정도를 잡습니다. 조직성숙도는 아이가 몸을 뒤집을 수 있으면 그 다음에는 기어다닐 수 있고, 걸음마를 띄고 걸어다니면 이후에 뛰어다닐 수 있다는 개념입니다. 조직에 아무 기반이 없는 상태에서 Level 2는 프로젝트 관리가 이루어지는 단계입니다. 기술 프로세스보다 관리 프로세스가 먼저 자리를 잡아야 한다는 것입니다. Level 3에서는 관리적 프로세스가 갖추어지고 나면 기술적 개발 프로세스를 표준화시키고 조직관리 프로세스가 도입됩니다. 표준화된 프로세스를 통해 정성적, 정량적 지표를 수집하고 분석할 수 있는 Level 4에 오르게 됩니다. 이후에는 분석된 데이타를 기반으로 지속적인 개선을 이루는 Level 5에 도달하는 것입니다. CMM에서는 Level 2와 3를 저성숙 조직으로, Level 4와 5 고성숙 조직으로 구분하는데, 고성숙 조직에 요구되는 데이타 수집 및 분석, 내재화된 지속적 개선 능력을 갖추기 위해 인프라 구축과 표준화가 이루어져야 하고 도달하기 어렵기 때문입니다.

개인뿐만 아니라 조직의 성장은 S곡선을 따라 진행됩니다. 선순환을 통한 개선이 어느 수준에서는 익숙한 일로 변하면 개선이 느려지고 정체가 생기면서 퇴화하는 것입니다. 소위 쉽게 따먹을 과일이 없어지기 때문에 새로운 변화를 받아들이지 않는 이상 악순환의 고리에 빠지게 됩니다. 끊임없는 혁신을 하기 위해서는 조직이 성장속도의 기울기가 꺽이는 시점에서 새로운 기술을 수용하거나 난이도를 높여 연속된 S자 순환 고리를 만들어가야 한다는 것이 혁신의 진화곡선입니다.

3. 애자일 개선 시나리오

앞에서 살펴본 프로세스 개선 고찰, 혁신의 진화곡선 그리고 경험을 기반으로 애자일 개선 시나리오를 생각해 봅니다. 먼저 애자일 방법에서 조직의 성숙 단계를 적용해 봅니다. 제가 생각하는 애자일의 첫번째 단계는 팀간의 신뢰를 형성하는 것입니다. 팀원간에 신뢰 형성없이 어떤 방법도 좋은 결과를 만들기 어렵지만, 특히나 팀원간 존중과 자율성을 강조하는 애자일에서는 더욱 중요합니다. 두번째 단계는 스크럼, 린과 같은 관리적 기반의 방법을 적용하는 것입니다. 세번째는 개발과 품질을 다루는 기술적 프랙티스인 XP를 도입합니다. 여기서 CI는 개발 과정에서 나오는 빌드와 테스트 자동화를 통해 측정과 분석을 하기 위한 중요한 개발 인프라를 구성해 줍니다. 측정과 개선은 함께 짝처럼 움직여 네번째, 다섯번째 단계를 형성합니다. 측정 및 분석된 결과를 피드백받아 개선 기회를 찾고 새로운 기술과 난이도를 높여 지속적 개선을 이루어 나가는 것입니다. 이러한 단계는 계층적 구조가 아니라 케익조각처럼 프랙티스를 뽑아서 관리, 기술, 측정 및 개선을 구성할 수도 있을 것입니다.

애자일에서는 일, 주, 월/분기 단위로 주기를 이루어 수행될 활동들이 있습니다. 이런 주기는 고정된 것이 아니라 1시간 안에 일, 주기, 월 단위 활동이 비율에 따라 이루어질 수 있습니다. 마치 프랙탈과 같은 구조이지요. 일단위 활동은 주간 및 월간 활동보다 잦은 빈도로 이루어져야 합니다.

애자일 개선에서 어떤 것부터 먼저 개선하는 것이 투자 대비 수익이 많이 날지도 중요한 결정입니다. 소위 ROI(Return of Investment)가 높은 것이 좋겠지요. Barry Boehm은 소프트웨어 공학 경제학(Software Engineering Economics)에서 소프트웨어 비용 대비 효용을 내는 Cost Driver Category를 도구, 인력, 시스템, 관리도 나누어 분석했는데 그 결과가 흥미롭니다. 도구를 통해 3이라는 비용 절감 효과를 낸다면, 인력의 경우 11, 시스템은 17, 관리는 무려 64의 효과가 있다는 것입니다. 도구보다는 관리를 변경하다면 무려 20배가 넘는 효과가 있다고 한 것입니다. 그러나 조직에서는 그 반대로 행하는 경우가 많습니다. 도구를 가장 먼저 바뀌고, 그 다음에 교육 등을 통한 인력, 시스템 그리고 제일 나중에 관리를 변경합니다. 비용 대비 효용이 가장 적은 순서를 따르고 있는 것입니다.

개발조직에서 Done의 기준이 느슨해질수록 테스트된 동작하는 기능이 줄어듭니다. 결함이 늘어나고 수정이 오래걸리며 점점 부채에 눌려 생산성이 줄어드는 것입니다. 국내 소프트웨어 진흥원에서 2012년에 발간한 SW공학백서를 살펴보면 이를 확인할 수 있습니다. 국내 220개 개발업체 중에서 데이타 수집이 가능한 75개 프로젝트를 분석한 결과를 보면, 결함밀도 수준을 결정하는 가장 중요한 변수는 생산성입니다. 생산성이 높은 조직이 결함제거활동을 잘 수행하였으며 비용 및 납기 초과도 적었습니다. 보다 자세한 분석 내용은 “국내 SW기업의 결함제거활동과 프로젝트 성과 분석 결과“를 살펴보시기 바랍니다.

애자일 개선 시나리오의 마지막 영역은 애자일 마인드셋입니다. 애자일 방법이라고 개발기술이나 관리방법에만 초점을 맞추기 쉽습니다. 그러나 애자일을 도입하는 조직에서 실패하는 원인은 기술적 장벽보다 변화에 대한 저항에서 기인하는 경우가 많습니다. 애자일과 패턴의 대가인 린다 라이징(Linda Rising)은 “Fearless change” 저서에서 변화를 위한 패턴을 얘기합니다. 도움 요청하기(Ask for Help Pattern), 같이 식사 하기(Do Food Pattern), 간식 곁들이기(Do Food Pattern), 음식을 싸와서 회의하기(Brown Bag Pattern), 칭찬하기(Just Say Thanks Pattern), 주기적으로 연락하기(Stay In touch Pattern), 가벼운 주제를 통해 의견에 동조하는지 알아보기(Test the water pattern) 등 조직에 새로운 아이디어를 불어넣고 실천하기 위한 48가지 패턴을 설명하고 있습니다. 각자의 상황에서 적절한 패턴을 찾아 변화를 시도해 볼 것을 제안합니다.

흔히 자기조직화(self-organization)라고 하면 권한을 이향하고 동기부여와 자율권을 주면 된다고 생각하기 쉽습니다. 그러나 이런 것들은 전제조건일 뿐입니다. 관리자가 10명의 조직원을 가지고 10개의 일이 있을때 각각 1명씩에게 일을 나눠 주기 쉽습니다. 이는 자기조직화하는 방법이 아닙니다. 10개의 일 중에서 3개를 먼저 10명의 팀원들에게 주어 서로가 관심섞기 (mingling of concerns)를 할 때 자기조직화가 이루어집니다. 관심섞기를 통해 화학작용 같은 시너지 효과를 경험할 수 있습니다. 3개를 마치고 다시 4개를 같이 수행할 수 있는 것입니다. 또한 정보방열기 역할을 하는 화이트보드에 붙이는 대시보드는 자기조직화의 도구입니다. 시각화는 현재의 위치와 계획간의 간격을 좁혀가며 목표를 향해 도달해 나갈 수 있게 만들어주는 네비게이터입니다.

애자일이 강조하는 가치의 원천은 고객이고 비지니스입니다. 결코 기술이 아닌 것이죠. 짧은 주기 반복과 피드백은 학습을 위한 강력한 메커니즘입니다. 즐겨 사용하는 “日日新 又日新(일일신 우일신)”이라는 말은 모두 배움에 관한 것입니다. 우리는 1만 시간의 법칙으로 전문가가 되는 방법을 잘 알고 있습니다. 그러나 1만 시간은 단순하게 시간이 누적되어 쌓이는 개념이 아닙니다. 계획되고 몰입된 강도 높은 훈련의 시간을 의미합니다. 어영부영한 10년차 개발자보다 훈련된 3년차 개발자가 고수가 될 수 있습니다.

일반적으로 새로운 지식으로 배운다고 했을 때, 보통 우리는 서술 지식(declarative knowledge)을 얻게 됩니다. 즉 “애자일은 무엇이고 어떤 기법들이 있다”라는 내용입니다. 하지만 이를 적용하는데 보다 필요한 것은 서술지식이 아니라 절차지식(procedural knowledge)입니다. 절차지식은 “이런 경우에는 어떻게 한다”라는 형태의 지식입니다. 따라서 절차지식은 말로 표현되거나 설명하기 어렵습니다. 예를 들어, 춤을 배운다고 했을 때 춤추는 방법을 책에서 보고 따라 해봐도 잘 되지 않습니다. 절차지식은 서술지식과 달라서 외우거나 따라한다고 잘 익혀지지 않습니다. 애자일에 잘 활용하기 위해서 책을 통한 이론적 지식 습득에는 한계가 있습니다. 애자일 커뮤니티에 참여하여 피드백을 교환하고 전문가에게 의견을 구해보는 것이 애자일을 잘 배울 수 있는 방법입니다.

Kent Beck은 2003년 Computer (IEEE Computer Society에서 발행)에 실린 “Agility through Discipline: A Debate”에서 기민함은 강한 규율(discipline)을 통하여 얻을 수 있음을 강조합니다. 일반적으로 전통적 개발방법이 규율이 강하다고 생각하지만 애자일은 팀내부에서 합의한 규칙(rule)을 존중하고 Done의 기준을 맞추기 위해 더욱 높은 규율을 요구합니다. 자유는 책임을 질 수 있어야만 유효한 것입니다. 양심에 비춰 부끄럼이 없는 업무윤리와 끊임없는 개선을 추구하려고 하는 장인정신이 필요하죠. 일이 귀찮고 힘들때, 남이 알아주는 것도 아닌데, 중요한 기능도 아닌데, 돌아만 가면 돼는데, 나중에 처리해도 되는데, 해봐야 또 바뀔텐데…스스로에게 이런 변명이 늘어난다면 애자일을 하고 있는 것이 아닙니다.

글 : 황순삼
출처 : http://goo.gl/Q9xHzf