안녕하세요, 나인투원에서 Product Owner를 맡고 있는 서다영입니다.
오늘부터 몇 차례에 걸쳐 나인투원이 일레클 프로덕트를 만드는 과정을 소개하려고 합니다.
이렇게 블로그를 통해 저희가 일을 하는 방식에 대해 공유하려는 이유는 크게 두 가지입니다. 첫 번째는 저희보다 더 초기 단계인 스타트업에서 각 조직에 맞는 프로세스를 만드는 과정에 저희의 경험이 도움이 되었으면 좋겠다는 바람 때문입니다. 저희도 많은 블로그에서 도움을 받았으니 받은 도움에 대한 보답이랄까요,
두 번째는 앞으로 나인투원에 합류하실 분들이 합류하시기 전에 나인투원에 대해 더 잘 아실 수 있도록 공유하기 위함입니다. 아무래도 규모가 작은 스타트업이다보니 취업 플랫폼을 통해 나인투원에서 일하는 사람들/일했던 사람들의 이야기를 들을 수 있는 확률이 적은데, 그럼에도 불구하고 새로운 회사에 이직/취업하는 것은 모두의 인생에서 아주 중요한 결정이기 때문에 합류 결정을 하시는 데에 조금이라도 도움이 되고자 글을 쓰게 되었습니다.
오늘은 우선 나인투원에서 스크럼 개발 방법론을 채택하게 된 배경과 스프린트 계획 회의를 진행하는 방식에 대해 설명을 하겠습니다.
저는 현재 소프트웨어팀 5명, 프로덕트팀 3명과 함께 일하고 있습니다. 하드웨어 개발도 회사 내에서 직접 하고 있다보니, 비슷한 규모의 다른 스타트업에 비해 소프트웨어 개발팀의 규모가 작은 편입니다.
나인투원은 애자일 소프트웨어 개발 방법론인 스크럼을 조직 상황에 맞게 변형하여 활용하고 있습니다. 초창기부터 스크럼을 활용했던 것은 아니고, 처음 1년은 프로젝트 기반으로 개발을 했었는데 그 과정에서 조직 내에서 발견된 몇 가지 문제를 해결하기 위해 여러 대안들을 생각하다보니 스크럼 방법론을 적용하게 되었습니다.
프로젝트 기반 프로세스의 장단점
스크럼 기반으로 움직이기 전에는 크고 작은 프로젝트가 시작될 때마다 킥오프 미팅을 열고, 프로덕트팀과 개발팀이 함께 모여 해당 프로젝트에 대해 논의한 후 해당 프로젝트가 얼마나 걸릴지 정하고 QA 일정과 배포 일정을 잡는 방식으로 프로덕트를 개발했습니다.
이 프로세스의 장점은 한 가지 프로젝트를 시작할 때 킥오프 미팅에서 프로덕트팀과 개발팀이 상당히 깊게 논의를 할 수 있고, 개발팀도 기획에 참여하기에 더 수월하다는 점입니다. 한 번의 회의에서 하나의 프로젝트에 대해서만 깊게 이야기할 수 있으니까요.
반면, 가장 큰 문제는 한 사람이 동시에 많게는 3–4개의 프로젝트를 진행하게 되어 PO뿐만 아니라 모든 팀원이 각자 리소스 관리가 안 되고 컨텍스트 스위칭을 많이 겪게 된다는 점이었습니다. 현재 각자가 얼마나 많은 태스크를 진행하고 있는지 공유가 잘 안 된 상태에서 새로운 프로젝트가 시작되기 때문에 1주일이면 끝낼 수 있는 가벼운 프로젝트도 이미 진행되고 있는 프로젝트들과 겹쳐 4주씩 걸리는 일도 발생했습니다.
스프린트 주기
이런 문제를 해결하기 위해 제품을 개발하는 단위를 프로젝트 단위가 아닌 시간 주기로 설정해야겠다는 생각을 하게 되었고, 스크럼 방법론을 채택하게 되었습니다. 스크럼은 보통 1~4주로 구성된 스프린트를 반복적으로 실시하며 한 스프린트마다 부분적으로 완성된 결과물이 만들어지게 됩니다. 나인투원은 현재 기본적으로 2주 단위로 스프린트를 실시하며 상황에 따라 1주 혹은 3주로 유연하게 변형하여 진행하고 있습니다.
스프린트 주기는 처음에는 1주마다 진행하는 것도 시도해 보았지만 스프린트 계획 회의와 개발 회의에 드는 시간이 길어져서 실질적으로 일을 할 수 있는 시간이 너무 적다는 피드백이 있어 2주로 늘리게 되었습니다. 보통의 경우 2주가 제일 적합하지만 빠르게 배포가 되어야 하는 작은 프로젝트가 있다면 1주로 줄이기도 합니다.
스프린트 계획 회의 (Iteration Planning Meeting)
스프린트는 모든 팀원이 참여하는 스프린트 계획 회의(나인투원에서는 IPM이라고 부릅니다)로 시작합니다. PO가 우선순위에 따라 스프린트 백로그에 넣어둔 스토리들을 같이 읽으며 각 스토리에 대해 이해하고, 어떤 스토리를 이번 스프린트 내에 할 수 있을지 어떤 스토리는 이번 스프린트에 할 수 없을지 논의합니다. 각 스프린트는 보통 큰 프로젝트의 일부와 작은 스토리들로 이루어져 있는데, 큰 프로젝트의 개요와 방향에 대해 모두가 잘 이해할 수 있도록 시간을 많이 할애하는 편입니다. 이 과정에서 더 좋은 제품을 만들기 위해 추가적으로 있으면 좋을 것 같은 스토리와 각 스토리를 어떻게 더 좋게 바꿀 수 있을지에 대해서도 자유롭게 논의합니다. 이후에는 각 스토리를 완수하기 위해 어떤 사람들이 무엇을 해야 하는지 명확히 합니다.
다만, 50%의 확률로 스토리만 가지고는 개발을 어떻게 진행할지, 그래서 얼마나 시간이 걸릴지 그 순간 결정하기 어려운 경우들이 있습니다. 대부분 새로운 기술 스택을 적용해야 하거나 각 기술 파트가 복잡하게 엮여 있어 기술적으로 개발 회의가 별도로 필요한 경우들입니다. 이런 경우 2차 스프린트 계획 회의라고 할 수 있는 개발 회의를 별도로 진행합니다. 개발팀만 따로 모여서 스프린트에서 나온 스토리들을 어떻게 개발을 할 수 있을지 이야기를 하면서 개발 문서를 작성하고 각 파트를 담당한 팀원이 언제까지 태스크들을 끝낼지 논의합니다.
스프린트 계획 회의가 끝나면 협업 툴이자 프로젝트 관리 툴인 Asana에 해당 스프린트를 위한 칸반을 새로 만들고, 태스크들을 생성합니다. (Asana에 대해서도 다음에 기회가 되면 설명해 드릴게요) 이후 각 스토리에 대해서 업무를 진행하면서 당사자들끼리 세부적인 논의를 하고, 진행 상황에 대해 공유합니다. Asana에서는 각 태스크에 대해서 코멘트를 쓸 수 있고 스토리의 담당자들이 각 코멘트를 follow할 수 있으면서 인박스 기능이 잘 되어 있어서 특정 스토리/태스크에 대해서는 Asana에서 논의하는 편입니다.
스프린트 내에 디자인 태스크를 포함할지
초반에 스프린트를 진행하면서 고민했던 점 중 하나는 스프린트 내에 개발 태스크 외에 디자인 프로토타입을 하는 태스크도 포함할 것인지에 대한 부분이었습니다. 제가 다른 스타트업의 사례들을 찾아보았을 때 그로스 실험을 많이 하는 팀들은 보통 디자인 프로토타입도 스프린트 내에 포함을 시키는 것 같았고, 저희도 더 많은 시도를 더 빠르게 해보자는 욕심으로 처음에는 스프린트 내에 디자인 프로토타입 태스크도 포함을 시켰었습니다. 결론적으로 말씀드리자면 80% 이상의 스프린트에서는 디자인 프로토타입을 사전에 진행합니다. 즉, 각 스토리를 위한 디자인 프로토타입과 개발을 하나의 스프린트에 넣지 않고 두 개 이상의 스프린트에 쪼개서 넣고 있습니다.
이런 결정을 하게 된 가장 큰 이유는 프로덕트 디자이너에게 더 오래 마음 놓고 편하게 고민할 시간을 주기 위함입니다. 많은 분들이 공감하시겠지만, 처음부터 최고의 결과물을 내기는 정말 어렵습니다. 초안을 만들고 다음 날 다시 보면 아쉬운 점이 보여 수정하게 되고, 다른 팀원들에게 프로토타입을 보여주면서 더 좋은 아이디어가 생각이 나는데 하나의 스프린트 내에 프로토타입과 개발 태스크를 함께 진행할 경우 일정에 쫓겨 더 좋은 디자인을 포기하게 되는 경우들이 발생했습니다. 일레클 서비스는 많은 시도를 빠르게 해보는 것도 중요하지만, 사람들에게 빠르고 편리한 이동 경험을 주는 것이 조금 더 중요하겠다는 판단하에 사용성에 대해 더 고민하고 최고의 프로토타입을 만들기 위한 충분한 시간(혹은 심리적 여유)을 확보하기로 했습니다.
다만, 상대적으로 빠른 실행이 중요하고 프로덕트팀에서 상대적으로 깊게 고민하지 않아도 되는 간단한 스토리인 경우에는 하나의 스프린트 내에서 프로토타입과 개발을 동시에 진행하기도 합니다.
쓰다보니 글이 길어졌네요. 저희가 스크럼 방법론을 정석대로 사용하고 있는 것은 아니지만, 각 결정들을 하게 된 근거들에 대해 공유드리고 싶었습니다. 저희는 지금도 계속 시행착오를 겪어가며 일하는 프로세스를 개선해나가고 있습니다. 프로세스에 대한 개선은 대부분 회고 미팅을 통해 이루어지는데 다음 글에서는 회고 미팅을 어떻게 진행하는지에 대해 설명드릴게요.
