컴파일과 실행 과정

이전 장에서는 첫 C++ 프로그램의 작성, 컴파일, 실행 흐름을 확인했습니다.

단순히 코드를 작성하고 실행하는 것을 넘어 우리가 작성한 소스 코드가 컴퓨터에서 실제로 동작하는 실행 파일이 되기까지 어떤 과정을 거치는지 이해하는 것은 C++ 프로그래밍을 깊이 있게 이해하는 데 매우 중요합니다.

이 장에서는 C++ 소스 코드가 프로그램으로 변환되고 실행되는 전반적인 과정, 즉 컴파일(Compilation)과 링크(Linking) 과정의 단계와 산출물을 정리합니다.

소스 코드가 전처리, 컴파일, 어셈블, 링크를 거쳐 실행 파일로 완성되는 흐름과 각 단계의 산출물을 한눈에 정리합니다.

g++ -E main.cpp -o main.ii

g++ -S main.ii -o main.s

g++ -c main.s -o main.o

g++ main.o -o hello.exe

g++ -E main.cpp -o main.ii

g++ -S main.ii -o main.s

g++ -c main.s -o main.o

g++ main.o -o hello.exe

왜 컴파일이 필요한가?

우리가 작성하는 C++ 코드는 사람이 이해하기 쉬운 고급 언어(High-level Language)로 표현됩니다.

하지만 컴퓨터의 중앙처리장치(CPU)는 0과 1로 이루어진 기계어(Machine Code)만을 직접 이해하고 실행할 수 있습니다.

따라서 우리가 작성한 C++ 코드를 컴퓨터가 이해할 수 있는 기계어로 변환해 주는 과정이 반드시 필요합니다.

이 역할을 수행하는 것이 바로 컴파일러(Compiler)입니다.

컴파일러는 C++ 소스 코드를 읽어 들여 문법 오류를 검사하고, 오류가 없다면 이를 기계어로 번역하여 목적 파일(Object File)을 생성합니다.

목적 파일은 아직 완전한 실행 파일이 아니며, 여러 조각의 기계어 코드와 참조 정보들을 담고 있습니다.

컴파일 과정의 단계별 이해

C++ 컴파일 과정은 크게 네 가지 단계로 나누어 볼 수 있습니다.

여러분이 g++ hello_world.cpp -o hello_world와 같은 명령어를 입력할 때, 내부적으로 이 모든 과정이 순차적으로 진행됩니다.

g++ -E hello_world.cpp -o hello_world.ii

g++ -S hello_world.ii -o hello_world.s

g++ -S hello_world.cpp -o hello_world.s

g++ -c hello_world.s -o hello_world.o

g++ -c hello_world.cpp -o hello_world.o

g++ hello_world.o -o hello_world

오류가 날 때는 네 단계 중 어디에서 멈췄는지를 먼저 잡아야 합니다.

정적 링크와 동적 링크

링크 과정에서 라이브러리를 연결하는 방식은 크게 두 가지로 나눌 수 있습니다.

• 정적 링크 (Static Linking)
  • 라이브러리 코드가 최종 실행 파일 안에 직접 포함됩니다.
  • 장점: 정적으로 포함한 라이브러리의 별도 파일을 배포할 필요가 줄어듭니다. 다른 동적 의존성과 운영체제·ABI 요구까지 없어지는 것은 아닙니다.
  • 단점: 실행 파일의 크기가 커집니다. 동일한 라이브러리를 사용하는 여러 프로그램이 있더라도 각각의 실행 파일에 라이브러리 코드가 중복되어 포함됩니다. 라이브러리 업데이트를 반영하려면 적어도 다시 링크해야 하며, 인터페이스 변경은 재컴파일도 요구할 수 있습니다.
• 동적 링크 (Dynamic Linking)
  • 라이브러리 코드가 실행 파일에 직접 포함되지 않고, 실행 시점에 운영체제에 의해 메모리에 로드됩니다. 실행 파일에는 필요한 심벌과 동적 의존성·재배치 정보 등이 남습니다.
  • 장점: 실행 파일의 크기가 작습니다. 동일한 라이브러리를 여러 프로그램이 공유할 수 있어 메모리 사용이 효율적입니다. 호환되는 ABI를 유지한 라이브러리는 실행 파일을 다시 빌드하지 않고 교체할 수 있습니다. 배포 경로와 버전 호환은 확인해야 합니다.
  • 단점: 실행 파일이 동작하려면 해당 라이브러리 파일(Windows의 .dll, macOS의 .dylib, Linux의 .so)이 시스템에 존재해야 합니다. 라이브러리 버전에 따라 호환성 문제가 발생할 수도 있습니다 (DLL Hell).

대부분의 현대 운영체제에서는 동적 링크를 기본으로 사용합니다.

이는 디스크 공간과 메모리 효율성, 그리고 라이브러리 업데이트의 용이성 때문입니다.

정적 링크와 동적 링크는 “무엇을 실행 파일 안에 넣을 것인가”를 정하는 배포 전략이기도 합니다.

실행 파일 크기, 의존 파일 관리, 업데이트 방식, 실행 환경 진단을 함께 비교하면 링크 방식을 더 실무적으로 판단할 수 있습니다.

오류의 종류: 컴파일 오류 vs 런타임 오류

프로그래밍을 하다 보면 필연적으로 오류(Error)를 만나게 됩니다.

먼저 번역 중 발생하는 컴파일 오류와 실행이 시작된 뒤의 문제를 비교합니다. 그 사이의 링크 오류도 별도로 구분해야 합니다.

컴파일 오류는 컴파일러의 친절한 메시지를 통해 비교적 쉽게 수정할 수 있지만, 런타임 오류는 프로그램의 동작을 분석하고 디버깅(Debugging) 도구를 사용하여 원인을 찾아내야 하므로 해결하기가 더 까다로울 수 있습니다.

오류를 만났을 때는 메시지에 포함된 단어와 실행 파일 생성 여부를 기준으로 전처리, 컴파일, 링크, 런타임 중 어디에서 멈췄는지 먼저 나누면 수정 위치를 빠르게 좁힐 수 있습니다.

단계별 명령은 GCC의 출력 제어 옵션의 -E, -S, -c에 대응합니다. 위 명령은 컴파일러의 기본 언어 표준을 사용합니다. 개발 환경 설정 절처럼 C++20을 명시하려면 전처리 명령과 .ii를 컴파일하는 명령에 모두 -std=c++20을 추가합니다. 전처리 때 선택한 표준에 따라 헤더 내용도 달라질 수 있으므로 두 단계의 조건을 맞춥니다. 이미 작성한 hello_world.cpp로 위 명령을 차례대로 실행하고, 각 명령 뒤에 .ii, .s, .o, 실행 파일 중 무엇이 새로 생겼는지 확인해 보세요. .o까지 성공해도 아직 실행 파일은 없다는 것이 핵심입니다.

예시

다음 파일은 twice라는 함수의 이름과 사용 방법만 선언하고, 실제 계산을 수행하는 정의는 제공하지 않습니다. 뒤의 함수 장에서 선언과 정의를 자세히 다루지만, 지금은 ‘이런 함수를 쓸 수 있다’는 정보와 ‘그 함수가 수행할 코드’가 다르다는 점을 관찰합니다.

int twice(int value);

int main() {
    return twice(2);
}

g++ -c missing_definition.cpp -o missing_definition.o는 목적 파일을 만들 수 있습니다. 그러나 g++ missing_definition.o -o missing_definition은 함수의 정의를 찾지 못해 링크에서 실패합니다. 진단 표현은 툴체인마다 다르지만 GCC에서는 undefined reference가 대표적입니다. 이 사례에서는 실행이 시작되지 않았으므로 런타임 오류로 분류하지 않습니다.

혼자 분류해 보세요. 출력문에서 세미콜론을 빼서 번역이 멈춘 경우, 위처럼 함수 정의가 빠진 경우, 정상 빌드된 프로그램이 합계 대신 다른 계산 결과를 출력하는 경우는 각각 어느 단계의 문제일까요? 마지막 경우에 빌드 옵션부터 바꾸어야 하는지도 생각해 보세요.

첫째는 컴파일 단계, 둘째는 링크 단계, 셋째는 실행 결과를 요구와 비교해 찾는 논리 오류입니다. 셋째는 프로그램이 정상 상태로 종료할 수도 있으므로, 종료 상태 0만으로 계산이 맞았다고 판단할 수 없습니다.