애자일 프랙티스의 실제 활용사례

애자일 방법론을 공부하거나 실무에 적용하려고 노력하는 분들은 많지만

막상 우리나라의 정서나 실무 환경에서 적용해서 성공을 거두기란 참 어려운 일입니다.

오늘은 한국 스프링 유저 그룹 KSUG 와 블로그 http://www.younghoe.info/를 운영하고 있는

안영회 님이 자실의 활용 사례를 기반으로 마이크로소프트웨어에 기고해 주신 내용을 옮겨봅니다.

애자일 방법론에 관심있는 개발자 분들께 도움 되시길 바라며

아이마소 홈페이지에 더 유익하고 재미있는 자료들이 많다는 점 참고해 주시길... ^-^*

국내 SI 프로젝트 현장에서는 문화적인 요소 때문에 애자일 방법론 보급이 힘들다는 얘기를 종종 듣는다. 애자일 방법론 도입을 통해 이미 구축한 기존의 방법론을 대치하거나 지금까지 해오던 방식을 완전히 바꿔버리겠다는 발상은 오히려 애자일(?)하지 못하다. 필자는 애자일 방법론이나 프랙티스 전문가는 아니지만, 현장에서 애자일 프랙티스(Agile Practices)를 적절히 적용하여 효과를 보았다. 실제 사례를 널리 알려 현장에서 소프트웨어 구축에 힘쓰는 이들에게 작은 영감이라도 주고자 이 글을 쓴다.

안 영 회 ahnyounghoe@gmail.com | ㈜ITwise 컨설팅에서 소프트웨어 공학 컨설턴트로 일하고 있다. 지난 2005년 국내 대규모 프로젝트에 스프링 프레임워크 적용을 성공한 이후 한국스프링사용자모임(KSUG)을 만들어 운영하고 있기도 하다. Younghoe.info 블로그를 통해 자신의 경험을 공유하고 있다.

프로젝트 제안 단계에서 애자일 방법론을 채택한 이유는 프로젝트 특성 때문이다. 프로젝트 팀원의 숫자는 적은데 반해, 개발 범위는 다소 무리가 아닌가 싶은 수준이었다. 이런 가운데 국내 SI에서 주류로 채택하는 CBD 방법론은 많은 산출물을 요구하기 때문에, 애자일 방법론의 하나인 스크럼(Scrum)을 선정했다. 다만, 산출물 명칭과 양식만 기존 SI 프로젝트의 형식과 유사하게 수정하여, 새로운 방법론 도입에 따른 거부감을 최소화하려고 노력했다. 프로젝트 착수 이후 3.5개월여 시간이 흐른 지금 프로젝트 양상은 애초에 예상했던 것보다 바람직한 모습으로 진행되고 있다.

아직 두 달여 시간이 남은 시점에서 성공을 운운하는 것은 성급한 일이지만, 애자일 소프트웨어 개발(Agile Software Development) 적용만 놓고 보면 분명 성공적이었다. 이 글에서는 성공적이었다고 스스로 평하는 내용들에 대해서 살펴보고자 한다. 그러나 다른 프로젝트에서도 보편적으로 적용하기 위한 일반화를 시도하는 것은 아니며, 애자일 소프트웨어 개발이 지향하는 원칙에 입각해서 어떻게 해법을 찾았는지 그 과정을 공유하려는 것이 이 글의 목적이다.

애자일 선언

이 글에서는 애자일 소프트웨어 개발 혹은 애자일 방법론 자체에 대해 설명하지는 않을 것이다. 실제로 스크럼(Scrum)을 채택했다고는 하나, 이미 필자는 RUP(Rational Unified Process) 류의 방법론에 익숙해 있고, 스크럼 자체에 대한 필요 이상의 학습비용을 지불할 생각이 없다. 그보다는 과거의 프로젝트 수행 경험에 비춰볼 때 애자일 선언(Agile Manifesto, http://www.agilemanifesto.org/)은 매우 공감하는 가치 기준을 제시해 주었고, 이를 현장에서 활용하고자 했다. 애자일 선언에서는 소프트웨어 개발 방식에 있어 대비되는 가치를 기준으로 추구하는 바를 정의한다.

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

각 항목에 대한 내용을 여기서 설명하기보다 사례와 함께 이야기하도록 하겠다.

프로젝트 단계

프로젝트는 도입, 구축 및 이행의 3단계로 나누어 진행하고 있다. 아직 이행 단계를 수행하지 않은 시점이라 도입과 구축 단계에 대해 사례를 짚어본다. 각 단계별로 애자일 선언의 가치 기준을 기초로 애자일 프랙티스 적용이 종래의 경험에 비해 어떠한 개선을 가져왔는지 살펴보자. 사전 정의 없이 애자일 프랙티스라는 말을 사용했는데, 앞으로 ‘애자일 선언의 가치에 준하는 문제 해결책’을 애자일 프랙티스라고 지칭하겠다. 

도입 단계에서의 애자일 프랙티스

도입 단계는 전체 26주의 기간 중에서 초반 4주에 해당한다. 프로젝트 범위를 결정하는 기간인데, 이때 가장 초점을 맞춘 부분은 실현 가능한 계획 수립과 요구사항의 확정이다. 여기까지는 사실 애자일 소프트웨어 개발이 어떤 도움을 주었는지 살펴보자. 자, 이제 애자일 선언의 가치 기준이 등장할 시간이다.

● 변화를 수용할 수 있는 계획을 세운다 - Responding to change over following a plan

애자일 선언에서는 계획을 따르는 것도 가치가 있지만, 그보다는 변화에 대한 적응에 더 높은 가치를 부여한다고 강조한다. 필자가 앞서 참여한 대부분의 프로젝트에서는 WBS를 작성하는 데 많은 공수를 소요했다. 고객과 개발팀은 WBS를 PMS 등을 이용하여 공유하고, WBS 상의 계획을 기준으로 진척을 산정했다. 프로젝트가 새로운 업무나 기술을 다룰수록,  그리고 규모가 클수록 더 많은 변화의 가능성을 내포하고 있다. 하지만 대개의 경우 조기에 수립한 계획을 변경하는 일은 무척 번거로운 과정을 거쳐야 했다.

우리 프로젝트의 경우도 단위 시스템 개발이 아닌 플랫폼 성격의 제품 개발이기 때문에 전략적 결정에 의해 요구사항 변경의 여지가 많다. 또한 고객 스스로도 필요한지 확신을 갖지 못하는 요구사항에 대해서도 유리한 고지를 점하기 위해 계약에 명시하고 있었다. 이와 같이 변경 가능성을 내포하고 있는 항목을 기준으로 계획을 수립한다면, 계획 변경의 여지가 많아진다. 이런 경우 먼저 변경할 수 있는 것과 할 수 없는 것을 구분해야 한다. 가장 먼저 고객사의 WBS 양식과 샘플을 구했다. 계획 사항 중에서 내규에 따라 진척 평가가 어떻게 이루어지는지 파악했다. 이를 기준으로 특정 단계까지는 가중치를 고정하고, 해당 단계 하위의 작업 항목에 대해서는 변경하여도 진척 평가에 영향을 미치지는 않게 했다.

<화면 1>에서 우측 음영 처리가 있는 부분의 글은 WBS 변경에 대한 메모다. 프로젝트 중반 이후부터는 변경이 발생했다는 이야기다. 만일 이 부분에 대해 도입 단계에서 고정해 두었다면, 고객의 이해를 구하기 위한 설득 작업이 필요했을 것이다. 경우에 따라서는 고객이 계층적으로 존재하여 많은 보고 절차가 빈번하게 필요하기도 하다. 다행히 우리는 이러한 번거로운 절차를 피할 수 있었다. 이로써 얻은 교훈은 필연적으로 바뀔 가능성이 있는 부분을 인정하고 여지를 두라는 것이다. 

● 소프트웨어에 집중하라 - Working software over comprehensive documentation

현장에서 종종 지나치게 상세한 명세 작업 혹은 표준화 및 기법에만 초점을 맞춘 요구사항 모델링으로 비생산적인 분석 작업을 하는 것을 경험한다. 종국의 결과물은 작동하는 소프트웨어란 사실을 잊지 말아야 한다. 도입 단계에서 모호한 요구사항을 밝혀내는 일은 쉽지 않았다. 고객들마저 정확하게 무엇이 필요한지 모르는 상황이기 때문이다. 조기에 확정하기 어려운 것을 정하는 데 지나치게 시간을 투여할 우려가 있어 명세 자체보다는 요구사항 충족 기준이 되는 검증 기준 수립에 초점을 두었고 이는 <표 1>에서 보는 바와 같다. 이로써 약 10주 후에 소프트웨어를 구현했을 때 사용할 지표를 2주 만에 만들 수 있었다. 앞서 말했던 것처럼 무리한 듯 보이는 개발 범위에도 불구하고, 10주 후 70개의 모든 기준을 충족시킬 수 있었던 요인 중에 하나는 ‘5대1’ 비율, 즉 ‘요구사항 정의 2주 대 소프트웨어 개발10주’에 있다.

구축단계에서의 애자일 프랙티스

도입 단계는 전체 26주의 기간 중에서 중반 15주에 해당한다. 실제 제품 개발의 대부분을 수행하는 단계이다. 애자일 프랙티스를 도입했을 때 구축 단계의 가장 두드러진 특징 중 하나는 조기에 통합이 이뤄진다는 점이다. 이는 이행 단계의 부담을 한결 줄여준다. 결론부터 말하자면 조기 통합 및 상시 통합 수행은 구축단계에서 빠른 피드백과 팀 협력을 가속화하는 효과를 가져왔고, 이행 단계로 연착륙할 수 있게 하는 데 큰 공헌을 했다. 

● CI 적용 과정에서 배운 협업의 가치 - Individuals and interactions over processes and tools

프로젝트 초기에 필자는 툴과 프로세스에 초점을 맞춰 환경을 잘 구비하고 단위테스트만 잘 실시하면 CI(Continuous Integration), 다시 말해 지속적인 통합이 가능할 것이라고 보았다. 그러나 툴의 이점은 분명히 한계가 있었고, 프로세스 실현은 그리 간단하지 않았다. 우리는 이번 프로젝트 처음으로 손발을 맞춘 팀이었고, 당연히 프로세스가 몸에 밴 팀은 아니었다. 또한 프로젝트 일정 역시 프로세스를 익힐 만큼 여유 있지는 않았다. 여기서 필자는 해결책이 필요했다. 결국 개개인의 특성 파악으로 들어갔다. 프로젝트를 하면서 종종 그 사실을 잊어버리지만, 우린 모두 개성을 지닌 존재이다.

우선 각자 자신이 만들어야 할 산출물을, 그리고 해당 산출물을 통한 다른 사람과의 관계를 표현하게 했다. 작업자와 산출물 사이에 선을 그으면 행위가 나타난다. 필자는 이를 문맥도(context diagram)라 칭하고 모두에게 편한 방식으로 그려오게 했다. 흥미롭게도 관리자인 필자와는 달리, 대부분의 사람들이 주변 개발자와의 관계를 완벽하게 알지 못했다. 필자는 그 부분을 찾아서 그려주었다. 이후에 팀원 개인과 서로가 맺고 있는 관계(Individuals and interactions)가 정형화된 부분에 대해서만, 이를 프로세스로 정의해 공유했다.
문맥도를 그려보기 이전에는 팀원들이 자신의 작업에만 관심을 둔다고 오해했다. 팀원들은 다른 팀원의 일에 관심이 없었던 것이 아니었다. 전체를 볼 수 있는 사람이 서로 협력이 필요함을 알게만 해준다면 문제는 스스로 해결되었다.

● 고객과 마치 하나의 팀처럼 협력하라 - Customer collaboration over contract negotiation

프로젝트에 잔뼈가 굵은 사람이라면 ‘계약서’, ‘날인한 회의록’, ‘명세서’ 등을 중요하게 취급한다. 하지만 분쟁이 발생했을 때 이들이 개발팀을 유리한 입장에 놓을 수 있을지 몰라도, 그 이상의 가치는 없다. 구축 기간 초반에 앞서 언급한 것처럼, 70개의 기준을 충족했을 때 고객과 개발팀 사이에 신뢰 관계가 형성됐다. 신뢰 관계는 고객과 사전 협의한 사항에 대한 변경이 용이해졌음을 의미한다. 개발팀은 애초부터 지나치게 기술적인 어려움을 의식해서 요구사항 수용을 거부할 필요가 사라졌다. 고객은 언제든지 개발팀의 입장을 이해할 준비가 되어 있었다. 개발팀은 신뢰를 깨뜨리는 우를 범하지 않는 이상 계약관계에 입각해 서로를 인식하는 데 에너지를 쏟는 대신에 본연의 활동 즉, 개발에 대해 집중할 수 있었다. 자신감을 얻은 우리는 고객의 요구사항 수집에 있어서도 장벽을 제거했다.

우리는 <화면 3>과 같이 개발도구에서 작업목록을 볼 수 있는 환경을 구축하고 있는데, 고객이 직접 올린 요청사항을 작업목록에 포함시켰다. 고객 요청의 즉각적인 수렴과 기민한 커뮤니케이션은 고객의 개발팀에 대한 신뢰감을 더욱 높여주었다. 종국에 고객과 개발팀의 협력은 마치 오랫동안 함께 해온 조직 구성원의 일상적인 협력을 보는 듯했다. 물론 이러한 협력을 모든 프로젝트에서 실현할 수 있다고 할 순 없을 것이다. 착수 보고 때 프로젝트 스폰서인 임원이 ‘고객’이라는 말에 대해 거부감을 표시하며, ‘어차피 같이 일하는 사람인데 고객은 무슨’이라며 호칭을 나무랐다. 고객들은 향후 인수인계와 기술 이전을 받는 데 매우 적극적이었기 때문에 고객과 마치 한 조직 내에 속한 다른 팀처럼 일할 수 있었다.

경험의 산물, 애자일 프랙티스

애자일 프랙티스는 SI 개발 환경에서 오랜 논의 끝에 나온 경험의 산물이다. 연구소나 학계에서 나온 것이 아니란 점에서 ‘새로운 방법론의 하나’로 취급하는 것은 실용적이지 않다. 오히려 현재 사용하는 혹은 익숙한 방법론이나 개발 프로세스를 사용하면서도 단계적으로 애자일 프렉티스를 충분히 적용할 수 있다. 이 글은 이에 대한 하나의 사례를 제공함으로 해서 현장에 응용하기 위한 논의의 단초를 제공하는 데 의미를 지닌다.

 

<프로젝트 수행 과정에서의 갈등 그리고 조화>

나이가 들수록 조화와 균형을 배운다. 어릴 때는 ‘이것이 옳다’ 싶은 것에 대해선 물러서지 않았다. 다른 사람과 어울림을 통해 다른 생각이 있다는 것을 배우고, 점차 나를 둘러싼 주변과의 어울림을 받아들인다. 어떤 이는 이를 세상과 타협하는 것이라 하지만, 조화를 이루기 위해 나와 생각이 다른 사람과 타협할 뿐이다. 프로젝트를 수행하다 보면 필연적으로 많은 변수를 맞이한다. 참여하기로 했던 개발자가 불가피한 이유로 참여를 못할 수도 있다. 다른 업체나 부서의 사정으로 장비 구매가 늦을 수도 있다. 더러는 가장 중요한 협업 담당자가 장기 출장을 가버리기도 한다. 어디 이런 일이 한 두 가지뿐이겠는가? 흔히 발생하는 경우는 아니지만, 개발 도중에 법이 바뀌거나 고객 조직의 대대적인 인사이동으로 인해 프로젝트 자체가 위기에 몰리기도 한다. 만일 프로젝트 초반에 구체적으로 일정을 수립했다고 했을 때, 앞서 언급한 일이 벌어져도 이를 완벽하게 맞출 수가 있을까?

또뜨웍스(ThoughtWorks)사의 직원들이 출간한 책 “The Thought Works Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)”의 7장에서 의사결정의 적기에 대해 이야기하는 부분은 이 문제에 대해 훌륭한 영감을 준다.

많은 사람들이 불확실한 것을 미리 분명하게 계획해 두려는 경향이 있다. 하지만 예측이 힘든 일은 너무나도 많을 뿐더러 판단에 필요한 정보를 충분히 수집한 후에 결정해야 실행에 옮기기 쉽다. 필자는 일년 단위로 업무 성과를 측정하는 기업에서 발주한 프로젝트에 참여한 바 있다. 담당 부서에서는 프로젝트 진척을 자신들이 해오던 식으로 파악하고자 했다. 그래서 매 2주마다 진척 산정이 가능한 작업을 계획해주길 원했고, 가능하다면 모든 작업은 고유한 산출물을 제출해주길 원했다. 그런데 우리 프로젝트는 요구사항에 대한 가변성이 너무 높았다. 우리는 이미 수십여 개의 기능 목록을 달성한 프로젝트를 수행한 이후였다. 고객은 우리가 만든 제품을 특정 프로젝트마다 필요한 다양한 기능을 추가하기 위해 좀 더 튜닝해주길 원했다. 하지만 우리 제품을 채택한 프로젝트의 요구에 따라 작업 내용은 달라질 수밖에 없었다. 물론 사전에 요구사항을 정하면 되겠지만, 고객들은 해당 시점에 결정하길 원했다. 이런 경우 우리는 어떻게 가변적인 요소를 수용하면서 해당 기업의 평가 방식에 부합하는 계획을 만들 수 있을까?

우리는 나름의 답을 찾았다. 그것은 어디에나 적용할 수 있는 답은 아니고, 만들어낸 과정조차 명확하지 않다. 필자는 개발팀을 대표하여, 해당 부서 책임자와 함께 평가조직 담당자를 만나 머리를 싸매 협의했다. 그리고 또 다른 실무자들과 머리를 맞대어 논의한 후, 부족하게라도 합의한 것을 메모로 정리했다. 이를 기초로 초안을 계획하고, 다시 해당 부서 책임자와 검토했다. 그는 다시 스스로 이를 정제한 후에 검토를 요청했고, 수일 후에는 앞서 협의에 참여한 이해관계자가 고개를 끄덕일만한 계획표를 만들어냈다. ‘조화’라는 말은 듣기에 좋다. 하지만 조화를 이뤄낸 과정을 들어다 보면, 이와 같이 끈질긴 갈등과 타협으로 이루어진다.