설계안 트레이드오프 따지는 프롬프트

결론

현재 조건에서는 A) PostgreSQL 단일 인스턴스 + 읽기 전용 replica 1대를 추천합니다.

단, A만으로는 “결제 완료 데이터 절대 유실”을 보장하지 못합니다. 다음을 추가해야 합니다.

• 관리형 PostgreSQL 또는 다중 AZ 장애 대응
• WAL 아카이빙과 PITR(Point-in-Time Recovery)
• 결제 완료 이벤트의 멱등성 키
• 결제사 결과와 내부 주문 상태를 연결하는 outbox/reconciliation 처리
• 재고 차감 시 트랜잭션·행 잠금 또는 원자적 조건부 업데이트

이는 B나 C보다 훨씬 작은 추가 복잡도입니다.

평가 기준과 가중치

현재 월간 방문자 50만 명, 백엔드 3명, 6개월 내 출시, 월 200만 원 이하라는 조건에 맞춰 가중치를 부여했습니다.

기준	가중치	이유
재고 정합성·오버셀 방지	30	절대 조건
결제 데이터 내구성·복구 가능성	25	절대 조건
현재 규모에서의 충분한 성능	10	10배 미래가 아니라 현재 출시 규모 기준
운영 복잡도와 3명 팀의 대응 가능성	15	장애 대응 인력이 제한적
6개월 출시 가능성	10	일정 제약이 명확함
인프라 비용	5	월 200만 원 제한
향후 확장성	5	중요하지만 현재 절대 조건보다 낮음

점수는 5점 만점이며, 높은 점수가 좋습니다.

비교

기준	A. PostgreSQL + replica	B. PostgreSQL + Redis	C. 매장 ID 샤딩
재고 정합성	5	4	3
결제 데이터 내구성	5	4	3
현재 규모 성능	5	5	4
운영 복잡도	4	3	1
6개월 출시 가능성	5	4	2
비용	5	4	2
향후 확장성	3	4	5
가중 총점	4.65	4.00	2.90

A) PostgreSQL 단일 인스턴스 + 읽기 전용 replica

현재 규모에는 가장 균형이 좋습니다.

재고는 primary에서 트랜잭션으로 처리하면 됩니다.

UPDATE inventory
SET quantity = quantity - :requested
WHERE store_id = :store_id
  AND product_id = :product_id
  AND quantity >= :requested;

영향받은 행이 1개일 때만 주문을 진행하면 동시 주문에서도 오버셀을 막을 수 있습니다. 재고 차감과 주문 상태 변경은 같은 트랜잭션에 두어야 합니다.

다만 replica는 읽기 확장과 장애 대비에는 도움이 되지만 다음을 해결하지는 않습니다.

• primary 장애 시 자동 무중단 전환
• 결제 데이터의 백업
• replica 지연으로 인한 오래된 재고 조회
• 애플리케이션이 replica에 잘못 쓰는 문제

운영 시 주의할 점

• 재고·주문·결제 상태 조회는 primary 기준으로 읽기
• 상품 검색·매장 목록 같은 eventual consistency 허용 조회만 replica 사용
• replica는 비동기 복제일 가능성이 높으므로 “replica에 있으니 안전하다”고 간주하지 않기
• WAL/PITR와 복구 리허설을 별도로 구성하기

일방향 문은 상대적으로 적습니다. replica를 제거하거나 Redis를 나중에 추가하는 것은 비교적 쉽습니다. 다만 처음부터 데이터 접근 계층을 잘못 설계하면 primary/replica 라우팅 수정 비용이 생깁니다. 이는 어렵지만 되돌릴 수 없는 결정은 아닙니다.

B) PostgreSQL + Redis 캐시 레이어

Redis는 읽기 성능과 DB 부하를 줄이는 데 유용하지만, 현재 핵심 문제를 직접 해결하지는 않습니다.

특히 Redis를 재고의 진실 원장(source of truth)으로 사용하면 안 됩니다. Redis 장애, 만료, 복제 지연, 재시작, 캐시 갱신 순서 문제로 정합성이 깨질 수 있습니다.

안전한 구조는 다음과 같습니다.

• 재고 차감: PostgreSQL 트랜잭션
• Redis: 상품 정보, 매장 목록, 읽기 빈도가 높은 비정합성 허용 데이터
• 재고 캐시: 사용하더라도 표시용이며 주문 가능 여부의 최종 판단은 PostgreSQL

현재 규모에서의 문제

월간 방문자 50만 명이라는 수치만으로 Redis가 필수라고 보기는 어렵습니다. 실제로 중요한 것은 순간 요청률, 읽기/쓰기 비율, 검색 패턴, DB 쿼리 비용입니다. 현재 규모에서는 인덱스와 쿼리 최적화만으로 충분할 가능성이 큽니다.

Redis를 도입하면 다음이 추가됩니다.

• 캐시 무효화 순서
• stale 데이터 허용 범위
• Redis 장애 시 우회 경로
• cache stampede와 hot key
• 운영·모니터링·백업 정책

Redis 자체는 제거할 수 있지만, 애플리케이션 곳곳에 캐시 의존성이 퍼지면 제거 비용이 커집니다. 특히 캐시를 재고 판정에 사용하기 시작하면 사실상 위험한 일방향 문이 됩니다.

C) PostgreSQL 샤딩 — 매장 ID 기준

샤딩은 현재 요구사항에 의해 강제되지 않습니다.

월간 방문자 50만 명, 백엔드 3명, 6개월 출시라는 조건에서는 샤딩의 확장성보다 다음 비용이 훨씬 큽니다.

• 매장 간 쿼리와 집계
• 사용자·주문·결제 데이터의 교차 매장 조회
• 트랜잭션 경계 설계
• 샤드 재배치
• 장애 시 어느 샤드가 문제인지 확인
• 마이그레이션과 백필
• 커넥션 풀·모니터링·백업 관리

매장 ID가 모든 주문·재고·결제 작업에 완벽한 파티션 키라는 보장도 필요합니다. 사용자 주문, 프로모션, 정산, 전사 매출 집계처럼 여러 매장을 넘나드는 기능이 생기면 샤딩의 이점이 빠르게 줄어듭니다.

가장 큰 일방향 문은 매장 ID를 샤딩 경계로 채택하는 것입니다. 나중에 샤드 키를 바꾸거나 데이터를 재분배할 수는 있지만, 대규모 데이터 이동과 애플리케이션 수정이 필요합니다. 어렵고 비싸며, 출시 후에는 장애 위험도 동반합니다.

각 선택이 지금은 잘 보이지 않게 어렵게 만드는 것

A가 어렵게 만드는 것

• 대규모 단일 테이블의 장기적인 수평 확장
• 특정 매장이나 상품이 매우 뜨거워질 때의 부하 격리
• primary 장애 중 완전한 무중단 운영
• replica 지연을 고려한 읽기 일관성 설계

하지만 대부분은 현재 규모에서 어렵게 만들 뿐 불가능하게 만들지는 않습니다.

B가 어렵게 만드는 것

• 데이터가 언제 최신인지 판단하는 것
• 업데이트 후 어느 캐시 키를 삭제해야 하는지 보장하는 것
• 장애 시 DB fallback을 일관되게 처리하는 것
• 테스트에서 캐시 적중·실패·만료·동시 갱신 상황을 재현하는 것
• 캐시가 성능 최적화인지, 사실상 데이터 저장소인지 경계를 유지하는 것

C가 어렵게 만드는 것

• 여러 매장을 대상으로 하는 조회·정산·통계
• 주문·결제·재고를 하나의 원자적 작업으로 처리하는 것
• 데이터 이동과 스키마 변경
• 장애 원인 파악
• 백업 복구와 복구 시점 일관성
• 새 기능을 만들 때 어느 샤드에 데이터를 둘지 결정하는 것

이 중 일부는 결국 불가능하다기보다, 기능마다 분산 시스템 문제를 다시 풀어야 하는 상태가 됩니다.

3am에 무엇이 깨지고 누가 고칠 수 있는가

장애	A	B	C
DB primary 장애	replica 승격 또는 복구 필요. 비교적 명확함	Redis까지 포함해 캐시·DB 경로 확인 필요	해당 샤드와 라우터까지 확인 필요
replica 지연	읽기를 primary로 우회하면 됨	캐시가 오래된 값을 더 오래 보여줄 수 있음	샤드별 지연과 영향 범위 확인 필요
Redis 장애	해당 없음	fallback, 캐시 재가열, hot key 문제 대응	해당 없음
잘못된 결제 상태	DB 로그와 결제사 대사로 추적	캐시가 상태를 가리면 더 혼란스러움	어느 샤드·어느 트랜잭션인지 추적 필요
재고 오버셀 위험	트랜잭션 설계로 통제 가능	캐시를 잘못 사용하면 위험 증가	분산 트랜잭션 설계가 필요
복구 훈련	한 DB 복구 절차	DB와 Redis 복구 절차	샤드별 복구 및 일관성 검증

백엔드 개발자 3명이라면 A의 장애는 담당자를 정해 런북으로 대응할 수 있습니다. B는 추가 운영 요소가 하나 더 생기고, C는 팀이 데이터베이스 운영 전문성을 별도로 확보해야 합니다.

특히 결제 데이터는 세 선택지 모두 자동으로 보호되지 않습니다. 결제사에서 성공했지만 내부 DB 기록이 실패하는 경우를 대비해 다음이 필요합니다.

1. 결제 요청에 멱등성 키 사용
2. 결제 승인 결과를 내구성 있게 기록
3. 주문 상태 변경과 이벤트 발행을 outbox로 연결
4. 주기적인 결제사 대사 작업
5. 미확정 주문을 재처리하는 운영 도구

추천이 뒤집히는 조건

B로 뒤집히는 조건

실측 결과 다음이 동시에 나타날 때입니다.

• PostgreSQL이 인덱스·쿼리 최적화 후에도 목표 피크 트래픽을 감당하지 못함
• 읽기 트래픽이 병목의 대부분임
• 캐시 가능한 조회가 전체 요청의 큰 비중을 차지함
• 캐시 장애 시 DB fallback을 설계·운영할 사람이 있음

그때도 Redis는 재고 정합성 계층이 아니라 읽기 캐시로만 추가해야 합니다.

C로 뒤집히는 조건

다음과 같은 데이터베이스 병목이 실제로 측정되어야 합니다.

• 단일 primary 수직 확장과 읽기 replica로도 지속적으로 처리 불가능
• 트래픽 또는 데이터 규모가 계속 증가해 수직 확장의 비용·한계가 명확함
• 매장 단위 데이터 독립성이 강함
• 교차 매장 트랜잭션과 집계가 충분히 적음
• 샤딩 운영을 전담하거나 경험 있는 인력을 확보함

현재 정보만으로는 이 조건이 충족되지 않았습니다.

가장 싼 실험

가장 큰 불확실성은 “현재 및 출시 시점의 피크 트래픽에서 PostgreSQL 단일 primary가 실제로 병목이 되는가”입니다.

따라서 A 구조의 축소된 부하 테스트를 먼저 하십시오.

1. 실제 스키마와 대표 쿼리를 사용합니다.
2. 재고 차감 동시 주문 테스트를 포함합니다.
3. 현재 피크의 5~10배 요청률을 단계적으로 발생시킵니다.
4. primary CPU, I/O, lock wait, connection 수, p95/p99 지연을 측정합니다.
5. 장애 중복 결제와 재시도, 결제 결과 유실 복구 테스트도 포함합니다.

이 실험은 Redis나 샤딩을 도입하는 것보다 훨씬 저렴하며, 다음 두 질문을 동시에 답합니다.

• A가 현재 출시 규모에서 충분한가?
• 재고·결제 요구사항을 만족하면서 어느 지점에서 실제 병목이 생기는가?

실험 결과 A가 목표 피크의 5~10배를 안정적으로 처리하면 A로 출시하는 것이 합리적입니다. 그렇지 않고 읽기 쿼리가 병목이면 B를 추가하고, 쓰기·데이터 규모 자체가 병목이면 그때 C를 재검토하는 순서가 적절합니다.