HTTP/HTTPS

TCP가 서버까지 바이트를 안전하게 전달해 준다고 해서 곧바로 웹 서비스가 되는 것은 아닙니다. 브라우저는 문서를 요청하고 싶고, API 클라이언트는 데이터를 저장하거나 조회하고 싶고, 서버는 결과가 성공인지 실패인지 의미 있게 돌려줘야 합니다. 요청의 의도, 대상 자원, 인증 정보, 캐시 정책, 응답 결과를 표현하는 공통 규약이 없으면 서로 같은 바이트를 주고받아도 해석이 달라집니다. '연결이 됐다'와 '대화가 된다'는 전혀 다른 문제입니다. HTTP는 이 간극을 메우기 위해 웹에서 요청과 응답의 의미를 정리한 공용 언어입니다.

처음의 웹은 문서 몇 장을 연결해 보여주는 단순한 하이퍼텍스트 환경이었습니다. 1991년 HTTP 0.9는 GET 메서드 하나로 HTML 문서 하나를 받아 오는 게 전부였습니다. 시간이 지나며 웹은 로그인, 결제, 파일 업로드, API 호출, 대규모 프런트엔드 애플리케이션까지 떠안게 됐습니다. 그러자 성능, 보안, 캐시, 연결 재사용 문제를 감당하기 어려워졌고 HTTP는 계속 진화했습니다. HTTP/1.1은 연결 재사용을 도입했고, HTTP/2는 하나의 연결 위에서 여러 요청을 병렬로 처리했습니다. HTTP가 여러 버전을 거쳐 온 것은 웹 자체가 더 복잡해졌기 때문이지, 기존 개념이 틀렸기 때문은 아닙니다.

HTTP 요청은 메서드, URL, 헤더, 바디로 구성됩니다. 메서드는 조회인지 생성인지 같은 의도를 드러내고, URL은 어떤 자원에 대한 요청인지를 가리키며, 헤더는 인증 정보나 콘텐츠 형식, 캐시 정책 같은 부가 조건을 전달합니다. 서버는 상태 코드, 헤더, 바디를 담은 응답으로 결과를 돌려주고, 클라이언트는 이 조합을 해석해 다음 동작을 결정합니다. 200이면 성공이고, 404면 자원이 없고, 503이면 서버가 일시적으로 응답 불가입니다. 이 구조가 중요한 이유는 단순히 문법이 있기 때문이 아니라, 서로 다른 브라우저와 서버와 API가 동일한 의미 체계 안에서 상호 운용될 수 있기 때문입니다.

HTTP/1.1과 HTTP/2는 둘 다 같은 애플리케이션 의미를 전달합니다. GET은 여전히 조회이고, 상태 코드는 여전히 결과를 설명합니다. 차이는 이 의미를 실제 연결 위에 어떻게 실어 보내느냐에 있습니다. HTTP/1.1은 리소스를 받을 때 요청이 직렬로 처리되어 앞 요청이 끝나야 다음 요청이 시작되는 경우가 많았습니다. HTTP/2는 하나의 TCP 연결 위에서 여러 스트림을 동시에 처리해 같은 의미를 더 빠르게 전달합니다. 버전 차이를 볼 때는 '완전히 다른 프로토콜'이라기보다, 같은 요청-응답 모델을 더 현대적인 전송 방식으로 다듬어 온 과정으로 이해하는 편이 정확합니다.

HTTP는 웹 페이지 로딩, 브라우저와 API 서버 통신, 서비스 간 호출, 파일 다운로드, 웹훅처럼 요청과 응답이 명확한 인터넷 상호작용에 잘 맞습니다. 자원 중심 모델, 캐시 활용, 프록시와 게이트웨이 통과 같은 웹 인프라의 이점을 그대로 누릴 수 있다는 점도 큽니다. 다만 연결을 오래 붙잡고 수십 밀리초 단위로 상태를 계속 교환해야 하는 실시간 상호작용에서는 HTTP의 요청-응답 틀이 답답해질 수 있습니다. 그런 경우에는 HTTP를 중심으로 둔 설계가 어디까지 자연스럽고 어디부터 다른 통신 모델이 필요한지 판단해야 합니다. HTTP는 '웹에서 가장 흔한 규약'이라서 쓰는 것이 아니라, 요청의 의미와 결과를 명료하게 표현해야 하는 상황에 특히 잘 맞기 때문에 오래 살아남았습니다.