Kefir는 C17과 C23을 겨냥한 비교적 새로운 C 컴파일러다.1 대부분의 개발자에게 "또 하나의 컴파일러"는 반가운 뉴스가 아니다. 중요한 질문은 더 단순하다. 이게 C23을 실험해보는 데 도움이 되는가, 이식성 문제를 더 빨리 드러내는가, 아니면 그냥 오후 한때를 날리게 만드는가.
지금 이 얘기가 중요한 이유는 C23이 이제 공식 표준 단계에 들어왔고, GCC는 이미 지원을 갖추고 있으며 Clang도 일부를 따라오고 있기 때문이다.2 이런 시점에는 "주력 컴파일러가 무엇이냐"보다 "새 표준을 누가 어떻게 구현하느냐"가 더 좋은 판단 기준이 된다. Kefir는 그 시험지로 볼 만하다.
GCC와 Clang이 있는데도 Kefir를 보는 이유
작은 컴파일러의 가치는 대개 성능 경쟁이 아니라 시야를 넓히는 데 있다. 특히 C에서는 오랫동안 GCC/Clang 조합이 사실상의 기준처럼 굳어졌고, 그 결과 코드가 표준 C가 아니라 "GCC/Clang에서 우연히 잘 돌아가는 C"가 되기 쉽다.
이 점은 커뮤니티 경험담과도 맞닿아 있다. 다른 소형 컴파일러를 CI에 넣는 것만으로도 __GNUC__ 가정, __attribute__ 분기, __builtin_* 대체 경로, VLA 관련 숨은 버그가 드러났다는 사례가 있다.3 이건 Kefir가 반드시 같은 버그를 잡는다는 뜻은 아니다. 하지만 독립 구현체 하나를 더 돌려보는 것 자체가, 코드베이스가 특정 거대 컴파일러 습관에 얼마나 기대고 있는지 보여주는 좋은 스트레스 테스트라는 뜻이다.
즉, Kefir를 볼 이유는 "GCC를 대체해서"가 아니다. 표준을 더 곧게 읽는지, 전처리기·진단·호환성에서 다른 시각을 주는지 확인하기 위해서다.
진짜 질문: 장난감인가, 표준 실험실인가, 실무 도구인가
여기서 과장하면 안 된다. 주어진 자료만으로 Kefir를 범용 실무 컴파일러라고 단정하기는 어렵다. 확인 가능한 사실은 C17/C23 지향이라는 점과, 새로운 독립 구현체로 주목받고 있다는 정도다.1 반면 GCC는 1987년부터 축적된 대형 툴체인이고, 수많은 아키텍처와 운영체제, 대규모 코드베이스를 감당해왔다.4 이 격차는 단순히 "나이 차이"가 아니라 진단 품질, 플랫폼 지원, 최적화, 빌드 시스템 호환성의 차이다.
그래서 평가는 감으로 하면 안 된다. 다음 다섯 가지를 보면 된다.
첫째, 표준 커버리지다. C23은 nullptr, bool 같은 익숙한 요소만 추가한 것이 아니다. 0b 이진 리터럴, ' 숫자 구분자, _BitInt, typeof, #elifdef, #warning, __has_include, [[nodiscard]] 같은 속성 문법까지 넓게 바뀌었다.2 "C23 지원"이라는 말은 이 중 어디까지 되는지로 쪼개서 봐야 한다.
둘째, 진단 메시지다. 새로운 컴파일러는 통과/실패보다 실패할 때 얼마나 빨리 이유를 알려주는지가 더 중요하다.
셋째, 빌드 마찰이다. configure, CMake, autotools, 기존 헤더 가정이 얼마나 쉽게 깨지는지 봐야 한다.
넷째, 생성 코드 기대치다. TCC 같은 소형 컴파일러는 빠르고 작지만 최적화 면에서는 주류 컴파일러보다 약한 경우가 많다.5 Kefir도 당장은 "실험과 검증"에 더 가까울 가능성을 염두에 두는 편이 안전하다. 이것은 확인된 사실이라기보다, 신생 컴파일러를 볼 때 가져야 할 현실적 가정이다.
다섯째, 직접 스모크 테스트를 해보는 것이다. 당신 코드베이스에서 헤더 몇 개, 전처리기 분기 몇 개, 경고 정책 몇 개가 바로 흔들리는지 보면 이야기가 빨라진다.
C23에서 Kefir로 먼저 건드려볼 만한 것들
처음부터 C23 전체를 보는 건 비효율적이다. 차라리 "쉽게 검증되고, 컴파일러 차이가 드러나는 것"부터 보는 편이 낫다.
가장 먼저 볼 만한 건 전처리기와 문법 주변이다. #elifdef, #elifndef, #warning, __has_include는 대형 프로젝트의 조건부 컴파일 습관을 바로 건드린다.2 새 표준이 실제 코드에서 어디를 단순화하는지 체감하기 쉽다.
그다음은 표현식과 타입 쪽이다. 0b1010, 1'000'000 같은 리터럴은 눈에 보이는 변화라 테스트가 쉽고, _BitInt(N)나 typeof는 "컴파일은 되는데 타입 체계가 얼마나 안정적인가"를 보기 좋다.2
또 하나는 C/C++ 경계다. C23은 [[deprecated]], [[nodiscard]] 같은 C++식 속성 문법과 bool, nullptr, 빈 중괄호 초기화 같은 요소를 끌어오며 양쪽 문법 간 마찰을 줄이려 한다.2 이런 부분은 라이브러리 헤더나 혼합 코드베이스에서 특히 가치가 있다. 새 컴파일러가 이런 접점을 얼마나 자연스럽게 처리하는지는 꽤 실용적인 평가 포인트다.
틈새 컴파일러를 똑똑하게 쓰는 법: 교체재가 아니라 두 번째 심판
여기서 결론은 의외로 보수적이다. 대부분의 팀은 당분간 GCC나 Clang을 계속 써야 한다. 그 둘은 성숙도, 생태계, 플랫폼, 성능, 디버깅 도구 면에서 비교 대상이 아니다.24
하지만 그래서 Kefir가 덜 중요한 것은 아니다. 오히려 가장 영리한 사용법은 "주력"이 아니라 "보조"다. CI에서 한 번 더 돌려보고, C23 예제를 검증해보고, 표준 문구가 실제 구현에서 어떻게 해석되는지 살펴보는 용도다. 독립 구현체가 많을수록 표준은 특정 진영의 관습에 덜 끌려간다.3
지금 Kefir에 신경 써야 하는 사람은 명확하다. C23을 빨리 체감하고 싶은 개발자, 컴파일러/툴체인에 관심 있는 엔지니어, 그리고 자기 코드가 정말 표준 C에 가까운지 확인하고 싶은 팀이다. 반대로 제품 빌드의 안정성과 최적화가 최우선이라면, 판단 기준은 간단하다. 오늘의 주력은 여전히 GCC/Clang이고, Kefir의 가치는 "대체"보다 "검증"에 있다.
참고
2C23 (C standard revision) - Wikipedia
3Kefir C17/C23 Compiler | Hacker News
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.