Exactly-Once는 기능이 아니라 비즈니스 결정인 이유

정확히 한 번 처리가 단순한 기술적 목표가 아닌 이유

데이터 처리 시스템을 설계하거나 운영하는 엔지니어라면 한번쯤 ‘Exactly-Once’라는 용어를 들어보셨을 것입니다. 우리말로 ‘정확히 한 번 처리’라고 번역되는 이 개념은 데이터가 시스템을 통과할 때 누락되거나 중복되지 않고 오직 한 번만 반영되도록 보장하는 것을 의미합니다. 많은 개발자가 이를 기술적으로 완벽하게 구현하기 위해 복잡한 분산 트랜잭션이나 무거운 알고리즘을 도입하곤 합니다. 하지만 비즈니스 관점에서 보면 이 목표는 기술적 구현의 문제를 넘어, 비용과 효율 사이에서 내리는 고도의 비즈니스 결정입니다.

데이터 처리에서 정확히 한 번 처리가 중요한 이유

데이터 시스템에서 정확히 한 번 처리가 왜 그토록 갈망의 대상이 되는지 이해하려면 먼저 ‘왜 실패하는가’를 알아야 합니다. 네트워크 오류, 서버 다운, 메시지 중복 전송 등 분산 시스템에서 데이터 손실이나 중복은 불가피한 현상입니다. 만약 은행 계좌 이체 시스템에서 이 문제가 발생한다면 어떤 일이 벌어질까요? 돈이 두 번 빠져나가거나, 아예 전송되지 않는 상황은 비즈니스 신뢰도에 치명적인 타격을 줍니다. 따라서 정확히 한 번 처리는 단순한 성능 최적화가 아니라, 비즈니스 연속성과 데이터 무결성을 유지하기 위한 필수적인 안전장치입니다.

정확히 한 번 처리를 바라보는 흔한 오해와 진실

많은 이들이 ‘정확히 한 번 처리’를 시스템이 마법처럼 알아서 해주는 기능이라고 착각합니다. 하지만 실제로는 기술적 제약 때문에 100% 완벽한 구현은 이론적으로 매우 어렵습니다. 이와 관련된 대표적인 오해를 정리해 드립니다.

• 오해 1: 시스템 설정에서 Exactly-Once 옵션을 켜기만 하면 된다.

• 진실: 이는 데이터 소스, 처리 엔진, 그리고 최종 저장소(Sink)까지 모든 구간이 유기적으로 협력해야 가능한 결과입니다. 어느 한 곳이라도 지원하지 않으면 전체 시스템은 보장받지 못합니다.
• 오해 2: 정확히 한 번 처리는 언제나 비용 효율적이다.
• 진실: 정확히 한 번 처리를 달성하기 위해서는 상태 저장, 체크포인트 생성, 트랜잭션 관리 등 추가적인 오버헤드가 발생합니다. 이는 처리 속도 저하와 인프라 비용 상승으로 직결됩니다.
• 오해 3: 정확히 한 번 처리가 안 되면 시스템은 쓸모없다.
• 진실: 많은 경우 ‘최소 한 번 처리(At-least-once)’와 ‘멱등성(Idempotency)’을 조합하는 것만으로도 비즈니스 요구사항을 충분히 해결할 수 있습니다.

비즈니스 결정으로서의 정확히 한 번 처리

기술을 선택할 때는 항상 비용 대비 효과를 따져야 합니다. 정확히 한 번 처리를 구현하는 과정에는 상당한 개발 공수와 운영 비용이 투입됩니다. 따라서 기획 단계에서 다음과 같은 질문을 던져보아야 합니다.

• 데이터 중복이 발생했을 때 비즈니스적으로 치명적인가?
• 중복 데이터를 사후에 필터링하거나 보정하는 것이 더 저렴하지 않은가?
• 실시간성이 중요한가, 아니면 데이터의 정합성이 더 중요한가?

만약 데이터가 조금 중복되어도 나중에 배치 작업으로 쉽게 수정할 수 있다면, 굳이 복잡한 Exactly-Once 구조를 고집할 필요가 없습니다. 반대로 금융 거래나 실시간 재고 관리처럼 중복이 즉각적인 손실로 이어지는 경우에는 비용이 들더라도 이를 구현하는 것이 합리적인 비즈니스 결정이 됩니다.

실용적인 대안과 멱등성 설계의 힘

기술적으로 완벽한 ‘정확히 한 번’을 구현하기 어렵다면, 멱등성(Idempotency)을 설계에 도입하는 것이 가장 현명한 방법입니다. 멱등성이란 같은 연산을 여러 번 수행해도 결과가 달라지지 않는 성질을 말합니다. 예를 들어, ‘계좌에서 100원을 차감하라’는 명령 대신 ‘계좌 잔액을 900원으로 변경하라’는 명령을 내리면, 아무리 여러 번 처리해도 잔액은 900원으로 유지됩니다.

멱등성 구현을 위한 실무 팁

• 고유 식별자 활용: 모든 트랜잭션에 고유한 요청 ID를 부여하고, 데이터베이스에서 이 ID를 기반으로 중복 여부를 체크합니다.
• 상태 기반 업데이트: ‘더하기’ 방식보다는 ‘현재 상태를 지정’하는 방식을 사용합니다.
• 데이터베이스 제약 조건 활용: 고유 인덱스(Unique Index)를 사용하여 중복 레코드가 삽입되는 것을 원천 차단합니다.

비용 효율적인 활용 방법과 전략

모든 데이터 파이프라인에 최고 수준의 정합성을 적용하는 것은 예산 낭비입니다. 데이터의 성격에 따라 처리 전략을 다르게 가져가는 것이 효율적입니다.

데이터 성격별 전략 가이드

위와 같이 비즈니스 가치에 따라 데이터 처리 수준을 차등화하면 인프라 비용을 30% 이상 절감하면서도 비즈니스 요구사항을 만족시킬 수 있습니다. 무조건적인 기술 도입보다는 현재 우리 서비스가 감당할 수 있는 위험 수준을 먼저 정의하는 것이 중요합니다.

전문가의 조언

데이터 플랫폼 아키텍트들은 흔히 “완벽함을 추구하다가 시스템을 마비시키지 마라”고 조언합니다. 정확히 한 번 처리는 기술적인 성취감은 높여줄 수 있지만, 비즈니스 현장에서는 ‘빠르게 복구할 수 있는 시스템’이 더 가치 있을 때가 많습니다. 데이터가 중복되더라도 이를 식별하고 정제할 수 있는 도구를 갖추는 것이, 복잡한 분산 트랜잭션으로 시스템 전체를 묶어두는 것보다 운영 효율성 측면에서 훨씬 유리합니다.

자주 묻는 질문과 답변

Q: Kafka를 사용하면 정확히 한 번 처리가 자동으로 보장되나요?

A: Kafka는 트랜잭션 API를 통해 정확히 한 번 처리를 지원하지만, 이는 생산자(Producer)와 소비자(Consumer) 사이의 협력이 완벽할 때만 가능합니다. 데이터가 데이터베이스에 저장되는 시점까지 고려하면 추가적인 구현이 반드시 필요합니다.

Q: 데이터 중복을 완전히 막는 것이 불가능한가요?

A: 분산 시스템의 특성상 네트워크 장애는 언제든 발생할 수 있으므로, 완벽한 차단은 이론적으로 불가능합니다. 따라서 중복을 ‘막는 것’보다 중복이 발생했을 때 ‘어떻게 처리할 것인가’에 집중하는 것이 실무적으로 훨씬 효과적입니다.

Q: 정확히 한 번 처리를 위해 어떤 기술을 공부해야 하나요?

A: 분산 시스템의 합의 알고리즘(Raft, Paxos), 데이터베이스의 트랜잭션 격리 수준, 그리고 멱등성 패턴에 대해 공부하는 것을 추천합니다. 특히 분산 시스템에서의 장애 복구 메커니즘을 이해하는 것이 가장 큰 도움이 됩니다.

결국 정확히 한 번 처리는 기술적 도구들의 조합이 아니라, 우리 비즈니스가 데이터의 중복에 대해 얼마나 민감한지를 결정하는 경영적 판단의 문제입니다. 기술은 그 결정을 뒷받침하는 수단일 뿐입니다. 시스템의 복잡도를 높이기 전에, 혹시 비즈니스적으로 중복을 수용하거나 나중에 보정하는 것이 더 효율적이지 않은지 다시 한번 고민해 보시기를 권합니다.