Day 6 — 오늘 배운 게임 서버 개발 지식 5가지
학습일: 2026년 11월 6일
복습일: 2026년 11월 7일
학습 주제: PriorityQueue와 Heap, Sliding Window, Observer 패턴, C# 비동기 예외 처리, PostgreSQL 인덱스와 페이지네이션
오늘은 게임 서버 개발에서 자주 접할 수 있는 우선순위 큐, 알고리즘, 이벤트 처리, 비동기 예외, 데이터베이스 조회 최적화를 공부했다.
이번 복습에서는 개념을 설명하는 것은 어느 정도 가능했지만, 직접 C# 코드와 SQL을 작성하는 과정에서 여러 오류가 발생했다.
특히 알고리즘의 원리를 이해하는 것과 정확하게 구현하는 것은 별개의 능력이라는 점을 확인했다.
1. 자료구조 — PriorityQueue와 Heap의 내부 원리
우선순위 큐(Priority Queue)는 데이터가 들어온 순서가 아니라 우선순위에 따라 데이터를 꺼내는 자료구조다.
C#의 PriorityQueue<TElement, TPriority>는 내부적으로 4진 최소 힙(Quaternary Min-Heap) 을 사용한다.
최소 힙에서는 부모 노드의 우선순위가 자식 노드보다 크지 않아야 한다.
중요한 것은 왼쪽 자식이 오른쪽 자식보다 반드시 작아야 하는 구조는 아니라는 점이다.
Heap에 데이터를 삽입하면?
이진 최소 힙을 예시로 생각해 보자.
3
/ \
8 5
/ \
12 10
여기에 우선순위 2를 삽입한다면 다음 과정이 발생한다.
- 힙의 마지막 빈자리에 2를 추가한다.
- 부모 노드인 5와 비교한다.
- 2가 더 작으므로 부모와 위치를 교환한다.
- 다시 부모인 3과 비교하여 위치를 교환한다.
- 힙 조건을 만족하면 종료한다.
이러한 작업을 Sift Up이라고 한다.
최소값을 삭제하면?
최소 힙에서 가장 작은 우선순위는 루트 노드에 있다.
루트 노드를 제거할 때는 마지막 노드를 루트 위치로 이동하고 자식들과 비교하면서 힙 조건을 복구한다.
이를 Sift Down이라고 한다.
예를 들어 기존 힙에서 3을 제거하면 마지막 노드인 10을 루트로 이동시킨 뒤, 두 자식 중 더 작은 5와 비교하여 위치를 조정한다.
시간 복잡도
연산일반적인 시간 복잡도
| Peek |
O(1) |
| Enqueue |
O(log N) |
| Dequeue |
O(log N) |
Enqueue와 Dequeue가 O(log N)인 이유는 모든 데이터를 탐색하는 것이 아니라 힙의 높이를 따라 이동하기 때문이다.
단, 내부 배열의 용량 확장이 필요한 Enqueue에서는 배열 복사 비용이 추가로 발생할 수 있다.
.NET의 실제 구현은 이진 힙이 아니라 4진 최소 힙이므로 한 부모가 최대 네 자식을 가질 수 있다. 그만큼 힙 높이가 달라지지만, 점근적인 탐색 복잡도는 O(log N)이다.
게임 서버에서는 예약 작업이나 타이머, 우선순위가 있는 작업 처리 등에 활용할 수 있다.
다만 동일한 우선순위의 데이터가 반드시 먼저 들어온 순서대로 처리되는 것은 아니다.
2. 알고리즘 — 가변 길이 Sliding Window
Sliding Window는 연속된 구간을 이동하면서 조건을 만족하는 결과를 효율적으로 찾는 기법이다.
고정 길이 Sliding Window는 구간의 크기가 일정하지만, 가변 길이 Sliding Window는 조건에 따라 구간을 확장하거나 축소한다.
문제: 합이 7 이상인 최소 연속 구간
int[] numbers = { 2, 3, 1, 2, 4, 3 };
int target = 7;
연속된 구간의 합이 7 이상인 경우 중 가장 짧은 구간의 길이를 구해야 한다.
이 배열에서는 [4, 3]의 합이 7이므로 최소 길이는 2다.
가변 길이 Sliding Window의 원리
두 인덱스 left, right를 사용한다.
- right를 증가시키면서 새로운 요소를 구간 합에 추가한다.
- 구간 합이 target 이상이면 최소 길이를 갱신한다.
- 조건을 만족하는 동안 왼쪽 요소를 제거하고 left를 증가시킨다.
- 전체 탐색이 끝나면 최소 길이를 반환한다.
이번 복습에서 직접 코드를 작성하면서 세 가지 실수를 했다.
첫 번째는 sum > target으로 비교한 것이다. 문제 조건은 합이 target 이상이므로 등호를 포함해야 한다.
두 번째는 구간 길이를 right - left로 계산한 것이다. 양쪽 인덱스를 포함하므로 right - left + 1이어야 한다.
세 번째는 정답 구간을 찾자마자 반환한 것이다. 더 짧은 구간이 뒤에 있을 수 있으므로 전체 탐색이 필요하다.
학습용 C# 구현 예시
다음은 복습 과정에서 교정한 원리를 반영한 예시다. 내가 처음부터 독립적으로 완성한 코드는 아니며, 별도 컴파일·실행 검증은 수행하지 않았다.
static int MinLength(int[] numbers, int target)
{
int left = 0;
long sum = 0;
int minLength = int.MaxValue;
for (int right = 0; right < numbers.Length; right++)
{
sum += numbers[right];
while (sum >= target)
{
minLength = Math.Min(
minLength,
right - left + 1
);
sum -= numbers[left];
left++;
}
}
return minLength == int.MaxValue ? 0 : minLength;
}
이 코드는 모든 배열 요소가 양의 정수이고 target이 양수라는 전제를 둔다.
반복문이 중첩되어 있는데 왜 O(N)일까?
for문 안에 while문이 있지만, left와 right는 뒤로 이동하지 않는다.
right는 배열의 각 요소를 한 번씩 방문하고, left도 전체 실행 과정에서 최대 N번 증가한다.
따라서 전체 작업량은 O(N)이다.
이 문제에서 중요한 조건은 모든 요소가 양수라는 사실이다.
음수가 포함되면 왼쪽 값을 제거할 때 구간 합이 오히려 증가할 수 있으므로, 같은 방식의 가변 Sliding Window가 항상 올바른 답을 찾지는 못한다.
이번에는 개념과 시간 복잡도는 이해했지만 전체 코드를 스스로 정확하게 완성하는 데 실패했다. 이후 다시 구현해 볼 필요가 있다.
3. 디자인 패턴 — Observer 패턴과 결합도
Observer 패턴은 이벤트를 발행하는 객체와 그 이벤트에 반응하는 구독자를 분리하는 패턴이다.
게임 서버에서 몬스터를 처치하면 다음 기능들이 실행되어야 한다고 가정하자.
- 퀘스트 진행도 갱신
- 업적 조건 확인
- 통계 기록
기존에는 몬스터 서비스가 각 서비스를 직접 호출할 수도 있다.
하지만 Observer 패턴을 적용하면 몬스터 서비스는 이벤트를 발행하고, 각 기능이 해당 이벤트를 구독하도록 구성할 수 있다.
결합도가 낮아지는 이유
처음에는 Observer 패턴을 사용하면 각 서비스를 직접 생성하지 않아도 되기 때문에 결합도가 감소한다고 생각했다.
하지만 이것은 정확하지 않았다.
서비스 객체들은 여전히 생성되어야 한다.
실제 장점은 이벤트 발행자가 각 구독자의 구체적인 구현을 알 필요가 없어진다는 것이다.
예를 들어 길드 미션 기능이 새롭게 추가되어도 몬스터 서비스의 내부 로직을 변경하지 않고 새로운 구독자를 등록할 수 있다.
C#에서는 event, +=, -=, Invoke() 등을 활용할 수 있다.
Observer 패턴의 한계
이벤트 기반 구조에는 단점도 있다.
이벤트가 여러 구독자에게 전달되므로 전체 실행 흐름과 오류를 추적하기가 복잡해질 수 있다.
또한 C#의 일반적인 이벤트만으로는 다음 기능이 자동으로 보장되지 않는다.
- 이벤트 영속성
- 실패한 이벤트의 자동 재시도
- 이벤트 처리의 트랜잭션 원자성
특히 게임 서버의 골드 지급이나 구매 처리 같은 핵심 데이터 정합성을 이벤트에만 의존해서는 안 된다.
핵심 상태 변경은 적절한 트랜잭션으로 보호하고, 통계 기록처럼 분리할 수 있는 작업에 이벤트를 활용하는 방식을 고려할 수 있다.
Factory Method 복습
Observer와 함께 Factory Method의 호출 순서도 다시 확인했다.
부모 객체 타입으로 자식 인스턴스 참조
↓
부모의 Spawn() 호출
↓
자식에서 override한 CreateMonster() 실행
↓
부모의 Spawn()으로 복귀
↓
생성된 Monster의 Appear() 호출
실제 객체 타입이 자식 클래스라면 가상 메서드 호출 시 자식의 재정의된 구현이 선택된다는 점을 다시 확인했다.
4. C# 게임 서버 — try/catch/finally와 비동기 예외
C# 서버에서 비동기 메서드를 사용하다 보면 예외가 어느 위치에서 발생하고 어떻게 전달되는지 이해하는 것이 중요하다.
return이 있어도 finally는 실행된다
다음과 같은 코드를 생각해 보자.
static async Task<int> GetGoldAsync()
{
try
{
await Task.Delay(100);
return 100;
}
finally
{
Console.WriteLine("finally");
}
}
return 100에 도달하더라도 일반적으로 finally가 실행된 후 메서드가 완료된다.
따라서 return이 있다고 해서 finally가 생략되는 것은 아니다.
이는 예외가 발생해 제어 흐름이 이동하는 경우에도 마찬가지다.
다만 프로세스가 강제로 종료되는 등 일부 비정상적인 상황에서는 finally 실행이 보장되지 않는다.
비동기 예외는 await에서 어떻게 전달될까?
다음과 같은 메서드가 있다고 가정하자.
static async Task<int> GetGoldAsync()
{
try
{
await Task.Delay(100);
throw new InvalidOperationException();
}
finally
{
Console.WriteLine("정리 작업");
}
}
예외가 발생하면 finally가 실행된다.
이후 예외가 처리되지 않은 상태로 메서드 밖으로 전파되면 반환된 Task는 Faulted 상태가 된다.
호출자는 다음과 같이 예외를 처리할 수 있다.
try
{
int gold = await GetGoldAsync();
Console.WriteLine(gold);
}
catch (InvalidOperationException)
{
Console.WriteLine("작업 실패");
}
await GetGoldAsync()에서 예외가 전파되므로 바로 아래의 Console.WriteLine(gold)는 실행되지 않고 catch로 이동한다.
return과 throw의 차이
이번 복습에서 throw를 예외 객체를 반환하는 것처럼 표현한 적이 있었다.
하지만 return은 정상적인 반환 흐름이고, throw는 예외를 발생시키거나 전파하는 동작이다.
catch 내부에서 throw;를 사용하면 현재 처리 중인 예외를 다시 던진다.
게임 서버에서는 요청 취소, DB 장애, 잘못된 요청 등 예외 상황에 따라 적절한 처리 정책이 필요하다.
5. 게임 서버 DB — 복합 인덱스와 Keyset Pagination
PostgreSQL에서 조회 성능을 개선하려면 WHERE 조건뿐 아니라 ORDER BY와 LIMIT도 함께 고려해야 한다.
최근 구매 기록 20개 조회
다음과 같은 테이블이 있다고 가정하자.
CREATE TABLE purchases (
id BIGINT PRIMARY KEY,
user_id BIGINT NOT NULL,
purchased_at TIMESTAMP NOT NULL
);
플레이어 한 명의 최근 구매 기록을 조회한다.
SELECT *
FROM purchases
WHERE user_id = 100
ORDER BY purchased_at DESC
LIMIT 20;
이번에는 다음과 같이 인덱스를 구성할 수 있다.
CREATE INDEX idx_user_purchased
ON purchases (user_id, purchased_at DESC);
user_id로 특정 플레이어의 구매 기록 범위를 찾고, purchased_at 기준으로 최신 기록부터 접근하도록 도움을 줄 수 있다.
중요한 것은 인덱스 컬럼의 순서를 무조건 고유값의 개수만으로 결정하지 않는다는 것이다.
WHERE의 동등 조건과 ORDER BY에서 요구하는 정렬 순서를 함께 고려해야 한다.
PostgreSQL B-Tree는 역방향 인덱스 스캔도 지원하므로 이 쿼리에서는 purchased_at ASC 인덱스도 활용할 수 있다.
OFFSET Pagination의 한계
많은 페이지를 건너뛰려면 다음과 같이 사용할 수 있다.
SELECT *
FROM purchases
WHERE user_id = 100
ORDER BY purchased_at DESC
LIMIT 20 OFFSET 100000;
하지만 OFFSET이 커지면 건너뛰는 행도 처리해야 하므로 비용이 증가할 수 있다.
이러한 상황에서는 Keyset Pagination을 고려할 수 있다.
Keyset Pagination의 원리
Keyset Pagination은 이전 페이지의 마지막 정렬 키를 기준으로 다음 페이지를 조회한다.
예를 들어 최근 구매 기록부터 정렬하고, 이전 페이지의 마지막 구매 시각이 다음과 같다고 가정하자.
2026-11-05 15:00:00
모든 구매 시각이 서로 다르다는 전제라면 다음 페이지를 조회하는 조건은 다음과 같다.
SELECT *
FROM purchases
WHERE user_id = 100
AND purchased_at < TIMESTAMP '2026-11-05 15:00:00'
ORDER BY purchased_at DESC
LIMIT 20;
내림차순에서는 마지막 기록보다 오래된 시각을 조회해야 하므로 <를 사용한다.
반대로 오름차순에서 다음 페이지를 조회하려면 >를 사용한다.
이번 복습에서 처음에는 비교 연산자의 방향을 반대로 작성했지만, 정렬 방향을 바꾼 추가 질문에서는 정확하게 답변했다.
구매 시각이 같다면 어떻게 할까?
실제 서비스에서는 여러 구매 기록의 purchased_at 값이 같을 수 있다.
이 경우 구매 시각만으로 페이지를 구분하면 일부 데이터가 누락될 수 있다.
따라서 고유한 id를 추가하여 정렬 순서를 결정하는 방법을 사용할 수 있다.
CREATE INDEX idx_purchase_page
ON purchases (user_id, purchased_at DESC, id DESC);
페이지 조회에는 다음과 같은 복합 정렬을 사용할 수 있다.
SELECT *
FROM purchases
WHERE user_id = 100
AND (purchased_at, id)
< (TIMESTAMP '2026-11-05 15:00:00', 5000)
ORDER BY purchased_at DESC, id DESC
LIMIT 20;
여기서 5000은 예시로 가정한 마지막 구매 기록의 ID다.
실제 서비스에서는 이전 페이지의 마지막 행에서 구매 시각과 ID를 함께 커서로 전달해야 한다.
이 방식은 동일한 구매 시각이 존재하는 경우에도 안정적인 정렬 기준을 제공한다. 다만 조회 도중 데이터가 추가·삭제되는 상황까지 포함하여 페이지의 일관성을 어떻게 유지할지는 별도로 고려해야 한다.
오늘 새롭게 알게 된 점
- 최소 힙에서는 부모와 자식 사이의 우선순위 조건이 중요하며, .NET PriorityQueue는 4진 최소 힙을 사용한다.
- 가변 Sliding Window는 중첩 반복문이더라도 두 포인터가 앞으로만 이동하면 O(N)으로 처리할 수 있다.
- Observer 패턴은 객체 생성 자체를 없애는 것이 아니라 발행자와 구독자 사이의 직접 의존성을 줄인다.
- finally는 일반적인 return 및 예외 전파 과정에서도 실행된다.
- 비동기 Task의 Faulted 상태와 await에서의 예외 전파를 구분해야 한다.
- 복합 인덱스는 WHERE 조건과 ORDER BY 순서를 함께 고려하여 설계한다.
- Keyset Pagination에서는 정렬 방향에 따라 비교 연산자가 달라진다.
추가로 복습할 내용
- 가변 Sliding Window 전체 C# 코드의 독립 구현
- left, right 구간 길이 계산과 경계 조건
- Observer의 이벤트 예외 처리와 트랜잭션 정합성
- 비동기 예외 처리 미들웨어 및 CancellationToken
- CREATE INDEX SQL 문법
- Keyset Pagination의 복합 커서 SQL 직접 작성
- EXPLAIN ANALYZE를 이용한 실제 실행 계획 비교
오늘의 가장 큰 과제는 개념 설명에 그치지 않고, 실제 코드를 처음부터 정확하게 작성하는 능력을 기르는 것이다.
다음 복습에서는 Sliding Window와 Keyset Pagination을 힌트 없이 직접 구현해 보고 싶다.
모든 C# 코드와 SQL은 학습용 예시이며, 별도의 컴파일·실행·성능 측정은 수행하지 않았다. 실제 회사의 소스 코드나 내부 데이터는 포함하지 않았다.
