Compilers in the Age of LLMs - Yusuf Olokoba, Muna

영상 링크: Compilers in the Age of LLMs — Yusuf Olokoba, Muna
채널명: AI Engineer

LLM 시대의 컴파일러: Python 코드를 어디서든 실행 가능한 바이너리로 변환하는 혁신적 접근 핵심 요약

• 영상은 LLM(대규모 언어 모델)과 최신 AI 기반 애플리케이션 개발 현장의 실무적 문제에서 출발하여, “더 많은 AI 모델을 더 다양한 곳에 쉽게 배포하는 방법”을 고민한 결과로 Python용 컴파일러 개발기를 다룸
• 기존 AI 엔지니어의 작업 흐름(여러 레포, huggingface 탭, 에이전트적 워크플로우 등)이 복잡하고, 모델을 쓸 때마다 인프라 재구축 문제에 직면함을 지적함
• 목표는 오픈AI 클라이언트처럼 심플하게, 새로운 모델을 “그냥 지정만 하면” 바로 쓸 수 있게 하는 것 — 오픈소스 모델/내부 모델 모두가 타겟
• Python 추론 함수 → self-contained한 바이너리로 변환하여 어디서든(클라우드, 애플실리콘 등) 배포 가능하도록 설계
• 하이브리드 인퍼런스(로컬과 클라우드/엣지의 복합 AI 사용)가 미래라는 판단: 이를 위해 저수준, 하드웨어 친화적, 반응성 높은 실행 단위 필요
• 실제 예시로 Google의 2.7억 파라미터 Gemini 임베딩 모델 Python 함수를 바탕으로, 동적 Python 코드를 정적 C++/Rust 코드로 변환하는 과정을 상세히 소개
• Python의 동적 타이핑 문제를 ‘타입 전파(type propagation)’ 기법과 IR(Intermediate Representation) 생성으로 해결함
• 수많은 연산(예: 문자열+문자열, numpy 등)을 일일이 C++로 포팅하는 부담을 LLM 코드 생성 능력 활용으로 ‘대량 생산’ 트랙터블하게 만듦
• 완성된 C++ 라이브러리를 FFI(Foreign Function Interface)로 Node.js/JavaScript를 포함한 어떤 환경에서도 쉽게 사용할 수 있게 설계
• 최종적으로 오픈AI 공식 클라이언트 인터페이스와 완벽히 호환되도록 추상화하여, 모든 오픈소스 AI 모델을 손쉽게 활용하는 새로운 배포 패러다임을 구현함

세부 요약 - 주제별 정리

AI 개발자들이 실제 직면하는 것은 하이프가 아닌 기본적 배포와 통합의 어려움임

• AI 엔지니어들은 여러 레포지토리, huggingface 탭, client, agentic workflow(HTTP 호출을 체인으로 묶은 것 등)을 동시에 활용하는 복잡한 환경에서 일하고 있음
• 최근 시장의 화두(Voice agent, MCP 등)와 달리, 실제 현장 팀들은 “새로운 AI 모델을 더 많이 다양한 환경에 적용하려면 매번 인프라를 다시 만들어야 한다”는 실무적 과제에 직면함
• 예: hugging face에서 오픈소스 새 모델 사용 시 Dockerfile 작성, 컨테이너 배포, 추가적 tool chain 관리 등 복잡성이 급격히 증가함
• 개발자들은 오히려 “오픈AI 클라이언트처럼, 그냥 모델명만 바꾸면 어디서나 동작하는 경험”을 원한다는 현실적 니즈가 있음

Python 컴파일러 개발은 ‘하나의 단일 실행 파일로 어디든지 배포’라는 목표에서 출발함

• (1) “개발자가 내부/외부 오픈소스 모델을 가져와서 파이썬 추론 코드 몇 줄만 쓰면, 아무 환경에서나 실행될 수 있게 하고 싶었다”가 프로젝트 출발점
• (2) “앞으로의 AI 배포는 클라우드 대형모델 + 로컬/엣지 소형모델이 협업하는 하이브리드 인퍼런스가 될 것”이라는 미래 전망
• 하이브리드 환경에서는 꼭 Python + Docker, 서버 배포만이 아니라 기기 가까운 저수준, 반응성 높은 실행 단위가 필요함
• 목표: Python 추론 코드를 IR(중간 표현)로 바꾼 뒤, 자립 실행 가능한 바이너리(Cloud, Apple Silicon, 엣지 등 어디서나)로 컴파일

실제 예시: Google의 2.7억 파라미터 Gemini 임베딩 모델을 활용한 코드 변환 시연

• 데모 예제: Google Gemma 270M(2.7억 파라미터) 텍스트 임베딩 모델을 Python 함수로 작성
• 입력: 문장 리스트(str list) → 출력: 임베딩 벡터 행렬(matrix), RAG(Retrieval Augmented Generation) 등 검색 및 문서 추출에 활용
• 이 모델은 충분히 작아서 클라우드 GPU 뿐 아니라 PC급 소비자 하드웨어에서도 빠르게 실행 가능

Python 코드를 C++/Rust 코드로 변환하는 과정에선 tracing(추적)과 타입 정보 추출이 핵심임

• 첫 단계: Python 추론 함수를 ‘그래프’로 변환(trace)하여 내부의 호출 흐름과 연산 전개를 구조적으로 파악
• Torch FX(Pytorch 2의 symbolic tracer) 시도: 그러나 (1) PyTorch 연산만 추적 가능, (2) 고유한 자료형(numPy, OpenCV 등) 추적이 어렵고, (3) 샘플 입력값 생성에 한계 → 자체 트레이서 개발 필요성 대두
• LLM을 활용한 구조화된 출력물(trace) 생성 시도: 정확도는 우수했으나 속도가 너무 느려서 결국 AST(추상 구문 트리) 분석기반 자체 IR 생성기로 전환
• 결과: (1) 입력 노드(문장 리스트), (2) 서브 연산(토크나이저 호출, 모델 호출), (3) 출력 반환 - 이렇게 구조적, 계통적 IR 확보

Python과 네이티브 언어(C++/Rust)의 ‘동적 타입 vs 정적 타입’ 문제는 타입 전파 기법으로 해결함

• Python은 변수 타입 변경이 자유로운 ‘동적 타입’ 언어지만, C++/Rust는 변수 선언에 반드시 고정 타입이 필요
• ‘타입 전파(type propagation)’: Python 함수 시그니처(입력은 str 리스트 등)와 상수형 정보(예: prefix도 str), 그리고 연산 목적(덧셈 등)을 종합 분석
• 예시: 리스트 내포에서 prefix+입력문자열 연산 → 각 항목이 str임을 파악, 이 정보를 캐스케이딩하여 연쇄적으로 모든 중간 변수 타입을 추론
• C++에서는 이를 기반으로 string+string 연산 함수를 별도 생성해, 타입 안전성과 정적 컴파일에 적합하도록 변환

Python 연산 서명별 구현 부담은 LLM 코드 자동 생성으로 해결함

• 모든 Python 연산자/함수(+,-,**, numpy 연산 등)을 인간이 일일이 C++로 직접 포팅하면 너무 방대함
• 하지만 실제로는 조합의 다양성 때문이지, ‘초기 원시 연산자 집합’ 자체는 유한하여 트랙터블(tractable)함
• LLM을 활용해 Python 연산을 C++/Rust로 자동 코드 생성 → 내부적으로 다양한 function wrapping 지원, 대다수 변환 작업 자동화

IR → C++ 코드 → 바이너리 생성 단계에서는 모든 종속성이 self-contained됨

• Python 원본 함수의 IR을 바탕으로, 최적화되고 타입 정제된 C++ 코드 자동 생성
• 토크나이저 호출, 모델 추론 등 모든 로직을 네이티브 언어로 구조화
• 컴파일 후 결과물은 .so(리눅스: shared object), .dll(윈도우), .dylib(맥 등) 등 시스템별 네이티브 동적 라이브러리로 제공
• 즉, 기존에 Python + Docker 환경에 잠겨 있던 추론 코드를 완전히 해방 → 어떠한 디바이스, 아키텍처에서도 네이티브로 실행 가능

FFI(Foreign Function Interface)를 통해 어떤 프로그래밍 언어, 어떤 환경에서도 바로 호출하도록 설계함

• 예시: Node.js(JavaScript) 환경에서 만들어진 C++ 동적 라이브러리를 바로 import하여 사용할 수 있음
• FFI 표준 바인딩 인터페이스 정의: 함수 시그니처, 매개변수, 반환값 등 설계
• Node.js는 물론 Java, Go, Python 등 원하는 언어에서 라이브러리 직접 로딩 후 추론 실행 가능
• 이 과정을 표준화하여, 다양한 모델 바이너리와의 연동을 손쉽게 구현
• 실제로 JS 코드 몇 줄만 작성하면 input → 임베딩 벡터 결과를 바로 얻을 수 있음

오픈AI 클라이언트 사용 경험과 완벽히 동일한 인터페이스 제공이 가능함

• 최종적으로 오픈AI 공식 Python 클라이언트 스타일: client.embeddings.create(model, input) 인터페이스를 그대로 구현
• 내부적으로는 model 인자를 미리 컴파일된 라이브러리 경로로 매핑하고, 네이티브 라이브러리 load, FFI 호출 등을 자동화함
• 추론 결과 역시 오픈AI 클라이언트 포맷과 똑같은 output dict/JSON 등으로 가공하여 반환
• 즉, 기존 오픈AI 클라이언트에 익숙한 개발자라면 어떤 오픈소스 모델도 별도 수정 없이 바로 활용 가능

이 시스템을 통해 어느 오픈소스 모델이든 손쉽게 Python 함수로 가져와 즉각 실 서비스에 배포 가능해짐

• 단순히 huggingface/open-source 모델만이 대상이 아님
• 내부적으로 개발한 AI 모델/추론 함수도 동일하게 IR→C++→FFI→모듈 매핑 절차를 통해 어디든/어떤 언어든 확장 가능
• 하이브리드/로컬/엣지 등 AI 배포 패러다임의 전환기를 가속화할 수 있는 기술적 토대 마련

Python 코드를 네이티브 바이너리로 변환하는 통합 파이프라인은 검증 및 안전성까지 고려됨

• IR 생성과 타입 분석 과정은 다양한 검증 절차(verification), 자동화된 LLM 파워 테스트 등 안전장치와 함께 작동
• 코드 변환과정에서 발생할 수 있는 예외나 타입 불일치를 철저히 확인함
• 완성된 시스템은 실무 환경에서 필요로 하는 확장성, 신뢰성, 이식성을 균형 있게 확보함

결론적으로, 이 접근법은 AI 인프라 배포의 혁신적 전환을 가능하게 함

• Docker/Python/서버 중심 개발의 한계를 돌파, “원소스 멀티플랫폼-멀티랭귀지” AI 배포 시대를 앞당김
• LLM+컴파일러+FFI 결합으로, AI 모델 소스로부터 실행까지의 거리를 극적으로 단축
• 오픈AI 생태계 수준의 사용편의성을 모든 AI 모델에 확장함으로써, AI 엔지니어의 생산성과 실험 속도를 비약적으로 높일 수 있음