Day 5 — 오늘 배운 게임 서버 개발 지식 5가지

학습일: 2026년 11월 5일
복습일: 2026년 11월 6일
학습 주제: HashSet, Sliding Window, Singleton과 DI, CancellationToken, PostgreSQL 복합 인덱스

오늘은 C#의 HashSet과 알고리즘의 Sliding Window, ASP.NET Core의 DI 수명과 CancellationToken, PostgreSQL의 복합 인덱스를 공부했다.

이번 학습에서 특히 중요하게 느낀 부분은 자료구조나 기능의 사용 방법만 아는 것이 아니라, 내부에서 어떻게 동작하고 어떤 문제가 발생할 수 있는지 알아야 한다는 것이다.

1. 자료구조 — HashSet과 Dictionary의 차이

C#의 HashSet<T>는 중복되지 않는 값을 관리하는 해시 기반 자료구조다.

Dictionary<TKey, TValue>는 Key와 Value를 함께 저장하지만, HashSet은 값 자체의 중복 여부를 관리하는 데 적합하다.

HashSet은 중복을 어떻게 판단할까?

var players = new HashSet<string>();

players.Add("PlayerA"); // true
players.Add("PlayerA"); // false

같은 값을 다시 추가하려고 하면 Add()는 false를 반환한다.

그렇다면 서로 다른 두 값의 해시값이 우연히 같으면 어떻게 될까?

HashSet은 해시값만으로 중복을 판단하지 않는다.

내부적으로 해시값을 이용해 해당 버킷의 엔트리들을 찾고, 필요할 때 EqualityComparer<T>를 이용해 실제 값의 동등성을 비교한다.

따라서 "PlayerA"와 "PlayerB"의 해시값이 충돌하더라도 실제 값이 다르다면 둘 다 저장할 수 있다.

시간 복잡도

연산평균최악

평균적으로 조회와 중복 검사가 빠르기 때문에 게임 서버에서 이벤트 참여자 관리, 이미 처리한 식별자 확인 등에 활용할 수 있다.

다만 실제 결제나 재화 지급의 중복 처리는 메모리의 HashSet만으로 보장할 수 없다. 서버 재시작, 다중 인스턴스, 동시 요청 등을 고려해 DB의 고유 제약이나 영속적인 멱등성 처리도 필요하다.

2. 알고리즘 — Sliding Window와 최대 구간 합

Sliding Window는 연속된 구간을 이동하면서 필요한 계산 결과를 효율적으로 갱신하는 방법이다.

예를 들어 배열에서 연속된 K개 요소의 최대 합을 구한다고 가정하자.

int[] numbers = { -5, -2, -8, -1, -4 };
int k = 3;

가능한 구간의 합은 다음과 같다.

구간합

최대 합은 -11이다.

구간의 합을 매번 다시 계산할 필요가 없는 이유

이전 구간의 합에서 가장 왼쪽 값을 빼고, 새로 들어오는 오른쪽 값을 더하면 다음 구간의 합을 계산할 수 있다.

다음 구간 합
= 이전 구간 합 - 빠지는 값 + 새로 들어오는 값

첫 구간의 합을 구하는 데 O(K), 이후 구간을 이동하는 데 O(N-K)가 필요하므로 전체 시간 복잡도는 O(N)이다.

음수 배열에서 주의할 점

처음에는 최대 합을 다음과 같이 초기화했다.

int max = 0;

하지만 모든 구간의 합이 음수라면 결과가 잘못될 수 있다.

따라서 첫 번째 구간의 합을 계산한 뒤 해당 값으로 최댓값을 초기화해야 한다.

다음은 일반적인 고정 길이 Sliding Window 예시다.

static long MaxWindowSum(int[] numbers, int k)
{
    ArgumentNullException.ThrowIfNull(numbers);

    if (k < 1 || k > numbers.Length)
        throw new ArgumentOutOfRangeException(nameof(k));

    long sum = 0;

    for (int i = 0; i < k; i++)
        sum += numbers[i];

    long max = sum;

    for (int i = k; i < numbers.Length; i++)
    {
        sum -= numbers[i - k];
        sum += numbers[i];

        max = Math.Max(max, sum);
    }

    return max;
}

이 코드의 핵심은 초기 구간도 최댓값 후보에 포함하고, 이후에는 한 번에 두 요소만 이용해 합을 갱신한다는 점이다.

3. 디자인 패턴 — Singleton과 ASP.NET Core DI 수명

Singleton 패턴은 하나의 인스턴스를 만들어 여러 곳에서 공유하는 설계 패턴이다.

하지만 ASP.NET Core의 DI 컨테이너에는 Singleton 외에도 Scoped와 Transient라는 서비스 수명이 있다.

세 가지 수명의 차이

수명생성 및 재사용 기준

일반적인 ASP.NET Core HTTP 요청에서는 요청마다 Scope가 생성된다.

따라서 Scoped 서비스는 요청 A와 요청 B에서 각각 다른 인스턴스를 사용한다.

Singleton이 Scoped DbContext를 주입받으면?

다음과 같은 상황을 생각해 보자.

builder.Services.AddSingleton<GameService>();
builder.Services.AddDbContext<GameDbContext>();

AddDbContext는 기본적으로 DbContext를 Scoped 수명으로 등록한다.

그런데 Singleton인 GameService가 생성자에서 GameDbContext를 주입받는다면 수명 불일치가 발생한다.

Scoped 객체를 수명이 긴 Singleton이 붙잡게 되는 문제를 Captive Dependency라고 한다.

ASP.NET Core에서 Scope 검증이 활성화되어 있다면 이러한 잘못된 의존성은 예외로 감지될 수 있다.

반대로 검증 없이 허용되면 DbContext가 의도보다 오래 유지되어 여러 요청 사이에 공유될 위험이 있다.

DbContext는 스레드 안전하지 않기 때문에 이러한 구조는 특히 위험하다.

서버 전체에서 공유해야 할 특별한 상태가 없는 일반적인 요청 처리 서비스라면 다음과 같은 등록이 적절할 수 있다.

builder.Services.AddScoped<GameService>();
builder.Services.AddDbContext<GameDbContext>();

이렇게 하면 일반적인 HTTP 요청에서 두 서비스가 같은 요청 Scope에 속하고, 다른 요청에서는 별도 인스턴스를 사용할 수 있다.

단, Singleton이 정말 필요한 서비스라면 별도의 Scope 생성이나 IDbContextFactory<TContext>와 같은 대안도 검토할 수 있다.

Singleton은 스레드 안전할까?

Singleton은 인스턴스 공유를 의미할 뿐, 스레드 안전성을 자동으로 보장하지 않는다.

여러 요청이 공유 상태에 동시에 접근한다면 Race Condition이 발생하지 않도록 별도 동기화가 필요하다.

4. C# 게임 서버 — CancellationToken과 비동기 예외 처리

CancellationToken은 비동기 작업을 강제로 종료하는 기능이 아니다.

취소 요청을 작업에 전달하고, 작업이 이를 확인하여 협력적으로 중단하도록 만드는 구조다.

ASP.NET Core에서는 클라이언트 연결 종료 등의 상황을 HttpContext.RequestAborted를 통해 확인할 수 있다.

Minimal API의 CancellationToken 매개변수도 요청 취소 토큰을 전달받을 수 있다.

CancellationToken은 하위 작업까지 전달해야 한다

app.MapGet("/player/{id}", async (
    long id,
    CancellationToken ct,
    PlayerService service) =>
{
    var player = await service.GetPlayerAsync(id, ct);

    return Results.Ok(player);
});

GetPlayerAsync()가 비동기 DB 조회를 수행한다면 내부 DB API까지 토큰을 전달하는 것이 중요하다.

그렇지 않으면 클라이언트의 요청이 취소되었더라도 서버의 DB 작업은 계속 진행될 수 있다.

단, 토큰을 전달했다고 모든 DB 작업이 반드시 즉시 취소되는 것은 아니다.

catch와 throw의 차이

이번 복습에서 헷갈렸던 부분은 취소 예외를 처리한 이후의 실행 흐름이었다.

다음 코드를 보자.

try
{
    await Task.Delay(5000, ct);
}
catch (OperationCanceledException)
{
    Console.WriteLine("취소됨");
}

Console.WriteLine("다음 작업");

취소 예외가 발생해 catch에서 처리되고 다시 던지지 않는다면, 예외 처리 이후의 코드도 계속 실행될 수 있다.

반면 다음 코드는 다르다.

catch (OperationCanceledException)
{
    Console.WriteLine("취소됨");
    throw;
}

throw;는 현재 예외를 다시 던진다.

따라서 상위 호출자가 await하는 지점까지 예외가 전달될 수 있다.

중요한 것은 throw;는 return과 다르다는 점이다.

취소 예외를 처리하고 정상적으로 종료하면 반환 Task가 정상 완료 상태가 될 수 있고, 예외를 전파하면 호출자가 취소를 인식하고 처리할 수 있다.

취소와 DB 장애는 서로 다른 상황이므로 운영 로그 및 예외 처리 정책에서도 구분해야 한다.

5. 게임 서버 DB — 복합 인덱스와 EXPLAIN ANALYZE

PostgreSQL에서 복합 인덱스는 여러 컬럼을 하나의 인덱스로 관리하는 방식이다.

예를 들어 게임 서버에 다음 테이블과 인덱스가 있다고 가정하자.

CREATE TABLE player_items (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    status INT NOT NULL
);

CREATE INDEX idx_user_status
ON player_items(user_id, status);

복합 인덱스의 컬럼 순서

(user_id, status) 복합 B-Tree 인덱스는 먼저 user_id를 기준으로 정렬되고, 같은 user_id 안에서 status를 기준으로 정렬된다.

따라서 다음 세 조회 조건의 효율이 달라질 수 있다.

-- A
SELECT * FROM player_items
WHERE user_id = 100;

-- B
SELECT * FROM player_items
WHERE status = 1;

-- C
SELECT * FROM player_items
WHERE user_id = 100 AND status = 1;

일반적으로 A는 선행 컬럼인 user_id를 이용해 범위를 좁힐 수 있다.

C는 두 컬럼 조건을 모두 이용해 탐색 범위를 더 좁힐 수 있다.

반면 B는 선행 컬럼 조건이 없으므로 일반적으로 불리하다.

단, PostgreSQL 18에는 Skip Scan 최적화가 있어 선행 컬럼 조건이 없더라도 데이터 분포와 비용에 따라 복합 인덱스가 활용될 수 있다.

따라서 복합 인덱스의 선행 컬럼 규칙은 중요하지만, 특정 조건에서 인덱스를 절대로 사용할 수 없다고 단정해서는 안 된다.

EXPLAIN ANALYZE는 무엇을 확인할까?

EXPLAIN은 PostgreSQL이 선택한 실행 계획과 예상 비용·행 수 등을 보여준다.

EXPLAIN ANALYZE는 SQL을 실제 실행하여 실행 시간과 실제 처리 행 수 등을 보여준다.

EXPLAIN ANALYZE
SELECT *
FROM player_items
WHERE user_id = 100
  AND status = 1;

이 결과에서는 예상 행 수와 실제 행 수를 비교하고, 실행 계획이 Index Scan, Seq Scan 등 어떤 방식을 사용했는지 확인할 수 있다.

예상 행 수와 실제 행 수가 크게 다르다면 통계 정보나 데이터 분포 등을 살펴볼 필요가 있다.

다만 EXPLAIN ANALYZE는 실제 쿼리를 실행하므로, 운영 DB에서 변경 SQL을 분석할 때는 특히 주의해야 한다.

이번 복습에서는 복합 인덱스의 선행 컬럼 원리를 직접 다시 설명했다. EXPLAIN ANALYZE를 실제 실행하여 분석하는 실습은 별도로 진행할 예정이다.

오늘 새롭게 알게 된 점

1. HashSet은 해시값이 충돌하더라도 실제 값이 다르면 중복으로 판단하지 않는다.
2. Sliding Window에서는 첫 구간의 합으로 최댓값을 초기화해야 음수 배열도 정확하게 처리할 수 있다.
3. Singleton이 Scoped 객체를 오래 참조하면 DI 수명 문제가 발생할 수 있다.
4. catch에서 throw;를 실행하면 정상 반환이 아니라 예외가 다시 전파된다.
5. CancellationToken은 하위 비동기 작업까지 전달해야 취소 요청을 활용할 수 있다.
6. 복합 인덱스는 컬럼 순서가 중요하며 선행 컬럼만으로도 효율적인 탐색이 가능하다.

추가로 복습할 내용

• HashSet과 Dictionary의 내부 구조 및 사용 기준
• 가변 길이 Sliding Window 문제
• Singleton의 스레드 안전성과 Scoped 의존성 관리
• CancellationToken과 예외 전파의 실행 순서
• PostgreSQL 복합 인덱스의 범위 조건 및 ORDER BY 최적화
• EXPLAIN ANALYZE를 통한 실제 실행 계획 분석

오늘도 복습 중 잘못 이해한 부분이 발견되었다.

특히 DI 서비스 수명, throw;의 동작, 복합 인덱스 컬럼 순서는 처음부터 완전히 설명하지 못했다.

하지만 추가 질문을 통해 원리를 다시 이해하고 설명할 수 있었다.

앞으로도 외운 정답보다 왜 그렇게 동작하는지 설명할 수 있는 능력을 기르는 데 집중하려고 한다.

이 글의 C#과 SQL 예시는 학습용이다. 별도의 코드 실행, DB 쿼리 실행, 성능 측정 결과는 포함하지 않았다. 게임 서버 사례는 모두 일반화한 가상 상황이다.

Day 4 — 오늘 배운 게임 서버 개발 지식 5가지

학습일: 2026년 11월 4일
학습 주제: LinkedList, A* 알고리즘, 디자인 패턴, ASP.NET Core, PostgreSQL 인덱스

오늘은 자료구조의 내부 동작부터 게임 서버의 HTTP 요청 처리와 데이터베이스 인덱스까지 복습했다.

이번 학습에서 특히 기억에 남은 것은 시간 복잡도가 낮다고 무조건 좋은 자료구조는 아니며, 특정 기능을 사용할 때 내부적으로 어떤 과정이 일어나는지 알아야 한다는 점이다.

1. 자료구조 — LinkedList<T>는 왜 삽입과 삭제가 빠를까?

C#의 LinkedList<T>는 각 노드가 이전 노드와 다음 노드를 참조하는 이중 연결 리스트다.

각 노드는 크게 다음 정보를 가진다.

• Value: 저장하는 데이터
• Previous: 이전 노드에 대한 참조
• Next: 다음 노드에 대한 참조

노드 참조가 있다면 삭제는 O(1)

예를 들어 A, B, C 노드가 순서대로 연결되어 있다고 가정하자.

A ⇄ B ⇄ C

B 노드를 삭제하려면 A의 다음 노드를 C로, C의 이전 노드를 A로 연결하도록 변경하면 된다.

A ⇄ C

이때 B 노드의 참조를 이미 알고 있다면 전체 리스트를 탐색할 필요가 없으므로 O(1)에 삭제할 수 있다.

하지만 삭제하려는 값만 알고 있다면 이야기가 달라진다.

원하는 값이 저장된 노드를 처음부터 찾아야 하므로 최악 O(n)이 발생한다. 노드를 찾은 이후의 삭제는 O(1)이지만, 전체 작업은 O(n)이다.

그렇다면 List보다 LinkedList가 항상 좋을까?

그렇지 않다.

List<T>는 연속적인 배열에 데이터를 저장하므로 인덱스로 접근하는 작업에 강점이 있다. 반면 LinkedList<T>는 노드를 순서대로 따라가야 하며 인덱스 기반 임의 접근을 제공하지 않는다.

또한 LinkedList는 각 노드의 참조와 객체 관리 비용이 추가되고, 노드들이 메모리에 흩어져 있을 수 있어 CPU 캐시 효율도 불리할 수 있다.

따라서 삽입·삭제 O(1)이라는 사실만으로 LinkedList를 선택하면 안 된다.

게임 서버에서도 노드 참조를 유지하면서 빈번하게 요소를 제거하는 구조인지, 아니면 전체 순회나 인덱스 접근이 많은지 고려해야 한다.

2. 알고리즘 — BFS, 다익스트라, A* 그리고 휴리스틱

세 알고리즘은 경로를 탐색한다는 공통점이 있지만, 다음에 탐색할 노드를 선택하는 기준이 다르다.

알고리즘주요 탐색 기준대표적인 사용 조건

다익스트라는 현재까지 누적된 이동 비용이 가장 작은 노드를 우선 탐색한다.

A*는 여기에 목적지까지의 추정 비용을 추가하여 탐색 우선순위를 결정한다.

A*의 허용성(Admissibility)

허용성은 휴리스틱이 실제 남은 최단 비용을 과대평가하지 않는 조건이다.

h(n) <= h*(n)

• h(n): 휴리스틱으로 추정한 남은 비용
• h*(n): 해당 노드에서 목적지까지 실제 최단 비용

예를 들어 A에서 G까지 세 경로가 있다고 가정하자.

경로비용

A에서 G까지 실제 최단 비용은 5다.

따라서 h(A) = 6이라면 허용성을 만족하지 않는다.

반대로 h(A) = 5라면 정확히 실제 최단 비용과 같기 때문에 허용성을 만족한다.

처음에는 실제 최단 비용보다 반드시 작아야 한다고 생각했지만, 등호도 허용된다는 점을 다시 확인했다.

일관성(Consistency)은 무엇이 다를까?

일관성은 인접 노드 사이에서 다음 조건을 만족하는 것이다.

h(u) <= c(u, v) + h(v)

c(u, v)는 u에서 v까지 이동하는 비용이다.

일관성이 성립하면 경로를 따라 이동하면서 A*의 f(n) 값이 감소하지 않는다.

일관성이 깨진 경우에는 이미 탐색을 완료한 노드에 대해 나중에 더 저렴한 경로가 발견될 수 있다.

따라서 탐색 완료 노드를 다시 열지 않는 구현에서는 최단 경로를 놓칠 위험이 있다.

허용성과 일관성은 서로 다른 조건이며, 최단 경로를 보장하려면 휴리스틱의 성질뿐 아니라 알고리즘 구현 방식도 함께 고려해야 한다.

3. 디자인 패턴 — Strategy와 Factory Method의 실행 원리

오늘은 패턴의 목적뿐 아니라 실제 메서드가 어떤 과정을 거쳐 호출되는지도 복습했다.

Strategy 패턴

Strategy 패턴은 공통 인터페이스를 통해 서로 다른 동작을 교체하는 방식이다.

예를 들어 게임 캐릭터의 공격 방식을 변경한다고 가정하자.

public interface IAttackStrategy
{
    void Attack();
}

public class BowAttack : IAttackStrategy
{
    public void Attack()
    {
        Console.WriteLine("활 공격");
    }
}

public class Player
{
    private readonly IAttackStrategy _strategy;

    public Player(IAttackStrategy strategy)
    {
        _strategy = strategy;
    }

    public void Attack()
    {
        _strategy.Attack();
    }
}

호출 코드는 다음과 같다.

Player player = new Player(new BowAttack());
player.Attack();

new BowAttack()으로 객체를 생성하고 그 객체의 참조를 Player 생성자에 전달한다.

생성자는 해당 참조를 인터페이스 타입 필드인 _strategy에 저장한다.

player.Attack()을 호출하면 내부의 _strategy.Attack()이 실행되며, 실제 참조하는 객체 타입에 따라 BowAttack.Attack()이 선택된다.

이것이 인터페이스를 통한 다형성 호출이다.

중요한 점은 인터페이스를 구현하는 것과 클래스의 메서드를 override하는 것은 다르다는 것이다.

Factory Method 패턴

Factory Method는 객체 생성 메서드를 상위 클래스에 선언하고, 하위 클래스에서 구체적인 객체 생성 방식을 결정하도록 하는 패턴이다.

예를 들어 상위 클래스인 MonsterFactory가 Spawn()을 제공하고, 그 안에서 추상 메서드 CreateMonster()를 호출할 수 있다.

SlimeFactory가 CreateMonster()를 override했다면 실제 객체가 SlimeFactory일 때 해당 자식 클래스의 메서드가 실행된다.

실행 흐름은 다음과 같다.

MonsterFactory.Spawn()
        ↓
SlimeFactory.CreateMonster()
        ↓
new Slime()
        ↓
monster.Appear()

여기서 부모 클래스의 Spawn()이 실행되더라도 내부에서 호출하는 가상 메서드는 실제 객체 타입에 따라 선택된다.

언제 어떤 패턴을 사용할까?

• Strategy: 서로 다른 처리 방식을 실행 중 교체하고 싶을 때
• Simple Factory: 객체 생성 로직을 간단히 한곳에 모으고 싶을 때
• Factory Method: 하위 클래스마다 구체적인 객체 생성 방식을 다르게 결정하고 싶을 때

단순한 생성 로직에 불필요한 상속 구조를 추가하면 복잡도만 증가할 수 있다.

따라서 디자인 패턴도 유지보수성과 변경 가능성을 기준으로 선택해야 한다.

4. C# 게임 서버 — ThreadPool과 ASP.NET Core 요청 처리

ASP.NET Core는 일반적으로 ThreadPool의 작업자 스레드를 이용해 애플리케이션의 요청 처리 코드를 실행한다.

그렇다면 하나의 HTTP 요청에서 Thread.Sleep()을 사용하면 다른 요청도 모두 기다려야 할까?

그렇지는 않다.

Thread.Sleep이 차단하는 대상

다음과 같은 두 API가 있다고 가정하자.

app.MapGet("/slow", () =>
{
    Thread.Sleep(5000);
    return Results.Ok("Slow 완료");
});

app.MapGet("/fast", () =>
{
    return Results.Ok("Fast 완료");
});

/slow 요청이 실행되는 동안 Thread.Sleep(5000)은 그 코드를 실행 중인 작업자 스레드를 차단한다.

그러나 ThreadPool에 다른 가용 스레드가 있다면 /fast 요청은 별도로 처리될 수 있다.

즉, 한 요청에서 Thread.Sleep을 실행한다고 다른 모든 요청이 반드시 기다리는 것은 아니다.

ThreadPool Starvation은 언제 발생할까?

차단 작업이 많아지면 사용 가능한 ThreadPool 작업자 스레드가 부족해질 수 있다.

ThreadPool은 필요에 따라 작업자 스레드를 추가하지만, 요청이 계속 쌓여 필요한 작업을 제때 처리하지 못하면 응답 지연이 발생한다.

이것이 ThreadPool Starvation이다.

단순히 동시 요청 수가 현재 스레드 수보다 많다는 이유만으로 Starvation이라고 판단해서는 안 된다.

특히 비동기 I/O를 사용하는 경우에는 요청이 대기하는 동안 스레드를 계속 점유할 필요가 없기 때문이다.

Task.Run은 CPU 연산을 빠르게 만들지 않는다

Task.Run()은 작업을 ThreadPool에 예약한다.

ASP.NET Core에서 이미 ThreadPool 스레드로 수행 중인 짧은 CPU 계산을 Task.Run()으로 감싸면 불필요한 스케줄링 비용이 발생할 수 있다.

반면 실제 비동기 DB·네트워크 작업은 미완료 Task를 await하는 동안 스레드가 다른 작업을 처리할 수 있도록 할 수 있다.

따라서 CPU 연산과 비동기 I/O, 차단 작업의 차이를 이해하고 코드를 작성해야 한다.

5. 게임 서버 DB — PostgreSQL B-Tree 인덱스와 EXPLAIN

오늘 가장 확실하게 새롭게 이해한 개념은 인덱스가 실제 테이블의 모든 컬럼 값을 저장하는 것은 아니라는 점이다.

B-Tree 인덱스의 탐색 원리

B-Tree 인덱스는 정렬된 키를 계층적으로 관리한다.

따라서 데이터를 순차적으로 모두 확인하지 않고, 각 단계에서 탐색 범위를 좁혀 원하는 키를 찾을 수 있다.

다음 테이블을 살펴보자.

CREATE TABLE players (
    id BIGINT PRIMARY KEY,
    nickname VARCHAR(50),
    gold INT
);

PostgreSQL에서는 기본 키 제약 조건을 생성할 때 이를 지원하는 고유 B-Tree 인덱스가 기본적으로 생성된다.

다음 쿼리를 실행한다고 가정하자.

SELECT *
FROM players
WHERE id = 500000;

PostgreSQL이 일반적인 Index Scan을 선택했다면, 인덱스에서 id를 찾고 해당 엔트리의 TID를 이용해 실제 테이블 행에 접근한다.

TID와 Heap은 무엇일까?

PostgreSQL에서 일반적인 테이블 데이터는 Heap에 저장된다.

인덱스는 검색 키와 테이블 행을 찾는 데 필요한 위치 정보 등을 관리한다.

일반적인 Index Scan의 처리 과정은 다음과 같다.

B-Tree 인덱스 탐색
       ↓
id = 500000 검색
       ↓
TID 확인
       ↓
Heap에서 대상 행 접근
       ↓
nickname, gold 등 필요한 컬럼 조회

처음에는 nickname과 gold까지 인덱스에 저장되어 있다고 생각했다.

하지만 id만을 대상으로 하는 일반적인 인덱스에는 해당 컬럼들이 자동으로 저장되지 않는다.

따라서 실제 컬럼 값을 읽기 위해 Heap에 접근할 수 있다.

단, 필요한 컬럼이 인덱스에 포함되어 있고 MVCC 가시성 조건을 만족하면 Index Only Scan으로 Heap 접근을 생략할 수 있는 경우도 있다.

인덱스가 있어도 Seq Scan을 사용하는 이유

PostgreSQL은 인덱스가 존재한다는 사실만으로 항상 Index Scan을 선택하지 않는다.

예를 들어 gold 컬럼에 인덱스가 있다고 가정하자.

SELECT *
FROM players
WHERE gold = 999999;

결과가 극소수의 행이라면 Index Scan이 유리할 수 있다.

반면 다음 쿼리는 다르다.

SELECT *
FROM players
WHERE gold >= 0;

대부분의 플레이어가 해당 조건을 만족한다면 테이블 전체를 순차적으로 읽는 Seq Scan이 더 효율적일 수 있다.

이는 인덱스를 통한 많은 Heap 접근보다 순차적인 읽기가 더 저렴할 수 있기 때문이다.

다만 실제 선택은 테이블 크기와 통계 정보, 예상 비용 등 여러 조건에 따라 결정된다.

EXPLAIN으로 실행 계획 확인하기

EXPLAIN
SELECT *
FROM players
WHERE gold >= 0;

EXPLAIN은 PostgreSQL이 선택한 실행 계획과 예상 비용·행 수 등을 보여준다.

실제 실행 시간과 행 수를 조사하려면 EXPLAIN ANALYZE를 사용할 수 있다. 이때 대상 SQL이 실제 실행된다는 점에 주의해야 한다.

게임 서버에서도 조회가 느리다는 이유만으로 인덱스를 무조건 추가하기보다, 실행 계획을 확인하고 병목 원인을 파악하는 것이 중요하다.

오늘 새롭게 알게 된 점

1. LinkedList는 삭제할 노드 참조를 알고 있을 때 O(1)이지만, 노드 탐색이 필요하면 전체 O(n)이 발생한다.
2. A*의 허용성 조건은 실제 최단 비용과 같은 값도 허용하며, 일관성과는 다른 조건이다.
3. Strategy의 인터페이스 구현과 Factory Method의 override 호출은 서로 다른 구조다.
4. Thread.Sleep은 실행 중인 작업자 스레드를 차단하지만 다른 요청이 모두 차단되는 것은 아니다.
5. PostgreSQL에서는 인덱스로 TID를 찾고 실제 Heap에서 필요한 컬럼을 가져올 수 있다.
6. 인덱스가 있어도 예상 비용에 따라 Seq Scan이 선택될 수 있다.

추가로 복습할 내용

• LinkedList와 List의 실제 선택 기준
• A* 허용성·일관성의 차이와 최단 경로 보장 조건
• 인터페이스 구현과 override 메서드의 실행 흐름
• ThreadPool Starvation이 발생하는 조건
• B-Tree 인덱스, Heap 접근 및 Index Only Scan
• EXPLAIN ANALYZE를 통한 실제 실행 계획 분석

오늘은 개념을 기억하는 것뿐 아니라, 실제 내부 동작을 설명해 보는 것이 이해도를 확인하는 데 중요하다는 것을 느꼈다.

특히 PostgreSQL의 인덱스처럼 사용법은 알고 있어도 내부 원리를 정확히 이해하지 못한 부분이 있었다.

앞으로도 이러한 차이를 하나씩 줄여가며 게임 서버 개발에 필요한 기본기를 강화하려고 한다.

이 글의 코드는 학습용 예시이며 실제 실행, 성능 측정, 부하 테스트 결과를 포함하지 않는다. 모든 게임 서버 사례는 가상의 예시다.

Day 3 — 오늘 배운 게임 서버 개발 지식 5가지

학습일: 2026년 11월 3일
학습 주제: 자료구조 · 알고리즘 · 디자인 패턴 · C# 게임 서버 · PostgreSQL

오늘은 Stack과 Queue의 내부 구조부터 탐색 알고리즘, Factory 패턴, ASP.NET Core의 스레드 처리, PostgreSQL의 데드락까지 복습했다.

학습하면서 가장 중요하게 느낀 것은 단순히 기능을 사용하는 방법보다 내부에서 어떤 일이 발생하고, 왜 그 방식을 선택해야 하는지 이해하는 것이다.

1. 자료구조 — Stack과 Queue의 내부 원리

Stack과 Queue는 모두 데이터를 저장하는 자료구조이지만, 데이터를 꺼내는 순서가 다르다.

• Stack: LIFO(Last In, First Out). 마지막에 들어온 데이터가 먼저 나온다.
• Queue: FIFO(First In, First Out). 먼저 들어온 데이터가 먼저 나온다.

C#의 Stack<T>와 Queue<T>는 내부적으로 배열을 사용한다.

Queue는 왜 Dequeue할 때 데이터를 이동하지 않을까?

처음에는 Queue의 맨 앞 요소를 제거하면 나머지 요소들이 모두 앞으로 이동해야 하는지 궁금했다.

하지만 Queue<T>는 원형 배열(Circular Buffer)을 사용한다.

배열의 맨 앞에 있는 요소를 제거할 때 나머지 데이터들을 이동시키는 대신, 맨 앞을 가리키는 인덱스를 다음 위치로 이동시킨다.

마지막 인덱스에 도달하면 다시 배열의 처음으로 돌아가 빈 공간을 재활용할 수 있다.

덕분에 Dequeue()는 O(1)로 동작한다.

Enqueue는 왜 분할 상환 O(1)일까?

Enqueue()는 내부 배열에 여유 공간이 있다면 O(1)이다.

하지만 배열이 가득 찬 경우 더 큰 배열을 할당하고 기존 데이터를 복사해야 하므로 해당 작업은 O(n)이 된다.

그런데 배열 용량을 기하급수적으로 확장하면 전체 복사 작업이 매번 발생하지 않는다.

여러 번의 삽입 작업에 확장 비용을 나누어 계산하면 삽입 한 번당 분할 상환 O(1) 이 된다.

연산시간 복잡도

게임 서버에서는 작업을 순서대로 처리하는 대기열이나 최근 작업부터 되돌리는 처리 등에 활용할 수 있다.

2. 알고리즘 — 탐색 방법과 시간 복잡도

오늘은 순차 탐색, 이진 탐색, Dictionary 기반 탐색을 비교했다.

탐색 방법별 시간 복잡도

탐색 방법최선평균최악

순차 탐색은 첫 번째 데이터가 원하는 값이라면 O(1)이지만, 끝까지 확인해야 할 경우 O(n)이다.

이진 탐색은 정렬된 배열에서 중앙값을 확인하고 탐색 범위를 절반씩 줄인다. 첫 번째 중앙값이 정답이면 O(1)이다.

Dictionary는 해시값을 이용하므로 평균 O(1)에 데이터를 조회할 수 있다. 다만 해시 충돌로 인해 최악에는 O(n)이 발생할 수 있다.

게임 서버에서는 어떤 자료구조를 선택할까?

접속 중인 플레이어를 UserId로 자주 조회하고, 로그인과 로그아웃에 따라 추가하거나 제거해야 한다면 Dictionary<UserId, Player>가 적절할 수 있다.

조회·삽입·삭제 모두 평균 O(1)이기 때문이다.

다만 여러 스레드가 동시에 수정하는 환경이라면 별도의 동기화가 필요하다.

추가 복습 — A* 휴리스틱의 일관성

이번 복습에서 가장 헷갈렸던 부분이다.

A*는 다음 평가 비용을 사용한다.

f(n) = g(n) + h(n)

• g(n): 시작 노드부터 현재 노드까지 누적 비용
• h(n): 현재 노드에서 목적지까지 추정 비용

휴리스틱의 일관성 조건은 다음과 같다.

h(A) <= c(A, B) + h(B)

여기서 c(A, B)는 A에서 B까지의 실제 이동 비용이다.

예를 들어 h(A)=7, c(A,B)=3, h(B)=2라면 다음과 같다.

7 <= 3 + 2

조건을 만족하지 않는다.

일관성 조건을 만족하면 경로를 따라 이동할 때 f(n)이 감소하지 않는 성질이 있다.

반대로 일관성이 깨지면 이미 탐색을 완료한 노드에 대해 나중에 더 저렴한 경로가 발견될 수 있다.

이때 탐색 완료한 노드를 다시 열지 않는 구현은 최단 경로를 놓칠 위험이 있다.

다만 일관성이 없다고 항상 최단 경로를 찾지 못하는 것은 아니다. 휴리스틱의 허용성 등 필요한 조건을 만족하고 노드 재탐색을 올바르게 처리하는 구현이라면 최단 경로를 찾을 수 있다.

3. 디자인 패턴 — Simple Factory와 Factory Method

두 방식 모두 객체 생성과 관련이 있지만 구조가 다르다.

Simple Factory

하나의 팩토리 클래스 또는 메서드에 객체 생성 로직을 모으는 방식이다.

예를 들어 몬스터 종류에 따라 Slime, Goblin, Dragon 객체를 생성하도록 만들 수 있다.

생성할 객체의 종류가 적고 변경 가능성이 낮다면 간단한 Simple Factory로 충분할 수 있다.

Factory Method

Factory Method는 상위 클래스에 객체 생성 메서드를 정의하고, 하위 클래스에서 재정의하여 구체적으로 어떤 객체를 생성할지 결정하는 패턴이다.

즉, 객체 생성 책임을 하위 클래스에 위임한다.

이 방식은 객체 생성 방법이 하위 클래스별로 달라지고 확장 가능성이 높을 때 유용하다.

하지만 몬스터가 세 종류뿐이고 추가될 가능성도 거의 없다면 Factory Method의 상속 구조가 오히려 불필요한 복잡도를 증가시킬 수 있다.

비교Simple FactoryFactory Method

또한 Strategy 패턴과의 차이도 다시 확인했다.

Strategy는 처리 방식의 교체가 중심이고, Factory 계열은 객체 생성 책임의 분리가 중심이다.

디자인 패턴은 무조건 적용하기보다 실제 변경 가능성과 복잡도를 고려해 선택해야 한다.

4. C# 게임 서버 — async와 Task.Run의 차이

async 메서드는 호출한 스레드에서 실행을 시작한다.

미완료된 비동기 작업을 await하면 메서드 실행을 일시 중단하고, 해당 스레드가 다른 작업을 처리할 수 있도록 할 수 있다.

반대로 Task.Run()은 작업을 ThreadPool에 예약한다.

중요한 것은 Task.Run을 사용한다고 CPU 계산 자체가 빨라지는 것은 아니라는 점이다.

ASP.NET Core에서 Task.Run을 주의해야 하는 이유

ASP.NET Core는 기본적으로 ThreadPool 스레드를 이용하여 요청을 처리한다.

이미 ThreadPool 스레드에서 실행 중인 간단한 CPU 작업을 다시 Task.Run()으로 예약하면 불필요한 작업 스케줄링 비용이 발생할 수 있다.

반면 비동기 DB 조회는 성격이 다르다.

Player player = await db.GetPlayerAsync(userId);

실제 비동기 DB I/O가 진행되고 반환된 Task가 아직 완료되지 않았다면, await하는 동안 현재 스레드를 계속 점유할 필요가 없다.

그러나 다음과 같이 차단 작업이 존재하면 문제가 달라진다.

await Task.Run(() =>
{
    Thread.Sleep(5000);
});

Task.Run으로 작업을 예약하더라도 Thread.Sleep을 실행하는 ThreadPool 스레드는 차단된다.

이러한 작업이 많이 발생하면 사용 가능한 ThreadPool 스레드가 부족해지고 요청 처리가 지연될 수 있다.

이를 ThreadPool Starvation이라고 한다.

결국 중요한 것은 CPU 작업인지, 비동기 I/O인지, 스레드를 실제로 차단하는 작업인지 구분하는 것이다.

5. 게임 서버 DB — 데드락과 트랜잭션 재시도

PostgreSQL에서 데드락은 서로 다른 트랜잭션이 상대방이 보유한 잠금을 기다리면서 진행하지 못하는 상황이다.

예를 들어 다음과 같은 상황을 생각할 수 있다.

• 트랜잭션 1: 플레이어 A 잠금 획득 → 플레이어 B 잠금 요청
• 트랜잭션 2: 플레이어 B 잠금 획득 → 플레이어 A 잠금 요청

두 트랜잭션이 각각 첫 번째 잠금을 획득했다면 서로 상대방의 잠금이 해제되기를 기다릴 수 있다.

이는 단순한 잠금 대기가 아니라 순환 대기 관계가 형성된 데드락이다.

데드락을 예방하는 방법

여러 행의 잠금을 획득해야 한다면 모든 트랜잭션에서 잠금 획득 순서를 통일하는 것이 중요하다.

예를 들어 두 플레이어의 PlayerId 중 작은 값을 먼저 잠그도록 규칙을 정할 수 있다.

• 트랜잭션 1: A → B
• 트랜잭션 2: A → B

이렇게 하면 동일한 두 행을 반대 순서로 획득하면서 발생하는 데드락을 예방할 수 있다.

데드락이 이미 발생했다면?

PostgreSQL은 데드락을 감지하면 관련 트랜잭션 중 하나를 중단한다.

이때 실패한 SQL 명령부터 다시 실행하면 안 된다.

새로운 트랜잭션을 시작하고 전체 작업을 다시 처리해야 한다.

예를 들어 게임 서버에서 골드를 이전하는 거래라면 다음 작업이 하나의 트랜잭션에 포함될 수 있다.

1. 현재 골드 잔액 및 거래 조건 확인
2. 보내는 플레이어의 골드 차감
3. 받는 플레이어의 골드 증가
4. 거래 기록 저장
5. 커밋

데드락으로 트랜잭션이 실패했다면 새로운 트랜잭션에서 현재 데이터를 다시 읽고 조건을 재검증해야 한다.

다른 트랜잭션이 데이터를 변경했을 수 있기 때문이다.

또한 무제한 재시도보다는 재시도 횟수를 제한하고, 반복적으로 실패하면 오류 로그를 남겨 원인을 조사하는 것이 적절하다.

필요하다면 짧은 재시도 지연도 적용할 수 있다.

실제 게임 서버에서는 중복 거래 방지와 트랜잭션 밖의 부작용 처리까지 함께 고려해야 한다.

오늘 새롭게 알게 된 점

1. Queue는 원형 배열의 인덱스를 이동시키기 때문에 Dequeue할 때 전체 요소를 이동하지 않는다.
2. 분할 상환 O(1)은 단순히 대부분의 작업이 빠르기 때문만이 아니라, 배열 확장 비용을 여러 작업에 분산할 수 있기 때문에 성립한다.
3. A*에서 일관성이 깨지면 이미 탐색 완료한 노드에 대해 더 저렴한 경로가 나중에 발견될 수 있다.
4. 단순한 객체 생성에는 Factory Method보다 Simple Factory가 적합할 수 있다.
5. ASP.NET Core에서 Task.Run은 CPU 연산 자체를 가속하지 않는다.
6. 데드락 예방에는 잠금 순서 통일이 중요하며, 데드락 이후에는 새로운 트랜잭션에서 데이터를 재검증해야 한다.

추가로 복습할 내용

• Stack과 Queue의 내부 배열 확장 및 분할 상환 복잡도
• A* 휴리스틱의 허용성과 일관성
• Factory Method를 실제 C# 코드로 구현하는 방법
• ASP.NET Core의 비동기 I/O와 ThreadPool Starvation 진단
• PostgreSQL의 데드락 재시도, 잠금 순서, 인덱스 및 실행 계획

이번 학습에서는 개념을 암기하는 것뿐 아니라, 그 개념을 실제 게임 서버에 적용할 때 왜 그런 선택을 해야 하는지 생각해 볼 수 있었다.

다음 학습에서도 내부 동작 원리를 이해하고 실제 코드와 연결하는 방향으로 공부할 예정이다.

이 글의 예시 코드는 학습용으로 작성했으며 실제 실행·성능 측정 결과를 의미하지 않습니다. 게임 서버 예시는 가상 상황이며 회사 내부 구현 정보는 포함하지 않았습니다.