제가 애자일 방법론, 즉 XP(Extreme Programming)를 실무에 처음 적용한 것은 4년 전이었습니다. 책과 이야기로만 전해 들었던 애자일 방법론을 프로젝트에 적용하고 싶었습니다. 운이 좋게도, 당시에 새로운 프로젝트에 참여하게 되었습니다. 그 프로젝트의 멤버는 저와 선배사원 한 명이 전부였습니다. 평소 코드가 비슷했던 선배사원을 꼬셨습니다.

"선배! 기존 개발방법론보다 결과도 더 낫고 결정적으로 칼퇴근이 가능한 방법론이 있다는데, 이번 프로젝트에 적용해 보는 게 어떨까요?"

사실 선배가 칼퇴근이라는 감언이설(?)에 넘어오지는 않았지만, 그 당시 우리는 칼퇴근 이상의 근본적인 변화를 원했습니다. 프로젝트 일정으로 채워진 달력이 몇 번이나 바뀌었지만, 프로젝트의 내용은 변화가 없었기 때문입니다. 즉, 우리가 참여했던 프로젝트는 주인공과 배경만 바뀌고 스토리는 비슷한 드라마와 같았습니다. 프로젝트 제안서는 항상 고객이 원하는 것 이상을 보여주었지만, MS 프로젝트에 적힌 일정은 현실과 이상의 괴리를 처절히 깨닫게 해주었고, 제안서에 속은 고객은 허기를 달래려고 프로젝트 팀원들을 잡아먹으려 했으며, 목숨이 위태로워진 팀원들은 제안서에 그려진 이상향을 땅 위에 실현시키고자 프로젝트룸에서 청춘을 보내야 했습니다.

그리고 우리 앞에는 또 다른 프로젝트가 놓여 있었습니다.

다른 사람의 도움 없이 책으로만 접한 애자일 방법론을 실전에 적용하기란 쉽지 않았습니다. 아침마다 의욕 넘치게 시작했던 스탠드업 미팅은 카페인 부족으로 생긴 금단증상 때문에 며칠씩 건너뛰었고, 호랑이의 기백이 가득했던 단위테스트는 고양이 울음소리 비슷한 printf( )가 되었으며, 나침반이라고 생각했던 현장고객의 목소리는 업무를 방해하는 소음처럼 들렸습니다. 의욕적으로 출항했던 애자일 프로젝트는 난파되기 직전이었습니다.

선배와 저는 뜨거운 인스턴트커피를 앞에 두고 고민했습니다. 즉, 애자일 방법론을 걷어내고 기존의 개발방법론을 따를 것이냐의 이야기였죠. 커피가 식을 때까지 벌인 난상토론의 결과, 우리가 실패한 원인은 애자일 방법론을 지나치게 교과서대로 따르려고 했다는 것이었습니다. 당시 XP 진영에서 나온 이야기대로라면 논란의 여지가 많은 생각이었지만, 너무나 많은 것을 한꺼번에 시도했다는 것이 실패의 원인이었죠. 즉, 애자일 방법론을 추구하는 우리의 자세는 전혀 애자일하지 않았습니다.

그리고 실현하기 쉬운 실천방법을 하나씩 적용했습니다. 가장 먼저 적용했던 실천방법은 짝 프로그래밍이었습니다. 아침 9시부터 저녁 6시까지, 우리는 같은 노트북을 앞에 두고 코딩했습니다. 사실은 쉽게만 생각했던 짝 프로그래밍이 가장 힘들었습니다. 당시까지의 회사 생활을 통틀어 그때처럼 업무 효율이 높았던 때는 없었습니다. 키보드를 붙잡으면 머리가 깨질 정도로 코드에 집중했고, 옆에서 지켜볼 때는 더 나은 알고리즘이 존재하는지, 코딩룰을 지키는지 끊임없이 살폈으며, 코드를 두고 쉬지 않고 토론했습니다. 결국 8시간 근무는 선택사항이 아닌 필수사항이 되어버렸습니다. 퇴근시간이 되면 집으로 갈 체력만이 남았기 때문입니다.
짝 프로그래밍이 자리를 잡자, 변화가 생기기 시작했습니다. 어느새 코드 공동소유는 당연한 일이 되었으며, 배움의 선순환이 시작되었습니다. 상대방의 강점이 배움의 기초가 되었기에, 둘의 실력은 향상되었죠. 또한 끊임없이 대화했기에, 의사소통의 작은 오해 때문에 생기는 구현의 큰 오류는 사라졌습니다. 작은 성공 경험은 우리에게 긍정적인 피드백을 주었으며, 결국 코드 품질을 높였습니다.

이 프로젝트는 어떻게 되었을까요? 사내정치적인 요소만 없었다면(애자일 방법론과는 전혀 관련이 없습니다), 더욱 결과가 좋았을 겁니다. 절반의 성공인 셈이었죠. 하지만 우리는 이 프로젝트로 애자일 방법론의 강력함을 깨달았으며, 많은 것을 배웠습니다.

그리고 4년이 흘렀습니다.

이제 애자일 방법론은 유비쿼터스해졌습니다. 즉, 애자일 방법론은 소프트웨어개발 분야를 넘어 다양한 산업계에 적용되고 있습니다. 애자일이 산업계 전반에 퍼지는 것처럼, 애자일 방법론의 발상지였던 소프트웨어 진영에서 보편화되었을까요? 다시 말해 4년 전에 제가 경험했던 것이 이제는 개발자들의 일상이 되었을까요?

개발 사이트나 개발자들의 블로그를 통해 보는 그들의 삶은 변한 게 없는 듯합니다. 일단 수주하고 보자는 개념 없는 영업자, 스스로를 왕이라고 생각하는 꽉 막힌 갑, 야근은 기본이고 특근도 필수라고 생각하는 관리자들, 미래가 보장되는 않는 불안한 개발자 인생.

물론 개발자의 인생이 고단한 것은 개발자들만의 탓이 아닙니다. 갑, 을, 병, 정으로 이어지는 말도 안 되는 하도급 관계, 과도한 업무량, 관리자의 형편없는 의식수준 등 수많은 것들이 개발자의 인생을 우울하게 만듭니다.

그러나 세상에는 두 가지가 존재합니다. ‘내가 바꿀 수 없는 것’과 ‘내가 바꿀 수 있는 것’입니다. 개발자들을 둘러싼 답답한 현실들이 ‘내가 바꿀 수 없는 것’이라면, 즐겁고 효율적으로 일할 수 있는 방법은 ‘내가 바꿀 수 있는 것’입니다.

아직도 지속적인 통합 도구는커녕 버전 관리 시스템조차도 사용하지 않는 프로젝트팀이 많습니다. 고객을 훌륭한 테스터로 여겨 단위 테스트를 쓸데없는 짓이라고 생각하는 개발자도 있으며, 팀원 간의 상호 의사소통보다는 반목이 팽배한 현장도 있습니다. 이 모든 것이 ‘내가 바꿀 수 있는 것’입니다.

물론 우리네 프로젝트 인생이 행복해지기 위해서, ‘내가 바꿀 수 없는 것’도 결국 바꾸어야 합니다. 그러나 우리에게 두 가지 길이 있습니다. 즉, ‘내가 바꿀 수 있는 것’에 열정을 쏟으며 조금 더 나은 오늘을 만드는 것과 ‘내가 바꿀 수 없는 것’을 탓하며 ‘내가 바꿀 수 없는 것’이기에 누군가의 도움만을 바라며 똑같은 오늘을 보내는 것입니다.

어느 쪽을 선택할지는 개인의 문제입니다. 다만 여러분이 조금씩 개선되는 길을 선택하였다면, 이 책이 쉽지는 않은 그 길을 안내해줄 겁니다.

과연 어떻게 하는 것이 애자일한 것일까?
- 권정혁(http://xguru.net/blog/)

애자일, XP, SCRUM 등을 소개하는 책이나 블로그 글 등을 통해서 정보는 많이 얻을 수 있지만 애자일한 프랙티스들이 어떻게 실무에 적용되는 것인지에 대한 설명이나 관련 자료가 부족하여 실제로 개발자가 이를 적용해 보기는 쉽지 않은 게 사실이다.
과연 어떻게 하는 것이 애자일한 것일까? 애자일한 프랙티스들은 어떻게 실천할 수 있을까?
『애자일 프랙티스』는 이렇게 XP와 Agile 개념은 알고 있지만 실행해 보기 힘들었던 사람들에게 실전에서 어떻게 애자일 프랙티스들을 적용할 수 있을지를 알려주는 좋은 가이드북이다.
간결한 문체로 흥미로운 예제 사례 및 유머들과 함께 개발자가 따라야할 45개의 실천항목들을 제시하고 있다. 또한 실천항목의 나열만이 아니라 각 실천항목을 실제 적용했을 때 우리에게 나타날 수 있는 변화와 그 변화에 있어서 어떻게 균형을 맞춰나가야 하는지를 세세하게 설명하고 있어서, 핸드북처럼 옆에 두고 종종 펼쳐 보고 싶은 생각이 들게 한다.
애자일 관련 서적들을 보면 많은 개념들이 영어권에 익숙한 사람들이 쓰는 용어로 되어있어서 번역이 쉽지 않은 게 사실이다. 이 책의 번역서에 대한 리뷰를 부탁 받았을 때 과연 어떤 식으로 번역이 되어있을까 궁금했었는데, 역자인 신승환님은 블로그를 통해 소프트웨어 공학적인 이슈들을 많이 얘기해 오셨던 분이라 그런지 아주 매끄럽게 번역이 되어있었다. 원서의 간결한 느낌을 그대로 전하려고 노력한 흔적이 많이 보인다.
이전의 Pragmatic Programmers의 책들과 마찬가지로 아마존에서도 별 4개 반 이상의 좋은 평가를 받고 있으며, 애자일을 실전에 적용해 보고 싶은 개발자 분들께는 좋은 시작점이 될 것이다. 아니, 꼭 애자일을 적용해보고 싶은 개발자가 아니더라도 이 책은 도움이 될 수 있다. 각 실천 항목에서 보이는 문제점들이 자신의 주위에서도 일어나고 있다면, 이 책에서 제시하는 대로 행동해 보라. 어느 순간 애자일한 개발자가 되어있는 당신을 발견하게 될 것이다.


일상에서의 경험과 이를 개선하기 위한 작은 변화를 통한 성장에 초점
- 김성안(http://www.pragmatic.co.kr/blog)

애자일 프랙티스는 기민한 개발자가 되기 위한 "시작점이 되는 개발자의 태도, 습성 기르기, 고객 관점에서 개발하기, 피드백 활용, 개발, 디버깅, 협력"이라는 주제에 관한 45개의 실천사항을 정리한다. 각각의 실천방법만으로는 "스탠드업 미팅"과 같이 이미 알려진 실천방법도 다수 있고, "아이디어를 비난해야지 사람을 비난해서는 안 된다"와 같은 너무나도 당연해 보이는 실천방법도 포함한다. 하지만 단순히 45개의 실천방법을 잘 정리한 것 이상의 무언가가 있다.
먼저, 45개의 실천방법 중에서 (당연한 걸 포함해서) 얼마나 적용하고 있는지 자신에게 묻자. 책 전체에 걸친 천사의 조언과 악마의 유혹은 이미 무엇이 옳은 것인지 알지만 실천하지 못하는 우리의 마음을 잘 표현하는 수단으로서 흥미로운 존재이다. 모든 예외상황은 로그를 남기고 적절히 조치해야 함을 알면서도 당장 눈에 보이는 문제가 없기 때문에 숨겨두기도 하고 (그러고는 나중에 문제가 발생하면 숨겨둔 문제를 찾느라 엄청난 노력을 들이기도 하고), 문제가 있는지 알면서도 소스코드를 버전 관리 시스템에 체크인하기도 하는 평범한 개발자를 위한 책이다.
애자일 개발과 관련된 많은 책들을 볼 때 느낌은 "좋아 보이기는 하는데 하지만 이 사람과 팀이 열정적이고 대단하기 때문이겠지, 나와 우리 팀은 힘들 거야"와 같이 나와는 상관없는 이야기로 치부하고는 한다는 점이다. 애자일 프랙티스는 "맞아! 이런 상황이 있었지. 그땐 시간에 쫓겨 어쩔 수 없었지만 나중에 더 힘들어지더라."와 같은 개인의 일상에서의 경험과 이를 개선하기 위한 작은 변화를 통한 성장에 초점을 맞춘다. 45개의 실천방법 중 필요성을 느끼고 적은 노력으로 시작할 수 있는 것부터 시작한다면 나중에는 작은 변화들이 쌓여서 큰 변화를 만들 수 있다.
하루하루 자신의 잘못을 알지만 지나치거나, 자신이 무엇을 잘못 했는지 모른 채 잘못을 저지르는 평범한 개발자에서 든든한 기초를 가진 기민한 개발자가 되고자 한다면 좋은 시작점이 될 것이다. 얇고 부담 없는 책이라 읽기 시작한 책을 몇 번이고 다시 펼쳐보는 자신을 발견할 것이다. 조직을 평가하기 위한 수단으로 인기를 얻었던 조엘 테스트와 같은 느낌으로, 자신을 평가하기 위한 수단으로 애자일 프랙티스의 항목을 점검표로 사용하면 자신의 위치를 객관적으로 바로 보는데 많은 도움이 될 거라고 생각한다. 마지막으로 요즘 번역되어 나오는 많은 책들(애자일 프랙티스를 포함해서)의 자연스러운 번역 덕분에 좋은 내용을 빠르게 습득할 수 있게 되어 좋다.


업무 효율도 좋지만 이제는 인간다운 삶을 누리고 싶다는......
- 쿵야 어드벤처 게임 프로그래머 손경욱(http://writely.tistory.com/)

요즘 많은 사람들이 애자일 개발에 새롭게 관심을 가지고 궁금해 합니다. 관심이 없다고 하면 시대에 뒤떨어질 것 같은 기분이 들 정도입니다. 업무 효율도 좋지만 이제는 인간다운 삶을 누리고 싶다는 심리의 반증이 아닐까 합니다. (그렇다고 기존의 방법론이 효율이 높을까요? 저는 부정적입니다만.)
지금까지 애자일 방법론의 대표 격인 XP나 스크럼(Scrum)은 선각자에 의해 알음알음 전해져 왔지만 애자일 자체에 대한 것은 없었습니다. 그도 그럴 것이 애자일 자체는 형체가 있는 것이 아니고 그와 같은 경량 방법론들을 통칭해 부르는 말이니까요. 여러 방법론이 하나의 이름으로 불리는 것은 그들 사이에 공통점이 많다는 것을 의미할 겁니다. 그리고 그 공통점은 의미 있고 가장 중요한 부분일 가능성이 높습니다. 우리는 어떤 방법론을 선택하기에 앞서, '그럼 애자일한 개발이라는 것은 도대체 무엇인가?'를 알 필요가 있습니다. 이 책은 바로 그런 기대를 충족시켜 줍니다.
리뷰를 위해 원고를 받아들고 출퇴근길에 한 단원씩 읽었습니다. 처음에는 정말 좋아서 흥분할 지경이었지만 점점 그렇지 않게 되더군요. 제가 운영하는 블로그에 올리려고 가 편집 상태로 놓아 둔 다양한 소재를 다루는 이미 훨씬 더 좋은 글이 이 책에 들어 있었던 겁니다. 한 장 한 장 읽어갈 때마다 좌절을 하게 됐죠. 하긴 제가 블로그에 올린 글을 누가 보겠어요? 대신 실용주의 프로그래머로 유명한 앤디와 벤캣의 책을 보십시오.
지금에 와서 애자일은 다양한 분야에서 새삼스럽게 다시 회자되고 있습니다. 여러 권의 책이 나오고 사람들의 경험담이 전해져 옵니다. 지금이 기회입니다. 보다 인간다운 개발을 통해 어렸을 때 느꼈던 열정을 되찾읍시다.


‘애자일 = 실용주의’
- 주성식(http://www.codingstar.net/tts/)
소프트웨어 프로젝트를 진행하고 있는 많은 개발자들은 한해한해 지나갈수록 어려움을 호소하고 있다. 새로운 툴, 새로운 언어, 새로운 기술들이 아무리 쏟아져 나와도 상황은 그리 나아지고 있는 것 같지 않다. 이쯤에서 마인드의 전환이 필요함을 재고(再考)해 볼 수 있음은 극히 자연스러운 일이라 할 수 있겠다. 이러한 고민을 가지고 있던 중에 이 책을 읽게 되었다.
이 책에서 이야기 하는 애자일 방법론을 위한 practice들을 따라가다 보면 ‘애자일’ 이라는 한정된 단어를 벗어나 ‘실용적’, ’합리적’, ’효율적’이라는 의미로 확장되는 것을 뚜렷하게 느낄 수 있다. 이 책은 팀 내부의 의견 조율, 고객과의 효율적인 커뮤니케이션, 코드 베이스의 안정적인 관리, 자연스럽게 실천할 수 있는 TDD 방법, 해결책 로그 작성법 등을 자세한 예를 들어 보여 주고 있다. ‘애자일 프랙티스’를 읽으면서 저자의 경험을 간접 체험할 수 있는 유익한 시간을 보냈다. 나 스스로 현재 처한 프로젝트의 상황을 대조해 볼 수 있었으며 ‘애자일’ 이라는 단어를 낯설지 않게 느낄 수 있었다.
이제 책의 내용을 팀 사람들과 함께 공유할 차례다. 책에 소개된 프랙티스들 중 마음에 드는 것을 각자 하나씩 선택하고 간략한 스탠드 업 미팅을 진행해보자. 이렇게 마음에 드는 프랙티스들을 하나씩 실천해 나가다 보면 어느 새 우리의 팀은 성취감에 하루하루를 즐겁게 마무리 할 수 있는 ‘애자일’ 팀으로 변신해 있을 것이다.

기민한 개발자의 자질을 45개로 나눠 조목조목 설명
- 최재훈(http://kaistizen.net/)

소프트웨어 개발자의 자질과 역량을 다룬 책은 곰곰이 생각해보면 얼마 되지 않는다. 신기술의 명세를 다룬 책이나 프로젝트 관리를 말하는 책은 많지만, 의외로 프로그래머 자신에 관한 책이 많지 않다는 건 안타까운 일이다. '실용주의 프로그래머'가 거의 10년이 가깝게 사랑받는 이유도 이 때문이 아닐까? 이제 다시 앤디 헌트가 '애자일 프랙티스‘로 돌아왔다. 기민한 개발자의 자질을 45개로 나눠서 조목조목 따져나간다. 여기서 그치지 않고 실천 지침까지 알려주니 더할 나위 없다. 타성에 젖은 고참이든, 현업에 막 뛰어든 신참이든 각자 느끼고 얻는 바가 있으리라 생각한다.