SaaS 스타트업의 스크럼 적응기

스티비 팀은 2016년 11월 서비스를 첫 출시한 뒤, 지금까지 끊임없이 새로운 기능을 개발하고 개선하고 있습니다. 1년 만에 누적 가입자 5,000명, 누적 발송량 1억 건을 달성했고, 2019년 7월 현재 빠르게 성장하는 온라인 비즈니스부터 변화를 만들어가는 미디어 스타트업까지, 약 15,000개의 팀이 스티비를 사용하고 있습니다.

좋은 콘텐츠를 제공하는 스타트업위클리, 뉴닉, 오렌지레터, 코딩야학 등이 모두 스티비로 뉴스레터를 발행합니다.

이런 규모의 SaaS(Software As A Service)를 운영하면서 꾸준히 새로운 기능을 개발하고 개선하는 건, 생각보다 인내심이 필요한 일이었습니다.

몇 년 간 이 일을 하면서 느낀 건 이렇습니다. SaaS에서는 서비스의 기능이 상품을 판매하기 위한 도구인 것이 아니라, 기능 자체가 상품이고, 기능을 판매해야 매출이 발생합니다. 그러다보니 상품 판매에 집중하기 하기 위해 새로운 기능 개발을 미룬다는 건 모순입니다. 사용성 개선을 위해 새로운 기능 개발을 미루는 판단을 하는 것은 쉽지 않습니다.

꾸준히 빠른 속도로 새로운 기능을 출시해야하고 — 마치 쇼핑몰에서 새로운 상품을 꾸준히 출시하듯이 — 그러면서도 기존 기능에 대한 개선과 오류 해결도 꾸준히 해야합니다.

기능을 출시할 수록 개선해야할 것, 수정해야할 오류는 쌓여갔습니다. 서비스가 단순할 때는 괜찮았지만, 시간이 지나면서 기능이 점점 많아지고 복잡해지고, 어느 순간부터 개선하고 수정하는 속도보다 오류가 쌓이는 속도가 더 빨라졌습니다.

초기에는 2주 단위의 스프린트로 스크럼을 진행했습니다. 방식은 이랬습니다.

1. 백로그에 수시로 할 일을 쌓아놓습니다.
2. 스프린트를 시작할 때, 백로그에 쌓여있는 것들을 리뷰하고, 우선순위와 소요시간을 고려하여 할 일을 정하고, 요건을 구체화하고 개발을 시작합니다.
3. 매일 아침 스크럼 회의를 통해 작업 진행 상황과 이슈를 얘기합니다.
4. 긴급하게 해결해야하는 이슈는 스프린트 계획과 상관없이 즉시 개발, 배포합니다.
5. 스프린트가 끝나면 개발 완료된 것을 배포하고 회고합니다.

하지만 현실에서는 이런 문제가 생겼습니다.

1. 계획과 상관없이 긴급하게 해결해야하는 이슈가 너무 자주, 많이 발생합니다.
2. 매번 계획했던 것을 제대로 완료할 수 없습니다.
3. 그러다보니 계획을 세울 때 개발 소요시간을 예측하는 것에 소홀해집니다.

2주동안 뭘 하겠다고 우리끼리 합의해봤자, 수시로 바로바로 해결해야하는 이슈들이 발생하다보니, 결국 합의가 의미가 없어지는 상황이 많았습니다.

계획이란 건 수시로 수정되어야하는 게 맞고 실제로 계획을 수정해가며 상황에 적응해갔지만, 프로세스와 현실이 너무 다르게 느껴지는 것은 팀에게 큰 스트레스로 다가왔습니다.

스프린트 회고는 마치 “이번엔 왜 계획했던 걸 다 하지 못했나”에 대한 반성의 시간처럼 느껴졌고, 대부분은 “너무 많은 긴급 이슈가 발생했고 그걸 처리하다보니 원래 하기로 한 일을 할 시간이 없었다”는 이야기를 반복할 뿐이었습니다.

개선하고 수정하는 속도보다 오류가 쌓이는 속도가 더 빨라진 상황에서, 주기를 정해놓고 일을 하는 건 현실적이지 않았습니다. 주기마다 할 일을 정하고 회고하는 것에 시간을 쓰는 것도 비효율적으로 느껴졌습니다.

이런 것들은 스크럼이라는 방법론의 문제라기보다는, 그걸 도입하고 실행한 우리 팀의 문제였습니다. 애초에 환경이 맞지 않았기 때문일 수도 있고, 제대로 이해하고 실행하지 못했기 때문일 수도 있습니다.

어쨌든 우리는 작은 팀이었고, 일을 하는 방식 자체를 바꿔보기로 했습니다. “계획과 예측의 어려움”에 대한 스트레스가 상대적으로 적어보이는 칸반 방식을 도입했습니다.

방식은 이랬습니다.

1. 주기가 없이 계속 유지되는 하나의 칸반보드를 만듭니다.
2. 백로그에 누구나 이슈를 추가할 수 있다. 프로덕트 매니저는 주기적으로 백로그에 쌓인 이슈를 정리(우선순위 조정, 필요없는 것 삭제, 요구사항 구체화)합니다. 개발을 바로 시작할 수 있는 상태가 되면 칸반보드의 “계획”열(swimlane)으로 옮깁니다.
3. 모든 멤버는 “계획”에 있는 이슈를 수시로 확인하고, 자신에게 할당된 이슈를 우선순위에 따라 처리합니다.
4. 동시에 1개 이슈만 진행합니다. 우선순위에 따라 작업 순서가 바뀌면 먼저 작업하고 있던 건 “대기”열로 옮깁니다.
5. 검증이 완료된 이슈가 쌓이면 정해진 주기없이 수시로 배포합니다.

가장 중요한 건 3번과 4번이었습니다. 한 명이 동시에 하나의 이슈만 진행할 수 있기 때문에 담당자가 스스로 자신의 속도를 제어할 수 있었습니다. 우리는 이 방식이 마음에 들었습니다.

하지만 스프린트라는 주기를 없애자, 다른 스트레스가 몰려왔습니다. 눈 앞에 쌓여있는, 맥락이 잘 보이지 않는, 분절되어있지 않은 수많은 이슈들이었습니다.

스프린트에서 칸반으로 바꾸면서 스프린트 방식에서 우리가 겪는 어려움을 얘기할 때, 스프린트라는 주기는 장점에 가까웠습니다. 주기가 없는 건 오히려 스트레스를 키웠고, 리듬을 잃게 만들었습니다. 돌이켜보면 원인을 잘못 진단한 것이죠.

정말 안좋았던 건, 맥락과 방향이 잘 보이지 않는다는 것이었습니다. 한 이슈에 대해 맥락과 방향에 대해 공통된 이해를 하려면, 스프린트 계획 회의에서 시간낭비라고 느껴지던 것과 비슷한 노력을 해야했습니다.

결국은 이건 시간낭비가 아니라 필수적인 것이었는데, 개발 프로세스에 이 과정이 명시되어있지 않다보니 종종 불필요한, 건너뛰어도 되는 것처럼 다뤄졌습니다.

그래서 연간, 분기 단위로 큰 단위의 계획과 우선순위를, 정말 — 많은 시간을 들여서 정리해보기도 했지만, 2주 단위의 예측이 어려웠듯이 연간, 분기 단위의 예측도 당연히 어려웠습니다. 이 작업은 그저 해야할 일에 대한 중요도, 난이도를 평가하고 합의하는 데 그쳤습니다. 물론 그것도 충분히 의미는 있었습니다.

2주 단위 스프린트라는 원칙을 버리고 몇 개월 일을 해본 뒤, 우리는 다시 2주 단위의 스프린트로 돌아왔습니다.

그러면서 그걸 처음 버렸을 때 느꼈던 것들을 보완하고자 했습니다. 다시 돌이켜보면, 가장 큰 문제는 “긴급 이슈 때문에 계획했던 걸 — 거의 항상 — 완료하지 못하는 데서 오는 스트레스”였습니다.

근본적인 문제는 “긴급 이슈가 많다”는 것이었고, 바꿔 말하면, “배포한 기능에서 발생하는 개선점을 제때 개선하지 못하고 문제가 발생했을 때 긴급하게 처리한다”는 것이었습니다.

다시 2주 단위의 스프린트로 돌아오면서 개선한 방향은 이랬습니다. 당연한 것일 수도 있지만, 경험이 많지 않은 팀 입장에서는 이 당연한 것들을 실행하는 것도 쉽지 않았습니다.

1. 스프린트 단위로 해결할 문제를 정의하고 이를 스프린트 기간 내 개발할 수 있는 범위의 기능(단, 적어도 사용자가 기능을 경험할 수 있는 단위의 기능)으로 개발, 배포합니다.
2. 문제 정의 및 해결책 논의와 결정 과정에 모든 멤버가 참여합니다.
3. 배포된 기능에 대해 일정 시간이 지난 후 회고, 평가, 검증합니다.
4. 스프린트를 “신규 기능 개발”과 “개선, 버그 수정”으로 번갈아 진행합니다.
5. 배포한 것에 대한 회고를 하여 개선점을 도출하고, “개선, 버그 수정” 스프린트 때 이를 우선순위에 따라 처리합니다.
6. 한 번씩 번갈아 진행하는 걸 기본으로 하되, 상황에 따라 유연하게 합니다.

실제 일을 하면서 크게 달라졌다고 느끼는 부분은 2번이었습니다.

이전에는 — 이건 프로덕트 매니저인 제가 스스로의 역할을 잘못 이해했기 때문일 수 있는데 — 한 명이 해결책을 만들어 제안하고 이에 대해 의견을 수렴하여 보완하는 방식이었습니다.

지금은 모두가 동등하게 해결책을 제안합니다. 디자이너, 프론트엔드 개발자, 백엔드 개발자, 프로덕트 매니저 모두 자신이 생각하는 가장 좋은 해결책을 스케치해서 제안합니다.

그리고 의견을 나누고, 그 중 하나를 채택합니다. 여러 해결책을 조합하여 더 나은 걸 만들기도 합니다. 해결책에 대해 투표를 하지만, 다수결로 결정하진 않습니다.

그리고 한 가지 더, JIRA와 Confluence와 버리고 Notion을 사용하기 시작했습니다. 저를 포함한 스티비 팀은 모두 Notion의 팬이기도 합니다.

JIRA와 Confluence는 다양한 기능과 자유도를 제공하는 좋은 도구였지만, 우리에게 당장 필요하지 않는 기능이 많았고, 이를 최적화하는 데에도 많은 시간과 노력이 들어갔습니다.

그에 비해 Notion은, 일단 사용하기 편합니다. 다른 장점도 얼마든지 얘기할 수 있지만 이거 하나만으로도 충분하다고 생각합니다. 마치 JIRA와 Confluence를 통합한 것처럼 사용할 수 있기 때문에, 스프린트 현황판을 그 스프린트에서 논의된 내용과 함께 표현할 수 있습니다.

예를 들어, JIRA와 Confluence를 사용할 때는, JIRA의 Board에 접근하여 태스크를 관리하고, Board에 있는 각 이슈에 링크된 Confluence 문서를 참고했다면, 지금은 스프린트 문서에 접근하여 그 스프린트에서 논의된 내용과 현황판을 한 번에 볼 수 있습니다.

게다가 문서 아래에 문서를 무한히 만들 수 있는 구조이고, 현황판에 생성하는 카드(JIRA의 이슈에 해당하는 단위)도 하나의 문서이며, 카드 하위에도 문서를 무한히 만들 수 있습니다. 따라서 각 태스크별로 생성된 카드 하위에, 그 태스크와 관련된 문서를 만들기도 합니다.

바뀐 방식으로 이제 네 번의 스프린트를 했고, 한 번의 스프린트를 할 때마다 개발 프로세스에 대한 개선점도 계속 발견됩니다. 그리고 여전히 추정은 어렵습니다.

2016년 11월 첫 출시 이후, 개발 프로세스를 이쪽으로, 저쪽으로 두 번 바꿨으니, 말그대로 좌충우돌 한 셈입니다. 물론 이렇게 바꿔보기 시작한 것도 비교적 최근 — 1–2년 이내 — 의 일입니다. 항상 그랬듯이, 지금의 방식도 완벽한 건 아니기 때문에, 언제든 또 바뀔 수 있으리라 생각합니다.

최근에 팀에서 함께 읽은 “함께 자라기”라는 책에는, 일을 하는 방식을 개선하는 것을 넘어서, 개선하는 방식을 개선하는 것이 중요하다(더글러스 엥겔바트의 작업 구분을 인용한 내용입니다)는 내용이 있습니다.

A 작업은 원래 그 조직이 하기로 되어 있는 일을 하는 걸 말합니다. (중략)
B 작업은 A 작업을 개선하는 걸 말합니다. 제품을 만드는 사이클에서 시간과 품질을 개선하는 것이죠. 제품을 만드는 시스템을 잘 설계하는 것도 포함되겠죠.
C 작업은 B 작업을 개선하는 것입니다. 개선 사이클 자체의 시간과 품질을 개선하는 것입니다. (중략) 한마디로 개선하는 능력을 개선하는 걸 말합니다. 더글러스는 “우리가 더 잘하는 것을 더 잘하게 될수록 우리는 더 잘하는 걸 더 잘 그리고 더 빨리 하게 될 것이다”라고 표현하기도 합니다.

<함께 자라기>, 33p

다행히 우리는 아직 비교적 작은 팀이기 때문에 그렇게 하는 게 어렵지 않습니다.

팀 모두가 더 좋은 서비스를 만들기 위해, 더 즐겁게 일하고 성장하기 위해 고민하기 때문에, 지금보다 더 나은 개발 프로세스는 없는지 누가 언제 물음을 던져도 이상하지 않습니다.