단북
프론트엔드를 위한 HTTP & 웹 서버·HTTP 기초

요청과 응답

HTTP의 기본 구성요소를 정리합니다. URI의 구조, GET 요청과 응답의 구성, 상태 코드와 헤더를 curl과 브라우저 DevTools로 확인합니다.

HTTP(HyperText Transfer Protocol)는 브라우저와 웹 서버가 주고받는 약속된 형식입니다. 페이지를 열거나 파일을 내려받거나 영상을 재생할 때, 그 아래에서는 항상 HTTP 요청과 응답이 오갑니다. 이 레슨에서는 HTTP의 기본 구성요소인 URI, 요청, 응답, 상태 코드, 헤더를 정리합니다.

클라이언트와 서버

HTTP 통신에는 항상 클라이언트와 서버가 있습니다. 브라우저가 대표적인 클라이언트로, 서버에 요청(request)을 보내고 서버는 응답(response)을 돌려줍니다. 페이지 하나를 그리는 데에도 여러 번의 요청이 오가며, 서로 다른 서버로 향하기도 합니다. 예를 들어 한 페이지의 HTML은 자체 서버에서, 그 안에 삽입된 영상은 YouTube 서버에서 받아옵니다.

클라이언트는 브라우저만 있는 것은 아닙니다. 모바일 앱, 서버 간 통신 코드 등 네트워크 너머의 프로그램과 데이터를 주고받아야 하는 많은 소프트웨어가 HTTP를 사용합니다.

서버는 브라우저보다 단순합니다. UI나 렌더링이 없고, 들어오는 요청을 처리해 응답을 돌려주는 한 가지 일만 합니다.

URI의 구조

웹 주소를 정확히는 URI(Uniform Resource Identifier)라고 부릅니다. URL이라는 표현도 거의 같은 의미입니다. URI는 여러 부분으로 이루어지며, 대부분 선택 사항이라 서비스마다 모양이 달라 보입니다.

https://en.wikipedia.org/wiki/Fish?lang=ko#summary
└─┬─┘   └──────┬──────┘└───┬───┘└───┬──┘└──┬──┘
 scheme     hostname      path     query  fragment
  • scheme — 리소스에 접근하는 방식. http, https, file, mailto 등. https는 암호화된 연결을 사용합니다.
  • hostname — 어느 서버에 연결할지. en.wikipedia.org, localhost 같은 이름 또는 IP 주소.
  • path — 서버 안의 어떤 리소스인지. 실제 파일 경로일 수도 있고, 서버가 해석해 동적으로 만들어내는 값일 수도 있습니다.
  • query — ? 뒤에 key=value 형태로 붙는 값. 서버로 전송됩니다.
  • fragment — # 뒤의 값. 브라우저가 페이지 안의 특정 위치로 스크롤하는 데 쓰며, 서버로 전송되지 않습니다.

path가 항상 파일 이름인 것은 아닙니다. /search?q=fish 같은 경로는 서버에 그런 파일이 있다는 뜻이 아니라, 서버가 경로를 해석해 그때그때 결과를 만들어 응답한다는 뜻입니다.

scheme이나 hostname 없이 path만 있는 형태는 상대 URI입니다. <a href="logo.png">처럼 쓰면 브라우저가 현재 페이지를 기준으로 같은 서버에서 받아옵니다.

다음 URI에서 fragment(#) 부분에 대한 설명으로 옳은 것은? https://example.com/docs?page=2#install

hostname에서 서버까지: DNS와 포트

브라우저가 hostname을 가지고 실제 서버에 닿기까지는 두 단계를 거칩니다.

  1. DNS 조회 — en.wikipedia.org 같은 이름을 IP 주소로 변환합니다. 인터넷은 IP 주소로 컴퓨터를 구분하므로, 이름을 주소로 바꾸는 과정이 필요합니다.
  2. 포트 연결 — IP 주소 위의 특정 포트로 연결합니다. IP 주소가 컴퓨터를 구분한다면, 포트 번호는 그 컴퓨터 안의 프로그램을 구분합니다.

터미널에서 직접 DNS를 조회할 수 있습니다.

$ dig +short en.wikipedia.org
# 또는
$ host en.wikipedia.org

포트 번호는 scheme에서 기본값이 정해집니다. http는 80번, https는 443번입니다. 그래서 평소 주소에는 포트가 보이지 않고, 기본값이 아닐 때만 localhost:8000처럼 명시합니다. 0~1023번은 관리자(root) 권한이 있어야 사용할 수 있어, 학습용 서버는 보통 8000번이나 3000번 같은 높은 포트를 씁니다.

GET 요청의 구조

요청에는 서버에 무엇을 시킬지 알려주는 메서드(HTTP verb)가 들어갑니다. 그중 GET은 리소스를 받아오려 할 때 쓰는 메서드로, 브라우저가 페이지·이미지를 받을 때 사용합니다.

curl -v로 요청과 응답을 함께 볼 수 있습니다. >로 시작하는 줄이 브라우저가 보낸 요청입니다.

$ curl -v https://example.com/
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.4.0
> Accept: */*

요청의 첫 줄은 세 부분으로 이루어집니다.

  • GET — 메서드. 어떤 동작을 요청하는지.
  • / — path. URI 전체가 아니라 경로만 보냅니다.
  • HTTP/1.1 — 프로토콜 버전.

그 아래 Host:, User-Agent: 같은 줄은 요청 헤더입니다. HTTP/1.1에서 Host 헤더는 필수인데, 한 서버가 여러 도메인을 호스팅할 수 있어 어느 사이트와 통신하려는지 알려줘야 하기 때문입니다.

응답의 구조: 상태 줄, 헤더, 본문

서버의 응답은 세 부분으로 나뉩니다. curl -v에서 <로 시작하는 줄이 응답입니다.

< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 1256
<
<!doctype html> ...
  • 상태 줄 — HTTP/1.1 200 OK. 프로토콜 버전과 상태 코드.
  • 헤더 — 첫 빈 줄까지의 줄들. 응답에 대한 메타데이터.
  • 본문(body) — 빈 줄 다음의 내용. 요청한 리소스 자체(HTML, 이미지 등)나 에러 메시지.

상태 코드

상태 코드의 첫 자리가 요청의 대략적인 결과를 나타냅니다.

분류의미
1xx정보. 요청 처리 중이거나 다음 단계가 있음.
2xx성공. 요청이 처리되어 데이터를 보냄. (200 OK)
3xx리다이렉트. 다른 URI로 이동하라는 응답. Location 헤더에 새 주소.
4xx클라이언트 오류. 잘못된 요청·권한 문제 등. (404 Not Found, 403, 400)
5xx서버 오류. 서버 쪽에서 문제가 생김. (500, 502, 503)

리다이렉트는 좋은 사용자 경험의 예이기도 합니다. google.com에 접속하면 서버는 에러 대신 301 Moved Permanently와 함께 Location: https://www.google.com/을 보내고, 브라우저는 이를 따라 올바른 주소로 이동합니다.

API 호출에서 404 Not Found를 받았다. 가장 적절한 해석은?

헤더

헤더는 이름: 값 형태로 응답에 대한 정보를 전달합니다. 브라우저에 직접 표시되지는 않지만, 웹의 많은 기능이 헤더로 구현됩니다.

  • Content-Type — 본문의 데이터 종류. text/html; charset=utf-8, image/png, application/json 등. 텍스트라면 인코딩(주로 UTF-8)도 함께 알려줍니다.
  • Content-Length — 본문의 길이(바이트). 클라이언트가 응답을 어디까지 읽으면 되는지 알 수 있어, 한 연결로 여러 요청을 이어서 보낼 수 있습니다.
  • Location — 3xx 리다이렉트에서 이동할 주소.
  • Set-Cookie — 브라우저에 쿠키를 저장하도록 요청. (3편에서 다룸)

Content-Type은 프론트엔드에서 자주 마주치는 헤더입니다. fetch로 받은 응답을 .json()으로 파싱할 때 서버가 application/json을 보냈는지, 파일 다운로드가 의도대로 동작하는지 등이 모두 이 헤더에 달려 있습니다.

브라우저 DevTools로 확인하기

지금까지 본 요청·응답·상태 코드·헤더는 모두 브라우저 개발자 도구의 Network 탭에서 볼 수 있습니다.

  1. DevTools를 열고(F12 또는 Cmd+Opt+I) Network 탭으로 이동합니다.
  2. 페이지를 새로고침하면 모든 요청이 목록에 나타납니다.
  3. 요청 하나를 클릭하면 Headers(요청/응답 헤더), Payload(query·body), Response(본문), 상태 코드를 확인할 수 있습니다.

curl이 터미널에서 보여주는 것과 같은 정보를, DevTools는 브라우저가 실제로 주고받은 모든 요청에 대해 보여줍니다. 프론트엔드 디버깅의 출발점입니다.

정리 · HTTP 한 번의 교환은 요청(메서드 + path + 헤더) 과 응답(상태 코드 + 헤더 + 본문) 으로 이루어집니다. 페이지를 열 때마다 이 교환이 수십 번씩 반복되며, 그 전부를 Network 탭에서 확인할 수 있습니다.

이 레슨을 다 읽으셨나요?

완료 표시는 이 브라우저에 저장됩니다.