이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며#

C 언어는 1972년 탄생 이래 50년 넘게 시스템 프로그래밍의 근간이었습니다. Linux 커널, Windows, macOS, PostgreSQL, Python 런타임, nginx — 우리가 매일 쓰는 소프트웨어의 토대 상당 부분이 C로 작성되어 있습니다.

그러나 최근 몇 년간 C 언어의 입지에 큰 변화가 일어나고 있습니다. 메모리 안전성 문제를 둘러싼 논쟁이 격화되고, 미국 정부 기관이 공식적으로 C 사용을 자제하라고 권고하며, Rust를 비롯한 대안 언어들이 빠르게 성장하고 있습니다. 여기에 2024년부터 본격화된 AI 코딩 에이전트(Claude Code, Codex, Gemini CLI 등) 의 등장은 이 흐름을 더욱 가속하고 있습니다.

이 글은 2파트로 구성됩니다:

  • Part 1 (이 글): AI 이전의 C 언어 위상 변화, C23 표준, 대안 언어들
  • Part 2: AI 에이전트가 C 개발에 미치는 영향, 도메인별 현황, 개발자 생태계, 전망

1. 메모리 안전성 논쟁: “70% 규칙”#

C 언어의 위상이 흔들리기 시작한 핵심 원인은 메모리 안전성(Memory Safety) 문제입니다. 버퍼 오버플로, use-after-free, 댕글링 포인터 같은 메모리 관련 버그는 C/C++ 코드베이스에서 가장 흔한 보안 취약점의 원인입니다.

얼마나 심각할까요? 주요 기업과 프로젝트의 통계를 보면 놀라울 정도로 일관된 패턴이 나타납니다:

프로젝트/조직 메모리 안전 관련 취약점 비율 출처
Microsoft (Windows 등) ~70% (고위험 CVE 기준) MSRC, 2019 (12년간 일관)
Google Chrome ~70% (심각한 보안 버그 기준) Chromium 프로젝트
Android 76% (2019년) → 24% (2024년) Google Security Blog
Google Project Zero (제로데이) ~67% (2021년 기준) Project Zero 보고서

Microsoft는 2019년 MSRC 블로그에서 이렇게 밝혔습니다: “매년 CVE를 부여하는 보안 취약점의 약 70%가 메모리 안전 이슈이며, 이 비율은 최소 12년간 일관적으로 유지되고 있다.” 그리고 같은 해 “We Need a Safer Systems Programming Language"라는 제목의 글을 게시하며 Rust를 대안으로 명시적으로 언급했습니다.

이 “70% 규칙"은 C/C++ 코드베이스의 구조적 문제를 가리킵니다. 아무리 뛰어난 개발자라도 수만~수백만 줄의 C 코드에서 메모리 버그를 완전히 방지하기란 사실상 불가능합니다. 이것은 개발자의 역량 문제가 아니라 언어 설계의 근본적 한계 에 가깝습니다.

2. 주요 마이그레이션 사례: 누가, 왜 C를 떠나고 있는가#

Linux 커널: 가장 큰 C 코드베이스의 변화#

약 3,400만 줄의 C 코드로 이루어진 Linux 커널은 세계 최대의 C 프로젝트입니다. 이 커널이 Rust를 수용하기 시작했다는 것은 상징적인 의미가 큽니다.

  • 2022년 10월: Linux 6.1에 Rust 인프라가 최초로 머지됩니다. 약 12,500줄의 기본 인프라 코드였습니다.
  • 2023년 12월: Linux 6.8에 Rust로 작성된 최초의 드라이버가 수용됩니다.
  • 2024년 8월: Linus Torvalds는 Rust 도입 속도가 기대보다 느리다고 언급하면서도, “old-time kernel developers are used to C and don’t know Rust"라며 변화의 불가피성을 인정합니다.
  • 2025년 12월: 커널 메인테이너 서밋에서 “the experiment is done, Rust is here to stay"라는 선언이 나옵니다. Rust는 Linux 커널의 영구적인 공식 언어로 자리 잡았습니다.

그러나 이 과정이 순탄하지만은 않았습니다. 2024년 9월, Rust for Linux의 핵심 메인테이너 Wedson Almeida Filho가 “비기술적 문제(nontechnical nonsense)” 에 대한 좌절감으로 사임했고, 2025년 2월에는 커널 메인테이너 Christoph Hellwig가 Rust 바인딩 추가를 거부하며 다중 언어 코드베이스를 “cancer"에 비유하는 논란이 있었습니다. 50년간 C만 써온 거대한 커뮤니티에서의 변화는 기술적 문제만큼이나 문화적 저항도 크다 는 것을 보여주는 사례입니다.

Google Android: 가장 명확한 성과#

Google의 Android 프로젝트는 C에서 Rust로의 전환이 가져오는 실증적 성과 를 가장 명확하게 보여줍니다.

  • 메모리 안전 취약점 비율: 2019년 76% → 2024년 24% (실제 건수: 223건 → 50건 미만)
  • Rust 코드는 C/C++ 코드 대비 메모리 안전 취약점 밀도 1,000배 감소
  • 개발 효율: Rust 변경사항은 롤백률 4배 낮음, 코드 리뷰 시간 25% 단축

Microsoft: 2030년까지 C/C++ 전면 교체 선언#

2023년에 Azure CTO Mark Russinovich가 신규 C/C++ 프로젝트를 금지하고 Rust를 요구한 데 이어, 2025년 12월에는 Distinguished Engineer Galen Hunt가 “2030년까지 Microsoft의 모든 C/C++ 코드를 제거하겠다” 는 목표를 발표했습니다. 목표 지표는 “1명의 엔지니어가 1개월에 100만 줄의 코드를 변환"하는 것입니다. 다만 한 시니어 엔지니어는 “Windows가 AI로 Rust에 재작성되고 있다는 것은 아니다"라고 명확히 선을 긋기도 했습니다.

sudo/su: 보안 핵심 도구의 재작성#

Unix/Linux의 핵심 보안 도구인 sudo와 su도 Rust로 재작성되었습니다. 원래 sudo의 보안 버그 중 3분의 1이 메모리 관리 이슈 에서 기인했으며, 2023년 9월 ISRG의 Prossimo 프로젝트를 통해 메모리 안전한 sudo-rs가 출시되었습니다.

3. 미국 정부의 공식 권고: C를 쓰지 말라#

개별 기업의 판단을 넘어, 미국 정부 기관들이 공식적으로 C/C++ 사용을 자제하라고 권고 하고 있다는 점은 이 흐름의 무게감을 더해줍니다.

시기 기관 핵심 내용
2022년 11월 NSA C/C++에서 Rust, Go, Java, C# 등으로의 전략적 전환 권고
2023년 10월 CISA “Secure by Design” — 메모리 안전 언어 우선 사용 권고
2023년 12월 CISA+NSA+FBI “The Case for Memory Safe Roadmaps” 공동 가이드 발행
2024년 2월 백악관 ONCD 메모리 안전 언어 채택 공식 촉구. Morris worm(1988), Heartbleed(2014) 등의 공통 원인이 메모리 안전 취약점이라고 명시
2025년 6월 NSA/국방부 메모리 안전 언어 전환 권고 재강조

백악관이 특정 프로그래밍 언어에 대해 공식 입장을 내놓는 것은 이례적인 일입니다. 이는 메모리 안전성 문제가 단순한 기술적 논쟁이 아니라 국가 안보 차원의 이슈 로 격상되었음을 의미합니다.

4. “Rewrite it in Rust” 논쟁: 반론도 있다#

물론 이 흐름에 대한 반론도 존재합니다. 일방적인 “C는 끝났다” 서사는 현실을 정확히 반영하지 못합니다.

C/C++ 진영의 반론#

C++ 창시자 Bjarne Stroustrup 은 2023년 NSA의 권고에 대해 강하게 반박했습니다. 그는 NSA가 C와 C++를 “C/C++“로 묶어 취급하는 것에 반대하며, “30년 이상의 발전을 무시한다"고 비판했습니다. C++의 Safety Profiles를 통한 정적 분석으로 메모리 안전을 달성할 수 있다는 것이 그의 주장입니다.

UC San Diego의 학술 연구 는 C와 Rust 인터페이스 경계(FFI)에서 발생하는 메모리 안전 이슈를 분류하며, 단순한 재작성이 모든 문제를 해결하지 못한다는 점을 지적했습니다.

CISA KEV(Known Exploited Vulnerabilities) 분석에서는 실제로 악용된 취약점 중 메모리 손상은 19.5% 에 불과하다는 결과도 나왔습니다. 메모리 안전에만 집중하면 다른 유형의 취약점을 간과할 수 있다는 경고입니다.

C가 여전히 강점을 가지는 영역#

  • 성능: 순수한 실행 속도에서 여전히 최고 수준
  • 이식성: ANSI C로 작성하면 거의 모든 플랫폼에서 컴파일 가능
  • 생태계 성숙도: GCC, Clang 등 수십 년간 검증된 도구 체인
  • 하드웨어 근접성: OS 커널, 펌웨어, 임베디드 시스템에서의 결정적 리소스 제어
  • 언어 인터페이스: 대부분의 현대 언어가 C ABI를 통해 상호운용

5. C23 표준: 언어 차원의 대응, 그리고 근본적 한계#

2024년 10월, 새로운 C 표준인 C23(ISO/IEC 9899:2024) 이 공식 발표되었습니다. C 언어도 가만히 있지는 않았습니다.

주요 개선사항#

기능 설명
nullptr 키워드 타입 안전한 널 포인터. NULL/0의 모호함 해소
bool, true, false 정식 키워드 승격 (stdbool.h 불필요)
auto 타입 추론 변수 선언 시 타입 자동 추론
constexpr 컴파일 타임 상수 평가
typeof 연산자 표준화된 타입 추론
#embed 지시자 바이너리 데이터 직접 포함
속성 문법 [[nodiscard]], [[maybe_unused]] 등

근본적 한계#

그러나 C23이 메모리 안전성의 근본 문제를 해결하지는 못합니다. 빌려오기 검사(borrow checking), 수명 분석(lifetime analysis), 메모리 안전 보장 같은 기능은 C23에 포함되지 않았습니다. 버퍼 오버플로, use-after-free, 댕글링 포인터의 방지는 여전히 프로그래머의 책임입니다.

2025년 3월에 발표된 MISRA C:2025 는 4개의 새 규칙을 추가하고 C23 기능을 지원하지만, 이는 언어 차원의 강제가 아닌 가이드라인 수준에 머무릅니다.

요약하면, C23은 “더 현대적인 C” 를 제공하지만, 메모리 안전성이라는 핵심 논쟁에 대한 답은 되지 못합니다. C 언어의 설계 철학 — 프로그래머에게 최대한의 자유를 주되, 그 결과에 대한 책임도 프로그래머가 진다 — 은 C23에서도 변하지 않았습니다.

6. 대안 언어들: C의 왕좌를 노리는 도전자들#

Rust: 가장 유력한 후계자#

Rust는 현재 C의 대안으로 가장 주목받는 언어입니다.

  • 최근 12개월간 220만 명 이상 의 개발자가 사용
  • 기업의 60% 가 신규 프로젝트에 Rust를 채택 (RustRover 2025 설문)
  • Linux 커널의 영구 공식 언어로 자리매김
  • 자동차 분야에서 ISO 26262 인증 Rust 컴파일러 등장 (Ferrous Systems)
  • 임베디드: Espressif(ESP32)의 공식 지원, ARM Cortex-M 생태계 성장

Rust의 강점은 컴파일 타임에 메모리 안전성을 보장 하면서도 C에 준하는 성능을 제공한다는 점입니다. 다만 학습 곡선이 가파르고, 기존 C 개발자들의 채택 저항이 크다는 점은 여전한 과제입니다.

Zig: “더 나은 C"를 표방하는 신생 언어#

Zig는 C의 직접적인 개선을 목표로 하는 언어입니다. 아직 1.0 이전(2025년 10월 기준 0.15.2)이지만, 1.0은 2026년 중후반으로 예상됩니다.

  • 일급 C 상호운용: C 헤더를 직접 임포트하고, C 라이브러리와 자연스럽게 연동
  • 숨겨진 할당 없음: 메모리 할당이 명시적이어서 임베디드 환경에 적합
  • comptime: 컴파일 타임 코드 실행으로 C 매크로의 대안 제공

Zig는 Rust처럼 패러다임을 바꾸기보다, C의 철학을 유지하면서 날카로운 모서리를 다듬는 접근을 취합니다. C 개발자에게는 가장 자연스러운 전환 경로가 될 수 있습니다.

Go: 시스템 인프라의 새 강자#

Go는 가비지 컬렉션이 있어 C의 직접적 대체는 아니지만, 과거 C로 작성했을 법한 인프라 소프트웨어 의 상당 부분을 흡수했습니다. Docker, Kubernetes, Terraform, Prometheus — 클라우드 네이티브 생태계의 핵심 도구들이 Go로 작성되어 있습니다. 2024년 기준 세 번째로 빠르게 성장하는 언어입니다.

Carbon: 아직은 먼 미래#

Google이 개발 중인 Carbon은 C++의 후계자를 목표로 합니다. 그러나 0.1 버전도 2026년 말 이후로 예상되며, 프로덕션용 1.0은 2028년 이전에는 어렵습니다. C 대체보다는 C++ 대체에 초점이 맞춰져 있습니다.

TIOBE 지수로 본 현재#

TIOBE 지수에서 C의 위치도 의미심장한 변화를 보이고 있습니다:

  • 2024년: C++에 추월당하며 4위로 하락 — 2001년 TIOBE 지수 시작 이래 최저 순위 기록
  • 2026년 1월: C23 채택과 임베디드/IoT 수요에 힘입어 2위로 반등 (10.99%)
  • 2026년 3월: Python(~22%) 에 이어 2위권 유지, C++·Java와 1% 이내 근소한 차이

C가 죽어가는 것은 아니지만, 더 이상 압도적인 1위도 아닙니다. “범용 시스템 언어"에서 “특정 도메인의 핵심 언어"로 역할이 좁혀지고 있다 는 것이 현재의 흐름입니다.

Part 1 마무리#

지금까지 살펴본 것은 AI 에이전트가 등장하기 이전에 이미 진행되고 있던 변화입니다. 메모리 안전성 논쟁, 정부 권고, 주요 프로젝트의 마이그레이션, C23의 한계, 대안 언어의 성장 — 이 모든 것이 C 언어의 위상에 구조적 변화가 일어나고 있음을 보여줍니다.

Part 2에서는 이 변화의 한가운데 등장한 AI 코딩 에이전트 가 C 언어 개발에 어떤 영향을 미치고 있는지 살펴보겠습니다. AI는 C 개발을 더 안전하게 만들어 C의 수명을 연장하고 있을까요, 아니면 C에서 다른 언어로의 전환을 가속하고 있을까요? 흥미롭게도, 두 가지 현상이 동시에 일어나고 있습니다.

References#