application/octet-stream

application/octet-stream은 media type만으로는 구체적인 형식을 알 수 없는 임의의(arbitrary) 바이너리 데이터를 가리키는 MIME 타입입니다. 데이터 자체에 의미가 없다는 뜻이 아니라, Content-Type이 그 의미(형식)를 알려주지 못한다는 뜻입니다. 콘텐츠의 실제 형식을 모르거나 알려주지 않을 때 쓰는 가장 일반적인(default) 바이너리 타입입니다.

1. 이름 뜯어보기

octet: 8비트, 즉 1바이트를 가리키는 단어입니다. 굳이 "byte"라 하지 않고 "octet"이라 부르는 이유는, 과거에는 1바이트가 항상 8비트는 아니었기 때문입니다(6·7·9비트 바이트를 쓰던 기계도 있었습니다). 그래서 표준 문서는 "정확히 8비트"를 못 박기 위해 octet이라는 단어를 씁니다.
stream: 정해진 구조 없이 이어지는 바이트의 흐름입니다.

합치면 octet-stream = 해석 규칙이 정해지지 않은 바이트 스트림입니다. → String vs Binary에서 다룬 "약속이 없으면 그냥 바이트"라는 개념의 구체적인 사례입니다.

2. 무슨 의미인가

MIME 타입은 타입/서브타입 형태로 데이터의 종류를 알려줍니다(text/html, image/png, application/json 등). 받는 쪽은 이 값을 보고 "텍스트로 렌더링할지, 이미지로 그릴지, JSON으로 파싱할지"를 결정합니다.

application/octet-stream은 이 결정에 필요한 형식 정보를 제공하지 않는 값입니다. "형식을 특정하지 못한 바이너리"라는 신호이며, 사실상 모든 바이너리 데이터의 fallback 기본값입니다. MIME 표준(RFC 2046)에서도 "알려지지 않은 데이터"의 기본 타입으로 정의되어 있습니다.

3. 주로 언제 보이나

형식을 단정할 수 없는 파일: 서버가 응답하는 데이터의 형식을 특정하지 못할 때.
Content-Type을 모를 때의 기본값: 업로드된 파일 등에서 타입을 추론하지 못하면, 더 구체적인 타입 대신 이 타입을 기본값으로 사용합니다.

4. 브라우저의 반응

브라우저는 application/octet-stream을 받으면 "이걸 화면에 표시하는 방법을 모른다"고 보고 인라인 렌더링 대신 다운로드로 처리하는 경향이 있습니다. 다만 이는 경향일 뿐 보장은 아닙니다.

5. 주의할 점

정확한 타입을 알면 그걸 쓰는 게 낫습니다. PDF면 application/pdf, PNG면 image/png를 주는 편이 클라이언트가 미리보기·캐싱·처리하기 좋습니다. octet-stream을 남발하면 본래 인라인으로 열 수 있는 것도 다운로드로 떨어집니다.
MIME sniffing과 보안: Content-Type이 부정확하면 일부 브라우저는 내용을 보고 타입을 추측(sniffing)하는데, 이 과정에서 업로드된 파일이 의도치 않게 HTML/스크립트로 해석되어 XSS로 이어질 수 있습니다. X-Content-Type-Options: nosniff는 브라우저가 선언된 타입만 신뢰하도록 해 이 sniffing을 억제합니다. 단, nosniff는 MIME sniffing을 막는 장치일 뿐 만능 XSS 방어책은 아니며, XSS는 별도의 대책(출력 인코딩, CSP 등)이 필요합니다.

6. Reference

Document History

2026-06-15T16:35:40+09:00 - Written by Claude Opus 4.8 (1M context) via Claude Code
2026-06-16T09:26:09+09:00 - Edited by Claude Opus 4.8 (1M context) via Claude Code
2026-06-16T09:29:09+09:00 - Edited by Claude Opus 4.8 (1M context) via Claude Code