인라인 함수

inline 키워드는 흔히 "함수 호출을 본문으로 바꿔 넣어 빠르게 만드는 키워드"로 소개되지만, 현대 C++에서 inline이 실제로 정하는 것은 함수의 정의를 어디에, 몇 번 둘 수 있는지에 관한 규칙입니다. 호출 자리에 본문을 펼치는 인라인 확장(inline expansion)은 컴파일러의 최적화기가 따로 판단하며, 키워드가 있어도 호출이 남을 수 있고 없어도 펼쳐질 수 있습니다.

이 글은 먼저 함수의 정의와 호출의 선언과 정의를 세 파일로 나누어, 여러 .cpp 파일이 함수를 함께 쓰는 방법을 봅니다. 그다음 정의를 헤더로 옮길 때 inline이 필요한 이유, 실제 인라인 확장을 확인하는 방법, inline이 대신하는 함수형 매크로의 문제를 정리합니다.

inline 함수 선언

함수 앞에 inline 지정자를 붙이면 인라인 함수가 됩니다. 아래 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

출력은 함수가 돌려준 값일 뿐, 호출이 본문으로 펼쳐졌는지는 알려 주지 않습니다. 이 프로그램처럼 파일이 하나뿐이면 inline을 빼도 결과와 동작이 같습니다. inline의 의미는 여러 파일이 같은 함수를 쓸 때 드러납니다.

여러 파일에서 일반 함수 쓰기

각 .cpp 파일은 포함한 헤더의 내용과 합쳐져 따로 컴파일되는데, 이 단위를 번역 단위(translation unit)라고 합니다. 아래 예에서는 main.cpp와 my_math.cpp가 각각 번역 단위가 됩니다. 일반 함수는 헤더에 선언하고, 정의는 한 .cpp 파일에만 둡니다.

#pragma once

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

#include "my_math.h"

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

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

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

int main() {
    std::cout << "sum: " << add(10, 20) << '\n';
    std::cout << "from other file: " << addFromOtherFile() << '\n';
}

컴파일과 실행 과정에서 본 것처럼, 두 .cpp를 각각 목적 파일로 컴파일한 뒤 함께 링크합니다. 헤더는 각 소스에 포함될 뿐 따로 컴파일하거나 링크하지 않습니다.

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

sum: 30
from other file: 70

main.cpp는 헤더의 선언만 보고 add를 호출하는 코드를 만들고, 링커가 my_math.o에 있는 정의와 연결합니다. 링크 명령에서 my_math.o를 빼면 정의를 찾지 못한 링크 오류가 나므로, 에디터에서 현재 파일만 빌드하는 설정이라면 개발 환경 설정의 안내대로 두 소스를 모두 넘깁니다.

정의를 헤더로 옮기기

이번에는 add의 정의를 헤더에 두어, 두 번역 단위가 같은 정의를 함께 보게 합니다. 이렇게 하려면 정의에 inline을 붙여야 합니다.

#pragma once

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

int addFromOtherFile();

#include "my_math.h"

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

main.cpp는 그대로 두고 같은 명령으로 다시 빌드하면 출력은 여전히 sum: 30과 from other file: 70입니다. 헤더로 옮긴 add의 정의는 my_math.cpp에서 지워야 하며, addFromOtherFile은 여전히 선언만 헤더에 있는 일반 함수입니다.

그림처럼 같은 헤더를 포함한 두 번역 단위가 각각 목적 파일을 만들고, 두 목적 파일이 하나의 실행 파일로 링크됩니다. 이제 add의 정의가 두 번역 단위에 모두 들어가는데, C++에는 프로그램 전체에서 함수의 정의가 하나여야 한다는 단일 정의 규칙(ODR, One Definition Rule)이 있습니다. inline 함수는 이 규칙의 예외여서, 모든 정의가 공백과 주석을 빼고 같은 코드로 이루어지고 그 안의 이름도 같은 것을 가리키면 여러 번역 단위에 정의를 둘 수 있으며, 프로그램에서는 주소가 하나인 같은 함수로 취급됩니다.

#pragma once는 한 번역 단위 안에서 같은 헤더가 두 번 포함되는 것을 막을 뿐입니다. 서로 다른 .cpp가 같은 헤더를 포함하는 것은 막지 않으므로, 헤더에 본문을 둔 함수의 중복 정의 문제는 #pragma once가 아니라 inline이 해결합니다.

정의가 겹치거나 어긋날 때

헤더로 옮긴 뒤에도 my_math.cpp에 옛 add 정의를 남기면, 그 번역 단위 안에 같은 함수의 정의가 두 개 생겨 컴파일 단계에서 중복 정의 오류가 납니다. 반대로 헤더에 본문을 둔 채 inline만 지우면, 두 번역 단위에 일반 함수 add의 정의가 하나씩 생깁니다. 보통은 링크 단계에서 같은 정의가 여러 개라는 오류가 나지만, 표준은 여러 번역 단위에 걸친 이런 위반을 반드시 진단하라고 요구하지 않습니다.

더 찾기 어려운 경우는 inline 정의의 내용이 번역 단위마다 다를 때입니다. 헤더의 add를 고친 뒤 한쪽 소스만 다시 컴파일하면, 옛 정의로 만든 목적 파일과 새 정의로 만든 목적 파일이 섞입니다. 이것은 단일 정의 규칙을 어긴 것이어서 진단 없이 링크될 수 있고, 어느 정의가 쓰일지 알 수 없습니다. 헤더를 고치면 그 헤더를 포함한 모든 소스를 다시 컴파일해야 하며, 보통은 빌드 도구가 이를 맡습니다.

암시적으로 inline인 것들

inline을 직접 적지 않아도 인라인으로 취급되는 함수가 있습니다. constexpr 함수와, 클래스 정의 안에 본문을 함께 적은 멤버 함수가 그렇습니다. 그래서 이런 함수는 헤더에 정의를 두어 여러 파일에서 써도 중복 정의가 되지 않습니다. C++17부터는 변수에도 inline을 붙일 수 있어, 헤더에 정의한 전역 변수를 여러 파일이 하나의 변수로 함께 쓸 수 있습니다.

함수 템플릿도 보통 헤더에 정의를 두지만, 이것은 템플릿 자체의 규칙으로 허용되므로 inline을 붙일 필요는 없습니다. 또 C++20의 모듈(module) 안에 정의한 함수는 클래스 안에 정의해도 암시적으로 inline이 되지 않는 등 규칙이 다르므로, 이 글의 설명은 헤더와 소스 파일로 나누는 일반적인 구성에 한합니다.

실제 인라인 확장은 컴파일러가 정합니다

호출 자리에 함수 본문을 펼치는 인라인 확장은 최적화기가 호출 지점마다 판단합니다. 본문의 크기, 그 호출이 얼마나 자주 실행되는지, 펼친 뒤 상수 계산이나 분기 제거로 더 줄어드는지, 최적화 수준과 대상 CPU, 그리고 본문을 복사해 늘어나는 코드 크기를 함께 봅니다.

그래서 inline을 붙여도 펼쳐지지 않을 수 있고, inline이 없는 일반 함수도 같은 번역 단위에서 호출되면 펼쳐질 수 있습니다. 링크 시간 최적화(LTO, -flto)를 켜면 다른 .cpp에 정의한 일반 함수도 펼쳐질 수 있습니다. 재귀 함수나 함수 포인터를 통한 호출도 경우에 따라 일부가 펼쳐지므로, 함수의 모양 하나만으로 결과를 단정하지 않습니다.

최적화를 끈 -O0 빌드는 보통 호출을 그대로 두고, -O2 이상에서 인라인 확장이 활발해집니다. GCC는 -fopt-info-inline-optimized로 펼친 호출을, -fopt-info-inline-missed로 펼치지 않은 호출과 그 이유를 보고합니다. 실제로 펼쳐졌는지 알려면 이런 최적화 보고나 생성된 어셈블리를 확인해야 합니다.

더 깊이: 표준의 힌트 문구와 컴파일러별 강제 지정

표준 문서에는 inline의 원래 뜻도 남아 있습니다. 표준 초안의 inline 절은 inline 지정자가 호출 지점에서 본문을 대신 넣는 편이 보통의 호출보다 낫다는 것을 구현에 알린다고 하면서, 구현이 그렇게 할 의무는 없다고 함께 적습니다. 그래서 inline은 지금도 힌트이기는 하지만 따를지는 컴파일러가 정하고, 반드시 지켜지는 것은 이 글에서 본 정의의 규칙입니다. GCC는 -O2부터 inline이 없는 함수도 인라인 후보로 보는 -finline-functions를 켜므로, 힌트의 영향은 더 작아집니다.

힌트보다 강하게 정하고 싶을 때는 컴파일러마다 다른 확장을 씁니다. GCC의 __attribute__((always_inline))은 inline으로 선언한 함수를 다른 인라인 제한과 상관없이 펼치게 하고, 펼치지 못하면 오류로 알립니다. 반대로 __attribute__((noinline))은 그 함수를 인라인 후보에서 빼며, 함수 사이의 다른 최적화도 일부 꺼집니다. Clang도 두 속성을 지원합니다.

MSVC에는 __forceinline과 [[msvc::forceinline]]이 있지만, Microsoft 문서는 이것으로도 인라인 확장을 강제할 수는 없다고 밝힙니다. 디버그 빌드의 기본값인 /Ob0로 컴파일했거나, 함수가 가변 인자를 받거나, 함수 포인터를 통해 부르는 경우에는 펼쳐지지 않습니다. 펼치지 못하면 수준 1 경고를 내지만, /Od나 /Ob0로 컴파일했거나 함수가 다른 번역 단위에 정의되었거나 간접 호출의 대상인 경우에는 경고하지 않습니다. 어느 컴파일러든 강제 지정은 측정으로 효과를 확인한 좁은 곳에만 씁니다.

함수형 매크로와 비교

C와 오래된 C++ 코드에서는 호출 비용을 피하려고 함수 모양의 매크로를 쓰기도 했습니다. 아래 두 매크로는 모두 인자를 제곱하려는 것인데, SQUARE는 인자와 전체 식을 괄호로 감쌌고 BAD_SQUARE는 괄호가 없다는 점만 다릅니다.

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

매크로는 함수가 아니라, 컴파일 전의 전처리 단계에서 글자를 바꿔 넣는 것입니다. SQUARE(1 + 2)는 ((1 + 2) * (1 + 2))가 되어 9이지만, 괄호를 빠뜨린 BAD_SQUARE(1 + 2)는 1 + 2 * 1 + 2가 되어 연산자 우선순위에 따라 5가 됩니다. 매크로에는 타입 검사가 없고, 이름 공간도 무시하며, 오류가 펼쳐진 코드에서 보고되어 원인을 찾기도 어렵습니다.

인자가 여러 번 계산되는 것도 문제입니다. SQUARE(i++)는 ((i++) * (i++))가 되어 한 식에서 i를 두 번 바꾸므로 정의되지 않은 동작입니다. 함수는 인자를 한 번만 계산하므로 이런 문제가 없습니다. 조건부 컴파일처럼 전처리기가 꼭 필요한 일이 아니라면, 매크로 대신 일반 함수나 constexpr 함수, 함수 템플릿을 씁니다.

성능을 확인하는 순서

성능 때문에 인라인 확장을 검토한다면 inline을 늘리는 것부터 시작하지 않습니다. 아래 그림처럼 작고 자주 실행되는 함수는 좋은 후보일 수 있지만, 큰 함수를 여러 곳에 펼치면 실행 파일이 커지고 명령어 캐시 부담이 늘어 오히려 느려질 수 있습니다.

먼저 실제로 배포할 최적화 옵션과 대표적인 입력으로 빌드를 고정하고, 프로파일러로 시간이 많이 드는 호출 지점을 찾습니다. 그다음 최적화 보고나 어셈블리로 그 호출이 펼쳐졌는지와 펼쳐지지 않은 이유를 확인하고, 실행 시간과 함께 실행 파일의 크기도 비교합니다. 측정 없이 붙인 inline은 성능에 아무 영향이 없거나, 헤더 의존성만 늘릴 수 있습니다.

정리

• inline이 정하는 것은 정의의 배치 규칙이며, 같은 inline 정의를 여러 번역 단위에 둘 수 있게 합니다.
• 일반 함수는 헤더에 선언하고 정의를 한 .cpp에 두며, 헤더에 본문을 두려면 inline이 필요합니다.
• #pragma once는 한 번역 단위 안의 중복 포함만 막고, 여러 번역 단위의 중복 정의는 막지 않습니다.
• 번역 단위마다 다른 inline 정의는 단일 정의 규칙 위반이며 진단되지 않을 수 있으므로, 헤더를 고치면 포함한 모든 소스를 다시 컴파일합니다.
• 호출을 본문으로 펼치는 인라인 확장은 최적화기가 정하며, GCC의 -fopt-info-inline 보고나 어셈블리로 확인합니다.
• 함수형 매크로는 타입 검사가 없고 인자를 여러 번 계산할 수 있으므로, 일반 함수나 constexpr 함수로 대신합니다.

연습 문제

1. 헤더를 고친 뒤 다시 빌드하기

inline 버전 헤더의 add 본문을 return a + b + 1;로 바꾸고 두 소스를 모두 다시 컴파일해 링크하면 출력은 무엇인가요? 한쪽 소스만 다시 컴파일하면 왜 문제가 되나요?

2. 괄호 없는 매크로

BAD_SQUARE(1 + 2), SQUARE(1 + 2), 10 / SQUARE(2)의 값은 각각 무엇인가요?

3. inline을 지운 헤더

inline 버전 헤더에서 inline만 지우면 빌드는 어떻게 되나요? main.cpp 하나만 이 헤더를 포함하는 프로그램이었다면 어떤가요?

다음 글 기본 매개변수에서는 인자를 생략하면 미리 정한 값이 들어가는 기본 매개변수와, 그것을 선언할 위치를 다룹니다.