Opus 5.5가 서브 에이전트를 오케스트레이션하는 AI만을 사용한 멀티플레이어 추출형 RTS 개발: 세 가지 교훈과 원본 프롬프트

내가 만든 것:
브라우저에서 실행되는 멀티플레이어 추출형 RTS인 Pixkrieg입니다. 플레이어가 절차적으로 생성된 유닛 명단을 소유하고, 장비를 갖추게 한 뒤, 강도들, AI 파티, 그리고 다른 플레이어들을 상대로 습격(PvPvE)을 보냅니다. 추출 지점에서 빠져나오는 사람이 전리품을 가지고 돌아가고, 쓰러지는 사람은 영원히 사라집니다. 전리품은 캠프와 유닛에 쌓입니다.

Claude가 사용된 방식:
모든 과정에서요. Opus 5.5를 사용하는 Claude Code가 대부분의 작업을 수행하고, GPT Astra를 사용하는 Codex가 그 옆에서 작동합니다. 코드, 생성기(generators), 서버, 테스트, 아트워크(절차적 생성기, 이미지 모델 제외), 사운드, Discord 봇, 심지어 위의 클립까지 모두요.

설정:
둘 다 VS Code 확장 프로그램으로 실행됩니다. 저는 오케스트레이터와 대화합니다. 오케스트레이터는 계획을 세우고 작업을 분할하며, 실제 구축을 수행하는 서브 에이전트들을 자체 브랜치 및 작업 트리(worktrees)에 시작시킵니다. 어떤 것이 병합되기 전에는 별도의 서브 에이전트가 적대적으로 검토하고, 시각적 작업은 이전 라운드를 본 적 없는 신선한 리뷰어 서브 에이전트에 의해 점수가 매겨집니다. 오케스트레이터의 주요 임무는 모두를 하나의 중앙 규칙 세트(central rule set)에 유지하는 것입니다: 코드 중복 금지 (jscpd 게이트), 기성 자산 금지, 오류에 대한 까다로운 지적, 커버리지 및 뮤테이션 테스트 하한선, 그리고 오직 제가 결정할 수 있는 항목 목록(돈, 계정, 출판, 최종 이름).

프롬프트보다 더 도움이 된 세 가지 교훈:

Claude에게 반복할 숫자를 제공하세요. 저는 첫 공개 플레이 테스트 이전에 게임에 원격 측정(telemetry) 및 플레이어 퍼널을 구축했고, 모든 디자인 목표는 목표 범위를 갖게 되었습니다. 몇 가지 예시: 레이드 진입 후 10초 이내 최초 명령어 실행 (측정값 20초), 5분에서 8분 분량의 튜토리얼 (측정값 2.9분), 레이드당 유닛 손실률 15%~20% (측정값 7.3%), 지도상 가장 위험한 지역에서의 손실률 40%~60% (측정값 6%, 위험 곡선이 거꾸로 되어 있음). 퍼널에 따르면 모든 플레이어 중 절반가량이 튜토리얼에서 이탈했습니다. 피드백에서는 아무도 저에게 그것을 말해주지 않았습니다. 그들은 그냥 떠날 뿐입니다.

데이터를 확보하자 Claude가 튜토리얼을 재구축했고, 현재 플레이 테스트에서는 약 70%가 통과합니다. 한 번의 반복(iteration)입니다. 데이터 없이는 여전히 추측만 했을 것입니다.

마케팅 도구도 만들게 하세요. 저는 비디오 편집을 정말 좋아하지 않습니다. 이전에는 클립을 만들어 본 적도 없고 소셜 미디어 채널도 없었습니다. Claude는 개발 로그(devlog) 파이프라인을 구축했습니다: 게임은 결정론적 장면 스튜디오(deterministic scene studio)를 가지고 있으며, 이 파이프라인은 거기서 연출된 장면들을 촬영하고, 내레이션에 맞춰 자르고, 로컬 TTS 모델로 음성을 입히고, Whisper로 목소리를 검증하며, 측정 가능한 품질 관리(QC: 프레임 0의 움직임, 대비, 정지 화면, 음량, 텍스트 안전 영역)를 실행합니다. 거의 노력 없이 쇼츠, 클립, 두 빌드 간의 전/후 비교가 가능합니다. 결과물이 아직 완벽하지는 않습니다. 좋은 점은 필요하다면 API 호출 없이 완전히 실행될 수 있으며, Claude가 그 결과를 검토하면 품질이 향상된다는 것입니다.
커뮤니티를 게임 안에 배치하세요. 저의 이전 프로젝트인 ExoSiege는 플레이어들이 디스코드(Discord) 링크를 얼마나 좋아하는지 보여주었습니다. 그래서 Out of Pixkrieg에서는 채팅과 피드백이 게임과 Discord 사이에서 동기화됩니다. 게임에 작성된 피드백은 Discord의 포럼 스레드가 되고, 답변은 다시 게임으로 돌아옵니다. 여러 작은 조각들 대신 하나의 공유 장소가 생기는 것입니다.

5주 후에는 유닛, 동물, 지형, 깃발, 아바타 및 스킬 생성기뿐만 아니라 건물, 보행 장치(walkers), 아이템, 이름, 픽셀 폰트, 사운드까지 갖추고 있으며, 베이스와 레이드 시스템을 가진 브라우저 멀티플레이어, 서버 측 안개 지대(server-side fog of war)를 가진 권위 있는 레이드 서버, 충돌 체크포인트 및 AI 진영 계정, 매치메이킹, 경제 시스템, Discord 브릿지, 플레이 테스트 대시보드가 구현되어 있습니다. 스택: 모든 곳에 Rust (시뮬레이션, netcode, 생성기, 렌더러, UI, 오디오). 클라이언트는 wgpu 기반의 Rust로 WASM으로 컴파일되었으며, WebGPU와 WebGL2 폴백을 사용하고 얇은 TypeScript 셸이 적용되었습니다. 서버는 tokio/axum, WebSocket 폴백을 가진 WebTransport, Postgres, Redis, Docker Compose, Caddy를 사용합니다. Rust + WASM은 지금까지 제가 '바이브 코딩(vibe coding)'에 사용해 본 조합 중 가장 좋은 것일 것입니다.

타입 시스템과 엄격한 린트(lint)는 에이전트가 무언가를 실행하기 전에 많은 오류를 잡아내며, 동일한 크레이트(crates)가 네이티브로 브라우저에서 실행될 수 있기 때문에 Claude는 클라이언트의 로직을 몇 초 만에 네이티브하게 테스트할 수 있습니다. 이 프로젝트를 시작하게 만든 프롬프트가 있습니다. 이후 수많은 프롬프트들이 사용되었지만, 모든 것은 약 2~3일에 걸쳐 단일 세션으로 전체 기반을 만들어낸 매우 상세한 하나의 프롬프트에서 시작되었습니다. 일부 분들이 흥미로워하실까 봐 이 게시물 하단에 독일어에서 경로 및 기계 세부 정보가 제거된 상태로 번역하여 제공합니다. 현재 버전은 설치 없이 브라우저에서 무료로 플레이할 수 있습니다: https://pixkrieg.com

프롬프트:

개요(Brief): 프로덕션 레디 브라우저 RTS 추출 게임("Tarkov를 RTS로")

0. 개요 및 작동 모드

이 디렉토리에서는 브라우저에서 실행되는 완전하고 프로덕션 레디한 멀티플레이어 게임을 구축합니다. 전체 스택은 로컬과 프로덕션 환경 모두에서 Docker Compose로 실행됩니다. 네이티브 데스크톱 빌드와 Steam은 나중에 추가되며, 본 개요에는 포함되지 않습니다. 하지만 아키텍처는 처음부터 이들을 위한 길을 열어둡니다 (6.1).

기준은 타협 없이 모든 분야에서 최대 품질을 요구합니다: 코드, 아키텍처, 성능, 네트코드(netcode), 보안, 게임 디자인, 그래픽스, UX, 오디오 및 운영. 섹션 4는 모든 줄과 모든 결정에 적용됩니다.

정의된 완료(Definition of Done, 13)가 충족될 때까지 완전히 자율적으로 작업합니다.
일상적인 결정을 스스로 내리고, 이를 문서화하며 계속 작업합니다. 질문 때문에 멈추지 않습니다. 예외는 섹션 14에 의해서만 정의됩니다.
사전 지식 없이 시작합니다. 관련 모든 내용은 여기에 있으며, 참고 레포지토리(reference repo)는 끝에 첨부되어 있습니다.

환경: Windows 11, PowerShell 5.1 및 Git Bash, 6코어 데스크톱 CPU, 고급 GPU, 64 GB RAM, MSVC 빌드 도구. VM(~12 GB)이 호스트 포트를 차지하는 다른 영구 실행 스택과 공유되는 Docker Desktop (Hyper-V)을 사용하며, 따라서 리소스 제한 및 충돌 없는 포트가 필수적입니다. 툴체인(Toolchains)은 시스템 전체가 아닌 프로젝트 로컬에 설치됩니다.

1. 게임 컨셉 (사용자 확인 완료) - 장르: 오픈 월드 RTS 추출 장르, "타르코프를 RTS로". 완전한 멀티플레이어 및 PvP 지원.

플랫폼: 현재는 브라우저에서 플레이 가능하여 누구나 바로 접근할 수 있음. 나중에는 동일 코드베이스를 사용하며 하나의 공유 플레이어 풀을 가진 네이티브 클라이언트와 Steam 버전을 출시함 (본 개요에서는 제외).
레이드: 세션 기반. 레이드 인스턴스는 1~2시간 동안 열려 있으며, 플레이어들은 참여하고 떠날 수 있음(진행 중 참가 가능).
지도 위: 곳곳에 작은 도적 캠프(PvE), 채광 가능한 자원 노드(돌, 나무 등), 새로운 사람을 모집하는 상점이 있는 안전 구역, 사람들과 함께 추출하는 추출 지점, 다른 플레이어 및 그들의 군대와의 PvP가 존재함.
유닛: 모든 유닛은 절차적으로 생성되며 고유함: 외모, 역할, 장비, 이름이 다름.
레이드에서 모집된 병력은 전리품(loot)임. 그들은 고용되는 순간부터 싸우지만 추출 후에만 플레이어 소속이 됨.
사망은 유닛의 영구적인 손실을 의미함. 플레이어는 항상 3개의 기본 유닛으로 시작할 수 있으므로, 완전한 손실은 불가능함.
"유닛 봉봉(Unit bonbons)"은 무작위 유닛을 제공함. 희귀도는 생성기의 티어(Recruit, Veteran, Elite, Hero)를 거침.
로비/기지: 추출된 유닛들이 이곳에서 자원을 수동적으로 생산하며, 이는 모집 및 제작에 사용됨. 핵심 긴장감: 사람들을 위험 속으로 다시 보낼 것인가, 아니면 안전하게 생산하도록 둘 것인가.
규모: 처음부터 매우 큰 숫자로 계획해야 함. 대규모 군대는 나중에 추가되는 기능이 아니라 기본 전제임.
호스팅: 독일의 임대 서버를 사용하며, 사용자 기기에서 약 15ms RTT가 발생함. 여기서 고정되지 않은 모든 것은 섹션 2의 기둥(crafting, items, loot tables, economy, progression, raid entry and end, factions, squads, map size, tutorial, social features)에 따라 docs/GDD.md에서 직접 설계해야 함. 각 결정과 균형은 시뮬레이션 및 봇 플레이 테스트를 통해 정당화하고 맞춰야 함.

2. 디자인 기둥 (Design pillars)

위험 대 보상(Risk versus reward): 사람들을 데려가는 모든 결정이 체감됨.
모든 유닛은 소중함: 절차적 정체성(procedural identity)과 영구적인 죽음(permadeath)이 애착을 형성함.

대규모 가독성: 지형(ground)보다 전경(figure), 분대(squads), 확대 시 세부 수준(levels of detail).
4. 설계 단계부터 레이턴시 방지: 반사적인 마이크로 컨트롤 대신 채널 시간, 공지된 능력 및 서버 측 상태(server-side stances).
5. 최소화되고 직관적인 사용자 인터페이스(UI).
6. 공정성: 서버가 모든 것을 결정하며, 과금으로 승리하는 구조(pay-to-win)가 없음.

3. 황금률 (협상 불가)

코드는 절대 중복되지 않으며, 장기적인 유지보수성을 위해 항상 적절하게 추상화(abstracted)되어야 한다.
기성 자산(ready-made assets)은 제외한다. 기존 생성기(generators)를 사용하거나 새로운 것을 구축한다. 여기에는 지형, 글꼴(fonts), 사운드, 음악, 아이콘 및 UI 그래픽이 포함된다.
UI 관련 모든 것은 가능한 한 직관적이고, 미니멀하며, 단순해야 하며, 피규어의 8비트 스타일과 어울리는 독특한 스타일을 가져야 한다.
CI가 규칙을 기계적으로 강제한다: 고정된 임계값(fixed threshold)으로 Rust와 TypeScript 전반의 중복 감지(예: jscpd); 모듈 계층(섹션 7) 확인, 따라서 플랫폼 크레이트(platform crates) 외부에 있는 브라우저 코드는 빌드를 실패시킨다; 리포지토리 내에 이미지, 오디오 또는 글꼴 파일은 단일 폴더의 생성된 테스트 참조를 제외하고는 없다; UI는 수작업으로 디자인되었지만 공유 팔레트 토큰(shared palette tokens)을 사용하여 코드로 구축되며, 프레임은 코드 내에 있고, 아이콘은 생성기에서 가져오며, 사용자 정의 픽셀 글꼴이 글리프 데이터로 사용된다.

4. 품질 기준(Quality bar): 예외 없이 최고 수준

기준은 훌륭한 프로토타입이 아니라 해당 장르 최고의 상업적 타이틀이어야 한다. "작동한다(Works)"는 "완료되었다(done)"를 의미하지 않는다. 무언가가 완료된 것은 그것이 탁월하고, 측정되었으며, 독립적으로 검토되었을 때이다. 만약 "충분히 좋다(good enough)"고 느껴진다면, 그것은 완료된 것이 아니다.
원칙:

main에 대한 지름길 금지, CI가 확인한다: 플레이스홀더(placeholders), 목업(mocks) 또는 스텁(stubs) 없음, 주석 처리된 코드 없음, TODO, FIXME, todo!(), unimplemented!(), "나중에" 같은 표현 없음.
모든 구성 요소는 해당 분야의 선도적인 전문가들이 승인하는 것처럼 구축되어야 한다.
중요한 결정에 대해서는 최소한 두 가지 심각한 대안을 검토하고, 가능한 경우 측정하며, 그 결과를 ADR(Architecture Decision Record)에 기록해야 한다.
게이트 기준에 미달하는 결과는 과장되지 않고 개선된다. - 단순성이 곧 품질이다. 모든 요구사항을 훌륭하게 충족시키는 가장 간단한 해결책이어야 한다. 이점 없는 추상화(abstraction)는 없으며, 필요하지 않은 의존성(dependency)은 없다.

CI(지속적 통합)의 기술 게이트:

Rust: rustfmt; 선택된 까다로운 린트(pedantic lints)를 사용한 clippy -D warnings; 기본적으로 #![forbid(unsafe_code)] 적용 (안전하지 않은 코드(unsafe code)는 서면 근거, SAFETY 주석 및 Miri 테스트가 있어야 함); 모든 라이브러리 크레이트에는 #![deny(missing_docs)] 적용.
TypeScript 셸: 엄격 모드(strict mode), 경고 없이 린팅 실행.
Docker: Dockerfile에 대한 린팅(hadolint), Compose 설정 검증.
빌드: 경고가 없어야 함.
불안정한 테스트(Flaky tests): 없음 (불안정한 테스트는 버그이다).
커버리지(Coverage): foundation, generator, rule, net, meta의 라인 중 90% 이상 (cargo-llvm-cov 사용). 이것은 목표가 아니라 최소 기준이다.
뮤테이션 테스트(Mutation testing): rule, economy, transaction 및 netcode에 대해 90% 이상 포착 (cargo-mutants 사용).
속성 테스트(Property tests): 모든 불변 조건(invariant) 검증 (자원은 절대 중복되지 않음, HP는 범위 내에 유지됨, 거래가 균형을 이룸).
퍼징(Fuzzing): 모든 디코더 및 파서 (네트워크 프로토콜, 저장 형식, generator 사양)에 대해 수행 (cargo-fuzz 사용). 정기적인 CI 실행 시 열린 발견 사항이 없어야 한다.
공급망(Supply chain): 라이선스, 권고 사항, 중복 버전 확인 (cargo-deny 사용), 최소한의 고정된 의존성(pinned dependencies), 고정된 베이스 이미지(pinned base images), 재현 가능한 빌드(reproducible builds).
성능(Performance): CI에서 p50 및 p99 예산 설정. 벤치마크 장면에서 프레임이 예산을 두 배 초과해서는 안 되며, 메모리 예산과 GPU 시간 측정 필수.

검토를 통한 제품 게이트:

스코어카드(Scorecards): 그래픽, UX, 게임 감각(game feel), 오디오, 게임 디자인 각 항목이 최소 9/10 점수를 받아야 하며, 적어도 두 명의 독립적인 검토자 서브 에이전트가 평가해야 한다 (세 번째는 의견 불일치 시 결정).
게임 감각(Game feel): 동일 프레임 내에서 로컬 피드백 제공, 모든 액션에 대한 시각적 및 청각적 피드백, 깔끔한 픽셀 그리드(정수 스케일링, 서브픽셀 지터 없음, 블러 없음).
최종 패널(Final panel): 각 분야별 전문가 서브 에이전트 (게임 디자인, 아트 디렉션, 렌더링, 시뮬레이션, netcode, 보안, UX, 오디오, 운영)가 배치되어야 한다.

각 항목은 최소 9/10점 이상의 승인을 받았으며, 모든 발견된 사항은 ADR(Architecture Decision Record)에 의해 수정되거나 정당화되었습니다. ### 5. 시작 자료: 참조 리포지토리 (읽기 전용)
끝에 첨부된 리포지토리에는 유일한 시작 자료인 **유닛 및 구조 생성기(unit and structure generator)**가 포함되어 있습니다. 나머지 모든 것은 지형을 포함하여 새로 구축되었습니다. 이는 절대 수정되지 않습니다. 참조 실행을 위해서는 이를 git-ignored 캐시 디렉터리로 복사해야 합니다.

Godot 4.5, .NET / C#, 엔진 독립형 코어(engine-independent core), 골든 테스트(golden tests), 콘솔 하네스(console harness). 먼저 README와 docs/를 읽으십시오. 실제 적용된 스타일 결정 사항들이 거기에 작성되어 있습니다.
페인팅 로직: 색상 대신 재질과 톤 단계로 구성된 캔버스; 그림자가 청보라색(blue-violet, 285°)으로, 하이라이트가 따뜻한 노란색(warm yellow, 85°)으로 변하는 5단계 OKLCH 램프(OKLCH ramps); 하나의 전역 윤곽선 색상 Oklch(0.215, 0.038, 282); 왼쪽 상단에서 오는 빛, 모양별 볼륨 음영 처리(volume shading per shape); 흙빛 무광(earthy mate)