HaNong

[C++] 코딩테스트에서의 스택

hanong8 — Thu, 14 May 2026 19:43:40 +0900

1스택의 특징과 LIFO 원리

스택(Stack)은 가장 최근에 삽입한 원소가 가장 먼저 나오는 LIFO(Last In First Out) 구조의 자료구조다. 데이터를 쌓아 올리는 접시 더미처럼, 꺼낼 때는 맨 위부터 꺼낸다.

코딩테스트에서 스택이 등장하는 패턴은 대부분 "가장 최근에 넣은 원소"를 즉시 참조하거나 제거해야 하는 상황이다. 괄호 검증, 단조 스택(Monotone Stack), 함수 콜스택 시뮬레이션 등이 대표적이다.

구조	설명	대표 자료구조
LIFO	마지막에 넣은 원소가 먼저 나옴	Stack
FIFO	먼저 넣은 원소가 먼저 나옴	Queue

2스택의 활용 예시

스택은 이론 속 개념이 아니라 우리가 매일 쓰는 기능에 이미 녹아 있다. 두 가지 대표 예시를 코드와 함께 살펴보자.

예시 1 — 웹 브라우저 뒤로 가기

방문한 페이지를 스택에 순서대로 push하고, 뒤로 가기를 누르면 pop하여 직전 페이지로 돌아간다. LIFO 구조이므로 가장 최근에 방문한 페이지가 자연스럽게 제거된다.

C++ — 뒤로 가기 기능 구현

// 방문한 페이지를 스택에 저장하고, 뒤로 가기 시 최근 페이지를 제거
#include <iostream>
#include <stack>
#include <string>
using namespace std;

int main() {
    stack<string> history;

    history.push("A");
    history.push("B");
    history.push("C");

    cout << "현재 페이지: " << history.top() << endl; // C

    history.pop(); // C → B
    cout << "뒤로 가기 후 현재 페이지: " << history.top() << endl; // B

    return 0;
}
/* 출력결과
현재 페이지: C
뒤로 가기 후 현재 페이지: B */

예시 2 — 함수 호출 스택

C++ 프로그램이 실행될 때 함수 호출은 내부적으로 콜 스택(Call Stack)으로 관리된다. main이 A를 호출하고, A가 B를 호출하면 스택에 순서대로 쌓인다. B가 종료되면 LIFO 구조에 따라 A로 자연스럽게 복귀한다.

1 main 함수에서 A 함수 호출 → 스택에 main, A 순으로 적재

2 A 함수에서 B 함수 호출 → 스택에 main, A, B 순으로 적재

3 B 함수 종료 → B가 pop되고 자신을 호출한 A로 반환

C++ — 함수 호출 스택 시뮬레이션

#include <iostream>
using namespace std;

void B() {
    cout << "B 함수 호출됨" << endl;
    cout << "B 함수 종료됨" << endl;
}
void A() {
    cout << "A 함수 호출됨" << endl;
    B();
    cout << "A 함수 종료됨" << endl;
}
int main() {
    cout << "main 함수 호출됨" << endl;
    A();
    cout << "main 함수 종료됨" << endl;
    return 0;
}
/* 출력결과
main 함수 호출됨 → A 함수 호출됨 → B 함수 호출됨
→ B 함수 종료됨 → A 함수 종료됨 → main 함수 종료됨 */

3스택의 ADT 정의

ADT(Abstract Data Type, 추상 자료형)란 자료구조의 동작을 구체적인 구현과 분리하여 인터페이스 수준에서 정의한 설계도다. 실제로 배열로 구현하든 연결 리스트로 구현하든 외부에서는 동일하게 사용할 수 있다.

구분	정의	설명
연산	`boolean isFull()`	데이터 개수가 maxsize와 같으면 `true`, 아니면 `false` 반환
연산	`boolean isEmpty()`	데이터가 하나도 없으면 `true`, 있으면 `false` 반환
연산	`void push(ItemType item)`	스택 top에 데이터를 추가
연산	`ItemType pop()`	가장 최근에 추가된 데이터를 제거하고 반환
상태	`int top`	가장 최근에 추가된 데이터의 위치 인덱스
상태	`ItemType data[maxsize]`	스택의 데이터를 관리하는 배열, 최대 maxsize개 저장

4push / pop 동작 원리

ADT를 기준으로 push와 pop이 내부에서 어떻게 수행되는지 단계별로 확인한다.

push(3) 수행 과정

1 isFull()을 호출하여 스택이 가득 찼는지 확인

2 스택이 가득 차지 않은 경우 top을 1 증가 (-1 → 0)

3 data[top]에 해당하는 위치에 값 3을 저장

pop() 수행 과정

1 isEmpty()를 호출하여 빈 스택인지 확인

2 스택이 비어있지 않은 경우 top을 1 감소 (0 → -1)

3 제거된 위치의 데이터(3)를 반환 — 이것이 가장 최근에 넣은 원소

핵심 포인트 — top은 실제로 데이터를 지우지 않는다. 인덱스를 감소시켜 논리적으로 비어있는 것으로 간주할 뿐이며, 다음 push가 그 자리를 덮어쓴다.

5STL stack 주요 메서드

C++은 <stack> 헤더를 통해 스택을 기본 제공하므로 직접 구현할 필요가 없다. 주요 메서드와 시간 복잡도를 정리하면 아래와 같다.

메서드	동작	예시	시간 복잡도
`top()`	top 요소 접근 (제거 안 함)	`s.top()`	O(1)
`push(val)`	top에 요소 삽입	`s.push(10)`	O(1)
`pop()`	top 요소 제거 (반환값 없음)	`s.pop()`	O(1)
`empty()`	스택이 비어 있는지 확인	`s.empty()`	O(1)
`size()`	스택 내 요소 개수 반환	`s.size()`	O(1)
`push_range(first, last)`	반복자 범위의 요소를 일괄 삽입	`s.push_range(v.begin(), v.end())`	O(N)

주의 — pop()은 반환값이 없다.
값을 꺼내야 한다면 반드시 top()으로 먼저 읽은 뒤 pop()을 호출해야 한다. int x = s.pop();은 컴파일 에러가 발생한다.

C++ — STL stack 기본 사용법

#include <iostream>
#include <stack>
using namespace std;

int main() {
    stack<int> s;
    s.push(10); s.push(20); s.push(30);

    cout << "스택의 top: " << s.top() << endl;  // 30
    s.pop();
    cout << "pop 후 top: " << s.top() << endl;  // 20

    cout << "비어있나? " << (s.empty() ? "예" : "아니오") << endl;
    cout << "크기: " << s.size() << endl;  // 2

    // 올바른 값 추출 패턴
    int val = s.top(); // 먼저 읽고
    s.pop();           // 그 다음 제거
    // int x = s.pop(); // ❌ 컴파일 에러 — pop()은 반환값 없음

    return 0;
}

6실전 문제 풀이

문제 9 — 10진수를 2진수로 변환하기

정수 decimal을 2진수 문자열로 반환한다. 2로 나눈 나머지를 스택에 쌓은 뒤, 스택에서 순서대로 꺼내면 LIFO 특성에 의해 자연스럽게 올바른 2진수 순서(MSB → LSB)가 완성된다.

decimal	result
10	"1010"
27	"11011"
12345	"11000000111001"

C++ — 10진수 → 2진수 변환

#include <stack>
#include <string>
using namespace std;

string solution(int decimal) {
    if (decimal == 0) return "0";

    stack<int> st;
    while (decimal > 0) {
        st.push(decimal % 2); // 나머지를 스택에 쌓음
        decimal /= 2;
    }

    string binary = "";
    while (!st.empty()) {
        binary += to_string(st.top()); // LIFO → MSB부터 꺼내짐
        st.pop();
    }
    return binary;
}

문제 12 — 주식 가격 (프로그래머스)

초 단위로 기록된 주식 가격 배열 prices가 주어질 때, 각 시점에서 가격이 떨어지지 않은 기간(초)을 반환한다. 스택에 인덱스를 저장하고 현재 가격이 이전 가격보다 낮을 때 pop하여 기간을 계산한다.

핵심 아이디어 — 단조 스택(Monotone Stack)
스택에 저장된 인덱스의 가격이 항상 현재 가격 이하를 유지하도록 관리한다. 현재 가격이 더 낮으면 스택을 pop하면서 그 시점의 지속 기간을 i - s.top()으로 계산한다. 순회 후 스택에 남은 인덱스는 끝까지 가격이 떨어지지 않은 경우다.

C++ — 주식 가격

#include <vector>
#include <stack>
using namespace std;

vector<int> solution(vector<int> prices) {
    vector<int> answer(prices.size());
    stack<int> s;
    int n = prices.size();

    for (int i = 0; i < n; i++) {
        while (!s.empty() && prices[s.top()] > prices[i]) {
            // 가격이 떨어진 시점 → 기간 계산 후 pop
            answer[s.top()] = i - s.top();
            s.pop();
        }
        s.push(i);
    }
    // 끝까지 가격이 떨어지지 않은 인덱스 처리
    while (!s.empty()) {
        answer[s.top()] = n - s.top() - 1;
        s.pop();
    }
    return answer;
}
// solution({1,2,3,2,3}) → {4,3,1,1,0}

문제 13 — 크레인 인형 뽑기 게임 (프로그래머스)

N×N 격자 보드에서 크레인이 지정된 열 순서(moves)로 인형을 뽑는다. 뽑은 인형을 바구니 스택에 쌓을 때, 스택 top과 같은 인형이 오면 두 인형이 제거된다. 최종적으로 사라진 인형의 총 개수를 반환한다.

C++ — 크레인 인형 뽑기 게임

#include <stack>
#include <vector>
using namespace std;

int solution(vector<vector<int>> board, vector<int> moves) {
    // 각 열을 스택으로 모델링 (아래→위 순서로 push)
    stack<int> lanes[board[0].size()];
    for (int i = board.size()-1; i >= 0; --i)
        for (int j = 0; j < board[0].size(); ++j)
            if (board[i][j]) lanes[j].push(board[i][j]);

    stack<int> bucket;
    int answer = 0;

    for (int m : moves) {
        if (lanes[m-1].size()) {
            int doll = lanes[m-1].top();
            lanes[m-1].pop();
            // 바구니 top과 같으면 둘 다 제거 (+2점)
            if (bucket.size() && bucket.top() == doll) {
                bucket.pop();
                answer += 2;
            } else {
                bucket.push(doll);
            }
        }
    }
    return answer;
}

7오늘의 회고

새로 배운 것	스택의 LIFO 원리가 웹 브라우저 뒤로 가기, 함수 콜 스택 등 실생활과 직결되어 있다는 것을 코드로 직접 확인했다. ADT 개념을 통해 push/pop 내부에서 top 인덱스가 어떻게 움직이는지 구체적으로 이해했다. STL stack에서 `pop()`이 반환값이 없으므로 반드시 `top()`을 먼저 써야 한다는 점도 새롭게 정리됐다.
어려웠던 점	주식 가격 문제에서 단조 스택 패턴을 처음 접했을 때, 스택에 값이 아닌 인덱스를 저장한다는 발상이 직관적이지 않았다. 크레인 인형 뽑기 역시 보드를 열 단위 스택으로 모델링하는 아이디어를 떠올리는 데 시간이 걸렸다.
기억할 핵심	"가장 최근 원소"가 키워드라면 스택을 의심하라. 값 대신 인덱스를 스택에 저장하면 구간 계산이 훨씬 쉬워진다. `top() → pop()` 순서는 반드시 지킨다.
다음 목표	큐(Queue) 자료구조와 STL `<queue>` 활용법을 학습하고, 스택과 큐를 함께 사용하는 문제 유형까지 연습한다.

[C++] 코딩테스트에서의 시뮬레이션

hanong8 — Tue, 12 May 2026 23:09:40 +0900

1개요

시뮬레이션은 문제에서 제시한 규칙을 코드로 그대로 옮겨 구현하는 유형이다. 별도의 알고리즘 공식보다는 조건과 흐름을 정확히 파악하고 실수 없이 구현하는 능력이 핵심이다.

이번 챕터에서는 2차원 배열 기반의 좌표 연산, 대칭·회전 변환, 대각선 순회, 행렬 연산을 다룬다. 모두 코딩 테스트에서 반복적으로 출제되는 핵심 패턴이다.

2y, x 좌표 표현하기

코딩 테스트에서 2차원 평면은 2차원 배열로 표현하는 것이 가장 직관적이다. 이때 y좌표 → 행(row) 인덱스, x좌표 → 열(col) 인덱스로 대응시킨다.

예를 들어, 좌표 (3, 4)는 배열의 arr[4][3]에 해당한다. 수학 좌표계와 배열 인덱스의 y축 방향이 반대임을 항상 주의해야 한다.

수학 좌표	배열 표현	의미
(x, y)	`arr[y][x]`	y = 행 인덱스, x = 열 인덱스
(3, 4)	`arr[4][3]`	4행 3열

3dy, dx 배열로 인접 좌표 이동하기

현재 좌표에서 인접한 좌표로 이동할 때 오프셋 배열 dy, dx를 사용하면 하드코딩 없이 반복문으로 깔끔하게 처리할 수 있다. 실제 시뮬레이션 문제의 대부분이 이 방식을 활용한다.

C++ · dy, dx 오프셋 배열 (8방향)

// 8방향: 상좌, 상, 상우, 우, 하우, 하, 하좌, 좌
int dy[] = {-1, -1, -1,  0, 1, 1,  1,  0};
int dx[] = {-1,  0,  1,  1, 1, 0, -1, -1};

// 현재 위치 (y, x)에서 인접한 8개 좌표 순회
for (int i = 0; i < 8; i++) {
    int ny = y + dy[i];
    int nx = x + dx[i];
    // 범위 체크 후 처리
    if (ny >= 0 && ny < N && nx >= 0 && nx < N) {
        // 유효한 인접 좌표 처리
    }
}

4방향만 필요하다면 dy = {-1, 1, 0, 0}, dx = {0, 0, -1, 1}으로 줄일 수 있다. 같은 인덱스끼리 짝을 이루는 구조가 핵심이다.

4대칭과 회전 변환 공식

N×N 배열에서 좌표 변환 공식을 암기해 두면 시뮬레이션 문제에서 바로 적용할 수 있다.

변환	공식 (Y, X) →	변화하지 않는 축
좌우 대칭	`(Y, (N-1) - X)`	Y 고정, X만 변환
상하 대칭	`((N-1) - Y, X)`	X 고정, Y만 변환
90도 회전 (시계)	`((N-1) - X, Y)`	행·열 모두 변환
180도 회전	90도 회전 2회 적용	—
270도 회전	90도 회전 3회 적용	—

⚠️ 90도 회전 후 결과를 원본 배열에 바로 쓰면 덮어쓰기 충돌이 발생한다. 반드시 별도의 임시 배열에 결과를 저장한 뒤 원본에 복사해야 한다.

5대각선 행렬 순회

같은 대각선 상에 있는 원소들을 판별하는 조건과 이동 방향을 정리한다.

종류	다음 원소 이동	같은 대각선 판별 조건
정방향 대각선 (↘)	`(Y+1, X+1)`	`Y - A == X - B`
역방향 대각선 (↙)	`(Y+1, X-1)`	`Y - A == B - X`

정방향은 Y - X 값이 같은 원소끼리 같은 대각선이고, 역방향은 Y + X 값이 같은 원소끼리 같은 대각선이다.

6행렬 연산

행렬 덧셈 / 뺄셈

두 행렬의 크기가 같을 때, 같은 위치의 원소끼리 더하거나 빼는 연산이다. 결과 행렬의 크기는 입력 행렬과 동일하다.

C++ · 행렬 덧셈

for (int i = 0; i < N; i++)
    for (int j = 0; j < N; j++)
        C[i][j] = A[i][j] + B[i][j];

행렬 곱셈

A의 X행과 B의 Y열의 원소를 각각 곱한 후 합산하여 C[X][Y]를 완성한다. 연산이 가능하려면 A의 열 수 == B의 행 수여야 한다. 결과 행렬 C의 크기는 A의 행 수 × B의 열 수다.

C++ · 행렬 곱셈

// A: N×M, B: M×K → C: N×K
for (int i = 0; i < N; i++)
    for (int j = 0; j < K; j++)
        for (int k = 0; k < M; k++)
            C[i][j] += A[i][k] * B[k][j];

연산	전제 조건	결과 크기
덧셈 / 뺄셈	두 행렬 크기 동일	입력과 동일
곱셈	A의 열 수 == B의 행 수	A의 행 수 × B의 열 수

7오늘의 회고

항목	내용
새로 배운 것	좌표 변환 공식(좌우·상하 대칭, 90도 회전)을 표로 정리하니 패턴이 명확해졌다. 대각선 판별 조건도 `Y - X`와 `Y + X`로 단순화할 수 있다는 점이 유용했다.
어려웠던 점	90도 회전 시 임시 배열 없이 원본에 바로 쓰면 안 된다는 것을 직접 실수하면서 깨달았다. 변환 공식보다 구현 시 덮어쓰기 문제를 놓치기 쉽다.
기억할 핵심	dy·dx 오프셋 배열은 방향 이동 문제의 기본 패턴이므로 4방향·8방향 모두 손에 익혀둬야 한다. 행렬 곱셈은 `A열 == B행` 조건과 3중 반복문 구조를 반드시 암기한다.
다음 목표	달팽이 수열(문제 64)과 캐릭터 좌표(문제 69)를 직접 구현해보고, 회전·대칭 변환이 포함된 추가 문제도 찾아서 풀어볼 예정이다.

[C++] 코딩테스트에서의 정렬

hanong8 — Mon, 11 May 2026 21:15:00 +0900

1개요

정렬은 사용자가 정의한 순서대로 데이터를 나열하는 연산이다. 오름차순·내림차순이 일반적이지만, 임의 조건도 가능하다. 정렬이 필요한 이유는 크게 두 가지다. 첫째, 데이터가 정렬되어 있으면 중앙값·최댓값을 훨씬 빠르게 구할 수 있다. 둘째, 이진 탐색처럼 정렬을 전제 조건으로 삼는 알고리즘이 존재한다.

이번 챕터에서는 삽입 정렬, 병합 정렬, 계수 정렬, 힙 정렬 네 가지를 다룬다. 각 알고리즘의 동작 원리와 시간 복잡도를 비교하며 어떤 상황에 무엇을 써야 하는지 판단 기준을 세우는 것이 목표다.

2삽입 정렬 (Insertion Sort)

정렬되지 않은 원소를 이미 정렬된 부분 배열의 적절한 위치에 삽입하며 전체를 정렬하는 알고리즘이다. 첫 번째 원소는 이미 정렬된 것으로 간주하고 두 번째 원소부터 처리한다.

key 설정: 현재 인덱스 j의 값을 key로 저장하고 i = j - 1로 초기화한다.

밀어내기: A[i] > key인 동안 A[i+1] = A[i]로 원소를 한 칸씩 뒤로 밀고, i--한다.

삽입: 루프 종료 후 A[i+1] = key로 알맞은 자리에 넣는다.

C++ · 삽입 정렬

for (int i = 1; i < n; i++) {
    int key = arr[i];
    int j = i - 1;

    // key보다 큰 요소를 한 칸씩 뒤로 이동
    while (j >= 0 && arr[j] > key) {
        arr[j + 1] = arr[j];
        j--;
    }
    arr[j + 1] = key;
}

삽입 정렬의 시간 복잡도 — 최악 vs 최선

경우	시간 복잡도	조건	이유
최악	O(N²)	역순 정렬 데이터	매 단계 전체 원소를 밀어야 함. 비교 횟수 = N(N-1)/2
최선	O(N)	이미 정렬된 데이터	각 원소마다 1번 비교 후 즉시 종료

거의 정렬된 데이터에서 삽입 정렬은 O(N)에 가까워진다. 이 특성 때문에 실무의 하이브리드 정렬(Timsort 등)에서 소규모 구간에 삽입 정렬을 활용한다.

3병합 정렬 (Merge Sort)

분할 정복(Divide & Conquer) 기법을 활용한 정렬이다. 배열을 계속 반으로 나눈 뒤 가장 작은 단위부터 정렬하며 합쳐 올라간다. 크게 세 단계로 이루어진다.

분할 (Divide): 중간 지점 mid = left + (right - left) / 2 기준으로 배열을 두 하위 배열로 나눈다.

정복 (Conquer): 각 하위 배열을 재귀적으로 mergeSort() 호출해 정렬한다. 원소가 1개가 될 때까지 반복한다.

결합 (Combine): 두 정렬된 배열의 맨 앞 원소를 포인터로 비교해 작은 값을 먼저 임시 배열에 추가한다. 모두 소진되면 임시 배열을 원본에 복사한다.

C++ · 병합 정렬

void mergeSort(int arr[], int left, int right) {
    if (left < right) {
        int mid = left + (right - left) / 2;  // (left+right)/2는 오버플로우 위험
        mergeSort(arr, left, mid);
        mergeSort(arr, mid + 1, right);
        merge(arr, left, mid, right);
    }
}

// merge() 핵심 — 두 포인터 비교
while (i <= mid && j <= right) {
    if (arr[i] <= arr[j]) temp[k++] = arr[i++];
    else                  temp[k++] = arr[j++];
}

분할 트리의 높이는 log N층이고, 각 층에서 모든 원소를 한 번씩 병합하므로 한 층당 O(N)이 걸린다. 따라서 전체 시간 복잡도는 O(N log N)이며 최선·평균·최악 모두 동일하다. 단, 병합 과정에서 임시 배열이 필요해 추가 메모리 O(N)이 사용된다.

4계수 정렬 (Counting Sort)

데이터값 자체를 인덱스로 사용하는 방식이다. 각 값의 등장 횟수를 count[] 배열에 기록한 뒤, 인덱스 순서대로 횟수만큼 꺼내면 정렬 결과가 된다. 비교 연산을 전혀 하지 않기 때문에 조건만 맞으면 매우 빠르다.

C++ · 계수 정렬

// 1. 최댓값 K 탐색
int maxVal = *max_element(arr, arr + n);

// 2. count 배열 생성 및 빈도수 기록 — O(K) + O(N)
int* count = new int[maxVal + 1]{};
for (int i = 0; i < n; ++i)
    count[arr[i]]++;

// 3. 인덱스 순으로 빈도수만큼 결과 생성 — O(N)
int idx = 0;
for (int i = 0; i <= maxVal; ++i)
    while (count[i]--) arr[idx++] = i;

delete[] count;
// 입출력: {4,2,2,8,3,3,1} → {1,2,2,3,3,4,8}

N은 입력 배열 크기, K는 최댓값이라 할 때 시간 복잡도는 O(N + K)다. K가 충분히 작으면 비교 기반 정렬보다 훨씬 빠르다. 단, 아래 두 가지 경우에는 사용할 수 없다.

⚠️ 계수 정렬을 쓰면 안 되는 경우
① 음수 값이 포함된 경우 — 배열의 인덱스로 음수를 쓸 수 없다.
② 값의 범위(K)가 매우 큰 경우 — 데이터가 500과 10억이라면 10억 크기의 배열이 필요해 메모리가 폭발한다.

5힙 정렬 (Heap Sort)

힙(Heap)이라는 자료구조를 활용한 정렬이다. 힙은 조건을 만족하는 완전 이진 트리로, 최대 힙(Max-Heap)은 모든 부모 노드의 값이 자식 노드 이상이고, 최소 힙(Min-Heap)은 그 반대다. 힙을 배열로 표현할 때 인덱스 규칙(0-based)은 다음과 같다.

관계	인덱스 수식
왼쪽 자식	`2 * i + 1`
오른쪽 자식	`2 * i + 2`
부모	`(i - 1) / 2`

힙 정렬 동작 순서

최대 힙 구축 — build_max_heap(): 인덱스 n/2 - 1부터 0까지 역순으로 heapify()를 호출한다. 리프 노드는 자식이 없어 heapify가 불필요하므로 절반부터 시작한다.

루트 추출 & 교환: 루트 arr[0](최댓값)과 배열 마지막 원소를 교환해 최댓값을 배열 뒤에 정착시킨다.

힙 크기 축소 & 반복: 힙 범위를 1 줄이고, 루트에 대해 다시 heapify()를 수행한다. heap_size = 1이 될 때까지 반복하면 오름차순 정렬이 완료된다.

C++ · 힙 정렬

void heapify(int arr[], int n, int i) {
    int largest = i;
    int left  = 2 * i + 1;
    int right = 2 * i + 2;

    if (left  < n && arr[left]  > arr[largest]) largest = left;
    if (right < n && arr[right] > arr[largest]) largest = right;

    if (largest != i) {
        swap(arr[i], arr[largest]);
        heapify(arr, n, largest);  // 재귀 — 교환된 위치 재정비
    }
}

void heapSort(int arr[], int n) {
    // 1. Build Max Heap
    for (int i = n / 2 - 1; i >= 0; i--)
        heapify(arr, n, i);

    // 2. 최댓값을 하나씩 배열 뒤로 정착
    for (int i = n - 1; i >= 0; i--) {
        swap(arr[0], arr[i]);       // 루트 ↔ 마지막 원소
        heapify(arr, i, 0);        // 줄어든 범위에서 재정비
    }
}
// {4,10,3,5,1} → {1,3,4,5,10}

힙의 높이는 log N이고, N번의 추출마다 heapify()가 O(log N)이므로 전체 시간 복잡도는 O(N log N)이다. 추가 메모리가 O(1)이며 최선·평균·최악 모두 동일하다는 것이 장점이다.

힙 자료구조는 정렬뿐 아니라 삽입/삭제 연산도 O(log N)에 수행할 수 있어 우선순위 큐(Priority Queue) 구현에도 폭넓게 사용된다.

6한눈에 보는 정리

알고리즘	최선	평균	최악	추가 메모리	안정 정렬	특이사항
삽입 정렬	O(N)	O(N²)	O(N²)	O(1)	✓	거의 정렬된 경우 강력
병합 정렬	O(NlogN)	O(NlogN)	O(NlogN)	O(N)	✓	성능이 일정, 메모리 필요
계수 정렬	O(N+K)	O(N+K)	O(N+K)	O(K)	✓	음수·큰 K 사용 불가
힙 정렬	O(NlogN)	O(NlogN)	O(NlogN)	O(1)	✗	제자리 정렬, 성능 일정

7오늘의 회고

항목	내용
새로 배운 것	삽입·병합·계수·힙 정렬의 동작 원리와 시간 복잡도 차이. 힙이 단순한 정렬 도구가 아니라 삽입/삭제도 O(log N)에 처리하는 자료구조라는 점이 인상적이었다.
어려웠던 점	`build_max_heap()`에서 왜 `n/2 - 1`부터 시작하는지 처음엔 직관적으로 이해가 안 됐다. 인덱스 규칙(`left = 2i+1`)을 직접 그려보니, `n/2` 이상 인덱스는 모두 리프 노드임을 확인할 수 있었다.
기억할 핵심	계수 정렬은 K가 작고 음수가 없을 때만 사용. 범용 상황에서는 병합·힙 정렬이 안전한 선택이며, 이미 거의 정렬된 데이터에는 삽입 정렬이 의외로 강하다.
다음 목표	계수 정렬 응용 문제(문자열 정렬), 커스텀 비교 함수를 이용한 정렬 문제 직접 풀어보기. 힙을 활용한 우선순위 큐 패턴도 별도로 정리할 예정이다.

[C++] 코딩테스트에서의 배열

hanong8 — Thu, 7 May 2026 20:17:35 +0900

1개요

배열은 동일한 타입의 원소들을 연속된 메모리 공간에 저장하는 가장 기본적인 자료구조다. 인덱스로 O(1) 접근이 가능하지만, 삽입 위치에 따라 시간 복잡도가 크게 달라진다. 맨 뒤 삽입은 O(1)이지만 맨 앞 삽입은 O(N)이 된다. 이 차이를 이해하면 어떤 자료구조를 선택해야 할지 판단하는 기준이 생긴다.

2배열의 세 가지 특징

동질성: 배열의 모든 원소는 동일한 타입이어야 한다. 정수형 배열이면 모든 원소가 int, 문자형 배열이면 모든 원소가 char다.

연속된 메모리 할당: 원소들이 메모리상에 연속적으로 배치된다. 단편화 문제가 적고, CPU 캐시를 효율적으로 활용할 수 있어 접근 속도가 빠르다.

인덱스 기반 접근: 첫 번째 원소는 인덱스 0. arr[i]처럼 어떤 위치든 O(1) 상수 시간에 직접 접근할 수 있다.

int arr[5] = {10, 20, 30, 40, 50} — 메모리 배치

arr[0]

0x...b0

arr[1]

0x...b4

arr[2]

0x...b8

arr[3]

0x...bc

arr[4]

0x...c0

int형 원소 하나는 4바이트이므로 주소가 4씩 증가하는 것을 확인할 수 있다.

3배열 선언 및 초기화 — 1차원

선언 문법은 data_type array_name[size]다. 초기화 방식에 따라 동작이 달라지므로 주의해야 한다.

초기화 없이 선언

쓰레기값(Garbage Value)이 들어간다. 실행할 때마다 값이 달라지므로 반드시 초기화해야 한다.

전체 초기화

int arr[5] = {1,2,3,4,5}
앞에서부터 순서대로 값이 채워진다.

부분 초기화

int arr[5] = {1,2,3}
지정한 값 이후 나머지는 0으로 자동 초기화된다.

전체 0 초기화

int arr[5] = {0} 또는 int arr[5] = {}
모든 원소를 0으로 빠르게 초기화하는 관용 표현이다.

주의: 초기화하지 않고 선언만 한 배열을 그대로 사용하면 쓰레기값이 출력된다. 코딩 테스트에서 원인 모를 오답의 주범이 될 수 있으므로, 선언과 동시에 초기화하는 습관을 들이자.

42차원 배열 선언 및 메모리 구조

2차원 배열은 1차원 배열을 여러 개 묶어 놓은 형태로, int arr[2][3]처럼 행(row)과 열(col) 크기를 함께 명시한다.

int arr[2][3] = {{1,2,3},{4,5,6}} — 논리 구조

[0]

[1]

[2]

행 0

행 1

행 우선(Row-Major) 저장: C++에서 2차원 배열은 내부적으로 1행 전체 → 2행 전체 순서로 연속 메모리에 저장된다. 즉 arr[0][0], arr[0][1], arr[0][2], arr[1][0], arr[1][1], arr[1][2] 순으로 배치된다. 2차원처럼 보여도 메모리는 항상 1차원이다.

int arr[2][3] = {
    {1, 2, 3},   // 0행
    {4, 5, 6}    // 1행
};
// 메모리: [1][2][3][4][5][6] 연속 배치
// arr[1][0]의 주소 = arr[0][0]의 주소 + (3 * sizeof(int))

5삽입 위치에 따른 시간 복잡도 차이

배열은 연속 메모리 구조이기 때문에 삽입 위치에 따라 성능이 크게 달라진다.

맨 뒤 삽입 O(1)

가장 효율적

기존 원소를 전혀 건드리지 않고 다음 빈 자리에 바로 추가. 다른 원소 이동이 없으므로 상수 시간.

맨 앞 삽입 O(N)

가장 비효율적

기존 원소 전체를 한 칸씩 뒤로 밀어야 한다. 원소가 N개면 N번의 이동이 필요.

맨 뒤 삽입 — arr[size]에 바로 대입

← 한 번에 추가 O(1)

맨 앞 삽입 — 기존 원소 전체 이동

← 5번 이동 후 삽입 O(N)

맨 뒤 vs 맨 앞 삽입 — 원소 수별 연산 횟수

맨 뒤 삽입 — O(1) 맨 앞 삽입 — O(N)

// 맨 뒤 삽입 — O(1)
if (size < capacity) {
    arr[size] = newValue;  // 그냥 넣기만 하면 끝
    size++;
}

// 맨 앞 삽입 — O(N)
for (int i = size - 1; i >= 0; i--)
    arr[i + 1] = arr[i];  // 전체를 한 칸씩 뒤로
arr[0] = newValue;
size++;

6실전 문제 — 배열 활용 패턴 3가지

① 배열 제어하기 — 중복 제거 + 내림차순 정렬

핵심 아이디어: sort()로 내림차순 정렬 후 unique()로 연속된 중복값을 뒤로 밀고, erase()로 제거한다. unique()는 정렬된 배열에서만 올바르게 동작하므로 순서가 중요하다.

bool compare(int a, int b) { return a > b; }  // 내림차순 기준

vector<int> solution(vector<int> lst) {
    sort(lst.begin(), lst.end(), compare);       // 내림차순 정렬
    lst.erase(unique(lst.begin(), lst.end()),    // 중복 제거
               lst.end());
    return lst;
}
// {4,2,2,1,1,3,4} → {4,3,2,1}

② 두 수를 뽑아서 더하기 — set으로 중복 없는 합 수집

핵심 아이디어: set<int>에 두 원소의 합을 삽입하면 중복이 자동 제거되고 오름차순 정렬도 자동으로 된다. 이중 루프로 모든 쌍을 순회하면 O(N²).

vector<int> solution(vector<int> numbers) {
    set<int> sum;
    for (int i = 0; i < numbers.size(); ++i)
        for (int j = i + 1; j < numbers.size(); ++j)
            sum.insert(numbers[i] + numbers[j]);  // set이 중복+정렬 처리
    return vector<int>(sum.begin(), sum.end());
}
// {2,1,3,4,1} → {2,3,4,5,6,7}

③ 모의고사 — 패턴 배열 + 나머지 연산

핵심 아이디어: 각 수포자의 반복 패턴을 배열로 정의하고 i % pattern.size()로 패턴을 순환시킨다. 맞힌 횟수를 비교해 최댓값과 동률인 사람을 모두 반환한다.

vector<int> p1 = {1,2,3,4,5};
vector<int> p2 = {2,1,2,3,2,4,2,5};
vector<int> p3 = {3,3,1,1,2,2,4,4,5,5};

for (int i = 0; i < answers.size(); i++) {
    if (answers[i] == p1[i % p1.size()]) cnt[0]++;
    if (answers[i] == p2[i % p2.size()]) cnt[1]++;
    if (answers[i] == p3[i % p3.size()]) cnt[2]++;
}
// i % size() 로 패턴을 무한 반복시키는 것이 핵심

7한눈에 보는 정리

연산	시간 복잡도	이유
임의 접근 `arr[i]`	O(1)	시작 주소 + i × 타입 크기로 직접 계산
맨 뒤 삽입/삭제	O(1)	다른 원소 이동 없음
중간/맨 앞 삽입/삭제	O(N)	이후 원소들을 전부 밀거나 당겨야 함
선형 탐색	O(N)	최악의 경우 모든 원소를 순회
크기 변경	불가	C++ 정적 배열은 선언 시 크기 고정

8오늘의 회고

이번 챕터에서 가장 인상 깊었던 건 2차원 배열도 메모리상에서는 1차원으로 저장된다는 사실이었다. 행 우선 순서로 연속 배치된다는 것을 이해하니, 2차원 배열의 열(col) 방향 순회가 왜 행(row) 방향 순회보다 느린지 — 캐시 미스가 더 자주 발생하기 때문 — 까지 자연스럽게 이해됐다.

맨 앞 삽입이 O(N)이라는 사실을 단순히 외우는 것에서 끝내지 않고, 연속 메모리 구조상 앞의 빈 공간이 없기 때문에 전체를 밀어야 한다는 이유를 이해한 것이 중요했다. 앞쪽 삽입/삭제가 잦은 경우에는 배열 대신 deque를 선택해야 한다는 판단 기준도 이 이해에서 나온다.

[C++] 재귀 함수를 코드로

hanong8 — Wed, 6 May 2026 21:19:13 +0900

1이번 챕터의 핵심 메시지

재귀는 자기 자신을 호출하는 함수로, 올바르게 설계하지 않으면 스택 오버플로우가 발생한다. 핵심은 단 두 가지 — 기저 조건(Base Case)과 재귀 호출 단계(Recursive Step)를 명확히 정의하는 것이다. 이 두 가지가 갖춰지면 팩토리얼, DFS, 분할 정복까지 재귀로 자연스럽게 표현할 수 있다.

2재귀의 정의와 두 가지 요건

재귀 함수를 구현하려면 반드시 아래 두 가지를 설계해야 한다. 하나라도 빠지면 무한 루프나 스택 오버플로우로 이어진다.

① 재귀 호출 단계

문제 크기 축소

자기 자신을 호출하되, 매번 문제의 크기를 줄여야 한다. 크기가 줄지 않으면 무한 호출로 이어진다.

② 기저 조건 (Base Case)

종료 조건

특정 조건을 만족하면 자기 자신을 더 이상 호출하지 않고 직접 값을 반환해 함수를 종료한다.

기저 조건이 없으면? 함수가 종료되지 않고 계속 스택 프레임이 쌓여 스택 오버플로우(Stack Overflow)가 발생한다. 종료 조건은 반드시 명확하게 정의해야 한다.

3재귀 함수 설계 — 팩토리얼 예시

재귀 함수를 설계할 때는 "구현하려는 함수가 이미 있다고 가정"하는 사고방식이 핵심이다. 그러면 현재 문제를 더 작은 문제의 해로 표현하는 데 집중할 수 있다.

문제 정의: Fact(N)은 N!을 반환하는 함수라고 가정한다.

재귀 호출 단계: Fact(N) = N × Fact(N-1) → 크기 N 문제를 크기 N-1 문제로 축소한다.

기저 조건: N이 0 또는 1이면 더 이상 쪼갤 수 없으므로 1을 직접 반환한다.

n! = 1, if n = 0 or n = 1 ← 기저 조건
n! = n × (n−1)!, if n > 1 ← 재귀 호출 단계

int Fact(int N) {
    if (N == 0 || N == 1) return 1;  // 기저 조건
    return N * Fact(N - 1);           // 재귀 호출 단계
}
// Fact(5) → 120

스택 호출 흐름 (N=5)

Fact(5) 호출
  Fact(4) 호출
    Fact(3) 호출
      Fact(2) 호출
        Fact(1) 호출
          Fact(0) 호출
          Fact(0) = 1 반환  ← 기저 조건 도달
        Fact(1) = 1 반환
      Fact(2) = 2 반환
    Fact(3) = 6 반환
  Fact(4) = 24 반환
Fact(5) = 120 반환

4수학적 귀납법과 재귀의 관계

재귀 함수 설계는 수학적 귀납법(Mathematical Induction)과 동일한 논리 구조를 가진다. 도미노 효과를 떠올리면 쉽다.

수학적 귀납법

기본 단계: 첫 번째 도미노가 넘어진다.

귀납 단계: k번째가 넘어지면 k+1번째도 반드시 넘어진다.

재귀 함수 설계

기저 조건: 가장 작은 입력(0 or 1)은 직접 답을 반환한다.

재귀 호출 단계: 크기 N 문제를 크기 N-1 문제로 표현한다.

핵심 인사이트: 구현하려는 함수가 이미 있다고 가정하면, 더 작은 문제로 현재 문제를 표현하는 데만 집중할 수 있다. 이것이 재귀 설계의 본질이다.

5재귀 함수 동작 시 메모리의 모습

함수가 호출될 때마다 스택 프레임(Stack Frame)이 생성되어 쌓인다. 스택 프레임에는 지역 변수, 매개 변수, 반환 주소가 포함된다. 함수가 종료되면 해당 프레임이 제거되고 이전 호출 위치로 돌아간다.

초기

main()

→

Fact(5) 호출

Fact(5)

main()

→

Fact(3) 호출

Fact(3)

Fact(4)

Fact(5)

main()

→

최대 깊이

Fact(0)

Fact(1)

Fact(2)

Fact(3)

Fact(4)

Fact(5)

main()

주의: 재귀 깊이가 깊어질수록 스택 메모리를 계속 소비한다. 기저 조건에 도달한 후에는 역방향으로 각 프레임이 차례로 제거되며 최종 결과가 계산된다. 호출 깊이를 적절히 제한하지 않으면 스택 오버플로우가 발생할 수 있다.

6재귀가 효율적인 경우

대부분의 반복 작업은 반복문으로도 구현할 수 있다. 그럼에도 재귀가 더 자연스럽고 효율적인 경우가 있다.

스택 기반 알고리즘

함수 호출 자체가 LIFO 스택 구조다. DFS(깊이 우선 탐색)을 명시적 스택 없이 재귀로 자연스럽게 구현할 수 있다.

분할 정복 알고리즘

문제를 분할 → 정복 → 결합하는 구조가 재귀와 맞아떨어진다. 병합 정렬, 퀵 정렬이 대표적이다.

DFS — 재귀 vs 반복문 비교

재귀 DFS 간결

void DFS(int node) {
  visited[node] = true;
  cout << node << ' ';
  for (int next : graph[node])
    if (!visited[next])
      DFS(next); // 재귀
}

반복문 DFS 복잡

void DFS(int start) {
  stack<int> s;
  s.push(start);
  visited[start] = true;
  while (!s.empty()) {
    // 역순 탐색 별도 처리...
  }
}

재귀 DFS는 각 함수가 자신과 인접한 노드만 관리하면 되므로 코드가 간결하고 가독성이 높다. 반면 반복문 DFS는 스택 초기화, 삽입, 삭제, 역순 탐색까지 직접 처리해야 해서 코드가 복잡해진다.

7재귀 사용 시 주의점 — 피보나치와 메모이제이션

단순 재귀는 중복 호출 문제를 일으킬 수 있다. fibo(6)을 단순 재귀로 계산하면 같은 값을 여러 번 반복 계산해 시간 복잡도가 O(2ⁿ)까지 치솟는다.

단순 재귀 O(2ⁿ)

하나의 함수가 두 개를 호출 → 호출 수가 지수적으로 폭증. fibo(4)가 2번, fibo(3)이 4번 중복 호출된다.

메모이제이션 O(N)

한 번 계산한 결과를 배열에 저장. 이후 동일한 값을 요청받으면 저장된 값을 즉시 반환해 중복 연산을 제거한다.

fibo(40) 계산 — 단순 재귀 vs 메모이제이션 호출 횟수

단순 재귀 — O(2ⁿ) 메모이제이션 — O(N)

fibo(40) 기준으로 단순 재귀는 약 3억 3천만 번의 함수 호출이 발생하지만, 메모이제이션 적용 시 단 79번만 호출된다. 메모이제이션 하나만으로 수백만 배의 성능 차이가 생긴다.

// 메모이제이션을 적용한 피보나치
vector<int> memo(1000, -1);

int fibo(int n) {
    if (n == 1 || n == 2) return 1;
    if (memo[n] != -1) return memo[n];  // 이미 계산됨 → 즉시 반환
    memo[n] = fibo(n - 1) + fibo(n - 2);
    return memo[n];
}

8재귀 예시 — 지수 연산의 최적화

X의 N승을 단순 재귀로 구현하면 O(N)이다. N이 짝수일 때 문제 크기를 절반으로 줄이는 분할 정복을 적용하면 O(log N)으로 개선할 수 있다.

기본 재귀 O(N)

매번 1씩 줄여가며 N번 호출. N이 클수록 호출 횟수가 선형으로 증가한다.

분할 정복 O(log N)

짝수면 절반으로 분할해 제곱. 홀수면 하나 더 곱함. 호출 횟수가 log N으로 급감한다.

pow(2, N) 계산 — 재귀 호출 횟수 비교

기본 재귀 — O(N) 분할 정복 — O(log N)

// 분할 정복을 활용한 효율적인 X의 N승 계산
double pow(double X, int N) {
    if (N == 0) return 1;
    double half = pow(X, N / 2);
    if (N % 2 == 0)
        return half * half;        // 짝수: (X^(N/2))²
    else
        return half * half * X;    // 홀수: (X^(N/2))² × X
}
// pow(2.0, 10) = 1024

9한눈에 보는 정리 — 재귀 vs 반복문

특성	재귀 함수	반복문
메모리 사용	스택 프레임 누적 → 오버플로우 위험	스택 메모리 사용 없음 → 효율적
실행 속도	함수 호출 오버헤드 → 상대적으로 느림	함수 호출 없음 → 일반적으로 빠름
가독성	재귀 구조 문제에서 간결하고 직관적	단순 반복 작업에서 직관적
변수 사용	상태 변수 불필요, 코드 간결	상태 유지 변수 다수 필요
무한 반복 시	스택 오버플로우 발생	CPU 점유 → 시스템 부하
적합한 상황	DFS, 분할 정복, 트리/그래프 탐색	단순 집계, 선형 순회, 성능 중시

10오늘의 회고

이번 챕터에서 가장 인상 깊었던 건 "구현하려는 함수가 이미 있다고 가정하라"는 사고방식이었다. 처음엔 순환 논리처럼 느껴졌지만, 수학적 귀납법과 연결해서 생각하니 오히려 명확하게 이해됐다. 재귀를 설계할 때 기저 조건을 먼저 잡고, 그다음 현재 문제를 더 작은 문제로 표현하는 순서로 접근하면 훨씬 수월하다는 것도 배웠다.

피보나치의 단순 재귀가 O(2ⁿ)이 되는 이유를 트리 구조로 직접 시각화하니 명확하게 와닿았고, 메모이제이션 하나만으로 O(N)으로 줄어드는 것이 생각보다 훨씬 강력하게 느껴졌다. 앞으로 재귀 문제를 만나면 ① 중복 호출이 발생하는 구조인지 확인하고, 그렇다면 메모이제이션을 바로 적용하는 습관을 들여야겠다.

[C++] 입출력 데이터 다루기 - 숫자 연산과 문자열 스트림 정리

hanong8 — Tue, 28 Apr 2026 21:09:02 +0900

1. 이번 챕터에서 배운 것

코딩 테스트 문제를 풀다 보면 입력값을 파싱하고 변환하는 데 생각보다 많은 시간을 쓰게 된다. 이번 강의에서는 C++에서 자주 쓰이는 숫자 처리 함수 3가지와, 문자열을 스트림처럼 다루는 stringstream 활용법을 집중적으로 다뤘다.

모든 수학 함수(round, ceil, floor)는 #include <cmath> 헤더가 필요하고, 문자열 스트림 관련 기능은 #include <sstream>이 필요하다.

2. 숫자 다루기 — cmath 함수 3종

함수	동작	양수 예	음수 예
`round(x)`	반올림 (0.5는 0에서 먼 쪽)	round(3.5) → 4	round(-2.5) → -3
`ceil(x)`	올림	ceil(3.2) → 4	ceil(-3.2) → -3
`floor(x)`	내림	floor(3.7) → 3	floor(-3.7) → -4

주의: floor(-3.7)은 단순히 소수점을 버린 -3이 아니라 -4다. 음수에서 내림은 숫자가 더 작아지는 방향(더 음수)으로 간다.

3. stringstream — 문자열을 스트림처럼

stringstream은 문자열을 마치 cin처럼 다룰 수 있게 해주는 클래스다. 이미 갖고 있는 문자열에서 특정 타입의 값을 순서대로 추출하거나, 반대로 값을 문자열로 변환할 때 매우 유용하다.

공백 기준 분리

string str = "123 X 67";
stringstream stream(str);
int num; char c; float f;
stream >> num >> c >> f;
// num=123, c='X', f=67.0

4. 특정 문자 기준 분리 — getline

공백 외에 쉼표나 슬래시 같은 특정 문자로 구분된 문자열을 분리할 때는 getline(스트림, 버퍼, 구분자)를 사용한다.

string text = "apple,banana,grape,orange";
stringstream ss(text);
string token;
while (getline(ss, token, ',')) {
    cout << token << endl;
}
// apple / banana / grape / orange

패턴 정리: >>는 공백 기준 분리, getline(ss, buf, 구분자)는 특정 문자 기준 분리.

5. 진법 변환 — hex 조작자 활용

10진수 → 16진수

int n = 4095;
stringstream ss;
ss << hex << n;
string h = ss.str(); // "fff"

16진수 → 10진수

string h = "ff";
stringstream ss(h);
int n;
ss >> hex >> n; // n = 255

방향 기억법: 10→16은 <<(출력 방향으로 넣기), 16→10은 >>(추출 방향으로 읽기).

6. 오늘의 회고

지금까지 입력값 파싱은 cin만 쓰거나 손으로 처리해왔는데, stringstream 하나로 타입 변환과 구분자 분리가 깔끔하게 해결된다는 게 인상적이었다. 특히 16진수 변환 시 hex 조작자를 쓰는 방식은 외워두면 실전에서 시간을 많이 아낄 수 있을 것 같다. 음수에서 floor와 단순 소수점 버리기의 차이는 헷갈리기 쉬운 부분이므로 따로 정리해뒀다.

[코딩 테스트] 어떻게 준비하고 어떻게 풀어야 할까?

hanong8 — Mon, 27 Apr 2026 20:12:21 +0900

1. 코딩 테스트란 무엇인가

코딩 테스트는 제한된 시간 안에 프로그래밍 언어로 주어진 문제를 풀어내는 시험이다. 많은 IT 기업의 채용 프로세스에 포함되어 있으며, 단순히 정답을 맞히는 것을 넘어 문제에서 요구하는 성능을 충족하는 코드를 구현하는 것이 핵심이다.

흔히 "머리가 좋아야 풀 수 있다"고 생각하지만, 코딩 테스트는 IQ 테스트가 아니다. 시험에서 요구하는 사항을 명확히 인지하고 반복 트레이닝한다면 충분히 통과할 수 있는 시험이다.

프로그래머스 기준으로 취업을 목표로 한다면 레벨 2 ~ 3 수준을 목표로 삼는 것이 적절하다.

2. 나의 현재 수준 파악하기

레벨 0~1: 기본 문법은 숙지했으나 자료구조·알고리즘을 모름. 직관과 단순 논리로 문제 해결.
레벨 1~2: 자료구조·알고리즘을 배우는 중. 간단한 자료구조를 적용해서 문제를 풀 수 있음.
레벨 2~3: 다양한 접근 방식으로 풀이 가능. 요구 성능 파악 및 이에 맞는 코드 구현 가능.

3. 코딩 테스트에 필요한 4가지 역량

요구 사항 파악: 문제를 읽고 핵심을 요약하고, 제약 사항을 정확히 이해한다.
효율적인 코드 구현: 다량의 입력값을 처리할 수 있는 성능 충족 코드를 작성한다.
논리적 설계 및 구현: 의사 코드를 먼저 작성하고, 이를 실제 코드로 옮긴다.
예외 처리 능력: 사전에 예외 케이스를 발굴하고 테스트 케이스에 반영한다.

4. 문제를 푸는 전략 — 70:30 법칙

풀이 시간의 70%는 분석에, 30%는 구현에 써야 한다.

5. 프로그래머스 채점 방식 이해하기

정확성 테스트: 코드가 리턴한 값과 실제 정답이 일치하는지 확인. 10초 내 리턴 필요.
효율성 테스트: 구현한 코드가 요구 성능을 충족하는지 확인. 출제자 정답 코드의 평균 수행 시간이 기준.

오픈채팅방 예시 문제에서 정확성은 통과했지만 효율성에서 시간 초과가 발생했다. 원인은 O(N²) 탐색 구조였으며, HashMap으로 아이디-닉네임을 별도 관리하는 방식으로 해결할 수 있었다.

6. 효율적인 학습법 — 데이터 기반 목표 세우기

(X) "한 달에 100문제 풀기"
(O) "오답 유형 분류 후, 취약 분야 60문제 + 복습 40문제" — 한 사이클이 끝나면 다시 데이터를 보고 동적으로 조정.

일주일에 한 번은 실전처럼 타이머를 켜고 문제를 풀어보는 습관도 중요하다. 모르는 문제가 나왔을 때는 약 60분 정도 고민한 뒤 풀이를 확인하고, 풀지 못한 이유와 정답 코드의 전략을 정리해두는 것이 좋다.

7. 오늘의 회고

오늘 가장 인상 깊었던 부분은 문제를 푸는 과정 자체를 체계화하는 것의 중요성이었다. 구현보다 분석에 더 많은 시간을 써야 한다는 것, 그리고 시간 초과가 발생했을 때 코드가 아니라 알고리즘의 구조를 먼저 의심해야 한다는 것을 예시 문제를 통해 직접 경험했다.

[UnrealEngine] 멀티플레이어 디펜스 `SagoMagic` 프로젝트 KPT 회고

hanong8 — Fri, 24 Apr 2026 16:42:41 +0900

프로젝트 개요

프로젝트명	SagoMagic (Co-op 탑다운 타워디펜스)
엔진	Unreal Engine 5.6, C++ / Blueprint
네트워크	Dedicated Server, Seamless Travel
핵심 기술	GAS, GMS, 그리드 건축, 격자형 인벤토리, Fragment 패턴
팀 규모	7인 ( 곽은서, 김현, 박원종, 이준로, 임영택, 주철민, 허태린 )
개발 기간	4 / 1 ~ 4 / 24

게임 루프는 로비 → 정비 단계(BuildState) → 웨이브 전투(CombatState) → 결과 화면(ResultState)의 사이클을 반복하며 베이스캠프(ASMBaseCampActor)의 HP가 0이 되면 패배, 마지막 웨이브를 클리어하면 승리한다.4인 Dedicated Server 구조로 운영되며 맵 전환은 Seamless Travel(L_Transition 경유)로 처리했다.

Keep - 잘 된 것, 유지할 것

1. GAS 기반 전투·건축 시스템의 통합 설계

이번 프로젝트에서 가장 큰 기술적 성과는 GAS를 단순히 "스킬 시스템"으로 국한하지 않고, 전투·건축·쿨타임·상태 관리를 아우르는 프로젝트 전체의 공통 인프라로 정착시킨 것이다.

어빌리티 시스템 컴포넌트(SMAbilitySystemComponent)는 플레이어, 몬스터, 건물, 베이스캠프 각각에 독립적인 AttributeSet을 붙여 관리한다. USMPlayerAttributeSet은 플레이어의 HP와 이동 속도를, USMMonsterAttributeSet은 몬스터 스탯을, USMBuildingAttributeSet은 건물 내구도를, USMBaseCampAttributeSet은 베이스캠프 HP를 전담한다. 이처럼 어트리뷰트를 객체 타입별로 분리함으로써 각 객체의 상태 변화가 다른 객체에 간섭하지 않으며, GE(GameplayEffect)의 적용 대상을 태그 기반으로 명확히 구분할 수 있었다.

스킬 실행 흐름은 다음과 같이 정형화되어 있다. 마우스 클릭이 TryActivateAbilitiesByTag()를 호출하면GA_SkillBase::ActivateAbility()가 실행되고, 먼저 인벤토리에서 FSMCompiledSkillSummary를 로드해 최종 수치(피해량, 쿨타임, 범위, 지속시간, 업그레이드 태그)를 확보한다. 이후 CommitAbility()로 GE_SkillCooldown을 적용하고, 몽타주를 재생하여 AN_SendEvent AnimNotify가 발동되는 타이밍에 GameplayEvent를 전달한다. 클라이언트는 이 시점에 마우스 좌표를 수집해 ServerSetReplicatedTargetData로 서버에 전송하며, 서버는 OnTargetDataReadyCallback()에서 실제 피해를 적용한다.

건물 배치(GA_BuildPlace) 역시 동일한 어빌리티 파이프라인으로 처리된다. ServerRPC_RequestPlaceBuilding() 호출 후 GA_BuildPlace::ActivateAbility()가 서버에서만 실행되어 셀 점유 검증 → GE로 골드 차감 → 건물 스폰 + GridData 등록 순서로 원자적으로 처리된다. 스킬 발동과 건물 배치가 동일한 어빌리티 인터페이스를 공유하기 때문에, 어빌리티 등록/해제, 쿨타임 처리, 태그 기반 발동 차단 등의 공통 로직을 중복 없이 재사용할 수 있었다.

쿨타임 관리는 GE_SkillCooldown(HasDuration)과 SetByCaller(Data.Cooldown) 조합으로 동적 주입 방식을 채택했다. GA의 ActivationBlockedTags에 Cooldown.Skill.* 태그를 등록해두면, 해당 GE가 활성화된 동안에는 어빌리티 발동이 자동으로 차단된다. GE의 GrantedTags가 부여/제거되는 시점에 USMSkillCooldownWidget이 실시간으로 갱신되어, 별도의 UI 타이머 로직 없이도 정확한 쿨타임 표시가 가능하다.

2. GMS 기반 UI 디커플링의 구조적 효과

멀티플레이어 게임에서 UI 갱신을 서버 → 클라이언트 복제에 의존하면 불필요한 네트워크 트래픽이 발생하고, 게임 로직과 UI 간의 결합도가 높아진다. 이를 해결하기 위해 GameplayMessageRouter 플러그인 기반의 GameplayMessageSubsystem(GMS)을 UI 갱신의 단일 채널로 채택했다.

구체적인 채널 구조는 다음과 같다. 웨이브 진행 정보는 UI.Event.Wave 채널로 방송되어 USMWaveTimeWidget이 수신하고, 베이스캠프 HP 변화는 USMBaseCampAttributeSet::OnRep_Health()에서 UI.Event.BaseCamp로 방송되어 USMBaseCampHPBarWidget이 수신한다. 알림 메시지는 ClientRPC_ShowNotification()에서 UI.Event.Notification으로 방송되고, 건축 모드 진입/해제는 UI.Event.BuildMode, 편집 모드는 UI.Event.EditMode, 인벤토리 관련 조작은 SM.Message.Inventory.* 채널을 통해 처리된다.

이 구조의 핵심 이점은 게임 로직 클래스가 어떤 위젯도 직접 참조하지 않는다는 점이다. 예를 들어 ASMBaseCampActor는 HP가 변할 때 GMS에 메시지를 방송하는 것 외에 UI에 대해 아무것도 알지 못한다. 위젯을 교체하거나 추가하더라도 로직 코드를 건드릴 필요가 없다. 실제 개발 과정에서 HUD 구조가 여러 차례 변경되었음에도 게임 로직 측에서의 수정이 전혀 필요 없었던 것이 이를 잘 보여준다.

3. Fragment 패턴 기반 데이터 주도 아키텍처

인벤토리와 스킬 시스템의 데이터 설계에서 Fragment 패턴을 채택한 것은 이번 프로젝트의 아키텍처적 하이라이트 중 하나다. USMItemDefinition이 필요한 Fragment를 조합하는 방식으로, 아이템 종류마다 클래스를 새로 만들 필요 없이 Fragment 구성만으로 다양한 아이템을 정의할 수 있다.

각 Fragment의 역할은 명확하게 분리되어 있다. USMGridShapeFragment는 비트마스크(FSMGridMaskData)로 격자 점유 형태를 정의하며 0°/90°/180°/270° 회전을 지원하고, 배치 충돌 감지도 비트마스크 AND 연산으로 처리되어 루프 기반 충돌 검사 대비 성능이 우수하다. USMAbilityFragment는 아이템과 어빌리티 클래스를 연결하며 관련 태그를 보유한다. USMGemModifierFragment는 젬 효과의 종류·수치·장착 조건 태그(RequiredAllTargetTags, RequiredAnyTargetTags, BlockedTargetTags)를 포함해 태그 기반 호환성 검사를 가능하게 한다. USMInternalInventoryFragment와 USMSkillProgressionFragment는 스킬 아이템의 내부 인벤토리 구조와 레벨업 규칙을 담당한다.

스킬 발동 시마다 젬 효과를 재순회하는 대신 FSMCompiledSkillSummary에 수치를 미리 캐싱해두는 설계도 중요한 최적화다. BuildSkillSummary()는 DT_Skill의 베이스 수치에 레벨 증가량을 합산하고, 내부 젬을 순회하며 FinalDamage *= (1 + %), FinalCooldown *= (1 - %) 등의 승산 합성을 적용한 뒤, GrantedBehaviorTags를 BehaviorTags에 병합하여 동작 분기 플래그로 활용한다. 이 캐시는 인벤토리 구성이 바뀔 때만 재계산되므로, 매 어빌리티 발동마다 순회 비용이 발생하지 않는다.

4. 그리드 건축 시스템의 완성도

ASMGridManager는 1D 배열(Index = Y × Width + X) 기반으로 전체 그리드 상태를 관리한다. 각 셀은 bIsOccupied, BuildingType, OwnerId를 클라이언트에 DOREPLIFETIME으로 복제하고, PlacedActor는 서버 전용으로 유지한다. 이는 건물 액터 자체가 bReplicates = true로 별도 복제되기 때문에 이중 복제를 피하면서도 클라이언트가 그리드 상태를 정확히 인식할 수 있게 하는 효율적인 설계다.

BakeGridHeights()는 StartPlay 시 1회 Landscape의 Z값을 사전 베이크하여, 건물 배치 시마다 지형 높이를 실시간으로 계산하는 비용을 제거한다.

경로 기반 펜스 배치에서의 A* 구현은 방향 전환 패널티를 포함하여 직선 경로를 우선시하도록 설계했다. 이를 통해 플레이어가 두 점을 찍으면 꺾이는 경로보다 직선에 가까운 자연스러운 펜스 배치가 이루어진다. 경로의 방향 전환 지점은 GetEffectiveCornerInfo()로 자동 감지되어 ConvertToCornerPreview()를 통해 코너 메시로 교체되고 적절한 Yaw가 계산된다. 경로 끝점에서도 인접 점유 셀을 검사해 접합부 코너를 자동 처리하므로 플레이어가 코너를 수동으로 배치할 필요가 없다.

편집 모드(SMEditModeComponent)에서 건물 이동 시 클라이언트는 로컬에서 선제적으로 이동을 표시하고, ServerRPC_PreviewMove → MulticastRPC_PreviewMove로 다른 클라이언트에 동기화한다. 이동 확정 시 ServerRPC_MoveBuildings가 원자적으로 검증하여 전체 성공 또는 전체 원위치 처리(all-or-nothing)를 보장한다. 이동 중 Pawn 충돌 채널을 MulticastRPC_SetBuildCollision으로 임시 비활성화해 플레이어가 이동 중인 건물에 막히지 않도록 처리한 것도 세심한 UX 고려였다.

5. 웨이브 시스템의 서버-클라이언트 동기화 설계

웨이브 전환 시 가장 까다로운 문제는 서버와 모든 클라이언트의 DataAsset 로드가 완료된 시점에만 전투를 시작해야 한다는 것이었다. 이를 위해 BuildState::Enter() 시점에 USMWaveManagerSubsystem::PreSpawnForWave()가 DT_Monster에서 MonsterDataAsset 경로를 수집하고, AssetManager로 PrimaryAssetId를 조회한 뒤 GameState::SetAssetsToLoad()를 통해 클라이언트에 로드 목록을 복제한다. 서버는 LoadAssetsByIDWithBundles({"Server"}), 클라이언트는 OnRep_AssetsToLoad() 콜백에서 LoadAssetsByIDWithBundles({"Client"})를 비동기로 실행하며, 각 클라이언트가 로드 완료 시 ServerNotifyClientLoadComplete()를 호출해 ReadyClientCount를 증가시킨다. 전원이 준비되면 OnReadyForCombat이 발동되어 CombatState로 전환된다.

CombatState에서 몬스터는 SpawnInterval 간격으로 순차 활성화된다. PreSpawn 단계에서 이미 Hidden 상태로 스폰해 두었기 때문에 전투 시작 시점의 스폰 부하가 없으며, 시각적으로도 몬스터가 갑자기 대량으로 나타나는 현상을 방지할 수 있다. 타임오버 패널티로 잔존 몬스터가 SelfKill하여 베이스캠프에 고정 데미지를 입히는 메커니즘은, 플레이어가 웨이브를 질질 끌어 시간을 낭비하는 전략을 방지하는 게임 디자인적 의도와 서버 측 리소스 정리를 동시에 달성한다.

6. 네트워크 보안 및 서버 권한 설계

보안 설계에서 세 가지 핵심 원칙을 일관되게 유지했다. 첫째, 이속 핵 방어를 위해 서버가 1초마다 MaxWalkSpeed를 검증하고 허용 오차(110%) 초과 시 강제 복구한다. 둘째, 건축 배치는 클라이언트의 고스트 프리뷰가 순수 로컬 표현에 그치고 실제 배치는 GA_BuildPlace [ServerOnly]에서 이중 검증 후 처리된다. 셋째, 인벤토리의 모든 Add/Move/Drop 조작이 서버에서 Authority 체크를 통과해야만 반영된다.

USMSyncDataManager를 서버 전용으로 제한한 것도 의도적인 설계 제약이다. 클라이언트에서 DataTable 원본에 직접 접근할 수 없으므로 치트 도구를 통한 스탯 조작 시도를 구조적으로 차단한다. 스킬 어빌리티를 ASMPlayerCharacter의 ASC가 아닌 ASMPlayerState의 ASC에 등록한 것도 중요한 설계 결정이다. 캐릭터가 리스폰으로 재생성되더라도 PlayerState는 유지되기 때문에, 부활 후에도 어빌리티 등록 상태와 쿨타임 정보가 그대로 보존된다.

Problem - 아쉬웠던 점, 겪었던 문제

1. GAS 초기 설계 비용과 구조 재설계

GAS는 초기 아키텍처 결정이 이후 전체 개발 흐름에 미치는 영향이 매우 크다. 이번 프로젝트에서도 AttributeSet 계층 구조와 GameplayEffect 연산 파이프라인을 초반에 확정하는 데 예상보다 많은 시간이 소요되었고, 프로젝트 중반에 일부 Effect 구조를 재설계하는 일이 발생했다.

특히 피해 계산 흐름에서 GE_InstantDamage의 Execution을 통한 계산과 SetByCaller를 통한 직접 수치 주입 방식 사이의 선택을 두고 초반 설계가 흔들렸다. 최종적으로 SetByCaller(Data.Damage.Amount) 방식을 채택했지만, 이 결정이 늦어지면서 일부 어빌리티에서 두 방식이 혼재하는 시기가 있었고 이를 정리하는 데 추가 공수가 들었다.

ActivationBlockedTags와 ActivationRequiredTags의 설계도 초반에는 충분히 체계화되지 않아, 전투 중 건축 모드 진입 차단(CombatState에서 State.Build.Place 태그 차단) 같은 요구사항이 생길 때마다 태그 구조를 추가하는 방식으로 대응했다. 처음부터 게임 상태 전환과 연동되는 태그 계층을 설계 문서로 정리해두었다면 이런 추가 작업을 줄일 수 있었을 것이다.

2. 멀티플레이어 복제 및 RPC 부하

Dedicated Server 환경에서 액터 수가 늘어남에 따라 복제 부하가 누적되는 문제가 있었다. 웨이브 후반부에 ASMMonsterBase 객체가 다수 활성화된 상태에서 ASMMonsterProjectile 스폰, ASMBaseCampActor HP 변화, ASMGridManager 상태 갱신이 동시에 발생하면 클라이언트 측에서 리플리케이션 지연이 체감될 수 있었다.

몬스터 ASC를 Minimal 복제 모드로 설정한 것은 클라이언트 태그 동기화만을 위한 최소한의 복제라는 의도였으나, 실제로는 UGA_MonsterAttackBase 실행 시 GameplayCue의 네트워크 발동이 예상보다 많은 트래픽을 발생시켰다. 원거리 몬스터(Squid)의 투사체는 서버에서S 스폰되어 bReplicates = true로 모든 클라이언트에 복제되는데, 웨이브 후반에 다수의 투사체가 동시에 활성화되면 복제 대역폭 소비가 컸다.

SMEditModeComponent의 건물 이동 미리보기에서 ServerRPC_PreviewMove → MulticastRPC_PreviewMove 체인이 건물 수만큼 반복 호출될 수 있어, 다수의 건물을 동시에 이동할 때 RPC 호출 빈도가 높아지는 문제도 있었다. 이 부분은 건물 이동 데이터를 배열로 묶어 단일 RPC 호출로 처리하도록 배칭(batching)하지 못한 것이 아쉽다.

3. 몬스터 AI 연산 부하

ASMMonsterAIController는 BehaviorTree와 타이머 기반 UpdateTargetAndTryAttack()을 함께 운영한다. 웨이브 후반에 수십 개의 몬스터가 동시에 활성화되면 각 AIController의 타이머가 거의 같은 프레임에 집중될 수 있으며, 여기에 FindBuildingInRange(), FindNearestPlayerInRange() 같은 오버랩 탐색이 겹치면 CPU 스파이크가 발생했다.

ASMGridManager::FindPath()의 A* 연산도 그리드 크기와 건물 배치 밀도에 따라 비용이 증가한다. 현재 구현에서는 몬스터의 이동 목표(TargetActor)가 항상 가장 가까운 베이스캠프로 고정되어 있고, 장애물(건물)이 변경될 때마다 경로를 재계산하는 구조인데, 이 재계산이 전투 중에도 빈번하게 발생할 수 있었다. 특히 편집 모드에서 건물 이동이 일어날 때 다수의 몬스터가 동시에 경로를 재계산하는 구간이 문제였다.

USMWaveManagerSubsystem의 틱 처리도 최적화가 부족했다. 서브시스템이 매 틱마다 웨이브 상태를 검사하는 대신, 이벤트 기반으로 전환하거나 틱 간격을 늘렸다면 불필요한 연산을 줄일 수 있었다.

4. GAS Prediction 구현의 미완성

현재 구현에서 스킬 발동 시 클라이언트는 GameplayCue의 코스메틱 이펙트만 선예측하고, 실제 피해 처리는 서버에서 OnTargetDataReadyCallback() 이후에 이루어진다. 이 구조는 서버 권한을 보장한다는 측면에서 올바르지만, 네트워크 레이턴시가 높을 때 스킬 이펙트와 실제 피해 판정 사이의 시각적 불일치가 발생할 수 있다.

건축 배치는 ServerOnly 어빌리티로 처리되어 클라이언트 예측이 전혀 없다. 클라이언트가 배치 요청을 보낸 후 서버 응답을 받기까지 건물이 나타나지 않는 딜레이가 존재하며, 이것이 빠른 연속 배치 시에는 체감될 수 있다.

FPredictionKey 기반의 예측 롤백을 건축과 인벤토리 조작에까지 확장하지 못한 것이 UX 측면에서 아쉬운 부분으로 남았다.

5. 인벤토리 복제와 클라이언트 반응성

USMInventoryComponent는 COND_OwnerOnly로 복제되어 보안과 트래픽 측면에서는 이상적이지만, 인벤토리 조작의 모든 경로가 서버를 경유해야 한다는 제약이 생긴다. 아이템 이동, 젬 장착, 스킬 레벨업 등 인벤토리 내부 조작 시 서버 왕복 레이턴시만큼 반응이 늦게 느껴질 수 있으며, 이를 보완하는 로컬 예측 레이어가 구현되지 않았다.

비트마스크 기반 충돌 감지는 성능 측면에서는 효율적이지만, FSMGridMaskData의 회전 변환 로직이 복잡해 일부 엣지 케이스(아이템 회전 후 격자 경계 근처 배치)에서 잘못된 충돌 판정이 발생하는 버그가 간헐적으로 재현되었다. 이 문제는 회전 변환 행렬 계산의 부호 처리 오류에서 기인했으나, 프로젝트 기간 내에 완전히 수정하지 못했다.

Try - 앞으로 시도할 것, 개선 방향

1. 대규모 환경 최적화 체계 도입

다음 장기 프로젝트에서는 Unreal Engine 5의 대규모 최적화 도구를 본격적으로 활용할 계획이다.

Significance Manager를 도입하여 카메라 거리, 화면 점유율, 플레이어와의 상호작용 빈도에 따라 몬스터 AI 틱 빈도를 동적으로 조절한다. 예를 들어 화면 밖 원거리 몬스터는 Significance 값이 낮게 설정되어 AI 틱이 0.3~0.5초 간격으로 줄어들고, 플레이어 근처의 몬스터는 정상 빈도로 유지된다. 이 접근만으로도 웨이브 후반 AI 연산 부하의 상당 부분을 줄일 수 있을 것으로 기대한다.

A* 경로 계산은 온디맨드 캐싱 전략으로 전환한다. 전투 중에는 그리드 변화(건물 배치/삭제/이동)가 발생할 때만 영향 받는 몬스터 그룹의 경로를 재계산하고, 그 외에는 기존 경로를 재사용한다. 이를 위해 그리드 셀 변경 이벤트를 발행하고, 해당 셀을 경로의 일부로 포함하는 몬스터만 선택적으로 재계산하는 구조가 필요하다. ASMGridManager에 구독 패턴을 추가하면 구현 가능하다.

USMWaveManagerSubsystem의 상태 검사는 틱 기반에서 이벤트 기반으로 전환한다. 몬스터가 사망할 때마다 CheckWaveCleared()를 호출하는 현재 방식은 이미 이벤트 기반에 가깝지만, 타임오버 처리 등 일부 흐름이 틱에 의존하고 있어 이를 타이머 델리게이트로 대체할 것이다.

렌더링 측면에서는 World Partition과 HLOD를 도입해 대규모 맵에서 원거리 오브젝트의 렌더링 비용을 줄이고, Occlusion Culling과 Distance Culling을 병행하여 화면에 보이지 않는 건물과 몬스터의 렌더링 스레드 부하를 제거한다.

2. GAS Prediction 고도화

FPredictionKey 기반의 클라이언트 예측을 스킬 피해 판정을 넘어 건축 배치까지 확장한다. 건물 배치의 경우, 클라이언트가 서버 검증 전에 고스트 프리뷰가 아닌 실제 건물 메시를 로컬에서 즉시 표시하고, 서버 검증 실패 시 롤백하는 방식으로 반응성을 개선할 수 있다. 이를 위해 GA_BuildPlace에 LocalPredicted 활성화 정책을 적용하고, 서버 검증 실패 시 OnAbilityCancelled 콜백에서 클라이언트 측 임시 건물 액터를 제거하는 롤백 로직을 구현해야 한다.

인벤토리 조작의 경우 서버 왕복 없이 로컬에서 선예측 상태를 표시하고, 서버 응답이 오면 결과를 확정하거나 원상 복귀하는 Optimistic UI 패턴을 도입한다. GAS의 LocalPredicted 정책을 인벤토리 어빌리티에도 적용하거나, 별도의 클라이언트 측 임시 상태 레이어를 두는 방식으로 구현할 수 있다.

몬스터 투사체의 경우, 서버에서만 스폰하고 복제하는 현재 방식 대신 클라이언트에서 발사 시점을 예측하여 로컬 코스메틱 투사체를 생성하고, 피해 판정은 서버에서만 처리하는 방식으로 체감 반응성을 높인다.

3. 복제 전략 세분화

ASMGridManager의 GridData 배열은 현재 DOREPLIFETIME 단일 조건으로 전체가 복제된다. 실제로는 변경된 셀만 클라이언트에 전달하면 충분한데, 배열 전체를 복제하면 웨이브 시작 시처럼 다수의 셀이 동시에 변경되는 구간에서 불필요한 트래픽이 발생한다. DOREPLIFETIME_CONDITION과 ReplicatedUsing 콜백을 조합하거나, FastArraySerializer를 활용해 변경된 요소만 델타 전송하도록 개선할 계획이다.

몬스터 투사체의 복제도 재검토가 필요하다. 수명이 짧고 수가 많은 투사체 액터를 전통적인 액터 복제로 처리하는 것은 연결/해제 오버헤드가 크다. UReplicationGraph의 UReplicationGraphNode_ActorList를 활용하거나, 투사체 상태를 별도의 경량 구조체 배열로 압축해 GameState를 통해 복제하는 커스텀 복제 전략이 더 효율적일 수 있다.

RPC 배칭도 개선 과제다. 편집 모드의 다중 건물 이동처럼 여러 엔티티의 상태를 동시에 변경하는 작업은 단일 RPC에 배열을 담아 전송하도록 통일한다. ServerRPC_MoveBuildings는 이미 이 방식을 사용하고 있으나, 미리보기 단계의 ServerRPC_PreviewMove도 배칭으로 통일해야 한다.

4. 프로파일링 기반 개발 문화 정착

이번 프로젝트에서 성능 문제는 주로 증상이 나타난 후 사후 대응 방식으로 처리했다. 다음 프로젝트에서는 Unreal Insights와 stat unit, stat game, stat net 명령을 개발 초기부터 주기적으로 모니터링하여 병목을 선제적으로 발견하는 습관을 팀 전체에 정착시킨다.

특히 네트워크 프로파일링에서 NetworkProfiler를 활용해 복제 대역폭을 액터 단위로 분석하고, RPC 호출 빈도와 페이로드 크기를 정량적으로 파악하는 과정을 스프린트마다 반복한다. 이를 통해 주관적인 "느린 것 같다"는 판단 대신 수치 기반으로 최적화 우선순위를 결정할 수 있다.

GAS 측면에서는 AbilitySystem.DebugAbilities 콘솔 명령과 ShowDebug AbilitySystem 활성화를 통해 어트리뷰트 수치, 활성 Effect, 태그 상태를 실시간으로 확인하는 디버깅 워크플로를 팀 표준으로 수립한다.

5. 게임 기획과 기술의 통합적 시각 확보

Fragment 패턴과 DataTable 기반의 데이터 주도 아키텍처를 구축해두었기 때문에, 다음 단계는 이 구조를 플레이테스트 피드백 사이클에 실제로 활용하는 것이다. 젬 조합별 스킬 성능 데이터를 로깅하고, 어떤 조합이 실제 플레이에서 지배적인지 분석하는 인게임 통계 시스템을 USMSyncDataManager 위에 구축할 계획이다.

밸런스 조정을 위해 코드를 재컴파일할 필요 없이 DT_Skill, DT_Wave, DT_Building 수치를 런타임에 핫리로드하는 기능도 다음 프로젝트에서 구현한다. Unreal Engine의 FTableRowBase 기반 DataTable은 에디터에서 이미 핫리로드를 지원하므로, 이를 패키징된 빌드에서도 외부 JSON으로 오버라이드할 수 있는 레이어를 추가하면 된다.

궁극적으로는 기술 아키텍처가 게임 기획의 실험 속도를 뒷받침하는 구조, 즉 프로그래머의 개입 없이 기획자가 새로운 스킬 조합이나 웨이브 구성을 빠르게 시험하고 검증할 수 있는 파이프라인을 완성하는 것이 목표다.

[Unreal Engine5] GA_SkillBase 리팩토링 회고 — 애니메이션 추가와 GameplayCue owner 복제 이슈

hanong8 — Tue, 21 Apr 2026 20:45:35 +0900

프로토타입 단계에서 급히 쌓인 스킬 GA들에 애니메이션을 입히려다 보니, 각 GA가 같은 네트워크 보일러플레이트를 따로따로 들고 있고 그 안에 LocalPredicted 특유의 함정까지 숨어 있었다. 이번 글에서는 (1) 왜 리팩토링이 필요했는지, (2) 어떤 구조로 통합했는지, 그리고 (3) 리팩토링 과정에서 드러난 GameplayCue owner-skip 버그를 어떻게 해결했는지 세 가지를 정리한다.

1. 리팩토링 전 구조

공통 문제 (보일러플레이트의 출처)

스킬마다 "로컬 마우스 좌표 → ServerSetReplicatedTargetData → 서버 AbilityTargetDataSetDelegate 바인딩 → CallReplicatedTargetDataDelegatesIfSet → 콜백에서 종료" 루틴을 따로 재구현.
TryGetMouseGroundLocation이 GA_SkillField에만 존재. 다른 스킬은 각자 GetHitResultUnderCursor / 컨트롤러 회전으로 제각각 처리.
몽타주/노티파이를 연결할 구조가 없어 애니메이션을 넣으려면 모든 파일에 동일 코드를 추가해야 함.
클라 예측 Cue 호출이 GA_SkillField::OnSkillEffect처럼 GA 안쪽에서 일어남 → 뒤에서 다룰 ScopedPredictionKey 이슈를 구조적으로 안고 있었다.

2. 리팩토링 후 구조 — `UGA_SkillBase`로 Template Method 통합

부모가 흐름 전체를 소유하고, 자식은 OnSkillEffect 한 곳만 오버라이드하도록 묶었다.

ActivateAbility
 ├─ LoadActiveSkillSummary      (인벤토리 최종 스탯)
 ├─ CommitAbility
 └─ ExecuteSkillLogic
     ├─ (서버) AbilityTargetDataSetDelegate 바인딩 + CallReplicatedTargetDataDelegatesIfSet
     └─ StartMontageAndTasks
         ├─ WaitGameplayEvent(SkillEventTag)  ──▶ OnFireEventReceived
         │    └─ (로컬) FScopedPredictionWindow + 마우스 좌표 → ServerSetReplicatedTargetData
         │                                     → 클라는 즉시 OnSkillEffect(Target, Aim)
         └─ PlayMontageAndWait  ──▶ OnMontageFinished ──▶ EndAbility

자식 GA가 단순해진다.

GA_Projectile_after: 지팡이 소켓 기반 스폰 + 서버 권위 SpawnActor 수준.
GA_SkillField_after: 5줄 수준. 장판 액터 스폰 후 SMASkillField::InitField에 모든 이펙트 위임.
마우스 좌표 획득은 TryGetMouseGroundLocation 하나로 통일.

설계 포인트

AttackMontage가 없으면 OnFireEventReceived를 즉시 부르고 EndAbility → 애니메이션 없는 스킬과 호환.
OnFireEventReceived는 로컬 경로에서만 ServerRPC를 날림 → 자식은 서버/클라 분기를 신경 쓰지 않음.
OnTargetDataReadyCallBack에서 ConsumeClientReplicatedTargetData 호출 — 이전 구조에서 빠져 있던 ASC 타겟데이터 큐 메모리 누수 방어.

결과적으로 GA_SkillField는 110줄 → 40줄, GA_Projectile은 50줄 → 몇 줄로 줄었고, 앞으로 추가되는 스킬은 템플릿에 얹기만 하면 된다.

3. GameplayCue가 owner 클라에만 안 보이는 문제

리팩토링을 진행하면서 GA_SkillField에 오래전부터 남아 있던 버그 하나가 드러났다.

3-1. 배경지식 — LocalPredicted GA와 ScopedPredictionKey

이론 배경은 이전에 정리한 글로 갈음한다.

GameplayCue 멀티플레이 작동 방식

핵심만 다시 짚으면,

ASC Replication Mode 3가지

Full: owner 포함 모든 클라에 복제
Mixed: owner 제외, 다른 클라에만 복제 (owner는 예측으로 로컬 재생)
Minimal: 특정 속성만 선택 복제

LocalPredicted GA 내부의 예측키 스코프
GA의 NetExecutionPolicy가 LocalPredicted이면, 서버가 그 GA를 실행하는 동안 UAbilitySystemComponent::ScopedPredictionKey에 클라이언트가 생성한 activation prediction key가 세팅된다. 이 스코프 안에서 AddGameplayCue를 호출하면 FastArray 엔트리에 그 key가 붙어 직렬화되고, 복제 로직은 "owner는 이 key로 이미 로컬 예측을 했을 것"으로 판단해 owner에게는 전송을 스킵한다. 다른 클라에게는 정상 전송된다.

즉, ASC Replication Mode = Full이라도 예측키 기반 owner-skip은 별개 경로로 작동한다. 이 점이 이번 문제의 뿌리다.

3-2. 증상

SagoMagic의 ASMPlayerState는 ASC Replication Mode를 Full로 설정해 owner 포함 모든 클라에 Cue가 복제되도록 해뒀다. 그런데 장판 스킬만 이상했다.

리모트 클라에서는 장판 비주얼이 항상 정상 표시
owner(시전자 본인) 클라에서만 간헐적으로 비주얼 누락

owner 쪽 누락이 의심되어 클라 측 예측 분기(if (!HasAuthority()) ASC->AddGameplayCue(...))를 제거했더니 오히려 owner 클라가 항상 안 보이게 됐다. 다른 클라는 여전히 정상. 이 시점에서 "Full 모드인데 owner만 skip되는" 전형적인 예측키 skip 패턴이라는 확신이 생겼다.

3-3. 원인 확정

리팩토링 전 코드를 다시 보면 서버 경로에서 직접 AddGameplayCue를 호출하고 있었다.

// GA_SkillField_before.cpp — 서버 경로
UAbilitySystemComponent* SourceASC = GetAbilitySystemComponentFromActorInfo();
...
FGameplayCueParameters CueParams;
CueParams.Location = SpawnLocation;
CueParams.RawMagnitude = FieldDuration;
SourceASC->AddGameplayCue(SMSkillTag::GameplayCue_Skill_SpawnField_Tick, CueParams);

호출 시점은 UGA_SkillBase::ActivateAbility → OnSkillEffect 체인 안. GA가 LocalPredicted라 서버에서 이 콜스택이 실행되는 동안 ASC->ScopedPredictionKey에는 클라 activation key가 꽂혀 있다. 결과적으로 Cue FastArray 엔트리가 클라 key로 태깅되고, owner에게는 복제가 스킵된다. 실제 owner 클라는 아무것도 예측하지 않았지만 FastArray는 알 방법이 없다.

Full 모드라고 방심하면 안 된다. LocalPredicted GA 안쪽에서 서버 권위로 AddGameplayCue를 호출하면 owner-skip이 일어난다.

3-4. 해결 후보 2가지

A. 예측키 일시 초기화 (이전 블로그 글에서 소개한 방식)

FPredictionKey Saved = OwnerASC->ScopedPredictionKey;
OwnerASC->ScopedPredictionKey = FPredictionKey();

FGameplayCueParameters CueParams;
CueParams.Location = SpawnLocation;
CueParams.RawMagnitude = FieldDuration;
OwnerASC->AddGameplayCue(Tag, CueParams);

OwnerASC->ScopedPredictionKey = Saved;

호출 직전에 예측키를 빈 key로 교체해 FastArray 엔트리를 "서버 권위 항목"으로 만들고, 호출 후 원래 키로 되돌린다. 기존 코드를 최소한으로 건드린다는 장점이 있다.

B. Cue 호출을 GA 바깥으로 이동 (최종 채택)

SMASkillField::InitField는 서버에서 World->SpawnActor 이후 호출되는 일반 액터 메서드라 GA 예측키 스코프 바깥이다. 이 지점에서 Cue를 Duration GE로 래핑해 ASC에 붙이면, GE의 정상 복제 경로를 통해 owner를 포함한 모든 클라에 정상 도달한다..

// SMASkillField::InitField
OwnerASC = UAbilitySystemBlueprintLibrary::GetAbilitySystemComponent(InInstigatorActor);
ActiveCueTag = SMSkillTag::GameplayCue_Skill_SpawnField_Tick;

if (HasAuthority() && IsValid(OwnerASC) && CueEffectClass)
{
    FGameplayEffectContextHandle Context = OwnerASC->MakeEffectContext();
    Context.AddOrigin(GetActorLocation());
    Context.AddInstigator(this, this);

    FGameplayEffectSpecHandle Spec = OwnerASC->MakeOutgoingSpec(CueEffectClass, 1.f, Context);
    if (Spec.IsValid())
    {
        CueEffectHandle = OwnerASC->ApplyGameplayEffectSpecToSelf(*Spec.Data.Get());
    }
}

제거는 OnDurationExpired에서 대칭으로 처리:

if (IsValid(OwnerASC))
{
    OwnerASC->RemoveActiveGameplayEffect(CueEffectHandle);
}

3-5. 왜 B를 택했나

두 해결책 모두 증상은 없앤다. 그럼에도 B를 고른 이유 세 가지.

규율 의존성 제거
A는 "AddGameplayCue를 LocalPredicted GA 서버 경로에서 호출할 땐 save-clear-restore로 감싼다"는 규칙을 팀 전원이 매번 기억해야 한다. 한 명이라도 잊으면 같은 버그가 다른 GA에서 재발. B는 호출 지점 자체가 예측키 스코프 밖이라 구조적으로 재발이 불가능하다.
Cue 수명과 액터 수명의 응집
장판 비주얼은 ASMASkillField 액터가 살아있는 동안만 보여야 한다. Add도 Remove도 SMASkillField 안에 두면 같은 파일, 같은 상태 기계 안에서 관리된다. A를 고르면 Add는 GA에, Remove는 액터에 남아 수명 책임이 두 곳으로 쪼개진다.
Duration GE 래핑의 부수 효과
AddGameplayCue 대신 ApplyGameplayEffectSpecToSelf로 붙이면 FActiveGameplayEffectHandle이라는 취소 가능한 핸들을 얻는다. 디스펠/해제/시전자 사망 같은 이벤트에서 RemoveActiveGameplayEffect(Handle) 한 줄로 거둬들일 수 있어 확장성이 좋다.

3-6. 함께 점검한 항목 — GCN 풀링 `WhileActive`

이전 블로그 글에서 짚었듯 AGameplayCueNotify_Actor는 성능 최적화를 위해 풀링된다. 같은 Cue가 두 번째로 활성화될 때 엔진은 OnActive가 아닌 WhileActive를 호출하므로, 이걸 오버라이드하지 않으면 두 번째 시전부터 이펙트가 아예 보이지 않는 별도의 함정이 있다.

bool WhileActive_Implementation(AActor* MyTarget,
    const FGameplayCueParameters& Parameters)
{
    return OnActive_Implementation(MyTarget, Parameters);
}

이번 수정 과정에서 GameplayCue_Skill_SpawnField_Tick 대응 GCN이 이 패턴을 지키고 있는지 같이 확인했다. 예측키 이슈와 풀링 이슈는 증상이 비슷해서("두 번째부터 안 보인다" / "owner만 안 보인다") 서로 가려버리기 쉽다. 동시에 점검하는 편이 안전하다.

3-7. 체크리스트 (회귀 방지)

비슷한 증상을 만났을 때는 다음 순서로.

ASC Replication Mode가 Full인가 — Mixed면 owner-skip은 설계상 정상 동작. Full로 바꿨는데도 owner만 안 보이면 아래 2~4.
GA NetExecutionPolicy가 LocalPredicted인가 — ServerOnly/ServerInitiated면 예측키 스코프 이슈는 발생하지 않음.
AddGameplayCue 호출 지점이 GA ActivateAbility/OnSkillEffect 내부인가 — 그렇다면 예측키 스코프 안이 거의 확실.
호출을 스폰된 액터/컴포넌트 메서드로 옮길 수 있는가 — 가능하면 B, 구조 변경이 부담되면 A(예측키 save/clear/restore), 최후에 NetMulticast RPC + 코스메틱 우회.
동일 Cue를 두 번 시전했을 때도 보이는가 — 안 보이면 GCN 풀링 WhileActive 미구현 의심.

4. 회고

프로토타입 단계에선 "Mixed가 기본인데 Full로만 바꾸면 owner 복제 이슈는 끝난다"고 막연히 생각했다. 실제로는 ScopedPredictionKey라는 별개의 경로가 owner-skip을 일으킬 수 있고, LocalPredicted 정책을 쓰는 한 모든 GA가 잠재적으로 이 함정을 갖는다. 해결 자체는 간단하지만 원인을 한 번 정확히 짚어두지 않으면 다른 스킬에서 같은 모양으로 재발하는 부류의 버그였다.

그리고 이 이슈를 찾아낸 계기는 결국 "애니메이션을 추가하려고 열어본 코드가 너무 중복이 많아서" 리팩토링을 시작한 것이었다. 보일러플레이트를 걷어내는 과정은 단순한 코드 정리가 아니라, 숨어 있던 네트워크 버그가 한 곳에 모여 드러나는 기회이기도 했다. 앞으로 추가될 스킬들은 통합된 템플릿 위에 얹기만 하면 되고, CCue 호출 규칙도 "액터 메서드에서 GE로 래핑" 한 가지로 정리됐다.

[Unreal Engine5] GAS의 GameplayEffectContextHandle과 GameplayEffectSpecHandle

hanong8 — Mon, 20 Apr 2026 20:22:31 +0900

계기

SMASkillProjectile에서 투사체가 적에게 맞았을 때 데미지를 적용하는 코드를 작성하다가 두 핸들의 역할이 헷갈렸다.

FGameplayEffectContextHandle ContextHandle = SourceASC->MakeEffectContext();
ContextHandle.AddInstigator(Avatar, Controller);

FGameplayEffectSpecHandle SpecHandle = SourceASC->MakeOutgoingSpec(DamageEffectClass, 1.f, ContextHandle);
SpecHandle.Data->SetSetByCallerMagnitude(SMSkillTag::Data_Damage_Amount, -BaseDamage);

TargetASC->ApplyGameplayEffectSpecToSelf(*SpecHandle.Data.Get());

왜 두 개를 따로 만들어야 하는지, 그냥 하나로 합칠 수 없는지 의문이 생겼다.

GameplayEffectContextHandle — 출처 증명서

"누가, 어떤 상황에서 이 GE를 발동했는가" 에 대한 메타데이터를 담는 구조체다.

FGameplayEffectContextHandle Context = ASC->MakeEffectContext();
Context.AddInstigator(Avatar, Controller); // 시전자 + 컨트롤러
Context.AddOrigin(GetActorLocation());     // 발동 위치
Context.AddHitResult(HitResult);          // 피격 정보

GE가 적용될 때 부가 정보를 함께 전달하는 봉투 역할을 한다. 이 정보는 이후 아래와 같은 곳에서 꺼내 쓴다.

데미지 계산 시 Instigator 귀속
GameplayCue의 피격 위치/방향
어트리뷰트 변경 이벤트에서 누가 때렸는지 추적

GameplayEffectSpecHandle — 실행 계획서

"어떤 GE를, 어떤 수치로 적용할 것인가" 에 대한 실행 설계도다.

FGameplayEffectSpecHandle Spec = ASC->MakeOutgoingSpec(DamageEffectClass, Level, Context);
Spec.Data->SetSetByCallerMagnitude(Tag, -100.f); // 수치 런타임 주입
Spec.Data->DynamicGrantedTags.AddTag(CooldownTag); // 태그 런타임 추가

ContextHandle을 내부에 포함하면서, 실제로 적용될 GE의 클래스, 레벨, 수치, 태그 등 모든 정보를 담고 있다.

둘의 관계

ContextHandle          →    SpecHandle              →    ApplyGameplayEffectSpecToSelf
(누가 / 어디서 / 어떻게)      (무엇을 / 얼마나 / 어떤 태그)      (실제 적용)

SpecHandle이 ContextHandle을 포함하는 구조다. ContextHandle 없이 Spec을 만드는 것도 가능하지만, 그 경우 GE는 적용되어도 시전자 정보가 없어서 Instigator가 None으로 남는다.

핵심 정리

ContextHandle SpecHandle

역할	출처 증명서	실행 계획서
담는 것	시전자, 위치, 피격 정보	GE 클래스, 수치, 태그
포함 관계	—	ContextHandle을 내부에 포함
없으면	Instigator 추적 불가	GE 적용 자체가 불가

ContextHandle은 "누가 쐈는지", SpecHandle은 "무엇을 얼마나 쐈는지"다.
출처 없이 계획만 있으면 GE는 적용되지만, 누가 쐈는지 게임이 모른다.

HaNong

[C++] 코딩테스트에서의 스택

[C++] 코딩테스트에서의 시뮬레이션

[C++] 코딩테스트에서의 정렬

[C++] 코딩테스트에서의 배열

[C++] 재귀 함수를 코드로

[C++] 입출력 데이터 다루기 - 숫자 연산과 문자열 스트림 정리

1. 이번 챕터에서 배운 것

2. 숫자 다루기 — cmath 함수 3종

3. stringstream — 문자열을 스트림처럼

공백 기준 분리

4. 특정 문자 기준 분리 — getline

5. 진법 변환 — hex 조작자 활용

10진수 → 16진수

16진수 → 10진수

6. 오늘의 회고

[코딩 테스트] 어떻게 준비하고 어떻게 풀어야 할까?

1. 코딩 테스트란 무엇인가

2. 나의 현재 수준 파악하기

3. 코딩 테스트에 필요한 4가지 역량

4. 문제를 푸는 전략 — 70:30 법칙

5. 프로그래머스 채점 방식 이해하기

6. 효율적인 학습법 — 데이터 기반 목표 세우기

7. 오늘의 회고

[UnrealEngine] 멀티플레이어 디펜스 `SagoMagic` 프로젝트 KPT 회고

프로젝트 개요

Keep - 잘 된 것, 유지할 것

1. GAS 기반 전투·건축 시스템의 통합 설계

2. GMS 기반 UI 디커플링의 구조적 효과

3. Fragment 패턴 기반 데이터 주도 아키텍처

4. 그리드 건축 시스템의 완성도

5. 웨이브 시스템의 서버-클라이언트 동기화 설계

6. 네트워크 보안 및 서버 권한 설계

Problem - 아쉬웠던 점, 겪었던 문제

1. GAS 초기 설계 비용과 구조 재설계

2. 멀티플레이어 복제 및 RPC 부하

3. 몬스터 AI 연산 부하

4. GAS Prediction 구현의 미완성

5. 인벤토리 복제와 클라이언트 반응성

Try - 앞으로 시도할 것, 개선 방향

1. 대규모 환경 최적화 체계 도입

2. GAS Prediction 고도화

3. 복제 전략 세분화

4. 프로파일링 기반 개발 문화 정착

5. 게임 기획과 기술의 통합적 시각 확보

[Unreal Engine5] GA_SkillBase 리팩토링 회고 — 애니메이션 추가와 GameplayCue owner 복제 이슈

1. 리팩토링 전 구조

2. 리팩토링 후 구조 — UGA_SkillBase로 Template Method 통합

3. GameplayCue가 owner 클라에만 안 보이는 문제

3-1. 배경지식 — LocalPredicted GA와 ScopedPredictionKey

3-2. 증상

3-3. 원인 확정

3-4. 해결 후보 2가지

A. 예측키 일시 초기화 (이전 블로그 글에서 소개한 방식)

B. Cue 호출을 GA 바깥으로 이동 (최종 채택)

3-5. 왜 B를 택했나

3-6. 함께 점검한 항목 — GCN 풀링 WhileActive

3-7. 체크리스트 (회귀 방지)

4. 회고

[Unreal Engine5] GAS의 GameplayEffectContextHandle과 GameplayEffectSpecHandle

계기

GameplayEffectContextHandle — 출처 증명서

GameplayEffectSpecHandle — 실행 계획서

둘의 관계

핵심 정리

2. 리팩토링 후 구조 — `UGA_SkillBase`로 Template Method 통합

3-6. 함께 점검한 항목 — GCN 풀링 `WhileActive`