서비스 알파를 앞두고 이제 시각화된 제품이 조립되고 있으니 업무 방식을 개선하고 싶었다. 아직 아무 서비스가 없는 상태에서는 백엔드 프론트엔드가 각각의 파트들을 개별적으로 개발하고, 병합하는 것이 괜찮았다. 하지만 프로토타입이 나온 시점에서는 앞으로의 업무 효율을 높이려면 팀으로서 사용자 경험에 집중하고 두고 기능 단위의 업무를 산정해서 애자일하게 개발해야겠다는 생각이 들었다. 그런데 그 애자일. 있어보이는 IT 회사들은 모두 사용하고 있다고 해서 무작정 따라하고 싶었던건 아닐까? 하는 생각이 들었다. 각 방법론에 대한 철학을 제대로 이해하지 못한 상태에서 막연하게 ‘폭포수 모델은 구려.’, ‘애자일이 무적권 좋아’라고 생각했던 것은 아닐까?

무지성 지지를 내려놓고 폭포수 모델과 애자일 모델에 대해 다시 한번 생각해보는 시간을 가져봤다.

폭포수 모델 Waterfall methology

전통적 개발 방법이라고도 불리는 폭포수 모델은 하나의 작업이 완료되기 전에 다음 작업을 착수하지 못하는 방식이다.

1. 요구 사항 정의
2. 설계
3. 구현
4. 테스트
5. 배포 및 유지보수

하나의 사이클이 돌면 하나의 프로젝트가 끝난다. 각 단계가 순차적으로 진행되기 때문에 이전 단계가 제대로 마무리되지 않으면 다음 단계를 수행할 수 없다. 폭포수 모델은 지극히 자연스럽다. 특별한 개발 방법이라기 보다는 하다보면 따르게 되는 자연스러운 개발 흐름인 것 같다. 그럼 자연스러운게 나쁜거냐? 꼭 그렇지만은 않을 것이다. 그걸 알고 가는게 이 포스트의 주제니까 한번 진지하게 생각해보자. 우리는 언제 폭포수 모델을 쓸 수 있을까?

언제 폭포수 모델의 장점이 극대화될까? 요구 사항 정의와 시스템 설계가 프로젝트의 가장 초기에 진행됨에 주목해본다. 우리는 첫 두 단계를 통해 전체 프로젝트의 작업 내용을 어느정도 정해놓고 출발하게 된다. 이로부터 비롯되는 장점은 다음과 같다.

• 요구사항이 미리 fix되면 시스템 설계가 비교적 쉽다.
• 프로젝트의 작업량과 크기를 가늠하기 쉽다.
• 미리 정한 전체 윤곽에 따라 개발이 진행되기 때문에 소프트웨어 엔지니어 입장에서도 구현 단계가 비교적 단순하게 느껴질 수 있다.

이 외에도 폭포수 모델에서는 각 phase의 역할이 명확하기 때문에 기획자, 디자이너, 개발자 등의 여러 구성원이 프로젝트의 phase에 따라 참여 시기를 정하기 쉽다.

그런데 장점에 대해 생각해볼수록 왠지 실무에서는 폭포수 모델이 비효율적일 것 같은 느낌이 팍팍 든다. 왜냐하면 실무에서 프로젝트의 요구사항은 갈대마냥 흔들리기 마련이기 때문이다. 위에 기재된 폭포수 모델의 장점들은 요구 사항 정의와 설계가 아주 잘 수행되었을 때 발현된다. 프로젝트 중간에 요구 사항 정의가 바뀐다면 설계와 구현에 미치는 영향이 아주 클 것이고, 요구 사항 변화의 정도가 크다면 프로젝트 뿌리가 흔들릴 것이다.

자연상태의 폭포는 중력을 거슬러 거꾸로 올라가지 않는다. 따라서 폭포수 모델은 이전 단계에서의 수정 빈도를 최소화시킬 수 있을 때 가장 효과적인 방법이라 하겠다. 폭포수 모델이 효과적일 수 있는 실제 사례는 어떤 것이 있을까?

• 토이 프로젝트로 카피앱을 만들때는 요구사항이 변할 일이 거의 없다. 카피할 앱을 분석하고, 설계하고, 구현하고, 테스트하고. 이전 단계의 변화가 거의 없는 상태에서 폭포수를 흘려보낼 수 있다.

• 용도가 뚜렷한 “서비스 내부 API”를 구현할 때에도 폭포수 모델이 적합할 수 있다. 용도가 뚜렷하다면 요구 사항이 명확하게 정의되기 수월할테고, 설계, 구현, 테스트, 배포 및 유지보수가 자연스럽다.

• 정부 사업을 따냈다면 폭포수 모델이 적합할 수 있다. 정부 사업의 특성상 요구 사항이 한번 정의되고 문서화되어 제출, 통과되면 좀처럼 수정되는 경우가 없다. 따라서 폭포수 모델의 다음 단계들이 극적으로 변화할 가능성이 낮다.

서비스를 개발하다가 Client의 요구 사항이 바뀌거나, 시스템 설계가 수정되는 일이 빈번하다면 폭포수 모델은 효율성을 잃게 될 것이다. 이전 단계가 마무리 되기 전에 다음 단계로 갈 수 없다는 것은 이전 단계가 수정되면 다음 단계에 해야할 일이 완전히 바뀐다는 것을 의미하기 때문이다. 폭포수 모델은 수정이 싫다.

현대 소프트웨어는 이전에 비해 더욱 유기적이고 사용자와 상호 작용하는 경향을 띈다. 대다수의 유니콘 스타트업들은 대중을 대상으로 서비스하며 사용자의 반응을 거의 실시간으로 체크하며 한 분기에도 몇번씩 서비스를 개선하고 배포한다. 이렇게 사용자의 피드백을 최우선 가치로 여기며 수정에 수정을 거듭하는 요즘 소프트웨어의 개발 트렌드 에서 살아남기 위해서는 수정이라는 단어를 아주 싫어하는 폭포수 모델을 끼고 있기 어려워질만 하다.

애자일 방법론 Agile Methology

애자일 방법론은 위에서 언급된 요즘 소프트웨어의 개발 트렌드 에서 살아남기 위해 생겨난 폭포수 모델의 대안이다. 더 빠르게 개발하고 배포할 수 있게끔 하겠다는 것이 그 이름의 유래인데, 모두가 애자일해야 한다고 외치지만 애자일은 하나의 형태가 아니다. 애자일은 추상적인 개념이며 애자일한 개발을 위해 실행할 수 있는 방법론은 다양하다. 그 중 대표적인 방법이 스크럼과 칸반이며, 본 포스팅에서는 익스트림 프로그래밍과 린 개발 방법론 까지 다뤄본다.

스크럼 Scrum

스크럼은 애자일 방법론의 실현을 위해 가장 많이 이용되는 방법론 중 하나다.

1
2
3
4
5
6
7
8
프로젝트 전체 작업 범위를 쪼갠다.
정해진 기간(sprint)동안 개발할 범위를 정한다.
다음의 작업을 수행한다.  
  - 개발 계획 수립  
  - 구현  
  - 리뷰  
  - 스프린트 회고
프로젝트가 마무리되지 않았다면 2번으로 돌아간다.

스프린트는 1~4주 단위로 하고, 각 스프린트 마다 실제 동작하는 결과를 만든다.

스프린트가 잘 굴러가려면 Daily Meeting을 통해 매일 각자의 작업 내용을 공유하고, 스프린트 참여 인원의 작업 상황을 동기화하여 스프린트 목표를 달성하기 위한 최선의 계획을 갱신할 필요가 있다. 이를 통해 스프린트 health를 측정하고 관리한다. 데일리 미팅은 보고가 아닌 공유를 위한 자리이다. 참석자 전원은 한 일, 할 일, 이슈를 공유해야 한다.

스크럼에서는 항상 팀이 우선이다. 스프린트 목표 달성을 위해 자신의 task보다 더 중요한 이슈가 있다면 도와준다. 한 배를 탄 이상, 배에 구멍이 나면 일단 그걸 고치는게 우선이다.

스크럼이 추구하는 가치

• 용기
  옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라!
  해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다. 또한 도전적으로 시도해보는 용기와 완료 할 수 없는 업무량이라고 모두 말 할 수 있어야 한다.
• 집중
  할 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라!
  한번에 하나의 일부터 마무리하고, 업무에 집중 할 수 있도록 불필요한 회의 참석은 지양하며, 루틴한 반복 작업은 제거 하거나 자동화해야 한다.
• 약속(헌신/책임)
  팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 팀에 헌신하며, 이를 달성 위해 필요한 모든 권한을 부여하라!
  개인보다는 팀성과 달성이 우선이고, Value 있는 SW를 개발 할 수 있게 최대한 지원과 권한이 필요하다.
• 존중
  경력과 경험이 사람을 만든다. 팀원들을 존중하라!
  개개인별로 장단점이 있고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을것이다.
• 투명성/개방성
  프로젝트에 대한 모든 내용을 투명하게 공개하라!
  제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않고 도움을 요청한다.

발췌: https://medium.com/dtevangelist/scrum-dfc6523a3604

칸반 Kanban

칸반은 일본어로 “간판”이라는 뜻이다. 칸반에는 업무 상태를 표기한 간판이 있다. 칸반은 포스트잇에 업무를 적고, 업무 진행에 따라 포스트잇이 각 간판을 이동하며 관리되는 것을 의미한다. 물론 디지털 세계에서 포스트잇은 보통 “카드”, “아이템”, “태스크”등의 이름으로 불린다.

칸반은 프로젝트의 모든 태스크를 한눈에 보고, 각 태스크의 상황을 파악하기 좋은 방법이다. 특히 HR, 마케팅 업무 등, 작업 흐름의 시각화가 큰 효과를 발휘할 때 쓰기 좋다.

익스트림 프로그래밍 Extreme Programming (XP)

XP는 수시로 발생하는 고객의 신규 요구 사항에 유연하게 대응하기 위해 사용자 참여-피드백-개발 과정의 반복을 극대화하여 개발 생산성을 향상하는 방법으로, 위에서 다뤘던 스크럼, 칸반과 같은 “도구”로서의 개념보다는 “마인드 셋”에 더 가깝다.

XP는 다음의 방법을 통해 소프트웨어를 개발한다.

• Simple Design: 모든 코딩은 간단하게 한다. 기능이 추가되고 소프트웨어가 복잡해질수록 신규 인원의 온보딩이 어려워지고 버그 수정에 걸리는 시간도 늘어난다. 이를 방지하기 위해 가능한 한 모든 기능은 간단하게 설계한다.
• Planning Game: 위에서 다뤘던 scrum의 스프린트와 유사한 개념이다. 일반적으로 2주 단위 주기로 개발 계획을 세우고 작동하는 프로토타입을 만들어 테스트 및 개발 방향에 대한 승인을 얻는다.
• Small Releases: 작은 기능 단위를 자주 배포한다. 이를 통해 의뢰인은 실제로 작동하는 데모를 볼 수 있으며 개발 방향에 대한 확인이 더 원활해진다.
• Customer Test: Small Releases를 통해 소프트웨어가 주기적으로 업데이트 되므로 반복적으로 사용자 테스트를 수행할 수 있다. 이를 통해 사용자 요구 사항 반영 주기가 짧아지고 사용자 만족도를 높일 수 있다.
• Pair Programming : 두 명이 한 조가 되어 프로그래밍하여 서로 리뷰하면서 코드의 질을 높이고 개발 책임을 공동으로 나눠 갖는다
• Test-Driven Development: 실제 기능 코드를 구현하기 전에 테스트 케이스를 먼저 작성하여 “무엇을 만들지”를 구체화 한다.
• Whole Team : 모든 프로젝트에 참여하는 팀원들은 각자의 역할을 가지고, 그 역할에 책임진다. 여기서 역할은 주로 다음과 같이 나뉜다. tester, designer, architect, PM, executives, programmer

발췌 및 편집 : Wiki

이 외에도 아래와 같은 원칙이 존재한다.

• 스펙에 없는 것은 절대 개발하지 않기
• 야근 금지. 정규 일과 시간에만 작업하기
• 기회가 생기는 즉시 코드를 개선하기

린 개발 방법론 Lean Development

낭비를 최소화하는 전략이다. 소프트웨어 가치를 최대화하는데 중요하지 않은 모든 요소를 무자비하게 제거하는 방법이다.

린 개발 방법론에서 다루는 대표적인 낭비 요소는 다음과 같다.

린 개발 방법론의 낭비 요소

• 이동/이관(Handoff) : 업무의 이관은 암묵지가 전수되지 못할 수 있음. 이관할 때마다 지식이 누락
• 미완성 작업(Partial Done Work) : 배포되지 않은 코드, 코드로 옮기지 않은 문서, 테스트하지 않은 코드
• 작업 전환(Task Switching) : 작업 진행 도중 다른 작업으로의 전환은 시간을 소모 시키므로 전환 시간 낭비 최소화
• 대기, 지연(Delay) : 필요 인원이 가용 가능할 때까지 기다림. 정기적인 피드백이 있는 Iteration은 지연을 극적으로 줄일 수 있음
• 가외기능(Extra Feature) : 고객이 필요로 하지 않는 기능을 추가하여 낭비 발생. 커뮤니케이션을 통한 feedback
• 재학습(Relearning) : 사람들을 개발 과정에 끌어들이지 못해 작업 공간에 제공할 수 있는 지식을 놓여 재학습하는 활동
• 결함/재작업(Defects/Rework) : 테스트에 결함 유입을 걸러주는 실수 방지 테스트를 포함

발췌: 린_소프트웨어_개발방법론

린 개발 방법론에서는 개발 프로세스 상에서 이러한 낭비 요소를 과감하게 제거하여 고객 입장에서의 가치를 극대화하지 않는 모든 요소를 폐기한다. 다음은 린 개발 방법론의 7가지 원칙이다.

린 개발 방법론 7원칙

• 낭비 제거(Eliminate waste) : 불필요한 코드/기능, 불분명한 요구사항(요구사항 혼란) 등 상품의 가치에 영향을 미치지 않는 모든 것을 제거
• 배움 증폭(Amplify Learning) : 개발 과정 진행 중 참여자(기획자, 개발자, 고객 등) 학습의 필요성 존재
• 늦은 결정(Defer Commitment) : 돌이키기 힘든 주요 문제에 대한 의사결정을 최대한 연기함으로써 요구사항변경에 적극적으로 대응
• 빠른 납품(Deliver Fast) : 결과물을 가능한 한 빨리 제공하는 것이 도움이 됨. 사용자의 불확실성이 감소하고, 개발자에게는 결함발견의 기회가 주어짐
• 팀에 권한 위임(Empower the Team) : 팀원들의 동기부여 및 자기 의사 결정권으로 잠재력 극대화
• 통합성 구축(Build Integrity in) : 개발 초기부터 지속적인 통합(TDD)으로 품질 향상. 소규모 개발 단계에서 오류를 수정하여 낭비를 제거
• 전체 최적화(Optimize the whole) : 사용자 요구사항수집부터 S/W 배포까지 모든 프로세스 최적화

발췌: 린_소프트웨어_개발방법론

참조

• waterfall-vs-agile-methodology
• top-5-agile-methodologies
• (강추) 애자일 Scrum(스크럼) 이해하기
• Wiki-익스트림 프로그래밍
• XP - 익스트림 프로그래밍
• 린 소프트웨어 개발방법론