Hacker News 2026.03.29 31

리눅스는 사실 인터프리터다? ELF 바이너리를 바라보는 새로운 시선

우리가 당연하게 여기던 것

리눅스에서 프로그램을 실행한다는 건, 터미널에 ./myapp을 치거나 더블클릭하는 거잖아요. 그런데 이 과정을 자세히 들여다보면 꽤 흥미로운 관점이 하나 나와요. "리눅스 커널은 사실 인터프리터 아닌가?"라는 거예요.

인터프리터라고 하면 보통 Python이나 JavaScript 같은 걸 떠올리잖아요. 소스 코드를 한 줄씩 읽어서 실행하는 프로그램이요. 그런데 생각해 보면, 리눅스 커널도 ELF라는 형식의 바이너리 파일을 읽어서 메모리에 올리고 실행하는 역할을 하거든요. 이게 뭐냐면, 커널이 ELF 파일이라는 "프로그램"을 해석해서 실행해 주는 "인터프리터"처럼 동작한다는 이야기예요.

셔뱅(#!)에서 시작되는 이야기

리눅스에서 스크립트 파일 맨 윗줄에 #!/bin/bash나 #!/usr/bin/env python3 같은 걸 적어본 적 있을 거예요. 이걸 셔뱅(shebang)이라고 하는데요, 커널이 이 줄을 읽고 "아, 이 파일은 bash로 실행해야 하는구나" 또는 "python3으로 돌려야 하는구나" 하고 판단하는 거예요.

여기서 재미있는 점이 있어요. 셔뱅이 있는 스크립트 파일을 실행하면, 커널은 해당 인터프리터를 찾아서 그 인터프리터에게 스크립트를 넘겨주잖아요. 그런데 그 인터프리터 자체(예를 들어 /bin/bash)는 ELF 바이너리거든요. 그러면 그 ELF 바이너리는 누가 해석하나요? 바로 커널이에요. 커널이 ELF 형식을 읽고, 코드 세그먼트와 데이터 세그먼트를 메모리에 적절히 배치하고, 동적 링커를 호출하고, 최종적으로 엔트리 포인트에서 실행을 시작시켜 주는 거예요.

이렇게 보면 커널은 ELF라는 언어의 인터프리터 역할을 하고 있는 셈이에요. Python 인터프리터가 .py 파일을 해석하듯, 리눅스 커널은 ELF 파일을 해석하는 거죠.

`binfmt_misc`라는 숨은 기능

이 관점이 단순한 말장난이 아니라는 걸 보여주는 리눅스 기능이 하나 있어요. 바로 binfmt_misc인데요, 이게 뭐냐면 커널에게 "이런 형식의 파일을 만나면 이 프로그램으로 실행해 줘"라고 등록할 수 있는 기능이에요.

예를 들어 .jar 파일을 만나면 자동으로 java -jar로 실행하게 할 수도 있고, Windows의 .exe 파일을 만나면 Wine으로 실행하게 설정할 수도 있어요. 심지어 다른 CPU 아키텍처용 바이너리를 QEMU로 에뮬레이션해서 실행하는 것도 가능하거든요. Docker에서 ARM 이미지를 x86 머신에서 빌드할 때 쓰이는 게 바로 이 메커니즘이에요.

이걸 보면 리눅스 커널은 단순히 ELF만 해석하는 게 아니라, 다양한 형식의 실행 파일을 적절한 인터프리터에게 연결해 주는 일종의 메타 인터프리터 역할을 하고 있는 거예요.

계층 구조로 바라보기

이 관점을 확장하면 재미있는 계층 구조가 보여요. 맨 아래에 하드웨어(CPU)가 있고, 그 위에 커널이 있고, 커널 위에 각종 런타임(bash, Python, JVM 등)이 있고, 그 위에 우리가 작성한 코드가 있잖아요. 각 계층이 윗 계층의 "프로그램"을 해석해서 실행해 주는 인터프리터 역할을 하는 거예요.

CPU는 기계어를 인터프리팅하고, 커널은 ELF를 인터프리팅하고, Python은 .py를 인터프리팅하고... 이런 식으로 컴퓨터 시스템 전체가 인터프리터의 층층이 쌓인 구조라고 볼 수 있는 거죠. 컴퓨터 과학에서 말하는 "추상화 계층"이라는 개념이 이렇게 실체화되는 거예요.

비슷한 관점들

사실 이런 시각은 완전히 새로운 건 아니에요. SICP(컴퓨터 프로그램의 구조와 해석)라는 유명한 교과서에서도 "메타서큘러 인터프리터"라는 개념을 다루면서, 프로그래밍 언어 자체를 해석하는 프로그래밍 언어라는 재귀적 구조를 설명하거든요. 또 가상 머신(VM)이라는 개념도 비슷한 맥락이에요. JVM이 Java 바이트코드를 해석하는 것, V8이 JavaScript를 실행하는 것, 이 모든 게 결국 같은 패턴이에요.

다만 일반적으로 "인터프리터"라고 하면 소스 코드를 텍스트로 읽어서 실행하는 걸 떠올리는데, 커널이 하는 일은 바이너리 형식을 파싱해서 실행하는 거라 전통적인 정의와는 좀 달라요. 그래서 이 주장에 동의하지 않는 사람도 있을 수 있는데, 어디까지를 인터프리터라고 부를 것이냐는 정의의 문제이기도 하죠.

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

이런 관점이 당장 코딩에 도움이 되냐고요? 직접적으로는 아닐 수도 있어요. 하지만 시스템을 이해하는 깊이가 달라져요. binfmt_misc를 알면 Docker 멀티 아키텍처 빌드가 어떻게 돌아가는지 이해할 수 있고, ELF 로딩 과정을 알면 실행 파일 크기 최적화나 보안 분석에서 한 발 앞서갈 수 있거든요.

특히 임베디드 리눅스나 컨테이너 환경을 다루는 분들에게는 이런 저수준 이해가 디버깅할 때 큰 도움이 되어요. "왜 이 바이너리가 실행이 안 되지?" 같은 문제를 만났을 때, 커널이 실행 파일을 어떻게 처리하는지 알면 원인을 훨씬 빨리 찾을 수 있거든요.