PRD vs 스펙 vs RFC: 어떤 문서가 필요할까

PRD(프로덕트 요구사항 문서)는 결정하고 비용을 대는 사람들을 위해 무엇을 왜 만드는지 말합니다. 스펙(사양서)은 만들고 테스트하는 사람들을 위해 정확히 어떻게 동작하는지 말합니다. RFC(Request for Comments)는 누군가 착수하기 전에 변경을 제안하고 반론을 초대합니다. 대부분의 작은 팀에는 프로덕트마다 PRD 하나, 엣지 케이스가 있는 것에는 스펙, 되돌리기 어려운 결정에만 RFC가 필요합니다.

이것이 짧은 답입니다. 긴 답은 독자와 시점, 그리고 지난 2년 사이에 생긴 변화에 관한 것입니다. 이 문서들을 가장 먼저 읽는 쪽이 이제는 AI 에이전트인 경우가 많고, 그것이 좋은 문서의 조건을 바꿨습니다.

세 문서를 나란히 놓고 보기

	PRD	스펙	RFC
답하는 질문	무엇을, 누구를 위해, 왜 만드는가	정확히 어떻게 동작하는가	이 변경을 해야 하는가
쓰는 사람	프로덕트 책임자, 창업자, PM	작업에 가장 가까운 엔지니어나 디자이너	변경을 제안하는 사람
읽는 사람	창업자, 고객, 엔지니어, 마케팅	엔지니어, QA, 코드를 쓰는 에이전트	결정 전, 영향을 받는 모든 사람
수명	프로덕트의 수명만큼	기능의 수명만큼	결정될 때까지, 그 후 보관
길이	2~6쪽	동작을 설명하는 데 필요한 만큼	1~3쪽과 댓글
변경 방식	베이스라인과 변경 기록을 통해	출시 전까지 자유롭게	드물게; 새 RFC가 대체
실패하는 경우	문제 없이 기능만 나열할 때	동작 대신 의도를 적을 때	결정 후에 작성될 때

가장 중요한 행은 첫 줄과 마지막 줄입니다. 각 문서는 하나의 질문에 답하고, 각각 특유의 방식으로 잘못됩니다.

PRD는 무엇을 위한 문서인가

프로덕트 요구사항 문서는 누군가 에디터를 열기 전에, 프로덕트에 관여하는 모두가 문제와 경계에 합의하기 위해 존재합니다. 용어집의 PRD 항목에 전체 구조가 있고, 제 몫을 하는 부분은 다음과 같습니다.

문제를 한 단락으로. 누가 겪고 있고, 그걸 어떻게 아는지.
목표와 비목표. 더 유용한 쪽은 비목표입니다. "v1에서는 오프라인 편집을 지원하지 않는다"는 한 줄이 한 달치 논쟁을 막습니다.
번호가 붙은 요구사항. 바뀌지 않는 식별자(REQ-007), 우선순위, 테스터에게 넘길 수 있는 인수 기준.
미해결 질문. 아직 열려 있는 것만, 날짜와 함께.

PRD는 고객이 승인하는 문서이자, 나중에 요구사항 감사가 구현 결과를 대조하는 기준입니다. 그러려면 바뀌지 않는 식별자와 승인 시점에 동결된 사본이 필요합니다. 매주 제자리에서 다시 쓰이는 PRD는 감사할 수 없습니다. 무엇이 합의됐는지 아무도 말할 수 없기 때문입니다.

PRD가 아닌 것: 화면 목록, 데이터베이스 스키마, 기술 설계. "이걸 JSONB 컬럼에 저장한다"고 적는 순간, 그 문서는 모자를 잘못 쓴 스펙이 됩니다.

처음부터 쓴다면 PRD 템플릿에 이 순서대로 섹션이 있고, 이전 글 AI로 PRD 쓰는 법이 채우는 과정을 안내합니다.

스펙은 무엇을 위한 문서인가

스펙(기능 사양, 기술 사양, 설계 문서; 이름은 서로 섞입니다)은 요구사항을 만들고 테스트할 수 있을 만큼 정확한 동작으로 번역합니다. PRD가 "고객은 자신의 데이터를 내보낼 수 있다"고 말할 때, 스펙은 어떤 형식인지, 파일 이름이 무엇인지, 25MB가 넘는 첨부는 어떻게 되는지, 내보내기가 백그라운드에서 도는지, 그동안 사용자가 무엇을 보는지를 말합니다.

좋은 스펙은 PRD와 모양이 다릅니다.

스펙 하나에 요구사항 또는 기능 하나. 프로덕트 전체를 다루는 스펙은 너무 자세한 PRD입니다.
산문이 아니라 상태와 전이. "상태 Y에서 사용자가 X를 하면 Z가 일어난다"는 표가 단락보다 더 많은 버그를 잡습니다.
엣지 케이스를 명시적으로 나열. 비어 있음, 최대치, 동시 실행, 오프라인, 권한 거부.
인터페이스. API 형태, 이벤트 이름, 필드와 타입.
이번 버전의 범위 밖. 누군가 실수로 만들지 않도록.

스펙은 기능이 출시되는 순간까지 자주 바뀌어도 됩니다. 만드는 사람들을 위한 작업 문서이므로 승인보다 버전 기록이 더 중요합니다. 다섯 명 팀에서는 스펙이 프로젝트 아래 PRD 옆에 있는 페이지이고, 엔지니어가 작업하면서 편집하고 PM은 고쳐 쓰는 대신 댓글을 다는 경우가 많습니다.

프로덕트 스펙과 기술 스펙의 차이는 주로 누가 엣지 케이스를 쓰느냐입니다. 프로덕트 스펙은 각 상태에서 사용자가 보는 것을, 기술 스펙은 시스템이 거기에 이르는 방법을 나열합니다. 작은 팀은 보통 두 섹션짜리 문서 하나로 합치고, 그래도 괜찮습니다.

RFC는 무엇을 위한 문서인가

RFC는 되돌리기 비싼 변경을 제안하고, 영향을 받는 사람들에게 나중이 아니라 지금 반론하라고 요청합니다. 이 도구들로 작은 회사를 운영하며 겪은 예: 프로젝트별 권한에서 워크스페이스 전체 권한으로의 전환, 결제 공급자 이전, 모노레포 도입, 마케팅 사이트에서 언어 하나 제거.

형식은 단순하고, 초기 인터넷 RFC가 말 그대로 "의견을 구하는 메모"였던 1960년대 이후 안정적입니다.

배경: 지금 무엇이 사실이고 왜 문제인가.
제안: 구체적인 변경 내용.
검토한 대안과 각각을 기각한 이유. 이 섹션이 RFC와 공지를 구분합니다.
결과: 쉬워지는 것만이 아니라 어려워지는 것.
의견 수렴 기간: 댓글 마감일과 결정권자.

RFC는 그에 따라 행동할 사람보다 더 많은 사람이 읽습니다. 세 문서 중 유일하게 코드가 출시될 때가 아니라 댓글이 멈출 때 완성됩니다. 결정되면 승인 또는 기각으로 표시하고 그대로 둡니다. 이후의 변경은 첫 RFC를 참조하는 별도의 RFC로 다룹니다. 이를 의사결정 기록이나 ADR이라 부르는 팀도 있지만 작동 방식은 같습니다.

전형적인 실패는 결정이 난 뒤 서류상 근거를 만들려고 쓰는 RFC입니다. 사람들은 알아채고, 다음 RFC에는 댓글을 달지 않게 됩니다.

지금 당장 필요한 문서는 무엇인가

다음 질문을 순서대로 따져 보세요.

아직 존재하지 않는 프로덕트나 기능이 있고, 그것이 무엇인지 두 사람 이상이 합의해야 하는가? PRD를 씁니다. 기존 프로덕트 안의 기능이라면 별도 문서를 시작하지 말고 프로덕트의 PRD에 새 번호의 요구사항으로 추가합니다.
엣지 케이스가 두세 개를 넘는 요구사항이 있거나, 다른 사람이 그에 맞춰 개발할 인터페이스가 있는가? 그 요구사항의 스펙을 쓰고 요구사항에서 링크합니다.
여러 팀에 걸치거나, 일주일 이상 걸리거나, 되돌리기 어려운 변경이 있는가? RFC를 쓰고 마감일을 정합니다.
어느 것도 아닌가? 인수 기준이 있는 이슈를 쓰고 문서는 건너뜁니다. 이틀짜리 작업에 PRD는 필요 없습니다.

고객 프로덕트를 만드는 여섯 명 팀이라면 보통 PRD 하나, 프로젝트 기간 동안 스펙 3~10개, 1년에 RFC 한두 개입니다. 스펙보다 RFC가 많다면 만드는 것보다 토론을 더 많이 하고 있는 겁니다.

2026년의 변화: 에이전트가 먼저 읽는다

2년 전 스펙의 첫 독자는 개발자였습니다. 지금은 코딩 에이전트, 워크스페이스 안의 계획 에이전트, MCP로 연결된 어시스턴트인 경우가 많습니다. 이것이 좋은 문서의 조건을 몇 가지 실질적인 방식으로 바꿉니다.

구조가 산문을 이깁니다. 번호 붙은 요구사항과 인수 기준이 있는 PRD를 받은 에이전트는 그에 맞춰 이슈를 계획하고 커버리지를 보고할 수 있습니다. 네 쪽짜리 서사를 받으면 요약하다가 경계를 잃습니다. 제목, 식별자, 표는 더 이상 스타일 취향이 아니라 인터페이스입니다.

비목표는 글자 그대로 읽힙니다. 사람은 "v1에 오프라인은 없음"을 훑어보고 기억합니다. 작업을 계획하는 에이전트는 받은 문서에 적혀 있을 때만 그것을 지킵니다. 비목표는 채팅 스레드가 아니라 PRD에 적으세요.

베이스라인이 더 중요해집니다. 한 에이전트가 요구사항을 쓰고 다른 에이전트가 그로부터 이슈를 계획하면 드리프트가 쉽게 생깁니다. 한 번의 처리에서 요구사항이 약해져도 아무도 모릅니다. 승인 시점에 PRD를 동결하고 이후 버전을 그것과 비교하는 것이 이를 잡는 방법입니다. Atrix에서는 에이전트의 Develop 실행이 브리프로부터 요구사항 문서를 쓰고, 요구사항을 베이스라인으로 동결할 수 있으며, 요구사항 감사가 그 베이스라인 대비 커버리지와 드리프트를 보여줍니다. 코드를 스캔하는 것이 아니라 레코드를 비교합니다.

스펙이 테스트 계획이 됩니다. 스펙이 상태와 기대 동작의 표라면 코딩 에이전트는 각 행을 테스트로 바꿀 수 있습니다. 단락으로 쓴 의도라면 불가능합니다.

RFC는 사람의 몫으로 남습니다. RFC의 결정은 조직이 감수할 트레이드오프에 대한 판단입니다. 에이전트는 대안 섹션을 잘 초안하고 댓글을 요약할 수 있습니다. 결정하는 쪽이 되어서는 안 됩니다.

세 문서를 한곳에 두기

문서가 어디에 있는지는 전보다 중요합니다. 에이전트는 닿을 수 있는 것만 읽을 수 있기 때문입니다. PRD는 Google 문서에, 스펙은 위키에, RFC는 풀 리퀘스트 설명에 있다면 권한 세 개, 검색창 세 개, 서로 간의 링크는 없는 셈입니다.

우리에게 효과가 있었던 방식은 프로덕트별 페이지 트리입니다. PRD가 최상위 페이지, 각 스펙은 해당 요구사항에서 링크된 하위 페이지, RFC는 워크스페이스 수준 폴더에 제목에 상태를 달아 둡니다. 로드맵 항목은 요구사항으로 되돌아 링크되므로, 항목이 밀리면 그것이 담당하는 요구사항까지 한 번의 클릭입니다. 프로덕트 로드맵 템플릿은 그 링크 위에 만들어져 있습니다.

Atrix는 이를 얻는 한 가지 방법으로, 프로젝트 아래 중첩되는 페이지, 실시간 공동 편집, 버전 기록, Markdown 내보내기를 제공하고, MCP 서버를 통해 외부 어시스턴트도 같은 페이지를 읽을 수 있습니다. Notion과 Confluence도 중첩과 기록을 지원합니다. 중요한 속성은 세 문서 모두 같은 도구에서 같은 권한으로 접근할 수 있다는 것입니다.

FAQ

PRD와 스펙의 차이는 무엇인가요?

PRD는 인수 기준이 붙은 번호 요구사항 수준에서 무엇을 왜 만드는지 말합니다. 스펙은 그 요구사항 하나가 각 상태에서 어떻게 동작하는지를 만들고 테스트할 수 있을 만큼 정확히 말합니다. PRD는 승인된 뒤 동결되고, 스펙은 기능이 출시될 때까지 바뀝니다.

RFC는 설계 문서와 같은 것인가요?

조금 다릅니다. 설계 문서는 무언가를 어떻게 만들지 설명하고, RFC는 변경을 해야 하는지 묻고 결정 전에 반론을 초대합니다. 많은 설계 문서가 RFC식 "검토한 대안" 섹션을 포함하고 두 이름을 섞어 쓰는 팀도 있지만, RFC를 정의하는 것은 의견 수렴 기간과 마지막의 결정입니다.

스타트업에 PRD가 필요한가요?

첫 버전을 만드는 두 명 팀은 한 쪽짜리 문제 기술과 이슈 목록으로 충분합니다. 고객, 투자자, 신규 입사자가 무엇이 합의됐는지 알아야 하는 첫 순간부터, 번호 붙은 요구사항이 있는 PRD는 제값을 합니다. 계기는 회사 규모가 아니라 두 사람 이상의 합의가 필요해지는 것입니다.

스펙은 PM이 쓰나요, 엔지니어가 쓰나요?

보통 작업에 가장 가까운 엔지니어나 디자이너가 쓰고 PM이 검토합니다. PRD는 PM의 문서이고 스펙은 만드는 사람의 문서입니다. PM이 없는 팀에서는 창업자가 PRD를 쓰고 기능을 만드는 사람이 스펙을 씁니다.

PRD에 기술적 세부 사항을 넣어야 하나요?

아니요. 아키텍처, 스키마, API 형태는 스펙이나 기술 설계에 속합니다. 구현을 지정하는 PRD는 만드는 사람이 내려야 할 결정을 고정하고, 엔지니어가 다른 접근을 택하는 순간 낡은 문서가 됩니다.

AI 에이전트가 이 문서들을 쓸 수 있나요?

셋 다 초안을 쓸 수 있고, 명확한 브리프와 기존 페이지를 컨텍스트로 주면 PRD와 스펙은 잘 씁니다. 사람의 몫으로 남겨야 할 부분은 PRD의 문제 기술, RFC의 결정, 그리고 요구사항을 베이스라인으로 바꾸는 승인입니다.

다음 단계

프로덕트를 시작한다면 PRD부터 쓰세요. PRD 템플릿은 위 섹션을 순서대로 담은 Markdown 페이지입니다. 요구사항이 생기면 프로덕트 로드맵 템플릿이 각 로드맵 항목을 담당 요구사항에 연결하며, 이것이 나중에 감사가 의존하는 링크입니다. 에이전트가 있는 워크스페이스에서 이 문서들이 어떻게 작동하는지는 문서와 화이트보드와 AI 에이전트 페이지를 참고하세요.

PRD, 스펙, RFC: 세 가지 문서, 세 종류의 독자, 그리고 무엇을 먼저 쓸 것인가