콘텐츠로 바로가기
HY_TECH_BASE

Web Protocols & API Paradigms

현대 웹 애플리케이션의 통신 기반인 HTTP 프로토콜의 진화와 REST, GraphQL, gRPC 등 다양한 데이터 교환 패러다임의 설계 원칙을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

웹 프로토콜 및 API 패러다임(Web Protocols & API Paradigms, WAP)은 정보가 웹 브라우저와 서버 사이에서 어떻게 논리적으로 구조화되어 오가는지를 다룹니다.

웹은 단순한 문서 전달 체계를 넘어 복잡한 분산 애플리케이션 플랫폼으로 진화했습니다. 학습자는 무상태성(Stateless)을 기반으로 하는 HTTP/1.1의 한계와 이를 극복한 HTTP/2 (Multiplexing), HTTP/3 (QUIC)의 물리적 전송 혁신을 배웁니다. 또한, 자원 중심의 REST, 클라이언트 필요 중심의 GraphQL, 고성능 RPC 중심의 gRPC 등 서로 다른 API 설계 철학을 이해하여 비즈니스 요구사항에 최적화된 통신 인터페이스를 구축하는 역량을 갖춥니다.

2. Scope & Boundaries

In-Scope

  • HTTP Evolution: HTTP/1.1, HTTP/2, HTTP/3 프로토콜의 작동 물리 및 헤더 압축
  • REST Lifecycle: 자원(Resource), 메서드(Method), 미디어 타입 및 HATEOAS 설계
  • Alternative Paradigms: GraphQL의 스키마 정의 및 쿼리 역학, gRPC와 Protobuf의 이진 전송
  • Web State Handling: 쿠키(Cookie), 세션(Session), JWT를 이용한 상태 유지 및 논리적 흐름

Out-of-Scope

  • 프론트엔드 프레임워크(React, Vue)의 UI 컴포넌트 구현 (12. HCI 영역으로 위임)
  • 데이터베이스의 SQL 쿼리 성능 최적화 (06. Data 영역으로 위임)

Boundaries

  • WAP vs. Network Transport: 08-02(TRP)가 '패킷과 바이트의 전송'을 다룬다면, WAP은 '메시지의 의미와 API 설계 구조'에 집중합니다.

3. Counterexample

  • 단순히 REST API 문서를 작성하는 법을 익히는 것은 WAP 학습이 아닙니다. 왜 HTTP/1.1에서 발생하던 HOL(Head-of-Line) Blocking 문제가 HTTP/2의 Stream Multiplexing을 통해 물리적으로 어떻게 해결되는지 그 전송 메커니즘을 설명하고, 왜 오버헤드가 적은 gRPC가 마이크로서비스 간 통신(Internal)에서 REST보다 유리한지 트레이드오프를 논할 수 있어야 합니다.

4. Prerequisites

  • 네트워크 기초 및 OSI 스택 (Basic): 애플리케이션 계층(L7)의 위치 이해가 필요합니다. (08. NFS)
  • TCP, IP 및 라우팅 프로토콜 (Recommended): TCP 연결 지연 및 UDP 기반 QUIC 이해를 위해 전송 계층 지식이 권장됩니다. (08. TRP)

5. Learning Map

  1. The Language of Web: HTTP 요청/응답 구조와 상태 코드의 표준 인터페이스를 익힙니다.
  2. Speeding Up: 비효율적인 텍스트 기반 전송을 개선하는 현대적 웹 프로토콜의 기술적 배경을 배웁니다.
  3. Designing Contracts: 개발자 간의 약속인 API를 설계하는 RESTful 및 다양한 패턴을 배웁니다.
  4. Binary & Type Safety: 대규모 시스템에서 성능과 타입 안정성을 보장하는 최신 API 기술(gRPC 등)을 탐구합니다.

6. Learning Topics

Basic

Core: HTTP 기본 물리 및 상태 관리 (HTTP Basics)

  • Why to Learn: 모든 웹 통신의 가장 기본이 되는 규약을 이해하여 클라이언트-서버 구조를 명확히 파악하기 위함입니다.
  • What to Learn:
    • HTTP 요청/응답 헤더와 페이로드(Payload)의 물리적 구분
    • GET, POST, PUT, DELETE 메서드의 멱등성(Idempotency) 및 의미
    • 무상태(Stateless) 환경에서 상태를 유지하기 위한 Cookie와 Session의 논리적 동작
  • How to Learn:
    • 브라우저 개발자 도구(F12 Network tab)를 지원하여 실제 웹사이트 접속 시 오가는 HTTP 패킷 분석
    • curl 명령어를 사용하여 수동으로 HTTP 요청을 보내고 응답 헤더의 서버 정보를 파약
  • Implement: 로그인 상태 유지 시나리오에서 Cookie와 Session의 흐름을 기술한 시퀀스 다이어그램

Core: 현대적 웹 전송 기술 (HTTP/2, HTTP/3)

  • Why to Learn: 대규모 사용자 대응 시 웹 페이지 로딩 속도를 물리적으로 개선하기 위해서입니다.
  • What to Learn:
    • HTTP/1.1의 한계: HOL Blocking과 RTT 지연
    • HTTP/2: Multiplexing, Server Push, Header Compression(HPACK)
    • HTTP/3 & QUIC: 패킷 손실 시 복구 알고리즘의 유연성 및 암호화 결합
  • How to Learn:
    • 동일한 리소스 수백 개를 HTTP/1.1과 HTTP/2 환경에서 로딩할 때의 워터폴(Waterfall) 차이 비교
    • QUIC 프로토콜의 0-RTT 연결 설정 방식이 모바일 환경의 레이턴시에 미치는 영향 분석
  • Implement: 프로토콜 버전별 웹 성능 렌더링 지표 비교 분석서

Practical

Core: RESTful 아키텍처 설계 (REST Design)

  • Why to Learn: 다른 개발자가 이해하기 쉽고 유지보수가 용이한 표준 API 인터페이스를 제공하기 위함입니다.
  • What to Learn:
    • 리소스(URI) 중심의 명명 규칙과 계층 구조 설계
    • Richardson 성숙도 모델(Level 0-3)의 단계별 요구사항
    • API 버전 관리 전략(Header vs URL)과 문서화 표준(OpenAPI/Swagger)
  • How to Learn:
    • 기존의 비표준 API를 RESTful하게 리팩토링하는 설계 과제 수행
    • Postman 등을 활용하여 설계된 API의 실제 응답과 에러 코드가 표준에 부합하는지 검증
  • Implement: 특정 도메인(예: 쇼핑몰)의 핵심 리소스를 정의한 RESTful API 명세서

Advanced

Core: GraphQL과 gRPC 패러다임 (Alternative APIs)

  • Why to Learn: REST의 데이터 오버페칭(Over-fetching) 문제를 해결하거나 극한의 통신 성능을 확보하기 위해서입니다.
  • What to Learn:
    • GraphQL: 단일 엔드포인트, Query/Mutation 스키마 및 Resolver 구현 물리
    • gRPC: Protocol Buffers를 이용한 인터페이스 정의(IDL) 및 코드 생성 역학
    • 브라우저 환경 vs 서버-서버 환경에서의 프로토콜 최적화 트레이드오프
  • How to Learn:
    • 동일한 요구사항을 REST와 GraphQL로 구현했을 때 네트워크 전송 데이터 용량 비교
    • gRPC의 스트리밍(Streaming) 기능을 활용하여 실시간 데이터 전송 모듈 구축 실습
  • Implement: 데이터 복잡성이 높은 조회 환경에서의 GraphQL 도입 타당성 검토 보고서

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
Idempotency (멱등성) 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질로, API 에러 복구의 핵심 논리입니다. 기본 설계 원칙 Safe Method GET / PUT / POST 동일한 응답을 주는 것으로 오해 P2:SWEBOK core
HOL Blocking 네트워크에서 앞선 데이터 처리가 늦어져 뒤의 데이터들이 물리적으로 대기하게 되는 현상입니다. 권장 성능 이슈 HTTP/1.1 Multiplexing 단순히 '서버 느림'으로 오해 Industry 7540 core
HATEOAS 애플리케이션의 상태 변화를 응답 내의 하이퍼링크를 통해 동적으로 안내하는 REST의 원칙입니다. 실무 설계 수준 API Maturity Richardson Model 단순히 '링크 포함'으로 오해 Industry Dissertation core
Protobuf 구글에서 개발한 구조화된 데이터를 직렬화하는 이진(Binary) 포맷으로 gRPC의 기본 데이터 물리입니다. 심화 데이터 전송 Serialization JSON / XML 텍스트 파일로 오해 Industry Standard core

8. References

Primary References

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 중 무엇을 선택할지 논증 가능한가?

Concepts & Tags

#http-protocols#rest-api#graphql#grpc#state-management