477. REST API (Representational State Transfer) - 자원 중심 구조, HTTP 메서드 매핑

핵심 인사이트 (3줄 요약)

본질: REST(Representational State Transfer)는 2000년 로이 필딩(Roy Fielding)이 창안한 아키텍처 제약 조건의 집합으로, 네트워크 상의 모든 자원(Resource)에 고유한 URI를 부여하고 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 자원의 상태를 주고받는 일관된 인터페이스다.

가치: 특정 언어나 기술에 종속되지 않는 범용성(JSON/XML)을 제공하고 클라이언트와 서버를 완전히 분리함으로써, 모바일 앱부터 IoT 기기까지 다양한 플랫폼이 하나의 백엔드 자원을 재사용할 수 있는 무한한 확장성을 부여한다.

융합: 단순히 "URL 예쁘게 짜기"가 아니라, 무상태성(Stateless)을 통한 클라우드 스케일아웃, 캐시 제어 헤더 연동, 그리고 상태 전이 링크(HATEOAS)를 통한 자기 서술성(Self-descriptiveness) 확보가 성숙도 높은(Level 3) RESTful 시스템의 핵심 요건이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: REST(Representational State Transfer)는 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처 디자인 제약(Constraints)의 모음이다. REST 철학을 완벽히 따르는 시스템을 RESTful하다고 부른다. 가장 직관적인 요약은 **"URI로 자원을 정의하고, HTTP 메서드로 행위를 정의하며, 페이로드(JSON/XML)로 자원의 상태(표현)를 주고받는 아키텍처"**다.
필요성: 2000년대 초반, 시스템 간 통신은 SOAP, CORBA 같은 RPC(Remote Procedure Call) 방식이 주를 이뤘다. 이는 "서버의 특정 함수를 원격으로 실행해라(getUsers(), deleteUser(), updateUser())라는 명령형 구조였다. 이 방식은 API 스펙이 변할 때마다 클라이언트 코드를 통째로 갈아엎어야 하는 강한 결합(Tight Coupling) 문제를 낳았다. 웹의 근본 프로토콜인 HTTP가 이미 훌륭한 규약을 갖고 있는데 굳이 새로운 규칙을 덮어씌울 필요가 있을까? HTTP의 철학을 100% 퓨어하게 재활용하여 서버와 클라이언트를 영원히 분리하자는 철학이 절실했다.
💡 비유: 기존 RPC 방식이 식당에서 "1번 테이블 국밥 갖다주세요, 1번 테이블 깍두기 치워주세요, 1번 테이블 국물 더 주세요"라고 행동 하나하나를 육성으로 통제하는 것이라면, REST는 메뉴판(URI)과 키오스크 버튼(GET/POST/PUT/DELETE)을 완벽히 표준화해두어, 손님이 버튼만 누르면 주방장이 알아서 상태를 척척 바꾸고 결과물(JSON)을 내어주는 완벽한 '분업화 식당'과 같습니다.
등장 배경:
1. SOAP/XML-RPC의 복잡성: 기존 통신 방식은 규약이 너무 무겁고 설정이 복잡했으며, XML 페이로드의 오버헤드가 극심했다.
2. Roy Fielding의 논문: HTTP 1.0/1.1 스펙 작성에 참여한 로이 필딩이 2000년 박사 논문에서 "웹의 장점을 최대한 활용하는 아키텍처"로 REST를 창안했다.
3. 모바일 시대와 MSA의 도래: 2010년대 아이폰의 등장과 함께, 웹 브라우저뿐만 아니라 모바일 앱, 스마트 TV 등 다양한 클라이언트가 동일한 백엔드 서버 자원(Resource)을 찔러야 하는 멀티 플랫폼 시대가 열리며 REST API가 천하통일을 이루었다.

┌─────────────────────────────────────────────────────────────┐
│          전통적인 RPC 방식 vs RESTful API 설계 비교             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [RPC (행위/함수 호출 중심) 안티패턴]                           │
│  - 유저 조회 ➔ GET /getUser?id=123                          │
│  - 유저 생성 ➔ POST /createUser                            │
│  - 유저 삭제 ➔ GET /deleteUser?id=123 (GET으로 삭제를?!)       │
│  - 유저 수정 ➔ POST /updateUser                            │
│  ⚠️ 문제점: URL에 '명사(자원)'와 '동사(행위)'가 뒤섞여 혼돈의 카오스.   │
│            HTTP 메서드를 전혀 활용하지 못하고 오직 껍데기로만 씀.    │
│                                                             │
│ [RESTful (자원과 행위의 완벽한 분리) 표준 패턴]                   │
│         [자원(명사) URI]          [행위(동사) HTTP Method]       │
│                                                             │
│         /users/123       ◀─── [ GET ]    (해당 유저 조회)    │
│         /users           ◀─── [ POST ]   (새로운 유저 생성)   │
│         /users/123       ◀─── [ DELETE ] (해당 유저 삭제)    │
│         /users/123       ◀─── [ PUT ]    (해당 유저 통째 덮어쓰기)│
│         /users/123       ◀─── [ PATCH ]  (해당 유저 일부만 수정) │
│                                                             │
│  🌟 결과: URL은 오직 '무엇(명사)'인지 식별만 하고,               │
│          '어떻게(동사)' 할지는 HTTP 고유 메서드에 전적으로 위임한다!   │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 초보 개발자들이 가장 많이 하는 실수가 URL 안에 create, delete 같은 동사를 욱여넣는 것이다. 이는 웹의 기본 철학을 무시한 RPC 방식이다. REST의 핵심은 URI(Uniform Resource Identifier)를 통해 전 세계 유일한 식별자로 '명사(자원)'만 콕 집어내고, 그 자원을 지지고 볶는 조작 명령은 HTTP 프로토콜이 태어날 때부터 만들어 둔 GET, POST, PUT, DELETE 표준 메서드로 완벽하게 이원화하는 것이다. 이 단순한 제약 하나가 전 세계 모든 개발자들이 별도의 매뉴얼 없이도 API의 목적을 직관적으로 이해할 수 있는 우아한 표준화를 이뤄냈다.

📢 섹션 요약 비유: 서류 폴더에 이름을 붙일 때 "영수증을_복사해서_모아두는_철"이라고 행동까지 길게 적어두면 나중에 찾기 헷갈립니다. просто "2026년 영수증(URI)"이라고만 깔끔하게 적어두고, 볼지(GET) 찢을지(DELETE) 덮어쓸지(PUT)는 내 손(HTTP Method)으로 결정하는 것이 REST의 깔끔한 정리 정돈법입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

REST의 6가지 아키텍처 제약 조건 (Constraints)

로이 필딩의 논문에서 RESTful이라고 불리기 위해 만족해야 하는 6가지 철칙이다. 이를 지키면 시스템은 미친 듯한 유연성과 확장성을 얻는다.

제약 조건	설명	아키텍처적 가치	실무 예시 및 비유
Client-Server 구조	클라이언트(UI, UX)와 서버(데이터, 로직)의 완벽한 관심사 분리	독립적 진화 가능. 앱 개발자와 백엔드 개발자 병렬 작업	주방(서버)과 홀 서빙(클라이언트) 분업
Stateless (무상태성)	각 요청은 독립적이며, 서버는 클라이언트의 상태를 저장(세션)하지 않음	극강의 스케일아웃(서버 증설) 가능. 로드밸런싱이 자유로움	어제 온 손님이라도 혜택 없이 원칙대로 처리
Cacheable (캐시 가능성)	HTTP의 캐시 인프라를 그대로 재사용 (ETag, Cache-Control)	서버 부하 극감, 응답 속도 밀리초 단위 단축	많이 나가는 메뉴는 미리 포장(캐시)
Uniform Interface (일관성)	URI 식별, 자원 조작, 자기 서술적 메시지, HATEOAS 준수	REST의 꽃. 클라이언트가 API 스펙에 얽매이지 않게 결합도를 끊음	모든 레스토랑의 공통 메뉴얼 규격화
Layered System (계층 구조)	클라이언트는 서버 앞단에 프록시/로드밸런서가 있는지 몰라도 됨	L7 로드밸런싱, SSL 암호화 계층 추가 등 인프라 아키텍처 자유도 확보	사장님(백엔드)을 만나기 전 경호원(프록시) 통과
Code-On-Demand (선택)	서버가 클라이언트에게 실행 가능한 코드(JS)를 전송해 기능 확장	프론트엔드 기능의 동적 확장	레시피북을 통째로 손님에게 던져줌

REST의 궁극적 목표: Uniform Interface와 HATEOAS

"우리가 RESTful API라고 부르는 것들의 99%는 REST가 아니라 단순 HTTP RPC다." 창시자 로이 필딩이 직접 남긴 독설이다. 대다수 개발자는 URI 명사화와 HTTP 메서드 매핑까지만 해놓고(Richardson Maturity Model Level 2) REST라고 우긴다. 진정한 REST(Level 3)가 되려면 **Self-descriptive message(자기 서술적 메시지)**와 **HATEOAS(Hypermedia As The Engine Of Application State)**를 만족해야 한다.

Self-descriptive message: 메시지 스스로가 자신을 어떻게 해석해야 하는지 완벽하게 설명해야 한다. 응답 헤더의 Content-Type: application/json 뿐만 아니라, 이 JSON의 구조가 어떤 명세서(Schema)를 따르는지 Link: <schema.url>; rel="describedby" 형태로 명시해 브라우저가 스펙을 몰라도 파싱할 수 있어야 한다.
HATEOAS: 응답 JSON 안에 "현재 상태에서 클라이언트가 다음에 어떤 행동을 할 수 있는지"를 알려주는 하이퍼링크 모음이 동적으로 포함되어야 한다.

┌───────────────────────────────────────────────────────────────┐
│        가짜 REST(Level 2) vs 진짜 REST(HATEOAS 포함, Level 3)   │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│ [ ❌ 대다수가 쓰는 가짜 REST API 응답 ]                             │
│ GET /accounts/123                                             │
│ {                                                             │
│    "account_id": "123",                                       │
│    "balance": 50000,                                          │
│    "status": "ACTIVE"                                         │
│ }                                                             │
│ ➔ 클라이언트는 "이 계좌에 입금하려면 어떤 URL을 찔러야 하지?"를           │
│    모르기 때문에 스웨거(Swagger)나 API 문서를 직접 찾아봐야 한다.        │
│    (서버 URL 구조가 바뀌면 클라이언트 앱을 통째로 재배포해야 함 = 강결합) │
│                                                               │
│ [ ✅ 진정한 RESTful API 응답 (HATEOAS 적용) ]                     │
│ GET /accounts/123                                             │
│ {                                                             │
│    "account_id": "123",                                       │
│    "balance": 50000,                                          │
│    "status": "ACTIVE",                                        │
│    "_links": {                                                │
│       "self": { "href": "/accounts/123" },                    │
│       "deposit": { "href": "/accounts/123/deposit", "method": "POST" }, │
│       "withdraw": { "href": "/accounts/123/withdraw", "method": "POST" },│
│       "close": { "href": "/accounts/123/close", "method": "DELETE" }    │
│    }                                                          │
│ }                                                             │
│ ➔ 클라이언트는 API 문서를 볼 필요가 없다! 응답으로 온 `_links` 객체    │
│    안의 `href`만 보고 버튼 UI를 동적으로 그려내면 끝이다. 서버가 입금 URL을│
│    `/accounts/123/in`으로 바꿔도 클라이언트 코드는 단 한 줄도 안 고친다. │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] HATEOAS는 애플리케이션의 상태 전이(State Transfer)를 철저하게 하이퍼미디어(Hypermedia, 즉 링크)에 위임한다. 사용자의 계좌 잔고가 0원이 되어 출금(Withdraw)이 불가능해졌다면, 서버는 응답 JSON의 _links 목록에서 withdraw 링크 자체를 빼버린다. 프론트엔드는 withdraw 링크가 없는 것을 보고 출금 버튼을 회색으로 비활성화(Disable)하기만 하면 된다. 클라이언트가 "잔고가 0원이면 출금 불가"라는 비즈니스 로직을 하드코딩으로 들고 있을 필요가 없어진다. 클라이언트와 서버가 서로의 존재를 잊고 극단적으로 느슨하게 결합(Loose Coupling)하는, 로이 필딩이 꿈꿨던 완벽한 아키텍처다.

📢 섹션 요약 비유: 미로 탐험을 할 때 처음부터 전체 지도를 암기해서 출발하는 것(가짜 REST)이 아니라, 방에 도착할 때마다 "다음 방으로 가는 문은 왼쪽(deposit)과 오른쪽(close)입니다"라는 표지판(HATEOAS)만 보고 길을 찾아가는 완벽한 동적 아키텍처입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: REST API vs GraphQL (현대 아키텍처 패러다임)

REST가 10년간 천하를 통일했으나, 모바일 시대의 고도화와 함께 페이스북이 내놓은 GraphQL에 치열한 도전을 받고 있다.

아키텍처 항목	REST API	GraphQL	아키텍처 선택 기준
엔드포인트 형태	다중 자원별 URI (수백 개의 라우팅)	단일 엔드포인트 (오직 `/graphql` 하나)	통제냐 유연성이냐
데이터 페칭의 주도권	서버 주도. (서버가 주는 모양대로 다 받아야 함)	클라이언트 주도. (클라이언트가 원하는 필드 구조만 명시)	응답 데이터의 형태 결정권
Over-fetching 문제	극심함. (이름 하나 필요한데 프로필 전체 데이터 1MB를 내려줌)	없음. (이름만 달라고 명시하면 이름 필드만 내려옴)	모바일 대역폭 최적화
Under-fetching 문제	극심함. (게시글, 댓글, 작성자 API를 3번 직렬 핑 쳐야 함)	없음. (그래프 쿼리로 한방에 계층형 조인해서 내려줌)	클라이언트 RTT 지연 단축
캐시 최적화	극강. HTTP 표준 ETag, Cache-Control 100% 호환	매우 취약. 모두 POST로 쏘기 때문에 HTTP 캐시 불가	정적 데이터 위주 서비스인가
러닝 커브 및 백엔드 부하	낮고 안정적. 구현 쉬움.	쿼리 복잡도에 따른 백엔드 DB 연산 파탄 (N+1 문제) 등 백엔드 부하 심각.	프론트엔드 파워가 쎈 조직인가

과목 융합 관점

운영체제 & 파일시스템: REST에서 고유한 URI로 자원에 접근하는 철학은 유닉스/리눅스 철학인 "Everything is a File"과 맥락이 똑같다. 하드웨어 장치든 소켓이든 모두 /dev/xxx라는 경로(URI)로 추상화하여 읽고 쓰는(GET/POST) 유닉스의 철학이 인터넷 스케일로 확장된 것이 REST다.
클라우드 & MSA: 넷플릭스나 우버 같은 MSA 환경에서 수천 개의 마이크로서비스 간 통신은 전부 RESTful API 또는 gRPC 기반으로 이루어진다. REST의 무상태성(Stateless) 덕분에, AWS Auto Scaling Group이 수백 대의 노드 컨테이너를 마음대로 껐다 켰다 해도 서비스의 상태가 무너지지 않는 견고한 클라우드 탄력성(Elasticity)을 보장받는다.
📢 섹션 요약 비유: REST API가 정해진 코스 요리 메뉴판 100개를 만들어두고 "3번 세트 주세요" 하면 주방장이 정해진 접시를 내주는 전통 식당이라면, GraphQL은 손님이 뷔페에 가서 "양상추 3장, 고기 2점, 드레싱 조금"이라고 콕 집어 주문하는 주문형 맞춤 식당입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 부적절한 HTTP Method 매핑으로 인한 멱등성(Idempotency) 붕괴: 초보 백엔드 개발자가 사용자 정보 수정을 GET /users/update?id=1&name=kim 형태로 구현했다. 이 API가 구글 검색엔진 크롤러 봇에 노출되었고, 봇이 링크를 따라 무차별적으로 GET 요청을 날리는 바람에 사내 시스템의 모든 유저 이름이 'kim'으로 변경되는 대형 사고가 터졌다.
- 판단: GET 메서드는 HTTP 스펙상 반드시 "안전(Safe)하고 멱등(Idempotent - 여러 번 호출해도 결과가 동일)"해야 한다. 조회용인 GET에 상태 변경(Update) 로직을 매핑하는 것은 REST 안티패턴 중 최악이다. 상태 변경은 반드시 본문(Body)을 감출 수 있고 멱등하지 않은 POST나, 멱등성이 보장된 PUT/PATCH/DELETE로 설계하여 캐시 봇이나 프록시가 함부로 건드리지 못하게 인프라 방어막을 쳐야 한다.
시나리오 — PUT과 PATCH의 혼동으로 인한 데이터 유실: 회원의 주소 정보만 수정하는 프론트엔드 모듈이 개발되었다. 개발자는 PUT /users/1 에 JSON { "address": "Seoul" } 만 담아 쐈다. 백엔드는 이 요청을 받고 해당 유저의 기존 정보(이름, 나이, 이메일)를 전부 NULL로 덮어씌워버렸고, 유저 데이터가 통째로 증발했다.
- 판단: REST 표준에서 **PUT은 "전체 교체(Replace)"**를 의미하고, **PATCH는 "부분 수정(Modify)"**을 의미한다. PUT을 쐈다는 것은 "기존 데이터를 싹 지우고 내가 방금 보낸 JSON 껍데기 하나로 통째로 덮어써라"는 파괴적 명령이다. 필드 하나만 변경할 때는 아키텍처 규칙상 반드시 PATCH를 써야 데이터 무결성 붕괴(Data Loss) 사고를 피할 수 있다.

  ┌──────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 리차드슨 성숙도 모델 (Maturity Model)         │
  ├──────────────────────────────────────────────────────────────┤
  │                                                              │
  │ [Level 0: 늪지대 (The Swamp of POX)]                           │
  │  - URL 하나로 다 퉁침: POST /api/v1/endpoint                    │
  │  - Body: { "action": "deleteUser", "id": 123 }                 │
  │  ➔ ❌ 이건 그냥 HTTP라는 터널을 뚫고 SOAP/RPC 짓을 하는 안티패턴.     │
  │                                                              │
  │ [Level 1: 자원 (Resources)]                                   │
  │  - 명사화된 여러 URI 등장: POST /users/123/delete                │
  │  - 모든 통신을 POST(또는 GET) 하나로만 퉁침.                      │
  │  ➔ ❌ 동사가 URL에 섞여 있고, 메서드를 활용 못 함.                 │
  │                                                              │
  │ [Level 2: HTTP 동사 (HTTP Verbs)] 🌟 대다수 기업의 타협점 🌟      │
  │  - 자원과 행위의 완벽한 분리: DELETE /users/123                   │
  │  - GET, POST, PUT, DELETE 상태 코드를 철저히 맞춰 씀.             │
  │  ➔ ✅ 실무 백엔드 스펙의 표준. (하지만 아직 완벽한 REST는 아님)         │
  │                                                              │
  │ [Level 3: 하이퍼미디어 컨트롤 (HATEOAS)] 🚀 진정한 REST의 완성 🚀  │
  │  - 응답 JSON에 _links 가 있어, 클라이언트가 다음 상태로 전이할 URL을 │
  │    동적으로 발견하게 만듦.                                       │
  │  ➔ ✅ 클라이언트와 서버의 극단적인 디커플링 완성. 서버 업그레이드 자유.   │
└──────────────────────────────────────────────────────────────┘

[다이어그램 해설] 리차드슨 성숙도 모델은 우리 회사의 API가 얼마나 REST 철학을 잘 준수하는지 채점하는 잣대다. 실무 개발팀의 90%는 Level 2에 머무르며 이를 'REST API'라 칭하고 Swagger 문서에 의존한다. Level 3(HATEOAS)까지 구현하려면 백엔드의 응답 객체 조립 로직이 엄청나게 복잡해지기 때문이다. 실무적 판단으로는 범용 공개 오픈 API(Github API, 결제 연동 API 등)를 설계할 때는 무조건 Level 3를 지향하여 파트너사의 스펙 파편화를 막아야 하며, 사내 앱-백엔드 간 폐쇄망 통신용이라면 팀의 피로도를 고려해 Level 2에서 멈추고 Swagger로 문서화하는 타협(Trade-off)이 훨씬 경제적이다.

도입 체크리스트

기술적: API 버전 관리를 위해 URL 경로(/api/v1/users)를 쓰고 있는가, 아니면 커스텀 헤더(Accept: application/vnd.company.v1+json)를 통해 HATEOAS의 진정한 본질을 추구하고 있는가?
운영·보안적: 컬렉션(복수형) URI 조회 시 GET /users 호출이 DB 풀 스캔을 일으켜 OOM을 낼 위험이 없는가? 페이징(Pagination: ?page=1&size=20) 및 필터링 제약 조건이 아키텍처 단에서 강제되어 있는가?

안티패턴

HTTP 응답 상태 코드(Status Code) 무시: 백엔드 내부에서 NullPointerException이 나거나 찾을 수 없는 리소스인데 무조건 200 OK를 내리고, JSON Body 안쪽에 { "code": 500, "message": "에러" }를 숨겨서 내보내는 최악의 기만행위. 이 경우 앞단의 L7 로드밸런서, CDN, API 게이트웨이는 이게 에러인지 정상 응답인지 알 길이 없어 캐시에 썩은 에러 메시지를 영구 저장해버리는 글로벌 장애를 유발한다. 실패는 4xx/5xx로 당당히 던져라.
📢 섹션 요약 비유: 신호등(HTTP 상태 코드)이 빨간불(404 에러)인데 겉으로는 초록불(200 OK) 페인트를 칠해놓고 건너가면, 앞차(클라이언트)는 물론이고 교차로를 감시하던 경찰관(프록시/캐시)까지 대형 사고의 책임을 뒤집어쓰게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	RPC / Level 0 아키텍처	Level 2 / Level 3 RESTful	개선 효과
정량	상태 정보 유지로 서버 메모리 팽창	Stateless 기반 Scale-out	서버 동시 접속 소화량 수십 배 스케일 증대
정량	봇과 캐시 서버의 제어 불가	표준 메서드 연동을 통한 자동 캐싱	CDN 캐시 히트율 극대화, 응답 지연 0ms 도달
정성	플랫폼별 별도 API 개발 (웹용/앱용)	동일 URI 재사용, 프론트/백 결합도 0	멀티 플랫폼 개발 생산성 200% 증가

미래 전망

REST와 GraphQL의 이원화 공존: 프론트엔드가 요구하는 데이터 결합도가 극심해지는 화면(모바일 피드, 대시보드)에서는 REST의 잦은 핑(N+1 문제)이 발목을 잡는다. 따라서 메인 조회 레이어는 GraphQL을 채택하고, 결제, 회원가입, 대용량 파일 전송 등 캐싱과 무결성이 극도로 중요한 코어 백엔드(Command)는 REST가 전담하는 CQRS(명령/조회 책임 분리) 기반 하이브리드 아키텍처가 대기업 스택의 표준으로 자리 잡고 있다.
gRPC의 내륙 침공: MSA 환경의 백엔드 서버 1번과 2번끼리의 내부 통신에서마저 무거운 JSON 텍스트 파싱을 견디는 것은 어리석다. 마이크로서비스 내부망 통신은 이진(Binary) 직렬화와 HTTP/2를 기반으로 압도적 성능을 내는 구글의 gRPC(Protocol Buffers)로 완전히 세대교체가 끝났다.

참고 표준

Roy Fielding's Dissertation (2000): Architectural Styles and the Design of Network-based Software Architectures
RFC 7231: HTTP/1.1 Routing and Methods (GET, POST, PUT, DELETE 멱등성 명세)

REST는 단순한 코딩 스타일이나 트렌드가 아니라, 월드 와이드 웹이라는 인류 역사상 가장 거대한 분산 시스템이 30년 넘게 붕괴하지 않고 무한정 팽창할 수 있었던 심오한 아키텍처의 비밀 그 자체다. 껍데기만 REST 흉내를 내면서 URL 예쁘게 짜는 데 집착하기보다는, 내 API가 HTTP 캐시 생태계를 타파하지 않고 무상태성을 지키며 로드밸런싱의 축복을 100% 누리고 있는지를 성찰하는 것이 진짜 시니어 아키텍트의 시선이다.

📢 섹션 요약 비유: REST는 건물을 지을 때 배관, 전기, 환풍구의 규격을 표준화한 국가 건축법입니다. 이 법을 귀찮다고 어기고 내 마음대로 벽에 구멍을 뚫어버리면(RPC), 나중에 에어컨 기사나 배관공(모바일 기기, 클라우드)이 와도 유지보수를 할 수 없는 버려진 폐가가 되고 맙니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Stateless (무상태성)	REST의 핵심 제약 중 하나로, 서버가 상태(세션)를 들고 있지 않게 함으로써 로드밸런싱과 클라우드 Auto-Scaling의 무한 확장을 가능하게 하는 근간이다.
HTTP Methods (GET/POST/PUT/DELETE)	자원(URI)에 가해지는 행위를 규격화한 통신 규약으로, 특히 GET/PUT/DELETE는 멱등성(Idempotency)을 보장하여 네트워크 재시도(Retry) 폭풍을 안전하게 막아낸다.
HATEOAS	클라이언트가 서버의 URL 스펙 변경에 구애받지 않도록, 응답 페이로드 내에 상태 전이 링크를 동적으로 삽입해 완벽한 디커플링(결합도 제거)을 이루는 끝판왕 설계다.
GraphQL	REST의 치명적 한계인 오버패칭(데이터 과다)과 언더패칭(여러 번 호출)을 타파하기 위해 등장한, 클라이언트 쿼리 주도형 최신 API 패러다임이다.
Idempotency (멱등성)	연산을 1번 하나 100번 하나 서버의 상태 결과가 100% 동일함을 보장하는 성질로, REST 메서드 설계 시 결제 이중 출금을 막는 가장 핵심적인 분산 시스템 철학이다.

👶 어린이를 위한 3줄 비유 설명

옛날에는 식당에서 아저씨가 "1번 테이블 그릇 치워라, 물 갖다 줘라, 밥 줘라" 하고 행동을 하나하나 지시해서 너무 바빴어요 (RPC).
REST는 식탁 위에 밥, 국, 반찬(자원)을 딱딱 이름표를 붙여놓고, 먹기(GET), 더달라하기(PUT), 버리기(DELETE) 버튼만 누르면 알아서 작동하는 뷔페식 규격이에요.
전 세계 모든 식당이 이 똑같은 버튼 규격을 쓰기로 약속했기 때문에, 우리는 처음 가는 외국 식당에 가서도 헤매지 않고 맛있게 밥을 시켜 먹을 수 있답니다!