김진철의 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)”라고 한다. 번다운 차트를 통해 릴리즈 목표를 달성하기 위해 남아 있는 작업의 양을 개발팀 구성원들이 한눈에 확인할 수 있게 된다.

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

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

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

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

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

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


데이터 과학에서 애자일 프로젝트 관리의 중요성 – 반복적이고 꾸준한 결과물 만들기의 힘
지난 서른세번째 글에서 정리한 데이터 과학 프로젝트 관리의 요건을 다시 한번 환기하면서 애자일 프로젝트 방법론이 어떻게 데이터 과학 프로젝트에 적용할 수 있을지 같이 생각해보자.

1. 반복적인 과정을 통해 데이터 과학을 통해 풀어야 하는 문제를 구체적으로 정의하고 정의된 문제를 단계적으로 풀어나가는 것을 체계적으로 지원할 수 있는 프로젝트 관리 방법론
스크럼으로 대표되는 애자일 개발 방법론은 기본적으로 반복적인 개발 과정을 따른다. 스크럼에서 체계적으로 정리된 스프린트와 릴리즈를 단위로 한 데이터 분석과 데이터 분석 산출물 작성도 똑같이 데이터 과학 프로젝트에 응용해볼 수 있다. 다만, 데이터 과학 프로젝트에서는 일반적인 소프트웨어 개발 프로젝트와 달리 분석해야 하는 문제를 정의하는 과정에서도 시행착오를 겪거나 분석을 통해 풀어야 하는 문제의 범위와 해결 방법을 연구, 조사를 통해 좁혀 나가야 하는 과정이 필요할 수 있다. 이런 이유로 데이터 과학 프로젝트 초반에는 풀어야 할 문제나 프로젝트의 목표가 소프트웨어 개발 프로젝트보다 더 모호하거나 분명하게 정의되지 않을 수 있다.

데이터를 수집하기 위한 연구 조사의 대상과 데이터 분석의 방법, 해석 방법 등을 프로젝트 초반부터 분명하게 정하고 시작하기가 경우에 따라서 어려울 수 있기 때문에 이런 점을 고려해서 프로젝트 계획을 세우고 일정 관리를 해야 한다는 것이다.

앞서 데이터 과학 프로젝트 관리를 효과적으로 하기 위한 프로젝트 관리의 요건에서 반복적이고 체계적인 문제 해결 단계를 프로세스로 정의하고 이에 맞추어 데이터 과학 프로젝트를 진행하는 것이 필요하다고 언급한 바 있다. 이런 데이터 과학 문제 해결 단계를 정의하고, 단계별 산출물을 정의해서 문제 해결 과정을 체계적으로 정리하고 문서화하는데 스크럼 방법론을 차용할 수 있다.

위와 같은 데이터 과학 프로젝트 초반의 모호성 때문에 릴리즈 계획을 수립하는 과정이 소프트웨어 개발 프로젝트보다 더 많은 시간과 노력이 필요할 수 있다는 것이다. 정도의 차이는 있어도 풀려고 하는 문제가 모호한 것이야 소프트웨어 개발도 마찬가지이기는 하지만, 비즈니스를 지원하기 위한 정보 시스템에서 많이 쓰이는 소프트웨어 기술이나 아키텍처는 그래도 상대적으로 많이 패턴화되어서 업계에서 정리되어 가기 때문에 소프트웨어 개발 계획 수립에 활용할 자료는 그래도 많은 편이다.

데이터 과학 프로젝트의 경우에도 잘 알려진 수학적, 통계학적, 데이터 마이닝 관점의 문제들에 대해서는 이미 많은 연구가 진행되어 있기 때문에 꽤 많은 문헌과 자료가 축적된 것이 사실이다. 하지만, 기업의 비즈니스에 데이터 과학을 활용할 때는 이렇게 방대한 데이터 분석 방법론 중 어떤 방법론을 당면한 문제에 적용해서 데이터의 어떤 측면을 관찰, 분석할 것인지 정하기도 쉽지 않고 별도의 연구조사가 필요할 수 있다. 적용할 데이터 분석 방법론을 어느 정도 연구조사를 통해 결정했다고 하더라도, 이렇게 정한 데이터 분석 방법론을 어떤 방식으로 적용할 것인지 찾는 과정도 또 다른 연구조사 과정이 될 수 있다.

이런 이유로 경우에 따라서 데이터 과학 프로젝트는 스크럼 방법론을 적용할 때 릴리즈 플래닝 기간이 길거나, 릴리즈 플래닝을 위한 또 하나의 “릴리즈 전 플래닝(pre-release planning)” 단계를 거쳐야 할 수 있다. 스크럼 방법론 자체가 반복적인 개발 프로세스를 수용할 수 있도록 디자인되어 있기 때문에 이런 릴리즈 전 플래닝을 또 하나의 릴리즈 플래닝 과정으로 생각해서 스크럼 방법론을 적용하는 것은 스크럼 시스템에서 큰 문제가 되지 않는다.

스크럼 방법론에 맞추어 데이터 과학 프로젝트 진행 과정을 설계하고 산출물을 만드는 과정에서 데이터 과학 프로젝트에서 풀어야 할 문제와 해결 과정이 좀더 분명해지면서 자연스럽게 문서화까지 되는 것을 쉽게 확인할 수 있다. 스크럼 방법론을 있는 그대로 적용하지는 못하더라도 스크럼 방법론이 데이터 과학 프로젝트를 좀더 체계적이고 질서정연한 과정으로 만드는 데에 크게 도움이 된다.

2. 소프트웨어 엔지니어들과 협업과 의사소통을 체계적이고 효과적으로 지원할 수 있는 프로젝트 관리 방법론
스크럼 방법론은 기본적으로 소프트웨어 개발을 효과적으로 관리하기 위한 프로젝트 관리 방법론이다. 데이터 과학 프로젝트에 스크럼을 적용하는 것은 스크럼을 이용한 소프트웨어 개발에 데이터 과학 프로젝트가 올라타는 듯한 느낌의 과정이다. 이런 이유로 스크럼 방법론을 데이터 과학 프로젝트에 적용하면 데이터 과학을 위한 분석 소프트웨어 개발과 함께 이를 위한 데이터 엔지니어들의 빅데이터 시스템과 데이터 가공 과정 개발, 데이터 가시화 소프트웨어 개발과 같은 데이터 과학 소프트웨어를 개발하는 과정뿐 아니라, 이들 데이터 과학 소프트웨어 개발 결과물들을 현재의 비즈니스 지원 시스템(BSS), 운영 지원 시스템(OSS)에 통합하는 소프트웨어 개발 과정도 자연스럽게 스크럼 체계 안에서 통합할 수 있다는 장점이 있다.

이런 스크럼 방법론 활용의 장점을 이용해 데이터 과학 프로젝트가 단순히 데이터 분석과 문제 해결로 끝나는 것이 아니라, 데이터 과학 문제를 해결하는 과정에서 얻은 분석 소프트웨어를 BSS와 OSS의 소프트웨어 모듈이나 하위 시스템의 하나로 통합하는 과정까지 데이터 과학 프로젝트의 최종 단계로 포함하여 프로젝트 관리가 가능하기 때문에 보다 더 효과적으로 데이터 과학 산출물을 활용하는 데에도 도움이 된다.

스크럼을 데이터 과학 프로젝트에 적용할 때는 소프트웨어 개발에 스크럼을 적용하는 것과 몇 가지 다른 점을 염두에 두고 소프트웨어 개발팀과의 협업을 관리할 필요가 있다. 스크럼 방법론이 가장 효과적으로 동작하는 팀 구성원 수가 5~10명 미만이라는 것도 고려해서 소프트웨어 개발팀과의 협업을 계획하는 것이 좋다. 대개의 데이터 과학 프로젝트에서 데이터 과학자가 5명 이상 협업하는 경우는 많지 않을 것이므로, 보통 데이터 과학 프로젝트에서 데이터 과학자와 소프트웨어 엔지니어들이 한 스크럼팀으로 일하면서 프로젝트를 진행할 때는 스크럼 방법론으로 협업하는 데 크게 문제가 없다.

다만, 데이터 과학자들의 업무를 사용자 스토리로 기술하기 어려운 경우가 많기 때문에, 데이터 과학자들의 업무를 어떻게 사용자 스토리 형태로 기술하고, 데이터 과학 업무에 대한 사용자 스토리의 작업 규모 추정을 소프트웨어 개발을 위한 사용자 스토리의 작업 규모 추정치와 어떻게 하면 일관성 있고 비슷한 정도의 정확도를 가지고 추정할 수 있을지에 대해서는 데이터 과학자나 데이터 과학 프로젝트 관리자의 고민과 전문성이 많이 동원되어야 한다.

스크럼을 비롯한 애자일 방법론을 적용해 데이터 과학자들과 소프트웨어 엔지니어들과의 협업을 진행할 경우 다음과 같은 것들을 더 고려할 필요가 있다. 데이터 과학자들이 만든 데이터 분석 소스코드가 소프트웨어 모듈의 일부로 통합되는 과정에서 소스코드 품질의 차이로 인해 통합 작업이 원활하지 않을 수 있다. 데이터 과학자들의 데이터 분석 소스코드를 소프트웨어 엔지니어들이 추가 작업하거나, 또는 데이터 분석 산출물을 소프트웨어 모듈화하는 소프트웨어 엔지니어들과 데이터 과학자 간에 생길 수 있는 의사소통과 개발 문화 차이에 따라 팀워크를 유지하기가 쉽지 않을 수 있다. 

소프트웨어 개발과 데이터 과학이 많은 부분 공통점이 있어서 다른 분야의 전문가들보다 상대적으로 협업하기가 수월하다고는 하나, 데이터 과학자들의 업무 진행 방식과 소프트웨어 엔지니어들의 업무 방식을 비교해보면 상대적으로 소프트웨어 엔지니어들의 업무 수행 방식이 데이터 과학자들보다 더 조직적이고 정형화되는 경우가 많다. 소프트웨어 엔지니어들은 소프트웨어 개발의 특성상 개발하려는 대상의 명확성을 추구하는 경향이 있는데, 데이터 과학 프로젝트 초반에는 소프트웨어 엔지니어들이 원하는 수준의 명확성이 데이터 과학 산출물을 만드는 과정에서 제시되지 못할 수 있다. 데이터 과학 프로젝트 초반부터 데이터 과학자들과 소프트웨어 엔지니어들이 협업할 때는 이런 사용자 스토리 정의나 협업 업무를 정의하는 과정에서 서로가 기대하는 명확성의 차이에 따른 소통과 협업 이슈가 원만하게 조율될 수 있도록 프로젝트 관리자나 데이터 과학팀 리더가 많이 신경 쓸 필요가 있다.

데이터 과학 프로젝트가 어느 정도 진행되어 데이터 과학 프로젝트 산출물이 어느 정도 구체화되고, 이를 어떻게 BSS나 OSS에 통합하여 IT 시스템의 일부로서 활용할 것인지 어느 정도 구체적인 논의를 시작할 수 있을 때부터 소프트웨어 엔지니어들과의 협업을 진행하는 것이 일정과 자원 관리 측면에서 더 효과적이다. 데이터 엔지니어나 빅데이터 시스템을 다루는 소프트웨어 엔지니어들과 데이터 과학자와의 협업은 소프트웨어 개발 업무와는 다르게 상대적으로 데이터 과학 프로세스의 일부로 통합하기가 쉽기 때문에 데이터 과학 프로젝트 초반부터 협업하여도 큰 문제가 없다. 오히려 데이터 가공과 분석 이슈를 효과적으로 논의해서 진행하기 위해서는 데이터 엔지니어와 빅데이터 시스템 소프트웨어 엔지니어와의 협업은 적극적으로 진행되는 것이 좋다.

3. 데이터 과학 프로젝트를 진행하면서 필요한 자원과 시스템의 변화와 클라우드 컴퓨팅을 이용한 데이터 과학 인프라 관리의 소프트웨어적 요소를 적극적으로 지원할 수 있는 프로젝트 관리 방법론
데이터 과학 프로젝트를 진행하다 보면 프로젝트 초반에 데이터 과학에 필요한 데이터를 모두 수집했거나 가공해 놓은 상태에서 프로젝트를 시작하는 경우는 매우 드물다. 데이터 분석을 진행하는 과정에서 추가로 필요한 정보가 발견되어 추가 데이터 수집과 가공이 필요한 경우도 많고, 어느 정도 축적된 데이터셋을 대상으로 데이터 분석을 일차적으로 진행한다고 하여도, 데이터의 맥락과 의미를 구체적으로 파악하기 위해 다른 데이터 셋이나 데이터 소스를 활용하여야 하는 경우도 많다.

이렇기 때문에 데이터 과학에 필요한 데이터 분석 인프라를 필요한 만큼 갖추어 놓고 프로젝트를 시작하는 경우가 매우 드물고, 어느 정도 양과 가공 수준의 데이터를 다루어야 할지 분명하지 않은 경우도 많기 때문에 데이터 가공과 분석에 필요한 인프라의 규모와 수준이 어느 정도인지 정하기도 쉽지 않은 경우도 많다. 이런 이유로 데이터 과학 프로젝트에서는 프로젝트의 기민성과 데이터 과학 프로젝트의 심화 과정에서 생기는 IT 인프라의 추가 요구 사항에 기민하게 대응하기 위해 클라우드 컴퓨팅을 사용하는 것이 필요하다.

클라우드 컴퓨팅 서비스의 시작이 가상 머신 인스턴스를 서비스하는 것과 함께 빅데이터를 위한 저장소와 질의 서비스로부터 시작되었다는 것은 결코 우연이 아니다. 이전 아홉번째부터 열네번째 글에서 같이 살펴본 것같이 CERN의 LHC 빅데이터 분석에서 탄력적인 자원 활용의 필요성 때문에 CERN에서 클라우드 컴퓨팅 기술의 요구사항이 처음으로 발견되고 개발되기 시작하였다. 클라우드 컴퓨팅이 가장 필요하고 효과적으로 활용될 수 있는 분야가 빅데이터 분석인 것을 생각해보면 빅데이터를 활용한 데이터 과학 프로젝트에서 클라우드 컴퓨팅 인프라 활용 계획과 관리가 프로젝트 관리의 주요 내용으로 반드시 포함되어야 하는 것은 전혀 이상하지 않다.

더군다나 빅데이터 인프라의 대부분은 분산 컴퓨팅 시스템이기 때문에 데이터 과학 프로젝트를 진행하다가 그때그때 필요한 서버와 네트워크 인프라, 분산 컴퓨팅 소프트웨어를 일일이 설치, 구축해가면서 프로젝트를 진행하여야 한다면 프로젝트의 기민성과 스피드도 많이 떨어지고, 지나치게 많은 비용이 들 수도 있다. 클라우드 컴퓨팅을 활용한 데브옵스와 자동화도 데이터 과학 프로젝트의 일부로서 같이 고려되는 것이 바람직하다.

클라우드 컴퓨팅을 활용하면 조직과 비즈니스 도메인에 따라 자주 활용되는 데이터 가공, 분석 인프라와 환경을 만드는 과정을 템플릿화하고 설치, 구축과정을 소프트웨어로 자동화할 수 있기 때문에 빅데이터 인프라를 다루는 과정도 쉽게 소프트웨어 프로젝트와 같이 다루고 관리할 수 있다. 데이터 과학 프로젝트의 요구 사항과 분석 과정에서의 추가 요구 사항과 인프라 변경에 대한 기민한 지원과 대응을 위해서라도 클라우드 컴퓨팅을 다루는 소프트웨어 엔지니어가 데이터 과학 프로젝트팀에 초반부터 같이 합류하는 것이 좋다.

탐색적 분석이 자주 일어나고 문제 정의를 위한 다양한 시도가 일어나는 데이터 과학 프로젝트 초반에 특히 이런 임의적인(ad-hoc) 데이터 분석 시스템 자원 요구 사항이 자주 발생할 것이기 때문에 클라우드 컴퓨팅을 활용한 데이터 가공, 분석 인프라 자원 관리 요구 사항을 적극적으로 수용할 필요가 있다. 이를 위해서는 정기적으로 데이터 과학 프로젝트의 진척사항과 추가 요구 사항을 프로젝트팀원들이 같이 협의하고, 필요한 컴퓨팅 자원과 시스템을 어떻게 마련하면서 프로젝트를 진행할 것인지 논의하는 자리가 공식적으로 필요하다. 애자일 프로젝트 관리 방법론을 활용하면 이렇게 데이터 과학에 필요한 인프라와 IT 자원을 어떻게 마련하고 활용할 것인지 논의하고 계획할 수 있는 정기적인 회의를 스프린트마다 가질 수 있기 때문에 효과적으로 IT 인프라와 자원의 변경과 추가 요구 사항에 적극적으로 대응할 수 있다.

보통 4~6주마다 가지는 스프린트 계획 회의 및 스프린트 리뷰 회의를 통해서 데이터 과학자, 데이터 엔지니어, 빅데이터 시스템 소프트웨어 엔지니어, 서비스 및 비즈니스 정보 시스템 소프트웨어 엔지니어, 인프라 엔지니어들이 같은 자리에 모여서 다음 스프린트를 위한 개발 내용과 데이터 분석 내용을 같이 검토하고 이를 위한 클라우드 컴퓨팅 시스템 구축 내용을 같이 검토, 실행한다면 인프라부터 데이터 분석까지 짜임새 있는 프로젝트 계획 및 관리가 가능해진다.

지금까지 살펴본 바와 같이 스크럼과 애자일 방법론은 소프트웨어 개발뿐 아니라 데이터 과학 프로젝트를 위해서도 효과적으로 활용이 가능하다. 그뿐만 아니라, 빅데이터를 활용한 데이터 과학 프로젝트 특성상 반드시 일어날 수밖에 없는 소프트웨어 엔지니어, 데이터 엔지니어, 인프라 엔지니어와의 협업을 위한 의사소통도 체계적으로 계획하고 실행할 방법론을 제공한다.

 스크럼 방법론을 적절하게 활용해 데이터 과학 프로젝트를 체계적으로 수행한다면 산출물과 분석 결과의 고객과의 정기적인 공유를 통해 고객에게 신뢰를 얻을 수 있다. 프로젝트의 특성상 프로젝트 진행 과정이 눈에 잘 보이지 않고 정보 공유가 어려운 데이터 과학 프로젝트의 성과와 진척상황을 프로젝트 구성원들이 효과적으로 소통하여 공유할 수 있으며, 이를 통해서 다양한 기술 배경을 가진 프로젝트 구성원들이 협업하여 프로젝트 목적을 달성할 수 있다.

프로젝트 관리를 위한 정기적인 회의와 이런 정기적인 회의를 통해 나오는 산출물들, 그리고 다양한 배경을 가진 프로젝트 구성원 간의 회의와 다양한 통로를 이용한 소통의 중요성은 이미 지난 스물세번째 글에서 자세하게 소개한 바 있다. 이런 소통과 협업이 스크럼을 통해 좀더 체계적이고 구체화되는 것이다. 

CERN과 LHC 프로젝트의 연구자들이 정기적으로 논문을 작성, 발표하고 컨퍼런스 등의 학술회의에 모여 성과를 발표하는 이유는 연구 성과 홍보와 함께 프로젝트를 위한 의사소통과 정보 교환이 주목적이다. 이에 더해, 또 하나 더 중요한 이유는 논문과 학술 보고서, 학술회의 발표 논문을 작성하면서 현재 연구하고 있는 주제의 현황을 다른 연구자들과 정리, 공유하여 연구자 자신이 연구를 통해 잘 알고 모르는 점에 대한 생각을 정리하고, 논문을 통한 새로운 아이디어의 공유와 집단적인 비판적 사고를 통해 연구자 전체의 집단 사고력을 높이는 것이다.

기업에서의 데이터 과학도 마찬가지 원리가 적용될 수 있다. 불필요한 프로젝트 산출물 문서 작업은 지양하고 데이터 분석과 소프트웨어 개발에 집중할 시간을 최대한 보장해주는 것이 바람직하기는 하다. 그렇지만, 프로젝트를 통해 얻은 현재까지의 분석 결과와 통찰을 프로젝트 구성원과 프로젝트 결과를 활용할 조직 구성원과 경영진에게 문서의 형태로 주기적으로 공유하는 것은 데이터 과학자가 자기 생각을 명료하게 하는 데에도 도움이 된다. 이와 함께, 산출물의 내용을 엄밀하게 검토하는 과정에서 프로젝트 외부의 관련 구성원들과 경영진들도 데이터 과학 결과물을 어떻게 활용할 것인지 좀더 비판적이고 구체적인 논의가 가능해지기 때문에 조직 차원에서의 문제 해결 역량과 사고 능력의 수준이 향상된다.

스크럼과 애자일 방법론을 통해서 데이터 분석 현황에 대한 산출물을 정기적으로 고객에게 공유하게 되면 설사 고객이 산출물을 모두 검토하지는 않더라도 데이터 과학 프로젝트를 통해 꾸준하게 성과물과 진척이 이루어지고 있다는 인상을 줄 수 있다. 이렇게 꾸준한 성과물로 데이터 과학의 효과에 대해 아직 확신이 없는 고객을 안심시키고 데이터 과학 프로젝트를 수행하는 팀의 성실성에 대한 긍정적인 인상을 주어 고객과의 관계 개선에도 긍정적인 효과를 줄 수 있다.

소프트웨어 개발의 본질에 집중하고 체계적으로 일정 및 자원을 관리하며, 반복적인 소프트웨어 개발을 통한 품질 향상과 체계적인 프로젝트 위험 관리를 할 수 있게 돕는 애자일 프로젝트 관리 방법론을 통해서 데이터 과학자들은 소프트웨어 엔지니어, 데이터 엔지니어, 인프라 엔지니어들과 체계적으로 협업하여 데이터 과학 프로젝트를 성공으로 이끌 수 있다.

기업에서 데이터 과학자만 영입한다고 빅데이터를 쉽게 활용할 수 있는 것은 아니다. 데이터 과학자들이 체계적으로 프로젝트를 관리하고 일할 수 있는 제도와 시스템을 구축하는 것도 중요하다. 데이터 과학 프로젝트를 어떻게 진행하고 관리할지 아직 구체적인 생각이 없는 기업에서 애자일 방법론을 통한 협업과 프로젝트 관리를 통해 좀더 구체적으로 데이터 과학을 활용하고 관리할 수 있을 것이다. 최근 애자일 방법론을 채용하는 IT 기업들이 늘어가면서 애자일 방법론을 컨설팅하고 코칭하는 전문 컨설팅 기업들도 많이 생겨났다. 애자일 방법론을 실행하는 데에는 많은 비용이 필요하지도 않으니 좀더 효과적이고 구체적인 데이터 과학 프로젝트 관리를 원하는 기업들은 애자일 방법론 도입을 꼭 검토해 보자.

[참고문헌]
[1] 김진철, “LHC에서 배우는 빅데이터와 machine learning 활용 방안”, 2016년 9월 28일, A CIO Conversation for Technology Leadership – Breakfast Roundtable 발표 자료
[2] 마이크 콘, “경험과 사례로 풀어낸 성공하는 애자일”, 인사이트, 2012.
[3] Mike Cohn, “Succeeding with Agile” Addision-Wesley, 2010. ([2]의 영문 원전)
[4] 마이크 콘, “사용자 스토리”, 인사이트, 2006.
[5] 조너선 라스무슨, “애자일 마스터”, 2012.
[6] 헨릭 크니버그, “스크럼과 XP”, 인사이트, 2009.
[7] 켄 슈와버, “엔터프라이즈 스크럼 - 사례에 기반한 기업 차원의 스크럼 도입과 활용 에이콘 애자일 시리즈 3”, 에이콘출판, 2010.
[8] 켄 슈와버, “Agile Project Management with Scrum(한국어판)”, 에이콘출판, 2012.

*김진철 박사는 1997년 한국과학기술원에서 물리학 학사, 1999년 포항공과대학교에서 인공신경망에 대한 연구로 석사 학위를, 2005년 레이저-플라즈마 가속기에 대한 연구로 박사 학위를 받았다. 2005년부터 유럽입자물리학연구소(CERN)의 LHC 데이터 그리드 구축, 개발에 참여, LHC 빅데이터 인프라를 위한 미들웨어 및 데이터 분석 기술을 연구하였다. 이후 한국과학기술정보연구원(KISTI), 포항공과대학교, 삼성SDS를 거쳐 2013년부터 SK텔레콤에서 클라우드 컴퓨팅과 인공지능 기술을 연구하고 있다. 빅데이터와 인공지능 기술의 기업 활용 방안에 대해 최근 다수의 초청 강연 및 컨설팅을 수행하였다. ciokr@idg.co.kr