18 컴파일러의 지형 — 현역 C 컴파일러들

18.1 세상의 큰 셋 — GCC, Clang/LLVM, MSVC

오늘날 데스크톱과 서버 C의 대부분은 이 셋 위에서 돈다.

GCC(GNU Compiler Collection). 1987년부터 이어져 온 자유 소프트웨어 컴파일러이고, 리눅스 세계의 기본값이다. 겨냥할 수 있는 CPU의 수가 압도적 으로 많다는 것이 가장 큰 강점이다 — x86·Arm·RISC-V는 물론이고 AVR, MSP430, SuperH, PowerPC 같은 임베디드 칩까지 하나의 계보로 덮는다. 임베디드 벤더들이 자기 도구의 속을 gcc로 채우는 일이 흔한 이유다(97장).

Clang/LLVM. 2000년대에 나온 후발 주자로, 컴파일러를 부품으로 쓸 수 있게 설계한 LLVM 기반이다. 진단 메시지가 친절하다는 평판으로 자리를 잡았고, 오늘날에는 그 부품성 덕에 생태계 전체가 그 위에 섰다 — 정적 분석기 (clang-tidy), 서식 도구(clang-format), 편집기의 자동완성 서버(clangd), 그리고 여러 벤더의 새 컴파일러가 전부 LLVM에서 갈라져 나왔다. macOS의 기본 컴파일러이기도 하다.

MSVC(Microsoft Visual C++). 윈도우의 표준 도구다. 이름은 C++이지만 C도 컴파일하며, 오랫동안 C99조차 미완이라는 평을 들었으나 근래에는 C11·C17을 지원하고 C23으로 나아가는 중이다. 윈도우 API와 가장 잘 맞물린다는 것이 존재 이유다.

18.2 성능을 파는 컴파일러들 — 벤더 컴파일러

같은 소스라도 자기 회사 CPU에서 더 빨리 돌게 만들어 주는 것을 파는 컴파일러 들이 있다. 대형 계산(HPC)과 서버 쪽에서 주로 만난다.

표를 관통하는 흐름이 하나 보인다 — 다들 LLVM으로 모였다. 자기만의 컴파일러를 처음부터 유지하는 비용이 너무 커서, 앞단(문법 해석)과 최적화의 공통부는 LLVM에서 가져오고 자기 칩에 맞는 뒷단만 붙이는 방식이 표준이 됐다. 인텔의 고전 icc가 물러나고 LLVM 기반 icx가 그 자리를 이은 것이 이 흐름의 가장 상징적인 장면이다.

18.3 임베디드 — 다음 장의 입구

세상의 C 컴파일러 중 수적으로 가장 많은 갈래는 임베디드 쪽이다. 칩을 만드는 회사마다 자기 컴파일러가 있고, 안전 인증(자동차·항공·의료)이 걸린 자리에는 그 인증을 함께 파는 전문 회사들이 있다. IAR, Arm의 Keil 계열, TI, 마이크로칩, 르네사스, 그린힐스, 윈드리버 — 그리고 8비트 칩을 위한 자유 소프트웨어 SDCC 까지. 이 지형은 도구 전체(디버그 프로브, 온칩 디버깅, 정적 분석)와 함께 보아야 뜻이 서므로 다음 장에서 따로 다룬다.

18.4 곁다리 하나 — 윈도우의 단정한 대안, Pelles C

지금까지의 이름들이 “많이 쓰이는 것”이었다면, 이 절은 조금 다르다. 시장 점유로 보면 큰 자리를 차지하지 않지만 성격이 뚜렷해서 소개할 만한 도구다.

Pelles C는 스웨덴의 펠레 오를린드(Pelle Orinius)가 혼자 이어 온 윈도우 전용 프리웨어다. 편집기·컴파일러·어셈블러·링커·자원 편집기·디버거·설치 파일 생성기까지 한 묶음으로 들어 있고, 다운로드 하나로 끝난다. 이름은 만든 사람의 이름에서 왔다.

주목할 점은 표준 지원이 성실하다는 것이다. 이 책을 쓰는 시점의 최신판 (14.50, 2026년 7월)이 C99·C11·C17·C23을 지원한다고 밝히고 있다. 규모가 훨씬 큰 도구들보다 새 표준을 빨리 따라간 시기도 있었다.

혈통도 재미있다. Pelles C는 맨땅에서 나온 것이 아니라 LCC(프레이저와 핸슨이 만든 작고 이식성 높은 교육용 C 컴파일러)를 크게 손본 물건이다. 위키백과에도 독립 문서가 아니라 「LCC (compiler)」 항목의 한 절로 실려 있고, 거기서 “C11·C17·C23 지원, amd64 지원, 인라인 전개 같은 최적화, 그리고 IDE를 더한 LCC의 대폭 개작판”이라고 설명한다. 자료를 찾을 때 이 사실을 알아 두면 헛수고를 던다 — “Pelles C” 위키백과 문서를 찾으면 나오지 않는다.

받는 곳은 공식 홈페이지 pellesc.se이고, 질문과 배포 소식은 별도의 포럼(forum.pellesc.de)에 모인다. 만든 사람이 그 포럼에서 직접 답하는 것이 이 도구의 오래된 풍경이다.

사용자들의 평가를 모으면 대체로 이렇게 갈린다.

18.4.1 윈도 앱을 C로 짠다는 선택

이 도구의 자리를 하나 더 짚어 둘 만하다. 윈도 API(Win32)로 데스크톱 앱을 짤 때 특히 잘 맞는다 — 자원 편집기와 링커가 한 묶음이고, 만들어지는 것이 런타임 의존성 없는 실행 파일 하나이기 때문이다.

「지금 시대에 왜 C로 윈도 앱을 짜는가」라는 물음이 자연스럽다. 근거를 과장 없이 적으면 이렇다.

18.4.2 한 묶음에 들어 있는 것 — 자원 편집기와 대화 상자 디자이너

이 도구가 Win32 개발에 잘 맞는 진짜 이유는 편집기들에 있다. 공식 사이트가 밝히는 구성은 이렇다.

여기서 대화 상자 편집기가 이른바 GUI 디자이너다. 창에 버튼과 입력란을 끌어다 놓고 배치를 정하면 .rc 자원 스크립트로 저장되고, 자원 컴파일러가 그것을 실행 파일 안에 넣는다. 코드에서는 DialogBox나 CreateDialog로 그 대화 상자를 띄우고, 컨트롤은 번호(ID)로 찾는다 — Win32의 오래된 작업 방식 그대로다.

마이크로소프트가 새 앱에 권하는 것은 Win32가 아니라 최신 스택(Windows App SDK·WinUI 3)이다 — 이 점은 분명히 해 두자. 다만 윈도의 UI 스택은 MFC → WinForms → WPF → UWP → WinUI로 여러 번 갈아엎혔고, 그때마다 앞 세대는 「유지는 되지만 새로 권하지는 않는」 자리로 밀렸다. 그 소용돌이 밖에서 변하지 않은 것이 Win32이고, 오래 쓸 작은 도구라면 그 안정성이 곧 이득이다.

한 가지가 더 달라졌다. 위 표의 「코드가 길다」는 대가가 예전만큼 무겁지 않다 — 정형화된 준비 코드는 지금 AI가 잘 만들어 내는 종류의 코드이기 때문이다. 창을 만들고 메시지 루프를 도는 껍데기는 어디서나 같은 모양이고, 사람이 손으로 외워 적을 이유가 줄었다. 다만 이 책의 태도는 여기서도 같다 — 받아 온 코드도 읽을 줄 알아야 고칠 수 있다. 껍데기를 남이 써 주더라도, 그 안에서 도는 것이 무엇인지(메시지 루프, 핸들, 자원의 수명)는 결국 알아야 한다.

정리하면 이렇다 — 윈도우에서 순수 C만, 가볍게 다루고 싶을 때 잘 맞는 도구다. 학습용으로, 작은 윈도우 유틸리티용으로, 그리고 “새 표준 문법이 실제로 되는지” 시험해 보는 용도로 쓰기 좋다. 반대로 여러 플랫폼으로 옮길 코드나, CMake 같은 빌드 도구와 CI에 얹을 프로젝트라면 앞의 큰 셋 쪽이 맞는다.

18.5 그 밖에, 그리고 은퇴한 이름들

작지만 살아 있는 것 — tcc(Tiny C Compiler)는 몇백 KiB짜리 초소형 컴파일러로, C 소스를 즉석에서 컴파일해 바로 실행하는 용도로 여전히 쓰인다. cproc·chibicc 같은 작은 컴파일러들은 “컴파일러를 배우는 교재”로서 값이 있다. 실무의 주력은 아니다.

이름은 유명하지만 이제 현역이 아닌 것 — 오래된 교재나 인터넷 글에서 이 이름들을 만나면 시대를 감안해 읽어야 한다.

특히 Dev-C++ 과 TDM-GCC 조합은 한국의 학교와 학원에서 오래 쓰여 지금도 자료가 많이 남아 있다. 문제는 그 조합이 물고 있는 컴파일러가 몇 판 뒤처져 있다는 것이다 — C11 이후의 문법이나 C23의 낱말(78장)이 통하지 않는 일이 흔하다. 지금 시작한다면 17장의 두 갈래(LLVM clang 또는 MSYS2 의 gcc)를 권한다. 옛 교재를 따라가다 “이 문법이 왜 안 되지?”라고 만나는 벽의 상당수가 도구의 나이 때문이다.

18.6 공식 자료가 있는 곳

컴파일러 이야기는 판과 옵션에 매여 있어서, 1차 자료를 직접 여는 습관이 특히 값지다. 이 책을 쓰는 시점에 살아 있는 주소를 모아 둔다(도메인만 적는다 — 경로는 바뀌어도 도메인은 오래간다).

세 가지만 덧붙인다. 첫째, 옵션의 정확한 뜻은 그 컴파일러의 매뉴얼에만 있다 — 17장에서 켜 둔 경고들이 무엇을 잡는지도 거기 적혀 있다. 둘째, 릴리스 노트가 「이번 판에서 어느 표준 기능이 들어왔는가」를 알려 준다 — C23 기능의 지원 현황을 확인하는 가장 빠른 길이다. 셋째, 위키백과는 역사와 계보를 훑기에 좋고, 정확한 동작의 근거로는 공식 문서를 쓴다.

마지막으로, 학습자에게 한마디. 이 장에 나온 현역 컴파일러 중 무엇으로 공부해도 상관없다. 이 책의 예제는 표준 C만 쓰므로 gcc·clang·MSVC·Pelles C 어디서든 같은 결과가 나온다. 손에 익은 것, 설치가 편한 것, 학교나 회사가 쓰는 것 — 아무 기준으로 골라도 배우는 내용은 달라지지 않는다.

다만 하나는 권하지 않는다. Dev-C++ 은 설치가 간편해 지금도 널리 쓰이지만, 물고 있는 컴파일러가 너무 오래됐다. C11 이후의 문법이나 C23의 낱말이 통하지 않아, “책대로 썼는데 왜 안 되지?”라는 벽을 만들기 쉽다. 같은 이유로 옛 교재의 Turbo C 화면도 따라 하지 않는 편이 좋다. 설치의 간편함이라면 17장의 두 갈래(LLVM clang 한 줄 설치, 또는 MSYS2 의 gcc)도 충분히 간편하고, 그쪽은 최신 표준과 검사 도구가 함께 온다.

컴파일러의 지형을 폈다. 이 지형의 가장 넓은 구역 — 임베디드의 컴파일러들과 그 곁의 연장들 — 은 도구 전체를 함께 보아야 뜻이 서므로 책의 끝에서 한 장을 따로 들여 다룬다(97장).

제3부가 끝났다. 첫 프로그램을 읽었고(15장), 그것이 실행 파일이 되는 릴레이를 보았고(16장), 도구를 갖췄고(17장), 세상의 컴파일러 지형을 폈다(18장). 다음 부부터 본격적인 언어 공부다 — 새 문법을 나열하는 것이 아니라, 15장의 헬로 월드 한 편을 완전히 읽어 내는 것이 제4부의 목표다.