멱등성
멱등성(Idempotency)에 관한 이해는 RESTful API 설계에서 매우 중요하다. 멱등성을 만족한다는 것은 같은 요청을 여러 번 반복해서 보내더라도 서버의 최종 상태가 변하지 않는다는 의미다. 예를 들어, ‘좋아요’를 추가하는 API가 멱등성을 지닌다면 PUT 요청을 여러 차례 보내더라도 ‘좋아요’ 상태는 한 번만 반영되어 변하지 않는다. 마찬가지로, DELETE 요청을 여러 번 보내더라도 ‘좋아요 해제’ 상태가 계속 유지된다.
RESTful API 원칙에 따르면, PUT 메서드는 리소스를 완전하게 대체하는 역할을 하며, 리소스가 없으면 생성하고 있으면 교체한다. 이러한 특성 덕분에 PUT은 멱등성을 자연스럽게 만족한다. DELETE 역시 멱등성을 가지는데, 리소스가 이미 삭제되었거나 존재하지 않아도 요청을 처리하고 동일한 결과를 반환한다는 점에서 멱등하다.
클라이언트 입장에서는 상태 변경 API를 설계할 때 멱등성을 보장하는 것이 명확한 상태 관리를 가능하게 한다. 예를 들어 toggleLike 방식은 현재 ‘좋아요’ 상태를 클라이언트가 알고 있어야 하며, 네트워크 지연이나 오류로 상태가 꼬일 위험이 크다. 반면, PUT과 DELETE를 구분하면 클라이언트가 ‘좋아요 추가’ 또는 ‘좋아요 해제’를 명확하게 요청할 수 있어 상태 불일치 문제를 예방할 수 있다.
네트워크 오류와 재시도 상황에서도 멱등성은 큰 장점으로 작용한다. 네트워크 환경은 불안정하여 클라이언트가 요청에 대한 응답을 받지 못할 때가 많다. 이 경우 클라이언트는 같은 요청을 재전송하는데, 멱등한 API라면 여러 번 요청을 보내도 서버 상태가 중복 변경되지 않아 일관성이 유지된다. 예를 들어 PUT /articles/1/like 요청을 여러 번 보내도 ‘좋아요’ 상태는 변함없지만, toggleLike API라면 상태가 계속 반전되어 혼란이 발생한다.
데이터 무결성 측면에서 비멱등 API는 중복 처리로 인해 문제가 발생할 수 있다. 은행 송금 API를 예로 들면, 비멱등 방식인 toggleTransfer()를 여러 번 호출하면 돈이 중복 이체될 수 있다. 반면 PUT /transfer와 같이 멱등성을 보장하는 API는 같은 요청을 여러 번 보내도 실제 이체는 한 번만 실행되어 중복 처리를 방지한다. ‘좋아요’ 시스템에서도 마찬가지로, toggleLike 방식은 예기치 않은 상태 변경을 유발하지만, PUT/DELETE 분리 방식을 사용하면 데이터 일관성을 확실히 유지할 수 있다.
또한 멱등한 API는 캐싱과 로드 밸런싱 측면에서 이점을 가진다. GET, PUT, DELETE와 같이 멱등성을 보장하는 메서드는 중간 프록시나 로드 밸런서가 요청을 복제하거나 재전송해도 서버 상태에 영향을 미치지 않는다. 따라서 이러한 요청은 효과적으로 캐싱될 수 있어 시스템 부하를 줄이고 성능을 최적화한다. 반면 POST와 같은 비멱등 요청은 반드시 신중히 다뤄야 하며, 무분별한 재전송이나 복제는 데이터 부정합이나 중복 생성 문제를 초래할 수 있다.
결론적으로, 멱등성을 지키는 API 설계는 다음과 같은 이점을 제공한다. 재시도 시에도 데이터 상태가 꼬이지 않고, RESTful 원칙을 준수해 클라이언트가 사용하기 쉬우며, 데이터 무결성을 보장해 중복 처리를 예방하고, 캐싱 및 로드 밸런싱 환경에서 효율적으로 동작한다. 따라서 특히 상태 변경이 있는 API, 예를 들어 ‘좋아요’, 결제, 예약 등에서는 멱등성을 반드시 보장하는 것이 안정적이고 예측 가능한 시스템 운영을 위해 필수적이다.
'Project > 기록' 카테고리의 다른 글
MySQL에서의 Lock 경합 문제 해결과 성능 개선 (1) | 2025.06.09 |
---|---|
Bullmq Document + CS 관점으로 다시 생각 (1) | 2025.06.05 |
비동기 아키텍처 전환 (0) | 2025.05.28 |
내 API는 실패할 수 있다 (0) | 2025.05.26 |
객체지향의 사실과 오해 - 2 (0) | 2025.05.10 |