HTTP: 클라이언트 - 서버 구조

HTTP를 이해하려면 제일 먼저 “클라이언트와 서버가 어떤 역할을 하는지”를 잡아야 한다.
웹은 기본적으로 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 돌려주는 구조로 돌아간다.

1) 클라이언트와 서버의 정의

클라이언트(Client)

• 요청을 보내는 주체
• 대표적으로 브라우저(Chrome/Safari), 모바일 앱, 서버에서 서버로 호출하는 API 클라이언트 등
• “화면”만 의미하는 게 아니라 HTTP 요청을 만드는 쪽이면 클라이언트다.

서버(Server)

• 요청을 받아 처리하고 응답을 만드는 주체
• 웹서버(Nginx), 애플리케이션 서버(Spring Boot), DB 서버 등으로 역할이 더 나뉠 수 있음
• 핵심은 요청을 처리하는 책임이 서버에 있다는 점

2) 왜 굳이 클라이언트-서버 구조로 나눌까?

핵심은 역할 분리(Separation of Concerns) 다.

• 클라이언트: 사용자와 가까운 영역
  → UI/입력/표현/상태(일부) 담당
• 서버: 비즈니스 로직과 데이터의 중심
  → 인증/권한/규칙/DB 처리/검증 담당

이렇게 나누면 얻는 이점이 크다.

장점

1. 확장성(Scale-out)
   • 서버만 여러 대로 늘려서 트래픽을 감당할 수 있음
2. 유지보수성
   • UI 변경(클라이언트)과 비즈니스 로직 변경(서버)이 서로 덜 엉킴
3. 보안
   • 중요한 로직/데이터를 서버에 두고 접근을 통제할 수 있음
4. 재사용성
   • 서버 API 하나로 웹/앱/외부 파트너 등 여러 클라이언트가 재사용 가능

3) HTTP 관점에서의 “요청-응답” 흐름

클라이언트-서버 구조를 가장 단순하게 적으면 아래다.

Client  --HTTP Request-->  Server
Client  <--HTTP Response-- Server

요청(Request)에 주로 담기는 것

• 메서드(Method): GET/POST/PUT/DELETE…
• URL(경로): 어떤 자원을 요청하는지
• 헤더(Header): 부가 정보(인증 토큰, 콘텐츠 타입, 캐시 등)
• 바디(Body): 실제 데이터(주로 POST/PUT/PATCH)

응답(Response)에 주로 담기는 것

• 상태 코드(Status): 200/201/400/401/404/500…
• 헤더(Header): 응답 형식, 캐시 정책 등
• 바디(Body): HTML/JSON/이미지 등

4) “서버”는 하나가 아닐 수 있다 

현실 서비스에서는 서버가 보통 계층으로 나뉜다.

Client
  ↓
Web Server (Nginx)  - 정적파일/리버스프록시/로드밸런싱
  ↓
App Server (Spring Boot) - 비즈니스 로직, 인증/권한, API 처리
  ↓
DB / Cache (MySQL, Redis)

하지만 HTTP 관점에서는 클라이언트 입장에서 응답을 주는 최종 상대가 서버다.

5) 자주 헷갈리는 포인트 3개

1. “브라우저만 클라이언트다?”

아님. HTTP 요청을 보내는 모든 주체가 클라이언트다.
예: 백엔드가 다른 서버 API 호출하면 그 순간 백엔드도 클라이언트 역할.

2. “서버는 항상 한 대?”

아님. 서버는 수평 확장 가능하고(여러 대) 내부적으로 계층도 많다.

3. “서버가 UI까지 전부 만드는가?”

케이스가 갈린다.

• SSR(Server Side Rendering): 서버가 HTML을 만들어 내려줌
• CSR(Client Side Rendering): 서버는 JSON 주고, 화면은 클라이언트가 그림(React 등)

SSR/CSR은 “화면(HTML)을 어디서 만들어서 사용자에게 보여주느냐” 차이

SSR (Server-Side Rendering)

서버가 HTML을 만들어서 브라우저에 보내주는 방식.

• 흐름
  1. 브라우저 요청
  2. 서버가 DB/API 조회
  3. 완성된 HTML 생성
  4. 브라우저는 받은 HTML을 바로 렌더링
• 장점
  • 첫 화면이 빨리 뜨는 편(초기 로딩 유리)
  • 검색엔진(SEO)에 유리한 경우가 많음
  • 저사양 기기에서도 부담이 덜할 수 있음
• 단점
  • 화면 이동/상호작용마다 서버 렌더링이 필요하면 서버 부담↑
  • 페이지 전환이 “새로고침 느낌”으로 끊길 수 있음(구현 방식에 따라)
• 예시
  • 전통적인 JSP/Thymeleaf, Rails, Django 템플릿 렌더링
  • Next.js에서 SSR 모드 사용

CSR (Client-Side Rendering)

서버는 주로 데이터(JSON) 만 주고 브라우저(클라이언트)가 JS로 화면을 그리는 방식

• 흐름
  1. 브라우저가 최초에 HTML(뼈대) + JS 번들을 받음
  2. JS 실행
  3. API 요청으로 데이터(JSON) 받음
  4. 브라우저가 DOM을 조작해서 화면 렌더링
• 장점
  • 화면 전환이 부드럽고 앱처럼 동작(SPA)
  • 서버는 렌더링 대신 API에 집중 가능
  • UI 인터랙션이 많은 서비스에 적합
• 단점
  • 초기 로딩이 느릴 수 있음(JS 다운로드/실행 필요)
  • SEO는 추가 처리(프리렌더/SSR/SSG 등)가 필요할 수 있음
  • 클라이언트 성능/네트워크에 더 민감
• 예시
  • React/Vue/Angular SPA 전형

한 줄로 구분

• SSR: “서버가 HTML을 만들어준다”
• CSR: “브라우저가 JS로 화면을 만든다(서버는 데이터 중심)”

언제 뭘 쓰는 게 흔한가?

• SEO/초기 로딩이 중요(블로그, 쇼핑몰, 마케팅 페이지) → SSR(또는 SSG) 많이 선택
• 인터랙션이 많은 웹앱(대시보드, 관리툴, 채팅) → CSR(SPA) 많이 선택
• 요즘은 혼합이 많음(Next.js 같은 프레임워크로 SSR + CSR 섞기)

6) 면접에서 자주 묻는 질문 형태

• 클라이언트와 서버의 역할을 각각 설명해보세요.
• 왜 클라이언트-서버 구조가 확장성과 유지보수에 유리한가요?
• 서버를 수평 확장하면 어떤 문제가 생기고(세션/상태), 어떻게 해결하나요?
• SSR과 CSR의 차이와 장단점을 설명해보세요.