
솔직히 고백합니다.
오늘 새벽, 회사에서 LLM 서빙용 도커 이미지를 빌드하고 있었습니다.
PyTorch 깔고, CUDA 라이브러리 넣고, 각종 Python 의존성 패키지 설치하다 보니 이미지 사이즈가 가볍게 3GB를 넘기더군요.
"요즘 스토리지 싼데 뭐 어때, 최적화는 나중에 하자"며 스스로 합리화하고 있을 때였습니다.
우연히 기술 블로그 하나를 봤습니다.
머리를 한 대 얻어맞은 기분이었습니다.
13KB짜리 파일 하나가 있습니다.
이 단일 파일 하나가 Windows에서도 돌고, Linux에서도 돌고, 심지어 웹 브라우저에서도 돕니다.
에뮬레이터가 아닙니다. 네이티브 실행입니다.
내용물은 '스네이크(Snake)' 게임입니다.

순간 얼굴이 화끈거렸습니다.
저는 지금 기껏해야 'Hello World' 수준의 API 서버 띄우는데 기가바이트 단위 리소스를 태우고 있는데,
누군가는 플로피 디스크 한 장의 1/100도 안 되는 용량에 멀티 플랫폼 런타임을 구겨 넣었으니까요.
도대체 어떻게 짠 걸까요.
오기가 생겨 헥사 에디터(Hex Editor)를 열어 뜯어봤습니다.
이건 단순한 코딩이 아니라, 운영체제(OS)와 컴파일러에 대한 '변태적인' 이해도가 없으면 불가능한 구조입니다.
핵심은 'Polyglot(폴리글롯)' 바이너리입니다.
하나의 파일이 여러 가지 언어(형식)로 동시에 해석되도록 만든 겁니다.
구조를 뜯어보니 기가 찹니다.
첫째, Windows 실행을 위해 파일 앞부분에 PE(Portable Executable) 헤더를 둡니다.
보통은 여기서 끝나야 정상이지만, 이 개발자는 PE 헤더의 'MZ' 시그니처 뒤에 있는 잉여 공간을 노렸습니다.
여기에 Linux가 해석할 수 있는 셸 스크립트 명령어를 숨겨놨습니다.
Windows는 이 부분을 무시하고 바이너리를 실행하지만,
Linux에서 이 파일을 실행하면 앞부분의 PE 헤더를 셸 스크립트로 인식합니다.
둘째, Linux에서는 이 스크립트가 파일 뒷부분의 압축된 ELF64 바이너리를 찾아냅니다.
dd나 tail 같은 명령어로 자기 자신을 잘라내고, lzma로 압축을 풀어 메모리에 올린 뒤 실행합니다.
셋째, 웹 브라우저는 더 가관입니다.
HTML 파서는 파일 앞부분에 쓰레기 데이터(바이너리 코드)가 있어도, <html> 태그가 나올 때까지 무시하는 경향이 있습니다.
이 점을 악용했습니다.
파일 맨 뒤에 HTML/JS 코드를 붙여놓고, 앞부분의 바이너리 데이터는 CSS로 font-size: 0 처리를 해버려서 화면에 안 보이게 숨겼습니다.
결국 이 파일은 3개의 운영체제를 모두 속이고 있는 겁니다.
총 파일 크기 13,312 바이트.
우리가 흔히 쓰는 node_modules 폴더 안에 있는 아이콘 파일 하나보다 작습니다.
이걸 보며 "와, 신기하다" 하고 넘어가면 당신은 평생 '복사 붙여넣기' 개발자에 머무를 겁니다.
여기서 우리가 느껴야 할 것은 '추상화의 비용(Cost of Abstraction)'입니다.
우리는 너무 편한 세상에 살고 있습니다.
Electron으로 앱 하나 만들면 수백 메가바이트, Python으로 간단한 스크립트 짜도 가상환경 포함하면 수십 메가바이트입니다.
하드웨어가 좋아졌다고 해서, 개발자가 리소스를 낭비해도 되는 면죄부가 생기는 건 아닙니다.
Latency가 튀고, Throughput이 안 나오는 이유를 항상 "서버 스펙이 낮아서"라고 핑계 대지 않으셨나요?
사실은 우리가 OS가 메모리를 어떻게 관리하는지, 바이너리가 어떻게 로딩되는지 전혀 모르고 짰기 때문일 수 있습니다.
물론 현업에서 이렇게 코드를 짜면 유지보수 불가능한 레거시가 됩니다. 절대 따라 하라는 말이 아닙니다.
하지만 적어도 내가 작성한 코드가 로우 레벨(Low-level)에서 어떻게 동작하는지는 알아야 합니다.
라이브러리 함수 하나 호출할 때, 그 뒤에서 일어나는 수천 번의 인스트럭션 사이클을 상상할 수 있어야 진짜 엔지니어입니다.
저는 오늘 작성하던 Dockerfile을 다시 열었습니다.
불필요한 레이어(Layer)를 다 지우고, Base Image를 알파인(Alpine)으로 바꾸고, 멀티 스테이지 빌드를 적용했습니다.
3GB였던 이미지가 400MB로 줄었습니다.
아직 저 13KB짜리 장인정신에는 발끝도 못 미치지만, 적어도 개발자로서의 양심은 조금 지킨 것 같습니다.
여러분의 코드는 지금 얼마나 비대한가요?
그 무게가 정말 필요한 무게인지, 아니면 당신의 게으름의 무게인지 한 번쯤 점검해 보시기 바랍니다.

![[실리콘밸리] 엔비디아 엔지니어가 분석한 'RTX 5090 병목 현상' 실험 리포트](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fpoooling-blog%2Fblog-images%2F2026%2F01%2F12%2F1961_02a179d9.png&w=3840&q=75)
