6a00d8341ca4d953ef01a511e114a3970c

프로젝트 방법론, 이상과 현실사이(2) – 애자일 방법론 적용후기

1편에서는 프로젝트를 수행할 때 가장 일반적으로 사용하는 워터폴 모델과 소개해 드리고 싶었던 애자일 모델에 대해 간략히 설명을 드렸는데요. 지금부터는 애자일 모델을 실제로 경험해보고 느낀 장점과 단점에 대해 나름의 정리를 해보도록 하겠습니다.

너무 개발자 중심의 방법론이다.

애자일 모델은 기획자, 디자이너 보다는 개발자의 역량과 퍼포먼스에 초점이 맞춰진 방법론이 아닌가 생각됩니다.
물론 방법론의 출발점이 Less Document-Oriented, Code-Oriented 이기 때문에 어쩔 수 없는 부분이지만, 제한된 시간과 비용 안에서 전체적인 플랜없이 기능위주의 개발로 진행된다면, 불완전하고 예측 불가능한 위험요소를 지닌 채 프로젝트가 진행될 가능성이 높습니다.

기획자와 디자이너는 매 스프린트 회의에 참석하여 개발자로부터 프로젝트의 진행사항을 공유 받게 됩니다.
하지만 여러 개로 나뉜 기능위주의 개발 객체를 보며, 전체적인 페이지의 디자인과 플랜을 세우기란 여간 어려운 일이 아닙니다.

실제로 처음 잡았던 디자인 컨셉이 개발된 기능에 의해 여러 번 변경되는 현상이 발생했고, 워터폴 모델에 익숙하던 저희 TF는 멘탈붕괴(?)를 경험하기도 했습니다.

애자일이라 쓰고 무한수정이라 읽는다.

위에 언급한 멘탈붕괴의 가장 큰 이유입니다.
한 페이지를 기획하거나 디자인 할 때 기획자나 디자이너는 수없이 많은 고민을 하게 됩니다.
‘어떤 방식이 좋을까? 어떻게 표현해야 할까? 하는 고민들 말입니다.

하지만 애자일 모델은 조금 달랐습니다.
‘고민중인 선택지를 모두 적용해보고 가장 괜찮은 것을 쓰자’ 였던 거죠.
이를 몰랐던 저희는 많은 고민 끝에 내놓은 디자인을, 선택 가능한 옵션만큼의 수정을 반복한 다음에서야 컨펌을 받을 수 있었습니다.

물론 다른 프로젝트에서도 이런 수정이 빈번했기 때문에 그러려니 했습니다만, 이후 생성되는 거의 대부분의 디자인 페이지에서 위와 같은 일이 반복되며 디자이너들의 인내심이 부처님의 경지에 이르는 과정을 지켜보기도 했습니다.

애자일 모델에 많이 익숙해진 지금은 수정이라는 생각보다는 ‘하나의 과정’이다 라고 생각하며 업무를 수행하고 있습니다.
(아니면 이미 부처님이 되었던가..^^;;)

애자일과 통계의 시너지, 혹은 역 시너지

애자일 모델과 통계를 묶어보면 시너지 효과가 상당한 조합입니다.
통계를 통해 사용자의 반응을 살피고 수정이 필요한 항목(기능)을 분석해 냅니다.
수정이 필요하다 판단되는 항목(기능)을 애자일 모델에 적용하여 스크럼을 짜고 스프린트를 통해 빠르게 보완합니다.
그리고 보완된 항목(기능)에 대한 모니터링 후 이전의 통계 데이터와 비교 분석하여 다시 또 유의미한 결과를 도출하게 되는 것이지요.

하지만, 수정이 필요한 항목(기능) 위주의 수정이 빈번히 발생하게 되면 전체적인 디자인의 톤(Tone)이 무너지게 됩니다.
하나하나의 기능은 매우 훌륭하나 웹사이트 내에서 조합이 되지 않는 느낌이랄까요?

물론 이 부분 또한 기획/디자인에서 수정하여 결국은 조화로운 웹사이트를 만들어 내겠지만 주객이 전도된 느낌을 지울 수 없습니다. (물론 제가 워터폴 모델에 너무 익숙한 탓일 수도 있겠습니다)

애자일 모델이 적용된 프로젝트는 디자인 요소를 많이 쓰지 않고 각각의 요소를 심플하고 간결하게 처리한 뒤 모듈화 시키면 더 좋을 것 같다는 생각을 했습니다.
각각의 기능을 모듈화하여 블록을 쌓듯 여러 형태로 배치해볼 수 있는 구조 말입니다.

틀리지 않다. 다르다.

사실 애자일 모델을 처음 접하고 매우 혼란스러웠습니다.
전체적인 플랜을 짜는 것이 무의미하게 느껴졌고, 수없이 많은 고민을 담은 디자인이 손바닥 뒤집듯 수정되는 모습을 보며 애자일 모델은 틀린 모델이다! 라고 혼자 단정짓기까지 했습니다.

하지만 시간이 지나 애자일 모델에 대해 조금 더 경험하고 이해하다 보니 애자일 모델은 틀린 것이 아니라 다른 모델이었습니다.
조금 더 개발자에 맞춰진 모델이고, 문서 보다는 사람을 중심에 놓고 소통하며 업무를 진행해 나가는 방식으로 말이죠.

간단히 워터폴 모델과 애자일 모델의 다른 점을 정리해 보자면 아래와 같습니다.


워터폴 모델 (Waterfall Model)

초기에 미리 정의된 요구사항
미리 요구사항을 파악하고 프로젝트 전체에 대한 분석이 가능

큰 릴리즈
정형화된 프로세스에 따라 주기 별 릴리스, 업데이트가 비교적 느림

계획중심
프로젝트에 대하여 완벽한 계획을 수립하고 진행

적은 의사소통
문서중심의 방법론으로 문서에 근거하여 프로젝트를 수행: 문서 중심

단계별 개발
초석부터 차근차근 단계를 거쳐 튼튼한 기반의 개발 (하드웨어 적합)

단계별 산출물 전달
계획 중심적 방법론으로 정해진 단계가 완성됨에 따른 산출물 점검

마지막 통합
초기 계획이 완전하다는 가정하에 중간 통합 없이 최종 프로세스 수행 후 통합 후 문제점 도출 및 해결

애자일 모델 (Agile Model)

프로젝트 과정에 걸쳐 생기는 요구사항
미리 모든 요구사항을 알 수 없다는 가정하에 시간적 변화를 인지하고 지속적으로 요구사항을 수렴

작고 빠른 릴리즈
고객이 원하는 것을 파악하여 가능한 빨리 니즈를 충족 시키는 것을 중요시

학습 중심
최소한의 지식으로 시작하여 단계를 거듭, 학습

많은 의사소통
프로젝트 팀 간, 고객 간의 많은 의사소통으로 진행되는 프로젝트: 사람 중심

기능별 개발
고객의 니즈를 빠르게 반영하여 개발하는 과정을 짧은 주기로 반복

지속적인 산출물 전달
프로젝트 진행 중 잦은 산출물 공유로 수정사항에 빠르게 대처

잦은 통합
기능별 완료 시기에 맞춰 잦은 통합과 문제점 도출 및 해결


개발 기법에는 워터폴 모델, 애자일 모델 이외에도 다양한 방법론이 있습니다. 기회가 된다면 한번쯤 공부해 두는 것이 나중에 실제로 맞닥트렸을 경우 저처럼 당황하지 않는 좋은 방법이 될 것 같습니다.

이 글이 다양한 개발 기법을 경험하지 못했던 분들에게 작게나마 도움이 되길 바랍니다.
언제든지 궁금한 점은 댓글 남겨주십시오.^^
감사합니다.

– 가치 UX 그룹 김유진

* 메인이미지 출처. http://herdingcats.typepad.com/

Share this:

Leave a comment