엘리베이터 앞에서 버튼을 한 번 눌러 놓고도 불안해 몇 번 더 눌러 본 적이 있을 것입니다. 이미 불이 들어왔는데 또 눌러도 엘리베이터가 두 대 오지는 않습니다. 반대로 온라인 결제 창에서 버튼을 두 번 눌렀다가 두 번 결제될까 가슴을 졸인 적도 있을 것입니다. 같은 동작인데 한쪽은 안전하고 한쪽은 위험한 이유를 설명해 주는 개념이 바로 멱등성입니다.

멱등성(Idempotence)이란 어떤 동작을 한 번 하든 여러 번 하든 처음 한 번 한 결과에서 더 달라지지 않는 성질을 말합니다. 쉽게 말해 ‘다시 해도 이미 끝난 일이 더 커지지 않는다’는 뜻이며, 연결이 끊기고 요청이 중복되는 일이 잦은 컴퓨터 세계에서 특히 중요하게 다뤄집니다.

본 자료에서는 멱등성이라는 이름이 어디서 왔는지, 일상 속 사례는 어떻게 갈리는지, HTTP가 이 개념을 어떻게 약속으로 삼는지, 그리고 중복 요청을 안전하게 다루는 설계와 흔한 오해까지 차례로 살펴보겠습니다.

두 번 해도 한 번과 같은 동작의 이치

같은 힘이라는 뜻, 수학에서 건너온 이름

이 용어는 1870년 미국 수학자 벤저민 퍼스(Benjamin Peirce)가 선형 결합 대수(Linear Associative Algebra)를 다룬 글에서 만든 것으로 알려져 있습니다. ‘같다’는 뜻의 idem과 ‘힘’을 뜻하는 potence를 합친 말이어서 글자 그대로 ‘같은 힘을 가진’이라는 뜻입니다. 퍼스는 제곱하거나 더 높은 거듭제곱을 해도 자기 자신이 되는 대수적 대상에 이 이름을 붙였습니다.

(1) 수학적 정의
함수 f를 두 번 적용한 결과가 한 번 적용한 결과와 같다는 뜻으로, f(f(x)) = f(x)라고 씁니다.

(2) 대표적인 함수
절댓값, 소수점 아래를 버리는 내림 함수, 올림 함수, 입력을 그대로 돌려주는 항등 함수가 이런 성질을 갖습니다.

(3) 컴퓨터로 건너온 뜻
부수 효과가 있는 작업이라도 여러 번 호출한 뒤의 시스템 상태가 한 번 호출한 뒤와 같다면 멱등이라고 부릅니다.

여기서 눈여겨볼 점은 ‘응답이 같다’가 아니라 ‘상태가 더 바뀌지 않는다’가 기준이라는 것입니다. 이 차이를 놓치면 멱등성을 자꾸 다른 개념과 헷갈리게 됩니다.

일상의 버튼으로 가려 보는 멱등과 비멱등

엘리베이터 호출 버튼이나 횡단보도 버튼은 처음 누르면 ‘요청 중’ 상태가 되고, 그 요청이 처리되기 전까지 더 눌러도 아무 일도 일어나지 않습니다. 문 닫힘 버튼도 정해진 시간표대로 문이 닫히므로 몇 번을 눌러도 같습니다. 그러나 문 열림 버튼은 누를 때마다 기다리는 시간이 늘어나므로 멱등이 아닙니다.

• 조회(Lookup): 고객의 이름과 주소를 읽는 일은 데이터를 바꾸지 않으므로 멱등입니다.
• 설정(Assignment): 주소를 특정 값으로 바꾸라는 요청은 몇 번을 보내도 최종 주소가 같아 멱등입니다.
• 주문(Order Placement): 주문을 넣으라는 요청은 보낸 횟수만큼 주문이 생길 수 있어 멱등이 아닙니다.
• 취소(Cancellation): 특정 주문을 취소하라는 요청은 몇 번을 보내도 주문이 취소된 상태로 남아 멱등입니다.

같은 ‘버튼 누르기’라도 상태를 정해 주는 동작인지, 상태에 무언가를 더하는 동작인지에 따라 운명이 갈립니다.

HTTP가 정해 둔 메서드별 약속

웹의 규약인 HTTP의 표준 문서(RFC 9110)는 같은 요청을 여러 번 보냈을 때 서버에 미치는 의도된 효과가 한 번 보냈을 때와 같은 메서드를 멱등이라고 정의합니다.

(1) 읽기 요청
GET, HEAD, OPTIONS, TRACE는 읽기만 요청하는 안전한 메서드이며 모두 멱등입니다.

(2) PUT과 DELETE
PUT은 대상의 상태를 보낸 내용으로 정하고 DELETE는 대상을 지웁니다. 몇 번을 보내도 끝난 상태가 같으므로 멱등으로 규정됩니다.

(3) POST와 PATCH
POST는 내용을 어떻게 처리할지 받는 쪽에 맡기므로 두 번 보내면 주문이 두 건 생길 수 있습니다. PATCH도 멱등이 보장되지 않습니다.

이 구분이 실제로 쓰이는 곳은 재시도입니다. 연결이 끊겨 응답을 읽지 못했을 때 멱등한 요청은 클라이언트가 자동으로 다시 보내도 되지만, 멱등하지 않은 요청은 원래 요청이 적용되지 않았음을 알아낼 수단이 없다면 자동으로 재시도하지 않는 편이 바람직하다고 표준은 권고합니다. 또 멱등은 응답이 같다는 약속이 아니어서, 지우기를 두 번째 보내면 처음과 달리 ‘없음’ 응답이 돌아올 수 있어도 문제가 없습니다.

중복 요청을 다루는 설계와 흔한 오해

그렇다면 멱등이 아닌 POST를 어쩔 수 없이 다시 보내야 할 때는 어떻게 할까요? 널리 쓰이는 방법이 요청마다 고유한 값을 붙이는 멱등성 키입니다. 결제 서비스 스트라이프(Stripe)는 요청에 Idempotency-Key 헤더를 달 수 있게 했습니다. 키는 최대 255자이고 무작위 UUID 같은 값을 권장하며, 같은 키로 다시 온 요청에는 첫 요청의 상태 코드와 본문을 그대로 돌려줍니다. 키는 최소 24시간이 지나면 지워질 수 있고, 같은 키에 다른 내용이 오면 오류로 처리합니다. 메시지가 두 번 이상 도착해도 같은 결과를 내는 이벤트 처리 시스템도 같은 발상 위에 서 있습니다.

• 응답(Response): 멱등은 응답이 같다는 뜻이 아니라 서버의 상태가 더 바뀌지 않는다는 뜻입니다.
• 부수 효과(Side Effect): 서버가 요청 기록을 남기는 일까지 따지지는 않고 의도한 효과만 기준으로 삼습니다.
• 합성(Composition): 멱등한 단계를 이어 붙여도 전체가 멱등이라는 보장은 없습니다.
• 예시(Example): 변수가 3일 때 ‘읽기, 5로 바꾸기, 읽기’를 한 번 실행하면 3과 5가 나오고 두 번째에는 5와 5가 나옵니다.

두 번 눌러도 괜찮게 만드는 일은 사용자의 조심성에 기대는 대신 시스템이 스스로 안전해지도록 설계하는 일입니다. 다시 해도 같은 결과가 나오도록 처음부터 동작을 설계하는 마음, 그것이 멱등성의 첫걸음입니다.