Exactly-Once보다 Idempotency를 선택한 이유

분산 시스템에서 완벽함보다 유연함을 선택하는 전략

현대적인 소프트웨어 아키텍처, 특히 마이크로서비스나 클라우드 기반의 분산 시스템을 설계할 때 가장 자주 마주치는 난제 중 하나는 데이터의 일관성입니다. 네트워크는 불안정하고 서버는 언제든 다운될 수 있습니다. 이런 환경에서 데이터를 주고받을 때 ‘정확히 한 번(Exactly-Once)’ 전달을 보장하려는 시도는 매우 고통스럽고 비용이 많이 드는 작업입니다. 그래서 많은 실무자는 ‘멱등성(Idempotency)’이라는 개념을 도입하여 이 문제를 해결합니다. 왜 우리는 완벽한 전달을 포기하고 멱등성을 선택하는지, 그리고 이것이 왜 실무에서 더 강력한 전략인지 상세히 살펴보겠습니다.

정확히 한 번 전달이라는 환상

정확히 한 번 전달은 이론적으로는 완벽해 보입니다. 메시지를 보내면 반드시 한 번만 도착하고, 시스템은 이를 단 한 번만 처리하는 상태를 의미합니다. 하지만 분산 시스템의 세계에서 이는 달성하기 매우 어렵습니다. 메시지를 보내는 쪽과 받는 쪽 사이에는 수많은 네트워크 노드가 존재하며, 응답이 오지 않았을 때 이것이 메시지가 전달되지 않은 것인지, 아니면 처리는 되었는데 응답만 유실된 것인지 구분할 방법이 없기 때문입니다. 이를 해결하기 위해 분산 트랜잭션이나 복잡한 합의 알고리즘을 사용하면 시스템의 성능은 급격히 떨어지고 복잡도는 기하급수적으로 증가합니다.

반면 멱등성은 ‘어떤 연산을 여러 번 수행하더라도 결과가 처음 한 번 수행한 것과 동일하다’는 성질을 의미합니다. 즉, 중복 전달이 발생해도 시스템이 이를 무시하거나 이미 처리된 것으로 간주하여 안전하게 넘어갈 수 있게 만드는 설계 방식입니다. 이는 시스템을 훨씬 단순하고 견고하게 만듭니다.

멱등성을 구현하는 실질적인 방법들

멱등성을 도입하기 위해서는 시스템 설계 단계에서 몇 가지 전략을 적용해야 합니다. 가장 널리 쓰이는 방법들을 정리했습니다.

• 고유 식별자 활용: 클라이언트가 요청을 보낼 때마다 고유한 아이디(예: UUID)를 함께 전송합니다. 서버는 이 아이디를 데이터베이스의 고유 제약 조건으로 저장하여, 동일한 아이디의 요청이 들어오면 이미 처리된 것으로 간주하고 무시합니다.

• 상태 기반 처리: 현재 시스템의 상태를 확인한 후 연산을 수행합니다. 예를 들어 ‘결제 승인’ 요청이 들어왔을 때, 주문 상태가 이미 ‘결제 완료’라면 추가 작업을 하지 않고 성공 응답만 반환하는 방식입니다.
• 낙관적 락: 데이터의 버전을 관리하여, 요청 시 보낸 버전 정보와 데이터베이스의 현재 버전이 일치할 때만 업데이트를 수행합니다. 버전이 다르면 이미 수정된 것으로 간주합니다.
• 데이터베이스 제약 조건: 데이터베이스의 유니크 키(Unique Key) 기능을 활용하면 중복 데이터를 원천적으로 차단할 수 있습니다. 가장 비용이 적게 들면서도 확실한 방법입니다.

실생활에서 찾아보는 멱등성 사례

우리가 일상에서 사용하는 서비스들에도 멱등성의 원리가 깊숙이 숨어 있습니다. 가장 대표적인 예는 결제 시스템입니다. 사용자가 결제 버튼을 실수로 두 번 눌렀을 때, 돈이 두 번 빠져나간다면 큰 문제가 됩니다. 결제 서버는 내부적으로 결제 요청에 대한 고유한 주문 번호를 생성하고, 이 번호가 이미 처리되었는지 검사함으로써 중복 결제를 방지합니다.

또 다른 예는 API 호출입니다. 우리가 웹 페이지를 새로고침할 때 브라우저가 ‘양식 제출을 다시 하시겠습니까?’라고 묻는 경우가 있습니다. 이는 POST 요청이 멱등성을 보장하지 않을 수 있기 때문입니다. 반면 GET 요청은 데이터를 조회만 하므로 여러 번 수행해도 상태가 변하지 않아 멱등성을 가집니다. 현대의 API 설계에서는 POST 요청에도 클라이언트가 생성한 고유 키를 포함시켜 멱등성을 부여하는 것이 표준으로 자리 잡고 있습니다.

멱등성 도입 시 흔히 하는 오해와 사실

멱등성을 도입하면 시스템이 무조건 느려질 것이라고 생각하는 분들이 많습니다. 하지만 실제로는 정반대입니다. ‘정확히 한 번’을 보장하기 위해 네트워크 전체를 잠그거나 복잡한 2단계 커밋(2PC)을 사용하는 것보다, 데이터베이스에 인덱스를 하나 추가하고 상태를 확인하는 것이 훨씬 빠르고 효율적입니다.

또 다른 오해는 ‘멱등성은 쓰기 작업에만 필요하다’는 생각입니다. 물론 데이터 변경이 일어나는 쓰기 작업에서 더 중요하지만, 조회 작업에서도 데이터가 실시간으로 변하는 환경이라면 멱등성 개념을 활용해 일관된 결과를 얻는 것이 중요합니다. 멱등성은 단순한 기술적 기교가 아니라, 시스템의 신뢰성을 높이는 설계 철학입니다.

비용 효율적인 시스템 설계를 위한 전문가의 조언

시스템을 설계할 때 모든 곳에 완벽을 기하려 하지 마세요. 비용 효율적인 설계를 위해서는 ‘멱등성을 적용할 대상’을 선별하는 것이 중요합니다. 모든 API에 고유 식별자를 생성하고 상태를 체크하는 로직을 넣는 것은 과도한 엔지니어링이 될 수 있습니다.

• 중요도에 따른 분리: 결제, 재고 차감, 데이터 변경 등 금전적 손실이나 데이터 오염이 발생할 수 있는 핵심 프로세스에만 멱등성을 우선 적용하세요.
• 보상 트랜잭션 활용: 멱등성만으로 해결되지 않는 복잡한 프로세스는, 실패 시 이전 상태로 되돌리는 보상 트랜잭션(Saga 패턴 등)과 조합하여 사용하세요.
• 로그와 모니터링: 중복 요청이 들어왔을 때 이를 단순히 무시하는 것이 아니라, 로그를 남겨서 시스템이 어떤 공격이나 오류를 방어하고 있는지 가시화해야 합니다.

멱등성 구현을 위한 체크리스트

개발자가 멱등성을 구현할 때 반드시 고려해야 할 항목들을 체크리스트로 정리했습니다. 이 항목들을 검토하는 것만으로도 시스템의 안정성을 크게 높일 수 있습니다.

• 요청에 유일성을 보장하는 식별자(Idempotency-Key)가 포함되어 있는가?
• 데이터베이스의 유니크 제약 조건을 통해 중복 삽입을 방지하고 있는가?
• 요청이 여러 번 들어왔을 때, 이전 요청의 결과값(응답)을 캐싱하여 재사용할 수 있는가?
• 비즈니스 로직이 상태 변화를 확인하고 안전하게 동작하는가?
• 네트워크 타임아웃 발생 시 클라이언트가 재시도할 수 있는 환경인가?

멱등성이 가져오는 운영의 이점

멱등성을 선택하면 운영 측면에서도 큰 이득을 얻을 수 있습니다. 첫째, 네트워크 오류나 일시적인 서비스 장애 상황에서 클라이언트가 부담 없이 재시도를 할 수 있습니다. 이는 장애 복구 시간을 획기적으로 단축시킵니다. 둘째, 시스템의 상태가 모호해질 가능성이 낮아집니다. 모든 연산이 ‘이미 처리되었거나, 지금 처리하거나, 아직 처리되지 않았거나’ 중 하나로 명확히 정의되기 때문입니다.

마지막으로, 분산 시스템에서의 디버깅이 훨씬 쉬워집니다. 중복 요청으로 인한 데이터 오염을 걱정할 필요가 없기 때문에, 발생한 오류가 로직의 문제인지 네트워크의 문제인지 더 빠르게 파악할 수 있습니다. 멱등성은 단순히 기술적인 선택을 넘어, 불안정한 환경에서 시스템을 지속 가능하게 유지하는 가장 현실적이고 강력한 도구입니다.