최근 게임 개발에서도 AI의 활용도가 빠르게 높아지고 있다.
예전에는 AI에게 코드를 물어보는 정도였다면, 지금은 AI Agent를 이용해 코드를 작성하고 수정하는 것은 물론이고 Unity Editor와 연결하여 Scene을 구성하거나 GameObject와 Component를 다루고, 프로젝트를 분석하고, 오류를 찾아 수정하는 방식까지 발전하고 있다.
하지만 여기서 한 가지 문제가 있다.
게임 개발은 단순히 코드를 작성하는 일이 아니다.
그래서 웹 개발에서 흔히 이야기하는 Vibe Coding 방식을 그대로 게임 개발에 적용하면 어느 순간 한계에 부딪힌다.
게임 개발에서 AI를 제대로 활용하려면 단순히 AI에게 코드를 작성시키는 것이 아니라 AI가 실제 게임 개발 과정에 참여할 수 있는 환경을 만드는 것이 중요하다.
게임 개발은 왜 Vibe Coding만으로 어려운가
Vibe Coding은 매우 강력하다.
예를 들어 Unity에서 플레이어 이동을 구현한다고 해보자.
플레이어 이동 시스템을 만들어줘.
- WASD 이동
- 카메라 방향 기준 이동
- 점프
- 중력
- 이동 속도 Inspector 설정
- Unity Input System 사용
AI는 상당히 빠르게 C# 코드를 만들어낼 수 있다.
간단한 기능이나 프로토타입을 만드는 데는 매우 효율적이다.
하지만 게임 프로젝트가 커지기 시작하면 문제가 달라진다.
게임은 코드만으로 만들어지지 않는다
일반적인 프로그램은 대략 다음과 같은 구조로 생각할 수 있다.
요구사항
↓
코드
↓
실행
↓
결과
Unity 게임은 훨씬 복잡하다.
Game
│
┌─────────┼─────────┐
▼ ▼ ▼
Code Data Asset
│ │ │
▼ ▼ ▼
System Config Model
│ │ │
└─────────┼─────────┘
▼
Unity
│
┌─────────┼─────────┐
▼ ▼ ▼
Scene Physics Animation
│ │ │
└─────────┼─────────┘
▼
Gameplay
│
▼
Player
│
▼
재미
코드가 정상적으로 작성되었다고 해서 게임이 정상적으로 만들어지는 것이 아니다.
Scene의 GameObject 구조가 잘못될 수도 있고, Inspector의 Reference가 비어 있을 수도 있다.
Animator 설정이 잘못되었을 수도 있고, Collider나 Layer 설정이 잘못되었을 수도 있다.
그리고 가장 중요한 문제도 있다.
코드가 정상적으로 동작해도 게임이 재미없을 수 있다.
AI는 코드를 만들 수 있지만 게임을 대신 플레이할 수는 없다
예를 들어 AI에게 다음과 같이 요청할 수 있다.
플레이어 공격 시스템을 만들어줘.
AI는 공격 코드를 만들어 줄 수 있다.
하지만 다음 질문은 별개의 문제다.
공격 속도가 적당한가?
타격감이 좋은가?
Hit Timing이 자연스러운가?
애니메이션과 공격 판정이 일치하는가?
공격 후 딜레이가 답답하지 않은가?
적의 피격 반응이 충분한가?
플레이어가 공격하는 과정이 재미있는가?
이것들은 코드 생성으로 해결되는 문제가 아니다.
직접 플레이하고 판단해야 한다.
결국 게임 개발에는 다음과 같은 반복 과정이 필요하다.
만든다
↓
플레이한다
↓
문제를 발견한다
↓
수정한다
↓
다시 플레이한다
AI는 이 과정을 상당 부분 자동화할 수 있지만 무엇이 좋은 게임 경험인지 최종적으로 판단하는 것은 개발자다.
Unity는 코드와 Editor 상태가 연결되어 있다
Unity에서 특히 문제가 되는 부분이다.
다음 코드가 있다고 해보자.
public class PlayerCombat : MonoBehaviour
{
[SerializeField]
private Weapon weapon;
}
코드 자체에는 문제가 없다.
하지만 Inspector에서 weapon에 아무것도 연결하지 않았다면?
PlayerCombat
weapon = null
이 된다.
결과적으로 게임 실행 중 NullReferenceException이 발생할 수 있다.
즉,
코드가 정상
≠
Unity 프로젝트가 정상
이다.
Unity에서는 다음과 같은 상태가 모두 중요하다.
GameObject
Component
Inspector
Prefab
Scene
Transform
Layer
Tag
Reference
Animator
Collider
Rigidbody
Material
ScriptableObject
Project Settings
AI가 코드만 보고 있다면 이 전체 상태를 알 수 없다.
이것이 게임 개발에서 단순 Vibe Coding이 가지는 가장 큰 한계 중 하나다.
프로젝트가 커지면 AI가 프로젝트 전체를 이해해야 한다
작은 프로젝트에서는 파일 몇 개만 보면 된다.
하지만 프로젝트가 커지면 상황이 달라진다.
Scripts
├─ Player
├─ Enemy
├─ Combat
├─ UI
├─ Network
├─ Save
├─ Inventory
└─ GameManager
Scenes
Prefabs
ScriptableObjects
Animations
Materials
Audio
Shaders
AI에게 특정 Script 하나를 보여주고 수정하게 하는 것만으로는 부족하다.
예를 들어 Enemy가 공격하지 않는 문제가 발생했다고 하자.
원인은 다음 중 하나일 수 있다.
EnemyAI 코드
Animator
Animation Event
Collider
Layer
Target Reference
NavMesh
Prefab
Scene
Inspector
코드만 보고서는 원인을 찾지 못할 수 있다.
그래서 AI가 실제 Unity 프로젝트의 상태를 확인할 수 있는 환경이 필요하다.
Unity MCP
여기서 MCP가 중요해진다.
MCP(Model Context Protocol)는 AI Agent가 외부 도구와 연결될 수 있도록 하는 표준이다.
Unity에서도 MCP Server를 통해 외부 AI Agent와 Unity Editor를 연결할 수 있다.
구조를 단순화하면 다음과 같다.
AI Agent
│
▼
MCP
│
▼
Unity Editor
기존에는 개발자가 Unity의 상태를 확인해서 AI에게 알려줘야 했다.
Unity
↓
사람이 확인
↓
정보 복사
↓
AI
MCP를 사용하면 AI가 Unity와 직접 연결될 수 있다.
AI Agent
↕
Unity MCP
↕
Unity Editor
Unity 공식 MCP Server는 Unity Editor와 AI Agent를 연결하여 Scene, GameObject, Component 등의 프로젝트 컨텍스트를 활용하고 Editor 작업을 수행할 수 있도록 하는 방향으로 제공되고 있다.
즉 MCP는 AI에게 Unity를 다룰 수 있는 손을 제공하는 것에 가깝다.
Cursor를 AI 개발 환경으로 사용하기
여기에 Cursor 같은 AI 코드 에디터를 사용할 수 있다.
Cursor는 프로젝트의 코드를 분석하고 수정하는 역할을 담당한다.
전체 구조는 다음과 같다.
AI
│
Cursor
│
┌────────┴────────┐
▼ ▼
Project Code Unity MCP
│ │
▼ ▼
C# 수정 Unity Editor
Cursor가 코드를 담당하고 MCP가 Unity Editor와 연결되는 구조다.
그러면 AI는 단순히 코드를 작성하는 것에서 벗어나 코드와 실제 Unity 상태를 함께 다루게 된다.
Unity MCP로 무엇을 할 수 있는가
MCP의 구체적인 기능은 사용하는 MCP 구현과 버전에 따라 다르지만, Unity 개발에서는 다음과 같은 작업을 AI Agent에 맡기는 방향으로 활용할 수 있다.
Scene 분석
현재 Scene의 GameObject 구조를 분석해줘.
Player와 Enemy를 찾아서
각각 어떤 Component를 가지고 있는지 정리해줘.
AI가 Scene의 실제 상태를 확인할 수 있다.
GameObject 생성
현재 Scene에 EnemySpawner라는
Empty GameObject를 만들어줘.
또는
Player 앞에 테스트용 Enemy 5개를 배치해줘.
같은 Editor 작업을 수행하도록 할 수 있다.
Component 설정
모든 Enemy에 Health Component를 추가해줘.
기본 HP는 100으로 설정해.
또는
Player Rigidbody의 Collision Detection을
Continuous로 변경해줘.
같은 반복적인 Inspector 작업을 AI에게 맡길 수 있다.
Scene 구성
게임 개발에서 상당히 유용한 부분이다.
예를 들어:
전투 테스트 Scene을 만들어줘.
- 중앙에 Player
- Player 주변에 Enemy 8개
- 바닥 생성
- 카메라 배치
- 조명 설정
- EnemySpawner 생성
이런 요구사항을 AI에게 전달하면 AI가 Unity Editor와 연결되어 실제 Scene을 구성하는 작업을 수행할 수 있다.
직접 하나씩 GameObject를 만들고 위치를 설정하는 반복 작업을 줄일 수 있다.
Prefab 관리
Prefab 역시 AI와 MCP가 결합되면 활용 범위가 넓어진다.
예를 들어:
현재 Enemy Prefab을 분석해.
필수 Component가 빠져 있는지 확인하고
누락된 것이 있다면 추가해줘.
또는:
모든 Enemy Prefab의 기본 HP를 100으로 통일해줘.
같은 작업을 수행할 수 있다.
대량 작업
MCP가 특히 강력한 부분이다.
예를 들어 Scene에 NPC가 100개 있다고 하자.
직접 하면:
NPC 선택
→ Component 수정
→ 값 변경
→ 다음 NPC
→ 반복
AI에게는:
현재 Scene의 모든 NPC를 찾아서
CapsuleCollider Height를 1.8로 설정하고
Center Y를 0.9로 설정해줘.
라고 할 수 있다.
사람이 직접 수행하던 반복 작업을 규칙으로 바꾸는 것이다.
AI를 이용한 디버깅
MCP를 사용하면 디버깅 방식도 달라질 수 있다.
기존에는:
게임 실행
↓
오류 발생
↓
Console 확인
↓
오류 복사
↓
AI에게 전달
↓
코드 수정
↓
게임 재실행
이었다.
AI Agent가 Unity에 연결되어 있다면:
게임 실행
↓
Console 확인
↓
관련 GameObject 확인
↓
Component 확인
↓
관련 코드 분석
↓
원인 추론
↓
수정
↓
재실행
↓
검증
이라는 자동화된 루프를 만들 수 있다.
이것이 단순한 Vibe Coding과 AI Agent 기반 개발의 차이다.
하지만 MCP만으로 충분하지 않다
여기서 또 다른 문제가 생긴다.
AI가 Unity 프로젝트를 볼 수 있다고 해서 프로젝트를 제대로 이해하는 것은 아니다.
예를 들어 프로젝트에 다음과 같은 개발 원칙이 있다고 하자.
Game Logic과 MonoBehaviour를 분리한다.
게임 데이터는 ScriptableObject를 사용한다.
Manager의 무분별한 사용을 금지한다.
Network Authority는 Server를 기준으로 한다.
AI가 이 규칙을 모르면 프로젝트에 맞지 않는 코드를 작성할 수 있다.
그래서 프로젝트의 지식을 AI에게 제공하는 시스템이 필요하다.
LLM Wiki
여기서 LLM Wiki가 등장한다.
LLM Wiki는 단순한 문서 저장소가 아니다.
프로젝트의
기획
아키텍처
개발 규칙
기술적 결정
시스템 구조
문제점
을 AI가 참고할 수 있는 형태로 정리해 놓는 것이다.
예를 들어:
AI-Wiki
│
├─ GameDesign
│ ├─ GameOverview.md
│ ├─ Combat.md
│ └─ Progression.md
│
├─ Architecture
│ ├─ Overview.md
│ ├─ Player.md
│ ├─ Combat.md
│ └─ Network.md
│
├─ Technical
│ ├─ CodingRules.md
│ ├─ UnityRules.md
│ └─ Performance.md
│
└─ Decisions
├─ ADR-001.md
├─ ADR-002.md
└─ ADR-003.md
Obsidian을 사용해도 되고 단순한 Markdown 파일 구조로 관리해도 된다.
중요한 것은 문서의 형식보다 AI가 프로젝트의 지식을 지속적으로 참조할 수 있는 구조를 만드는 것이다.
왜 프로젝트의 결정을 기록해야 하는가
예를 들어 프로젝트에서 ECS를 사용하지 않기로 결정했다고 하자.
그 이유가 단순히 개발자의 취향이 아니라 다음과 같은 판단 때문이라고 하자.
현재 프로젝트 규모에서는
ECS의 복잡성이 얻을 수 있는 성능 이점보다 크다.
이것을 기록하지 않으면 AI는 나중에 성능 문제를 발견하고 갑자기 ECS 도입을 제안할 수 있다.
따라서 다음처럼 기록한다.
ADR-004
결정:
현재 프로젝트에서는 ECS를 사용하지 않는다.
이유:
현재 규모에서는 전환 비용이 크다.
재검토 조건:
동시 Entity 수가 특정 수준을 넘어갈 경우
다시 검토한다.
이런 문서를 Architecture Decision Record 형태로 남겨두면 AI가 프로젝트의 과거 의사결정을 이해하는 데 도움이 된다.
Git을 반드시 같이 사용해야 한다
AI에게 프로젝트를 직접 수정하게 만들수록 Git의 중요성은 커진다.
AI는 한 번에 여러 파일을 수정할 수 있다.
때로는 의도하지 않은 부분까지 변경할 수도 있다.
따라서:
Git
↓
AI 작업
↓
Diff 확인
↓
테스트
↓
Commit
이라는 흐름을 유지하는 것이 좋다.
AI에게 모든 권한을 주는 것보다 AI가 만든 변경사항을 사람이 검토하고 확정하는 구조가 안전하다.
테스트 역시 AI 개발의 일부가 된다
AI를 적극적으로 활용하려면 테스트도 중요하다.
예를 들어:
Player가 공격한다.
↓
Damage 발생
↓
Enemy HP 감소
↓
HP 0
↓
Death
↓
Reward
이 과정을 테스트할 수 있도록 만들어 놓으면 AI가 코드를 수정한 뒤 기존 기능이 깨졌는지 확인할 수 있다.
따라서 가능하면:
Unity Test Framework
+
Play Mode Test
+
Automated Test
등을 활용하는 것이 좋다.
AI가 코드를 작성하는 것보다 중요한 것은 AI가 수정한 결과를 검증할 수 있는 환경을 만드는 것이다.
결국 AI 게임 개발은 하나의 루프가 된다
이 모든 것을 연결하면 다음과 같은 구조가 된다.
개발자
│
게임의 방향 결정
│
▼
LLM Wiki
│
▼
AI Agent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Cursor MCP Git
│ │
▼ ▼
Code Unity
│ │
└──────┬──────┘
▼
Play Test
│
▼
검증
│
▼
AI
│
└──────────→ 수정
이것이 AI를 활용한 게임 개발의 핵심적인 구조라고 볼 수 있다.
개발자가 해야 하는 일도 바뀐다
AI를 제대로 활용하면 개발자가 직접 해야 하는 작업의 양은 줄어든다.
하지만 개발자의 역할이 없어지는 것은 아니다.
오히려 역할이 바뀐다.
기존 개발자는:
기획
+
설계
+
코딩
+
Editor 작업
+
디버깅
+
테스트
+
반복 작업
을 모두 직접 처리했다.
AI를 적극적으로 활용하면:
개발자
게임의 방향 결정
시스템 설계
아키텍처 결정
품질 기준 설정
플레이 테스트
최종 판단
을 담당하고,
AI가:
코드 작성
코드 수정
반복 작업
Scene 작업
Editor 작업
디버깅 지원
테스트 작성
문서화
분석
등을 담당하는 형태로 바뀐다.
즉 개발자가 직접 모든 작업을 하는 구조에서 개발자가 AI를 지휘하는 구조로 이동하는 것이다.
AI를 활용한 게임 개발의 핵심
결국 중요한 것은 AI에게 얼마나 많은 코드를 생성시키느냐가 아니다.
AI를 게임 개발 과정에 얼마나 깊게 연결하느냐가 중요하다.
단순한 Vibe Coding은:
사람
↓
자연어
↓
AI
↓
코드
이다.
반면 AI를 제대로 활용하는 게임 개발은:
개발자
│
Game Design
│
▼
LLM Wiki
│
▼
AI Agent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Cursor MCP Git
│ │
▼ ▼
C# Code Unity
│ │
└──────┬──────┘
▼
Play Test
│
▼
Feedback
│
└──────────→ AI
이렇게 된다.
마무리
게임 개발이 Vibe Coding만으로 어려운 이유는 명확하다.
게임은 코드가 아니기 때문이다.
게임은 코드뿐만 아니라 Scene, GameObject, Component, Asset, Animation, Physics, UI, Audio, 데이터, 아키텍처, 게임 디자인, UX, 성능, 그리고 플레이어 경험까지 결합된 결과물이다.
AI는 이 과정의 상당 부분을 도와줄 수 있다.
하지만 AI에게 단순히 코드를 생성하게 하는 것만으로는 부족하다.
AI가 프로젝트의 구조를 이해하고, 프로젝트의 규칙을 알고, 실제 Unity Editor를 확인하고, Scene과 GameObject를 조작하고, 코드를 수정하고, 테스트하고, 결과를 다시 분석할 수 있어야 한다.
그래서 앞으로의 AI 게임 개발은 단순한 Vibe Coding보다
LLM + AI Agent + Cursor + Unity MCP + LLM Wiki + Git + 자동 테스트
를 하나의 개발 환경으로 묶는 방향에 가까워질 것이다.
AI에게 게임을 통째로 만들어 달라고 하는 것이 아니다.
게임을 만드는 과정 자체를 AI가 참여할 수 있는 구조로 만드는 것이다.
이것이 현재 Unity에서 AI를 활용하여 게임을 개발하는 가장 현실적인 방향이라고 생각한다.