Web Protocols & API Paradigms

1. Overview

웹 프로토콜 및 API 패러다임(Web Protocols & API Paradigms, WAP)은 브라우저와 서버, 혹은 서버와 서버 간에 데이터를 어떻게 규격화하여 주고받을 것인지에 대한 소프트웨어 통신 계약(Contract)의 역사를 다룹니다.

웹은 문서를 보는 시대에서 거대한 애플리케이션을 구동하는 시대로 진화했습니다. 학습자는 단순히 텍스트를 주고받던 HTTP/1.1의 무상태성(Stateless) 한계와, 이를 극복하기 위해 다중화(Multiplexing)를 도입한 HTTP/2, UDP 기반으로 속도를 극한으로 끌어올린 HTTP/3(QUIC)의 진화 역학을 배웁니다. 더불어 자원 중심의 REST, 프론트엔드가 쿼리를 주도하는 GraphQL, 그리고 마이크로서비스(MSA) 시대의 초고속 이진 통신인 gRPC에 이르는 다양한 API 아키텍처 패턴을 학습하여, 도메인에 맞는 최적의 인터페이스를 설계하는 안목을 갖춥니다.

2. Scope & Boundaries

In-Scope

• HTTP Evolution: HTTP/1.1 (Keep-Alive, Pipelining 한계), HTTP/2 (이진 프레이밍, Multiplexing), HTTP/3 (QUIC, 0-RTT 연결 설정).
• Web State Handling: 무상태 환경에서의 Cookie, Session 작동 원리, CORS(교차 출처 리소스 공유) 물리.
• RESTful Architecture: 리소스 중심 URL 설계, HTTP Method 멱등성, Richardson 성숙도 모델, HATEOAS.
• Modern API Paradigms: GraphQL(Over-fetching 해결, Schema/Resolver 로직), gRPC & Protobuf(IDL 기반 양방향 스트리밍).

Out-of-Scope

• 데이터베이스 쿼리 튜닝: API 서버 내부에서 SQL 데이터베이스를 최적화하는 기법 $\rightarrow$ 06. Data & Information Management 영역으로 위임.
• 프론트엔드 상태 관리 라이브러리: Redux, Zustand 등 클라이언트 내부 메모리 관리 $\rightarrow$ 12-04. Frontend App Architecture 영역으로 위임.

Boundaries

• WAP vs. Web Security (10-02, 10-03): WAP은 쿠키와 세션의 '통신 로직'을 가르치지만, 그 쿠키가 XSS나 CSRF 공격에 어떻게 탈취당하고 방어(HttpOnly, SameSite)되는지에 대한 보안 역학은 10. Security 노드에서 심도 있게 다룹니다.

3. Counterexample

• 동사형 URL의 남발 (REST Fallacy): 게시글을 삭제하는 API를 GET /deleteArticle?id=5로 설계하는 것. 이는 HTTP 캐싱 정책을 완전히 무너뜨리고 멱등성(Idempotency)을 훼손하는 최악의 아키텍처입니다. 브라우저가 화면 로딩 속도를 높이려고 GET 요청을 몰래 다시 보낼 때마다 게시글이 날아가는 버그를 만듭니다. 올바른 설계는 **자원(명사)**을 지칭하고 행위는 **메서드(DELETE)**에 위임하는 DELETE /articles/5 구조를 따르는 것입니다.
• 만능 gRPC 맹신 (Silver Bullet Fallacy): "REST는 구형이고 gRPC가 무조건 빠르다"며 프론트엔드 웹 브라우저 통신까지 전부 gRPC로 뜯어고치려다 브라우저 호환성 문제(gRPC-Web 프록시 강제)에 부딪혀 시스템을 망치는 행위. gRPC는 이진(Binary) 통신이므로 서버 간 내부 통신(Internal MSA)에서는 극강의 효율을 내지만, 텍스트 기반 디버깅이 필수적이고 범용성이 중요한 공개(Public) API 생태계에서는 여전히 REST나 GraphQL이 적합하다는 트레이드오프를 무시한 결과입니다.

4. Prerequisites

• 네트워크 계층 및 전송 프로토콜 (Basic): HTTP/2는 TCP 위에서 돌아가고 HTTP/3은 UDP 위에서 돌아간다는 전제 지식이 필요합니다. (08-02. TCP/UDP)
• 소프트웨어 설계 패턴 (Recommended): 클라이언트와 서버를 분리하는 레이어드 아키텍처의 의존성 역전 개념이 요구됩니다. (07-01. FAP)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: HTTP 프로토콜과 멱등성 (HTTP Physics)

• Why to Learn: 브라우저와 서버가 서로 대화하는 언어의 문법을 파악하여, 에러가 났을 때 누구의 잘못인지 네트워크 단에서 증명하기 위함입니다.
• What to Learn:
  • Concepts: 무상태성(Stateless), 비연결성(Connectionless), HTTP 헤더(Header) 구조.
  • Skills: HTTP 메서드(GET, POST, PUT, PATCH, DELETE)의 의미론, 멱등성(Idempotency)과 안전성(Safety). HTTP 상태 코드(2xx, 3xx, 4xx, 5xx).
  • Tools: Chrome DevTools (Network 탭), curl, Postman.
  • Trade-offs: 응답이 끝나면 서버가 클라이언트를 잊어버리는 무상태성의 매정한 설계 덕분에 서버 수평 확장(Scale-out)이 무한히 가능해지는 물리적 이점.
• How to Learn:
  • 1단계: 네트워크 탭을 열고 구글에 접속하여, "Request Header(내가 보내는 브라우저 정보)"와 "Response Header(구글 서버가 주는 캐시 지시자 등)"의 구조를 해부합니다.
  • 2단계: 네트워크가 끊겨 사용자가 '결제' 버튼을 두 번 눌렀을 때, POST(결제 생성)는 돈이 두 번 빠져나가지만 PUT(결제 상태를 완료로 덮어쓰기)은 몇 번을 눌러도 안전한 멱등성의 원리를 비즈니스 로직에 결합하여 이해합니다.
• Implement: 특정 이커머스 장바구니 도메인에서 발생할 수 있는 10가지 시나리오(조회, 추가, 부분 수정, 전체 수정, 에러)에 대응하는 정확한 HTTP 메서드와 상태 코드 매핑 테이블 작성.

Recommended

Core Topic 02: 브라우저 상태 관리와 CORS (Web State Mechanics)

• Why to Learn: 무상태 환경인 웹에서 "네가 어제 로그인한 그 유저가 맞구나"라는 것을 증명하고, 악의적인 해커 웹사이트의 API 호출을 물리적으로 차단하기 위해서입니다.
• What to Learn:
  • Concepts: Cookie, Session, Token(JWT), Same-Origin Policy(SOP), CORS(Cross-Origin Resource Sharing).
  • Skills: 세션 ID 기반 인증 아키텍처, 브라우저의 Preflight Request(OPTIONS) 매커니즘 해석.
  • Tools: 브라우저 Application 탭.
  • Trade-offs: 서버가 모든 로그인 세션을 메모리에 들고 있으면 관리는 쉽지만 서버 확장이 어려워지는 문제 vs 세션 데이터를 JWT 암호화 토큰으로 클라이언트에 넘기면 서버는 가벼워지지만 토큰 탈취 시 무효화(Revoke)가 극도로 어려워지는 아키텍처의 딜레마.
• How to Learn:
  • 1단계: 로그인을 하면 서버가 응답 헤더에 Set-Cookie: session_id=1234를 내려주고, 브라우저가 다음 요청부터는 알아서 헤더에 쿠키를 끼워 보내는 자동화 물리를 관찰합니다.
  • 2단계: 로컬 localhost:3000의 프론트엔드가 api.server.com 백엔드를 찌를 때 브라우저가 빨간색 CORS 에러를 뿜어내는 이유를 분석하고, 백엔드가 Access-Control-Allow-Origin 헤더를 열어주어 이 문지기(SOP)를 통과하는 과정을 추적합니다.
• Implement: Node.js/Python으로 간단한 API 서버를 띄우고, 고의로 CORS 에러를 유발한 뒤 백엔드 코드 수정을 통해 이를 해결하는 디버깅 레포트.

Practical

Core Topic 03: RESTful 아키텍처와 HTTP 진화 (REST & HTTP/2,3)

• Why to Learn: 우후죽순 짜여진 스파게티 API를 글로벌 표준 아키텍처로 정립하고, 로딩이 느린 웹 환경을 프로토콜 교체만으로 비약적으로 가속하기 위함입니다.
• What to Learn:
  • Concepts: REST(Representational State Transfer)의 원칙, Richardson 성숙도 모델, HTTP/1.1 vs HTTP/2 vs HTTP/3.
  • Skills: HATEOAS(하이퍼미디어 상태 전이), HTTP/2의 멀티플렉싱(Stream Multiplexing)과 헤더 압축(HPACK), HTTP/3의 QUIC(UDP 기반) 전송.
  • Tools: Swagger / OpenAPI.
  • Trade-offs: HTTP/1.1에서는 이미지를 여러 개 받으려면 TCP 파이프를 여러 개 뚫어야 했던 낭비 vs HTTP/2에서는 하나의 TCP 파이프 안에서 데이터를 쪼개서(Frame) 병렬로 보내는 혁신, 그러나 TCP 파이프 하나가 막히면 병렬 데이터가 다 멈추는 HOL Blocking의 역설.
• How to Learn:
  • 1단계: API 응답 JSON 안에 { "next": "/api/users/2" } 같은 하이퍼링크를 포함시켜, 클라이언트가 하드코딩 없이 서버의 지시(HATEOAS)대로 화면을 넘어가게 만드는 고수준 REST 설계를 구축합니다.
  • 2단계: 이미지 100장이 있는 웹페이지를 HTTP/1.1로 불러올 때의 계단식 폭포(Waterfall) 로딩과, HTTP/2로 불러올 때 동시다발적으로 떨어지는 병렬 로딩 차이를 네트워크 탭에서 비교합니다.
• Implement: 현재 운영 중인 서비스나 외부 퍼블릭 API(GitHub 등)를 하나 선정하여, Richardson 성숙도 모델에 기반해 어느 레벨에 위치하는지 평가하고 Level 3로 가기 위한 리팩토링 제안서 작성.

Advanced

Core Topic 04: GraphQL과 gRPC (Modern API Paradigms)

• Why to Learn: 모바일 환경에서 데이터 낭비를 막고(GraphQL), 거대한 백엔드 마이크로서비스 간에 데이터를 빛의 속도로 쏘아대기(gRPC) 위해서입니다.
• What to Learn:
  • Concepts: GraphQL(선언적 데이터 질의), gRPC(원격 프로시저 호출), Protocol Buffers(Protobuf).
  • Skills: GraphQL 스키마 정의 및 N+1 문제 해결(DataLoader), gRPC 인터페이스 정의(IDL) 컴파일링, HTTP/2 기반 양방향 스트리밍(Bi-directional Streaming).
  • Tools: Apollo GraphQL, gRPC CLI, Protocol Buffers Compiler(protoc).
  • Trade-offs: 클라이언트가 원하는 데이터만 쏙쏙 골라가서 네트워크 대역폭이 비약적으로 절감되는 GraphQL vs 무거운 JSON 대신 이진 데이터(Binary)를 써서 구문 분석(Parsing) CPU 부하를 0으로 수렴시키는 gRPC의 백엔드 특화 성능.
• How to Learn:
  • 1단계: REST에서는 '유저의 최근 작성 글 제목들'을 가져오기 위해 /users/1, /posts?userId=1을 두 번 호출(Under-fetching)해야 하지만, GraphQL에서는 단 한 번의 쿼리로 정확히 원하는 구조를 조립해 내는 과정을 실습합니다.
  • 2단계: .proto 파일에 rpc GetUser (UserRequest) returns (UserResponse)라고 인터페이스를 정의하고 컴파일(protoc)을 돌리면, 서버와 클라이언트 네트워크 통신 코드가 여러 언어(Go, Java, Python 등)로 자동 생성되는 마법 같은 생산성을 체험합니다.
• Implement: 특정 기능(예: 실시간 위치 정보 전송)에 대해 REST(JSON), GraphQL, gRPC 세 가지 패러다임으로 더미(Dummy) 서버를 구현하고, 각각의 페이로드 바이트 크기와 직렬화/역직렬화 소요 시간을 측정한 벤치마킹 보고서.

7. Terminology

8. References

Primary References

• [P1] CS2023 - NC/Application Layer Protocols — Web standards.
• [P2] SWEBOK v4.0 - Software Design/Web APIs — Interface engineering.

Secondary References

• [RESTful Web APIs] Leonard Richardson — Practical REST guide.
• [Learning GraphQL] Eve Porcello — Comprehensive schema design.

Industry References

• [Mozilla Developer Network (MDN) - HTTP] — The gold standard for web docs.
• [Google API Design Guide] — High-level enterprise API standards.

9. Final Checklist

Primary Checklist

• HTTP의 비연결성(Connectionless)과 무상태성(Stateless)이 분산 시스템의 확장성에 미치는 물리적 이점을 설명할 수 있는 있는가? (P1)
• REST API 설계 시 적절한 HTTP 상태 코드(2xx, 4xx, 5xx)를 상황에 맞게 분류하여 응답할 수 있는가? (P2)

Secondary Checklist

• HTTP/2의 헤더 압축(HPACK)이 모바일 네트워크의 대역폭 절감에 어떻게 기여하는지 원리를 이해하는가?
• GraphQL의 N+1 쿼리 문제가 발생하는 물리적 이유와 이를 해결하기 위한 데이터 로더(DataLoader) 패턴을 인지하는가?

Industry Checklist

• 공개 API를 설계할 때, 인증(Authentication) 정보를 헤더에 담아야 하는 보안적 이유를 HTTP 프로토콜 구조와 연결하여 설명 가능한가? (SFIA)
• 서비스 간 통신(Microservices)을 설계할 때 메시지 페이로드 크기와 CPU 비용을 고려하여 JSON과 Protobuf 중 무엇을 선택할지 논증 가능한가?