데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
패러다임으로 발전 하고 있는 Agile 그 한계를 극복하다 오민석 현재 Agile방법론은 기존의 객체지향방법론이 그랬던 것처럼 단순한 방법론을 넘어 하나의 패러다임으로 발전되어 가고 있다. 패러다임이란 어떤 한 시대의 사람들의 견해나 생각을 지배하고 있는 이론적 틀이나 개념적 집합체를 말한다[1]. 이제 SCRUM, XP 등의 Agile 방법론은 소프트웨어를 개발하기 위한 분석, 설계, 개발, 테스트, 운영에 이르는 소프트웨어 개발 생명주기상의 Process, Method, Artifact, Tool에 대한 영역 뿐만 아니라 이를 위한 조직의 구성과 역할 및 책임, 프로젝트 관리, 심지어 기업의 Style, 비지니스 전략에 까지도 영향을 미치며 많은 영역에서 활용되고 있다. 그러나 Agile방법론이 진정한 패러다임으로 정착되기 위해서는 Agile방법론의 한계로 지적 받아 오고 있던 몇가지 커다란 숙제를 해결 해야만 한다. Agile방법론에 대해 개발자들이나 프로젝트 관리자들은 몇가지 의문을 가지고 있다. 그 중 큰 두가지 이슈는 첫째, 대규모 프로젝트에 대해 Agile방법론이 효과적으로 적용이 가능 한가 이다. Agile방법론은 Sweet Spot(5-9명정도)의 단일 Team이 하나의 Product Backlog을 분할 하여 반복적인 Sprint나 Iteration을 통해 제품을 완성해 나가는 방법론이다. 그러나, 최근 대규모의 프로젝트들은 수백명 심지어 수천 명에 이르는 인원이 참여하는 프로젝트가 흔하다. 과연 이러한 프로젝트들을 Agile방법론에서 효과적이고 효율적으로 대응할 수 있느냐 하는 문제이다. Agile 방법론에서는 현재 다양한 Scaling Framework을 사용하여 대규모 프로젝트에서 다수의 팀과 많은 인원들이 효과적이고 효율적으로 프로젝트를 수행 할 수 있도록 하고 있다. 이 장에서는 주요한 몇가지 Scaling Framework에 대해 살펴보고, 이를 통해 어떻게 Agile방법론에서 대규모 프로젝트에 대한 한계를 극복하는지 살펴 볼 것이다. 기존의 방법론 또는 다양한 프로젝트 환경에서의 필수 요구사항 및 활동을 Agile방법론으로 마이그레이션 할 수 있어야 다양한 특성의 신규 프로젝트 뿐만이 아니라 유지보수 환경에서의 소프트웨어개발의 지원 등 다양한 환경에서의 프로젝트를 Agile방법론을 통해 수행하는 것이 가능하다. 현재 Agile방법론은 대규모 프로젝트를 위한 Scaling 프레임워크와 기존 방법론 또는 특정한 환경 에서 필요한 필수 요구사항들 또는 활동들을 Agile방법론으로 융합할 수 있는 메커니즘을 사용하여 기존에 Agile방법론의 한계로 지적 받던 이슈를 해결하고 한계를 극복하고 있다. 이러한 정황에서 우리는 Agile 방법론이 어떤 제품을 개발하기 위한 특정한 프로세스나 기법이 아니고 오히려 다양한 프로세스나 기법을 Agile사고 방식과 철학을 기반으로 사용할 수 있도록 틀을 제공하는 프레임워크서 더욱 유용 하다는 사실을 자각해야 할 것이다. 이미 해외 글로벌 IT기업들은 대부분 Agile 방법론을 채택하고 있고, 프로젝트 관리를 위해 PM을 교육하고 인증하기 위한 PMBOK의 6th Edition에는 Agile방법론이 전반적으로 융합되어 소개되고 있다. 이는 Agile 방법론이 이미 다양한 분야에 영향을 주고 있음을 반증하는 사례라고 할 수 있겠다. 이러한 점을 고려할 때 Agile 방법론은 이미 단순한 방법론을 넘어 하나의 패러다임으로 진화하고 있다고 확신할 수 있으며 각 기업과 조직들은 빠르게 밀려오는4차산업혁명의 물결 속에서 Agility하게 Digital Shift하기 위한 방법론과 전략의 일환으로 보다 깊게 Agile방법론을 연구하고 적용하며, 새로운 시도를 함에 있어 주저하지 않아야 될 것이라고 사료된다. Reference패러다임으로 발전 하고 있는 Agile 그 한계를 극복하다
소속 (주)에스피컨설팅
경력사항 現)(주)에스피컨설팅 대표이사
前)(주)위메프 정보화개발실 실장
정보관리기술사
데이터 기획, 분석, 시각화
Technical Architect
Software Architect
1. 서론
이에 본고에서는 Agile 방법론의 한계점으로 지적되어 온 이슈에 대해 짚어 보고 Agile방법론에서 이러한 이슈를 어떻게 해결하고 있는지 확인하여, Agile 방법론이 단순히 일정 수준 발전하다가 대체되는 과정으로서의 소프트웨어 방법론이 아니라 한 시대를 풍미하는 패러다임으로 완숙 될 것인가에 대해 고찰해 보도록 할 것이다.
2. Agile 방법론의 주요 이슈와 대응 방안
둘째, 기업이나 조직에서 사용하고 있던 기존 방법론에서의 핵심적이고 필수적인 Requirements, Activity나 산출물에 대한 마이그레이션 이슈이다. 방법론을 바꾸더라도 버릴 수 없는 필수적인 활동들이나 산출물이 있다. 또한 Agile방법론은 신규 프로젝트에서만 적용 가능하다는 의견들도 있다[10]. 이러한 이슈를 해결하기 위해서는 Tailoring과정에서 이러한 여러가지 Context에서 필요한 핵심 요구사항과 활동들을 Agile 방법론 안에 녹여 넬 수 있어야 한다. 그러나 Agile방법론은 이전의 방법론들과는 그 접근 철학과 Style이 너무도 달라, Tailoring 과정에서 이러한 필수 요구사항과 활동들을 Agile 방법론으로 어떻게 마이그레이션 할 수 있는가에 대해 실제 적용 현장에서는 고민 되지 않을 수 없다.
Agile방법론이 현실적으로 다양한 환경의 프로젝트에서(신규 제품의 개발 및 유지보수 프로젝트를 포함하여) 그 효과를 발휘하기 위해서는 이러한 두가지 문제는 반드시 해결 해야만 할 과제이다.
3. 대규모 프로젝트 적용 한계 극복방안
3.1. LeSS(Large Scale SCRUM)의 개념과 메커니즘
LeSS는 하나의 Product을 위한 많은 팀에 적용되는 SCRUM이다. 그러나, LeSS는 완전히 새롭거나 획기적으로 재구조화 된 새로운 SCRUM이 아니다. LeSS는 대규모의 환경에서 SCRUM본연의 원리와 목표를 잘 반영하기 위한 Experiments, Guides, Frameworks, Principles을 제공함으로서 대규모 프로젝트에서도 SCRUM본연의 철학과 원리를 충실히 적용하도록 하는 SCRUM이다. 이 중 Experiments와 Guides 필수 요소는 아니다. 그러나 LeSS는 실험을 통해 기존의Best Practices가 주는 환상을 깨고 어떤 Context에서 어떤 Practices가 최선의 Practices인지 발견할 수 있도록 한다. 이 과정에서 가이드는 하나의 팁과 같은 역할을 하며 프레임워크와 원칙은 지켜야 할 최소한의 틀과 규칙을 제공한다.
그림 1은 LeSS의 프레임워크 구성도를 보여주고 있다.
[그림1] LeSS의 Framework [3][4]
LeSS에는 아래와 같은 두가지 프레임워크가 있다.
① LeSS. 2~8개의 Team들로 구성된 스크럼
② LeSS Huge. 8개 이상의 Team팀과 2,000명 이상의 대규모 인원 참여 가능한 스크럼
그림 2은 LeSS의 원칙을 보여주고 있다.
[그림2] LeSS의 Principles [3][4]
① Large-Scale Scrum is Scrum
-LeSS는 스크럼의 원리, 규칙, 요소 및 목적을 대규모 프로젝트에서도 보다 충실히 하도록 하는 스크럼이다.
② Transparency
-작업을 수행하는 사람들과 점진적 작업에 대해 검증하는 사람들은 “완료(Done)”에 대한 정의를 공유해야 한다.
③ More with less
-LeSS는 대규모 개발에서 필수적인 것을 정의하려고 노력한다.(Simplicity의 추구)
④ Whole-product focus
-고객은 소프트웨어의 부분이 아닌 응집력 있는 전체 제품에서 가치 있는 기능을 원한다.
⑤ Customer Centric
- 모든 사람들은 자신의 업무가 현재 고객의 가치와 직접적으로 관련되어 있는지 이해한다. 대규모 프로젝트에서는 이를 실천하는 것이 보다 어렵다.
⑥ Continuous improvement towards perfection
-완벽에 대한 지속적인 개선을 수행한다.
⑦ Lean thinking
- 린 (lean) 사고를 적용하고 개선한다. 린 사고의 두가지 기둥은 지속적인 개선과 인간에 대한 존중이다.
⑧ Systems thinking
- 부품이 아닌 전체 시스템을 보고 이해하고 최적화하고 시스템 모델링을 사용한다.
⑨ Empirical process control
- 제품, 프로세스, 행동, 조직 설계 및 관행을 상황에 맞는 방식으로 진화적으로 조사하고 조정한다. 스크럼은 제품을 만들기 위한 프로세스나 기법이 아니다. 오히려 다양한 프로세스나 기법을 사용할 수 있는 프레임워크이다.
⑩ Queuing theory
- 대기열이론은 전통적인 개발방식이 왜 느린가에 대한 통찰력을 제공한다.
결국 LeSS는 대규모 프로젝트에서 SCRUM의 단순함과 경험적 프로세스의 통제를 효과적으로 사용하과 원리에 충실하게 해주는 Large Scaling을 위한 SCRUM 그 자체이다.
3.2.SCRUM of SCRUMS의 개념과 메커니즘
Scrum of Scrums는 여러 Agile팀의 대표를 통해 구성한 가상의 Scrum Team(Meta Scrum) 또는 이를 통한 SCRUM의 Scaling을 위한 SCRUM확장 메커니즘이다.[5]
[그림3] SCRUM of SCRUMS의 구성도 [9]
그림 3에서와 같이 SCRUM팀마다 SCRUM of SCRUMS의 회의를 위한 대표를 선정하고 이 회의를 통해 하나의 Product을 위한 다수 팀의 통합 이슈를 해소하고 조정한다. 이때 각 SCRUM팀의 대표는 보통 스크럼마스터가 역할을 수행하고 논의 주제에 따라서는 기술적 이해가 높은 SCRUM팀의 누구라도 같이 참석이 가능하다. SCRUM of SCRUMS회의는 마치 Daily미팅과 같은 형태로 수행이 되나 매일 할 필요는 없으며 15분 이내로 라는 Daily Meeting과 같은 제약을 받지 않는다. 
[그림4] SCRUM of SCRUMS의 켜뮤니케이션 효율성[6]
그림 4에서는 이러한 SCROM of SCROMS의 효율성에 대해 보여 주고 있다. 일반적으로 커뮤니케이션 주체인 Node을 n이라 할 때 n(n-1)/2의 커뮤니케이션을 위한 Cost가 소요된다. 대규모 프로젝트에서 이러한 비용을 SCRUM of SCRUMS의 Scaling메커니즘을 통해 획기적으로 줄일 수 있다는 것을 보여주고 있다. 이러한 효율성을 통해 SCRUM of SCRUMS는 다수의 팀이 하나의 Product Backlog을 여러 팀이 나누어 Sprint을 수행하더라도 효과적으로 Product을 완성 할 수 있도록 한다.
3.3. Nexus 프레임워크
Nexus는 Scaling된 Professional Scrum이다. Nexus는 스케일이 적용된 Agile 프로젝트에서 사용되는 Agile 프레임 워크로 5 ~ 9 명의 구성원으로 구성된 약 3 ~ 9 개의 다수의 스크럼 개발팀이 공통의 Product Backlog을 구현하는 프레임워크이다. Nexus 프레임워크는 기존의 Scrum Agile 프레임 워크에 추가 되거나 오버레이 된다. 이것은 "스크럼의 eco-skeleton"이다.
그림 5는 Nexus 프레임워크의 구성도로서 Nexus Integration Team을 통해 Integrated work을 수행하는 공정을 보여주고 있다.
[그림5] Nexus Framework의 구성도[10]
Agile방법론 에서는 이러한 Scaling 프레임워크외에도 Disciplined Agile Delivery, Scaled Agile Framework, Crystal Clear 등의 프레임워크를 통해 대규모 프로젝트를 수행 할 수 있도록 Scaling을 수행하고 있다.
4. 기존 방법론의 필수 활동 마이그레이션 방안
Agile방법론의 특징은 짧은 주기와 지속적인 통합을 통해Product완성해 가는 것이다. 이러한 메커니즘을 통해 기업은 Time to Market이 가능하며, Big Bang 통합의 Risk을 해소하고 품질을 확보 할 수 있다. 그러나 이러한 Adaptive한 방식이 Agile방법론 이전의 정형적 방법론에서의 필수 요구사항과 활동을 Agile방법론에 적용 하는 데는 오히려 어려움을 주고 있다. 이러한 이슈를 해소하고 효과적이고 효율적으로 기존 방법론의 필수 요구사항 및 활동을 마이그레이션 하기 위해서는 기존 방법론에서의 필수 Requirements와 Activity들을 분류하고 이를 SCRUM 방법론의 주요 공정에 잘 매핑하는 것이 효과적이다. 그림 6는 이러한 과정을 도식화 하여 보여 주고 있다. 이번 장에서는 필수 Requirements와 Activity을 효과적으로 분류하고 SCRUM 의 주요 공정에 이를 매핑하여 Agile 방법론에 다양한 방법론과 환경에서 활용되던 핵심 요소를 마이그레이션 하는 방법에 대해 살펴 보겠다.
그림 6는 이러한 마이그레이션을 하기 위한 전체 프로세스를 도식화하여 보여주고 있다.
[그림6] 기존 방법론의 핵심 요구사항과 활동을 Agile공정으로 적용하기 위한 프로세스[11]
4.1. 필수 요소의 분류 방안
Agile방법론의 주요 공정에 기존 방법론에서의 필수 요소를 적용하기 위해서는 우선 기존 필수 요구사항 및 활동들을 세가지 유형으로 분류한다. 그 유형은 One time Requirements, Every time Requirements, Bucket Requirements이다[7][8][11].
표 1은 이러한 세가지 유형의 분류 방법에 대해서 보안 활동 적용사례를 통해 설명 하고 있다.
[표1] Agile공정에 적용하기 위한 Requirements의 분류 방안(보안 요구사항의 적용 사례) 이후 이러한 형태로 분류된 Requirements 및 Activity들을 Agile의 주요 공정에 매핑 되게 한다.
4.2.Agile 공정에 매핑 방안
[그림7] Agile공정과 세가지 유형의 요구사항 매핑 방안[11]
그림 7는 4.1에서 제시한 세가지 유형의 요구사항을 Agile공정에 매핑한 모습을 보여주고 있다. 이러한 메커니즘을 통해 다양한 프로젝트 환경에서 필요한 필수 요구사항과 활동들을 Agile방법론에 적용할 수가 있다.
5. 결론
[1] homas Kuhn, The Structure of Scientific Revolution, 1962
[2] Ken Schwaber and Jeff Sutherland, 2017-Scrum-Guide-Korean, 2017.11
[3] Craig Lanman, Large-Scale Scrum: More with LeSS, Addison-Wesley Professional, 2016. 9. 23
[4] https://Less.works
[5] https://www.agilealliance.org/
[6] https://www.scruminc.com/scrum-of-scrums/
[7] Microsoft Security Development Lifecycle for Agile Development Version 1.0 June 30, 2009
[8] PMBPK 6th Edition
[9] https://www.agilest.org/
[10] https://www.scrum.org/
[11] 오민석, MS-SDL과 스크럼 프로세스를 이용한 통합 방법론, 정보보호학회, 2017년동계학술대회