왜 대부분의 SaaS는 At-Least-Once를 선택할까

왜 대부분의 SaaS는 최소 한 번 전달 방식을 선택하는가

소프트웨어 서비스(SaaS)를 운영하거나 시스템 설계를 고민하다 보면 데이터 처리의 신뢰성 문제에 직면하게 됩니다. 특히 분산 시스템에서 메시지나 이벤트를 주고받을 때 ‘정확히 한 번(Exactly Once)’ 전달하는 것이 기술적으로 얼마나 어려운지 알게 되면, 왜 많은 서비스가 ‘최소 한 번(At Least Once)’ 전달 방식을 선택하는지 이해하게 됩니다. 이 글에서는 기술적인 배경부터 실무적인 선택 기준까지, 왜 이 방식이 업계의 표준이 되었는지 상세히 알아봅니다.

데이터 전달 방식의 세 가지 핵심 유형

시스템 간에 메시지를 보낼 때 발생할 수 있는 상황은 크게 세 가지로 나뉩니다. 각 방식은 시스템의 복잡도와 비용, 그리고 데이터 정합성 사이에서 서로 다른 타협점을 가집니다.

• 최대 한 번(At Most Once): 메시지를 보내고 나서 제대로 도착했는지 확인하지 않습니다. 메시지가 유실될 수 있지만, 중복 처리는 발생하지 않습니다. 속도가 매우 빠르지만 데이터 손실에 민감한 서비스에는 적합하지 않습니다.

• 최소 한 번(At Least Once): 메시지가 수신자에게 전달될 때까지 재시도를 반복합니다. 메시지가 유실되지 않는다는 강력한 장점이 있지만, 네트워크 오류 등으로 인해 동일한 메시지가 여러 번 전달될 가능성이 있습니다.
• 정확히 한 번(Exactly Once): 메시지가 단 한 번만 처리되는 것을 보장합니다. 이론적으로 가장 이상적이지만, 이를 구현하기 위해서는 매우 복잡한 분산 트랜잭션과 상태 관리 기술이 필요하며 시스템의 성능 저하를 감수해야 합니다.

왜 최소 한 번 방식이 표준이 되었는가

대부분의 SaaS 기업이 ‘최소 한 번’ 방식을 선택하는 이유는 기술적 한계와 비용 효율성 때문입니다. ‘정확히 한 번’을 구현하기 위해서는 송신자와 수신자, 그리고 메시지 브로커가 모두 강력하게 결합되어야 합니다. 하지만 클라우드 환경에서는 네트워크 단절, 서버 장애 등 예측 불가능한 변수가 너무 많습니다. ‘최소 한 번’ 방식을 선택하면 이러한 장애 상황에서도 데이터 유실을 방지할 수 있으며, 구현 난이도 역시 훨씬 낮아집니다.

실제 비즈니스 관점에서는 데이터가 누락되어 매출이 기록되지 않는 것보다, 중복으로 처리되어 나중에 정산 과정에서 걸러내는 것이 훨씬 더 비용이 적게 듭니다. 시스템 설계의 황금률 중 하나는 ‘복잡한 문제를 기술적으로 완벽하게 해결하려 하지 말고, 비즈니스 로직으로 우아하게 해결하라’는 것입니다.

중복 처리를 해결하는 실용적인 방법

‘최소 한 번’ 방식을 선택했다면 필연적으로 발생하는 중복 메시지 문제를 해결해야 합니다. 이를 위한 가장 효과적인 전략은 ‘멱등성(Idempotency)’을 확보하는 것입니다. 멱등성이란 동일한 연산을 여러 번 수행하더라도 결과가 처음 수행했을 때와 동일하게 유지되는 성질을 의미합니다.

멱등성 구현을 위한 실무 팁

• 고유 식별자 사용: 모든 요청에 고유한 주문 번호나 이벤트 ID를 부여합니다. 수신 측에서는 이미 처리된 ID인지 데이터베이스에서 확인한 후, 처리된 적이 있다면 메시지를 무시합니다.

• 상태 기반 처리: 데이터의 상태 값을 확인합니다. 예를 들어 ‘결제 완료’ 상태인 주문에 대해 다시 ‘결제 완료’ 요청이 들어오면 아무 작업도 하지 않고 성공 응답만 보냅니다.
• 데이터베이스 제약 조건 활용: 데이터베이스의 유니크 키(Unique Key) 설정을 통해 중복 삽입을 원천적으로 차단합니다.

흔한 오해와 사실 관계

많은 개발자가 ‘정확히 한 번’을 구현하지 못하는 것을 기술적인 부족함으로 생각하곤 합니다. 하지만 이는 오해입니다. 구글, 아마존, 넷플릭스 같은 거대 기업들도 대부분의 경우 ‘최소 한 번’ 전달 방식을 기반으로 설계하고, 애플리케이션 레벨에서 중복을 처리하는 방식을 택합니다.

또 다른 오해는 ‘최소 한 번’ 방식이 성능을 저하시킬 것이라는 생각입니다. 실제로는 메시지 재시도 로직이 가끔 작동할 뿐, 평상시에는 ‘최대 한 번’과 동일한 속도로 동작합니다. 오히려 시스템 전체의 가용성을 높여주기 때문에 사용자 경험 측면에서도 더 나은 선택이 되는 경우가 많습니다.

비용 효율적인 시스템 설계 전략

시스템을 설계할 때 비용을 절감하는 가장 좋은 방법은 복잡성을 낮추는 것입니다. ‘최소 한 번’ 방식은 메시지 브로커(Kafka, RabbitMQ 등)의 기본 기능을 활용하기 때문에 별도의 복잡한 분산 트랜잭션 관리 도구가 필요 없습니다.

비용 효율성을 극대화하려면 다음 사항을 고려하세요.

• 오토 스케일링 활용: 재시도 로직으로 인해 일시적으로 트래픽이 몰릴 수 있으므로, 클라우드 환경의 오토 스케일링을 적절히 설정하여 비용을 최적화합니다.
• 데드 레터 큐(DLQ) 운영: 재시도해도 실패하는 메시지는 별도의 큐로 보내 따로 관리합니다. 이를 통해 정상적인 트래픽이 방해받지 않도록 격리할 수 있습니다.
• 모니터링 강화: 중복 요청이 얼마나 발생하는지, 재시도 횟수가 비정상적으로 높지는 않은지 모니터링 대시보드를 구축하여 병목 지점을 빠르게 파악합니다.

전문가의 조언

시스템 설계 전문가들은 대개 ‘완벽함보다는 회복 탄력성’을 강조합니다. 분산 시스템에서 완벽한 데이터 정합성을 추구하다 보면 시스템이 너무 무거워지고, 결국 장애 발생 시 복구하기가 매우 어려워집니다. 대신, 시스템이 실패할 수 있다는 것을 인정하고, 실패했을 때 어떻게 복구할지(Self-healing)에 집중하는 것이 훨씬 더 건강한 접근 방식입니다.

따라서 여러분의 서비스가 높은 수준의 정합성을 요구한다면, 모든 계층에서 ‘정확히 한 번’을 구현하려 애쓰기보다는 ‘최소 한 번’ 전달을 기본으로 하되, 데이터베이스의 트랜잭션과 멱등성 보장 로직을 충실히 구현하는 것을 권장합니다. 이것이 바로 현대적인 SaaS 아키텍처가 지향하는 현실적이고도 강력한 전략입니다.

자주 묻는 질문과 답변

Q: 중복 데이터가 쌓이면 저장 공간 비용이 많이 들지 않나요?

A: 멱등성 로직을 잘 설계했다면, 중복 요청이 들어와도 데이터베이스에 실제로 저장되지 않거나 즉시 무시됩니다. 따라서 저장 공간 비용은 크게 걱정할 필요가 없습니다. 오히려 중복을 막기 위한 과도한 검증 로직이 비용을 발생시킬 수 있습니다.

Q: 멱등성을 구현하기 어려운 시스템은 어떻게 하나요?

A: 외부 API 연동 등 멱등성 구현이 불가능한 경우에는 ‘분산 락(Distributed Lock)’을 사용하여 특정 작업이 진행 중일 때 다른 요청이 들어오지 못하도록 제어할 수 있습니다. 다만, 락은 성능 저하를 유발할 수 있으므로 꼭 필요한 지점에만 제한적으로 사용해야 합니다.

Q: 최소 한 번 방식에서도 데이터가 영영 유실될 가능성이 있나요?

A: 메시지 브로커가 메시지를 영구 저장소(디스크)에 제대로 기록하지 못한 채 장애가 발생하면 유실될 수 있습니다. 이를 방지하기 위해서는 브로커의 ‘Ack(확인)’ 설정을 적절히 구성하여, 메시지가 안전하게 기록된 후에만 응답을 주도록 설정하는 것이 필수적입니다.

Q: 어떤 상황에서 정확히 한 번 방식이 필요한가요?

A: 금융 결제 시스템이나 원자력 발전소 제어 시스템처럼 단 한 번의 중복 처리도 치명적인 결과를 초래하는 특수한 상황에서는 ‘정확히 한 번’을 구현해야 합니다. 하지만 일반적인 비즈니스 SaaS라면 ‘최소 한 번’과 적절한 예외 처리가 훨씬 경제적이고 안전합니다.