쓰리(Writely)

쿵야 어드벤처 키맵 for VIM User

hey — Mon, 19 Nov 2007 13:55:00 +0900

이야기가 있는 쿵야 대모험/쿵야 어드벤처 키맵 for VIM으로 옮겼습니다.

쿵야 어드벤처 키맵

hey — Sat, 17 Nov 2007 17:50:48 +0900

이야기가 있는 쿵야 대모험/쿵야 어드벤처 키맵 for HHKB로 옮겼습니다.

결과보다 더 중요한 것

hey — Mon, 29 Oct 2007 10:59:07 +0900

요즘 읽고 있는 책을 제 서재에 빠짐없이 기록하고 있는데요, 이것 저것 마구잡이로 추천받은 책들을 읽다가 묘한 관계를 발견했어요. 어떤 책과 어떤 책은 같은 결과를 다른 시각으로 소개하고 있고, 어떤 책은 어떤 책보다 먼저 읽어야 한다는 그런 느낌 말이죠. 얼마 전에 읽었던 '마음은 어떻게 작동하는가' -> '마인드해킹'이 그렇고요, '셈코 스토리' -> '더 골' -> '린 소프트웨어 개발'이 그랬습니다. 지금은 팀장님이 소개해준 '숨겨진 힘 - 사람'을 읽고 있는데, 여기에는 '린 소프트웨어 개발'에 소개된 NUMMI라는 회사가 등장합니다. 다 읽고 나면 책들의 순서를 다시 재배치해 볼 생각이에요.

'셈코 스토리', '더 골', '숨겨진 힘 - 사람'에 등장하는 회사들은 다른 일반적인 회사와 다른 방식으로 일하고, 모두가 행복하게 일하는데도 그 어떤 회사보다 생산적으로 일하는, 제가 꿈꾸는 이상적인 조직들입니다. 그런데 문제가 있어요. 그것은 결국 결과일 뿐이라는 겁니다. 내가 어떤 회사의 사장이라면, 하고 머리 속에서 시뮬레이션을 해봤습니다. 내 회사가 대기업이라면, 잘 하면 좋은 결과를 볼 수도 있을 거라고 생각해요. 하지만 그렇게 안 할 겁니다. 잃을 게 많거든요. 지금까지 해보지 않았던 무언가를 새로 시도하는 데는 모르긴 몰라도 어마어마한 용기가 요구될 거에요. 제 회사가 작은 기업이라면 어떨까요? 제 시뮬레이션에서는 그럴 체력이 부족했어요. 이상이 눈 앞에서 현존하고 있는데 왜 결과는 이렇게 실망스러울까요? 이유가 뭘까요? 제 생각은 아마 저 위에서 소개된 이상적인 회사들도 처음엔 그렇게 안 했을 거라는 겁니다.

'셈코 스토리'를 다 읽고 생각한 게 있습니다. '셈코는 분명히 좋은 회사다. 하지만 많은 회사가 셈코를 배워갔다고 하는데, 왜 어떤 회사도 셈코가 될 수 없었을까?' 제 대답은 이렇습니다. 그들이 셈코를 다시 만들어도 지금과 같을 수는 없을 거예요. 셈코도 셈코가 될 수 없는데 하물며 대체 어떤 회사가 셈코가 될 수 있을까요? 그들이 이룩한 결과 - 현재에서 배울 것이 아니라 그들이 다른 누구가 아니라 바로 그들이 되었던 과정 - 과거를 배워야 합니다. 셈코는 단 한 순간에 이루어지지 않았습니다. 어릴 때는 어릴 때의 성장 방법이, 자라서는 자라서의 성장 방법이 있는 법이지요. 시작부터 끝까지 일직선을 그어서 그 성장 경로를 따라가기만 하면 되겠어요?

예전에 사용자 스토리라는 글에서 그렸던 그림이 생각나네요. 지난 주 애자일 코리아 모임에서 이야기를 들으면서 생각했던 게 바로 이겁니다. 지금 애자일 방법론들을 잘 적용하고 있는 회사나 팀들은 과거에 여러 가지 문제들을 어떻게든 해결했기 때문에 지금의 모습이 있는 것일 겁니다. 기억해서 말해줄 수 있는 것 외에, 그런 문제가 정말 있었는지조차 모르는 문제도 해결했을 거고, 어떻게 해결했는지 모르는 문제도 있을 겁니다. 우리가 놓치고 있는 건 바로 그것들입니다. 그게 바로 우리가 셈코가 될 수 없는 이유죠.

이 글은 스프링노트에서 작성되었습니다.

단위 테스트로 스펙을 정의해요

hey — Mon, 1 Oct 2007 01:01:36 +0900

다들 동의하시겠지만, 테스트를 만들 때 제일 힘든 건 역시 이름 짓기입니다. 테스트에는 목적을 잘 드러내는 이름을 붙여 주어야 합니다. 그래서 안 되는 영어로 열심히 작명을 하다 보면 메서드 이름이 너무 길어져서, 원래는 설명을 하려던 것이 도리어 알아볼 수 없는 이름이 되고 말죠. 나중에 결과를 봐도 파일 이름과 줄 번호로 찾아가서야 겨우 알게 되고요. 이럴 때 어떻게 하시나요? 저는 이름을 열심히 짓고, 나중에 못 알아볼까봐서 주석도 열심히 달고 그랬습니다. (저는 CppUnit을 사용합니다.)

루비라는 언어를 보면 일종의 테스트 프레임워크로써 RSpec이라는 게 있습니다. 기존 단위 테스트 프레임워크와의 차이는 클래스에 테스트 메서드 이름을 짓는 대신 일종의 DSL로써 스펙을 말로 정의한다는 거죠. 국내 RoR 레퍼런스의 대표격인 스프링노트를 만드신 강규영(=강애란)님은 RSpec을 본따서 JSSpec을 만드신 바도 있습니다. 아마 테스트 메서드 이름 짓기에 치인 개발자라면 RSpec 환경이 한없이 매력적으로 보일 겁니다. 저처럼 경험이 많지 않은 사람조차 그런걸 보면요.

아무튼 그래서 없어보이지만, 다음과 같은 짓을 해보았어요.

저는 Visual Studio 2005를 사용하고요, 테스트 프레임워크는 앞에서도 밝혔다시피 CppUnit입니다. 어느 쪽이든 저렴해 보이긴 마찬가지지만, 중요한 것은 메서드 이름을 지으려고 노력하는 대신 사용자 스토리를 만들거나 스펙을 적는다는 감각으로 하는 게 중요합니다.

그냥 볼만 하죠?

이 글은 스프링노트에서 작성되었습니다.

Ship it!

hey — Wed, 19 Sep 2007 11:06:00 +0900

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드 -
자레드 리차드슨 외 지음, 최재훈 옮김/위키북스

서문을 다 읽고 본문을 8페이지까지 읽었다. 이 책을 다 읽고 나서 쓰는 글은 결코 예전과 같을 수 없을 것 같다는 예감이 든다.

위의 메모는 지난 12일 회사에서 서문을 막 다 읽고, 본문을 몇 쪽 읽다가 적은 것입니다. (얼마 전부터 오픈유어북을 다시 사용하고 있어요.) 몇 쪽 읽지도 않았는데 앞으로 제가 하려고 하는 이야기가 이미 다 담겨있을 것 같은 예감이 들어서 그랬었습니다. 이 비슷한 얘기를 얼마 전에도 한 것 같은데, 어디였더라….

저는 주로 지하철로 출퇴근 하는 중에 책을 읽기 때문에, 마음에 드는 구절을 휴대전화에 달린 카메라로 찍어 두었다가 오픈유어북에 옮겨 적었습니다. 책에 줄 긋는 걸 좋아하지 않거든요. 지금부터 제가 뽑아 놓은 책갈피들을 제 경험담과 함께 소개 해볼까 합니다.

책갈피

팀 환경이란 대부분 팀 구성원이 무엇을 요청했는가, 무엇을 체험했는가에 따라 달라집니다. 어떤 도구나 기법, 그리고 프로세스가 회사에 긍정적인 영향을 미칠 수 있는지 알아뒀다가, 제안할 일이 있을 때마다 명확한 이유를 제시할 수 있어야 합니다.

p. 10

여러분은 어떤 환경에서 일했는지요? 여러분이 무엇을 요청하거나 체험담을 이야기할 수 있는 위치에 있기 전에는 누가 그것을 결정했나요? 팀 환경에 개선이 있었다면 누구에 의해서였나요?

누군가가 업무처리 기법을 먼저 사용해보고 쓸만하다 싶어서 팀과 공유하는 일은 흔합니다. 우리는 이런 일을 반복해왔고, 다른 이가 그렇게 하는 걸 지켜봤습니다.

p. 12

변화는 대개 외부에서 옵니다. 팀에서 리베로 역할을 하는 기술 전도사(Technical Evangelist)가 있다면 좋겠지만, 그렇지 않다면 새로운 사람과 함께 새로운 문물이 들어오기 마련입니다. 우리는 변화를 두려워 합니다. 하지만 팀에 새로운 사람이 들어와서 벌이는 이런 저런 일은 묵인하는 경우가 많습니다. 신기한 일이죠? 사실은 변화 자체가 두려운 것이 아니라 변화를 시작하는 일에 용기 내기를 어려워 하기 때문인 것 같습니다. 지금 하려는 일이 옳은 일이고, 또 그가 그 일을 기꺼이 맡아 주겠다면야 우리에게는 그런 제의를 얼마든지 받아들일 수 있는 아량이 있습니다. 게다가 누구든지 처음엔 의욕에 넘치기 마련이니 일이 시작될 수 있는 거죠. 제 경험을 떠올려 봐도 입사 초기에 새로운 도구나 프로세스를 도입한 경우가 많았습니다. 지난 번에는 CVS였고, 이번 팀에서는 SVN이 대표적입니다. 그 얘기를 조만간에 할 기회가 있을 겁니다.

팀이 받아들이기 쉬운 것은 좋다고 들어 아는 것보다 누군가 실제 체험한 것일 경우가 많습니다. 예전엔 당연하게 생각했던 것이 지금은 없다면, 불편함을 참기 힘들기 때문에 팀원들을 더 열심히 설득할 동기가 됩니다. 또, 그래야만 우리가 뒷걸음질 하지 않고 다만 한 발짝이라도 더 나아갈 수 있는 것이겠지요.

이런 도구들이 출현하기 전에는 우리가 하루 동안 나누는 대화는 대부분 빌드 실패에 대해 사람들에게 질문하거나 API 변경을 통지하는 것이었습니다. CruiseControl.NET이 빌드를 처리해주기 때문에, 개발자들은 빌드를 원래 상태대로 유지하는 게 얼마나 중요한지 이해했고 그렇게 하려고 헌신했습니다.

p. 14

이 구절이 말하는 내용이 중요한 건 아닙니다. CruiseControl.NET을 사용하라는 얘기는 너무 노골적이잖아요. 제가 동감한 것은 '개발자들은 … 이해했고'라는 부분이었습니다. 제 생각에, 아는 것은 그렇게 중요하지 않아요. 하지만 이해하는 것은 중요합니다. 이 아는 것과 이해하는 것의 차이는 극적입니다. 지난 글, '자주 통합하고 커밋 알림을 사용하세요'의 서두에서 말하려고 했던 것도 그것이었는데 잘 전달이 되었는지 모르겠습니다. 제 경험으로 그 차이는 놀라울 정도였어요. 하지만 이건 제 글솜씨로 몇 문장에 걸쳐서 이야기할 수 있는 주제가 아니네요. 지면이 좁아서 마저 다 적을 수가 없습니다….

어쨌거나 훌륭한 기술 리더라면 여러분이 '목록'을 사용한다는 걸 눈치채고, '목록'을 팀 전체를 위한 용도로 사용할 겁니다. 좋은 습관이 얼마나 자주 전파되는지 알게 되면 놀랄 겁니다. 그러기까지 시간이 걸릴진 몰라도, 사람들은 뭐가 좋은지 눈치챕니다.

p. 85

기술 리더는 이 책에서 꾸준히 주장하는 큰 축 중에 하나입니다. 기술 전도사이자 멘토쯤 되는 사람으로써, 프로젝트나 제품을 책임지지는 않지만 팀이 기술적인 면에서 방향을 잃지 않도록 큰 그림을 보는 사람이 필요하다는 것입니다.

꼭 기술 리더가 아니더라도 좋은 습관은 팀 전체로 퍼져 나가는 것을 볼 수 있습니다. 때로는 전혀 그렇지 않은 게 아닌가 생각되는 때도 있지만요. 이것을 촉진하는 가장 좋은 방법이 짝 프로그래밍이나 멘토링이 아닌가 싶습니다.

팀 전체와 좀 더 자주 만나서 모든 사람이 자기가 무슨 일을 하고 있는지 공유하도록 하세요. 진행 방향을 수시로 바로 잡는 게 목표입니다. 여러분이 차를 몰아 길을 따라 내려가고 싶을 때, 한 방향을 정해놓고 그쪽에만 매달리지는 않을 겁니다. 가고 싶은 방향으로 차를 움직여놓고, 바퀴를 왼쪽, 오른쪽으로 틀면서 조금씩 방향을 조정해 갑니다. 방향 조정을 해주지 않고 버티다 보면 결국 도로를 벗어나 차를 망가뜨리게 됩니다. 소프트웨어 프로젝트도 마찬가지라, 조금씩 조정해주지 않으면 부서져버립니다.

p. 95

사실 서문에서 켄트 벡의 이름이 나왔을 때 짐작을 했습니다. 이 저자들은 우리랑 별로 다르지 않게, 소프트웨어 영웅들에 푹 빠져 있는게 아닌가 말이에요. 실용주의 프로그래머인 앤디 헌트, 데이브 토머스, XP의 켄트 벡, 마틴 파울러… 이들이 바로 그들이죠. 물론 어느 누구 하나 부족함이 없고요. 위의 인용은 사실은 켄트 벡의 TDDBE에서 소개된 일화입니다. 그의 어머니가 처음 운전 면허를 딴 그를 운전석에 앉히고서 들려준 말이라고 하죠. (참고로 그의 어머니는 그에게 차의 방향을 길과 똑바르게 놓도록 하고 눈을 감으라고 하셨답니다. 마치 한석봉의 일화 같죠.)

주간 회의 역시 아주 널리 쓰입니다. 이 방법의 문제라면 주간 회의가 진정으로 효율적으로 운영되려면 많은 양의 정보를 공유해야만 한다는 점입니다. 팀 구성원들은 한 주 동안 정말 많은 일을 했을 테니, 의미 있는 정보교환이 일어나기란 불가능합니다. 되려 관리자가 정보나 공지를 공유하는 자리가 되어 버립니다. 좋은 관리자라면 이 자리를 이용해서 그룹이 특정 이슈나 문제를 주목하게 만들 수 있습니다. 하지만 이슈가 있는지도 모른다면, 주목할 수조차 없겠죠. 주간 회의는 분기별 회의보단 낫지만, 일일 회의에는 훨씬 못 미칩니다.

p. 103

좀 더 앞 페이지의 책갈피가 있지만 순서를 좀 바꿔 놓겠습니다. 처음에 우리 프로그램 팀은 주간 회의를 하기로 했습니다. 팀원 간에 교류가 너무 없었기 때문에 서로 뭘 하는지도 몰랐고, 좀 더 정보를 공유하자는 의미에서, 할 얘기가 없더라도 반드시 정해진 날짜에 모이기로 한거죠. 하지만 할 얘기가 정말 없었어요. 간혹 누군가 안건을 준비해 오면 회의는 그 사람을 중심으로 진행되었습니다. 그것도 나름대로 부담스러운 일이죠. 회의는 곧 거의 열리지 않게 되었습니다. 매주 일정을 보고하는 회의가 새로 만들어지기 전까지는요.

매주 새로운 회의가 열리게 되면서 이제야 겨우 매주 한 번 한 자리에 모이게 되었습니다. 일정 회의였기 때문에 이번 한 주 동안 한 일은 어떤 것들이 있고, 다음 주에 할 일은 어떤 거라는 내용으로 돌아가면서 발언을 했습니다. 우리는 한 주 동안 정말 많은 일을 했죠! 틀림없이 어느 누구도 3분 내에 다 말할 수는 없었을 겁니다. 얼마나 서로의 발표를 열심히 들었는지도 알 수 없는 일입니다. 제 생각에는 회의에서보다 커밋 로그로 서로의 작업에 대해 더 많은 것을 얻을 수 있었던 것 같아요. (그러려면 로그를 더 잘 써야 합니다.) 그래도 다행인 건 모이는 것이 안 모이는 것보다는 나았다는 겁니다.

일일 회의를 하면 한 사람만 주목의 대상으로 만들지 않고, 모든 사람이 이야기를 하게 만들 수 있습니다. 매일같이 함께 이야기하고 정보를 공유하면 팀을 결속시키는 데 놀라울 정도로 도움이 됩니다. 각 팀 구성원마다 모든 사람과 하루에 적어도 한번씩은 대화를 나누는 팀이 얼마나 됩니까? 일일 회의는 단절된 개발자 집단을 진정한 팀으로 변모시킵니다.

p. 101

최근에 스크럼을 도입하면서, 우리는 몇 개의 작은 팀으로 쪼개졌습니다. 우리 프로젝트는 게임 완성을 골로 본다면 중반쯤 왔겠고, 게임 공개를 골로 본다면 후반에 이른 상황입니다. 당면한 상황이 있기 때문에, 바람직하진 않지만, 너무 작은 스크럼 단위로 쪼개진 경향이 있습니다. 그리고 이제 매일 만납니다. 개인적으로 큰 변화를 느낍니다. 서로의 업무를 공유하는 것도 좋지만 특히나 책임의 공유가 크게 느껴집니다.

그룹 내에 너무 많은 사람이 있다면, 이것도 잠재적인 문제가 됩니다. 우리는 일일 회의가 15명 정도의 인원까지만 감당할 수 있다는 사실을 알게 됐습니다. 이런 시나리오에선, 좀더 작은 그룹으로 나눠서 일일 회의를 하는 방법을 찾아보세요. 같은 영역에서 일하는 팀 구성원들끼리 회의를 하면 됩니다. 적어도 한두 명은 겹치게 해서 관련 정보가 함께 넘나들게 만드세요.

p. 107

위에서도 말했지만 우리 팀은 너무 잘게 나눠졌습니다. 이 때도 단점이 있는 것 같아요. 스크럼간의 의사소통이 잘 이루어지지 않는다는 거죠. 불가피한 이유로 본의 아니게 여러 스크럼에 소속되어 있는 사람이 있는데, 우연히도 이 책에서 권장하는 것과 맞아 떨어집니다. 이들이 정보를 공유하는 중심이 됩니다. 부서 전체 인원은 일일 회의를 하기에 어려움이 많지만, 프로그램 팀만은 전에도 가능했을텐데 필요성을 느끼지 못했습니다. 일일 회의를 당장 시작하라는 얘기는 많은 곳에서 들었지만 그렇게 하지 못했어요. 그래서 뭐가 달라질까 하는 의심이 먼저 들었죠. 마찬가지로, 아는 것보다 이해가 중요하다는 하나의 사례라고 볼 수 있겠습니다.

애자일 프랙티스를 번역하신 하니님이 바로 얼마전에 비슷한 글을 적어 주셨습니다. 정규 대면회의 시간을 가져라라는 글입니다. 좋은 실천 사례는 많은 분들이 추천하기 마련입니다. 하지만 안 합니다. 어떨 때는 알면서도 안 해요. 도대체 왜 그럴까요? 모르겠습니다… 저는 용기가 없어서라고 생각하는데, 그럼 용기는 왜 없을까요? (꼬리에 꼬리를 무는 의문.)

회의를 열지 않으면 사람들이 불평할까요? 그래야만 합니다! 팀이 일일 회의에 의존하게 만들어서 최신 정보를 놓치는 법이 없도록 해야 합니다. 회의가 사라져도 된다고 생각한다면, 회의가 아무런 가치도 제공하지 못했기 때문입니다. 팀은 일일 회의를 소중한 자원으로 삼고 의존해야 합니다.

p. 108

회의가 없으면 사람들이 불평할 경지에 오르려면 아직 갈 길이 멉니다. 정말 그런 날이 올지 아직은 감이 안 오네요.

여러분은 곧 이 장의 모든 섹션에 깔린 주제를 깨닫게 될 겁니다. '행동하라'. 현상 유지에 만족하거나 싸움을 포기한 사람들에게는 맞는 글은 아닙니다. 하지만 우리의 제안을 받아들여서 더 나아지고 싶어 못 견디겠다면, 계속 읽으세요.

p. 161

저조차도 잘 안 되는 일이지만, 그냥 아는 것보다 당장 행동하고 보는 게 훨씬 더 나은 앎을 가져다 주는 일이 많습니다. 항상 답답하게 생각하던 것이 있는데, 왜 팀의 개선이 새 팀이 만들어 지고 나서 얼마간만 일어나냐는 것이죠. 또는 새로운 구성원이 들어올 때만요. 작은 프로젝트를 많이 해보고 싶었는데, 작은 프로젝트일 수록 피드백이 빠르고, 많은 이터레이션을 통해서 지속적인 개선이 일어날 수 있으리라고 생각했기 때문입니다. 지금 생각해 보면 행동하지 않았기 때문이 아닌가 싶어요. 긴 프로젝트일 수록 지속적인 개선이 더 필요할 수 있는데 말입니다.

그래도 지금 프로젝트에서는 초반부터 지금까지 느리지만 꾸준히 변화가 일어나고 있습니다. 프로젝트가 끝나고 여유 시간이 좀 생길 때쯤엔 제 오랜 질문에 대한 답을 찾을 수 있길 바랍니다.

코드 통합을 미루면 미룰수록 이런 충돌이 벌어질 가능성도 높아집니다. 이런 미룰수록 코드를 더 많이 수정하게 됩니다. 수정된 코드의 줄 수가 늘어날수록 충돌 횟수도 증가합니다. 충돌 횟수가 커질수록 병합 작업도 보다 골치 아파집니다. 해결책은 간단합니다. 코드를 보다 자주 통합해서 충돌을 줄이고 병합을 단순화시키는 겁니다.

p. 172

애자일 프랙티스를 읽고 제게 든 위기감이 있었습니다. (위에서 말했었죠? 이제 생각났네요.) 내가 하려던 이야기가 이미 여기 다 들어있어서, 이제 특별히 별로 할 말이 없다는 겁니다. 이전에 올린 글도 지난 몇 달간 깨작깨작 퇴고만 하고 있던 글을 용기를 내서 올렸었는데요, 지금에 와서 보면 참 잘한 일이었다는 생각이 듭니다. 제가 한 말이 고스란히 더 나은 문장으로 이 책에 들어있잖아요. 이 책을 먼저 읽었더라면 못 쓸 뻔했죠.

여러분이 가진 레퍼토리에 새로운 실천방법을 추가하기로 결정했다고 합시다. 그런데 새로운 실천방법을 효과적으로 도입하려면 어떻게 해야 할까요? 여러분이 해야 할 일은 크게 두 가지입니다. 시범을 보이고 설득하세요. 이 두가지 목표만 달성해내면 그 즉시 열광적인 팬을 한 무더기 얻게 될 겁니다.

p. 189

새로운 도구나 프로세스를 도입하는 데 제가 추천하는 전략도 이와 같습니다. 시범을 보이고 설득하는 거요. 설득을 먼저 하면 안 통합니다. 나중에 여기에 대해서도 제 경험을 정리해서 올릴게요. '조만간에'라고 적었다가 지금 막 고쳤습니다. 왜 그랬는지 다들 아실거예요.

간단 정리

지금까지 열심히 읽고 정리를 해보았는데요, 사실 전체 내용에 대해서는 좀 불만입니다. 몇 가지 이유가 있습니다. 이 책의 저자들은 십 몇 년에서 이십여 년간 소프트웨어 업계에서 잔뼈가 굵은 베테랑들입니다. 많은 프로젝트에서 성공과 실패를 경험했을 거고요. 하지만 비슷한 좋은 책을 써준 XP의 대가들이나 실용주의 프로그래머 같은 영웅 프로그래머, 또는 스티븐 맥코넬이나 로버트 L. 글래스 어르신들의 책에 비하면 아직 공력이 많이 낮은 것 같아요. 이게 불공평한 비교라는 건 알지만(경력이 두 배, 세 배 차이가 날뿐 아니라 어쩌면 소프트웨어 경력이 이 책의 저자 나이보다 많기도 할거예요), 요즘들어 워낙 좋은 책을 많이 읽어서 그런지 비교되는 것이 어쩔 수 없었습니다. 저자들도 그들에게 무한한 존경을 표하고 있어서, 신기한 느낌이 들었어요. 저자가 그들보다 우리쪽에 더 가깝구나 하는 친밀감이랄까?

둘째는 유명한 소프트웨어 경구들을 옮겨 온 티가 많이 난다는 겁니다. 예광탄 개발이나, 위에서 소개한 켄트 벡의 사례도 그렇고요. 그리고 절반이 넘어갈 때까지는 차분히 잘 소개를 해줘서 읽기가 좋았는데, 특히 예광탄을 소개하는 부분에서 왠지 저자의 흥분한 목소리를 듣는 것 같은 기분이 들었습니다. 공저이다보니 어느 한 명이 맡아서 적은 부분이 유달리 그런지도 모르겠어요. 후반부로 갈수록 심하더군요.

이 책의 목차가 진부하게 느껴지는 분은 잠깐 더 생각해 보세요. 하지만 비슷한 논지의 책을 많이 읽지 않으셨다면 이 책이라도 꼭 읽으세요. 제가 불평을 좀 늘어놓긴 했지만, 이 두 분 경력을 합치면 여러분 나이만큼 되지 않겠어요?

이 글은 스프링노트에서 작성되었습니다.

서브버전 커밋 알림

hey — Wed, 22 Aug 2007 01:30:47 +0900

사실 지난 글에서 중요한 내용은 커밋 알림이 아니었기 때문에 간단히 다루고 넘어갔는데요, 여러(두) 분이 많은 관심을 보여주셔서 이렇게 소개하는 자리를 따로 마련해 보렵니다. 사실 구현은 간단합니다. 하지만 그 간단한 걸 만들지 않는 이유도 이해합니다. 저도 그랬거든요.

서브버전은 CVS처럼 몇 가지 후킹 포인트를 제공합니다. 기본적인 기능을 제공하지 않음으로써 후킹을 적극적으로 사용하도록 권장하기도 하지요(^^). 예를 들면 로그 수정같은 기능 말입니다. 후킹이 뭔지에 대해서 설명하고 싶은데, 제 글을 읽는 분 중 저보다 모르는 분은 아마 없으리라 생각해서 관두렵니다. 부끄러워서요.

아무튼 제가 커밋 알림 봇을 만들기 전에 쓰던 후킹 스크립트는 두 개였습니다. 로그 수정을 허용하는 것과 로그 없는 커밋을 거절하도록 하는 스크립트인데, 각각 '리비전 설정 변경 직전'과 '커밋 직전'에 이루어지는 작업입니다. CVS를 사용하던 시절에도 비슷한 스크립트를 넣어 놓곤 했었죠.

아주 예전에 언젠가, msn 봇을 만들려고 파이썬으로 만들어진 라이브러리를 들여다 본 적이 있습니다. 꽤 잘 만들어진 콘솔 메신저를 제공하고 있어서 몇 번 뚝딱거려보고는 말았습니다만은. 그러니까, 저는 그걸 어떻게 만들어야 하는지 이미 알고 있었다는 거지요.

왜 그럴까요? 왜 그걸 안 만들었을까요? 이럴 때 쉽게 할 수 있는 변명은, 바쁘다는 겁니다. 저는 정말 바빴어요. 그리고 또 다른 변명은, 그게 좋은 건 알겠지만, 얼마나 좋은지 몰랐다는 겁니다. 이것도 흔한 변명이죠. 개발 일이 본격화 하고 나면 컨텐츠와 상관없는 것(눈에 보이지 않는 것)에는 손을 대기가 쉽지 않아집니다. 새로운 일을 하는 건 언제나 즐겁지만, 또 언제나 두렵습니다. 우리에게는 관성이라는 게 있기 때문입니다. 하지만 이것 하나는 확실합니다. 곱하기는 언제나 더하기 보다 더 낫다는 거요. 김창준님식으로 하면 복리적인 행동이라고 할 수 있겠죠.

개발 환경에 투자하는 것은 언제나 안 하는 것보다 낫습니다! 하지만, 같은 일을 하더라도 최소한의 노력으로 하는 게 더 이익인 셈이죠. 다른 사람의 동작하는 작업물을 바탕으로 하면 관성과 두려움을 이기기에 더 도움이 되리라 생각합니다. (정신 차려 보면 전혀 다른 코드가 되어 있을지라도요.)

이 소스는 msnlib을 필요로 합니다. 소스를 옮겨 넣으시고, hooks 디렉토리에 들어 있는 'post-commit'을 수정하셔야 합니다.

REPOS="$1"
REV="$2"
/home/svn/project/hooks/commit-notifier.py "$REPOS" "$REV" >> /home/svn/project/hooks/msn.log 2>&1 &

어제도 적었지만 몇 가지 문제는 있습니다. 아마 이 문제를 해결하려면 전혀 다른 방식으로 해야 할거예요. 완성하시면 다시 공개해주실 것을 기대합니다. :]

아직 원인은 찾지 못했는데, 봇이 로그인만 하고 로그를 보내주지 않는 경우가 드물게 있습니다.
봇이 이미 로그인 한 상태에서 소스가 새로 커밋되면 기대하는 동작을 못할 겁니다.

이 글은 스프링노트에서 작성되었습니다.

자주 통합하고 커밋 알림을 사용하세요

hey — Mon, 20 Aug 2007 08:22:34 +0900

로그 달기

예전에 소스세이프와 서브버전의 차이에 대해서 글을 쓴 적이 있습니다. 로그를 읽어야 쓰기도 한다는 얘기였지요. 이것은 도구의 차이라기보다는 문화의 차이입니다. 그리고 도구가 문화의 필요조건이 되기도 합니다.

로그를 쓰는 이유는 두 가지가 있습니다. 하나는 내가 읽기 위해 쓰는 것이고, 나머지 하나는 다른 사람을 위해 쓰는 것입니다. 내가 쓴 로그를 읽는 것은 어떤 경우가 있을까요? 어떤 코드가 왜 들어갔는지 기억이 안 날 때, 특정한 시점의 작업 내역을 되돌릴 필요가 있을 때, 특정한 시점으로 돌아갈 필요가 있을 때 등이 있겠지요.

그럼 다른 사람을 위해 쓰는 경우는 어떨까요? 다른 사람을 위해 쓴다는 것은 반대로 말하면 다른 사람이 쓴 로그를 내가 읽는다는 것입니다. 일반적으로 협업의 경우겠습니다. 개발자들이 멀리 떨어져 있는 일이 많은 오픈소스 개발에서는 로그 없이는 기본적으로 일이 안 됩니다. 누군가 로그를 달지 않으면 내가 힘드니까 나부터 달게 되는 거지요. 하지만 현업에서는 오히려 로그를 달지 않는 일이 비일비재합니다. 그냥 말로 하면 되기 때문이죠. 정책적으로 다중 체크아웃을 꺼놓고 소스세이프를 사용하면 개발자간의 지속적인 대화 없이는 업무가 불가능합니다. 누군가 파일을 잠궈버리면 아무도 일을 못하니까요. 내가 작업하려는 파일이 잠겨 있으면 잠근 사람에게 요청합니다. 얼른 풀어달라고요. 그 사람이 그저 올리는 것만 잊은 상태라면 즉시 올려줄 겁니다. 그러나 그 파일을 고치는 중이었으면 다급해집니다. 잠시만요, 금방 올릴게요! 급하게 작업을 마무리하고 잠금을 풀어줍니다. 뭐가 빠졌죠? 로그를 달지 않았네요! 그치만 적으면 뭐해요? 아무도 읽질 않는데. 그냥 물어보면 돼죠. 로그를 보는 것이 불편하기 때문에 적을 생각도 들지 않습니다.

버전 컨트롤 시스템을 서브버전으로 바꾼다면 사정이 좀 나아질까요? 별로 그런 것 같지도 않습니다. 어쨌든 로그를 읽을 일이 없잖아요.

자주 통합하기

저는 자주 통합하는 것을 지향하는 파(^^)지만, 현업에서도 통합의 시점에 대한 스펙트럼은 굉장히 넓습니다. 제가 생각하는 자주는 일일 평균 3~5회입니다. 일정 시간마다 하는 것은 아니고 작은 단위로 나눈 일이 끝날 때마다 통합하는 것을 기준으로 하고 있습니다. 적어도 작동하는 상태에서 통합해야하는 것은 당연하지요. 개발자가 여럿이다보면 업무 진도에는 편차가 있기 마련이고, 따라서 평균 1~6회 정도면 적당하다고 봅니다.

반면에 기능이 완성되지 않으면 열흘이고 보름이고 통합을 하지 않는 개발자도 있습니다. 여기에는 어떤 문제가 있을까요? 통합이 늦으면 늦을 수록 통합 비용과 리스크가 상승합니다. 서로 연결되어야 할 모듈을 각기 다른 철학으로 만들거나, 기획을 제대로 이해하지 못해 기능을 잘못 구현하는 등의 문제는 언제든지 발생할 수 있습니다. 문제를 늦게 발견하니 위험이 커지는 것은 당연합니다. 그럼 왜 자주 통합하지 않나요? 저는 이 역시 문화적인 문제라고 봅니다. 아직도 버전 컨트롤 시스템을 쓰지 않고 WinMerge나 WinDiff를 사용하는 팀도 있을 겁니다. (물론 좋은 툴이지요.) 게다가 코드는 FTP나 공유 폴더로 공유하고요. (물론 편하죠.) 이런 환경에서는 잦은 통합 작업이 힘듭니다. 저는 2002년까지도 그런 팀에서 일했습니다. 통합을 늦게 하는 개발자는 아마 최근까지 그런 환경에서 일했을 겁니다. 도구는 쉽게 바꿀 수 있어도 문화의 영향은 쉽게 벗어나기 힘든 법이죠.

자, 만일 여러분이 혼자 일하고 있다고 생각해 보세요. 소스 코드의 주인은 누구인가요? 그리고 그 코드를 빌드하는 주체는 누구인가요? 누구의 코드가 올바른 코드일까요? 사용자의 경험을 제공하는 코드는 결국 누구의 코드일까요? 답을 말씀 드리겠습니다. 답은 물론 여러분과 여러분의 코드죠. 여러분의 하드 디스크 안에 들어 있는 바로 그 코드가 빌드 되어 완성된 모습으로 사용자에게 제공됩니다.

그러면 이번엔 여러분이 혼자 일하긴 하지만 이력 관리를 위해 소스 컨트롤을 사용한다고 생각해보세요. 뭔가 달라지나요? 여럿이 함께 작업한다면 어떤가요? 앞의 질문을 여러분의 팀에 던져보세요. 누구의 코드가 올바른 코드인가요? 여전히 여러분의 코드일까요?

아닙니다. 사용자에게 제공되는 코드는 여러분의 코드가 아니라, 바로 저장소에 있는 코드입니다. 여러분은 그걸 잠시 빌려와서 쓰는 것뿐입니다. 작업하고 있는 동안의 코드는 불안정한 상태입니다. 가능하면 빨리 안정적인 상태로 되돌려 놓아야 합니다. 절대 여러분의 코드가 사용자에게 제공된다고 생각해서는 안 됩니다. 여러분의 컴퓨터에서 프로그램이 잘 빌드 되고 똑바로 실행된다고 해서 최종적인 버전도 반드시 그렇다고 볼 수는 없습니다. 그래서 커밋을 자주 하고 저장소의 코드를 깨뜨리지 않으려고 노력해야 합니다. 저장소 앞에 앉아서 사람들이 소스 코드를 가져가고 돌려놓는 것을 지켜본다고 생각해 보세요. 어떤 부류의 개발자와 일할 때 안심이 되겠어요?

이제 위에서 던져 놓은 질문에 대답하겠습니다. 저장소에 있는 소스 코드가 올바른 코드입니다. 여러분은 저장소의 코드로 결과물을 빌드해야 합니다. 물론 빌드 하는건 더 이상 여러분이 아닐 수도 있죠.

커밋을 자주 하면 문화의 변화가 생깁니다. 커밋을 하기 위해서는 먼저 업데이트를 할 수 밖에 없습니다. (소스세이프에서는 Get Lastest Version이라고 부르는 그것.) 그렇기 때문에 항상 작은 통합을 하게 됩니다. 통합을 하다가 종종 충돌이 나고 빌드가 깨지는 문제가 발생해서 업데이트 하기를 꺼리는 사람도 있습니다. 하지만 반대로 생각을 해 보세요. 그 충돌은 언젠가 나도 날겁니다. 문제가 작을 때 해결하는 게 낫지요. 큰 문제를 잘게 쪼개서 작은 문제가 여러 번 난다면 무슨 이득이 있냐구요? 글쎄요, 이미 작은 문제가 일어났는데 큰 문제가 일어날 때까지 기다릴 수 있을까요?

XP에서는 오히려 커밋을 더 자주하기를 권고합니다. 어떤 문서에서는 15분마다 소스를 동기화(업데이트하고 커밋하는 일련의 작업을 동기화라고 부를 수도 있습니다)하라고 합니다. 이렇게 하는 것에는 부수적인 효과가 있습니다. 개발자마다 각자 작업을 해서 그 결과물을 때때로 저장소에 올려놓는 것이 아니라, 우리가 하나의 소스를 다루고 있다는 생각이 들게 합니다. 일을 하면서 빌드 에러 메시지를 한 번도 보지 않을 수는 없습니다. 마찬가지로 작은 충돌 또한 겨우 그 정도로 여기게 됩니다. 어떤 놈이 잘못된 코드를 확인도 안 하고 저장소에 넣어서 나를 열받게 만드는 게 아니고요.

팀이 소스 저장소에 대해 어떤 어휘를 사용하나요? 주의를 기울여 잘 살펴보세요. 공유폴더 메타포를 사용한다면 이미 위험한 상황입니다. 공유폴더 메타포는 내 하드 디스크에 있는 코드가 진짜고 다른 사람에게 주기 위해 저장소에 올린다는 문화가 만연해 있다는 것을 의미하기 때문입니다.

언제 올려줄거예요?

공유 폴더를 사용하든 버전 컨트롤 시스템을 사용하든 개발자 간에 코드를 공유하는 이상 내가 원하는 코드가 언제 올라오는가를 아는 것이 중요합니다. 예를 들어보죠. 저는 필요한 코드가 올라올 때까지 다른 일을 시작해보려고 합니다. 항상 그럴 수 있는 것은 아니지만 못할 것도 없지요. 마냥 놀면서 기다릴 수는 없잖아요. 그런데 언제까지 그 일을 하고 있으면 될까요? 코드가 올라왔을 때 내가 그 코드를 받을 준비가 되어 있지 않으면 어떻게 할까요? 또, 코드를 올려놓고 알려주지 않거나, 알려주려고 할 때 마침 내가 자리에 없어서 전달되지 않는다면 어떻게 될까요? 어떤 사람이 깨지는 코드를 올렸는데, 그가 퇴근하고 난 뒤에나 그 사실을 알게 된다면요? 하지만 그걸 어쩌겠어요? 이러한 단절은 두 명 이상의 개발자가 작업을 하기 때문에 필연적으로 생기는 걸요. 단지 프로그래머이기 때문이 아니라 혼자서 할 수 없는 모든 분야의 모든 일에서 단절의 문제는 언제나 생깁니다. 역사적으로 한 사람이 모든 일을 다 할 수 없게 된 다음부터 이 모든 문제가 존재하고 있었습니다.

제가 있는 팀은 15분마다 소스 코드를 동기화 하고 있지는 못하지만, 서로의 코드를 그럭저럭 잘 반영하는 편입니다. 서브버전에 소스가 커밋되면 그 내용이 MSN으로 전달됩니다. 그러면 작업자는 내용을 확인하고 필요한 것이면 업데이트를 합니다. 눈에 띄거나 의심스러운 내용이 들어오면 로그를 열어서 변경 내역을 바로 확인하기도 하지요.

서로의 코드가 반영이 잘 안 되는 경우도 있습니다. 릴리즈 막판까지 커밋을 미루었다가 한꺼번에 하는 경우가 그렇습니다. 일을 하면서 그럴 일이 전혀 없을 수는 없습니다. 이 경우에도 업데이트를 자주 한다면 문제를 줄일 수 있습니다. 자주 업데이트 해서 내가 작업하고 있는 내용의 전제가 바뀌지 않았다는 것을 확인해야 합니다. 아무리 일이 다 끝나고 올리고 싶다지만 내가 가정하고 있는 내용이 모두 다 바뀐다면 어떻게 하겠어요? 그걸 커밋할 때 비로소 알았다면 어떻겠어요? 어떻긴요, 저는 일주일간의 작업분을 날린 거지요.

이 스샷은 파이썬으로 만들어진 msnlib의 msnbot을 조금 수정해서 만든 알리미인데, 만드는 데 들인 공에 비하면 팀에 긍정적인 관점의 변화를 가져오고 있습니다. (치명적인 버그가 있긴 합니다.)

이 글은 스프링노트에서 작성되었습니다.

왜 사용자 스토리?

hey — Mon, 12 Feb 2007 00:26:43 +0900

여러분들도 이런 경험을 했는지 모르겠습니다. 저는 그런 일이 꽤 많았거든요. 뭐냐고요?

자, 기획서가 잔뜩 나왔다고 칩시다. PM은 여러분에게 기획서 더미를 가져다 주며 일정을 산출해 달라고 합니다. 아직 기획이 완벽하지 않은 상황이니 일정은 대략적이기만 해도 된다고 하네요. 어떨 때는 기획서 대신 시스템 목록만 주는 경우도 있죠. 이제 여러분은 몇 개로 나뉜 시스템 제목을 기준으로 일정을 잡기 시작합니다.

A 시스템: 3주
B 시스템: 2주
C...

하다보니 시스템이 너무 크고 뭉뚱그려 있어서 감이 잘 오지 않습니다. 기획서를 대충 훑어 보면서 시간을 어림셈한 다음 나온 숫자에 안전하게 두 배를 하고 거기에 여분을 더합니다. 에드 요돈의 죽음의 행진(Death March)에 따르면 이런 일정 산출법은 피라미드 시대부터 있었다고 합니다. 나름 역사적 전통이 있는 셈법이지요.

다 마쳤나요? '대략적으로' 산출된 일정을 가져다 줍시다. 이것이 그대로 반영된다면 좋겠지만 현실은 그리 녹록치 않습니다. 현실 세계의 프로젝트는 대부분 '문제 프로젝트'이며 안전한 일정은 잘 받아들여지지 않는 경향이 있습니다. [죽음의 행진]은, 어떤 부류의 PM들은 프로그래머가 가져온 일정을 반 토막 내길 즐긴다고 말하고 있습니다. (개발자이던 시절의 일정 산출법을 떠올리기라도 하나보죠.) 저도 그런 경험을 해보지 않은 것은 아닙니다. 일정이 반토막 날 때 어떤 기분이 들까요? 제 경우를 돌이켜 보면, 억울하긴 했지만 일이 앞으로 어떻게 될 것인지 잘 알 수 없었습니다. 그거라도, 어떻게, 내가 잘 하면 될 거라고 생각했어요. 제가 왜 그렇게 생각했을까요? 미쳤나봐요...

구현의 시간. 시스템의 기능을 하나씩 구현해 나갑니다. 수시로 기획자와 상의를 하고, 기획을 보강 - 수정하고, 구현하기를 반복하다 보니 아무리 계산기를 두드려도 도저히 일정 내에 완료가 불가능하게 생겼습니다. 어떻게 해야 할까요? 업무 간의 우선순위는 정해져 있지만 모든 시스템이 이번 릴리스에 들어가야 하는 필수 항목이라고 합니다. 그래서야 그런 우선순위가 도대체 무엇에 쓸모가 있겠습니까? 결국은 작업하던 시스템의 핵심적인 부분만 구현하고 다음 작업으로 넘어갑니다. 기분이 영 찝찝합니다. 내가 뭘 하고 뭘 안 했는지 누가 알고 있을까요? 애초에 각 시스템이 핵심 기능과 부가 기능으로 나뉘어 있다면 어땠을까 생각해봤습니다만 대안 프로세스가 잘 작동하리라는 확신이 없었습니다. 용기도 없었구요. A 시스템의 핵심 기능이 B 시스템의 부가 기능에 의존성이 있다면 어떻게 합니까? B 시스템의 핵심 기능보다 부가 기능의 우선순위가 더 높아야 할까요? 그런 우선순위는 또 무엇에 쓸모가 있겠어요?

사용자 스토리는 바로 그런 일을 합니다. 시스템을 몇 개의 스토리로 잘 쪼개면 우선순위가 높은 시스템의, 우선순위가 낮은 스토리를 추출해낼 수 있습니다. 그래서 스토리를 사용하면 보다 실질적인 우선순위를 얻을 수 있습니다.

..라고 저는 주장합니다.

사용자 스토리는 어떻게 쓸까요?

저난이도: 인덱스 카드 사기

사용자 스토리를 시도하는데 있어 가장 쉬운 관문은 인덱스 카드를 사는 겁니다. 지금이라도 문구점에 가서 500원짜리 묶음을 사세요. 정말 쉽습니다. 저도 마음을 먹자마자, 문구점에 들른 김에 재미삼아 사봤습니다. 연하장을 좀 사러 가려던 길이었지요. 그러니까, 작년 초에요. 그리고 서랍 속에 넣어두세요. 마음이 든든해질겁니다.

중간난이도: 인덱스 카드 쓰기

이건 좀 어렵습니다. 인덱스 카드를 산 다음에 저는 이런 생각을 했습니다. '사용자 스토리를 좀 더 알게 되면 쓰자.' 하지만 잘 생각해 보세요. 겨우 500원 짜리라구요. 게다가 한 팩에 수십 장이나 들어있어요. 그저 낙서라도 하지 못할 이유가 어디 있어요? 잘 알게 되면 정말 썼을지도 모르지만 알려는 시도조차 안 하게 되더군요. 결국 테이프를 뜯는 데에 반 년이 넘게 걸렸습니다. 정말 용기가 없었던 거죠. 여러분은 그러지 마세요.

일단 시작하고 나니 일은 술술 풀렸습니다. 맨 처음 적었던 것은 에픽이었습니다. 그냥 카드 하나당 시스템 이름 하나씩만 적었지요. 사용자 스토리에 대해 잘 알 필요도 없고, 평소에 하던 것과 그리 다르지도 않습니다.

에픽은 엄밀히 말해 사용자 스토리가 아닙니다. 에픽은 사용자 스토리가 갖는 기본적인 특징과 장점을 갖지 않습니다. 그러나 그것은 처음 사용자 스토리를 적을 수 있는 용기를 갖게 해 줍니다. 에픽에는 커다란 시스템 이름을 적으면 됩니다. 에픽은 우선순위도 크기도 없습니다. 아직 자세한 사용자 스토리를 적을 수 없고 커다란 덩어리만 알고 있는 경우에 에픽을 적어 붙이면 됩니다. 그래서 스토리(이야기)가 아닌 에픽(서사시)입니다. 사용자 스토리는 대개 어떤 에픽에 속하는 경향을 보입니다. 하지만 에픽을 체계적으로 관리할 생각은 말고 세부 기능 목록을 사용자 스토리로 적을 수 있을 때가 오면 떼어버리는 것이 좋겠습니다.

고난이도: 사용자 스토리 만들기

인덱스 카드에 사용자 스토리를 적는 것은 쉽습니다. 그저 몇 줄 적으면 되죠. 어려운 것은 '잘 쓰는 것'입니다. 애초에 왜 사용자 스토리가 필요했는지 생각해보세요. 각자 자신의 이유가 있을 것입니다. 저는 위에서 적었던 대로 우선순위 결정을 위해 뭔가 인식의 전환이 필요했고, 그것이 의미있기 위해서는 '잘' 써야만 했습니다. 어떻게 하면 잘 쓸 수 있을까요?

우리는 사용자 스토리를 알기 전에도 작업에 들어가기 전에 명세 비슷한 무언가를 작성해 왔습니다. 문제는 그 둘의 차이가 무엇인가 하는 것입니다. 사용자 스토리의 기본적인 성격을 생각해봅시다.

사용자 스토리는 사용자의 경험을 설명해야 합니다. 제 경험상 단어의 나열이나 단언보다는 ~할 수 있다, ~한다 등으로 끝나는 일반적인 문장 한 두 줄로 만드는 것이 적합했습니다.

단어의 나열이나 단언) 금액 입력 시 소지 금액 검사
일반적인 문장) 입력한 액수가 소지 금액을 초과하는 순간 소지 금액으로 변한다

사용자 스토리는 고객이 읽고 우선순위를 정할 수 있어야 합니다. 개발자의 시각에서 작성한 스토리는 고객이 알아볼 수가 없습니다. 개발자에게만 의미 있는 스토리도 적어서는 안 됩니다.

개발자 우선: Log.xml 파일 로더를 작성한다. 백엔드는 기존에 사용하던 xml 라이브러리를 활용한다.
사용자 경험: Log.xml 파일을 읽어서 화면에 보여준다.

사용자 스토리는 고객이 정한 우선순위에 따라 개발 순서가 달라져야 합니다. 따라서 각각의 스토리가 다른 스토리에 덜 의존할수록 좋습니다. 의존성이 아예 없을 수는 없지만 개발 상황이나 환경의 변화에 따라서 어느 시점에서든지 릴리스 할 수 있다고 생각해야 합니다. 의존성이 얼기설기 뒤엉켜 있다면 작업을 끊을 수가 없을 것입니다. 제가 위에서 설명한 바가 있습니다. "그런 우선순위가 무슨 의미가 있겠어요?"

위의 이야기가 다음에서 설명하는 '케이크 자르기'에 함축되어 있습니다.

케이크 자르기

마이크 콘은 그의 책 사용자 스토리에서 스토리를 자르는 기준을 케이크 자르는 것에 비유했습니다. 이 메타포로 설명하자면 케이크를 잘못 자르는 방법은 다음과 같습니다.

바깥쪽 둘레의 크림만 잘라 먹는다
초콜릿 장식만 떼어 먹는다
윗단의 크림만 잘라 먹는다
밑단의 스폰지 케이크만 먹는다

(아, 케이크 먹고 싶네) 그럼 이 메타포를 사용자 스토리에 대입하면 어떻게 될까요? 즉 사용자 스토리를 잘못 자르는 방법은 어떤걸까요? 그것은 이렇습니다.

사용자 정보 DB를 만든다
사용자 정보 입력 폼을 만든다
사용자 정보를 저장한다
프로토콜을 정의한다

어디서 많이 본 구조입니다. 우리는 흔히 이런 식으로 업무를 쪼갭니다. 이렇게 사용자 스토리를 나누면 뭐가 나쁠까요? 이런 사용자 스토리를 각각 구현해서는 아무런 기능도 동작하지 않습니다. 고객에게 동작하는 버전을 '언제나' 전달 할 수 없다는 의미입니다. 가장 큰 문제는 이런 상황에서는 우선순위를 정하는 것이 아무런 의미가 없다는 것입니다. 코 앞에 닥쳐온 출시일에 맞춰 우선순위가 낮은 스토리를 잘라내고자 할 때, 어디서 자를 수 있겠습니까?

케이크를 잘 자르는 방법은 케이크의 중심점에서 바깥으로 케이크의 모든 요소가 다 들어있게 자르는 것입니다. 그리고 스토리를 제대로 나누는 방법은 다음처럼 하는 것입니다.

사용자의 기본 정보 3~5개를 입력하고 저장한다
사용자의 선택적인 정보를 저장한다

큰 기능을 기본적인 동작과 부가적인 동작으로 나누는 것은 가장 초보적이고 기본적인 시도입니다. 필요하면 기능별로 조각조각 나누고 우선순위에 상관없이 고를 수 있게 하는 것이 좋습니다. 하나의 스토리는 하나의 조각 케이크라고 생각하세요.

그런데 케이크 메타포는 사실 좀 어렵습니다. 왜냐하면 케이크 조각은 너비, 높이, 깊이의 정보를 가진 삼차원 좌표계이기 때문입니다. 게다가 어떤 사람들은 정말 크림만 잘라먹고 싶어할지도 모릅니다. 특히 케이크 위에 올려진 생과일과 초콜릿은 따로 떼어먹기 좋게 유혹합니다. 따라서 저는 보다 단순한 이차원적인 좌표계를 가진 메타포로 피자를 추천합니다. 토핑만 떼어먹으면 나중에 얼마나 힘들어질까는 잘 아실 거예요.

스토리 크기

모든 일은 소요 시간이 다릅니다. 이 크기를 수치화해서 스토리 구석 어딘가에 적습니다. 이것이 스토리 크기가 됩니다. 수치의 단위가 얼마인가는 아무 상관이 없습니다. 단지 동일한 크기의 스토리는 서로 비슷한 시간이 걸리고 두 배 큰 스토리가 두 배 긴 시간을 소모하기만 하면 됩니다. 마이크 콘은 스토리 크기 1을 이상적인 작업시간 기준으로 하루로 하는 것이 어떤가 제안하고 있습니다. 이상적인 작업시간이란 회의도 없고, 전화도 걸려오지 않고, 보고 문서를 작성할 필요도 없는 말 그대로의 이상적인 환경에서 누구의 방해도 없이 근무시간 내내 일하는 것을 의미합니다.

사용자 스토리를 모르던 시절에 저는 일정 산출과 업무 보고를 위해 개인적으로 유닛이라는 단위를 만들어 사용했는데, 1 유닛은 하루를 3등분하고 각 유닛 사이에 적당한 휴식 시간을 포함해 각각 두시간 반씩을 할당한 업무 단위를 의미했습니다. 나름 퇴근 준비 시간으로 사용하기 위해 퇴근 전 30분이 비어 있었죠. 그 시간에 정말로 퇴근 준비를 한 적은 없었지만 말입니다.

지금은 스토리 크기 1을 일반적인 하루 근무에 해당하도록 작성하고 있습니다. 우리 환경에서 이상적인 근무를 할 수 있는 경우는 거의 없으며, 따라서 스토리 크기를 읽거나 측정할 때 이상적인 근무일을 일반적인 근무일로, 또는 일반적인 근무일을 이상적인 근무일로 변환하는 과정이 필요하기 때문이었습니다. 저는 지난 몇 달간 시계부를 작성하여 제 자신의 업무 패턴을 조사한바 있는데, 실험 결과 하루에 집중해서 일하는 시간은 3 ~ 5시간에 불과했습니다. (야근을 하는 경우는 5 ~ 6시간.) 이 시간은 주위에서 듣거나 직접 겪는 체감 수치와 일치합니다. 그래서 스토리의 크기를 추측할 때 이 정도의 시간을 기준으로 삼기로 했습니다.

일하지 않는 시간에는 무엇을 할까요? 대개 업무 준비, 업무 지원, 회의, 협업, 업무 상 토론, 휴식(집중력이 떨어져서 쉬는 것), 잡담(친목 도모), 딴짓(대개 컴파일 시간에 KLDP를 보다가 끝난지도 모르고 계속 보는 것. 인터넷 쇼핑을 하거나 공과금을 내러 은행에 가거나 주민등록등본을 떼는 것. 집에는 잠만 자러 들어가니 집에서 할 방도가 없지 않습니까?) 등이 있습니다. 혼자 일하지 않는 이상 이 일들을 전혀 하지 않을 수는 없습니다. 그러나 일정 예측이 틀리거나 긴급한 일이 벌어졌을 때 이 시간들을 줄일 수는 있을 것입니다. 회의를 안 할 수는 없어도 미룰 수는 있는 법이죠. TortoiseSVN 같은 건 다음날 설치해줘도 되지 않습니까? 이런 의미에서 스토리 크기 1을 일반적인 하루 근무 시간으로 잡는 것은 나쁘지 않다고 봅니다.

그런데 왜 마이크 콘은 이상적인 작업시간을 단위로 잡았을까요? 그런 문제를 생각하지 못해서였을까요? 그 이유는 다음 단락인 팀 속도에서 알 수 있습니다.

팀 속도

현대의 방법론과 고수들은 더 자주 릴리스하고 더 빨리 실패할 것을 권장합니다. 여기에 위키위키의 아버지인 워드 커닝엄이 말했다는 'Fail ealry and often'이라는 경구가 있습니다. 워드 커닝엄은 XP의 중요한 리더 중 한 사람이기도 합니다. XP를 포함해 최근에 인기를 얻고 있는 기민한 방법론들에서 공통적으로 주장하는 것은 짧은 주기의 릴리스입니다. XP에서는 이런 작은 개발 주기를 이터레이션(iteration)이라고 부릅니다. 개발팀은 한 주나 두 주, 길어도 네 주를 넘지 않는 정해진 크기의 이터레이션 동안 개발을 진행하고 릴리스를 배포합니다. 이는 우리가 흔히 하는 것과는 반대라고 볼 수 있습니다. 꼭 필요한 기능이 들어갈 때까지 릴리스를 기다리는 것이 아니라 릴리스 시점이 먼저 정해지고 그 시간을 스토리로 채웁니다. 이렇게 해보면 왜 케이크 자르기(피자 자르기)가 중요하고 우선순위가 중요한지, 스토리를 작게 만드는 것이 왜 중요한지 알게 됩니다.

한 번의 이터레이션이 끝나면 그 기간 동안 완성된 스토리의 크기를 다 더해봅니다. 그 숫자가 팀의 속도가 됩니다. 다음 이터레이션에는 몇 개의 스토리를 완성할 수 있을까요? 항상 같은 속도를 낼 수는 없지만 팀의 경험이 쌓여갈 수록 예측은 정확해질 것입니다. 예측이 빗나가서 이번 이터레이션에는 팀의 속도가 상당히 떨어질 것이라고 생각해 봅시다. 팀에는 어떤 변화가 생길까요? 릴리스가 미뤄질까요? 그렇지 않습니다. 왜? 우리는 고객이 정한 우선순위에 따라 어떤 스토리를 배제해야 하는지 알고 있기 때문입니다. 팀의 속도가 빨라졌다면요? 그럼 스토리를 하나 더 시작해 보죠.

저도 책을 읽으면서 그랬지만, 이런 의문이 들 수 있습니다. 우리 팀은 일반적인 하루 근무를 기준으로 스토리의 크기를 매깁니다. 반면에 옆 팀은 이상적인 작업시간을 기준으로 스토리의 크기를 매깁니다. 일반적으로 사용자 스토리의 크기는 우리 팀이 더 크고, 같은 기간동안 우리는 더 많은 점수를 땁니다. 그럼 우리 팀은 옆 팀보다 두 배 빠를까요? 그렇지 않습니다. 팀 속도의 비교는 같은 팀에서의 상대적인 비교만 의미가 있습니다. 따라서 팀이 스토리의 크기를 어떤 기준을 사용하든 상관없는 것입니다. 마이크 콘이 이상적인 작업시간을 사용한다고 해서 이상주의자라고 비난할 수는 없는 일이지요!

마치며

이전 글에서도 쓴 바가 있지만 저는 '일이 어떻게 시작되고 결국 정착되는가'에 관심이 많습니다. 성공한 실험은 결과만 남지 과정은 남지 않는 경우가 많거든요.적어도 시스템 도입에서는 결과만 가지고는 배우기가 힘이 듭니다. (그 수많은 부자되기 류나 영어완전정복 류의 책들을 떠올려 보세요. 부자가 된 사람은 그 책의 저자뿐입니다.) 경험상 새로운 시도는 용두사미가 되는 경향이 많음에도 불구하고 아직 검증 되지 않은 이야기를 위험을 무릅쓰고 늘어놓고 있습니다. 양해 바랍니다. 어느 날 결국 실험 실패 글을 올리고 잠적할지도 모릅니다. :]

특히 이번 글은 제 예상보다 더 길어진 데다 재미도 없어서 부득이 이런 단락을 마련했습니다. ^^; 저의 사용자 스토리 실험은 그 뒤로 인상적인 변화가 있어서 새로운 전기를 맞고 있습니다. 아직 공개할 단계는 아닌데, 다음 번에는 긍정적인 실험 결과를 소개할 수 있다면 좋겠군요.

기획에서 기능 명세 얻기

hey — Sat, 13 Jan 2007 11:29:10 +0900

아래에서 제가 설명하고자 하는 내용은 현업에서 폭넓게 다양한 사람들에게 적용해본 결과는 아닙니다. 몇 가지 개인적인 실험의 일환으로 시도해 보았고, 나름대로 성과를 얻었기에 공유하고자 합니다. 글을 쓰다가 흥이 올라서 과장을 하거나 막 나가는 경우가 있었는지도 모릅니다. 양해를 구하겠습니다. 어쩌면 흐름이 일정치 않은 부분도 있을 것이고요. 그건 최근 따로 여유 시간이 없는 관계로 며칠에 걸쳐서 조금씩 적어서 그렇습니다. 본문에서 사용하는 예는 모두 순전히 가상입니다. (오해하실까봐)

용어의 혼란

여러분에게는 이런 경험이 있었을 것입니다.

"캐릭터가 특정 존에 들어왔을 때 캐릭터에게 특정한 효과가 부여되게 하고 싶은데요,"

"잠깐만요, '존'이라는 게 정확히 뭔가요?"

"'존'이 뭐냐고요? 캐릭터가 돌아다니는 게임 공간을 말하는 거죠."

"아, 제가 필드라고 부르는것 말이군요."

"그래요? 필드라고요? 그래픽팀이나 우리도 다 '존'이라고 부르는데 용어를 좀 통일하면 안 될까요?"

"안돼요, 소스코드에 이미 그렇게 썼어요."
"?_?"

이런 일도 있었겠죠?

"사용자가 여기를 지나다가 함정에 빠지면 대미지를 입고요, 여기서는 무조건 죽어요. 그러면 죽음 페널티를 받게 되는데, 레벨 차이가 얼마나 나는 캐릭터가 살려주느냐에 따라 부활 페널티의 효과가 높아지거나 낮아지거나 하는거죠."

"잠깐만요. 아까 전에 말한 '죽음 페널티'는 '부활 페널티'와 다른건가요?"

"뭐가요?"

"아까는 '죽음 페널티', 좀전엔 '부활..'"

"아아, 그건 그냥 그렇게 부른거예요."

"그럼 그 '뭔가' 페널티는 죽을 때 적용되나요 부활할 때 적용되나요?

"?~?"

아마 이 비슷한 예는 셀 수도 없이 많을 겁니다. 어떤 때는 몇 시간동안 서로의 용어를 질문하고 고쳐주느라고 정신이 없기도 하죠. 그렇다고 어디 나와 너의 용어만 다르던가요? 같은 내용을 지칭하는 용어가 내가 말하는 중에도 조금씩 바뀌거나 하죠. 설령 그게 죽음 페널티이든 사망 페널티이든 뭐 그렇게 중요하겠어요? (하지만 부활 페널티는 뉘앙스가 정말 다릅니다.) 그래서 책을 읽거나 다른 선배님들의 경험을 들으면 그렇게들 프로젝트의 용어 사전을 만들어야 한다고 하는가봐요. 그건 어떻게 만들까요? 조금 있다가 알아보죠.

내용의 중복

좀 다른 이야기. 이런 저런 이유로 열심히 문서를 작성하다보면 간혹 문제에 봉착할 때가 있습니다. 내용들이 서로 관련이 있을 때죠. A를 설명하는 중에 B의 일부와 밀접한 관련이 발생했습니다. B-a를 빼놓고는 A-b를 설명할 수가 없어요. 어떻게 해야 할까요? 좀 불친절하게도 B-a를 설명하는 문서를 참조하시라고 적을 수도 있겠죠. 어쨌든 모든 내용은 제 머릿속에 있는데, B-a가 정말은 어느 문서에 있는지 알 수가 없네요. 제일 쉬운 방법은 제가 알고 이해하고 있는 내용을 A-b 근처에 다시 적는 겁니다. 사실 아직 어느 문서에도 없을 수도 있잖아요. 저라면 그렇게 하겠어요. 두 번 쓰는게 뭐 그리 대수인가요?

그런데... 문제는 하나의 사실을 표현하는 말이 역시 하나인 것은 아니라는 겁니다. 왜 비슷한 내용이 여기 저기에 있죠? 고쳐야 할 일이 있을 때는 어떻게 할까요? 그 내용이 대체 어디어디에 있는거에요?

사실 기획은 문서에 있는 것이 아닙니다. 그건 기획자의 머릿속에 있죠. (어쩌면 기획자들의 '사이에' 있는 경우도 있어요.) 그러니까 기획서의 오류도 뭐 그리 대단한 것은 아니에요. 기획자에게 물어보면 언제나 정답을 알 수 있습니다. 그리고 기획서를 갱신해주겠다는 대답도 하죠. 기획서는 소통의 도구일 뿐입니다. 이 사람과 저 사람의 소통을 위한 도구이기도 하고, 한 사람의 과거와 현재를 이어주기도 하고요. 기획서가 아예 없다고 하더라도 기획만 잘 전달이 된다면 괜찮습니다. 어차피 잘 쓰여진 기획서라도 그것만 갖고는 모든걸 이해할 수는 없어요. (작가의 의도는 무엇인가 - 한 두 번 들어보셨어요?) 정말 문제는 내가 기획을 제대로 이해하고 있는가 아닌가입니다.

자, 이제 기획자에게 꼬치꼬치 캐물어 기획에 대한 모든 걸 다 들었다고 칩시다. 그럼 그건 이제 어디에 있나요? 제 머릿속에요? 농담마세요, 저는 들은지 5분이면 까맣게 다 잊는다고요!

명세서를 쓰자

가끔 우리는 한참 설명을 듣다가 이렇게 말하는 때가 있습니다. "제가 다시 설명을 해 볼테니 제대로 이해했는지 들어주세요." 마치 '제가 전화번호를 제대로 들었는지 다시 불러볼게요' 같죠. 이건 꽤 유용한 행동입니다. 다른 사람에게 말로 설명할 때 자신이 제대로 이해하고 있는지 아닌지를 알 수 있게 되는 경험, 여러번 해보셨을 거예요. 기록이 남지 않는다는게 단점이긴 하죠. 글로 적어보는 것은 어떻습니까? 남의 글을 별로 읽을 기회가 없는 기획자에게 거꾸로 문서를 주어보자구요.

글을 쓰는데 제가 추천하는 도구는 위키위키입니다. 몇 가지 장점이 있습니다. 적는 법을 알려드리죠. 대신 전제가 있습니다. 여러분은 기획자와 방금 기획서 리뷰를 끝내고 돌아와 아직 모든걸 다 잊기 전이어야 합니다. 그러니까, 제 경우는 5분이 지나기 전이죠.

새로운 페이지의 이름을 정해야 합니다. 뭐가 좋을까요? 기획서 이름으로 해도 좋고, 일반적으로 통용될 수 있는 이름이라면 다 좋습니다. 기존에 정해둔 이름이 있다면 그걸로 해도 좋습니다. 저는 '캐릭터의 죽음과 부활'이라는 문서를 받았는데, 제가 선택한 페이지 이름은 '플레이어의 죽음'이었습니다. 공교롭게도 지난번에 거기까지만 정의를 해놓고 페이지 만들기를 끝낸 적이 있었거든요. 뭐든 앞으로 '그 내용'을 지칭할 땐 '그 이름'을 써야 한다는 것만 지키면 됩니다. 이유는 곧 알게 되실 겁니다.

다음은, 그 페이지에 기획서의 내용 전체를 털어넣겠다고 덤벼듭니다. 안 들어갈 것 같죠? 맞습니다. 다 넣을 필요도 없고요. 군더더기는 다 뺍니다. 빼야할 것들의 목록은 다음과 같습니다. 그림, 그래프, 순서도, 도표, 표들은 뺍니다. 설명을 위한 설명, 접속사, '~습니다', '~할 것입니다', '다음 기획서 A32067zQ에서 보강합니다...', 뺍니다. 기획 의도, 동기들도 빼야할 주요 요소 중 하나입니다. 그런 것들은 기획자와의 리뷰에서 벌써 해결했어야 합니다. 여기까지 들고 오진 마세요. 이제와서 기획 의도를 의심해서 어쩌겠어요?

진짜 알맹이들은 구조화 해서 모아야 합니다. 단락이나 들여쓰기, 총알 목록 등을 이용해서 관련 있는 것끼리 모읍시다.

문제가 생겼어요!

정리를 하다보니 앞에 나왔던 유사한 내용이 다시 등장했습니다. 어쩌죠?

앞에 나온 내용으로 다시 돌아가서 둘을 비교해 보세요. 완전히 같거나 혹은 완전히 같아야 할 내용인가요? 좋아요, 그러면 잘라냅니다. 새로운 페이지를 만들어서 거기에 넣고 두 군데에 그 이름으로 링크를 겁니다. 왠지 익숙한 행동이네요... ReFactoring에서 ExtractMethod라고 부르는 그것이죠. 위키위키에서는 이런걸 ExtractPage라고 합니다. 이제 앞으로 이 새로운 페이지가 여러 곳에서 불려진다면 좋겠네요. 그래야 잘 분리한 거겠죠? 중요한 건 페이지의 이름이 '바로 그 내용'을 잘 반영하는 좋은 이름이어야 한다는 겁니다. 앞으로 그런 내용을 이야기할 때는 내용을 일일이 말하거나 아무래도 좋은 이름을 사용하는 대신, 정확하게 바로 그 페이지 이름을 사용하세요. 기껏 열심히 생각해서 만들었는데 아깝잖아요.

이제 다 됐나요? 혹시 명세서가 너무 길진 않나요? 위키위키에서 긴 글을 편집할 수도 있지만, 위키위키로 정리한 명세서는 통상 그리 길어지지 않습니다. 저는 15페이지짜리 기획서를 정리하는데 스무줄 정도면 됐어요.

페이지를 뚫어져라 노려봅시다. 비슷한 성격의 기능 명세는 서로 모여있을 것입니다. 유사한 명세의 묶음과 다른 성격의 묶음들이 눈에 들어오나요? 따로 분리할 수 있을 것 같은 기분이 들진 않나요? 이름을 하나 붙여준다면 그 묶음을 따로 떼어 부르기 쉬울 것 같은데요. '어쩌구저쩌구.doc'의 '4.2.1 뭐뭐의 기능과 효과'라고 부르는 대신 말이에요.

저는 '죽었을 때는 이것과 저것과 요것, 조것, A, B, C, D는 할 수 없다. E는 할 수 있다. F는 받을 수만 있다'를 모아놓은 총알 목록이 눈에 띄이길래 ExtractPage를 하고, [사망 상태]라고 이름을 붙여주었습니다. 원래 페이지에는

[사망 상태]가 된다

라고 적었습니다. 그리고 이런 내용들도 있더라고요. 'A가 Aa만큼 감소한다. B가 Ba만큼 감소한다. C는...'. [죽음 페널티]로 묶었습니다. '마을에서 부활하거나, 그 자리에서 부활하거나, 다른 사람이..' 라는 기능 묶음은 [부활]이라고 이름을 붙였습니다. 그랬더니,

[사망 상태]가 된다
[죽음 페널티]가 주어진다
[부활]을 기다린다

죽었을 때 일어나는 일은 사실 몇 가지 되지 않네요. 이제 명세서가 한 화면 이내로 줄었나요? 수고하셨습니다. 이제 명세서의 주소를 기획자에게 주고 검토해 달라고 하세요. 구현은 기획서를 보고 하는게 아니라 명세서를 기준으로 할 거고, 그러므로 기획서와 명세서가 같은지 검토할 필요가 있다고 하세요. 즉, '제가 제대로 이해했는지 적어봤어요, 읽어주세요'와 같습니다.

기획자가 명세서를 읽는 동안, 우리도 지금까지 우리가 무엇을 했는지 검토해 봅시다.

용어를 정립했습니다: 우리는 어떤 기능 목록마다 알맞는 이름을 정해주었습니다. 이제는 [죽음 페널티] 대신 [사망 페널티], [부활 페널티]라고 부를 방법이 없습니다. 그런 페이지는 아예 있지도 않으니까요.
중복되는 내용들을 제거했습니다: 이제 더 이상 여기서 조금 다르고 저기서 조금 다른 내용은 없습니다. 딱 하나뿐이니까요!
기획을 잘 이해했습니다: 어떤 내용을 다른 사람에게 설명하는 것은 자신이 오히려 더 잘 이해할 수 있는 방법입니다. 기획자의 설명을 듣고 기획서를 읽는 동안 괜찮다고 생각했던 내용에 오류가 있었다는 것도 발견했을 겁니다. 기획서의 오류를 고치는 공짜 기능도 있었네요!
비슷한 기능 명세를 서로 모아놓았습니다
꼭 필요한 내용만 남기고 분량이 줄어서 전체 흐름을 더 잘 이해할 수 있게 되었습니다
어떤 기능이 영향을 미치는 다른 시스템과 기능들을 찾아냈습니다: 페이지 제목을 눌러서 역링크를 찾아보세요. [이동 속도]를 고치면 어떤 기능들이 영향을 받나요?

이렇게 정리된 명세서를 가지고 구현에 들어갈 수 있는데요, 사실 다른 것도 할 수 있습니다. 다음 번엔 사용자 스토리를 도출하는 방법을 알아보죠.

사용자 스토리

hey — Wed, 10 Jan 2007 08:07:17 +0900

제가 어떻게 사용자 스토리를 시작할 마음을 먹게 되었을까요? 여러분은 어떻게 시작하게 되었나요?

우리가 어떤 일을 시작하려는 마음을 먹고 나면 먼저 주변에서 이미 그 일을 해낸 사람들을 보게 됩니다. 어떤 일이냐에 따라 다르지만 대개 시작하는 사람들보다는 하고 있는 사람들이 많고 그보다는 해낸 사람들이 많습니다. 이들 사이에는 어떤 차이가 있을까요? 그들이 그 일을 시작하게 된 데에는 어떤 동기와 용기, 그리고 어떤 행위유발성이 있었을까요?

저는 가끔 무언가에 도달한 사람들이 '나도 예전엔 그랬었지'라고 하는 것을 듣습니다. 그리고 그런 말은 별로 의미가 없다고 생각해요. 아직 시작하지 못하고 있는 사람들이 시작하게 되는 사이에는 비선형적인 단계가 있고 거기를 넘어가는 데에는 계기가 필요합니다. 그 사람들에게는 '예전엔 그랬었지, 지금은 요래' 보다 바로 '그 과정'이 중요합니다. 중요한 것은, TDD(또는 금연)를 어떻게 시작할 마음을 먹게 되셨어요? 기존의 습관을 어떻게 고치셨어요? 어느 순간 갑자기 깨닫는 어떤 계기가 있었어요? 이런 질문들이죠.

< 당신에게 무슨 일이 생겼나요? >

우리가 관심있는 것은 빨간 원 안에서 일어났던 일입니다. 제가 늘 관심을 두고 있는 것도 그렇습니다. 다른 블로그에서 Winter Bell 게임을 숙달해 가는 과정에 대해 쓴 글들(1, 2, 3)도 그런 형태의 과정에 대한 관심이라고 볼 수 있습니다.

저는 XP에 꾸준히 관심을 갖고 있었지만, 마음이 맞는 팀을 우연히 통째로 - 그러니까 공짜로.. - 만나기 전에는 실제 업무에 도입할 수 없을 거라 생각했습니다. 그러다가 TDDBE(위키페이지)를 읽고나서 이건 혼자서도 할 수 있는 일이구나 싶었습니다. 몇 가지 다른 언어로 맛을 보고, 실제 업무에도 제한적으로 도입해 보았습니다. (이 얘기는 따로 할 기회가 있을 것입니다.) 그리고 마이크 콘의 사용자 스토리(위키페이지)를 읽었습니다. 'XP의' 사용자 스토리로 접했을 때에 비해 훨씬 많은 이해와 통찰을 얻었고, XP의 각 요소들을 개별적으로도 도입할 수 있겠구나 하는 용기를 얻었습니다. 그래서 다시 한 번 혼자서 사용자 스토리를 사용해보기 시작했습니다. 본격적인 반복을 한지는 몇 주 되지 않았는데, 작지만 의미있는 진전이 보이고 있습니다.

사진을 몇 장 찍어보았습니다. 개인적인 실험이기 때문에 제 자리의 파티션에 붙여두고 있습니다. 아래는 에픽과 스토리를 구분해서 붙여놓은 것입니다. 사진 상단의 많은 쪽이 에픽이고 적은 쪽은 스토리입니다. 에픽이 스토리만큼 중요한 것은 아니지만, 다른 사람들의 주목을 받는데에는 큰 역할을 하고 있습니다. :) 에픽을 잔뜩 붙이기 전과 지금은 관심도가 달라요. 눈에 보이는 것이 생각보다 더 중요하다는 것을 깨달은 시점이었습니다.

스토리 오른쪽 상단에는 두 개로 나눈 칸을 그려서 왼쪽엔 시작하기 전에 측정한 스토리의 크기를, 오른쪽엔 스토리가 끝났을 때 측정한 크기를 적습니다. 스토리를 설명하는 길이는 한 문장에서 두 문장 정도로 간략하게 합니다.

에픽과 스토리

스토리가 완성되면 오른쪽 책꽂이 위에 한동안 붙여놓습니다. 보통 반복이 끝날 때까지는 계속 둡니다.

(팀)속도

반복이 끝나면 완성된 스토리를 옆에 아무렇게나 시위하듯이 붙여놓습니다. 사실은 치워야 되는데 귀찮아서 그러지 못하고 있네요. 예전 스토리와 지금의 스토리를 비교하면서 읽어보면 점점 스토리를 만드는 요령이 생기는 것을 느낍니다. 아직 떠들 정도는 아니지만, 앞으로는 여기에 대한 이야기를 차차 적어보겠습니다.