고객과 팀원을 위한 애자일 스크럼 개발 프로세스

숨고의 테크/프로덕트 팀이 일하는 방식을 이야기하며 이제는 IT분야에 관련이 없더라도 알고 있는 사람이 많을 정도로 유명한 애자일(Agile)에 대해 소개하고자 합니다. 애자일 개발 프로세스에 대한 이론적 설명은 구글에서 조금만 검색을 해도 쉽게 알 수 있을 정도로 널리 알려져 있고, 정보량도 풍부합니다. 하지만 실제 기업, 특히 스타트업에서 적용해본 경험 사례를 스스로 밝힌 정보는 그만큼 많지는 않습니다. 

어떤 정답이나 결론을 내리기보다는 숨고만의 '우리는 애자일을 도입해서 이렇게 하고 있어요'라는 경험담을 이야기하고 싶습니다. 빠르게 성장하는 스타트업으로써 성장에 맞춘, 그리고 이용자를 위한 애자일에 대해 많은 고민을 한 만큼 우리의 이야기를 해보고자 합니다.

먼저, 애자일(Agile)이란?

애자일, 스프린트, 린스타트업, 그로스 등 각종 용어가 난무하는 세상입니다. IT 업계 종사자라도 간혹 헷갈리고, 정확한 뜻을 모르는 경우가 많죠. 여기서 우리가 말하는 애자일 개발 프로세스란 특정 개발 방법론을 일컫는 것이 아닌 재빠르고 효율적인 개발을 가능하게 도와주는 전부를 말합니다. 개발자가 생각한 대로 정하고 시작하는 것이 아닌, 유저 입장에서 스토리를 만들고 이를 재빠르고 효율적으로 구현하는 개발 프로세스입니다.

숨고는 어떻게 애자일을 하고 있을까요?

칸반 보드(Kanban Board) + 스크럼(Scrum)

숨고에서는 처음부터 애자일을 했어요. 애자일 방법론 중 크게 칸반과 스크럼이라는 2가지 방법을 도입했습니다. (물론 이밖에 무수한 방법론이 있습니다) 처음에는 칸반 방법론만 채택해서 개발했어요. 하지만 수많은 변수가 존재하는 플랫폼 스타트업인 숨고에게는 스크럼 방식이 더욱 적합할 듯 하여 스크럼 방법을 도입했습니다. 대신 기존의 칸반 보드는 그대로 가져가되 스크럼 주기를 만들었습니다.

칸반과 스크럼의 큰 차이는 개발 업무의 스프린트 주기입니다. 칸반의 경우, 해야 할 일들을 모두 칸반 보드에 올려놓고 특정 마감기한 없이 우선순위에 맞춰 넘어가는 방식입니다. 일이 언제 정확히 끝날지 정확하게 가늠하기 어려워 제대로 시행하기 어렵습니다. 반면에, 스크럼 방식은 좀 더 측정 가능한 계획을 구성할 수 있다는 생각에 도입했습니다.

포기하기 힘들었던 워터폴(Waterfall Model)

사실 최근까지 워터폴 방식을 결합한 방식으로 진행하고 있었습니다. 스크럼으로 일의 기간은 정했는데, 실행 방식은 사실 워터폴이었죠. PO가 기획하고 디자이너가 디자인을 입히면, 그 뒤 개발이 들어가는 프로세스를 2주 주기로 했습니다.

하지만 워터폴 방법이 가진 고유의 문제점을 꾸준히 느꼈습니다. PO(Product Owner)의 책임이 크고, 초기 기획에서 조금이라도 정확하지 못하면 다음 단계에서 빠트린게 보여 개발 단계 진행이 자꾸 늦어지는 문제가 있었습니다.

특히, 스타트업의 경우 항상 사람이 부족합니다. PO 한 명이 다양한 기능을 담당하기 때문에 모든 디테일과 구성을 챙기고 빠뜨리는 것 없이 기획하리란 쉽지 않습니다. 생각하지 못했던 에러가 발생하거나, 이슈가 자주 발생해 기한이 늦춰졌습니다. 이래서는 안되겠다는 의견이 나왔고, 전격적으로 애자일을 도입해서 개선했습니다.

스크럼 방식의 애자일은 PO가 실제 이용자 입장을 고려하고, 다른 팀의 의견을 반영해 개발의 우선순위를 세웁니다. 그리고 기획자 혼자 만드는게 아니라 모든 팀원들이 모여 첫단계부터 함께 시작하죠. 겉으로 봤을 때는 일의 속도가 느려보이나, 오히려 더욱 정확하고 효율적인 방식이라는 점을 체감하고 있습니다.

숨고 Tech/Product팀의 애자일 구성

숨고의 애자일 스프린트는 일주일(1 week) 간격으로 진행되고 있습니다. 크게 기획(Planning), 측정(Estimation), 실행 및 매일 확인(Daily Stand-up/Check-in Meeting), 회고(Timeline Retrospective) 총 4가지로 이루어져 있습니다.

1. 계획(Planning)

팀이 해야할 일은 스토리로 정합니다. 스토리는 이용자(고객)입장에서 이해되는 바로 정리합니다. 예를 들어, '숨고 채팅 이미지 첨부 기능 추가'로 개발 업무를 정하는 것이 아닌, '서비스 요청자는 더 정확한 견적을 받기 위해서 채팅으로 사진 보내기를 원한다.'라는 스토리로 작성합니다. 기본적으로 모든 개발 스토리는 '00는 X 하기 위해서 Y 한다'의 형식으로 쓰고 있습니다.

우선순위를 정하는 건 PO(Product Owner)입니다. 서비스 개선 및 발전, 그리고 특정 시즌을 반영해서 우선순위를 정하고 있어요. RICE* 관점에 맞춰서 우선순위를 정하고 있습니다. 명확한 공식은 아직 없으나 꾸준히 이에 맞춰 올바른 일의 순서를 정하고자 고민하고 있습니다. 또한, Sales팀과 CS팀에서 알려주는 이용자의 요구를 빠르게 반영하고자 노력하고 있습니다. 버그가 아니더라도 이용 경험을 해친다고 확인되는 경우 최대한 빠르게 처리하고 있습니다.

* RICE(Reach, Impact, Confident, Easy) - 얼마나 많은 사람에게 영향을 끼치고, 임팩트가 크며, 신뢰도가 높고, 개발이 쉬운지에 따라 우선순위 기준

2. 측정(Estimation)

실행도 중요하지만, 그전에 이 일의 규모가 얼만큼인지 정확하게 파악하는 것이 더욱 중요합니다. 그래서 숨고에서는 상대적으로 크기를 결정하고 있어요. 절대적으로 결정하지 않습니다. 기존에는 이 일이 담당자가 처리하기까지 걸리는 시간으로 업무량(point)을 측정했습니다. 혼자 하는 업무라면 각자 알아서 스스로 예측했죠. 하루면 1point, 이틀이면 2, 사흘이면 3, 이런 식으로요.

하지만 팀으로 움직여야 하는 애자일에서는 이런 측정 방법이 도움 되지 않습니다. 팀이 움직이지 않고 각기 개인으로만 움직이기 때문에 일의 크기가 서로 다르고, 공유하기 어려워요. 애자일을 적극적으로 도입하면서부터 일의 크기를 상대적으로 파악하고 있어요. 

숨고의 개발 포인트 측정 방식이 궁금하면 '카드놀이 하듯 개발 리소스 예측하기'에서 확인할 수 있습니다. 

3. 실행 및 확인(Daily Stand-up + Check-in Meeting)

데일리 스탠드업의 경우, 보통 어제 했던 일, 오늘 할 일, 혹은 장애물에 대해 이야기합니다. 그리고 체크인 미팅을 통해 서로 컨디션을 공유하죠. 만약 간단히 의논해야 할 사항이 있으면 그 자리에서 이야기를 나눠요. 이때 중요한 점은 문제가 생겼을 때 그 문제를 혼자 고민하지 않고 팀이 같이 고민할 수 있도록 유도하는 구조를 갖추는 것이 중요합니다. 숨고 테크팀은 문제 발생 시 적극적으로 의견을 공유하도록 장려하고 있습니다.

자세한 내용은 '매일 아침 호텔에 오듯 Check-in을 하는 개발팀'에서 확인할 수 있습니다.

4. 회고 (Retrospective)

한 주의 스프린트를 마치면 모두 모여 회고하는 시간을 가집니다. 숨고에서는 수요일을 회고(Retro)하는 날로 정했습니다. 나흘 동안 진행했던 스토리를 정리하고 있어요. 회고에만 몇 시간을 쓸 정도로 중요하게 생각하고 있습니다. 자세하고 깊게 회고할수록 지난 스프린트의 부족한 점을 반성할 수 있고, 다음 스프린트에 긍정적인 흐름을 줄 수 있기 때문입니다.

회고에 대한 자세한 내용 '차가움과 따뜻함이 공존하는 회고 미팅'은 에서 확인할 수 있습니다.

숨고 Tech/Product Team의 지향점은 '팀원의 성장'

숨고의 미션과 맞닿아 있는 개발 우선순위

개발의 우선순위는 숨고의 미션과 맞닿아 있습니다. 숨고의 미션은 '전문가는 좋은 고객을 효율적으로 유치하고, 고객은 좋은 전문가를 쉽게 만날 수 있도록 돕는다.'입니다.

서비스 시장은 정보 비대칭 시장입니다. 고객 입장에서는 가격을 알아보려면 시간을 많이 써야 하고, 고수의 서비스 퀄리티도 믿을 수 없습니다. 전문가도 고객을 효율적으로 만날 기회가 적었습니다. IT 기술을 통해 이런 불균형을 해소하고 더욱 많은 사람들이 문제를 해결할 수 있도록 노력하고 있습니다.

Tech/Product 팀의 지향점은 팀원의 성장

Tech 팀원 한 명의 성장이 곧 숨고 서비스의 성장으로 이어진다고 생각합니다. 애자일 개발 프로세스를 도입한 중요한 이유 중 하나이기도 합니다.

숨고 테크팀은 팀 단위로 개발 스토리별 함께 일하며 업무의 진도를 나가고 있습니다. 서로가 도와줄 수 있는 부분을 찾고 배울 기회를 주는 것이 목표입니다. 팀원의 개발 역량의 이해도와 능력 범위를 최대한 넓혀 주고 있습니다.

팀으로 일할 수 있도록, 팀으로 일하는 게 바로 애자일의 목표이자 실천 방향이라고 생각합니다. 숨고 Tech/Product팀은 지속해서 팀으로써 함께 일하고 성장할 수 있도록 노력하고 있습니다.