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

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

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

원문이 말하는 것

컬리는 직매입(1P) 중심에서 3PL로 확장하며 외부 파트너의 입고 예정 정보를 다양한 규격으로 받게 됐다. 레거시의 실패 지점은 둘이었다. 발행부: 인터페이스 DB 저장과 Kafka 발행 사이에 원자성이 없어 저장은 됐는데 발행이 안 되거나 그 반대가 났다. 수신부: 파트너 정보나 상품 정보가 아직 동기화되지 않아 입고 예정 정보 생성이 실패했다.

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

수신부는 재시도 토픽이다. 입고 예정 정보는 실제 입고까지 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를 다시 읽는 것이다. 상대(파트너)에게 아무것도 보내지 않는다. parity-pay의 재시도는 외부 기관에 요청을 다시 보내는 것이고, 그 기관은 이미 아프다.

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

같은 곳: DLT가 있다는 것

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

원문이 답하지 않는 것

• 수신부의 멱등을 어떻게 구현했는가. “카프카 리스너에서 멱등성 보장 설계가 필요하다”까지이고 방법은 없다. 5편의 (consumer_name, event_id) 삽입의 반환 행 수처럼, 동시 소비(같은 메시지가 두 인스턴스에)까지 막는지 순차 중복만 막는지가 갈린다.
• 순서 위반의 실제 처리. 외부 채널의 프로세스 순서를 강요할 수 없으니 “별도 모니터링”이라고 적었다. 그런데 재시도 토픽은 순서를 깨는 장치다. 메인에서 실패한 메시지가 10분 뒤 재시도 토픽에서 성공하는 동안, 그 뒤에 온 같은 입고 건의 수정 메시지가 먼저 처리될 수 있다. 원문의 도메인에서 그것이 문제가 안 되는 이유(입고 예정 정보가 마지막 값 우선인가)가 있을 텐데 적혀 있지 않다.
• 폴러 다중 인스턴스. 한계로 언급했지만 라이브러리가 SKIP LOCKED 같은 선점을 하는지, 순서는 지키는지는 없다. 5편에서 발행기 4대의 순서 역전이 정산 금액을 바꿨던 것이 정확히 이 자리다.

가져갈 것

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