2019.10.02

김진철의 How-to-Big Data | 빅데이터 조직과 시스템 (13)

김진철 | CIO KR

애자일 프로젝트 관리란? – 스크럼으로 애자일 맛보기
켄트 벡을 비롯한 일부 소프트웨어 엔지니어들이 왜 소프트웨어 엔지니어들은 항상 야근과 과로에 시달려야 하는가, 소프트웨어 프로젝트는 왜 일정을 맞추지 못하고 과도한 요구 사항 변화와 이로 인한 일정 지연에 시달리고 유난히 실패 위험이 높은 것인가, 소프트웨어 엔지니어들도 일반 직장인들과 같은 평범한 라이프스타일을 가지면서 생산성을 높일 방법은 없는 것인가 하는 문제를 고민하기 시작했다. 이를 위해 이들은 소프트웨어 개발 방식에 새로운 방법론이 필요하다고 생각하게 되었는데 이에 대한 해답으로 제시한 것이 익스트림 프로그래밍과 애자일 방법론이다. 

애자일 방법론은 반복적인 과정을 통한 소프트웨어 프로젝트 실패 위험 감소와 소스 코드 품질 향상, 코드 리뷰, 페어 프로그래밍을 통한 소스 코드 품질 향상 및 버그 감소, 정기적인 플래닝과 리뷰를 통한 개발자 간 소통과 소프트웨어 개발의 암묵적인 지식 공유를 통한 위험 감소 등으로 특징 지워진다. 애자일 방법론은 린 소프트웨어 개발 방법론과 함께 일정과 자원이 넉넉지 않은 스타트업들을 중심으로 널리 쓰이기 시작하여 그 효용이 입증되면서 이제는 많은 IT 기업들에서 널리 쓰이는 소프트웨어 프로젝트 관리 방법론이 되었다.


그림 1. 애자일 선언(“The Agile Manifesto”)의 핵심 아이디어를 설명한 그림. 애자일 선언은 과거 폭포수(waterfall) 방식의 소프트웨어 공학 방법론에서 탈피하여, 고객과의 밀접한 소통, 피드백과 소프트웨어 엔지니어 간 소통과 협업, 명세서와 문서화 위주의 소프트웨어 개발보다는 실제 동작하는 소프트웨어 개발을 목표로 하고, 반복적인 소프트웨어 개발을 통한 프로젝트 변경과 변화의 능동적 수용을 기본으로 한다. (그림 출처: https://www.slideshare.net/valtechuk/adapting-agile-to-the-entreprise)


그림 2. 애자일 선언의 핵심 아이디어가 된 익스트림 프로그래밍 방법론을 제안한 켄트 벡(그림 출처: https://en.wikipedia.org/wiki/Kent_Beck)

애자일 프로젝트 방법론을 가장 체계적으로 잘 정리한 스크럼 프로젝트 관리 방법론(이하 “스크럼”)을 살펴보면서 애자일 소프트웨어 개발이 어떤 것인지, 스크럼을 이용해 데이터 과학 프로젝트에 애자일 방법론을 적용하면서 어떤 이점을 얻을 수 있는지, 데이터 과학 프로젝트에 애자일 방법론을 적용할 때 어떤 점들을 조심해야 하는지 같이 살펴보도록 하자.


그림 3. 애자일 개발의 대표적인 방법론인 스크럼(Scrum)의 개요. 스크럼 프로세스에서 나오는 산출물을 중심으로 정리한 그림. (그림 출처:   https://www.mimeo.com/blog/three-reasons-scrum-master-certified/)

스크럼은 애자일 선언의 반복적 소프트웨어 개발과 고객과의 긴밀한 상호 작용을 시스템으로 만든 소프트웨어 프로젝트 관리 방법론으로, 단계별로 만들어야 할 프로젝트 산출물이 구체적으로 정의되어 있다는 것이 큰 특징이다. 스크럼 방법론의 가장 큰 특징은 반복적인 개발과 테스트를 통해 완성된 소프트웨어를 주기적으로 자주 릴리즈하고, 이런 반복된 주기를 통한 제품 계획과 개발, 완성을 통해 고객과 시장 상황에 따른 요구 사항과 개발 기능 우선순위의 변화를 능동적으로 수용하고 반영할 수 있다는 점이다. 이에 더해, 고객이 프로젝트 산출물을 검토하고 피드백을 줄 방법을 명시하고 구체적으로 정의해 개발하는 소프트웨어가 고객의 요구 사항과 전혀 다른 상품이 되지 않을 수 있도록 사전에 위험을 관리할 수 있다.


그림 4. 스크럼 프로젝트 관리 프로세스를 중심으로 본 스크럼의 개요. (그림 출처: https://www.researchgate.net/publication/303805587_Hybrid-Agile_Approach_in_Smart_Cities_Procurement/figures?lo=1 )

그림 3과 4를 통해서 스크럼 프로젝트 관리의 전 과정을 같이 한번 살펴보도록 하자. 우선 스크럼 프로젝트를 통해 만들 소프트웨어의 정의와 특성, 개발해야 할 주요 자질(feature)과 기능들을 상품 관리자(product manager)가 정리하여 “프로젝트 비전 선언서(Vision Manifesto)”로 정리한다. 이 “프로젝트 비전 선언서”는 개발할 소프트웨어가 고객의 의뢰로 만들어지는 경우라면 고객이 제공한 소프트웨어의 요구 사항을 중심으로 상품 관리자가 작성하게 된다. 고객의 의뢰로 만들어지는 소프트웨어가 아니라면, 기업 내에서 소프트웨어를 포함한 상품을 기획한 상품 기획 부서와 관련 담당자들의 상품 기획서와 명세서를 바탕으로 상품 관리자나 기획자가 작성하게 된다.

이렇게 작성된 “프로젝트 비전 선언서(Vision Manifesto)”를 바탕으로 소프트웨어가 사용자에게 어떻게 사용될 것인지를 명시하는 “사용자 스토리(User Story)” 문서를 만들게 된다. 이 “사용자 스토리(User Story)” 산출물은 흔히 얘기하는 “소프트웨어 요구 사항 명세서(Requirement Specification)”와 다른 문서이지만, 스크럼 프로세스에서는 요구 사항 명세서와 비슷한 용도로 쓰이기도 한다. 그렇지만, “사용자 스토리”와 “소프트웨어 요구 사항 명세서”는 엄연히 다른 산출물이며, 좀더 엄격한 프로젝트 관리가 필요한 스크럼 프로젝트에서는 “소프트웨어 요구 사항 명세서”도 같이 작성하기도 한다.

“사용자 스토리”가 작성된 후에는 각 사용자 스토리에 해당하는 개발 작업의 분량과 일정이 어느 정도 필요한지를 추정하고 프로젝트 상세 계획을 세우기 위한 프로젝트 규모 추정 과정에 들어가게 된다. 상품 관리자(product manager)가 작성한 “프로젝트 비전 선언서(Vision Manifesto)”를 바탕으로 상품 관리자와의 협업 아래 소프트웨어를 개발할 개발자 또는 소프트웨어 엔지니어들과 프로젝트 관리자, 그리고 애자일 프로젝트 관리를 도울 스크럼 마스터나 애자일 코치가 참석한 가운데 그 유명한 “스크럼 포커(Scrum Poker)”를 하게 된다.

“스크럼 포커(Scrum Poker)”는 각 사용자 스토리별로 어떻게 구현할 것인지를 소프트웨어 개발팀 구성원들이 서로 같이 의견을 교환하면서 개발에 어느 정도의 시간과 노력이 들지를 협의하는 회의이다. 사용자 스토리별 개발 시간과 작업의 양을 추정할 때 포커 게임을 하듯이 한다고 해서 “스크럼 포커”라고 불린다. 스크럼 포커를 통해 각 사용자 스토리별로 어느 정도의 시간이 걸릴지를 대략 추정할 수 있고, 이를 바탕으로 해서 소프트웨어가 만족시킬 것으로 요구되는 전체 사용자 스토리를 소프트웨어로 구현하는데 어느 정도의 기간과 노력이 필요한지를 대략 추정할 수 있게 된다.

대개 스크럼팀이 처음 짜였을 때는 팀 구성원들의 개발 및 프로젝트 관리 역량이 어느 정도인지 서로 잘 모르기 때문에 스크럼 포커를 통해 추정된 작업 규모는 부정확한 경우가 많다. 그렇지만, 스크럼의 장점인 반복적인 개발 과정을 통해 스프린트와 소프트웨어 릴리즈 과정을 몇 번 거치면서 다시 스크럼 포커를 하게 되면 어느 정도 정확하게 팀 규모의 작업 규모 추정이 수렴하는 경우가 많다. 이렇게 반복적인 과정을 통해 프로젝트 수행을 위한 시간과 자원의 추정이 점진적으로 개선될 수 있는 것도 스크럼의 장점이다.

위와 같이 “사용자 스토리”가 정의되고, 스크럼 포커 회의를 통해서 사용자 스토리별 개발 규모와 분량이 어느 정도 추정되면, 이를 바탕으로 “상품 백로그(Product Backlog)”가 작성된다. “상품 백로그”는 개발할 소프트웨어에서 구현되어 사용자의 요구 사항을 충족시킬 내용을 “사용자 스토리”를 중심으로 정의한 문서이다. 이 “상품 백로그”를 기초로 하여 “소프트웨어 릴리즈 계획(release planning)”을 수립하게 된다. 소프트웨어 릴리즈 계획은 “상품 백로그”에서 정의한 소프트웨어에서 구현할 사용자 스토리들을 단계별로 개발될 소프트웨어 릴리즈 별로 어떤 순서와 우선순위로 구현할 것인지 정하여 개발 계획을 세운 것이다.

이렇게 “소프트웨어 릴리즈 계획”이 수립되면 이를 바탕으로 하나의 소프트웨어 릴리즈 개발 기간에 몇 번의 더 작은 반복적인 과정을 거쳐 소프트웨어를 개발할지 정하게 된다. 스크럼에서는 이 반복적인 소프트웨어 개발, 테스트 기간의 단위를 “스프린트(Sprint)”라고 한다. 스크럼으로 개발되는 소프트웨어는 보통 한번의 소프트웨어 릴리즈가 아니라 여러 번의 소프트웨어 릴리즈를 통해 개발되면서 소프트웨어의 품질과 기능이 개선되는 것이 보통이다. 소프트웨어의 종류에 따라 많이 다르기는 하지만, 한번의 소프트웨어 릴리즈 과정에서 4주 정도의 기간을 가지는 4~6번의 스프린트 과정을 거쳐 릴리즈하는 경우가 많은데, 이는 개발하려는 소프트웨어의 종류와 개발 조직의 특성에 따라 많이 달라지므로 절대적인 것은 아니다.

각 “스프린트”는 모두 독립적인 개발의 단계로서, 스프린트마다 완성된 기능을 가진 소프트웨어가 테스트 과정까지 거쳐 나오게 된다. 스프린트마다 나오는 소프트웨어는 모두 동작하는 소프트웨어로 만들어지며, 스프린트를 거치면서 기능이 추가되거나 보완되어 릴리즈 계획 때 목표로 한 소프트웨어를 점진적으로 만들어간다. 과거 “폭포수(waterfall)” 개발 방법론에서 개발되었던 소프트웨어와의 차이는, “폭포수” 개발 모델에서는 중간 단계에 나오는 소프트웨어는 그 자체로 아직 완전하게 동작할 수 없는 미완성의 소프트웨어이지만, “스크럼”의 “스프린트”마다 나오는 소프트웨어는, 릴리즈 계획 시 목표로 한 기능을 모두 갖추고 있지는 못하더라도 그 자체로 동작하는 소프트웨어라는 것이다. 이렇게 스프린트마다 동작하는 소프트웨어를 만든다는 목표로 점진적으로 소프트웨어를 개발하여 최종 목표 기능을 모두 갖추도록 만드는 것이 “스크럼”을 비롯한 애자일 방법론의 특징이다.

각 스프린트를 시작할 때에는 “스프린트 계획(sprint planning)” 회의를 거쳐 “스프린트 계획 보고서”를 산출물로서 내놓는다. “스프린트 계획 보고서”는 “스프린트 계획” 회의를 상품 관리자와 프로젝트 관리자, 개발자들이 같이 진행한 후 보통 상품 관리자와 프로젝트 관리자가 작성하며, 소프트웨어 개발을 의뢰한 고객에게 공유된다. “스프린트 계획” 회의 후에는 실제 개발에 들어가게 되는데, 실제 개발을 진행하면서 개발 내용과 개발 과정의 이슈에 대한 원활한 소통과 관리를 위해 다양한 방법들을 활용하게 된다.

“스크럼”에서 가장 유명한 것 중의 하나가 바로 “일일 스크럼 회의(daily scrum meeting)”일 것이다. 스크럼에 익숙하지 않은 많은 개발자가 부담을 느끼기도 하는 회의인데, 사실 직접 해보면 그렇게 어렵고 힘든 것도 아니다. 말 그대로, 매일 개발팀의 모든 구성원이 모여 개발 진행 상황과 이슈를 짧게 공유하는 회의인데, 매일 진행해야 하기 때문에 사람에 따라서는 부담을 느끼기도 한다. 하지만, “일일 스크럼 회의”의 목적은 개발에 대한 평가보다는 소통과 공유에 있기 때문에 프로젝트 리더가 개방적인 개발 문화를 잘 만든다면 자연스럽게 진행할 수 있는 제도이다.

“스크럼”에서 많이 사용하는 프로젝트 관리 기법 중으로 “칸반 보드(Kanban board)”, “짝 프로그래밍(pair programming)” 등 다양한 방법들이 있다. “칸반 보드”는 별도의 도구 없이 카드와 화이트보드만으로 진척 관리를 할 수 있도록 스프린트별 사용자 스토리를 적은 카드를 각 구성원과 개발 단계별로 화이트보드 또는 진척 관리 상황판에 붙여 모든 구성원이 상시로 보면서 개발 상황을 업데이트하고 소통할 수 있도록 하는 도구인데, 최근에는 온라인 소프트웨어 도구로 많이 대체되는 추세다.

“짝 프로그래밍”은 원래 “익스트림 프로그래밍” 방법론의 하나로서 제안된 것이지만, 요즘에는 소프트웨어의 소스 코드 품질과 일정 관리를 위해 스크럼을 비롯한 애자일 프로젝트 관리 과정에서 많이 활용되고 있다. “짝 프로그래밍”은 말 그대로 두 사람이 같은 기능에 대한 개발을 나란히 앉아 같이 진행하는 것이다. “짝 프로그래밍”을 하게 되면 소스 코드상에서 미처 생각하지 못했던 버그나 실수를 미연에 예방할 수 있는 가능성이 커지고, 개발 내용을 두 사람이 완전하게 공유하기 때문에 주 개발자에게 질병이나 사고 등의 문제가 생기더라도 일정 지연 등의 문제 없이 개발 일정을 탄력적으로 조절해서 진행할 수 있는 장점이 있다.

각 스프린트를 “테스트 주도 개발(Test-Driven Development, 이하 TDD)”을 통해 테스트, 배포 자동화를 갖추고 진행하게 되면 크게 개발 생산성을 향상할 수 있기 때문에 요즘은 많은 소프트웨어 개발팀이 TDD를 하려고 한다. TDD는 테스트 내용을 먼저 정의하고 테스트를 자동화하는 프로그램을 먼저 만든 후에 소프트웨어를 개발하는 것이다. TDD를 이용하면 소프트웨어 테스트를 자동화할 수 있어서 새롭게 개발한 소프트웨어의 기능이 원래 목표했던 기능을 만족하는지 쉽게 확인할 수 있고, 향후 기능의 변경 없이 소프트웨어 내부 구조와 내용만 변경하여 성능과 품질을 개선하는 “리팩터링(refactoring)”을 진행하기도 쉬워 소프트웨어의 품질을 높이는 데 효과적이다.

이렇게 스프린트별 개발을 다양한 프로젝트 관리 방법론을 통해 진행하여 한 스프린트를 마치게 되면 보통 “스프린트 리뷰(sprint review)” 및 “회고(sprint retrospective)” 회의를 진행하게 된다. “스프린트 리뷰” 회의는 말 그대로 스프린트 동안 개발한 내용을 고객과 상품 관리자, 프로젝트 관리자와 개발에 참여한 소프트웨어 엔지니어들이 같이 검토하면서 개발의 현재 상황을 확인하고 다음 스프린트 동안 보완할 내용을 의논하는 회의이다. 스프린트 회의 때에는 스프린트 동안 개발된 내용을 데모를 통해 꼭 동작을 확인하는 과정이 포함된다. 앞에서 스프린트마다 나오는 소프트웨어는 그 자체로 동작하는 소프트웨어가 되도록 스크럼에서 개발한다고 얘기한 바 있는데, 이렇게 목표한 개발 내용이 그 자체로 완전한지를 스프린트 리뷰 회의를 통해 확인하게 된다.

“회고” 회의는 스프린트 기간에 개발과정과 산출물을 만드는 과정을 평가하고 개선 사항을 의논하는 회의다. “회고” 회의에서는 스프린트 개발 산출물 자체에 대한 평가보다는 개발 프로세스와 개발 문화, 소프트웨어 엔지니어 간 소통 문제가 없었는지 점검하고 다음 스프린트에서 어떻게 개선되도록 실행할 것인지 개선방향을 논의한다.

이렇게 “회고” 회의까지 마치게 되면 한 스프린트가 끝나게 되며, 스프린트 동안 개발된 소프트웨어의 소스 코드와 “스프린트 완료 보고서”가 산출물로 남게 된다. 스프린트 동안 완료된 개발 내용에 대해서는 칸반 보드와 스프린트 백로그, 상품 백로그의 사용자 스토리의 상태를 “완료”로 변경하여 현재까지 개발 진척 상황을 업데이트하여 공유한다. 이렇게 상품 백로그의 사용자 스토리의 상태를 스프린트마다 “완료”로 변경하게 되면 미완료로 남아 있는 사용자 스토리와 스토리 포인트의 양이 스프린트마다 점점 줄어들게 되고, 이를 그래프로 표현한 것을 “번다운 차트(Burndown chart)”라고 한다. 번다운 차트를 통해 릴리즈 목표를 달성하기 위해 남아 있는 작업의 양을 개발팀 구성원들이 한눈에 확인할 수 있게 된다.

“스프린트 리뷰” 회의를 통해 가장 중요하게 점검되는 항목 중의 하나는 개발팀의 개발 속도이다. 보통 사용자 스토리의 작업 분량은 스크럼 포커를 통해 스토리 포인트로서 대략 작업 분량과 기간이 추정된다. 개발팀의 각 구성원이 소화할 수 있는 스토리 포인트가 대개 프로젝트 초반에는 정확하지 않기 때문에 “스프린트 리뷰” 회의를 통해 완료된 사용자 스토리와 완성되지 않은 사용자 스토리를 점검하면서 스크럼 포커를 통해 추정된 스토리 포인트가 적절한 추정값인지, 스프린트에 할당된 사용자 스토리의 양이 개발팀에서 소화할 수 있을 만큼의 적절한 양이었는지를 점검한다.

이런 식으로 스프린트마다 개발 내용과 상황, 스토리 포인트 추정치를 점검하는 과정을 몇 번의 스프린트를 통해 거치게 되면 개발팀 구성원들의 스토리 포인트를 통한 작업량 추정의 정확도가 높아지게 되어 반복적으로 프로젝트 일정 관리가 개선되는 것도 스크럼의 큰 장점이다. 스토리 포인트 추정과 점검이 반복적으로 이루어지고 팀의 개발 역량을 보다 구체적이고 정확하게 파악할 수 있게 되면서 측정과 정량적인 계획을 통한 프로젝트 일정 관리가 가능하게 되면 소프트웨어 프로젝트의 위험을 크게 줄일 수 있게 된다.

이렇게 몇 번의 스프린트를 거쳐 하나의 릴리즈가 완료되면 소프트웨어 개발 상황을 고객과 상품 관리자, 프로젝트 관리자와 개발팀 구성원들이 같이 점검하고 공식 버전으로 릴리즈하게 된다. 이렇게 한번의 릴리즈를 거치면서 발견된 개선 사항들은 다음 릴리즈 계획에 포함하여 다시 스크럼 프로세스를 반복하면서 개발하게 된다.

앞에서 살펴본 바와 같이 스크럼 방법론의 가장 큰 특징은 소프트웨어 개발을 반복적인 작은 단위인 “스프린트”로 나누어서, 이 스프린트를 반복하면서 소프트웨어의 기능과 안정성을 점진적으로 향상하는 데 있다. 각 개발 단위인 “스프린트”마다 “사용자 스토리”로 표현되는 고객의 요구사항을 만족시키는 버전의 소프트웨어가 개발되게 되며, 소프트웨어 개발 산출물이 정기적으로 나오면서 소프트웨어 문서화도 프로젝트 관리 프로세스를 통해 같이 이루어지는 것이 특징이다.

스크럼 방법론의 위와 같은 특징은 무형의 자산인 소프트웨어를 과거 폭포수 모델의 프로젝트 관리 방법론을 통해 개발하면서 자주 생겼던 소프트웨어 최종 결과물이 고객의 기대와 달리 개발되거나, 소프트웨어 개발 계획 수립 시점의 소프트웨어 요구 사항이 소프트웨어 개발 완료 시점의 시장과 고객의 요구 사항과 달라져서 오는 근본적인 위험을 보다 체계적이고 유연하게 수용할 수 있게 한다. 이를 통해 소프트웨어가 보다 더 고객과 시장의 요구 사항을 잘 만족하고 프로젝트의 실패 가능성을 낮출 수 있게 하였다.

이렇게 스크럼으로 대표되는 애자일 프로젝트 관리 방법론은 최근 미국 실리콘 밸리 스타트업을 중심으로 크게 확산되고 있다. 비즈니스 모델이 아직 검증되지 않고 자금, 일정 압박을 고스란히 겪는 스타트업이 빠른 시간에 자사의 소프트웨어와 상품을 고객과 시장 친화적으로 만들고 검증하기 위한 방법으로 애자일 프로젝트 관리 방법론이 각광을 받고 있는 것이다. 빅데이터와 데이터 과학을 활용한 상품 개발과 비즈니스 모델 설계도 애자일 방법론을 통해 위험을 줄이고 보다 더 조직과 시장의 요구 사항에 잘 맞도록 활용하는 것이 가능하다. 어떻게 하면 애자일 방법론을 빅데이터와 데이터 과학에 적용할 수 있을지 같이 한번 생각해 보자.




2019.10.02

김진철의 How-to-Big Data | 빅데이터 조직과 시스템 (13)

김진철 | CIO KR

애자일 프로젝트 관리란? – 스크럼으로 애자일 맛보기
켄트 벡을 비롯한 일부 소프트웨어 엔지니어들이 왜 소프트웨어 엔지니어들은 항상 야근과 과로에 시달려야 하는가, 소프트웨어 프로젝트는 왜 일정을 맞추지 못하고 과도한 요구 사항 변화와 이로 인한 일정 지연에 시달리고 유난히 실패 위험이 높은 것인가, 소프트웨어 엔지니어들도 일반 직장인들과 같은 평범한 라이프스타일을 가지면서 생산성을 높일 방법은 없는 것인가 하는 문제를 고민하기 시작했다. 이를 위해 이들은 소프트웨어 개발 방식에 새로운 방법론이 필요하다고 생각하게 되었는데 이에 대한 해답으로 제시한 것이 익스트림 프로그래밍과 애자일 방법론이다. 

애자일 방법론은 반복적인 과정을 통한 소프트웨어 프로젝트 실패 위험 감소와 소스 코드 품질 향상, 코드 리뷰, 페어 프로그래밍을 통한 소스 코드 품질 향상 및 버그 감소, 정기적인 플래닝과 리뷰를 통한 개발자 간 소통과 소프트웨어 개발의 암묵적인 지식 공유를 통한 위험 감소 등으로 특징 지워진다. 애자일 방법론은 린 소프트웨어 개발 방법론과 함께 일정과 자원이 넉넉지 않은 스타트업들을 중심으로 널리 쓰이기 시작하여 그 효용이 입증되면서 이제는 많은 IT 기업들에서 널리 쓰이는 소프트웨어 프로젝트 관리 방법론이 되었다.


그림 1. 애자일 선언(“The Agile Manifesto”)의 핵심 아이디어를 설명한 그림. 애자일 선언은 과거 폭포수(waterfall) 방식의 소프트웨어 공학 방법론에서 탈피하여, 고객과의 밀접한 소통, 피드백과 소프트웨어 엔지니어 간 소통과 협업, 명세서와 문서화 위주의 소프트웨어 개발보다는 실제 동작하는 소프트웨어 개발을 목표로 하고, 반복적인 소프트웨어 개발을 통한 프로젝트 변경과 변화의 능동적 수용을 기본으로 한다. (그림 출처: https://www.slideshare.net/valtechuk/adapting-agile-to-the-entreprise)


그림 2. 애자일 선언의 핵심 아이디어가 된 익스트림 프로그래밍 방법론을 제안한 켄트 벡(그림 출처: https://en.wikipedia.org/wiki/Kent_Beck)

애자일 프로젝트 방법론을 가장 체계적으로 잘 정리한 스크럼 프로젝트 관리 방법론(이하 “스크럼”)을 살펴보면서 애자일 소프트웨어 개발이 어떤 것인지, 스크럼을 이용해 데이터 과학 프로젝트에 애자일 방법론을 적용하면서 어떤 이점을 얻을 수 있는지, 데이터 과학 프로젝트에 애자일 방법론을 적용할 때 어떤 점들을 조심해야 하는지 같이 살펴보도록 하자.


그림 3. 애자일 개발의 대표적인 방법론인 스크럼(Scrum)의 개요. 스크럼 프로세스에서 나오는 산출물을 중심으로 정리한 그림. (그림 출처:   https://www.mimeo.com/blog/three-reasons-scrum-master-certified/)

스크럼은 애자일 선언의 반복적 소프트웨어 개발과 고객과의 긴밀한 상호 작용을 시스템으로 만든 소프트웨어 프로젝트 관리 방법론으로, 단계별로 만들어야 할 프로젝트 산출물이 구체적으로 정의되어 있다는 것이 큰 특징이다. 스크럼 방법론의 가장 큰 특징은 반복적인 개발과 테스트를 통해 완성된 소프트웨어를 주기적으로 자주 릴리즈하고, 이런 반복된 주기를 통한 제품 계획과 개발, 완성을 통해 고객과 시장 상황에 따른 요구 사항과 개발 기능 우선순위의 변화를 능동적으로 수용하고 반영할 수 있다는 점이다. 이에 더해, 고객이 프로젝트 산출물을 검토하고 피드백을 줄 방법을 명시하고 구체적으로 정의해 개발하는 소프트웨어가 고객의 요구 사항과 전혀 다른 상품이 되지 않을 수 있도록 사전에 위험을 관리할 수 있다.


그림 4. 스크럼 프로젝트 관리 프로세스를 중심으로 본 스크럼의 개요. (그림 출처: https://www.researchgate.net/publication/303805587_Hybrid-Agile_Approach_in_Smart_Cities_Procurement/figures?lo=1 )

그림 3과 4를 통해서 스크럼 프로젝트 관리의 전 과정을 같이 한번 살펴보도록 하자. 우선 스크럼 프로젝트를 통해 만들 소프트웨어의 정의와 특성, 개발해야 할 주요 자질(feature)과 기능들을 상품 관리자(product manager)가 정리하여 “프로젝트 비전 선언서(Vision Manifesto)”로 정리한다. 이 “프로젝트 비전 선언서”는 개발할 소프트웨어가 고객의 의뢰로 만들어지는 경우라면 고객이 제공한 소프트웨어의 요구 사항을 중심으로 상품 관리자가 작성하게 된다. 고객의 의뢰로 만들어지는 소프트웨어가 아니라면, 기업 내에서 소프트웨어를 포함한 상품을 기획한 상품 기획 부서와 관련 담당자들의 상품 기획서와 명세서를 바탕으로 상품 관리자나 기획자가 작성하게 된다.

이렇게 작성된 “프로젝트 비전 선언서(Vision Manifesto)”를 바탕으로 소프트웨어가 사용자에게 어떻게 사용될 것인지를 명시하는 “사용자 스토리(User Story)” 문서를 만들게 된다. 이 “사용자 스토리(User Story)” 산출물은 흔히 얘기하는 “소프트웨어 요구 사항 명세서(Requirement Specification)”와 다른 문서이지만, 스크럼 프로세스에서는 요구 사항 명세서와 비슷한 용도로 쓰이기도 한다. 그렇지만, “사용자 스토리”와 “소프트웨어 요구 사항 명세서”는 엄연히 다른 산출물이며, 좀더 엄격한 프로젝트 관리가 필요한 스크럼 프로젝트에서는 “소프트웨어 요구 사항 명세서”도 같이 작성하기도 한다.

“사용자 스토리”가 작성된 후에는 각 사용자 스토리에 해당하는 개발 작업의 분량과 일정이 어느 정도 필요한지를 추정하고 프로젝트 상세 계획을 세우기 위한 프로젝트 규모 추정 과정에 들어가게 된다. 상품 관리자(product manager)가 작성한 “프로젝트 비전 선언서(Vision Manifesto)”를 바탕으로 상품 관리자와의 협업 아래 소프트웨어를 개발할 개발자 또는 소프트웨어 엔지니어들과 프로젝트 관리자, 그리고 애자일 프로젝트 관리를 도울 스크럼 마스터나 애자일 코치가 참석한 가운데 그 유명한 “스크럼 포커(Scrum Poker)”를 하게 된다.

“스크럼 포커(Scrum Poker)”는 각 사용자 스토리별로 어떻게 구현할 것인지를 소프트웨어 개발팀 구성원들이 서로 같이 의견을 교환하면서 개발에 어느 정도의 시간과 노력이 들지를 협의하는 회의이다. 사용자 스토리별 개발 시간과 작업의 양을 추정할 때 포커 게임을 하듯이 한다고 해서 “스크럼 포커”라고 불린다. 스크럼 포커를 통해 각 사용자 스토리별로 어느 정도의 시간이 걸릴지를 대략 추정할 수 있고, 이를 바탕으로 해서 소프트웨어가 만족시킬 것으로 요구되는 전체 사용자 스토리를 소프트웨어로 구현하는데 어느 정도의 기간과 노력이 필요한지를 대략 추정할 수 있게 된다.

대개 스크럼팀이 처음 짜였을 때는 팀 구성원들의 개발 및 프로젝트 관리 역량이 어느 정도인지 서로 잘 모르기 때문에 스크럼 포커를 통해 추정된 작업 규모는 부정확한 경우가 많다. 그렇지만, 스크럼의 장점인 반복적인 개발 과정을 통해 스프린트와 소프트웨어 릴리즈 과정을 몇 번 거치면서 다시 스크럼 포커를 하게 되면 어느 정도 정확하게 팀 규모의 작업 규모 추정이 수렴하는 경우가 많다. 이렇게 반복적인 과정을 통해 프로젝트 수행을 위한 시간과 자원의 추정이 점진적으로 개선될 수 있는 것도 스크럼의 장점이다.

위와 같이 “사용자 스토리”가 정의되고, 스크럼 포커 회의를 통해서 사용자 스토리별 개발 규모와 분량이 어느 정도 추정되면, 이를 바탕으로 “상품 백로그(Product Backlog)”가 작성된다. “상품 백로그”는 개발할 소프트웨어에서 구현되어 사용자의 요구 사항을 충족시킬 내용을 “사용자 스토리”를 중심으로 정의한 문서이다. 이 “상품 백로그”를 기초로 하여 “소프트웨어 릴리즈 계획(release planning)”을 수립하게 된다. 소프트웨어 릴리즈 계획은 “상품 백로그”에서 정의한 소프트웨어에서 구현할 사용자 스토리들을 단계별로 개발될 소프트웨어 릴리즈 별로 어떤 순서와 우선순위로 구현할 것인지 정하여 개발 계획을 세운 것이다.

이렇게 “소프트웨어 릴리즈 계획”이 수립되면 이를 바탕으로 하나의 소프트웨어 릴리즈 개발 기간에 몇 번의 더 작은 반복적인 과정을 거쳐 소프트웨어를 개발할지 정하게 된다. 스크럼에서는 이 반복적인 소프트웨어 개발, 테스트 기간의 단위를 “스프린트(Sprint)”라고 한다. 스크럼으로 개발되는 소프트웨어는 보통 한번의 소프트웨어 릴리즈가 아니라 여러 번의 소프트웨어 릴리즈를 통해 개발되면서 소프트웨어의 품질과 기능이 개선되는 것이 보통이다. 소프트웨어의 종류에 따라 많이 다르기는 하지만, 한번의 소프트웨어 릴리즈 과정에서 4주 정도의 기간을 가지는 4~6번의 스프린트 과정을 거쳐 릴리즈하는 경우가 많은데, 이는 개발하려는 소프트웨어의 종류와 개발 조직의 특성에 따라 많이 달라지므로 절대적인 것은 아니다.

각 “스프린트”는 모두 독립적인 개발의 단계로서, 스프린트마다 완성된 기능을 가진 소프트웨어가 테스트 과정까지 거쳐 나오게 된다. 스프린트마다 나오는 소프트웨어는 모두 동작하는 소프트웨어로 만들어지며, 스프린트를 거치면서 기능이 추가되거나 보완되어 릴리즈 계획 때 목표로 한 소프트웨어를 점진적으로 만들어간다. 과거 “폭포수(waterfall)” 개발 방법론에서 개발되었던 소프트웨어와의 차이는, “폭포수” 개발 모델에서는 중간 단계에 나오는 소프트웨어는 그 자체로 아직 완전하게 동작할 수 없는 미완성의 소프트웨어이지만, “스크럼”의 “스프린트”마다 나오는 소프트웨어는, 릴리즈 계획 시 목표로 한 기능을 모두 갖추고 있지는 못하더라도 그 자체로 동작하는 소프트웨어라는 것이다. 이렇게 스프린트마다 동작하는 소프트웨어를 만든다는 목표로 점진적으로 소프트웨어를 개발하여 최종 목표 기능을 모두 갖추도록 만드는 것이 “스크럼”을 비롯한 애자일 방법론의 특징이다.

각 스프린트를 시작할 때에는 “스프린트 계획(sprint planning)” 회의를 거쳐 “스프린트 계획 보고서”를 산출물로서 내놓는다. “스프린트 계획 보고서”는 “스프린트 계획” 회의를 상품 관리자와 프로젝트 관리자, 개발자들이 같이 진행한 후 보통 상품 관리자와 프로젝트 관리자가 작성하며, 소프트웨어 개발을 의뢰한 고객에게 공유된다. “스프린트 계획” 회의 후에는 실제 개발에 들어가게 되는데, 실제 개발을 진행하면서 개발 내용과 개발 과정의 이슈에 대한 원활한 소통과 관리를 위해 다양한 방법들을 활용하게 된다.

“스크럼”에서 가장 유명한 것 중의 하나가 바로 “일일 스크럼 회의(daily scrum meeting)”일 것이다. 스크럼에 익숙하지 않은 많은 개발자가 부담을 느끼기도 하는 회의인데, 사실 직접 해보면 그렇게 어렵고 힘든 것도 아니다. 말 그대로, 매일 개발팀의 모든 구성원이 모여 개발 진행 상황과 이슈를 짧게 공유하는 회의인데, 매일 진행해야 하기 때문에 사람에 따라서는 부담을 느끼기도 한다. 하지만, “일일 스크럼 회의”의 목적은 개발에 대한 평가보다는 소통과 공유에 있기 때문에 프로젝트 리더가 개방적인 개발 문화를 잘 만든다면 자연스럽게 진행할 수 있는 제도이다.

“스크럼”에서 많이 사용하는 프로젝트 관리 기법 중으로 “칸반 보드(Kanban board)”, “짝 프로그래밍(pair programming)” 등 다양한 방법들이 있다. “칸반 보드”는 별도의 도구 없이 카드와 화이트보드만으로 진척 관리를 할 수 있도록 스프린트별 사용자 스토리를 적은 카드를 각 구성원과 개발 단계별로 화이트보드 또는 진척 관리 상황판에 붙여 모든 구성원이 상시로 보면서 개발 상황을 업데이트하고 소통할 수 있도록 하는 도구인데, 최근에는 온라인 소프트웨어 도구로 많이 대체되는 추세다.

“짝 프로그래밍”은 원래 “익스트림 프로그래밍” 방법론의 하나로서 제안된 것이지만, 요즘에는 소프트웨어의 소스 코드 품질과 일정 관리를 위해 스크럼을 비롯한 애자일 프로젝트 관리 과정에서 많이 활용되고 있다. “짝 프로그래밍”은 말 그대로 두 사람이 같은 기능에 대한 개발을 나란히 앉아 같이 진행하는 것이다. “짝 프로그래밍”을 하게 되면 소스 코드상에서 미처 생각하지 못했던 버그나 실수를 미연에 예방할 수 있는 가능성이 커지고, 개발 내용을 두 사람이 완전하게 공유하기 때문에 주 개발자에게 질병이나 사고 등의 문제가 생기더라도 일정 지연 등의 문제 없이 개발 일정을 탄력적으로 조절해서 진행할 수 있는 장점이 있다.

각 스프린트를 “테스트 주도 개발(Test-Driven Development, 이하 TDD)”을 통해 테스트, 배포 자동화를 갖추고 진행하게 되면 크게 개발 생산성을 향상할 수 있기 때문에 요즘은 많은 소프트웨어 개발팀이 TDD를 하려고 한다. TDD는 테스트 내용을 먼저 정의하고 테스트를 자동화하는 프로그램을 먼저 만든 후에 소프트웨어를 개발하는 것이다. TDD를 이용하면 소프트웨어 테스트를 자동화할 수 있어서 새롭게 개발한 소프트웨어의 기능이 원래 목표했던 기능을 만족하는지 쉽게 확인할 수 있고, 향후 기능의 변경 없이 소프트웨어 내부 구조와 내용만 변경하여 성능과 품질을 개선하는 “리팩터링(refactoring)”을 진행하기도 쉬워 소프트웨어의 품질을 높이는 데 효과적이다.

이렇게 스프린트별 개발을 다양한 프로젝트 관리 방법론을 통해 진행하여 한 스프린트를 마치게 되면 보통 “스프린트 리뷰(sprint review)” 및 “회고(sprint retrospective)” 회의를 진행하게 된다. “스프린트 리뷰” 회의는 말 그대로 스프린트 동안 개발한 내용을 고객과 상품 관리자, 프로젝트 관리자와 개발에 참여한 소프트웨어 엔지니어들이 같이 검토하면서 개발의 현재 상황을 확인하고 다음 스프린트 동안 보완할 내용을 의논하는 회의이다. 스프린트 회의 때에는 스프린트 동안 개발된 내용을 데모를 통해 꼭 동작을 확인하는 과정이 포함된다. 앞에서 스프린트마다 나오는 소프트웨어는 그 자체로 동작하는 소프트웨어가 되도록 스크럼에서 개발한다고 얘기한 바 있는데, 이렇게 목표한 개발 내용이 그 자체로 완전한지를 스프린트 리뷰 회의를 통해 확인하게 된다.

“회고” 회의는 스프린트 기간에 개발과정과 산출물을 만드는 과정을 평가하고 개선 사항을 의논하는 회의다. “회고” 회의에서는 스프린트 개발 산출물 자체에 대한 평가보다는 개발 프로세스와 개발 문화, 소프트웨어 엔지니어 간 소통 문제가 없었는지 점검하고 다음 스프린트에서 어떻게 개선되도록 실행할 것인지 개선방향을 논의한다.

이렇게 “회고” 회의까지 마치게 되면 한 스프린트가 끝나게 되며, 스프린트 동안 개발된 소프트웨어의 소스 코드와 “스프린트 완료 보고서”가 산출물로 남게 된다. 스프린트 동안 완료된 개발 내용에 대해서는 칸반 보드와 스프린트 백로그, 상품 백로그의 사용자 스토리의 상태를 “완료”로 변경하여 현재까지 개발 진척 상황을 업데이트하여 공유한다. 이렇게 상품 백로그의 사용자 스토리의 상태를 스프린트마다 “완료”로 변경하게 되면 미완료로 남아 있는 사용자 스토리와 스토리 포인트의 양이 스프린트마다 점점 줄어들게 되고, 이를 그래프로 표현한 것을 “번다운 차트(Burndown chart)”라고 한다. 번다운 차트를 통해 릴리즈 목표를 달성하기 위해 남아 있는 작업의 양을 개발팀 구성원들이 한눈에 확인할 수 있게 된다.

“스프린트 리뷰” 회의를 통해 가장 중요하게 점검되는 항목 중의 하나는 개발팀의 개발 속도이다. 보통 사용자 스토리의 작업 분량은 스크럼 포커를 통해 스토리 포인트로서 대략 작업 분량과 기간이 추정된다. 개발팀의 각 구성원이 소화할 수 있는 스토리 포인트가 대개 프로젝트 초반에는 정확하지 않기 때문에 “스프린트 리뷰” 회의를 통해 완료된 사용자 스토리와 완성되지 않은 사용자 스토리를 점검하면서 스크럼 포커를 통해 추정된 스토리 포인트가 적절한 추정값인지, 스프린트에 할당된 사용자 스토리의 양이 개발팀에서 소화할 수 있을 만큼의 적절한 양이었는지를 점검한다.

이런 식으로 스프린트마다 개발 내용과 상황, 스토리 포인트 추정치를 점검하는 과정을 몇 번의 스프린트를 통해 거치게 되면 개발팀 구성원들의 스토리 포인트를 통한 작업량 추정의 정확도가 높아지게 되어 반복적으로 프로젝트 일정 관리가 개선되는 것도 스크럼의 큰 장점이다. 스토리 포인트 추정과 점검이 반복적으로 이루어지고 팀의 개발 역량을 보다 구체적이고 정확하게 파악할 수 있게 되면서 측정과 정량적인 계획을 통한 프로젝트 일정 관리가 가능하게 되면 소프트웨어 프로젝트의 위험을 크게 줄일 수 있게 된다.

이렇게 몇 번의 스프린트를 거쳐 하나의 릴리즈가 완료되면 소프트웨어 개발 상황을 고객과 상품 관리자, 프로젝트 관리자와 개발팀 구성원들이 같이 점검하고 공식 버전으로 릴리즈하게 된다. 이렇게 한번의 릴리즈를 거치면서 발견된 개선 사항들은 다음 릴리즈 계획에 포함하여 다시 스크럼 프로세스를 반복하면서 개발하게 된다.

앞에서 살펴본 바와 같이 스크럼 방법론의 가장 큰 특징은 소프트웨어 개발을 반복적인 작은 단위인 “스프린트”로 나누어서, 이 스프린트를 반복하면서 소프트웨어의 기능과 안정성을 점진적으로 향상하는 데 있다. 각 개발 단위인 “스프린트”마다 “사용자 스토리”로 표현되는 고객의 요구사항을 만족시키는 버전의 소프트웨어가 개발되게 되며, 소프트웨어 개발 산출물이 정기적으로 나오면서 소프트웨어 문서화도 프로젝트 관리 프로세스를 통해 같이 이루어지는 것이 특징이다.

스크럼 방법론의 위와 같은 특징은 무형의 자산인 소프트웨어를 과거 폭포수 모델의 프로젝트 관리 방법론을 통해 개발하면서 자주 생겼던 소프트웨어 최종 결과물이 고객의 기대와 달리 개발되거나, 소프트웨어 개발 계획 수립 시점의 소프트웨어 요구 사항이 소프트웨어 개발 완료 시점의 시장과 고객의 요구 사항과 달라져서 오는 근본적인 위험을 보다 체계적이고 유연하게 수용할 수 있게 한다. 이를 통해 소프트웨어가 보다 더 고객과 시장의 요구 사항을 잘 만족하고 프로젝트의 실패 가능성을 낮출 수 있게 하였다.

이렇게 스크럼으로 대표되는 애자일 프로젝트 관리 방법론은 최근 미국 실리콘 밸리 스타트업을 중심으로 크게 확산되고 있다. 비즈니스 모델이 아직 검증되지 않고 자금, 일정 압박을 고스란히 겪는 스타트업이 빠른 시간에 자사의 소프트웨어와 상품을 고객과 시장 친화적으로 만들고 검증하기 위한 방법으로 애자일 프로젝트 관리 방법론이 각광을 받고 있는 것이다. 빅데이터와 데이터 과학을 활용한 상품 개발과 비즈니스 모델 설계도 애자일 방법론을 통해 위험을 줄이고 보다 더 조직과 시장의 요구 사항에 잘 맞도록 활용하는 것이 가능하다. 어떻게 하면 애자일 방법론을 빅데이터와 데이터 과학에 적용할 수 있을지 같이 한번 생각해 보자.


X