제품 스쿼드의 스크럼 프로세스 개선기 1부

안녕하세요. 저는 레몬베이스에서 Backend Engineer로 일하고 있는 라봉(Labhong)이라고 합니다.

레몬베이스는 스쿼드 조직으로 제품을 개발합니다. 레몬베이스 스쿼드는 보통 PO(Product Owner)와 PD(Product Designer), 그리고 Frontend / Backend Engineer가 하나의 스쿼드를 이뤄 하나의 제품을 만들고 있죠 저는 그 중 ‘리뷰’ 제품을 개발하는 리뷰 스쿼드에 속해 현재까지 약 1년 가까이 일을 하고 있고요.

리뷰 스쿼드는 스프린트 단위로 개발을 진행하는 스크럼 방식을 사용하고 있습니다. 여기서 ‘스크럼(Scrum)’이란, 팀이 협업하고 영향력이 큰 업무를 수행하는 데 도움이 되는 애자일 프레임워크를 말해요. 스크럼 프로세스를 실행하면 복잡한 문제를 함께 해결하는 데 도움이 될 수 있어서 저희도 이 방식으로 일 하고 있습니다.

이렇게만 보면 스크럼은 정말 좋아보이는 프레임워크라고 생각할 수 있겠지만, 스크럼에 대한 좋지 않은 시선들도 분명 존재합니다. 제대로 활용하지 못한다면 오히려 비효율적인 방식으로 일을 하게 되기 때문이에요. 사실 제가 리뷰 스쿼드에 처음 들어왔을 때도 그러한 상황이었는데요, 일을 하면 할수록 팀에 적합하지 않은 스크럼 방식이 점점 비효율적으로 느껴졌습니다.

하지만 과거의 좋지 않은 스크럼 방식에서 우리 팀에게 맞는 방식으로 계속 보완해나가면서 현재는 스쿼드 내의 모든 크루가 기존보다 더 나은 방식으로 업무를 하고 있습니다. 어떤 일이 있었고, 어떻게 개선해나갔는지 공유 해보고자 해요

글의 내용이 길어 1부는 과거의 스크럼 방식의 문제점을 정리하고, 2부는 어떻게 개선했고 현재는 어떤 방식으로 운영하는지 소개해보겠습니다.

제가 리뷰 스쿼드에 합류했던 시점은 22년 1분기 쯤, 리뷰 스쿼드가 일괄 평가 기능을 런칭하기 직전이었습니다. 그때 당시 크루들은 런칭 막바지에 해결해야 하는 일들을 급하게 처리하느라 매우 바쁘고 지친 상태였는데요. 쉽지 않은 상황이었지만 힘을 모아 일괄 평가 기능을 런칭했고, 곧바로 업적 평가 기능 개발에 돌입했습니다. 저는 그 이후에 본격적으로 개발을 시작하게 되면서 팀이 일하는 방식을 배우게 됐습니다.

그 당시 리뷰 스쿼드는 스크럼을 위해 Jira와 Confluence를 사용했으며 다음과 같은 방식으로 업무를 진행했어요.

PO가 스프린트 사이클을 시작하기 전에 어떤 기능을 개발해야 하는지 기획서를 작성해 공유합니다. 그리고 PO 주도 하에 해당 기획을 공유하는 미팅을 진행하며, 이 때 모든 크루가 미팅에 참가합니다. 여기서 스쿼드는 큰 맥락의 기획 방향성을 맞추게 되고요, PO는 기획의 의도를 담은 Jira 티켓을 User Story 형식으로 생성합니다.

스프린트를 시작하기 직전, 혹은 시작하고 난 뒤에 스프린트에 배정된 일감을 누가 가져갈 건지 자율적으로 선택해서 가져갑니다. 이 때, 각 티켓에 대한 세부적인 개발 방향성 논의는 하지 않은 상태인데요. 그렇기 때문에 각 작업의 일의 양이 얼마나 되는지, 어떤 방식으로 개발하면 좋을지 서로 모르는 상태로 스프린트가 시작됩니다.

앞서 언급한 대로 스프린트 시작하기 전에 작업에 대한 세부적인 논의를 거치지 않은 상태이기 때문에, 티켓을 할당받은 크루들은 자신의 작업과 관련있는 팀원과 커뮤니케이션이 필요한 경우 그제서야 소통하게 됩니다.

예를 들어 기획에 문제가 있거나, 세부 기획이 빠져있는 경우 업무 진행자가 PO, PD와 같이 미팅을 진행해 세부 기획을 추가합니다. 혹은 기획에 대해 어떻게 문제를 해결할지 개발팀에서 논의가 필요한 상황이라면 관련 팀원과 같이 미팅을 진행해 개발 방향을 결정하기도 하고요.

매일 오전 10시에 모든 크루들이 모여 데일리 스크럼을 진행합니다. 데일리 스크럼 시간 동안 각 크루는 돌아가면서 어제 무슨 일을 했는지 본인들의 진척 상황을 얘기합니다.

스프린트 초반에는 업무를 어떻게 해야 하는 지 세부적인 논의를 하지 않은 상태이기 때문에 데일리 스크럼 시간을 이용해서 세부 스펙에 대한 논의를 진행하기도 합니다.

스프린트가 끝나갈 무렵에 스프린트 기간 동안 우리가 무엇을 잘했고, 무엇을 못했는지 회고하는 시간을 갖습니다. 팀원 중 한 명이 진행자가 되어 미팅 시간동안 KPT(Keep-Problem-Try) 방식이나 4L(Liked, Lacked, Learned, Longed for) 등의 템플릿을 사용해 회고를 진행합니다. 그 후, 회고를 통해 다음 스프린트에 도입해 볼 액션 아이템을 도출한 뒤에 회고를 마무리해요.

하지만 스프린트 업무를 하다보면 기한 안에 작업을 다 끝내지 못한 경우가 대부분인데요, 그럴 땐 회고 미팅을 하지 않고 은근슬쩍 넘어가기도 합니다

위의 방식을 살펴봤을 땐, 스크럼 방식에는 크게 문제가 없어 보입니다. 하지만 하나씩 조목조목 살펴보면 내부에는 두 가지 숨겨진 문제점이 있었습니다. 하나는 충분한 커뮤니케이션의 부재, 다른 하나는 잘못된 스프린트 관리입니다.

스프린트를 진행하는 동안 개발해야 하는 기획에 대해, 그리고 개발 방향에 대해 팀 내에 충분한 커뮤니케이션이 부족했어요. 그로 인해 다음과 같은 문제점들이 발생했습니다.

제가 리뷰 스쿼드에 합류한 시점은 스쿼드의 절반 이상이 신규 팀원으로 충원 됐었던 시기였습니다. 그런 상황에서 적절한 스쿼드 온보딩 프로세스가 없었기 때문에 아직 서로 간의 친밀함이 부족한 상황이었었죠. 그런 상황이었기에 커뮤니케이션 부족으로 인해 발생한 문제는 다음과 같았습니다.

서로 간에 거리감이 있다보니 일을 하다가 모르는 것이 있어도 다른 팀원에게 질문하려고 하지 않았습니다. 본인이 직접 코드를 찾아보거나 기획서를 살펴보는 등 스스로 문제를 해결하는 데 시간을 사용했고요. 또한 자신의 부족함을 드러내는 것을 어려워하다보니 팀원에게 도움을 요청하려고 하지 않는 경향을 보였습니다.

애초에 팀 내 커뮤니케이션이 원활하지 못한 상황에서 팀이 나를, 혹은 내가 팀을 믿지 못하다 보니 더욱더 커뮤니케이션은 부족해졌고, 그로 인해 팀 내 신뢰도가 계속 떨어지면서 악순환이 반복됐습니다.

기획서를 보고 모든 팀원이 한 자리에 모여서 기획에 대한 이해를 일치시키는 커뮤니케이션 과정이 없었습니다. 그 때문에 같은 기획에 대해 서로 다르게 이해하는 상황이 발생하게 됐고요. 그러다 보면 PO의 기획과는 다른 기능이 개발되기도 하고 개발자들끼리도 이게 맞는지, 저게 맞는지 갑론을박을 펼치다가 다시 PO나 PD에게 질문하는 등 시간을 아깝게 소모하는 상황이 빈번히 발생했습니다.

기획을 바탕으로 기능을 개발할 때 필요한 것, 해야 하는 것들이 무엇인지 모르는 상태를 우리 스쿼드는 “모르는 걸 모르는 상태”라고 얘기합니다.

스프린트가 시작되기 전에 기획에 부족한 점이 있는지, 해당 기획안대로 개발을 실제 진행할 수 있는지, 기획이 현재 제품에 녹아들 수 있는 상황인지 등 개발팀에서 검증하는 과정이 없었어요. 그러다 보니 PO와 PD는 현재 기획과 디자인이 스프린트 기간 안에 개발이 가능한지, 개발했을 때 문제는 없는지, 부족한 부분은 없는지 등의 상황을 모르기 때문에 답답함이 있었죠.

그렇게 스프린트가 시작되고 상당한 시간이 흘러 스프린트가 다 끝나갈 때쯤에 실제 프로덕트를 개발하다가 세부 기획이 부족했다거나 현재 제품에 맞지 않는 기획이라는 것을 깨닫게 됩니다. 하지만 제품에 맞지 않는 기획을 바꾸기엔 너무 멀리 와버려서 급하게 임시방편의 해결책을 넣게 돼요. 그런 식으로 부채는 쌓여갔습니다.

정리하자면 커뮤니케이션이 부족했기 때문에 모르는 걸 모르는 경우가 많았습니다. 뭔가가 부족한 것 같은데 그게 뭔지 몰라서 답답해하다가 결국에 나중에 일이 터져버렸고, 긴박감과 스트레스에 압박감을 느끼게 된 경우가 상당히 많았습니다.

스프린트가 시작되기 전에 문제를 어떤 식으로 해결할 지 정하지 않다 보니 어떻게 해결해야 하는지 혼자서 고민하는 시간이 많이 필요했습니다. 그런 상황에 커뮤니케이션까지 원활하지 않으니 같은 문제에 대해 서로 다른 해결 방법을 고민하게 되고, 의견을 취합하고 합의하는 과정에 많은 시간이 소요됐어요.

예를 들어, 코드를 개발하고 난 뒤에 코드 리뷰를 진행할 때도 팀원마다 생각했던 해결 방식이 서로 다른 경우 이를 설득하고 합의하는 과정에 상당한 시간이 소요됐습니다.

과거의 스크럼은 다른 팀이 사용하는 스프린트 방식을 그대로 가져와서 사용했다는 느낌을 받았습니다. 왜 이런 미팅을 해야 하고 저런 과정을 거쳐야 하는지 모르는 상태로 스프린트를 진행하다 보니 우리 팀에 맞지 않는 스프린트를 하고 있다고 생각했습니다.

스프린트의 잘못된 관리로 인해 발생한 문제는 다음과 같습니다.

과거 스프린트는 이번 스프린트의 목표가 무엇이고, 어떤 작업을 해야하는지 공유가 제대로 이루어지지 않았습니다. 이렇게 맥락 파악이 안 된 상태에서 각자 진척도를 공유하게 되니 누가 무슨 일을 했고 어떤 일을 하고 있는지 알기 어려웠죠. 안 그래도 다른 팀원이 어떤 일을 하는지 공유가 안 된 상태에서 서로 진척도를 구두로 전달하니 더 이해가 되지 않아서 시간을 오히려 낭비하는 일이 생겼습니다.

게다가 일감을 쪼개지 않고 큰 덩어리로 Jira 티켓을 관리하다보니 매일 아침 데일리 스크럼 때 진척도를 공유해도 “진행 중” 단계에만 머무르는 작업을 보고 어디까지 진행했는지 알기 어려웠어요.

과거의 프로세스는 전반적으로 스프린트의 현재 상황을 알기 어려운 구조였습니다. 모두 한 자리에 모여서 문제에 대해 얘기하는 과정이 없었고, 자신들과 연관된 사람들끼리만 커뮤니케이션을 하다 보니 스프린트 내 연관 이슈들을 파악하기 어려웠어요. 즉, 전체적인 조감도가 그려지지 않았습니다.

또한 문제에 대해 개개인이 개별적으로 문제를 해결한다거나, 데일리 스크럼 때 개인이 한 일만 말로써 얘기하다 보니 스프린트가 어디까지 왔는지 시각적으로 알기 어려웠어요.

일이 어렵거나, 프로젝트 진행이 잘 안되는 느낌 등등 어려움을 공유하는 환경이 조성되지 않았습니다. 그러다보니 스프린트 끝날 때쯤 문제가 터지게 됐습니다.

미리 어려움을 팀원들에게 말하거나 공유할 수 있는 환경이었다면, 겪고있는 문제를 얘기하고 미리 문제를 방지할 수 있는 것들이 많았으나 그럴 수 있는 환경이 아니다 보니 자신의 어려움을 공유하려면 큰 마음을 먹고 공유했어야 했습니다.

스프린트가 시작하기 전에 일감을 산정하는 방식이 현명하지 못했습니다. 스프린트에서 일감을 산정할 때 주요 논쟁은 "기간 안에 끝낼 수 있냐"가 아니라 "이거 해야 하니 하자"가 목표였어요. 즉, 일감의 소요 시간을 측정하지 않고 무작정 일감을 배정했던 것이죠.

측정이 안 되는 일을 일단 해야 한다는 명목하에 스프린트에 넣고 시작하다 보니 예상하지 못한 장애물을 만나게 될 때가 있습니다. 하지만 일정은 이미 정해져 있기 때문에 기간 안에 해결해야 한다는 부담이 점점 커지게 됩니다. 그 와중에 각자 어려움을 공유하지도 않는 환경이었기 때문에 불안감과 압박감이 심했어요. 이런 스프린트가 반복되니 팀의 사기가 눈에 띄게 줄어드는 것이 느껴졌어요.

과거의 스쿼드는 PO가 Product Owner 본연의 역할 뿐만 아니라 스크럼을 관리하는 역할도 같이 수행했습니다. 그러다 보니 PO의 역할을 수행할 때는 스크럼을 세세하게 관리하기 힘들어지는 일이 발생했어요. 특히 한창 바쁠 때는 PO의 업무 과다로 스크럼이 제대로 관리되지 못하는 경우가 생기는데, 그때마다 스쿼드는 망망대해를 떠도는 느낌을 받았습니다. (어디로 가야 하는지, 잘 가고 있는지, 팀원 모두가 노를 젓고 있는 상황인지..)

과거의 스크럼 방식의 문제점을 정리하자면 아래와 같습니다.

앞선 글을 통해 과거 리뷰 스쿼드의 스크럼 방식과 해당 방식의 문제점을 짚어봤습니다. 스쿼드 전원이 필사적으로 노력해서, 과거의 아픔을 딛고 지금은 모두가 훨씬 더 효율적이고 수월하게 스쿼드 내 협업을 하고 있는데요