--- title: "웹 요청의 문법과 의미를 나누어 읽는 HTTP" author: "Lee" published_at: "2026-10-23T09:41:02.607Z" updated_at: "2026-09-30T09:24:33.705Z" tags: ["컴퓨터공학","네트워크"] canonical_url: "https://ariser.io/@writer_a1cd615ab19e/%EC%9B%B9-%EC%9A%94%EC%B2%AD%EC%9D%98-%EB%AC%B8%EB%B2%95%EA%B3%BC-%EC%9D%98%EB%AF%B8%EB%A5%BC-%EB%82%98%EB%88%84%EC%96%B4-%EC%9D%BD%EB%8A%94-http" ai_assisted: false --- # 웹 요청의 문법과 의미를 나누어 읽는 HTTP [원문](https://ariser.io/@writer_a1cd615ab19e/%EC%9B%B9-%EC%9A%94%EC%B2%AD%EC%9D%98-%EB%AC%B8%EB%B2%95%EA%B3%BC-%EC%9D%98%EB%AF%B8%EB%A5%BC-%EB%82%98%EB%88%84%EC%96%B4-%EC%9D%BD%EB%8A%94-http) HTTP는 클라이언트가 요청하고 서버가 응답하는 웹의 응용 계층 프로토콜이다. 메서드, 대상, 헤더, 상태 코드와 본문을 이용해 리소스에 대한 동작과 결과를 표현한다. 웹페이지뿐 아니라 API, 파일 전송과 여러 서비스에서도 사용되며, 인터넷 패킷이 전달되는 방식 자체와는 다른 층의 규칙이다. ![GET 요청과 200 응답을 주고받는 브라우저·서버, 표현을 재사용하는 캐시를 보여주는 그림](/api/v1/media/b9d78838-8120-4078-80c8-265029e630ee) *HTTP는 요청의 의미와 응답의 결과를 표현하며 캐시는 정해진 조건으로 응답을 재사용한다.* ### 요청은 주소만으로 결정되지 않는다 GET /articles/42라는 요청은 해당 리소스의 표현을 가져오려는 의미를 갖는다. 같은 주소라도 Accept 같은 헤더에 따라 서로 다른 표현을 요청할 수 있다. 헤더는 메타데이터와 처리 조건을 전달하고, 본문은 요청이나 응답의 실제 내용을 담는다. URL만 비교하면 두 요청의 의미가 항상 같다는 결론을 낼 수 없다. GET은 안전한 메서드로 정의되며, 요청자가 서버 상태 변경을 요구하는 용도로 사용하지 않는다는 의미다. 서버가 조회 기록을 남기거나 통계를 계산하는 부수 효과까지 없다는 뜻은 아니다. POST는 대상 리소스가 지정한 방식으로 내용을 처리하도록 요청한다. POST를 데이터를 보내는 모든 행위의 유일한 방법으로 이해하면 PUT 등 다른 메서드의 의미를 놓친다. 멱등성은 같은 요청을 반복했을 때 의도한 서버 상태 효과가 같은지를 뜻한다. 응답 코드나 시간, 로그가 매번 같아야 한다는 뜻은 아니다. PUT과 DELETE는 정의상 멱등적인 의미를 갖고, POST는 일반적으로 그 보장을 갖지 않는다. 다만 응용은 요청 키 같은 방식으로 특정 POST 업무를 안전하게 재시도하도록 설계할 수 있다. ### 상태 코드는 결과의 종류를 알린다 200은 성공적인 처리의 대표적인 상태 코드다. 404는 서버가 대상 리소스의 현재 표현을 찾지 못했거나 존재를 드러내지 않으려는 경우 등에 쓰인다. 503은 일시적으로 서비스를 제공하기 어려운 상황을 나타낸다. 정확한 업무 성공 여부와 재시도 정책은 상태 코드에 더해 본문과 API 계약도 확인해야 한다. HTTP 캐시는 응답의 저장 가능성, 신선도와 재검증 조건에 따라 같은 표현을 재사용한다. ETag 같은 검증자를 이용하면 서버가 이전 표현과 달라졌는지 확인하고, 조건이 맞을 때 본문 전체의 재전송을 줄일 수 있다. 캐시는 단순히 브라우저가 임의로 오래된 페이지를 쓰는 기능이 아니라 명시된 제어 정보와 검증 규칙을 따르는 장치다. HTTP가 무상태라고 할 때는 서버가 사용자의 로그인 정보를 어떤 형태로도 저장하지 못한다는 의미가 아니다. 요청 자체의 의미를 이전 요청의 암묵적 순서에만 의존시키지 않는 프로토콜 특성을 가리킨다. 쿠키, 세션과 토큰으로 사용자 상태를 관리하는 웹 응용은 그 위에서 얼마든지 구성된다. 버전에 따라 전송 방식도 다르다. HTTP/1.1은 텍스트 기반 메시지 구문을 사용하고, HTTP/2는 프레임과 여러 스트림을 활용한다. HTTP/3는 QUIC 위에서 동작한다. 모든 버전이 단순히 한 줄의 텍스트를 TCP에 보낸다고 설명하면 현대적인 전송 특성을 놓친다. 핵심적인 메서드와 상태의 의미는 여러 버전 사이에서 공유된다. API 장애를 살펴볼 때는 전송 실패와 정상적으로 받은 오류 응답을 구분한다. 서버가 503을 보냈다는 것은 HTTP 응답을 받았다는 뜻이지만 업무는 성공하지 않았을 수 있다. 타임아웃에는 처리 결과를 모르는 상황도 포함된다. 메서드의 의미, 응답 계약과 재시도 안전성을 함께 설계해야 HTTP의 표면적인 문법이 실제 서비스의 신뢰성으로 이어진다. ### 참고 자료 - [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html) - [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111.html)