웹 서비스는 결국 “텍스트를 주고받는 약속” 위에 세워져 있다. 브라우저가 화면을 그리고, 버튼을 누르면 반응하고, 동영상이 재생되는 모든 것이 TCP 문자열 전송이라는 하나의 제약 조건에서 출발한다. HTTP 구조를 이해하면 웹이 왜 이런 방식으로 설계됐는지, HTML·CSS·JavaScript가 각각 무슨 역할을 하는지 한 번에 잡힌다.
이 글에서는 TCP가 왜 문자열만 주고받을 수 있는지부터 시작해, HTTP 구조가 어떤 형태로 요청과 응답을 처리하는지, 그리고 브라우저가 그 텍스트를 받아 화면으로 그려내는 원리까지 3단계로 정리한다.
TCP는 왜 문자열만 주고받는가
TCP(Transmission Control Protocol)는 1991년에 설계된 통신 규약이다. 설계 당시의 목표는 단순했다. 네트워크 위에서 데이터를 신뢰성 있게 전달하는 것. 그 수단으로 선택한 방식이 바로 문자열이었다.
TCP 자체는 사운드도, 이미지도, 영상도 직접 전달하지 못한다. 오직 텍스트 기반의 데이터만 주고받을 수 있다. 그런데 오늘날 Netflix는 TCP로 동작한다. 이상하게 들리지만, 사실이다.
비결은 간단하다. Netflix 서버는 영상 파일을 직접 보내는 게 아니라, 브라우저에게 “이 영상을 재생해달라는 요청서”를 텍스트로 보낸다. 브라우저는 그 텍스트 요청서를 읽고 직접 화면을 그린다. 즉, TCP는 그림을 보내는 게 아니라 그림을 그려달라는 지시서를 텍스트로 전달하는 방식으로 작동한다.
TCP가 30년이 지난 지금도 버려지지 않는 이유는 단 하나다. 이미 전 세계 모든 서비스가 이 위에 세워져 있기 때문이다. 제약은 있지만, 그 제약 안에서 가능한 모든 방법이 이미 구현돼 있다.
HTTP 구조란 무엇인가 — 요청서를 텍스트로 보내는 이유
HTTP(HyperText Transfer Protocol)는 TCP 위에서 작동하는 통신 규칙이다. HTTP 구조는 크게 두 가지로 나뉜다. 요청(Request)과 응답(Response).
브라우저가 서버에 어떤 페이지를 달라고 할 때, 그 요청은 텍스트로 작성된 요청서 형태로 전송된다. 서버는 그 텍스트 요청서를 읽고 응답 텍스트를 돌려준다. 브라우저는 응답 텍스트를 해석해 화면을 그린다.
HTTP 구조에서 요청과 응답은 각각 두 부분으로 구성된다.
| 구분 | 구성 요소 | 역할 |
|---|---|---|
| 요청(Request) | 헤더(Header) | 요청 방식, 인증 정보, 브라우저 환경 등 참고사항 |
| 요청(Request) | 바디(Body) | 서버에 전달할 실제 데이터 (POST 방식일 때) |
| 응답(Response) | 헤더(Header) | 응답 데이터 형식, 상태 코드, 캐시 정책 등 참고사항 |
| 응답(Response) | 바디(Body) | 브라우저가 화면으로 그릴 실제 내용 (HTML 등) |
핵심은 이 모든 데이터가 TCP 문자열 전송 방식으로 오간다는 것이다. 서버는 이미지를 직접 보내지 않는다. 이미지를 어디서 가져와 어떻게 표시하라는 지시가 담긴 텍스트를 보낼 뿐이다.
HTTP 헤더가 하는 일 — 브라우저에게 보내는 참고사항
HTTP 구조에서 헤더는 바디를 어떻게 해석해야 하는지 브라우저에게 알려주는 참고사항이다.
예를 들어 서버가 HTML 문서를 응답으로 보낼 때, 헤더에 Content-Type: text/html이라고 명시한다. 브라우저는 이 헤더를 먼저 읽고 “아, 바디에 있는 텍스트는 HTML로 해석해서 화면을 그려야겠다”고 판단한다.
반대로 헤더에 Content-Type: text/plain이라고 적혀 있으면 브라우저는 같은 텍스트를 HTML로 그리지 않고 그냥 평문으로 보여준다.
| Content-Type 값 | 브라우저 동작 |
|---|---|
text/html | HTML로 해석 → 화면 렌더링 |
text/plain | 평문 텍스트로 그대로 표시 |
application/json | JSON 데이터로 해석 |
image/jpeg | 이미지로 표시 |
헤더에는 인증 정보도 담긴다. 사용자가 로그인한 상태라면, 브라우저는 요청 헤더에 인증 토큰을 실어서 서버에 보낸다. 서버는 그 토큰을 보고 이 사람이 누구인지 확인한다. 단, 헤더는 클라이언트 쪽에서 수정이 가능하기 때문에 서버는 헤더 정보를 그대로 신뢰하지 않고 별도로 검증한다.
결국 HTTP 구조에서 헤더는 “바디를 읽기 전에 먼저 확인해야 할 지시사항”이다. 현장으로 치면, 작업 지시서 앞장에 붙어있는 주의사항 페이지와 같다.
HTML·CSS·JavaScript — 웹 화면을 만드는 3가지 역할
서버가 보낸 응답 바디에는 대부분 HTML이 담겨 있다. 브라우저는 이 HTML을 읽고 화면을 구성한다. 그런데 웹 화면을 만드는 데는 HTML 하나만 쓰이지 않는다. HTML, CSS, JavaScript 세 가지가 각자 다른 역할을 담당한다.
| 구성 요소 | 역할 | 비유 |
|---|---|---|
| HTML | 화면에 무엇이 있는가 (구조) | 건물의 기둥과 벽 |
| CSS | 그것이 어떻게 보이는가 (스타일) | 인테리어와 도색 |
| JavaScript | 사용자가 조작했을 때 무슨 일이 벌어지는가 (액션) | 자동문, 조명 스위치 |
HTML은 화면의 구성 요소를 정의한다. 버튼이 있다, 제목이 있다, 이미지가 있다 — 무엇이 화면에 존재하는지를 태그로 선언한다.
CSS는 그 구성 요소들이 어떻게 보일지를 결정한다. 글자 색을 빨간색으로, 버튼을 둥글게, 배경을 어둡게 — 디자인과 스타일 전반을 담당한다.
JavaScript는 사용자의 행동에 반응하는 로직을 담는다. 버튼을 클릭했을 때 텍스트가 바뀐다, 마우스를 올렸을 때 색이 변한다 — 화면의 모든 인터랙션은 JavaScript가 처리한다.
네이버, 쿠팡, 유튜브 모두 이 세 가지로 만들어진다. 구조가 다르고 디자인이 달라 보여도, 뜯어보면 HTML로 구조를 잡고 CSS로 꾸미고 JavaScript로 동작을 붙인 것이다.
API 란 무엇인가에서 다뤘듯, 서버와 클라이언트가 주고받는 데이터의 형식과 규칙을 이해하면 HTTP 구조가 훨씬 입체적으로 보인다.
현장 장비를 다루던 사람이 웹 개발을 처음 배울 때 가장 헷갈리는 지점은 “왜 이렇게 많은 단계로 쪼개놓았을까”라는 질문이다. 현장에서는 신호 하나가 배선을 타고 곧바로 전달되면 그만이지만, 웹은 신뢰성과 확장성을 위해 매 단계를 텍스트 약속으로 잘게 쪼개놓았다. 그 이유를 알고 나면 복잡해 보이던 HTTP 구조가 오히려 단순한 규칙의 반복으로 보인다.
핵심 요약
- TCP는 문자열만 주고받을 수 있다. 이미지나 영상이 아닌, 그것을 그려달라는 텍스트 지시서를 전달한다.
- HTTP 구조는 요청과 응답으로 나뉘며, 각각 헤더(참고사항)와 바디(실제 내용)로 구성된다.
- 헤더의 Content-Type이 브라우저에게 바디를 어떻게 해석할지 알려준다.
- HTML은 구조, CSS는 스타일, JavaScript는 액션 — 모든 웹 화면은 이 3가지 역할 분담으로 작동한다.
함께 읽으면 좋은 글
웹 개발의 전체 구조가 잡혔다면, 다음 단계는 실제 서버를 만들어보는 것이다.
웹 표준과 프로토콜의 공식 레퍼런스는 MDN Web Docs에서 확인할 수 있다.
