PRD — AI 팀에게는 문서가 곧 기억이다

PRD는 Product Requirements Document, 우리말로 하면 제품 요구사항 정의서다. 무엇을 만들지, 왜 만드는지, 각 기능이 어떻게 동작해야 하는지를 적은 문서. 기획자의 본진이다.

혼자 만드는데 PRD가 왜 필요하냐고 물을 수 있다. 결재 올릴 상사도, 설득할 개발팀도 없는데. 그런데 AI와 일해 보면 알게 된다 — AI 팀원은 어제의 대화를 기억하지 못한다. 오늘 밤의 AI는 어젯밤의 AI가 무슨 결정을 했는지 모른다. 사람 팀이라면 "지난주에 얘기했잖아요"가 통하지만, AI 팀에서는 통하지 않는다.

이게 생각보다 무섭다. 어제 두 시간을 들여 "이 화면에서는 이렇게 하기로 했다"고 합의해도, 오늘 새 대화를 열면 그 합의는 존재하지 않는다. 더 나쁜 건 AI가 "모르겠다"고 하지 않는다는 점이다. 대신 그럴듯한 다른 방식을 새로 제안하고, 나는 그게 어제와 다르다는 걸 알아차리지 못한 채 승인한다. 그렇게 이틀만 지나면 앱 안에 같은 일을 하는 방식이 세 가지쯤 생긴다. 사람 팀에서 신입이 매일 아침 리셋되는 상황이라고 생각하면 이해가 쉽다.

그래서 문서가 팀의 기억이 된다. 프롤로그의 그 어설픈 프롬프트는 첫날 밤 정식 PRD가 됐다. 기능마다 번호가 붙었다.

• F-101 : 데일리 브리핑
• F-103 : URL 요약
• F-205 : 온톨로지 그래프 (내 기록들이 어떻게 연결되는지 보여주는 지도)
• F-306 : Pro 구독

이 번호들은 열흘 내내 나와 AI 사이의 공용어였다. "F-103에서 크롤링 실패하면 어떻게 돼?"라고 물으면 대화가 한 번에 정렬됐다.

번호를 붙인 효과는 예상보다 컸다. 사람 조직에서 기능 번호는 주로 추적용, 그러니까 진행률을 세기 위한 도구다. 그런데 AI 팀에서는 좌표로 쓰였다. "요약 기능 말인데"라고 하면 AI는 어느 요약인지 되묻거나 혼자 짐작하지만, "F-103"이라고 하면 문서의 그 항목을 그대로 읽고 시작한다. 새 대화를 열 때마다 배경 설명을 다시 하지 않아도 되니, 대화 첫머리가 짧아지고 본론이 길어졌다.

HARNESS.md — 매 세션 처음 읽는 문서

한 발 더 나갔다. 프로젝트 저장소에 HARNESS.md(작업 하네스)라는 문서를 만들었다. 하네스는 원래 안전벨트 장구를 뜻하는데, 여기서는 "AI가 일을 시작하기 전에 반드시 매는 벨트"다. 매 세션의 AI는 이 문서부터 읽는다. 지금 프로젝트가 어떤 상태인지, 건드리기 전에 확인할 규칙이 뭔지, 지난밤에 뭐가 끝났고 뭐가 막혀 있는지. 문서의 첫머리에는 이런 문장이 있다.

작업이 끝나면 반드시 이 문서를 갱신한다. 안 하면? 다음 세션의 AI가 틀린 전제로 일을 시작한다. 사람 조직에서는 온보딩 문서가 낡아도 선배가 커버해 주지만, AI 조직에서는 문서가 낡는 순간 팀 전체가 어긋난다. 덕분에 나는 20년 경력에서 가장 문서화에 성실한 열흘을 보냈다. 자발적으로는 아니고, 구조적으로.

재미있는 건 이 습관이 나에게도 남았다는 것이다. 예전의 나는 결정을 내리고 나면 그 근거를 굳이 적지 않았다. 내 머릿속에 있으니까. 그런데 AI에게 설명하려면 근거를 문장으로 만들어야 하고, 문장으로 만들다 보면 근거가 부실한 결정이 그 자리에서 드러난다. 문서화가 팀을 위한 일인 줄 알았는데, 실은 내 생각을 검산하는 절차였다.