Kefir C 컴파일러, 공개 개발 중단 — 1인 오픈소스의 한계와 가능성

한 사람이 만든 C 컴파일러가 멈췄다

프로그래밍 언어 세계에서 컴파일러는 가장 어렵고 묵직한 분야 중 하나예요. GCC, Clang/LLVM, MSVC 같은 거대 컴파일러들은 수백 명의 개발자가 수십 년에 걸쳐 만들어낸 결과물이거든요. 그런데 이 무거운 영역에 혼자 도전한 사람이 있었어요. 라트비아의 개발자 Jevgenijs Protopopovs가 만든 Kefir라는 C 컴파일러예요.

Kefir는 C17과 C23 표준을 거의 완벽하게 지원하는 컴파일러로 주목받았어요. 그것도 1인 프로젝트로 말이죠. C23은 2024년에 공식 발표된 최신 C 표준인데, 이걸 지원하는 컴파일러는 GCC, Clang 정도밖에 없거든요. 거기에 한 사람이 만든 Kefir가 이름을 올렸다는 게 놀라운 일이었어요. 그런데 최근 저자가 공개 개발을 중단한다는 공지를 올렸어요. 이게 단순한 "프로젝트 종료" 소식이 아니라, 오픈소스 생태계의 구조적인 문제를 다시 한번 드러내는 사건이라 살펴볼 가치가 있어요.

Kefir는 어떤 컴파일러였나

간단히 설명하면 Kefir는 C 소스 코드를 받아서 x86_64 어셈블리(요즘 PC와 서버에서 쓰는 CPU의 기계어에 가까운 언어)로 바꿔주는 컴파일러예요. GCC나 Clang의 경량 대안을 목표로 만들어졌고, 외부 의존성을 최소화하고 자기 자신만으로 빌드되도록 설계됐어요(self-hosting).

기술적으로 인상적인 부분이 몇 가지 있어요. 우선 표준 준수도예요. C 언어는 표준이 굉장히 복잡해서, 사소한 코너 케이스(드물지만 표준에 명시된 특이 케이스)까지 완벽하게 지원하는 컴파일러를 만드는 게 정말 어려워요. Kefir는 C17과 C23의 까다로운 기능들, 예를 들어 _BitInt(임의 비트 폭의 정수 타입), 어트리뷰트 문법, constexpr 같은 것들을 잘 다뤘어요.

또 자체 IR(중간 표현, Intermediate Representation)을 가진다는 점도 흥미로워요. 컴파일러는 보통 소스 코드를 바로 기계어로 바꾸지 않고, 중간 형태로 한 번 변환한 다음에 최적화하고 기계어로 떨어뜨려요. LLVM이 LLVM IR을 갖는 것처럼요. Kefir도 자기만의 IR을 설계해서 거기서 최적화를 수행했어요. 이게 작은 프로젝트에서는 정말 만만치 않은 일이거든요.

왜 멈췄을까

저자의 공지를 읽어보면 이유가 무겁고 현실적이에요. 핵심은 "혼자서 감당할 수 없는 규모가 됐다"는 거예요. 처음에는 취미로 시작했지만, C23 같은 최신 표준을 따라가고, 다양한 플랫폼을 지원하고, 사용자가 보고하는 이슈를 다 처리하는 일이 한 사람의 여가 시간으로는 도저히 안 되는 수준이 된 거예요.

특히 컴파일러는 "올바름"의 기준이 굉장히 높아요. 일반 앱은 사소한 버그가 있어도 사용자가 워크어라운드를 찾을 수 있지만, 컴파일러가 코드를 잘못 번역하면 그 위에 올라간 모든 소프트웨어가 잘못된 동작을 해요. 그래서 컴파일러 개발자는 일반 개발자보다 훨씬 더 신중하고, 테스트를 더 많이 짜고, 문서를 더 꼼꼼히 봐야 해요. 그 부담이 1인 개발자에게 얼마나 무거울지 짐작이 가시죠.

저자는 "공개 개발"을 멈춘다고 했지, 코드를 지우거나 프로젝트 자체를 끝낸다고 하진 않았어요. 즉, 더 이상 새로운 기능을 적극적으로 추가하거나, 외부의 이슈와 PR에 응답하지 않겠다는 의미예요. 이건 정말 솔직한 결정이에요. 많은 1인 오픈소스 프로젝트가 사용자 요청에 시달리다가 메인테이너가 번아웃되고 결국 조용히 사라지는 경우가 많거든요. 그것보다는 "공개적으로 손을 뗀다"고 명확히 알리는 게 모두에게 덜 고통스러운 길이에요.

업계 맥락에서 보면

C 컴파일러 생태계는 의외로 다양해요. GCC와 Clang 외에도 tcc(Tiny C Compiler, 빠른 컴파일 속도가 강점), chibicc(교육용으로 만든 소형 C 컴파일러), cproc, lacc 같은 프로젝트들이 있어요. Kefir는 이 중에서도 "진지하게 표준을 따르는 1인 컴파일러"라는 독특한 자리에 있었어요.

이번 일은 오픈소스 지속가능성이라는 더 큰 이슈와 연결돼요. 우리가 매일 쓰는 인프라급 오픈소스들, 예를 들어 OpenSSL이나 curl, log4j 같은 것들도 결국 소수의 메인테이너가 무급으로 떠받치고 있어요. log4j 사건이나 xz 백도어 사건처럼, 1~2명의 메인테이너에게 의존하는 구조는 보안적으로도 위험해요. 기업들이 이런 프로젝트를 사용하면서 정작 후원은 거의 하지 않는 게 현실이고요.

Kefir의 경우는 "인프라급"까지는 아니지만, 그래도 한 개인이 거대 기업들의 영역에 도전했다가 한계를 인정한 사례라 의미가 있어요.

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

첫째, 컴파일러나 언어 런타임처럼 임팩트가 큰 영역도 1인 개발자가 의미 있는 기여를 할 수 있다는 걸 보여줘요. 한국에선 "컴파일러는 박사급 연구실의 영역"이라는 인식이 강한데, Kefir 같은 사례는 그 벽이 생각보다 낮을 수도 있다는 신호예요. 물론 쉽지 않지만, 시도해볼 가치가 있어요.

둘째, 오픈소스를 쓸 때 "누가 만들고 있는지"를 보세요. 메인테이너가 한 명뿐이고 후원 구조가 약한 프로젝트를 회사 핵심 인프라에 쓰는 건 위험해요. 적어도 그 프로젝트가 멈췄을 때 대안이 뭐가 있는지, 우리가 직접 포크해서 유지보수할 수 있을지 정도는 미리 생각해두는 게 좋아요.

셋째, "중단"이라는 결정도 존중받아야 한다는 문화가 필요해요. 무급 메인테이너에게 "왜 안 고쳐주냐"고 따지는 건 정말 미안한 일이에요. Kefir 저자처럼 명확하게 "여기까지"라고 선을 긋는 결정은 비난받을 게 아니라 박수받을 일이에요.

마무리

한 사람의 열정으로 시작된 프로젝트가 한 사람의 한계로 멈추는 건, 실패가 아니라 정직함이에요.

Kefir 같은 1인 프로젝트가 지속 가능하려면 무엇이 필요할까요? 기업의 후원, 정부 펀딩, 아니면 커뮤니티 기반의 분산 메인테이너십? 여러분이 생각하는 답이 궁금해요.