서론 이전 포스트에서 Flow Field 패스파인딩의 개념과 3단계 파이프라인을 다뤘다. Flow Field는 에이전트 수와 무관하게 \(O(V)\) 로 계산되므로, 패스파인딩 자체는 병목이 아니다. 그렇다면 3,000 에이전트에서 프레임이 떨어지는 원인은 무엇인가? 그리고 10,000 에이전트까지 스케일업하려면 무엇을 바꿔야 하는가? 이 포스트...

서론 이전 포스트의 마지막에서 이렇게 예고했다: NativeContainer를 써야 하는 진짜 이유 — GC가 게임에 미치는 영향 이 시리즈에서 우리는 “managed 세계를 벗어나라”는 메시지를 반복적으로 만났다. Job System은 NativeContainer만 허용하고, Burst는 managed 타입을 컴파일하지 않으며, SoA ...

서론 Job System 포스트에서 NativeArray의 내부 구조를 해부했다. C# 배열과의 메모리 모델 차이, Allocator 종류, Safety System의 기본 동작까지 다뤘다. 하지만 실전에서는 NativeArray만으로 모든 것을 해결할 수 없다. 동적 크기의 리스트가 필요하고, 키-값 쌍으로 빠르게 조회해야 하고, 여러 워커 스레...

서론 3,000마리의 좀비가 플레이어를 향해 몰려온다고 상상해보자. 각 좀비에게 개별 경로를 계산해준다면? A* 하나당 수백~수천 노드를 탐색하고, 그것을 3,000번 반복해야 한다. 프레임은 순식간에 바닥을 친다. Flow Field 패스파인딩은 이 문제를 근본적으로 다른 방식으로 접근한다. 개별 에이전트에게 경로를 주는 대신, 공간 전체에 “어...

서론 2018년, Aras Pranckevičius는 ToyPathTracer 벤치마크에서 놀라운 결과를 발표했다. C# Burst가 C++보다 빠른 경우가 존재한다는 것이다 — PC에서 Burst 140 Mray/s vs C++ 136 Mray/s. Aras Pranckevičius, “Pathtracer 16: Burst & SIM...

들어가며 이전 포스트에서 Claude Code의 아키텍처 설계 원리를 분석했다. 이번 글에서는 한 단계 더 깊이 들어가서, 하네스 엔지니어링(Harness Engineering) — 즉 AI 에이전트의 오케스트레이션 계층이 어떤 설계 원리로 구축되는지를 해부한다. “하네스”라는 용어는 원래 테스트 하네스(test harness)에서 온 것으로, 실...

들어가며 Claude Code는 Anthropic이 개발한 CLI 기반 AI 코딩 에이전트다. 터미널에서 직접 코드를 읽고, 수정하고, 빌드하고, 테스트까지 수행하는 에이전트형 도구로, 2025년 이후 빠르게 발전해왔다. 이 글에서는 Claude Code를 오랜 기간 사용하면서 관찰한 동작 패턴, 공식 문서, 그리고 공개된 기술 스택(TypeScr...

서론 이전 포스트에서 Unity Job System과 Burst Compiler의 원리를 다뤘다. Part 4에서 캐시 계층, AoS vs SoA의 기본 개념, 메모리 정렬과 SIMD의 관계를 살펴봤는데 — SoA가 빠르다는 것은 확인했다. 하지만 몇 가지 질문이 남아있다: 왜 빠른가? 캐시 라인 단위의 동작을 수학적으로 분석할 수 있는가? ...

서론 Unity에서 수천 개의 에이전트를 60fps로 구동하려면 메인 스레드 하나로는 불가능하다. 경로 탐색, 분리 조향, 거리 계산, 행렬 변환 — 이 모든 연산을 매 프레임 처리해야 하는데, Update()에서 순차적으로 돌리면 3,000개 에이전트 기준으로 프레임 하나에 수십 ms가 소요된다. C# Job System과 Burst Compil...

서론 멀티스레드 프로그래밍은 게임 개발에서 피할 수 없는 주제다. CPU가 매년 클럭 속도 대신 코어 수를 늘리는 방향으로 진화하면서, 단일 스레드로는 하드웨어의 성능을 온전히 활용할 수 없게 되었다. 그런데 멀티스레드는 어렵기로 악명이 높다. 경합 조건(Race Condition), 데드락(Deadlock), 기아(Starvation) — 운영체...