본문으로 건너뛰기

너희는 지금 전혀 '애자일'하고 있지 않아

· 약 11분
Sewon Kim
Front End Engineer @ Neurocle

이전 글 어느 날, 회사에서 서비스 개발을 멈추기로 했다.에서는 회사에서 2개월 간 서비스 개발을 멈추고, 개발 프로세스 개선하는 TF에 참여하면서 느낀 점을 정리했습니다.

애자일 프로세스를 적용한 지 6개월이 지났습니다

6개월의 시간 동안, 1번의 마이너 업데이트와 2번의 핫픽스를 진행했습니다. 이번 글에서는 조직에서 애자일 프로세스를 적용한 방법, 겪었던 시행착오, 개선된 점 등을 기록 해보려고 합니다.

애자일 하다는 착각

애자일이 뭐야...

애자일이 뭐야...

회사 채용페이지의 개발 문화 페이지는 제가 작성했는데요. 작성할 때만해도 저는 저희 조직이 애자일하게 개발하고 있다고 생각했습니다. 그런데 기획을 수정하는 게 왜 이렇게 힘든 걸까요? 왜 개발자들이 릴리즈 날에 밤새면서 버그를 고치는 걸까요? 애자일한 조직은 이러지 않아야 하는 것 아닐까요? 애자일은 무엇일까요?


AS-IS

예를 들어 메이저 업데이트를 6개월 간 개발한다고 가정해 보겠습니다. 기존에는 스프린트 1개의 기간을 1개월로 잡아서 총 6개의 스프린트를 진행했습니다. 개발 스프린트 5개와 QA 스프린트 1개로 구성되어 있었어요.

프로젝트 초기(스프린트 1~2)

초반 1~2개월은 버전에 들어갈 메인 피쳐를 선정하는 데 소비합니다. 우선순위와 대략적인 마감 날짜를 정하기 위해 VoC, 피쳐 목록들을 쭉 보면서 기획이 없는 항목에 대해서도 주 단위로 공수를 산정해야 했습니다. 기획이 없다보니 각 팀이 생각하는 기능이 동상이몽입니다.

그리고 이 기간동안에는 당장 진행할 수 있는 피쳐가 없으니 기획/디자인이 완성되길 기다리면서 리팩토링도 하고, 기술 탐색도 해보고, 비교적 여유 있는 시간을 보냅니다.

문제점
  1. 기획자도 모르는 피쳐에 대한 공수 산정
  2. 기획이 없어서 프로젝트 초반의 시간을 허비

프로젝트 중기(스프린트 3~4)

이때쯤에는 메인 피쳐에 대한 기획이 어느정도 진행되어 있습니다. 하지만 피쳐의 크기가 워낙 커서 스프린트 4가 끝날 때까지도 디자인이 완성되지 않았거나, 기술적인 한계 때문에 기획이 변경되는 경우가 많습니다. 개발을 진행하면서 기획이 빈번하게 변경되면서 하나의 피쳐를 2~3개월에 걸쳐 개발하기도 합니다. 스프린트를 끝내고 PM이 진행도를 체크하려고 보면 '메이져 업데이트에서 우선순위가 높은 기능들을 열심히 개발중'이라고 밖에 말할 수 없습니다.

문제점
  1. 피쳐의 크기가 너무 커서 놓치는 기획도 많고, 변경이 빈번함
  2. PM이 프로젝트의 진행도를 체크하기 어려움

프로젝트 말기(스프린트 5, QA 스프린트)

스프린트 5에서는 큰 피쳐는 어느정도 끝내고, 작은 피쳐들을 개발하기 시작합니다. 그런데 작은 피쳐라고 생각했던 것들도 한달 안에 끝내기에는 쉽지 않아 보이는 것들이 많습니다.

한편, 큰 피쳐들에 대한 QA가 진행되면서 버그가 계속 쌓입니다. 프로젝트 중기에 미뤄둔 작은 피쳐 개발을 진행하느라 버그 픽스는 QA 스프린트로 미뤄둡니다. 최악의 상황에는 피쳐 개발을 끝내지 못해서 QA 스프린트에서도 피쳐 개발을 진행합니다.

문제점
  1. 남은 피쳐의 크기도 작지 않음
  2. 버그 픽스할 시간이 없음
  3. QA 스프린트에서도 개발 진행
  4. a.k.a 지옥의 행군

애자일 하기 위해 도입한 2가지

진짜 '애자일'한 프로세스를 위해 크게 2가지를 도입했습니다.

1. 스프린트 기간을 2주로 줄임

1개월 단위로 진행했던 스프린트 기간을 2주로 줄이고, 스프린트 전후로 킥오프와 회고를 진행했습니다. 이렇게 되면 6개월의 개발 기간 동안 12개의 스프린트를 진행하게 됩니다. 스프린트 회고를 더 자주 하게 되면서 문제점을 비교적 초기에 발견하고, 대처할 수 있었습니다. 스프린트 기간이 짧아지면서 개발의 속도감도 높아졌습니다.

2. 스토리 포인트 도입

스프린트 킥오프에서는 스프린트에서 진행할 스토리를 산정했습니다. 각 스토리마다 스토리 포인트를 부여하여 스프린트 목표를 수치화 할 수 있었어요.

스프린트 회고에서는 완료된 스토리 포인트를 계산하고, 평균 속도를 측정했습니다. 팀의 개발 속도를 PM의 경험적 의견이 아닌 정량적인 수치로 파악할 수 있었어요. 남은 기간동안 우리가 목표했던 것들을 전부 개발할 수 있는지 없는지, 개발할 수 없다면 얼만큼의 시간이 더 필요한지에 대한 판단 근거가 되어주었습니다.


새로운 업무 프로세스

결과적으로 이런 사이클을 계속 반복하게 되었어요! 업무 프로세스를 변경한다고 했을 때, 너무 복잡해져서 적응하지 못하는 것 아닌지에 대한 걱정이 많았는데 사실 핵심은 이 2가지였고, 나머지는 저희가 늘 해왔던 일들이라 실제로 수행하는 데 어려움은 적었습니다.


효과는 굉장했다!

실제로 적용 중인 스토리 & 스토리 포인트 캡쳐

실제로 적용 중인 스토리 & 스토리 포인트 캡쳐

우선 모든 피쳐에 대해서 이렇게 스토리와 스토리 포인트를 부여하니 피쳐의 크기를 대략적으로 파악할 수 있었습니다.

유저의 입장을 기준으로 스토리를 지정하여 QA 포인트도 좀 더 정확하게 잡아낼 수 있었어요. OO 기능에 대한 QA 보다는 OO 버튼을 누르면 OO 화면으로 이동하는 기능에 대한 QA 가 훨씬 구체적이고, 놓치기 어렵거든요. 이런식으로 스토리를 구체적으로 뽑아낼 수 없는 기획은 더 잘게 쪼개게 되면서 MVP를 더 빨리 도출할 수 있었습니다. 중요한 기능을 먼저 개발하고, 나머지는 시간이 남을 때 개발하는 방식으로 진행할 수 있었습니다.

PM의 후기

얼마 전 PM분께 애자일 프로세스 도입 후기에 대해 여쭤봤는데 이전에는 스프린트 2~3개에 걸쳐서 '진행중'이던 피쳐가 스토리로 작게 쪼개진 덕분에 관리 리소스가 크게 줄었고, 명확해졌다고 말씀해주셨습니다. 그럼에도 불구하고 스토리를 만드는 것은 각 팀마다 이해도 차이가 있어서 아직은 조금 더 연습이 필요한 것 같다고 하셨어요.


혼자서는 바꿀 수 없는 것

애자일 프로세스를 도입하면서 가장 크게 느낀 점은 '혼자서는 바꿀 수 없다'는 것이었습니다. 나만 스토리를 잘 뽑고, 나만 스토리 포인트를 잘 산정하고, 나만 스프린트 목표를 이룬다고 해서 조직이 애자일해지는 것은 아닙니다. 팀원 모두의 이해도를 올리는 것이 중요했고, 이를 위해서 많은 노력이 필요했습니다.

태어나서 처음으로 업무 워크샵을 기획하고 진행해보았습니다

태어나서 처음으로 업무 워크샵을 기획하고 진행해보았습니다

애자일 워크샵을 진행해서 스토리를 어떻게 만들어야 하는지, 스토리 포인트는 어떻게 산정해야 하는지에 대해 설명하고 실습을 통해 익히는 시간을 가졌습니다. 그 과정에서 각자의 이해 수준을 맞추고, 각 팀이 느끼는 어려운 점을 함께 공유할 수 있었어요.

이 워크샵을 진행하기 위한 자료를 2개월 동안 정말 치열하게 연구하고, 토론해서 만들어 냈는데 이 과정이 팀을 더 단단하게 만들어 주기도 했습니다.

가장 중요한 건 팀원 모두가 이 모든 프로세스를 그저 생각없이 따르거나, 최대한 덜 일하려고 이용하는 것이 아니라 더 나은 제품을 만들기 위한 과정, 완성도를 높이기 위한 시간을 확보하는 수단으로 생각해야 한다는 것입니다. 그렇지 않다면 큰 의미가 없고, 워터폴 방식으로 하는 것이 나쁜 방식이 아니라고 생각하거든요. 애자일을 알면 알수록 이 방법이 만병통치약이 아니고 각 팀의 성격, 규모, 상황마다 적절한 프로세스가 있는 것 같습니다.


남은 과제

릴리즈가 큰 일이 되지 않기를...

사실 처음 이 프로세스를 도입한 마이너 버전 릴리즈 날도 새벽에 퇴근하긴 했습니다. 노력했지만 한 번에 모든 문제를 해결할 수는 없더라고요.

<애자일 개발이 처음인 내가 출근했더니 스크럼 마스터가 된 건에 관하여> 중에서...

<애자일 개발이 처음인 내가 출근했더니 스크럼 마스터가 된 건에 관하여> 중에서...

책의 한 페이지가 너무 와닿아서 찍어두었습니다. (책에 실제로 겪을 법한 상황들이 많이 묘사되어있어서 재미있었어요. 추천!) 애자일을 처음 도입한 팀의 이야기인데 이 팀도 결국 릴리즈 당일에는 새벽 2시까지 일하더군요...ㅎㅎ

애자일의 진정한 의미는 '카이젠(개선)'에 있으니까! 다음 릴리즈에는 더 나은 방향으로 개선 되기를 바라고 있습니다.


기획, 디자인은 언제...?

책에서도 나오지 않는 건 기획과 디자인입니다. 기획이 완료되지 않아서 개발이 늦어지는 상황은 지금도 여전히 해결되지 않은 문제입니다. 가장 좋은 시나리오는 다음 버전의 기획이 미리 완료되어있는 건데 현재 리소스로는 불가능에 가까운 일이네요. 기획자, 디자이너가 많은 조직은 이런 문제가 없을까요? 궁금합니다.

일단 와이어프레임으로 MVP 개발과 검증을 진행하면서 완성도를 올리는 방식을 지향하고 있지만, 모든 피쳐의 성격이 MVP 기획이 가능한 형태는 아니라서 현실과 타협할 수밖에 없는 상황입니다. 책이나 컨퍼런스에 참가할 기회가 있다면 이런 문제들에 대한 해결책들을 찾아보고 싶어요.


중요한 것은 꺾이지 않는 마음

처음 개선된 프로세스를 소개할 때, 사내 발표에서 썼던 장표 중 하나입니다.

expectation

이런 것들을 기대했는데 완벽하진 않지만 어느정도 변화를 이끌어 낸 것 같아서 굉장히 뿌듯하네요. 가장 긍정적으로 생각되는 건 일하고 싶은 환경을 스스로 만들어 갈 수 있다는 희망이 생겼다는 것입니다. 이 글을 읽고 계신 분들은 애자일 하고 계시는지, 어떤 방식으로 일하고 싶은 환경을 가꾸고 계신지 궁금하네요!

긴 글 읽어주셔서 감사합니다!🙏