팀과 함께 성장하는 Agile Scrum
이 세상 어디에도 은탄환(Silver bullet)은 없습니다. 그럼에도 불구하고 인간은 만능주의에 혹하기 쉽고, 언제나 은탄환을 찾아 나섭니다.
2001년 애자일(Agile) 선언문이 발표되었을 때 애자일은 개발 업계의 은탄환 후보로 주목받았습니다. 17년이 지난 지금, 개발자들에게 애자일은 더이상 그토록 찾아 해메던 은탄환은 아닙니다. 그러나 팀을 성장시키며 비즈니스를 성공으로 이끄는 실용적이고 훌륭한 도구로 자리잡았습니다.
저는 2004년 웹개발자로 커리어를 시작했습니다. 2011년부터는 개발팀의 리더겸 시니어 개발자로 일하고 있습니다. 팀 리더 역할을 맡게 된 이후, 어떻게 하면 개발 프로젝트를 통해 달성하고자 하는 목표들(일정 준수, 우수한 품질, 팀의 성장)을 모두 성취할 수 있을 지 꾸준히 고민했습니다.
고민의 결과 오늘날 최선의 답은 애자일이라고 생각합니다. 그렇기에 저의 애자일 개발 프로세스 경험을 언젠가 이야기 하고 싶었습니다.
애자일? 타협을 통한 지속적인 개선
소프트웨어 개발 방법에 있어서 이상적인 것은 완벽한 기획과 예측에 근거하여 완성된 소프트웨어를 적시에 개발하는 것입니다. 이것을 ‘계획 기반 개발(Plan-driven development)’이라고 하며, 이 때 소프트웨어는 ‘폭포수 모델(Waterfall Model)’이라는 프로세스에 따라 개발됩니다. 이러한 방식이 성공하기 위해서는 너무나도 이상적인 조건들이 모두 딱딱 맞아 떨어져야 합니다. 그러나 현실에서는 미래의 일을 예측하기 어렵고, 예상 밖의 변화들은 필연적으로 발생합니다. 더군다나 소프트웨어 개발 과정은 유동적이고 개방적이며 작업량을 예측하기 어렵습니다.
그렇다면 애자일(Agile)은 무엇일까요? 저는 애자일이 타협이라고 생각합니다. 애자일은 이상적인 조건이 아닌 현실의 상황을 가정합니다. 지속적인 변화를 수용하며 제한된 자원을 활용하여 프로젝트를 개선해 나갑니다. 매 순간 팀은 최선의 타협점을 고민하고 찾아나가며 개발을 수행합니다.
애자일 개발 프로세스라 불리는 것은 여러가지 종류가 있습니다. 스크럼(Scrum), 칸반(Kanban), 익스트림 프로그래밍(eXtreme Programming, XP) 등이 있으며 각각 특징과 적용범위가 달라 서로 조합하여 활용할 수 있습니다.
새내기 팀장의 시행착오로 끝난 첫번째 애자일 스크럼
2011년, 새내기 팀장이 되어 팀의 일하는 방식을 고민하기 시작했습니다. 소프트웨어 개발 방법론을 공부하며 애자일에 대해 관심을 가지게 되었고 ‘스크럼과 XP’라는 한 권의 책을 읽고 큰 감명을 받게 됩니다.
스크럼이 말하는 이터레이션(Iteration)은 이상적이며 매력적입니다. 팀은 과업을 백로그(Backlog)로 관리하고 있으며, 스프린트(Sprint)라 불리는 짧은 반복 개발주기를 기준으로 다시 계획을 세우고 이를 해결해 나가며 지속적인 개발과 개선을 만듭니다.
하지만 스크럼의 방법론은 당시 소속 부서의 특성(유관 부서의 영향을 지속적으로 받으며 일을 해야하는 운영과 동시에 개발을 진행하는) 때문에 실제로 도입할 수는 없었습니다. 가볍게 시도해 봤던 스크럼은 예상대로 실패하였습니다. 스크럼으로 일하려면 팀원 뿐만 아니라 고객도 준비가 필요하기 때문에 실천이 쉽지 않습니다.
팀은 다시 예전에 일하던 방식으로 돌아갔습니다. 전화나 이메일을 통해 요구를 접수한 후 포스트잇에 기록하여 벽에 붙이고, 작업자는 이를 자리로 가져가서 모니터에 붙인 다음 해결이 되면 팀의 공용 다이어리에 옮겨 붙였습니다. 덕분에 팀원들의 모니터 테두리는 항상 포스트잇으로 가득했죠!
간단하고 익히기 쉬웠지만 2% 부족했던 칸반
그러다가 2013년에 이직을 했고 다시 한번 팀의 일하는 방식에 대해 고민할 기회를 얻었습니다. 때마침 ‘칸반과 스크럼’이라는 책이 번역되어 발간되었습니다. 이 책을 통해 칸반을 배웠습니다.
칸반의 방법은 좀 더 심플합니다. 아주 간단하게는 아래와 같은 모습으로도 표현할 수 있습니다. 칸반은 몇 개의 구분된 보드를 가지며 일의 상태에 따라 옮겨가며 프로세스를 진행합니다. 아주 익히고 사용하기 쉽지요!
실제로 칸반과 유사한 방법을 자연적으로 고안하여 실천하고 있는 경우를 종종 접할 수 있습니다. 하지만 칸반은 여기에 몇 가지 룰을 더합니다. 일을 잘개 쪼개고, 우선순위를 매기며, 동시에 진행되는 일의 가짓수를 제한하는 등의 규칙입니다(칸반을 더 자세하게 알고 싶으시면, 위의 도서를 참고해주세요).
칸반을 통해 팀을 운영하는 것은 매우 손쉬웠습니다. 칸반의 간단한 룰은 누구나 쉽게 이해할 수 있었고, 이에 비해 얻을 수 있는 효용은 컸습니다. 하지만 뭔가 아쉬운 느낌은 지울 수 없었죠. 앞서 실패했던 스크럼에 대한 아쉬움이 컸습니다. 스크럼으로 좀 더 계획적이고 체계적으로 일하고 싶었습니다.
창업과 함께 재도전한 두번째 애자일 스크럼
2015년 창업을 하면서 이번에는 완전히 새로운 제품을 개발하는 조직을 리드해야하는 상황에 처했습니다. 기존 서비스 운영에 영향을 받지 않기에, 바로 이 때가 스크럼을 실천할 적기라는 것을 직감적으로 알 수 있었습니다.
첫번째 제품의 아이디어가 결정되었을 때 이를 개발하기 위한 작업을 최대한 잘개 쪼갠 후 상세히 정리하여 백로그에 가득 채웠습니다. 스프린트의 주기는 2주로 정했습니다. 한 달로 하려하니 그만큼의 기간을 계획할 자신이 없었습니다. 1주일로 하기에는 주기가 너무 짧다고 생각했습니다. 2주로 정한 데는 1주차를 보내고 난 뒤에 진도가 미진하면 주말을 이용해 채우겠다는 얄팍한 의도가 포함되었음을 고백합니다.
처음 몇 달은 전자적인 도구의 도움 없이 화이트 보드와 포스트잇을 활용하여 스프린트를 진행했습니다. 당시 유행했던 Trello나 Jira를 사용하기에는 학습 비용이 부담되었고, 저를 포함한 팀원 모두에게 스크럼 문화가 낯설었기 때문입니다.
스크럼의 집중도(Velocity)를 통한 지속적 성과 향상
스크럼에서 가장 중요한 개념은 집중도입니다. 이는 사람이 실제로 집중할 수 있는 시간은 한정되어 있다는 타당한 가정에서 출발합니다. 하루 업무 시간을 결정하고 이중에 집중해서 일한 비율을 관리합니다. 이를 위해서 세분화한 작업 단위를 스토리라 부르고, 이 스토리 카드(Story card)에 스토리 점수(Story point)라는 숫자를 매깁니다.
스토리 점수는 최고로 집중하여 최대의 퍼포먼스로 일했을 때, 스토리 카드를 해결하는 데 걸리는 시간을 의미합니다. 산정된 스토리 점수와 이를 해결하기에 소모된 시간을 바탕으로 스프린트의 집중도를 계산하고, 이 집중도를 기준으로 스프린트 성취도를 판단합니다. 그러므로 스토리 점수가 너무 과소 혹은 과도하게 부여되지 않도록 신중하게 결정해야 합니다.
집중도(Velocity) = 해결한 스토리 점수 / 실제 소요 시간
예를 들어 10명의 개발자가 하루 8시간 씩 10일 동안 개발을 했는데, 스토리 점수를 528점 해결했다면 집중도는 528점 / (10명 X 10일 X 8시간) = 66%라는 것이죠.
집중도는 스크럼에 참여하는 모든 인원을 합산하여 계산합니다. 개인별로 집중도를 계산하는 것은 불필요하게 팀원을 서로 경쟁하게 만들어 장기적으로는 오히려 해악을 가져올 수 있습니다.
재미있는 점은 다음 스프린트의 집중도 목표는 최근 몇 개의 스프린트에서 달성한 집중도의 평균을 바탕으로 계산하는데, 항상 과거 결과의 평균보다 약간 더 높은 목표를 설정하여 매 스프린트가 도전적인 목표를 가지게 된다는 것입니다. 예를 들어 최근 3번의 스프린트 집중도가 66% 였다면, 다음 스프린트의 집중도 목표를 67%로 상향하는 방식입니다. 그래서 목표를 이루었을 때는 높은 성취감을 느낄 수 있고, 실패하더라도 다음 스프린트에서 낮아진 평균값으로 인하여 덜 도전적인 집중도 목표를 설정하게 됩니다. 이러한 집중도 관리를 통해 스크럼 팀은 계획의 정확도와 성과를 지속적으로 향상시킬 수 있습니다.
스크럼을 기반으로 한 스프린트의 진행 과정
스크럼 팀은 공동의 도전적 목표를 공유하고 스프린트를 진행하며 매일 간단한 미팅을 가집니다. 이를 ‘일일 스크럼 회의(Daily scrum meeting)’이라고 하는데, 가능한 짧게 진행하기 위해 서서 하는 것을 권장하여 ‘일일 스탠드업 미팅(Daily standup meeting)’이라고도 불립니다. 이 미팅에서 스크럼 팀원들은 각자의 진행상황을 공유하여 팀 내에 긴장감을 지속적으로 환기시킵니다.
하나의 스프린트가 끝난 뒤에는 회고와 계획의 시간이 필요합니다. 회고를 통해 목표와 성과를 비교하고 집중도를 계산하며 서로에게 칭찬과 위로를 건네면서 팀의 유대를 강화합니다. 절대로 누군가를 비난해서는 안됩니다.
이후 다음 스프린트를 위한 계획회의를 합니다. 그간의 경험과 진행 상황을 토대로 백로그에 남은 스토리 카드의 내용을 업데이트하고 스토리 점수를 정밀하게 조정합니다. 그리고 다음 스프린트의 집중도 목표를 정하고 스프린트의 범위와 일정을 합의한 후에 다시 스프린트를 시작합니다(더 자세한 실천 방법은 위의 두 권의 도서를 참고해주세요).
이후 2년간 스크럼 팀을 운영하면서 많은 경험을 얻었습니다. 스크럼은 팀을 집중하게 만들었고 자연히 높은 성과를 가져왔으며 일정을 정확하게 산정하는 것을 가능케 했습니다. 무엇보다도 팀의 구성원들이 큰 자신감을 가졌고 높은 유대감을 형성할 수 있었습니다. 결과적으로 팀은 빠르게 성장하였습니다.
스크럼을 프로세스 관리를 위해 여러 도구를 사용해 보았는데 결론적으로 Jira에 정착했습니다. Jira는 칸반과 스크럼 방식 모두에서 가장 강력하고 편리한 도구라고 개인적으로 생각합니다.
Jira를 통해 스크럼 유형의 프로젝트 보드를 생성하면 백로그 관리 기능과 스크럼 보드를 사용할 수 있으며 이를 바탕으로 다양한 리포트 역시 제공합니다. 스프린트 보고서, 번다운 차트, 집중도 차트, 버전 보고서 등의 측정 도구를 통해 성과를 보다 정밀하게 관리할 수 있었습니다.
성공적인 스크럼을 통해 개발한 이벤트 플랫폼 Festa
2017년 12월에 잠시 Festa라고 하는 이벤트 세일즈 플랫폼 개발에 PM으로 참여하였습니다. 당시 Festa는 개념증명(Proof of concept, POC)을 마친 뒤 첫번째 제품 출시를 위해 준비하고 있었습니다.
새로 조직된 팀이기에 업무 방법에 대한 논의가 필요했고 저는 스크럼을 제안했습니다. 제안이 받아들여져 첫번째 ‘최소 기능 제품(Minimum viable product, MVP)’를 결정하고 백로그를 수립하였습니다.
이 때 가장 주안점으로 둔 부분은 제품 출시 일정이었습니다. 제품이 필요한 날짜가 결정되어 있었고 반드시 일정에 맞추어 프로젝트를 완료해야 했습니다. 주어진 기간은 한 달 남짓. 만들어야 하는 것은 ‘이벤트의 티켓을 간편 결제를 통해 구입할 수 있는 편리한 웹사이트’ 였습니다.
과연 이제 갓 조직된 Festa팀은 첫번째 제품을 기한 내에 출시할 수 있었을까요?
기간이 한 달 남짓으로 짧았기에 스프린트 주기를 일주일로 결정했습니다. 스프린트를 반복하면서 백로그를 충실히 관리하면 제품 출시 일정을 매우 정확하게 예측할 수 있습니다. Jira는 스토리 카드에 버전을 매길 수 있는데 이를 통해 버전 보고서를 제공해 줍니다. 이 기능을 활용하여 예상 출시일을 지속적으로 확인했고 과감하게 개발 범위를 조정하여 목표를 달성가능하게 관리했습니다.
Festa 팀은 스크럼을 통해 꾸준하게 높은 성과를 내었고 목표한 시점에 성공적으로 제품을 출시할 수 있었습니다. 위의 버전 보고서를 보시면 스토리 점수가일정한 기울기로 증가함을 확인할 수 있습니다. 이는 팀이 항상 꾸준한 퍼포먼스로 적시에 제품을 개발했다는 증거입니다.
새로운 스크럼 도전, QueryPie 개발 in CHEQUER
2018년에는 새로운 회사인 CHEQUER에서 일하게 되었습니다. SQLGate라는 DB Tool을 서비스하는 회사입니다. 처음에는 스스로를 새로운 환경에 적응시킨 후 성과를 내는 데 집중했습니다. 어느 정도 적응을 마친 후 다시 한번 팀의 일하는 방법에 대해 고민하였습니다. 그리고 조심스럽게 팀원들에게 스크럼에 대해 이야기하기 시작했습니다.
스크럼을 비롯하여 애자일 프로세스를 도입하고자 할 때 가장 중요한 것은 무엇이라고 생각하시나요? 저는 도입을 추진하는 사람에 대한 평판이라고 생각합니다. 신뢰가 기본이 되어야 새로운 것을 받아들일 열린 마음을 얻을 수 있습니다. 반년 이상 CHEQUER에서 능동적으로 일하며 경영진과 팀원들의 신뢰를 확보했기에 다시 한번 스크럼팀을 조직할 수 있었 습니다.
CHEQUER는 빠르게 성장하는 스타트업으로, 깊은 내공을 가진 경영진들의 노력으로 적극적이며 재능 넘치는 크루들을 빠르게 확보한 상태였습니다. 저는 이들을 스크럼을 통해 단단하게 성장시켜 비즈니스를 성공시키겠다는 도전정신과 열의에 불타올랐습니다. (CHEQUER가 이번에 스크럼을 통해 도전할 목표인 QueryPie에 대해서는 이 글을 참고해주세요)
팀원들에게 스크럼의 개념과 규칙을 설명하면서 백로그를 수립하고 첫번째 스프린트 계획을 수립했습니다. 집중도 목표는 경험을 바탕으로 64%로 설정했습니다. 참고로 70% 이상은 초일류의 수준이라고 생각합니다. 속임수가 없다면 달성하기 정말 어려운 숫자 입니다. 참여하는 크루의 수는 일단 4명이었고 첫번째 스프린트 기간은 8일이었습니다. 이를 기반으로 계산하면 4명 X 8일 X 8시간 X 64%(집중도) = 164 스토리 점수 달성이 목표가 됩니다.
백로그를 정리하여 ver.1.0.0의 목표를 세웠습니다. 목표 완료일은 3월 1일 입니다. 스프린트를 시작한지 며칠이 지나고 버전 보고서를 보았습니다. 예상 완료일이 3월 5일이군요. 아차차! 공휴일정보가 입력되지 않았습니다.
공휴일 정보를 입력했습니다. 큰일 날 뻔 했어요! 예상 완료일이 3월 11일로 딱 휴일 수 만큼 늘어났습니다. 하지만 이대로라면 완료일이 목표일보다 무려 10일이나 늦어지게 되어 조정이 필요합니다. 우선 백로그를 다시 살펴봤습니다. 단 며칠 밖에 스프린트를 진행하지 않았지만 유능한 CHEQUER의 크루들은 금새 스크럼에 적응하여 초기에 부정확하게 정해진 스토리 카드와 스토리 점수를 다시 정밀하게 조정할 수 있었습니다.
첫번째 스프린트 8일의 도전이 끝났습니다. 크루들이 마지막에 높은 성과를 이뤄낸 것이 보입니다. 또한 예상 완료일이 2월 22일로 여유 있게 조정되었습니다. 버전 그래프가 보여주는 긍정적인 완료일과 부정적인 완료일의 차이도 좁혀졌습니다. 앞으로 두 번 정도의 스프린트를 완료하고 나면 매우 높은 정확도를 가진 버전 보고서를 얻을 수 있을 것이라 기대합니다.
단 8일의 짧은 스프린트였지만 이를 통해 CHEQUER의 크루들은 체계적이고 효율적으로 일하는 방법을 체득했습니다. 또한 첫번째 스프린트를 성공함으로써 자신감을 얻었고 크루들간의 유대도 돈독해졌습니다. 스크럼을 통해 우리는 함께 성장했으며, 앞으로 이어질 스프린트를 통해 더욱 크게 성장할 것입니다.
애자일 스크럼 회고를 마치며
첫번째 스프린트를 마치고 애자일 스크럼 프로세스 회고를 하며 여러가지 의견들이 나왔습니다. 그 중에 크루별로 진도를 볼 수 있으면 좋겠다는 의견도 있었는데 이것은 자칫 불필요한 경쟁과 부정적인 낙인을 야기할 수 있어서 조심스럽게 접근해야 한다고 생각합니다.
팀으로 일하는 것은 경쟁이 아니며 공동의 목표를 향해 유대감을 쌓으며 꾸준히 함께 나아가야 합니다. 힘들어하는 크루가 있으면 도와서 스크럼 팀의 집중도를 계속 향상시켜야 같이 성장할 수 있습니다.
마지막으로 이 긴 글을 통해 함께 성장하는 애자일 스크럼이 가능하다는 것을 많은 분들이 이해하고, 당신의 도전에 힘을 조금이라도 보탤 수 있다면 좋겠습니다. 당신과 팀의 성장을 기원합니다!
