TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 32 READS

인터프리터를 아예 빼버렸다 — Python을 네이티브로 컴파일하는 'pon' 실험

인터프리터를 아예 빼버렸다 — Python을 네이티브로 컴파일하는 'pon' 실험

Python은 왜 느리다는 소리를 들을까

Python으로 개발하다 보면 '편한데 느리다'는 말을 참 많이 듣죠. 왜 그럴까요? Python은 우리가 쓴 코드를 바로 기계어로 바꾸지 않고, 일단 바이트코드(bytecode)라는 중간 형태로 만든 다음, CPython이라는 인터프리터가 그걸 한 줄씩 읽으며 실행하기 때문이에요. 이 '한 줄씩 해석해가며 돌리는' 과정 자체에 오버헤드가 붙어요. 마치 외국어 문장을 통역사가 실시간으로 한 문장씩 옮겨주는 것과 비슷해서, 아무리 빨라도 처음부터 그 나라 말로 쓰인 글을 읽는 것보단 느릴 수밖에 없죠.

이번에 소개할 'pon'은 여기서 아주 과감한 시도를 해요. 제목 그대로 인터프리터를 아예 빼버리고, Python 3.14 코드를 곧장 네이티브 기계어(metal)로 컴파일하겠다는 거예요. 실행할 때 통역사(인터프리터)를 옆에 두지 않고, 처음부터 CPU가 바로 읽는 언어로 번역해두겠다는 발상이죠.

'인터프리터 없이'가 왜 어려운 일이냐면

Python을 빠르게 하려는 시도는 예전부터 많았어요. 그런데 대부분은 인터프리터를 완전히 없애지는 못했어요. 이유는 Python이 너무 '유연한' 언어이기 때문이에요.

Python은 변수에 무슨 타입이 들어올지 실행 전엔 확정하기 어렵고(동적 타이핑), 실행 도중에 함수나 클래스를 갈아끼울 수도 있고(몽키패칭), 심지어 문자열을 코드로 바꿔 실행하는 eval도 있어요. 이렇게 실행 중에 뭐든 바뀔 수 있으니, '컴파일 시점에 모든 걸 확정해서 기계어로 굳혀두는' AOT(Ahead-Of-Time, 미리 컴파일) 방식과는 궁합이 나빠요. 그래서 진짜로 인터프리터를 걷어내려면, 이런 극단적인 유연함을 어느 정도 제약하거나, 코드를 분석해 타입을 최대한 추론해내는 영리한 작업이 필요해요. pon이 도전하는 지점이 바로 이 어려운 매듭이에요.

기존 가속 도구들과의 지형도

Python 속도를 끌어올리는 도구들을 한 줄씩 정리하면 지형이 보여요. PyPy는 자주 실행되는 코드를 실행 중에 기계어로 바꾸는 JIT(Just-In-Time) 방식이라 빠르지만, 여전히 런타임이 함께 돌아가요. Cython은 Python에 타입 힌트를 달아 C로 바꿔주고, Numba는 수치 계산 함수에 JIT을 걸어줘요. Nuitka는 Python을 C로 컴파일해 실행 파일까지 만들어주는데, 속을 들여다보면 여전히 CPython 런타임(libpython)을 품고 있어요. 즉 '컴파일'이라고 해도 인터프리터의 그림자가 남아 있는 경우가 많다는 거죠.

반면 MIT에서 만든 Codon은 LLVM을 써서 Python과 비슷한 코드를 진짜 네이티브로 뽑는데, 대신 Python의 동적 기능 일부를 포기했어요. pon의 '인터프리터 없음(no interpreter)'은 바로 이 Codon 계열의 야심에 가까워요. 게다가 최근 CPython 본체도 3.13에서 실험적 JIT과 GIL(전역 잠금)을 없앤 빌드를 도입하며 성능에 팔을 걷어붙인 상황이라, Python 생태계 전체가 '더 빠르게'로 방향을 튼 흐름 위에 pon이 서 있는 거예요.

한국 개발자에게

실무에서 이걸 당장 배포에 넣긴 이르지만, 방향은 눈여겨볼 만해요. 특히 머신러닝 추론 서버나 데이터 파이프라인처럼 'Python으로 짜긴 했는데 속도가 아쉬운' 코드를 다루는 분들에게는 이런 네이티브 컴파일 시도가 미래의 선택지가 될 수 있어요.

다만 냉정하게 볼 부분도 있어요. Python의 진짜 힘은 numpy·pandas 같은 방대한 C 확장 생태계인데, 인터프리터를 걷어내면 이 라이브러리들과의 호환이 큰 숙제가 돼요. eval이나 동적 클래스 조작 같은 기능도 제약될 수 있고요. 그래서 pon 같은 프로젝트는 '모든 Python을 대체한다'기보다, '제약을 받아들이는 대신 속도를 얻는 특정 영역'에서 빛날 가능성이 커요. 이런 도구를 구경하다 보면 '인터프리터냐 컴파일이냐', '유연함이냐 속도냐' 하는 언어 설계의 근본 트레이드오프를 자연스레 이해하게 되는데, 그 감각 자체가 좋은 공부예요.

핵심 한 줄: Python을 빠르게 만드는 진짜 싸움은 '어떻게 컴파일하느냐'가 아니라, '이 언어의 어떤 유연함을 포기할 것이냐'입니다.

여러분은 Python의 속도 때문에 다른 언어로 갈아탄 경험이 있나요? 아니면 '느려도 생산성 때문에 계속 쓴다'는 쪽인가요? 각자의 선택 기준을 나눠봐요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/can1357/pon
SHARE
처리 중...