내가 회사 다니기 시작했을 때, 나의 직속 선배 분이 Software Engineering을 전공한 선배였다. 그 분은 전통적인 Waterfall 방식에서 Analysis와 Design을 강조하였던 것을 기억한다. 그래서, 당시 개발하던 Software도 요구 사항을 분석 하고 설계하는데 대부분의 시간을 투여 하고 구현에는 적은 노력을 투여 하려고 하였다. 하지만, 이러한 방법으로 제품을 개발할 때 성공하기 어려운 점이 많았다. 이후에는 솔루션을 기반으로 제품화를 많이 했지만, 많은 밤샘과 비효율이 많았다. 그러는 와중에도 여러가지 Agile Methodology를 알게 되었고, 효율적으로 일하는 방법으로서 어떻게 이를 활용할지 고민하였다.
아래 그림은 간략한 Agile Software Development 방법들의 역사[1]에 대해 정리한 것이다. 여기서는 간략한 Agile Software Development 방법론들에 대해서 소개하고 어떻게 나는 이를 활용 혹은 참고해 왔는지 정리해 본다.
eXtreme Programming (XP)
Extreme Programming(XP)은 내가 가장 먼저 알게 된 Agile Software Development 방법론이었다. 이 때에는 Agile이라는 말도 없을 때였다. XP는 극단적으로 개발자 중점이라는 생각이 든다. 그리고, 기존 개발 프로세스가 있는 회사에는 적용하기 어려웠다. 그리고, 실천(Practice)해야 할 것들이 많아서 실행이 쉽지 않다.
아래 그림[2]은 XP에 관해서 검색하면 가장 많이 볼 수 있는 것 중에 하나이고, 가장 XP의 Process를 잘 표현한 그림 중에 하나라고 생각된다. Agile Software Development 의 원칙과 같이 짧은 주기와 반복(Iteration)을 통해서 Software를 개발하는 것을 알 수 있다. 여기서 여러가지 재미있는 용어 들이 나이기 때문에 각각 살펴 본다.
XP의 오리지널 사례에서 요구 되는 엄격함때문에, XP를 채용하는 경우는 더 이상 채용하지 않거나 많은 변형이 일어나는 경우가 많다고 한다[2]. 하지만, XP는 Continuous Integration이나 Test-Driven Development와 같이 개발의 중요한 개념을 탄생시켜 지금까지도 Software 개발에 많은 영향을 끼치고 있다.
가장 첫 번째가 Pair Programming[3]이다. 이는 2명의 프로그래머가 한 개의 컴퓨터를 가지고 한가지 프로그램을 짜는 것을 말한다. 한명은 Driver로 실재로 프로그램을 짜고, 다른 한명은 Navigator로 Driver가 짜는 프로그램에 대해서 질문하고 의견을 제시한다. 때때로 역할을 바꿔가면서 프로그램을 작성한다. 이 방법은 여러 가지 장점을 가지고 있다. 한 명이 작성할 때 보다 실수가 적고, 실력 차가 나는 경우에는 훈련용으로도 좋다. 또한, Code Review가 실시간으로 이루어 진다는 장점도 있을 수 있다.
또 다른 특징 중의 하나가 Unit Testing이다. 사실 XP에서 중요한 개념은 Unit Testing이 아니고, Test-Driven Development(TDD)이다. 이는 초창기 부터 제안되었으며 이제는 Software의 독립적인 화두로 최근까지 논의 되고 있다. 프로그램을 구현하기 전에 Test 부터 작성 하고 실재 구현을 하게 된다. 이는 요구 사항에 대해서 이해를 높이고 Unit Test Case를 확보하게 하여 Software 구조를 좋게 만들어 준다. 하지만, 이러한 실천법이 쉽지 않아서 아직도 많은 사람들이 채용하지는 못하고 있는 것이 현실적이다.
내가 XP관련해서 처음 봤던 책이 Extreme Programming Installed[4] 였던 것으로 기억한다. 실재로 어떻게 XP가 적용되는지에 대해서 잘 설명이 되어 있는 책이다. 이 후 잊고 있다가, 4명 정도의 후배가 생겼던 나에게 과제 진행의 책임이 맡겨졌을 때, 신규 인력들을 역량을 키우면서도 개발을 하려고 해야 하는 쉽지 않은 상황이었다. 이 때, Pair Programming이 생각이 났고, 그 방법을 적용해 볼 수 있었다. 이를 통해서 얻은 가장 큰 장점은 신규 인력들을 트레이닝하는 것이었고 또한 인력들이 할 수 있는 업무량에 대한 예측도 쉬웠다.
Scrum
이 후, 학교에 가서 공부를 하게 되면서 학생 자격으로 Microsoft사에 초대 받아 간적이 있다. 2007년 경으로 기억한다. 이 때, Microsoft도 Scrum을 채용하고 있다는 소개를 받게 되면서 Scrum에 대해서는 처음 알게 되었다. Scrum은 산업계에서 가장 많이 채용되어 사용되는 Agile Software Development 이다[5]. 2018년도 기준으로는 Agile Software Development를 채용한 기업에서 56%가 Scrum을 채용하고 있다고 한다. 이는 개발자로서 이는 기술적인 것 보다는 관리적인 측면에서 이해하기 쉽고 추적하기 쉽기 때문이라고 생각한다.
아래 그림[6]은 여러 Scrum의 흐름도 중에서 Animation 버전이다. Scrum은 Sprint라는 Iteration이 반복되며 Sprint Backlog를 개발한다. 이 때, Daily Scrum을 통해서 매일 Scrum에 포함된 작은 숫자(일반적으로 피자 2판을 먹을 수 있을 정도의 인원)의 팀이 어제 했던 일과 오늘 해야 할일을 점검하면서 Potentially Shippable Product를 만든다. 제일 처음에는 Product에서 개발해야 할 항목을 Product Backlog로 만들고 일부를 Sprint Backlog로 추출해서 1~4주 정도 1번의 Sprint를 돌게 된다. 마지막에는 Sprint마다 회고(Retrospective)를 하게 된다.
Scrum은 나 보다는 후배들이 채용하자고 하였다. 하지만, 휴대폰을 만드는 회사이고 우리 팀의 역할이 휴대폰의 Middleware이기 때문에 신기능을 Scrum으로 개발한다고 하더라도 Scrum이 지속적으로 동작하지 않고 신규 기능을 개발하는 동안에만 동작한다. 그 이후에는 유지 보수(Maintenance)를 해야 하는 과정으로 주로 문제점(Defect)을 수정하는 것이 주요 업무였다. 특히, 여기서 나에게 인상적이었던 것은 Daily Scrum과 Retrospective였다. 이를 통해서 팀의 점진적인 발전을 꾀할 수 있었기 때문이다.
Kanban
팀의 일부 인원들이 Scrum을 채용하면서 문제 되었던 것은 신규 기능 보다는 제품의 유지 보수(Maintenance) 역할을 담당하는 팀의 사기였다. 팀의 많은 인원들이 중에는 신규 기능을 개발하는 경우도 있었지만, 대부분의 업무는 유지 보수를 담당하는 인력들도 있었다. 이 들은 반복적인 업무만 하고 자신들은 발전이 없다는 생각에 많이 빠져 있었다. 이 때, 알게 된 것이 칸반(Kanban)이었다.
Kanban관련해서 처음 접한 자료는 Scrum과 Kanban을 비교한 자료[7]였다. 여기에는 여러 개발 방법론을 아래와 같이 비교 하고 있다. Kanban에서는 다른 방법들과는 달리 3가지만 고려하면 되었다. 그것은 Visualize the workflow와 Limit WIP(Work In Progress) 그리고 Measure and optimize lead time이 있다. 이런 측면에서는 매우 간단한 방법일 수 있다. 하지만, 실재 Kanban은 이렇게 간단하지 않다. 이는 기존 프로세스 없이 새롭게 Kanban을 적용하는 경우에 해당된다고 할 수 있다.
Kanban은 David J. Anderson[8]에 의해서 소개되었다. Anderson은 여러번의 시도를 통해서 기존에 존재하는 프로세스를 개선하는 방법을 고민하였다. 이것을 정리하여 처음 적용한 것이 Microsoft사에서 처음 적용하였다. 이 때에는 Drum-Buffer-Rope방식[9]을 Software 개발 방법에 적용하였다. 그런데, 이 것이 실재로 Toyota 자동차의Kanban과 더 유사하다는 것을 파악하고 이를 Kanban이라 명명하게 되었다. 즉, 기존에 있는 개발 프로세스를 개선해 나가는 방법이 실재 Kanban인 것이다.
Back to basics: Agile Manifesto
앞에서 이야기 한 것 처럼 나는 Kanban을 유지보수 사람들에게 적용하였고, 간헐적 Scrum을 자체 모듈 개발 하는 사람들에게 적용하였다. 또한 이것도 하기 힘들어 하는 사람들에게는 회고와 계획만 진행하게 하면서 조금 더 발전할 수 있도록 선택하게 하였다. 이는 Agile Software Development가 팀의 커뮤니케이션을 증대하고 실질적으로 동작하는 Software 제품을 만들며, 고객과 더 가까이 일하며, 점진적으로 발전해가는 것이라 믿었기 때문이다. 즉, Agile Manifesto[10]가 정말 고민해야 하는 가장 기본이되는 가치(Value)들을 포함하기 때문이다. 정말 재미있는 것은 처음에는 뒤에 항목들만 중요하다는 생각이었다. 하지만, 그것을 틀린 생각이었다. 실재로는 앞에 것도 중요하지만, 뒤에 것이 더 중요하다는 것임을 더 깨닳아 갔다.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기를
좀 더 깊게는 Agile Manifesto에서는 원칙(Principle)을 포함하고 있다. 이 12가지 원칙은 적어 놓고 반복적으로 읽어 보며, 여러 가지 판단을 내릴 때 떠올리려서 활용하는 것이 유요하다.
- 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
- 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
- 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
- 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
- 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
- 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
- 작동하는 소프트웨어가 진척의 주된 척도이다.
- 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
- 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀(Self Organizing Team)에서 창발한다.
- 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
예를 들면, 최근에는 "면대면 대화"의 중요성도 많이 깨닳았다. 우리는 전화와 카카오톡과 같은 메신저와 같은 소통 도구의 홍수에 살고 있다. 하지만, 면대면대화와 같이 협업을 증대시키는 도구는 없다. 지속적으로 주기적으로 면대면대화를 통해서 프로젝트의 진전을 가져올 수 있음을 계속 깨닳게 된다. 또한 단순성, 즉 하지 않는 일의 양을 최대화 하는 것도 아이러니 해보이지만, 정말 의미 있는 부분이다. 이를 통해서 팀은 여유를 가지게 되고 좀 더 창의적이거나 프로세스를 개선하는데 이 여유, 여력을 활용할 수 있다.
벌써 몇년에 고민하고 적용하고 있지만, 아직까지도 이 원칙과 가치에 대해서 100% 이해하고 있다고 생각하지 않는다. 아직 접근해 가는 과정이다. 우리는 아직도 성장하고 있는 것이다.
References
[4] Ron Jeffries et al., "Extreme Programming Insalled," Addison-Wesley (번역본 Insight)
[8] David J. Anderson, "Kanban: Successful Evolutionary Change for Your Technology Business," Blue Hole Press, 2010
[9] 제프 콕스, 엘리 골드렛, "더 골 The Goal (만화판) - 당신의 목표는 무엇인가?" 동양북스(동양문고)
[10] Manifesto for Agile Software Development, http://agilemanifesto.org/
