포스트

컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조

Tech Blog Review
게시 수정 작성자 August
좋아요 조회 15 분 읽는 시간
시리즈 빅테크 기술 블로그 리뷰 32편 중 24편 빅테크 기술 블로그 리뷰
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
  32. 32 Airbnb 「Avoiding double payments in a distributed payments system」 리뷰 — 네트워크와 DB 트랜잭션을 섞지 않는 세 단계, 재시도 가능 여부의 분류, 그리고 복제본을 읽으면 이중 결제가 나는 이유
엔지니어링 요약 컬리가 3PL로 확장하며 외부 파트너의 입고 예정 정보를 받기 시작했다. 레거시는 인터페이스 DB 저장과 Kafka 발행 사이의 원자성이 깨졌고, 수신부는 ...

Problem

컬리가 3PL로 확장하며 외부 파트너의 입고 예정 정보를 받기 시작했다. 레거시는 인터페이스 DB 저장과 Kafka 발행 사이의 원자성이 깨졌고, 수신부는 파트너·상품 정보가 아직 동기화되지 않아 실패했다. 발행부와 수신부가 서로를 의존하지 않고 각자 안전해야 했다.

Decision

원문의 두 축(Namastack Outbox 라이브러리로 발행부, Spring Kafka @RetryableTopic으로 수신부: 10분 간격 145회 약 24시간, SINGLE_TOPIC, DLT, 토픽별 알림 차등)을 옮기고, MDS SQS 파이프라인 글에 대조한 뒤 이후 쓴 parity-pay 5·8·9편(Outbox 구현, 결함 M의 DLT, 재시도 3.00배 증폭)을 덧붙였다.

Result

같은 Outbox인데 재시도 정책이 정반대다. 컬리는 수신부에서 24시간 동안 145회 재시도하고, 이후 만든 parity-pay는 외부 승인 재시도를 금지한다. 갈리는 이유는 실패의 원인이 시간이 지나면 해소되는가(파트너 정보가 곧 동기화됨)와 재시도가 상대에게 비용을 지우는가(느린 기관에 3배 부하)다. 원문이 답하지 않는 것은 '이론적 위험'이라고 적은 Outbox 중복 발행을 수신부가 실제로 어떻게 막는지, 그리고 순서를 보장하지 않는 재시도 토픽 위에서 같은 입고 건의 메시지 순서를 어떻게 다루는지다.

원문: 컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법 — 아웃박스 패턴과 재시도 토픽으로 외부 채널 입고 정보를 안전하게 동기화하기 — 컬리 기술 블로그, 이창섭(SCM프로덕트개발), 2026-01-12

나중에 쓴 parity-pay 5편과 같은 패턴, 같은 스택(Spring, Kafka), 같은 해에 쓴 글이다. 그런데 재시도에 대한 결론이 정반대다. 컬리는 24시간 동안 145회 재시도하고, parity-pay는 재시도를 금지한다. 둘 다 맞다고 생각하고, 왜 둘 다 맞는지가 이 리뷰다.

원문이 말하는 것

컬리는 직매입(1P) 중심에서 3PL로 확장하며 외부 파트너의 입고 예정 정보를 다양한 규격으로 받게 됐다. 레거시는 인터페이스 DB 적재와 Kafka 발행을 한 트랜잭션으로 묶었고, 실패 지점은 둘이었다. 발행부에서는 메시지는 발행됐는데 네트워크나 DB 서버 문제로 커밋이 실패하면 인터페이스 테이블과 메시지 사이의 원자성이 깨진다. 수신부에서는 파트너 정보나 상품 정보가 아직 등록·전송되지 않아 입고 예정 정보 생성이 실패했다.

발행부는 Outbox다. 인터페이스 테이블에 데이터를 적고, 같은 트랜잭션에 아웃박스 행을 적고, 폴러가 미발행을 읽어 발행하고, 성공하면 상태를 표시한다. 직접 만들지 않고 namastack-outbox-starter-jpa를 썼다. 폴링 2초, 배치 10 aggregate, 지수 백오프(2초 → 최대 60초). 원문은 발행 성공과 상태 표시 사이에 인스턴스가 죽으면 같은 메시지가 두 번 나갈 수 있는 “이론적 위험”을 명시하고, 이를 인지해 Kafka 리스너에서 멱등성을 보장하는 설계를 미리 마련해야 한다고 적는다.

수신부는 재시도 토픽이다. 기존 에러 핸들러는 실패하면 알림을 보내고 메시지를 커밋했기 때문에, 곧 처리될 수 있는 메시지도 개발자가 모아 두었다가 수동으로 다시 발행해야 했다. 입고 예정 정보는 실제 입고까지 1~2일이 있으므로, 그 안에 자동 복구되면 된다. @RetryableTopic으로 메인 1회 + 재시도 144회, 10분 고정 간격, 약 24시간. 재시도 토픽은 하나(SINGLE_TOPIC)로 합쳤고, 전부 실패하면 DLT다. 알림은 토픽으로 가른다. 메인 토픽 실패는 즉시 알림, 재시도 토픽 실패는 알림 생략, 재시도 성공은 해소 알림, DLT 진입은 최종 실패 알림.

설계 원칙은 발행부와 수신부의 책임 분리다. 원문은 처음에 인터페이스 테이블에서 미완료 건을 찾아 처리하는 스케줄링 배치도 검토했지만, 그러면 수신부가 발행부의 저장소에 직접 의존하게 되어 택하지 않았다. 그래서 발행부는 안전하게 내보내는 데 집중하고, 수신부는 자기 재시도 상태를 스스로 관리한다. 검증된 라이브러리를 쓴 것을 “바퀴를 다시 발명하지 마라”로 정리한다.

같은 곳: 발행부의 모양

Outbox의 뼈대는 5편과 같다. 같은 트랜잭션에 적고, 폴러가 발행하고, 확인 뒤 표시한다. 원문이 “이론적 위험”이라고 적은 것(발행 성공 후 표시 전 종료 → 중복 발행)은 이후 5편에서 “버그가 아니라 전제”라고 적은 것이고, 둘 다 소비자의 멱등으로 흡수한다. 원문이 라이브러리를 쓴 것과 내가 직접 만든 것의 차이는 목적의 차이다. 컬리는 입고 시스템을 만드는 것이 목적이고 Outbox는 수단이라 라이브러리가 맞다. parity-pay는 Outbox가 어떻게 깨지는지 보는 것이 목적이라 직접 만들어야 했다. 나중에 4편에 정리한, Outbox 발행기가 운영 경로에서 전혀 안 돌던 결함 B, 브로커 장애 시 배치 전체가 롤백되던 결함 C, 발행기 4대에서 순서가 깨지던 결함 F는 전부 직접 만든 Outbox에서 나왔다. 라이브러리가 그 셋을 이미 처리하는지는 원문에 없고, 그것이 라이브러리를 고를 때 물어야 할 질문이다.

갈리는 곳: 145회 재시도 vs 재시도 금지

parity-pay는 외부 승인 요청을 재시도하지 않는다(ADR-007). 이후 9편에서 그 이유를 쟀다. 타임아웃 3초에 재시도 3회를 붙이자 이미 느린 기관이 받는 요청이 정확히 3.00배가 됐고, 이중 청구가 안 난 것은 기관이 멱등해서였다.

컬리의 145회는 정반대인데 맞다. 두 조건이 다르기 때문이다.

첫째, 실패의 원인이 시간이 지나면 해소되는가. 컬리 수신부의 실패는 파트너·상품 정보의 동기화 지연이나 담당자 실수로 인한 순서 뒤바뀜이다. 얼마가 걸릴지는 모르지만 곧 해소되고, 그러면 같은 메시지가 성공한다. 원문의 문장대로 “일정 시간이 지나고 다시 재시도 하면 정상적으로 처리될 가능성이 아주 큽니다.” parity-pay 외부 승인의 실패는 “기관이 느림”이고, 재시도는 그 원인을 해소하지 않는다.

둘째, 재시도가 상대에게 비용을 지우는가. 컬리의 재시도는 자기 DB를 다시 읽는 것이다. 상대(파트너)에게 아무것도 보내지 않는다. 원문도 발행부와 수신부가 모두 컬리 서비스 안에 있으므로 Poison Pill(어떤 소비자도 처리할 수 없는 메시지) 문제는 보장된다는 것을 전제로 둔다. parity-pay의 재시도는 외부 기관에 요청을 다시 보내는 것이고, 그 기관은 이미 아프다.

그래서 규칙은 “재시도하라”도 “하지 말라”도 아니다. 원인이 시간으로 해소되고 재시도가 자기 안에서 끝나면 길게 재시도하고, 원인이 상대에게 있고 재시도가 상대에게 닿으면 재시도 대신 조회한다. 원문의 10분 × 144회는 첫 번째 경우의 정직한 설계다. 1~2일이라는 도메인의 여유에서 24시간을 역산했고, 그 안에 안 되면 DLT로 사람에게 넘긴다.

같은 곳: DLT가 있다는 것

이후 8편 결함 M으로 찾은 것은 parity-pay 소비자에 DLT(Dead Letter Topic, 끝내 처리하지 못한 메시지를 모아 두는 토픽)가 없어서 처리 불가 레코드가 10회 즉시 재시도 뒤 조용히 사라지던 문제였다. 컬리는 처음부터 DLT가 있고, DLT 진입을 최종 실패 알림으로 만들었다. MDS SQS 글에서 “DLQ 이후 절차가 없으면 격리가 아니라 유실”이라고 적었는데, 원문의 알림 차등이 그 절차다. 재시도 중에는 조용히, 해소되면 알리고, 끝까지 안 되면 크게 알린다. 145회 재시도 동안 매번 알리면 알림이 소음이 되어 아무도 안 본다. 원문이 재시도 토픽 실패를 알림에서 뺀 것이 그것을 막는 설계이고, 이 판단이 재시도 횟수만큼 중요하다.

원문이 답하지 않는 것

  • 수신부의 멱등을 어떻게 구현했는가. Kafka 리스너에 멱등성을 보장하는 설계가 미리 마련되어야 한다는 데까지이고 방법은 없다. 이후 5편에서 쓴 (consumer_name, event_id) 삽입의 반환 행 수처럼, 동시 소비(같은 메시지가 두 인스턴스에)까지 막는지 순차 중복만 막는지가 갈린다.
  • 순서 위반의 실제 처리. 원문은 파트너·상품 정보가 먼저 와야 한다는 프로세스 순서가 컬리의 제약이라 외부 채널에 강요할 수 없다고 적었고, 그 어긋남을 재시도로 흡수한다. 그런데 재시도 토픽은 메시지 사이의 순서를 깨는 장치다. Spring Kafka 문서도 이 방식을 쓰면 “you lose Kafka’s ordering guarantees for that topic”(그 토픽에서 Kafka의 순서 보장을 잃는다)라고 적는다(How the Pattern Works). 메인에서 실패한 메시지가 10분 뒤 재시도 토픽에서 성공하는 동안, 그 뒤에 온 같은 입고 건의 수정 메시지가 먼저 처리될 수 있다. 원문의 도메인에서 그것이 문제가 안 되는 이유(입고 예정 정보가 마지막 값 우선인가)가 있을 텐데 적혀 있지 않다.
  • 폴러 다중 인스턴스. 원문의 설정에는 라이브러리의 인스턴스 조정·파티션 관리 항목(heartbeat, 비정상 인스턴스 판정)이 있지만, 여러 폴러가 같은 레코드를 어떻게 나눠 갖는지, 순서는 지키는지는 설명하지 않는다. 나중에 5편에서 발행기 4대의 순서 역전이 정산 금액을 바꿨던 것이 정확히 이 자리다.

가져갈 것

  • 재시도 정책은 두 질문으로 정한다. 원인이 시간으로 해소되는가, 재시도가 상대에게 닿는가. 둘 다 예면 길게, 둘 다 아니면 조회.
  • 재시도 횟수는 도메인의 여유에서 역산한다. 입고까지 1~2일이면 24시간.
  • DLT는 알림 정책과 함께여야 격리다. 재시도 중에는 조용히, 끝나면 크게.
  • 재시도 토픽은 순서를 깬다. 그 도메인에서 순서가 왜 문제가 안 되는지를 적어 두어야 한다.
참고한 자료외부 출처 3

외부 출처

TechBlog, Kurly
Tech Blog Review Kurly Transactional Outbox Retry Topic Dead Letter Topic Kafka Idempotency Spring Kafka
Kafka와 메시징 결제·정산 정합성 Spring과 JVM 백엔드
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

변경이력

3번 수정

  1. docs(posts): separate the sections of every post with a thematic break
  2. docs(posts): describe parity-pay work as later in posts that predate it
  3. docs(techblog): remove claims the kurly original does not make

댓글

아직 댓글이 없습니다