<div id="readability-page-1" class="page"><article id="post-145">
	<div>
	<p><img fetchpriority="high" decoding="async" src="https://notforme.kr/wp-content/uploads/2025/04/%EC%8B%A4%EB%AC%B4%EC%97%90-%EB%B0%94%EB%A1%9C-%EC%93%B0%EB%8A%94-%EB%A9%B1%EB%93%B1%EC%84%B1-%EA%B0%80%EC%9D%B4%EB%93%9C-REST-API-%EC%84%A4%EA%B3%84%EC%97%90%EC%84%9C-%EC%8B%A4%EC%88%98%ED%95%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EB%B2%95.png" alt="" width="1536" height="1024" sizes="(max-width: 1536px) 100vw, 1536px"></p>
<h2>멱등성이란 무엇인가요? 한 번이든 백 번이든, 결과는 같아야 합니다</h2>
<p>혹시 ‘멱등성(Idempotency)’이라는 단어를 처음 들으셨을 때, 무슨 마법 주문 같다는 느낌 안 드셨나요? 개발자들 사이에선 꽤나 자주 등장하지만, 생소한 단어죠. 하지만 REST API를 설계할 때 이 개념은 마치 튼튼한 기초공사처럼 굉장히 중요한 역할을 합니다. 멱등성은 간단히 말하면, 어떤 연산을 한 번 수행했든, 열 번 반복했든, 그 결과가 항상 동일해야 한다는 개념입니다. 예를 들어, 계좌 이체를 한 번 했는데 네트워크가 끊겨서 같은 요청을 또 보냈다고 가정해 보겠습니다. 이게 멱등하지 않다면 계좌에서 돈이 중복으로 빠져나가겠죠? 큰일 납니다. 멱등성은 바로 이런 ‘의도하지 않은 중복 처리’를 방지하기 위해 등장한 개념입니다. HTTP 메서드 중에서도 GET, PUT, DELETE는 기본적으로 멱등하게 설계되어 있습니다. 하지만 POST는 멱등하지 않기 때문에 특별히 신경 써서 다뤄야 하죠. 왜 이런 차이가 있는지, 그리고 실무에서 어떤 식으로 이를 설계에 녹여야 하는지, 지금부터 10가지 포인트로 하나씩 살펴보겠습니다.</p>
<h2>1. 멱등성과 안전성은 다릅니다 — 혼동하지 마세요</h2>
<p>많은 분들이 멱등성과 안전성(safety)을 헷갈려 하시더라고요. 둘 다 ‘여러 번 요청해도 괜찮다’는 맥락에서 등장하긴 하지만, 사실은 완전히 다릅니다. 안전성은 서버의 상태나 리소스에 아무런 영향도 주지 않는 요청을 의미합니다. 대표적으로 GET 요청이 있죠. 반면, 멱등성은 요청을 여러 번 하더라도 결과가 같기만 하면 되는 겁니다. PUT이나 DELETE가 여기에 해당합니다. 예를 들어, 동일한 데이터를 PUT으로 업데이트하면, 몇 번을 보내든 서버의 최종 상태는 동일하죠. 하지만 리소스 상태는 분명히 변합니다. 이런 차이를 명확히 이해하지 못하면 API 설계에서 큰 오류를 범할 수 있습니다. 안전하고 멱등한 API가 이상적이긴 하지만, 두 속성은 결코 같지 않다는 점을 꼭 기억하셔야 합니다.</p>
<h2>2. POST 요청의 멱등성을 어떻게 보장할 수 있을까요?</h2>
<p>POST는 기본적으로 멱등하지 않은 요청입니다. 왜냐하면 새로운 리소스를 생성하는 데 주로 쓰이기 때문이죠. 예를 들어 주문을 생성하거나 결제를 요청할 때 POST를 사용합니다. 그런데 사용자가 동일한 POST 요청을 두 번 보내면 어떻게 될까요? 같은 주문이 두 번 생성되거나 결제가 두 번 이루어질 수 있습니다. 이걸 막기 위해 등장한 것이 바로 ‘멱등 키(Idempotency Key)’입니다. 클라이언트는 요청을 보낼 때 고유한 키를 함께 전송하고, 서버는 이 키를 기반으로 요청을 식별해서 이미 처리된 요청이라면 응답만 재전송하고, 중복 처리를 하지 않도록 설계합니다. 멱등 키는 단순하지만 강력한 해결책입니다. 특히 금융, 결제, 의료처럼 민감한 데이터를 다루는 API에서는 필수적인 보호장치가 됩니다.</p>
<h2>3. 클라이언트에게 멱등성을 위임하지 마세요</h2>
<p>서버 개발을 하다 보면 이런 유혹이 생길 수 있습니다. “그냥 클라이언트에서 알아서 중복 요청 안 보내게 처리하라고 하면 되지 않을까?” 하지만 현실은 그렇게 단순하지 않습니다. 네트워크는 예측 불가능하고, 사용자 행동도 마찬가지죠. 버튼을 두 번 누르거나, 브라우저가 자동으로 요청을 재전송하는 경우도 있습니다. 클라이언트에 멱등성 보장을 맡겨두면, 결국 버그와 사고의 책임도 클라이언트 쪽에 넘어가게 됩니다. 그러니 서버는 가능한 한 자체적으로 멱등성을 보장해야 합니다. 서버에서 요청을 식별하고, 처리 여부를 캐싱하거나 로그로 관리하는 게 훨씬 안정적이고 신뢰도 높은 설계 방식입니다.</p>
<h2>4. 멱등 키는 어디에 저장해야 할까요?</h2>
<p>멱등 키를 쓰기로 했다면, 그 다음 고민은 저장입니다. 키가 서버로 날아왔을 때, 서버는 이전에 같은 키가 있었는지 찾아야 하죠. 보통은 데이터베이스에 저장하거나, Redis와 같은 인메모리 캐시 시스템을 활용합니다. 특히 Redis는 속도가 빠르고 TTL 설정도 가능해서 멱등 키 관리에 매우 적합합니다. 단, 저장소를 구성할 때는 몇 가지 유의할 점이 있습니다. 첫째, 키의 유효기간을 정해 과도한 리소스 낭비를 막아야 합니다. 둘째, 키와 응답 결과를 함께 저장해, 요청이 재전송됐을 때 같은 응답을 줄 수 있도록 해야 합니다. 이렇게 멱등 키 관리 전략까지 갖춘다면, 보다 안정적이고 예측 가능한 API를 설계할 수 있습니다.</p>
<h2>5. 에러 코드도 멱등하게 처리되어야 합니다</h2>
<p>API에서 에러가 발생했을 때, 멱등성 설계를 무시하면 낭패를 볼 수 있습니다. 예를 들어, 클라이언트가 같은 POST 요청을 두 번 보냈고, 서버는 첫 번째 요청에 대해 성공 응답을 보냈습니다. 그런데 두 번째 요청에서는 “이미 처리됨”이라는 에러를 반환한다면 어떨까요? 이건 멱등하지 않은 동작입니다. 왜냐하면 클라이언트 입장에서는 같은 요청에 대해 다른 응답을 받은 셈이니까요. 이상적인 설계는 두 번째 요청에도 첫 번째와 동일한 성공 응답을 보내는 것입니다. 물론 내부적으로는 에러지만, 외부에서는 멱등성을 유지하기 위해 같은 결과를 보여줘야 합니다. 이게 바로 사용자 경험까지 고려한 세심한 설계입니다.</p>
<h2>6. 시간 기반 중복 방지는 완전하지 않습니다</h2>
<p>간혹 일부 시스템에서는 “같은 IP나 같은 요청이 5초 이내에 다시 들어오면 중복 처리로 간주하자”는 식의 시간 기반 방식을 채택하기도 합니다. 물론 나름의 효과는 있습니다. 하지만 완전한 멱등성 보장은 절대 아니죠. 클라이언트 환경이나 네트워크 상태에 따라 요청이 몇 초 늦게 도착할 수도 있고, 진짜로 다른 사용자가 우연히 같은 요청을 보내는 경우도 있습니다. 시간 기반의 중복 방지는 보조 수단일 뿐, 정확한 요청 식별과 저장, 그리고 응답 재사용이 핵심입니다. 멱등성을 진지하게 고려한다면, 시간보다 데이터 중심의 판단이 필요합니다.</p>
<h2>7. 로그와 모니터링으로 멱등성을 감시하세요</h2>
<p>아무리 시스템이 멱등하게 설계되었더라도, 운영 중에는 예기치 못한 상황이 발생할 수 있습니다. 따라서 로그와 모니터링은 필수입니다. 특히 멱등 키를 포함한 요청 로그는 나중에 문제가 생겼을 때 매우 유용합니다. 어떤 요청이 어떤 응답을 받았는지, 중복 요청은 얼마나 있었는지 추적할 수 있어야 하며, 이 데이터를 바탕으로 시스템을 개선할 수 있습니다. 모니터링 대시보드에 멱등 요청 관련 지표를 추가하면, 운영 안정성도 크게 향상됩니다. 멱등성은 단지 개발 단계의 개념이 아니라, 운영 전반에 걸쳐 지속적으로 관리되어야 하는 약속입니다.</p>

<p>클라이언트 개발자는 서버의 내부 로직을 알 수 없습니다. 그러니 API 문서에 어떤 요청이 멱등한지, 어떤 필드를 필수로 제공해야 하는지 명확히 적어야 합니다. 특히 멱등 키를 사용하는 API라면, 그 키가 어떤 형식이어야 하는지, 어떤 헤더나 바디에 포함시켜야 하는지 등을 구체적으로 설명해야 합니다. 문서화는 단순한 매뉴얼을 넘어서서, 개발자 간의 신뢰를 형성하는 커뮤니케이션 도구입니다. 멱등성에 대한 정보가 명확히 공유되어야, 모든 개발자가 같은 기대를 가지고 API를 사용할 수 있습니다.</p>
<h2>9. 테스트 시나리오에 중복 요청을 포함하세요</h2>
<p>API 테스트를 할 때, 단순히 요청 한 번 보내고 결과만 확인하는 건 초보적인 방식입니다. 특히 멱등성을 테스트할 땐, 동일한 요청을 여러 번 보내고 결과가 동일한지 비교하는 시나리오가 필수입니다. 예를 들어, 같은 결제 요청을 세 번 반복했을 때, 실제 결제는 한 번만 이루어졌는지 확인해야 하죠. 자동화 테스트 스크립트에도 이런 반복 요청 테스트를 포함시키면, 배포 전에 미리 문제를 발견하고 대응할 수 있습니다. 테스트는 코드의 거울이자, 설계 철학을 실천하는 첫 걸음입니다.</p>
<h2>10. 멱등성은 UX와도 직결됩니다</h2>
<p>마지막으로, 멱등성은 단순히 기술적인 안정성만 보장하는 것이 아닙니다. **사용자 경험(UX)**과도 밀접하게 연결되어 있습니다. 같은 요청을 여러 번 보냈을 때도 일관된 결과를 받는다면, 사용자는 시스템에 신뢰를 갖게 됩니다. 특히 결제, 예약, 주문과 같은 민감한 액션에서는 멱등성이 곧 ‘믿음’이 됩니다. 사용자가 버튼을 여러 번 클릭해도 중복으로 결제되지 않는다는 확신, 서버가 언제나 동일한 결과를 반환해준다는 안정감. 이것이 바로 멱등성이 제공하는 최고의 UX입니다.</p>
<h2>마무리하며</h2>
<p>멱등성은 단순한 기술 용어가 아닙니다. 그것은 신뢰와 안정성을 약속하는 원칙이며, REST API 설계의 핵심 축입니다. 많은 시스템 장애가 멱등성 결여에서 비롯되고, 많은 사용자 불신이 반복 요청 처리 실패에서 시작됩니다. 오늘 소개해드린 10가지 포인트는 단지 이론이 아니라, 실전에서 반드시 고려해야 할 체크리스트입니다. 멱등성을 통해 더 나은 시스템을, 더 믿음직한 서비스를 설계해 보시기 바랍니다.</p>
<p>자주 묻는 질문(FAQs)<br>
Q1. 멱등성과 트랜잭션 처리는 어떤 관계가 있나요?<br>
트랜잭션은 연산의 원자성을 보장하는 개념이고, 멱등성은 같은 요청 반복 시 결과 일관성을 보장하는 개념입니다. 둘은 서로 보완적으로 작용할 수 있습니다.</p>
<p>Q2. 멱등 키는 어떤 형식으로 구성하는 게 좋을까요?<br>
UUID 형식이 가장 흔히 쓰이며, 요청 ID나 사용자 ID를 조합해 고유성을 보장하는 방식도 좋습니다. 중요한 건 충돌이 없도록 설계하는 것입니다.</p>
<p>Q3. PUT 요청도 멱등하지 않게 만들 수 있나요?<br>
기본적으로 PUT은 멱등한 메서드이지만, 내부 로직에 따라 멱등하지 않게 설계할 수도 있습니다. 예를 들어 업데이트 시 서버에서 생성하는 값이 달라진다면 멱등성이 깨질 수 있습니다.</p>
<p>Q4. 멱등 키의 TTL은 보통 얼마로 설정하나요?<br>
보통은 요청의 중요도에 따라 다르지만, 수 분에서 수 시간까지 다양하게 설정됩니다. 결제 요청처럼 민감한 경우엔 조금 더 길게 유지하는 것이 좋습니다.</p>
<p>Q5. 멱등성을 지키는 게 항상 필요한가요?<br>
아닙니다. 모든 API가 멱등할 필요는 없지만, 사용자 액션이 중복될 경우 문제가 생길 수 있는 상황이라면 반드시 고려해야 합니다.</p>
</div>
</article></div>

Not for Me

멱등성이란 무엇인가요? 한 번이든 백 번이든, 결과는 같아야 합니다
혹시 ‘멱등성(Idempotency)’이라는 단어를 처음 들으셨을 때, 무슨 마법 주문 같다는 느낌 안 드셨나요? 개발자들 사이에선 꽤나 자주 등장하지만, 생소한 단어죠. 하지만 REST API를 설계할 때 이 개념은 마치 튼튼한 기초공사처럼 굉장히 중요한 역할을 합니다. 멱등성은 간단히 말하면, 어떤 연산을 한 번 수행했든, 열 번 반복했든, 그 결과가 항상 동일해야 한다는 개념입니다. 예를 들어, 계좌 이체를 한 번 했는데 네트워크가 끊겨서 같은 요청을 또 보냈다고 가정해 보겠습니다. 이게 멱등하지 않다면 계좌에서 돈이 중복으로 빠져나가겠죠? 큰일 납니다. 멱등성은 바로 이런 ‘의도하지 않은 중복 처리’를 방지하기 위해 등장한 개념입니다. HTTP 메서드 중에서도 GET, PUT, DELETE는 기본적으로 멱등하게 설계되어 있습니다. 하지만 POST는 멱등하지 않기 때문에 특별히 신경 써서 다뤄야 하죠. 왜 이런 차이가 있는지, 그리고 실무에서 어떤 식으로 이를 설계에 녹여야 하는지, 지금부터 10가지 포인트로 하나씩 살펴보겠습니다.
1. 멱등성과 안전성은 다릅니다 — 혼동하지 마세요
많은 분들이 멱등성과 안전성(safety)을 헷갈려 하시더라고요. 둘 다 ‘여러 번 요청해도 괜찮다’는 맥락에서 등장하긴 하지만, 사실은 완전히 다릅니다. 안전성은 서버의 상태나 리소스에 아무런 영향도 주지 않는 요청을 의미합니다. 대표적으로 GET 요청이 있죠. 반면, 멱등성은 요청을 여러 번 하더라도 결과가 같기만 하면 되는 겁니다. PUT이나 DELETE가 여기에 해당합니다. 예를 들어, 동일한 데이터를 PUT으로 업데이트하면, 몇 번을 보내든 서버의 최종 상태는 동일하죠. 하지만 리소스 상태는 분명히 변합니다. 이런 차이를 명확히 이해하지 못하면 API 설계에서 큰 오류를 범할 수 있습니다. 안전하고 멱등한 API가 이상적이긴 하지만, 두 속성은 결코 같지 않다는 점을 꼭 기억하셔야 합니다.
2. POST 요청의 멱등성을 어떻게 보장할 수 있을까요?
POST는 기본적으로 멱등하지 않은 요청입니다. 왜냐하면 새로운 리소스를 생성하는 데 주로 쓰이기 때문이죠. 예를 들어 주문을 생성하거나 결제를 요청할 때 POST를 사용합니다. 그런데 사용자가 동일한 POST 요청을 두 번 보내면 어떻게 될까요? 같은 주문이 두 번 생성되거나 결제가 두 번 이루어질 수 있습니다. 이걸 막기 위해 등장한 것이 바로 ‘멱등 키(Idempotency Key)’입니다. 클라이언트는 요청을 보낼 때 고유한 키를 함께 전송하고, 서버는 이 키를 기반으로 요청을 식별해서 이미 처리된 요청이라면 응답만 재전송하고, 중복 처리를 하지 않도록 설계합니다. 멱등 키는 단순하지만 강력한 해결책입니다. 특히 금융, 결제, 의료처럼 민감한 데이터를 다루는 API에서는 필수적인 보호장치가 됩니다.
3. 클라이언트에게 멱등성을 위임하지 마세요
서버 개발을 하다 보면 이런 유혹이 생길 수 있습니다. “그냥 클라이언트에서 알아서 중복 요청 안 보내게 처리하라고 하면 되지 않을까?” 하지만 현실은 그렇게 단순하지 않습니다. 네트워크는 예측 불가능하고, 사용자 행동도 마찬가지죠. 버튼을 두 번 누르거나, 브라우저가 자동으로 요청을 재전송하는 경우도 있습니다. 클라이언트에 멱등성 보장을 맡겨두면, 결국 버그와 사고의 책임도 클라이언트 쪽에 넘어가게 됩니다. 그러니 서버는 가능한 한 자체적으로 멱등성을 보장해야 합니다. 서버에서 요청을 식별하고, 처리 여부를 캐싱하거나 로그로 관리하는 게 훨씬 안정적이고 신뢰도 높은 설계 방식입니다.
4. 멱등 키는 어디에 저장해야 할까요?
멱등 키를 쓰기로 했다면, 그 다음 고민은 저장입니다. 키가 서버로 날아왔을 때, 서버는 이전에 같은 키가 있었는지 찾아야 하죠. 보통은 데이터베이스에 저장하거나, Redis와 같은 인메모리 캐시 시스템을 활용합니다. 특히 Redis는 속도가 빠르고 TTL 설정도 가능해서 멱등 키 관리에 매우 적합합니다. 단, 저장소를 구성할 때는 몇 가지 유의할 점이 있습니다. 첫째, 키의 유효기간을 정해 과도한 리소스 낭비를 막아야 합니다. 둘째, 키와 응답 결과를 함께 저장해, 요청이 재전송됐을 때 같은 응답을 줄 수 있도록 해야 합니다. 이렇게 멱등 키 관리 전략까지 갖춘다면, 보다 안정적이고 예측 가능한 API를 설계할 수 있습니다.
5. 에러 코드도 멱등하게 처리되어야 합니다
API에서 에러가 발생했을 때, 멱등성 설계를 무시하면 낭패를 볼 수 있습니다. 예를 들어, 클라이언트가 같은 POST 요청을 두 번 보냈고, 서버는 첫 번째 요청에 대해 성공 응답을 보냈습니다. 그런데 두 번째 요청에서는 “이미 처리됨”이라는 에러를 반환한다면 어떨까요? 이건 멱등하지 않은 동작입니다. 왜냐하면 클라이언트 입장에서는 같은 요청에 대해 다른 응답을 받은 셈이니까요. 이상적인 설계는 두 번째 요청에도 첫 번째와 동일한 성공 응답을 보내는 것입니다. 물론 내부적으로는 에러지만, 외부에서는 멱등성을 유지하기 위해 같은 결과를 보여줘야 합니다. 이게 바로 사용자 경험까지 고려한 세심한 설계입니다.
6. 시간 기반 중복 방지는 완전하지 않습니다
간혹 일부 시스템에서는 “같은 IP나 같은 요청이 5초 이내에 다시 들어오면 중복 처리로 간주하자”는 식의 시간 기반 방식을 채택하기도 합니다. 물론 나름의 효과는 있습니다. 하지만 완전한 멱등성 보장은 절대 아니죠. 클라이언트 환경이나 네트워크 상태에 따라 요청이 몇 초 늦게 도착할 수도 있고, 진짜로 다른 사용자가 우연히 같은 요청을 보내는 경우도 있습니다. 시간 기반의 중복 방지는 보조 수단일 뿐, 정확한 요청 식별과 저장, 그리고 응답 재사용이 핵심입니다. 멱등성을 진지하게 고려한다면, 시간보다 데이터 중심의 판단이 필요합니다.
7. 로그와 모니터링으로 멱등성을 감시하세요
아무리 시스템이 멱등하게 설계되었더라도, 운영 중에는 예기치 못한 상황이 발생할 수 있습니다. 따라서 로그와 모니터링은 필수입니다. 특히 멱등 키를 포함한 요청 로그는 나중에 문제가 생겼을 때 매우 유용합니다. 어떤 요청이 어떤 응답을 받았는지, 중복 요청은 얼마나 있었는지 추적할 수 있어야 하며, 이 데이터를 바탕으로 시스템을 개선할 수 있습니다. 모니터링 대시보드에 멱등 요청 관련 지표를 추가하면, 운영 안정성도 크게 향상됩니다. 멱등성은 단지 개발 단계의 개념이 아니라, 운영 전반에 걸쳐 지속적으로 관리되어야 하는 약속입니다.
8. API 문서에 멱등성 정책을 명시하세요
클라이언트 개발자는 서버의 내부 로직을 알 수 없습니다. 그러니 API 문서에 어떤 요청이 멱등한지, 어떤 필드를 필수로 제공해야 하는지 명확히 적어야 합니다. 특히 멱등 키를 사용하는 API라면, 그 키가 어떤 형식이어야 하는지, 어떤 헤더나 바디에 포함시켜야 하는지 등을 구체적으로 설명해야 합니다. 문서화는 단순한 매뉴얼을 넘어서서, 개발자 간의 신뢰를 형성하는 커뮤니케이션 도구입니다. 멱등성에 대한 정보가 명확히 공유되어야, 모든 개발자가 같은 기대를 가지고 API를 사용할 수 있습니다.
9. 테스트 시나리오에 중복 요청을 포함하세요
API 테스트를 할 때, 단순히 요청 한 번 보내고 결과만 확인하는 건 초보적인 방식입니다. 특히 멱등성을 테스트할 땐, 동일한 요청을 여러 번 보내고 결과가 동일한지 비교하는 시나리오가 필수입니다. 예를 들어, 같은 결제 요청을 세 번 반복했을 때, 실제 결제는 한 번만 이루어졌는지 확인해야 하죠. 자동화 테스트 스크립트에도 이런 반복 요청 테스트를 포함시키면, 배포 전에 미리 문제를 발견하고 대응할 수 있습니다. 테스트는 코드의 거울이자, 설계 철학을 실천하는 첫 걸음입니다.
10. 멱등성은 UX와도 직결됩니다
마지막으로, 멱등성은 단순히 기술적인 안정성만 보장하는 것이 아닙니다. **사용자 경험(UX)**과도 밀접하게 연결되어 있습니다. 같은 요청을 여러 번 보냈을 때도 일관된 결과를 받는다면, 사용자는 시스템에 신뢰를 갖게 됩니다. 특히 결제, 예약, 주문과 같은 민감한 액션에서는 멱등성이 곧 ‘믿음’이 됩니다. 사용자가 버튼을 여러 번 클릭해도 중복으로 결제되지 않는다는 확신, 서버가 언제나 동일한 결과를 반환해준다는 안정감. 이것이 바로 멱등성이 제공하는 최고의 UX입니다.
마무리하며
멱등성은 단순한 기술 용어가 아닙니다. 그것은 신뢰와 안정성을 약속하는 원칙이며, REST API 설계의 핵심 축입니다. 많은 시스템 장애가 멱등성 결여에서 비롯되고, 많은 사용자 불신이 반복 요청 처리 실패에서 시작됩니다. 오늘 소개해드린 10가지 포인트는 단지 이론이 아니라, 실전에서 반드시 고려해야 할 체크리스트입니다. 멱등성을 통해 더 나은 시스템을, 더 믿음직한 서비스를 설계해 보시기 바랍니다.
자주 묻는 질문(FAQs)
Q2. 멱등 키는 어떤 형식으로 구성하는 게 좋을까요?
Q3. PUT 요청도 멱등하지 않게 만들 수 있나요?
Q4. 멱등 키의 TTL은 보통 얼마로 설정하나요?
Q5. 멱등성을 지키는 게 항상 필요한가요?
The post 실무에 바로 쓰는 멱등성 가이드: REST API 설계에서 실수하지 않는 법 first appeared on notforme.

실무에 바로 쓰는 멱등성 가이드: REST API 설계에서 실수하지 않는 법

댓글