BRD·PRD·Tech-spec·Task: 에이전트 하네스에서 네 계층이 두세 계층으로 줄어드는 이유

들어가며: 교과서 답안은 맞았고 맥락은 틀렸다

어제 글은 "스펙 작성 이전 단계"인 컨텍스트 얼라인을 다뤘다. 이 글은 바로 그 뒤, 스펙 작성 단계 자체의 문서 계층을 파고든다.

발단은 이랬다. 누가 물었다. "BRD, PRD, Tech-spec, Task가 각각 뭐고 AI 에이전트에 어떻게 쓸 수 있냐"고. 나는 업계 표준 정의를 정리해 넘겼다. 비즈니스 요구서 → 제품 요구서 → 기술 설계서 → 작업 분해. 상류에서 하류로 내려오는 네 계층. 답의 사실성은 맞았지만, 검토를 거치니 맥락 적합성에서 크게 빗나갔다는 걸 알게 됐다.

네 문서 체계는 여러 역할이 협업하는 조직을 전제로 한다. 비즈니스가 BRD를 쓰고, PM이 PRD로 옮기고, 엔지니어가 Tech-spec을 뽑고, 팀이 Task로 쪼갠다. 각 문서는 서로 다른 역할 사이의 계약서다. 그런데 질문자는 1인 프로젝트에서 에이전트 하네스를 구상 중이었다. 계약서를 쓸 당사자가 하나뿐이다. 형식이 작동할 조건이 성립하지 않는 자리에 형식을 그대로 얹으면, 그 형식은 비용만 된다.

이 글은 그 반성을 구조화한다. 네 문서의 전통적 자리를 정리하고, 에이전트 하네스에서 각각이 어떻게 소비되는지 분해하고, 1인 규모에서 전제가 깨지는 세 지점을 짚은 뒤, 2~3계층 경량 체계로 어떻게 줄이는지를 보인다. 마지막에 이 저장소가 실제로 굳힌 specs / plans 구조를 예로 든다.

1. 네 문서의 전통적 자리

먼저 각각이 "무엇을 답하는 문서"인지 한 줄로 잡고 들어간다.

문서	답하는 질문	작성 주체	수명
BRD (Business Requirements)	왜 해야 하는가 — 비즈니스 관점	사업 오너·전략	중기(분기~년)
PRD (Product Requirements)	무엇을 만드는가 — 사용자 관점	PM·프로덕트	단기~~중기(주~~분기)
Tech-spec	어떻게 만드는가 — 구현 관점	엔지니어·테크리드	구현 기간
Task	지금 당장 뭘 하는가	실행자	며칠~한 스프린트

1-1. BRD

시장 기회·목표 KPI·투자 근거·이해관계자·성공 기준을 담는다. "우리가 이걸 왜 하는가"의 근거다. 이 문서가 없으면 하위 문서가 조직 전체의 우선순위와 어긋날 위험이 생긴다. 그래서 여러 프로젝트가 같은 자원을 두고 경쟁할 때 가장 먼저 필요해진다.

1-2. PRD

문제 정의·사용자 스토리·기능 요구·비기능 요구·범위와 제외 범위·릴리스 단계. "무엇을 만들 것인가"를 사용자 언어로 고정한다. BRD가 "왜"이고 Tech-spec이 "어떻게"라면, PRD는 그 둘을 잇는 "무엇".

1-3. Tech-spec

아키텍처·데이터 모델·API·시퀀스·장애 시나리오·마이그레이션·테스트 전략. 구현 가능한 수준으로 PRD를 번역한다. Tech-spec이 좋으면 엔지니어 여러 명이 같은 머릿속 그림을 갖고 일한다. 나쁘면 각자의 상상으로 구현하고 나중에 충돌한다.

1-4. Task

구현 단위·담당자·예상 공수·선후 관계. 몇 시간~며칠 단위로 쪼갠다. Task가 작을수록 실패 복구 비용이 낮고, 진척도가 가시화된다.

2. 네 계층이 존재하는 이유 — 세 전제

이 체계가 형식으로 굳은 데는 세 가지 전제가 깔려 있다.

전제 1 — 작성자와 독자가 다르다. BRD를 쓰는 사람과 읽는 사람이 다르다. PRD도, Tech-spec도 마찬가지. 문서가 역할 간 계약서 역할을 하므로, 한쪽이 나중에 "그건 그 뜻이 아니었다"고 주장하지 못하도록 형식이 엄격해진다.

전제 2 — 결정이 단계별로 고정된다. 상류의 결정이 하류를 제약한다. BRD의 성공 기준이 정해져야 PRD의 범위가 그어지고, PRD가 굳어야 Tech-spec의 트레이드오프가 의미를 갖는다. 이 순서가 깨지면 하위 문서를 다시 써야 한다. 그래서 순차성을 전제하는 워터폴 질감이 남는다.

전제 3 — 문서 작성 비용이 여러 사람에게 분산된다. 한 장에 수일을 쓸 수 있는 이유는 BRD는 전략팀이, PRD는 PM이, Tech-spec은 엔지니어가 나눠 쓰기 때문이다. 총비용은 크지만 1인당 부담은 감내 가능한 수준이다.

세 전제가 다 성립하는 환경에서는 네 계층이 제값을 한다. 거꾸로 말하면, 전제 중 어느 하나가 깨지면 그 계층의 비용이 가치를 초과한다.

3. 에이전트 하네스에서 각 문서가 맡는 자리

여기서 한 걸음 더. 이 네 문서를 에이전트가 어떻게 소비하는가로 치환하면 자리가 또렷해진다.

3-1. BRD — 기각 기준

에이전트는 풀어달라는 문제를 쉬운 방향으로 해석하는 경향이 있다. 제시된 제약만 보고 최단거리로 풀러 간다. BRD는 에이전트가 내놓은 제안을 "이게 비즈니스 목적에 맞는가"로 거르는 필터다. BRD가 없으면 에이전트는 기술적으로는 정합한데 비즈니스적으로는 엉뚱한 제안을 내놓고, 그걸 거를 근거가 없다.

3-2. PRD — 스코프의 닻

에이전트는 스코프를 자기 상상으로 늘리는 경향이 더 크다. "이 기능이면 이것도 해야겠지"가 한두 번 반복되면 원래 의도와 무관한 제품이 된다. PRD는 "무엇을 만들고 무엇을 만들지 않는가"를 명시적으로 고정한다. 특히 "제외 범위(Non-goals)" 섹션이 핵심이다. 에이전트에게 "뭘 안 하는지"를 못 박는 게 "뭘 하는지"를 적는 것보다 효과가 크다.

3-3. Tech-spec — 설계의 감옥이자 일관성 보증

구현 에이전트에게 주입되는 컨텍스트. 아키텍처 경계, 명명 규칙, 의존성 방향이 여기 담긴다. 없으면 에이전트는 세션마다 다른 스타일로 구현한다. 있으면 에이전트는 그 감옥 안에서만 움직이고, 결과가 세션을 넘어 일관된다. 에이전트 입장에서는 답답하지만, 결과물 입장에서는 그게 품질이다.

3-4. Task — 실행 단위

에이전트가 한 세션에 끝낼 수 있는 크기로 쪼갠 단위. 이상적으로 1 Task = 1 세션. Task가 너무 크면 에이전트는 중간에 컨텍스트를 잃거나 방향을 놓친다. 너무 작으면 오버헤드(환경 복구·테스트 실행)가 쌓인다. 적당한 크기는 "한 번의 PR 분량"에 해당한다.

에이전트 하네스 관점에서 네 문서의 소비 방식은 다르다:

BRD / PRD는 주로 상류 판단에 소비된다 — "이 제안을 받을까 말까"
Tech-spec은 구현 컨텍스트로 주입된다 — "이 감옥 안에서 만들어라"
Task는 실행 트리거다 — "이걸 지금 해라"

소비 방식이 다르기 때문에, 네 문서를 하나로 합치면 에이전트에 한 번에 주입하기에는 너무 크고, 서로 다른 판단 지점에서 다른 모양으로 호출할 수 없게 된다. 분리되어 있는 게 에이전트 주입 비용을 낮춘다는 점은 네 문서 체계의 감춰진 장점이다.

4. 1인 / 소규모 프로젝트에서 전제가 깨지는 지점

그러면 왜 1인 프로젝트에서 이 체계가 과잉이 되는가. 2장의 세 전제를 하나씩 비춰 보면 된다.

전제 1의 붕괴 — 작성자와 독자가 같다. 혼자서 쓰고 혼자서 읽는다. 자기 자신에게 쓰는 계약서는 형식이 과하다. 대신 "미래의 나"가 3주 뒤에 돌아왔을 때 의도를 복원할 수 있을 정도면 충분하다. 엄격한 섹션 구조보다 자유로운 메모 한 장이 오히려 낫다.

전제 2의 붕괴 — 결정이 유동적이다. PRD를 쓰던 중에 생각이 바뀌어 BRD까지 고쳐야 하는 일이 자주 생긴다. 문서가 네 장이면 네 번 고쳐야 한다. 이 drift 비용은 작업 속도를 빨아들인다. 1인 환경은 본질적으로 탐색적이고, 탐색적 환경에서 워터폴 순서를 강제하면 대부분의 수정이 역류 수정이 된다.

전제 3의 붕괴 — 비용이 한 사람에게 몰린다. 네 장을 다 쓰면 코드 쓸 시간이 사라진다. 전제 3은 "비용이 분산되니 감내 가능하다"는 것이었는데, 1인에서는 분산되지 않는다. 전체 비용이 한 사람에게 얹힌다.

세 전제가 한꺼번에 깨지는 환경에서 네 문서 체계를 그대로 들이밀면, 문서 작성 자체가 프로젝트의 병목이 된다. 에이전트를 쓰는 이유가 속도였는데, 속도를 문서에 다 쓰게 된다.

5. 경량 대안 세 가지

업계에는 이미 "1~2인 규모에 맞춘 축소판" 처방이 여럿 돌아다닌다. 셋만 짚는다.

5-1. Shape Up — 3계층

Basecamp가 정리한 방식. 네 계층을 세 계층으로 압축한다.

Pitch  →  Bet  →  Build

Pitch (반페이지~6페이지): 문제·해답 스케치·추정 범위·한계(rabbit holes)·범위 제외. BRD + PRD를 축약한 한 장. 에이전트에 "왜·무엇"을 한 번에 주입하는 용도로 맞춤이다.
Bet: 6주 주기로 "이 Pitch를 할지 말지" 의사결정. BRD의 의사결정 포인트만 살린 것.
Build: 팀(또는 자기 자신)이 알아서 Tech-spec과 Task를 섞어 관리.

에이전트 관점에서 이 방식의 장점은 Pitch 한 장이 상류 컨텍스트 전부라는 것이다. 주입이 간단하고 drift 포인트가 줄어든다.

5-2. Linear 방식 — 2계층

Initiative + Issue 구조. 프로덕트 조직에서 문서를 극단적으로 줄인 예시다.

Initiative: 목표·성공지표·연관 이슈 링크. PRD의 뼈대만 남긴 카드.
Issue: 명세와 실행이 한 장에. Tech-spec의 "설계 노트"와 Task의 "체크리스트"가 같은 문서에 섞여 있다.

에이전트가 Issue 한 장만 읽으면 설계와 실행을 한꺼번에 볼 수 있다는 게 핵심이다. 대신 Issue가 커지면 가독성이 떨어진다는 단점도 있다.

5-3. DACI + 설계 문서

합의 구조(Driver / Approver / Contributor / Informed)만 별도 카드로 기록하고, 문서는 Tech-spec 한 장으로 통합하는 변형. 이해관계자가 2~3명 있어도 의사결정 흔적을 남기는 비용을 최소화한다. 1인 환경에서는 DACI 자체는 생략하고, 설계 문서 한 장으로 끝난다.

6. 내가 이 저장소에서 굳히는 3계층

원칙이 정해지면 이 저장소의 실제 운용을 한 번 검증해 볼 수 있다. docs/ 하위는 현재 이렇게 되어 있다.

docs/
└── superpowers/
    ├── specs/   (설계서)
    └── plans/   (구현 플랜)

2계층이다. Spec(무엇·어떻게)과 Plan(구현 단계)이 분리되어 있고, BRD·PRD에 해당하는 상류 문서는 명시적으로 없다. 지금까지는 글 시리즈 하나가 한 작업 단위였기 때문에 이 정도로 충분히 작동했다. 하지만 시리즈 규모가 커지고 "어떤 글을 쓸지 말지"를 결정하는 상류 판단이 쌓이면, 2계층만으로는 "왜 이 시리즈를 쓰는가"의 근거가 흩어진다.

그래서 3계층으로 확장할 때는 이렇게 붙인다.

Pitch  →  Spec  →  Plan
 (반페이지)    (1~2페이지)   (체크리스트)

Pitch (반페이지): "왜 이걸 쓰는가 + 무엇을 쓰는가"를 압축. BRD와 PRD의 통합본. 제목·대상 독자·전달하려는 핵심·제외 범위를 한 장에 담는다.
Spec (1~2페이지): 접근법·의사결정·트레이드오프. Tech-spec에 해당. 이 저장소의 specs/가 이미 이 자리를 차지하고 있다.
Plan (체크리스트): 구현 단계. plans/가 이미 이 자리를 차지하고 있다.

에이전트 관점에서 각 층의 소비 방식은 이렇다.

층	에이전트에서의 역할	주입 방식
Pitch	엇나간 제안을 기각하는 필터	작업 시작 시 1회 로드
Spec	구현의 감옥	구현 에이전트에 매번 주입
Plan	단위 실행 큐	세션 단위로 하나씩 소비

BRD를 완전히 제거한 게 아니다. BRD가 답하던 "왜 해야 하는가"를 Pitch의 반 장에 녹여서 통합한 것이다. 질문이 사라진 게 아니라, 질문에 답하는 문서의 모양을 줄였다.

7. 언제 다시 풀 체인으로 돌아가는가

3계층이 2계층으로, 2계층이 4계층으로 바뀌는 트리거가 뭔지 미리 알아두는 게 좋다. 세 경우에 풀 체인이 다시 의미를 갖는다.

트리거 1 — 이해관계자가 3명 이상이 될 때. 투자자·사업 파트너·외부 개발자 등 결정에 영향을 주는 사람이 3명 이상 되면, BRD가 의사결정의 기록이자 설득 자료로 필요해진다. 이때부터 Pitch만으로는 부족하다.

트리거 2 — 같은 영역에 여러 프로젝트가 겹칠 때. 프로젝트 A가 B의 자원을 가져가야 할지 판단이 필요해지면, 두 프로젝트의 비교 가능한 BRD가 있어야 한다. 우선순위 결정은 Pitch 간 비교로는 잘 안 된다.

트리거 3 — 엔지니어가 여럿이 되어 설계 일관성이 문제가 될 때. Tech-spec이 팀 계약서로 필요해진다. 한 명이 쓰고 혼자 읽을 땐 Spec 한 장이면 됐지만, 여럿이 읽으면 섹션 구조와 형식이 일관성을 떠받치기 시작한다.

이 셋 중 어느 트리거도 당겨지지 않은 환경에서는 3계층으로 충분하고, 네 번째 계층은 "혹시 필요할 때를 위해 뒤에 치워 두는 도구"의 자리에 두면 된다.

마무리: 형식은 공짜가 아니다

네 문서 체계는 협업의 비용을 낮추려고 만들어진 형식이다. 작성자와 독자가 다르고, 결정이 단계별로 고정되고, 비용이 여러 사람에게 분산되는 환경에서 제값을 한다. 그 환경이 아니면 형식은 도움이 아니라 세금이다.

에이전트 하네스에서는 이 판단이 더 예민해진다. 문서는 곧 주입 컨텍스트 비용이기 때문이다. 네 장을 다 읽히면 토큰 예산이 깎이고, 실행 전 판단 비용이 커진다. 거꾸로 한 장으로 다 합치면 에이전트가 판단 지점마다 다른 모양으로 꺼내 쓸 수가 없다. 적정 계층 수는 작성자 수와 세션당 판단 지점 수로 결정된다고 요약할 수 있겠다.

내 경우 답은 대부분 3계층이다. Pitch·Spec·Plan. 상류의 BRD는 Pitch의 반 장에 녹이고, Tech-spec과 Task 분해는 Spec·Plan으로 자연스럽게 매핑된다. 이 저장소도 이 모양으로 수렴하고 있고, 이해관계자가 늘거나 프로젝트가 경쟁하기 시작하면 그때 네 번째 층을 꺼낼 예정이다.

처음 질문자에게 돌려준 교과서 답안은 틀리지 않았다. 하지만 옳은 정의가 옳은 처방은 아니다. 문서 체계를 고를 때는 그 체계가 전제하는 환경이 내 환경과 같은지를 먼저 물어야 한다. 그 확인이 빠지면 형식은 생산성을 갉아먹는 쪽으로 작동한다.