'애자일' 굴에 들어가서 정신 똑바로 차리는 법
우리는 왜 애자일하게 일하기로 했을까?
흔한 것과는 별개로, 우리가 정말 애자일(Agile) 한 지 의심해야 한다.
이 글이 도움 될 수 있을 분들
○ 애자일 프로세스를 적용하기 시작한 분들
○ 스프린트가 계속해서 깨지거나 속도 그래프가 일정하지 않은 분들
○ 초기 스타트업의 업무 프로세스가 궁금한 분들
스타트업 프로덕트팀의 채용 공고를 보면 스스로를 애자일한 조직이라 소개하는 것을 쉽게 볼 수 있다. IT 시장은 1~2개월 사이에 아이템이 사장되곤 해서, 프로덕트가 긴 호흡을 갖고 오래 달릴 수 있는 여건을 보장하지 않는다. 그만큼 개발, 기획, 디자인이 쳇바퀴처럼 도는 이터레이션(Iteration, 반복)은 싫다고 피할 수 있는 게 아니게 됐다.
피할 수 없다면 즐기면 되는 걸까. 생각보다 애자일의 장점만을 끌어모아 안정적으로 일하기란 정말 쉽지 않다. 얼굴을 보고 하자던 스크럼 미팅이 변모되어 슬랙에 할 일과 한 일을 기록하는 자기 할 말만 쓰고 가는 메모장이 되어버렸다거나, (아무도 내가 뭘 하는지 모른다.) 회고가 전혀 공유가 되지 않아서 당장 다음 주에 뭘 해야 할지 기획자만 알고 있거나, 매주 스프린트의 달성 목표는 지키지 못했지만 일단 고! 하는 식이다.
변모한 애자일을 대처하기 위해서는 매너리즘에서 빠져나오려는 노력이 필요하다. 이미 익숙해진 애자일 프로세스에 질문을 던지는 것이다. 애자일은 왜 도입한 거였지? 과연 바라는 방향으로 일하고 있는 걸까? 스크럼, 회고는 우리에게 무슨 의미를 갖고 있지? 애자일은 효율적인 협업을 위한 툴인만큼, 공동의 목표가 잘 Align 되어 있을수록 효과적이다. 하지만 잘하고 싶은 마음이 굴뚝같지만 관성적으로 움직이고 있다면, 다시 원점으로 돌아와야 하는 때가 온 것이다.
이제는 돌아와야 할 때
매주 스프린트가 깨지는데 무시하고 있는 우리
나는 앞서 언급한 여러 사례 중에서, 가장 마지막의 케이스를 해결한 방식을 소개하고 싶다. 이전 회사는 금융 IT 스타트업이자 어린 연령대로 채워진 학생 창업이었기에 그 누구보다도 불나방처럼 일했지, 매너리즘에 빠지지는 않았다. 잘하고 싶었는데 그 방법을 몰랐을 뿐이다.
업무를 시작하면 데일리 미팅 (스크럼 미팅)을 진행해서 각 팀원의 업무 진척을 파악했고, 특정 기능을 만들 때에는 1~2주일짜리 스프린트로 척척 개발하여 기존 프로덕트에 붙여냈다. 에픽, 스토리의 백로그(Backlog)는 아틀라시안 지라 (Atlassian Jira)로 관리되었고, 각 기능이 만들어지기 위해 필요한 최대 시간을 중요도에 따라 측정하여 (Estimate Point) 각 멤버에게 분배했다. 이렇게 분배된 작은 테스크들은 해야 할 일/진행 중인 일/완료된 일로 구분된 칸반 보드에서 각 필러를 오고 갔다. 덕분에 서로의 업무가 어디까지 진행됐는지 현황은 세세하게 관찰할 수 있었다. 하지만 서로의 업무를 지켜보는 것과 별개로 기간 내에 모든 할 일을 완수해내는 성공률은 반 밖에 안됐다.
비밀유지로 인해 흐릿하게 만들었지만, 왼쪽 칼럼부터 해야 할 일, 하고 있는 일, 끝난 일이다.성공률을 높이기 위해 회의를 잡아 공격적이지만 현실적으로 가능한 OKR을 짰는지 논의해보기도 하고, 개발자의 업무 량이 얼마나 과도한지 이해해보려 했지만 스프린트 성공률에 이렇다 할 변화는 없었다. 한 주 한 주 터져만가는 스프린트를 지켜보며 고민하다 마침내 발견한 패착은, '개발자-기획자, 기획자-디자이너, 디자이너-개발자가 서로 뭘 하는지 글자로만 알고 있음'이었다. 생전 처음 도착한 외국의 어느 공항에서 다음 비행기를 타야 하는 상황. 하지만 게이트 번호는 아는데 가는 방법을 찾아봐도 외국어만 나오는 경우 같았다.
예를 들어 기획자는 개발자가 소스를 제공하는 API나 특정 자료의 수식을 '구하는' 시간까지 충분히 고려해야 하는 걸 인지하지 못했다. 개발자는 기획자가 줄 자료를 기다리면서 이전 버전의 버그나 오류를 조용히 수정하고 있다 보니 우선순위의 의미가 사라졌다. 만일 기획과 개발 사이, 디자인과 개발 사이에 충분히 우려되는 점이나 서로 영향을 끼칠 작업이 무엇인지 이해하고 있었다면 스프린트는 지킬 수 있었을 것이다.
우리에게 필요한 것은 무엇이었을까. 첫째로 예정된 테스크에 쏟아부을 시간을 가정하되, 해야 할 일들을 쪼갤 수 있을 때까지 쪼개는 능력을 갖고 있어야 했다. 예를 들어 개발자나 기획자는 특정 기능의 코드를 짜기 전부터 배포하기 전까지 일을 어떻게 쪼개어 분류할 것인지 고민하고, 쪼개진 일을 해결하기 위해 서로에게 필요한 정보가 무엇인지 모아서 요구하며, 이해할 수 있는 언어로 전달하는 것이다.
가장 중요한 건 소통하는 것. 만일 멤버 각자가 그럴만한 역량을 갖추지 못했다면 팀이 어떻게 일하는지 파악하는 롤이 필요하다. 이런 기능을 만듭시다, 하고 자 이제 시작이야! 가 아니라, 잠깐만요! 할 줄 아는 사람.
방법론에 휘둘리지 않으려면 (1)
1. 멀리 내다볼 줄 아는 PM과 동료
대개 프로젝트의 관리를 위해 PM을 채용하기도 하는데, 이 포지션에는 경력자가 뽑히는 게 옳다. 커뮤니케이션 능력을 기반으로 회사의 사이클과 각 팀의 퍼포먼스를 동시에 이해하고, 알맞게 업무를 분담해내는 능력이 생기려면 최소 5년은 필요하리라 생각하기 때문이다. 하지만 어느 정도 성장한 스타트업이 아니라면 노련한 PM을 채용하기란 쉽지 않다. 때문에 사업 초기에는 CEO가 PM을 맡거나 기획자가 겸임하기도 하는데, 이들이 본래의 포지션에 대한 skill은 꽤 쌓였을지 몰라도 Project Managing은 처음이라는 점을 스스로와 팀원 모두 인지해야 한다.
좋은 PM은 일정 관리부터 QA까지, 전 영역에 걸쳐 각 멤버의 업무 강도의 텐션을 골고루 나누는 섬세함을 갖고 있다. 프로젝트를 조감도로 멀리 내다볼 줄 아는 능력을 가진 것이다. 하지만 그렇지 못한 매니징은 미시적인 시야로 인해 기획, 디자인, 개발 간 소통을 저해하고 더 나아가 신뢰를 떨어뜨릴 수도 있다. 따라서 팀원은 처음 PM이 되었거나, 초면인 PM과 처음 합을 맞춰갈 때엔 차근차근히 능력을 펼칠 수 있도록 push 해주고, 서로의 영역을 필사적으로 이해시키며, 갑작스레 닥칠 수 있는 모종의 상황에 유연하게 대처할 수 있어야 한다.
* PM이란?
PM과 기획자는 운영 관계자(C level)와의 협의를 통해 설계문서를 만들어내고, 필요한 내용들을 녹여내어 디자이너와 개발자가 일하게 되는 바탕을 만드는 역할을 합니다. 출시까지의 일정을 관리하거나 QA를 진행하기도 합니다.
지금은 단순한 해프닝처럼 느껴지지만, 언젠가 PM에게서 "배경 색은 지금보다 더 진한 게 좋을 거 같지 않나요? 조금만 더 진하게 만들어주세요."라는 피드백을 들은 적 있었다. 이에 '피드백 주신 배경 컬러는 디자인 라이브러리의 세 번째 Scale에 해당하는 컬러이고, 배경에만 쓰이는 색이 아니다. 또한 각 Gray Scale은 구글의 메테리얼 디자인 (Material Design)에서 소개되는 대비 기준에 (4.5:1, AA) 맞게 제작되어 다른 색상들과 유기적으로 연결되어 있기 때문에 당장 하나만 수정하기는 어렵다는 뜻을 전했다. 구구절절... 하지만 돌아오는 대답은 다소 당황스러웠다.
"프로덕트 디자이너가 구글이 시키는 대로 하는 건가요? (중략) 그럼 제가 디자인에 대해서 피드백하는 건 전혀 적용하지 않겠다는 말 아니에요?"
제가 언제 그렇게 말했죠?당시는 PM의 역할을 맡은 기획자가 아직 매니징에 익숙하지 않고 스프린트를 온전히 혼자서 관리할 역량이 부족하던 시절이었다. 아마 구글 메테리얼 디자인이 뭔지 잘 몰랐을 수도 있다. 처음이라 그런 것이겠거니 되뇌며, '배경색으로 지정된 색의 탄생 배경을 설명하고, 이를 차치하고서라도 수정해야만 하는 당신의 이유가 충분하지 않으며 우리가 서로 주고받을 피드백은 이런 micro 한 게 아님'을 설명했다. 약 한 시간 여의 핑퐁이 끝나고, PM은 아마도 조금은 이해했다는 눈치로 자리로 돌아갔다.
이 불필요한 논쟁 시간을 없애기 위해서, PM과 나는 상상 속 기린 같은 Good Managing이 현업에 녹아들려면 어떻게 해야 하는지 더욱 공부했다. 시간이 흘러, PM은 아래와 같이 애자일 시스템을 정밀하게 조정하여 팀에게 맞는 형태를 제안했고, 본인은 더 이상 회의가 아닌 시간에 특정 요소에 대한 논쟁이 일어나지 않도록 전사 회의를 진행했다. 대신 전사 회의를 제외하고, 기획이나 추가 회의 등 절대적인 회의의 양이 많아지는 것을 대비해 각 안건당 최대 15분이 넘지 않도록 조정하였다. 15분이 지나면 인사하고 자리로 돌아가면 된다.
1. 전사 회의를 통한 팀 공동 목표 설정 (최대 8주)
2. 공동 목표를 위해 만들어가야 할 기능 리스트 제작
3. 기능 리스트 별 우선순위 제작
4. 기능을 제작하기 위해 해야 할 일을 모아두는 백로그 관리
5. 우선순위와 각 멤버별 역량에 맞춘 백로그 분배
6. 스프린트 진행
7. 회고를 통한 스프린트 일정 조율 및 목표 조정
* 특정 백로그에 관한 논의점이 발생할 경우 회의로 잡고, 각 안건당 15분을 넘지 않을 것.
* 우선순위 부여의 책임과 권리는 PM에게만 부여
위의 해프닝처럼 처음에는 비틀거렸지만 시간이 지날수록 팀의 커뮤니케이션과 서비스 개발 진척이 점점 안정적인 흐름을 갖게 된 것 같다. 완벽한 애자일은 없다. 팀에게 맞는 핏이 되기까지 PM은 비즈니스뿐만 아니라 스프린트와 업무 환경의 Flywheel을 누구보다도 잘 이해해야 한다. 그리고 PM 뿐만 아니라 모두가 함께 수정하고 공유하면서 만들어 나가는 환경임을 알아야 한다. 결국 애자일하게 잘 구르기 위해서는, 커뮤니케이션 능력과 사업/업무 프로세스의 전반을 거시적인 관점으로 볼 줄 아는 섬세함을 가진 PM과 애자일 도입 기간 동안 함께 힘써줄, 서로 신뢰하는 동료와의 팀워크가 필요하다.
방법론에 휘둘리지 않으려면 (2)
2. 시간을 Atomic 하게 측정하고 과한 욕심내지 않기.
우리 팀의 경우 1주일간 디자이너 한 명, 개발자 세 명이 해치울 수 있는 총 Story Estimate Point는(일을 해내기까지 걸리는 시간) 50포인트, 즉 50시간 정도였다. 하지만 50시간짜리 일들을 해치우려고 보니, 50시간은 사실 70~80시간짜리였다.(두둥)
위에서 언급한 함께 만들어낸 시스템과는 별개로 업무량을 적절하게 매기지 못한 것이다. 갑작스럽게 목표치가 높게 바뀐다 해서 슈퍼파워가 솟아나 쌓인 테스크를 해치울 수는 없는 법이다. 워라밸이 붕괴된다는 말을 하려는 것이 아니라, 놓치는 이슈가 발생했고, 앞으로도 발생하게 될 거란 얘기이다. 알고 보니 보스몹이었다, 하는 이슈는 누적되어 더 많은 백로그를 생성하고 스프린트에 소요되는 포인트를 증가하는 악순환의 고리를 만든다.
버그나 미싱 이슈는 디자인과 개발의 완성도의 기준이 높아서 생기는 허들이 아니다. 오히려 완성과 거리가 먼 불량을 생산해내니 A/S로 들어오는 건이 많아지는 경우라고 할 수 있다. 촉박한 시간에 맞춰 시각화하길 반복하니 디자인 시스템을 무시하는 각 컴포넌츠를 만들어버리는 식이다. 안 그래도 바쁜 개발자를 붙잡고 프론트 코드를 다시 수정하게 만들 때마다 죄책감으로 가시방석에 앉은 것 같았다.
때문에 대개 월간 계획을 세울 때, 각 주마다 새로운 기능이 탄생한다고 하자. 그렇다면 새로운 기능이 탄생하기까지 필요한 정확한 시간을 측정해야 하며, 기준이 되는 시간을 크게 초과하지 않도록 해야 한다. 아무리 좋은 시스템 속에서 화목하게 일한다 한들, 감당해낼 수 없는 백로그와 투두 리스트는 또 다른 압박감을 낳는다.
어어어 다 흘린다로그인? 10시간이면 쌉 충분하지. 가 아니라, 로그인 API를 제공하는 기업을 탐색하는 시간, 네아로(네이버로 로그인)이나 페이스북 Api를 끌어오는 데 걸리는 시간, 프론트 코드를 작성하는 데 걸리는 시간, 수집한 유저 데이터를 모아 둘 백엔드 코드를 작성하는 데 걸리는 시간으로 쪼개서 테스크로 관리해야 하는 것이다. 디자인도 마찬가지다. 어중간하게 측정한 시간대에, 만일 위에서 언급한 자잘한 회의들이나 사업 제반을 위한 다른 업무가 끼어들게 된다면, 스프린트의 성공은 그만큼 멀어진다.
또한 프로덕트가 생산되어야 하는 데드라인을 맞추는 것도 중요하지만, 얼마 되지 않는 인력을 쥐어 짜내 기한을 맞출 수 있다는 기대를 하지 않는 것이 중요하다. 대부분 KPI는 불가능해 보일 만큼 높이 잡는 것이 좋다고 한다. 하지만 현실적으로 불가능한 목표인지 점검하는 객관적 성찰도 필요하다. '적은' 인력을 '과하게' 쥐어 짜내야 한다면 목표가 지나치게 높은 것이니 스토리의 규모를 줄이거나, 인력을 추가 채용하는 것이 좋을 것이다. 처음 한, 두 달은 하드한 일정에 맞추는 데에 성공할 수 있겠지만 계속되는 야근과 초과 업무로 인해 A/S가 필요한 불량품이 많아지게 된다면 조삼모사나 다름없다. 추가 인력 고용 없이 이루기 어려울 것 같은 목표를 설정하고 달리기로 했다면, 적어도 회사는 팀이 도전할 수 있을 만큼 많은 도움을 줘야 할 것이다. 성과급 말이다. 바탕 없이 이루어지는 쾌거는 없다.
결론
애자일은 속력이 아니라 팀워크
시장에 내놓고 피드백을 받는 것, 즉 만들고 부수는 주기가 굉장히 빠른 프로덕트 생산 방식을 따르기 때문에, 얼마든지 부서져도 서로를 신뢰할 수 있는 배경에서 도입해야 하는 것이 애자일이다. 무조건적인 답습으로 스크럼, 스프린트 회고를 진행한다고 해서 업무 능률이 비약적으로 상승하는 것이 아니기 때문에, 어떠한 환상을 갖고 도입하지 않기를 바란다.
또, 워터폴과 비교하여 많은 법칙이 생겨났지만, '우리 팀'의 애자일을 결정하는 것은 우리이다. 애자일 굴에 빠졌더라도, 방법론에 잡아먹히지 않고 '툴'로서 잘 이용할 수 있길.
