HTTP

컴퓨터가 인터넷으로 연결됐더라도 서로 다른 시스템이 어떤 형식으로 요청을 보내고 어떻게 응답해야 하는지 합의되어 있지 않으면 소통이 안 됩니다. A가 'GET /page'라고 보냈을 때 B가 이게 파일을 달라는 건지, 실행하라는 건지 알 수 없다면, 웹 서버를 만들 때마다 새로운 통신 규약을 설계해야 합니다. 요청 형식, 응답 코드, 메타데이터 전달 방법이 표준화되지 않으면 브라우저 하나가 세상의 모든 웹 서버와 대화하기가 불가능합니다.

1989년 팀 버너스 리는 유럽 입자물리연구소(CERN)에서 연구자들이 문서를 공유하는 방법을 고민했습니다. 당시는 파일 전송에 FTP를 쓰거나, 텔넷으로 직접 접속하는 방식이 주를 이뤘지만 링크를 타고 다른 문서로 이동하는 개념은 없었습니다. HTTP는 하이퍼텍스트, 즉 링크가 연결된 문서를 요청하고 받는 단순한 프로토콜로 시작했습니다. HTTP/0.9는 GET 하나뿐이었고, HTTP/1.0에서 헤더와 상태 코드가 생겼으며, HTTP/1.1에서 연결 재사용과 청크 전송이 추가됐습니다. 이후 HTTP/2는 멀티플렉싱으로 병렬 요청을 다루고, HTTP/3는 TCP 대신 QUIC 위에서 동작해 지연을 줄였습니다. 단순한 문서 공유 프로토콜이 지금은 웹 API, 스트리밍, 실시간 통신의 기반이 됐습니다.

HTTP 요청은 크게 메서드, URL, 헤더, 바디 네 부분으로 이루어집니다. 메서드는 'GET /users/1'처럼 어떤 행동을 할지 동사 역할을 합니다. 헤더는 콘텐츠 타입, 인증 토큰, 캐시 지시어 같은 메타데이터를 담고, 바디는 POST나 PUT 요청에서 서버에 전달할 실제 데이터를 싣습니다. 서버는 상태 코드, 헤더, 바디로 응답합니다. 상태 코드는 200 OK처럼 처리 결과를 숫자로 요약합니다. 200~299는 성공, 300~399는 리다이렉션, 400~499는 클라이언트 잘못(404 Not Found, 401 Unauthorized), 500~599는 서버 오류입니다. HTTP는 무상태입니다. 서버는 이전 요청을 기억하지 않습니다. 요청마다 독립적이므로, 로그인 상태처럼 여러 요청에 걸쳐 유지해야 하는 정보는 쿠키나 JWT 같은 별도 메커니즘으로 관리해야 합니다.

HTTP와 HTTPS는 거의 같은 프로토콜이지만 HTTPS는 TLS 계층을 얹어 전송 중 데이터를 암호화합니다. HTTP는 내용이 평문으로 흐르기 때문에 네트워크 경로 어디서든 도청이나 변조가 가능합니다. 오늘날 공개 인터넷에서 HTTP 단독 사용은 사실상 권장되지 않습니다. HTTP와 WebSocket은 처음엔 HTTP 핸드셰이크로 연결을 시작하지만, WebSocket은 이후 지속 연결 채널을 유지하며 서버가 먼저 메시지를 보낼 수 있습니다. HTTP는 요청 없이는 서버가 응답하지 않는 구조입니다. HTTP와 REST는 다른 개념입니다. REST는 HTTP 메서드와 URL 설계에 대한 아키텍처 스타일이고, HTTP는 그 설계를 실어 나르는 프로토콜입니다.

프론트엔드에서 fetch나 axios로 API를 호출할 때마다 HTTP가 작동합니다. 상태 코드를 보고 에러 처리 분기를 짤 때, 요청 헤더에 Authorization을 붙일 때, 파일 업로드에 multipart/form-data를 쓸 때 모두 HTTP의 구체적인 동작입니다. 백엔드에서는 라우터가 HTTP 메서드와 URL 패턴을 보고 핸들러를 결정합니다. API 설계에서 'GET은 멱등이어야 한다', 'POST는 중복 방지가 필요하다'는 원칙도 HTTP 메서드의 의미론에서 나옵니다. 네트워크 디버깅에서 브라우저 DevTools의 Network 탭이 보여주는 것이 바로 HTTP 요청과 응답의 원문입니다. 요청이 왜 실패했는지, 헤더가 제대로 설정됐는지, 응답 바디가 예상대로인지를 HTTP 수준에서 읽을 수 있어야 문제를 빠르게 좁힐 수 있습니다.