96 실전의 C — 도구, 프로젝트, 그리고 영역

96.1 make — 무엇을 다시 만들 것인가

make의 착상은 한 줄이다 — 결과물이 재료보다 오래됐으면 다시 만든다. 규칙을 적는 문법도 그 착상 그대로다:

hello: hello.c greet.c greet.h      # 목표: 재료들
  cc -Wall -Wextra -o hello hello.c greet.c    # 만드는 법(탭으로 시작)

make hello라고 부르면 파일들의 시각을 비교해, 필요할 때만 명령을 실행한다. 파일 하나만 고쳤을 때 전체를 다시 컴파일하지 않는 것 — 16장의 릴레이와 54장의 분할이 실무에서 시간을 아끼는 방식이 이것이다.

make는 1976년에 만들어져 지금도 쓰인다. 문법의 괴벽(명령 줄은 반드시 탭으로 시작해야 한다 — 만든 사람 스스로 “그때는 사용자가 열둘뿐이었다”고 회고한 실수다)까지 그대로 남았지만, “의존 관계를 적으면 필요한 것만 다시 만든다”는 착상은 이후 모든 빌드 도구의 뿌리가 됐다. 오늘의 큰 프로젝트는 CMake·Meson·Ninja 같은 도구를 얹어 쓰지만, 그 도구들이 결국 만들어 내는 것도 대개 make류의 규칙이다.

96.2 git — 무엇이 언제 바뀌었나

두 번째 필수 도구는 버전 관리다. 코드의 모든 변경을 기록해 두고, 언제든 되돌리고, 여럿이 같은 코드를 고쳐도 합칠 수 있게 하는 도구 — 오늘의 사실상 표준이 git이다.

일상의 명령은 다섯이면 시작할 수 있다.

$ git init                 # 이 폴더를 저장소로
$ git add hello.c          # 기록할 변경을 고른다
$ git commit -m "첫 프로그램"   # 이유와 함께 기록한다
$ git log                  # 지나온 기록을 본다
$ git diff                 # 지금 무엇이 바뀌었나

git이 이 책의 주제와 이어지는 대목이 하나 있다 — git 자신이 순수 C로 쓰인 프로그램이다. 2005년 리누스 토르발스가 리눅스 커널 개발을 위해 며칠 만에 초기판을 만들었고, 지금은 세계에서 가장 널리 쓰이는 개발 도구가 됐다. 10장에서 본 CRLF 경고를 내는 그 도구가, 이 책이 가르친 언어로 만들어져 있는 것이다.

96.3 도구 상자의 나머지 — 빌드, 관측, 검사

make 와 git 은 시작일 뿐이다. 실무의 C 프로젝트는 대개 여러 도구를 겹쳐 쓰는데, 각각이 어떤 질문에 답하는 도구인지로 묶으면 외울 것이 없다.

96.3.1 ① 무엇을 어떻게 만들 것인가 — 빌드와 의존성

마지막 줄이 C 의 오랜 약점이다 — 언어에 딸린 공식 패키지 관리자가 없어서, 의존성을 어떻게 들여올지가 프로젝트마다 다르다(시스템 패키지, 소스 통째로 넣기(vendoring), 서브모듈, vcpkg·Conan 같은 도구). 이 책의 예제가 proven 을 저장소 안에 통째로 넣어 쓰는 것도 그 현실 때문이다.

96.3.2 ② 무엇이 잘못됐는가 — 디버거와 기록·재생

17장에서 gdb·lldb를 익혔다. 실무에는 그 곁에 두 부류가 더 있다.

• 플랫폼 디버거 — 윈도우의 WinDbg와 Visual Studio 디버거. 특히 WinDbg 의 시간 여행 디버깅(TTD)은 실행을 통째로 기록해 두고 뒤로 돌려 가며 볼 수 있다.

- 기록·재생 — 리눅스의 rr가 같은 일을 한다. 한 번 재현된 버그를 기록해 두면 그 실행을 몇 번이고 똑같이 되돌려 볼 수 있어서, “가끔만 재현되는” 버그에 특히 강하다. 17장에서 본 하이젠버그의 정공법이다.

• 크래시 사후 분석 — 코어 덤프(리눅스)와 미니덤프(윈도우)를 디버거로 열어 현장을 되짚는다. 릴리스 빌드도 -g로 만들어 디버그 정보를 따로 보관하는 관행(17장)이 여기서 값을 한다.

96.3.3 ③ 어디가 느린가 — 프로파일러

“짐작하지 말고 재라”는 것이 성능 작업의 첫 규칙이다.

프로파일러를 쓰면 11·12장의 이야기가 숫자로 확인된다 — 캐시 미스가 많은 루프, 분기 예측이 빗나가는 조건문, 값비싼 할당(45장)이 어디에 몰려 있는지가 그대로 보인다.

96.3.4 ④ 코드가 옳은가 — 검사와 시험

• 정적 분석 — clang-tidy, cppcheck, 그리고 컴파일러 자체의 -fanalyzer(GCC). 상용으로는 PC-lint Plus·PVS-Studio·Coverity.
• 동적 검사 — 17장의 새니타이저(ASan·UBSan·TSan)와 valgrind --tool=memcheck. 전자는 다시 컴파일해야 하고 빠르며, 후자는 그대로 돌릴 수 있고 느리다.

- 덮개율(coverage) — gcov/lcov(GCC), llvm-cov(Clang). “시험이 어느 줄을 실제로 지나갔는가”를 보여 준다.

• 퍼징 — libFuzzer, AFL++, honggfuzz. 무작위 입력을 쏟아부어 죽는 자리를 찾는다. 파서와 디코더처럼 바깥 입력을 먹는 코드에서 효과가 크다.
• 단위 시험 — C 에는 표준 시험 틀이 없어 Unity·CppUTest·Criterion 같은 라이브러리를 쓴다.

96.3.5 ⑤ 사람이 읽기 좋은가 — 서식과 문서

clang-format(서식 자동 정리), uncrustify, Doxygen(주석에서 문서 생성), 그리고 compile_commands.json(빌드 명령의 목록)이다. 마지막 것은 편집기의 자동완성(clangd)과 정적 분석 도구가 “이 파일이 어떤 옵션으로 컴파일되는지”를 알기 위해 읽는 파일이라, CMake 에서 한 줄로 켜 두는 것이 요즘 관행이다.

96.4 오늘도 C로 도는 것들 — 그리고 왜

1장에서 “C는 어디에나 있다”고 했다. 이제 구체적인 이름과 이유를 적을 수 있다.

공통점을 뽑으면 C를 고르는 이유가 네 가지로 정리된다.

• 가장 낮은 층에 서야 할 때 — 운영체제, 드라이버, 런타임.
• 어디에나 옮겨야 할 때 — 새 칩이 나오면 C 컴파일러부터 만들어진다 (4장의 이식성 혁명이 반세기째 유효하다).
• 성능과 자원을 손으로 통제해야 할 때 — 메모리 배치, 지연시간, 실행 파일 크기.
• 다른 모든 언어와 대화해야 할 때 — 파이썬·자바·러스트 어느 쪽에서든 C 함수는 부를 수 있다. C ABI가 언어들 사이의 국제 공용어다.

96.5 업계의 규약 — MISRA C와 그 이웃들

방금 본 목록 — 자동차, 항공, 의료, 발전소 — 을 다시 읽어 보면 공통점이 하나 있다. 틀리면 사람이 다치는 자리다. 그래서 이 산업들은 C를 쓰되 그냥 쓰지 않는다.

사람이 죽거나 큰돈이 걸린 자리에서는, 「C를 잘 쓰자」는 다짐만으로 부족하다. 그래서 산업마다 쓸 수 있는 C의 부분집합을 문서로 정해 놓았다. 12장의 회색지대와 52장의 정의되지 않은 동작이 실무에서 어떻게 다뤄지는지가 이 규약들에 그대로 적혀 있다.

96.5.1 MISRA C — 자동차에서 나와 업계 전체로

가장 널리 쓰이는 것이 MISRA C다. 이름은 그 유래에서 왔다 — Motor Industry Software Reliability Association, 영국의 자동차 업계 단체다.

MISRA C의 규칙은 「하지 마라」의 목록처럼 보이지만, 그 구조가 더 중요하다.

첫째, 규칙에 등급이 있다.

둘째, 「일탈」(deviation)이라는 정식 절차가 있다. 규칙을 어겨야 하는 자리가 실무에는 반드시 생기므로, MISRA는 어기지 마라가 아니라 어길 거면 이렇게 남겨라를 정해 두었다 — 무슨 규칙을, 어디서, 왜 어겼고, 그 대신 어떤 조치를 했는지를 문서에 적는다.

이 구조가 12장에서 말한 규율과 정확히 같은 사상이라는 점을 눈여겨볼 만하다. 선택을 금지하는 것이 아니라, 선택을 눈에 보이게 만드는 것이다.

96.5.2 이웃들 — 안전 규격과 코딩 규칙

MISRA C 하나만 있는 것이 아니다. 크게 두 갈래로 갈린다 — 어떻게 만들 것인가를 정하는 안전 규격과, 어떻게 쓸 것인가를 정하는 코딩 규칙이다.

안전 규격은 대개 언어의 부분집합을 쓰라고만 말하고 그 부분집합을 직접 정하지 않는다. 그래서 「ISO 26262를 따르려고 MISRA C를 쓴다」는 조합이 표준적이다.

96.5.3 무엇을 금지하는가 — 공통된 무늬

규약마다 항목은 다르지만, 금지되거나 강하게 제한되는 것들의 얼굴은 놀랄 만큼 닮았다. 그리고 그 목록이 이 책이 위험하다고 말해 온 것들과 겹친다.

이 표를 거꾸로 읽으면 이 책의 요약이 된다 — 계약을 벗어나지 말고, 자원의 수명과 크기를 예측 가능하게 유지하고, 사람이 읽어 확인할 수 있게 쓰라.

96.6 C와 C++ — 형제이지, 부모와 자식이 아니다

가장 흔한 오해를 여기서 정리한다. C는 C++의 부분집합이 아니다. C++은 “C에 객체지향과 템플릿을 더한 언어”가 아니라, C에서 갈라져 나와 따로 자란 다른 언어다.

역사를 짧게 보면 관계가 분명해진다. 1979년 비야네 스트롭스트룹이 C에 클래스를 얹은 “C with Classes”를 만들었고, 1983년 C++로 이름이 바뀌었다. 여기까지는 확장이 맞다. 그런데 그 뒤로 두 언어는 각자의 위원회에서 각자 표준을 만들며 갈라졌다 — C는 1989년 C89로, C++은 1998년 C++98로 처음 표준을 얻었고, 이후 서로를 참고하되 서로에게 종속되지 않았다.

그래서 오늘날 양쪽 모두에 상대에게 없는 것이 있다.

96.7 C 코드를 C++ 컴파일러에 넣으면

말이 아니라 실물로 보인다. 아래는 완전히 올바른 C 코드다.

#include <stdio.h>
#include <stdlib.h>

/* 아래는 전부 올바른 C 코드다. 그런데 C++ 컴파일러에 그대로 넣으면
   상당수가 컴파일되지 않는다. 이 예제는 C 로만 빌드된다. */

struct point { int x, y; };

/* ① C++ 의 예약어가 C 에서는 평범한 이름이다 */
static int class_of(int n) { return n / 10; }

int main(void)
{
    /* ② void* 에서 다른 포인터로의 암묵 변환 — C 는 허용, C++ 는 거부 */
    int *buf = malloc(4 * sizeof *buf);
    if (!buf) return 1;
    for (int i = 0; i < 4; i++) buf[i] = i * i;

    /* ③ 문자 상수의 타입: C 에서는 int 다 */
    printf("sizeof('a') = %zu  (in C++ this is 1)\n", sizeof('a'));

    /* ④ 순서를 바꾼 지정 초기화 — C99 는 허용 */
    struct point p = { .y = 2, .x = 1 };
    printf("point = (%d, %d)\n", p.x, p.y);

    /* ⑤ 구조체 태그는 별도 이름 공간이라 struct 를 붙여야 한다 */
    struct point q = p;
    printf("copy  = (%d, %d)\n", q.x, q.y);

    printf("class_of(37) = %d\n", class_of(37));
    printf("buf = %d %d %d %d\n", buf[0], buf[1], buf[2], buf[3]);

    free(buf);
    return 0;
}

sizeof('a') = 4  (in C++ this is 1)
point = (1, 2)
copy  = (1, 2)
class_of(37) = 3
buf = 0 1 4 9

같은 파일을 g++ -std=c++20으로 컴파일하면 이렇게 된다.

error: invalid conversion from ‘void*’ to ‘int*’ [-fpermissive]
   15 |     int *buf = malloc(4 * sizeof *buf);
      |                ~~~~~~^~~~~~~~~~~~~~~~~
      |                      void*
error: designator order for field ‘point::x’ does not match
       declaration order in ‘point’
   23 |     struct point p = { .y = 2, .x = 1 };

C가 허용하는 void *의 암묵 변환을 C++은 거부한다 — 그래서 C++에서는 malloc의 결과에 반드시 캐스트가 붙는다(그리고 그것이 C에서는 권하지 않는 관행이다. 거기서 “malloc의 반환값을 캐스트해야 하는가” 논쟁이 갈린다). 지정 초기화도 C++20이 받아들이긴 했지만 순서를 바꿀 수는 없다.

그 밖에 조용히 뜻이 달라지는 자리도 있다. 대표가 문자 상수다.

C  : sizeof('a') = 4      (문자 상수의 타입이 int)
C++: sizeof('a') = 1      (타입이 char)

컴파일은 양쪽 다 되는데 결과가 다르다 — 이런 자리가 가장 위험하다. class, new, template, this 같은 C++ 예약어를 C에서 변수 이름으로 쓴 코드도 그대로는 넘어가지 않는다.

96.8 C++ 쪽의 시간은 더 빨리 흐른다

1장에서 잠깐 말한 사정을 여기서 조금 더 적는다. C++은 2011년 이후 3년 주기로 표준을 낸다 — C++11, 14, 17, 20, 23, 26. 매 판마다 언어와 표준 라이브러리에 큰 기능이 들어오고, 그만큼 “현대적 C++”의 모습도 빠르게 바뀐다. 반면 C의 개정 주기는 훨씬 길고(C89 → C99 → C11 → C17 → C23), 들어오는 것도 대체로 작고 보수적이다.

이 속도 차이는 취향의 문제가 아니라 역할의 차이에서 온다. C는 운영체제와 펌웨어, 다른 언어들이 기대는 바닥층의 언어라 바뀌지 않는 것 자체가 기능이 된다. 30년 된 코드가 오늘도 컴파일되는 것, 그리고 어느 플랫폼에나 C 컴파일러가 있는 것이 그 대가로 얻은 자산이다.

96.9 섞어 쓰는 법 — extern "C"

실무에서는 두 언어를 섞는 일이 아주 흔하다. C로 짠 라이브러리를 C++ 프로그램이 부르는 경우가 대표적이다. 문제는 이름 장식(name mangling) 이다 — C++ 컴파일러는 오버로딩을 지원하려고 함수 이름에 매개변수 타입 정보를 섞어 목적 파일에 심는데(54장의 링크를 떠올리면 된다), C 컴파일러는 이름을 그대로 둔다. 그래서 그냥 이으면 링커가 짝을 찾지 못한다.

해법은 선언에 “이건 C 규약으로 다뤄라”라고 표시하는 것이다.

/* mylib.h — C 로 만든 라이브러리의 헤더 */
#ifndef MYLIB_H
#define MYLIB_H

#ifdef __cplusplus
extern "C" {
#endif

int mylib_add(int a, int b);
void mylib_reset(void);

#ifdef __cplusplus
}
#endif

#endif

__cplusplus는 C++ 컴파일러만 정의하는 매크로다. 그래서 이 헤더는 C에서 읽으면 평범한 선언 둘이고, C++에서 읽으면 extern "C" { ... }로 감싸인 선언이 된다 — 헤더 하나로 두 언어를 모두 만족시키는 표준 관용구이고, 세상의 거의 모든 C 라이브러리 헤더가 이 모양을 하고 있다.

몇 가지 규칙을 함께 기억하면 된다.

• extern "C"는 이름과 호출 규약에만 관여한다. 함수의 내용이나 타입 검사와는 무관하다.
• 오버로딩된 함수는 extern "C"로 묶을 수 없다 — 이름이 하나뿐이어야 하기 때문이다.
• C 헤더를 C++에서 쓸 때는 C++ 예약어(class, new, template, namespace, this)를 매개변수 이름으로 쓰지 않는 것이 예의다.
• 경계를 넘는 자료는 두 언어가 모두 이해하는 모양으로 유지한다 — 단순 구조체와 포인터, 그리고 명시적인 크기. C++의 클래스나 예외를 경계 너머로 던지지 않는다.

96.10 임베디드 — C의 본진

일상에서 눈에 안 띄지만 물량으로는 가장 큰 C의 영역이 임베디드다. 세탁기와 에어컨의 제어판, 자동차의 수십 개 제어 장치, 의료 기기, 드론과 로봇의 저수준 제어, 통신 모듈의 펌웨어 — 대부분이 C로 쓰인다.

이유는 그 환경의 제약에 있다. 메모리가 킬로바이트 단위이고, 운영체제가 없을 수도 있고(6장의 0번지가 인터럽트 벡터인 그 세계), 실행 시간이 예측 가능해야 하며(가비지 컬렉션 같은 예측 불가한 멈춤이 허용되지 않는다), 전력이 제한된다. C는 이런 환경에서 실행되지 않는 것에는 비용을 물리지 않는 언어라 자연스럽게 맞는다 — 표준 라이브러리 없이 쓸 수 있고(61장의 프리스탠딩), 생성되는 코드가 예측 가능하다.

임베디드의 C에는 이 책의 지식이 유난히 직접적으로 쓰인다 — 특정 주소를 장치 레지스터로 다루기(6장), volatile로 최적화를 막기(13장), 비트 연산으로 하드웨어 플래그를 조작하기(5·28장), 동적 할당을 아예 쓰지 않기(45장), 정렬과 표현을 의식하며 통신 프로토콜을 다루기(6·48장).

96.11 한계를 넘는 법 — 실전의 요령

C의 결핍은 분명하다 — 이름 공간이 없고, 제네릭이 없고, 자원 정리가 자동이 아니고, 안전이 강제되지 않는다. 실전은 이것을 언어 밖의 규율과 도구로 메운다. 이 책이 지나온 것들을 실무 지침으로 모으면 이렇다.

• 이름 공간이 없다 → 접두어 규약과 파일 수준 static, 그리고 심볼 가시성(55·56장. 정확히는 표준이 정한 이름 공간이 넷 있고, 새로 만들 수 없는 것이다).
• 제네릭이 없다 → 매크로로 코드 생성(57장의 ##, X 매크로), 또는 void *와 크기·비교 함수를 받는 일반화(표준의 qsort가 그 방식이다), 또는 C11의 _Generic 선택.
• 자원 정리가 자동이 아니다 → 소유 규약을 이름과 문서로 명시하고 (45장), 한 함수의 정리 지점을 한 곳으로 모으는 관용구(정리 라벨로 goto하는 패턴은 커널에서 표준 관행이다).
• 안전이 강제되지 않는다 → 그물을 겹친다(17장): 경고 최대, 새니타이저, 두 컴파일러 교차, 정적 분석 도구, 그리고 검사가 내장된 부품(제12부).
• 표준 라이브러리가 얇다 → 필요한 층을 고르거나 만든다. vendor로 들여와 빌드를 단순하게 유지하는 것이 작은 프로젝트의 정석이다.
• 큰 프로젝트의 복잡도 → 컴파일 단위를 작게 나누고 헤더로 계약을 드러내며(54장), 테스트와 빌드를 자동화한다(이 장의 make·git).

지면 밖의 지형까지 둘러보았다. 다음 장은 그중 한 구역을 확대한다 — C가 가장 깊이 뿌리내린 자리인 임베디드에서, 어떤 컴파일러와 어떤 연장을 들고 일하는지다. 그다음 마지막 장에서 이 책이 지나온 길을 되짚고 책을 닫는다.