맛있는 페이지 준비중...맛있는 페이지 준비중...
프로젝트를 시작할 때 프로젝트 관리 방법을 크게 폭포수(Waterfall) 모델과 애자일(Agile) 모델 둘 중 하나로 선택하고 시작하시나요?
저는 여태 각 방법을 사용하는데 있어서 현재 상황/개발한 기능/구성원 수준 등을 고려해서 적절한 방법을 선택해오지 않은 것 같아요. 그냥 애자일 모델을 많이 사용하니 애자일 방식으로 업무하고자만 했고, 사실상 폭포수 모델로 일을 해왔어요... 그래서 폭포수와 애자일에 대한 저의 생각을 정리하고자 이 글을 써봅니다.
프로젝트를 진행할 때 가장 먼저 결정해야 하는 것 중 하나가 방법론입니다. 신입 시절에는 "당연히 애자일이 피드백도 빠르고, 유연하니 더 좋은 거 아닌가?"라고 생각했지만, 더 좋고 나쁨은 없다는 것을 알았어요. 상황에 맞게 각 모델을 적절히 사용할 수 있어야해요. 이 글에서는 두 방법론의 진행 방법과 차이점들을 소개하려고 해요.
폭포수 모델은 이름 그대로 위에서 아래로 흐르는 물처럼 단계가 순차적으로 진행되요.
각 단계가 완전히 끝나야 다음 단계로 넘어가고, 이전 단계로 돌아가는 것이 원칙적으로 어렵거나 비용이 많이 들어요.
그리고 산출되는 문서도 되게 많아요. 그만큼 탄탄하게 설계되어 제품이 나오게 되요.
일정과 비용 예측이 명확해요.
문서가 풍부해서 인수인계가 비교적 수월해요.
요구사항이 고정된 프로젝트에서는 효율적이에요.
변경에 취약해요. 설계 단계 이후 요구사항이 바뀌면 일정과 비용이 어떻게 바뀔지 몰라요.
사용자가 결과물을 보는 시점이 늦어요.
초반 단계에서 모든 요구사항을 완벽하게 정의해야 한다는 부담이 크고 현실적으로 완벽함은 힘들어요.
애자일은 방법론이라기보다는 철학과 원칙의 집합이에요. 짧은 주기(보통 1-4주, '스프린트')로 동작하는 결과물을 만들고, 피드백을 받아 개선하는 방식이 보통이에요.
대표적인 프레임워크는 스크럼(Scrum) 과 칸반(Kanban) 이 있어요.
애자일 모델에는 기획자 대신에 PM과 PO라는 역할이 있고, PM, 개발자, 디자이너가 함께 기획에 참여해요. 또한 빠르게 결과물을 내고 피드백을 받기 때문에 문서 산출물이 간소해요. 정해진대로 하지도 않기 때문에 실력있는 사람들이 많아야하고요.
변화에 강해요. 우선순위에 따라 매 스프린트 작업을 조절할 수 있어요.
사용자 피드백을 빠르게 반영할 수 있어요.
팀의 자율성과 책임감이 높아져요.
"애자일 한다고 했는데 그냥 야근하는 것 같아요" 라는 말이 나오기 쉬워요. 잘못 도입하면 무계획적인 개발이 되요. (점점 애자일이라 불리는 폭포수 모델로 개발하고 있는 것처럼 될 확률이 커요. 조직 문화가 뒷받침 되어야 해요. 물론 애자일과 폭포수 모델을 하이브리드 형식으로 가져가는게 나쁘다는건 아니에요.)
전체 일정과 비용을 미리 약속하기 어려워요.
시니어가 부족한 팀에서는 잘 굴러가지 않고, 자기 주도성이 전제되요. (사실 실력이 없으면 자기 주도성을 갖기도 힘들어요... ㅜㅜ)
문서가 빈약해지기 쉽고 인수인계 시점에 고통이 와요.
방법론이 바뀌면 단순히 프로세스만 바뀌는 것이 아니라 역할, 개발자의 책임, 협업 방식까지 함께 바껴요.
처음 제품 개발에는 워터폴로, 이후 운영단계에서는 고객 피드백에 따른 애자일 방식으로
하나의 프로젝트에서 안정성이 중요한 고정된 기능들은 워터폴 방식으로, 고객에게 WOW 포인트를 주고싶은 기능은 애자일 방식으로
결제 / 인증 / 정산 -> 폭포수
추천 / UI 개선 / 실험 기능 -> 애자일
방법론 자체를 기획 단계는 폭포수로, 기능/UX 설계 및 구현 단계는 애자일로
우선 회사에서 폭포수 => 애자일로 바꾸려 시도한다면 대부분 실패할거에요. 왜냐하면 저의 생각에는 폭포수/애자일 방법론은 조직 문화를 그대로 반영하기 때문이에요. 애자일 vs 폭포수 차이점만 봐도 조직 구성부터 다르다는 것 알 수 있어요.
만약 위계가 강하고 의사결정이 느린 조직에서 스크럼만 얹으면 그냥 애자일 코스프레하는 기업일 뿐이에요. 이런 기업에서는 스크럼이 책임 추궁 자리가 될거에요.
방법론을 바꾸기 전에 권한 위임과 의사결정 구조(조직 문화)를 먼저 바꾸세요!!!!!!!!!!!!!!!!!!!!!!!!
산출물 문서와 프로세스를 확인해보면 좋을 것 같아요. 대표적인 문서로는 화면 기능 명세서가 있을 것 있어요. 워터폴 방식에서는 정확하게 문서화 하기 때문에 화면 기능 명세서를 만들고, 이 문서를 주로 참고하여 개발자가 개발을 해요. 하지만 애자일 방식이라면 유저 스토리(User Story) 단위로 기능을 작성할 거에요. 그래서 이 문서를 기반으로 유저 스토리별로 에픽과 태스크가 나오고 일정 산정까지 이뤄질거에요.
저는 요즘 느끼는 것은 성공적으로 좋은 제품을 만들려면 프로젝트 특성과 조직의 본질에 맞게 방법론을 채택해야 한다는 것이에요. 그냥 "어떤 개발 방법론을 채택하겠다! 앞으로 이렇게 진행할거다!"라고 주장하고 실행하면 억지로 프로세스에 끼워맞추는 것 밖에 안되요.
그리고 가장 중요한 것은 "왜 이 방법론을 선택했는가"에 대한 팀이나 회사의 합의인 것 같아요. 아무리 좋다고 설명해봤자, 본인만 좋다면 쓸모 없어요. 예를들면 CEO는 전혀 원하지 않는데, PM만 좋다고 설파해봤자, CEO가 이렇게하라 하면 이렇게 해야할 확률이 엄청 높을거에요...ㅠㅠ 그래서 프로젝트를 관리하는 사람은 프로세스 하나를 선택하는데도 본인의 생각, 의도, 이유가 담겨있고 그 의도를 달성할 수 있다고 판단되었을때 상황에 최선인 프로세스를 결정해야한다고 생각해요.
방법론 결정에 생각, 의도, 이유가 빠지면 그냥 형식만 남아 족쇄가 될거에요.
저가 지금 속한 조직도 상황에 맞게 계속 변화할 수 있는 성숙한 조직이 되면 좋겠어요.
