왜 사용자 스토리?

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

자, 기획서가 잔뜩 나왔다고 칩시다. 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)이라고 부릅니다. 개발팀은 한 주나 두 주, 길어도 네 주를 넘지 않는 정해진 크기의 이터레이션 동안 개발을 진행하고 릴리스를 배포합니다. 이는 우리가 흔히 하는 것과는 반대라고 볼 수 있습니다. 꼭 필요한 기능이 들어갈 때까지 릴리스를 기다리는 것이 아니라 릴리스 시점이 먼저 정해지고 그 시간을 스토리로 채웁니다. 이렇게 해보면 왜 케이크 자르기(피자 자르기)가 중요하고 우선순위가 중요한지, 스토리를 작게 만드는 것이 왜 중요한지 알게 됩니다.

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

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

마치며

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

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