애자일 프로세스라는 용어에 익숙하지 않은 사람이라면 두려움과 의심을 느끼면서 이 책을 펼쳤을지도 모르겠다. 하지만 그건 여러분 탓이 아니다. 애자일 프로세스를 배우다 보면 질주(스프린트, sprint), 속력(velocity), 스크럼(scrum, 럭비게임의 기본 대형?), 익스트림 프로그래밍(extreme programming, 스노보드로 벼랑 끝에서 점프하는?), 사용자 스토리(user stories), 서사(에픽, epic)와 전설(saga, 소설에 나오는 이야기?), 불가사의한 사회적 의례(weird social rituals), 짝 프로그래밍(pair programming), 사용자 회고(user retrospectives), 허들(huddles), 일일 스탠드업 미팅(이제 서로 껴안아줘야 하나?) 등과 같은 기이한 표현들을 자주 접하게 될 것이다. 또 애자일팀들은 엄청나게 많은 포스트잇과 명함 만한 인덱스카드를 벽에다 마구 붙이면서 무질서하게 일을 하는 것처럼 보이기도 한다. 그리고 이런 행동들은 마치 스콧 애덤스의 만화 딜버트(Dilbert)에나 나오는 이야기처럼 보인다. 그러나 착각하지 않길 바란다. 애자일 소프트웨어 개발 프로세스는 제프리 무어가 말한 것처럼 '큰 차이를 극복하는 것(Crossing the Chasm)'이라 할 수 있다. 이제 애자일은 단순히 흥미를 끄는 유행어를 넘어선, 효과적이고 생산적이며 측정 가능한 개발방법론이다. 애자일 개발방법론을 받아들여 성공의 길로 들어서느냐 아니면 그냥 이대로 낙오하느냐는 모두 여러분에게 달렸다.
애자일 개발방법론은 '계획적인 개발' 방법론과는 차이가 있다는 말을 어디선가 들어봤을 것이다. 어떻게 생각하면 애자일 방법론은 매우 무질서하며 그동안 알고 있던 체계적이고 계획적인 소프트웨어 개발방법들과는 많이 다르다고 느꼈을 것이다. 하지만 계획을 세우는 방법이 다를 뿐, 애자일 프로젝트도 매우 주의 깊게 계획된다. 다만 여타 개발방법론에 비해 좀더 자주 정제되고 재계획된다는 점에서 차별된다고 할 수 있다. 애자일 방법론은 7~12명으로 구성된 소규모 팀이 2~9개월 동안 진행하는 단기 프로젝트에는 높은 효율을 보이지만 전 세계에 퍼져 있는 대규모 팀이 진행하는 장기 프로젝트에는 적합하지 않다고 알려졌다. 그렇다고 이 책을 덮을 필요는 없다. 전 세계에서 진행되는 대부분 프로젝트처럼 애자일 프로세스도 그 경계를 넓혀나가면서 생산성이 높은 고품질 소프트웨어를 만들어 가고 있다.
이 책에서 딘 레핑웰이 이야기하고 싶어하는 것은 다음과 같다. 익스트림 프로그래밍(XP), 스크럼(Scrum), 린(Lean), 동적 시스템 개발방법론(DSDM, Dynamic System Development Method), 기능 주도 개발방법론(FDD, Feature Driven Development), 유니파이드 프로세스(Unified Process)와 같은 애자일 프로세스 사이에 발생하는 문제들에 대해 상호 간에 어떤 공통점이 있는지를 먼저 설명한다. 그러고 나서 저자는 이런 장점이 있는 다양한 방법론보다 애자일 접근 방법이 더욱 월등한 이유를 열띤 논조로 이야기하고 있다. 저자는 이 책에서 기존 방법론들과 새로운 애자일 프로세스를 이야기하려는 것이 아니라, 기존 애자일 실례와 새로운 예제를 통해 고수준의 기술과 관리 방법을 설명하고자 한다. 저자는 기존의 베스트 프랙티스에서 볼 수 있었던 내용뿐만 아니라 좀더 큰 애자일 프로젝트 관리에 초점을 맞춰 설명하고 있다. 예를 들어 이제까지는 많이 언급되지 않았던 릴리스 계획법, 대규모로 분산된 팀들을 다루는 법, 프로젝트 사업 목표 수립법, 장기 프로젝트 수행법 등을 다룬다.
저자는 그저 탁상공론을 논하는 학자가 아니며 자신이 주장하는 방법론을 주입시키기 위해 어림짐작으로 이야기하지도 않는다. 저자가 이 책에서 충고하는 내용은 수많은 회사와 다양한 프로젝트(생명의학용 소프트웨어부터 놀이공원과 놀이기구에 필요한 거대한 IT 인프라 애플리케이션까지)에서 직접 겪은 오랜 경험을 바탕으로 하고 있다. 나는 래셔널(Rational) 사와 랠리(Rally) 사에서 저자와 10년 동안 함께 일해왔기 때문에 누구보다도 잘 알고 있다.
이 책에 대한 몇 가지 충고를 덧붙이자면, 이 책을 읽은 후 책의 내용을 그대로 따라 한다고 해서 모든 프로젝트가 곧바로 성공할 거라 기대하면 안 된다. 부동산 업자들이 위치(location)를 중요하게 생각하는 것처럼 새로운 소프트웨어 개발 예를 적용하는 것의 핵심은 컨텍스트(context)라고 말할 수 있다. 여러분이 처한 컨텍스트, 즉 상황을 잘 이해한 다음, 저자가 주장하는 내용과 비교해보고, 프로젝트의 목표와 범위, 크기, 조직 문화 등을 비교해 저자가 추천하는 방법들을 여러분의 조직에 적용하길 바란다. 고려하고 있는 상황은 다양한 요소로 구성되어 있을 것이다. 예를 들어 조직의 도메인(어떤 일을 하는 산업인지), 개발하고자 하는 시스템의 규모, 팀의 경력, 각 팀원의 경험과 교육수준과 학력, 사용하고 있는 기술, 시스템의 엄격도, 심지어는 여러분의 조직과 나라의 문화까지도 포괄한다. 이 책에서 저자는 기업가, 소프트웨어 개발 관리자, 경영진, 방법론자, 컨설턴트 등 다양한 경험을 바탕으로 자신이 정립해둔 가치와 기준, 자신이 처했던 여러 상황을 설명하고 있다. 물론 여러분의 경험은 저자와는 다를 것이다. 책을 읽으면서 조금이라도 의구심이 든다면, 특정 용어와 방법에 연연하지 말고 애자일의 기본 개념을 떠올려보길 바란다.
문서화가 되어 있든, 사람들의 머릿속에만 존재하든 간에 '애자일 프로세스'는 프로세스 자체가 기민하거나 민첩하게 변화하는 것이 아니라, 사람이나 팀, 조직 등이 민첩하게 변화하는 것이다. 단순히 애자일 프로세스를 따라만 하기보다는 애자일 자체가 여러분이나 여러분이 속한 조직에 녹아 있어서 '애자일'의 속성이 여러분 몸에 깊이 배어들어야 한다. 여러분이 속한 그룹이나 여러분 자체가 애자일화되지 않고 단순히 애자일 프로세스에서 제공하는 몇 가지 방법들만 적용하려고 한다면, 이유를 알지 못한 채 실패할 것이며 어느 책에선가 나쁜 선례로 언급될지도 모른다. 이 차이를 극복하려면 저자나 다른 사람들이 말하는 것을 그대로 따라 하거나 애자일 방법론을 그대로 받아들이는 것을 넘어 그 이상으로 열심히 노력해야 할 것이다. 쉽진 않겠지만 마음가짐이나 태도 자체가 변화해야 한다. 마음가짐이나 태도라는 건 단순히 책을 읽는다거나 교육과정을 통해 수업을 듣는다고 해서 저절로 바뀌는 게 아니다. 애자일 프로세스에서 이익을 얻으려면 여러분과 여러분이 속한 조직이 애자일의 기본 원칙을 받아들여 새로운 시도를 반복, 또 반복해야 한다. 그리고 여러분의 경험을 평가해보고 그 경험을 살려, 새로운 시도를 통해 어떤 것을 얻고 얻지 못했는지를 검토하고 얻어낸 교훈을 다시 적용해 봐야 할 것이다. 거듭 말하지만, 이 책을 읽었다고 해서 애자일 방법론을 모두 배웠다고 생각하지 않길 바란다. 이 책을 통해 생각하고, 느끼고 변화해야만 진정한 애자일이 무엇인지 알게 될 것이다.
만일 여러분이 애자일에 대해 잘 알고 있고, 1970년대 천공카드를 쓸 때부터 애자일 프로세스가 몸에 배어 있는 사람이라면 이 책에서 무엇을 얻을 수 있을까? 답부터 말하자면, 그래도 배울 게 아주 많을 것이다. 개인적으로 이 책을 검토하는 동안 그동안 내가 겪어온 경험과 실례들을 돌이켜볼 수 있었으며 많은 것을 배울 수 있었다. 사실 저자가 말한 모든 의견에 동의하는 건 아니다. 내가 처했던 상황과 경험은 그와는 약간 차이가 있기 때문이다. 하지만 저자와 나는 몇몇 특정 용어와 방법을 제외하고는 전체적으로는 이 책의 모든 내용이나 기본적인 원칙과 전략에 대해서는 서로 동의하고 있다(얼마 전 그에게 들은 바대로 우리는 각자의 의견을 서로 나누며 토론 자체를 즐겼다. 토론을 통해 우리가 지닌 핵심 원칙을 시험해보고 서로 생각을 알아보기도 했다). 이런 관점에서 볼 때, 여러분이 이미 애자일을 많이 경험했더라도 이 책에서 더욱 가치 있는 교훈을 얻고 지식을 한층 강화할 수 있을 거라 믿는다.
자, 이제 충분히 이야기한 것 같다. 이것으로 서문을 마치고 페이지를 넘겨 본론으로 들어가 보자. 책을 읽는 동안 즐겁게 배우면서 '애자일'을 몸소 실천하길 바란다.
필립 크루첸
소프트웨어공학 박사
캐나다 밴쿠버의 브리티쉬 컬럼비아대학 소프트웨어공학 교수
--- 서문
소프트웨어 방법론 경력 1단계: 레라와 리퀴짓 사
나는 업무를 통해 소프트웨어 공학과 소프트웨어 개발 관리에 대한 기술을 익히고 발전시켜왔다. 목표는 항상 일정했지만, 소프트웨어 개발 경험은 크게 3단계를 통해 발전한 것 같다. 첫 번째는 다른 업체 수주를 받아 소프트웨어를 개발해주던 레라Rela 사(社)의 CEO로서 출발했다. 레라는 놀이동산의 놀이기구부터 생명의학 장치까지 다양한 분야에 걸쳐 사용되는 소프트웨어 애플리케이션을 개발하는 회사였다. 레라의 소프트웨어는 고객에게 수주해 진행하는 것이었기 때문에, 회사의 목표는 언제나 "고객이 원하는 것을 제대로 만들자(build the right thing)"였다. 회사의 모든 역량은 주어진 문제의 해결책은 무엇인지, 그 해결책을 적용하는 가장 효과적인 방법은 무엇인가를 연구하고 고객에게 설명하는 것에 집중됐다.
그래서 폭포수 방법론(waterfall method)에 기반을 둔 엄격한 방법론을 사용했다. 실제로 몇몇 고객과 식품의약국(FDA) 같은 주요 규제 조직에서는 폭포수 방법론을 원했고, 우린 고객이 원하는 대로 폭포수 방법론을 따랐으며, 필요한 경우 약간의 수정을 가해 적용하기도 했다. 폭포수 방법론을 사용하는 동안 우리가 알아낸 사실은 폭포수 방법론이 과거 프로젝트 중 일부를 기반으로 발전시키고 산출물을 중요시한다는 점이다. 당시 내 주관심사는 요구공학 프로세스(Requirement Engineering Process)에 있었는데, 이슴 프로젝트에 큰 영향을 미치는 심각한 문제점을 찾을 수 있으며, 문제의 해결책에 대한 정의가 이뤄지고, 계약의 밑바탕이 되기 때문이었다.
이런 경험을 바탕으로 나는 요구공학 솔루션 프로그램인 리퀴짓프로(RequisitePro)를 만든 리퀴짓(Requisite) 사의 창립자이자 CEO가 될 수 있었다. 리퀴짓 사에서는 요구사항 정의에 필요한 사례와 제품을 개발하고 발전시킬 수 있었으며, 이런 경험 덕분에 소프트웨어 개발 사이클 전반부에 대한 많은 경험을 갖게 됐다. 1997년 리퀴짓은 래셔널 사에 인수되었고, 나는 소프트웨어 개발 프로세스 인생의 두 번째 전기를 맞게 된다.
소프트웨어 방법론 경력 2단계: 래셔널 사
나는 래셔널(Rational) 사의 고위 경영층으로서 UML(Unified Modeling Language)과 RUP(Rational Unified Process) 배포에 조력하고 있었다. 래셔널 사에서 그래디 부치(Grady Booch), 이바 야콥슨(Ivar Jacobson), 제임스 럼바우(James Rumbaugh), 워커 로이스(Walker Royce), 필립 크루첸(Philippe Kruchten)과 같은 당대 석학들과 함께 일할 좋은 기회를 얻을 수 있었다. 그리고 이때 돈 위드릭(Don Widrig)과 함께 Addison-Wesley 출판사에서 『Managing Software Requirements』(2000)라는 책을 집필, 출간했다.
생각할 수 있는 모든 개념은 객체지향(Object Orientation)에 바탕을 뒀는데, 객체지향 사고방식을 통해 개발방법론은 유연성이 높아지고 소프트웨어를 더욱 탄력적으로 작성할 수 있었다. 또 폭포수 모델과는 달리 반복 점진적인 소프트웨어 개발이 가능해졌다. 이렇게 하면 주기마다 객관적으로 평가할 수 있는 소프트웨어를 만들어낼 수 있었고, 이런 방식은 폭포수 모델을 사용할 때보다 좀더 애자일스러웠다. 폭포수 모델을 사용할 때와는 달리, 문서나 디자인 리뷰와 같은 중간 산출물들이 독립적으로 존재할 필요가 없었고 측정, 평가도 가능했다.
래셔널 사는 래셔널 유니파이드 프로세스(RUP)란 이름으로 이 모든 과정들을 집대성해 문서화했다. 그리고 시장에 출시하고 산업체에 적용해 좋은 성공 스토리를 만들었다. 뿐만 아니라 이 프로세스와 래셔널 사의 제품군을 개발에 적용했고, 4개국에 걸쳐 800명의 팀원이 있는 조직에도 적용했다. 매년 두 번씩 유기적으로 연결된 래셔널 제품군을 출시했다. 그 후 래셔널 사는 IBM에 합병됐고 이제는 RUP란 이름으로 IBM의 래셔널 소프트웨어 부서가 판매하고 있으며, 현재 수백, 수천 명의 개발자가 이를 사용하고 있다.
소프트웨어 방법론 경력 3단계: 본격적인 애자일, 랠리 사
래셔널을 떠나서 독립 컨설턴트로서 소프트웨어 각 개발 단계에 대해 조언을 하게 됐다. 사업 전략에 대해 지도를 하고, 몇몇 새로운 벤처 업체에는 소프트웨어 개발방법론을 가르쳤다. 이때 XP나 스크럼 같은 좀더 혁신적이고 가벼운 방법을 적용해 볼 수 있었고 소규모 팀들이 이 방법론을 통해 제품의 생산성과 질을 어떻게 향상시키는지를 두 눈으로 직접 확인할 수 있었다.
얼마 지나지 않아 나는 애자일의 매력에 푹 빠져서 이제는 애자일 방법론을 알지 못하는 팀이나 사업가와 함께 일을 하기 싫을 지경에 이르렀다. 그렇지 않으면 사업에 대한 위험이 너무 컸기 때문이다. 하지만 동시에 애자일 방법론에 대한 한계가 보이기 시작했다. 팀이나 애플리케이션의 규모가 점점 더 커질수록 코드를 만드는 능력은 감소했고, 요구사항을 좀더 명확하게 정의할 필요가 있었으며, 폭주하는 설계방식에 뭔가 변화를 줘야 할 필요성을 느꼈다. 이때를 즈음해 랠리(Rally) 소프트웨어 사에서 소프트웨어 개발방법론자로서 컨설팅을 시작했고, 분산 애자일 기반 솔루션 개발에 많은 조언을 했다. 랠리 사에서는 라이언 마틴즈(Ryan Martens), 켄 슈와버(Ken Schwaber), 짐 하이스미스(Jim Highsmith), 마이크 콘(Mike Cohn), 톰과 메리 포펜딕 부부(Tom and Mary Poppendieck), 제프 서덜랜드(Jeff Sutherland) 같은 애자일 전문가들과 함께 일하면서 많은 영향을 받았다.
엔터프라이즈급 프로젝트에서의 애자일 경험
앞에서 언급한 다양한 직무 경력을 통해, 개인적으로는 많은 기업으로부터 엔터프라이즈급 프로젝트에 애자일 방법론을 도입할 수 있게 해달라는 협조 요청을 받았다. 약간 두려움이 앞서긴 했지만, 몇 년간 각 지역에 산재한 수백 명의 개발자가 대규모 애플리케이션을 개발하는 BMC 소프트웨어에 애자일의 핵심 원리와 내 업무 경험을 적용하는 데 성공했다.
애자일 방법론을 가르치는 동안 기업에 큰 가치를 부여하는 베스트 프랙티스들을 발견할 수 있었다. 하지만 이런 베스트 프랙티스들을 대규모 팀에 적용하는 건 그리 수월한 일이 아니었다. 그래서 엔터프라이즈 조직에 맞는 애자일 방법론을 좀더 연구해 보기로 했다. 하지만 엔터프라이즈급 회사에 맞는 애자일 방법론을 다룬 책들은 찾아뢺기가 어려웠고 결국 책을 한 권 집필하기로 했다. 이 책을 읽고 ?운 내용을 조직에 맞게 적용하고 더 좋은 품질과 생산성을 얻게 되기를 희망한다. 세상에 많은 소프트웨어가 있지만 산업과 경제를 도약시킬 만한 소프트웨어 방법론을 찾기란 쉽지가 않다.
--- 저자 서문
이 책을 읽는 독자라면 이제 애자일이란 용어가 아주 낯설게 느껴지지는 않을 것이다. 서점에 나가도 애자일을 다룬 서적이 이미 많이 나와 있으니 말이다. 내가 처음 애자일이란 용어를 접한 것은 5년 전쯤 익스트림 프로그래밍(XP, Extreme Programming)에 대한 교육을 받을 때였다. 교육을 신청한 이유도 단순히 제목이 참 흥미로웠기 때문이었다. 당시만 해도 '애자일=XP'라는 아주 단순한 생각을 하고 있었으며, 처음 '애자일' 이란 용어를 접했을 때에도 매우 낯설어 사전에서 '기민한, 민첩한'이란 뜻을 찾아냈지만 정확히 무슨 의미를 뜻하는지 그 느낌이 쉽게 다가오지 않았다.
그 뒤 회사에서 SE 업무를 시작하게 됐고 애자일 방법론의 여러 가지 활동들을 접하게 되면서 몇 가지 베스트 프랙티스들은 지금 하는 현업에 직접 적용해 볼 수도 있겠다는 아이디어가 떠올랐다. 점점 더 애자일 방법론에 대해 알아갈수록 이 방법론은 많은 개발 경험이 있고, 프로세스가 어느 정도 내재화되어 있는 팀에서 충분히 적용 가능하다는 생각이 들었다. 하지만 현실적으로 개발자들에게 가장 매력적으로 다가가는 애자일 방법론의 장점은 개발 도중에 끊임없이 만들어내야 하는, 그리고 도대체 왜 필요한지 동감할 수 없는 '문서'가 없다는 점일 것이다. 그래서 '애자일 개발 = 애드혹 개발'이라는 오해를 받기도 한다. 이 책 첫머리에 나오는 이야기지만 '애자일은 소규모 프로젝트에만 효과가 있다'라는 통념 때문에 애자일 방법론에 대해 약간은 부정적인 시각을 갖고 있었다.
하지만 이 책의 번역 의뢰를 받았을 때 선뜻하겠다고 나선 이유는, 책 제목에서도 알 수 있듯이 애자일 방법론을 엔터프라이즈급 회사에 적용해본다는 새로운 시각, 그리고 애자일 방법론에 대한 기본 이론을 먼저 설명한 후 이를 점차 확장시켜 가면서 고려해야 할 여러 사항을 저자의 경험을 토대로 다양한 사례를 들어가며 상세히 설명하고 있기 때문이었다. 번역을 진행하면서 애자일 방법론에 대해 좀더 체계적으로 알 수 있었고, 현업 적용에 대한 아이디어를 많이 떠올릴 수 있게 됐다.
매번 만족하지는 못하지만, 항상 번역을 하면서 고민하게 되는 것은 어떻게 하면 저자가 말하고자 하는 바를 왜곡 없이 100% 독자들에게 전달할 수 있을까였다. 그래서 가능한 용어는 이미 출간된 여러 책을 참조해 독자들이 무리 없이 읽을 수 있게 하고 전체적으로 저자의 의도를 최대한 살리도록 노력했다.
수많은 애자일 방법론에 대한 책이 출간됐지만, 엔터프라이즈급 대규모 프로젝트에 확장 적용하는 애자일 기법과 사례를 충실히 그리고 생생하게 익힐 수 있는 이 책이 애자일 방법론 확장에 좀더 기여할 수 있게 되길 바란다.
--- 옮긴이의 말