Exactly-Once 구현 비용을 계산해 본 결과

데이터 처리의 성배인 Exactly Once를 구현할 때 고려해야 할 비용과 현실

소프트웨어 엔지니어링과 데이터 아키텍처 분야에서 가장 이상적이면서도 구현하기 까다로운 개념 중 하나가 바로 ‘Exactly-Once(정확히 한 번)’ 처리입니다. 데이터가 유실되지도 않고, 중복되지도 않으며 오직 한 번만 처리되는 상태를 의미합니다. 하지만 현실 세계의 분산 시스템에서 이를 완벽하게 구현하는 것은 단순히 기술적인 문제를 넘어 엄청난 비용과 복잡성을 동반합니다. 이 글에서는 Exactly-Once를 구현하려는 시도가 왜 비용이 많이 드는지, 그리고 어떤 관점에서 접근해야 실용적인지 상세히 살펴보겠습니다.

Exactly Once가 무엇이며 왜 중요한가

Exactly-Once란 데이터가 전송되는 과정에서 네트워크 오류, 서버 장애, 프로세스 중단 등 어떠한 예외 상황이 발생하더라도 해당 데이터가 시스템 내부에서 정확히 한 번만 처리됨을 보장하는 속성입니다. 금융 거래, 재고 관리, 광고 과금 시스템처럼 데이터의 정합성이 곧 비즈니스의 신뢰도와 직결되는 분야에서는 이 개념이 필수적입니다.

만약 데이터가 한 번도 처리되지 않는다면(At-least-once의 부작용 또는 데이터 유실) 고객은 결제 완료 메시지를 받지 못할 것이고, 반대로 두 번 처리된다면(At-least-once의 중복 발생) 고객은 같은 금액을 두 번 결제하는 치명적인 오류를 겪게 됩니다. 따라서 시스템의 신뢰성을 유지하기 위해 개발자들은 Exactly-Once를 구현하고자 노력합니다.

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

• At-most-once (최대 한 번): 데이터가 유실될 수 있지만 중복은 발생하지 않습니다. 속도가 매우 빠르지만 데이터 정합성이 중요하지 않은 로그 수집 등에 사용됩니다.
• At-least-once (최소 한 번): 데이터가 유실되지 않지만 중복 처리가 발생할 수 있습니다. 가장 흔한 방식이며, 중복을 애플리케이션 단에서 처리하기 위해 멱등성(Idempotency) 로직이 필요합니다.
• Exactly-once (정확히 한 번): 데이터 유실도 없고 중복도 없습니다. 이론상 완벽하지만 시스템 복잡도가 급격히 상승합니다.

Exactly Once 구현이 비싼 이유

많은 이들이 오해하는 것 중 하나가 Exactly-Once를 ‘기능’이나 ‘옵션’으로 생각하는 것입니다. 하지만 이는 시스템 전반의 상태를 동기화해야 하는 ‘상태 관리’의 영역입니다. 구현 비용이 높은 이유는 다음과 같습니다.

1. 분산 트랜잭션의 복잡성

여러 서비스에 걸쳐 데이터를 처리할 때, 데이터베이스와 메시지 큐, 그리고 애플리케이션 서버 간의 상태를 원자적으로(Atomic) 유지해야 합니다. 이를 위해 2단계 커밋(2PC)이나 분산 락(Lock)을 사용하는데, 이는 전체 시스템의 처리량(Throughput)을 심각하게 저하시키고 병목 현상을 유발합니다.

2. 네트워크 지연과 오버헤드

메시지를 보낼 때마다 수신 확인(ACK)을 기다리고, 처리 완료 여부를 기록하는 과정에서 네트워크 왕복 횟수가 늘어납니다. 이는 초당 수만 건을 처리해야 하는 대규모 시스템에서 응답 속도를 늦추는 주범이 됩니다.

3. 상태 저장소의 유지 관리

데이터가 처리되었는지 여부를 확인하기 위해 ‘처리된 ID’를 저장하는 별도의 저장소가 필요합니다. 이 저장소 또한 장애가 나지 않아야 하므로 고가용성 설계를 해야 하며, 시간이 지날수록 쌓이는 처리 로그를 관리하는 비용도 만만치 않습니다.

흔한 오해와 사실 관계

오해: 카프카(Kafka) 같은 최신 메시징 시스템을 쓰면 Exactly-Once가 자동으로 해결된다.

사실: 카프카는 ‘카프카 내부’에서의 Exactly-Once를 지원하지만, 카프카와 외부 시스템(데이터베이스 등)을 연결할 때는 여전히 개발자의 노력이 필요합니다. 외부 시스템이 멱등성을 지원하지 않는다면, 카프카가 아무리 완벽해도 전체 파이프라인의 Exactly-Once는 보장되지 않습니다.

오해: Exactly-Once를 구현하면 모든 데이터 문제는 해결된다.

사실: Exactly-Once는 중복과 유실을 막을 뿐, ‘처리 로직의 오류’까지 막아주지는 않습니다. 만약 데이터 처리 코드 자체에 버그가 있다면, 잘못된 데이터가 정확히 한 번 처리될 뿐입니다.

비용 효율적인 활용 방법과 전문가의 조언

모든 시스템에 Exactly-Once를 적용하는 것은 과잉 설계(Over-engineering)일 가능성이 높습니다. 전문가들은 무조건적인 Exactly-Once 구현보다는 멱등성(Idempotency)을 통한 우회를 강력히 권장합니다.

멱등성을 활용한 효율적 설계

멱등성이란 같은 연산을 여러 번 수행해도 결과가 달라지지 않는 성질을 말합니다. 예를 들어, ‘잔액을 100원 더한다’는 연산은 멱등하지 않지만, ‘잔액을 1100원으로 업데이트한다’는 연산은 멱등합니다. 시스템 설계 시 데이터를 처리할 때 고유한 트랜잭션 ID를 부여하고, 이미 처리된 ID라면 무시하거나 결과를 재전송하도록 설계하면 Exactly-Once와 동일한 효과를 낼 수 있습니다.

데이터 처리 전략 요약표

실생활에서의 활용 예시

결제 시스템을 예로 들어보겠습니다. 결제 서버가 결제 완료 신호를 보낸 후, 네트워크 장애로 인해 메시지가 다시 전송될 수 있습니다. 이때 서버가 멱등성을 구현하지 않았다면 고객은 두 번 결제됩니다. 하지만 주문번호를 키(Key)로 활용하여 데이터베이스에 유니크 제약 조건을 걸어두면, 두 번째 중복 요청은 데이터베이스에서 거부하게 됩니다. 이것이 바로 기술적으로 가장 비용 효율적인 Exactly-Once 구현 방식입니다.

자주 묻는 질문과 답변

Q: Exactly-Once는 반드시 필요한가요?

A: 아닙니다. 데이터 정합성이 비즈니스에 치명적인 경우에만 선택적으로 사용해야 합니다. 로그 수집이나 일반적인 통계 데이터 처리라면 At-least-once와 후처리를 조합하는 것이 비용 면에서 훨씬 유리합니다.

Q: 멱등성 구현이 불가능한 로직은 어떻게 하나요?

A: 그런 경우에는 분산 트랜잭션이나 아웃박스(Outbox) 패턴을 고려해야 합니다. 아웃박스 패턴은 데이터베이스 변경과 메시지 발행을 하나의 트랜잭션으로 묶어 데이터 유실을 방지하는 기술로, Exactly-Once의 대안으로 널리 사용됩니다.

Q: 하드웨어 성능을 높이면 구현 비용을 상쇄할 수 있나요?

A: 하드웨어 성능 향상은 일시적인 해결책일 뿐입니다. 분산 시스템의 복잡성은 데이터 양이 늘어날수록 기하급수적으로 증가하므로, 소프트웨어 아키텍처 수준에서의 효율적인 설계가 무엇보다 중요합니다.

성공적인 설계를 위한 실무 팁

• 데이터 식별자를 명확히 하세요: 모든 이벤트에 고유한 UUID를 부여하는 것만으로도 나중에 데이터 중복을 검사하기가 훨씬 쉬워집니다.
• 비동기 처리를 지양할 때를 구분하세요: 정합성이 최우선인 로직은 동기 방식으로 처리하고, 그 외에는 비동기로 처리하여 시스템 전체의 부하를 분산하세요.
• 모니터링을 강화하세요: 중복 데이터가 발생하는지, 혹은 데이터 유실이 있는지 실시간으로 탐지할 수 있는 대시보드를 구축하는 것이 시스템을 완벽하게 만드는 것보다 더 중요할 때가 많습니다.
• 단계적 접근을 하세요: 처음부터 완벽한 Exactly-Once를 노리기보다, At-least-once 환경에서 멱등성을 확보하는 것부터 시작해 점진적으로 정합성을 높이는 방향으로 시스템을 고도화하세요.

결국, Exactly-Once 구현은 시스템이 감당해야 할 비용과 비즈니스가 얻는 이익 사이의 균형을 맞추는 과정입니다. 기술 자체의 화려함에 매몰되기보다는, 우리 시스템의 비즈니스 도메인에 가장 적합한 신뢰성 보장 모델이 무엇인지 고민하고, 그에 맞는 가장 경제적인 구현 방식을 선택하는 지혜가 필요합니다.