SW 제품 개발의 양대 산맥, 애자일과 워터폴
처음 입문하는 PM/PO/기획자를 위한 잡학상식 ①
(해당 아티클은 PC 환경에 최적화되어있습니다.)
'Waterfall, Agile, Kanban, Scrum, Sprint, Backlog...'
스타트업이나 PM에 관심이 있었다면, 이런 단어들을 많이 들어보셨을 겁니다. 이 생소한 용어들은 도대체 무엇을 의미하는 걸까요?
소프트웨어 개발에서 아주 중요한 역할을 차지하는 용어일 것 같지만, 처음 듣는다면 도대체 무엇을 의미하는지 전혀 가늠이 되지 않으실 겁니다.
이 용어들과 그 개념을 파악하기 위해, 우리는 먼저 소프트웨어 제품 개발의 양대 산맥인 애자일과 워터폴 방법론에 대해서 이해해야 합니다.
1. 계획 기반의 제품 개발, 워터폴 방법론(Waterfall Method)
워터폴 방법론은 폭포수 방법론이라고도 불리며,
기획 - 디자인 -개발의 순서대로 차근차근 진행되는 순차적 개발 프로세스입니다.
워터폴 방법론에서는 일반적으로 다음의 다섯 단계를 거쳐 제품이 출시됩니다.
(조직에 따라 프로젝트 최종 결과물 전달 방식에 편차는 있지만, 대부분의 경우는 해당 프로세스를 따릅니다.)
1. 요구사항 수집과 분석
프로젝트 관리자가 클라이언트와 이해관계자의 요구사항을 수집하고, 해당 사항을 프로젝트의 구성 요소인 [일정],[범위],[비용] 등을 통해 작업 요소로 세분화합니다.
요구사항을 통해 WBS와 간트 차트 등을 작성해 거시적인 세부 일정을 수립하고, 실제로 프로젝트 매니저가 이해한 요구사항이 이해관계자들의 요청과 명확하게 일치하는지 세심하게 확인합니다.
프로젝트의 목표(Goal)가 결정되는 구간이기 때문에, 요구사항이 중간에 수정된다면 [일정],[범위],[비용],[품질]등 다양한 요소에 영향을 미칠 수 있습니다.
2. 설계
UX Designer, 서비스 기획자,GUI Desginer 등의 서비스 설계자들이 실제로 서비스에 사용되는 시나리오나 UI등의 설계를 진행합니다. 프로젝트 매니저나 소프트웨어 아키텍트가 ERD 등을 미리 작성하는 경우도 있습니다.
여기서는 구현 단계에서 개발자들이 구현할 기능의 상세와 각각의 기능의 범위(Scope)에 대한 사항이 확정됩니다.
3. 구현
소프트웨어 아키텍트와 개발자들이 설계를 바탕으로 실제로 개발을 진행하는 파트입니다.
요구 사항과 설계 자료를 기반으로 프로그램을 실제로 코딩하고, 간단한 테스트도 진행합니다.
만약 설계 자료가 잘못되었거나, 프로그램 설계에 논리적 오류가 있는 경우는 해당 파트만 설계 단계로 다시 되돌리는 경우도 있습니다.
(이런 경우, 프로젝트 관리자는 납기 일정을 재조정해야 하는 경우도 벌어집니다.)
4. 확인 및 테스트
[범위],[품질] 등이 기존의 요구사항에서 수립한 목표(Goal)과 부합하는지 확인과 테스트를 진행합니다.
대부분의 경우 전문 QA나 서비스 기획자(QA가 없는 경우)가 작성한 테스트 시나리오를 바탕으로 단위 테스트, 통합 테스트 등을 진행하여 제품의 품질을 검증합니다.
5. 프로젝트 최종 결과물 전달(인도) / 유지 보수
클라이언트, 이해관계자에게 제품의 최종 결과물이 전달되는 시점입니다.
계약 내용에 따라 다르지만, 납기 후 일정 기간의 의무 유지 보수/하자 보수 기간이 추가되는 경우가 있습니다.
만약, 계약 내용에 명시된 유지 보수/하자 보수 외 다른 추가 사항과 요구 사항이 발생할 경우, 프로젝트 관리자는 요구 사항 분석 후 [1. 추가 프로젝트 계약] [2. 일정 및 비용,품질 조정] 등으로 대응할 수 있습니다.
워터폴은 기획과 디자인과 개발에 대한 계획을 초기에 전부 세워놓고, 철저하게 그 계획에 따라 팀원들이 협업해서 제품을 만들어내는 구조입니다. 따라서, 초기에 결정된 계획이 중간에 변경되기가 매우 어렵습니다.
예를 들어서, 디자이너가 디자인을 전부 진행하고 개발자에게 넘겨 개발이 거의 완성되고 있는 상황인데,
디자인에 갑자기 수정 사항이 생겼다면, 디자이너도 일을 해야 하고, 개발자도 이미 완성된 제품을 수정해야 하는 상황이 벌어지겠죠.
그래서 워터폴 방법론은 다음과 같은 특징들을 가집니다.
워터폴 방법론의 특징
- 중간에 요구사항이 변경되는 일이 거의 없는 프로젝트, 초기에 완벽한 기획과 디자인이 만들어져 있는 프로젝트의 경우에 적합합니다.
(금융권 프로젝트 등, 서비스 정책 변경이 사용자에게 치명적인 영향을 주는 경우도 동일합니다.)
- 상세한 사전 설계를 바탕으로 서비스를 개발하기 때문에, 계획을 설계하는 프로젝트 관리자의 역량이 서비스의 품질에 매우 큰 영향을 미칩니다.
- 기획과 디자인이 전부 확정된 이후에 개발을 진행하는 만큼, 고객과의 상호작용을 통해 프로젝트를 수정하는 것은 매우 어렵습니다.
- 프로젝트를 시작하기 전 요구사항과 프로젝트의 [범위, 비용, 일정]에 대해 명확하게 정하기 때문에, 전체적인 과정의 이해가 비교적 쉽습니다.
워터폴 방법론은 각 단계별로 프로세스가 명확하게 나누어져있고, 따라서 동시 다발적인 업무 처리가 매우 어렵습니다. 이는 일정이나 업무를 트래킹하기에는 용이한 점이지만, 프로젝트 전체에는 비효율적일 수 있죠.
따라서, 이런 비효율성을 해결하기 위해 사시미 방법론(각 프로세스 간의 중첩, 병렬 진행을 허용하는 방식), V-프로세스 방법론(폭포수 모델에서 테스팅 활동을 추가한, 루프 형태의 개발 프로세스) 등이 제시되었지만, 결과적으로는 진화적 개발 모델(Evolutionary Development Model)인 애자일 모델(Agile Model)이 가장 널리 알려지게 되었습니다.
2. 고객의 피드백을 빠르게 반영하는, 애자일 모델(Agile Model)
스타트업이나 PM(Product Management) 직무에 관심이 있는 사람이라면, '애자일'이라는 용어를 한 번 씩은 들어보셨으리라 생각됩니다.
애자일(Agile)은 기민함, 민첩함을 뜻하는 영단어인데, 소프트웨어 업계에서는 '제품을 시장에 출시하기 위해, 보다 유연하고 효율적인 방법으로 프로젝트를 관리하도록 만들어진 방식'을 뜻하는 용어로 사용됩니다.
애자일은 워터폴 방법론이 '미리 정의된 요구사항'에 따라 개발됨에 따라 생기는 문제점을 해결해, 고객의 피드백을 반영한 효율적인 제품 개발을 위해 고안되었습니다.
애자일은 사실상 방법론이라기보다, 효율적인 제품 개발을 위한 철학이나 사상에 가깝습니다. 지켜야 할 원칙과 가치만을 제시하고, 실행하기 위한 특별한 '방법'을 제시하지는 않기 때문이죠.
(따라서, 애자일을 실현하기 위해서는 스크럼이나 칸반, 린 스타트업과 같은 프로세스 기법을 사용해야 합니다.)
애자일에는 다양한 기법들이 존재하지만, 공통적으로 다음의 [4가지 핵심 가치]와 애자일 원칙(Agile Manifesto)이라고 불리는 [12가지 원칙]을 따릅니다.
애자일 프로세스의 4가지 핵심 가치
1. 프로세스 및 도구에 대한 개인 및 상호 작용
애자일에서 가장 중요한 것은, 구성원과의 유기적인 협업입니다. 형식보다는 효율을 추구하기 때문에 구성원과 직접적이고 빠르게 소통해야 합니다. 워터폴 방법론과 다르게 전체적인 계획에 따라 프로젝트가 흘러가지 않기 때문에, 협업을 위해서는 구성원 각자가 본인의 R&R(역할과 책임)이 무엇인지 명확하게 인지해야 합니다.
2. 포괄적인 문서보다 작업 소프트웨어
SW 제품 개발에서, 기획 문서나 와이어프레임과 같은 서비스 디자인 산출물은 '최종 산출물'이 아닙니다. 애자일은 형식적인 문서보다는 빠른 제품 개발에 필요한 문서들만 작성하길 지향**합니다. (다만, 문서가 필요하지 않다는 뜻은 절대 아닙니다.)
3. 계약 협상을 통한 고객 협업
제품이 만들어지더라도, 고객이 필요로 하지 않는다면 그 제품은 아무런 소용이 없습니다. [애자일은 고객의 피드백을 최대한 빠르게 제품에 적용]하려고 노력합니다.
4. 계획에 따른 변경에 대한 대응
앞서 말씀드린 세 가지는 전부 '빠른 대응'이 갖춰지지 않으면 실현할 수 없습니다. 각자의 명확한 R&R과 유기적인 협업을 통해 '계획 변경에 대한 빠른 대응'을 실현하고자 모든 구성원들이 노력합니다.
애자일 프로세스의 12가지 원칙
1. 우리의 최우선 과제는 귀중한 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.
2. 개발이 늦어도 변화하는 요구 사항을 환영합니다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
3. 작업 소프트웨어를 몇 주에서 몇 달까지 자주 제공하고 더 짧은 기간을 선호합니다.
4. 비즈니스맨(Product Manager, Product Owner 등..)과 개발자는 프로젝트 전반에 걸쳐 매일 함께 작업해야 합니다.
5. 동기 부여된 개인을 중심으로 프로젝트를 구축해야 합니다. 개인에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 수 있도록 신뢰하십시오.
6. 개발 팀과 개발 팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
7. 작동하는 소프트웨어는 진행 상황의 주요 척도입니다.
8. 애자일 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 계속해서 일정한 속도를 유지할 수 있어야 합니다.
9. 기술적 우수성과 우수한 디자인에 대한 지속적인 관심을 통해 조직의 민첩성을 향상합니다.
10. 수행하지 않은 작업의 양을 최대화하는 기술인 단순성은 필수적입니다.
11. 최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화된 팀(Self-Organized team)에서 나옵니다.
12. 팀은 정기적으로 더 효과적인 방법을 논의한 다음 그에 따라 행동을 조정하고 조정합니다.
출처 : https://agilemanifesto.org/principles.html
애자일 프로젝트 관리의 특징
- 시작 단계에서 요구사항이 명확하지 않은 프로젝트, 고객의 요구사항이 성과에 큰 영향을 미치고, 요구사항이 지속적으로 변화하는 프로젝트의 경우에 적합합니다.
- 기술이나 시장 트렌드가 빠르게 변화하는 환경에서 일하는 조직에게 적합합니다.
- 프로젝트 기간 동안 고객 및 외부 이해관계자와 원활히 협력해야 하는 경우 적합합니다.
- 프로젝트의 논리적인 정밀함보다는, 빠른 피드백과 실험, 빠른 배포가 더 필요한 경우 적합합니다.
3. 그렇다면 애자일과 워터폴, 둘 중 어느 것이 정답일까요?
결론만 말하자면, 정답은 '조직의 구성과 상황에 따라 다르다'입니다.
애초에 '방법론'이란 것은 '학계에서 인정한 진리'와 같이 어느 곳에서나 적용되는 편리한 것이 아니라, 조직에 따라 응용하여 적용하는 '도구'이기 때문입니다.
(그래서 이 질문은, '칼이 좋냐, 가위가 좋냐?'와 같이 정답이 없는 질문입니다.)
최근 국내에서도 '스타트업'과 수평적 문화, 빠른 개발과 실험 등에 대한 접근이 계속해서 일어나고 있는 만큼, 애자일이 '워터폴보다 발전된 방법론'이고, 모든 것의 정답이자 만병통치약인 것처럼 이야기하는 경우가 있습니다. (적어도 소프트웨어 제품 개발에서는요!)
애자일이 고객의 요구사항과 수요를 적극적으로 반영하고자 하는 만큼, 트렌드의 변화가 빠른 현재 상황에서, 제대로 사용한다면 대부분의 기업에서 효과적인 것은 확실합니다.
다만, 애자일은 프로세스와 R&R에 대한 명확한 이해, 수평적 조직 문화와 구성원 개개인의 역량이 받쳐주지 않는다면, 초기에 계획이 명확하지 않은 만큼 엉망이 될 가능성이 높습니다.
따라서 애자일을 제대로 실현하고자 한다면, '경영진과 조직 문화 담당자의 적극적인 후원'이 필요합니다.
이처럼 만약 애자일에 필요한 요구사항이 갖춰지지 않은 기업이라면, 오히려 훌륭한 프로젝트 매니저와 서비스 기획자(UX Designer)가 초기에 완벽한 계획을 짜는 워터폴 프로세스가 더 용이할 수도 있습니다.
앞서 말한 대로, 애자일과 워터폴은 조직에 따라 응용하거나 다르게 적용할 수 있는 프로세스이고, 둘 중 무언가가 정답이 아닌 본인의 조직에 맞춰서 유동적으로 적용해야 하는 프로세스입니다.
결국 여러분들이 PM/PO/서비스 기획자와 같은 SW 제품 기획 직군에 종사하여 조직을 원활하게 운영하고 시장에 진짜 혁신을 불러일으키는 제품을 만들고자 한다면,
이 두 프로세스에 대한 명확한 이해를 통해 조직에 맞는 프로세스를 적용시키거나, 혹은 이미 만들어진 프로세스가 '왜 만들어졌을까?, 더 효율적이게 응용할 방법은 없을까?"와 같은 고민을 지속적으로 해야 합니다.
