
무슨 일이 있었나요?
OCaml이라는 프로그래밍 언어를 혹시 들어보셨나요? 함수형 프로그래밍 언어 중 하나인데, 타입 시스템이 아주 강력해서 컴파일러나 정적 분석 도구를 만들 때 자주 쓰이는 언어예요. Facebook의 Flow(자바스크립트 타입 체커)나 Hack 언어도 OCaml로 만들어졌거든요.
그런데 이 OCaml의 공식 컴파일러인 ocamlc에 C++ 코드 생성 백엔드가 새로 추가되는 PR이 올라왔어요. 이게 뭐냐면, OCaml로 작성한 코드를 기계어로 바로 변환하는 대신 중간에 C++ 코드를 한번 거쳐서 컴파일하는 경로를 추가한다는 뜻이에요.
컴파일러 백엔드가 뭔데요?
컴파일러의 구조를 아주 간단히 설명하면 이래요. 앞단(프론트엔드)에서 소스 코드를 읽고 분석한 다음, 뒷단(백엔드)에서 실제 실행 가능한 코드로 변환해요. 여기서 "백엔드"는 웹 개발의 백엔드가 아니라, 컴파일러 내부에서 최종 출력 코드를 생성하는 부분을 말하는 거예요.
기존 OCaml 컴파일러는 두 가지 백엔드가 있었어요. 하나는 바이트코드를 생성하는 것(인터프리터에서 실행), 다른 하나는 네이티브 코드를 직접 생성하는 것이었죠. 여기에 이번에 C++ 코드를 생성하는 세 번째 백엔드가 추가되는 겁니다.
왜 굳이 C++를 거치나요?
"이미 네이티브 코드를 직접 만들 수 있는데 왜 돌아가지?"라고 생각할 수 있는데요, 여기엔 꽤 실용적인 이유가 있어요.
첫째, 이식성(portability) 문제예요. OCaml의 네이티브 백엔드는 지원하는 CPU 아키텍처가 제한적이에요. 반면 C++ 컴파일러(GCC나 Clang)는 거의 모든 플랫폼을 지원하잖아요? C++ 코드를 중간에 생성하면, 그 뒤는 해당 플랫폼의 C++ 컴파일러가 알아서 처리해주니까 새로운 하드웨어에서도 OCaml 프로그램을 돌릴 수 있게 되는 거예요.
둘째, 최적화의 이점이에요. GCC나 LLVM 같은 C/C++ 컴파일러는 수십 년간 최적화 기술이 쌓여 있거든요. OCaml이 직접 하기 어려운 저수준 최적화를 C++ 컴파일러에 위임할 수 있어요. 비유하자면, 번역을 할 때 직접 번역하는 것과 전문 번역가에게 맡기는 것의 차이라고 할까요.
셋째, C/C++ 라이브러리와의 연동(FFI)이 훨씬 자연스러워져요. OCaml에서 C 라이브러리를 호출할 때 기존에는 복잡한 바인딩 코드를 작성해야 했는데, C++ 백엔드를 쓰면 같은 컴파일 파이프라인 안에서 처리할 수 있게 되거든요.
비슷한 접근을 한 다른 언어들
사실 이 방식은 OCaml만의 독창적인 발상은 아니에요. Haskell의 GHC 컴파일러도 C 코드를 생성하는 백엔드를 오랫동안 유지했었고, Chicken Scheme은 아예 C로의 변환을 핵심 전략으로 삼고 있어요. Nim 언어도 C/C++ 코드를 생성한 뒤 기존 컴파일러로 컴파일하는 방식을 쓰고 있죠.
흥미로운 건 최근 트렌드예요. 많은 언어들이 LLVM IR을 백엔드로 쓰는 방향으로 가고 있는데(Rust, Swift, Zig 등), OCaml은 LLVM 대신 C++라는 더 높은 수준의 중간 언어를 선택했어요. LLVM을 쓰면 LLVM 프로젝트에 대한 의존성이 생기는 반면, C++ 코드 생성은 어떤 C++ 컴파일러든 쓸 수 있다는 장점이 있어요.
한국 개발자에게 어떤 의미가 있을까?
OCaml을 직접 쓰는 한국 개발자는 많지 않을 거예요. 하지만 이 변화에서 배울 수 있는 점은 분명히 있어요.
컴파일러 설계에 관심 있는 분들에게는 "고수준 언어를 다른 고수준 언어로 변환하는 전략(transpilation)"의 현대적 사례를 보여줘요. 요즘 TypeScript → JavaScript, Kotlin → JVM 바이트코드처럼 변환 기반 언어가 대세인데, 그 근본 원리가 같은 맥락이거든요.
또 임베디드나 IoT 관련 일을 하시는 분이라면, OCaml 같은 안전한 함수형 언어를 다양한 하드웨어에서 쓸 수 있게 된다는 점이 반가울 수 있어요. 메모리 안전성이 중요한 시스템 프로그래밍에서 Rust만이 유일한 선택지가 아니게 되는 셈이니까요.
정리하자면
OCaml 컴파일러에 C++ 백엔드가 추가되면서, 더 많은 플랫폼 지원과 최적화 이점을 동시에 얻게 되었어요. 언어 생태계를 확장하는 전략으로 "이미 잘 만들어진 도구 위에 올라타기"를 선택한 셈이죠.
여러분은 새로운 프로그래밍 언어가 기존 컴파일러 인프라를 활용하는 전략에 대해 어떻게 생각하시나요? 직접 네이티브 코드를 생성하는 것과 비교해서 어떤 트레이드오프가 있을지 이야기해봐요.
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공