00-foundations
이 챕터가 답하는 질문: 파일은 무엇이며, 컴퓨터는 그것을 어떻게 식별하는가? 한 줄 답: “파일은 바이트 스트림이지만, 우리가 실제로 다루는 것은 그 위의 식별과 메타데이터다.”
한 문장 답 (Pyramid Top)
파일이라는 단어는 두 개의 다른 것을 동시에 가리킨다 — ① 저장 매체 위의 바이트 시퀀스 자체(
bytes on disk)와 ② 그 바이트가 무엇인지를 말해주는 식별자 묶음(name + extension + MIME + magic + filesystem metadata). 이 챕터는 ②가 ①을 어떻게 감싸고 있는지를 한 층씩 벗긴다.
챕터 지도 (Mermaid)
Why — 왜 이 챕터부터 시작하나
상위 레이어(전송·미디어·스트리밍)에서 일어나는 거의 모든 미스터리한 버그는 여기서 출발한다.
- “왜 PNG로 업로드한 파일이 서버에서는
application/octet-stream으로 보일까?” →03-mime-and-magic.md - “왜 한글 파일명이 다운로드하면 깨질까?” →
02-encoding-binary.md - “왜
.jpg확장자인데 브라우저가 안 띄울까?” →04-extensions-and-identification.md - “왜 S3는
ls로 디렉토리를 못 보나?” →05-filesystems.md
이 챕터는 ‘파일’이라는 단어 안에 숨어 있는 5개의 분리된 개념을 분리해서 이름을 붙인다. 이름을 붙이고 나면, 위 질문들이 자동으로 풀린다.
How — 어떻게 읽나
다음 5개 문서를 순서대로 읽으면 한 시간 정도 걸린다. 각 문서는 독립적으로 읽혀도 되지만, 순서가 누적적이다.
| # | 파일 | 읽는 데 | 핵심 키워드 |
|---|---|---|---|
| 01 | 01-what-is-a-file.md | 12분 | byte stream, file descriptor, UNIX everything is a file, POSIX |
| 02 | 02-encoding-binary.md | 12분 | binary vs text, ASCII, UTF-8, UTF-16, BOM, endianness |
| 03 | 03-mime-and-magic.md | 12분 | MIME type, magic number, RFC 6838, libmagic, content sniffing |
| 04 | 04-extensions-and-identification.md | 10분 | file extension, MIME vs ext, MIME sniffing 보안 |
| 05 | 05-filesystems.md | 12분 | inode, metadata, ext4/APFS/NTFS, object storage(S3) |
의존성: 02는 01을, 03은 02를, 04는 03을 이미 알고 있다고 가정한다. 05는 1~4 모두를 통합한다.
What — 한 페이지 요약 (모든 문서의 핵심 한 줄)
| 문서 | 한 줄 결론 |
|---|---|
| 01 | 파일은 바이트 시퀀스고, 그것에 접근하는 표준 인터페이스(open/read/write/close)가 UNIX의 핵심 발명이다. |
| 02 | 텍스트 파일이라는 것은 없다 — 모든 파일은 바이너리이고, “텍스트”란 그 바이트를 어떤 인코딩으로 해석하기로 약속한 것뿐이다. |
| 03 | 진짜 파일 타입은 *확장자가 아니라 첫 몇 바이트(매직넘버)*에 있다. 브라우저·CDN·OS가 모두 이 사실에 의존한다. |
| 04 | 확장자는 힌트고 MIME은 선언이며 매직은 증거다. 셋이 어긋나는 순간 보안 사고가 시작된다. |
| 05 | 파일시스템은 바이트를 어디에 어떻게 색인할지를 정한 규약이다. S3는 그래서 파일시스템이 아니다 (key-value object store). |
What-if — 이 챕터를 건너뛰면
- 인코딩을 모르고 다국어를 다루면: 문자가 깨진다 (Mojibake).
?나□로 바뀌는 그 현상. - MIME과 매직을 혼동하면:
Content-Type: image/png인데 실제론 SVG라 XSS가 터진다. - 파일시스템을 추상화로만 이해하면: S3에 대고
mv명령처럼 코드를 짜다가 복사 + 삭제가 atomic이 아니라는 사실에 운영 사고를 낸다.
Insight — 한 단락 이야기
“파일이라는 단어는 1956년 IBM에서 태어났다”
자기테이프 시대, IBM 305 RAMAC가 처음으로 디스크에 데이터를 저장했을 때 엔지니어들은 그것을 folder나 record가 아니라 **
file**이라 불렀다 — 종이 서류철에서 빌려온 비유였다. 50년 뒤 우리는 그 단어로 4K HDR 비디오, 머신러닝 가중치, 컨테이너 이미지를 부르고 있다. 추상화의 이름은 가벼웠지만, 그 위에 쌓인 표준은 무겁다. — 이 챕터가 하는 일은 그 무게를 다섯 층으로 분해하는 것.
한 단락 요약
파일은 바이트 스트림(
01) 위에 인코딩(02), 식별(03,04), 저장 구조(05)가 차례로 쌓인 구조다. 이 챕터를 끝내면 “왜 그 파일이 그렇게 동작하는가”라는 질문 대신 *“어느 레이어에서 잘못된 가정을 했는가”*라는 질문을 던지게 된다. 다음 챕터(01-transfer)는 이 식별된 파일이 네트워크 위를 어떻게 움직이는지를 다룬다.