유저 스토리

만들 것을 적는 방식은 오랫동안 기능 목록이었습니다. "검색 필터 추가", "파일 업로드 지원", "알림 설정 화면" 처럼 시스템이 갖출 기능을 줄줄이 적어 개발팀에 넘겼습니다. 목록은 깔끔했지만 그 안에 사람이 없었습니다.

빈자리는 만들다 막히는 순간에 드러납니다. "파일 업로드 지원" 이라는 한 줄을 받은 개발자가 용량 상한을 얼마로 잡을지 묻습니다. 적어 준 사람은 그 자리에 없고, 있어도 "적당히요" 라고밖에 답하지 못합니다. 누가 어떤 상황에서 무엇을 올리는지가 문장에 없으니 상한을 정할 근거가 없는 겁니다. 계약서 스캔본을 올리는 사람이라면 5MB로 넉넉하고, 회의 녹화 영상을 올리는 사람이라면 500MB도 모자랍니다. 같은 한 줄이 완전히 다른 기능 두 개를 가리키고 있었던 셈입니다.

기능 목록은 우선순위를 매길 때도 힘을 못 씁니다. "검색 필터 추가" 와 "알림 설정 화면" 중 무엇을 먼저 할지 물으면 답이 취향 싸움으로 흘러갑니다. 어느 쪽이 누구의 무슨 불편을 없애는지가 적혀 있지 않으니 비교할 축이 없는 겁니다. 목소리가 큰 사람의 항목이 앞으로 가고, 밀린 항목은 왜 밀렸는지 아무도 설명하지 못합니다.

이 상태로 두 달을 보내면 결과물은 대개 아무도 원하지 않은 모습으로 나옵니다. 개발자는 자기가 상상한 사용자를 기준으로 판단했고, 적어 준 사람은 다른 사용자를 떠올리고 있었는데 둘이 그 차이를 확인할 자리가 없었기 때문입니다. 완성된 화면을 처음 본 날에야 "이게 아닌데요" 라는 말이 나오고, 그때는 되돌리는 비용이 처음 만든 비용과 비슷해져 있습니다.

같은 요구를 큰 그릇에 담는 문서가 PRD입니다. 무엇을 왜 만들고 어디까지 되면 끝인지를 한 문서에 적는데, 이 문서는 서른 쪽짜리가 되기도 합니다. 그대로는 한 사람이 한 주에 끝낼 수 있는 크기가 아니라서 쪼개야 하고, 쪼개는 순간 다시 기능 목록으로 돌아가기 쉽습니다.

유저 스토리는 그 쪼개기를 사람 기준으로 하게 만든 형식입니다. 한 줄을 누가, 무엇을 하고 싶고, 그래서 무엇을 얻는가의 세 칸으로 나눠 적습니다. 앞의 예는 "영업 담당자로서 서명된 계약서 스캔본을 문서에 첨부하고 싶다, 고객별 서류를 한자리에서 찾기 위해" 가 됩니다. 이렇게 적고 나면 용량 상한 질문의 답이 문장 안에 이미 들어 있습니다. 이렇게 쪼갠 스토리를 순서대로 쌓아 둔 목록이 제품 백로그이고, 팀은 위에서부터 꺼내 하나씩 만듭니다.

유저 스토리를 다루려면 세 갈래를 알아야 합니다. 스토리 한 줄과 그 뒤에 무엇이 붙는지(구성 요소), 잘 쓴 스토리인지 어떻게 판정하는지(품질 기준), 스토리를 여럿 늘어놓아 전체 그림을 보는 방법(방법)입니다.

구성 요소는 스토리 하나를 이루는 칸을 다루는 갈래입니다. 문장 자체는 세 칸이고, 그 아래 네 번째 칸이 따로 붙습니다.

1. 누가 — 이 기능을 쓰는 사람을 역할로 적습니다. "사용자로서" 는 아무것도 좁히지 못하니 "처음 가입한 팀장으로서", "결제 담당자로서" 처럼 한 겹 더 내려갑니다. 여기가 좁아질수록 뒤의 두 칸이 저절로 선명해집니다.
2. 무엇을 하고 싶은가 — 사용자가 하려는 행동을 적습니다. 화면 이름이나 버튼 위치가 아니라 행동입니다. "설정 화면에 토글을 추가한다" 는 만드는 쪽의 말이고, "알림을 주말에는 받지 않도록 끄고 싶다" 가 쓰는 쪽의 말입니다.
3. 그래서 무엇을 얻는가 — 그 행동으로 이루려는 목적입니다. 세 칸 중 가장 자주 비는 자리인데, 비면 다른 해법을 검토할 길이 막힙니다. 목적이 "주말에 방해받고 싶지 않다" 라고 적혀 있으면 토글 대신 방해 금지 시간대 설정이 더 나은 답일 수 있다는 논의가 열립니다.
4. 인수 조건 — 문장 아래에 붙는 확인 항목입니다. 이 스토리가 끝났다고 인정받으려면 무엇이 되어야 하는지를 검증 가능한 문장으로 적습니다. 앞의 예라면 "주말 설정을 켜면 토요일과 일요일에 알림이 발송되지 않는다", "설정은 계정 단위로 저장되어 다른 기기에서도 유지된다" 같은 줄입니다.

세 칸이 왜 만드는지를 말하고 네 번째 칸이 언제 끝나는지를 말합니다. 앞의 셋만 있으면 방향은 알아도 완료 판정을 못 하고, 네 번째만 있으면 체크리스트는 있는데 왜 하는지를 모르는 상태가 됩니다.

품질 기준은 쓴 스토리가 쓸 만한지 재는 갈래입니다. 두 가지가 다른 시점에 붙습니다.

1. INVEST 원칙 — 스토리를 백로그에 넣기 전에 봅니다. 독립적인가, 협의 여지가 있는가, 가치가 있는가, 크기를 매길 수 있는가, 충분히 작은가, 확인할 수 있는가의 여섯 가지를 묻습니다. 여기서 가장 자주 걸리는 항목은 크기입니다. "결제 기능 전체" 처럼 한 주기에 못 끝낼 덩어리는 스토리가 아니라 더 쪼갤 대상입니다. 독립성도 자주 걸립니다. A를 끝내야만 B를 시작할 수 있는 두 스토리는 순서를 바꿔 담을 수 없어서 계획을 세울 때 선택지를 줄입니다.
2. 완료 정의 — 스토리를 개발하고 나서 봅니다. 인수 조건이 스토리마다 다른 확인 항목이라면, 완료 정의는 모든 스토리에 똑같이 적용되는 공통 기준입니다. 코드 리뷰를 통과했는가, 테스트가 돌았는가, 운영 환경에 올라갔는가 같은 항목이 들어갑니다. 인수 조건만 통과하고 완료 정의를 건너뛴 작업은 화면상으로는 다 된 것처럼 보이지만 배포되지 않은 채 남습니다.

방법은 스토리를 여러 개 놓고 보는 갈래입니다. 스토리 매핑은 사용자가 처음부터 끝까지 거치는 흐름을 가로축에 늘어놓고, 각 단계에 필요한 스토리를 그 아래로 세로로 쌓는 기법입니다. 협업 문서 제품이라면 가로축이 가입하고, 문서를 만들고, 동료를 초대하고, 함께 고치고, 밖으로 공유하는 다섯 칸이 됩니다. 세로로 쌓고 나면 초대 칸만 스토리가 열두 개인데 공유 칸은 하나도 없다는 사실이 눈에 보입니다. 목록으로만 보면 절대 보이지 않던 구멍입니다. 위에서 가로로 한 줄을 그어 그 윗부분만 먼저 만들면 모든 단계가 최소한으로 돌아가는 첫 버전이 나옵니다. 세로로 잘라 초대 기능만 완벽하게 내보내면 사용자는 동료를 부를 수는 있어도 함께 고칠 수는 없는 제품을 받습니다. 가로로 자르는 편이 나은 이유가 여기 있습니다.

세 갈래는 순서대로 이어집니다. 구성 요소로 한 줄을 쓰고, 품질 기준으로 그 줄이 쓸 만한지 걸러 내고, 방법으로 줄들을 늘어놓아 빠진 데를 찾습니다. 그래서 스토리를 잘 쓰는 팀은 문장 형식을 잘 외운 팀이 아니라 이 세 단계를 다 돌리는 팀입니다.

"이거 스토리로 다시 써 주실 수 있을까요. 누가 쓰는 건지가 없어서요."

받은 요구가 기능 이름만 적혀 있어 판단할 근거가 모자라다는 말입니다.

"이 스토리 인수 조건이 비어 있는데, 뭐가 되면 끝난 건가요."

완료를 무엇으로 판정할지 합의되지 않았으니 개발을 시작하기 전에 정하자는 요청입니다.

"스토리가 너무 커요. 두 개로 쪼개죠."

한 주기 안에 끝낼 수 없는 크기라 그대로 가져가면 계획이 밀린다는 뜻입니다.

페이지덱에서 알림 설정을 손보기로 한 주에 지현이 스토리를 여덟 개 적어 왔습니다. 스프린트 플래닝 자리에서 태오가 그중 하나를 짚었습니다. "팀 관리자로서 알림 규칙을 관리하고 싶다" 라는 줄이었는데, 관리가 무엇을 뜻하는지가 사람마다 달랐습니다. 태오는 규칙을 켜고 끄는 일로 읽었고, 지현은 다른 구성원의 규칙까지 대신 바꾸는 일로 적은 것이었습니다. 두 해석 사이의 개발량 차이는 이틀과 2주였습니다.

그 자리에서 스토리는 셋으로 나뉘었습니다. 자기 알림을 끄는 것, 팀 기본값을 정하는 것, 다른 구성원의 설정을 들여다보는 것입니다. 각각에 인수 조건을 붙이고 나니 세 번째는 권한 문제가 걸려 이번 주기에 넣을 수 없다는 사실이 분명해졌고, 앞의 둘만 담아 계획이 섰습니다. 스토리 포인트도 쪼개고 난 뒤에야 매길 수 있었습니다. 스토리 포인트는 작업 하나의 상대적 크기를 나타내는 숫자인데, 원래 줄에는 아무도 그 숫자를 붙이지 못했습니다. 이틀짜리와 2주짜리가 같은 문장 안에 들어 있었기 때문입니다.

지현이 그 뒤로 바꾼 습관은 문장을 길게 쓰는 것이 아니라 역할 칸을 한 겹 더 좁히는 것이었습니다. "팀 관리자로서" 대신 "구성원 열 명 이상인 팀의 관리자로서" 라고 적자 다음 회의에서 같은 종류의 되물음이 나오지 않았습니다. 역할이 좁아지면 그 사람이 하루에 몇 번 이 화면에 들어오는지, 무엇을 못 해서 답답한지가 함께 좁혀지기 때문입니다.

형식만 맞추면 유저 스토리가 된다고 여기는 경우가 가장 많습니다. 템플릿이 세 칸으로 정해져 있으니 칸을 채우는 일이 곧 스토리 쓰기처럼 보입니다. 하지만 "사용자로서 로그인하고 싶다, 로그인하기 위해" 같은 문장은 세 칸을 다 채우고도 아무것도 좁히지 못합니다. 역할이 모두이고 목적이 행동을 되풀이하고 있어서입니다. 이런 줄이 백로그에 쌓이면 형식은 바뀌었는데 실제로 오가는 정보는 예전 기능 목록과 같아지고, 팀은 스토리를 쓰느라 시간만 더 쓴 채 같은 자리에서 막힙니다. 판정 방법은 간단합니다. 역할 칸에 적힌 말을 지우고 읽어도 문장이 그대로 말이 되면 그 칸은 비어 있는 겁니다.

스토리를 문서로 여기는 오해도 흔합니다. 한 줄로 적어 두면 그 줄이 곧 명세라고 생각하기 쉽습니다. 실제로 이 형식은 처음부터 대화를 여는 표시로 만들어졌습니다. 한 줄에 담을 수 있는 정보가 적다는 점이 단점이 아니라 설계 의도이고, 모자란 부분은 개발 직전에 만든 사람과 쓸 사람이 마주 앉아 채웁니다. 이 대화를 건너뛰고 줄만 넘기면 앞서 본 알림 규칙 사례처럼 같은 문장을 두 사람이 다르게 읽은 채로 2주가 지나갑니다. 그래서 스토리를 회의 없이 문서로만 주고받는 팀에서는 인수 조건이 점점 길어집니다. 대화로 채울 것을 글로 채우려다 보니 한 스토리에 확인 항목이 스무 줄씩 붙고, 그쯤 되면 예전의 명세 문서와 구별되지 않습니다.