워터폴, 애자일... 그래서 뭐가 좋은건데?
Codestates PMB 10 | 워터폴 vs 애자일
미국에서는 구글, 애플, 마이크로소프트, 넷플릭스, 스포티파이 등 한국에서는 토스, 당근마켓, 배달의 민족 등이 애자일을 경영 방식으로 활용한다고 한다.
여자들이 립스틱 색을 고를 때 하는 말이 있다. "하늘 아래 같은 레드는 없어"
조직도 같은 맥락이라고 생각한다. "하늘 아래 같은 조직은 없어"
각 기업마다 구성원이 다르기 때문에 일을 하는 방식, 문화도 조금씩 다 다르다. 완전히 똑같을 수는 없겠지만 그래도 요즘 시대에서는 업무 방식이 크게 두 가지로 나뉜다고들 이야기한다. 그게 바로 "워터폴" 그리고 "애자일" 방법이다. 애자일 방식을 활용하는 기업을 애자일 조직이라고 표현하기도 한다. 그렇다면 워터폴 방식, 애자일 방식이란 무엇일까?
워터폴 vs 애자일
부제: 좋고 나쁜건 없어, 각 조직의 특성에 맞게 정하면 되는거야.
워터폴(Waterfall, 폭포수)
gif 출처: https://hygger.io/guides/agile/agile-vs-waterfall/워터폴 방식은 IT업계 말고도 전 산업군에 걸쳐 많이 사용되던 방법이다. 워터폴의 특징은 고객에게 테스트를 해보는 단계 없이 팀 내 혹은 기업 내 이해 관계자들끼리 결정해서 제품을 개발한 후 시장에 내놓는다는 것이다. 이 말에서 느꼈겠지만, 유저의 반응을 보면서 제품을 만들어내는 것이 아니라 유저의 문제에 대한 솔루션을 팀에서 혹은 기업에서 이미 다 정해놓고 열심히 개발해서 고객에게 짜잔하고 보여주는 것이다. 그렇기에 기획하고 개발하는 단계에서 고객의 마음에 드는 제품을 만들어내기 위해 무척이나 공을 들일 것이다.
워터폴은 단계별로 접근하는 방식을 사용한다. 각 단계에는 stage-gate 즉 문이 있어서, 한 단계를 다 완료해야만 그 다음 단계의 문을 열 수 있다. 다음 단계로 넘어가기 위해서는 이전 단계가 완료가 되어야 한다는 것이다. 워터폴의 단계별 업무 프로세스는 다음과 같다.
https://Step 1. 요구분석
프로젝트에 사용될 기능, 시스템, 기술적 사양 정보를 유저와 주요 이해관계자로부터 수집한다.
Step 2. 설계
사용자경험 전문가는 고객, 제품팀 및 기타 주요 이해관계자와 함께 제품의 각종 요소들을 결정한다.
Step 3. 개발 및 테스트
설계된 결과를 구현해내기 위해 개발을 진행한다. 이후 성능, 시스템 및 사용자 승인 테스팅을 수행하여 제품이 요구사항을 충족하는지 확인하고 결함이나 버그가 발견되면 제품이 전달되기 전에 해결한다.
Step 4. 출시
프로젝트를 착수할 때 확정했던 사양이 충족되면 유저에게 전달한다.
Step 5. 유지보수
유저는 제품을 전달받은 후 추가적인 변경을 요청할 수 있다. 프로젝트 비용과 시간은 추가될 수 있다.
워터폴 장단점
(참고: 현업 기획자 도그냥이 알려주는 서비스 기획 스쿨)
장점
1. 단계가 명확히 구분되어 있으므로 진행사항을 명확히 확인할 수 있다.
2. 단계가 명확히 구분되어 있으므로 책임 소재가 명확하다.
3. 프로젝트 인력에 푸시를 잘하는 조직의 경우 오픈 일정을 맞추기 적합하다. (즉 구성원은 죽어난다는 말)
4. 산출물 문서가 명확하여 관리가 용이하다.
5. 외주 인력과 작업하기 용이하다.
단점
1. 앞 단계에서 잘못된 기획이나 설계가 되었을 때 되돌리기 어렵다.
(굉장히 오랜 시간이 걸리므로 엎고 새로 시작하는게 나을지도 모른다.)
2. 앞 단계 문서에 명시되지 않은 부분은 누락되기 쉽고 기획 변경 시 영향 범위가 넓다.
(문서 작성이 그만큼 중요하며 빼먹는 내용 없이 신중히 작성해야 한다.)
3. 테스트 기간 전까지 산출물의 형태를 미리 보거나 테스트하기 어렵다.
워터폴은 탑다운 방식으로 불리는 만큼, 주로 수직적인 문화의 기업들에서 사용하는 방법이다.
애자일(Agile, 날렵/민첩/기민한)
기존의 전통적 조직에서는 전략을 짜고 디테일한 플랜들을 짜는데 오랜 시간을 할애해야 했고 이미 설계한 후 개발 단계로 넘어갔을 때는 수정하기란 거의 불가능했다. 요즘 Risk Management라고 하는 위험 관리 역시 해내기 힘들다. 오직 미래가 정확히 예측되는 상황에서만 최대 효율과 긍정적인 성과를 낼 수 있다.
애자일 방법론은 기존의 전통 조직들의 문제점을 극복하기 위해 생겨났다고 볼 수 있다. 지금은 시장이 빠르게 변하기 때문에 미래를 예측하기 힘들다. 차근차근 공들여서 세상에 내놓으면 이미 소비자들은 또 다른 제품, 다른 니즈를 가지고 있을 확률이 높다. 특히 COVID-19 pandemic가 터지고 장기화되면서 시장에서 기업이 살아남기 위해 적응력(adaptability), 속도(speed), 고효율(efficiency)의 중요성이 대두된 상황이다.(맥킨지 아티클 참고)
애자일은 이름처럼 날렵하고 민첩하게 움직일 수 있는 조직이다. 애자일 조직은 아주 작은 핵심 요소만으로 제품, 샘플을 만들어서 소비자 반응을 확인하고 수정, 변경을 통해 점점 살을 붙여나가는 방식을 사용한다. 지금과 같은 팬데믹 상황에서 애자일 조직은 빛을 발한다. 일하는 방식을 이미지로 표현하면 아래와 같다.
이미지 출처: https://brunch.co.kr/@linecard/425애자일 관련 용어 - 스크럼, 유저 스토리, 백로그
애자일에서는 위의 그림처럼 요구분석 -> 설계 -> 개발 -> 테스트 -> 출시를 계속 반복하게 된다. 제품의 목적을 달성하기 위해 팀원들이 스크럼(럭비에서 유래한 용어, 목적지에 도달하기 위해 하나로 뭉쳐 움직이는 형태)처럼 하나로 뭉쳐 목적을 달성하는데 이 팀을 스크럼 팀이라고 부른다.
각 팀에게는 해결해야 하는 고객의 문제가 있을 것이다. 이 고객의 문제를 팀의 입장이 아닌 고객의 입장에서 서술한 내용을 유저 스토리, 이해관계자로부터 제안된 유저스토리의 목록을 백로그라고 지칭한다.
PM/PO에게 필요한 역량
앞의 내용에 따르면 애자일 조직은 최소한의 기능을 조금씩 자주 만들어 고객에게 전달한다. 한번 배포할 때는 해결해야 할 유저스토리의 개수를 적당하게 정할 필요가 있다. 이를 팀의 capacity라고 부른다.
PM/PO는 팀 멤버들과 논의를 통해 수 많은 유저스토리 중 고객 가치와 사업 가치를 따져 4-6개로 추려내야 한다. 이 때 시간(Schedule), 범위(Features/Functionality), 리소스(Cost/Budget) 세 가지 측면을 종합적으로 고려해야 한다.
애자일 장단점
(참고: 현업 기획자 도그냥이 알려주는 서비스 기획 스쿨)
장점
1. 문서화 시간을 단축하고 개발된 결과를 빠르게 확인할 수 있다.
2. 중간 단계에서도 수정이 가능하다.
3. 개발자와 디자이너의 자유도가 높으므로 창의적인 결과를 낼 수 있다.
4. 프로세스의 처음부터 끝까지 팀원들과 협의가 가능하며 이를 통해 최고의 결과물을 얻을 수 있다.
(=개발자와 디자이너와의 끈끈한 협업이 가능하다.)
단점
1. 복잡한 프로젝트의 팀 멤버 수준이 제각각이면, 전체 진척률과 수준 관리가 어렵다.
(=복잡한 프로젝트라면 어느정도 실력있는 팀 멤버로만 구성되어야 잘 굴러간다.)
2. 팀 멤버가 애자일 방식에 공감하지 못한 상태에서 합류하면 상호 간 *R&R 문제로 번질 수 있다.
3. 팀과 밀접하게 움직여야 하므로 애자일 방식을 설득할 수 있는 전문가 역할과 팀워크 관리가 필요하다.
*R&R문제란?
Role&Role의 약자로 상호 업무자 간의 업무 역할을 설정한 범위를 말한다. R&R을 침범한다는 표현은 상대 업무자의 업무 범위에 참견, 개입함을 의미한다.
아래의 이미지는 워터폴과 애자일 조직을 잘 비교해서 나타냈다. 좌우는 같은 내용인데 좌측 이미지는 맥킨지 기사에서 인용된 부분이고 우측 이미지는 동아 비즈니스 리뷰에서 한글판으로 적은 내용이다.
PM/PO에게 애자일이란..?
PM/PO는 워터폴이든 애자일이든 프로젝트가 시작되기 전 출시할 (혹은 개선할) 서비스에 대한 고민을 해야 한다. 방법론은 기획을 쉽게 만들어주지 않는다. PM/PO는 결국 기획을 해야 한다. 1) 고객 가치, 비즈니즈 가치를 고려해 2) 구현 가능한 기술과 3) 최대치의 고객경험을 가능하게 하는 디자인에 대한 구상을 담은 기획을 해야 한다. 그리고 그 기획을 실현 가능하게 만드는 팀원들에게 설명하고 또 설명해야 한다. 물론 이 때 소통은 각 방법론에 맞는 방식으로 해야 한다. 워터폴이든 애자일이든 결국 PM/PO는 "기획과 소통"을 잘 해야 한다.
[참고자료]
https://brunch.co.kr/@linecard/425
