C 언어의 "확장 기능"이 왜 이식성 지옥을 만드는지 들여다봐요

C 언어, 표준이 있는데 왜 컴파일러마다 다를까요?

C 언어를 배우다 보면 이상한 경험을 하게 돼요. 분명 같은 C 코드인데 GCC에서는 잘 컴파일되던 게 Clang에서는 경고가 뜨고, MSVC(마이크로소프트 컴파일러)에서는 아예 안 돌아가는 경우가 있거든요. 처음엔 "내가 뭘 잘못 쓴 건가?" 싶지만, 사실 이건 여러분 잘못이 아니에요. C 표준(C89, C99, C11, C17, C23)이 정의하지 않은 영역에서 각 컴파일러가 자기만의 확장 기능(extension) 을 추가하기 때문이에요.

lemon.rip이라는 블로그에서 이 주제를 자세히 다룬 글이 올라왔는데요, C 확장 기능과 이식성, 그리고 대안 컴파일러가 핵심이에요. 메인스트림이 GCC와 Clang에 너무 쏠려 있는 지금, 작지만 흥미로운 컴파일러들이 어떤 역할을 하는지를 짚어주는 글이에요.

컴파일러 확장 기능이 뭐냐면요

예를 들어볼게요. GCC에는 __attribute__((packed))라는 게 있어요. 구조체의 멤버 사이에 패딩을 넣지 말라는 지시인데요, 이게 표준 C에는 없어요. GCC가 자체적으로 추가한 기능이거든요. MSVC에서는 같은 일을 하려면 #pragma pack(1)을 써야 해요. 문법이 완전히 달라요. 또 GCC의 nested function(함수 안에 함수 정의), statement expressions(({ ... }) 형태의 표현식), typeof 연산자 같은 것들도 다 표준 밖의 GCC 확장이에요.

이게 왜 문제냐면, 한번 GCC 확장에 의존하기 시작하면 다른 컴파일러로 옮기는 게 거의 불가능해진다는 거예요. 리눅스 커널이 GCC에 강하게 묶여 있던 이유 중 하나가 바로 이거였어요. 최근에는 Clang으로도 빌드되도록 많은 작업이 들어갔지만, 그 과정에서 수많은 GCC-isms를 제거하거나 추상화해야 했죠.

대안 컴파일러들의 세계

이 글이 흥미로운 또 다른 이유는 GCC와 Clang 외에도 C 컴파일러가 많다는 걸 알려준다는 점이에요. 대부분의 개발자는 "C 컴파일러 = GCC 또는 Clang"이라고 생각하잖아요. 그런데 사실 이건 빙산의 일각이에요.

TCC (Tiny C Compiler) 라는 게 있어요. 이게 뭐냐면, 페이브 벨라드(QEMU 만든 그 사람)가 만든 초경량 C 컴파일러예요. 너무 가벼워서 C 코드를 스크립트처럼 즉석에서 실행할 수도 있어요. tcc -run hello.c 한 줄로 컴파일과 실행을 동시에 하는 거죠. 다만 최적화는 거의 안 해요. chibicc는 교육용으로 만들어진 C 컴파일러인데, 코드가 굉장히 읽기 쉬워서 컴파일러 공부할 때 많이 추천돼요. cproc, lacc, 8cc 같은 작은 컴파일러들도 각자의 철학으로 만들어지고 있고요.

그리고 임베디드 쪽으로 가면 IAR, Keil, SDCC 같은 상용/특수 목적 컴파일러들이 또 따로 있어요. 자동차 ECU나 마이크로컨트롤러 펌웨어를 짤 때 이런 컴파일러들을 쓰는데, 이들은 GCC 확장을 지원하지 않는 경우가 많아서 코드를 정말 "표준 C"로 짜야 해요.

이식성을 지키려면 어떻게 해야 할까요

글에서 강조하는 핵심 메시지는 이거예요. "GCC만 쓰고 있다고 해서 그 코드가 C 언어로 쓰여 있다고 착각하지 마라." 사실 우리가 쓰는 건 "GCC 방언의 C"인 경우가 많거든요.

이식성 있는 C 코드를 쓰려면 몇 가지 습관이 필요해요. 첫째, 컴파일할 때 -std=c99 같은 표준 플래그를 명시하고, -pedantic을 함께 켜두면 표준에서 벗어난 코드에 경고가 떠요. 둘째, 여러 컴파일러로 빌드를 돌려보는 것이 가장 확실해요. CI에 GCC, Clang을 모두 넣어두고, 가능하면 MSVC나 TCC까지 추가하면 이식성 문제를 일찍 발견할 수 있어요. 셋째, 확장 기능을 꼭 써야 한다면 매크로로 감싸세요. #ifdef __GNUC__ 식으로 분기를 만들어 두면 나중에 다른 컴파일러를 지원할 때 한 곳만 고치면 돼요.

업계 흐름에서의 의미

요즘은 Rust, Zig 같은 새로운 시스템 언어들이 "C의 자리를 노린다"는 이야기가 많죠. 그런데 C는 여전히 단단해요. 운영체제 커널, 데이터베이스 엔진, 임베디드 펌웨어, 언어 런타임 같은 인프라 코드의 상당수가 C로 쓰여 있고, 앞으로도 한동안 그럴 거예요. 그래서 "C를 어떻게 더 안전하고 이식성 있게 쓸 것인가"는 여전히 중요한 질문이에요.

특히 Zig가 C 컴파일러 역할도 한다는 점이 재밌어요. zig cc 명령을 쓰면 Zig 툴체인이 Clang을 감싸서 C를 컴파일해주는데, 크로스 컴파일이 정말 쉬워져요. 윈도우에서 리눅스용 바이너리를 한 줄로 뽑아낼 수 있거든요. C의 이식성 문제를 다른 각도에서 풀어주는 흥미로운 시도예요.

한국 개발자에게는요

실무에서 C를 직접 쓰는 분은 점점 줄고 있긴 해요. 하지만 펌웨어, IoT, 시스템 프로그래밍, 게임 엔진 쪽에서는 여전히 핵심이에요. 그리고 의외로 파이썬, Node.js, Ruby 같은 고수준 언어의 네이티브 확장을 만들 때 C를 만나게 되는 경우가 많아요. 이때 컴파일러 차이로 빌드가 깨지는 경험을 한 번쯤 해보셨을 거예요. 특히 macOS(Clang), 리눅스(GCC), 윈도우(MSVC)를 모두 지원해야 할 때요.

오픈소스 라이브러리 만드시는 분이라면 이 글이 진짜 도움이 될 거예요. "내 라이브러리가 GCC에만 돌아간다"는 건 사용자 풀의 상당 부분을 포기하는 거니까요.

마무리

C 언어의 "표준"과 실제 우리가 쓰는 C 사이에는 생각보다 큰 간극이 있어요. 그 간극을 메우는 게 컴파일러 확장이고, 동시에 이식성을 망치는 주범이기도 해요. 여러분은 본인 코드가 얼마나 "표준 C"인지 점검해본 적 있으세요? 다른 컴파일러로 빌드해본 게 마지막으로 언제였는지 한번 떠올려보면 재밌을 거예요.