PRD에서 백로그로: 요구사항으로 이어지는 실을 놓치지 않고 AI로 계획된 이슈 생성하기

요구사항으로 이어지는 실이 중요한 이유

PRD에서 생성한 백로그는 첫날에는 완성된 것처럼 보입니다. 이슈 40개, 깔끔한 제목, 정돈된 라벨. 두 사이클 뒤에 누군가 "내보내기 제한은 만들었나요?"라고 묻는데 아무도 답할 수 없습니다. 그것을 다루던 이슈가 쪼개지고, 이름이 바뀌고, 다른 이슈와 합쳐졌으며, 그 사이 PRD는 두 번 수정되었기 때문입니다.

각 이슈에서 그것이 구현하는 정확한 요구사항으로 이어지는 실이 있어야 그 질문에 답할 수 있습니다. 그 실이 있어야 에이전트든 사람이든 나중에 커버리지 확인을 할 수 있습니다. 어떤 요구사항에 이슈가 없는지, 어떤 이슈가 아무 요구사항도 가리키지 않는지, 어떤 요구사항이 이슈 작성 후 바뀌었는지. 실이 없으면 "커버리지"는 느낌일 뿐입니다.

그래서 첫 번째 규칙은 이것입니다. 생성 전에 PRD를 고정하고, 모든 이슈가 요구사항을 id로 인용하게 하세요.

넘기기 전에 PRD 준비하기

에이전트는 모호한 PRD를 충실하게 모호한 이슈로 바꿉니다. 문서에 30분을 쓰면 티켓 정리 하루를 아낍니다.

1. 요구사항에 번호를 매긴다. R1, R2, R3 또는 중첩 체계. 에이전트는 인용할 안정적인 손잡이가 필요합니다. 산문 문단은 손잡이가 아닙니다.
2. 각 요구사항에 인수 기준을 준다. "주어진 / 할 때 / 그러면" 형식이나 단순 체크리스트로 두세 줄에서 네 줄. 요구사항의 기준을 쓸 수 없다면 이슈가 될 준비가 안 된 것이고, 에이전트가 지어낼 것입니다.
3. 비목표를 표시한다. 범위 밖인 것의 짧은 목록은 일부러 하지 않는 것에 대해 에이전트가 이슈를 생성하는 것을 막습니다.
4. 고정한다. 버전을 저장하고 기준선으로 표시하고 그 버전에서만 생성합니다. 나중의 수정은 새 기준선과 차이를 만들지, 이미 진행 중인 이슈를 조용히 바꾸지 않습니다.

우리 PRD 템플릿이 정확히 이 순서로 이 섹션들을 갖춘 이유입니다.

에이전트에게 주는 브리프

브리프는 짧고 엄격합니다. 우리 것을 약간 다듬었습니다.

입력: PRD "예약 리마인더" v3 (고정 기준선). 요구사항 R1–R9,
각각 인수 기준 포함. 비목표 섹션은 구속력이 있음.

다음 조건을 만족하는 계획된 이슈를 만들 것:
- 모든 이슈는 구현하는 요구사항 id를 정확히 하나 명시한다.
- 모든 이슈는 그 요구사항의 인수 기준을 그대로 복사한 뒤
  필요한 기술적 기준을 추가한다.
- 모든 이슈는 한 사람이 한 사이클에 끝낼 만큼 작아야 한다. 요구사항이
  그 이상을 필요로 하면 쪼개고 부분들이 어떻게 합쳐지는지 말한다.
- 모든 이슈는 기존 라벨 목록에서 유형 라벨(feature, bug, chore) 하나와
  영역 라벨 하나를 붙인다. 라벨을 새로 만들지 않는다.
- 비목표를 구현하는 이슈는 없다.
- 이슈로 만들 수 없었던 요구사항을 나열하고 이유를 말한다.

계획된 이슈만 만들 것. 기존 이슈나 상태는 바꾸지 말 것.

마지막 줄은 에이전트의 권한과 대응합니다. 계획 실행에는 계획된 이슈를 만들기 위한 work.write를 주고, 실제 보드를 건드리는 것은 주지 않습니다.

잘 생성된 이슈의 모습

이 표는 검토 체크리스트로도 씁니다. 이슈 40개를 여섯 열로 검토하는 데 40분쯤 걸리는데, 직접 쓰는 것보다 빠르고 나중에 빈틈을 발견하는 것보다는 훨씬 빠릅니다.

거부 규칙: 백로그에 받아들이지 말아야 할 것

거부하고, 이유를 붙여 에이전트에게 돌려보냅니다.

• 요구사항 id 없음. 가장 흔한 실패. 이슈는 합리적일 수 있지만 추적할 수 없습니다. 요구사항을 구현하면 인용하고, 잡무면 그렇게 라벨을 붙이고, 범위 확장이면 버립니다.
• 이슈 하나에 요구사항 id 여러 개. 그것은 이슈가 아니라 에픽입니다. 쪼개세요.
• 복사가 아니라 바꿔 쓴 인수 기준. 바꿔 쓰면 어긋납니다. 이슈의 기준은 PRD의 기준 그대로여야 하고, 기술적 추가는 추가라고 명확히 표시합니다.
• "올바르게 작동함"이나 "설계대로"가 기준. 테스트할 수 없습니다. 거부.
• 비목표에 대한 이슈. 에이전트가 비목표를 읽고도 생성합니다. 일어나는 일입니다. 거부.
• 한 사람이 한 사이클에 끝내는 모습을 그릴 수 없는 크기. 당신이 끝을 못 보면 담당자도 못 봅니다.
• 지어낸 라벨이나 컴포넌트. 에이전트는 받은 라벨 목록을 써야 합니다. 새 라벨은 사람의 결정입니다.

보통 두 라운드면 충분합니다. 세 번째 라운드에도 같은 실패가 나오면 문제는 에이전트가 아니라 PRD입니다.

이슈를 사이클과 라벨에 배치하기

이슈가 통과하면 계획된 작업이지 약속된 작업은 아닙니다. Atrix에서 프로젝트 관리는 사이클이 계획될 때까지 이슈를 백로그에 둡니다. 사이클은 목표와 이슈 수를 세는 번다운이 있는 1–4주이며, 사이클이 닫히면 끝나지 않은 이슈는 다음 사이클로 넘어가거나 백로그로 돌아갑니다. 스토리 포인트는 없습니다. 위의 크기 규칙("한 사람, 한 사이클")이 추정 모델의 전부이며 일부러 거칠게 두었습니다.

라벨은 워크스페이스에 속하고 색을 가집니다. 우리는 이슈마다 유형 라벨 하나와 영역 라벨 하나를 쓰며, 브리프에서 에이전트에게도 그렇게 지시했습니다. 요구사항 묶음에 출시일이 있으면 마일스톤이 사이클을 가로질러 이슈를 묶습니다.

요구사항 감사는 그다음 납품된 것을 고정 기준선과 비교해 커버리지와 드리프트를 보고합니다. 어떤 요구사항에 출시된 이슈가 있고, 어떤 것에는 없고, 어떤 것이 이슈 작성 후 바뀌었는지. 요구사항을 코드가 아니라 계획과 비교합니다. 코드가 이슈가 말하는 대로 동작하는지는 여전히 코드 리뷰의 일입니다.

Linear나 Jira에서도 같은 워크플로가 됩니다. Linear의 프로젝트와 라벨, Jira의 에픽과 컴포넌트. 그 도구들에서 요구사항으로 이어지는 실은 기능이 아니라 관례이므로, 이슈 제목에 요구사항 id를 넣고 PRD는 버전 기록이 있는 곳에 두세요.

자주 묻는 질문

AI가 PRD에서 백로그를 생성할 수 있나요?

네. PRD에 인수 기준이 있는 번호 매긴 요구사항과 비목표 목록이 있으면 쪼개기와 라벨 붙이기를 잘합니다. 쪼갠 것이 전체와 맞는지는 판단하지 않으므로, 생성된 모든 이슈는 백로그에 들어가기 전에 짧은 거부 목록에 비춘 사람의 확인이 필요합니다.

생성된 이슈는 요구사항에 어떻게 연결해야 하나요?

각 이슈가 요구사항 id를 정확히 하나 명시하고 그 요구사항의 인수 기준을 그대로 복사합니다. PRD는 생성 전에 기준선으로 고정되므로 나중의 수정은 진행 중인 이슈를 조용히 바꾸지 않고 새 기준선을 만듭니다.

생성된 이슈는 얼마나 커야 하나요?

한 사람이 한 사이클 안에 끝낼 만큼 작게. 요구사항이 그 이상을 필요로 하면 쪼개고 부분들이 어떻게 합쳐지는지 적습니다. 이 거친 규칙이 스토리 포인트를 대신합니다. Atrix는 설계상 포인트가 없고 번다운은 이슈 수를 셉니다.

AI가 생성한 백로그에서 무엇을 거부해야 하나요?

요구사항 id가 없는 이슈, 여러 요구사항을 인용하는 이슈, 바꿔 쓰거나 테스트할 수 없는 인수 기준, 명시된 비목표에 대한 이슈, 끝을 그릴 수 없을 만큼 큰 이슈, 지어낸 라벨. 각각 이유를 붙여 돌려보내세요. 보통 두 라운드면 충분합니다.

제품 백로그란 무엇인가요?

아직 사이클에 배정되지 않은 계획된 작업의 순서 있는 목록입니다. 로드맵 및 사이클과의 차이는 백로그 용어집 항목을 보세요.

요구사항 감사는 코드를 확인하나요?

아니요. 납품된 이슈를 고정된 요구사항 기준선과 비교해 커버리지와 드리프트를 보고합니다. 코드가 이슈가 말하는 대로 동작하는지는 사람이 하는 코드 리뷰입니다.

다음 단계

다음 PRD에서 요구사항에 번호를 매기고, 각각에 인수 기준을 더하고, 어떤 에이전트에게든 이슈를 요청하기 전에 고정하세요. PRD 템플릿은 그렇게 구성되어 있고, AI 에이전트 페이지에는 Develop 실행이 돌려주는 것, 즉 요구사항, 아키텍처, 그리고 각각 자기 요구사항을 가리키는 계획된 이슈가 나와 있습니다.