프로젝트 방법론, 이상과 현실사이(1) – 워터폴 vs 애자일

프로젝트 방법론, 이상과 현실사이(1) – 워터폴 vs 애자일

프로젝트 방법론, 이상과 현실사이(1) – 워터폴 vs 애자일
Category
Share Story

UX 프로젝트를 이끌고 진행하며 딱히 ‘방법론’에 대해 고민해본 경험은 다들 많지 않으리라 예상됩니다. 지금까지 그래왔듯 기획, 디자인, 퍼블리싱, 개발 파트로 업무를 나누고, 프로젝트 기간에 맞춰 순차적으로 진행하면 되리라 생각하기 때문이죠.

사실 각 프로젝트의 핵심가치, 환경, 컨디션 등을 고려해 최적의 개발 모델을 사용하는 것이 가장 이상적인 프로젝트 수행방법이라는 것은 잘 압니다.
하지만 현실적으로 부딪히게 되는 비용, 기간, (고객사와의)협업 숙련도 등 다양한 이유로, 여러 방법론을 시도해 보려는 노력은 늘 벽에 부딪히고 섣불리 시도하기 쉽지 않은 것이 사실입니다.

올해 초 운 좋게도(?) 기존과 다른 방식인 ‘애자일(Agile) 모델’을 적용한 프로젝트를 수행할 수 있게 되었습니다.
그 경험을 바탕으로 현업 프로젝트에서 가장 많이 사용하고 있는 ‘워터폴(Waterfall) 모델’과 ‘애자일 모델’에 대해 간단히 설명하고, 그 차이점에 대해 이야기 해보고자 합니다.

글에 들어가기 앞서
모든 프로젝트가 동일한 컨디션을 가지고 있지 않듯, 같은 개발 기법을 사용하더라도 진행되는 방식이 조금씩 다를 수 있습니다.
그래서 제가 겪은 한번의 프로젝트만으로 애자일은 이렇더라! 하고 일반화 시킬 수 없습니다.
혹 “내가 겪은 애자일은 그렇지 않았는데?” 라고 생각되는 분이 있더라도, 제 경험에 비추어 쓴 개인생각임을 미리 양지하고 읽어 주시면 감사하겠습니다. ^^

일상적이고 익숙한 워터폴 모델(Waterfall Model)

우리가 가장 흔하게 쓰고 있고 어쩌면 당연하다고도 생각 될 만큼 익숙한 프로젝트 수행 방식이 ‘워터폴 모델’ 입니다.
요구분석 → 설계 → 디자인 → 코딩 → 개발 순으로 순차적으로 이어지는 흐름이 마치 폭포수처럼 아래로 이어져 보인다 하여 이름 붙여졌습니다.


  그림-1

[워터폴 모델 도식화, 출처. http://slidehunter.com/]

워터폴 모델은 오랜 기간 사용된 기법이니만큼 적용 사례가 많고, 단계별로 정형화된 접근방식을 사용하는 이유로 기술적인 위험 요소가 적다는 장점을 가지고 있습니다.
정해진 순서대로 각 파트의 업무가 분장되고 관리되기 때문에 프로세스 상의 마일스톤을 정하는 것이 비교적 쉬운 편이라는 것도 장점이 될 수 있겠습니다.

하지만 실제로 각 단의 경계를 명확히 구분하고, 앞선 파트의 업무가 완전히 끝난 후 다음 단계를 시작하는 것이 거의 불가능하다는 문제를 가지고 있습니다.
그리고 실제 프로젝트를 수행할 때 가장 빈번히 마주치게 되고, 해결하기도 굉장히 까다로운 문제가 있죠.
바로 ‘고객과의 커뮤니케이션’ 입니다.

워터폴 모델을 사용할 경우 디자인이 구현되어 시각적으로 확인하거나, 개발을 통해 실제로 웹 또는 앱이 구동되는 모습을 보기 전까지, 고객사는 자신들이 요구했던 사항들의 실체를 알기 어렵습니다.
물론 화면설계 문서나 요구사항 정의서만 보고 실제 구현될 서비스의 그림을 그릴 수 있는 고객도 있긴 하지만, 매번 그런 고객사를 만나기란 쉽지 않습니다.

그래서 실제 디자인 또는 개발된 화면을 시각적으로 확인하고 나서야 수정요청이 발생하기 시작합니다.
이럴 경우 고객사의 요청을 통제할 수 있는 방법은 음… 없습니다. 많지가 않습니다.

이미 많은 단계를 지나온 상태에서 다시 되돌아가 기획단계부터 수정되기 시작하면 일정과 비용 등 여러 항목에서 애로사항이 꽃피게 되는 것이지요.
이런 워터폴 모델의 단점을 보완하기 위해 여러가지 방법론들이 생겨나고 실제 사용되고 있는데요.
그 중 하나가 제가 이번에 수행했던 애자일 모델입니다.

고객과의 의사소통을 중시하는 애자일 모델(Agile Model)

애자일 모델은 정확히 말하면 어느 특정한 개발 방법론을 지칭하고 있지 않습니다.
‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말입니다.

예전에는 애자일 개발 프로세스를 경량(Lightweight) 프로세스 라고 불렀다고도 합니다.
애자일 모델이 다른 방법론과 구별되는 가장 큰 차이점은 Less Document-Oriented, 즉 문서를 통한 개발이 아니라 Code-Oriented, 실질적인 코딩을 통한 방법론이라는 점입니다.

그림-2

[ 애자일 모델 도식화, 출처. http://slidehunter.com/ ]

애자일 모델은 전체적인 플랜을 짜고 문서를 통해 주도해 나가던 과거의 방식(워터폴 모델)과 달리 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어 내며 필요할 때마다 요구사항을 더하고 수정하여 커다란 소프트웨어를 개발해 나가는 방식입니다.

이렇게 실질적인 프로토 타입이 계속해서 생산됨으로 고객이 개발과정에 참여할 수 있는 여지가 커지는 장점을 가지고 있습니다.
기능이 실제로 구동되는 모습을 확인하고, 수정요청을 하거나 다음 단계로 넘어가는 긴밀한 관계를 형성할 수 있는 것이죠.

그림-3

[ 스크럼 프로세스, 출처: 위키백과]

애자일 방식은 일반적으로 스크럼 프로세스를 따르게 되는데, 스크럼은 보통 30일 단위로 주기를 나누고, 짧게는 1~2주 길게는 3~4주 단위의 스프린트로 쪼개서 개발하게 됩니다.
여기서 스프린트란 반복되는 개발 주기를 말합니다.
특정 기간 동안 해야 할 목표와 필요 작업을 명시하고, 실제로 어떻게 진행 되었는지 백로그(Backlog)를 남겨 각 스프린트가 끝나는 시점에 함께 모여 리뷰하고 피드백을 주고받는 형태로 업무를 진행합니다.

애자일 모델을 사용하는 사례가 많아지자, 이를 지원하는 소프트웨어들도 등장하기 시작합니다.
그 중 저희가 사용했던 소프트웨어는 아틀라시안의 ‘지라(Jira)’ 였습니다.

그림-4

[그림-4 아틀라시안의 Jira, 출처: 네이버캐스트]

해야 할 업무를 생성하고, 지난 회의에서 생성된 해야 할 일이 어떻게 진행되고 있으며, 개발이 완료되어 리뷰를 기다리는 항목은 어떤 것이 있는지 한눈에 볼 수 있도록 설계되어 있습니다.
또한 완료된 항목이 어떤 히스토리가 있는지 확인할 수 있는 백로그 기능도 잘 구현되어 있습니다.
이후 애자일 모델로 프로젝트를 진행할 계획이 있으시다면 미리 공부해 두는 것도 좋겠습니다.

이상 프로젝트를 수행할 때 가장 일반적으로 사용하는 워터폴 모델과 소개해 드리고 싶었던 애자일 모델에 대해 간략히 설명을 드렸습니다.

다음편에는 아래와 같은 내용을 골자로 실제 제가 경험한 애자일 모델에 대한 장점과 단점을 상세히 정리해 공유하려고 합니다.

  • 너무 개발자 중심의 방법론이다
  • 애자일이라 쓰고 ‘무한수정’이라 읽는다
  • 애자일과 통계의 시너지, 혹은 부작용
  • 틀리지 않다, 다르다

감사합니다.

– 가치 UX 그룹 김유진

 

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

 

* 메인이미지 출처. .fansshare.com

No Comments

  1. 정은 2015년 09월 07일 at 12:20 오후 - Reply

    좋은정보 감사합니다

    • blogadmin 2015년 09월 07일 at 2:24 오후 - Reply

      ^^ 수요일 혹은 목요일 업데이트 될 2편은 좀더 솔직하고 생생한 후기를 전달드릴 예정입니다. 감사합니다.

  2. 인광 2015년 09월 07일 at 3:21 오후 - Reply

    책임님, 좋은 글 잘 봤습니다.

  3. 도형 2015년 09월 07일 at 5:53 오후 - Reply

    좋은 글 잘 읽었습니다.
    장단점에도 쓰신 것처럼 개발위주의 방법론이어서 UX의 방법론과 어떻게 접목을 시키셨는지가 궁금해지네요. :)

    하지만, 중간에 한가지 바로잡아야 할 부분이 있어서 댓글 남깁니다.
    “특정 기간 동안 해야 할 목표와 필요 작업을 명시하고, 실제로 어떻게 진행 되었는지 백로그(Backlog)를 남겨 …..”
    사실 백로그는 앞의 설명 즉, “특정 기간 동안 해야 할 목표”이 스프린트 백로그라고 보는게 맞을 듯 합니다.
    그리고, 그보다 상위의 해야 할 일(목표)를 프로덕트 백로그라 부르고,
    스프린트 백로그보다 더 세분화된 Task는 (유저) 스토리라고 합니다.
    그래서, 실제 하나의 스프린트가 끝나면 백로그를 남기는 것이 아닌, 각각의 스토리를 가지고 회고 미팅을 하게 됩니다.

    근데, 사실 애자일 같은 경우도 회사마다 적용하는 방법이 다르기 때문에,
    꼭 위의 방식을 따르지는 않을 수도 있겠지만, 일반적인 방법이라 함께 보면 도움이 될까 싶어서 글을 남깁니다.

    다음편도 기대하겠습니다. :)

  4. 상락 2017년 01월 04일 at 2:14 오후 - Reply

    좋은글 잘 읽고 갑니다. 감사합니다.

    • blogadmin 2017년 01월 12일 at 2:51 오후 - Reply

      감사합니다. 더욱 좋은 글들로 계속 찾아 뵙도록 하겠습니다.

  5. Nagne 2017년 09월 14일 at 4:09 오후 - Reply

    Agaile은 이름만 그럴듯한 무한수정 방법론임. 개인적으로는 방법론 중 가장 이상적이라고 생각함. 단점은 PM빨이 있다는 것임. client의 요구를 기민하고 빠르게 인지하고 적당하게 조율해야 함.

    • blogadmin 2017년 09월 15일 at 9:24 오전 - Reply

      좋은 댓글 감사합니다. 앞으로 더 좋은 글 올릴 수 있도록 하겠습니다.

  6. totobiyo 2020년 04월 21일 at 8:53 오전 - Reply

    워터폴 모델을 가져온 곳이 건축으로 알고 있는데 현실에 적용하기에 불가능에 가깝지 않을까 생각합니당…
    이론에만 존재하는 것들이 있는데 개발에서 워터폴 모델이 그 중 하나가 아닐까 싶습니다

Leave A Comment