인라인 함수

여러 .cpp 파일에서 같은 함수를 쓰려면 선언과 정의를 어디에 둘지 먼저 정해야 합니다. 앞 절의 함수 선언과 정의를 세 파일로 나누어 살펴보겠습니다.

inline은 함수 정의를 공유할 때 지켜야 할 언어 규칙에 영향을 줍니다. 최적화기(optimizer)가 호출을 함수 본문으로 펼치는 실제 인라인화는 별도의 판단입니다. 키워드가 있어도 호출이 남을 수 있고, 없어도 호출이 펼쳐질 수 있습니다.

함수 호출에는 호출·복귀와 호출 규약에 따른 비용이 생길 수 있지만, 소스의 호출이 항상 별도 스택 프레임이나 기계어 call 명령으로 이어지는 것은 아닙니다. 먼저 파일 배치를 이해한 뒤 성능 판단을 살펴보겠습니다.

인라인 함수란 무엇인가?

함수 선언에 inline 지정자를 붙이면 inline 함수를 선언합니다.

inline 반환타입 함수이름(매개변수타입1 매개변수이름1, ...) {
    // 함수 몸체
}

다음 예제의 getMax는 inline 함수이지만, 이 키워드만 보고 실제 기계어가 호출 치환 형태라고 단정할 수는 없습니다.

#include <iostream>

inline int getMax(int a, int b) {
    return (a > b) ? a : b;
}

int main() {
    int x = 10;
    int y = 20;

    std::cout << getMax(x, y) << '\n';
    std::cout << getMax(50, 30) << '\n';
}

이 예제의 예상 출력은 20과 50입니다. 이 값은 함수가 반환하는 결과이며 실제 호출 치환 여부를 알려 주지는 않습니다.

헤더와 .cpp 경계를 정확히 나누기

보통 각 .cpp는 포함한 헤더 내용과 함께 하나의 번역 단위(translation unit)가 됩니다. 아래에서는 main.cpp와 my_math.cpp를 각각 처리하므로 번역 단위가 두 개입니다.

일반 함수의 세 파일

일반 외부 함수는 헤더에 선언하고 한 .cpp에 정의할 수 있습니다. main.cpp는 add를 직접 호출하고, my_math.cpp의 addFromOtherFile도 같은 add를 호출하도록 만듭니다.

#pragma once

int add(int a, int b);
int addFromOtherFile();

#include "my_math.h"

// add의 정의는 프로그램의 이 한 곳에 둡니다.
int add(int a, int b) {
    return a + b;
}

int addFromOtherFile() {
    return add(30, 40);
}

#include <iostream>
#include "my_math.h"

int main() {
    int sum = add(10, 20);
    std::cout << "합계: " << sum << '\n';
    std::cout << "다른 파일의 합계: " << addFromOtherFile() << '\n';
}

세 파일을 같은 폴더에 저장합니다. 앞 장의 GCC 환경에서는 두 .cpp를 각각 목적 파일(object file)로 만들고 함께 링크하는 과정을 다음 명령으로 나눠 볼 수 있습니다. 헤더는 각 소스에 포함되며, 별도 목적 파일로 만들어 링크하는 입력이 아닙니다.

g++ -std=c++20 -Wall -Wextra -c main.cpp -o main.o
g++ -std=c++20 -Wall -Wextra -c my_math.cpp -o my_math.o
g++ main.o my_math.o -o inline_demo.exe
.\inline_demo.exe

-c는 목적 파일을 만든 뒤 링크 전에 멈춥니다. 마지막 g++ 명령이 두 목적 파일과 필요한 라이브러리를 연결해 실행 파일을 만듭니다. 예상 출력은 다음과 같습니다.

합계: 30
다른 파일의 합계: 70

add의 정의를 둔 목적 파일이 링크 입력에서 빠졌는지 먼저 확인하면 정의를 찾지 못하는 링크 오류를 좁힐 수 있습니다. 에디터의 현재 파일만 빌드하는 설정이라면 두 소스를 명시해야 한다는 개발 환경 설정의 안내도 확인합니다.

같은 파일을 inline 정의로 바꾸기

이번에는 add의 정의를 헤더에 둡니다. main.cpp와 my_math.cpp가 모두 이 헤더를 포함하면 두 번역 단위에서 같은 inline 정의를 사용할 수 있습니다.

#pragma once

inline int add(int a, int b) {
    return a + b;
}

int addFromOtherFile();

헤더로 옮긴 add의 정의를 my_math.cpp에도 남기면 안 됩니다. 앞의 my_math.cpp 내용은 다음으로 대체하고, main.cpp는 그대로 사용합니다.

#include "my_math.h"

int addFromOtherFile() {
    return add(30, 40);
}

두 소스를 같은 명령으로 다시 컴파일하고 새 목적 파일을 링크합니다. 예상 출력은 여전히 30과 70입니다. addFromOtherFile은 선언만 헤더에 두고 한 .cpp에 정의한 일반 함수로 남습니다.

#pragma once는 이 툴체인에서 한 번역 단위 안의 반복 include를 막는 장치입니다. 서로 다른 .cpp에서 같은 헤더를 포함하는 것까지 막거나 프로그램 전체의 중복 정의 규칙을 해결하지는 않습니다.

헤더에 포함된 inline 정의는 여러 번역 단위에 있어도 ODR(One Definition Rule, 단일 정의 규칙)의 일치 요건을 만족하면 허용됩니다. 이 예제처럼 같은 헤더를 공유하되 정의의 토큰과 그 안에서 찾는 이름의 의미도 일치해야 합니다. 프로그램에서는 주소가 하나인 단일 함수로 취급하며, 특정 링커가 중복 기계 코드를 합치는 동작에만 기대는 규칙이 아닙니다.

출력이 같다는 사실은 호출이 실제로 펼쳐졌다는 증거가 아닙니다. 목적 파일의 구체적인 함수 코드나 심볼 배치도 최적화에 따라 달라질 수 있습니다. inline은 정의 배치의 규칙을 바꾸며, 호출 치환과 성능은 뒤에서 따로 판단합니다.

세 파일을 직접 변경하고 다시 만들기

inline 헤더의 add 본문만 return a+b+1;로 바꾸세요. 다른 소스는 그대로 두고 두 목적 파일을 모두 새로 컴파일한 뒤 다시 링크하면 두 출력 값은 무엇인가요? 헤더를 포함하는 소스 한쪽만 재컴파일하면 왜 이 연습의 올바른 비교가 되지 않나요?

정의가 겹치거나 보이지 않을 때

inline 헤더로 바꾼 뒤 옛 my_math.cpp의 add 정의까지 남기면, 그 번역 단위에는 헤더의 정의와 소스의 정의가 함께 들어갑니다. 같은 번역 단위의 중복 정의는 진단 대상이며 보통 컴파일 단계에서 재정의 오류가 나타납니다. 표준이 요구하는 것은 진단이고, 오류 문구나 도구가 반드시 빌드를 중단하는 방식까지 고정하지는 않습니다.

반대로 헤더에 본문을 둔 채 inline만 없애면 두 번역 단위에 일반 외부 함수 add의 정의가 생깁니다. 보통 링크 단계에서 다중 정의 오류가 나지만, 이 교차 번역 단위 ODR 위반은 표준상 진단이 보장되지 않습니다. 우연히 링크됐다고 올바른 정의 배치로 판단하지 않습니다.

다른 번역 단위에서 inline으로 선언하고 사용하는 함수의 정의를 한 .cpp에만 숨기는 것도 정상적인 일반 호출 전환이 아닙니다. 호출하는 쪽의 정의 도달성 규칙을 위반하며 진단이 보장되지 않을 수 있습니다. 일반 함수로 분리할지, inline 정의를 헤더로 공유할지 한 방식으로 맞춥니다.

template <typename T>
T sum(T a, T b) {
    return a + b;
}

optimizer는 호출 지점마다 다시 판단한다

실제 인라인화는 보통 다음 정보를 함께 사용합니다.

• 함수 본문의 크기와 제어 흐름.
• 호출 지점이 실제로 자주 실행되는지에 대한 정적 추정이나 profile 정보.
• caller에서 보이는 상수 인자와 치환 뒤 가능한 상수 전파·분기 제거.
• target, 최적화 수준, PGO(Profile-Guided Optimization)와 LTO(Link-Time Optimization) 설정.
• 본문 복제로 늘어나는 binary 크기와 instruction-cache 비용.

작고 자주 실행되는 함수는 좋은 후보일 수 있지만, 함수 크기나 호출 형태 하나만으로 결과가 정해지지는 않습니다.

• 재귀 호출을 무한히 펼칠 수는 없어도, 비재귀 호출 지점이나 제한된 깊이, 일부 경로를 인라인화할 수 있습니다.
• 함수 포인터나 virtual 호출도 target을 알아내거나 devirtualize할 수 있다면 직접 호출로 바뀐 뒤 후보가 될 수 있습니다.
• 큰 for 루프, switch 또는 복잡한 제어 흐름은 비용을 높일 수 있지만 절대적인 비인라인 조건은 아닙니다.
• 정상적으로 한 .cpp에 정의한 일반 함수도 LTO가 번역 단위 정보를 결합하면 cross-TU 인라인화가 가능할 수 있습니다. 이는 inline 함수의 정의 reachability 규칙을 대신하지 않습니다.

따라서 getMax처럼 짧은 함수도 “인라인화될 가능성이 있는 후보”라고 표현해야 하며, 최종 결과는 해당 compiler·옵션·호출 지점의 최적화 기록이나 생성 코드를 확인해야 합니다.

인라인 함수와 함수형 매크로

C와 오래된 C++ 코드에서는 호출 모양을 만들기 위해 함수형 매크로를 사용하기도 합니다.

#define SQUARE(x) ((x) * (x))

매크로는 함수가 아니라 preprocessing 단계의 텍스트 치환입니다.

• 타입과 scope 규칙이 약함: 함수 overload, parameter type checking, namespace와 같은 언어 기능을 그대로 제공하지 않습니다.
• 인자를 여러 번 평가할 수 있음: SQUARE(i++)는 i++를 두 번 치환하며, 이 예제는 unsequenced modification으로 undefined behavior가 됩니다.
• 진단과 디버깅이 어려움: 오류가 확장된 토큰에서 나타나고 일반 함수처럼 단계별 호출을 추적하기 어렵습니다.

함수는 각 인자 표현식을 한 번씩 평가하고 C++의 type·scope 규칙을 따릅니다. preprocessing이 꼭 필요한 조건부 컴파일, 문자열화 또는 token 결합이 아니라면 일반 함수, constexpr 함수나 함수 template을 먼저 선택합니다.

후보 선정과 측정

실제 인라인화를 검토할 때는 inline 표기부터 늘리지 말고 다음 순서를 따릅니다.

1. 실제 target과 release 최적화 옵션, LTO·PGO 설정, 대표 입력을 고정합니다.
2. profiler로 hot call site를 찾습니다.
3. compiler optimization remark나 생성 assembly에서 실제 치환 여부와 미치환 이유를 확인합니다.
4. runtime과 함께 binary 크기, instruction-cache 지표를 비교합니다.

핵심은 두 문장으로 정리할 수 있습니다.

• 헤더의 inline 정의는 정의 도달성과 ODR을 위한 언어 계약입니다.
• 성능을 위한 실제 인라인화는 optimizer가 호출 지점별로 수행하고, 개발자는 측정으로 결과를 확인합니다.