TECH 으로 돌아가기
TECH HACKER NEWS 2주 전 6분 읽기 86 READS

바이너리는 왜 자꾸 뚱뚱해질까? '모든 바이트가 중요하다'가 알려주는 실행파일 다이어트

바이너리는 왜 자꾸 뚱뚱해질까? '모든 바이트가 중요하다'가 알려주는 실행파일 다이어트

무슨 일이 있었냐면요

요즘은 디스크도 넉넉하고 네트워크도 빠르니까, 실행파일(바이너리) 크기 같은 건 신경 안 쓰는 분이 많을 거예요. 'Hello World 하나가 2MB쯤 되면 어때, 돌아가기만 하면 되지' 하는 마음이죠. 그런데 이번 글은 바로 그 무심함을 정면으로 건드립니다. 모든 바이트가 중요하다(Every Byte Matters) 는 제목 그대로, 바이너리 속을 한 바이트 한 바이트 뜯어보면서 '왜 이렇게 커졌는지'를 추적하는 이야기예요.

왜 지금 이 얘기가 의미 있냐면요. 컨테이너 이미지, 서버리스 함수, 임베디드 기기, 웹어셈블리처럼 크기가 곧 비용이자 속도인 환경이 점점 늘고 있거든요. 콜드 스타트(함수가 처음 깨어날 때 걸리는 시간)나 배포 속도, 메모리 사용량이 전부 바이너리 크기와 직결되니까, 다시 한번 '다이어트'가 중요한 주제로 돌아온 거죠.

바이너리 안에는 뭐가 들어 있을까

조금 풀어서 설명해 볼게요. 우리가 컴파일하면 나오는 실행파일은 그냥 기계어 덩어리가 아니에요. 안을 들여다보면 여러 칸막이(섹션)로 나뉘어 있어요. 실제 코드가 들어가는 .text, 초기값이 있는 데이터가 담기는 .data, 디버깅 정보가 잔뜩 들어가는 .debug, 그리고 함수나 변수 이름이 적힌 심볼 테이블 같은 것들이죠.

핵심은, 우리가 실제로 실행하는 데 꼭 필요한 건 이 중 일부뿐이라는 거예요. 디버그 정보나 심볼 이름은 개발할 때는 고맙지만 배포본에서는 그냥 무게만 더하는 짐일 때가 많거든요. 그래서 strip 같은 도구로 이걸 떼어내면 크기가 확 줄어요.

바이너리가 뚱뚱해지는 더 큰 원인은 정적 링크와 의존성이에요. 이게 뭐냐면, 내가 쓴 코드는 한 줄인데 그게 끌고 들어오는 라이브러리가 자기 친구들을 줄줄이 데려오는 상황이에요. 특히 Go나 Rust처럼 정적 링크를 기본으로 하는 언어는 런타임과 표준 라이브러리를 통째로 안고 가다 보니 기본 크기가 커요. 여기서 '데드 코드 제거(쓰지 않는 코드 잘라내기)'나 링커 최적화가 빛을 발하는 거죠.

실제로 줄이는 방법들

실무에서 바로 써볼 만한 무기들을 정리해 볼게요. 먼저 무엇이 무거운지 측정하는 게 시작이에요. size로 섹션별 크기를 보고, Google의 Bloaty McBloatface 같은 도구를 쓰면 '어떤 심볼, 어떤 라이브러리가 몇 바이트를 차지하는지'를 사람이 읽기 좋게 보여줘요. 추측으로 자르지 말고, 측정하고 자르는 게 핵심이에요.

그다음은 정석 코스예요. 디버그 심볼을 떼는 strip, 컴파일러에 -Os(크기 최적화) 옵션 주기, 링크 타임 최적화(LTO)로 안 쓰는 코드 정리하기, 그리고 압축 도구인 UPX로 실행파일 자체를 압축하기 같은 거죠. 컨테이너라면 scratchdistroless 같은 최소 베이스 이미지를 쓰는 것만으로도 수백 MB가 사라지기도 해요.

업계 맥락에서 보면

이 주제는 임베디드와 시스템 프로그래밍 쪽에서는 늘 진지했지만, 최근엔 웹어셈블리(Wasm) 덕분에 다시 뜨거워졌어요. Wasm은 브라우저나 엣지에서 모듈을 내려받아 실행하는데, 크기가 곧 로딩 속도라서 바이트 하나에 민감하거든요. 서버리스 진영에서도 콜드 스타트를 줄이려고 바이너리 슬림화에 진심이고요. 리눅스 배포판들이 디버그 정보를 별도 패키지로 분리하는 흐름도 같은 맥락이에요. 결국 업계 전체가 '필요할 때만 무게를 진다'는 방향으로 가고 있는 거죠.

한국 개발자에게 주는 시사점

클라우드 비용 청구서를 받아본 분이라면 바로 와닿을 거예요. 컨테이너 이미지를 절반으로 줄이면 배포 시간, 레지스트리 저장 비용, 콜드 스타트 지연이 같이 줄어들거든요. CI/CD 파이프라인에 'Bloaty로 크기 변화 추적하기' 같은 단계를 하나 넣어두면, 어느 날 누가 무거운 라이브러리를 무심코 추가했을 때 바로 알아챌 수 있어요. 큰 작업이 아니라 '습관'의 문제라 부담도 적고요.

마무리

한 줄로 정리하면, 바이너리 크기는 운명이 아니라 선택의 결과라는 거예요. 측정하고, 떼어내고, 최소화하면 분명히 줄어듭니다.

여러분은 빌드 결과물 크기를 따로 신경 써 본 적 있으세요? 아니면 '돌아가면 장땡'이라 한 번도 들여다본 적 없으셨나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://fzakaria.com/2026/06/01/every-byte-matters
SHARE
처리 중...