왜 네트워크 요청은 불확실성으로 가득 차 있는가
분산 시스템 아키텍처에서 클라이언트와 서버 간의 통신은 결코 절대적으로 안정적일 수 없습니다. 사용자가 "결제" 버튼을 클릭했을 때 네트워크 지연이나 단절이 발생하면, 클라이언트는 요청이 서버에 정상적으로 수신 및 처리되었는지 확인할 수 없습니다. 이때 자동 재시도 메커니즘(Retry)이 개발자의 우선적인 방어 전략이 되지만, 동시에 "중복 실행"이라는 큰 우려를 안게 됩니다.
결제 요청이 서버 측에서 이미 처리되었음에도 불구하고 확인 메시지를 받는 과정에서 네트워크가 단절되면, 클라이언트는 응답을 받지 못해 두 번째 요청을 보냅니다. 시스템에 방어 메커니즘이 없다면 중복 결제나 데이터 불일치가 쉽게 발생합니다. "요청이 여러 번 실행되어도 시스템의 최종 상태는 한 번 실행된 경우와 동일하다"는 특성을 소프트웨어 공학에서는 "멱등성(Idempotency)"이라고 부릅니다.
멱등성의 저수준 메커니즘
멱등성의 핵심은 서버가 어떻게 "동일한 요청"을 식별하느냐에 있습니다. HTTP 프로토콜에서 GET, PUT, DELETE 메서드는 이론상 본질적으로 멱등성을 갖추고 있습니다. 요청을 몇 번 보내든 리소스 상태는 변하지 않아야 하기 때문입니다. 그러나 POST 요청은 이 특성이 없습니다. POST 요청에서 멱등성을 구현하려면 "멱등 키(Idempotency Key)"를 도입해야 합니다.
식별자 생성 로직
식별자는 보통 클라이언트가 요청을 보낼 때 생성하는 고유한 UUID나 업무 일련번호입니다. 서버가 요청을 수신하면 먼저 해당 식별자가 캐시(Redis 등)에 존재하는지 확인합니다. 만약 존재한다면, 두 번째 업무 로직 처리는 하지 않고 이전에 저장된 처리 결과를 바로 반환합니다. 이 메커니즘은 "실행"과 "조회"를 분리하여 트랜잭션의 안전성을 확보합니다.
일반적인 HTTP 메서드의 멱등성 차이 판단
모든 API에 엄격한 멱등성 설계가 필요한 것은 아닙니다. 개발자는 비즈니스 시나리오에 따라 평가해야 합니다. 다음 표는 각 HTTP 메서드의 멱등성 특성과 적용 시나리오를 보여줍니다.
| 메서드 | 멱등성 | 적용 시나리오 |
|---|---|---|
| GET | 예 | 데이터 조회, 리소스 획득 |
| PUT | 예 | 리소스 전체 업데이트 또는 덮어쓰기 |
| DELETE | 예 | 특정 리소스 삭제 |
| POST | 아니오 | 신규 리소스 생성, 결제 트랜잭션 |
| PATCH | 아니오 | 리소스 일부 업데이트 |
구현 전략: 요청 인터셉트에서 상태 캐시로
프로그램 개발에 들어가기 전에 표준 인터셉터 흐름을 구축하는 것을 권장합니다. 먼저 API Gateway 또는 Middleware 계층이 요청 헤더 내의 Idempotency-Key 필드를 해석할 수 있어야 합니다. 이 필드가 누락된 경우, 비멱등성 메서드에 대해서는 시스템이 수락을 거부하고 400 Bad Request를 반환함으로써 예상치 못한 중복 작업을 방지합니다.
구현 단계 체크리스트
- Idempotency-Key 요청 헤더 형식을 정의한다.
- 서버 측에서 키에 대한 잠금 메커니즘(분산 락)을 구축한다.
- Redis에 해당 키의 처리 상태가 존재하는지 확인한다.
- 상태가 "처리 중"이면 신규 요청을 거부하거나 잠금 해제를 기다린다.
- 상태가 "완료됨"이면 캐시 결과를 바로 반환한다.
- 기록이 없으면 업무 로직을 실행하고 결과와 상태를 저장한다.
흔히 발생하는 개발 오해
많은 개발자가 "데이터베이스에서 중복을 체크하면 멱등성이 된다"고 오해하지만, 이는 큰 잘못입니다. 데이터베이스 쿼리는 고비용 I/O를 동반하므로, 고병렬 환경에서 DB에만 의존하면 심각한 성능 병목 현상이 발생합니다. 올바른 접근은 고성능 인메모리 DB(Redis 등)를 첫 번째 방어선으로 사용하는 것입니다.
또 다른 흔한 실수는 "멱등성"과 "트랜잭션"을 혼동하는 것입니다. 트랜잭션은 작업의 원자성을 보장하고, 멱등성은 작업의 중복 안전성을 보장합니다. 분산 시스템에서 둘은 서로 보완하는 관계이지 대체할 수 있는 것이 아닙니다. 트랜잭션만 수행하고 멱등성을 무시하면 네트워크 불안정에 취약한 상태로 남게 됩니다.
예외 케이스와 상태 일관성 유지
서버가 업무 로직을 수행하던 중 크래시가 발생하여 상태 기록이 Redis에 쓰이기 전에 중단되었다면 어떻게 해야 할까요? 이는 "재시도 전략" 설계와 관련이 있습니다. "먼저 점유하고, 나중에 업데이트하는" 전략을 권장합니다. 업무 실행 전에 키를 쓰고 `PENDING`으로 표시합니다. 그 후 크래시가 발생해도 클라이언트가 재전송하면 서버는 해당 작업이 처리 중임을 인식할 수 있어 리소스 충돌을 피할 수 있습니다.
다음 단계: 시스템 탄력성 향상을 위하여
API가 완벽한 멱등성을 갖추면 시스템의 복원력은 크게 향상됩니다. 개발자는 "멱등성 실패"의 예외 처리에도 주목해야 합니다. 예를 들어 서버가 409 Conflict를 반환하여 키가 현재 처리 중임을 알렸을 때, 클라이언트는 어떻게 지수 백오프(Exponential Backoff) 알고리즘을 구현해야 할까요? 이는 기술 구현의 세부 사항일 뿐만 아니라 현대적이고 안정적인 API를 구축하기 위한 핵심 기술입니다.