RFC 템플릿 — 설계 결정 을 한 장 에 담는 법

좋은 설계 결정 은 이유 없이 가파르게 난다. 최종 결정 을 보면 “왜 이거?” 라는 질문 이 따라붙는데, 그 이유 를 설명 하려면 결정 과정 전체 를 다시 풀어야 한다. RFC(Request For Comments) 는 이 과정 을 한 장 으로 압축 해서, 결정 을 재현 가능 하게 하는 템플릿 이다.

RFC 템플릿 한 장에 들어가야 합니다 — CONTEXT · GOAL · NON-GOAL · OPTIONS · TRADE-OFFS · DECISION · RISKS · ROLLOUT

RFC 의 힘 은 간단 하다. 8개 섹션 각각 이 하나 의 질문 에 답 한다. 그리고 그 8개 질문 의 답 을 읽으면, 당신 은 설계자 의 머릿속 을 완벽 하게 재현 할 수 있다. 6개월 뒤 신입 이 “왜 이렇게 했어요?” 라고 물어도, RFC 를 건네면 끝 이다.

1. CONTEXT — 왜 지금?

“배경” 이 결정 을 낳는다.

설계 는 진공 에서 나오지 않는다. 항상 지금 의 문제 가 있다. 비즈니스 변화, 기술 부채, 성능 문제, 팀 의 새로운 요구. CONTEXT 는 그 배경 을 일 선 에 드러낸다 — 왜 지금 이 결정 을 해야 하는가.

❌ "캐시를 도입합니다"
✅ "주문 조회 API 의 latency 가 p95 500ms 로 올라갔고, 
    조회 요청 의 70% 가 repeat request (같은 주문_id 를 3초 내 재조회).
    DB query 최적화 는 한계 (이미 인덱스 최적). 캐시 검토.

“지금 아니면 언제?” 를 글 한두 줄 에 답 해야 한다. 논리적 긴급성 이 없으면, 그 결정 은 미뤄도 된다.

2. GOAL — 뭘 달성하나?

GOAL 은 숫자로 답 한다. “빠르게 하자” 가 아니라 “p95 latency 를 200ms 이하로”.

❌ "사용자 경험을 개선합니다"
✅ "조회 API p95 latency: 500ms → 200ms,
    주문 목록 화면 로드: 3초 → 1초"

목표 가 명확 하면, 2주 뒤 “우리 가 성공 했나?” 를 객관적 으로 재는 표 가 생긴다. 감정 이 끼어들 여지 가 없다.

3. NON-GOAL — 뭐 말나?

가장 중요 한 섹션 이 이것 이다. 설계 를 정의 하는 건 하는 것 이 아니라 하지 않는 것 이기 때문 이다.

❌ NON-GOAL 없음 = 범위 크리프(scope creep) → 결국 3배 비용

✅ "이 RFC 는:
  · 실시간 동기화 를 목표 로 하지 않음 (조회 → 캐시 → 1시간 ttl)
  · 캐시 일관성(consistency) 보장 하지 않음 (최종일관성 허용)
  · 분산 캐시 시스템 도입 하지 않음 (Redis 하나, HA 별도)

NON-GOAL 이 사라지는 순간, 당신 은 완전히 다른 시스템 을 짓고 있다. 지도에 경계 를 긋지 않으면 끝 이 없다.

4. OPTIONS — 어떤 선택지?

설계 결정 은 비교 에서 나온다. 한 가지 방법 만 보면, 그게 최선 처럼 보인다. 최소 2가지(권장 3가지) 선택지 를 놓고 봐야 한다.

· Option A: Local 인메모리 캐시 (Caffeine)
  → 간단, 배포 단순, 하지만 node 간 일관성 문제

· Option B: Redis (중앙식 캐시)
  → 모든 node 에서 동일 데이터, 하지만 외부 의존성 추가

· Option C: Hybrid (local L1 + Redis L2)
  → 최고의 성능, 하지만 복잡도 극대, 일관성 관리 필요

각 옵션 이 무엇 이고, 왜 그렇게 작동 하는지 를 한두 줄 에 정리 해야 한다. 그리고 뒤에 나올 TRADE-OFFS 에서 비교 할 수 있게.

5. TRADE-OFFS — 뭘 포기하나?

TRADE-OFFS 는 각 옵션 을 축 단위 로 비교 한다. 각 축 은 상충 하는 특성 들이다:

Option	성능	복잡도	배포 속도	운영 비용
A (Caffeine)	⭐⭐⭐	⭐	⭐⭐⭐	⭐ (저)
B (Redis)	⭐⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐⭐ (중)
C (Hybrid)	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐⭐⭐ (고)

각 옵션 은 항상 something-for-something 이다. “최고” 는 없다 — 있는 건 “우리 가 지금 포기할 수 있는 것” 뿐 이다.

6. DECISION — 뭘 고르나?

“우리 는 Option B (Redis) 를 선택 합니다. 이유:”

왜 B 인가 — 중앙식 캐시 로 모든 node 가 동일 데이터 를 볼 수 있어, 일관성 이슈 가 단순해짐. 현재 팀 역량 (마이크로서비스 경험 3년) 에서 관리 가능.
왜 A 가 아닌가 — node 간 캐시 일관성 을 정기적 으로 재검증 해야 해서, 운영 복잡도 가 숨어 있음. 성능 이득 (로컬 접근 시간) 은 2ms 인데, 장애 포함 시 이득 이 음수 될 가능성.
왜 C 가 아닌가 — 지금 당장 필요한 건 “p95 200ms” 인데, 하이브리드 는 그 목표 를 6개월 뒤 달성. 그때까지 다른 병목(DB 쿼리) 이 생길 가능성 높음. “너무 많이 하는 것” 보다 “먼저 간단히”.

이 부분 이 의사결정 의 뼈대 다. 6개월 뒤 누군가 물으면 — “왜 Redis 했어?” — 이 문단 을 그대로 답 할 수 있다.

7. RISKS — 뭐가 우려되나?

선택지 마다 잠재된 위험 이 있다. RISKS 는 “이게 터질 수 있는 포인트” 를 명시 하고, “그러면 어떻게 할 건가?” 를 적는다.

· Risk: Redis 가 single point of failure → 장애 시 캐시 miss storm
  대응: Redis Sentinel (HA 구성), 캐시 miss 시 DB 타임아웃(2초), circuit breaker

· Risk: 캐시 일관성이 깨져서 outdated 데이터 노출 → 사용자 혼란
  대응: TTL 1시간, 중요 데이터(결제 상태) 는 캐시 제외, 모니터링

· Risk: 예상 외 Redis 데이터 증가 → 비용 초과
  대응: 월간 용량 리뷰, 메모리 임계값 80% 시 알림

“우려된다” 로 끝내지 않는다. 각 Risk 에 대응 방안 을 적어야, 팀 이 “이건 괜찮겠네” 라고 느낀다.

8. ROLLOUT — 어떻게 구나?

실행 계획 이다. 한 번 에 다 바꾸면 안 되니까:

Week 1-2: Redis 인프라 구축 (devops) + 캐시 코드 작성 (backend)
Week 3: 스테이징 환경 테스트 (부하 테스트, failover 시나리오)
Week 4: 프로덕션 카나리 배포 (트래픽 5% → 10% → 50% → 100%)
Week 5: 모니터링 (p95 latency, cache hit ratio, Redis CPU/메모리)

그리고 가장 중요:

Rollback plan: 5분 내 Redis 캐시 disable 가능? 네.
(캐시 미스 시 DB 직접 조회 로직 이 이미 있음)

Rollback 을 먼저 그려야, 앞으로 나아갈 수 있다.

왜 이 템플릿 이 강한가

팀 이 어디 서 튈 수 있는지 를 보여 준다. CONTEXT 가 부족 하면 설계자 만 안다 — 팀 은 이해 못 한다. TRADE-OFFS 가 없으면 “왜 이거?” 의 대답 이 없다. RISKS 와 ROLLOUT 이 없으면 배포 할 때 눈 을 감는다.

이 8개 를 한 장 에 담으면:

의사결정 자 는 결정 을 재현 할 수 있다 — 6개월 뒤 회고 할 때.
팀원 은 설계자 를 이해 한다 — 수동적 “따름” 이 아니라 적극적 “동의”.
신입 은 “우리 가 왜 이렇게 해?” 의 답 을 문서 에서 찾는다 — 사람 한테 묻지 않아도.

설계 결정 은 한 번 하는 게 아니라, 계속 설명 하는 것 이다. RFC 는 그 설명 을 한 장 으로 고쳐 둔다. 앞으로, 6개월 뒤로, 새 팀원 이 들어오는 날 까지.

관련: AX 시대 의 문제정의 능력 · 백엔드 설계 의 세 축