CAP Theorem으로 보는 Exactly-Once의 한계

분산 시스템의 성배 Exactly Once와 CAP 정리의 충돌

현대 IT 서비스에서 데이터를 정확하게 처리하는 일은 가장 기본적이면서도 어려운 과제입니다. 특히 결제 시스템이나 재고 관리 시스템처럼 한 번의 거래가 정확히 한 번만 반영되어야 하는 상황에서 ‘Exactly Once(정확히 한 번 처리)’는 개발자들에게 꿈의 목표와 같습니다. 하지만 분산 시스템의 세계에는 이를 방해하는 강력한 법칙이 존재하는데, 바로 CAP 정리입니다. 이번 글에서는 왜 우리가 완벽한 Exactly Once를 구현하는 것이 이론적으로 불가능에 가까운지, 그리고 실무에서는 이를 어떻게 타협하고 해결하는지 깊이 있게 다뤄보겠습니다.

CAP 정리가 무엇인지 이해하기

CAP 정리는 분산 데이터 저장소가 세 가지 핵심 속성을 모두 동시에 만족할 수 없다는 이론입니다. 세 가지 속성은 다음과 같습니다.

• Consistency(일관성): 모든 노드가 동시에 같은 데이터를 보아야 합니다.

• Availability(가용성): 모든 요청은 성공 혹은 실패 응답을 즉시 받아야 합니다.
• Partition Tolerance(분할 내성): 네트워크 장애로 인해 노드 간 통신이 단절되어도 시스템은 운영되어야 합니다.

분산 환경에서는 네트워크 장애가 필연적으로 발생하므로, 우리는 사실상 C와 A 사이에서 하나를 선택해야 하는 상황에 놓입니다. Exactly Once는 데이터의 일관성을 유지하는 강력한 기법이지만, 네트워크 단절 상황에서 시스템 전체의 가용성을 포기하지 않고는 완벽하게 구현하기 매우 어렵습니다. 결국 Exactly Once를 추구하는 것은 일관성을 위해 가용성이나 성능을 희생하는 과정과 맞닿아 있습니다.

Exactly Once가 실무에서 어려운 이유

시스템 간에 데이터를 주고받을 때 ‘정확히 한 번’을 보장하려면 송신자와 수신자 사이에 완벽한 합의가 필요합니다. 하지만 현실은 녹록지 않습니다. 메시지를 보냈는데 네트워크가 끊겨 응답을 받지 못했다면, 송신자는 메시지가 성공적으로 전달되었는지 알 수 없습니다. 이 상황에서 송신자는 두 가지 선택을 해야 합니다.

• 메시지를 다시 보낸다(At Least Once): 중복 처리의 위험이 있습니다.
• 전송을 포기한다(At Most Once): 데이터 유실의 위험이 있습니다.

이것이 바로 분산 시스템의 딜레마입니다. 시스템은 ‘중복’과 ‘유실’ 사이에서 항상 줄타기를 해야 합니다. 완전한 Exactly Once는 시스템의 모든 구성 요소가 원자적(Atomic)으로 상태를 변경해야 하는데, 이는 분산 환경에서 엄청난 성능 저하를 불러옵니다.

실무에서 활용하는 멱등성 전략

완벽한 Exactly Once를 구현하는 대신, 실무에서는 ‘멱등성(Idempotency)’이라는 개념을 활용합니다. 멱등성이란 동일한 작업을 여러 번 수행하더라도 결과가 처음 수행한 것과 동일하게 유지되는 성질을 말합니다.

멱등성 구현을 위한 실용적인 팁

• 고유 키 생성: 모든 요청에 고유한 트랜잭션 ID를 부여합니다. 서버는 이 ID를 저장해두고 동일한 요청이 다시 들어오면 이미 처리된 작업으로 간주하여 무시합니다.
• 상태 기반 처리: 단순히 값을 더하는 대신, 현재 상태를 확인하고 필요한 경우에만 변경합니다. 예를 들어 ‘잔액을 100원 더해라’ 대신 ‘잔액이 500원일 때 600원으로 변경하라’는 식의 접근입니다.
• 분산 락 활용: 특정 데이터에 대해 락을 걸어 처리 중에는 다른 요청이 접근하지 못하게 합니다. 다만, 락은 가용성을 떨어뜨릴 수 있으므로 세심한 설계가 필요합니다.

흔한 오해와 진실

많은 이들이 Exactly Once를 시스템의 기능으로 오해하곤 합니다. 즉, “우리 메시지 큐 시스템은 Exactly Once를 지원하니까 안심해도 돼”라고 생각하는 것입니다. 하지만 이는 절반만 맞는 말입니다. 메시지 큐가 메시지를 한 번만 전달하더라도, 그 메시지를 받은 애플리케이션이 데이터베이스에 저장하는 과정에서 오류가 발생한다면 전체 프로세스는 결국 실패하게 됩니다. 따라서 Exactly Once는 특정 라이브러리의 기능이 아니라, 송신자부터 수신자, 그리고 저장소까지 이어지는 전체 파이프라인의 설계 철학이어야 합니다.

전문가가 제안하는 시스템 설계 조언

분산 시스템을 설계할 때 가장 중요한 것은 ‘완벽함’에 집착하지 않는 것입니다. 구글이나 아마존 같은 거대 기업들도 Exactly Once를 구현하기 위해 시스템 전체를 멈추는 대신, ‘At Least Once’를 기본으로 하고 이를 보완하는 ‘멱등성’ 전략을 사용합니다. 네트워크 장애가 발생했을 때 시스템이 중단되는 것보다는, 약간의 중복 처리를 허용하고 추후에 보정하는 것이 비즈니스 관점에서는 훨씬 효율적입니다.

또한, 데이터의 중요도에 따라 전략을 다르게 가져가야 합니다. 금융 거래처럼 절대로 중복이 허용되지 않는 데이터는 강력한 일관성을 보장하는 데이터베이스(RDBMS 등)를 사용하고, 로그 데이터처럼 약간의 중복이 큰 문제가 되지 않는 데이터는 가용성을 중시하는 분산 시스템을 사용하는 식의 차별화된 접근이 필요합니다.

자주 묻는 질문과 답변

Q: Exactly Once는 정말로 구현할 수 없나요?

A: 단일 시스템 내에서는 가능하지만, 여러 네트워크 노드를 거치는 분산 시스템에서는 이론적으로 매우 어렵습니다. 다만, 분산 트랜잭션(2PC, 3PC)이나 합의 알고리즘(Raft, Paxos)을 사용하면 유사하게 구현할 수 있으나, 이는 시스템의 성능을 매우 크게 희생시킵니다.

Q: 중복 처리를 막기 위해 데이터베이스에 매번 조회하는 것은 비용이 너무 크지 않나요?

A: 맞습니다. 이를 해결하기 위해 레디스(Redis)와 같은 인메모리 저장소를 사용하여 캐싱된 멱등 키를 확인하거나, 메시지 큐의 오프셋(Offset)을 활용하여 처리 상태를 효율적으로 관리하는 방법을 많이 사용합니다.

Q: 분산 시스템 설계 시 가장 먼저 고려해야 할 것은 무엇인가요?

A: CAP 정리 중 무엇을 포기할지 결정하는 것입니다. 비즈니스 요구사항에 따라 일관성이 중요한지, 아니면 장애가 나도 서비스가 멈추지 않는 것이 중요한지 먼저 비즈니스 가치를 정의해야 합니다.

비용 효율적인 시스템 운영 전략

기술적인 완벽함을 추구하기 위해 복잡한 분산 트랜잭션이나 고가의 솔루션을 도입하는 것은 종종 배보다 배꼽이 더 큰 상황을 만듭니다. 비용 효율적인 운영을 위해서는 다음의 단계적 접근을 권장합니다.

• 보상 트랜잭션 고려: 처리가 실패했을 때 원상복구하는 로직을 먼저 만듭니다. 이는 완벽한 Exactly Once보다 구현이 쉽고 실무에서 매우 효과적입니다.
• 비동기 처리와 멱등성 조합: 메시지를 비동기로 처리하되, 결과가 항상 멱등성을 유지하도록 설계하여 네트워크 장애에 강한 시스템을 구축합니다.
• 모니터링 강화: 완벽한 시스템은 없습니다. 중복이나 유실이 발생했을 때 이를 즉시 감지하고 알람을 주는 모니터링 시스템을 구축하는 것이, 100% 무결성을 보장하는 시스템을 만드는 것보다 비용 효율적일 때가 많습니다.

결국 분산 시스템에서 Exactly Once를 논하는 것은 기술적인 한계를 이해하고 그 안에서 비즈니스적인 타협점을 찾는 과정입니다. CAP 정리가 제시하는 제약 사항을 명확히 이해하고, 멱등성이라는 무기를 활용한다면, 여러분의 시스템은 훨씬 더 견고하고 유연해질 것입니다. 기술은 완벽할 수 없지만, 그 기술을 다루는 우리의 설계는 충분히 완벽에 가까워질 수 있습니다.