이 글은 결제 승인 이벤트를 동기 호출에서 Kafka 기반 비동기 흐름으로 옮길 때 정한 세 가지 불변식과 그 구현을 다룬다.

1. 승인 결과와 이벤트는 함께 남는다

처음에는 결제 트랜잭션이 끝난 뒤 프로듀서로 이벤트를 보냈다.

@Transactional
public Payment approve(ApproveCommand command) {
    Payment payment = paymentRepository.save(Payment.approved(command));
    kafkaTemplate.send("payment-approved", payment.getId(), toEvent(payment));
    return payment;
}

코드는 짧지만 데이터베이스 커밋과 Kafka 발행은 하나의 원자적 연산이 아니다. DB 커밋 후 프로세스가 종료되면 승인은 남고 이벤트는 사라진다. 반대로 Kafka 발행을 기다리는 동안 DB 트랜잭션을 오래 열어 두면 지연과 장애의 영향 범위가 커진다.

그래서 Transactional Outbox를 사용했다. 결제 상태와 발행할 이벤트를 같은 로컬 트랜잭션에 기록하고, 별도 릴레이가 outbox를 읽어 Kafka로 보낸다.

@Transactional
public Payment approve(ApproveCommand command) {
    Payment payment = paymentRepository.save(Payment.approved(command));
    outboxRepository.save(OutboxEvent.pending(
        payment.getId(),
        "PaymentApproved",
        eventSerializer.serialize(toEvent(payment))
    ));
    return payment;
}

이 구조가 보장하는 것은 “정확히 한 번 발행”이 아니다. 승인이 존재하면 결국 발행할 이벤트도 존재한다는 복구 가능한 상태다. 릴레이는 발행 직후 종료될 수 있으므로 같은 이벤트를 다시 보낼 수 있다. 중복은 다음 불변식에서 처리한다.

2. 같은 이벤트는 여러 번 와도 결과가 같다

Kafka의 재전달, 컨슈머 재시작, outbox 릴레이 재시도 때문에 소비자는 중복을 정상 입력으로 받아들여야 한다. 이벤트 ID를 기준으로 처리 이력을 남기고, 비즈니스 변경과 같은 트랜잭션에서 중복 여부를 확인한다.

@KafkaListener(topics = "payment-approved")
@Transactional
public void handle(PaymentApproved event) {
    if (processedEventRepository.existsById(event.eventId())) {
        return;
    }

    settlementRepository.createPending(
        event.paymentId(),
        event.amount()
    );
    processedEventRepository.save(new ProcessedEvent(event.eventId()));
}

exists 다음 insert 사이에는 경쟁 조건이 있다. 따라서 processed_event.event_id에 유니크 제약을 두고, 충돌을 이미 처리된 이벤트로 해석한다. 애플리케이션의 사전 조회는 빠른 종료를 위한 최적화일 뿐, 정확성은 데이터베이스 제약이 지킨다.

이벤트 ID는 재시도마다 새로 만들지 않는다. 비즈니스 사건 하나에 ID 하나를 부여하고 outbox 레코드와 Kafka 메시지 헤더에서 끝까지 유지한다.

3. 순서가 필요한 사건은 같은 파티션으로 간다

결제에는 Approved → Cancelled처럼 인과 순서가 있다. 토픽 전체의 순서를 보장할 필요는 없지만, 같은 결제 건의 이벤트는 순서대로 처리되어야 한다. 프로듀서 키를 paymentId로 고정해 한 결제의 이벤트가 같은 파티션에 들어가게 했다.

kafkaTemplate.send(
    "payment-events",
    event.paymentId().toString(),
    event
);

파티션 키를 정할 때는 순서와 부하 분산을 함께 본다. 가맹점 ID를 키로 사용하면 특정 대형 가맹점이 한 파티션을 과열시킬 수 있다. 결제 ID는 개별 결제의 인과 관계를 유지하면서 비교적 고르게 분산된다.

컨슈머에서는 예상하지 못한 상태 전이를 거부한다. 취소 이벤트가 도착했는데 승인 상태가 없다면 무작정 재시도하지 않고 보류 큐로 보내 원인을 분리한다. 순서 보장은 정상 조건의 약속이지, 손상된 데이터까지 자동으로 고치는 장치가 아니다.

운영 지표는 불변식의 위반을 보여줘야 한다

기술 지표만으로는 돈의 흐름이 맞는지 알 수 없다. 다음 지표를 함께 운영했다.

알람에는 토픽과 파티션뿐 아니라 eventType, 최초 발생 시각, 영향 결제 수를 넣었다. 그래야 “Kafka lag이 높다”가 아니라 “승인 312건의 정산 생성이 4분 늦다”로 상황을 설명할 수 있다.

마치며

Kafka를 도입해 얻은 가장 큰 이점은 처리량이 아니라 경계를 명확히 한 것이었다. 결제 서비스는 승인과 발행 의도를 원자적으로 남기고, 릴레이는 적어도 한 번 전달하며, 소비자는 중복을 제거하고 상태 전이를 검증한다.

정리하면 세 가지 불변식은 다음과 같다.

1. 승인이 남으면 발행할 이벤트도 반드시 남는다.
2. 같은 이벤트가 여러 번 도착해도 결과는 한 번 처리한 것과 같다.
3. 같은 결제의 상태 전이는 관찰 가능한 순서를 지킨다.

“Exactly once”라는 한 문장보다 각 경계가 무엇을 보장하고 어디서 복구하는지 적어 두는 편이 운영에서 훨씬 강했다.

문제는 Redis가 락을 잘못 준 것이 아니었다. 락을 획득한 프로세스가 여전히 유효한 소유자인지 실제 데이터를 변경하는 시스템은 알지 못했다.

재현한 실패 경로

락의 TTL은 3초였고 일반적인 결제 준비 단계는 300ms 안에 끝났다. 장애 당시 흐름은 다음과 같았다.

1. 인스턴스 A가 order:42 락을 얻는다.
2. A가 4초 동안 GC로 멈춘다.
3. 락이 만료되고 인스턴스 B가 같은 락을 얻는다.
4. B가 결제 레코드를 생성한다.
5. A가 깨어나 자신이 여전히 소유자라고 생각하고 레코드를 생성한다.

락을 얻을 때 임의 토큰을 값으로 저장하고 Lua 스크립트로 소유자만 해제하도록 구현해도 이 실패는 남는다.

SET order:42 9b71... NX PX 3000

안전한 해제는 다른 소유자의 락을 지우지 않게 할 뿐, 만료된 이전 소유자의 쓰기를 막지는 않는다.

TTL을 늘리는 것은 확률을 낮출 뿐이다

TTL을 30초로 늘리자는 제안이 있었다. 평균 처리 시간보다 충분히 길어 보이지만 상한을 증명할 수 없다면 같은 문제가 더 드물게 일어날 뿐이다. 네트워크 지연, stop-the-world GC, 외부 결제사 타임아웃이 겹치면 어떤 TTL도 만료될 수 있다.

락 연장 watchdog도 도움이 되지만 완전한 답은 아니다. 프로세스가 멈추면 watchdog도 멈추고, 네트워크가 분리되면 연장 성공 여부를 확정하기 어렵다. 가용성을 위해 만료가 필요하고, 만료를 허용하면 과거 소유자가 돌아올 가능성을 처리해야 한다.

쓰기 시스템이 오래된 소유자를 거절하게 한다

해결의 핵심은 단조 증가하는 fencing token이었다. 락을 얻을 때마다 더 큰 번호를 받고, 데이터를 변경할 때 토큰을 함께 전달한다. 저장소는 마지막으로 본 토큰보다 작은 쓰기를 거절한다.

UPDATE payment_attempt
SET status = 'READY',
    fencing_token = :token
WHERE order_id = :orderId
  AND fencing_token < :token;

A가 토큰 101을 받은 뒤 멈추고 B가 102를 받아 먼저 쓰면, 늦게 돌아온 A의 101은 updated rows = 0으로 거절된다. 시간이나 프로세스 상태를 추측하지 않고 순서 자체를 데이터에 남긴다.

다만 모든 외부 시스템이 fencing token을 이해하는 것은 아니다. 결제사 API에 임의 버전 조건을 전달할 수 없다면 토큰만으로 외부 부작용을 막을 수 없다. 이 경우 결제사에서 지원하는 멱등 키를 주문의 결제 시도 ID에 연결해야 한다.

PaymentResult result = paymentGateway.approve(
    request.withIdempotencyKey(paymentAttempt.getId().toString())
);

데이터베이스 제약을 마지막 방어선으로 둔다

우리의 실제 불변식은 “한 번에 한 프로세스만 실행”이 아니라 “주문 하나에 유효한 결제 시도는 하나”였다. 따라서 정확성을 락에만 맡기지 않고 데이터 모델에 표현했다.

CREATE UNIQUE INDEX ux_payment_attempt_order_active
ON payment_attempt (order_id, active_key);

active_key는 활성 시도일 때 고정값, 종료된 시도일 때 고유값을 사용했다. 데이터베이스 종류에 따라 partial unique index나 별도 상태 테이블을 선택할 수 있다. 중요한 점은 경쟁 요청이 락 경계를 통과하더라도 저장소가 불변식을 거절한다는 것이다.

각 장치의 역할은 달랐다.

락을 적용하기 전에 묻는 질문

이후 분산 락을 검토할 때 네 가지를 먼저 확인한다.

1. 보호하려는 것은 실행 구간인가, 데이터 불변식인가?
2. 락이 만료된 뒤 이전 소유자가 돌아오면 누가 쓰기를 거절하는가?
3. 외부 부작용은 멱등 키나 상태 조회로 복구할 수 있는가?
4. Redis를 사용할 수 없을 때 실패를 닫을 것인가, 제한적으로 열 것인가?

락이 없어도 데이터가 틀리지 않고, 락이 있을 때 불필요한 경쟁만 줄어드는 구조가 가장 운영하기 쉬웠다.

마치며

분산 락은 상호 배제를 위한 유용한 조정 도구지만 정확성의 증명은 아니다. TTL이 있는 락에는 항상 과거 소유자가 돌아올 수 있다. 그 가능성을 fencing token, 데이터베이스 제약, 외부 API의 멱등성으로 각 경계에서 차단해야 한다.

장애 이후 우리가 바꾼 가장 중요한 문장은 “Redis 락으로 중복 결제를 막는다”에서 “저장소와 결제사가 중복을 거절하고, Redis 락은 경쟁 비용을 줄인다”였다.

관측 가능성을 “로그를 많이 남기는 일”이 아니라 사용자의 실패에서 원인 후보까지 이동하는 경로를 짧게 만드는 일로 정의하고 구조를 바꿨다.

도구보다 먼저 SLO를 정한다

첫 대시보드는 JVM 메모리와 CPU로 가득했지만 “사용자가 결제를 완료할 수 있는가?”에는 바로 답하지 못했다. 결제 승인 API에 다음 SLI를 정했다.

• 성공률: 시스템 오류 없이 최종 결과를 반환한 요청 비율
• 지연 시간: 승인 API의 p50, p95, p99
• 결과 최신성: 승인 후 정산 준비 이벤트가 생성되기까지 걸린 시간
• 불명확 결과: 타임아웃 뒤 성공·실패를 즉시 확정하지 못한 요청 수

시스템 메트릭은 원인 분석에 필요하지만 알람의 출발점은 사용자 경험이어야 한다. 예를 들어 CPU 90% 자체보다 “승인 p99이 2초를 넘고 오류 예산 소진 속도가 6배”라는 신호가 대응 우선순위를 더 명확히 만든다.

한 요청의 식별자를 경계 끝까지 전달한다

Spring Boot 3의 Micrometer Tracing을 사용해 HTTP 요청에 trace ID와 span ID를 만들고 로그 패턴에 포함했다.

management:
  tracing:
    sampling:
      probability: 0.1

logging:
  pattern:
    level: "%5p [traceId=%X{traceId:-},spanId=%X{spanId:-}]"

샘플링 비율이 10%여도 오류 요청은 별도 정책으로 보존했다. 개인정보와 카드 정보는 span attribute에 넣지 않았다. 대신 조사에 필요한 안전한 식별자만 제한적으로 기록했다.

Observation observation = Observation.createNotStarted(
    "payment.approve",
    observationRegistry
).lowCardinalityKeyValue("provider", providerCode)
 .lowCardinalityKeyValue("result", resultCode);

여기서 paymentId를 low-cardinality tag로 넣지 않는다. 고유값이 많은 태그는 시계열 수를 폭발시킨다. 결제 ID처럼 개별 요청을 찾기 위한 값은 로그나 trace attribute에 두고, 메트릭 태그는 결제사·결과 코드·API처럼 제한된 집합만 사용한다.

비동기 경계에서도 맥락을 끊지 않는다

HTTP 요청에서 만든 추적 맥락은 Kafka로 넘어갈 때 자동으로 이어지는지 확인해야 한다. 프로듀서가 trace context를 메시지 헤더에 주입하고 컨슈머가 추출하도록 계측 라이브러리를 맞췄다. 비즈니스 사건을 추적하는 eventId와 기술적인 traceId는 역할이 다르므로 둘 다 유지했다.

• traceId: 한 번의 실행 경로를 추적한다. 재시도하면 새 trace가 생길 수 있다.
• eventId: 같은 비즈니스 사건을 식별한다. 재전달돼도 유지된다.

컨슈머 로그에는 두 값을 함께 남겼다.

{
  "message": "settlement event consumed",
  "traceId": "8d7e4b2a...",
  "eventId": "evt_01J...",
  "topic": "payment-approved",
  "partition": 7,
  "offset": 184201
}

이 구조 덕분에 한 실행의 지연은 trace에서, 같은 이벤트의 반복 처리는 event ID 검색에서 확인할 수 있었다.

로그에는 사실과 다음 행동을 남긴다

다음과 같은 로그는 실제 대응에 거의 도움이 되지 않았다.

ERROR payment failed

오류 로그를 설계할 때 최소한 네 가지를 포함했다.

1. 어떤 작업이 실패했는가
2. 재시도 가능한가
3. 외부 부작용이 발생했을 가능성이 있는가
4. 안전하게 식별할 수 있는 비즈니스 키는 무엇인가

예외 스택은 원인을 보여 주지만 현재 상태와 복구 방법까지 알려주지는 않는다. 그래서 outcome=UNKNOWN, retryable=false, reconciliationRequired=true처럼 다음 행동을 결정하는 필드를 구조화해 남겼다.

알람에서 trace까지 한 번에 이동한다

최종 대시보드는 다음 순서로 읽게 만들었다.

1. SLO와 오류 예산 소진 속도로 영향도를 확인한다.
2. 실패한 API·결제사·결과 코드로 범위를 좁힌다.
3. exemplar가 연결한 trace에서 가장 긴 span과 오류를 본다.
4. trace ID로 구조화 로그를 검색해 비즈니스 상태를 확인한다.

알람 메시지에도 같은 경로를 넣었다. 담당자는 채널에서 대시보드, 대표 trace, 대응 문서로 바로 이동할 수 있었다. 도구를 추가한 것보다 관찰 화면 사이의 이동 비용을 줄인 것이 평균 확인 시간을 더 크게 줄였다.

비용과 개인정보도 설계 대상이다

모든 요청을 영구 보관할 수는 없다. 정상 trace는 낮은 비율로 샘플링하고 오류와 고지연 trace는 tail-based sampling으로 더 많이 보존했다. 로그 보존 기간은 용도별로 나누고, 운영 검색에 필요 없는 body와 헤더는 수집 단계에서 제거했다.

관측 데이터는 디버깅 편의를 위한 복사본이 아니라 또 하나의 데이터 시스템이다. 접근 권한, 마스킹, 보존 기간, 비용 상한이 애플리케이션 설계와 함께 정해져야 한다.

마치며

관측 가능성의 목표는 데이터의 양이 아니다. 질문에 답하는 데 필요한 연결이 핵심이다.

• SLO는 사용자 실패에서 조사를 시작하게 한다.
• trace ID는 동기·비동기 실행 경로를 연결한다.
• event ID는 재시도와 재전달 사이에서도 사건을 연결한다.
• 구조화 로그는 현재 상태와 다음 행동을 설명한다.
• 메트릭 태그는 집계에 필요한 낮은 카디널리티만 가진다.

로그 한 줄을 더 남기기 전에, 그 로그가 어떤 알람과 trace에서 도달 가능한지 먼저 확인하는 습관이 장애 대응 시간을 바꿨다.