Request Headers – Accept와 Accept-Encoding, HTTP 요청에서 왜 중요할까?

들어가며

웹 개발을 하다 보면 개발자 도구의 Network 탭에서 수많은 Request Headers를 만나게 됩니다. 처음 보면 Accept, Accept-Encoding, User-Agent, Referer, Cookie 같은 항목이 줄줄이 표시되는데, 막상 각각 어떤 역할을 하는지 설명하려고 하면 헷갈리는 경우가 많습니다.

특히 API를 호출하거나 웹 페이지의 네트워크 요청을 분석할 때 Accept와 Accept-Encoding은 자주 등장하는 헤더입니다.

겉으로 보기에는 단순한 문자열처럼 보이지만, 서버와 브라우저가 어떤 데이터를 주고받을지 협의하는 과정에서 중요한 역할을 합니다.

이번 글에서는 개발자 도구에서 확인할 수 있는 Request Headers의 Accept와 Accept-Encoding이 정확히 무엇을 의미하는지, 실제 HTTP 요청에서는 어떻게 사용되는지 정리해보겠습니다.

Request Headers란 무엇일까?

먼저 Request Headers부터 이해할 필요가 있습니다.

웹 브라우저가 서버에 페이지나 데이터를 요청할 때 단순히 URL만 보내는 것은 아닙니다. 요청에 필요한 여러 정보를 함께 전달합니다.

이 정보가 바로 HTTP Request Headers입니다.

예를 들어 브라우저가 서버에 요청을 보내면 다음과 비슷한 형태의 헤더가 포함될 수 있습니다.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br, zstd
User-Agent: Mozilla/5.0 ...

각 헤더는 서로 다른 정보를 전달합니다.

User-Agent는 어떤 브라우저나 클라이언트에서 요청했는지를 알려주고, Accept는 어떤 형식의 응답을 받을 수 있는지를 알려줍니다.

그리고 Accept-Encoding은 서버가 응답 데이터를 어떤 방식으로 압축해서 보내도 되는지를 나타냅니다.

Accept 헤더는 무엇을 의미할까?

Accept는 말 그대로 클라이언트가 어떤 미디어 타입의 응답을 받을 수 있는지 서버에 알려주는 헤더입니다.

예를 들어 다음과 같은 요청이 있다고 해보겠습니다.

Accept: application/json

이 경우 클라이언트는 서버에게 JSON 형식의 응답을 기대한다고 전달하는 것입니다.

API를 호출할 때 특히 자주 볼 수 있는 형태입니다.

Accept: application/json

반면 웹 브라우저에서 HTML 페이지를 요청하는 경우에는 다음처럼 여러 형식이 포함될 수 있습니다.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

여기서 text/html은 HTML 문서를 의미합니다.

application/xhtml+xml은 XHTML 형식을 의미하고, application/xml은 XML 형식을 의미합니다.

마지막에 있는 */*는 특정 형식으로 제한하지 않고 다른 미디어 타입도 허용한다는 의미입니다.

q 값은 무엇일까?

Accept 헤더를 보다 보면 q=0.9, q=0.8 같은 값이 붙어 있는 경우가 있습니다.

이것은 해당 콘텐츠 타입에 대한 선호도 또는 상대적인 우선순위를 나타내는 품질값입니다.

예를 들어 다음과 같은 요청이 있다고 가정해보겠습니다.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

단순하게 이해하면 HTML을 가장 선호하고, 그다음 XML 계열을 선호하며, 그 외의 형식도 어느 정도 허용한다는 의미입니다.

다만 q 값이 있다고 해서 서버가 반드시 그 순서대로 응답한다는 의미는 아닙니다.

실제 응답 형식은 서버의 설정이나 API의 구현 방식 등에 따라 달라질 수 있습니다.

Accept-Encoding은 무엇일까?

이번에는 Accept-Encoding입니다.

이 헤더는 서버가 응답 데이터를 어떤 압축 방식으로 보내도 되는지 알려주는 역할을 합니다.

예를 들어 다음과 같은 헤더를 볼 수 있습니다.

Accept-Encoding: gzip, deflate, br, zstd

여기서 gzip, deflate, br, zstd는 데이터를 압축하는 방식입니다.

웹 페이지나 API에서 주고받는 데이터가 상당히 많다면 압축을 사용하는 것이 유리합니다.

예를 들어 서버에서 1MB 크기의 응답을 그대로 보내는 것보다 압축해서 전송하면 실제 네트워크에서 전송해야 하는 데이터의 크기를 줄일 수 있습니다.

결과적으로 네트워크 사용량을 줄이고 응답 속도를 개선하는 데 도움이 됩니다.

gzip, br, zstd는 어떻게 다른가?

개발자 도구를 보다 보면 여러 압축 방식이 한꺼번에 표시되기 때문에 처음에는 조금 복잡해 보입니다.

대표적으로 다음과 같이 이해하면 됩니다.

• gzip : 오랫동안 널리 사용되어 온 압축 방식
• deflate : HTTP에서 사용되는 전통적인 압축 방식
• br : Brotli 압축 방식
• zstd : Zstandard 압축 방식

최근 웹 환경에서는 Brotli인 br이나 Zstandard인 zstd가 보이는 경우도 있습니다.

중요한 것은 클라이언트가 이 압축 방식을 지원한다고 서버에 알려주면, 서버가 그중 하나를 선택해서 응답을 압축할 수 있다는 점입니다.

Accept와 Accept-Encoding의 차이

두 헤더가 비슷하게 느껴질 수 있지만 역할은 명확하게 다릅니다.

Accept는 어떤 종류의 콘텐츠를 받을 것인지에 대한 정보입니다.

예를 들어 JSON, HTML, XML 같은 콘텐츠 형식이 여기에 해당합니다.

반면 Accept-Encoding은 그 콘텐츠를 어떤 압축 방식으로 받아도 되는지에 대한 정보입니다.

쉽게 비유하면 이렇습니다.

Accept = 어떤 물건을 받을 것인가?

Accept-Encoding = 그 물건을 어떤 포장 방식으로 받아도 되는가?

따라서 다음 두 헤더는 서로 다른 목적으로 사용됩니다.

Accept: application/json
Accept-Encoding: gzip, br, zstd

이 요청은 쉽게 말해 JSON 형태의 응답을 원하고, 서버가 gzip·Brotli·Zstandard 등의 방식으로 압축해서 보내는 것도 허용한다는 의미로 볼 수 있습니다.

개발자 도구에서 직접 확인해보기

Chrome이나 Edge에서 웹 페이지를 열고 F12를 누르면 개발자 도구를 열 수 있습니다.

그다음 Network 탭으로 이동한 후 페이지를 새로고침합니다.

요청 목록에서 특정 요청을 선택하면 Headers라는 항목을 확인할 수 있습니다.

여기에서 Request Headers 영역을 펼치면 Accept와 Accept-Encoding을 확인할 수 있습니다.

이 방법은 단순히 헤더의 의미를 공부하는 것보다 실제 웹사이트가 서버에 어떤 요청을 보내는지 확인하는 데 훨씬 도움이 됩니다.

특히 API를 분석할 때는 Request URL, Request Method, Request Headers, Query String Parameters, Response Headers, Response Payload를 함께 확인하는 습관을 들이면 좋습니다.

API 분석에서 Accept 헤더가 중요한 이유

API를 개발하거나 외부 API를 분석하다 보면 Accept 헤더를 직접 지정해야 하는 상황도 있습니다.

예를 들어 JSON API라면 다음과 같이 지정할 수 있습니다.

Accept: application/json

그러면 클라이언트가 JSON 응답을 기대한다는 것을 명확하게 전달할 수 있습니다.

다만 여기서 주의해야 할 점도 있습니다.

Accept 헤더를 넣었다고 해서 서버가 반드시 해당 형식으로 응답하는 것은 아닙니다.

서버가 해당 미디어 타입을 지원하지 않거나 API 자체가 특정 응답 형식으로 고정되어 있다면 요청한 것과 다른 방식으로 응답할 수도 있습니다.

따라서 실제 API를 분석할 때는 Request Headers만 보고 판단하기보다는 실제 Response를 함께 확인하는 것이 중요합니다.

Accept-Encoding을 직접 수정해야 할까?

일반적인 웹 개발에서는 Accept-Encoding을 직접 수정할 필요가 거의 없습니다.

대부분의 브라우저와 HTTP 클라이언트가 지원 가능한 압축 방식을 자동으로 관리하기 때문입니다.

특히 브라우저 환경에서는 서버와 클라이언트가 압축 방식에 맞춰 통신하는 과정이 자동으로 처리됩니다.

그래서 개발자 도구에서 Accept-Encoding을 발견했다고 해서 반드시 이것을 수정해야 하는 것은 아닙니다.

오히려 네트워크 요청을 분석하는 목적이라면 현재 어떤 값이 전송되고 있는지 확인하는 것만으로도 충분한 경우가 많습니다.

마무리

웹 개발을 하다 보면 Request Headers에는 생각보다 많은 정보가 들어 있다는 것을 알게 됩니다.

그중에서도 Accept와 Accept-Encoding은 기본적인 HTTP 통신 구조를 이해하는 데 좋은 출발점입니다.

Accept는 클라이언트가 원하는 콘텐츠 형식을 알려주고, Accept-Encoding은 클라이언트가 허용하는 콘텐츠 압축 방식을 알려줍니다.

예를 들어,

Accept: application/json
Accept-Encoding: gzip, br, zstd

라는 요청을 보면 단순히 문자열로 볼 것이 아니라,

“JSON 응답을 원하고 있으며, 서버가 지원한다면 여러 압축 방식으로 데이터를 받아도 된다.”

정도로 이해하면 됩니다.

앞으로 개발자 도구의 Network 탭에서 Request Headers를 볼 때 Accept와 Accept-Encoding이 눈에 들어온다면, 단순한 설정값이 아니라 브라우저와 서버가 데이터를 주고받기 위해 미리 협의하는 정보라고 생각하면 이해하기 훨씬 쉬워집니다.

특히 API 호출이나 웹 통신을 직접 분석하고 있다면 이 두 헤더를 시작으로 Content-Type, User-Agent, Authorization, Cookie, Referer 등의 역할까지 하나씩 살펴보면 HTTP 요청의 전체 구조를 이해하는 데 큰 도움이 됩니다.