웹 동작 원리 HTTP와 URL로 보는 요청과 응답

주소창에 www.naver.com을 입력하고 엔터를 누르면 화면에 페이지가 뜬다. 매일 수십 번 반복하는 동작이지만, 그 사이에 무슨 일이 벌어지는지 설명하라고 하면 막히는 개발자가 많다. 결론부터 말하면 웹의 동작 원리는 생각보다 단순하다. 어떤 컴퓨터에 저장된 문서 하나를 네트워크 너머에서 요청하고, 그 컴퓨터가 문서를 돌려주는 것이 전부다. 이 글은 그 단순한 구조를 URL과 HTTP라는 두 축으로 풀어낸다. 신입 개발자가 처음 웹을 이해할 때 알아야 할 최소한의 골격이다

웹은 논문 참고문헌을 추적하다 태어났다

웹을 만든 사람은 팀 버너스 리(Tim Berners-Lee)다. 그는 2016년 ACM 튜링상을 받았고, 시상은 2017년에 이루어졌다. 튜링상은 IT 분야에 노벨상이 없는 탓에 사실상 컴퓨터 과학의 노벨상으로 불린다. 웹을 만든 공로를 한참 뒤에야 인정받은 셈이다

그가 웹을 구상한 곳은 유럽입자물리연구소(CERN)다. 1989년, 그는 연구소 내부의 정보 관리 시스템을 제안했고 이듬해에 첫 웹 서버와 브라우저, 그리고 핵심 프로토콜을 만들어 냈다. 출발점은 거창한 비전이 아니라 연구자들의 일상적인 불편이었다

연구소에서 가장 많이 보는 문서는 논문이다. 논문은 본문 뒤에 항상 참고문헌이 붙는다. A 논문을 읽다 보면 B를 봐야 하고, B를 읽다 보면 C와 D까지 따라가야 한다. 종이책이라면 그때마다 도서관 서가를 다시 뒤져야 한다. 문서와 문서 사이에는 분명히 관계가 존재하는데, 그 관계를 따라가는 일이 너무 번거로웠다

버너스 리는 이 관계 자체를 문서 안에 심자고 생각했다. 화면에 띄운 논문에서 참조 부분을 마우스로 클릭하면 다음 문서가 곧바로 열리게 하는 것이다. 이렇게 문서를 잇는 관계가 바로 링크(link)이고, 링크를 표현할 수 있도록 만든 문서 형식이 HTML(HyperText Markup Language)이다. 일반 텍스트와 달리 하이퍼텍스트는 다른 문서로 건너뛸 수 있다

문서 형식만으로는 부족했다. 그 문서를 네트워크 너머로 실어 나를 방법도 필요했다. 마침 인터넷의 기반인 TCP/IP가 자리를 잡아 가던 시기였고, 그는 그 위에서 HTML 문서를 주고받는 전용 프로토콜을 설계했다. 그것이 HTTP(HyperText Transfer Protocol)다. 정리하면 웹을 지탱하는 두 기둥은 문서 형식인 HTML과 전송 규약인 HTTP다

여담으로 그가 인정한 실수도 있다. https:// 처럼 스킴 뒤에 붙는 슬래시 두 개(//)에 대해, 2009년 한 행사에서 그는 이 표기가 사실상 불필요했다고 밝혔다. 당시 프로그래밍 관례를 따랐을 뿐인데, 그 두 글자 때문에 수많은 사람이 잉크와 종이, 그리고 시간을 낭비하게 됐다는 것이다. 불필요하든 아니든 이미 표준이 됐으니 오늘날에도 그대로 쓴다

URL은 인터넷에 연결된 컴퓨터의 파일 하나를 가리킨다

브라우저 주소창에 입력하는 문자열을 흔히 주소 또는 URL이라고 부른다. www.naver.com을 예로 들면, naver.com은 도메인 네임이고 www는 그 도메인에 속한 호스트의 이름이다. 둘이 합쳐져 하나의 주소가 된다

이 주소가 결국 식별하는 대상은 인터넷에 연결된 컴퓨터 한 대다. 도메인 네임은 사람이 읽기 좋은 형태일 뿐, 실제로는 IP 주소로 변환되어 특정 컴퓨터를 가리킨다. 그래서 누구든 인터넷을 통해 그 컴퓨터에 접속해 정보를 주고받을 수 있다

URL의 정식 명칭은 Uniform Resource Locator다. 마지막 단어가 위치(Location)가 아니라 위치 지정자(Locator)라는 점이 핵심이다. 위치를 가리키는 식별자라는 뜻이다. URL은 더 넓은 개념인 URI(Uniform Resource Identifier), 즉 리소스 식별자의 한 종류다

그렇다면 리소스란 무엇인가. 컴퓨터 수준에서 가장 기본적인 리소스는 파일이다. 보고서를 쓰든 친구에게 정리한 내용을 보내든, 우리가 만드는 정보는 기본적으로 파일 단위로 존재한다. 웹에서 리소스가 무엇이냐고 물으면, 엄밀히는 파일만 가리키는 것은 아니지만 입문 단계에서는 기본적으로 파일이라고 생각해도 된다

파일을 찾으려면 위치를 알아야 한다. 운영체제는 경로(path)로 파일의 위치를 표현한다. 윈도우라면 C:\Windows\data\test.html 처럼 드라이브 문자부터 시작하는 전체 경로를 절대 경로 또는 풀 패스라고 부른다. 드라이브 문자는 윈도우에만 있고 리눅스나 macOS에는 없지만, 경로와 파일 이름으로 파일을 식별한다는 원리는 같다

URL은 이 발상을 인터넷 전체로 확장한 것이다. 먼저 어떤 컴퓨터인지 식별하고, 그 컴퓨터의 파일 시스템 안에서 경로를 따라가 리소스 하나를 특정한다. 즉 URL은 인터넷까지 포함한 파일의 위치 표현이다

여기서 자주 놓치는 부분이 하나 있다. www.naver.com만 입력해도 페이지가 뜨는 이유다. 원래 이 뒤에는 /index.html 같은 파일 이름이 와야 한다. 생략하면 브라우저가 기본 파일을 알아서 요청하고, 서버는 색인(index) 파일을 돌려준다. 우리가 첫 화면이라고 부르는 것이 바로 이 기본 파일이다

URL을 뜯어보면 구조가 보인다

URL은 도메인 이름만 덜렁 있는 단순한 형태부터, 파라미터까지 붙은 복잡한 형태까지 다양하다. 전체 구조를 한 번 분해해 두면 어떤 URL을 만나도 읽어 낼 수 있다

https://example.co.kr:443/course.do?cmd=search&search_keyword=test
└─┬─┘   └────┬─────┘  └┬┘ └───┬───┘ └─────────────┬──────────────┘
스킴      호스트         포트    경로              쿼리 문자열

각 부분의 역할은 다음과 같다

구성 요소	예시	역할
스킴	`https`	사용할 프로토콜
호스트	`example.co.kr`	접속할 컴퓨터(도메인 네임)
포트	`443`	컴퓨터 안에서 어떤 서비스로 갈지 지정 (생략 시 기본값)
경로	`/course.do`	컴퓨터 내부의 리소스 위치
쿼리 문자열	`?cmd=search&...`	서버에 전달하는 추가 정보

쿼리 문자열은 인터넷을 쓰다 보면 자주 마주친다. 물음표(?) 뒤에 파라미터=값 형태로 붙고, 파라미터가 여러 개면 앰퍼샌드(&)로 잇는다. 위 예시에서 파라미터는 cmd와 search_keyword이고, 각각의 값은 search와 test다. 검색어나 페이지 번호처럼 같은 페이지에 더 구체적인 요구를 전달할 때 이 방식을 쓴다

HTTP는 요청과 응답, 두 메시지로 끝난다

웹 시스템은 서버와 클라이언트로 이루어진다. 서버는 연결을 기다리고, 클라이언트는 서버에 접속해 원하는 것을 요청한다. 브라우저가 바로 대표적인 클라이언트다. 전체 흐름은 다음과 같이 단순하다.

 클라이언트                           서버
    │                               │
    │  ① 연결                        │ (연결 대기)
    │ ────────────────────────────▶ │
    │                               │
    │  ② 요청 (GET /index.html)      │
    │ ────────────────────────────▶ │
    │                               │  ③ 저장된 HTML 문서를 찾는다
    │  ④ 응답 (200 OK + 문서)         │
    │ ◀──────────────────────────── │
    │                               │
    │  ⑤ 브라우저가 문서를 렌더링         │

클라이언트가 보내는 GET은 HTTP 메서드 중 하나다. “이 문서를 보내 달라”는 요청이라고 보면 된다. 서버는 저장하고 있던 문서를 돌려주고, 클라이언트는 그것을 받아 화면에 표시한다.

요청과 응답은 모두 텍스트 메시지다. 실제 네트워크를 들여다보면 형태가 단순하다. 먼저 클라이언트가 보내는 요청 메시지는 다음과 같다.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html

첫 줄은 “HTTP/1.1 규약으로 /index.html을 GET 해 달라”는 뜻이다. Host는 어느 도메인에 보내는 요청인지 알려 주고, User-Agent는 요청을 보낸 클라이언트가 어떤 브라우저인지, Accept는 어떤 형식을 받아 해석할 수 있는지를 서버에 전달한다

서버는 이에 대한 응답 메시지를 돌려준다

HTTP/1.1 200 OK
Date: Sat, 20 Jun 2026 09:00:00 GMT
Server: Apache
Content-Type: text/html; charset=UTF-8
Content-Length: 123

<html>
  <body>Hello, Web</body>
</html>

첫 줄의 200 OK는 “요청한 문서가 있고 문제없이 보낸다”는 상태 코드다. Content-Type은 본문이 HTML이라는 것을, Content-Length는 본문의 길이가 123바이트라는 것을 알려 준다. 빈 줄 아래부터가 실제 HTML 문서, 즉 본문이다

여기서 HTML 문서가 일반 텍스트와 다른 점이 드러난다. 본문에는 <html>, <body> 같은 태그가 들어 있다. 태그는 각 텍스트가 어떤 속성을 갖는지 규정한다. 브라우저는 이 태그 규칙을 해석해 화면을 렌더링한다. 단순한 메모장 텍스트에서 한 단계 나아간, 구조와 표현을 담은 문서 형식인 셈이다

연결은 더 이상 매번 끊기지 않는다

오래된 자료에서는 “응답을 받으면 TCP 연결이 곧바로 끊긴다”고 설명한다. 이는 HTTP/1.0 시절의 기본 동작이다. 그 시절에는 문서 하나를 받을 때마다 연결을 새로 맺고 끊었다. 한 페이지에 이미지가 여러 개 있으면 그만큼 연결을 반복해야 해서 비효율적이었다.

지금 널리 쓰는 HTTP/1.1은 기본적으로 연결을 유지한다(persistent connection). 한 번 맺은 연결로 여러 요청과 응답을 주고받은 뒤에 정리한다. 그래서 입문 단계에서 흐름을 이해할 때는 “요청-응답이 한 번 오가면 끝”이라고 보되, 실제로는 연결이 매번 끊기지는 않는다는 점을 함께 기억해 두면 된다

그 위로 HTTP/2와 HTTP/3도 이미 자리를 잡았다. HTTP/2는 하나의 연결에서 여러 요청을 동시에 처리하고, HTTP/3은 TCP 대신 QUIC을 쓴다. 버전마다 연결을 다루는 방식은 다르지만, “클라이언트가 요청하면 서버가 응답한다”는 큰 골격은 변하지 않는다. 그 골격부터 잡고 나면 버전별 차이는 나중에 얹어 가면 된다

정리

한 줄로 요약하면, 웹은 URL로 인터넷 위의 리소스 하나를 가리키고 HTTP로 그것을 요청·응답하는 구조다. URL이 “무엇을 어디서”를 정하고 HTTP가 “어떻게 주고받을지”를 정한다. 이 두 축만 손에 쥐면 브라우저 주소창 뒤에서 벌어지는 일의 대부분이 설명된다

출처 – 인프런 강의 중 [모든 웹 개발자가 봐야 할 단 한 장의 지도]