Retry 정책이 데이터 정합성을 무너뜨린 경험

Retry 정책이 데이터 정합성을 위협하는 이유

소프트웨어 개발에서 Retry(재시도) 정책은 시스템의 회복 탄력성을 높이는 매우 강력한 도구입니다. 네트워크가 일시적으로 불안정하거나 외부 서비스가 잠시 응답하지 않을 때, 단순히 다시 요청을 보내는 것만으로도 서비스의 가용성을 크게 개선할 수 있기 때문입니다. 하지만 이러한 편리함 뒤에는 ‘데이터 정합성’이라는 거대한 함정이 숨어 있습니다. 무분별한 재시도는 시스템의 상태를 꼬이게 만들고, 결국 복구하기 어려운 데이터 오류를 유발합니다.

데이터 정합성이란 데이터가 서로 모순 없이 일관성을 유지하는 상태를 의미합니다. 예를 들어, 결제 시스템에서 사용자의 계좌에서 돈은 빠져나갔는데 주문 정보는 생성되지 않았거나, 중복으로 결제가 처리되는 상황이 대표적인 정합성 붕괴 사례입니다. 재시도 정책을 설계할 때는 단순히 ‘성공할 때까지 시도한다’는 접근을 넘어, ‘어떤 상황에서 재시도할 것인가’에 대한 철저한 고민이 필요합니다.

재시도 정책의 유형과 특성 이해하기

재시도 정책은 크게 몇 가지 방식으로 나뉩니다. 각 방식은 시스템의 부하와 데이터 안전성에 서로 다른 영향을 미칩니다.

• 즉시 재시도: 오류가 발생하자마자 바로 다시 요청합니다. 네트워크가 아주 짧게 끊겼을 때는 효과적이지만, 서버가 과부하 상태라면 오히려 장애를 심화시킵니다.

• 고정 간격 재시도: 일정한 시간 간격(예: 1초마다)을 두고 재시도합니다. 구현은 쉽지만, 여러 클라이언트가 동시에 재시도를 수행할 경우 특정 시점에 요청이 몰리는 ‘Thundering Herd’ 현상이 발생할 수 있습니다.
• 지수 백오프 재시도: 재시도할 때마다 대기 시간을 기하급수적으로 늘리는 방식입니다. (예: 1초, 2초, 4초, 8초…) 시스템에 가해지는 부담을 최소화하면서 성공 확률을 높이는 가장 권장되는 방식입니다.
• 지터 적용 재시도: 지수 백오프에 무작위 시간을 더하는 방식입니다. 모든 클라이언트가 동시에 재시도를 시작하지 않도록 분산시켜 서버의 부하를 효과적으로 조절합니다.

데이터 정합성을 무너뜨리는 치명적인 패턴

재시도가 데이터 정합성을 파괴하는 가장 흔한 경우는 ‘멱등성’을 보장하지 못할 때 발생합니다. 멱등성이란 동일한 요청을 여러 번 보내도 결과가 한 번만 보낸 것과 동일하게 유지되는 성질을 말합니다. 멱등성이 확보되지 않은 시스템에서 재시도를 수행하면 다음과 같은 문제가 발생합니다.

중복 데이터 발생 문제

사용자가 결제 버튼을 눌렀을 때 서버가 처리를 완료했지만, 응답이 사용자에게 도달하기 전 네트워크가 끊겼다고 가정해 봅시다. 클라이언트는 응답을 받지 못했으므로 재시도를 수행합니다. 이때 서버가 이전 요청과 동일한 결제임을 식별하지 못하면, 사용자의 계좌에서 두 번의 결제가 이루어집니다.

상태 불일치 문제

재시도 과정에서 일부는 성공하고 일부는 실패하는 경우입니다. 예를 들어, 데이터베이스에는 데이터가 저장되었으나 외부 API 호출에서 실패가 발생하여 재시도가 트리거될 수 있습니다. 이때 이미 저장된 데이터를 삭제하거나 수정하는 로직이 제대로 작동하지 않으면 시스템 내부에 유령 데이터가 남게 됩니다.

현명한 재시도 전략을 위한 실용적인 팁

재시도 정책을 안전하게 운영하기 위해서는 몇 가지 핵심적인 원칙을 준수해야 합니다. 기술적 부채를 줄이고 데이터 안전성을 지키는 방법은 다음과 같습니다.

• 멱등키 활용하기: 클라이언트가 요청을 보낼 때 고유한 식별값(Idempotency Key)을 함께 보냅니다. 서버는 이 키를 기록해두고, 동일한 키로 다시 요청이 오면 실제 로직을 수행하지 않고 이전에 처리했던 결과값을 즉시 반환합니다.

• 읽기 작업과 쓰기 작업 구분하기: 데이터를 조회하는 GET 요청은 재시도를 해도 안전하지만, 데이터를 생성, 수정, 삭제하는 POST, PUT, DELETE 요청은 훨씬 신중해야 합니다. 쓰기 작업에는 반드시 재시도 횟수 제한과 타임아웃 설정을 엄격하게 적용하세요.
• 비동기 처리와 상태 확인: 즉각적인 응답이 필요한 시스템이 아니라면, 요청을 큐(Queue)에 담아 비동기로 처리하는 것이 좋습니다. 비동기 환경에서는 재시도 로직을 더 세밀하게 제어할 수 있으며, 실패 시 알림을 보내 관리자가 수동으로 개입할 수도 있습니다.
• 서킷 브레이커 패턴 도입: 특정 서비스가 지속적으로 실패한다면, 재시도를 멈추고 시스템을 잠시 차단하는 서킷 브레이커를 사용하세요. 무조건적인 재시도는 장애를 겪고 있는 시스템에 ‘공격’을 가하는 것과 다름없습니다.

흔한 오해와 진실

재시도 정책에 대해 많은 개발자들이 오해하는 부분들이 있습니다.

첫째, ‘재시도를 많이 할수록 성공 확률이 높다’는 생각은 위험합니다. 대부분의 장애는 시스템 과부하로 발생합니다. 이때 재시도를 늘리는 것은 불난 집에 기름을 붓는 격입니다. 재시도 횟수는 항상 합리적인 한계 내에서 설정해야 합니다.

둘째, ‘서버 측에서 처리해주겠지’라는 안일한 태도입니다. 데이터 정합성은 클라이언트와 서버가 함께 책임져야 합니다. 클라이언트는 재시도 정책을 명확히 정의하고, 서버는 멱등성을 보장하는 API를 설계해야만 전체 시스템의 정합성이 유지됩니다.

비용 효율적인 재시도 아키텍처 설계

재시도를 무분별하게 사용하면 클라우드 비용이 급증할 수 있습니다. 불필요한 요청은 데이터 전송료와 API 호출 비용을 발생시키기 때문입니다. 비용 효율성을 높이려면 다음과 같은 전략을 고려하세요.

우선, 재시도 이전에 ‘검증’ 단계를 강화하세요. 요청이 잘못된 형식이라면 재시도를 해도 실패할 것이 뻔합니다. 이런 요청은 즉시 거절하여 불필요한 자원 낭비를 막아야 합니다. 또한, 재시도 로그를 수집하여 어떤 지점에서 가장 많은 재시도가 발생하는지 분석하세요. 특정 API에서 재시도가 빈번하다면, 그 부분의 로직을 최적화하거나 캐싱을 도입하여 시스템 부하를 줄이는 것이 장기적으로 훨씬 저렴합니다.

전문가의 제언

시스템 아키텍처를 설계하는 전문가들은 재시도를 ‘최후의 수단’으로 보라고 조언합니다. 가장 좋은 설계는 재시도가 필요 없는 구조입니다. 예를 들어, 데이터베이스의 트랜잭션을 활용하여 원자성(Atomicity)을 보장하거나, 상태 머신(State Machine)을 도입하여 데이터의 흐름을 명확하게 제어하는 방식입니다.

또한, 시스템이 실패했을 때 어떻게 ‘복구’할 것인지에 대한 설계가 우선되어야 합니다. 재시도는 복구 전략의 일부일 뿐, 전체가 되어서는 안 됩니다. 실패한 데이터를 추적하고 후속 처리를 할 수 있는 ‘Dead Letter Queue’를 활용하여 실패한 요청을 별도로 관리하는 습관을 들이는 것이 중요합니다.

자주 묻는 질문과 답변

Q: 재시도 횟수는 보통 몇 번이 적당한가요?

A: 비즈니스 성격에 따라 다르지만, 일반적으로 3회에서 5회 정도가 적당합니다. 5회 이상 시도해도 실패한다면, 이는 일시적인 오류가 아니라 서버 장애나 로직 오류일 가능성이 높으므로 사람이 개입하여 문제를 해결해야 합니다.

Q: 모든 API에 멱등키를 적용해야 하나요?

A: 반드시 그래야 하는 것은 아니지만, 결제, 주문 생성, 데이터 수정 등 데이터 정합성이 중요한 핵심 API에는 필수입니다. 조회용 API에는 굳이 멱등키를 적용할 필요가 없습니다.

Q: 지수 백오프와 지터는 왜 함께 사용해야 하나요?

A: 지수 백오프만 사용하면 특정 시간에 요청이 몰리는 현상이 여전히 발생할 수 있습니다. 여기에 지터(무작위성)를 추가하면 요청이 시간축으로 골고루 분산되어 서버가 안정적으로 요청을 처리할 수 있게 됩니다.

재시도 정책은 시스템의 생명줄과 같습니다. 하지만 그 줄을 어떻게 묶느냐에 따라 시스템을 살릴 수도, 혹은 시스템을 더 깊은 수렁으로 빠뜨릴 수도 있습니다. 오늘 살펴본 멱등성 보장, 지수 백오프와 지터의 활용, 그리고 무엇보다 재시도를 최소화하려는 설계 철학을 바탕으로 더 견고하고 데이터가 안전한 서비스를 구축하시길 바랍니다. 재시도는 기술의 문제이기도 하지만, 결국 데이터의 신뢰성을 지키기 위한 철저한 설계의 문제입니다.