Build Club Week Two: PRD는 모든 것을 포착하지 못한다
Source: Dev.to
이번 주 작업
지난 주에 나는 코드는 없고, 코드를 가능하게 하는 작업—PRD, 프롬프트 사양, 아키텍처 문서, 그리고 Kiro를 위한 빌드 브리프—만 있다고 글을 올렸다. 이번 주에는 모든 결정을 미리 정해놓았다고 생각하고 시작했다.
그런데 빌드를 시작했다.
- Block 2에서는 실제 테스트를 통해 법원 직원이 절대 쓰지 않을 문구가 모델에 포함된 것을 발견했다. “Strip identifiers”는 개발자에게는 합리적으로 들리지만, 법원 서기는 이해하기 어렵고 기술적인 표현이다—교육에서 건너뛰기 쉬운 종류다. 정확히 버그라기보다는 PRD에도 명시되지 않은, 눈에 띄는 문제였다.
- Block 3에서는 대비 질문, 헬퍼 텍스트 마이크로카피, 검증이 필요한 비활성화 상태 등을 표시하기 시작했다. 이 항목들은 원래 범위에 없었고, 빌드 중단 이슈도 아니었지만 실제로 존재했다.
- Block 4에서는 빌드 진행 중에 머릿속에 다듬어야 할 항목 리스트를 가지고 있었다. 밤 11시경 Claude에게 모든 것이 어떻게 추적되고 있는지 물었더니, 솔직히 “신뢰할 만한 방식으로는 추적되지 않는다”고 답했다. 이는 내가 빌드 브리프에서 문제점으로 지적했던 “기억해 두겠다”는 신뢰와 정확히 맞닿아 있었고, 나는 그것이 스며들게 허용했다.
펀치리스트
펀치리스트는 PRD가 아니다. PRD는 무엇을 만들지 정의하고, 펀치리스트는 실제로 만들면서 드러나는 것을 기록한다. 두 문서는 서로 다른 역할을 하며 별도의 문서로 존재해야 한다.
주말이 끝날 무렵 내 펀치리스트는 다음과 같이 늘어났다:
- 14개의 다듬기 항목
- 8개의 v2로 연기된 항목
- 배포 전 정리 작업 4개
- 학습 내용 4개
이 중 일부는 “한 시간만 하면 되니 추가하자”는 생각에 의해 발생하는 범위 확장(스코프 크리프)으로, 4주짜리 빌드를 8주짜리로 늘릴 위험이 있다. 다른 항목들은 PRD가 예측할 수 없었던 실제 버그였으며, 아직 충분히 제품을 출시하지 않아 발견되지 않은 문제들이다. 또 일부는 실제 법원 직원의 목소리로 읽어볼 때 바로 잘못된 표현임을 알 수 있었다.
다르게 할 점
펀치리스트를 1일 차에 PRD와 동시에 시작한다. PRD의 섹션으로 넣는 것이 아니라(역할이 다르므로) 별도의 문서로 두어 언제든 바로 사용할 수 있게 만든다. 빈 펀치리스트 자체를 자리채우기가 아니라 하나의 기능으로 취급한다.
핵심 정리
- PRD는 범위를 고정한다; 펀치리스트는 PRD가 아직 보지 못한 모든 것을 담는다.
- 두 문서 모두 필요하다.
- 중요한 점은 완벽한 PRD를 쓰는 것이 아니라, 생각이 어느 문서에 속하는지 즉시 판단해 바로 기록하는 습관이다. 기억에 의존하지 않는다.
다음 주: 다듬기와 배포
3주 차는 다듬기와 배포에 집중한다. 현재 진행 중인 펀치리스트가 다음 작업을 안내한다:
- 지연에 대비한 로딩 상태 경험
- PDF 내 브랜드 배너
- 모바일 반응형 디자인
- AWS Amplify를 이용한 실시간 URL 배포
**Women in AI Accelerator의 Build Club**과 함께 빌드 중. 사려 깊고 관대한 커뮤니티를 운영하는 **Annie Liao**와 **Caroline Ciaramitaro**에게 태그를 남긴다.