분산 시스템에서 중복 이벤트가 사라지지 않는 이유

분산 시스템에서 중복 이벤트가 발생하는 근본적인 이유

현대적인 소프트웨어 아키텍처는 대부분 분산 시스템으로 구성됩니다. 여러 대의 서버가 네트워크를 통해 데이터를 주고받으며 서비스를 운영하는 방식입니다. 하지만 이 과정에서 우리는 필연적으로 중복 이벤트라는 문제와 마주하게 됩니다. 왜 시스템은 데이터를 한 번만 처리하지 못하고 똑같은 이벤트를 반복해서 전달할까요? 그 이유는 분산 시스템의 근본적인 한계인 네트워크의 신뢰성 때문입니다.

네트워크는 본질적으로 불안정합니다. 데이터를 보냈을 때 상대방이 받았는지 확인할 수 없는 ‘불확실성’이 존재합니다. 발신자는 데이터를 보낸 뒤 수신자로부터 ‘잘 받았다’는 응답을 기다립니다. 만약 일정 시간 동안 응답이 없다면 발신자는 두 가지 경우를 가정해야 합니다. 첫째, 데이터가 가는 도중 유실되었을 경우. 둘째, 데이터는 잘 전달되었지만 수신자의 응답이 도중에 유실되었을 경우입니다. 이때 발신자는 안전을 위해 데이터를 다시 보냅니다. 바로 이 지점에서 중복 이벤트가 탄생합니다.

분산 시스템의 메시지 전달 보장 유형

분산 시스템에서 메시지를 처리하는 방식은 크게 세 가지로 나뉩니다. 각 방식은 시스템의 복잡도와 안정성 사이에서 서로 다른 선택을 강요합니다.

• 최대 한 번 전달: 메시지를 한 번 보내고 끝냅니다. 유실될 가능성이 있지만 중복은 발생하지 않습니다. 로그 수집처럼 일부 데이터가 빠져도 큰 문제가 없는 시스템에 적합합니다.

• 최소 한 번 전달: 메시지가 확실히 전달될 때까지 재전송합니다. 중복이 발생할 수 있지만 데이터 유실은 방지합니다. 대부분의 금융 시스템이나 결제 서비스가 이 방식을 택합니다.
• 정확히 한 번 전달: 이론적으로 가장 이상적이지만, 실제 네트워크 환경에서는 구현이 매우 어렵습니다. 메시지 처리 과정에서 상태 정보를 함께 관리하여 중복을 제거하는 기술이 필요합니다.

흔한 오해와 진실

많은 개발자가 “네트워크가 빠르면 중복이 줄어들지 않을까?”라고 생각합니다. 하지만 이는 오해입니다. 네트워크 속도가 빨라져도 ‘불확실성’이라는 본질은 사라지지 않습니다. 오히려 시스템의 처리 속도가 빨라질수록 재시도 로직이 더 빈번하게 작동하여 중복 이벤트가 더 많이 발생할 수도 있습니다. 또 다른 오해는 “중복 제거 로직을 메시지 큐(Message Queue)에서 처리하면 되지 않느냐”는 것입니다. 메시지 큐는 전달을 보장할 뿐, 비즈니스 로직 수준에서의 중복까지 완벽히 제어하기는 어렵습니다.

중복 이벤트가 사라지지 않는 진짜 이유

시스템 설계자들은 흔히 ‘멱등성’이라는 개념을 간과하곤 합니다. 시스템이 동일한 요청을 여러 번 받아도 최종 결과는 한 번 수행한 것과 동일하게 유지하는 성질을 멱등성이라고 합니다. 중복 이벤트 자체가 사라지는 것이 아니라, 중복이 발생해도 시스템이 이를 무해하게 처리하도록 설계하는 것이 핵심입니다.

실무에서 활용하는 중복 처리 전략

중복 이벤트를 막을 수 없다면, 우리는 어떻게 대응해야 할까요? 실무에서 가장 많이 사용하는 실용적인 방법들을 소개합니다.

멱등성 키를 활용한 데이터 관리

모든 이벤트에는 고유한 식별자(Request ID 또는 Transaction ID)를 부여해야 합니다. 서버는 이 ID를 데이터베이스에 저장해두고, 새로운 요청이 들어올 때마다 ID가 이미 존재하는지 확인합니다. 만약 존재한다면 이미 처리된 이벤트로 간주하고 무시하는 방식입니다. 이는 가장 비용 효율적이고 강력한 방어 기제입니다.

데이터베이스의 고유 제약 조건 활용

데이터베이스의 유니크 제약 조건을 적극 활용하세요. 특정 칼럼에 대해 중복 데이터를 허용하지 않도록 설정하면, 설령 애플리케이션 레벨에서 중복을 걸러내지 못하더라도 데이터베이스 수준에서 에러를 발생시켜 데이터 오염을 막을 수 있습니다.

상태 기반 처리

이벤트가 단순히 값을 더하는 것이 아니라 상태를 변경하는 경우라면, 현재 상태를 확인하는 로직이 필요합니다. 예를 들어 ‘주문 완료’ 상태인 건에 대해 다시 ‘주문 완료’ 이벤트가 들어오면 이를 무시하도록 상태 전이 로직을 설계해야 합니다.

전문가의 조언

분산 시스템을 설계할 때 가장 경계해야 할 태도는 ‘중복이 발생하지 않을 것’이라는 낙관론입니다. 중복은 분산 시스템의 상수와 같습니다. 따라서 시스템을 설계할 때는 항상 ‘중복이 발생했을 때 어떻게 시스템을 보호할 것인가’를 먼저 고민해야 합니다. 전문가들은 이를 ‘방어적 프로그래밍’이라고 부릅니다. 또한, 모든 곳에 완벽한 중복 제거를 적용하면 시스템 성능이 크게 저하될 수 있습니다. 비즈니스 중요도가 높은 결제나 계좌 이체 같은 영역에는 엄격한 멱등성 처리를 적용하고, 그렇지 않은 로그나 통계 데이터는 가벼운 처리 방식을 선택하는 등 유연한 접근이 필요합니다.

자주 묻는 질문

질문: 메시지 큐를 사용하면 중복이 자동으로 제거되지 않나요?

답변: 카프카(Kafka)와 같은 메시지 큐는 ‘중복 전달’을 방지하기 위해 노력하지만, 네트워크 장애 상황에서는 여전히 중복 메시지가 발생할 수 있습니다. 큐는 전달을 담당할 뿐, 그 이후의 처리 결과까지 완벽히 보장하지는 않습니다.

질문: 중복 제거를 위해 데이터베이스를 조회하면 성능이 너무 느려지지 않을까요?

답변: 충분히 타당한 우려입니다. 이럴 때는 레디스(Redis)와 같은 인메모리 저장소를 활용해 최근 처리된 ID를 빠르게 확인하는 방식을 추천합니다. 디스크 기반의 데이터베이스보다 훨씬 빠른 속도로 중복 여부를 판단할 수 있습니다.

질문: 중복 이벤트 처리를 위한 비용 효율적인 방법은 무엇인가요?

답변: 클라우드 서비스에서 제공하는 관리형 서비스나, 멱등성을 고려한 API 설계 패턴을 사용하는 것이 비용을 절감하는 길입니다. 나중에 중복으로 인해 발생한 데이터를 수동으로 수정하는 비용이, 처음에 멱등성 로직을 설계하는 비용보다 훨씬 크다는 점을 명심하세요.

시스템 안정성을 높이는 체크리스트

분산 시스템을 구축하고 운영할 때 다음 항목들을 점검해 보시기 바랍니다.

• 모든 이벤트가 고유한 ID를 가지고 있는가?

• 데이터베이스 스키마에 적절한 고유 제약 조건이 설정되어 있는가?
• API 호출 시 실패에 대비한 재시도 로직이 멱등성을 보장하는가?
• 중복 이벤트가 발생했을 때 이를 모니터링하고 추적할 수 있는가?
• 중복 처리 과정에서 발생하는 성능 저하를 고려한 캐싱 전략이 있는가?

분산 시스템에서의 중복 이벤트는 제거 대상이 아니라 관리 대상입니다. 네트워크의 불안정함을 인정하고, 그 위에서 어떻게 시스템이 일관성을 유지할지 고민하는 과정이 바로 분산 시스템 설계의 본질입니다. 위에서 언급한 멱등성 키 활용, 데이터베이스 제약 조건 활용, 그리고 상태 기반의 로직 설계를 단계적으로 적용해 보세요. 작은 변화가 모여 훨씬 더 견고하고 신뢰할 수 있는 분산 아키텍처를 만들어낼 것입니다.