AI로 게임 개발하기 1일차 — Unity와 AI를 연결한 이유

AI에게 “게임 하나 만들어 줘”라고 요청한다고 바로 플레이 가능한 게임이 나오지는 않는다. Unity 안의 씬과 에셋을 AI가 볼 수 있어야 하고, 무엇을 먼저 만들지 정하는 기준도 필요하다.

1일차 목표는 코드를 많이 만드는 것이 아니라 AI가 Unity를 조작할 통로를 만들고, 내가 중간 결과를 검토하는 작업 순서를 세우는 것이었다. 이 글에서는 당시 사용한 Unity MCP와 역할별 프롬프트가 그 흐름에서 각각 무슨 일을 했는지 설명한다.

이 글의 설치 화면과 설정값은 2026년 2월 작업 당시 기준이다. 도구 버전이 바뀌면 메뉴 이름이나 연결 방식도 달라질 수 있으므로 실제 설치 전에는 각 도구의 최신 문서를 함께 확인해야 한다.

먼저 알아둘 용어 세 가지

Unity: 게임 화면, 오브젝트, 물리, 빌드 과정을 관리하는 게임 엔진이다.
LLM: Claude처럼 글과 코드를 생성하는 대규모 언어 모델을 뜻한다.
MCP(Model Context Protocol): AI 도구와 외부 프로그램 사이에서 필요한 정보와 명령을 주고받는 연결 규칙이다. 여기서는 AI가 Unity 에디터의 상태를 읽고 작업을 요청하는 통로로 사용했다.

MCP가 없으면 AI가 작성한 코드를 사람이 Unity로 옮기고 결과를 다시 설명해야 한다. MCP를 연결하면 이 왕복 과정의 일부를 줄일 수 있다. 다만 AI가 Unity를 직접 조작할 수 있다는 뜻이지, 결과가 자동으로 옳아진다는 뜻은 아니다.

당시에는 Unity MCP를 Unity와 Cursor에 연결했다. 작업 순서는 다음과 같았다.

당시 사용한 패키지 주소를 입력한다.

https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#beta

Cursor의 MCP 클라이언트 설정에 Unity 서버 주소를 등록한다.

{
  "mcpServers": {
    "unityMCP": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

처음부터 씬 전체를 수정하게 하지 않은 이유는 연결 성공과 작업 정확도를 따로 확인하기 위해서다. 큐브 하나도 만들지 못하면 설정 문제이고, 큐브는 만들지만 위치가 틀리면 지시나 도구 사용 문제다.

초기에는 PM, 게임 기획자, 디자이너, Unity 개발자, QA 역할을 각각 프롬프트로 만들었다. 여기서 PM은 제품 관리자(Product Manager), QA는 품질 보증(Quality Assurance)을 뜻한다.

역할을 나눈 목적은 AI를 여러 명처럼 보이게 만드는 데 있지 않았다. “좋은 게임을 만들어 줘”처럼 범위가 큰 요청을, 답을 확인할 수 있는 작은 질문으로 바꾸는 데 있었다.

다만 모든 요청에 다섯 역할을 동원하면 대화와 문서만 늘어난다. 구현 방법이 분명한 작은 수정은 Unity 개발자 역할 하나로 처리하고, 기획과 구현이 얽힌 기능에서만 역할을 나눴다.

1인 인디 모바일 게임 개발 파트너 시스템 - 활성화된 전문 역할

첫 게임은 Vampire Survivors처럼 캐릭터가 자동 공격하고 플레이어가 이동과 업그레이드 선택에 집중하는 2D 생존 게임으로 정했다. 이런 유형을 흔히 뱀서라이크라고 부른다.

기획서에는 핵심 플레이 흐름과 첫 프로토타입의 범위만 남겼다.

이 문서를 공통 기준으로 두면 기획자는 없는 기능을 전제로 설명하지 않고, 개발자는 범위 밖 시스템을 먼저 만들지 않으며, QA도 같은 완료 조건으로 검사할 수 있다. 문서의 길이보다 모든 작업자가 같은 범위를 보고 있다는 점이 중요했다.

계획 정리
  ↓
내가 범위 확인
  ↓
기능 구현
  ↓
Unity에서 직접 실행
  ↓
오류 수정과 다시 실행
  ↓
내가 다음 작업 결정

AI가 다음 단계를 스스로 계속 진행하게 두지 않고, 계획과 구현 사이에 사용자 확인을 넣었다. 기능이 많아질수록 앞 단계의 작은 오해가 뒤에서 큰 재작업으로 이어지기 때문이다.

첫날에는 연결 환경과 기획 기준을 만드는 데 집중했다. 이 덕분에 다음 작업부터는 “게임을 만들어 줘”가 아니라 “플레이어 이동을 구현하고 Unity에서 입력을 확인하자”처럼 결과를 검증할 수 있는 단위로 요청할 수 있었다.

1일차의 성과는 기능 개수가 아니라, AI의 제안과 Unity의 실제 실행 결과 사이에 사용자 검토가 끼어 있는 개발 흐름을 만든 것이다.