그냥 C 그 자체

초록

이 논문은 C 소스 코드가 독립적으로 의미를 갖지 못한다는 점을 강조한다. 컴파일러 옵션, 표준 라이브러리 구현, 매크로 정의, 정의되지 않은 동작 등 빌드 환경 전체가 알려져야만 코드의 의미를 정확히 파악할 수 있다.

상세 분석

C 언어는 설계 단계부터 구현 의존성을 크게 허용하도록 만들어졌다. 표준은 “정의되지 않은 동작”(undefined behavior)이라는 개념을 도입해, 특정 상황에서 프로그램이 어떤 결과를 내야 하는지 명시하지 않는다. 이는 메모리 접근 오류, 정수 오버플로우, 시그널 처리 등 다양한 경우에 적용되며, 동일한 소스가 서로 다른 컴파일러나 옵션에 따라 전혀 다른 동작을 보일 수 있음을 의미한다.

또한 C 표준은 전처리 단계에서 제공되는 매크로와 헤더 파일을 구현마다 다르게 정의한다. 예컨대 assert, offsetof, NULL 등은 구현에 따라 전혀 다른 형태로 전개될 수 있다. 심지어 같은 구현이라도 플랫폼별로 제공되는 시스템 헤더(unistd.h, windows.h 등)는 서로 다른 선언과 매크로를 포함한다. 따라서 “#include <stdio.h>”만으로는 printf의 실제 구현이 무엇인지, 어떤 버퍼링 정책을 쓰는지 알 수 없으며, 이는 프로그램의 I/O 동작에 직접적인 영향을 미친다.

컴파일러 옵션 역시 의미론에 큰 변화를 일으킨다. 최적화 레벨(-O0, -O2, -Ofast)에 따라 변수의 살아있는 범위, 인라인 여부, 루프 전개 등이 달라지고, 이는 메모리 모델과 동시성 메커니즘에까지 파급된다. 예를 들어 -fno-strict-aliasing 옵션을 켜면 엄격한 별칭 규칙을 무시하게 되지만, 이를 끄면 동일한 코드는 정의되지 않은 동작으로 전락한다. 또한 -std=c99와 -std=c11 사이의 차이는 새로운 키워드(_Atomic, _Thread_local)와 라이브러리 함수의 추가·삭제를 초래한다.

링크 단계와 런타임 환경도 무시할 수 없다. 정적 라이브러리와 동적 라이브러리의 선택, 심볼 해석 순서, 주소 공간 배치(ASLR) 등은 프로그램이 실제로 어떤 코드를 호출하는지를 결정한다. 특히 표준 C 라이브러리(glibc, musl, msvcrt)는 같은 함수라도 내부 구현이 다르고, 오류 처리 방식이나 스레드 안전성도 차이가 난다.

이 모든 요소를 종합하면, “코드 조각”만으로는 그 의미를 완전히 규정할 수 없다는 결론에 도달한다. 논문은 이를 입증하기 위해 “해결 가능한 연습문제”를 제시한다. 해당 연습문제는 동일한 소스가 서로 다른 빌드 설정에 따라 서로 다른 결과를 내도록 설계되었으며, 이를 통해 독자는 빌드 전 과정을 모두 알지 못하면 코드의 의미를 확정할 수 없음을 체감한다.

결국 C 프로그래밍은 “텍스트 + 빌드 환경”이라는 복합적인 산물이며, 텍스트만으로는 의미를 추론할 수 없다는 점을 명확히 한다. 이는 코드 리뷰, 보안 감사, 정적 분석 등 실무에서 흔히 간과되는 위험 요소를 경고하고, 완전한 의미론적 이해를 위해서는 전체 툴체인과 설정을 문서화하고 재현 가능한 빌드 스크립트를 유지해야 함을 강조한다.