RFC 작성법: 여러 팀 합의를 끌어내는 제안서/스펙 문서 구조

PR/FAQ가 “고객 가치가 진짜인지”를 먼저 증명하는 문서라면, RFC(Request for Comments)는 그 다음 단계입니다.

즉, 여러 팀이 같은 그림으로 구현·운영·출시까지 가게 만드는 합의 문서입니다.

 

PM 실무에서 RFC가 필요한 순간은 명확합니다.

 

• 팀이 2개 이상 얽히고(플랫폼/개발/데이터/CS/마케팅)
• 인터페이스·정책·데이터 정의 같은 “경계면”에서 충돌이 나고
• 구두 합의가 번복되거나, 책임이 흐려지거나, 범위가 폭발할 때

 

RFC는 이 문제를 문서로 잠가서 실행을 가능하게 합니다.

---

 

RFC란 무엇인가

RFC는 원래 “의견을 수렴하기 위한 초안 문서”라는 의미가 강합니다. 제품 조직에서는 조금 다르게 씁니다.

 

• 제안(Proposal) + 스펙(Spec) + 의사결정(Decision) + 운영/출시 계획을 한 문서에 담아
• 리뷰 코멘트를 받아 합의하고
• 최종 버전이 “이 프로젝트의 기준선(Source of Truth)”이 되는 문서

 

즉, “제안서”로 시작하지만, 끝나면 “합의된 스펙”이 됩니다.

---

 

언제 RFC를 써야 하나

상황	RFC를 쓰는 이유	대안 문서가 실패하는 이유
여러 팀이 같이 개발	인터페이스/의존성/오너십 합의	회의록은 스펙이 아니다
정책/정산/권한처럼 민감한 변경	변경의 파장과 예외를 선제 처리	PRD만으로는 디테일 충돌
데이터 정의/이벤트 트래킹	지표 정의가 바뀌면 모두가 깨짐	“각자 이해”가 리스크
단계적 론칭/마이그레이션	롤아웃·롤백을 합의	일정표만으로는 운영 불가

 

---

 

RFC 문서의 핵심 원칙 5가지

1. 논쟁을 ‘코멘트’로 옮겨라
   말로 싸우지 말고 문서에 코멘트가 남게 만들어야 합니다.
2. 결정 포인트를 명확히 표시하라
   “정보 공유”와 “승인/결정 요청”을 섞으면 리뷰가 산으로 갑니다.
3. 경계면을 먼저 정의하라
   API/정책/데이터/권한 같은 경계면이 가장 큰 리스크입니다.
4. 대안을 적고, 왜 버렸는지 남겨라
   대안이 없는 제안은 독단으로 보이고, 나중에 재논쟁이 됩니다.
5. 출시 이후를 포함하라
   RFC는 개발 문서가 아니라 제품 문서입니다. 운영/모니터링/롤백이 포함돼야 합니다.

---

 

PM용 RFC 표준 구조

아래는 제품 조직에서 가장 실용적인 RFC 목차입니다. (필요한 경우만 포함)

섹션	목적	반드시 답해야 할 질문
1) Summary	1분 이해	“무엇을 바꾸며, 왜 지금인가?”
2) Problem & Goals	문제/성공 정의	“성공은 무엇이고, 무엇은 하지 않나(Non-goals)?”
3) Proposal	제안안	“정확히 무엇을, 어디에, 어떻게 적용하나?”
4) Scope	범위 고정	“포함/제외가 무엇인가?”
5) Spec / Details	스펙 합의	“API/화면/정책/데이터 정의는 무엇인가?”
6) Alternatives	비교/기각 사유	“다른 옵션은 왜 안 되나?”
7) Risks & Mitigations	리스크 관리	“무엇이 깨지고, 어떻게 막나?”
8) Rollout / Migration	출시 계획	“단계적 론칭/마이그레이션/롤백은?”
9) Metrics & Monitoring	운영 기준	“성공/실패를 무엇으로 판단하나?”
10) Ownership	책임 고정	“오너는 누구고, 의존성은 무엇인가?”
11) Open Questions	미결 이슈	“아직 확정 못한 질문은 무엇인가?”
12) Appendix	근거 격리	“표/로그/원자료/참고 링크”

 

---

 

RFC에서 가장 많이 터지는 충돌 지점 6개

RFC를 “합의 문서”로 만들려면, 아래 6개는 표로 박아두는 게 안전합니다.

충돌 지점	자주 나오는 질문	문서에 박아야 할 것
API/인터페이스	“요청/응답 스키마는?”	endpoint, 필드 정의, 에러코드
정책/예외	“이 케이스는 어떻게 처리?”	예외 케이스 리스트, 우선순위
권한/보안	“누가 볼 수 있고, 기록은?”	권한 매트릭스, 로그 정책
데이터 정의	“전환/매출 계산은?”	이벤트/지표 정의, 샘플
운영/CS	“장애/문의는 어디로?”	운영 플로우, CS 시나리오
롤아웃/롤백	“문제 생기면 되돌리나?”	Feature flag, 단계/조건/절차

 

---

 

필수 표 1: 스펙 합의 표(경계면 고정)

항목	정의	소유팀	변경 영향	비고
API
정책
데이터
권한/보안

이 표 하나만 있어도 “각자 이해”가 크게 줄어듭니다.

 

---

 

필수 표 2: 롤아웃 계획 표(출시를 실행으로 바꾸기)

단계	대상/범위	전환 조건	모니터링 지표	롤백 조건	오너
0	내부 테스트	테스트 통과	에러율/로그	치명 버그
1	1%	지표 안정	전환/에러	에러율 X%↑
2	10%	안정 24h	CS/전환	CS 급증
3	100%	안정 72h	전체 KPI	핵심 KPI 하락

PM 관점에서 이 표가 없으면, 출시 당일에 “감으로” 롤아웃하게 됩니다.

 

---

 

RFC 작성 프로세스: 코멘트 기반 합의 운영

RFC는 “문서 작성”이 아니라 “리뷰 운영”이 핵심입니다.

단계	목표	운영 팁
1	초안 공개	70% 수준에서 빨리 공유(완벽주의 금지)
2	코멘트 수렴	회의 대신 코멘트로 논쟁 이동
3	결정 포인트 정리	의견을 묶어 “결정해야 할 것”만 남김
4	합의 반영(리라이트)	반영/미반영을 명시(왜?)
5	최종 승인	“이 문서가 기준선”임을 선언
6	변경 관리	변경 시 RFC 업데이트/버전 관리

 

---

 

RFC가 망하는 패턴 3가지

실패 패턴	왜 문제인가	처방
PRD를 그대로 복사	스펙 합의가 아니라 방향 설명	경계면(API/정책/데이터/권한) 중심으로 재구성
Open Questions가 숨겨짐	나중에 일정 폭탄	미결 질문을 표로 드러내고 오너/기한 지정
롤아웃/롤백이 없다	출시가 운영 리스크로 전환	단계적 론칭 표 + 롤백 조건 필수

 

---

 

제출 전 체크리스트

체크 항목	통과 기준
결정 요청이 분명한가	“승인/결정이 필요한 항목”이 명시
Non-goals가 있는가	“이번엔 안 한다”가 써 있음
경계면 스펙이 고정됐는가	API/정책/데이터/권한 표가 있음
대안이 있는가	Alternatives + 기각 사유가 있음
운영이 포함됐는가	모니터링/CS/온콜/로그
롤아웃/롤백이 있는가	단계/조건/지표/오너가 있음
오너십이 개인/팀 단위로 고정됐는가	책임과 의존성이 표로 보임

 

---

 

결론: RFC는 “회의를 줄이는 문서”가 아니라 “재논쟁을 없애는 문서”다

RFC의 목적은 문서를 예쁘게 만드는 게 아닙니다.

합의된 스펙을 기준선으로 만들고, 변경을 통제하며, 출시와 운영까지 예측 가능하게 만드는 것입니다.

 

PR/FAQ로 “가치”를 증명했다면, RFC로 “실행 가능한 합의”를 고정하세요.

---

 

다음 편 예고: Postmortem / RCA(블레임리스 회고 문서)

다음 글은 Postmortem / RCA(블레임리스 회고 문서)입니다.

RFC가 “출시 전에 합의와 리스크를 잠그는 문서”라면, Postmortem/RCA는 “출시 후 사건을 학습으로 전환해 재발 방지를 잠그는 문서”입니다.