오늘은 개발자 면접을 볼 때 면접자 분들께서 늘 물어보시는 질문인 ‘드라마앤컴퍼니의 개발 그룹은 어떻게 일을 하나요’에 대한 첫 번째 글을 적어볼까 합니다. ‘어떻게 일을 하는지’는 굉장히 광범위한 질문이기 때문에 이번 글에서는 저희의 방법론과 계획 등에 대하여 얘기해보겠습니다.
업무의 방법론이란 굉장히 중요합니다. 무작정 열심히 한다고 해서는 절대로 장기적으로 일을 효율적으로 해낼 수 없습니다. 특히 사람이 많아지면 많아질수록 모두가 제일 효율적이라고 생각하는 업무 방식을 찾아야 합니다. 드라마앤컴퍼니의 개발 그룹도 무작정 열심히만 했다가 일을 제대로 할 수 없다는 것을 실제로 겪고 깨달았습니다. 분명히 모두가 열심히 일하고 있었으나 커뮤니케이션에 문제가 있었으며, 계획했던 일들을 연달아 끝내지 못하고 계속 미루게 되는 상황이 발생했습니다. 이런 일의 재발을 막고 모두가 최고의 효율로 일을 할 수 있도록 모든 일을 멈추고 업무 방식을 찾기 위해 오랜 시간 동안 다 같이 논의하며 고민했으며 지금도 끊임없이 고민하고 있습니다. 지금부터 설명드릴 방법은 저희가 긴 고민을 한 끝에 만들어진 현재 버전의 답안입니다.
Agile
개발 그룹의 업무 환경은 애자일 방법론에 기반을 두고 있습니다. 애자일 방법론 중 스크럼을 중심으로 업무를 처리합니다. 큰 flow는 다음 그림과 비슷합니다. 제품(혹은 프로젝트)에 대한 모든 task들이 담겨있는 프로덕트 백로그가 존재하며, 이번 스프린트에 진행할 task들을 스프린트 백로그에 옮깁니다. 그 후에는 하루와 총 스크럼 기간 두 단위로 나누어 일을 진행합니다. 저희가 실제로 어떻게 사용하는지에 대한 자세한 내용은 뒤에서 다루겠습니다. 혹시 Agile 방법론이나 스크럼 등의 용어가 생소하신 분이라면 위키피디아에서 가볍게 읽어보고 오시는 것을 추천해 드립니다.
Planning
개발 그룹의 업무 계획 단위는 Yearly Planning, Phase, Phase break, Sprint로, 총 세 가지로 나누어 볼 수 있습니다. Yearly planning은 장기 계획, Phase는 중기 계획, Sprint는 단기 계획를 나타냅니다. 이렇게 장기, 중기, 단기로 나누어 계획을 짜는 이유는 다양한 시점에서 우리가 올바른 방향과 속도로 나아가고 있는지 계속 인지하기 위함입니다. 또한 상황에 따라 적절하고 lean하게 계획을 조율하여 리소스를 효율적으로 사용하며 목표에 다다를 성공률을 높히기 위함입니다. 다음은 Sprint, Phase, Phase break 등의 모든 업무 단위들을 포함하여 하나의 그림으로 나타낸 표입니다. 다음 표가 전체 사이클이며 다음과 같은 사이클을 반복합니다.
Sprint
하나의 스프린트는 2주 동안 진행됩니다. 스프린트를 시작하기 전에 우선 프로덕트 백로그에 있는 task들의 우선순위를 PM님과 담당 개발자분이 상의하여 정리합니다. 그 후에는 담당 엔지니어분께서 각 task 별 예상 일정을 산정합니다. 스프린트를 시작하기 전주 금요일의 스프린트 플래닝 회의에서 미리 산정해놓은 task들의 우선순위와 예상 일정을 참고하여 이번 스프린트 시간동안 하게 될 업무의 목록을 정하고 스프린트 백로그에 올려놓습니다. 이렇게 스프린트 백로그이 올라간 task들은 세 가지 상태(todo/doing/done)로 나뉘어 스크럼 보드에서 관리됩니다.
매일 아침 출근시간인 10시에 개발 그룹, PM, QA 분들이 모두 모여서 약 15분 동안 데일리 스크럼 회의를 진행합니다. 이때는 각 엔지니어 분들이 차례대로 ‘어제 한 일’, ‘오늘 할 일’, ‘이슈/장애물’ 이 세가지를 간단히 요약하여 얘기합니다. 또한 다른 파트나 엔지니어 분들과 의논 해야 할 사항들을 의논하기도 합니다. 이렇게 각자 진행상황과 문제점 등을 공유하고 동기화하는 시간을 갖습니다. 스프린트가 끝나는 주의 금요일에는 이번에 진행한 스프린트에 대해 피드백을 하는 스프린트 리뷰 회의를 갖습니다. 이때 이번 스프린트에 대한 리뷰를 하고 어떤 점들을 어떻게 개선해야 하는지 논의하고 다음 스프린트 때 반영합니다.
데일리 스크럼 회의의 가장 큰 의미는 모두가 모여서 동기화 할 시간을 갖게 해준다는 것 입니다. 개발 그룹에는 각 안드로이드, iOS, 웹 플랫폼당 한 분, API는 두 분, DB는 한 분께서 담당하고 있는데, 이렇게 동기화할 시간이 없을 땐 전체가 아닌 일부 사람들끼리만 내용을 논의하게 되고 논의된 내용이 전체적으로 공유되지 않아 커뮤니케이션의 문제가 발생했었습니다. 하지만 데일리 스크럼 회의때는 엔지니어 분들 외에도 PM, 기획자, QA분들까지 모두 모여 계시니 미스 커뮤니케이션의 문제를 많이 해소할 수 있었습니다.
Phase
하나의 페이즈는 스프린트가 4개 모여 총 8주의 기간 동안 진행됩니다. 페이즈는 스프린트와 같이 상세한 계획을 짜기 보다는 중기적인 계획으로 우리가 나아갈 방향과 속도를 인지하기 위한 목표가 큽니다. 이번 기간 동안 우리가 이루고자 하는 것이 무엇인지 (예: 안정성 향상, 리텐션 상승 등) 컨셉을 잡고 진행하기도 합니다. 페이즈를 시작하기 전에 페이즈 플래닝 회의에서는 중기적인 플랜을 짜기 위해 개발 그룹에서 진행해야할 전체 task들이 담겨있는 프로덕트 백로그에서 우선순위와 매우 러프한 예상 일정을 산정하고 이번 페이즈 기간에 진행할 항목들을 페이즈 백로그로 가지고 와서 페이즈 보드를 작성합니다.
4번의 스프린트로 페이즈가 끝나게 되면 페이즈 리뷰 미팅을 하며 ‘원래 계획했던 일들’, ‘실제 완료한 일들’, ‘좋았다고 느낀점’, ‘아쉬웠던 점/개선해야 할 점’ 등에 대한 피드백을 모아서 더 나은 프로세스를 논의하여 정한 후 다음 페이즈에 반영합니다.
매 Phase가 끝날 때 마다 개발 그룹은 회식을 하는데 이때 회식을 하게 될 장소를 Phase 이름으로 사용하고 있습니다. Phase 1의 이름은 ‘마장’으로 마장동 우시장에 갔으며 Phase 2의 이름은 ‘정선’으로 phase가 끝난 후 워크샵 겸 정선의 하이원 리조트를 갔습니다. Phase 3은 ‘양재’로 양재 느린마을 막걸리집을 갔습니다.
Phase Break
페이즈 브레이크 기간에는 정말 급한 업무 외에는 회사의 비즈니스에 필요한 개발을 멈추고 재정비를 하게 됩니다. 이 기간에는 기술 공유 세션, 기술 블로그 글 작성, 해커톤, 리서치, 네트워킹 등 개발자의 성장에 도움이 되는 일들을 진행하게 됩니다. 이 기간은 페이즈 기간 동안 열심히 달려 왔으니, 다음 페이즈에서 도약을 하기 위한 재정비 시간을 갖는 것을 목적으로 하고 있습니다.
사실 8주의 페이즈 후에 2주 동안 페이즈 기간을 갖는 것은, 회사 입장에서 보면 전체의 1/5이라는 시간을 회사 비즈니스에 직접적이지 않은 일에 쓰는 것 이므로 매우 비효율적이고 충격적으로 보일수도 있습니다. 하지만 실제 3회정도 진행해본 결과 페이즈를 도입하기 하기 이전의 개발 속도와 별 차이가 없었으며 오히려 마음 놓고 당장 업무에 직결되지 않은 분야들을 열심히 공부 해볼 수 있어서 개개인의 개발 능력 성장과 장기적인 개발 속도에 매우 큰 도움이 되었습니다. 사실 생각해보면 저희가 페이즈 브레이크 기간동안 하는 일들은 많은 엔지니어분들이 하고 있고 매우 중요한 일들 입니다. 하지만 보통은 비즈니스 일정에 치여 낮은 우선순위로 미뤄지거나 틈틈이 하게 되는데, 그럴 경우 100% 몰입하여 할 수 없기 때문에 결과적으로는 시간도 오래 걸리고 제대로 끝내기 힘듭니다. 하지만 이렇게 다른 업무에 걱정 할 필요없는 시간이 주어질 경우 오히려 더 효율적으로 끝낼 수 있습니다.
그리고 페이즈 기간 동안 정말 열심히 일을 하다가 적절한 시기에 break time을 가질 수 있으니 burnout을 막는데 매우 큰 역할을 하고 있습니다. 내부에서는 이 페이즈 브레이크 기간을 신의 한수라고 평가하고 있습니다.
마무리
지금 진행하고 있는 이 방식이 버그나 개선사항이 없는 마지막 버전이라고 생각하지 않습니다. 그렇기 때문에 어쩌면 너무 많아 보일 수도 있는 review와 planning 회의를 하는 것입니다. 절대로 단번에 완벽한 계획을 할 수 없기 때문에 오랜 시간동안 고민만 하고 있기 보다는 끊임없이 시도하고, 그로 얻은 피드백과 교훈을 바로 다시 적용하여 개선해나가는 lean 정신을 가지고 이행하고 있습니다. 첫 sprint와 phase에 비하여 계속 발전하고 점점 자리를 잡아가는 것을 보면 이 방법이 옳았으며, 앞으로도 더 발전해나갈 수 있다는 믿음이 생깁니다.
이상으로 드라마앤컴퍼니의 개발 그룹이 어떤 방식으로 계획하고 업무를 진행하는지 살펴보았습니다. 다음 편에서는 개발 그룹의 DevOps나 개발 그룹이 PM, 기획자, QA 그리고 대표님과 어떤 방식으로 일을 하는지 등에 대한 주제를 가지고 얘기해보도록 하겠습니다.