정보컴퓨터공학부 201924657 장원석

요약

 애자일이란 폭포수 방법론의 실패로부터 탄생한 소프트웨어 개발 방법론이다. 스크럼은 애자일 가치를 누구나 실천할 수 있도록 돕는 애자일의 한 갈래로서 정형화된 활동과 산출물을 제시한다. 결국 그 핵심은 애자일 가치를 추구하는 데에 있는데, 성공적인 도입을 위해서는 팀의 특성에 맞게 유연하게 적용하는 기지가 필요하다. 이번 조사에서는 성공적인 애자일 도입을 위한 방향을 제시하고자 스크럼의 특징과 실무 도입 사례를 살펴본다.

1. 서론

1.1 조사 배경

 소프트웨어 개발 방법론에는 여러 가지가 있으나 그중 특히 폭포수와 애자일이 많이 언급된다. 폭포수 모델은 오래 전부터 사용되어 온 전통적인 방법론으로, 프로젝트 초기에 모든 요구사항의 파악과 완성형 기획안을 요구한다. 애자일은 이 폭포수의 실패로부터 탄생한 방법론이다.

 학부 동아리에서 기획자, 디자이너와 팀을 이루어 학기 중 프로젝트를 진행한 적이 있었다. 동아리 운영진은 기획 완성, 디자인 완성, 개발 착수 순으로 하는 폭포수 일정을 제시했고, 당시 진행했던 4개 팀 중 프로젝트를 기획안대로 완수한 팀은 한 팀도 없었다.

 폭포수 모델을 따르면서 미숙한 팀은 외주 프로젝트나 다름 없었고 그 과정과 결과 모두 좋지 않았다. 프로젝트에 대한 공통된 기준이나 공감대를 형성하기 어려울 뿐더러 기획은 디자인에게, 디자인은 개발에게 일감을 주문하는 형식이었다. 배움의 요람이 되어야 할 학부 과정에서 학기에 걸쳐 이런 폐단을 겪는 것은 결코 바람직하지 않다고 생각한다.

 이에 대한 대안으로 스크럼 방법론을 제시하고 실무 적용 사례를 소개하고자 한다.

1.2 배경지식

1.2.1 애자일(Agile)

 애자일이란 폭포수에 대비되는 용어로 2000년대 들어서 소프트웨어 개발에 처음 사용되었다. 켄트 벡(Kent Beck)과 로버트 마틴(Robert Martin)을 포함한 저명한 개발자들이 ‘경량 프로세스’에 대해 논의 후 [표 1]과 같이 애자일 선언문을 정리하고 이것을 ‘애자일’이라 정의한 것이 그 시작이다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

< 표1. 애자일 선언문 전문¹ >

 또한 애자일 선언문에 더해 보조 설명으로 12가지 원칙을 제시한다². 동기부여된 팀원, 짧은 배포 주기, 요구사항 변경 수용 등이 그것이다. 이처럼 애자일의 실체는 변화에 기민하게 대응하기 위한 가치와 원칙들이며, [표2]와 같이 실무에 도입하기 위한 다양한 구체적 실천 방법론이 별도로 존재한다.

< 표2. 애자일 실천 방법론들의 대표 특징 비교표 >

 위의 애자일 실천 방법 중 가장 널리 알려지고 빈번하게 적용되는 방법은 스크럼(Scrum)이다. 16th State of Agile 보고서에 따르면 애자일을 경험해본 조사 대상자의 약 87%가 실무에 스크럼을 활용한다고 답했다³.

1.2.2 스크럼(Scrum)

< 그림1. 스크럼 프로세스, 출처: www.scrum.org/resources/what-scrum-module >

 스크럼의 중요한 특징은 짧은 주기로 정형화된 팀 활동을 반복한다는 점이다. 프로젝트 초기에 최소제품과 유저스토리를 식별하여 제품 백로그를 작성하고, 우선순위에 따라 스프린트(반복 주기) 동안 진행할 항목을 스프린트 백로그에 옮긴다. 이후 약 4주 이내로 기간을 정해 스프린트에 착수한다.

 ‘스프린트’란 개발이 진척되는 기간으로, 스프린트 중에는 투명한 업무 공유를 위해 수시로 데일리 스크럼이라는 회의를 한다. ‘데일리 스크럼 회의’는 약 15분 간 진행하면서 그동안 한 일과 문제점, 장애 요소를 공유하는 약식 회의이다. 스프린트가 종료되는 시점에 사용자에게 제품을 시연하는 ‘스프린트 리뷰’ 활동 및 개선할 점을 논의하는 ‘스프린트 회고’ 활동을 진행한다. 상황에 따라 스프린트 중 제품 백로그에 유저 스토리를 추가하거나 기존 공수 추정을 수정하는 ‘백로그 정제’ 회의를 진행할 수 있다.

1.3 비교 방법

 정보통신산업진흥원은 ‘SW중소기업을 위한 경량 개발 방법론’(2018년)에서 애자일 도입의 성공 기준을 다음과 같이 정의하였다.

• 애자일 적용을 통하여 출시기간 단축 등 비즈니스 효과가 나타나고 있는가?
• 고객을 포함한 경영진과 직원 모두 만족도가 향상되고 있는가?
• 조직 차원에서 애자일 업무 방식이 지속적으로 유지되고 있는가?

 따라서 위 세 가지 관점을 참고하여 ‘생산성’, ‘비용 절감’, ‘적기 출시’, ‘내부 만족도’, ‘고객 만족도’, ‘지속성’의 6가지 항목에서 본론의 사례를 비교하고자 한다.

1. 본론

2.1 Dutch Railways⁴

2.1.1 도입 배경

 Dutch Railways는 네덜란드의 철도 운송 회사로, 하루 평균 열차 이용객 수는 120만명에 이른다. 여행객들에게 보다 정확한 여행 정보를 제공하기 위한 노력의 일환으로 새로운 중앙 정보 시스템 ‘PUB’을 구축하기로 결정한다. 초기에는 외주 개발사에 세부 요구사항을 전달하고, 폭포수 방식으로 프로젝트를 관리했으나 3년에 이르는 기간 동안 개발사가 작동하는 시스템을 내놓지 못하여 결국 취소되었다. 이에 Scrum 방법론을 도입해 고객 피드백을 적극 수용하고 점진적 작업에 중점을 두어 새로 프로젝트를 시작하기로 한다.

2.1.2 도입 과정

 먼저 프로젝트 초기 3주의 준비 과정을 거쳐 팀원의 역할, 스프린트 주기, 초기 요구사항을 정리했다. 총 7명의 팀원 중 프로덕트 오너와 설계자(개발 책임자), 스크럼 마스터를 두고 2주 간격으로 스프린트를 진행하기로 합의하였다.

 첫 스프린트는 팀 활동이 주를 이루었다. 페어 프로그래밍 방법, 핵심 개발시간 정의, 코드 퀄리티 합의 등을 이루고 문서를 작성해 공유했으며, 스프린트 회고에서 수정되는 사항은 즉각 반영했다. 유저 스토리는 한 줄 제목과 프로덕트 오너의 기능 설명으로 구성했다.

 스크럼 팀은 기능 개발팀과 아키텍처 팀으로 나누어 기능 팀은 유저 스토리 구현에 집중할 수 있도록 했다. 아키텍처 팀은 신뢰성, 보안성, 모니터링 등 고객측 비기능 요구사항을 파악하고 유저 스토리로 변환하는 데에 중점을 둔다. 그러나 고객사 요청에 따라 MIL 양식의 요구사항 문서를 작성해야 하는 탓에 외부 Technical Writer를 따로 두었다.

 스프린트 리뷰에서 시스템의 핵심 기능을 고객에게 시연할 수 있었다. 이전 시도에 비해 프로젝트 경과가 더 빠르게 공유되고, 고객의 통제력이 높아졌기 때문에 이는 고객과 팀 서로 만족스러운 결과로 이어졌다. 몇 번의 스프린트 이후 개발 인력을 추가로 고용했는데, 5명 단위의 스크럼 팀을 구성하고 QA 테스터가 중간에서 조율하는 형태로 확장하였다.

2.2 컬리⁵

2.2.1 도입 배경

 컬리는 식품 판매와 화장품 판매를 전문으로 하는 온라인 쇼핑몰로, 직책을 최소화하고 직급에 관계 없이 전문성과 독립된 결정권을 존중하는 기업문화를 갖고 있다⁶. 개개인의 개성과 자율성을 중시하기 때문에 업무를 함에 있어서 개인 성향이 잘 드러나 이를 효율적으로 중재할 수단이 필요했다. 더욱이 기능 단위로 분배해 작업하는 탓에 개발팀 전체의 도메인 이해도가 낮은 문제가 있었다.

2.2.2 도입 과정

 팀은 약 7명 내외로, 구성원은 프로덕트 오너와 스크럼 마스터, 개발진으로 나뉜다. 스프린트 시작 전 배포 요일, 티켓 작성법, 회의 방식 등 팀의 협업 방식을 합의해 공유하였으며 스프린트 주기는 2주 단위, 배포는 1주 단위로 정했다. 스프린트는 스프린트 계획, 백로그 정제, 데일리 스크럼 회의. 배포, 스프린트 회고 순으로 진행된다.

 스프린트 계획에서는 팀원의 가용 스토리 포인트를 계산하고 그 안에서 유저 스토리를 선택한다. 유저 스토리는 백로그 정제에서 추가되는데, 1주 단위로 모여 약 1시간 30분 동안 새로운 유저 스토리를 설명하고 PlanItPoker라는 플래닝 포커 서비스를 통해 공수를 추정한다. 스프린트의 끝에 스프린트 회고에서는 좋았던 것, 지양할 것, 새로 시도할 것으로 나누어 익명으로 항목을 작성해 나열한 후 이모티콘으로 순위를 매기고 다음 스프린트를 준비한다.

 스크럼을 경험한 컬리의 개발자는 공통의 목표를 설정해 한 팀으로 일하는 점, 피드백 시간을 정해 스프린트 동안에는 목표 달성에만 집중할 수 있다는 점, 유저 스토리 공수 추정을 통해 개발진이 주도적으로 업무의 일정을 산정할 수 있다는 점 등에서 만족감을 드러냈다.

2.3 Salesforce⁷

2.3.1 도입 배경

 Salesforce는 클라우드 컴퓨팅 서비스 형태로 고객 관리 솔루션을 제공하는 기업이다. 시장에서 지배적인 위치에 있는 것과 달리 배포는 매년 주요 업데이트 1개만 가능했고, 인력이 늘어날수록 생산성은 줄어들고 있었다. 기술 임원 Chris Fry는 회사 업무가 폭포수로 진행되면서 다음과 같은 문제가 발생한다고 지적했다.

• 정확하지 않은 전체 개발기간
• 가시적인 결과물의 부재
• 릴리즈에 다가서야 이루어지는 늦은 피드백
• 길고 예측이 어려운 릴리즈 일정

 당시 회사는 기능별 팀으로 조직화되어 사용자경험, 제품개발, 제품관리, 문서화 등 기능별로 진행되는 폭포수 방식을 따르고 있었다. 작은 전문가 그룹일 때에는 효과적이었지만 회사가 커지면서 대규모 조직을 관리하기에는 적합하지 않았고, 애자일을 도입하기로 결정한다.

2.3.2 도입 과정

 Salesforce에서는 스크럼과 XP를 함께 교육하면서 스크럼 형식보다 애자일 가치를 지키는 데에 중점을 두었다. 업무 평가의 초점을 팀 단위 처리량에 두었으며 애자일 비전과 컨벤션, 유저스토리 공수 추정 방식, 릴리즈 완성도 지표 등을 팀원 전체가 보고 수정할 수 있도록 공유했다. 스프린트는 회사 전체에 대해 4주, 내부 팀에 대해 2주 간격으로 진행하는데, 스프린트 회고는 전사적으로 4주마다 시행했다. 배포는 스프린트마다 내부 릴리즈를 하고 이것이 쌓여 비즈니스 정책에 따라 큰 공개 릴리즈를 결정한다.

 Salesforce의 애자일 프로세스는 스프린트, 스프린트 계획, 데일리 스크럼, 스프린트 회고 순으로 스크럼 형식을 따르지만 투명한 업무 공유와 교육에 더 많은 시간과 비용을 투자했다. 개발 조직, QA팀, UX팀 등 각 팀의 임원진이 스크럼 도입팀을 구성해 직원들에게 전사적인 트레이닝, 교육을 제공했고 각 팀은 항상 투명하게 회의 내용을 공개하고 피드백을 받았다. 개발 조직은 대규모 자동화 도구와 빌드 시스템을 적극적으로 활용하면서 ‘지속적인 통합과 릴리즈’에 많은 노력을 기울였다.

 이렇게 도입한 스크럼은 3개월 만에 릴리즈 횟수 증가, 버그 약 1500개 감소, 사용자 기능 업데이트, 팀의 역량 파악 및 관리라는 가시적 성과를 나타냈다. 단, 임원진이 도입을 주도하면서 증가한 생산성에 비례해 릴리즈 범위까지 늘어나는 부작용이 있기도 했다.

2.4 Intel⁸

2.4.1 도입 배경

 인텔은 수십 년간 반도체 시장 1위를 유지하고 있는 거대 반도체 제조 기업이다. 하지만 내부적으로 개발 조직은 오랜 폭포수 문화로 인해 팀간 소통 부족, 만성적 업무 과중, 낮은 사기, 높은 이직률 등 여러 문제가 적체돼 있었다. 테스팅 환경이 구비되지 않은 것은 물론 개발 도구 또한 오래된 컨벤션을 따르고 있어 신제품이나 개선된 제품을 제때 제공하기 어려웠다. 경영진은 여기서 스크럼을 활용한 애자일을 도입하기로 한다.

2.4.2 도입 과정

 인텔의 애자일 팀은 프로덕트 오너, 스크럼 마스터, 개발진에 더해 애자일 매니저로 구성된다. 애자일 매니저는 팀장의 위치에서 비전과 전략을 제시하고 스크럼 도입/유지를 모니터링하는 역할이며 스크럼 마스터는 스크럼 활동을 주도하여 진행하는 역할이다. 스프린트 시작 전에 전체 팀은 컬리의 사례와 같이 협업 방식을 논의하고 ‘working agreement’ 문서를 작성해 공유한다. 스크럼 활동은 스프린트 계획, 백로그 정제, 데일리 스크럼 회의, 스프린트 리뷰, 스프린트 회고 순으로 진행된다.

 인텔은 애자일의 점진적 적용을 위해 3단계로 도입 단계를 구분했다. 첫 단계는 준비 단계로, 외부 애자일 전문가를 초빙해 ‘Process Action Team’을 구성하고 직원 교육과 스크럼 경과 모니터링을 담당하게 하였다. 다음은 적응 단계로, 스크럼 활동 산출물을 리뷰하고 기존 방법으로 회귀하려는 팀을 재교육 하는 단계이다. 마지막은 제조 팀과 융합 단계로, 도메인이 다른 팀끼리 업무가 단절되는 문제를 방지하고자 팀과 팀 사이에 통합 테스트 환경을 구축한다.

 스크럼 도입 3개월 이후 처음과 비교하여 생산성과 배포 범위, 만족도에서 유의미한 개선을 관찰할 수 있었다. 유저 스토리 처리 속도는 약 26% 증가했고, 릴리즈에 실패하는 유저 스토리의 수는 31% 감소했으며, 스프린트 회고에서 보고하는 만족도는 25% 상승했다.

3. 결론

< 표3. 스크럼 도입 사례의 주요 지표 비교⁹ >

 위와 같이 성공적인 애자일 도입 사례 4가지를 살펴보았다. 4개 기업 모두 폭포수 환경에서는 팀 간 소통이 단절되는 ‘Functional Silo’ 현상과 지속적인 릴리즈 지연을 겪고 있었고, 이를 해소하기 위해 도메인 위주 팀을 구성하는가 하면 전체 팀 활동을 장려하고 QA 테스팅을 매개로 팀 간 유기적 관계를 유도했다.

 한편, 커뮤니케이션 비용과 조직 유지 비용은 증가했음을 알 수 있는데, 투명하게 업무를 공유하고 여러 주기적 회의에 참석해야 한다는 점과 애자일 코치, Technical Writer를 추가로 고용한다는 점에서 그렇다. 이것은 스크럼 팀이 유저 스토리 구현에 집중하기 위한 방편이므로 높아진 생산성을 고려한다면 그만한 가치가 있다고 하겠다. Salesforce의 경우 임원진에 의해 개발 업무가 오히려 가중되는 부작용이 있었다.

 사례를 통해 살펴본 바, 스크럼의 핵심은 팀이 사용자 가치를 전달하는 데에 집중할 수 있게 하고 소통과 피드백을 통해 불필요한 절차와 과정을 없애 생산성을 높이는 데에 있다. 전문성이 부족한 학부생 입장에서 경량화된 스크럼을 적용하거나 애자일 가치를 추구하며 프로젝트를 진행한다면 프로젝트 성공 여부에 관계없이 긍정적인 협업 경험을 얻을 수 있으리라 기대한다.

참고 문헌

• Digital.ai, “16th State of Agile Report”, 2022
• Patrick Elwer, “Intel IT: Agile Scalability & Transformation”, Intel, 2022
• Robert C. Martin, “Clean Agile”, 2019
• 정보통신산업진흥원, “SW중소기업을 위한 경량 개발 방법론”, 2018
• Chris Fry 외 1명, “Large Scale Agile Transformation in an On-Demand World”, IEEE, 2007