스크럼(Scrum)의 대부인 켄 슈와버와 마이크 비들이 쓴 스크럼의 바이블 『Agile Software Development with Scrum』이 『스크럼』이란 제목으로 출간을 앞두고 있습니다. 번역은 박피디 님과 김기웅 님께서 해주셨습니다.

“스크럼은 다르다”

애자일 소프트웨어 개발 방법론이 유연한 소프트웨어 시스템의 미래를 여는 열쇠라고 감히(?) 말한다면, 스크럼은 급변하는 비즈니스 환경에서 소프트웨어 개발과 관리를 가장 효과적으로 해내는 전위대라고 또한 감히 말할 수 있을 겁니다. 이 책에는 기존의 것들을 단순히 우려먹는 그렇고 그런 방법론이 아니라 수십 년 간의 경험을 통해 얻은 저자들의 철학과 이론 그리고 실천법들이 다양하고 심층적인 사례와 함께 온전히 담겨 있습니다.

“스크럼이 불편하다”

스크럼은 외견상 간단하게 보이는 방법론이지만 우아한 기술과 헌신적인 실천을 요구합니다. 그러니 적용하자마자 잠재되어 있는 문제점들이 폭로되어 이러저러하게 조직의 쓴맛을 보게 됩니다. 그래서 스크럼은 불편합니다. 허나 어쩌랴! 성공하는 프로젝트를 만끽하려면 넘어야 할 산인걸^^. 신뢰와 헌신, 믿음과 용기, 개방과 공유라는 스크럼의 가치를 통해 그 ‘불편’을 돌파해 보시죠.

“스크럼으로 통한다”

소프트웨어 개발은 항상 새로운 제품을 만드는 창조적인 행위입니다. 이러한 새로운 제품을 개발하는 과정에서 넓고 깊은 연구와 창발적인 활동은 두말하면 잔소리죠. 그러려면 새로운 지식을 창출하고 스스로 자기 조직화를 잘 할 수 있는 관점과 실천이 필요합니다. 스크럼은 소프트웨어 개발의 패러다임을 바꾸는 새로운 세계관을 보여줍니다. 이 책에서 스크럼의 세계관을 투영한 소프트웨어 개발의 다양한 관점을 – 시스템 역학적, 인류학적, 복잡계 과학적, 정신분석적, 패러다임 전환적 관점 등 – 확인하십시오. 왜 스크럼은 통하는지 바로 알아챌 것입니다.

[ 추천 글 ]

김창준, 애자일 컨설팅

스크럼은 단순하다. 전체 규칙을 설명하는 데에 10분도 안 걸리는 방법이다. 스크럼을 설명하는 데에 한 권의 책이 필요하다는 것 자체가 이상할 정도이다. 하지만, 사실 스크럼의 규칙을 모두 알게 되는 데에는 10분이 걸리지만 스크럼을 철학과 “왜”를 이해하는 데에는 10일이 걸릴 수도 있고, 스크럼을 제대로 행하는 데에는 10주가 넘게 걸릴 수도 있다. 그렇지만 여전히 스크럼은 간단하다.

간단하다는 것은 많은 이들에게 매력으로 작용한다. 사람들은 스크럼을 우습게 본다. 그 정도의 변화라면 나에게 뭐 해가 될 게 없겠지 하고 안심하고 시작한다. 하지만 사실 그렇지 않다. 스크럼은 간단해 보이지만 사실 엄청난 변화를 요구한다.

스크럼을 적용하면 순식간에 문제점들이 많아진다. 스크럼이 만든 문제가 아니다. 이제까지 땅속에 묻어뒀던 문제들이다. 하지만 그것은 발전이다. 묻어둔 문제를 파내는 것 자체가 발전이다. 이제는 그 문제를 합심하여 해결하기만 하면 된다. 하지만 이를 위해서는 썩어 문드러진 고약한 문제를 함께 해결할 의지가 있어야 한다. 그것이 스크럼에서 가장 어려운 부분이다.

그렇지만 여전히 스크럼 초심자에게 저항감을 덜 느끼게 한다는 것은 큰 장점이다. 그래서 스크럼은 비교적 쉽게 퍼졌다. 국내에서도 스크럼을 사용하는 조직이 많이 있다. 하지만 국내에 스크럼의 고전이라고 불리는 이 책이 번역되질 않았었다. 그런 중에서도 스크럼이 많이 퍼질 수 있었던 것은 역시 스크럼의 단순성 덕분이다. 이 책을 통해 국내에 더 많은 스크럼이 퍼지길, 그래서 더 많은 문제를 발굴할 수 있기 바란다.

마지막으로 번역에 대해 한마디. 이 책을 번역한 박일 님과 김기웅 님은 꽤 오래전부터 자신이 속한 회사에서 애자일을 몸소 실천해 왔다. 그런 분들이 이 책의 번역을 맡아 무척 다행이라고 생각했다. 일반적 기술서적과 달리 번역이 어려웠을 것이라 생각이 드는데, 여러 차례에 걸쳐 교정을 하면서 많은 노력을 쏟아 부었던 것 같다. 사명감이 없으면 할 수 없는 일이다. 번역자들에게 박수를 보낸다.

심우곤, LG전자 생산성연구원 선임연구원,

이 책은 Scrum을 체계화하는 데 지대한 공헌을 한 Ken Schwaber가 2001년에 저술한 첫 번째 책으로, 이 책의 출간 후 각각 2004년, 2007년에 이어 나온 『Agile Project Management with Scrum』과 『The Enterprise and Scrum』의 근간이 된다. 책이 너무 오래되었다고 생각할 수도 있겠지만 걱정은 하지 않아도 된다. 오히려 초기 Scrum의 고민거리와 아이디어가 어땠는지를 살펴보는 즐거움을 안겨줄 것이다.

Scrum은 Agile의 원칙을 팀 커뮤니케이션과 프로젝트 관리에 적용한 결과물로 ‘Agile Manifesto’의 모든 기조를 철저하게 따르고 있다. 구성원들을 존중하고 협력하는 것은 “개인과 상호작용이 프로세스와 툴보다 우선함”을… 매 Sprint 완료 시 작동하는 소프트웨어를 시연하도록 하는 것은 “동작하는 소프트웨어가 포괄적인 문서화보다 우선함” 을… 제품 총괄책임자와의 긴밀한 커뮤니케이션을 통해 제품의 시장가치 높이도록 하는 것은 “고객과의 협력이 계약 협상보다 우선함”을…timebox를 두어 팀을 보호하지만, timebox 후에는 언제든지 변화를 수용할 수 있도록 한 것은 “변화 대응 계획 준수보다 우선함”을 반영한 것이다.

황상철, 실용주의 이야기,

“우리 산업이 명시적인 방법론들을 사용할 경우 통제력이 상실되거나 불완전한 제품 생산을 초래할 것이라는 사실을 이론화하였다.” 지금까지 무거운 방법론을 주로 적용해 온 제 경험에 비추어 본다면 너무나 가슴에 와 닿는 책 속의 구절입니다. 스크럼을 처음 알게 된 건 2년 전입니다. 현장에서 여러 가지 문제를 해결하기 위해 찾은 것이 애자일 방법론이었는데, 특히 스크럼 방법론을 현장에 확산시키면서 항상 느끼는 부분은 이게 잘못된 선택이 아니라는 확신입니다.

남기룡, 마이에트 엔터테인먼트, http://mypage.sarang.net

재작년 프로젝트 관리에 허덕이고 있을 때 스크럼을 처음 접했습니다. 아니! 이런 것이 있었다니! 바로 스크럼을 도입했고 처음엔 적응하는 것이 쉽지 않았지만, 지금은 스크럼이 없었으면 어땠을까 하고 안도의 한숨을 쉬게 합니다. 스크럼의 가장 큰 장점은 빈번하고 빠르게 피드백을 받게 만들어 장애물을 신속히 제거하는 데 있다고 생각합니다. 일하면서 업무 외적인 방해나 커뮤니케이션의 장애 등이 없으면 얼마나 생산성이 올라갈까요? 여러분은 이 책으로 프로젝트를 보다 더 활기차고 발전적으로 이끌 수 있을 것입니다.

[ 역자의 글 ]

박일

“자, 11시입니다. 모여주세요.” 리니지2 개발팀은 2년 전 스크럼을 도입한 후로 아침마다 다 같이 모여 일일 스크럼 회의를 합니다. 일일 회의에서는 책에서처럼,

1. 따로 회의실을 잡지 않고

2. 일어선 채로 최대 15분을 넘기지 않고

3. 어제 한 일과 오늘 할 일, 일하는 데 방해가 되는 것 세 가지를 돌아가며 얘기합니다.

이렇게 쉬워 보이는 실천법 덕분에, 스크럼이라는 단어는 소프트웨어 개발 회사와 게임 개발사에서 큰 인기를 끌고 있습니다. KGC(Korea Game Conference) 2007에서 애자일과 스크럼 관련 포럼에 패널로 참가했을 때 얼마나 많은 분들이 관심을 가지고 있는지를 몸으로 느낄 수 있었습니다. 특히, 주 40일 시간 근무나 짝 프로그래밍 같은 급진적인(?) 주장 때문에 XP나 애자일 방법론의 도입을 꺼리던 회사에서도 스크럼만큼은 큰 저항 없이 도입하고 있습니다. 그것은 스크럼이 쉬우면서도 Agile의 장점과 기존 방법론의 장점을 동시에 가지고 있고, 무엇을 어떻게 해야 할지가 철학책 같은 느낌의 익스트림 프로그래밍(XP)보다는 스크럼이 훨씬 단순하고 명확하기 때문일 것입니다.

단순히 스크럼을 알고 싶다면 16장짜리 「Scrum in five minutes」같은 문서를 읽으시길 추천 드리며 『Scrum and XP from the Trenches』에서는 컬러 사진과 함께 어떻게 백로그를 만드는지, 번다운 차트는 어떻게 그리는지를 보실 수 있습니다. 둘 다 인터넷에서 쉽게 찾아보실 수 있습니다. 하지만, 이것만으로는 스크럼을 성공적으로 도입하기 어려울 것입니다.

왜냐고요? 스크럼은 딱히 명문화된 실천법이 없기 때문입니다. 일일 스크럼 회의, 번다운 차트, 백로그 같은 기본 개념은 같지만, 이것을 실제로 적용하는 과정에서는 각 팀마다 갖고 있는 개성에 따라 다양한 방법이 사용됩니다. 백로그를 예로 들어보면, 포스트잇에 할 일을 써서 사무실 벽에 붙여두는 팀도 있지만, 위키를 쓰거나, 심지어 엑셀로 정리를 하는 팀도 있습니다. 개발팀마다 고유하게 지닌 다양한 개성에 맞는 스크럼을 도입하려면, ‘어떻게’가 아닌 ‘왜’를 알아야 합니다. 그래서 이 책이 필요합니다.

『스크럼(Agile Software Development With Scrum)』은 단순히 실천법만 나열하는 책이 아닙니다. 오히려 실천법에 있어서는 정말 간단한 몇 가지만 언급하고 있습니다. 하지만, 이 책을 통해서 여러분은 저자들이 수십 년 간 여러 프로젝트를 해오면서, 때로는 팀이 크게 성공하기도 하고, 때로는 절망 속에서 프로젝트가 실패했던 경험을 생생하게 느끼실 수 있습니다. 그리고 그 과정에서 스크럼이 어떻게 생겨나고, 스크럼을 통해서 절벽 끝에 몰려 있던 팀이 성공적인 팀으로 거듭날 수 있었는지를 알게 됩니다. 경험 공유야말로 스크럼을 배울 수 있는 가장 좋은 방법입니다. 이를 통해, 스크럼의 겉모습이 아닌 정신을 팀에 적용할 수 있습니다. 또한, 복잡계 이론이나 지식변환(Knowledge Conversion) 같은 관련 지식도 덤으로 얻을 수 있습니다.

마지막으로, 스크럼이나 애자일이 팀의 목표가 되어 가는 건 아닌지를 항상 조심해야 합니다. 책에서도 여러 번 강조합니다만, 팀의 목표는 프로젝트의 성공이고 가치 창출이지, 외견상 드러나는 새로운 방법론의 성공적인 도입만이 되어서는 안 됩니다. 팀이나 회사의 분위기상 Waterfall 방식이 프로젝트의 성공에 더 적합하다면 주저하지 말고 그 방식을 이용해야 합니다. 또한, 팀원들에게서 스크럼이나 애자일 방법론을 도입해 보자는 얘기를 듣게 된다면, 왜 그런 얘기가 나오는지를 먼저 생각해봐야 합니다. 정말 새로운 방법론을 도입해서 프로젝트를 더 성공적으로 만들고 싶어서인지, 아니면 야근에 지쳐 애자일이 약속하는(혹은 약속하는 것처럼 보이는) 행복한 인간 중심의 개발 환경을 원해서인지를 살펴봐야 할 것입니다.

스크럼을 꾸준히 지속해 온 리니지2 개발팀 덕분에 스크럼의 장점을 실제로 느낄 수 있었고, 소신 있게 이 책을 번역할 수 있었습니다. 베타리딩을 해주신 심우곤, 한주영, 황승현, 남기룡, 황상철, 조동환 님께 감사드립니다. 원문 전체를 번역본과 비교해 가면서 꼼꼼히 챙겨주신 인사이트 김강석 님과 한기성 사장님 그리고 어려운 문장의 번역을 도와준 친구 테드(Ted)에게도 감사합니다. 저를 후원해 주시는 부모님과 옆에서 힘이 되어주는, 사랑하는 유영에게도 감사의 마음을 전합니다.

책에 대한 질문이나 오류 문의, 스크럼에 대한 토론 등은 http://andstudy.net 위키나 인사이트 이메일(insight at insightbook.co.kr)을 이용해 주세요. 감사합니다.

김기웅

‘스크럼’을 여러분께 소개하게 되어서 무척 기쁩니다. 이 기회를 통해 여기서는 제가 스크럼을 직접 실천하거나, 다른 사람들이 실천하도록 도와주는 과정에서 얻게 된 교훈들을 공유하고자 합니다.


스크럼을 도입하는 데 있어서, 가장 중요한 것은 믿음입니다. 그 이유는 무수한 반대들에 직면하여, “내가 틀린 것은 아닐까?”라는 자기 회의에 빠지기 쉽기 때문입니다. 만약 그런 상황이 닥친다면, 다음을 추천 드립니다.

– 스스로 실천해보고, 확신을 가지세요. 여러분이 믿지 못한다면, 그 누구도 설득시킬 수 없습니다. 반면에 여러분이 모범을 보이면, 따라오는 동료들도 생겨납니다.

– 관련 모임에 참석하세요. 그곳에서 “넌 미치지 않았어.”라고 확인해줄 사람들을 만나 보세요. (만약 시간이 없다면, 관련 메일링 리스트나 블로그를 활용하는 방법도 있습니다.)

– “상식은 보편적이지 않다(Common sense isn’t common).”는 말을 기억하세요.

후원자를 찾으세요. 후원자는 당신을 지지하고 방어해주는 사람을 말합니다. 그는 누구나 다 알만한 업적을 가진 임원일 수도 있고, 신뢰할 만한 동료이거나, 바로 옆에 있는 유능한 부하직원일 수도 있습니다. 중요한 것은, 그가 여러분의 시도가 외압으로 꺾이는 것을 막아주고, 필요한 자원들을 제공해주며, 정신적으로 탈진해 있을 때 사기를 북돋워준다는 점입니다.

연착륙을 시도하세요. 이상적으로 어떻게 해야 하는지에 대해서 이야기하는 책은 많습니다. 그러나 여러분의 상황에서 실제로 지금 당장 어떻게 해야 하는가를 알려주는 책은 어디에도 없습니다. 따라서 중간 단계(baby steps)를 신중하게 설정하는 것은 매우 중요합니다.

? 작게 시작하세요. 절대로 하루아침에 회사 전체에 적용하려고 하지 마세요. 자신부터 시작해서, 같이 일하는 동료, 그와 일하는 다른 동료…… 이런 식으로 서서히 퍼져나가도록 하십시오.

? 할 수 있는 것부터 시작하세요. 완벽하게 하려고 미루다가 하지 않는 것보다는, 작은 거라도 일단 실천하는 게 좋습니다. 프로그래머라면 자신의 코드에 단위 테스트를 삽입할 수 있고, 프로젝트 관리자라면 일일 스크럼 회의를 할 수 있습니다. 예를 들어, 이른 아침, 함께 일하는 동료에게 커피를 한잔 건네면서, 어제 한 일과 오늘 하려는 일을 물어보세요. 그게 시작입니다.

? 이름 없이 시작하세요. 많은 사람이 변화를 싫어합니다. 그게 거창한 이름을 달고 있다면 더욱더 그렇습니다. 낯선 용어, 특히 영어로 된 용어는 절대 사용하지 마세요.

? 호의적인 사람들에 집중하세요. 변화에 부정적인 사람을 변화시키려고 하면, 그 사람도 괴롭고, 여러분도 많은 에너지가 소모됩니다. 반면에 호의적인 사람에게 집중하면, 그 사람도 즐겁고, 훨씬 적은 수고로도 성과를 낼 수 있습니다. 그리고 다른 사람들도 하나 둘씩 호의적으로 변해갈 것입니다.

가치에 집중하세요. 스크럼을 한마디로 정의하면, “피드백을 좀더 일찍, 좀더 자주, 좀더 많이, 좀더 지속적으로 주고받자.”라고 할 수 있습니다. 스크럼은 그것을 통해서 장애물을 적시에 시각화하고, 상식을 적용해서 문제를 해결해 나갑니다. 나머지는 이것을 어떻게 보다 효과적이고, 효율적으로 실천할 것인가를 풀어놓은 것에 지나지 않습니다.

마지막으로 이 책이 나올 수 있게 도와주신 분들께 감사드립니다. 제가 지쳐있을 때, 이 책의 상당량을 번역해주신 박일 님, 그리고 저를 믿고 원고를 기다려주신 인사이트의 김강석 님과 한기성 사장님께도 감사드립니다. 더불어 이 책을 번역하는 사이에 소천하신 이철 님을 기립니다. 멘토이자 형, 그리고 친구였던 당신이 없었다면, 저의 인생은 많이 달라졌을 겁니다.

질문이 있으신 분은 betterways.tistory.com이나 agile4kay at gmail.com 혹은 인사이트 이메일(insight at insightbook.co.kr)을 통해서 연락주시기 바랍니다.

* 늦어도 10월 6일에는 서점에서 만나실 수 있을 겁니다.

Yes24, 강컴, 교보문고, 알라딘, 인터파크