Day 4. 이벤트 처리에서 발생하는 문제

1. 오늘의 학습 목표

• 메시지가 중복 전달될 수 있는 이유를 설명할 수 있다.
• at-least-once와 멱등성의 관계를 설명할 수 있다.
• Retry와 DLQ가 필요한 상황과 무한 재시도의 문제를 구분할 수 있다.
• 이벤트 지연과 순서 문제가 주문 상태에 미치는 영향을 분석할 수 있다.
• 최종적 일관성의 중간 상태를 업무 관점에서 설명할 수 있다.

2. 학습 전 생각해보기

질문 1

Stock이 재고 차감에는 성공했지만 “처리 완료” 기록 전에 종료되면 같은 이벤트를 다시 받을 때 어떤 일이 생길까?

내 답변

질문 2

실패한 메시지를 성공할 때까지 쉬지 않고 계속 재시도하면 왜 위험할까?

내 답변

질문 3

OrderCancelled가 OrderCreated보다 먼저 처리되면 주문 시스템에 어떤 잘못된 결과가 생길 수 있을까?

내 답변

3. 핵심 개념 설명

3.1 메시지는 왜 중복 전달될 수 있는가

메시지 시스템에서 “업무 처리가 성공했다”와 “처리 완료 위치를 기록했다”는 별도 동작일 수 있다. Consumer가 재고를 차감한 직후, 완료 위치를 기록하기 전에 종료되면 Broker는 그 처리가 끝났는지 확신할 수 없다.

안전하게 누락을 피하려면 Broker는 해당 메시지를 다시 전달한다. 첫 처리가 실제로 반영되었으므로 Consumer 입장에서는 같은 메시지를 두 번 받게 된다. 네트워크 응답 유실이나 재조정 중에도 비슷한 상황이 생길 수 있다.

따라서 중복은 단순한 Kafka 오류라기보다 “처리 여부를 확실히 알 수 없는 실패 구간”에서 누락을 피하려는 전달 방식의 결과다.

3.2 At-least-once와 멱등성

At-least-once는 메시지가 최소 한 번 전달되도록 하는 방식이다. 누락 가능성을 줄이는 대신 한 번보다 많이 전달될 수 있다. “정확히 한 번 비즈니스 효과”와 같은 뜻이 아니다.

멱등성은 같은 요청이나 이벤트를 여러 번 처리해도 최종 결과가 한 번 처리한 것과 같게 유지되는 성질이다. 재고를 1 감소를 두 번 실행하면 멱등하지 않지만, 이미 처리한 event ID인지 확인해 두 번째 효과를 막으면 결과를 보호할 수 있다.

멱등성은 Consumer의 업무 효과를 기준으로 생각해야 한다. 단지 메시지를 한 번 읽었다고 표시하는 것만으로 DB 변경과의 경계가 안전해지는지는 별도로 따져야 한다.

이후 학습: Outbox와 함께 멱등성이 필요한 이유는 Day 6에서 연결한다. 구현 방식은 이번 범위에서 다루지 않는다.

3.3 Retry와 무한 재시도

Retry는 일시적인 실패가 회복될 가능성을 보고 처리를 다시 시도하는 것이다. 잠깐의 DB 연결 끊김이나 외부 시스템의 일시적 과부하처럼 시간이 지나면 성공할 수 있는 문제에 의미가 있다.

모든 실패가 Retry로 해결되지는 않는다. 필수 필드가 없는 메시지나 지원하지 않는 값처럼 같은 입력으로 계속 실패하는 문제는 반복해도 성공하지 않는다. 재시도 사이의 간격이 없으면 장애 중인 자원을 더 압박할 수 있다.

무한 재시도는 특정 실패 메시지가 처리 흐름을 계속 막고, 자원을 소모하며, 뒤의 정상 메시지까지 지연시킬 수 있다. 따라서 재시도 가능 여부, 횟수와 간격, 최종 실패 처리 기준이 필요하다.

3.4 DLQ의 역할

DLQ(Dead Letter Queue)는 정해진 처리 시도 후에도 성공하지 못한 메시지를 정상 흐름과 분리해 보관하는 곳이다. 문제 메시지 때문에 전체 소비가 영구히 멈추는 것을 피하고 나중에 원인을 조사할 수 있게 한다.

DLQ로 보냈다고 업무 문제가 해결된 것은 아니다. 어떤 메시지가 왜 실패했는지 관찰하고, 수정 후 다시 처리할지 또는 별도로 보정할지 운영 판단이 필요하다.

DLQ는 “실패 메시지 쓰레기통”이 아니라 조사가 필요한 격리 구역에 가깝다. 민감한 결제 실패를 조용히 쌓아두기만 하면 시스템은 계속 불일치 상태로 남는다.

3.5 이벤트 처리 지연과 순서 문제

이벤트는 발행 즉시 처리된다고 보장할 수 없다. Consumer 과부하, 재시도, Broker나 네트워크 문제로 대기 시간이 늘어날 수 있다. 주문은 생성됐지만 재고 차감이 한동안 시작되지 않는 중간 상태가 생긴다.

서로 다른 Partition이나 병렬 처리에서는 이벤트의 완료 순서가 달라질 수 있다. 취소가 생성보다 먼저 반영되거나 결제 성공 뒤 늦은 실패 이벤트가 상태를 덮으면 잘못된 결과가 된다.

순서가 중요한 범위를 식별해야 한다. 모든 주문 사이의 전체 순서보다 같은 주문 ID에 대한 상태 전이 순서가 중요한 경우가 많다.

3.6 최종적 일관성

최종적 일관성은 각 서비스의 상태가 항상 동시에 바뀌지는 않지만 이벤트 처리가 끝나면 업무적으로 맞는 상태에 도달한다는 모델이다. 처리 중에는 Order가 처리 중, Stock이 차감 완료, Payment가 대기일 수 있다.

중간 상태를 숨기거나 실패를 방치해서는 안 된다. 사용자가 볼 상태와 가능한 전이, 지연 허용 시간, 실패 감지 기준을 정해야 한다.

최종적 일관성은 신뢰성 문제의 이름이 아니라 분산된 변경의 시간 차이를 인정하는 일관성 방식이다. 이를 유지하려면 중복, 실패, 지연, 순서를 함께 고려해야 한다.

4. 흐름으로 이해하기

Broker ── event-101 ──→ Stock Consumer
                            │
                            ├── 재고 차감 성공
                            └── 완료 기록 전 종료 ✕

Broker ── event-101 재전달 ─→ Stock Consumer
                                  │
                                  └── 중복 차감 위험

실패 ──→ 제한된 Retry ──→ 계속 실패 ──→ DLQ ──→ 조사/재처리 판단

처리 성공과 완료 기록 사이에서 장애가 나면 메시지가 재전달될 수 있다. Consumer의 업무 처리는 중복에도 안전해야 한다. 반복해도 해결되지 않는 메시지는 정상 흐름에서 격리하고 반드시 후속 조치를 해야 한다.

5. 직접 채우는 핵심 질문

질문 1. “재고 차감 성공 후 완료 기록 전 종료”가 중복을 만드는 과정을 설명하라.

내 답변

답변에 포함해야 할 키워드

• 업무 효과
• 완료 위치
• 재전달

질문 2. At-least-once가 메시지를 정확히 한 번만 처리한다는 뜻이 아닌 이유는 무엇인가?

내 답변

답변에 포함해야 할 키워드

• 최소 한 번
• 누락 방지
• 중복 가능

질문 3. 재고를 단순히 quantity - 1 하는 처리가 중복에 취약한 이유를 적어라.

내 답변

답변에 포함해야 할 키워드

• 같은 이벤트
• 여러 번 효과
• 멱등성

질문 4. 일시적 DB 연결 실패와 잘못된 메시지 형식은 Retry 관점에서 어떻게 다른가?

내 답변

답변에 포함해야 할 키워드

• 일시적 실패
• 영구적 실패
• 재시도 가능성

질문 5. 무한 재시도가 정상 메시지까지 지연시킬 수 있는 이유는 무엇인가?

내 답변

답변에 포함해야 할 키워드

• 자원 소모
• 반복 실패
• 처리 흐름

질문 6. DLQ에 메시지를 보낸 뒤 운영자가 해야 할 일을 세 가지 적어라.

내 답변

답변에 포함해야 할 키워드

• 관찰
• 원인 조사
• 재처리 또는 보정

질문 7. 모든 주문의 전체 순서보다 같은 주문의 이벤트 순서가 중요한 이유를 설명하라.

내 답변

답변에 포함해야 할 키워드

• 업무 대상
• 상태 전이
• 주문 ID

질문 8. 최종적 일관성에서 허용 가능한 중간 상태를 하나 만들고 종료 조건을 적어라.

내 답변

답변에 포함해야 할 키워드

• 처리 중
• 시간 차이
• 최종 상태

6. 상황 판단 문제

상황 1

PaymentCompleted(eventId=77)를 두 번 받은 Order가 주문 확정 알림을 두 번 보냈다.

1. 어떤 성질이 부족한가?
2. 메시지가 두 번 온 것과 알림이 두 번 발생한 것을 구분해 설명하라.

내 답변

상황 2

필수 orderId가 없는 메시지를 Consumer가 0.1초 간격으로 무한 재시도하고 있다.

1. 시간이 지나면 성공할 가능성이 높은가?
2. 정상 흐름을 보호하려면 어떤 분리가 필요한가?

내 답변

상황 3

주문 상태가 CANCELLED였는데 늦게 도착한 PaymentCompleted가 이를 COMPLETED로 바꿨다.

1. 지연과 순서 중 어떤 문제가 드러났는가?
2. 상태 전이 규칙에서 무엇을 확인해야 하는가?

내 답변

7. 오늘의 용어 정리

8. 프로젝트에 한 줄 연결

• Stock의 재고 차감은 같은 이벤트를 다시 받아도 이중 차감되지 않아야 한다.
• Payment 이벤트 처리 실패는 제한된 재시도 후에도 해결되지 않으면 관찰 가능한 별도 흐름이 필요하다.
• Order 상태는 늦거나 순서가 바뀐 이벤트에도 허용된 상태 전이를 지켜야 한다.

9. 오늘의 자기 점검

• 핵심 개념을 내 말로 설명할 수 있다.
• 오늘 등장한 주요 용어를 구분할 수 있다.
• 주문 시스템에 개념을 적용할 수 있다.
• 이해하지 못한 부분을 표시했다.
• 다음 주제와 현재 주제를 혼동하지 않는다.

10. 이해하지 못한 부분

11. 3문장 요약

12. 복습 퀴즈

1. At-least-once 방식에서 허용되는 것은 누락인가, 중복인가?
2. 같은 이벤트를 여러 번 처리해도 최종 효과가 같은 성질은 무엇인가?
3. 입력 자체가 잘못되어 반복해도 실패하는 메시지를 무한 재시도하면 안 되는 이유는 무엇인가?
4. 반복 실패 메시지를 정상 처리 흐름과 분리해 보관하는 곳은 무엇인가?
5. 최종적 일관성은 모든 서비스의 데이터가 항상 동시에 같다는 뜻인가?