버렸던 PRD를 판정 근거로 되살린 기획 문서 체인

문제 정의

혼자 빌드하게 되자 PRD를 버렸는데, 검증 앞에서 되돌아왔다

PRD는 왜 만들고 이 목표를 위해 무엇이 충족돼야 하는지를 적어 구성원을 설득하는 개발 요청 문서였다. 혼자 다 빌드하게 되면서 설득할 상대가 사라졌고, 나는 이 문서를 오버헤드라고 판단해 버렸다. 여기까지는 틀린 판단이 아니었다. 문제는 그 자리에 무엇이 남았는지를 한참 뒤에야 봤다는 것이다. 코드 생성이 거의 공짜가 되면서 병목은 생성에서 판정으로 옮겨갔는데, 무엇을 완료로 볼지 적어 두던 문서를 하필 그 시점에 버린 셈이었다.

나만 그런 게 아니었다. 본업인 슈퍼센트에서도 사이드 팀인 NMWC에서도 엔지니어 출신 빌더들이 제품을 직접 만들기 시작했고, 이들이 가지고 온 스펙 문화는 단단했지만 전부 어떻게 만들 것인가 쪽이었다. 팀이 정본으로 보관해 온 가이드를 세어 보면 빌드 쪽 문서가 여덟 종인데 제품 쪽은 1KB짜리 PRD 템플릿 한 장이 전부였고, 그 한 장에도 인수 조건 표의 빈 칸만 있을 뿐 그 칸을 어떻게 채우는지는 한 줄도 적혀 있지 않았다. 빌드 규격 여덟 종 대 제품 규격 한 종이라는 비율이, 판정의 근거가 어느 쪽에서 사라졌는지를 그대로 보여준다.

실제 제품에서는 더 노골적으로 드러났다. AIDRA는 한 달 동안 652커밋으로 쌓였는데 PRD도 스펙도 없었고, 무엇이 완료인지 판단하려면 웹과 서버를 합쳐 약 39,000줄의 코드를 직접 읽는 것 말고는 방법이 없었다. 그렇다고 규격을 세울 여유가 넉넉했던 것도 아니다. 본업을 돌리면서 하루 안에 만들어야 했고, 팀이 설치해 쓰려면 공개 마켓에 올려야 하는데 그러자면 사내 가이드와 실제 제품의 유저 스토리를 그대로 담을 수 없다는 제약이 따라붙었다. 그래서 범위를 좁게 잡았다. 문서를 잘 쓰게 만드는 도구가 아니라, 판정의 근거로 쓸 수 있는 최소 규격만 세우기로 했다.

가설 수립

채점을 시키는 대신, 채점표를 지을 근거를 주기로 했다

PRD가 죽었다는 판단에서 틀린 건 문서가 아니라 상대였다. 설득할 팀이 없으니 개발 요청서로서의 PRD가 오버헤드인 건 맞다. 그런데 협업자가 AI로 바뀌면 상대는 다시 생기고, 이 상대에게 줘야 할 것은 요청이 아니라 무엇이 완료인지를 판정할 근거다. PRD는 사라진 게 아니라 사람을 설득하는 명세에서 검증을 세우는 근거로 옮겨간 것이었다.

그렇다면 검증은 사람이 하면 되지 않느냐는 반문이 남는다. 그건 고전적인 QA의 방식이고, 정해진 케이스의 통과 여부만 확인하니 이 상황에서 이 니즈를 진짜 채웠는가 같은 정성 판정은 잡지 못한다. 무엇보다 사람이 매번 채점하면 느린 공정이 그 자리에 그대로 남아 병목이 풀리지 않는다. 그래서 방향을 뒤집었다. 결과가 몇 점이냐고 묻는 대신, 인수 조건을 근거로 평가 루브릭을 먼저 짓게 하고 그 루브릭으로 스스로 채점하게 한다. 내가 줄 것은 채점표가 아니라 채점표를 지을 근거였다.

물론 PM 방법론을 통째로 되살리자는 건 아니었다. 워터폴식 완결 명세와 개발팀에 던지는 요청서, 빅뱅 기획은 혼자 만드는 시대에 발산만 키우니 버리는 게 맞다. 재활용할 것은 골격이다. 왜 하는지와 목표, 그리고 인수 조건으로 이어지는 정성 인수 기준의 구조는 협업자가 사람에서 AI로 바뀌면서 합의 기능이 판정 근거 기능으로 그대로 넘어간다. 그 골격을 기획과 PRD와 스펙과 검증 네 단계로 세우고, PRD 하나의 요구사항이 여러 개의 스펙으로 쪼개지도록 (스펙 하나가 브랜치 하나이자 PR 하나가 되도록) 층위를 못 박았다.

솔루션 도출

근거가 되려면, 지어낸 값이 하나도 없어야 했다

게이트는 값싼 것부터 깔았다. 스키마와 타입 검사가 가장 싸고 확실하며 그다음이 유닛 테스트, 그다음이 모델 판정이고 사람 리뷰는 최후의 수단이다. 그래서 문서 쪽에도 사람 눈보다 먼저 스크립트를 세웠다. 필수 섹션이 빠졌거나 인수 조건 없는 유저 스토리가 하나라도 있으면 검증기가 완료 선언 자체를 차단한다. 검증 단계에서는 PRD를 인자로 받아 인수 조건이 하나라도 누락됐는지 대조하게 했는데, 조용히 건너뛴 인수 조건을 사람이 알아채기는 어렵지만 스크립트에게는 쉬운 일이기 때문이다.

스킬 네 개를 만들고 바로 올리는 대신 출하 전에 A/B를 돌렸다. 구체적인 PRD 요청과 구체적인 스펙 요청, 그리고 목표와 범위가 흐린 모호한 요청 세 가지를 준비하고 스킬을 쥔 에이전트와 맨손 에이전트 여섯을 병렬로 붙였다. 규격 준수율은 맨손이 32퍼센트인 데 비해 스킬을 쥔 쪽이 100퍼센트였고, 격차의 대부분은 잘 썼는가가 아니라 빠뜨리지 않았는가에서 나왔다. 가장 결정적인 장면은 모호한 요청 쪽에서 나왔다. 맨손 에이전트는 존재하지도 않는 제품의 완성된 기획서를 만들어 냈고, 스킬을 쥔 쪽은 인터뷰만 하고 문서를 쓰지 않은 채 멈춰 섰다.

이 대조가 설계의 방향을 정했다. 모델이 빈칸을 그럴듯하게 메우는 건 실력 부족이 아니라 기본 동작이다. 그런데 이 문서는 판정의 근거로 쓸 것이라 지어낸 값이 한 줄이라도 섞이면 그 위에 세운 판정이 전부 무의미해진다. 그래서 스킬이 할 일은 더 잘 쓰게 만드는 게 아니라 못 쓰게 막는 것이라고 보고, 인터뷰에서 채우지 못한 값은 확인 필요 표시로 남기라는 규율을 네 스킬 전체에 공통으로 걸었다.

검증 스킬은 따로 픽스처를 만들어 확인했다. 로그인 폼과 할일 목록에 버그를 하나씩 심어 두고 실제 브라우저를 붙인 에이전트 넷에게 찾게 했더니, 스킬을 쥔 쪽과 맨손 쪽 모두 심어 둔 버그를 잡아냈다. 정량 차이가 없다는 게 실망스럽지는 않았다. 판정이라는 과제 자체가 성립한다는 뜻이었고, 스킬 쪽만 검증기를 통과하는 고정 포맷을 냈으며 로그아웃 로직은 멀쩡한데 앞단 버그 때문에 도달을 못 한다는 상태를 부분 통과로 갈라낸 것도 그쪽이었다.

결과 & 배운 점

도구가 삐걱댄 자리마다 제품의 모순이 있었다

만든 체인을 곧바로 AIDRA에 걸어 봤다. 이미 다 만들어진 제품에 사후로 PRD를 쓰는 역기획이었으니 순수한 테스트였는데, 결과는 문서가 아니라 결함으로 나왔다. 에픽 14개와 유저 스토리 53개, 인수 조건 264개를 세우는 과정에서 코드가 기존 문서를 반박한 사례가 18건 나왔고 아무도 모르던 결함 6건이 새로 잡혔다. 가장 큰 건은 프로덕션 라이브 결함이었다. 서빙 모델이 하루 전에 바뀌었는데 긴 생성을 이어 붙이는 로직이 이전 모델 경로에만 배선돼 있어서, 전날부터 긴 글이 문장 중간에 잘려 나가고 있었다.

역기획은 애먹었다. 이 체인은 신규 기획에 맞게 설계된 것이고, PRD와 스펙 없이 만들어진 제품을 거꾸로 문서화하려니 모순이 계속 쏟아졌다. 스펙 라운드가 내 PRD 오류를 아홉 건 잡아냈고, 같은 방식을 적용한 다른 제품에서는 독립 검증이 네 라운드를 돌아 지적 열 건이 나왔는데 그중 절반이 내 오류였다. 그런데 이건 도구의 실패가 아니라 성공의 증거로 읽는 게 맞다. 삐걱댄 자리마다 제품의 모순이 있었고, 그 모순은 PRD 없이 빌드한 대가가 그제서야 청구된 것이었다.

지금 이 체인은 나와 NMWC 팀원들이 설치해 쓰고 있다. 같은 양식으로 기획 문서를 읽고 이야기하니 검증 기준이 하나로 모였고, 이거 다 된 거 맞냐고 확인하는 대화가 줄면서 의사결정과 빌드가 눈에 띄게 빨라졌다. 남은 거리도 분명하다. 내가 적어 둔 처방은 AI가 인수 조건에서 루브릭을 지어 스스로 채점하는 데까지였는데, 실제로 만든 것은 사람이 쓴 인수 조건을 그대로 체크리스트로 가져와 판정하고 누락만 기계가 막는 한 단계 앞의 버전이다. 판정 기준은 두 제품에 걸쳐 475개를 세웠지만 그 기준을 먹고 도는 검증 산출물은 아직 실제 프로젝트에서 한 건도 나오지 않았다.

이 작업에서 내가 배운 건 도구가 아니라 태도 쪽이었다. AI로 제품을 만들 때는 각자에게 맞는 워크플로우가 필요한데, 그걸 새로 발명해야 한다고 생각하기 쉽다. 그런데 내가 한 일은 버렸다고 믿었던 것 중 하나를, 그러니까 사람과 사람이 합의하던 방식을 판정 근거 쪽으로 옮겨 적은 것뿐이었다. 언러닝했다고 여긴 것 중에 되가져올 게 아직 남아 있다.