RFC
Request for Comments
산출물
아직 정해지지 않은 제안을 글로 공개하고 정해진 기간 동안 의견을 받아 결론을 내는 문서입니다.
등장 배경
큰 결정을 회의로만 내리던 시절에는 결정의 품질이 그 자리의 분위기에 달려 있었습니다. 한 시간 안에 반대 의견을 꺼내려면 즉석에서 말을 만들어야 하고, 먼저 말한 사람의 안이 기준이 되어 버립니다.
페이지덱에서 데이터 저장 구조를 바꿀지 논의한 자리가 그랬습니다. 규원이 한 방향으로 기울었다고 말한 뒤로는 반대가 나오지 않았고 그날 결론이 났습니다. 3주 뒤 태오가 지현에게 그때 말하지 못한 것이 있다고 했습니다. 그 구조로 가면 기존 데이터를 옮기는 데만 한 달이 걸린다는 이야기였습니다. 회의에서 침묵한 이유는 반대할 생각이 없어서가 아니라, 그 자리에서 근거를 정리할 시간이 없었기 때문입니다.
여기에 한 가지가 더 겹쳤습니다. 같은 시간에 붙어 있지 않아도 일이 진행되는 비동기 커뮤니케이션이 기본이 된 팀에서는 사람을 한자리에 모으는 일 자체가 결정을 일주일 미루는 일이 됩니다.
그래서 순서를 뒤집었습니다. 제안을 먼저 글로 적어 공개하고, 반박은 각자 시간을 들여 글로 달게 하고, 기한이 지나면 제안자가 결론을 적어 닫습니다. 글에 달린 반박은 누가 썼든 같은 무게로 읽힙니다.
구성 항목
칸은 여섯 개이고, 순서에도 뜻이 있어 배경이 제안보다 먼저 옵니다.
- 제목과 한 문장 요약. 제목만 보고 무엇을 정하려는 글인지 알 수 있어야 합니다. "저장 구조 변경" 이 아니라 "문서 본문을 문단 단위로 쪼개 저장하는 방식으로 옮기는 안" 처럼 씁니다.
- 배경과 문제. 왜 이 논의가 지금 필요한지 적습니다. 현재 구조에서 문서 하나를 열 때 평균 1.8초가 걸리고, 긴 문서에서는 여러 명이 동시에 고칠 때 마지막 저장이 앞의 것을 덮어쓴다는 식으로 숫자와 장면을 함께 넣습니다.
- 제안. 무엇을 하겠다는 것인지 한 방향으로 적습니다. 여러 안을 나란히 늘어놓고 골라 달라고 하면 논의가 흩어집니다. 제안자가 한 안을 밀고 나머지는 다음 칸으로 보냅니다.
- 검토한 대안과 버린 이유. 이 칸이 이 문서의 값을 대부분 짊어집니다. 읽는 사람이 가장 먼저 떠올릴 대안 두세 개가 여기 이미 적혀 있고 왜 접었는지가 붙어 있으면, 댓글이 같은 이야기를 반복하지 않고 그다음으로 넘어갑니다.
- 따라오는 영향. 이 결정을 실행하면 무엇이 바뀌고 누가 일을 더 해야 하는지, 되돌리는 데 무엇이 드는지 적습니다. 반년 뒤에 되돌리려면 이미 쌓인 데이터를 다시 옮겨야 한다는 문장이 있으면 읽는 쪽의 태도가 달라집니다.
- 기한과 결정권자. 언제까지 의견을 받고 누가 닫는지 적습니다. 이 칸이 없으면 문서는 열려 있는데 아무도 결론을 내지 않는 상태로 몇 주가 지나갑니다. 보통 1~2주를 두고, 닫는 사람은 한 명으로 적습니다.
닫을 때 칸 하나가 더 붙습니다. 결론과 그렇게 정한 이유입니다. 이 칸을 채우면 문서가 제안에서 기록으로 바뀝니다. 논의 중에 나온 반박 중 받아들인 것과 접은 것을 한 줄씩 남기면, 반년 뒤에 같은 주제가 다시 올라왔을 때 어디까지 이야기했는지를 찾아 읽을 수 있습니다.
작성자와 독자
쓰는 사람은 그 결정이 필요하다고 느낀 사람입니다. 직급이나 역할로 정하지 않습니다. 저장 구조 제안은 태오가, 요금제 구조 제안은 지현이, 계약 조건을 바꾸는 제안은 수아가 씁니다. 결정권자가 쓰지 않는 것이 이 형식의 성질입니다. 결정하는 사람이 제안까지 쓰면 반박을 달기가 다시 어려워집니다.
읽는 사람은 두 겹입니다.
- 지정된 검토자 — 그 결정에 영향을 받거나 영향을 줄 수 있는 이해관계자를 제안자가 직접 지목합니다. 셋에서 다섯 명 정도이고, 기한 안에 의견을 달라고 명시적으로 요청합니다. 지목하지 않으면 아무도 자기 일이라고 생각하지 않습니다.
- 그 밖의 전원 — 문서는 회사 전체가 볼 수 있게 열어 둡니다. 반년 뒤에 들어온 사람이 왜 이 구조인지 찾아 읽는 자리가 여기입니다.
기한을 지키는 방식도 형식의 일부입니다. 페이지덱은 기한 하루 전에 자동으로 알림을 보내고, 기한이 지나면 의견이 없어도 닫습니다. 닫히지 않는 문서가 쌓이면 사람들이 새 문서를 열지 않게 되기 때문입니다.
실무 용례
"이건 RFC로 열죠. 되돌리기 어려운 결정이라 회의에서 끝낼 일이 아닙니다."
영향이 커서 글로 의견을 받고 기록을 남기자는 제안입니다.
"대안 칸에 그 방법이 왜 없어요? 그거부터 답해 주세요."
제안자가 검토했어야 하는 선택지가 빠졌다는 지적입니다.
"금요일에 닫습니다. 반대 있으면 그때까지 댓글로 주세요."
기한 뒤에는 의견이 없는 것으로 보고 결론을 적겠다는 뜻입니다.
페이지덱은 되돌리기 어려운 결정에만 이 형식을 씁니다. 데이터베이스를 바꾸거나 요금제 구조를 손보는 일은 문서를 열고, 라이브러리 하나를 고르는 일은 짧은 기록 한 장으로 끝냅니다. 선을 긋지 않으면 사소한 결정에도 문서가 열리고 2주가 지나갑니다.
닫힌 뒤가 더 자주 쓰입니다. 반박이 함께 남아 있는 문서는 결론만 있는 기록보다 이 팀이 왜 이렇게 굴러가는지를 빨리 알려 줘서, 신입이 들어오면 지현이 최근 문서 몇 개를 건넵니다. 말보다 글로 먼저 정리해 공유하는 문서 우선 문화가 있는 팀에서 이 형식이 특히 잘 돕니다.
흔한 오해
전원이 동의해야 닫을 수 있다고 여기는 경우가 많습니다. 의견을 받는 문서이니 합의가 목표처럼 보입니다. 하지만 이 형식이 겨냥하는 것은 합의가 아니라 반대 의견이 기록되는 것입니다. 반박을 읽고도 원래 안으로 가기로 정했다면 그 사실과 이유를 결론 칸에 적으면 됩니다. 동의를 조건으로 걸면 사람들이 반대를 적지 않고 문서 밖에서 말하기 시작하고, 그러면 회의만 하던 때로 되돌아갑니다.
길게 써야 제대로 쓴 것이라고 보는 것도 흔합니다. 여섯 칸을 갖춰 쓰라고 하면 열 장을 쓰게 되고, 열 장이 되면 지정된 검토자조차 끝까지 읽지 않습니다. 실제로 값을 하는 분량은 두세 장입니다. 배경과 대안 칸에 숫자와 장면이 들어 있으면 짧아도 반박할 거리가 분명하고, 그 반박이 붙는 순간 문서는 제 일을 시작합니다.
자주 헷갈리는 용어
| 용어 | 언제 쓰는가 | RFC와의 차이 |
|---|---|---|
| 아키텍처 의사결정 기록 | 결정이 끝난 뒤 | 정해진 것을 짧게 남깁니다. RFC는 정해지기 전에 열어 의견을 받고, 닫힐 때 그 기록으로 넘어갑니다 |
같이 보면 좋은 페이지
- 의사결정 기록
이 문서가 어느 갈래의 어느 시점에 놓이는지 봅니다
- 아키텍처 의사결정 기록
같은 결정의 뒤쪽을 맡는 형식입니다
- 문서 우선
이 형식이 도는 전제가 되는 일하는 방식입니다
마지막 업데이트 2026-09-16