· 12 min read
HTTP headers are the unsung heroes of web communication. Every time you load a webpage,
HTTP 헤더는 웹 통신의 숨은 영웅입니다. 웹페이지를 로드하거나, 비디오를 스트리밍하거나, 폼을 제출할 때마다 수십 개의 헤더가 뒤에서 작동하여 이를 가능하게 합니다. 헤더는 요청과 응답에 대한 중요한 메타데이터를 전달하고, 캐싱 동작을 제어하며, 보안 정책을 시행하고, 최신 웹 기능을 활성화합니다.
HTTP 헤더를 이해하는 것은 더 이상 백엔드 개발자만을 위한 것이 아닙니다. 프론트엔드 엔지니어는 API 통합을 위해 필요하고, DevOps 팀은 성능 최적화를 위해 의존하며, 보안 전문가는 공격으로부터 애플리케이션을 보호하기 위해 사용합니다. 이 가이드는 기본 개념부터 고급 보안 구현까지 HTTP 헤더에 대해 알아야 할 모든 것을 설명합니다.
HTTP 헤더는 HTTP 통신 중에 클라이언트와 서버 간에 전송되는 키-값 쌍입니다. 콘텐츠 유형, 인코딩, 인증 자격 증명, 캐싱 지시문 및 보안 정책을 포함하여 요청 또는 응답에 대한 필수 컨텍스트를 제공합니다.
헤더는 간단한 형식을 따릅니다: Header-Name: value. 각 헤더는 자체 줄에 나타나며, 빈 줄이 헤더와 메시지 본문을 구분합니다. HTTP/1.1은 일반 텍스트 헤더를 사용하지만, HTTP/2와 HTTP/3는 각각 HPACK 및 QPACK 알고리즘을 사용하여 압축합니다.
헤더는 네 가지 주요 범주로 나뉩니다:
최신 웹 애플리케이션은 일반적으로 요청-응답 주기당 20-40개의 헤더를 교환합니다. 일부는 필수적이며(HTTP/1.1의 Host와 같이), 다른 일부는 선택 사항이지만 보안 및 성능을 위해 강력히 권장됩니다.
프로 팁: 브라우저의 DevTools 네트워크 탭을 사용하여 실시간으로 헤더를 검사하세요. 이는 API 문제를 디버깅하고 타사 서비스가 애플리케이션과 통신하는 방식을 이해하는 데 매우 유용합니다.
요청 헤더는 클라이언트가 원하는 것과 처리할 수 있는 것을 서버에 알려줍니다. 허용되는 콘텐츠 유형, 선호하는 언어, 인증 자격 증명 및 클라이언트의 기능에 대한 정보를 포함합니다.
다음은 접하게 될 가장 중요한 요청 헤더입니다:
| 헤더 | 목적 | 예시 |
|---|---|---|
Host |
서버의 도메인 이름 지정 | Host: example.com |
User-Agent |
클라이언트 소프트웨어 식별 | User-Agent: Mozilla/5.0... |
Accept |
클라이언트가 처리할 수 있는 미디어 유형 | Accept: application/json |
Accept-Language |
응답에 선호하는 언어 | Accept-Language: en-US,en;q=0.9 |
Accept-Encoding |
지원되는 압축 알고리즘 | Accept-Encoding: gzip, br |
Authorization |
인증 자격 증명 | Authorization: Bearer token123 |
Cookie |
도메인에 저장된 쿠키 | Cookie: session=abc123 |
Referer |
이전 페이지의 URL | Referer: https://google.com |
Accept 헤더는 여러 형식이 허용될 때 선호도를 나타내기 위해 품질 값(q-값)을 사용합니다. 값의 범위는 0에서 1까지이며, 1이 가장 높은 우선순위입니다:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8이것은 서버에게 다음과 같이 알려줍니다: "HTML 또는 XHTML을 선호하지만, 90% 선호도로 XML을 수락하고, 80% 선호도로 다른 모든 것을 수락합니다." 서버는 이를 사용하여 콘텐츠 협상을 수행하고 가장 적절한 형식을 반환합니다.
User-Agent 헤더는 클라이언트 소프트웨어, 운영 체제 및 장치 유형을 식별합니다. 분석 및 장치별 콘텐츠 제공에 유용하지만, 사용자 에이전트 스푸핑으로 인해 신뢰할 수 없기로 악명 높습니다.
최신 모범 사례는 사용자 에이전트 스니핑 대신 기능 감지를 사용하는 것입니다. 그러나 헤더는 로깅, 디버깅 및 봇 감지에 여전히 유용합니다.
빠른 팁: 다양한 User-Agent 문자열로 API 엔드포인트를 테스트하여 정상적인 클라이언트에 대해 중단되지 않는지 확인하세요. 일부 서버는 익숙하지 않은 사용자 에이전트로 요청을 잘못 차단합니다.
응답 헤더는 콘텐츠 유형, 캐싱 지침, 보안 정책 및 서버 정보를 포함하여 서버의 응답에 대한 메타데이터를 제공합니다. 적절한 콘텐츠 렌더링, 성능 최적화 및 보안에 중요합니다.
주요 응답 헤더는 다음과 같습니다:
| 헤더 | 목적 | 예시 |
|---|---|---|
Content-Type |
응답 본문의 미디어 유형 | Content-Type: text/html; charset=utf-8 |
Content-Length |
응답 본문의 크기(바이트) | Content-Length: 1234 |
Content-Encoding |
사용된 압축 알고리즘 | Content-Encoding: gzip |
Set-Cookie |
클라이언트에 쿠키 전송 | Set-Cookie: id=a3; Secure; HttpOnly |
Location |
리디렉션을 위한 URL | Location: https://example.com/new |
Server |
서버 소프트웨어에 대한 정보 | Server: nginx/1.18.0 |
Date |
응답이 전송된 날짜 및 시간 | Date: Mon, 31 Mar 2026 12:00:00 GMT |
ETag |
리소스 버전의 고유 식별자 | ETag: "33a64df551425fcc55e" |
Content-Type 헤더는 적절한 콘텐츠 렌더링에 중요합니다. 브라우저에게 응답 본문을 해석하는 방법을 알려줍니다. 인코딩 문제를 방지하기 위해 항상 문자 인코딩(일반적으로 UTF-8)을 포함하세요:
Content-Type: application/json; charset=utf-8
Content-Type: text/html; charset=utf-8
Content-Type: image/pngContent-Type 헤더가 누락되거나 잘못되면 브라우저가 콘텐츠 유형을 추측하게 되며(MIME 스니핑), 이는 보안 취약점과 렌더링 문제로 이어질 수 있습니다.
Set-Cookie 헤더는 클라이언트 측에 쿠키를 생성합니다. 최신 쿠키는 항상 보안 속성을 포함해야 합니다:
Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Max-Age=3600보안 헤더는 일반적인 웹 취약점에 대한 첫 번째 방어선입니다. XSS, 클릭재킹 및 중간자 공격과 같은 공격으로부터 사용자를 보호하는 보안 정책을 시행하도록 브라우저에 지시합니다.
모든 프로덕션 애플리케이션은 다음과 같은 필수 보안 헤더를 구현해야 합니다:
CSP는 브라우저가 로드할 수 있는 리소스를 제어하여 XSS 공격을 방지합니다. 가장 강력한 보안 헤더 중 하나이지만 신중한 구성이 필요합니다:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com제한적인 정책으로 시작하여 필요에 따라 점진적으로 완화하세요. 사이트를 중단시키지 않고 정책을 테스트하려면 Content-Security-Policy-Report-Only를 사용하세요.
HSTS는 브라우저가 도메인에 대한 모든 향후 요청에 HTTPS를 사용하도록 강제하여 프로토콜 다운그레이드 공격을 방지합니다:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadpreload 지시문을 사용하면 도메인을 HSTS 프리로드 목록에 제출할 수 있으며, 이는 브라우저에 하드코딩됩니다. 이는twork Tools