gRPC vs Outbox 패턴

결제(Payment)처럼 실시간성과 즉각적인 피드백이 생명인 서비스에서는 Outbox 패턴보다 gRPC가 더 나은 선택이 아닌지 의문이 듭니다..

결론부터 말씀드리면, "둘 다 쓰지만, 용도가 다릅니다." 실무에서는 보통 gRPC(동기)로 먼저 확인하고, Outbox(비동기)로 뒤처리를 합니다. 왜 그런지 결제 시나리오로 비교해 드릴게요. 💳

 

1. gRPC vs Outbox 패턴 (결제 상황 비교)

비교 항목	gRPC (Synchronous)	Transactional Outbox (Asynchronous)
통신 방식	즉각적인 응답 (Request-Response)	이벤트 발행 후 나중에 처리 (Eventual Consistency)
데이터 확정	호출이 성공해야 결제가 완료됨	주문은 일단 성공, 결제/재고는 잠시 후 확정
장애 전파	결제 서비스가 죽으면 주문도 실패함	결제 서비스가 죽어도 주문은 받아둘 수 있음
주요 용도	"지금 당장" 잔액 확인, 카드 인증	"결제 완료 후" 포인트 적립, 배송 지시, 알림톡 발송

 

2. 왜 결제에서 gRPC'만' 쓰면 위험할까? (결합도 문제)

결제 과정에서 gRPC만 사용해 모든 서비스를 묶어버리면 '연쇄 장애(Cascading Failure)' 위험이 커집니다.

• 시나리오: 주문 서비스 -> (gRPC) -> 결제 서비스 -> (gRPC) -> 재고 서비스
• 만약 재고 서비스가 점검 중이거나 응답이 늦어지면, 결제 서비스도 대기하게 되고, 결국 주문 서비스까지 타임아웃이 발생해 고객은 결제 버튼을 눌러도 무한 로딩을 보게 됩니다. 😱

 

3. 실무급 '쿠팡 스타일' 하이브리드 설계 🏗️

실제 대규모 시스템에서는 두 방식을 섞어서 최적의 사용자 경험을 만듭니다.

① [gRPC] "돈 나가는 건 즉시!" (강한 정합성)

고객이 결제 버튼을 누르는 순간, 최소한의 필수 작업은 gRPC로 처리합니다.

• 주문 -> 결제 서비스: "이 카드 유효해? 잔액 있어?" (승인 요청)
• 주문 -> 재고 서비스: "이 물건 지금 딱 하나 남았는데 선점 가능해?" (Soft Lock)
• 결과: 사용자는 1~2초 내에 "결제 완료" 화면을 봅니다.

② [Outbox + Kafka] "그 외 나머지는 천천히" (결과적 정합성)

결제 승인이 완료된 후, 굳이 고객이 기다릴 필요 없는 작업들은 Outbox 패턴으로 넘깁니다.

• 주문 서비스: DB에 결제 완료 기록 + Outbox에 'OrderCompleted' 이벤트 저장.
• Debezium/Kafka: 이 이벤트를 긁어서 전달.
• 다른 서비스들:
  • 포인트 서비스: "오, 결제됐네? 500원 적립해줄게." 💰
  • 알림 서비스: "카톡! 결제가 완료되었습니다." 📱
  • 데이터 분석: "방금 30대 남성이 노트북을 샀어." 📊

 

4. 결제 데이터의 '원천'은 어디인가?

사용자가 gRPC를 선호하는 이유는 "실패하면 바로 에러를 띄울 수 있어서"입니다. 하지만 결제 서비스 자체 내부적으로는 Transactional Outbox가 반드시 필요합니다.

예를 들어, 외부 PG사(NICE, Toss 등)와 통신해서 결제는 성공했는데, 우리 쪽 DB에 기록하다가 서버가 꺼졌다면?

• PG사에는 돈이 나갔는데 우리 DB에는 기록이 없는 끔찍한 상황이 됩니다. 💸
• 이럴 때 Outbox 패턴을 통해 "결제 시도 로그"를 먼저 남기고 작업을 시작해야, 나중에 서버가 살아났을 때 누락된 결제 건을 대조(Reconciliation)해서 복구할 수 있습니다.

 

💡 시니어 개발자의 조언

"결제는 gRPC로 빠르게 승인하고, Outbox로 확실하게 기록하세요."

• gRPC: 사용자 대기 시간을 줄이는 UX용 도구
• Outbox: 시스템 간 데이터가 꼬이지 않게 만드는 안전장치(Data Integrity)