C++20 모듈의 어떤 특정 속성이 번역 단위 경계를 넘어 매크로 유출을 방지하는가?

질문에 대한 답변.

질문의 배경

C++20 이전에, C++ 컴파일 모델은 전처리 지시문을 통한 텍스트 포함에 의존했다. 헤더 파일이 포함되면 전처리기는 해당 헤더의 텍스트를 포함하는 파일로 문자 그대로 복사했다. 이 메커니즘은 헤더에 정의된 매크로가 이를 포함한 모든 번역 단위의 전역 네임스페이스로 유출되어, 진단하기 어려운 미세한 버그와 이름 충돌을 초래했다.

문제

매크로 유출은 대규모 코드베이스에서 유지 보수의 악몽을 초래했다. 서드파티 라이브러리에서 정의된 매크로는 소비자 코드에서 키워드나 일반 식별자를 조용히 재정의할 수 있어, 컴파일 실패나 런타임 오류를 발생시킬 수 있다. 전통적인 우회 방법인 #undef 가드는 수동적이고 오류가 발생하기 쉬우며 복잡한 의존성 그래프에 걸쳐 확장되지 않았다. 근본적인 문제는 전처리기가 범위나 인터페이스 경계에 대한 개념을 갖고 있지 않았다는 것이다.

해결책

C++20 모듈은 전처리기 수준이 아니라 언어 수준에서 작동하는 의미적 임포트 메커니즘을 도입한다. import module_name;으로 모듈을 임포트하면 컴파일러는 임포트한 번역 단위의 전처리 지시문을 실행하지 않고 모듈의 내보낸 인터페이스를 처리한다. 모듈 내에서 정의된 매크로는 명시적으로 내보내지 않는 한 해당 모듈의 구현에만 비공개로 남아 있다. 이 속성은 매크로가 번역 단위 경계를 넘지 않도록 보장하여 진정한 캡슐화를 제공하고 이름 오염을 방지한다.

// mathlib.cpp (모듈 구현)
module;
#define INTERNAL_CALC_FACTOR 3.14  // 비공개 매크로, 유출되지 않음

export module mathlib;

export double compute(double x) {
    return x * INTERNAL_CALC_FACTOR;
}

// main.cpp (소비자)
import mathlib;

// INTERNAL_CALC_FACTOR는 여기서 보이지 않음
// #ifdef INTERNAL_CALC_FACTOR는 false가 될 것임

int main() {
    double result = compute(10.0);  // 정상 작동
}

생활에서의 상황

한 금융 거래 회사는 수백 개의 모듈에 걸쳐 수백만 줄의 코드로 구성된 대규모 코드베이스를 유지 관리하고 있었다. 이들은 공개 헤더에 MIN 및 MAX와 같은 매크로를 정의한 레거시 수학 라이브러리에 의존했다. 이러한 매크로는 표준 라이브러리 함수 및 서드파티 JSON 파싱 라이브러리와 충돌하여, min 및 max를 변수 이름이나 함수 템플릿으로 사용하는 경우가 많았다.

첫 번째 접근법으로 고려된 것은 모든 서드파티 헤더를 #pragma once 스타일 가드로 감싸고 각 포함 후에 문제를 일으키는 매크로를 수동으로 #undef하는 것이었다. 이는 개발자들이 어떤 헤더가 어떤 매크로를 정의했는지 기억해야 하고 각 포함 후에 정리해야 하므로 문제가 발생하기 쉬웠다. 이 접근 방식은 한 번의 #undef를 놓치는 것만으로도 코드베이스의 다른 부분에서 실패를 초래할 수 있어 취약했다. 또한 동일한 헤더 텍스트를 번역 단위 전반에 걸쳐 반복적으로 처리하므로 컴파일 시간도 상당히 증가했다.

두 번째 접근법으로 고려된 것은 수학 라이브러리를 매크로 대신 인라인 함수와 템플릿을 사용하도록 변환하는 것이었다. 비록 이것이 유출 문제를 해결했지만 레거시 라이브러리를 폭넓게 수정해야 했다. 수학 라이브러리는 여러 팀에서 사용하였고, 이를 변경하는 것은 특정 매크로 평가 의미나 부작용에 의존하는 기존 계산을 깨뜨릴 위험이 있었다. 리팩토링 작업은 6개월이 걸릴 것으로 추정되었고 거래 플랫폼에는 위험이 너무 컸다.

선택된 해결책은 C++20 모듈로의 전환이었다. 팀은 수학 라이브러리를 모듈로 변환하여 수학적 함수들을 내보내면서 매크로는 모듈 구현 내에서만 보관하도록 했다. 이를 통해 #include <mathlib.h> 대신 import mathlib;를 사용하면서 소비하는 번역 단위에서는 더 이상 MIN 및 MAX 매크로를 볼 수 없게 되었다. 이 접근 방식은 라이브러리 구현에서 최소한의 수정만 필요했다—단지 내보내기 문을 추가하고 헤더를 모듈 인터페이스 단위로 변환하는 것만으로도 충분했다. 이전의 6개월이 아닌 2주가 걸렸다. 그 결과 코드베이스 전반에 걸쳐 매크로 관련 이름 충돌이 제거되었고, 모듈의 컴파일된 인터페이스 덕분에 컴파일 시간이 15% 감소했다.

후보자들이 자주 놓치는 것

모듈 인터페이스 단위의 컴파일된 이진 형식이 텍스트 헤더 포함과 비교하여 매크로 유출을 어떻게 방지하는가?

후보자들은 종종 C++20 모듈이 생성하는 컴파일된 모듈 인터페이스 단위(CMI)가 모듈의 내보낸 인터페이스에 대한 이진 표현이라는 사실을 놓친다. 전처리기를 통해 처리되며 매크로 정의를 텍스트로 포함하는 텍스트 헤더와 달리, CMIs는 내보낸 함수, 유형 및 템플릿에 대한 의미 정보를 저장한다. 전처리기는 임포트된 모듈의 내용을 처리하지 않는다; 오직 임포트 선언만 본다. 따라서 모듈의 구현 또는 인터페이스 단위에서 정의된 매크로는 임포터에게 보이지 않는다. 이는 #include와는 근본적으로 다르며, #define 지시문을 포함한 텍스트를 문자적으로 복사하는 것이다. 이를 이해하려면 모듈이 텍스트 포함 모델에서 의미적 임포트 모델로 전환된다는 것을 인식해야 한다.

내보낸 매크로가 사용된 export import와 #include 지시문에서의 매크로가 어떻게 다르게 작동하는가?

후보자들은 종종 매크로의 export import를 일반적인 매크로 동작과 혼동한다. C++20에서는 매크로를 export import를 통해 내보내는 것을 허용하지만, 이러한 매크로는 모듈을 임포트하는 코드에만 영향을 미치고 해당 임포트 범위를 넘어서 유출되지 않는다. #include와 달리 매크로는 번역 단위에서 명시적으로 정의 해제되거나 파일 끝까지 존재하는 동안 지속된다; 모듈에서 내보낸 매크로는 그 모듈에 대한 임포트된 번역 단위의 노출에 국한된다. 더욱이, 여러 모듈이 충돌하는 매크로를 내보낼 경우, 충돌은 컴파일 중 후에 조용한 재정의 오류를 발생시키지 않고 임포트 시점에 감지된다. 이러한 범위 동작은 텍스트 포함이 결여한 위생을 제공한다.

모듈이 전처리기와 독립성을 유지함으로써 빌드 시스템 통합 및 의존성 스캔에 어떤 영향을 미치는가?

후보자들은 종종 C++20 모듈이 헤더와 달리 컴파일 시작 전에 빌드 시스템이 모듈 의존성을 이해해야 함을 놓친다. 모듈은 텍스트 파일이 아닌 컴파일된 단위이기 때문에 빌드 시스템은 모듈 인터페이스 단위를 분석하여 무엇을 내보내고 무엇을 임포트하는지 결정해야 한다. 이는 두 단계의 빌드 프로세스를 요구한다: 먼저, 모듈 인터페이스 단위를 스캔하여 의존성 그래프를 구축한 다음, 의존성 순서로 컴파일하는 것이다. 전처리기와의 독립성은 전통적인 헤더 포함에 대한 #ifdef 가드가 무의미하게 되며, 모듈 인터페이스의 매크로 기반 구성은 제한된다. 빌드 시스템은 단순히 소스 파일이 아니라 컴파일된 모듈 아티팩트(BMI - 이진 모듈 인터페이스)를 추적해야 하며, 이는 의존성 추적 및 증분 빌드 작업 방식에 근본적인 변화를 가져온다.