워크로그 #3 유저스토리 기반의 개발방법론
새로운 시도와 회고를 통해 성장하는 팀
카카오스타일은 오픈 세미나 '워크로그‘를 통해 우리가 일하는 방식과 문화를 공유합니다. 워크로그는 카카오스타일과 크루들이 이제까지 고민하고 해결하며, 성장해온 그 과정을 나누고자 시작하게 된 프로젝트입니다.
유저의 니즈를 충족시키고 더욱 유용한 서비스를 만들기 위해서는 끊임없는 노력과 시도가 필요합니다. 그래서 카카오스타일의 프로덕트를 만드는 사람들은 다양한 시도와 회고를 반복하며 더 나은 방법을 찾고 더 좋은 결과를 만들어내려 노력하고 있습니다.
워크로그 #3에서는 지그재그의 커머스 기능을 개발하고 구현하는 조직의 유저스토리 기반의 개발방법론 활용 사례와 함께 서비스를 개선시키기 위한 그들의 고민과 시도에 대해 공유합니다.
워크로그 #3 발표자 셀러앤코어부문 주문팀 PO 폴리(Polly)
카카오스타일 프로덕트팀은 어떻게 일할까
카카오스타일에는 목적조직*과 기능조직*이 각 팀의 목표와 형태에 맞게 공존하고 있으며, 각자 더욱 효율적인 방식으로 일하면서 서로 소통하며 협업하고 있습니다. 셀러앤코어부문*은 주로 목적조직으로 구성되어 있으며, 각각의 목적조직(팀)은 테크리더, PO, PM, 프로덕트디자이너, 프론트엔드 및 백엔드 개발자 등으로 이루어져 있습니다.
*목적조직 : 하나의 공동 목적(ex. 프로덕트, TF 등)을 위해 관련 직무를 하는 인재들이 한 팀에 소속된 조직
*기능조직 : 같은 직무(기능)를 하는 인재들이 한 팀에 소속되어 있는 조직(ex. 개발팀, PO팀, 디자인팀 등)
*셀러앤코어부문 : 카카오스타일의 파트너(셀러)에게 다양하고 효율적인 커머스 서비스들을 제공하고, 상품데이터의 품질과 셀렉션을 강화하여 유저에게 더 나은 이커머스 경험을 제공하는 조직)
이렇게 구성된 프로덕트팀은 팀별로 일하는 방법을 자유롭게 만들어 나갈 수 있습니다. 전사플래닝을 통해 싱크된 전사 단위의 전략과 방향성, 미션 안에서 팀별로 비전과 로드맵을 결정합니다. 또한 팀별로 스트린트* 방식이나 스크럼* 방식과 같은 일하는 방식도 결정할 수 있기 때문에 각 팀이 자유롭게 일하는 방식을 만들 수 있습니다. 이처럼 팀의 자유도가 보장된 문화 덕분에 새로운 방법론의 적용을 팀에서 결정하고 시도할 수 있습니다.
*스프린트 방식 : 팀이 일정량의 작업을 완료하는 시간이 정해진 짧은 기간
*스크럼 방식 : 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중의 하나
주문팀이 일하는 방법
카카오스타일은 전사플래닝 기간을 통해 각 팀에서 추진하는 주요 과제와 전사 단위 방향성에 대해 싱크를 맞춥니다. 그리고 팀에 주어지는 일과 우리 팀에서 하고 싶은 일을 적절하게 조율해서 팀 플래닝을 할 수 있습니다. 셀러앤코어부문 내 주문팀은 하나의 프로덕트 팀으로 애자일 기반의 스크럼 조직을 기본으로 하고 있으며 팀원 모두가 긴밀하게 소통하고 수정하며 일하고 있습니다.
애자일 기반의 스크럼 조직 기본 구조 예시 이미지스크럼은 애자일 기반 프로덕트 팀의 가장 기본적인 방법입니다, 가장 먼저 팀 내 프로덕트 오너가 백로그라고 하는 업무 리스트를 쌓습니다. 그중에서 스프린트에 포함시킬 백로그를 팀에서 선정하면 이것이 스프린트에서 해야 될 업무 리스트가 됩니다. 선정된 백로그 리스트를 2주 단위로 스프린트를 진행하고 끝나면 회고하는 방식으로 일을 하고 있습니다. 스프린트 기간에는 돌아가면서 스크럼 마스터를 담당하고 데일리 스크럼을 통해서 해야 되는 일이나 하고 있는 일들을 서로 체크합니다.
프로덕트오너(PO)는 평상시에 PRD라는 문서 양식에 맞춰서 백로그를 작성합니다. PRD는 일종의 화면 설계서에 해당하는 문서로, 목적이나 이유, 가설을 중심으로 작성하고 있으며 이때 유저스토리 라는 방식을 사용하여 정리하게 됩니다.
유저스토리란?
유저스토리는 백로그도, 유즈케이스(usecase)도, 페르소나도 아닙니다. 백로그가 해야 될 업무 목록, 유즈케이스는 어떤 기능에 대한 사용자 이용 케이스, 페르소나는 유저의 특징과 가치를 대표성 있게 정리한 모습이라고 설명할 수 있습니다. 유저스토리는 프로젝트 진행을 위해서 PRD에서 정의한 목적에 맞게 서비스 기능에 대한 요구사항을 사용자의 상세한 동선으로 구분하여 정리한 문장 리스트입니다.
유저 스토리는 기본적으로 “사용자는 00를 위해서 00를 할 수 있다”의 구조로 되어 있습니다. 이 구조를 통해 사용자가 누구인지, 사용자의 목적은 무엇이며 무엇을 하려고 하는지 정의할 수 있게 됩니다. 실리콘밸리 PM 마이크 콘에 따르면 유저스토리는 몇 가지 조건을 갖고 있습니다. 유저스토리는 독립적이고 협상 가능해야 하며, 사용자와 비즈니스에 가치가 있어야 합니다. 또한 예측 가능해야 하며, 2주 내 개발 가능할 정도로 사이즈가 작고 테스트가 가능해야 합니다.
유저스토리, 무엇이 다른가요
유저스토리는 워터폴 프로젝트* 요구사항 정의서나 화면 설계서의 디스크립션(description)과 비슷하다고 할 수 있습니다. 그런데 워터폴 프로젝트에는 단점이 하나 있습니다. 워터폴 프로젝트의 문서는 개발 로직의 구현까지도 ‘확언적'이고 ‘확정적'이어서 메이커들의 자유도를 해칠 수 있고 기획적인 완성도가 낮을 경우 구현 과정에서 더 큰 문제가 될 수 있다는 점입니다.
*워터폴 프로젝트 : 단계 구분이 뚜렷하게 나누어진 순차적 프로젝트 관리 방법론
화면 설계서의 디스크립션 예시반면, 유저스토리는 최종적으로 사용자가 무언가를 달성하기 위해서 사용자가 어떤 태스크를 수행해야 한다는 것을 보여줌으로써 개발자와 디자이너들의 프로젝트에 대한 전문성을 발휘할 수 있는 자유도를 보장해줄 수 있고 더 많은 아이디어를 낼 수 있는 기본 틀을 만들어줍니다. 그래서 유저스토리는 모두의 참여와 협업을 중시하는 애자일 조직에서 많이 사용합니다.
처음 유저스토리를 쓰며 발견한 문제점
유저스토리의 기본 개념만 알고 유저스토리를 쓰기 시작했을 때, 몇 가지 문제점을 발견했습니다. 우선 주문팀 프로젝트 같은 경우에는 업무의 연결 범위가 굉장히 많고, 안정성이 특히 더 중요한 팀이었기 때문에 오픈 후 실험으로 이어지기 어려운 프로젝트들이 다소 있었습니다.
또한 스펙의 구체적인 정의 부분을 지나치게 구체화해서 쓰면 요구사항 정의서와 비슷해져서 유저스토리의 장점이 희석되기도 했습니다. 어떤 프로젝트의 경우 지라(jira)를 통해 에픽(epic)을 생성했는데 이 범위가 너무 커서 여러 번의 스프린트 진행 후에도 프로젝트가 종료되지 않고 남아있어서 결과가 측정되지 않는 어려움도 있었습니다.
회고와 관찰을 통해 찾은 개선 포인트
1. 지라 에픽(epic)을 쪼개자!
카카오스타일에서는 업무 태스크 관리를 위해 지라(jira)라는 툴을 사용합니다. 지라에서는 태스크 별로 티켓을 만들고 티켓마다 담당자를 지정하고 협업하며 업무 진행 과정을 확인할 수 있는데요. 유저스토리 방식을 사용하면서 지라 티켓을 만들고 해당 티켓들의 층위를 관리하는 데에 어려움이 있었습니다. 중복 티켓이 생기거나 다양한 티켓들이 에픽 하위에 질서 없이 들어가게 되기도 했습니다. 또 스토리 단위가 너무 커서 스토리마다 또 많은 티켓들이 생겨나면서 PRD에 작성된 우리가 만들어야 하는 기능과 지라 작업 티켓이 연결이 안 되기 시작했습니다.
그래서 에픽을 더 작게 쪼개야 한다는 결론을 내리게 되었습니다. 셀러앤코어부문 주문팀은 2주 단위로 스프린트를 진행하기 때문에 에픽도 해당 주기에 맞게 혹은 이 두 개 스프린트 정도에 맞게 줄여서 분리 배포가 가능하도록 티켓 자체의 사이즈를 줄여서 개선 포인트를 도출할 수 있었습니다.
2. 유저스토리를 리뷰하고 설계하는 충분한 시간을 갖자!
또한 팀 내 회고를 통해서 에픽 이름이나 PRD를 통해서 해야 하는 일을 명확하게 이해하기 어렵다는 피드백이 나왔습니다. 특히 스프린트 설계 시점에서 PRD의 완성도가 낮아서 설계 시 필요한 정책이 부족하거나, 스프린트 설계까지 담당자가 미지정되어 PO가 나중에 구체적인 처리자를 인지하기가 어렵다는 의견도 있었습니다. 그래서 프로젝트가 클수록 유저 스토리를 리뷰하고 설계하는 충분한 시간이 필요하다는 개선점을 파악할 수 있었습니다.
3. 완료 조건을 활용하자!
유저스토리가 “사용자가 00을 하기 위해 00을 할 수 있다”라는 다소 단순한 구조로 되어있다 보니 예외 처리나 텍스트 제한, 케이스에 따른 분리 조건과 같이 더 상세한 디스크립션을 남겨둘 곳이 없다는 어려움이 있었습니다. 이런 고민을 하던 중 다른 팀과 업무 미팅을 통해 이런 구체적인 스펙을 소화할 수 있다는 완료 조건(AC, 엑셀터스 크리 테리어)의 용도에 대해서 새롭게 알게 되었고 이를 바로 적용해보기로 했습니다.
완료 조건 활용 예시유저스토리 에픽이라고 하는 큰 프로젝트를 더 작은 에픽 단위로 나누고 그 하위에 사용자에 대한 태스크별로 유저스토리를 쪼개기로 했습니다. 그리고 각각의 유저스토리에 해당하는 구체적인 예외 케이스나 디스크립션은 이 완료 조건에 최대한 같이 쓰기로 했습니다. 이를 통해 사용자 별 개발 소요 시간도 어느 정도 예상이 가능하다는 것을 알게 됐습니다.
이후에 카카오스타일 개발 조직에서 주기적으로 개최하는 Dev monthly meeting에서 공유된 내용 덕분에 완료 조건에 대한 또 하나의 팁을 얻게 되었는데요. ‘완료 조건 기반 개발 방법론’이라는 개념으로, 유저스토리와 완료 조건을 바탕으로 개발자의 태스크와 테스트 코드까지 일치시켜서 개발을 좀 더 효율적으로 하게 돕는 방법론이었습니다. 이를 통해 애자일 방법론에서 개발자와 디자이너가 모두 프로젝트를 잘 이해하고 사용자에게 의미 있는 프로젝트를 만들어내려면 유저스토리와 완료 조건을 바탕으로 개발 태스크를 설계할 수 있어야 한다는 교훈을 얻을 수 있었습니다.
완료 조건을 활용한 개발 방법론 구조글로벌 서비스 베타 버전 오픈 프로젝트
이렇게 팀 내부의 회고와 다른 팀 업무 방식을 통해 배운 팁을 적절히 활용하면서 꾸준히 유저 스토리 활용에 대한 개선을 해나가게 되었습니다. 그리고 최근 주문 팀에서는 글로벌 서비스 베타 버전 오픈 프로젝트를 유저스토리 방법론을 활용해서 진행하게 되었습니다. 이 프로젝트는 지그재그 글로벌 서비스 베타버전 오픈과 함께 다양한 국가에서 해외배송 및 클레임까지 할 수 있게 하는 중요한 프로젝트였습니다. 그래서 이 프로젝트를 어떻게 효율적으로 수행할 수 있을지 팀 내 논의를 거쳐 유저스토리를 활용해보자고 결정하게 되었습니다.
1. 상세하게 쪼갠 에픽으로 유저스토리 리뷰
우선 큰 방향성은 에픽을 최대한 쪼개서 관리하기로 했습니다. 어떻게 나누면 좋을지 레퍼런스를 많이 찾아보았고, 스터디도 했습니다. 그렇게 해서 찾은 에픽을 쪼개는 가장 좋은 방법은 케이크 레이어처럼 다양한 기능의 한 조각에 모두 포함되어야 한다는 것이었습니다. DB, 서버, 백엔드, 프론트엔드를 고객 행동을 기준으로 버티컬하게 쪼갤 수 있어야 하는 것이죠.
에픽을 나눈 구조 예시또 하나는 다른 팀과 연결되어 있는 디펜던시(의존성) 팀과는 어떻게 할지 고민이었는데요. 이런 경우에는 주문팀에서 스토리를 생성하고 디펜던시 팀의 티켓을 연결해서 체크하는 방식을 썼습니다. 다른 팀이 작업하는 부분이라고 생략하게 되면 전체적인 부분을 이해하기 힘들다고 생각했기 때문입니다.
2. 각 항목별 설계를 위한 워크샵 진행
이렇게 정한 기준을 바탕으로 필요한 에픽과 유저스토리 레벨을 시트로 정리를 했고, 구체적인 설명이 필요한 부분은 완료 조건으로 정의했습니다. 그리고 가장 중요한 것은 해당 요구 사항과 유저스토리에 대해서 모두가 이해를 하는 것이 중요했기 때문에 하루 동안의 워크샵을 통해서 싱크를 맞추고 개발 태스크 티켓을 위한 구조의 기반을 만들었습니다.
3. 티켓의 생성 및 구조화
논의된 내용을 바탕으로 본격적으로 지라 티켓을 생성하고 구조화했습니다. 글로벌 서비스 베타 버전 오픈 프로젝트라는 큰 상위 이니셔티브 아래에 에픽, 스토리를 연결하고 태스크 개발 티켓을 생성했습니다. 유저스토리 자체는 PO가 작성했지만 작업에 대한 티켓은 개발자, 디자이너가 직접 스토리를 분석하면서 좀 더 구체화시키기도 했습니다.
생성된 지라 티켓 예시스프린트를 설계하면서 형성된 에픽을 활용해서 목표 설정에 반영했습니다. 그리고 스프린트가 종료되면 스토리를 기반으로 팀 테스트를 진행하고, 스토리 티켓을 IN QA 상태로 변경했습니다. 에픽의 종료는 프로덕션에 배포된 이후에 완전히 종료했고, 사용자 화면에 관계없는 경우에는 백엔드부터 선배포를 진행하여 향후 프론트엔드에 대한 리스크만 테스트 시점에 확인할 수 있도록 했습니다. 특히 티켓이 명시적으로 나와있어 티켓 해결에 대한 대시보드 확인이 용이했고, 프로젝트 진행 중 성과 관리에도 굉장히 유용하게 활용할 수 있었습니다.
티켓 생성 및 해결 대시보드 예시4. 유저스토리 기반의 리뷰 워크샵 진행
클로즈드 베타 테스트(CBT) 전에 유저스토리 처리 현황을 보면서 리뷰 워크샵을 진행했습니다. 유저 스토리를 하나씩 읽으면서 실제 우리가 의도한 대로 사용할 수 있게 작동하고 있는지, 목표와 동일한지를 체크했습니다. 그리고 잔존 티켓, 누락 티켓 여부를 확인하고 타 팀과의 디펜던시 개발도 완료가 되었는지 다시 한번 체크할 수 있었습니다. 무엇보다도 리뷰 워크샵을 통해서 스토리 기반 티켓 처리 현황을 살펴보고 우리가 수행한 개발 결과에 대해서 직관적으로 볼 수 있어서 회고와는 또 다른 의미 있는 성취감을 느낄 수 있었습니다.
새로운 방법론, 어떤 점이 좋았나요
우선, 좋았던 점 중에 하나는 팀 내에서 프로젝트에 대한 이해도와 사용자 흐름에 대해서 더 공유가 잘된다는 점이었습니다. 전체 맥락에서 사용자 스토리를 파악할 수 있기 때문에 내가 하고 있는 부분이 어떤 부분이고, 어떤 흐름으로 가는지에 대해 직관적으로 알 수 있다는 것이 좋았습니다.
그리고 큰 에픽이나 티켓의 영향으로 막연하게 보였던 프로젝트 진행 현황을 명확하게 인지할 수 있다는 점도 만족스러웠습니다. 그리고 메이커 분들도 사전에 워크샵을 통해서 스토리나 세부사항을 파악할 수 있어서 나중에 누락되어 문제가 생기는 부분이 별로 없이 마무리할 수 있었습니다.
앞으로 어떻게 하면 좋을까
유저스토리 기반 개발 방법론은 디자이너와 프론트엔드 개발에서 상세 정책이 잘 전달되기 어려웠습니다. 기존의 화면 설계서와 같은 기획에 대한 부분이 디자이너에게 많이 이관되다 보니 서로 아쉬운 점이 있었고, 프론트엔드 개발 시에도 상세 정책이 기록에 잘 남아 있지 않아 어려워했습니다. 이런 점을 반영하여 팀 회고에서 다음번에는 UI PRD를 추가하자는 의견이 나왔습니다. 큰 프로젝트의 경우에 UI PRD를 별도로 작성하여 프론트엔드 개발에서도 세부사항을 체크할 수 있도록 장치를 마련하는 것이죠.
또 하나 아쉬운 점은 정책에 대한 변경이 생겼을 때 유저스토리와 완료 조건 업데이트 과정이 번거롭다는 점이었습니다. PRD(노션), 처음 논의한 유저스토리(엑셀시트), 결정된 티켓(지라) 세 개를 모두 업데이트해야 하다 보니 싱크가 안 맞는 경우가 종종 발생했습니다.
그리고 또 하나는 QA팀에서 유저스토리 단위에 대한 이해가 어려웠다는 의견을 주기도 했습니다. QA팀이 별도 팀으로 분리되어 있다 보니 유저스토리 단위나 내용에 대해서 싱크가 부족했던 것이죠. 추후에는 QA팀에도 별도 공유 시간을 갖거나 앞서 언급한 UI PRD를 통해서 정책 산출물을 만드는 과정의 필요성을 느낄 수 있었습니다.
카카오스타일의 프로덕트팀은 각 팀 별로 가장 효율적이고 긍정적인 임팩트를 만들며 일할 수 있는 방법을 꾸준히 찾고 시도하며 성장하고 있습니다. 그리고 그 고민의 중심에는 유저에게 더 편하고 좋은 서비스를 제공하고자 마음이 빠질 수 없겠죠.
세 번째 워크로그에서 나눈 유저스토리 기반의 개발 방법론의 이야기가 다양한 시도를 통해서 더 나은 프로덕트를 만들고자 하는 많은 분들께 도움이 되었으면 좋겠습니다. 카카오스타일의 더 많은 이야기가 궁금하다면, 아래 링크를 참고해주세요!
>>> 카카오스타일 채용 페이지 바로가기
