테마
현대 웹과 REST API
웹의 진화: 문서에서 애플리케이션으로
초기 웹은 정적 HTML 문서를 보여주는 문서 뷰어였다. 이후 CSS로 스타일이 분리되고, JavaScript가 도입되면서 웹은 단순한 문서 열람을 넘어 복잡한 애플리케이션 플랫폼으로 진화했다.
SSR vs CSR
웹 페이지를 생성하는 방식에는 두 가지 패러다임이 있다.
SSR(Server-Side Rendering): 서버가 HTML을 만든다
전통적인 방식이다. 서버(WAS)가 데이터와 템플릿을 결합하여 완성된 HTML을 클라이언트에 보낸다.
CSR(Client-Side Rendering): 브라우저가 HTML을 만든다
현대적인 방식이다. 서버는 **순수한 데이터(JSON)**만 보내고, 브라우저의 JavaScript 프레임워크가 데이터를 받아 HTML을 생성한다.
SSR vs CSR 비교
| 항목 | SSR | CSR |
|---|---|---|
| HTML 생성 위치 | 서버 | 클라이언트 (브라우저) |
| 서버 응답 형태 | 완성된 HTML | JSON/XML 데이터 |
| 대표 기술 | JSP, PHP, ASP | React, Vue.js, Angular |
| 장점 | SEO 유리, 초기 로딩 빠름 | 유연한 UI, 서버 부하 감소 |
현대 프레임워크는 이 둘을 완전히 이분법으로 나누기보다 혼합 전략을 사용한다. 예를 들어 초기 화면은 SSR로 빠르게 전달하고, 이후 상호작용은 CSR로 처리하는 방식이 흔하다.
SPA(Single Page Application)
CSR 방식을 극단적으로 적용한 것이 SPA이다. 페이지 이동 없이 하나의 HTML 페이지 안에서 JavaScript가 화면을 동적으로 교체한다.
대표적인 SPA 프레임워크가 다음과 같다.
- React (Meta/Facebook)
- Vue.js (Evan You)
- Angular (Google)
SPA에서 서버와의 통신은 전부 API 호출로 이루어지며, 응답은 JSON 형식이다.
CSR이 등장한 이유: 디바이스 다양성
서버에서 HTML을 만들어 보내는 SSR 방식은, 클라이언트 환경이 단순할 때는 문제가 없었다. 하지만 현대에는 사용자가 PC, 스마트폰, 태블릿, 스마트 TV 등 다양한 디바이스를 사용한다.
각 디바이스마다 별도의 HTML을 서버에서 만드는 것은 비효율적이다. 서버는 데이터만 제공하고, 각 클라이언트가 자신의 환경에 맞게 UI를 렌더링하는 것이 CSR의 핵심 철학이다.
HTTP API, REST, CRUD
많은 웹 API가 HTTP 메서드를 데이터 조작에 대응시키며 설계된다. 흔히 이를 REST API라고 부르지만, 엄밀히 말하면 REST(Representational State Transfer) 는 리소스 지향 URI, 무상태성, 캐시 가능성 같은 제약을 포함한 아키텍처 스타일이다. 따라서 단순히 CRUD와 메서드를 매핑했다고 해서 자동으로 REST가 되는 것은 아니다.
| CRUD | HTTP 메서드 | URL 예시 | 설명 |
|---|---|---|---|
| Create | POST | /api/users | 새 사용자 생성 |
| Read | GET | /api/users/1 | 사용자 1번 조회 |
| Update | PUT/PATCH | /api/users/1 | 사용자 1번 수정 |
| Delete | DELETE | /api/users/1 | 사용자 1번 삭제 |
JSON: 데이터 교환 형식
CSR 환경에서 서버와 클라이언트 사이에 오가는 데이터의 표준 형식이 **JSON(JavaScript Object Notation)**이다.
json
{
"name": "철수",
"age": 25,
"email": "cheolsu@example.com",
"skills": ["JavaScript", "React", "Node.js"]
}JSON은 텍스트 기반이라 사람이 읽을 수 있고, 거의 모든 프로그래밍 언어에서 파싱이 가능하다. XML에 비해 간결하고 가벼워 현대 웹에서 사실상 표준으로 자리잡았다.
UDP와 HTTP/3 (QUIC)
TCP 기반의 HTTP/1.1, HTTP/2를 넘어, UDP 기반의 HTTP/3가 등장했다. HTTP/3는 QUIC 프로토콜 위에서 동작한다.
HTTP/3가 UDP 위에서 동작하는 이유는 "UDP라서 무조건 빠르다"기보다, QUIC이 사용자 공간에서 연결 관리, 재전송, 혼잡 제어, TLS 1.3 통합을 구현할 수 있기 때문이다. 이를 통해 연결 설정 지연을 줄이고, TCP 기반 HTTP/2에서 문제가 되던 일부 헤드 오브 라인 블로킹 영향을 완화할 수 있다.
UDP가 적합한 서비스
| 서비스 유형 | 이유 |
|---|---|
| IPTV / 동영상 스트리밍 | 일부 데이터 손실보다 전체 지연이 중요 |
| 온라인 게임 | 동기화 속도 우선, 일부 워프 허용 |
| 화상 회의 | 실시간성이 핵심 |
| HTTP/3 (QUIC) | 애플리케이션 레벨 혼잡 제어로 성능 향상 |
핵심 정리
- SSR: 서버가 HTML을 만들어 보낸다 (전통적 방식)
- CSR: 서버는 JSON 데이터만 제공하고, 클라이언트가 HTML을 생성한다 (현대적 방식)
- SPA: 하나의 페이지에서 JavaScript가 화면을 동적으로 교체한다
- HTTP API 설계: CRUD와 메서드 매핑은 흔하지만, REST는 그보다 더 넓은 아키텍처 스타일이다
- JSON: 현대 웹의 표준 데이터 교환 형식이다
- HTTP/3(QUIC): UDP 기반으로 더 빠른 웹 통신을 실현한다