05 · Application Files
이 챕터가 답하는 질문:
image/*,video/*,audio/*가 아닌application/*은 어떻게 다루는가? 작성: 2026-05-10 / 스타일: Minto +/explain
한 줄 답 (Pyramid Top)
application/*은 “미디어가 아닌 모든 파일” 의 쓰레기통이지만, 실제로는① 문서(PDF/Office) · ② 아카이브(ZIP/TAR/7z) · ③ 데이터 직렬화(protobuf/parquet)의 3대 부족이다. 이 셋은 재생이 아니라 해석·추출·검증으로 다룬다는 점에서 미디어와 결정적으로 다르다.
Why — 왜 application/* 이 따로 필요한가
미디어(image/*, video/*, audio/*)는 재생(decode) 이 목적이지만,
application/* 은 콘텐츠 추출 / 구조 검증 / 변환 이 목적이다.
- PDF 한 장을 띄우려면
xref → 객체 트리 → 폰트/이미지 → 텍스트 추출을 거쳐야 한다 (디코더 한 줄로 끝나지 않음). - docx 한 개는 사실 ZIP 안에 XML 더미 —
unzip -l file.docx가 핵심 디버깅 도구다. - parquet 한 덩어리는 미디어처럼 시간축이 아니라 컬럼 축으로 인덱싱된다.
또한 미디어보다 보안 위협이 훨씬 크다:
- ZIP slip — 압축 해제 시
../../../etc/passwd로 빠져나오는 path traversal. - Zip bomb — 42KB 파일이 풀면 4.5PB 가 되는 폭탄.
- PDF JavaScript —
/JS스트림으로 사용자 추적 / exfil. - OLE 매크로 — 레거시 .doc/.xls 의 VBA.
그래서 application/* 은 “열기 전에 검증” 이 모든 절차의 시작이다.
How — 어떻게 정리했는가
5개 파일 인덱스
| # | 파일 | 핵심 질문 |
|---|---|---|
| 0 | README.md | 이 챕터의 입구 (이 문서) |
| 1 | 01-pdf.md | PDF는 왜 무작위 페이지를 바로 열 수 있는가 — xref 와 객체 트리 |
| 2 | 02-office-ooxml.md | docx 는 왜 ZIP 인가 — OOXML vs 레거시 OLE |
| 3 | 03-archives-zip-tar-7z.md | ZIP / TAR / 7z 는 무엇이 같고 무엇이 다른가 |
| 4 | 04-binary-formats.md | protobuf / CBOR / parquet — 데이터 바이너리는 미디어 바이너리와 어떻게 다른가 |
| 5 | 05-extraction-and-rendering.md | 텍스트 / 이미지 / 메타 추출 — Tika · pdfplumber · LibreOffice headless |
읽는 순서
- 처음 읽는다면 →
01 → 02 → 03 → 04 → 05순서. - PDF 만 급하다면 →
01 → 05. - 업로드 보안 검토 →
03 → 01(zip slip / PDF JS). - 데이터 파이프라인 →
04하나로. - 백오피스 검색 인덱싱 →
05만.
What — 챕터를 관통하는 5가지 사실
| # | 사실 | 어디서 다루나 |
|---|---|---|
| 1 | PDF의 xref 테이블이 끝부분에 있어서 마지막 N KB 만 받아도 페이지 위치를 안다 | 01-pdf.md |
| 2 | .docx / .xlsx / .pptx 는 unzip 만으로 내부 XML 을 볼 수 있다 | 02-office-ooxml.md |
| 3 | ZIP 의 중앙 디렉토리(Central Directory)도 파일 끝에 있다 — PDF 와 같은 패턴 | 03-archives-zip-tar-7z.md |
| 4 | 파일이 ZIP 인지 PDF 인지 첫 4바이트(매직) 만 봐도 알 수 있다 (PK\x03\x04 / %PDF) | 01, 03 |
| 5 | parquet 는 row 가 아니라 column 단위로 저장 — 분석 쿼리 99% 가 일부 컬럼만 읽는다 | 04-binary-formats.md |
What-if — 무엇이 잘못될 수 있는가
| 함정 | 증상 | 원인 챕터 |
|---|---|---|
| Zip slip | 업로드된 ZIP 풀었더니 서버 ~/.ssh/authorized_keys 가 변경됨 | 03 |
| Zip bomb | 42KB ZIP 가 풀면 디스크 4.5PB 점유 → OOM/디스크 풀 | 03 |
| PDF JS exfil | 폼 PDF가 사용자 입력을 외부 URL 로 POST | 01 |
| docx 매크로 | OLE 가 아닌 OOXML 도 vbaProject.bin 매크로 가능 | 02 |
| OLE 매직 헤더 | D0 CF 11 E0 — .doc/.xls 만이 아니라 .msi/.ppt 도 같은 헤더 | 02 |
| parquet schema drift | 다른 날짜의 파일이 컬럼 타입이 다름 → 쿼리 실패 | 04 |
Insight — 흥미로운 이야기
“PDF 는 1993년 표준이지만 여전히 정부·법률의 기본 포맷이다”
Adobe 가 1993년 PDF 1.0 발표, 2008년 ISO 32000-1 로 표준화. “디바이스/OS 와 무관하게 동일하게 보인다”는 약속을 30년간 지킨 거의 유일한 포맷. 그래서
xref같은 1993년의 설계가 지금도 살아있다 →01-pdf.md.
“Microsoft 가 Office 를 ZIP+XML 로 바꾼 이유”
2007년 Office 2007 발표와 함께
.docx등장. 그 전까지.doc은 OLE 컴파운드 — 사실상 작은 파일시스템. 표준화 압력(EU 의 ODF 채택)에 대응하기 위해 ECMA-376 / ISO/IEC 29500 표준화. 결과: 이제 누구나unzip word.docx로 내부를 볼 수 있다 →02-office-ooxml.md.
“Zip bomb 의 챔피언”
42.zip(Unzip Bomb) — 42KB 파일이 5중 중첩 압축 해제 시 4.5 PB. 단순 비율 압축이 아니라 자기참조 ZIP (DeepZip) 은 28바이트로 무한 루프. 그래서 모든 ZIP 처리기는 압축 해제 비율 한계 + 깊이 한계 가 필수 →03.
한 단락 요약
application/*은 미디어가 아닌 파일의 통칭이지만, 실제로는 문서·아카이브·데이터 바이너리 의 3대 부족이다. 모두 재생이 아니라 추출·검증 이 목적이고, 모두 보안 위협이 미디어보다 크다. 이 챕터는 그 5개 문서로 왜·어떻게·무엇을 정리한다.