05 프로젝트 방법론 -1편
애자일(Agile) 방식이란 무엇인가요
저의 브론치는 그 흔한 이미지나 예시 UI 한 개 없는 100% 1차원적인 텍스트로만 구성되어 있습니다. 기껏해야 텍스트에 볼드 또는 컬러를 주거나 사이즈 키우기 정도지요.(개인적으로 텍스트는 1차원, 이미지는 2차원, 동영상은 3차원 그리고 스마트폰 짐벌이나 드론으로 촬영 후 편집까지 한 동영상을 4차원적인 콘텐츠로 봅니다.) 여하튼 가끔 이해를 돕기 위한 예시 이미지를 첨부하고 싶으나 저도 한 조직에 속해 있는 구성원인지라 내부 자료 유출이라는 오해를 미연에 방지하는 차원에서 삼가고 있습니다. 이 점 양해 부탁드리며 반드시 필요한 경우 참고될 만한 사이트의 링크를 걸도록 하겠습니다. 그리고 언젠가 기회가 되면 저의 제2의 매거진 <IT 서비스 기획자의 여행>에 100% 저에게 저작권이 있는, 1차원부터 4차원으로 이루어진 콘텐츠를 업로드해 볼 계획입니다.
신규 서비스 론칭 시 두 가지 프로젝트 방법론 애자일(Agile)과 워터폴(Waterfall) 중 택 1 하여 이에 따른 전략을 가지고 프로젝트를 진행하는데 가끔 애자일+워터폴 방식을 접목하여 진행하기도 합니다. 이는 본인이 속한 회사나 조직의 유형 그리고 상황에 따라 결정되는데 이러한 결정은 대표(특히 스타트업인 경우)나 임원 또는 팀장 선에서 정책적으로 이루어지는 경우가 많습니다. 그만큼 누구나 쉽게 의사 결정할 수 있는 부분은 아니라는 것이지요. 서비스 기획자 초급 단계에서 결정할 수 있는 사항은 아니지만 저는 서비스 기획자로서 순차적으로 알아야 할 단계 차원에서 이번 편을 구성했습니다. 서비스 기획을 해야 하는 시점에 누군가(위에 언급한 사람들 중 누군가) 애자일 또는 워터폴 방식으로 진행해야 할지 방안을 제시해 줄 것입니다. 만약 제시해 주지 않는다면 워터폴 방식일 경우가 대부분이며, 스타트 업인 경우 물어보는 것도 방법입니다. 몇 년 전에 비교적 규모가 큰 소셜 커머스 기업 '쿠팡'에서도 애자일 방식을 사용한다고 들었습니다. 즉, 스타트 업계에서만 애자일 방식을 사용하는 것은 아니고, 시기적절하게 사용할 수 있는 전략적인 방법론이지요.
그럼 두 방법론의 선택 기준이 되는 배경적 예시를 들어 설명하겠습니다. 그리고 미리 말씀드리고 싶은 사항은 언제 어디서나 항상 예외 케이스는 존재하기에 이를 일반화하여 보셔도 되겠으나 절대적인 케이스로는 받아들이지 않으셨으면 합니다.
✔︎ 자본과 인력 리소스가 넉넉지 않아 사용자들의 반응을 봐가며 진행 여부를 결정해야 하는 경우 어떤 방법론을 선택해야 할까요
이는 위에도 언급했듯 스타트업인 경우도 있으나 대기업 내에서도 TF(Task Force)로 벤처 기업처럼 인력을 구성하여 시작하는 경우도 많이 있습니다. 완벽을 기하기보다는 심플하게 핵심 요소만 넣어 론칭 후 사용자들의 반응에 따라(비전이 있는지에 따라) 더 업데이트를 해나갈지, 아니면 반응이 전혀 없고 가능성조차 안 보이는 경우 깨끗하게 서비스를 접을지에 대한 결정을 해야 할 때 그 고민의 시간을 줄여줍니다. 이게 바로 에자일(Agile) 방식입니다. 그리고 다행히도 반응이 폭발적인 경우 벤처 캐피털을 통해 수많은 투자를 받게 되고 이는 곧 대박으로 이어지기도 하지요. 수많은 스타트 업계에서 성공한 사례들이 이러한 경우입니다.
기존에 존재하지 않았던 서비스, 참신한 서비스, 재미있는 서비스, 큰 자본이나 리소스가 없이 론칭이 가능한 서비스, 무엇보다 특정 사용자들(메인 타깃)에게 정말 유용하게 여겨지는 서비스는 전체적인 UI/UX적인 완성도는 좀 미흡해도 본인에게 꼭 필요하고, 대체할 만한 서비스조차 없는 경우엔 무조건 사용하게 됩니다. 그리고 이렇게 대박 난 서비스로 몰려든 사용자들(소위 액티브 유저들)은 불편을 감수하면서 조용히 사용하지 않습니다. '난 이런 부분이 불편하다, 난 이렇게 했을 때 App.이 다운된다, 난 이 부분이 이렇게 개선되면 좋겠다, 난 이런 기능이 생겼으면 좋겠다'라는 수많은 보이스(Voice)를 쏟아내고 이는 앞으로 어떻게 업데이트를 하면 좋을 지에 대한 방안을 제시해 주기 때문에 서비스는 당분간 지속 성장이 가능합니다.
애자일(Agile) 방식은 자본과 리소스에 대한 리스크를 줄여주는 만큼 주로 소규모 프로젝트에 적용되는데 그만큼 선택과 집중이 더욱 중요합니다. 긴 시간 동안 많은 기능을 넣은 서비스가 아니기 때문에 즉, 사용자가 혹 하고 쓸 만한 핵심 중에서도 핵심적인 기능을 잘 선택해야 하고, 기획, 디자인, 개발이 순차적으로 진행되는 것이 아니라 동시다발적으로 병행되기도 하기 때문에 프로젝트에 대한 집중력과 협업하는 사람들끼리의 신뢰와 존중이 밑바탕되어져야 합니다. 보통 한 프로젝트(서비스 또는 기능)를 완수하기까지의 일정 기간을 산정하고(보름 또는 한 달 등) 이 텀을 기준으로 마지막엔 실제 사용해 볼 수 있는 결과물을 내놓습니다. 그리고 작업자들 간 눈높이와 이해도를 항상 동일하게 맞추기 위해 매일 10분 ~ 15분간의 미팅을 진행하는데 이를 데일리 스크럼 미팅(Daily Scrum Meeting)이라 부르며 기획자 관점, 디자이너 관점, 개발자 관점에서 바라보기보다는 하나의 프로젝트, 하나의 팀 입장에서 진행 상황(진척률)을 공유합니다. (스크럼 미팅은 애자일 방식에서 많이 취하는 방법론이긴 하나 이는 팀 단위 또는 파트별로도 매일 실시간 프로젝트 진행 사항 체크를 위해 진행하기도 합니다) 주기가 매우 타이트한 만큼 그리고 동시에 진행되는 방식인 만큼 각자 역할에 대한 일정을 촘촘히 계획적으로 세워야 하며 그래서 PM(Product Manager 또는 Product Master)은 책임감이 막중하기 때문에 PM의 주도하에 잘 움직여져야 하고, 어느 한 곳에서 삐걱임이 있을 경우 워터폴 방식이라면 이슈가 아니었을 일도 애자일 방식이어서 발생할 수 있기 때문에 협업이 매우 중요합니다. 그리고 애자일 방식은 결과물 구현이 중요하기에 개발자가(또는 개발 스펙이 있는 기획자)가 PM역을 하는 경우도 많습니다.
✔︎ 애자일 방식으로 진행했을 때 단점도 있을까요
애자일은 순환이 빠른 만큼 단순 이벤트 페이지나 게임 랜딩 페이지 작업으로는 리스크도 적고, 괜찮으나 새로운 서비스를 만드는 프로젝트인 경우 완벽한 프로세스를 밟을 수가 없기 때문에 대체적으로 엉성하고, 무엇보다 버그(Bug: 오류)가 많을 수밖에 없습니다. 서비스의 매력도마저 없으면 사용자들의 만족도는 떨어질 수밖에 없고, 홍보 마케팅으로 이 서비스를 접하게 될 기회는 마련할 수 있어도 첫인상으로 인해 두 번 다시 발걸음을 하지 않을 확률이(재방문자가 없는 확률이) 높을 수밖에 없습니다. 즉, 완성도가 중요한 프로젝트에서는 적용해서는 안 되는 방식이지요.
그리고 계속 애자일 방식으로 진행되기 때문에(워터폴 방식에서 사용하는 프로세스와는 많이 다르기 때문에) 기획자가 깊게 고민하여 상세하게 기획서를 작성할 수 있는 시간이 부족한 만큼 기획자의 역량보다는 아이템(아이디어)이 지속적인 서비스 향상에 기여할 수 있는가가 가장 핵심입니다.
2편에서 언급한 운영성 업무 가운데서도 어드민을 활용한 단순 업데이트성 작업이 있지만 위에서 언급했듯 이벤트 페이지나 간단한 메뉴 추가 등도 애자일 방식입니다. 그래서 운영 업무 가운데서도 단순 업데이트가 아닌 이러한 업무를 진행하게 되는 경우 한 단계 진일보했다고 봐도 되겠습니다. 추가된 페이지에 대한 통계(트래픽) 작업도 오픈 전후 비교를 위해 빠트리면 안 된다는 사실은 이미 잘 알고 계실테지요.
다음편으로 워터폴 방식이 기다리고 있습니다.
