Book on

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

Sun, 27 Dec 2020 17:06:19 +0900

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

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

갑.분.돈(키호테)

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

풍차를 괴물로 보고 달려들었던 돈키호테

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

책의 구성

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

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

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

폭포수 모델로 프로젝트를 진행한 사례

프로젝트 관리자가 마감기한을 확인하고 회의를 진행한다. 지금은 1월이고 출시가 10월이니 각 일정은 거꾸로 계산하여 개발은 QA 기간 고려 9월에 종료, 설계는 7월에, 분석은 늦어도 4월까진 하는 걸로 ‘못 박는다.’ (네…?)

그렇게 여유롭게 시간을 보내다 4월이 되어 분석 단계가 끝난다. 왜? 4월이 됐으니까. 또 시간이 흘러 7월이 되자 기적이 발생한다. 설계 종료. 왜? 7월이 됐으니까. 그 후 남은 2개월 동안 개발자들은 엄청난 압박과 급증하는 야근과 함께 하나둘씩 팀을 떠나고 그만두기 시작한다. QA에서 확인한 버그가 셀 수 없이 쏟아져 나온다. (소름 1)

하지만 10월에 출시하기로 했으니 버그나 에러가 터져 나오지만 출시를 하고. 프로젝트는 실패로 돌아간다. 그리고 회고를 하고. 다음번엔 제대로 해야지! 하며 다짐한다. (소름 2)

저자는 이것을 따라잡을 수 없는 프로세스 인플레이션(Runaway Process Inflation)이라고 부른다. 우리는 될 리가 없는 일을 계속하려고 한다. 그것도 아주 많이.

매니저는 정말 개발자의 무덤일까? (리뷰 - 개발자 7년차, 매니저 1일차)

Thu, 26 Mar 2020 23:37:17 +0000

개발자로서의 커리어는 정말 다양하지만 필자가 보고 들은 경험을 아주 일반화 시켜 정리해 보자면 다음과 같다.

처음엔 전공/비전공을 불문하고 신입으로 개발을 시작하여 다양한 개발 경험을 하게 된다. 사수에게 혼나기도 해보고 또는 혼내줄 사수가 없어 혼자 끙끙 밤도 새보고, 다크서클과 거북목을 겸비한 이른바 “삽질"을 하며 고통의 시절을 보내고 나면 어느덧 승진(진급)을 하며 일정 규모의 “팀장(혹은 관리자)“이 된다. 그게 자의든 타의든. 개발자는 다소 “기술"이라는 특수성을 가지고 있지만 어느 직군이든 간에 이러한 커리어 패스의 흐름은 매우 비슷하게 흘러가는 것 같다. 적어도 필자가 보고 들은 것만 보면 말이다. (예외 케이스는 항상 있지만…)

하루는 팀장님과의 면담 중에 “이제는 마냥 눈앞에 있는 개발만 할 것이 아니다. 기술을 좀 더 깊게 들여다보는 자리와 사람을 관리하며 주어진 과제를 진행하는 자리, 둘 중 선택해야 하는 시기가 온 것 같다. 더 높고 더 멀리, 그리고 더 넓게 볼 줄 알아야 한다.“라는 말씀을 듣게 된다. 어느덧 “그 시점"이 다가온 것이다. 개인적으로 필자는 팀장님이 말씀하신 두 가지 중 전자에 좀 더 가깝게 다가가고 싶다. 그만큼 오래오래 “실무 개발"을 하고 싶고, 또 그만큼 개발이 재밌기 때문이다. 아직도 눈앞의 문제를 해결하기 위해 개발하며 시간 가는 줄 모를 만큼 밤을 새우는 게 재미있는 걸 보면…

요리하는 걸 좋아하지만 이상하게 치킨집은 하고 싶지 않다.
출처 : https://catapult.tistory.com/entry/%EC%B9%98%ED%82%A8%EC%A7%91%EC%9D%B4%EB%82%98-%EC%B0%A8%EB%A0%A4%EC%95%BC%EC%A7%80

어느 날 SNS 피드에 개발 관련된 소식들을 받아보다가 개발 7년차. 매니저 1일차라는 제목의 책을 보게 된다. 뭐야, 이거 내 이야기 아니야? 하며 귀신에 홀린 듯 사서 읽어보려는 찰나, 마침 한빛미디어 에서 주최하는 나는 리뷰어다 라는 이벤트를 발견하게 된다. 결국 리뷰어에 당첨이 되고 운 좋게 해당 책을 받아볼 수 있었다. (이 책을 읽게 해준 한빛미디어 측에게 이 글로나마 감사의 인사를 전하고 싶다.)

필자의 SNS를 장식했던 ‘개발 7년차, 매니저 1일차’

이번 포스팅에서는 우선 책에 대한 리뷰를 간단히 적어보고 거기에 필자의 생각을 조금 더 얹어보고 싶다. 필자를 두고 만들어진 책 같아서 아직도 책 표지만 봐도 신기하고 설렌다. 일단 책 표지나 제목이 맘에 든 건 감출 수 없는 사실이다.

신입 혹은 주니어 개발자가 읽어봐도 좋을 책.

제목만 보면 이제 갓 팀장 혹은 매니저를 하게 되는 사람에게만 해당되는 책으로 보인다. 표지 상단에 “개발만 해왔던 내가, 어느 날 갑자기 ‘팀’을 맡았다!” 적혀있기도 했으니까. 하지만 책을 읽다 보면 꼭 그렇지마는 않다. 멘토링을 할 때엔 멘토와 멘티 각자의 위치에서 어떤 자세로 서로를 맞이해야 하는 방법에 대해서도 알려주기도 하고 무작정 눈앞에 있는 기능 개발만을 하며 안갯속을 걷는 주니어 개발자가 미리 미래를 경험해보는 좋은 사례를 들어 알려주고 있기 때문이다.

꼭 누군가 혹은 무언가를 “관리"하는 입장이 아닌 “팀"이라는 공동체 사회, 특히 개발 팀에서 팀원들과 협력하는 방법론을 살펴보고 있고, 경력이 낮으면 안 보이는 부분들까지 마치 멀리 있는 것을 대신 망원경으로 보여주는 느낌이 들었다. 앞부분에는 “이 책을 읽는 방법"이라며 상황별로 읽는 챕터를 가이드 해주고 있지만 사실 어느 하나 중요하지 않을 내용이 없어서 처음부터 무언가에 홀린 듯 읽을 수밖에 없었고 선배님이 앞서 지나간 길을 올바르게 지나갈 수 있도록 가이드 해주는 느낌으로 중간중간 사례가 있어서 현업에 있어서 그런지 좀 더 쉽게 읽힐 수 있었다.

다 읽고서야 알아차린 번역서(?)라는 사실.

어떠한 XX 기술 서적에서는 Method를 ‘방법’, Overriding 을 ‘과적’이라고 번역한 책들이 있는가 반면, 이 책은 읽는 내내 국내 어떤 분이 쓰신 거라 생각하고 읽어내려 갔지만 다 읽고 보니 외국에 어느 CTO가 쓴 책을 옮겨서 다시 써진 책이었다. 그만큼 전혀 특유의 번역 느낌(?)은 없었고 오히려 한국 문화에 맞춰 다시 써진 건 아닐까 싶을 정도로 너무 술술 잘 읽혔다.