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

데이터 처리의 이상향인 Exactly Once가 왜 기술적 난제인가

소프트웨어 엔지니어링과 데이터 파이프라인 설계를 접하다 보면 ‘Exactly-Once(정확히 한 번)’라는 용어를 자주 마주하게 됩니다. 직역하면 데이터가 시스템을 통과할 때 정확히 한 번만 처리되어야 한다는 뜻입니다. 예를 들어, 은행 계좌에서 돈을 이체할 때 100달러가 두 번 출금되거나 아예 처리되지 않는다면 큰일이 나겠죠. 그래서 많은 개발자는 “우리 시스템은 Exactly-Once를 보장해야 해”라고 말합니다.

하지만 냉정하게 말하자면, 네트워크 장애나 서버 오류가 발생하는 현실 세계의 분산 시스템에서 Exactly-Once를 완벽하게 구현하는 것은 수학적으로 불가능에 가깝습니다. 이것이 바로 Exactly-Once가 단순한 기술적 기능이 아니라, 비즈니스적 판단의 영역인 이유입니다.

Exactly Once가 비즈니스 결정인 이유

Exactly-Once를 구현하려면 시스템 복잡도가 기하급수적으로 증가합니다. 상태를 저장하고, 트랜잭션을 관리하며, 롤백을 처리하는 모든 과정에 비용이 발생합니다. 여기서 비즈니스 결정이 필요합니다. “우리가 이 정확성을 위해 얼마나 많은 비용을 지불할 준비가 되었는가?”라는 질문에 답해야 하기 때문입니다.

데이터가 한 번 더 처리되어도 큰 문제가 없는 로그 수집 시스템이나 추천 엔진이라면, 굳이 막대한 비용을 들여 Exactly-Once를 구현할 필요가 없습니다. 반면, 금융 거래나 재고 관리 시스템이라면 비용이 들더라도 반드시 달성해야 하는 목표가 됩니다. 즉, 정확도와 비용, 그리고 속도 사이의 트레이드오프를 결정하는 것은 개발자가 아니라 비즈니스의 우선순위입니다.

데이터 처리 보장 모델의 유형

시스템이 데이터를 처리하는 방식은 크게 세 가지로 나뉩니다. 각 모델은 비즈니스 요구사항에 따라 선택적으로 적용됩니다.

• At-Most-Once (최대 한 번): 데이터가 유실될 수 있지만 중복은 없습니다. 실시간성이 중요하고 데이터 일부 유실이 허용되는 센서 데이터 등에 쓰입니다.

• At-Least-Once (최소 한 번): 데이터가 중복될 수 있지만 유실은 없습니다. 대부분의 현대적인 메시지 큐 시스템이 기본으로 채택하는 방식입니다. 중복 처리를 방지하는 로직을 애플리케이션 단에서 구현해야 합니다.
• Exactly-Once (정확히 한 번): 유실도 없고 중복도 없습니다. 가장 이상적이지만 구현 난이도가 가장 높으며 시스템 성능에 오버헤드를 줍니다.

흔한 오해와 진실

많은 분이 “우리는 카프카(Kafka)나 플링크(Flink)를 쓰니까 Exactly-Once가 해결됐어”라고 생각합니다. 하지만 이는 큰 오해입니다. 인프라 수준에서 Exactly-Once를 지원하더라도, 데이터가 최종적으로 외부 데이터베이스에 기록되거나 외부 API를 호출하는 순간 연결 고리가 끊어집니다. 외부 시스템과의 결합에서 발생하는 데이터 정합성 문제는 시스템 외부의 비즈니스 로직이 해결해야 할 몫입니다.

또 다른 오해는 Exactly-Once가 성능 저하를 일으키지 않는다는 믿음입니다. 트랜잭션 관리와 상태 저장을 위해서는 추가적인 디스크 쓰기나 네트워크 통신이 필요합니다. 따라서 처리량(Throughput)은 필연적으로 감소하게 됩니다. 비즈니스 팀은 이 성능 저하를 감수할 것인지, 아니면 ‘멱등성(Idempotency)’이라는 우회 전략을 사용할 것인지 결정해야 합니다.

비용 효율적인 활용을 위한 실용적인 전략

Exactly-Once를 무조건 구현하려고 애쓰기보다 비즈니스 가치에 맞는 효율적인 전략을 취하는 것이 중요합니다.

멱등성 구현을 최우선으로 하세요

Exactly-Once의 대안이자 가장 강력한 도구는 멱등성입니다. 멱등성이란 동일한 작업을 여러 번 수행하더라도 결과가 처음과 같은 상태를 유지하는 성질을 말합니다. 예를 들어, ‘잔액을 100달러 증가시켜라’는 멱등하지 않지만, ‘잔액을 500달러로 설정하라’는 멱등합니다. 데이터 처리 로직을 멱등하게 설계하면, 시스템이 At-Least-Once 방식으로 작동하더라도 중복 처리에 의한 부작용을 원천 차단할 수 있습니다.

비즈니스 성격에 따른 차등 적용

모든 데이터에 동일한 정확도를 요구하지 마세요. 중요도가 낮은 데이터는 At-Least-Once로 처리하여 시스템 리소스를 아끼고, 결제나 인증과 같은 핵심 로직에만 리소스를 집중하는 것이 현명합니다.

모니터링과 복구 전략 수립

완벽한 시스템은 존재하지 않습니다. 장애 발생 시 데이터를 어떻게 추적하고, 중복된 데이터를 어떻게 사후에 정제할 것인지에 대한 운영 프로세스를 갖추는 것이 기술적 구현보다 훨씬 더 중요할 때가 많습니다.

전문가의 조언

분산 시스템을 설계하는 베테랑 엔지니어들은 “데이터가 중복되더라도 시스템이 망가지지 않게 만드는 것이, 데이터 중복을 원천적으로 막는 것보다 훨씬 쉽고 저렴하다”라고 입을 모읍니다. Exactly-Once를 구현하기 위해 복잡한 분산 트랜잭션(2PC 등)을 도입하는 것은 종종 재앙을 불러옵니다. 대신, 애플리케이션 레벨에서 ‘이미 처리된 요청인지 확인하는 테이블’을 두거나, 데이터에 고유한 키(Unique ID)를 부여하여 중복 처리를 방지하는 패턴을 활용하세요.

자주 묻는 질문과 답변

질문: Exactly-Once는 아예 불가능한 것인가요?

답변: 완벽하게 분리된 두 시스템 사이에서 Exactly-Once를 보장하는 것은 이론적으로 불가능합니다. 하지만 단일 시스템 내에서는 트랜잭션을 통해 달성 가능하며, 외부 시스템과 연결될 때는 멱등성 설계를 통해 ‘결과적으로’ Exactly-Once처럼 보이게 만들 수 있습니다.

질문: 성능을 희생하면서까지 Exactly-Once를 구현해야 할 기준은 무엇인가요?

답변: 해당 데이터가 유실되거나 중복될 경우 금전적 손실이 발생하거나 법적 규제 위반이 되는 경우입니다. 일반적인 분석용 데이터라면 At-Least-Once로도 충분합니다.

질문: 멱등성을 구현하는 가장 쉬운 방법은 무엇인가요?

답변: 모든 데이터에 고유한 ‘비즈니스 키’를 부여하는 것입니다. 예를 들어 주문 번호를 기준으로 처리 여부를 데이터베이스에 기록해두면, 같은 주문 번호가 다시 들어왔을 때 무시하도록 간단히 로직을 짤 수 있습니다.

업무 적용 가이드

지금 운영 중인 시스템에서 데이터 정확도 문제가 고민이라면 다음 순서대로 검토해 보시기 바랍니다.

• 데이터 유실이나 중복이 발생했을 때 비즈니스에 미치는 영향도를 수치화해 보세요.
• 현재 시스템이 At-Least-Once인지 확인하고, 중복이 발생할 경우 어떤 부작용이 있는지 리스트업하세요.
• 부작용을 막기 위해 멱등한 로직으로 변경할 수 있는지 검토하세요.
• 멱등성으로 해결되지 않는 아주 중요한 영역에 대해서만 고비용의 Exactly-Once 기술(예: 트랜잭션 지원 메시지 큐, 분산 데이터베이스의 원자적 연산 등)을 적용하세요.

기술은 비즈니스를 돕기 위해 존재합니다. Exactly-Once라는 용어에 매몰되어 기술적 완벽함만을 쫓기보다는, 우리 서비스의 성격에 맞는 최적의 정합성 수준을 찾아내는 것이 진정한 엔지니어링의 본질입니다.