AI 에이전트를 사용해 하루 만에 전체 게임을 만들었습니다 — 무슨 일이 일어났는지

Source: Dev.to

하루 만에 14개의 상호 연결된 시스템을 갖춘 완전한 게임 프로토타입—단순한 데모가 아니라—을 만들 수 있다면 어떨까요?

바로 제가 Godot 4.6와 GDScript로 만든 아늑한 생활 시뮬 RPG Somnia를 통해 실현했습니다.
트위스트: 저는 각각 전용 역할을 가진 AI 서브‑에이전트 팀을 병렬로 운영했습니다.
다음은 무엇이 잘 작동했는지, 어떤 점이 놀라웠는지, 그리고 다르게 할 수 있었던 부분에 대한 솔직한 정리입니다.

설정: AI 에이전트 팀, “AI가 코드를 작성한다”가 아니다

명확히 하자면 — 이것은 “프롬프트를 ChatGPT에 붙여넣고 게임을 얻는” 것이 아니다. 나는 멀티‑에이전트 파이프라인을 구성했으며, 각 에이전트는 특정 역할을 담당했다:

이 에이전트들은 병렬로 작업했다 — Architect가 전투 시스템을 설계하는 동안, QA는 Lead Dev가 방금 완료한 농업 시스템에 대한 테스트를 이미 작성하고 있었다. PM은 모든 작업을 순차적으로 정리해 에이전트들이 서로에게 막히지 않도록 했다.

핵심 인사이트: 가치가 있었던 것은 어느 하나의 에이전트가 만든 결과물이 아니라 오케스트레이션이었다.

백본으로서의 TDD

나는 엄격한 규칙을 적용했다: 테스트를 먼저, 구현을 나중에, 다음 단계로 넘어가기 전에 모든 테스트가 통과하도록.

이는 선택 사항이 아니었다. 모든 시스템은 동일한 사이클을 따랐다:

1. QA는 아키텍트의 사양을 기반으로 테스트 케이스를 작성한다.
2. 리드 Dev는 테스트가 통과할 때까지 구현한다.
3. 보안 팀은 엣지 케이스를 검토하고; QA는 회귀 테스트를 추가한다.
4. 다음 시스템으로 이동한다.

하루가 끝날 때: 840개 이상의 테스트, 모두 통과.

AI 에이전트와 함께 TDD가 왜 이렇게 중요한가?
AI가 생성한 코드는 종종 보기에는 올바르지만 엣지 케이스를 제대로 처리하지 못한다. 테스트는 이를 즉시 포착한다. TDD가 없었다면, 나는 새로운 시스템을 구축하는 대신 하루의 후반을 미묘한 통합 버그 디버깅에 보냈을 것이다.

14개의 시스템

다음은 Somnia가 하루 만에 제공한 내용입니다:

• 농업 – 씨앗 심기, 물 주기, 성장 단계, 계절 작물
• 전투 – 원소 친화도와 상태 효과가 있는 턴제
• 낚시 – 희귀도 등급 및 위치 기반 낚시가 있는 미니게임
• 꿈 짜기 – 시그니처 메커니즘: 세계에 영향을 주는 꿈을 제작
• 던전 생성 – 난이도가 조절되는 절차적 방
• 날씨 시스템 – 작물, 낚시, NPC 행동에 영향을 주는 동적 날씨
• NPC 시스템 – 일정, 관계, 선물 선호도
• 퀘스트 엔진 – 분기 결과가 있는 다단계 퀘스트
• 집 꾸미기 – 그리드 스냅이 있는 가구 배치
• 인벤토리 – 스택 관리, 카테고리, 퀵 슬롯
• 저장/불러오기 – 마이그레이션 지원이 포함된 버전 관리 저장 파일
• 오디오 매니저 – 적응형 음악 및 공간 사운드 효과
• 낮/밤 주기 – 조명 변화, 시간 제한 이벤트
• UI 프레임워크 – 메뉴, HUD, 대화 상자, 알림

각 시스템은 모듈식입니다. 날씨 시스템은 농업을 직접 알지 못하고 신호만 발송하며, 농업이 이를 수신합니다. 이러한 결합 해제 설계는 Architect 에이전트의 가장 큰 기여였습니다.

실제로 놀랐던 점

1. PM 에이전트가 가장 가치 있었다
   나는 Lead Dev가 스타가 될 것이라고 기대했다. 틀렸다. PM의 작업 순서 지정 덕분에 거의 모든 차단 의존성이 사라졌다. 여섯 명의 에이전트가 병렬로 작업할 때 조정이 병목이며, 코딩 속도가 아니다.

2. 보안 에이전트가 실제 문제를 잡았다
   나는 보안 에이전트를 거의 건너뛰려 했었다 — “싱글플레이어 게임인데, 누가 신경 쓰겠어?” 하지만 저장 파일 변조 취약점, 인벤토리 스택 시스템의 정수 오버플로, 아이템을 복제할 수 있게 하는 Dream‑Weaving 익스플로잇 등을 잡아냈다. 이런 버그들은 나중에 큰 고통이 되었을 것이다.

3. 840개의 테스트는 많아 보이지만 충분하지 않다
   시스템 간 통합 테스트는 부족했다. 유닛 테스트는 탄탄했지만, “던전 탐험 중 비가 오고 플레이어가 낚시를 할 때는 어떻게 되는가” 같은 크로스‑시스템 시나리오는 더 많은 커버리지가 필요하다. 교훈: AI 에이전트를 활용하면 생각보다 훨씬 더 많은 테스트를 작성할 여유가 있다.

4. GDScript + Godot 4.6이 올바른 선택이었다
   GDScript는 충분히 간단해 AI 에이전트가 안정적으로 생성할 수 있다. C++나 Rust는 컴파일 오류와 메모리 버그를 도입해 하루짜리 일정에 치명적이었을 것이다. 제약에 맞는 언어를 선택하라.

실제 워크플로우

일반적인 30분 사이클은 다음과 같습니다:

[00:0] PM assigns: "Implement fishing minigame"
[00:2] Architect delivers: component diagram + signal contracts
[00:5] QA writes: 47 test cases for fishing mechanics
[00:8] Lead Dev starts implementation
[00:20] Lead Dev: all 47 tests passing
[00:22] Security review: adds input bounds on reel tension
[00:25] QA: 3 additional edge‑case tests
[00:28] Lead Dev: all 50 tests green
[00:30] PM: "Moving to Dream Weaving system"

이러한 사이클 6개가 서로 다른 시스템에서 병렬로 실행되었습니다. 이렇게 하루에 14개의 시스템을 구축할 수 있습니다.

내가 다르게 할 것

• 시작부터 더 많은 통합 테스트.
  두 번째 시스템이 완성되는 즉시 QA 에이전트가 시스템 간 테스트를 작성하도록 했을 것입니다.

• 전용 리팩터 에이전트.
  10개 이상의 시스템을 만든 뒤, 초기 코드 중 일부는 정리가 필요했습니다. 저는 직접 정리했지만, 에이전트가 이를 처리할 수 있었을 것입니다.

• 더 엄격한 인터페이스 계약.
  설계자가 인터페이스를 정의했지만, 일부 에이전트가 …

참고: 원본 내용이 “some agents dr”라는 문구에서 갑자기 끊겼습니다. 마크다운은 해당 절단을 그대로 유지하여 내용을 보존합니다.

Shifted

자동화된 계약 검사는 즉시 드리프트를 포착합니다.

직접 해보세요

프로토타입을 플레이할 수 있습니다: Somnia on itch.io

거칠지만 — 하루 작업은 하루 작업입니다. 하지만 이것은 스프라이트로 만든 hello‑world가 아니라 상호 연결된 시스템을 갖춘 실제 프로토타입입니다.

요약

The question isn’t “Can AI write code?” — it obviously can. The real question is: “Can you design a system where multiple AI agents collaborate effectively?”

The answer is yes, but only if you:

• Define clear roles and interfaces
• Enforce TDD ruthlessly
• Invest in orchestration (the PM agent)
• Pick a tech stack that minimizes friction

14개의 시스템. 840개 이상의 테스트. 하루 만에.
The game‑dev landscape is shifting, and the developers who learn to orchestrate AI teams will build things that were previously impossible solo.

멀티 에이전트 설정에 대한 질문이 있거나 이 방식을 직접 프로젝트에 적용해 보고 싶으신가요? 댓글을 남겨 주세요 — 구체적인 내용을 기꺼이 공유하겠습니다.