Kefir 컴파일러: 한 사람이 만든 C17/C23 컴파일러 이야기

한 개발자가 밑바닥부터 만든 C 컴파일러

C 언어 컴파일러 하면 보통 GCC나 Clang을 떠올리죠. 이 둘은 수백 명의 엔지니어가 수십 년 동안 만들어온 거대한 프로젝트예요. 그런데 최근에 Kefir라는 흥미로운 컴파일러가 주목받고 있어요. Jevgenij Protopopov라는 개발자 한 명이 밑바닥부터 만들고 있는 C17/C23 표준 컴파일러거든요.

왜 이런 프로젝트가 의미 있냐면, 요즘 C 컴파일러 생태계는 사실상 GCC와 Clang 양강 체제예요. 이 둘은 너무 거대해져서 새로 진입하기도 어렵고, 특정 구현에 종속되면 언어 표준 자체가 흔들릴 위험도 있어요. 그래서 독립적인 구현이 여럿 존재하는 게 C 언어 생태계의 건강성에 중요해요. Kefir는 그런 대안 중 하나로 자리잡으려는 시도예요.

C23까지 지원한다는 게 뭘 뜻하나

C 언어는 의외로 계속 진화하고 있어요. C99, C11, C17을 거쳐 가장 최근 표준이 C23인데요, C23에는 nullptr 키워드, constexpr, 이진 리터럴(0b1010), 개선된 열거형, #embed 디렉티브처럼 현대적인 기능들이 많이 추가됐어요. 이게 뭐냐면, C++에서만 쓸 수 있던 편리한 기능들이 C에도 하나씩 들어오고 있다는 거예요.

문제는 이런 새 기능들을 컴파일러가 따라잡는 데 시간이 걸린다는 점이에요. GCC나 Clang도 C23 기능을 단계적으로 추가하고 있거든요. Kefir가 C17 표준을 완전 지원하면서 C23 기능도 적극적으로 구현하고 있다는 건, 작은 프로젝트치고는 상당히 야심찬 목표예요.

아키텍처 측면에서 재밌는 점

Kefir의 구조를 보면 배울 점이 많아요. 프런트엔드(파서, 타입 체커)와 백엔드(코드 생성)를 명확히 분리한 설계를 채택했고, 중간 표현(IR, Intermediate Representation)을 자체적으로 정의해서 쓰고 있어요. IR이 뭐냐면, 소스 코드와 기계어 사이의 중간 단계 언어예요. 이걸 잘 만들면 최적화하기도 쉽고, 여러 타겟 아키텍처를 지원하기도 편해져요.

지금은 주로 x86_64 리눅스를 타겟으로 하고 있고, AMD64 System V ABI를 지원해요. ABI(Application Binary Interface)라는 건 컴파일된 바이너리들이 서로 어떻게 호출 규약을 맞추는지 정한 규격이에요. 이걸 정확히 지켜야 Kefir로 컴파일한 코드가 glibc 같은 시스템 라이브러리와 제대로 링크될 수 있거든요.

또 하나 흥미로운 선택은 Kefir 자체가 C로 작성됐다는 점이에요. 셀프 호스팅 가능성을 염두에 둔 설계인데, 컴파일러가 자기 자신을 컴파일할 수 있다는 건 언어 구현의 성숙도를 보여주는 중요한 지표예요.

비슷한 대안 컴파일러들

사실 GCC/Clang 말고도 C 컴파일러는 꽤 있어요. TCC(Tiny C Compiler)는 매우 빠른 컴파일 속도로 유명하지만 최적화는 거의 안 해요. cproc은 QBE 백엔드를 쓰는 현대적인 C11 컴파일러고요. chibicc는 교육용으로 유명한데 한 단계씩 커밋이 나뉘어 있어서 컴파일러 공부하기 좋아요. Plan 9의 계열을 잇는 8c, 9c 같은 것도 있고요.

이런 프로젝트들 사이에서 Kefir의 포지션은 "실용성 있는 표준 준수형 컴파일러"예요. TCC처럼 엄청 빠르진 않지만 제대로 된 표준 지원을 목표로 하고, cproc처럼 외부 백엔드에 의존하지 않고 자체 IR과 코드 생성기를 가지고 있어요. 아직 최적화 수준은 GCC/Clang에 한참 못 미치지만, "표준에 맞는 정직한 컴파일러"라는 방향성이 분명해요.

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

실무에서 Kefir를 당장 프로덕션에 쓸 일은 없을 거예요. 하지만 컴파일러를 공부하고 싶은 분들에게는 정말 좋은 학습 자료예요. 코드베이스가 한 사람의 손을 거쳐 만들어져서 일관성이 있고, GCC처럼 수십 년 된 레거시가 얽혀있지 않거든요. 파서부터 코드 생성까지 전 과정을 따라가볼 수 있는 규모예요.

또 임베디드나 보안 분야에서 일하시는 분들이라면 대안 컴파일러의 존재 자체가 의미 있어요. 같은 C 코드를 여러 컴파일러로 돌려보면서 동작이 일치하는지 확인하면, 특정 컴파일러의 버그나 비표준 동작에 의존하고 있지 않은지 검증할 수 있거든요. 이런 걸 "컴파일러 차이 퍼징"이라고 부르는데, 보안 감사에서 꽤 유용하게 쓰여요.

그리고 개인적으로는, 이런 "혼자서 거대한 걸 만드는" 프로젝트를 볼 때마다 영감을 받아요. 요즘은 뭐든 팀으로 하고 프레임워크 위에서 하는 게 당연시되는데, 한 명이 수년간 컴파일러를 만들어내는 걸 보면 개인의 집중력과 지속성이 얼마나 강력한지 다시 생각하게 되거든요.

마무리

Kefir는 당장 쓰는 도구는 아니지만, C 언어 생태계의 다양성을 지탱해주는 소중한 프로젝트예요. 여러분은 기존의 거대 오픈소스 말고 이런 1인 프로젝트를 후원하거나 기여해본 경험이 있으신가요? 컴파일러 같은 기반 기술 분야에서 개인 프로젝트가 가진 가능성에 대해 어떻게 생각하시는지 궁금해요.