CodeGym /행동 /C++ SELF /조건부 컴파일 — 플랫폼과 기능을 위한 #if/#ifdef

조건부 컴파일 — 플랫폼과 기능을 위한 #if/#ifdef

C++ SELF

레벨 28, 레슨 2

사용 가능

1. 조건부 컴파일과 그것이 if가 아닌 이유

조건부 컴파일은 "또 하나의 if"처럼 들리지만 전혀 다른 녀석입니다. if는 프로그램이 이미 실행 중일 때 런타임에 분기지를 선택하며, 두 분기 모두 유효한 C++이어야(컴파일러가 둘 다 파싱해야) 합니다. #if/#ifdef는 컴파일 전 전처리 단계에서 분기를 선택합니다: 선택되지 않은 분기는 문자 그대로 텍스트에서 잘려나가며, 컴파일러는 그것을 전혀 보지 못합니다.

이것은 강력하지만 위험합니다: '죽은' 코드가 수년 동안 그대로 남아 있고 더 이상 컴파일되지 않는 것을 모를 수 있습니다.

모델을 한 가지 미니 다이어그램으로 정리해봅시다:

flowchart TD
    A[소스 .cpp/.hpp] --> B[전처리기: include/define/if]
    B --> C[최종 텍스트]
    C --> D[C++ 컴파일러]
    D --> E[오브젝트 파일]
    E --> F[링커]

즉 #if는 컴파일러에 어떤 텍스트가 들어갈지를 제어하고, if는 이미 컴파일된 프로그램에서 어떤 경로가 실행될지를 제어합니다.

2. 미니 용어집: #ifdef, #ifndef, #if, #elif, #else, #endif

먼저 문법을 '선반에 정리'해두면 마법 같은 룬처럼 느껴지지 않습니다. C++의 조건부 컴파일은 전처리기 지시문의 모음으로, #로 시작하고 ;가 필요 없는 한 줄들입니다.

이 지시문들은 텍스트 수준에서 if/else와 비슷한 블록을 구성합니다: 조건을 열고, 텍스트 조각을 쓰고, #endif로 닫습니다. 실제 프로젝트에서는 플랫폼이나 빌드 모드를 지원해야 할 때 이런 블록이 자주 등장합니다.

작은 참고표:

지시문	아이디어	어떤 조건에서 활성화되는가
`#ifdef NAME`	"매크로가 정의되어 있으면"	매크로가 존재함(값은 중요하지 않음)
`#ifndef NAME`	"매크로가 정의되어 있지 않으면"	매크로가 존재하지 않음
`#if EXPR`	"식이 참이면"	EXPR — 전처리기 정수식
`#elif EXPR`	"그렇지 않으면 만약…"	체인용으로 #if와 동일한 방식
`#else`	"그 외의 경우…"	대체 분기
`#endif`	"블록 닫기"	조건부 블록의 끝

3. #ifdef와 #ifndef: "플래그가 존재하는가"

종종 코드에서 가장 단순한 것이 필요합니다: 기능 조각을 켜거나 끄는 것. 이럴 때는 "매크로가 정의되어 있는가/없는가" 모델이 적합합니다. #ifdef는 문자 그대로 이렇게 읽으면 됩니다: if defined.

예를 들어 학습용 콘솔 애플리케이션(가칭 TaskBook)을 계속 개발한다고 합시다: 인사 메시지를 출력하고 가끔 디버그 메시지를 출력해 내부 동작을 확인하고 싶을 수 있습니다.

config.hpp 파일을 만듭시다:

// config.hpp
#pragma once

#define APP_DEBUG

그리고 main.cpp에서:

#include <iostream>
#include "config.hpp"

int main() {
#ifdef APP_DEBUG
    std::cout << "[debug] start\n";  // [debug] start
#endif
    std::cout << "TaskBook is running\n"; // TaskBook is running
}

참고: 만약 #define APP_DEBUG 줄을 제거하면 디버그 관련 라인은 최종 텍스트에서 아예 사라집니다. 컴파일러는 그것을 전혀 보지 못합니다.

4. #if: 켜기/끄기 이상의 모드가 필요할 때

때로는 두 상태만으로는 부족합니다. 예를 들어 단순히 "디버그 켜짐/꺼짐"이 아니라 여러 상세 수준을 원할 수 있습니다: 0 — 출력 없음, 1 — 중요 메시지, 2 — 매우 상세한 메시지.

이런 경우 #ifdef는 해법치고는 불편해 보입니다. 여러 매크로를 만들고 충돌을 신경써야 하기 때문입니다. 숫자 표현식을 전처리기 쪽에서 검사할 수 있는 #if가 더 적합합니다.

config.hpp에 숫자 모드를 정의해봅시다:

// config.hpp
#pragma once

#define APP_LOG_LEVEL 2

코드에서 이렇게 사용합니다:

#include <iostream>
#include "config.hpp"

int main() {
#if APP_LOG_LEVEL >= 2
    std::cout << "[trace] entering main\n"; // [trace] entering main
#endif

#if APP_LOG_LEVEL >= 1
    std::cout << "[info] TaskBook started\n"; // [info] TaskBook started
#endif
}

이제 숫자 하나만 바꿔도 로그의 양을 조절할 수 있습니다. 이는 여러 #ifdef를 산처럼 쌓는 것보다 더 읽기 쉬운 경우가 많습니다.

5. 복합 조건: #elif와 defined()

조건이 여럿일 때, #ifdef를 중첩하는 유혹이 생기고, 위에 또 #if를 덮어쓰는 식으로 파일이 퍼즐처럼 바뀝니다. 정신을 잃지 않기 위해 두 가지 테크닉을 아는 것이 유용합니다: #elif를 이용한 '사다리'와 defined(...) 연산자입니다.

#elif로 조건 사다리 만들기

예를 들어 TaskBook가 "현재 플랫폼은 무엇인가"를 출력한다고 가정합시다(예시용). 로직은 다음과 같을 수 있습니다:

#include <iostream>

int main() {
#if defined(_WIN32)
    std::cout << "Platform: Windows\n"; // Platform: Windows
#elif defined(__APPLE__)
    std::cout << "Platform: macOS\n";   // Platform: macOS
#elif defined(__linux__)
    std::cout << "Platform: Linux\n";   // Platform: Linux
#else
    std::cout << "Platform: Unknown\n"; // Platform: Unknown
#endif
}

defined(NAME): 읽기 쉬운 복합 조건

때때로 "기능 A가 켜져 있고 기능 B는 꺼져 있을 때" 같은 조건을 쓰고 싶을 때가 있습니다. 그냥 #ifdef만으로는 금세 중첩 블록이 되어 버립니다.

defined(NAME) 연산자는 마치 논리를 쓰듯이 #if 안에서 그런 조건을 표현할 수 있게 해줍니다. 다만 이것은 전처리기 수준에서만 동작합니다.

#include <iostream>

#define FEATURE_A
// #define FEATURE_B

int main() {
#if defined(FEATURE_A) && !defined(FEATURE_B)
    std::cout << "A on, B off\n"; // A on, B off
#endif
}

중요: defined는 #if, #elif 같은 전처리기 조건에서만 동작합니다. 이는 C++의 함수나 연산자가 아닙니다.

6. 플랫폼과 기능: 빌드를 어떻게 구성할 것인가

플랫폼 매크로는 비밀 코드처럼 보이지만 지루하고 현실적인 문제를 해결합니다: 같은 코드가 서로 다른 시스템에서 컴파일되어야 하는데, 경로, 디렉토리 구분자, 사용 가능한 API, 심지어 포함 헤더까지 달라질 수 있습니다.

이상적인 세계라면 "하나의 깔끔한 C++"만 쓰겠지만, 현실은 세부 차이를 던져줍니다. 그래서 플랫폼별 조건부 컴파일과 기능별 조건부 컴파일이 등장합니다.

플랫폼: _WIN32, linux, APPLE

Windows 컴파일러는 보통 _WIN32를 정의하고, Linux는 __linux__, macOS는 __APPLE__를 정의합니다. 이를 사용해 동작의 작은 차이를 선택합니다.

TaskBook에 경로 구분자를 반환하는 작은 함수를 만들어 봅시다:

char pathSeparator() {
#if defined(_WIN32)
    return '\\';
#else
    return '/';
#endif
}

그리고 main에서는:

#include <iostream>

char pathSeparator();

int main() {
    std::cout << pathSeparator() << '\n'; // on Windows: \   on Linux/macOS: /
}

기능들: '고고학' 대신 하나의 config.hpp

조건부 컴파일은 플랫폼뿐 아니라 기능(feature)에도 유용합니다: '디버그 로깅', '실험적 모드', '추가 검증' 등. 큰 프로젝트에서는 '이 서브시스템 없는 빌드'를 만들거나 '특정 백엔드 지원을 켠다'는 식의 상황이 생깁니다.

좋은 관행은 기능 플래그를 한 곳에 모아두는 것입니다. 예: config.hpp에 넣고 필요한 곳에서 포함하세요. 이렇게 하면 #define FEATURE_X를 열 파일에 흩뿌려 놓고 나중에 고생하는 일을 피할 수 있습니다.

예를 들어 색상 출력 기능을 켜는 APP_ENABLE_COLOR_OUTPUT가 있다고 합시다(끄면 일반 출력):

// config.hpp
#pragma once
#define APP_ENABLE_COLOR_OUTPUT 0

사용 예:

#include <iostream>
#include "config.hpp"

int main() {
#if APP_ENABLE_COLOR_OUTPUT
    std::cout << "\x1b[32mOK\x1b[0m\n"; // OK (녹색, 터미널이 지원하면)
#else
    std::cout << "OK\n";               // OK
#endif
}

ANSI 이스케이프 시퀀스 코드는 일부 환경에서 적절하지 않을 수 있다는 점을 유의하세요. 조건부 컴파일을 사용하면 해당 텍스트를 최종 코드에 아예 포함시키지 않을 수 있습니다.

7. 주요 함정: 선택되지 않은 분기가 깨질 수 있다

조건부 컴파일의 가장 불쾌한 함정은 심리적인 것입니다. 프로그램이 컴파일되면 모든 if 분기가 최소한 문법적으로 유효하다고 믿기 쉽습니다(컴파일러가 모두 보았기 때문에). 그러나 #if에서는 그렇지 않습니다: 플래그가 꺼져 있으면 해당 분기는 엘프어로 써져 있어도 컴파일러가 보지 못하고 불평하지 않습니다.

의도적으로 잘못된 예를 보여드리겠습니다:

#include <iostream>

int main() {
#if 0
    std::cout << doesNotExist(123) << '\n'; // 이 함수는 선언되어 있지 않음
#endif
    std::cout << "Hello\n"; // Hello
}

현재는 #if 0이므로 모든 것이 '정상'입니다. 하지만 #if를 1로 바꿔버리면 갑자기 컴파일 오류가 발생합니다. 따라서 조건부 컴파일은 코드를 숨기는 수단이 아니라 구성 도구이며, 규율이 필요합니다.

8. 실용 팁: #if 0와 #endif 주석

조건부 컴파일에는 두 가지 매우 실용적인 요령이 있습니다: 큰 블록을 임시로 '끄는' 것과 긴 조건의 가독성을 유지하는 것.

#if 0를 '슈퍼 주석'처럼 사용하기

때로는 실험을 위해 큰 코드 덩어리를 빠르게 끄고 싶을 때가 있습니다. 블록을 주석 처리할 수도 있지만, 내부에 이미 주석이 있으면 주석을 닫는 것이 번거로울 수 있습니다. 그럴 때 #if 0 ... #endif 트릭을 사용하면 전처리기가 텍스트를 통째로 제거합니다.

예:

#include <iostream>

int main() {
#if 0
    std::cout << "Temporary disabled block\n";
    std::cout << "More lines...\n";
#endif
    std::cout << "Main path\n"; // Main path
}

이걸 남용하면 안 됩니다. 이런 블록이 몇 주 동안 살아 있다면 '코드 묘지'가 된 것이고, 코드 묘지는 Git에 보관하고 main.cpp에는 두지 않는 것이 좋습니다.

#endif에 주석 달기 — 블록이 세 줄 이상이면 필수

코드에 #if/#ifdef가 나타나면 어디서 열고 닫았는지 헷갈리기 쉽습니다. 그래서 긴 블록이나 중첩된 블록의 경우 #endif에 주석을 다는 습관이 큰 도움이 됩니다.

예:

#if defined(_WIN32)
    // Windows-specific code
#else
    // POSIX-like code
#endif // defined(_WIN32)

이건 언어 규칙이 아니라 생존 규칙입니다 — 특히 반년 뒤 파일을 열 때 큰 차이를 만듭니다.

9. 실용 미니 예제: #ifdef으로 만든 TaskBook 로거

이제 실제 애플리케이션의 일부처럼 보이는 코드 조각을 만들어봅시다. TaskBook에는 릴리스 모드에서는 전혀 존재하지 않는 간단한 로거 logDebug가 필요합니다.

logger.hpp를 만듭시다:

// logger.hpp
#pragma once

void logDebug(const char* msg);

logger.cpp:

// logger.cpp
#include <iostream>
#include "config.hpp"
#include "logger.hpp"

void logDebug(const char* msg) {
#ifdef APP_DEBUG
    std::cout << "[debug] " << msg << '\n';
#else
    (void)msg; // 사용되지 않는 매개변수에 대해 경고가 발생하지 않도록
#endif
}

그리고 main.cpp:

#include <iostream>
#include "logger.hpp"

int main() {
    logDebug("program started"); // APP_DEBUG가 정의된 경우에만 출력됨
    std::cout << "TaskBook\n";    // TaskBook
}

학습 수준에서 좋은 절충안입니다: 복잡한 아키텍처를 다루지는 않지만, #ifdef가 프로그램을 두 가지 모드로 나누는 데 어떻게 도움이 되는지 보여줍니다.

10. 조건부 컴파일 시 흔한 실수들

실수 #1: #if와 if를 혼동하고 일반 변수를 검사하려고 함.
자주 있는 상황: 학생이 #if x > 0 같은 것을 쓰는데, 여기서 x는 C++ 변수입니다. 전처리기는 변수에 대해 알지 못합니다 — 전처리기는 컴파일러보다 앞서 동작합니다. #if에서는 숫자, 매크로 및 그들의 표현식만 사용할 수 있습니다. 런타임 값 검사는 일반 if로 해야 합니다.

실수 #2: '꺼져 있는' 분기도 컴파일러가 검사한다고 생각함.
조건이 거짓이면 전처리기가 텍스트를 잘라내므로 컴파일러는 그 텍스트를 보지 않습니다. 이 때문에 '죽은' 코드가 쌓여서 오랫동안 컴파일되지 않을 수 있습니다. 중요한 분기라면 주기적으로 켜서 검증해야 합니다.

실수 #3: 프로젝트 곳곳에 플래그를 흩뿌리고 한 곳에 모아두지 않음.
예를 들어 #define FEATURE_X가 어떤 .cpp에 있고, 다른 파일에선 #ifdef로 그 플래그를 체크한다면 전체 구성을 이해하기 어렵습니다. 플래그를 하나의 config.hpp에 모아두고 필요한 곳에서 포함하는 것이 훨씬 낫습니다. 학습용 프로젝트나 초기 실제 프로그램에는 특히 유효한 접근입니다.

실수 #4: 너무 큰 #if 블록을 만들어 가독성을 잃음.
조건부 컴파일은 작은 차이를 감싸는 데 적합합니다: 몇 줄, 작은 구현 부분, 헤더 포함. 파일의 절반을 #if로 감싸면 코드는 두 개의 병렬 현실이 되어 유지보수가 어려워집니다. 어떤 때는 동일한 인터페이스를 가진 두 개의 작은 함수를 만들고 한 곳에서만 #if로 구현을 선택하는 편이 낫습니다.

실수 #5: 지시문의 짝을 잊어버려 중첩을 깨뜨림.
잘못된 #endif나 빠진 #endif는 전혀 예상치 못한 곳에서 에러를 유발할 수 있습니다. 최종 텍스트가 눈으로 보던 것과 달라질 수 있으므로, 컴파일러가 이상하게 불평한다면 최근에 수정한 #if/#ifdef 블록의 짝을 먼저 확인하세요.

이전 이전 레슨

다음 다음 레슨

코멘트

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION