유저 스토리는 문서가 아니라서 인수 조건이 필요하다

결론부터

명세에 쓰는 세 용어는 적는 단위가 다르다. 그래서 하나가 다른 하나를 대체하지 않는다.

PRD — 릴리스 하나에 대한 문서다. 무엇을 왜 만드는지 적고, 어떻게 만드는지는 비운다
유저 스토리 — 작업을 나눈 증분이다. 카드 한 장, 대화, 확인으로 이루어지고 문서가 아니다
인수 조건 — 그 증분이 끝났는지 가르는 기준이다. Jeffries 와 North 는 실행할 수 있는 형태로 적으라고 권한다

제목의 논지는 유저 스토리의 3C 를 제시한 Ron Jeffries 의 글에 있다. 카드에는 요구사항을 떠올릴 만큼만 적는다. 나머지는 대화로 채우고, 대화가 끝났다는 것은 인수 테스트로 확인한다. 카드가 짧아도 되는 이유가 인수 조건이다.

1편에서 이 셋을 “명세” 단계로 묶었다. 이번 편은 그 단계만 깊게 판다. 정의는 원저자의 글과 Agile Alliance 용어집에서 가져왔고, 백엔드 개발자 입장에서 덧붙인 해석은 그렇다고 표시했다.

PRD 는 무엇을 만들지 적고 어떻게 만들지는 비운다

이 연재가 PRD(Product Requirements Document, 제품 요구사항 문서)의 정의로 삼는 글은 Marty Cagan 의 「How To Write a Good PRD」다. 2005년 저작권 표기가 붙어 있고, 각주에서 Ben Horowitz 의 노트와 통찰에 일부 기반했다고 밝힌다.

글이 정한 PRD 의 목적은 이렇다.

제품의 목적, 기능, 기능성, 동작을 명확하고 모호하지 않게 표현하는 것
(clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior)

제품 팀은 이 문서로 제품을 실제로 만들고 테스트한다. 그래서 그 일을 할 정보가 다 들어 있어야 한다고 쓴다.

옆에 있는 문서들과는 이렇게 갈린다

MRD(시장 요구사항 문서) — 기회나 시장의 필요를 적는다. PRD 는 그 기회를 해결하는 제품을 적는다
제품 전략 — 보통 2~5년 뒤를 내다보는 비전이다
로드맵 — 그 비전까지 가는 단계들이다
PRD — 그 경로 위의 특정 릴리스 하나를 적는다

같은 글의 각주는 회사와 업계마다 용어가 다르다고 먼저 밝힌다. 시장·제품·인터페이스 요구사항을 문서 하나에 담는 곳도 있고, 여러 문서로 나누는 곳도 있다. 그러니 “우리 회사 PRD” 가 이 정의와 다르게 생겼어도 이상한 일은 아니다.

10단계 중 문서를 쓰는 것은 7단계다

글은 좋은 PRD 를 만드는 “검증되고 반복 가능한 과정(proven, repeatable process)”을 10단계로 제시한다.

Do Your Homework — 고객, 경쟁자, 팀의 역량과 쓸 수 있는 기술을 공부한다
Define the Product’s Purpose — 가치 제안을 엘리베이터 안에서 설명할 수 있게 만든다
Define the User Profiles, Goals and Tasks — 사용자 유형, 각자의 목표, 목표를 이루는 작업을 정한다
Define your Product Principles — 팀이 판단할 때 쓸 원칙을 정한다
Prototype and Test the Product Concept — 만들 수 있나, 쓸 수 있나, 원하나를 시험한다
Identify and Question Your Assumptions — 가정을 드러내고 의심한다
Write It Down — 적는다
Prioritize — 요구사항마다 우선순위를 매기고 1부터 n 까지 줄 세운다
Test Completeness — 빠진 것이 없는지 시험한다
Managing the Product — 구현 중에 나온 질문의 답을 PRD 에 기록한다

눈에 띄는 것은 순서다. 문서를 적는 일은 일곱 번째이고, 그 앞 여섯 단계는 조사와 시험이다. PRD 는 앞 단계의 결론을 담는 그릇이라는 뜻으로 읽힌다. 이건 내 해석이다.

7단계에서 글은 PRD 를 네 영역으로 나눈다. 제품 목적(Product Purpose), 기능(Features), 출시 기준(Release Criteria), 일정(Schedule)이다. 출시 기준에는 성능, 확장성, 신뢰성, 사용성, 지원 용이성, 현지화 가능성 같은 항목이 들어간다.

해법을 적지 않는다

글이 흔한 함정으로 드는 것 중 하나가 “What versus How” 다. 요구사항은 해결할 문제를 적어야 하고 해법을 적으면 안 된다고 쓴다. 이유는 셋이다.

같은 문제를 푸는 해법은 여러 개다. 해법만 적혀 있으면 엔지니어가 문제를 잘못 짐작한다
해법을 미리 정하면 더 나은 해법으로 가는 문이 닫힌다
해법을 내놓는 것이 엔지니어의 몫인데, 그걸 빼앗으면 팀이 반발한다

글의 비유로는 “PRD 에 양초를 적어서 전구를 얻을 길을 막지 마라” 다. 대신 기능은 인터랙션 디자인과 유스케이스 수준으로 적되, 엔지니어링 팀에 유연성을 최대한 남기라고 쓴다.

9단계도 짚어둔다. 완성도를 시험하는 질문이 둘이다. 엔지니어가 목표를 이해할 수 있는가, 그리고 QA 팀이 테스트 계획을 세우고 테스트 케이스를 쓰기 시작할 만큼 정보가 있는가. PRD 단계에서 이미 “테스트로 옮길 수 있는가”가 완성의 기준이다. 이 질문은 뒤의 인수 조건으로 이어진다.

유저 스토리는 카드에 적힌 것보다 크다

Agile Alliance 용어집의 정의부터 본다. 팀은 고객이나 제품 책임자와 상의해서 해야 할 일을 기능 증분으로 나누고, 그것을 유저 스토리라고 부른다. 각 스토리는 구현되면 만드는 순서와 관계없이 제품 전체의 가치에 보탬이 되어야 한다.

같은 글의 흔한 함정 항목에 이 문장이 있다.

3C 모델이 강조하듯 유저 스토리는 문서가 아니다. 이 말은 제품의 버전 V 를 특정 목표에 대해 더 가치 있는 버전 V’ 로 바꾸는 데 필요한 지식 전부를 가리킨다.
(as the 3 C’s model emphasizes, a user story is not a document; the term encompasses all of the knowledge required to transform version V of the product into version V’ …)

처음에는 유스케이스 같은 것이었다

용어집의 기원 항목에 따르면 유저 스토리는 익스트림 프로그래밍(XP)에서 나왔다. 1998년의 첫 서술은 고객이 “유스케이스 같은 유저 스토리로” 프로젝트 범위를 정한다고만 적었다. 별도 실천법이 아니라 계획 게임의 “게임 말” 하나였다.

이후의 글은 대부분 유저 스토리가 유스케이스와 어떻게 다른지를 설명하는 쪽으로 갔다. 그 과정에서 나온 것이 2001년의 3C 와 역할-기능-효용 템플릿, 2003년의 INVEST, 2006년의 Given-When-Then 이다.

3C — 카드, 대화, 확인

Ron Jeffries 가 2001년 8월에 쓴 글이 원문이다. 유저 스토리에는 결정적인 측면이 셋 있다고 쓴다.

Card(카드) — 스토리는 카드에 적는다. 카드에는 요구사항의 전부가 들어 있지 않다. 요구사항을 식별하고 무슨 스토리인지 떠올릴 만큼만 적는다. 카드는 요구사항을 대표하는 징표(token)이고 계획에 쓰인다
Conversation(대화) — 요구사항 자체는 고객에서 프로그래머로 대화를 통해 전달된다. 대화는 주로 말로 하지만 문서로 보충할 수 있다. 가장 좋은 보충은 예시이고, 가장 좋은 예시는 실행할 수 있는 것이다
Confirmation(확인) — 아무리 논의하고 문서를 써도 해야 할 일을 필요한 만큼 확신할 수 없다. 그래서 확인이 필요하고, 이 요소가 인수 테스트다

확인 단계의 묘사가 구체적이다. 이터레이션을 시작할 때 고객은 자기가 원하는 것을 어떻게 확인할지를 말하는 방식으로 전달한다. 프로그래머는 스토리와 함께 인수 테스트도 구현한다. 이터레이션이 끝나면 인수 테스트가 통과하는 것을 보여주며 완료를 확인한다.

글의 결론부에 제목의 근거가 있다. 인수 테스트로 하는 확인이 카드와 대화라는 단순한 방식을 가능하게 한다. 카드에 적는 것이 적어도 되는 것은 끝에 확인이 있어서다.

Jeffries 는 같은 글에서 이 방식에 아직 익숙하지 않은 팀이 유스케이스, 계산 스프레드시트, 화면 스케치, 여러 쪽짜리 명세 문서를 시도하곤 한다고 쓴다. 드물게 유용할 수 있지만 돌아보면 이상적이었던 적이 거의 없었다고 쓴다. 이건 Jeffries 개인의 경험에서 나온 판단이다. 뒤에서 보겠지만 Cagan 은 다른 쪽으로 답을 냈다.

역할-기능-효용 템플릿은 보조 바퀴다

흔히 보는 이 형식이다.

As a <누가>
I want to <무엇을>
So that <왜>

Agile Alliance 의 템플릿 항목에 따르면 2001년 영국의 Connextra 에서 만들어졌고, 그래서 “Connextra 형식”이라고도 부른다. 같은 항목은 이 템플릿을 “보조 바퀴(training wheels)”라고 부른다. 무엇을 하는지뿐 아니라 누구를 위해, 무슨 목적으로 하는지를 대화에서 놓치지 않게 해 주는 장치라는 뜻이다.

흔한 함정도 같이 적혀 있다. 초보 팀이 템플릿을 기계적으로 적용한다는 것이다. 스토리의 세부는 어차피 카드를 쓰고 한참 뒤의 대화에서 나오므로, 템플릿 문구를 맞추는 데 공을 들일 이유가 별로 없다고 쓴다.

Dan North 는 이 템플릿의 쓸모를 다르게 짚는다. So that 칸이 스토리를 처음 정할 때 그 가치를 밝히도록 강제한다는 것이다. 진짜 가치가 없으면 “so that [그냥 그렇다고요]” 같은 문장이 나오고, 그러면 범위에서 빼기 쉬워진다.

INVEST 는 좋은 스토리의 점검표다

Bill Wake 의 2003년 글이 원문이다. 좋은 스토리가 갖출 여섯 성질의 머리글자다.

Independent(독립적) — 개념이 겹치지 않고, 어떤 순서로든 일정을 잡고 구현할 수 있다
Negotiable(협상 가능) — 기능에 대한 명시적 계약이 아니다. 세부는 개발 중에 고객과 프로그래머가 함께 만든다
Valuable(가치 있음) — 아무에게나가 아니라 고객에게 가치가 있어야 한다
Estimable(추정 가능) — 정확할 필요는 없고, 고객이 순위와 일정을 정할 만큼이면 된다
Small(작음) — 좋은 스토리는 작은 경향이 있다
Testable(테스트 가능) — 스토리 카드를 쓰는 것은 “테스트를 쓸 수 있을 만큼 내가 원하는 것을 안다”는 암묵적 약속이다

마지막 항목에 한 문장이 더 붙어 있다. 고객이 무언가를 어떻게 테스트할지 모른다면, 스토리가 충분히 명확하지 않다는 신호일 수 있다. 테스트할 방법이 안 떠오르는 스토리는 아직 덜 쓴 스토리다.

Wake 의 글은 Alistair Cockburn 이 카드를 “미래의 대화를 약속하는 징표”라고 묘사했다고도 인용한다. N 이 계약이 아니라고 하는 것과 같은 이야기다.

흔한 오해 셋

Agile Alliance 용어집이 함정으로 꼽은 것 중 명세와 관련된 것만 추렸다.

서술형 요구사항 문서에서 시작해 그 구조대로 스토리를 뽑는다. 예를 들면 문서의 절마다 스토리 하나
유저 스토리를 유스케이스와 같다고 본다. 비교하면 유용하지만 일대일로 대응하지 않는다
스토리를 기술 요소나 UI 요소로 본다. “검색 대화상자 스토리”라고 줄여 말할 수는 있어도 화면, 대화상자, 버튼은 유저 스토리가 아니다

첫 번째가 다음 절의 PRD 와 스토리 관계에서 다시 나온다.

인수 조건은 스토리의 동작 그 자체다

Agile Alliance 의 인수 테스트 항목은 이렇게 정의한다.

인수 테스트는 소프트웨어 제품 동작의 형식적 기술이며, 보통 예시나 사용 시나리오로 표현한다.
(An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario.)

이어지는 설명은 이렇다.

많은 경우 소프트웨어 도구로 실행을 자동화하는 것이 목표다
단위 테스트처럼 결과는 통과 아니면 실패다. 실패는 결함이 있음을 시사하지만 증명하지는 않는다
성숙한 팀은 인수 테스트를 기능 명세의 주된 형태이자 비즈니스 요구사항의 유일한 형식적 표현으로 쓴다. 다른 팀은 유스케이스나 서술형 명세의 보완으로 쓴다
기능 테스트, 인수 테스트, 고객 테스트는 거의 같은 뜻으로 쓰인다. 유저 스토리의 인수 테스트를 가리켜 “스토리 테스트”라고도 한다

용어집에는 “인수 조건(acceptance criteria)”이라는 항목이 따로 없다. 대신 유저 스토리 항목의 기대 효과에 “개발자에게 명확하고 정확한 인수 조건”이 나오고, 숙련도 설명에는 “인수 조건을 자동화된 인수 테스트로 바로 쓸 수 있는 말로 표현할 수 있다”는 항목이 있다. 기준을 적은 것이 인수 조건이고, 그 기준을 통과·실패로 돌리는 것이 인수 테스트라고 나는 이해했다.

인수 조건과 완료의 정의(DoD)는 범위가 다르다

둘 다 “끝났나”를 묻는 말이라 자주 섞인다. Agile Alliance 의 DoD 항목은 팀이 합의해 잘 보이는 곳에 붙여두는 기준 목록으로 정의한다. 제품 증분(대개 유저 스토리)이 “완료”로 인정받으려면 이 기준을 다 만족해야 한다. 같은 항목은 개별 기능이나 스토리가 일반 기준 외에 자기만의 완료 기준을 가질 수 있다고도 쓴다.

정리하면 DoD 는 모든 작업에 공통으로 걸리는 기준이고, 인수 조건은 스토리마다 다른 기준이다. 이 구분은 두 항목을 맞대어 본 내 해석이다.

Given-When-Then 은 테스트 메서드 이름에서 나왔다

Given-When-Then 의 원문은 Dan North 의 「Introducing BDD」다. 글 끝에 2006년 3월 Better Software 잡지에 처음 실렸다고 적혀 있다.

출발점은 기획이 아니라 테스트였다. North 는 TDD(테스트 주도 개발)를 가르치다가 “무엇을 테스트하나, 테스트 이름을 뭐라고 짓나” 같은 질문이 반복되는 것을 봤다. 테스트 메서드 이름을 문장으로 쓰고, “test” 대신 “behaviour(동작)”라는 말을 쓰면서 BDD(행동 주도 개발)라는 이름이 나왔다.

그다음 분석가 Chris Matts 가 “그건 분석이랑 똑같다”고 말하면서 이 생각을 요구사항으로 넓혔다. 두 사람이 도달한 결론이 이 문장이다.

스토리의 동작은 그냥 그 스토리의 인수 조건이다. 시스템이 인수 조건을 모두 만족하면 올바르게 동작하는 것이고, 아니면 아니다.
(A story’s behaviour is simply its acceptance criteria: if the system fulfils all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t.)

그래서 인수 조건을 담을 템플릿을 만들었다. 분석가에게 부자연스럽지 않을 만큼 느슨하되, 스토리를 조각으로 나눠 자동화할 수 있을 만큼은 구조가 있어야 했다.

Given 처음 맥락이 주어지고 (the givens)
When  사건이 일어나면
Then  어떤 결과를 보장한다

Given 이 여러 개면 And 로 잇는다. North 의 예시는 ATM 출금 스토리 하나에 시나리오를 여럿 둔다. 잔고가 있을 때, 마이너스 한도 안에서 초과 인출된 상태일 때, 한도를 넘어 초과 인출된 상태일 때다. 스토리 하나에 인수 조건이 하나가 아니라는 점이 여기서 보인다.

글의 다음 절 제목은 “인수 조건은 실행할 수 있어야 한다(Acceptance criteria should be executable)”다. Given, 사건, 결과 조각을 각각 자바 클래스로 표현하고 JBehave 가 그걸 엮어 실행한다. 처음에는 목(mock)으로 채우다가 구현이 진행되면 실제 클래스로 바꿔서, 시나리오가 끝날 즈음에는 제대로 된 종단 간 기능 테스트가 된다고 쓴다.

쿠폰 복구 하나를 세 층으로 내려 보면 정책 질문이 나온다

1편의 “주문 취소 시 쿠폰 복구”를 세 층으로 내려 본다. 배달앱도, 아래 문서와 코드도 전부 지어낸 예다.

먼저 PRD 의 한 절이다. Cagan 의 네 영역 중 목적, 기능, 출시 기준만 적었다.

[목적]
주문을 취소한 고객이 쿠폰 혜택을 잃지 않게 한다

[기능]
F-3 주문을 취소하면 그 주문에 쓴 쿠폰 중 정책상 반환 대상인 쿠폰을 다시 쓸 수 있게 된다
    - 받치는 목적: 위 목적
    - 해법은 적지 않는다 (쿠폰을 새로 발급할지 상태를 되돌릴지는 엔지니어링이 정한다)

[출시 기준 — 신뢰성]
취소는 됐는데 정책상 돌려줘야 할 쿠폰이 안 돌아온 주문이 남지 않는다

기능 F-3 은 무엇을 원하는지만 말한다. 쿠폰을 재발급할지, 원래 쿠폰의 상태를 되돌릴지는 비워 뒀다. Cagan 의 What versus How 를 따른 것이다. 기능마다 받치는 목적을 적는 것은 같은 글이 말하는 요구사항 추적(requirements traceability)이다.

다음은 유저 스토리 카드다. 이 정도만 적는다.

고객으로서 주문을 취소하면 쓴 쿠폰을 돌려받고 싶다.
다음 주문에 다시 쓰기 위해서다.

카드만 보면 빠진 것이 많다. 배송이 시작된 뒤의 취소는 어떻게 되는지, 쿠폰 유효기간이 그 사이 지났으면 어떻게 되는지가 없다. 3C 로 보면 정상이다. 그건 대화에서 채울 몫이다.

대화의 결과를 Given-When-Then 으로 적는다.

시나리오 1: 유효기간이 남은 쿠폰
Given 쿠폰을 적용해 결제한 주문이 있다
And   그 쿠폰의 유효기간이 남아 있다
When  고객이 배송 전에 주문을 취소한다
Then  쿠폰이 사용 가능 상태로 돌아온다

시나리오 2: 취소 시점에 유효기간이 지난 쿠폰
Given 쿠폰을 적용해 결제한 주문이 있다
And   취소 시점에 그 쿠폰의 유효기간이 지났다
When  고객이 배송 전에 주문을 취소한다
Then  ???

시나리오 2 의 Then 을 쓰려는 순간 막힌다. 만료된 쿠폰을 그대로 돌려줄지, 유효기간을 늘려 줄지, 돌려주지 않을지는 스토리가 정할 일이 아니다. 서비스 전체에 걸리는 규칙이라 정책서에서 정해야 한다. 4편의 예시 정책서는 “취소 시점에 유효기간이 지났으면 되돌리지 않는다”로 정해 두었다. 그 행이 있으면 Then 은 “쿠폰은 돌아오지 않고 만료 상태가 된다”로 채워진다. 그 행이 없는 정책서를 받았다면 여기서 막힌다.

인수 조건을 쓰는 일이 정책의 빈칸을 찾아낸다. Wake 의 Testable 이 말한 “테스트할 방법을 모르면 스토리가 덜 명확하다”가 이 장면이다. Then 에 무엇을 쓸지 모르면 대화가 덜 끝난 것이다.

백엔드 개발자가 받으면 이렇게 된다

여기서부터는 내 해석이다. Given-When-Then 은 백엔드 테스트 코드의 구조와 거의 그대로 맞물린다. 아래는 시나리오 1 을 JUnit 테스트로 옮긴 모습이다. 지어낸 클래스 이름이고 실행해 본 코드가 아니다.

@Test
void 배송_전에_취소하면_유효기간이_남은_쿠폰은_다시_쓸_수_있다() {
    // Given 쿠폰을 적용해 결제한 주문이 있고, 쿠폰의 유효기간이 남아 있다
    Coupon coupon = couponFixture.issue(LocalDate.now().plusDays(7));
    Order order = orderFixture.paidWith(coupon);

    // When 고객이 배송 전에 주문을 취소한다
    orderService.cancel(order.getId());

    // Then 쿠폰이 사용 가능 상태로 돌아온다
    Coupon reloaded = couponRepository.findById(coupon.getId()).orElseThrow();
    assertThat(reloaded.getStatus()).isEqualTo(CouponStatus.ISSUED);
}

Given 은 픽스처(테스트용 사전 데이터)가 되고, When 은 서비스 호출 한 줄이 되고, Then 은 단언이 된다. 메서드 이름이 시나리오 문장인 것은 North 가 BDD 를 시작한 지점, 즉 “테스트 메서드 이름은 문장이어야 한다”와 같다.

이 대응이 주는 실익은 둘이라고 본다. 하나는 시나리오 2 처럼 Then 이 비어 있는 인수 조건을 받으면 테스트를 쓸 수 없다는 사실 자체가 질문이 된다는 것이다. 다른 하나는 테스트 하나가 실패했을 때 어느 인수 조건이 깨졌는지가 이름에 남는다는 것이다.

다만 Jeffries 와 North 가 말한 인수 테스트는 고객이 읽을 수 있는 수준의 테스트다. 위 코드처럼 리포지토리를 직접 들여다보는 테스트는 그보다 안쪽이다. 인수 조건을 단위·통합 테스트 어디까지 내려서 검증할지는 팀이 정할 문제이고, 이 글에서 정답을 내지 않는다.

셋은 단위가 달라서 서로를 쪼갠 것이 아니다

세 층을 다시 놓으면 이렇다.

용어	단위	답하는 질문	원전
PRD	릴리스 하나	무엇을, 왜 만드나. 언제 내보내도 되나	Cagan, 2005
유저 스토리	작업 증분 하나	누구에게 어떤 가치를 더하나	XP, 3C 는 Jeffries 2001
인수 조건	스토리 하나의 완료	끝났는지 어떻게 아나	3C 의 Confirmation, GWT 는 North 2006

쿠폰 예시에서 층을 내려가며 PRD 의 기능 F-3 이 스토리 하나가 됐다. 그렇다고 PRD 를 절 단위로 잘라 스토리로 만드는 것은 아니다. Agile Alliance 가 꼽은 고전적 실수가 정확히 그것이다. 서술형 요구사항 문서의 구조를 따라 절마다 스토리를 하나씩 뽑는 것.

스토리는 문서의 목차가 아니라 가치의 증분으로 나눈다. INVEST 의 I 와 V 가 그 기준이다. PRD 의 기능 하나가 스토리 여럿이 될 수도 있고, 기능 둘에 걸친 스토리가 나올 수도 있다.

대신 연결은 남긴다. Cagan 이 기능마다 받치는 목적을 적으라고 한 것처럼, Agile Alliance 도 숙련된 개인의 기준으로 “유저 스토리를 상위의 프로젝트 목표와 연결하고 각 스토리의 비즈니스 가치를 근거 댈 수 있다”를 든다. 스토리가 왜 있는지 물으면 PRD 의 목적까지 거슬러 올라갈 수 있어야 한다.

PRD 의 출시 기준과 인수 조건도 층이 다르다. 출시 기준은 릴리스 전체에 거는 성능, 신뢰성 같은 조건이고, 인수 조건은 스토리 하나의 동작이다. 쿠폰 예시의 “정책상 돌려줘야 할 쿠폰이 안 돌아온 주문이 남지 않는다”는 특정 시나리오가 아니라 시스템 전체에 대한 요구라서 출시 기준 쪽에 뒀다.

그럼 PRD 는 이제 안 쓰나

PRD 를 정의한 Cagan 자신이 이 질문에 먼저 답했다. SVPG 사이트에 2006년 10월로 올라 있는 「Revisiting the Product Spec」은 이렇게 시작한다. 제품 명세는 한참 전에 개편됐어야 했다.

글이 짚은 문제는 이렇다.

대부분의 명세는 쓰는 데 너무 오래 걸리고, 거의 읽히지 않는다
필요한 세부나 어려운 질문을 다루지 않는다
명세가 존재한다는 사실만으로 경영진과 팀에게 일이 잘 되고 있다는 거짓 신호를 준다

그가 내놓은 답은 고충실도 프로토타입이다. 명세는 전체 사용자 경험을 담아야 하고, 말과 그림으로는 소프트웨어의 동작을 다 표현할 수 없으니, 명세의 대부분을 프로토타입으로 하자는 것이다.

다만 문서를 다 없애지는 않는다. 같은 글에서 프로토타입으로 표현하기 어려운 것은 보충해야 한다고 쓴다. 신뢰성, 성능, 확장성 같은 출시 요구사항, 설치 요구사항이나 지원 브라우저 목록 같은 플랫폼 요구사항, 핵심 흐름을 적은 유스케이스다. 보충 자료는 위키에 두라고 권한다.

2007년 11월로 올라 있는 「Product Management in an Agile Environment」는 더 직접적이다. “무거운 PRD 와 기능 명세를 프로토타입과 유저 스토리로 바꿔라(Replace heavy PRD’s and Functional Specs with prototypes and user stories).” 같은 글에 “애자일이 제품 계획을 안 해도 되는 핑계는 아니다”라는 항목도 있다. 어디로 가는지, 무엇을 이루려는지, 성공을 어떻게 잴지는 여전히 알아야 한다고 쓴다.

바뀐 것은 무거운 문서라는 형식이고, PRD 가 하던 일은 남았다. 목적을 정하고, 출시 기준을 걸고, 팀 전체가 보는 하나의 기준을 두는 일이다. 이건 2005년 글과 2006·2007년 글을 맞대어 본 내 해석이다. Cagan 의 그 뒤 글이나 책에서 입장이 어떻게 이어졌는지는 이번에 확인하지 않았다.

유저 스토리가 PRD 를 대체하느냐는 질문도 같은 결론이 된다. Cagan 이 바꾸라고 한 것은 “무거운” PRD 이고, 그 자리에 들어간 것도 스토리만이 아니라 프로토타입과 스토리다.

인수 조건을 자동화하는 데도 비용이 든다

인수 조건이 실행 가능해야 한다는 것은 North 와 Jeffries 의 주장이다. 그런데 Agile Alliance 의 같은 인수 테스트 항목이 반론도 함께 싣는다.

자동화된 단위 테스트와 달리 자동화된 인수 테스트는 모두가 이득이라고 보지는 않는다. Jim Shore 와 Brian Marick 같은 전문가가 이득이 비용보다 큰지 의문을 제기했다
자동화된 인수 테스트를 만드는 데 상당한 노력이 든다고 보고하는 팀이 많다
깨지기 쉬운 테스트 때문에 유지보수가 부담스럽다고 느끼는 팀이 있다
1세대 도구(Fit/FitNesse 계열)로 만든 인수 테스트는 정작 고객이나 도메인 전문가가 이해하지 못했다

구현 세부에 치우친 인수 테스트의 함정도 적혀 있다. 텍스트 필드의 라벨을 참조하는 인수 테스트는 라벨만 바뀌어도 실패한다. 제품의 동작은 그대로인데도 그렇다. 앞의 쿠폰 테스트가 리포지토리를 직접 조회하는 것도 같은 위험을 안고 있다. 저장 방식을 바꾸면 동작이 같아도 테스트가 깨질 수 있다.

용어집은 BDD 가 이 논쟁을 풀 가능성이 있다고만 쓰고 결론을 내지 않는다. 이 글도 마찬가지다.

이번에 확인하지 못한 것도 적어둔다.

Mike Cohn 의 『User Stories Applied』는 읽지 않았다. Agile Alliance 는 이 책이 INVEST 를 2장에서 길게 다룬다고 소개한다
Wake 의 INVEST 글은 각 항목의 첫 문장 위주로 확인했다
North 의 글은 2006년 잡지 원본이 아니라 그의 블로그에 다시 실린 판본으로 읽었다
Cagan 의 두 SVPG 글의 연도는 사이트의 게시일 표기를 따랐다. 원래 쓴 날과 같은지는 확인하지 못했다

정리

헷갈리는 짝	가르는 질문
PRD / 유저 스토리	릴리스 하나의 문서인가, 가치를 더하는 작업 증분인가
유저 스토리 / 유스케이스	대화를 약속하는 징표인가, 흐름을 적은 문서인가
인수 조건 / 인수 테스트	기준을 적은 것인가, 그 기준을 통과·실패로 돌리는 것인가
인수 조건 / DoD	이 스토리만의 기준인가, 모든 작업에 공통인 기준인가
PRD 출시 기준 / 인수 조건	릴리스 전체에 거는 조건인가, 스토리 하나의 동작인가

세 개념은 내려갈수록 다루는 범위가 작아지고 구체적이 된다. PRD 는 무엇을 왜 만드는지, 스토리는 누구에게 무슨 가치를 더하는지, 인수 조건은 끝났는지 어떻게 아는지를 적는다.

스토리 카드가 짧은 것은 결함이 아니라 설계다. 다만 그 설계는 대화와 확인이 따라올 때만 성립한다. Then 을 채울 수 없는 시나리오가 나오면 그게 아직 끝나지 않은 대화다.