내 마음속 폭풍은 아직 아무것도 삼키지 못했다.

박지강 jkwave@gmail.com｜개발 및 번역 프리랜서로 활동하다 최근 SK 커뮤니케이션즈로 자리를 옮겼다. 역서로는 ‘프로젝트 데드라인(한빛미디어)’이 있으며, 최근 ‘당신은 웹2.0 개발자입니까?(한빛미디어)’를 집필하였다. 기술을 이용한 기획과 전략, 열린 전략적 제휴, 일인 기업에 관심이 많으며, 현재 목표는 스스로 기획하고 개발하고 디자인한 서비스를 대중들에게 공개하는 것이다.

스크럼이란?

스크럼은 프로젝트 관리를 위한 애자일 소프트웨어 개발 방법론이다. 스크럼은 1986년 하바드 비지니스 리뷰(Harvard Business Review)에서 타케우치(Takeuchi)와 노나카(Nonaka)의 "신제품 개발 게임(The New New Product Development Game"이라는 주제의 글로 처음 거론되었다. 그들은 작은 규모의 협업팀(Cross-Functional Team)들로 구성된 프로젝트를 수행하여 기록적인 성과를 올린 경험을 기록하여 많은 관심을 불러 일으켰다.

그들은 그때의 팀 구성이 마치 럭비의 스크럼과 같다고 했다. 스크럼은 럭비 게임 중 사소한 반칙이 생겼을 때 공정하게 플레이를 재개하기 위해 공을 가운데 두고 각 팀의 선수들이 짜는 대형을 말한다. 이와 같은 룰은 애자일 방법론을 쉽게 잘 설명하고 있다. 애자일의 대표적인 특징 중 하나는 반복 개발이다. 즉 프로세스를 계속 반복하여 문제를 발견하고 다시 수정하는 작업을 되풀이 하면서 목표를 향해 전진하는 것이다. 스크럼도 반칙(문제)을 심판이 발견하고 팀 간의 부딪힘 속에 목표 지점을 항해 전진한다는 점에서 기막힌 비유가 아닐 수 없다.

스크럼의 아버지, 애자일

일단 스크럼은 애자일 개발 방법론의 한 분류라는 태생을 가지고 있기 때문에 애자일에 대한 이해가 먼저 선행되어야 한다. 애자일 방법론은 정해진 룰이 아니라 지향하고자 하는 가치에 가깝기 때문에 그 정의에 대해 다양한 해석이 나올 수 있다. 하지만 애자일 방법론을 주창하고 실천해온 전문가(XP의 Kent Beck과 같은)들이 모여 함께 작성한 “애자일 소프트웨어 개발 선언문(Manifesto for Agile Software Development / http://agilemanifesto.org )”을 보면 좀 더 가시적인 목표를 확인할 수 있다. 그 선언문을 정리하자면 다음과 같다.

위의 선언문은 기존의 가치도 중요하지만 그것에 집착하다가는 더 중요한 가치를 잊을 수 있다는 내용의 주장을 하고 있다. 프로세스와 도구는 개인들 간의 커뮤니케이션을 원활하게 하기 위해 사용되어야 한다. 많은 문서를 만들기 위해 시간을 소비해 소프트웨어의 완성도를 떨어트리고 있지는 않은가. 계약이 성사된 후에도 고객의 소리에 귀를 기울이는가. 프로젝트를 진행하다 보면 예상치 못한 문제나 변화가 생길 수 있다. 그때 마다 가치 있는 변화에 적절히 대응하지 않은 채 정해진 계획을 수행하는 것에만 집착할 것인가? 프로젝트의 성패는 안중에도 없이 말이다. 이와 같이 프로젝트 내내 좀 더 중요한 가치에 대해 함께 질문하고 답변하는 자세가 바로 애자일 방법론이다. 스크럼은 이와 같은 자세를 구체적인 프로세스를 통해 현실화하고 있다.

스크럼의 특징

스크럼은 반복적이고 점진적인 프로세스를 통해 제품을 개발하고 작업을 관리한다. 그리고 프로세스가 반복되는 마지막 시점마다 진행 작업을 정리하는 과정을 수행한다. 스크럼은 다음과 같은 특징을 가지고 있다.

♦  스크럼은 스프린트(Sprint)라고 불리는 30일간의 기간을 기반으로 진행된다.

♦  제품 책임자(Product Owner)는 제품 개발 계획의 변경 사항과 개발 가능한 기능들의 우선순위를 수집하여 정리한다.

♦  이와 같은 제품 책임자의 작업은 제품 백로그(Product Backlog)라고 불린다. 제품 백로그는 지속적으로 우선순위를 변경되는 작업 리스트이다.

♦  스프린트가 반복되어 실행될 때마다 제품 백로그에서 가장 높은 우선순위의 기능을 스프린트 백로그(Sprint Backlog)로 이동시킨다.

♦  스크럼 팀(Scrum Team)은 가능한 5명에서 9명 사이의 인원으로 구성한다. 스크럼 팀은 제품 책임자와의 회의를 통해 스프린트의 목표를 정하고, 우선순위가 정해진 기능을 좀 더 실행 가능한 작은 업무단위로 쪼갠다. 팀의 구성은 자체적으로 조직하며, 구성원들은 결과에 대한 공동의 책임을 지닌다.

♦  스크럼 팀은 스프린트 기간동안 스프린트 백로그에 정리된 작업 리스트를 수행한다.

♦  매일 열리는 일일 스크럼(Daily Scrum)에서 현재의 진행사항을 파악하고 처리한다.

♦  스크럼 마스터(Scrum Master)는 개발 팀을 지도하고, 프로세스를 수행하는데 방해되는 장애물을 제거한다. 그리고 팀이 스프린트를 계획한대로 잘 실행할 수 있도록 최선의 환경에 놓여져 있는지 지속적으로 확인한다.

♦  팀은 매 스프린트 마다 제품의 시장 가치를 증가시키고 새로운 기능과 개선 사항을 반영하는 작업을 한다.  

스크럼 구성원의 역할

스크럼에는 다양한 역할이 정의되어있으며, 그 역할들은 돼지와 닭이라는 두 그룹으로 나뉘어 진다. 돼지와 닭에 대한 비유는 다음과 같은 오래된 우화로부터 비롯된 것이다.  

 햄은 돼지가 자기 살을 내어 희생해야지 만들 수 있지만, 달걀은 닭이 단지 낳기만 하면 된다는 상황에서 비롯된 비유이다. 이처럼 돼지에 속한 그룹은 스크럼 속에서 제품을 개발하는데 모든 역량을 쏟는다. 그에 반해 닭에 속한 그룹은 프로젝트와 연관된 사람이지만 돼지처럼 스크럼 안에 투입되어 헌신적으로 일하지는 않는다. 그러므로 닭의 요구와 아이디어는 업무에 참조할 수 있지만, 스크럼 프로젝트의 전반적인 계획에 영향을 미쳐 돼지를 힘들게 해서는 안된다.

돼지

돼지는 스크럼 프로세스와 프로젝트에 투입되어 실질적인 업무를 수행하는 그룹이다.

1. 스크럼 팀(Scrum Team)

문제를 정의하고 해결하는 실질적인 업무를 수행하는 팀이다. 대략 5~9명으로 구성되며 이 인원은 스크럼과 같은 형태의 업무를 수행하기에 최적화된 숫자이다. 팀 구성원들은 업무를 정의하고 분배하는 작업을 스스로 진행한다. 프로젝트 내의 정해진 역할은 존재하지 않는다. 즉 모든 사람이 다른 사람과 수행 업무를 교환할 수 있다.  

2. 제품 책임자(Product Owner)

고객의 의견을 대변하고, 스크럼 팀이 비즈니스 관점에서 올바르게 업무를 수행할 수 있도록 도와준다. 제품 책임자는 제품 백로그를 관리한다. 제품 백로그는 제품에 담고자 하는 기능의 우선순위를 정리한 작업 리스트이다. 그와 관련된 문서는 조직 전체에 공개하여 모든 사람이 제품의 완성 과정을 알 수 있도록 한다. 제품 책임자의 역할은 주로 고객이 맡지만, 내부 조직 사람이 될 수도 있다. 이 임무를 맡은 사람은 엔지니어링과 마케팅, 비즈니스 프로세스 등 제품에 대한 전반적인 지식을 갖추고 있어야 한다.

3. 스크럼 마스터(Scrum Master)

스크럼 마스터는 지도자이자 중재자의 역할을 수행한다. 스크럼 마스터는 매일 열리는 일일 스크럼(Daily Scrum) 회의에 항상 참여하여 스크럼 팀을 관리한다. 그리고 프로젝트의 외부에서 팀과 논의해야할 중요한 이슈를 가지고 있는 경우, 그 사안들이 구성원들의 작업에 여파를 미치지 않도록 최대한 노력을 한다. 이처럼 스크럼 마스터는 팀이 현재 주어진 과제에 충실할 수 있도록 도움을 준다. 팀이 스프린트 기간동안 정해진 목표를 성취할 수 있도록 최선의 환경을 제공하는데 항상 초점이 맞추어야 한다. 스크럼 마스터는 스프린트의 실행이 종료될 때마다 스크럼 팀과 함께 그동안의 작업과 결과물을 평가하는 회의를 연다. 그리고 회의를 통해 팀의 프로젝트 이해도를 높이고, 작업에 대한 동기를 유발시켜 다음 스프린트에 대비한다.

닭

닭은 스크럼 프로세스에 직접적으로 투입되지는 않지만 간접적으로 의견을 제시하는 그룹이다. 애자일 방법론의 핵심은 프로젝트와 관련된 사용자와 비즈니스 그리고 그 밖의 이해관계자들과의 커뮤니케이션을 프로세스의 중요한 일부분으로 인정한다는 것이다. 그들과 함께 일하고, 그 피드백을 스프린트를 계획하고 검토하는 시점마다 프로젝트에 반영하는 것은 매우 중요하다.

1. 사용자

제품은 누군가를 위해 만들어지는 것이다. 사용되지 않을 제품을 왜 만들고 있는가? 그들의 의견은 말할 것도 없이 매우 중요하다.

2. 이해관계자

그들은 프로젝트를 만드는데 기여를 하지만, 프로세스에 직접적으로 관여하지는 않는다. 이해관계자는 CEO를 포함한다.

3. 컨설팅 전문가

스프린트마다 항상 필요한 것은 아니지만 필요한 시기에 전문적인 지식과 의견을 제시한다. 특정 시점의 스프린트에서는 닭에서 돼지로 변신해 스크럼 팀에 포함되기도 한다.

스크럼을 진행하는 동안 닭은 비즈니스에 관여하되 헌신하는 돼지를 방해하지 않는다. 돼지는 동업 관계인 닭을 이해하고 그들의 의견을 수렴한다. 싫건 좋건 돼지와 닭은 한 배를 탔다. 이와 같은 역할 모델은 스프린트 기간 동안 정해진 시간에 목표를 수행할 수 있도록 도와준다.

스크럼 프로세스

스크럼은 다음과 같은 핵심 단위 프로세스를 반복적으로 실행하여 제품의 완성도를 높인다.

백로그(Backlog) 만들기

제품 책임자는 제품의 스펙과 고객의 요구를 수집하여 정리한다. 프로젝트의 최종 목표가 정의된 후, 그 목표를 구체적인 단위로 세분화 시켜 비즈니스 가치를 반영하고 수행할 수 있는 기능 리스트로 변경한다. 그리고 기능들의 중요도를 평가하여 우선순위를 정한다. 우선순위 리스트는 시장적 가치와 고객의 요구를 바탕으로 정렬한다. 제품 책임자는 새로운 스프린트를 시작할 시기가 되면 백로그를 가지고 스크럼 팀과 회의를 열고, 스크럼 팀은 백로그를 작업 리스트 삼아 업무를 수행한다.

스프린트(Sprint)

스프린트는 스크럼의 핵심적인 개념으로 제품 백로그를 완수하기 위해 주기적으로 반복되는 2~4주의 기간이다. 스프린트를 시작하기 전에는 스프린트 계획 회의를 열어 제품 백로그 리스트에서 스프린트동안 수행할 작업을 선택한다. 그리고 그 작업이 선정되면 스프린트 백로그로 옮겨 정리한다. 스프린트 기간동안 성취해야할 목표도 정의한다. 이처럼 스프린트에 필요한 시간과 수행할 업무들이 모두 정의되면 스프린트를 시작한다. 스프린트가 일단 시작되면 스프린트 백로그는 가능한 수정하지 않으며 스크럼 팀은 스프린트를 완수할 책임을 지닌다. 만약 팀이 올바르게 구성되어있다면, 정의된 업무는 팀의 주도하에 구성원에게 알맞게 배분될 것이다. 스프린트가 종료되는 시점에는 스프린트 검토 회의를 열어 스프린트가 목표를 올바르게 달성했는지 평가한다.  

일일 스크럼(Daily Scrum)

스프린트 동안 스크럼 마스터와 스크럼 팀은 매일 15분간 간략한 회의를 연다. 회의의 목적은 업무를 수행하는데 방해가 되는 장애요인들을 제거하는 것 이다. 회의 참여자들은 다음의 세 가지 질문에 적절한 답변을 해야 한다.

♦  지난 회의 이후에 지금까지 무엇을 했는가?

♦  지금부터 다음 회의까지 무엇을 할 것인가?

♦  업무를 수행하는데 있어서 방해가 되는 것들은 무엇인가?

처음 두 질문에 대한 답변은 프로젝트가 얼마나 진행되고 있는지 판단하는데 중요한 정보를 제공한다. 세번째 질문은 컴퓨터 마우스 고장에서부터 회사의 조직 개편까지 다양한 문제를 해결하는 실마리를 제공한다.

 위의 그림처럼 스크럼은 스프린트라는 한 달 가량의 기간을 반복하며 핵심 프로세스를 실행한다. 그리고 반복적인 작업을 통해 제품의 완성도를 높인다. 굳이 애자일 방법론이라는 다소 거창한 이름을 들먹거리지 않더라도 이는 충분히 설득력 있는 프로세스이다. 이미 우리는 고객들과 스크럼을 짜며 제품의 완성도를 높였던 경험을 가지고 있기 때문이다. 소프트웨어를 무리하게 출시하여 한달(스프린트)에 한번씩 패치를 릴리즈하지 않는가? 잠재적으로 많은 버그들이 숨어있는 웹 사이트를 공개하여 한달(스프린트)에 한번 정도는 예외 없이 엄청난 오류를 발견하고 서둘러 고치지는 않는가? 물론 이와 같은 과정을 통해 제품은 완성도를 더해갈 것이고 문제는 점점 줄어들 것이다. 하지만 더불어 고객들도 줄어들 것이다. 이와 같은 시행착오를 줄이는 것이 바로 스크럼이다. 고객들은 돼지와 닭이 아니다.

스크럼이  과연 해답인가?

 애자일  방법론에는 여러 가지 개발 방법이 존재한다. 이 방법론들은 비슷해 보이지만 서로 다른 특징을 가지고 있다.

♦  린 소프트웨어 개발(Lean Software Development) : 린 소프트웨어 개발은 개발 조직 전반에 걸친 법칙과 실천 과정을 다룬다.

♦  스크럼(Scrum) : 스크럼은 프로젝트가 어떻게 조직되어야 하고 계획되어야 하는지 다룬다.

♦  XP(eXtreme Programming) : XP는 프로그래밍을 이용해 어떻게 작업해야 하는지를 다룬다.

XP와 달리 스크럼은 단지 소프트웨어 개발에만 사용할 수 있는 방법론이 아니다. 지금까지의 내용을 숙지했다면 스크럼이 다양한 형태의 프로젝트에 적용할 수 있는 방법임을 눈치 챘을 것이다. 어찌 보면 스크럼은 서로 머리를 맞대고 아이디어를 도출해내는 브레인스토밍(Brain Storming)과 비슷하다. 브레인스토밍과 같은 지식 생산 행위를 세부적으로 스케줄링하여 목표에 맞는 구체적인 결과물이 나오도록 만든 것이 스크럼인 듯하다. 스크럼 팀은 매일 또는 매달 만나며 제품을 완성하는데 필요한 지식을 생각해내고 정리한다. 그리고 정리하는 작업을 함께 진행하는 도중에 또 다시 필요한 지식을 생각해내고 정리한다. 이와 같은 과정을 수행하면 프로젝트를 진행하는데 걸림돌이 되는 장애물은 미처 나타나기도 전에 제거될 것이고, 제품의 완성도는 눈치 채지 못하는 사이에 점점 더 높아질 것이다. 이런 프로세스에서는 과정의 중요함보다는 참여하는 사람의 자세와 팀의 가치관이 매우 중요한 역할을 한다. 좀 더 구체적인 사례를 들어보자. 정해진 업무 시간에만 일을 하고 정시에 퇴근하는 것은 스크럼에 긍정적인 영향을 준다. 누가 야근을 하며 매일 스크럼 회의를 열고 제품에 새로 추가할 기능에 대해 진취적으로 의견을 개진하겠는가? 그와 반면 야근을 고집하는 업무 분위기는 어떨까. 팀원들 모두 기능에 대한 개선점을 알고 있으면서도 언급하지 않은 채 정해진 스케줄만 묵묵히 수행할 것이다. 그리고 결말은? 제품 출시 후 수많은 불특정 고객들과의 힘겨운 스크럼이다.

스크럼을 수행한 효과는 다양한 체험과 보고를 통해 전해지고 있으며 그 중에서도 야후는 베스트 사례로 꼽힐 만하다. 야후는 근 30개월 동안 약 90개의 프로젝트에 스크럼을 도입했다. 야후 포토와 같이 디자인이 많이 들어간 웹 사이트서부터 야후 메일과 같이 사용량이 중요한 백 엔드(Back-end) 서비스까지 다양한 프로젝트에 스크럼을 도입해 유지보수를 진행했다. 그리고 새로 런칭하는 신규 사이트에도 스크럼을 적용해 안정된 서비스를 사용자에게 제공하였다. 이와 같은 야후의 성과는 조사를 통해 수치화 되었고, 스크럼 참여자 중 약 68%가 기존의 방법보다 더 또는 훨씬 더 좋다고 대답한 것으로 밝혀졌다. 그리고 스크럼에 참여한 제품 책임자들은 평균 36% 정도 생산성이 증가했다고 평가했다. 과연 스크럼만 도입해서 야후가 이런 성공을 거둔 것일까. 그들의 업무 문화가 스크럼의 효과를 배가시켰다고 보는 것이 옳을 것이다. 누구나 스크럼을 도입해서 30% 정도의 생산성 향상을 이루어 낼 수는 없는 것이다. 어떤 조직은 스크럼을 사용해 실패를 맛볼 것이고, 다른 조직은 경이적인 효과를 거둘 수도 있을 것이다. 조직의 문화란 하루 아침에 바뀔 수 없기 때문에 스크럼의 무조건적인 도입은 해악이 될 수 밖에 없다. 그럼에도 불구하고 스크럼에 대해 눈을 뗄 수 없는 이유가 있다. 그것은 바로 수많은 까탈스러운 고객들과의 뒤늦은 스크럼보다 친애하는 팀원들과 함께 하는 스크럼이 더욱 재밌고 흥미진진해보이기 때문이다.