loooong 님의 블로그

[UE5 개발일지] 친구 합류와 구조 완료를 분리하기 — 이벤트와 Actor 생명주기 정리

loooong — Wed, 16 Sep 2026 17:09:02 +0900

친구를 발견하면 편대에 합류해 플레이어를 따라오고, 함께 있는 동안 공동 최대 HP 보너스를 제공한다. 하지만 합류만으로 구조가 끝나는 것은 아니다. 안전지대까지 데려가 파견해야 구조가 완료된다.

앞선 작업에서는 최대 세 마리 편대, 안전지대 안에서 E로 편대 전원을 파견하는 기능, 합류·파견에 따른 공동 HP 보너스 추가와 제거를 구현했다.

그런데 구조 집계는 여전히 친구의 Following 전환을 기준으로 동작하고 있었다. 편대에 합류하기만 해도 구조 목표가 올라가면서, 실제 파견 행동과 미션 판정이 맞지 않았다.

이번 작업에서는 구조 성공을 집계하는 시점을 파견 성공으로 옮겼다. 기존 편대·공동 HP 정리 흐름에 구조 이벤트와 친구 Actor 제거를 연결하고, 안전지대 중첩 처리도 보완했다.

새로운 기능을 늘리기보다 합류는 동행과 임시 HP 보너스, 파견은 구조 완료와 편대 정리라는 두 행동의 의미를 코드에서도 일치시키는 데 집중했다.

상태를 관찰하는 대신 성공한 행동을 보고하기

기존 구조는 친구의 상태를 주기적으로 확인해 Following 전환을 FriendRescued 이벤트로 변환했다.

하지만 Following은 동행 중이라는 상태이지 구조가 끝났다는 증거가 아니다. 구조 완료를 상태에서 추측하기보다, 파견을 실행하는 코드가 성공 시점에 직접 보고하도록 변경했다.

if (!Friend->StartDeparture())
{
    continue;
}

RunEvents->ReportFriendRescued(
    Friend,
    FriendId,
    Rarity);

기존 UpdateFriendStates()의 선언·정의·Tick 호출을 제거하고, SendCurrentFriendFormation()에서 파견 전환이 성공한 친구만 보고하도록 연결했다.

ReportFriendRescued()는 런 이벤트 관찰 중에만 처리한다. 친구 Actor별 기록의 bRescueReported로 중복 보고를 방어하고, 이벤트에는 물고기 ID·희귀도·Amount = 1을 담는다.

관찰 Tick이 오기 전에 합류와 파견이 빠르게 끝난 경우에도 기록을 생성한다. 구조 집계가 폴링 주기에 좌우되지 않도록 한 것이다.

구조 보고와 연출, 제거의 순서 정리

구조 판정 시점을 바꾸면서 친구 Actor의 생명주기도 함께 정리했다.

기존에는 StartDeparture()가 상태 변경과 Blueprint 연출 호출을 함께 담당했다. 이번에는 이 함수가 Departing 상태로 전환하고 추종 참조와 슬롯을 정리하는 역할만 맡도록 변경했다.

이후 PlayerPawn이 구조 보고부터 Actor 제거까지의 순서를 명시적으로 관리한다.

if (!Friend->StartDeparture())
{
    continue;
}

// 성공한 친구만 편대에서 제거하고 HP 보너스 반환 대상으로 집계
FollowingFriends.RemoveAt(FriendIndex);
RemovedHealthBonus += HealthBonus;
++SentFriendCount;

// Actor가 제거되기 전에 구조 완료를 런 이벤트로 전달
if (UCF_RunEventSubsystem* RunEvents =
        UCF_RunEventSubsystem::Get(this))
{
    RunEvents->ReportFriendRescued(
        Friend,
        FriendId,
        Rarity);
}

// UI와 Blueprint에는 ID·희귀도 데이터 전달
OnFriendDelivered.Broadcast(FriendId, Rarity);

// 별도의 출발 효과를 생성할 수 있는 Blueprint 훅
Friend->ReceiveDepartureStarted();

// 처리가 끝난 게임플레이 Actor 제거
Friend->Destroy();

핵심은 필요한 보고와 알림을 끝낸 뒤 Actor를 제거하는 것이다.

런 이벤트에는 구조 완료를 보고하고, UI와 Blueprint에는 OnFriendDelivered로 물고기 ID와 희귀도를 전달한다. 모든 친구의 파견 처리가 끝나면 성공한 친구들의 공동 최대 HP 보너스를 합산해 제거한다.

ReceiveDepartureStarted() 직후 친구 Actor가 제거되므로, 지속되는 출발 연출은 별도 효과나 연출용 Actor로 생성해야 한다. 제거될 친구 Actor에 Delay를 걸어 이후 동작을 이어가는 방식은 사용하지 않도록 계약을 정리했다.

파견하면 공동 HP 보너스도 반환한다

친구 합류와 파견은 공동 HP에도 영향을 준다.

앞선 작업에서 친구가 편대에 합류하면 플레이어의 최대 HP가 증가하고, 안전지대로 파견하면 해당 친구들이 제공한 최대 HP 보너스를 제거하도록 구현했다.

파견할 때는 성공적으로 출발한 친구의 보너스만 합산해 제거한다. 현재 HP를 보너스만큼 그대로 차감하는 것이 아니라, 줄어든 최대 HP를 초과할 때만 보정한다.

파견 전: 현재 HP 140 / 최대 HP 175
보너스 75 제거
파견 후: 현재 HP 100 / 최대 HP 100

파견 전: 현재 HP 60 / 최대 HP 175
보너스 75 제거
파견 후: 현재 HP 60 / 최대 HP 100

친구를 구조했다고 해서 플레이어에게 추가 피해를 주지는 않되, 편대가 제공하던 임시 생존 보너스는 회수하는 방식이다.

이번 작업에서는 이 기존 HP 정리 흐름에 파견 성공 시 구조 이벤트 보고와 Actor 제거를 연결했다. 따라서 파견은 구조 기록뿐 아니라 편대 구성과 최대 HP까지 함께 정리하는 행동이 된다.

친구 합류 시 최대 HP가 증가하고 파견 후 보너스가 제거되는 장면

안전지대 안에 있다는 사실은 bool 하나로 부족했다

안전지대 진입 여부를 bool 하나로 관리하던 방식에도 문제가 있었다.

A와 B가 겹친 영역에 들어간 뒤 A만 벗어나면, 여전히 B 안에 있어도 A의 Exit 이벤트가 파견 가능 상태를 false로 바꿨다.

필요한 정보는 “마지막 이벤트가 Enter였는가?”가 아니라 “현재 어떤 안전지대 안에 있는가?”였다.

TSet<TWeakObjectPtr<ACF_FriendSafeZone>>
    ActiveFriendSafeZones;

각 존의 진입·이탈을 집합에 반영하고, 유효한 존이 하나라도 있으면 파견 가능한 것으로 판단하도록 변경했다. 약한 참조를 사용해 안전지대 Actor가 제거된 경우도 유효성 검사로 구분한다.

영구 무적과 시간제 무적도 분리했다

친구의 영구 무적과 향후 플레이어에게 사용할 짧은 무적을 같은 상태로 관리하지 않도록 분리했다.

bool IsInvulnerable() const
{
    return bIsPermanentlyInvulnerable
        || bHasTimedInvulnerability;
}

친구는 BeginPlay()에서 영구 무적을 적용한다. 체력 데이터를 다시 초기화해도 영구 무적은 유지하고, 시간제 효과만 초기화한다.

시간제 무적은 더 짧은 요청이 들어와도 기존 남은 시간을 줄이지 않도록 처리했다.

InvulnerabilityTimeRemaining = FMath::Max(
    InvulnerabilityTimeRemaining,
    Duration);

플레이어 대시 자체는 아직 구현하지 않았다. 이번 변경은 서로 다른 무적 정책이 충돌하지 않도록 기반을 정리한 작업이다.

회고

이번 작업은 이미 있는 기능의 의미를 바로잡는 작업이었다. 합류 상태를 구조 성공으로 추측하던 코드를 성공한 행동의 명시적 보고로 바꾸고, 안전지대 bool을 실제 중첩 관계를 표현하는 집합으로 바꿨다.

구조 완료를 보고하는 시점과 Actor를 제거하는 순서를 명확히 해야 미션 집계와 Blueprint 연출도 같은 계약 위에서 동작할 수 있다는 점을 배웠다.

std::list — 양방향 연결 리스트 컨테이너

loooong — Sun, 6 Sep 2026 19:57:59 +0900

std::vector는 연속된 메모리를 사용하기 때문에 Random Access와 순차 탐색 성능이 뛰어나다.

하지만 중간에 원소를 삽입하거나 삭제하면 뒤쪽 원소를 이동해야 한다.

std::list는 이러한 문제를 다른 방식으로 해결한다.

원소를 연속적으로 저장하는 대신 각각의 원소를 독립적인 Node로 만들고, Node끼리 연결한다.

이번 글에서는 std::list의 구조와 특징, Iterator 안정성, splice()와 sort() 같은 고유 기능을 살펴보고 마지막으로 vector와 비교한다.

1. std::list가 필요한 이유

1-1. vector의 중간 삽입·삭제 비용

vector는 원소를 연속해서 저장한다.

[10][20][30][40] // 20과 30 사이에 25를 넣으려면

        ↓

[10][20][25][30][40] // 뒤쪽 원소를 이동해야 한다.

따라서 중간 삽입은 일반적으로:

O(N)

삭제 역시 동일하다.

[10][20][30][40]

20 삭제

[10][30][40] // 뒤쪽 원소를 앞으로 이동시켜야 한다.

1-2. 원소를 이동하지 않는 자료구조

Linked List는 원소를 연속해서 저장하지 않는다.

대신 각 원소를 Node에 저장하고 Node끼리 연결한다.

[A] ⇄ [B] ⇄ [C]

B와 C 사이에 X를 삽입하면:

[A] ⇄ [B] ⇄ [X] ⇄ [C]

기존 C 이후의 원소들을 이동할 필요가 없다.

연결 관계만 수정하면 된다.

STL에서는 이러한 양방향 연결 리스트를:

std::list

로 제공한다.

2. std::list란

std::list 역시 vector, deque와 마찬가지로 Sequence Container에 속한다.

하지만 데이터 저장 방식은 완전히 다르다.

각 원소를 독립적인 Node에 저장하고 이전 Node와 다음 Node를 연결하는 Doubly Linked List 기반의 Sequence Container다.

대표적인 사용 방법은 다음과 같다.

std::list<int> Numbers = {
    10, 20, 30
};

2-1. Doubly Linked List

각 Node는 개념적으로 다음 정보를 가진다.

┌───────────────────┐
│ Prev Pointer      │
│ Data              │
│ Next Pointer      │
└───────────────────┘

따라서 양방향으로 이동할 수 있다.

[A] ⇄ [B] ⇄ [C]

3. 내부 구조

3-1. Node 구조

다음 list가 있다고 하자.

std::list<int> Numbers = {
    10, 20, 30
};

개념적으로:

[Prev | 10 | Next]
        ⇅
[Prev | 20 | Next]
        ⇅
[Prev | 30 | Next]

형태로 연결되어 있다.

3-2. 비연속 메모리

각 Node는 메모리상 서로 다른 위치에 존재할 수 있다.

0x1000             0x8700             0x3200

[10] ───────────→ [20] ───────────→ [30]

따라서:

Begin + Index * sizeof(T)

같은 방식으로 원하는 원소의 주소를 계산할 수 없다.

3-3. Bidirectional Iterator

std::list는 Bidirectional Iterator를 제공한다.

따라서:

++It;
--It;

처럼 앞뒤로 한 칸씩 이동할 수 있다.

하지만:

It += 10; // n칸 떨어진 위치로 직접 이동할 수 있는 Random Access Iterator 를 요구함

처럼 원하는 위치로 즉시 이동하는 Random Access는 지원하지 않는다.

4. 주요 특징

4-1. Random Access를 지원하지 않는다

다음 코드는 사용할 수 없다.

std::list<int> Numbers = {
    10, 20, 30
};

Numbers[2]; // 불가능

n번째 원소로 이동하려면 순차적으로 이동해야 한다.

auto It = Numbers.begin();

// Iterator를 지정한 거리만큼 이동시키는 함수
std::advance(It, 2);

이 경우 시간복잡도는:

O(N)

이다.

list의 Random Access가 O(N)인 것이 아니라, Random Access 자체를 지원하지 않으며 n번째 위치까지 이동하는 데 O(N)이 필요하다.

4-2. 삽입·삭제 위치를 알면 O(1)

다음 상태에서:

[A] ⇄ [B] ⇄ [C]

B와 C 사이에 X를 넣으면:

[A] ⇄ [B] ⇄ [X] ⇄ [C]

연결 정보만 변경한다.

따라서 삽입 위치 Iterator를 이미 가지고 있다면:

Numbers.insert(It, 25);

삽입 자체는:

O(1)

이다.

삭제도 마찬가지다.

Numbers.erase(It);

삭제 위치 Iterator가 이미 있다면 O(1)이다.

다만 삭제할 원소를 먼저 찾아야 한다면:

auto It = std::find(
    Numbers.begin(),
    Numbers.end(),
    20
);

탐색에 O(N)이 필요하다.

4-3. 앞·뒤 삽입과 삭제가 O(1)

std::list는 앞과 뒤 모두에서 삽입과 삭제를 O(1)에 수행할 수 있다.

Numbers.push_front(10);
Numbers.push_back(40);

Numbers.pop_front();
Numbers.pop_back();

반면, vector는 뒤쪽 삽입과 삭제만 지원한다.

다만 list가 앞뒤 삽입·삭제에 유리하다고 해서 항상 더 빠른 것은 아니다. 실제 성능은 Cache Locality, Node Allocation, 순회 빈도 등의 영향도 함께 받는다.

4-4. 메모리 오버헤드

각 Node는 데이터 이외에도 연결 정보를 가지고 있어야 한다.

Prev Pointer
Data
Next Pointer

따라서 vector보다 원소당 메모리 오버헤드가 크다.

특히 작은 타입일수록 이 차이가 커질 수 있다.

예를 들어 64-bit 환경에서 포인터 하나가 일반적으로 8Byte라면:

int Data        4Byte
Prev Pointer    8Byte
Next Pointer    8Byte

에 padding 등도 추가될 수 있다.

*padding : 메모리 정렬(alignment)을 맞추기 위해 객체 내부에 끼워 넣는 사용하지 않는 바이트

실제 Node 크기는 구현체와 alignment에 따라 달라진다.

4-5. Reallocation이 없다

vector는 capacity가 부족하면 더 큰 연속 저장 공간으로 이동해야 한다.

하지만 list는 새로운 Node를 하나 생성해 연결하면 된다.

기존

[A] ⇄ [B] ⇄ [C]

새 Node 삽입

[A] ⇄ [B] ⇄ [X] ⇄ [C]

따라서 vector와 같은 전체 저장 공간 Reallocation은 발생하지 않는다.

4-6. Iterator / Reference Invalidation

list는 Iterator 안정성이 높은 편이다.

새로운 원소를 삽입해도 20 Node의 위치는 바뀌지 않는다. 따라서 It은 계속 유효하다.

즉:

list에 원소를 삽입해도 기존 원소를 가리키는 Iterator와 Reference는 일반적으로 무효화되지 않는다.

삭제에서도 해당 원소를 가리키던 Iterator와 Reference만 무효화되고, 다른 Node를 가리키던 Iterator는 유지된다.

정리하면:

삽입
→ 기존 Iterator / Reference 유지

삭제
→ 삭제된 원소를 가리키던 것만 무효화

4-7. 주요 멤버 함수

함수	시간복잡도	역할
Random Access	지원하지 않음
n번째 원소까지 이동	O(N)
front()	O(1)	첫 번째 원소 접근
back()	O(1)	마지막 원소 접근
push_front()	O(1)	앞쪽 삽입
push_back()	O(1)	뒤쪽 삽입
pop_front()	O(1)	첫 번째 원소 제거
pop_back()	O(1)	마지막 원소 제거
insert()	O(1)	Iterator 위치에 삽입, 위치를 알고 있을 때
erase()	O(1)	Iterator 위치의 원소 제거, 위치를 알고 있을 때
clear()	O(N)	모든 원소 제거
size()	O(1)	원소 개수 반환
empty()	O(1)	비어 있는지 확인
splice()	overload에 따라 다름	Node 연결 변경
sort()	O(N log N)	list 자체 정렬

insert()와 erase()의 O(1)은 위치 Iterator를 이미 알고 있을 때 기준이다.

5. list::splice()

splice()는 std::list의 대표적인 고유 기능이다.

기존 원소를 복사하거나 이동 생성하지 않고 Node 자체의 연결 관계를 변경하여 다른 위치로 옮긴다.

std::list<int> A = {
    1, 2, 3
};

std::list<int> B = {
    10, 20, 30
};

auto It = B.begin();
++It;

// It → 20

A.splice(
    A.end(),
    B,
    It
);

결과:

// B가 소유하던 노드를 A 쪽으로 넘기는 것

A
[1] ⇄ [2] ⇄ [3] ⇄ [20]

B
[10] ⇄ [30]

단일 원소를 옮기는 경우 O(1)에 수행할 수 있다.

단, splice()의 모든 overload가 무조건 O(1)은 아니다. 범위를 옮기는 경우에는 상황에 따라 이동하는 원소 수에 비례하는 비용이 발생할 수 있다.

7. list::sort()

7-1. 왜 std::sort()를 사용할 수 없는가?

vector에서는 다음이 가능하다.

std::vector<int> Numbers = {
    4, 1, 3, 2
};

std::sort(
    Numbers.begin(),
    Numbers.end()
);

하지만 list에서는 사용할 수 없다.

std::list<int> Numbers = {
    4, 1, 3, 2
};

// 불가능
std::sort(
    Numbers.begin(),
    Numbers.end()
);

7-2. Iterator Category 차이

std::sort()는 Random Access Iterator를 요구한다.

즉:

It + N;
It - N;
It2 - It1;

같은 연산이 가능해야 한다.

vector의 Iterator는 이를 지원한다.

하지만 list는 Bidirectional Iterator만 제공한다.

++It;
--It;

만 가능하기 때문에 std::sort()의 요구조건을 만족하지 못한다.

7-3. list::sort()

대신 list 자체가 정렬 함수를 제공한다.

Numbers.sort();

내림차순도 가능하다.

Numbers.sort(
    std::greater<int>()
);

시간복잡도는:

O(N log N)

이다.

핵심은:

list라서 std::sort()를 못 쓰는 것이 아니라, std::sort()가 요구하는 Random Access Iterator를 list가 제공하지 않기 때문이다.

8. Big-O와 실제 성능은 다를 수 있다

8-1. list의 O(1) 삽입이 항상 빠른 것은 아니다

표만 보면:

vector 중간 삽입
O(N)

list 중간 삽입
O(1)

이므로 list가 훨씬 좋아 보인다.

하지만 현실에서는 반드시 그렇지 않다.

먼저 list의 O(1)은 삽입 위치 Iterator를 이미 알고 있을 때다.

삽입 위치를 먼저 찾는다면:

Search O(N)
+
Insert O(1)

이다.

그리고 실제 성능에는 Big-O 외에도 메모리 접근 방식이 큰 영향을 준다.

8-2. Cache Locality

vector는 원소가 연속되어 있다.

[A][B][C][D][E]

CPU가 A를 읽을 때 주변 데이터도 Cache Line 단위로 가져올 수 있다.

따라서 이후 B, C를 읽을 때 Cache Hit가 발생할 가능성이 높다.

반면 list는:

[A] ───→ [B] ───→ [C]

처럼 다음 Node가 메모리 어디에 존재할지 보장되지 않는다.

8-3. 시간 지역성과 공간 지역성

시간 지역성 — Temporal Locality

최근 사용한 데이터를 가까운 시간 안에 다시 사용할 가능성이 높다는 특성이다.

for (int i = 0; i < 1000; ++i)
{
    Sum += Player.Health;
}

같은 데이터를 반복적으로 사용한다.

공간 지역성 — Spatial Locality

특정 메모리에 접근했다면 주변 메모리에도 곧 접근할 가능성이 높다는 특성이다.

[A][B][C][D]
 ↑
A 접근 후 B, C 접근

vector 순회가 대표적이다.

list는 Node가 비연속적으로 존재할 수 있기 때문에 이 공간 지역성을 활용하기 상대적으로 어렵다.

8-4. Pointer Chasing

list를 순회하려면 계속 다음 Node의 Pointer를 따라가야 한다.

Node
 ↓
Next Pointer
 ↓
다른 메모리 위치
 ↓
Next Pointer
 ↓
다른 메모리 위치

이러한 접근을 Pointer Chasing이라고 한다.

Node가 캐시에 없다면 매번 메모리 접근 지연이 발생할 수 있다.

8-5. Node Allocation 비용

vector는 보통 하나의 연속된 저장 공간을 관리한다.

반면 list는 일반적으로 Node 단위의 메모리 할당이 필요하다.

따라서 다음과 같은 추가 비용이 발생할 수 있다.

Node Allocation
Deallocation
Allocator Metadata
Memory Fragmentation

결국:

실제 성능에서는 시간복잡도뿐 아니라 Cache Locality, Allocation 비용, 원소 크기, 접근 패턴까지 고려해야 한다.

9. std::forward_list

std::forward_list는:

Singly Linked List 기반의 Sequence Container다.

list는 양방향이다.

[A] ⇄ [B] ⇄ [C]

forward_list는 한 방향으로만 연결된다.

[A] → [B] → [C]

각 Node는 개념적으로:

Data
Next Pointer

만 가지고 있다.

따라서 list보다 연결 정보에 필요한 메모리 오버헤드를 줄일 수 있다.

9-1. list와 forward_list 비교

	std::list	std::forward_list
구조	Doubly Linked List	Singly Linked List
Node Pointer	Prev + Next	Next
Iterator	Bidirectional	Forward
++It	O	O
--It	O	X
push_front()	O(1)	O(1)
push_back()	O(1)	제공하지 않음 head만 관리하고 tail을 별도로 관리하지 않도록 설계됨
Random Access	지원하지 않음	지원하지 않음
메모리 오버헤드	상대적으로 큼	상대적으로 작음

9-2. insert_after() / erase_after()

forward_list는 이전 Node로 이동할 수 없다.

[A] → [B] → [C]
       ↑
       It

B 뒤에 X를 넣는 것은 쉽다.

[A] → [B] → [X] → [C]

하지만 B 앞에 삽입하려면 A의 Next를 수정해야 한다.

그런데 현재 B만 알고 있다면 이전 Node인 A를 바로 찾을 수 없다.

그래서:

insert_after();
erase_after();

인터페이스를 사용한다.

9-3. size()가 없다

std::forward_list에는 size() 멤버 함수가 없다.

원소 개수를 O(1)에 반환하려면 컨테이너가 별도의 원소 개수 상태를 유지해야 한다.

forward_list는 최소한의 메모리 오버헤드를 목표로 하기 때문에 이를 제공하지 않는다.

필요하다면:

std::distance(
    List.begin(),
    List.end()
);

로 계산할 수 있지만:

O(N)

이 필요하다.

10. vector vs list

10-1. 구조 및 시간복잡도 비교

	std::vector	std::list
내부 구조	동적 배열	양방향 연결 리스트
원소 저장	연속	비연속
Random Access	O(1)	지원하지 않음
n번째 원소 접근	O(1)	O(N)
Search	O(N)	O(N)
중간 삽입	O(N)	Iterator가 있다면 O(1)
중간 삭제	O(N)	Iterator가 있다면 O(1)
push_back()	Amortized O(1)	O(1)
push_front()	O(N)	O(1)

10-2. Iterator 안정성 비교

	vector	list
삽입	Reallocation/원소 이동으로 무효화 가능	기존 원소 유지
삭제	삭제 위치 이후 무효화	삭제된 원소만 무효화
Reallocation	발생 가능	없음

10-3. 메모리 및 캐시 특성

	vector	list
Cache Locality	좋음	일반적으로 좋지 않음
Pointer Chasing	없음	있음
원소별 Pointer	없음	Prev / Next
메모리 오버헤드	상대적으로 작음	큼
Allocation	연속 저장 공간 중심	Node 단위 할당

정리

std::list는 양방향 연결 리스트 기반의 Sequence Container다.

[A] ⇄ [B] ⇄ [C]

연속된 메모리를 사용하지 않기 때문에 Random Access는 지원하지 않지만, 삽입·삭제 위치 Iterator를 알고 있다면 Node의 연결 관계만 변경하여 O(1)에 처리할 수 있다.

또한 Reallocation이 없기 때문에 기존 Iterator와 Reference의 안정성이 높다는 특징이 있다.

반면:

Node Pointer 오버헤드
Pointer Chasing
낮은 공간 지역성
Node Allocation 비용

등으로 인해 실제 순회 성능은 vector보다 불리한 경우가 많다.

그래서 list는 Big-O만 보고 선택하는 자료구조가 아니라, Iterator 안정성이나 Node 단위 연결 작업이 실제 요구사항에 맞는지를 보고 선택하는 것이 중요하다.

forward_list는 여기서 Prev Pointer를 제거한 더 가벼운 단방향 연결 리스트다.

다음 글에서는 vector처럼 Random Access를 지원하면서도 앞과 뒤의 삽입·삭제를 효율적으로 수행하는 std::deque의 구조를 살펴본다.

std::vector — 동적 배열 컨테이너

loooong — Sun, 6 Sep 2026 01:05:56 +0900

좋아. 이번 글은 범위가 꽤 넓어서, vector를 중심으로 설명하고 std::array는 비교용으로 붙이는 구조가 가장 좋다.

다만 지금 초안에는 몇 군데 사실관계와 표현을 다듬는 게 좋다.

vector 성장 배율을 1.5~2.5배라고 고정적으로 쓰면 안 됨. 표준은 성장 배율을 규정하지 않는다.
push_back()의 시간복잡도는 “평균 O(1)”보다는 "amortized O(1)" (애머타이즈드)이라고 쓰는 게 정확하다.
resize()는 size를 변경하지만 필요하면 capacity도 증가할 수 있다.
shrink_to_fit()은 capacity를 줄이는 non-binding request다.
insert()/erase()의 invalidation은 단순히 “이후 iterator 무효화”가 아니라 reallocation 여부에 따라 규칙이 달라진다.
std::array의 크기는 “컴파일 타임”이라고 설명해도 좋지만, 더 정확히는 타입의 일부인 compile-time constant다.
vector 객체가 반드시 pointer + size + capacity 필드를 가진다고 단정하면 안 된다. 개념적으로 그렇게 관리한다고 표현해야 한다.

C++에서 가장 자주 사용되는 STL 컨테이너 중 하나가 std::vector다.

vector는 원소를 연속된 메모리에 저장하면서도 실행 중 크기를 변경할 수 있는 동적 배열 컨테이너다.

배열의 빠른 Random Access와 캐시 친화적인 메모리 구조를 유지하면서, 크기 관리와 메모리 재할당을 자동화한다는 점이 핵심이다.

1. vector의 등장 배경

C 스타일 배열은 연속된 메모리에 데이터를 저장한다.

int Numbers[5];

연속된 메모리를 사용하기 때문에 인덱스를 이용한 접근이 빠르다.

Numbers[2];

하지만 일반적인 고정 크기 배열에는 한계가 있다.

크기를 선언 시점에 결정해야 한다.
생성된 배열의 길이를 실행 중 변경할 수 없다.
크기를 작게 잡으면 공간이 부족할 수 있다.
크기를 크게 잡으면 사용하지 않는 공간이 낭비될 수 있다.
더 큰 저장 공간이 필요하면 새로운 배열을 만들고 데이터를 직접 옮겨야 한다.

예를 들어 다음 배열이 있다고 하자.

int Numbers[5] = {1, 2, 3, 4, 5};

이미 다섯 칸을 모두 사용하고 있다.

[1][2][3][4][5]

여기에 6을 추가하고 싶다고 해서 기존 배열 자체를 다음과 같이 늘릴 수는 없다.

필요하다면 더 큰 저장 공간을 새로 확보하고 기존 데이터를 복사해야 한다.

새로운 더 큰 배열 생성
        ↓
기존 데이터 복사
        ↓
기존 배열 정리

std::vector는 이러한 과정을 내부적으로 관리한다.

std::vector<int> Numbers;

원소가 늘어나 현재 저장 공간이 부족해지면 더 큰 연속 메모리를 확보하고 기존 원소를 새로운 공간으로 이동 또는 복사한다.

2. vector의 내부 구조

std::vector는 원소들을 연속된 메모리 공간에 저장한다.

std::vector<int> Numbers = {10, 20, 30, 40};

원소 저장 영역을 개념적으로 표현하면 다음과 같다.

Address

0x1000

┌────┬────┬────┬────┐
│ 10 │ 20 │ 30 │ 40 │
└────┴────┴────┴────┘

각 원소가 연속적으로 배치되어 있다.

따라서 인덱스를 알면 원하는 원소의 위치를 바로 계산할 수 있다.

원소 주소
=
시작 주소 + (Index × sizeof(T))

예를 들어 int가 4Byte이고 첫 번째 원소의 주소가 0x1000이라고 가정하면:

Numbers[2]

0x1000 + (2 × 4)

= 0x1008

와 같이 계산할 수 있다.

그래서 vector의 Random Access는:

O(1)

이다.

3. vector 객체와 실제 원소 저장 공간

vector 객체 자체와 실제 원소 저장 공간은 구분해서 이해하는 것이 좋다.

개념적으로 다음과 같은 구조를 생각할 수 있다.

vector 객체
┌──────────────────┐
│ 원소 저장소 정보  │
│ size 정보        │
│ capacity 정보    │
└───────┬──────────┘
        │
        ▼

별도의 연속 저장 공간
┌────┬────┬────┬────┬────┐
│ 10 │ 20 │ 30 │    │    │
└────┴────┴────┴────┴────┘

실제 표준은 vector 구현 내부에 반드시

pointer
size
capacity

라는 세 멤버를 저장하라고 규정하지 않는다.

다만 일반적인 구현에서는 원소 저장 영역과 현재 크기, 확보된 공간을 알 수 있는 정보를 내부적으로 관리한다.

4. size와 capacity

vector를 이해하려면 size와 capacity의 차이를 반드시 알아야 한다.

size

현재 실제로 존재하는 원소 개수다.

std::vector<int> Numbers = {10, 20, 30};

std::cout << Numbers.size();

capacity

현재 저장 공간을 다시 할당하지 않고 저장할 수 있는 최대 원소 개수다.

예를 들어:

size     = 3
capacity = 5

라면 메모리를 다음처럼 생각할 수 있다.

┌────┬────┬────┬────┬────┐
│ 10 │ 20 │ 30 │    │    │
└────┴────┴────┴────┴────┘
  실제 원소       여유 공간

size
→ 현재 존재하는 원소 수

capacity
→ 현재 저장 공간에 들어갈 수 있는 원소 수

항상 다음 관계가 성립한다.

size <= capacity

5. vector의 주요 특징

5.1 연속된 메모리

vector는 배열처럼 원소를 연속적으로 저장한다.

[A][B][C][D][E]

따라서 순차 접근 시 공간 지역성이 좋다.

CPU가 메모리를 읽을 때 일반적으로 하나의 값만 가져오는 것이 아니라 주변 데이터를 Cache Line 단위로 캐시에 가져온다.

현대 시스템에서는 Cache Line이 흔히 64Byte인 경우가 많다.

따라서 다음처럼 연속된 원소를 순회하는 코드는 캐시를 효율적으로 활용하기 좋다.

for (const auto& Value : Numbers)
{
    Process(Value);
}

이 때문에 vector는 list처럼 각 원소가 서로 떨어진 위치에 존재할 수 있는 Node 기반 자료구조보다 순차 탐색 성능에서 유리한 경우가 많다.

5.2 Random Access — O(1)

인덱스로 원하는 원소에 바로 접근할 수 있다.

Numbers[100];

시간복잡도는:

O(1)

이다.

5.3 뒤쪽 삽입 — Amortized O(1)

Numbers.push_back(10);

맨 뒤에 공간이 남아 있다면 단순히 마지막 위치에 원소를 추가하면 된다.

[1][2][3][ ][ ]
         ↓
[1][2][3][4][ ] // O(1)

하지만 size == capacity 상태라면 새로운 저장 공간이 필요하다.

[1][2][3]

여기에 4를 추가하면 더 큰 연속 메모리를 확보해야 한다.

기존 저장 공간

[1][2][3]

      ↓

새 저장 공간

[1][2][3][4][ ][ ]

기존 원소들을 이동 또는 복사해야 하므로 이 한 번의 삽입은 O(N)이 될 수 있다.

하지만 매번 재할당하는 것은 아니기 때문에 여러 번의 push_back()을 전체적으로 평균내면:

Amortized O(1)

이다.

6. 왜 push_back()은 Amortized O(1)인가?

vector는 공간이 부족할 때 보통 현재보다 더 큰 capacity를 확보한다.

예를 들어 개념적으로:

capacity 1
↓
capacity 2
↓
capacity 4
↓
capacity 8
↓
...

처럼 성장할 수 있다.

다만 중요한 점은:

C++ 표준은 vector의 capacity 성장 배율을 규정하지 않는다.

구현체에 따라 1.5배, 2배에 가까운 방식 등 서로 다른 성장 전략을 사용할 수 있다.

vector는 재할당 횟수를 줄이기 위해 일반적으로 현재보다 더 큰 capacity를 확보하며,
구체적인 성장 전략은 표준 라이브러리 구현체에 따라 다르다.

7. vector의 장점

빠른 Random Access

Numbers[Index]; // O(1)

Cache Locality가 좋다

원소가 연속적으로 존재하므로 순차 탐색 시 CPU Cache를 효율적으로 활용하기 좋다.

메모리 오버헤드가 상대적으로 작다

vector는 각 원소마다 별도의 Node 정보가 필요하지 않다.

vector

[A][B][C][D]

반면 이중 연결 리스트는 각 노드마다 원소 외에도 연결 정보가 필요하다.

Prev ← [A] → Next
Prev ← [B] → Next
Prev ← [C] → Next

따라서 원소별 추가 메모리 오버헤드는 일반적으로 vector가 더 작다.

다만 vector는 capacity - size만큼 사용되지 않는 여유 저장 공간을 가지고 있을 수 있다.

STL Algorithm과 잘 맞는다

vector의 Iterator는 Random Access Iterator이므로 다양한 STL 알고리즘을 사용할 수 있다.

대표적으로:

std::sort(
    Numbers.begin(),
    Numbers.end()
);

를 사용할 수 있다.

8. vector의 단점

중간 삽입과 삭제가 O(N)이다.
capacity가 부족하면 reallocation이 발생할 수 있다.
reallocation 시 기존 원소를 이동 또는 복사해야 한다.
reallocation이 발생하면 기존 pointer, reference, iterator가 무효화된다. ( 이터레이터 무효화 = Iterator Invalidation )
실제 필요한 원소보다 capacity가 클 경우 여유 메모리를 보유할 수 있다.

9. 주요 멤버 함수

vector에서 자주 사용하는 함수들을 기능별로 정리하면 다음과 같다.

	함수	시간 복잡도	역할
크기 관련	size()	O(1)	현재 원소 수
	capacity()	O(1)	재할당 없이 저장 가능한 원소 수
	empty()	O(1)	비어 있는지 확인
	reserve()	O(N) 가능	capacity 미리 확보. 원소를 생성하지 않음 현재 capacity 이하를 요청하면 보통 O(1) 더 크게 늘리면 reallocation으로 O(N)
	resize()	O(N)	size 변경. 증가 시 새 원소 생성, reallocation 발생 가능. 감소 시 뒤 원소 제거
	shrink_to_fit()	O(N) 가능	여분 capacity 축소 요청. 실제 축소가 일어나면 원소 이동/복사 때문에 O(N)
원소 삽입 / 제거 / 교체	push_back()	Amortized O(1)	맨 뒤에 원소 삽입. void 반환 reallocation 발생 시 O(N)
	emplace_back()	Amortized O(1)	맨 뒤에서 원소 직접 생성. 삽입된 원소에 대한 reference를 반환 reallocation 발생 시 O(N)
	pop_back()	O(1)	마지막 원소 제거 반환값 없음 (먼저 값을 얻은 뒤 제거해야 함)
	insert()	O(N)	원하는 위치에 삽입. 뒤 원소 이동, reallocation 가능
	emplace()	O(N)	원하는 위치에서 원소 직접 생성. 뒤 원소 이동, reallocation 가능
	erase()	O(N)	특정 위치 또는 범위 삭제. 뒤 원소를 앞으로 이동
	clear()	O(N)	모든 원소 제거 일반적으로 capacity는 유지
	assign()	O(N)	기존 원소를 제거하고 새 원소들로 교체
원소 접근	front()	O(1)	첫 번째 원소 접근
	back()	O(1)	마지막 원소 접근
	data()	O(1)	연속 저장 공간의 시작 포인터 반환 C 스타일 API나 메모리 기반 API와 연결할 때 유용
	at()	O(1)	범위 검사하며 인덱스 접근 잘못된 인덱스라면 std::out_of_range 예외
	operator[]	O(1)	범위 검사 없이 인덱스 접근 잘못된 인덱스를 사용하면 UB 발생 가능
벡터 스왑	swap()	보통 O(1)	두 vector의 내부 저장소 관리 정보를 교환

10. reserve()와 resize() 비교

10.1 reserve()

앞으로 들어올 원소 개수를 알고 있다면 미리 capacity를 확보해 reallocation 횟수를 줄일 수 있다.

std::vector<Player> Players;

Players.reserve(1000);

for (int i = 0; i < 1000; ++i)
{
    Players.emplace_back();
}

capacity가 충분한 동안은 capacity 부족으로 인한 reallocation이 발생하지 않는다.

10.2 resize()

resize()는 vector의 size를 변경한다.

std::vector<int> Numbers;

Numbers.resize(5); // size = 5

int의 경우 새 원소들은 value-initialization되어 일반적으로 0이 된다.

[0][0][0][0][0]

크기를 증가시키는 경우

새 원소가 추가로 생성된다.
capacity가 부족하다면 reallocation이 발생할 수도 있다.

크기를 감소시키는 경우

뒤쪽 원소들이 제거된다.
size는 줄어들지만 capacity까지 자동으로 줄어드는 것은 아니다.

기존

[10][20][30][40][50]

resize(3)

[10][20][30]

정리하면,

reserve()
→ 저장 공간 확보
→ capacity 변경
→ size는 변경하지 않음

resize()
→ 실제 원소 개수 변경
→ size 변경
→ 필요하면 capacity도 증가할 수 있음

11. push_back()과 emplace_back() 비교

11.1 push_back()

맨 뒤에 원소를 추가한다.

std::vector<std::string> Names;

std::string Name = "Minsu";

Names.push_back(Name); // Name이 lvalue이므로 복사

Names.push_back(std::move(Name)); // 이동 생성 이용하는 방식 : lvalue를 rvalue처럼 취급

Names.push_back(
    std::string("Minsu") // 임시 객체 전달하는 방식
);

임시 객체 : 이름을 붙여 따로 저장하지 않고, 표현식 안에서 잠깐 생성되어 사용된 뒤 사라지는 객체

11.2 emplace_back()

emplace_back()은 전달받은 생성자 인자를 이용해 vector의 마지막 위치에 원소를 직접 생성한다.

예를 들어:

class Player
{
public:
    Player(int Hp, std::string Name)
        : Hp(Hp),
          Name(std::move(Name))
    {
    }

private:
    int Hp;
    std::string Name;
};

push_back()은 다음처럼 사용할 수 있다.

std::vector<Player> Players;

Players.push_back(
    Player(100, "Minsu") // 임시 객체 생성 후,  vector 내부로 이동
);

반면:

Players.emplace_back(
    100,
    "Minsu"
);

는 Player 객체가 아니라 Player 생성자에 필요한 인자를 전달한다.

개념적으로:

100, "Minsu"
     ↓
vector 저장 공간에서
Player(100, "Minsu") 직접 생성

이다.

따라서 경우에 따라 임시 객체 생성과 이동을 줄일 수 있다.

11.3 emplace_back()이 항상 더 빠른 것은 아니다

이미 객체 P가 있다면:

Players.push_back(P);

또는

Players.push_back(
    std::move(P)
);

가 자연스럽다.

emplace_back()의 핵심은:

항상 더 빠르다가 아니라, 생성자 인자를 직접 전달하여 원소를 제자리 생성할 수 있다는 것이다.

11.4 반환값 차이

C++17 이후:

emplace_back()은 삽입된 원소에 대한 reference를 반환한다.

Player& P = Players.emplace_back(
    100,
    "Minsu"
);

반면 push_back()은 void를 반환한다.

12. shrink_to_fit() 자세히 보기

shrink_to_fit()은 현재 사용하지 않는 여분의 capacity를 줄여달라고 요청하는 함수다.

std::vector<int> Numbers;

Numbers.reserve(1000);

for (int i = 0; i < 100; ++i)
{
    Numbers.push_back(i);
}

// size     = 100
// capacity = 1000

이때:

Numbers.shrink_to_fit();

을 호출하면 여분의 capacity를 줄여달라고 구현체에 요청한다.

구현체가 실제로 축소했다면 예를 들어:

size     = 100
capacity = 100

처럼 될 수 있다.

하지만 중요한 점은 shrink_to_fit()은 non-binding request 이다.

즉 실제로 capacity가 줄어드는 것은 보장되지 않는다.

따라서 다음을 가정하면 안 된다.

Numbers.shrink_to_fit();

assert(
    Numbers.capacity() ==
    Numbers.size()
);

13. Reallocation과 Iterator Invalidation

13.1 Reallocation

vector의 가장 중요한 내부 동작 중 하나가 Reallocation이다.

기존

0x1000
┌────┬────┬────┐
│ 10 │ 20 │ 30 │
└────┴────┴────┘

V.push_back(40);
// 기존 저장 영역 바로 뒤가 비어 있다고 보장할 수 없기 때문에 
// vector는 더 큰 새로운 연속 저장 공간을 확보한다.


새 저장 공간

0x5000
┌────┬────┬────┬────┬────┬────┐
│ 10 │ 20 │ 30 │ 40 │    │    │
└────┴────┴────┴────┴────┴────┘

개념적으로 다음 과정이 일어난다.

새로운 연속 메모리 확보
        ↓
기존 원소 이동 또는 복사 생성
        ↓
기존 원소의 lifetime 종료
        ↓
기존 저장 공간 해제

이 과정이 Reallocation이다.

13.2 Iterator Invalidation

다음 코드를 보자.

std::vector<int> V;

V.reserve(3);

V.push_back(10);
V.push_back(20);
V.push_back(30);

int* Ptr = &V[0];
int& Ref = V[0];
auto It = V.begin();

세 변수 모두 현재 첫 번째 원소를 가리키고 있다.

0x1000

┌────┬────┬────┐
│ 10 │ 20 │ 30 │
└────┴────┴────┘
  ↑
 Ptr
 Ref
 It

이제:

V.push_back(40);

으로 reallocation이 발생했다고 하자.

기존

0x1000
┌────┬────┬────┐
│ 10 │ 20 │ 30 │
└────┴────┴────┘


새 저장 공간

0x5000
┌────┬────┬────┬────┐
│ 10 │ 20 │ 30 │ 40 │
└────┴────┴────┴────┘

기존 저장 영역에 있던 객체들의 lifetime이 끝났기 때문에:

*Ptr;
Ref;
*It;

를 더 이상 사용하면 안 된다.

즉, Reallocation이 발생하면 기존 원소를 가리키는 모든 pointer, reference, iterator가 무효화된다.

아래의 코드도 위험하다.

std::vector<int> Values = {
    1, 2, 3
};

for (auto It = Values.begin(); It != Values.end(); ++It)
{
    if (*It == 2)
    {
        Values.push_back(100);
        // 위험 : reallocation이 발생하면 현재 사용 중인 It 자체가 무효화될 수 있음
        // 무효화된 It 사용하면 UB
    }
}

13.3 왜 Reference도 무효화되는가?

reference는 특정 객체에 바인딩된다.

int& Ref = V[0]; // 현재 존재하는 V[0] 객체를 참조

하지만 reallocation이 발생하면:

기존 V[0] 객체 lifetime 종료
        ↓
새 메모리에 새로운 원소 생성

값이 똑같이 10이어도 기존 객체와 새 위치의 객체는 같은 lifetime의 객체가 아니다.

따라서 기존 reference는 dangling reference가 된다.

13.4 push_back()에서 reallocation이 없으면?

capacity가 충분해서 reallocation이 발생하지 않았다면 기존 원소를 가리키는 iterator/reference/pointer는 유지된다.

다만 기존의 end iterator는 무효화된다.

새 원소가 추가되면서 새로운 end() 위치가 생기기 때문이다.

비슷하게 insert(), erase()도 Reallocation이 발생한 경우, 모든 iterator, pointer, reference가 무효화된다.

Reallocation이 발생하지 않은 경우에는 삽입/삭제 위치 및 그 이후의 iterator/reference/pointer가 무효화된다.

삽입 위치보다 앞쪽 원소를 가리키는 것들은 유지된다.

13.4 Iterator Invalidation 예방

예상 크기를 알면 reserve() 한다.
변경 후 다시 iterator/reference를 얻는다
장기간 식별에는 ID나 Handle 고려한다.

[번외] std::array와 std::vector

std::array와 std::vector는 둘 다 원소를 연속된 메모리에 저장하는 Sequence Container다.

따라서 순차 탐색 시 공간 지역성이 좋다. (= Cache Friendly)

그래서 일반적으로 std::list 같은 Node 기반 컨테이너보다 순회 성능이 좋은 경우가 많다.

std::array

[A][B][C][D]


std::vector 원소 저장 영역

[A][B][C][D]

하지만 가장 큰 차이는 크기와 메모리 관리 방식이다.

	std::array	std::vector
크기	고정	동적
크기 정보	타입에 포함된 compile-time 상수	runtime에 관리
원소 저장 위치	객체 내부	별도의 동적 저장 공간
연속 메모리	O	O
Random Access	O(1)	O(1)
push_back()	X	O
resize()	X	O
Reallocation	없음	capacity 부족 시 발생 가능
Iterator Invalidation	구조적 크기 변경 자체가 없음	삽입/삭제/reallocation에 따라 발생
추가 관리 정보	매우 작음	size/capacity/저장소 관리 정보 필요

std::array

std::array<int, 3> Arr = { 10, 20, 30 };

여기서 3은 타입의 일부다.

// 원소 타입, 원소 개수
std::array<int, 3>
std::array<int, 4>

템플릿 인자가 서로 다르기 때문에, 서로 다른 타입이다.

*C++에서 서로 다른 템플릿 인자로 만들어진 템플릿 specialization은 서로 다른 타입이다.

원소 저장 공간이 array 객체 자체에 포함되어 있다.

std::array<int, 3>

┌────┬────┬────┐
│ 10 │ 20 │ 30 │
└────┴────┴────┘

std::vector

std::vector<int> V;

V.push_back(10);
V.push_back(20);
V.push_back(30);

원소는 vector 객체와 별도의 동적 저장 공간에 존재한다.

vector 객체
┌────────────────────┐
│  저장소 관리 정보   │
└──────┬─────────────┘
       │
       ▼

연속 동적 저장 공간
┌────┬────┬────┬────┐
│ 10 │ 20 │ 30 │    │
└────┴────┴────┴────┘

필요에 따라 실행 중 크기를 변경할 수 있다.

정리

std::vector는 연속된 메모리를 사용하는 동적 배열 컨테이너다.

핵심 특징은 다음과 같다.

연속 메모리
    ↓
Random Access O(1)
    ↓
좋은 Cache Locality

그리고:

동적 크기
    ↓
size / capacity 관리
    ↓
capacity 부족
    ↓
Reallocation

이라는 구조를 가진다.

특히 vector를 사용할 때는 다음 개념을 함께 이해해야 한다.

vector는 연속된 메모리를 사용하는 대신,
저장 공간이 변경될 때 기존 원소를 가리키는 iterator, pointer, reference가 무효화될 수 있다.

그리고 std::array와 비교하면 다음 한 문장으로 정리할 수 있다.

std::array는 크기가 타입에 포함된 고정 크기 연속 컨테이너이고,
std::vector는 별도의 동적 저장 공간을 관리하며 실행 중 크기를 변경할 수 있는 연속 컨테이너다.

STL(Standard Template Library)이란?

loooong — Sat, 5 Sep 2026 17:04:46 +0900

C++에서 vector, list, map, sort 등을 사용하다 보면 자연스럽게 STL(Standard Template Library)이라는 용어를 접하게 된다.

STL은 단순히 여러 자료구조를 모아놓은 라이브러리가 아니다.

컨테이너에 데이터를 저장하고, Iterator를 통해 접근하며, Algorithm이 Iterator를 기준으로 동작하도록 구성한 범용 라이브러리 설계라는 점이 핵심이다.

이번 글에서는 STL이 등장한 배경과 주요 구성 요소를 먼저 정리한다.

1. STL의 등장 배경

C에서는 연결 리스트, 스택, 큐와 같은 자료구조가 표준 라이브러리의 범용 컨테이너 형태로 제공되지 않기 때문에 필요한 자료구조를 직접 구현하거나 별도의 라이브러리를 사용해야 했다.

정렬이나 탐색의 경우 qsort, bsearch와 같은 표준 함수도 존재하지만, 현대 C++의 STL처럼 다양한 자료형과 자료구조에 동일한 형태로 적용할 수 있는 범용적인 구조는 아니었다.

예를 들어 정수용 스택을 직접 구현했다고 가정해 보자.

struct IntStack
{
    int Data[100]; // 실제 저장할 데이터의 타입
    int Top;       // 스택의 현재 위치를 나타내는 인덱스
};

이번에는 float을 저장해야 한다면 별도의 자료구조가 필요할 수 있다.

struct FloatStack
{
    float Data[100];
    int Top;
};

자료형만 다를 뿐 거의 동일한 코드가 반복된다.

이러한 방식은 다음과 같은 문제가 있다.

자료형마다 비슷한 코드를 반복해서 작성해야 한다.
프로젝트마다 동일한 자료구조를 다시 구현할 수 있다.
구현마다 성능과 안정성이 달라질 수 있다.
자료구조와 알고리즘이 강하게 결합되기 쉽다.
유지보수해야 하는 코드의 양이 증가한다.

C++에서는 이를 해결할 수 있는 Template 기능을 제공한다.

template <typename T>
struct Stack
{
    T Data[100]; // 실제 저장할 데이터의 타입
    int Top;     // 스택의 현재 위치를 나타내는 인덱스
};

하나의 구현으로 여러 자료형을 처리할 수 있다.

Stack<int> IntStack;
Stack<float> FloatStack;
Stack<double> DoubleStack;

STL은 이러한 Generic Programming 개념을 바탕으로 컨테이너, Iterator, 알고리즘 등을 서로 조합해서 사용할 수 있도록 설계되었다.

*Generic Programming : 데이터 형식에 의존하지 않고 알고리즘이나 자료구조를 일반화하여 재사용성을 높이는 프로그래밍 방식

2. STL이란?

STL(Standard Template Library)은 템플릿을 기반으로 컨테이너, Iterator, 알고리즘 등 범용적으로 재사용할 수 있는 구성 요소를 제공하는 라이브러리이다.

오늘날에는 STL의 구성 요소들이 C++ 표준 라이브러리(Standard Library)에 포함되어 제공된다.

여기서 한 가지 구분할 필요가 있다.

STL과 C++ Standard Library는 완전히 같은 의미가 아니다.

C++ 표준 라이브러리는 STL보다 더 넓은 개념이다.

예를 들어 다음과 같은 기능도 C++ 표준 라이브러리에 포함된다.

std::string
std::thread
std::filesystem
std::chrono
std::iostream
std::unique_ptr

일반적인 개발 환경에서는 vector, map, iterator, sort 등의 컨테이너와 알고리즘 계열을 설명할 때 STL이라는 표현을 관습적으로 많이 사용한다.

STL의 핵심 구성 요소는 다음과 같이 정리할 수 있다.

구성 요소	역할	대표 예시
Container	데이터를 저장하고 관리한다.	vector, list, deque, map, set
Iterator	컨테이너의 원소를 탐색하고 접근한다.	iterator, const_iterator, reverse_iterator
Algorithm	Iterator 범위의 데이터를 처리한다.	sort, find, count, copy, transform
Function Object	알고리즘 등에 동작이나 조건을 전달한다.	std::less, std::greater, 사용자 정의 Functor
Allocator	컨테이너가 사용할 메모리 할당 정책을 제공한다.	std::allocator

3. STL의 주요 구성 요소

3.1 Container

Container는 여러 데이터를 저장하고 관리하기 위한 객체이다.

컨테이너마다 내부 자료구조와 특성이 다르기 때문에 필요한 연산에 따라 적절한 컨테이너를 선택해야 한다.

STL 컨테이너는 일반적으로 크게 세 종류로 구분할 수 있다.

STL
├─ Container // 여기!
│  ├─ Sequence Container
│  │  ├─ vector
│  │  ├─ deque
│  │  └─ list
│  │
│  ├─ Associative Container
│  │  ├─ map
│  │  └─ set
│  │
│  ├─ Unordered Associative Container
│  │  ├─ unordered_map
│  │  └─ unordered_set
│  │
│  └─ Container Adapter // 성격이 다름
│     ├─ stack
│     ├─ queue
│     └─ priority_queue
│
├─ Iterator
├─ Algorithm
├─ Function Object
└─ Allocator

Sequence Container

원소의 순서 자체가 중요한 컨테이너이다.

std::vector
std::deque
std::list
std::forward_list
std::array

Associative Container

Key를 기준으로 정렬된 상태를 유지하는 컨테이너이다.

일반적으로 내부적으로 균형 이진 탐색 트리 계열의 자료구조를 사용해 구현된다.

std::map
std::set
std::multimap
std::multiset

표준은 특정 내부 구현을 직접 강제하지는 않지만, 요구되는 복잡도를 만족하기 위해 대부분의 구현체가 Red-Black Tree와 같은 균형 트리를 사용한다.

Unordered Associative Container

해시 테이블을 기반으로 Key를 관리한다.

std::unordered_map
std::unordered_set
std::unordered_multimap
std::unordered_multiset

평균적으로 검색, 삽입, 삭제를 O(1)에 수행할 수 있다.

3.2 Container Adapter

stack, queue, priority_queue는 일반적인 Container와 약간 다르다.

std::stack
std::queue
std::priority_queue

이들은 직접 데이터를 저장하기 위한 독립적인 자료구조라기보다 기존 컨테이너의 인터페이스를 제한하여 특정 자료구조처럼 사용할 수 있도록 만든 Container Adapter이다.

예를 들어 std::stack과 std::queue는 기본적으로 std::deque를 내부 컨테이너로 사용한다.

std::stack<int> Stack;

// 개념적으로는 아래와 같다.
std::stack<int, std::deque<int>> Stack;

// 필요하면 다른 컨테이너를 지정할 수 있다.
std::stack<int, std::vector<int>> Stack;

4. Iterator

Iterator는 컨테이너의 원소를 탐색하고 접근하기 위한 객체이다.

포인터와 비슷하게 다음 연산을 사용할 수 있다.

*It
++It
It != End

예를 들어 vector의 원소를 Iterator로 순회할 수 있다.

std::vector<int> Numbers = {1, 2, 3};

for (auto It = Numbers.begin(); It != Numbers.end(); ++It)
{
    std::cout << *It << '\n';
}

출력 결과는 다음과 같다.

1
2
3

역방향 Iterator도 존재한다.

for (auto It = Numbers.rbegin(); It != Numbers.rend(); ++It)
{
    std::cout << *It << '\n';
}

출력 결과는 다음과 같다.

3
2
1

Iterator가 중요한 이유는 단순히 반복문을 편하게 작성하기 위해서가 아니다.

컨테이너와 알고리즘을 분리하기 위해 사용한다.

예를 들어 std::find는 vector 자체를 인자로 받지 않는다.

std::find(Numbers.begin(), Numbers.end(), 10);

대신 다음과 같이 Iterator 범위를 받는다.

[begin, end)

따라서 알고리즘은 컨테이너의 실제 내부 구조를 직접 알 필요가 없다.

Container
    ↓
 Iterator
    ↓
 Algorithm

이 구조 덕분에 하나의 알고리즘을 여러 컨테이너에 재사용할 수 있다.

std::vector<int> Vector = {1, 2, 3};
std::list<int> List = {1, 2, 3};

std::find(Vector.begin(), Vector.end(), 2);
std::find(List.begin(), List.end(), 2);

vector와 list의 내부 자료구조는 완전히 다르지만 std::find는 동일한 형태로 사용할 수 있다.

이것이 STL의 중요한 설계 특징 중 하나이다.

5. Algorithm

STL Algorithm은 Iterator가 나타내는 범위의 데이터를 처리하는 범용 함수이다.

대표적으로 <algorithm> 헤더에서 다양한 알고리즘을 제공한다.

#include <algorithm>

// 정렬하기
std::sort(Numbers.begin(), Numbers.end());

// 원소 찾기
auto It = std::find(
    Numbers.begin(),
    Numbers.end(),
    10
);

// 특정 값의 개수 세기
int Count = std::count(
    Numbers.begin(),
    Numbers.end(),
    5
);

// 복사하기
std::copy(
    Source.begin(),
    Source.end(),
    Destination.begin()
);

여기서 중요한 점은 대부분의 알고리즘이 컨테이너가 아닌 이터레이터를 사용한다는 것이다.

따라서 알고리즘과 자료구조가 강하게 결합되지 않는다.

다만 모든 알고리즘을 모든 컨테이너에서 사용할 수 있는 것은 아니다.

알고리즘마다 요구하는 Iterator의 종류가 다르기 때문이다.

대표적인 예가 std::sort이다.

std::sort(
    Numbers.begin(),
    Numbers.end()
);

std::sort는 Random Access Iterator를 요구한다.

따라서 vector에는 사용할 수 있다.

std::vector<int> Numbers;

std::sort(
    Numbers.begin(),
    Numbers.end()
);

하지만 list에는 사용할 수 없다.

std::list<int> Numbers;

// 컴파일 오류
std::sort(
    Numbers.begin(),
    Numbers.end()
);

std::list의 Iterator는 Random Access Iterator가 아니기 때문이다.

대신 list는 자체 정렬 함수를 제공한다.

Numbers.sort();

이처럼 STL에서는 알고리즘이 요구하는 Iterator Category와 컨테이너가 제공하는 Iterator Category의 관계도 중요하다.

Iterator의 종류는 이후 별도의 글에서 자세히 다룬다.

6. Function Object(Functor)

Function Object는 함수처럼 호출할 수 있는 객체이다.

일반적으로 클래스나 구조체에서 함수 호출 연산자인

operator()

를 오버로딩하여 만든다.

예를 들어 다음과 같은 Functor를 만들 수 있다.

struct Compare
{
    bool operator()(int A, int B) const
    {
        return A > B;
    }
};

객체를 생성한 뒤 함수처럼 호출할 수 있다.

Compare Comp;

bool Result = Comp(10, 5);

std::sort의 비교 함수로도 전달할 수 있다.

std::sort(
    Numbers.begin(),
    Numbers.end(),
    Compare{} // 소괄호도 가능
);

STL에서는 기본적으로 여러 Function Object를 제공한다.

std::less<int>
std::greater<int>
std::plus<int>
std::minus<int>

예를 들어 내림차순 정렬을 다음과 같이 작성할 수 있다.

std::sort(
    Numbers.begin(),
    Numbers.end(),
    std::greater<int>{}
);

Lambda도 Function Object인가?

다음과 같이 Lambda를 전달할 수도 있다.

std::sort(
    Numbers.begin(),
    Numbers.end(),
    [](int A, int B)
    {
        return A > B;
    }
);

Lambda 자체는 람다 표현식(Lambda Expression)이다.

컴파일러는 각 Lambda Expression에 대해 고유한 Closure Type을 만들고, 람다 표현식을 평가하면 해당 타입의 Closure Object가 생성된다.

이 객체에는 operator()가 정의되므로 함수처럼 호출할 수 있다.

개념적으로는 다음과 비슷하게 생각할 수 있다.

struct CompilerGeneratedLambda
{
    bool operator()(int A, int B) const
    {
        return A > B;
    }
};

따라서 Lambda가 만들어내는 Closure Object 역시 Function Object의 한 종류로 사용할 수 있다.

7. Allocator

Allocator는 컨테이너가 원소를 저장할 메모리를 확보하고 반환하는 방법을 추상화한 객체이다.

예를 들어 std::vector<int>는 기본 Allocator로 std::allocator<int>를 사용한다.

std::vector<
    int,
    std::allocator<int>
> Numbers;

두 번째 Template 인자를 생략하면 기본값이 사용되므로 일반적으로는 다음과 같이 작성한다.

std::vector<int> Numbers;

Allocator를 별도의 정책으로 분리한 이유는

컨테이너의 자료구조 관리와 메모리 할당 정책을 분리하기 위해서이다.

개념적으로 보면 다음과 같다.

std::vector
    │
    ├─ 원소 배치와 크기 관리
    │
    └─ Allocator
          └─ 저장 공간 확보 / 반환

따라서 필요한 경우 컨테이너의 동작 자체를 다시 구현하지 않고 메모리 할당 전략을 변경할 수 있다.

예를 들어 특수한 환경에서는

메모리 풀
Arena Allocator
고정 크기 메모리 영역
별도의 메모리 추적 시스템

등과 연결된 Allocator를 사용할 수 있다.

특히 게임이나 실시간 애플리케이션에서는 메모리 단편화, allocation 비용, 캐시 효율, 메모리 추적 등이 중요하기 때문에 메모리 할당 전략이 성능에 영향을 줄 수 있다.

다만 일상적인 C++ 코드에서는 대부분 기본 Allocator를 그대로 사용한다.

또한 모든 컨테이너가 동적 메모리 할당을 사용하는 것은 아니다.

대표적으로

std::array<int, 10>

은 고정 크기 배열이기 때문에 std::allocator를 사용해 별도의 동적 저장 공간을 확보하지 않는다.

따라서

"모든 STL 컨테이너가 std::allocator를 사용한다."

라고 표현하기보다는

동적 메모리를 관리하는 표준 컨테이너들은 일반적으로 Allocator를 통해 메모리 할당 정책을 지정할 수 있으며, 기본적으로 std::allocator를 사용한다.

라고 이해하는 편이 정확하다.

8. STL의 핵심 설계

STL에서 가장 중요하게 볼 부분은 각각의 기능보다 구성 요소가 어떻게 분리되어 있는가이다.

예를 들어 다음과 같은 코드가 있다.

std::vector<int> Numbers = {5, 3, 1, 4, 2};

std::sort(
    Numbers.begin(),
    Numbers.end(),
    std::greater<int>{} // 내림차순
);

여기에는 다섯 가지 구성 요소가 모두 사용된다.

             ┌─ Function Object (Functor)
             │
Container → Iterator → Algorithm
    │
    └─ Allocator

즉 STL의 핵심은

Container가 데이터를 저장하고, Iterator가 데이터에 접근하는 공통 인터페이스 역할을 하며, Algorithm은 Iterator를 통해 데이터를 처리한다.

는 구조에 있다.

이 덕분에 컨테이너와 알고리즘을 서로 독립적으로 설계하면서도 다양한 조합으로 재사용할 수 있다.

정리

STL의 핵심 구성 요소를 정리하면 다음과 같다.

요소	역할
Container	데이터를 저장하고 관리한다. Container Adapter : 기존 컨테이너의 인터페이스를 제한해 특정 자료구조를 제공한다.
Iterator	컨테이너의 원소에 접근하고 순회한다.
Algorithm	Iterator 범위의 데이터를 처리한다.
Function Object	알고리즘 등에 동작과 조건을 전달한다.
Allocator	컨테이너의 메모리 할당 정책을 제공한다.

그중에서도 알고리즘이 특정 컨테이너에 직접 의존하지 않고 Iterator를 통해 동작하도록 설계되어 있다는 점이 STL의 핵심적인 특징이다.

이후에는 실제로 가장 많이 사용되는 STL 컨테이너 중 하나인

std::vector

부터 내부 구조와 메모리 관리 방식을 자세히 살펴본다.

Spline 기반 3요소 조향 알고리즘

loooong — Sat, 29 Aug 2026 01:21:15 +0900

자동차가 Spline 위의 한 점만 바라보게 하면 경로를 따라 움직일 수는 있다. 하지만 속도가 높아지거나 커브가 급해지면 차량이 도로 중심을 크게 벗어나거나 조향이 늦게 시작되는 문제가 나타난다.

이 문제를 줄이기 위해 전방 목표 위치, Spline의 진행 방향, 도로 중심선 이탈 거리를 함께 사용하는 조향 로직을 구현했다.

이 글에서는 USplineFollowerComponent에서 사용한 Position Delta, Heading Delta, Crosstrack Error의 계산 과정과 각 요소를 결합한 이유를 정리한다.

Position, Heading, Crosstrack과 속도·곡률 적응형 Look Ahead를 모두 적용한 정상 주행 모습

위 GIF는 이 글에서 설명할 세 가지 조향 요소를 모두 적용한 최종 상태다. 차량은 전방 목표점을 따라가면서 Spline의 진행 방향을 미리 반영하고, 중심선에서 이탈하면 Crosstrack 보정으로 복귀한다.

GIF의 디버그 표시 읽는 법

파란 구는 차량의 현재 진행 거리에 해당하는 Spline 기준 위치다.
빨간 구는 조향 계산에 실제로 사용하는 Look Ahead 목표점이다.
노란 선은 차량에서 빨간 목표점으로 향하는 방향이다. Position Delta의 기준이 된다.
초록 화살표는 빨간 목표점에서 Spline이 향하는 접선 방향이다. Heading Delta의 기준이 된다.

조향 계산의 전체 흐름

조향값은 다음 순서로 계산한다.

차량 위치와 속도 조회
↓
속도와 곡률로 Look Ahead 거리 계산
↓
Spline의 전방 위치와 접선 방향 조회
↓
Position Delta 계산
Heading Delta 계산
Crosstrack Error 계산
↓
Position과 Heading 가중 결합
↓
Crosstrack 보정 추가
↓
-1부터 1 사이로 Clamp
↓
Chaos Vehicle Steering Input

Position Delta와 Heading Delta는 각도 오차다. 두 값을 가중 결합해 기본 조향 방향을 구한다.

Crosstrack Error는 각도가 아니라 도로 중심선에서 벗어난 거리다. 따라서 두 각도와 동일한 가중평균에 넣지 않고 별도의 중심선 복귀 보정으로 사용했다.

고정 Look Ahead의 한계

Look Ahead는 차량이 현재 위치보다 얼마나 앞의 경로(빨간 구)를 바라볼 것인지 결정하는 거리다.

고정된 Look Ahead를 사용하면 모든 상황에 같은 거리를 적용하게 된다.

(좌) Fixed Long Look Ahead (우) Fixed Short Look Ahead

좌측은 Look Ahead를 길게 고정한 결과다. 빨간 구가 멀리 있어 직선에서는 조향이 완만하지만 급커브에서는 차량이 현재 도로의 굴곡보다 먼 목표점을 먼저 바라본다. 그 결과 노란 선이 커브 안쪽을 가로지르고 차량도 중심선을 크게 잘라 주행할 수 있다.

우측은 Look Ahead를 매우 짧게 설정한 극단적인 사례다. 빨간 구가 차량 가까이에 붙기 때문에 작은 위치 변화도 목표 방향을 크게 바꾸고 조향이 민감해진다.

GIF 속 커브길에 적절한 Look Ahead 값을 찾았다 해도, 차량의 속도과 커브의 정도에 따라 주행 결과가 또 어긋난다.

저속에서 너무 멀리 보면 가까운 경로 변화에 둔감해진다.
고속에서 너무 가까이 보면 작은 오차에도 조향이 크게 바뀐다.
급커브에서 너무 멀리 보면 커브 안쪽을 가로지르기 쉽다.

이는 빨간 구가 동일한 Spline 진행 거리 기준 항상 동일한 거리 앞에 놓이게 되면 모든 차량 속도와 도로 형상을 동시에 만족시키기 어렵다는 것을 보여준다.

속도와 곡률에 따라 Look Ahead 조절하기

위와 같이 다양한 상황에 대응하기 위해, 차량 속도가 높을수록 Look Ahead를 늘리고, 현재 곡률이 커질수록 다시 줄였다.

CurvatureScale = Lerp(
    1.0,
    0.5,
    Clamp(CurrentCurvature × 3.0, 0.0, 1.0)
)

LookAheadDistance =
    (LookAheadBase + Speed × LookAheadSpeedFactor)
    × CurvatureScale

직선에서는 CurvatureScale이 1에 가까워진다. 차량 속도에 따라 더 먼 지점을 바라보며 조향 변화가 완만해진다.

커브가 급해질수록 Scale은 0.5에 가까워진다. 목표점을 차량과 가까운 위치로 당겨 경로의 굴곡을 더 적극적으로 따라가게 한다.

Speed + Curvature Adaptive Look Ahead

그럼에도 조금은 어색한 부분이 있다.

차량 앞 방향과 노란선이 벌어지는 양상을 보면, 차량이 Spline이 꺾이는 방향을 늦게 반영하고 있는 것을 볼 수 있다. 그래서 중심선을 비스듬하게 슬라이딩하는 모습까지 보이게 된다.

이것이 바로 목표점 하나만 추종했을 때의 문제이다.

Position Delta / Heading Delta / Crosstrack Error

*현재까지는 이 Position Delta만 적용되고 있다.

Spline 추종을 구현하는 가장 단순한 방법은 차량 앞의 목표점을 구하고 그 방향으로 조향하는 것이다.

차량 현재 위치
    ↓
Spline 위 전방 목표점 (빨간 구)
    ↓
목표점 방향과 차량 방향의 각도 차이
    ↓
Steering Input

Position Delta는 차량이 전방 목표 위치를 바라보기 위해 필요한 Yaw 각도 차이다.

전방 목표 위치로 가려면
현재 방향에서 얼마나 회전해야 하는가?

먼저 현재 진행 거리에 Look Ahead를 더해 전방 목표 위치를 구한다.

// 열린 Spline에서는 목표 거리가 전체 길이를 넘지 않도록 제한한다. 
// 닫힌 Spline에서는 전체 길이를 기준으로 Wrap한다.

LookAheadProgress = ProgressDistance + LookAheadDistance

LookAheadPosition =
    Spline.GetLocationAtDistanceAlongSpline(
        LookAheadProgress,
        WorldSpace
    )

차량 위치에서 목표 위치로 향하는 방향은 다음과 같이 구한다.

DirectionToTarget =
    Normalize(LookAheadPosition - VehicleLocation)

TargetYaw = atan2(
    DirectionToTarget.Y,
    DirectionToTarget.X
)

마지막으로 차량 Yaw와 목표 방향의 가장 짧은 각도 차이를 계산한다.

PositionDelta =
    FindDeltaAngleDegrees(VehicleYaw, TargetYaw)

Position Delta / Heading Delta / Crosstrack Error

Position Delta는 목표점의 위치를 보지만 그 지점에서 도로가 어느 방향으로 이어지는지는 알지 못한다.

Heading Delta는 Look Ahead 지점의 Spline 접선 방향(초록 화살표)과 차량 방향의 차이다.

전방의 도로는 어느 방향으로 이어지며
차량은 그 방향과 얼마나 어긋나 있는가?

PathDirection =
    Spline.GetDirectionAtDistanceAlongSpline(
        LookAheadProgress,
        WorldSpace
    )

PathYaw = atan2(
    PathDirection.Y,
    PathDirection.X
)

HeadingDelta =
    FindDeltaAngleDegrees(VehicleYaw, PathYaw)

Position Delta가 목표 위치를 향하게 만든다면 Heading Delta는 전방 경로의 방향을 미리 조향에 반영한다.

두 값은 비슷해 보이지만 역할이 다르다.

Position Delta는 목표점으로 수렴하게 한다.
Heading Delta는 Spline의 진행 방향에 차량의 자세를 맞춘다.

Position + Heading

Position에 Heading을 추가한 결과다. 빨간 구의 위치는 같지만 초록 화살표가 나타내는 Spline 접선 방향을 실제 조향에 함께 사용한다. 따라서 단순히 목표점을 향하는 것을 넘어 전방에서 도로가 꺾이는 방향으로 차량 자세를 미리 맞춘다.

차량 자세를 맞추면서 중앙선에서 벗어나는 현상은 다음으로 나오는 Crosstrack Error로 해결할 수 있다.

Position Delta / Heading Delta / Crosstrack Error

Position과 Heading을 함께 사용해도 차량이 도로 중심에서 벗어난 상태로 경로와 평행하게 달릴 수 있다.

중심선에서 약간 이탈시켜 출발한 차량, Position + Heading

Crosstrack Error는 차량과 Spline 중심선 사이의 좌우 이탈 거리를 나타낸다.

먼저 현재 진행 거리에서 Spline의 위치와 접선 방향을 구한다.

NearestOnPath =
    Spline.GetLocationAtDistanceAlongSpline(
        ProgressDistance,
        WorldSpace
    )

PathTangent = Normalize(NearestOnPath)

그다음 차량 위치와 중심선 위치의 Offset을 계산한다.

Offset = VehicleLocation - NearestOnPath

Offset에는 Spline의 진행 방향 성분도 포함될 수 있다. 좌우 이탈만 얻기 위해 접선 방향 성분을 제거한다.

// Offset에서 접선 방향 성분을 제거해 수직 이탈을 구하는 과정
// 주황 화살표 - 초록 화살표

PerpendicularOffset = Offset - PathTangent × Dot(Offset, PathTangent)

월드 UpVector만 사용하지 않은 이유

평평한 도로라면 월드 UpVector와 Path Tangent의 Cross Product로 도로 오른쪽 방향을 구할 수 있다. (왼손 좌표계)

하지만 경사로나 높낮이가 있는 도로에서는 월드 수평면만 기준으로 계산하면 좌우 방향에 불필요한 오차가 생길 수 있다.

이를 줄이기 위해 월드 UpVector를 Path Tangent에 수직인 평면으로 투영해 도로 기준의 법선 방향을 만들었다.

ProjectedUp =
    WorldUp
    - PathTangent × Dot(WorldUp, PathTangent)

RoadNormal = Normalize(ProjectedUp)

PathRight = Cross(RoadNormal, PathTangent)

마지막으로 수직 Offset을 Path Right에 투영한다.

CrosstrackError =
    Dot(PerpendicularOffset, PathRight)

경사로와 평지를 달리는 차량 우측 모습

부호는 차량이 중심선의 어느 쪽에 있는지를 나타낸다.

양수면 도로 오른쪽으로 이탈한 상태다.
음수면 도로 왼쪽으로 이탈한 상태다.

오른쪽으로 이탈했다면 왼쪽으로 조향하고, 왼쪽으로 이탈했다면 오른쪽으로 조향해야 한다.

Crosstrack 보정 후

Position + Heading + Crosstrack 차량이 중심선으로 돌아온다

동일하게 중심선에서 이탈한 상태로 시작해도, Crosstrack Error의 부호와 크기가 최종 Steering에 추가되면서 차량이 파란 구가 이동하는 중심선 방향으로 더 명시적으로 복귀한다.

세 요소 결합하기

Position Delta와 Heading Delta는 HeadingWeight로 결합한다.

YawCommand =
    PositionDelta × (1 - HeadingWeight)
    + HeadingDelta × HeadingWeight

기본값에서는 Heading의 비중을 높여 전방 경로 방향을 미리 반영한다.

다만 커브가 급할 때는 Position의 비중을 높인다.

목표 위치로의 수렴을 강화해 커브에서 경로를 크게 벗어나는 것을 줄이기 위해서다.

DynamicHeadingWeight = Lerp(
    HeadingWeight,
    0.3,
    Clamp(CurrentCurvature × 3.0, 0.0, 1.0)
)

최종 Steering은 Yaw 명령을 정규화하고 Crosstrack 보정을 빼서 계산한다.

Steering = Clamp(
    YawCommand / MaxYawDelta
    - CrosstrackError × CrosstrackGain,
    -1.0,
    1.0
)

오른쪽 이탈은 양수이므로 Steering에서 양수 보정값을 뺀다. 결과적으로 차량은 왼쪽으로 조향한다.

반대로 왼쪽 이탈은 음수다. 음수를 빼면 Steering 값이 증가해 오른쪽 복귀 조향이 적용된다.

마무리

세 요소를 결합하면서 각 요소가 서로 다른 문제를 담당하게 됐다. 목표 위치만 추종할 때보다 커브 방향을 먼저 반영할 수 있었고, 중심선에서 벗어난 뒤에도 복귀 방향을 명시적으로 계산할 수 있었다.

Position Delta

전방 목표 위치를 향하게 한다.
차량을 경로 위의 목표점으로 수렴시킨다.

Heading Delta

전방 경로의 진행 방향을 미리 반영한다.
차량 자세를 Spline 접선 방향에 맞춘다.

Crosstrack Error

도로 중심선에서 벗어난 거리를 측정한다.
좌우 이탈을 별도의 복귀 조향으로 보정한다.

계산한 값을 Chaos Vehicle에 전달하기

USplineFollowerComponent는 소유 Pawn의 공개 인터페이스를 호출하여 최종 Steering 값을 넘긴다.

OwnerPawn->DoSteering(Steering);

ACityVehiclePawn은 전달받은 값을 Chaos Vehicle Movement Component에 적용한다.

void ACityVehiclePawn::DoSteering(float SteeringValue)
{
    ChaosVehicleMovement->SetSteeringInput(
        SteeringValue
    );
}

이 구조를 사용하면 SplineFollowerComponent는 차량 물리 컴포넌트의 세부사항보다 조향 계산에 집중할 수 있다.

기술 기록 시리즈

Unreal Engine 5로 만든 자동차 자율주행 시뮬레이션
DataTable과 SceneCapture2D로 구현한 인터랙티브 차량 선택 UI
UI 인터랙션을 위한 세 가지 Material 기록
Spline 기반 3요소 조향 알고리즘 (현재 게시글)
곡률 기반 안전속도와 계층형 속도 제한
Blackboard와 Behavior Tree를 이용한 환경 대응
구현 과정에서 발견한 문제와 개선 방향

C++ static 정리 — 정적 지역 변수부터 정적 멤버 변수와 함수까지

loooong — Thu, 27 Aug 2026 13:33:55 +0900

C++에서 static을 처음 배우면 조금 혼란스럽다.

함수 안에서도 사용할 수 있고, 전역 변수에도 붙일 수 있으며, 클래스의 멤버 변수와 멤버 함수에도 붙일 수 있기 때문이다.

static int Value;

class Cat
{
    static int Count;
    static void PrintCount();
};

모두 같은 static이라는 키워드를 사용하지만 의미가 완전히 동일한 것은 아니다.

특히 static = 프로그램이 끝날 때까지 살아 있는 변수라고만 기억하면 파일 범위 static이나 정적 멤버 함수를 설명하기 어려워진다.

그래서 이번에는 static을 어디에 사용했는가를 기준으로 나누어 정리해봤다.

변수의 수명과 범위

변수를 이해할 때는 수명(storage duration)과 범위(scope)를 구분해서 보는 것이 중요하다.

C에서 공부했던 내용을 단순화하면 다음처럼 볼 수 있다.

종류	수명	접근 가능한 범위
일반 지역 변수	함수 실행 동안	해당 블록
정적 지역 변수	프로그램 실행 동안	해당 블록
전역 변수	프로그램 실행 동안	선언을 볼 수 있는 영역
파일 범위 static 변수	프로그램 실행 동안	해당 번역 단위

여기서 중요한 점은 수명과 범위는 서로 다른 개념이라는 것이다.

예를 들어 정적 지역 변수는 함수가 끝난 뒤에도 객체 자체는 살아 있지만, 그 이름은 함수 밖에서 사용할 수 없다.

void Foo()
{
    static int Count = 0;
}

Count의 수명은 길지만 scope는 여전히 Foo() 내부다.

함수 내부의 static

함수 내부에서 static 지역 변수를 선언하면 해당 객체는 static storage duration, 즉 정적 저장 기간을 가진다.

선언과 동시에 초기화하면, 초기화는 한 번만 이루어진다!

함수 내부의 정적 지역 변수는 해당 선언에 처음 도달했을 때 초기화되고, 이후 함수가 다시 호출되어도 다시 초기화되지 않는다.

C++11부터는 함수 지역 정적 변수의 초기화가 스레드 안전하게 한 번만 수행되도록 언어 차원에서 보장된다.

#include <iostream>

void CreateCanCoke()
{
    static int CreatedCanCokeCount = 0; // 선언과 동시에 초기화

    ++CreatedCanCokeCount;

    std::cout
        << "CreatedCanCokeCount: "
        << CreatedCanCokeCount
        << '\n';
}

int main()
{
    CreateCanCoke(); //1
    CreateCanCoke(); //2
    CreateCanCoke(); //3
}

실행 결과는 다음과 같다.

CreatedCanCokeCount: 1
CreatedCanCokeCount: 2
CreatedCanCokeCount: 3

일반 지역 변수였다면 함수가 호출될 때마다 새로 만들어졌을 것이다.

void CreateCanCoke()
{
    int CreatedCanCokeCount = 0;

    ++CreatedCanCokeCount;
}

이 경우 호출할 때마다 다시 0에서 시작한다.

(+) 선언과 동시에 초기화 하지 않으면, 이후 코드가 매번 실행되어 의도한 동작이 안 될 수도 있다는 점 참고!

#include <iostream>

void CreateCanCoke()
{
    static int CreatedCanCokeCount; // 선언과 동시에 초기화 하기 않으면
    
    CreatedCanCokeCount = 0;
    
    ++CreatedCanCokeCount;

    std::cout
        << "CreatedCanCokeCount: "
        << CreatedCanCokeCount
        << '\n';
}

int main()
{
    CreateCanCoke(); // 1
    CreateCanCoke(); // 1
    CreateCanCoke(); // 1
}

데이터 섹션이라고 외우지 않기

정적 변수에 대해 흔히

static 변수는 데이터 영역에 저장된다.

라고 설명한다.

static의 본질은 "데이터 영역에 저장된다"가 아니라 "정적 저장 기간을 가진다"는 것이다.
.data나 .bss에 저장되는 것은 일반적인 컴파일 환경에서 그 규칙을 구현하는 대표적인 방법이다.

따라서 개념적으로는

일반 지역 변수
→ 함수 호출 동안 살아 있음
→ automatic storage duration
→ 일반적으로 스택을 사용

static 지역 변수
→ 프로그램 종료까지 살아 있음
→ static storage duration
→ 일반적으로 .data / .bss 등의 정적 영역 사용

으로 이해하는 것이 더 정확하다.

클래스의 static 멤버 변수 - 정적 멤버 변수

클래스 안에서도 멤버 변수에 static을 붙일 수 있다.

class Cat
{
public:
    Cat();

private:
    static float TailLength;
};

일반 멤버 변수는 객체마다 하나씩 존재한다.

class Cat
{
    float Weight;
};

Cat A;
Cat B;
Cat C;

라면 Weight는 각각의 객체 A, B, C가 자기 값을 가진다.

하지만 정적 멤버 변수는 다르다.

class Cat
{
    static float TailLength;
};

Cat 객체가 몇 개 만들어지든 TailLength는 객체마다 복제되는 멤버가 아니다.

Cat A
Cat B
Cat C

        ↓

Cat::TailLength 하나를 공유

따라서 정적 멤버 변수는 특정 객체가 아니라 클래스 자체에 속하는 상태를 표현할 때 사용할 수 있다.

예를 들어 지금까지 생성된 객체 수를 기록할 수 있다.

class Cat
{
public:
    Cat();

    static int GetCount();

private:
    static int Count;
};

int Cat::Count = 0;

Cat::Cat()
{
    ++Count;
}

int Cat::GetCount()
{
    return Count;
}

Cat A;
Cat B;
Cat C;

std::cout << Cat::GetCount();

결과는 3이 된다.

정적 멤버 변수의 정의

전통적인 C++ 코드에서는 클래스 안에 정적 멤버 변수를 선언한 뒤 cpp 파일에서 별도로 정의한다.

// Cat.h

#pragma once

class Cat
{
private:
    static float TailLength; // 정적 멤버의 선언
};

// Cat.cpp

#include "Cat.h"

float Cat::TailLength = 5.0f;

클래스 안의

static float TailLength;

는 정적 멤버의 선언이다.

실제 정의는

float Cat::TailLength = 5.0f;

처럼 클래스 밖에 작성한다.

C++17에서는 inline static도 사용할 수 있다

정적 멤버 변수는 반드시 cpp 파일에서 초기화해야 한다.

라고 외우면 현대 C++에서는 정확하지 않다.

C++17부터는 inline static 멤버를 사용할 수 있다.

class Cat
{
private:
    inline static float TailLength = 5.0f;
};

이 경우 헤더에서 바로 정의하고 초기화할 수 있다.

여러 cpp 파일에서 이 헤더를 include해도 inline 변수에 대한 ODR 규칙 덕분에 중복 정의 문제가 발생하지 않는다.

따라서 다음 두 방식을 구분해두면 된다.

// 전통적인 방식

// Cat.h
class Cat
{
    static float TailLength; // 선언만 - 헤더에서 초기화할 경우 중복 정의 에러 발생
};

// Cat.cpp
float Cat::TailLength = 5.0f;

또는 C++17 이후에는

class Cat
{
    // inline static 멤버로 헤더에서 바로 정의하고 초기화 가능
    inline static float TailLength = 5.0f;
};

처럼 작성할 수 있다.

생성자에서 정적 멤버를 초기화하지 않는 이유

정적 멤버 변수는 일반 멤버 변수와 달리 생성자 초기화 리스트에서 초기화하는 대상이 아니다.

// Cat.h

class Cat
{
public:
    Cat(float InWeight)
        : Weight(InWeight) // 초기화
    {
    	TailLength = 5; // 대입 - 문법적으로 가능
                        // 하지만 객체 생성 때마다 공유 변수에 대입됨
    }

private:
    float Weight;
    static float TailLength;
};

Weight는 각각의 Cat 객체가 자기 값을 가지므로 객체 생성 과정에서 초기화하는 것이 자연스럽다.

객체마다 만들어지는 값이 아니기 때문에 객체 생성자의 멤버 초기화 리스트에서 초기화하는 개념과 맞지 않는다.

(생성자 초기화 리스트는 기본적으로 지금 생성 중인 객체의 구성 요소(subobject)를 초기화하는 곳이다.)

생성자 본문에서 정적 멤버에 값을 대입하는 것은 가능하지만, 이는 초기화가 아니라 객체가 생성될 때마다 수행되는 일반적인 대입이다.

// Cat.cpp

float Cat::TailLength = 5.0f; // 반드시 Cat::

클래스 밖에서 초기화해줄 경우, 반드시 Cat:: 을 붙여 초기화해주어야 한다.

그렇지 않으면 Cat의 정적 멤버를 정의하는 것이 아니라 별개의 전역 변수를 정의하는 것이 된다.

static과 접근 지정자는 별개의 개념이다

#include <iostream>
using namespace std;

class Cat
{
public:
    // static 이라고 해서 자동으로 클래스 내부에서만 접근 가능한 것은 아니다.
    inline static int PublicCount = 0;

private:
    inline static int CatCount = 5;
};

int main()
{
    // public static 변수 - 클래스 외부에서도 직접 접근하고 수정 가능
    Cat::PublicCount = 10;
    
    // private static 변수
    //Cat::CatCount = 10; // 컴파일 에러
    
}

static 멤버 함수

멤버 함수에도 static을 붙일 수 있다.

class Math
{
public:
    static float Square(float Value)
    {
        return Value * Value;
    }
};

[특징 1] 정적 멤버 함수는 객체가 없어도 호출할 수 있다.

float Result = Math::Square(12.0f);

[특징 2] 정적 멤버 함수에는 특정 객체가 없으므로 this 포인터도 없다.

일반 멤버 함수의 예시를 보자.

#include <iostream>

class Cat
{
public:
    Cat(int InAge)
        : Age(InAge)
    {
    }

    void PrintAge()
    {
        std::cout << this->Age << '\n';
    }

private:
    int Age;
};

int main()
{
    Cat CatA(3);

    CatA.PrintAge(); // 3

    return 0;
}

PrintAge() 내부의 this는 개념적으로 &CatA 를 가리킨다.

반면, 정적 멤버 함수에는 특정 객체가 없으므로 this 포인터도 없다.

class Cat
{
public:
    static void StaticFunction()
    {
        // std::cout << this->Age; // ❌ this가 없음
    }

private:
    int Age = 3;
};

따라서 정적 멤버 함수는 특정 객체의 상태와 관계없이 클래스라는 논리적 범위에 묶고 싶은 기능을 표현할 때 사용할 수 있다.

static 멤버 함수가 일반 멤버 변수에 접근할 수 없는 이유

다음 클래스를 생각해보자.

class Cat
{
public:
    void NormalFunction();
    static void StaticFunction();

private:
    int Age = 3;
    static int Count;
};

일반 멤버 함수에서는 둘 다 접근할 수 있다.

void Cat::NormalFunction()
{
    Age = 5;
    Count = 10;
}

왜 가능할까?

일반 멤버 함수에는 this가 있기 때문이다.

this->Age

라고 생각할 수 있다.

어떤 객체의 Age인지 명확하다. (특정 가능)

정적 멤버 변수 Count 역시 클래스 전체에 하나뿐이므로 접근할 수 있다. (특정 가능)

반면 정적 멤버 함수는 다르다.

void Cat::StaticFunction()
{
    Age = 5;   // 오류
    Count = 10; // 가능
}

StaticFunction()에는 this가 없다.

따라서

Age = 5;

라고 작성하면 컴파일러 입장에서는 이런 문제가 생긴다.

어느 Cat의 Age를 말하는 것인가?

A.Age?
B.Age?
C.Age?

특정할 수 없다.

반면 Count는 클래스 전체에 하나다.

Cat::Count

이므로 어떤 객체를 선택할 필요가 없다.

예시 코드

왜 GetCatCount()도 static인가?

여기서 CatCount는 특정 Cat 객체의 상태가 아니다.

따라서 굳이 특정 객체를 통해 물어볼 필요 없이, 클래스 자체에게 현재 고양이가 몇 마리인지 묻는 것이 의미상 자연스럽다.

#include <iostream>
using namespace std;

class Cat
{
public:
    // static 이라고 해서 자동으로 클래스 내부에서만 접근 가능한 것은 아니다.
    inline static int PublicCount = 0;
    
    static int GetCatCount()
    {
        return CatCount; // 클래스 내부니까 Cat:: 없어도 됨
    }

private:
    inline static int CatCount = 5;
};



int main()
{
    // public static 변수 - 클래스 외부에서도 직접 접근하고 수정 가능
    Cat::PublicCount = 10;
    ++Cat::PublicCount; 
    cout << Cat::PublicCount << "\n"; // 11
    
    // private static 변수
    //Cat::CatCount = 10; // 컴파일 에러
    
    int temp = Cat::GetCatCount();
    cout << temp<< "\n"; // 5
}

멤버와 static 멤버의 접근 관계

정리하면 다음과 같다.

호출 위치	일반 멤버 변수	static 멤버 변수
일반 멤버 함수	해당 객체(this)의 멤버 변수이므로 특정 가능	클래스 단위로 한 개만 존재하므로 특정 가능
static 멤버 함수	직접 접근 불가능	어떤 객체를 선택할 필요가 없기 때문에 가능

핵심은 static이라는 문법 자체보다 현재 함수에 특정 객체를 나타내는 this가 존재하는가이다.

일반 멤버 함수
→ this 있음
→ 특정 객체의 일반 멤버 접근 가능

static 멤버 함수
→ this 없음
→ 특정 객체의 일반 멤버를 알 수 없음

물론 정적 멤버 함수에 객체를 직접 전달한다면 그 객체의 멤버에는 접근할 수 있다.

class Cat
{
public:
    static void PrintAge(const Cat& Target)
    {
        std::cout << Target.Age;
    }

private:
    int Age = 3;
};

문제는 정적 멤버 함수가 멤버에 절대 접근할 수 없다는 것이 아니라, 암시적인 대상 객체인 this가 없다는 것이다.

static 함수만 모은 클래스

다음처럼 특정 객체를 만들 필요가 없는 함수들을 하나의 클래스에 모으는 코드도 작성할 수 있다.

class MyMath
{
public:
    static float Square(float Value)
    {
        return Value * Value;
    }

    static float Power(float Value, float Exponent)
    {
        return std::pow(Value, Exponent);
    }

private:
    MyMath() = delete;
};

사용할 때는 객체를 만들지 않는다.

float A = MyMath::Square(3.0f);
float B = MyMath::Power(2.0f, 3.0f);

이런 클래스는 사실상 클래스 이름을 namespace처럼 사용하여 관련 함수를 묶은 형태에 가깝다.

다만 C++에서는 객체 상태가 전혀 필요 없는 단순 함수 그룹이라면 클래스만이 정답은 아니다.

namespace MyMath
{
    float Square(float Value)
    {
        return Value * Value;
    }
}

처럼 namespace를 사용할 수도 있다.

따라서

객체의 개념이 필요한가?
클래스의 private 상태와 함께 관리되어야 하는가? 
단순한 함수 그룹인가?

를 보고 클래스와 namespace 선택하는 것이 더 자연스럽다.

static 멤버 함수의 필요성

객체는 필요 없지만 클래스의 캡슐화 경계 안에 있어야 할 때 정적 멤버 함수가 특히 의미가 있다.

Player::Create() 같은 private 생성자를 사용하는 Factory (객체 없이 생성 필요한 경우)
GameManager::GetInstance() 같은 Singleton 접근 함수
Enemy::GetCount() 같은 클래스 공유 상태 접근 함수

정리

static은 사용되는 위치에 따라 의미가 달라진다.

함수 내부 static
→ 함수가 끝나도 객체의 수명을 유지한다.

파일 범위 static
→ 이름을 해당 번역 단위 내부로 제한한다.

static 멤버 변수
→ 객체마다 존재하지 않고 클래스 단위로 공유한다.

static 멤버 함수
→ 특정 객체 없이 호출하며 this 포인터가 없다.

처음에는 static을 단순히 "오래 살아 있는 변수" 정도로 이해했는데, 사용 위치별로 나누어보니 수명, 링키지, 객체 소속 여부라는 서로 다른 문제를 하나의 키워드가 다루고 있다는 점이 핵심이었다.

C++ extern과 파일 범위 static — 다른 cpp 파일의 변수는 어떻게 연결될까?

loooong — Thu, 27 Aug 2026 11:51:44 +0900

C++ 프로젝트가 커지면 하나의 소스 파일에 모든 코드를 작성하지 않고 여러 .h, .cpp 파일로 나누게 된다.

이때 한 가지 궁금증이 생긴다.

// A.cpp
int GValue = 10;

A.cpp에 만들어 둔 GValue를 B.cpp에서도 사용하려면 어떻게 해야 할까?

반대로 어떤 전역 변수는 해당 cpp 파일 안에서만 사용하고 외부에서는 접근하지 못하게 만들고 싶을 수도 있다.

이때 등장하는 것이 extern과 파일 범위에서 사용하는 static이다.

두 키워드를 이해하려면 단순히 "전역 변수를 공유한다", "접근을 막는다"라고 외우기보다 선언과 정의, 그리고 링키지(linkage)를 함께 이해하는 것이 좋다.

선언과 정의

먼저 extern을 이해하려면 선언과 정의의 차이를 알아야 한다.

선언

선언은 컴파일러에게 이름과 타입이 존재한다는 사실을 알려주는 것이다.

extern int GValue;

이 코드는 대략 다음과 같은 의미다.

GValue라는 int 변수가 어딘가에 정의되어 있다.

정의

정의는 실제 객체를 만들어 저장 공간을 갖게 하는 것이다.

int GValue = 2;

이 코드는 실제 GValue 객체를 정의한다.

즉,

extern int GValue;  // 선언
int GValue = 2;     // 정의

처럼 구분할 수 있다.

extern

extern은 다른 번역 단위(translation unit)에 정의된 이름을 사용할 때 주로 사용한다.

여기서 번역 단위는 간단하게 생각하면 전처리가 끝난 하나의 cpp 파일이라고 볼 수 있다.

예를 들어 다음과 같이 구성해볼 수 있다.

ExternTest.h

#pragma once

extern int GValue;

void IncreaseValue();

헤더에서는 GValue를 정의하지 않고 선언만 한다.

여러 cpp 파일에서 이 헤더를 include해도 각 파일에는 다음 선언만 들어간다.

extern int GValue;

따라서 여러 개의 GValue가 만들어지는 것이 아니다.

ExternTest.cpp

#include "ExternTest.h"

int GValue = 2; // 실제 변수 정의 - extern 필요 없음

void IncreaseValue()
{
    ++GValue;
}

실제 변수의 정의는 하나의 cpp 파일에 둔다.

int GValue = 2;

이 코드에서 실제 GValue가 만들어진다.

Main.cpp

#include <iostream>
#include "ExternTest.h"
	// 이 부분에 extern int GValue; void IncreaseValue(); 가 적히게 됨. 
	// 즉, 어딘가에 GValue가 있을 거라는 심볼(빈칸). 링커 과정에서 채워짐. 

int main()
{
    std::cout << GValue << '\n';

    IncreaseValue();

    std::cout << GValue << '\n';

    return 0;
}

Main.cpp 입장에서는 GValue의 실제 정의가 보이지 않는다.

하지만 헤더에

extern int GValue;

가 있기 때문에 컴파일러는 GValue라는 이름이 다른 곳에 정의되어 있다고 가정하고 코드를 컴파일할 수 있다.

이후 링커가 각각의 번역 단위를 연결하면서 Main.cpp에서 사용한 GValue와 ExternTest.cpp에서 정의한 GValue를 연결한다.

따라서 extern은 변수를 만드는 키워드라기보다 다른 곳에 존재하는 정의를 참조하기 위한 선언이라고 이해하는 편이 정확하다.

파일 범위 static

extern이 다른 번역 단위에서도 이름을 사용할 수 있도록 하는 것과 반대로, 파일 범위의 static은 이름을 현재 번역 단위 내부로 제한하는 데 사용할 수 있다.

// A.cpp

static int GValue = 10;

이 GValue는 A.cpp 내부에서만 연결할 수 있다.

이를 internal linkage, 즉 내부 링키지를 가진다고 한다.

다른 파일에서 접근하려 하면

다음과 같은 코드가 있다고 해보자.

// Globals.h

extern int GValue;

// A.cpp

static int GValue = 10;

// B.cpp

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

void PrintValue()
{
    std::cout << GValue;
}

B.cpp는 헤더를 통해 다음 선언을 본다.

extern int GValue;

따라서 컴파일 자체는 가능하다.

하지만 링크 단계에서는 문제가 생긴다.

B.cpp가 기대하는 것은 외부에서 연결할 수 있는 GValue의 정의다.

그런데 A.cpp의

static int GValue = 10;

는 A.cpp 내부에서만 사용할 수 있는 이름이다.

따라서 링커는 B.cpp가 요구하는 GValue의 정의를 찾지 못하고 링크 오류가 발생한다.

B.cpp
extern int GValue
        ↓
외부에서 GValue를 찾음

A.cpp
static int GValue = 10
        ↓
A.cpp 내부에서만 보임

        ↓

연결할 정의 없음
→ 링크 오류

extern과 static의 차이

파일 범위에서 두 키워드의 차이를 정리하면 다음과 같다.

코드	의미
int Value = 10;	전역 변수 정의
extern int Value;	다른 곳에 정의된 Value를 사용하겠다는 선언
static int Value = 10;	현재 번역 단위 내부에서만 연결 가능한 전역 변수 정의

특히 파일 범위의 static에서 중요한 것은 단순히 "접근 제한"이라는 표현보다 internal linkage를 부여한다는 점이다.

C++의 static은 사용 위치에 따라 의미가 달라지기 때문에 이것을 구분해두는 것이 좋다.

파일 범위 static
→ 이름의 링키지를 현재 번역 단위로 제한

함수 내부 static
→ 함수 호출이 끝나도 객체의 수명을 유지

클래스 static 멤버
→ 특정 객체가 아니라 클래스 자체에 속하는 멤버

같은 static이지만 각각 강조되는 성질이 다르다.

파일 내부에서만 사용할 값이라면

C++에서는 cpp 파일 내부에서만 사용할 전역 변수나 함수를 만들 때 파일 범위 static을 사용할 수 있다.

static int InternalValue = 10;

static void PrintInternalValue()
{
}

다만 현대 C++에서는 같은 목적으로 익명 namespace도 많이 사용한다.

namespace
{
    int InternalValue = 10;

    void PrintInternalValue()
    {
    }
}

이 안에 선언한 이름 역시 해당 번역 단위 내부에서만 사용할 수 있다.

따라서 C 스타일의 파일 범위 static을 만났을 때는

"이 이름은 이 cpp 파일 내부 구현에만 사용하려는 것이구나."

라고 이해하면 된다.

정리

extern과 파일 범위의 static은 여러 cpp 파일로 프로그램을 나누기 시작하면 자연스럽게 만나게 된다.

extern은

extern int Value;

처럼 다른 곳에 정의가 존재한다고 선언한다.

반면 파일 범위의 static은

static int Value = 10;

처럼 해당 이름에 내부 링키지를 부여하여 현재 번역 단위 내부에서만 연결되도록 만든다.

결국 두 개념은 다음처럼 대비해서 기억할 수 있다.

extern
→ 다른 번역 단위에 있는 정의와 연결하고 싶다.

파일 범위 static
→ 이 이름을 현재 번역 단위 안에 숨기고 싶다.

C++ 동적 메모리 할당은 왜 필요할까? - Stack과 Heap

loooong — Thu, 27 Aug 2026 10:49:46 +0900

프로그램에서 사용하는 모든 데이터의 크기와 수명을 프로그램 실행 전에 미리 알 수 있는 것은 아니다.

예를 들어 게임을 만든다고 생각해보자. 사용자가 선택한 플레이어 수, 런타임에 생성되는 몬스터의 수, 불러온 맵 데이터의 크기처럼 프로그램이 실행된 이후에야 필요한 메모리 크기가 결정되는 경우가 많다.

또 어떤 객체는 특정 함수가 끝난 뒤에도 계속 살아 있어야 할 수 있다.

이러한 데이터를 다루려면 단순히 지역 변수를 선언하는 것만으로는 부족하다.

이번 글에서는 왜 동적 메모리 할당이 필요한지, 그리고 이를 이해하기 위해 필요한 Stack과 Heap 메모리의 차이를 정리해본다.

동적 메모리 할당이 필요한 이유

[1] 정적 크기만으로는 모든 상황을 처리할 수 없다

다음과 같이 배열을 선언했다고 해보자.

int Players[10];

이 배열은 최대 10개의 int를 저장할 수 있다.

문제는 실제로 플레이어가 몇 명 필요한지 프로그램을 실행하기 전에는 알 수 없는 경우다.

int Count;
cin >> Count;

int Players[Count]; // 컴파일 에러 - expression did not evaluate to a constant

플레이어 수
→ 사용자 입력에 따라 결정

몬스터 수
→ 게임 진행 상황에 따라 결정

맵 데이터 크기
→ 런타임에 불러온 데이터에 따라 결정

이처럼 필요한 데이터의 크기가 런타임(Runtime) 에 결정된다면 처음부터 고정된 크기의 변수만 사용하기 어렵다.

물론 예상되는 최대 크기만큼 미리 크게 잡을 수도 있다.

int Players[10000];

하지만 실제로 몇 개가 필요할지도 모르는 상태에서 항상 최대 크기를 확보하는 방식은 불필요한 메모리를 사용할 수 있다.

필요한 만큼의 메모리를 실행 중에 확보할 수 있다면 더 유연하게 데이터를 관리할 수 있다.

이것이 동적 메모리 할당(Dynamic Memory Allocation) 이 필요한 첫 번째 이유다.

[2] 객체의 수명을 스코프와 분리해야 할 수도 있다

동적 메모리가 필요한 이유는 크기뿐만이 아니다.

지역 변수는 자신이 선언된 스코프와 수명이 연결되어 있다.

void CreatePlayer()
{
    int HP = 100;
}

HP는 CreatePlayer()가 실행되는 동안 존재하고, 함수가 끝나면 더 이상 사용할 수 없다.

CreatePlayer() 호출
        ↓
HP 생성
        ↓
함수 실행
        ↓
CreatePlayer() 종료
        ↓
HP 수명 종료

하지만 실제 프로그램에서는 객체를 함수가 끝난 뒤에도 유지해야 하는 경우가 있다.

예를 들어 어떤 함수에서 플레이어를 생성했지만, 해당 플레이어는 게임이 끝날 때까지 계속 사용해야 할 수 있다.

즉, 필요한 것은

원하는 시점에 생성
        ↓
필요한 동안 유지
        ↓
원하는 시점에 해제

할 수 있는 메모리다.

이처럼 객체의 생명주기를 특정 스코프와 분리해야 하는 경우에도 동적 메모리를 사용한다.

Stack Memory

함수의 지역 변수나 매개변수, 리턴값 등은 일반적으로 Stack Memory와 밀접하게 관련되어 있다.

int Test(int Damage)
{
    int HP = 100;
    HP -= Damage;
    return HP;
}

여기서 Damage, HP와 같은 값은 함수 실행과 함께 사용되고 함수가 끝나면 해당 호출에 속한 스택 영역도 정리된다.

Stack의 특징을 간단히 정리하면 다음과 같다.

Stack Memory

주로 저장되는 것
→ 지역 변수, 매개변수, 리턴값 
→ 함수 호출과 관련된 데이터

수명
→ 해당 함수/스코프의 실행과 밀접하게 연결

관리
→ 함수 호출과 반환에 따라 자동으로 처리

개발자가 직접

delete HP;

와 같은 작업을 할 필요가 없다.

함수가 종료되면 해당 함수 호출이 사용하던 스택 영역이 자동으로 정리된다.

이 때문에 스택은 사용하기 편하고 메모리 관리 비용도 비교적 작다.

Heap Memory

Heap은 프로그램 실행 중에 필요한 만큼 메모리를 동적으로 확보할 수 있는 영역이다.

C++에서는 대표적으로 new를 사용해 Heap에 메모리를 할당할 수 있다.

int* Ptr = new int;

개념적으로는 다음과 같다.

Stack                   Heap

Ptr ──────────────────► [ int ]

여기서 중요한 점은 Ptr과 Ptr이 가리키는 객체가 서로 다른 위치에 존재할 수 있다는 것이다.

int* Ptr = new int;

일반적인 지역 포인터 변수 Ptr 자체는 현재 함수의 지역 변수이므로 Stack 쪽에서 관리될 수 있다.

반면 new int로 생성된 int 객체는 Heap에 존재한다.

즉,

Ptr
→ Heap 객체의 주소를 저장

Heap 객체
→ 실제 동적으로 할당된 데이터

인 구조다.

Heap 객체의 수명은 스코프와 다르다

Heap에 동적으로 할당한 객체는 해당 포인터 변수가 스코프를 벗어난다고 자동으로 해제되는 것이 아니다.

즉, Heap을 이용하면 객체를 생성한 함수의 스코프와 객체의 생명주기를 분리할 수 있다.

Character* CreateCharacter()
{
    Character* Player = new Character();
    return Player;
}

int main()
{
    Character* Player = CreateCharacter();

    Player->Move();

    delete Player;
    Player = nullptr;
}

CreateCharacter() 함수는 이미 종료되었지만, Heap에 동적으로 생성된 Character 객체의 수명은 종료되지 않는다. 동적으로 할당된 객체는 명시적으로 해제하기 전까지 유지되기 때문이다.

Heap은

할당 시점
    ↓
필요한 동안 사용
    ↓
해제 시점

처럼 메모리의 수명을 보다 유연하게 관리할 수 있다는 장점이 있다.

그렇다면 Heap이 Stack보다 좋은 것일까?

그렇지는 않다. Heap은 유연한 대신 관리 비용이 존재한다.

동적 할당 요청이 발생하면 메모리 관리자는 사용 가능한 영역을 찾아 적절한 메모리 블록을 할당해야 한다.

반면 Stack은 함수 호출과 반환에 따라 일정한 방식으로 메모리를 관리할 수 있기 때문에 일반적으로 할당과 해제가 더 단순하다.

따라서 일반적으로

Stack
→ 빠르고 관리가 단순함

Heap
→ 유연하지만 관리 비용이 더 큼

이라고 볼 수 있다.

Heap을 사용한다고 해서 항상 성능이 나쁜 것은 아니지만, 동적 할당이 공짜는 아니라는 점은 기억해둘 필요가 있다.

특히 짧은 시간 동안 수많은 할당과 해제가 반복되는 프로그램에서는 동적 할당 비용도 고려해야 한다.

Heap은 개발자가 수명을 관리해야 한다

Heap의 더 큰 문제는 메모리 관리 책임이다.

다음과 같이 메모리를 할당했다고 해보자.

int* Ptr = new int(100);

사용이 끝났는데도 해제하지 않으면 해당 메모리가 계속 할당된 상태로 남을 수 있다.

int* Ptr = new int(100);

// delete Ptr; 누락

이렇게 더 이상 필요하지 않은 동적 메모리가 적절하게 반환되지 않는 문제를 Memory Leak, 메모리 누수라고 한다.

특히 해당 메모리를 가리키던 포인터까지 잃어버리면 문제가 더 커진다.

int* Ptr = new int(100);

Ptr = nullptr;

이제 처음 할당한 메모리는 여전히 Heap에 존재하지만 주소를 잃어버렸기 때문에 정상적으로 해제할 방법도 사라졌다.

Heap

[100]
 ↑
가리키는 포인터가 없음

따라서 동적 메모리를 사용할 때는 단순히

어디서 할당할 것인가?

만 생각할 것이 아니라

누가 이 메모리를 소유하는가?
언제까지 필요한가?
어디서 해제할 것인가?

까지 함께 생각해야 한다.

프로그램의 메모리 영역

동적 메모리를 공부하면서 Stack과 Heap 외에도 프로그램이 사용하는 메모리 영역을 함께 정리해두면 이해하기 쉽다.

크게 다음과 같이 생각할 수 있다. 각 영역의 역할을 살펴보자.

Code
Data
Heap
Stack

Code 영역

컴파일된 프로그램의 실행 코드, 즉 CPU가 실행할 기계어 명령 등이 저장되는 영역이다.

예를 들어 다음 함수 자체의 실행 명령이 여기에 포함될 수 있다.

void Move()
{
    // ...
}

쉽게 말하면

프로그램이 "무엇을 실행해야 하는지"

에 대한 코드가 저장되는 영역이다.

Data 영역

전역 변수와 정적 변수처럼 프로그램 실행 기간 동안 유지되는 데이터가 저장되는 영역이다.

int GlobalValue = 100;

void Test()
{
    static int Count = 0;
}

이러한 변수의 수명은 일반적으로 프로그램의 실행 기간과 함께한다.

프로그램 시작
    ↓
전역/정적 객체 존재
    ↓
프로그램 실행
    ↓
프로그램 종료

세부적으로는 초기화 여부 등에 따라 여러 섹션으로 다시 나뉠 수 있지만, 우선은 전역 변수와 정적 변수가 프로그램 수명 동안 유지되는 영역이라고 이해해두면 된다.

Stack 영역

함수 호출 과정에서 필요한 데이터가 관리되는 영역이다.

대표적으로 지역 변수, 매개변수, 리턴값고 같이 함수 호출과 관련된 정보가 여기에 위치할 수 있다.

void Attack(int Damage)
{
    int Result = Damage * 2;
}

함수 호출과 반환에 따라 자동으로 관리된다는 것이 중요한 특징이다.

Heap 영역

프로그램 실행 중 동적으로 요청한 메모리를 관리하는 영역이다.

Character* Player = new Character();

Heap 객체는 Stack의 지역 변수처럼 함수가 끝났다고 자동으로 없어지는 것이 아니라, 해당 자원의 소유자가 적절하게 수명을 관리해야 한다.

Stack과 Heap 비교

정리하면 다음과 같다.

중요한 것은 어느 한쪽이 항상 더 좋은 것이 아니라 데이터의 크기와 수명에 맞는 저장 방식을 선택하는 것이다.

구분	Stack	Heap
대표 용도	지역 변수, 함수 호출 관련 데이터	동적으로 할당한 객체
크기 결정	일반적으로 함수 실행 구조 및 정적 타입 정보에 따라 관리	런타임에 필요한 크기만큼 요청 가능
수명	스코프 및 함수 호출과 밀접하게 연결	할당부터 해제까지
관리	자동	동적 자원의 소유자가 관리
할당/해제 비용	일반적으로 작음	일반적으로 더 큼
주요 위험	Stack Overflow 등	Memory Leak, 잘못된 해제 등

정리

동적 메모리 할당이 필요한 이유는 크게 두 가지로 정리할 수 있다.

첫 번째는 런타임에 필요한 메모리 크기가 결정되는 데이터를 처리하기 위해서다.

두 번째는 객체의 생명주기를 현재 함수나 스코프와 분리해 관리하기 위해서다.

이를 위해 Heap 메모리를 사용할 수 있다.

하지만 Heap은 Stack보다 유연한 대신 동적 할당과 해제에 추가적인 관리 비용이 들고, 수명 관리에 실패하면 메모리 누수와 같은 문제가 발생할 수 있다.

따라서 동적 메모리를 공부할 때는 단순히 "new로 메모리를 만든다"라고 이해하기보다,

왜 동적으로 만들어야 하는가?
누가 소유하는가?
언제까지 살아 있어야 하는가?
언제 해제해야 하는가?

를 함께 생각하는 것이 중요하다.

C++ 멤버 접근 제어 방법 - Getter/Setter, friend, using

loooong — Wed, 26 Aug 2026 22:13:50 +0900

클래스를 설계할 때 멤버 변수를 private으로 두는 경우가 많다.

외부에서 객체의 내부 상태를 직접 수정하지 못하게 하고, 클래스가 정해둔 방식으로만 상태를 변경하도록 만들기 위해서다.

그런데 실제 코드를 작성하다 보면 외부에서 private 멤버의 값을 읽거나 수정해야 하는 상황도 생긴다.

이때 단순히 멤버를 public으로 바꾸기보다는, 필요한 범위만 열어주는 여러 방법을 사용할 수 있다.

이번 글에서는 Getter/Setter, friend, 그리고 상속받은 멤버의 접근 수준을 다시 노출할 때 사용하는 using을 통해 C++의 접근 제어 방법을 정리해본다.

Getter와 Setter

가장 기본적인 방법은 public 멤버 함수를 통해 private 멤버에 접근하도록 만드는 것이다.

클래스 내부의 멤버 함수는 자신의 private 멤버에 접근할 수 있기 때문에 가능한 구조이다.

예를 들어 다음과 같이 HP를 private으로 두고 Getter와 Setter를 제공할 수 있다.

class Character
{
public:
    int GetPrivateHP()
    {
        return PrivateHP;
    }

    void SetPrivateHP(int InPrivateHP)
    {
        PrivateHP = InPrivateHP;
    }

private:
    int PrivateHP;
};

외부에서는 PrivateHP에 직접 접근하지 않고 공개된 함수를 사용한다.

Character Player;

Player.SetPrivateHP(100);

int HP = Player.GetPrivateHP();

겉으로 보면 단순히 값을 읽고 쓰는 것뿐이라 public 멤버와 큰 차이가 없어 보일 수 있다.

하지만 함수로 접근 경로를 만들면 나중에 값을 변경하는 규칙을 추가할 수 있다.

예를 들어 HP가 0보다 작아지지 않도록 제한할 수 있다.

class Character
{
public:
    int GetHP() const
    {
        return HP;
    }

    void SetHP(int InHP)
    {
        if (InHP < 0)
        {
            HP = 0;
            return;
        }

        HP = InHP;
    }

private:
    int HP = 100;
};

외부에서는 여전히 같은 방식으로 사용하지만,

Player.SetHP(-100);

실제 상태 변경 규칙은 Character가 관리한다.

즉, Getter와 Setter를 사용하는 이유는 단순히 private 멤버에 우회해서 접근하기 위해서라기보다, 객체가 자신의 상태 변경 규칙을 관리할 수 있도록 하기 위해서라고 볼 수 있다.

Setter가 항상 필요한 것은 아니다

멤버를 private으로 만들었다고 해서 무조건 Getter와 Setter를 둘 다 만들 필요는 없다.

예를 들어 HP는 외부에서 확인할 필요는 있지만 임의로 설정하게 하고 싶지는 않을 수 있다.

class Character
{
public:
    int GetHP() const
    {
        return HP;
    }

    void TakeDamage(int Damage)
    {
        HP -= Damage;
    }

private:
    int HP = 100;
};

이 경우 외부에서는 HP를 읽을 수 있지만 직접 값을 설정할 수는 없다.

Character Player;

int HP = Player.GetHP();

Player.TakeDamage(30);

오히려 다음처럼 모든 private 멤버에 기계적으로 Getter와 Setter를 만들어버리면,

Player.SetHP(999999);

결국 public 멤버로 공개한 것과 큰 차이가 없어질 수도 있다.

따라서 필요한 동작 자체를 함수로 제공하는 것이 더 자연스러운 경우도 많다.

TakeDamage()
Heal()
ConsumeMana()

즉,

private 데이터
        ↓
필요한 public 인터페이스만 제공

하는 형태가 캡슐화의 의도에 더 가깝다.

friend 키워드

때로는 특정 외부 함수나 특정 클래스만 내 클래스의 private, protected 멤버에 직접 접근하도록 허용하고 싶을 수 있다.

이때 friend 키워드를 사용해 권한을 부여할 수 있다.

friend 선언이 friend 클래스/함수에 대한 전방선언 역할도 같이 하기 때문에 일반적으로 별도의 전방선언이 필요 없다.

*다만 friend 함수는 이름 탐색 규칙이 일반적인 함수 선언과 조금 다를 수 있으므로, 외부에서 명시적으로 사용할 함수라면 별도의 선언을 두는 경우도 있다.

friend 함수

먼저 특정 함수 하나를 friend로 지정할 수 있다.

#include <iostream>
using namespace std;

class Character
{
private:
    int HP = 100;
    int MP = 50;

    friend void PrintCharacterInfo(const Character& CharacterObj);
};

void PrintCharacterInfo(const Character& CharacterObj)
{
    cout << "HP : " << CharacterObj.HP << '\n';
    cout << "MP : " << CharacterObj.MP << '\n';
}

PrintCharacterInfo()는 Character의 멤버 함수가 아니다.

하지만 Character 내부에서 friend로 선언했기 때문에 private 멤버에 접근할 수 있다.

중요한 점은 friend 함수가 클래스의 멤버가 되는 것은 아니라는 것이다.

사용할 때는 일반 함수와 동일하다.

int main()
{
    Character Player;

    PrintCharacterInfo(Player);

    return 0;
}

friend 클래스

함수 하나가 아니라 특정 클래스 전체에 접근 권한을 줄 수도 있다.

class Character
{
private:
    int HP = 100;
    int MP = 50;

    friend class GameManager;
};

class GameManager
{
public:
    void Heal(Character& CharacterObj)
    {
        CharacterObj.HP += 100; // private 접근 가능
        CharacterObj.MP += 50;  // private 접근 가능
    }
};

이제 GameManager의 멤버 함수에서는 Character의 private 멤버에 직접 접근할 수 있다.

전체 예시는 다음과 같다.

#include <iostream>
using namespace std;

class Character
{
private:
    int HP = 100;
    int MP = 50;

    friend void PrintCharacterInfo(const Character& CharacterObj);
    friend class GameManager;
};

class GameManager
{
public:
    void Heal(Character& CharacterObj)
    {
        CharacterObj.HP += 100;
        CharacterObj.MP += 50;
    }
};

void PrintCharacterInfo(const Character& CharacterObj)
{
    cout << "HP : " << CharacterObj.HP << '\n';
    cout << "MP : " << CharacterObj.MP << '\n';
}

int main()
{
    Character Player;

    GameManager Manager;

    PrintCharacterInfo(Player);

    Manager.Heal(Player);

    cout << "===== Heal =====\n";

    PrintCharacterInfo(Player);

    return 0;
}

friend는 단방향 관계이다

friend 관계는 자동으로 서로에게 적용되지 않는다.

예를 들어 A가 B를 friend로 선언했다고 하자.

class A
{
private:
    int ValueA;

    friend class B;
};

이 경우 B는 A의 private 멤버에 접근할 수 있다.

하지만 A가 자동으로 B의 private 멤버에 접근할 수 있는 것은 아니다.

즉,

A가 B를 friend로 선언

B → A private 접근 가능
A → B private 접근 가능하다는 뜻은 아님

이다.

필요하다면 B도 별도로 A를 friend로 선언해야 한다.

friend는 캡슐화를 완전히 무시하는 기능일까?

friend는 분명 외부 코드에 private 접근 권한을 제공하기 때문에 남용하면 캡슐화를 약하게 만들 수 있다.

그렇다고 반드시 피해야 하는 기능은 아니다.

핵심은 모든 코드에 데이터를 공개하는 것이 아니라 특정 함수나 특정 타입에만 제한적으로 권한을 제공한다는 점이다.

public
→ 모든 외부 코드에서 접근 가능

friend
→ 내가 지정한 특정 대상만 접근 가능

따라서 서로 강하게 협력하는 타입이나 연산자 오버로딩처럼 클래스 내부 데이터 접근이 자연스러운 경우 등에 사용할 수 있다.

다만 접근 권한이 필요한 대상이 많아지기 시작한다면 클래스의 책임이나 인터페이스 설계를 다시 확인할 필요가 있다.

using으로 상속받은 멤버를 다시 노출하기

using도 접근 제어와 관련해서 사용할 수 있다.

다만 using은 앞에서 본 Getter/Setter나 friend와는 역할이 조금 다르다.

using은 private 멤버에 접근할 수 있게 만들어주는 기능이 아니다.

상속을 통해 이미 접근 가능한 멤버의 이름을 현재 클래스의 다른 접근 영역에 다시 노출하는 데 사용할 수 있다.

예를 들어 부모 클래스에 protected 멤버가 있다고 하자.

class Character
{
protected:
    int HP;
    
    void Move()
    {
        std::cout << "Move\n";
    }
};

Monster는 Character를 public 상속하므로 HP에 접근할 수 있다.

하지만 외부에서는 여전히 HP가 protected이기 때문에 접근할 수 없다.

class Monster : public Character
{
};

int main()
{
    Monster M;

    M.HP = 100; // Error!
    M.Move();   // Error!
}

이때 using을 public 영역에 선언할 수 있다.

class Monster : public Character
{
public:
    using Character::HP;
    using Character::Move; // 메서드도 다시 노출 가능
};

그러면 Monster에서는 HP가 외부에 공개된다.

int main()
{
    Monster M;

    M.HP = 100; // 가능
    M.Move();   // 가능
}

또한, public 상속 받은 자식 클래스 객체에서도 public 접근성이 그대로 이어진다.

class BabyMonster : public Monster // public 상속
{
};

int main()
{
    BabyMonster M;
    M.Move(); // 가능
}

즉, 개념적으로 다음과 같은 변화이다.

Character::HP
protected

        ↓ public 영역에서 using

Monster::HP
public

using으로 private 멤버도 공개할 수 있을까?

불가능하다.

예를 들어 부모의 멤버가 private이라면,

class Character
{
private:
    int HP;
};

자식 클래스 자체가 HP에 접근할 수 없다.

따라서 다음과 같이 다시 노출할 수도 없다.

class Monster : public Character
{
public:
    using Character::HP; // Error!
};

using이 부모의 접근 제한을 무시하는 기능은 아니기 때문이다.

즉, using을 이렇게 이해하는 편이 좋다.

private을 뚫는 기능 X

이미 접근 가능한 상속 멤버를
현재 클래스의 접근 영역에 다시 노출하는 기능 O

Getter/Setter, friend, using은 서로 역할이 다르다

세 가지를 모두 접근 제어와 관련된 기능으로 볼 수 있지만 목적은 다르다.

방법	목적
Getter / Setter	private 상태에 접근할 공개 인터페이스 제공
friend	특정 함수나 클래스에 private/protected 접근 권한 부여
using	상속받아 이미 접근 가능한 멤버를 다른 접근 수준으로 다시 노출

특히 using은 private 멤버에 접근하기 위한 방법으로 보면 안 된다.

Getter/Setter와 friend는 실제로 private 데이터와 관련된 접근 방법이지만, using은 상속 관계에서 접근 수준을 다시 노출하는 기능에 가깝다.

정리

클래스의 멤버를 private으로 만드는 이유는 단순히 외부에서 사용하지 못하게 막기 위해서가 아니다.

객체가 자신의 상태를 직접 관리하고, 외부에서는 필요한 인터페이스를 통해서만 상태를 다루도록 만들기 위함이다.

가장 일반적인 방법은 public 멤버 함수를 통해 필요한 기능을 인터페이스로 제공하는 것이다.
이를 통해 객체는 자신의 상태 변경 규칙을 유지할 수 있다.
특정 함수나 클래스가 내부 데이터에 직접 접근해야 한다면, 단방향 접근 권한을 주는 friend를 사용할 수도 있다.
다만 필요 이상으로 사용하면 클래스 간 결합도가 높아질 수 있다.
마지막으로 using은 조금 성격이 다르다. 부모로부터 상속받아 이미 접근 가능한 멤버를 현재 클래스의 원하는 접근 영역에 다시 노출할 때 사용할 수 있다.

C++ Struct와 Class의 차이, 서로 상속할 수 있을까?

loooong — Wed, 26 Aug 2026 21:10:48 +0900

C++에서 새로운 타입을 정의하다 보면 struct와 class 중 무엇을 사용해야 할지 고민하게 된다.

처음에는 struct는 단순히 데이터를 묶는 용도이고, class는 함수와 객체 지향 기능을 사용하는 타입이라고 생각하기 쉽다.

하지만 C++의 struct와 class는 생각보다 훨씬 비슷하다.

생성자, 소멸자, 상속, 가상 함수, 다형성 등 거의 모든 기능을 동일하게 사용할 수 있다.

그렇다면 굳이 두 문법을 나누어 사용하는 이유는 무엇일까?

이번 글에서는 struct와 class의 실제 차이가 무엇인지, 그리고 코드에서 어떤 기준으로 구분해서 사용하는지 정리해본다.

Struct와 Class는 기능적으로 거의 같다

C에서는 struct가 주로 여러 데이터를 하나로 묶는 용도로 사용되었다.

하지만 C++의 struct는 클래스가 사용할 수 있는 객체 지향 기능을 대부분 동일하게 사용할 수 있다.

예를 들어 struct에도 생성자와 멤버 함수를 정의할 수 있다.

struct Character
{
    Character()
    {
    }

    void Move()
    {
    }
};

상속과 가상 함수도 사용할 수 있다.

struct Character
{
    virtual void Move()
    {
    }
};

struct Monster : public Character
{
    void Move() override
    {
    }
};

즉, C++에서 다음과 같은 기능은 struct와 class 모두 사용할 수 있다.

생성자
소멸자
멤버 함수
상속
가상 함수
다형성

그렇다면 둘의 차이는 무엇일까?

언어 차원에서 중요한 차이는 다음 두 가지이다.

1. 기본 접근 지정자
2. 기본 상속 지정자

struct는 기본값이 public이고, class는 기본값이 private이다.

접근 지정자란?

접근 지정자는 멤버 변수나 멤버 함수에 어디에서 접근할 수 있는지를 제어하는 키워드이다.

C++에서는 다음 세 가지 접근 지정자를 사용한다.

public
private
protected

public

public으로 선언된 멤버는 외부에서도 접근할 수 있다. 따라서 보통 객체가 외부에 공개해야 하는 기능을 public으로 둔다.

class Character
{
public:
    int HP;

    void TakeDamage(int Damage)
    {
        HP -= Damage; // 클래스 내부에서 접근 가능
    }
};

class Monster : public Character
{
public:
    void TakeDamage(int Damage)
    {
        HP -= Damage; // 자식 클래스에서도 접근 가능
    }
};

int main()
{
    Monster Monster1;
    Monster1.HP = 100; // 외부에서도 접근 가능
}

private

private 멤버는 해당 클래스 내부에서만 직접 접근할 수 있다.

외부뿐만 아니라 자식 클래스에서도 부모의 private 멤버에는 직접 접근할 수 없다.

이처럼 외부에서 객체의 내부 상태를 마음대로 변경하지 못하도록 제한할 수 있기 때문에 private은 캡슐화를 구현하는 중요한 수단이 된다.

class Character
{
private:
    int HP;

public:
    void TakeDamage(int Damage)
    {
        HP -= Damage; // 클래스 내부에서는 접근 가능
    }
};

class Monster : public Character
{
public:
    void TakeDamage(int Damage)
    {
        HP -= Damage; // Error! 부모의 private 멤버
    }
};

int main()
{
    Monster Monster1;
    Monster1.HP = 100; // Error!
}

protected

protected는 외부에서는 접근할 수 없지만 자식 클래스에서는 접근할 수 있다.

class Character
{
protected:
    int HP;

public:
    void TakeDamage(int Damage)
    {
        HP -= Damage;
    }
};

class Monster : public Character
{
public:
    void TakeDamage(int Damage)
    {
        HP -= Damage; // 자식 클래스에서는 접근 가능
    }
};

int main()
{
    Monster Monster1;
    Monster1.HP = 100; // Error! 외부에서는 접근 불가
}

정리하면 다음과 같다.

접근 지정자	클래스 내부	자식 클래스	외부
public	O	O	O
protected	O	O	X
private	O	X	X

protected를 사용하면 자식 클래스에서 부모의 데이터를 직접 다룰 수 있어 편리하다.

하지만 자식 클래스가 부모 클래스의 내부 구현에 강하게 의존하게 될 수도 있다.

따라서 무조건 protected로 열어두기보다는 가능한 한 데이터를 private으로 숨기고, 필요한 기능만 함수로 제공하는 편이 유지보수에는 유리하다.

Struct와 Class의 첫 번째 차이 - 기본 접근 지정자

struct와 class의 첫 번째 차이는 접근 지정자를 생략했을 때 적용되는 기본값이다.

struct의 기본 접근 지정자는 public이다.

struct SMyStruct
{
    float X; // 기본적으로 public
    float Y;
};

따라서 외부에서 바로 접근할 수 있다.

SMyStruct V01;

V01.X = 10.0f;
V01.Y = 20.0f;

반면 class의 기본 접근 지정자는 private이다.

class CMyClass
{
    float X; // 기본적으로 private
    float Y;
};

따라서 다음과 같이 외부에서 접근할 수 없다.

CMyClass V02;

V02.X = 10.0f; // Error! Member is inaccessible
V02.Y = 20.0f; // Error! Member is inaccessible

즉, 다음 두 코드는 같은 의미이다.

struct SMyStruct
{
    float X;
};

struct SMyStruct
{
public:
    float X;
};

class는 반대이다.

class CMyClass
{
    float X;
};

class CMyClass
{
private:
    float X;
};

정리하면 다음과 같다.

타입	기본 접근 지정자
struct	public
class	private

Struct와 Class의 두 번째 차이 - 기본 상속 지정자

struct와 class에는 한 가지 차이가 더 있다. 바로 기본 상속 지정자이다.

부모의 멤버를 자식 입장에서 어떤 접근 수준으로 상속받을 것인지 결정한다.

상속 지정자는 다음 코드에서 public이 들어가는 부분을 말한다.

class Monster : public Character
{
};

Struct의 기본 상속은 public이다

다음 두 코드는 같은 의미이다.

struct CharacterStruct
{
};

struct MonsterStruct : CharacterStruct
{
};

struct CharacterStruct
{
};

struct MonsterStruct : public CharacterStruct
{
};

Class의 기본 상속은 private이다

다음 두 코드는 같은 의미이다.

class Character
{
};

class Monster : Character
{
};

class Character
{
};

class Monster : private Character
{
};

의도하지 않은 private 상속이 발생하면 단순히 멤버 접근 문제에서 끝나는 것이 아니라 업캐스팅이나 다형성에도 영향을 줄 수 있기 때문에 주의해야 한다.

public 상속

일반적인 객체 지향 상속에서 주로 사용하는 방식이다.

부모 멤버의 접근 수준은 다음과 같이 이어진다.

부모	자식에서
public	public
protected	protected
private	직접 접근 불가

예를 들어 다음과 같다.

class Character
{
public:
    int PublicHP;

protected:
    int ProtectedHP;

private:
    int PrivateHP;
};

class Monster : public Character
{
    void Test()
    {
        PublicHP = 100;       // 가능
        ProtectedHP = 100;    // 가능
        PrivateHP = 100;      // Error!
    }
};

객체 지향에서 말하는 is-a 관계의 상속은 일반적으로 public 상속으로 표현한다.

Monster is a Character

따라서 Monster 객체를 Character 타입으로 취급할 수 있다.

Monster M;
Character* Ptr = &M;

private 상속

private 상속에서는 부모의 public, protected 멤버가 자식 입장에서 private으로 취급된다.

부모의 실제 멤버가 private으로 변경되는 것은 아니다.

부모	private 상속 후
public	private
protected	private
private	직접 접근 불가

class Character
{
public:
    int PublicHP;

protected:
    int ProtectedHP;

private:
    int PrivateHP;
};

class Monster : private Character
{
    void Test()
    {
        PublicHP = 100;    // Monster 입장에서 private 멤버로 상속됨
        ProtectedHP = 100; // Monster 입장에서 private 멤버로 상속됨
        //PrivateHP = 100;   // 부모의 private 멤버 - 직접 접근 불가
    }
};

class BabyMonster : public Monster
{
    void Test2()
    {
        //PublicHP = 100;    // Monster에서 private으로 상속됨 - 접근 불가
        //ProtectedHP = 100; // Monster에서 private으로 상속됨 - 접근 불가
        //PrivateHP = 100;   // Character의 private 멤버 - 직접 접근 불가
    }
};

int main() {
    
    Monster M;
    //M.PublicHP = 100;   // Monster에서 private으로 상속됨 - 접근 불가
    //M.ProtectedHP= 100; // Monster에서 private으로 상속됨 - 접근 불가
    //M.PrivateHP= 100;   // Character의 private 멤버 - 직접 접근 불가
    
    return 0;
}

Monster를 기준으로 접근 수준이 private처럼 취급되는 것이다.

따라서 Monster 내부에서는 사용할 수 있지만, 외부 & 그 아래의 자식 클래스에서는 접근할 수 없다.

protected 상속

protected 상속에서는 부모의 public, protected 멤버가 자식에서 protected로 취급된다.

따라서 현재 클래스와 그 아래의 자식 클래스에서는 접근할 수 있지만 외부에서는 접근할 수 없다.

부모	protected 상속 후
public	protected
protected	protected
private	직접 접근 불가

class Character
{
public:
    int PublicHP;

protected:
    int ProtectedHP;

private:
    int PrivateHP;
};

class Monster : protected Character
{
    void Test()
    {
        PublicHP = 100;    // Monster 입장에서 protected 멤버로 상속됨
        ProtectedHP = 100; // Monster 입장에서 protected 멤버로 상속됨
        //PrivateHP = 100;   // 부모의 private 멤버 - 직접 접근 불가
    }
};

class BabyMonster : public Monster
{
    void Test2()
    {
        PublicHP = 100;    // Monster에서 protected으로 상속되어 접근 가능
        ProtectedHP = 100; // Monster에서 protected으로 상속되어 접근 가능
        //PrivateHP = 100;   // Character의 private 멤버 - 직접 접근 불가
    }
};

int main() {
    
    Monster M;
    //M.PublicHP = 100;   // Monster에서 protected으로 상속됨 - 접근 불가
    //M.ProtectedHP= 100; // Monster에서 protected으로 상속됨 - 접근 불가
    //M.PrivateHP= 100;   // Character의 private 멤버 - 직접 접근 불가
    
    return 0;
}

Struct와 Class는 서로 상속할 수 있을까?

가능하다.

struct와 class는 상속, 가상 함수, 다형성 등의 기능을 동일하게 지원하기 때문에 서로 자유롭게 상속할 수 있다.

struct Character
{
};

class Monster : public Character
{
};

반대도 가능하다.

class Character
{
};

struct Monster : public Character
{
};

단, 상속 지정자를 생략했을 때 적용되는 기본값이 다르다는 점을 주의해야 한다.

예를 들어 다음 코드를 보자.

struct Character
{
public:
    int HP;

    void Move()
    {
        cout << "Character Move\n";
    }
};

class Monster : Character // private 상속
{
};

기본 상속 지정자는 부모가 아니라 자식 타입의 선언 방식에 따라 결정된다.

Monster가 class이므로 다음 코드는 private 상속이다.

따라서 외부에서는 다음과 같이 사용할 수 없다.

Monster M;

M.Move(); // Error! Member is inaccessible

기본 상속 지정자를 놓치면 업캐스팅과 다운캐스팅이 막힌다

struct Character
{
public:
    void Move()
    {
        cout << "Character Move\n";
    }
};

class Monster : Character // private 상속
{
};

위 코드에서 private 상속은 멤버 접근뿐 아니라 외부에서 부모-자식 타입 관계를 이용하는 것에도 영향을 준다.

외부에서는 Monster를 Character로 업캐스팅할 수 없다

int main()
{
    Monster M;

    Character* Ptr = &M; // 컴파일 에러

    return 0;
}

컴파일러는 Monster가 Character를 상속하고 있다는 사실 자체는 알고 있다.

즉, 두 타입 사이의 변환 관계가 없는 것은 아니다. 문제는 그 상속 관계가 private이라는 점이다.

main()과 같은 외부 코드는 Monster의 private 상속 관계에 접근할 권한이 없기 때문에 다음 변환을 사용할 수 없다.

그래서 컴파일 에러가 발생한다.

Monster 내부에서는 업캐스팅할 수 있다

반면 Monster의 멤버 함수 내부에서는 자신의 private 상속 관계에 접근할 수 있다.

class Monster : Character
{
public:
    Character* GetCharacter()
    {
        return this;
    }
};

여기서 Monster* → Character* 암시적 업캐스팅은

컴파일러가 정적 타입과 상속 관계를 알고 있고, 해당 상속 관계에 접근할 권한도 있기 때문에 컴파일 타임에 자동으로 수행된다.

전체 코드를 보면 다음과 같다.

#include <iostream>
using namespace std;

struct Character
{
public:
    void Move()
    {
        cout << "Character Move\n";
    }
};

class Monster : Character // private 상속
{
public:
    Character* GetCharacter()
    {
        return this; // 가능
    }

    void TestInside()
    {
        Character* Ptr = this; // 클래스 내부에서는 업캐스팅 가능
        Ptr->Move();
    }
};

int main()
{
    Monster M;

    // 1. Monster 내부에서는 Character*로 변환 가능
    M.TestInside();

    // 2. public 함수가 Character*를 반환하는 것도 가능
    Character* Ptr1 = M.GetCharacter();
    Ptr1->Move();
    
    // 3. 외부에서 직접 업캐스팅은 불가능
    //Character* Ptr2 = &M; // 컴파일 에러

    return 0;
}

Ptr1은 Monster 객체 내부에 존재하는 Character 베이스 서브오브젝트를 가리킨다.

즉, Character의 인터페이스를 사용할 수 있다.

Character* Ptr1 = M.GetCharacter();

Ptr1->Move(); // 가능

Monster 객체
└── Character 베이스 서브오브젝트

외부에서는 다시 Monster*로 다운캐스팅하는 것도 제한된다

Character*를 얻었다고 해서 외부(ex. main 함수)에서 자유롭게 다시 Monster*로 변환할 수 있는 것도 아니다.

Character* Ptr1 = M.GetCharacter();

// Monster* M2 = static_cast<Monster*>(Ptr1); // Error!

이 변환 역시 private 상속 관계를 사용해야 하므로 외부에서는 허용되지 않는다.

즉, 외부에서는 다음 두 방향 모두 막힌다.

Monster*   → Character*   // 업캐스팅 불가
Character* → Monster*     // 다운캐스팅 불가

중요한 점은 단지 현재 코드가 그 private 상속 관계를 사용할 권한이 없는 것이다.

Monster 내부에서는 다운캐스팅도 가능하다

반대로 Monster 내부에서는 private 상속 관계에 접근할 수 있으므로 다운캐스팅도 가능하다.

class Monster : Character
{
public:
    void TestInside()
    {
    	// Monster* → Character*
        Character* CharacterPtr = this;
        
        // Character* → Monster*
        Monster* MonsterPtr =
            static_cast<Monster*>(CharacterPtr);

        MonsterPtr->Move();
    }
};

여기서는 다음 두 변환이 모두 가능하다.

둘 다 Monster의 멤버 함수 내부에서 수행되기 때문에 private 상속 관계에 접근할 권한이 있다.\

따라서 private 상속을 다음과 같이 이해하면 된다.

private 상속
≠ 상속 관계가 사라짐

private 상속
= 외부에서 그 상속 관계를 타입 변환에 사용할 수 없음

다형성에도 영향을 준다

private 상속 때문에 가상 함수 자체가 동작하지 않는 것은 아니다. 문제는 외부에서 자식 객체를 부모 타입으로 업캐스팅할 수 없다는 것이다. 이 때문에 부모 포인터나 참조를 이용해 여러 자식 객체를 동일한 인터페이스로 관리하는 일반적인 런타임 다형성 구조에 참여할 수 없게 된다.

#include <iostream>
#include <vector>
using namespace std;

struct Character
{
    virtual ~Character() = default;

    virtual void Move()
    {
        cout << "Character Move\n";
    }
};

class Player : public Character
{
public:
    void Move() override
    {
        cout << "Player Move\n";
    }
};

class Monster : Character // 실수: public 생략 → private 상속
{
public:
    void Move() override
    {
        cout << "Monster Move\n";
    }
};

int main()
{
    Player P;
    Monster M;

    vector<Character*> Characters;

    Characters.push_back(&P); // 가능
    Characters.push_back(&M); // Error!

    for (Character* CharacterPtr : Characters)
    {
        CharacterPtr->Move();
    }

    return 0;
}

그래서 객체 지향적인 is-a 관계를 표현할 목적이라면 다음처럼 public을 명시하는 편이 좋다.

class Monster : public Character
{
};

정리

처음에는 struct와 class를 서로 다른 종류의 타입이라고 생각하기 쉬웠다.

하지만 C++에서는 생성자, 소멸자, 상속, 가상 함수, 다형성 등 거의 동일한 기능을 사용할 수 있다.

실질적인 언어 차이는 다음 두 가지이다.

	struct	class
기본 접근 지정자	public	private
기본 상속 지정자	public	private

그럼에도 실제 코드에서는 역할을 구분하기 위해 서로 다르게 사용하는 경우가 많다.

Struct
→ 데이터를 표현하는 값 타입

Class
→ 상태를 관리하고 책임을 수행하는 객체

물론 이것은 C++ 문법이 강제하는 규칙은 아니다.

코드를 읽는 사람에게 이 타입을 어떤 의도로 만들었는지 전달하기 위한 관례에 가깝다.

그리고 개인적으로는 기본 접근 지정자의 차이보다 기본 상속 지정자의 차이를 더 주의해야 한다고 느꼈다.

class에서 상속 지정자를 생략하면 의도하지 않은 private 상속이 발생할 수 있고, 이 경우 외부에서 부모 타입으로 업캐스팅할 수 없어 다형성 활용까지 막힐 수 있기 때문이다.

일반적인 is-a 관계의 상속을 표현할 때는 기본값에 의존하기보다 public을 명시하자!