Ship it!

479758 Ship it! 238137 2007-09-19T16:17:40Z http://heycalmdown.springnote.com/pages/479758 2007-09-17T12:38:12Z <blockquote> 서문을 다 읽고 본문을 8페이지까지 읽었다. 이 책을 다 읽고 나서 쓰는 글은 결코 예전과 같을 수 없을 것 같다는 예감이 든다. </blockquote> 위의 메모는 지난 12일 회사에서 서문을 막 다 읽고, 본문을 몇 쪽 읽다가 적은 것입니다. (얼마 전부터 <a href="http://openyourbook.net/hey" title="오픈유어북" class="external">오픈유어북</a>을 다시 사용하고 있어요.) 몇 쪽 읽지도 않았는데 앞으로 제가 하려고 하는 이야기가 이미 다 담겨있을 것 같은 예감이 들어서 그랬었습니다. 이 비슷한 얘기를 얼마 전에도 한 것 같은데, 어디였더라…. 저는 주로 지하철로 출퇴근 하는 중에 책을 읽기 때문에, 마음에 드는 구절을 휴대전화에 달린 카메라로 찍어 두었다가 오픈유어북에 옮겨 적었습니다. 책에 줄 긋는 걸 좋아하지 않거든요. 지금부터 제가 뽑아 놓은 책갈피들을 제 경험담과 함께 소개 해볼까 합니다. <h3>책갈피 </h3> <blockquote> 팀 환경이란 대부분 팀 구성원이 무엇을 요청했는가, 무엇을 체험했는가에 따라 달라집니다. 어떤 도구나 기법, 그리고 프로세스가 회사에 긍정적인 영향을 미칠 수 있는지 알아뒀다가, 제안할 일이 있을 때마다 명확한 이유를 제시할 수 있어야 합니다. p. 10 </blockquote> 여러분은 어떤 환경에서 일했는지요? 여러분이 무엇을 요청하거나 체험담을 이야기할 수 있는 위치에 있기 전에는 누가 그것을 결정했나요? 팀 환경에 개선이 있었다면 누구에 의해서였나요? <blockquote> 누군가가 업무처리 기법을 먼저 사용해보고 쓸만하다 싶어서 팀과 공유하는 일은 흔합니다. 우리는 이런 일을 반복해왔고, 다른 이가 그렇게 하는 걸 지켜봤습니다. p. 12 </blockquote> 변화는 대개 외부에서 옵니다. 팀에서 리베로 역할을 하는 기술 전도사(Technical Evangelist)가 있다면 좋겠지만, 그렇지 않다면 새로운 사람과 함께 새로운 문물이 들어오기 마련입니다. 우리는 변화를 두려워 합니다. 하지만 팀에 새로운 사람이 들어와서 벌이는 이런 저런 일은 묵인하는 경우가 많습니다. 신기한 일이죠? 사실은 변화 자체가 두려운 것이 아니라 변화를 시작하는 일에 용기 내기를 어려워 하기 때문인 것 같습니다. 지금 하려는 일이 옳은 일이고, 또 그가 그 일을 기꺼이 맡아 주겠다면야 우리에게는 그런 제의를 얼마든지 받아들일 수 있는 아량이 있습니다. 게다가 누구든지 처음엔 의욕에 넘치기 마련이니 일이 시작될 수 있는 거죠. 제 경험을 떠올려 봐도 입사 초기에 새로운 도구나 프로세스를 도입한 경우가 많았습니다. 지난 번에는 CVS였고, 이번 팀에서는 SVN이 대표적입니다. 그 얘기를 조만간에 할 기회가 있을 겁니다. 팀이 받아들이기 쉬운 것은 좋다고 들어 아는 것보다 누군가 실제 체험한 것일 경우가 많습니다. 예전엔 당연하게 생각했던 것이 지금은 없다면, 불편함을 참기 힘들기 때문에 팀원들을 더 열심히 설득할 동기가 됩니다. 또, 그래야만 우리가 뒷걸음질 하지 않고 다만 한 발짝이라도 더 나아갈 수 있는 것이겠지요. <blockquote> 이런 도구들이 출현하기 전에는 우리가 하루 동안 나누는 대화는 대부분 빌드 실패에 대해 사람들에게 질문하거나 API 변경을 통지하는 것이었습니다. CruiseControl.NET이 빌드를 처리해주기 때문에, 개발자들은 빌드를 원래 상태대로 유지하는 게 얼마나 중요한지 이해했고 그렇게 하려고 헌신했습니다. p. 14 </blockquote> 이 구절이 말하는 내용이 중요한 건 아닙니다. CruiseControl.NET을 사용하라는 얘기는 너무 노골적이잖아요. 제가 동감한 것은 '개발자들은 … 이해했고'라는 부분이었습니다. 제 생각에, 아는 것은 그렇게 중요하지 않아요. 하지만 이해하는 것은 중요합니다. 이 아는 것과 이해하는 것의 차이는 극적입니다. 지난 글, '<a href="http://writely.tistory.com/17" class="external" title="'자주 통합하고 커밋 알림을 사용하세요">자주 통합하고 커밋 알림을 사용하세요</a>'의 서두에서 말하려고 했던 것도 그것이었는데 잘 전달이 되었는지 모르겠습니다. 제 경험으로 그 차이는 놀라울 정도였어요. 하지만 이건 제 글솜씨로 몇 문장에 걸쳐서 이야기할 수 있는 주제가 아니네요. 지면이 좁아서 마저 다 적을 수가 없습니다…. <blockquote> 어쨌거나 훌륭한 기술 리더라면 여러분이 '목록'을 사용한다는 걸 눈치채고, '목록'을 팀 전체를 위한 용도로 사용할 겁니다. 좋은 습관이 얼마나 자주 전파되는지 알게 되면 놀랄 겁니다. 그러기까지 시간이 걸릴진 몰라도, 사람들은 뭐가 좋은지 눈치챕니다. p. 85 </blockquote> 기술 리더는 이 책에서 꾸준히 주장하는 큰 축 중에 하나입니다. 기술 전도사이자 멘토쯤 되는 사람으로써, 프로젝트나 제품을 책임지지는 않지만 팀이 기술적인 면에서 방향을 잃지 않도록 큰 그림을 보는 사람이 필요하다는 것입니다. 꼭 기술 리더가 아니더라도 좋은 습관은 팀 전체로 퍼져 나가는 것을 볼 수 있습니다. 때로는 전혀 그렇지 않은 게 아닌가 생각되는 때도 있지만요. 이것을 촉진하는 가장 좋은 방법이 짝 프로그래밍이나 멘토링이 아닌가 싶습니다. <blockquote> 팀 전체와 좀 더 자주 만나서 모든 사람이 자기가 무슨 일을 하고 있는지 공유하도록 하세요. 진행 방향을 수시로 바로 잡는 게 목표입니다. 여러분이 차를 몰아 길을 따라 내려가고 싶을 때, 한 방향을 정해놓고 그쪽에만 매달리지는 않을 겁니다. 가고 싶은 방향으로 차를 움직여놓고, 바퀴를 왼쪽, 오른쪽으로 틀면서 조금씩 방향을 조정해 갑니다. 방향 조정을 해주지 않고 버티다 보면 결국 도로를 벗어나 차를 망가뜨리게 됩니다. 소프트웨어 프로젝트도 마찬가지라, 조금씩 조정해주지 않으면 부서져버립니다. p. 95 </blockquote> 사실 서문에서 켄트 벡의 이름이 나왔을 때 짐작을 했습니다. 이 저자들은 우리랑 별로 다르지 않게, 소프트웨어 영웅들에 푹 빠져 있는게 아닌가 말이에요. 실용주의 프로그래머인 앤디 헌트, 데이브 토머스, XP의 켄트 벡, 마틴 파울러… 이들이 바로 그들이죠. 물론 어느 누구 하나 부족함이 없고요. 위의 인용은 사실은 켄트 벡의 <a href="http://xper.org/wiki/xp/TestDrivenDevelopmentByExample" title="TDDBE" class="external">TDDBE</a>에서 소개된 일화입니다. 그의 어머니가 처음 운전 면허를 딴 그를 운전석에 앉히고서 들려준 말이라고 하죠. (참고로 그의 어머니는 그에게 차의 방향을 길과 똑바르게 놓도록 하고 눈을 감으라고 하셨답니다. 마치 한석봉의 일화 같죠.) <blockquote> 주간 회의 역시 아주 널리 쓰입니다. 이 방법의 문제라면 주간 회의가 진정으로 효율적으로 운영되려면 많은 양의 정보를 공유해야만 한다는 점입니다. 팀 구성원들은 한 주 동안 정말 많은 일을 했을 테니, 의미 있는 정보교환이 일어나기란 불가능합니다. 되려 관리자가 정보나 공지를 공유하는 자리가 되어 버립니다. 좋은 관리자라면 이 자리를 이용해서 그룹이 특정 이슈나 문제를 주목하게 만들 수 있습니다. 하지만 이슈가 있는지도 모른다면, 주목할 수조차 없겠죠. 주간 회의는 분기별 회의보단 낫지만, 일일 회의에는 훨씬 못 미칩니다. p. 103 </blockquote> 좀 더 앞 페이지의 책갈피가 있지만 순서를 좀 바꿔 놓겠습니다. 처음에 우리 프로그램 팀은 주간 회의를 하기로 했습니다. 팀원 간에 교류가 너무 없었기 때문에 서로 뭘 하는지도 몰랐고, 좀 더 정보를 공유하자는 의미에서, 할 얘기가 없더라도 반드시 정해진 날짜에 모이기로 한거죠. 하지만 할 얘기가 정말 없었어요. 간혹 누군가 안건을 준비해 오면 회의는 그 사람을 중심으로 진행되었습니다. 그것도 나름대로 부담스러운 일이죠. 회의는 곧 거의 열리지 않게 되었습니다. 매주 일정을 보고하는 회의가 새로 만들어지기 전까지는요. 매주 새로운 회의가 열리게 되면서 이제야 겨우 매주 한 번 한 자리에 모이게 되었습니다. 일정 회의였기 때문에 이번 한 주 동안 한 일은 어떤 것들이 있고, 다음 주에 할 일은 어떤 거라는 내용으로 돌아가면서 발언을 했습니다. 우리는 한 주 동안 정말 많은 일을 했죠! 틀림없이 어느 누구도 <a href="http://xper.org/wiki/xp/AreWeATeam" title="3분" class="external">3분</a> 내에 다 말할 수는 없었을 겁니다. 얼마나 서로의 발표를 열심히 들었는지도 알 수 없는 일입니다. 제 생각에는 회의에서보다 커밋 로그로 서로의 작업에 대해 더 많은 것을 얻을 수 있었던 것 같아요. (그러려면 로그를 더 잘 써야 합니다.) 그래도 다행인 건 모이는 것이 안 모이는 것보다는 나았다는 겁니다. <blockquote> 일일 회의를 하면 한 사람만 주목의 대상으로 만들지 않고, 모든 사람이 이야기를 하게 만들 수 있습니다. 매일같이 함께 이야기하고 정보를 공유하면 팀을 결속시키는 데 놀라울 정도로 도움이 됩니다. 각 팀 구성원마다 모든 사람과 하루에 적어도 한번씩은 대화를 나누는 팀이 얼마나 됩니까? 일일 회의는 단절된 개발자 집단을 진정한 팀으로 변모시킵니다. p. 101 </blockquote> 최근에 스크럼을 도입하면서, 우리는 몇 개의 작은 팀으로 쪼개졌습니다. 우리 프로젝트는 게임 완성을 골로 본다면 중반쯤 왔겠고, 게임 공개를 골로 본다면 후반에 이른 상황입니다. 당면한 상황이 있기 때문에, 바람직하진 않지만, 너무 작은 스크럼 단위로 쪼개진 경향이 있습니다. 그리고 이제 매일 만납니다. 개인적으로 큰 변화를 느낍니다. 서로의 업무를 공유하는 것도 좋지만 특히나 책임의 공유가 크게 느껴집니다. <blockquote> 그룹 내에 너무 많은 사람이 있다면, 이것도 잠재적인 문제가 됩니다. 우리는 일일 회의가 15명 정도의 인원까지만 감당할 수 있다는 사실을 알게 됐습니다. 이런 시나리오에선, 좀더 작은 그룹으로 나눠서 일일 회의를 하는 방법을 찾아보세요. 같은 영역에서 일하는 팀 구성원들끼리 회의를 하면 됩니다. 적어도 한두 명은 겹치게 해서 관련 정보가 함께 넘나들게 만드세요. p. 107 </blockquote> 위에서도 말했지만 우리 팀은 너무 잘게 나눠졌습니다. 이 때도 단점이 있는 것 같아요. 스크럼간의 의사소통이 잘 이루어지지 않는다는 거죠. 불가피한 이유로 본의 아니게 여러 스크럼에 소속되어 있는 사람이 있는데, 우연히도 이 책에서 권장하는 것과 맞아 떨어집니다. 이들이 정보를 공유하는 중심이 됩니다. 부서 전체 인원은 일일 회의를 하기에 어려움이 많지만, 프로그램 팀만은 전에도 가능했을텐데 필요성을 느끼지 못했습니다. 일일 회의를 당장 시작하라는 얘기는 많은 곳에서 들었지만 그렇게 하지 못했어요. 그래서 뭐가 달라질까 하는 의심이 먼저 들었죠. 마찬가지로, 아는 것보다 이해가 중요하다는 하나의 사례라고 볼 수 있겠습니다. <a href="http://www.talk-with-hani.com/archives/603" class="external" title="애자일 프랙티스">애자일 프랙티스</a>를 번역하신 하니님이 바로 얼마전에 비슷한 글을 적어 주셨습니다. <a href="http://www.talk-with-hani.com/archives/660" class="external" title="정규 대면회의 시간을 가져라">정규 대면회의 시간을 가져라</a>라는 글입니다. 좋은 실천 사례는 많은 분들이 추천하기 마련입니다. 하지만 안 합니다. 어떨 때는 알면서도 안 해요. 도대체 왜 그럴까요? 모르겠습니다… 저는 용기가 없어서라고 생각하는데, 그럼 용기는 왜 없을까요? (꼬리에 꼬리를 무는 의문.) <blockquote> 회의를 열지 않으면 사람들이 불평할까요? 그래야만 합니다! 팀이 일일 회의에 의존하게 만들어서 최신 정보를 놓치는 법이 없도록 해야 합니다. 회의가 사라져도 된다고 생각한다면, 회의가 아무런 가치도 제공하지 못했기 때문입니다. 팀은 일일 회의를 소중한 자원으로 삼고 의존해야 합니다. p. 108 </blockquote> 회의가 없으면 사람들이 불평할 경지에 오르려면 아직 갈 길이 멉니다. 정말 그런 날이 올지 아직은 감이 안 오네요. <blockquote> 여러분은 곧 이 장의 모든 섹션에 깔린 주제를 깨닫게 될 겁니다. '행동하라'. 현상 유지에 만족하거나 싸움을 포기한 사람들에게는 맞는 글은 아닙니다. 하지만 우리의 제안을 받아들여서 더 나아지고 싶어 못 견디겠다면, 계속 읽으세요. p. 161 </blockquote> 저조차도 잘 안 되는 일이지만, 그냥 아는 것보다 당장 행동하고 보는 게 훨씬 더 나은 앎을 가져다 주는 일이 많습니다. 항상 답답하게 생각하던 것이 있는데, 왜 팀의 개선이 새 팀이 만들어 지고 나서 얼마간만 일어나냐는 것이죠. 또는 새로운 구성원이 들어올 때만요. 작은 프로젝트를 많이 해보고 싶었는데, 작은 프로젝트일 수록 피드백이 빠르고, 많은 이터레이션을 통해서 지속적인 개선이 일어날 수 있으리라고 생각했기 때문입니다. 지금 생각해 보면 행동하지 않았기 때문이 아닌가 싶어요. 긴 프로젝트일 수록 지속적인 개선이 더 필요할 수 있는데 말입니다. 그래도 지금 프로젝트에서는 초반부터 지금까지 느리지만 꾸준히 변화가 일어나고 있습니다. 프로젝트가 끝나고 여유 시간이 좀 생길 때쯤엔 제 오랜 질문에 대한 답을 찾을 수 있길 바랍니다. <blockquote> 코드 통합을 미루면 미룰수록 이런 충돌이 벌어질 가능성도 높아집니다. 이런 미룰수록 코드를 더 많이 수정하게 됩니다. 수정된 코드의 줄 수가 늘어날수록 충돌 횟수도 증가합니다. 충돌 횟수가 커질수록 병합 작업도 보다 골치 아파집니다. 해결책은 간단합니다. 코드를 보다 자주 통합해서 충돌을 줄이고 병합을 단순화시키는 겁니다. p. 172 </blockquote> 애자일 프랙티스를 읽고 제게 든 위기감이 있었습니다. (위에서 말했었죠? 이제 생각났네요.) 내가 하려던 이야기가 이미 여기 다 들어있어서, 이제 특별히 별로 할 말이 없다는 겁니다. 이전에 올린 글도 지난 몇 달간 깨작깨작 퇴고만 하고 있던 글을 용기를 내서 올렸었는데요, 지금에 와서 보면 참 잘한 일이었다는 생각이 듭니다. 제가 한 말이 고스란히 더 나은 문장으로 이 책에 들어있잖아요. 이 책을 먼저 읽었더라면 못 쓸 뻔했죠. <blockquote> 여러분이 가진 레퍼토리에 새로운 실천방법을 추가하기로 결정했다고 합시다. 그런데 새로운 실천방법을 효과적으로 도입하려면 어떻게 해야 할까요? 여러분이 해야 할 일은 크게 두 가지입니다. 시범을 보이고 설득하세요. 이 두가지 목표만 달성해내면 그 즉시 열광적인 팬을 한 무더기 얻게 될 겁니다. p. 189 </blockquote> 새로운 도구나 프로세스를 도입하는 데 제가 추천하는 전략도 이와 같습니다. 시범을 보이고 설득하는 거요. 설득을 먼저 하면 안 통합니다. 나중에 여기에 대해서도 제 경험을 정리해서 올릴게요. '조만간에'라고 적었다가 지금 막 고쳤습니다. 왜 그랬는지 다들 아실거예요. <h3>간단 정리</h3> 지금까지 열심히 읽고 정리를 해보았는데요, 사실 전체 내용에 대해서는 좀 불만입니다. 몇 가지 이유가 있습니다. 이 책의 저자들은 십 몇 년에서 이십여 년간 소프트웨어 업계에서 잔뼈가 굵은 베테랑들입니다. 많은 프로젝트에서 성공과 실패를 경험했을 거고요. 하지만 비슷한 좋은 책을 써준 XP의 대가들이나 실용주의 프로그래머 같은 영웅 프로그래머, 또는 스티븐 맥코넬이나 로버트 L. 글래스 어르신들의 책에 비하면 아직 공력이 많이 낮은 것 같아요. 이게 불공평한 비교라는 건 알지만(경력이 두 배, 세 배 차이가 날뿐 아니라 어쩌면 소프트웨어 경력이 이 책의 저자 나이보다 많기도 할거예요), 요즘들어 워낙 좋은 책을 많이 읽어서 그런지 비교되는 것이 어쩔 수 없었습니다. 저자들도 그들에게 무한한 존경을 표하고 있어서, 신기한 느낌이 들었어요. 저자가 그들보다 우리쪽에 더 가깝구나 하는 친밀감이랄까? 둘째는 유명한 소프트웨어 경구들을 옮겨 온 티가 많이 난다는 겁니다. 예광탄 개발이나, 위에서 소개한 켄트 벡의 사례도 그렇고요. 그리고 절반이 넘어갈 때까지는 차분히 잘 소개를 해줘서 읽기가 좋았는데, 특히 예광탄을 소개하는 부분에서 왠지 저자의 흥분한 목소리를 듣는 것 같은 기분이 들었습니다. 공저이다보니 어느 한 명이 맡아서 적은 부분이 유달리 그런지도 모르겠어요. 후반부로 갈수록 심하더군요. 이 책의 <a href="http://www.aladdin.co.kr/shop/wproduct.aspx?isbn=8995856467" class="external" title="목차">목차</a>가 진부하게 느껴지는 분은 잠깐 더 생각해 보세요. 하지만 비슷한 논지의 책을 많이 읽지 않으셨다면 이 책이라도 꼭 읽으세요. 제가 불평을 좀 늘어놓긴 했지만, 이 두 분 경력을 합치면 여러분 나이만큼 되지 않겠어요? by-nc-sa http://heycalmdown.myid.net/ http://heycalmdown.myid.net/ 244