애자일 아버지의 고함과 호통 (리뷰：Clean Agile - Back to Basics)

　‘애자일’ 이라고 하면 무엇이 떠오르는가? 잘은 모르지만 막연하게 생각을 해보면, 매일 오전 스크럼을 하고 진행 현황을 가시화하며 프로젝트를 성공적으로 이끄는 일종의 ‘프로세스’로 알고 있다. 좋다는 것도 들었고 도입을 하려 하지만 뭔지 모르게 잘 안되는 그것. 현업에 들어오면서 ‘애자일’ 도입의 성공/실패에 대한 이야기를 가끔씩 건너건너 들어만 본 수준이다. 이제는 주니어도 시니어도 아닌 중니어가 되어보니 알고리즘이나 패턴, 신기술도 중요하지만 팀과 프로젝트 전반의 건강하고 성공적인 진행을 위해서는 이러한 활동들이 중요하구나 하며 요즘 (올해) 뼈!저!리!게! 느끼는 중이다.

　마침 크리스마스 연휴를 앞두고 이 시국에 나가지도 못하는데 뭘 해야 하나 고민하고 있던 찰나 운명처럼 클린 애자일, 저자 로버트 C. 마틴이라는 책 추천을 받는다. 보통 필자는 읽고 싶은 책을 고를 때 중요하게 생각하는 두 가지가 있는데 표지와 추천인(혹은 리뷰어)의 대한 신뢰. 둘 다 너무 좋았기에 바로 인터넷 주문을 하였지만 그새를 못 참고 근처 서점에 들러 책을 사 온다.

갑.분.돈(키호테)

　풍차나 폭포를 공격해본 모든 프로그래머에게

　호기롭게 첫 장을 넘기는데 강렬하게 다가오는 문구. 옮긴이에 따르면 세르벤테스의 소설 ‘돈키호테’에서 주인공 돈키호테가 풍차를 공격하는 모습에서 온 표현이라 한다. 대부분 헛되고 무모한 싸움을 하는 사람들을 빗대어 이야기하며 바보 혹은 현실 부적응자로 갈음하는 표현으로 사용된다. 러시아 작가 이반 투르게네프는 햄릿을 사랑하기는 힘들지만 돈키호테는 사랑하지 않기가 힘들다는 이야기를 했다고 한다. 아마 저자는 고민보다는 행동을 중요하게 생각했던 돈키호테를 빗대어 현실에 안주하지 않고 건강한 개발 문화를 개선하려는 모든 프로그래머에게 조언과 박수를 보내려 했던 건 아닐까 싶다.

책의 구성

　페이지 수(230p)가 많지 않아서 가볍게 읽을 수 있겠다 싶었지만 다소 작은 글씨들로 구성되어 있어서 책을 잘 안읽었던 필자에겐 약간 부담으로 다가왔다. 하지만 내용들이 너~무 공감이 되어 마치 필자의 2020년을 오래전에 예견하고 미리 써둔것 같은 느낌을 받았을 정도라 아침 5시에 일어나 저녁 11시가 되어서야 다 읽을 수 있었다. 처음 들어본 용어나 이해가 잘 안되는 개념들도 있어 다음날 노트북을 옆에 두고 찾아가며 다시 읽기도 하였다. (그만큼 제대로 읽어보고 싶었다.)

　책 초반부터 저자는 이 책을 ‘선언’이나 ‘정의’ 가 아닌 애자일에 대한 ‘경험’을 토대로 오해를 바로잡는다라고 이야기하고 있다. 2001년 2월, 애자일 선언이 발표가 되었고 내년이면 20년이 돼가는 시점에 여러 가지로 변형된 ‘애자일 방법론’이 나왔지만 애자일의 기준을 다시 소개하며 본질을 흐려선 안된다고 이야기한다. (책이 부 제목이 Back to Bascis인 것을 보면 …)

　흥미진진한 책 내용 중에 아직까지도 머릿속에 남아있던 애자일과 자주 비교되는 ‘폭포수 모델’로 프로젝트를 진행한 부분을 필자가 이해한 대로 적어보려 한다. (너무나도 끔찍하게 공감되기에…)

그래서 애자일이란?

　저자는 모든 일련의 과정을 작은 단위로 나누는 것부터 시작하라고 한다. 애자일은 작은 팀 단위에 어울리는 것이라고도 뒷부분에 이야기한다. 또한 애자일은 데이터를 생산하기에 관리자는 만들어진 데이터를 가지고 업무를 진행해야 한다고도 말한다.

　프로젝트의 일정 압박이 온다고 사람을 두 배로 늘리면 속도가 두 배로 늘어나지는 않고 (오히려 속도가 투입 직후 두 배로 줄어들 수 있는 비용(ROI)를 관리자는 감내해야 한다.) 품질을 떨어뜨린다고 속도가 빨라지는 건 아니다. (쓰레기를 만든다고 빨리 갈 수 없다. 오히려 품질을 올려야 속도가 빨라진다.)

　이 책을 읽고 필자가 생각하는 진정한 ‘애자일’이란, 론 제프리즈(Ron Jeffries)의 ‘삶의 순환’ 도표에서 나와있는 익스트림 프로그래밍(XP)의 실천 방법들로 비즈니스, 팀, 기술에 적용하며 구성원 모두가 함께 하는 모든 것이라 생각한다. 그것을 실행할 수 있는 가장 큰 힘은 ‘데이터’.



이 책은 누가 읽어야 할까?

　대부분 애자일은 ‘개발자’가 실천해야 한다 하지만 결국엔 하나의 프로덕트를 만드는 모든 구성원이 함께 해야 시너지 효과가 있다고 생각한다. 그 중심엔 애자일을 도입하며 진행하는데 올바른 길로 인도해 주거나 다양한 측면에서 도움을 주는 ‘컨트롤 타워’가 있어야 하는 건 당연한 일. 그럼에 이 책은 기획, 설계, 운영, 개발, 디자인, QA 등 모든 IT 직군이 한 번쯤은 읽어봐야 할 내용이라 생각한다. (적어도 애자일을 조직 내에 도입을 할 거라면 선행 교육과 서로의 이해 수준을 맞추는 과정 또한 필요할 테고..)

　꼭 필자 같은 중니어 나 시니어가 돼야지만 이러한 부분들에 관심을 가져야 하는 건 아니라 생각한다. 연차에 따른 암묵적인 개발자의 성장 로드맵이 있긴 하지만 순서를 결정하는 건 본인이기에. 오히려 이러한 애자일 (혹은 폭포수 모델) 에 대한 관심을 신입 때부터 갖는다면 보다 건강한 개발 문화를 만드는데 기여할 수 있는 부분이 훨씬 많아지지 않을까 감히 적어본다.

마치며

　애자일 선언이 된지 벌써 20년이 된 지금. 저자는 자꾸 좀 변형하지 말고 기본으로 돌아가라며 ‘다시 한번’ 애자일에 대한 목소리를 내고 있다. 필자가 태어나지도 않았던 1970년부터 프로그래머로 살아온 저자의 목소리가 20년이 지난 아직까지도 대두되고 있는 것을 보면. 그리고 이 책 내용과 필자가 경험한 ‘실패한 프로젝트’를 함께 생각해 보면 당장이라도 팀 내에 도입해 보고 싶다는 의지를 불태우게 해주는 것 같아 상당히 만족스러웠다.

　몇 가지 인상 깊었던 문구가 있어 밑줄을 쳐놨는데 울림이 많은 문구인 것 같아 적어본다. 아래 문구를 보고 개발 문화에 대해 갈증이 있던 독자라면 당장 구매 버튼을 누를 것만 같다. 

• 오래된 메시지지만, 옳은 메시지다. 이 메시지는 작은 일을 하는 작은 소프트웨어 팀이 겪는 작은 문제에 대한 작은 해결책을 알려준다.

• 당신은 코드의 변경을 두려워하고, 두려움 때문에 무능력해진다. 결과가 두려워서 필요한 코드 정리를 하지 못한다. 자신이 만든 이 코드를 완전히 통제할 수 없을 정도로 놔두었기 때문에 코드를 개선하는 일을 두려워하게 된다. 정말 무책임하다.

• 소프트웨어(Software)는 합성어다. ‘웨어(ware)‘는 ‘제품(product)‘을 의미한다. ‘소프트(soft)‘는 바꾸기 쉽다는 뜻이다. 따라서 소프트웨어는 바꾸기 쉬운 제품이다.

• 빌드를 깨 먹는 사람이 지켜야 하는 간단한 규칙을 하나 만들었습니다. 빌드를 깨먹은 날에는 “빌드를 깨 먹었어요"라고 적혀있는 티셔츠를 입어야 합니다. 참고로 이 티셔츠는 절대 빨지 않습니다.

• 마감 일정의 압박이 심해지면 지속적 빌드를 깨진 채로 방치하는 팀이 더러 있다. 이건 자살행위다. 지속적 빌드 서버에서 쏟아지는 실패 메일에 지친 나머지 실패하는 테스트를 아예 빼버린다. ‘나중에’ 다시 추가하고 고칠 거라고 다짐했을 것이다. 덕분에 빌드 서버가 다시 성공 메일을 보내기 시작하고, 모두 안도의 한숨을 내쉴 것이다. 빌드가 통과했다. 그리고 ‘나중에’ 고치기로 하고 치워둔 실패하던 테스트 무더기는 모두가 잊어버린다. 결국 망가져 있는 시스템이 배포된다.

 　끝으로, 이 책을 소개해준 asuraiv 님도 책 리뷰를 적었다고 하니 도움이 될것 같아 블로그 링크를 남겨 본다.