코드 제안에서 에디터 작업으로 넘어가기
앞 장에서는 Unity AI를 코드 작성 파트너로 사용하는 방법을 다뤘다. AI에게 구현 방향을 묻고, 초안 코드를 만들고, 콘솔 오류를 함께 분석하는 흐름이었다. 이 방식만으로도 반복 시간은 꽤 줄어든다. 하지만 여전히 사람이 직접 해야 하는 일이 남는다.
코드를 복사해 붙여 넣고, 스크립트를 저장하고, GameObject를 선택하고, 컴포넌트를 붙이고, Inspector 값을 채우고, Play Mode에서 확인하는 일이다. 기능 하나를 만들 때마다 이 과정이 반복된다.
Unity MCP는 이 간격을 줄이기 위한 연결 방식이다. Unity 문서에서는 외부 AI 클라이언트가 Unity Editor에 연결되어 씬, 에셋, 스크립트, 콘솔 출력 같은 프로젝트 정보를 도구 형태로 사용할 수 있다고 설명한다.1 즉 AI가 단순히 "이 코드를 넣어 보세요"라고 말하는 단계에서, "이 스크립트를 만들고, 이 오브젝트에 붙이고, 콘솔 결과를 확인하겠습니다"에 가까운 작업 흐름으로 확장된다.
단, 이것은 자동으로 안전해진다는 뜻이 아니다. 에디터를 직접 바꾸는 권한이 생기는 만큼 작업 범위, 승인 절차, 변경 검토가 더 중요해진다.
AI 생성 이미지
MCP를 Unity 프로젝트 예시로 이해하기
MCP는 Model Context Protocol의 약자다. 쉽게 말하면 AI 클라이언트와 작업 도구 사이에서 "어떤 기능을 호출할 수 있는지"를 정해 주는 약속이다. MCP 자체는 Unity 전용 기술이 아니지만, Unity MCP는 이 약속을 Unity Editor 작업에 맞게 적용한 사례라고 보면 된다.
Unity 프로젝트에서는 보통 다음 구조로 이해하면 된다.
AI 클라이언트: Claude Code, Cursor, Windsurf, VS Code Copilot, Claude Desktop처럼 사용자가 대화하거나 명령을 내리는 도구
릴레이 또는 MCP 서버 프로세스: AI 클라이언트의 요청을 받아 Unity 쪽으로 전달하는 중간 통로. Unity 문서에서는 사용자의 관점에서 Unity가 외부 클라이언트에 도구를 노출하는 MCP 서버 역할을 한다고 설명하지만, 실제 연결 경로에는 클라이언트가 실행하는 릴레이 프로세스가 포함된다.
Unity Editor의 MCP Bridge: Unity 안에서 실제 프로젝트 상태를 읽고, 허용된 작업을 실행하는 연결 지점
MCP 도구: 씬 계층 읽기, 콘솔 로그 확인, 스크립트 생성, GameObject 수정 같은 개별 기능
조금 더 풀어 말하면, AI 클라이언트가 Unity를 직접 만지는 것이 아니다. AI 클라이언트는 MCP 프로토콜로 릴레이에 요청을 보내고, 릴레이는 Unity Editor 안의 MCP Bridge와 통신한다. MCP Bridge는 등록된 도구 목록을 통해 씬, 에셋, 스크립트, 콘솔 같은 정보를 읽거나 변경한다. 그래서 사용자는 "AI가 Unity를 조작한다"고 느끼지만, 실제로는 Unity가 허용한 도구를 통해서만 작업이 일어난다.
예를 들어 인벤토리 화면에 ItemTooltipController를 추가한다고 해 보자.
기존 방식에서는 AI에게 코드를 받은 뒤 사람이 다음 일을 한다.
Unity에서 새 C# 스크립트를 만든다.
AI가 준 코드를 붙여 넣는다.
컴파일 오류를 확인한다.
Tooltip 패널 GameObject에 컴포넌트를 붙인다.
Text, Image, CanvasGroup 같은 참조를 Inspector에 연결한다.
Play Mode에서 아이템에 마우스를 올려 본다.
MCP를 사용하면 이 중 일부를 AI가 도구 호출로 처리할 수 있다. AI는 먼저 현재 씬 계층을 읽고, InventoryPanel 아래에 어떤 오브젝트가 있는지 확인한다. 그다음 필요한 스크립트를 만들고, 대상 GameObject에 컴포넌트를 붙인다. 마지막으로 콘솔 오류를 읽어 수정할 수 있다. Unity가 공개한 시작 안내에서도 AI 에이전트가 실행 중인 Unity 프로젝트의 씬 계층, GameObject, 컴포넌트 값, 콘솔 메시지, 빌드 설정 등을 실시간 문맥으로 사용할 수 있다고 설명한다.2
핵심은 AI가 Unity를 직접 "보는" 것이 아니라, Unity가 허용한 도구를 통해 프로젝트 정보를 읽고 변경한다는 점이다. 그래서 MCP 자동화의 품질은 AI 모델만이 아니라 도구 설명, 권한 설정, 프로젝트 구조, 사용자의 승인 규칙에 크게 좌우된다.
Unity MCP의 기본 작업 루프
처음부터 "전투 시스템을 전부 만들어 줘"라고 요청하면 실패하기 쉽다. MCP는 작은 작업을 반복할 때 가장 안정적이다. 다음 루프를 기본 단위로 삼는 것이 좋다.
1단계: 읽기 전용으로 현재 상태 확인하기
처음 요청은 수정이 아니라 확인이어야 한다.
목표: 현재 열려 있는 Unity 씬의 UI 구조를 파악한다.
제약: 파일 생성, 삭제, 씬 수정은 하지 않는다.
확인할 것: 씬 계층, 선택된 GameObject, 콘솔의 오류와 경고.
출력: 수정 제안 없이 현재 상태 요약만 작성한다.이 단계에서 AI는 씬 계층, 관련 GameObject, 콘솔 오류를 읽는다. 여기서부터 잘못된 결과가 나오면 이후 자동화도 위험하다. 예를 들어 AI가 현재 씬을 잘못 인식하거나, 다른 Unity 인스턴스에 연결되어 있다면 즉시 중단해야 한다.
2단계: 실행 계획을 먼저 받기
상태 확인이 끝나면 바로 수정하지 말고 계획을 받는다.
목표: InventoryItem에 마우스를 올리면 TooltipPanel이 표시되게 한다.
현재 상태: TooltipPanel은 씬에 있고 비활성화되어 있다. InventoryItem 프리팹에는 Button 컴포넌트가 있다.
제약: 기존 InventoryManager 코드는 수정하지 않는다. 새 스크립트는 Assets/Scripts/UI 안에만 만든다.
검증 기준: 컴파일 오류가 없어야 하고, Play Mode에서 hover 시 TooltipPanel이 켜지고 벗어나면 꺼져야 한다.
먼저 실행 계획만 작성하고, 파일이나 씬은 수정하지 않는다.좋은 계획은 변경 파일, 수정할 GameObject, 연결할 컴포넌트, 테스트 방법을 포함한다. 계획에 "관련 스크립트를 모두 정리한다"처럼 범위가 큰 문장이 들어 있으면 줄여야 한다.
3단계: 스크립트 작성과 컴포넌트 부착을 나누기
AI가 한 번에 코드 작성, 씬 수정, 테스트까지 수행하면 문제가 생겼을 때 원인을 추적하기 어렵다. 먼저 스크립트만 만들게 한다.
위 계획 중 1단계만 실행한다.
Assets/Scripts/UI/ItemTooltipController.cs 파일을 생성한다.
씬, 프리팹, Project Settings는 수정하지 않는다.
생성 후 컴파일 오류가 있는지 콘솔을 확인하고 요약한다.스크립트가 정상적으로 컴파일되면 다음에 컴포넌트를 붙인다.
이제 TooltipPanel GameObject에 ItemTooltipController를 부착한다.
Inspector 참조는 현재 씬에 존재하는 하위 오브젝트만 사용한다.
어떤 GameObject와 컴포넌트를 수정했는지 목록으로 보고한다.이렇게 나누면 문제가 생겼을 때 코드 오류인지, 씬 연결 오류인지 구분할 수 있다.
4단계: Play Mode 테스트와 콘솔 확인 연결하기
일부 환경에서는 MCP 도구나 클라이언트 구성에 따라 Play Mode 진입, 테스트 실행, 콘솔 확인까지 자동화할 수 있다. 반대로 Play Mode 제어 도구가 없거나 팀에서 쓰기 권한을 제한했다면 사람이 Play Mode를 실행하고 AI가 콘솔과 씬 상태만 읽게 해도 된다.
안전한 요청은 다음처럼 쓴다.
검증만 수행한다.
가능하면 Play Mode에 진입해 InventoryItem hover 동작을 확인한다.
Play Mode 제어 도구가 없으면 실행하지 말고, 내가 수동으로 테스트할 항목을 체크리스트로 작성한다.
테스트 후 콘솔 오류와 경고를 읽고, 새로 발생한 문제만 요약한다.여기서 중요한 것은 "가능하면"이라는 단어가 아니라 실패했을 때의 행동을 정하는 것이다. 도구가 없으면 임의로 다른 방법을 시도하지 말고 멈추게 해야 한다.
여러 AI 클라이언트가 같은 Unity 도구를 쓰는 구조
MCP의 장점은 원칙적으로 특정 AI 클라이언트 하나에만 종속되지 않는다는 점이다. Unity 쪽에서는 도구를 제공하고, AI 클라이언트는 그 도구 목록을 발견한 뒤 필요한 도구를 호출한다. Unity 문서에서도 Unity가 도구를 노출하고, 외부 AI 클라이언트가 그 도구를 발견해 요청을 보내는 구조라고 설명한다.1
다만 실제로 어떤 클라이언트를 자동 구성할 수 있는지, 어느 클라이언트에서 도구 호출이 안정적으로 동작하는지는 Unity 버전, AI Assistant 패키지 버전, 클라이언트 버전에 따라 달라질 수 있다. 따라서 "MCP를 지원한다"는 말만 믿기보다, 현재 프로젝트에서 연결과 도구 호출이 실제로 되는지 먼저 확인해야 한다.
클라이언트별 차이는 주로 사용 경험과 설정 방식에 있다.
| 클라이언트 | 강점 | 주의할 점 |
|---|---|---|
| Claude Code | 터미널 기반 작업, 코드 읽기와 수정 계획 수립에 강하다. | 프로젝트 경로, MCP 설정, Unity 승인 상태를 확인해야 한다. |
| Cursor | IDE 안에서 코드 diff를 보며 수정하기 좋다. | Unity에 연결된 프로젝트와 Cursor가 연 폴더가 같은지 확인해야 한다. |
| Windsurf 또는 Claude Desktop | MCP 클라이언트 설정을 통해 외부 도구를 붙이는 흐름에 익숙한 사용자에게 적합하다. | Unity가 제공하는 자동 구성 대상인지, 수동 릴레이 설정이 필요한지 확인해야 한다. |
| VS Code Copilot | 기존 VS Code 사용자에게 익숙하고 작은 코드 수정 흐름에 맞다. | MCP 연동 방식과 사용 가능한 도구 범위가 환경에 따라 다를 수 있다. |
| 기타 MCP 호환 클라이언트 | 팀이 이미 쓰는 AI 환경을 유지하면서 Unity 도구를 붙일 수 있다. | Unity MCP 도구 호출, 승인 절차, 파일 diff 확인이 가능한지 먼저 검증해야 한다. |
여기서 중요한 판단 기준은 "어느 모델이 더 똑똑한가"가 아니다. 팀이 확인해야 할 것은 다음이다.
이 클라이언트가 현재 Unity 프로젝트에 정확히 연결되는가?
도구 호출 전에 사용자의 승인을 요구하는가?
파일 diff를 사람이 검토하기 쉬운가?
씬, 프리팹, Project Settings 같은 위험한 변경을 제한할 수 있는가?
콘솔 오류와 테스트 결과를 다시 읽어 검증할 수 있는가?
AI 클라이언트를 바꾸더라도 Unity 쪽 자동화 도구가 같다면 기본 작업 규칙은 유지된다. 이것이 MCP 기반 워크플로의 실무적 장점이다.
씬을 수정하기 전 반드시 거칠 안전 규칙
MCP 자동화에서 가장 위험한 순간은 AI가 씬과 프리팹을 수정할 때다. C# 파일은 diff를 읽기 쉽지만, Unity 씬과 프리팹 파일은 직렬화된 YAML 형태라 변경 범위가 크게 보일 수 있다. 작은 Inspector 수정도 많은 줄의 diff로 나타날 수 있다.
따라서 다음 규칙을 팀 기본값으로 삼는 것이 좋다.
Git 상태를 먼저 깨끗하게 만든다
AI에게 쓰기 작업을 맡기기 전에는 Git 상태를 확인한다. AI 클라이언트가 터미널이나 Git 도구를 함께 사용할 수 있다면 AI에게 확인을 맡길 수 있지만, 그렇지 않다면 사람이 직접 확인해도 된다. 중요한 것은 자동화가 시작되기 전에 기준점을 만드는 것이다.
작업 전 규칙:
1. 현재 Git 변경 사항을 확인한다.
2. 변경 사항이 있으면 작업을 중단하고 사용자에게 보고한다.
3. 새 작업은 ai/mcp-tooltip-test 브랜치에서만 진행한다.
4. 커밋되지 않은 씬 수정이 있으면 씬을 저장하거나 되돌리기 전까지 수정하지 않는다.작업 전의 깨끗한 Git 상태는 되돌릴 수 있는 기준점이다. AI가 잘못 수정했을 때 "무엇이 바뀌었는지"를 빠르게 비교할 수 있다.
프리팹과 씬은 작은 단위로만 수정한다
AI에게 "UI 전체를 정리해 줘"라고 요청하면 프리팹, 씬, 스크립트가 동시에 바뀔 수 있다. 대신 대상 하나만 지정한다.
이번 작업에서는 Assets/Prefabs/UI/InventoryItem.prefab만 수정한다.
다른 프리팹, 씬 파일, Project Settings는 수정하지 않는다.
수정 전 현재 컴포넌트 목록을 보고하고, 승인 후 진행한다.중요한 프리팹이라면 복제본에서 먼저 테스트한다.
InventoryItem.prefab을 직접 수정하지 않는다.InventoryItem_MCP_Test.prefab을 만들어 실험한다.정상 동작을 확인한 뒤 사람이 원본에 반영한다.
이 방식은 느려 보이지만, 팀 프로젝트에서는 훨씬 안전하다.
diff 확인을 자동화 루프에 포함한다
작업이 끝난 뒤에는 AI에게 결과 요약만 받지 말고 변경 목록을 요구한다.
작업 결과를 보고한다.
다음 항목을 구분해서 작성한다.
1. 생성한 파일
2. 수정한 파일
3. 수정한 GameObject
4. 추가하거나 제거한 컴포넌트
5. Inspector에서 변경한 필드
6. 콘솔 오류와 경고
아직 커밋하지 않는다.그다음 사람이 Git diff, Unity Inspector, Play Mode 결과를 확인한다. AI의 "성공했습니다"라는 문장은 검증 결과가 아니다. 검증은 콘솔, 테스트, 실제 플레이, diff 리뷰로 확인해야 한다.
실패했을 때 점검할 것
MCP 연결은 여러 층으로 이루어진다. 문제가 생겼을 때는 모델을 탓하기 전에 연결 상태부터 확인한다.
Unity Editor가 실행 중인가?
Unity MCP Bridge가 켜져 있는가?
AI 클라이언트의 MCP 설정이 올바른 Unity 프로젝트를 가리키는가?
Unity의 Project Settings에서 첫 연결 승인 요청이 대기 중이지 않은가?
여러 Unity 인스턴스가 떠 있어 잘못된 프로젝트에 연결된 것은 아닌가?
Unity가 스크립트 컴파일 중이라 도구 호출에 실패한 것은 아닌가?
콘솔에 이전 오류가 남아 있어 새 오류와 섞인 것은 아닌가?
Unity, AI Assistant 패키지, AI 클라이언트 버전이 서로 호환되는가?
특히 첫 테스트는 단순해야 한다.
Unity 콘솔 메시지를 읽고 오류와 경고를 요약해 줘.
파일이나 씬은 수정하지 마.이 요청이 실패하면 자동화 작업을 시작하지 않는다. 읽기 작업이 안정적이어야 쓰기 작업도 안전하다.
MCP 자동화의 적절한 사용 범위
Unity MCP는 반복 작업에 강하다.
새 스크립트 생성
컴포넌트 부착
Inspector 필드 연결
씬 계층 확인
콘솔 오류 요약
간단한 테스트 루프 반복
빌드 설정이나 플랫폼 정보 확인
반대로 다음 판단은 사람이 해야 한다.
이 기능이 게임 감각에 맞는가?
UI 흐름이 플레이어에게 자연스러운가?
자동으로 붙인 컴포넌트 구조가 장기 유지보수에 적합한가?
씬 변경이 팀의 프리팹 규칙을 어기지 않았는가?
테스트가 실제 사용자 행동을 충분히 대표하는가?
MCP는 Unity Editor를 다루는 손을 하나 더 붙여 주는 방식에 가깝다. 하지만 무엇을 만들지, 어떤 변경을 승인할지, 결과가 충분히 좋은지는 여전히 사람이 결정해야 한다.
정리
Unity MCP의 핵심은 AI가 Unity 프로젝트를 도구 호출로 읽고 수정할 수 있게 만드는 데 있다. AI 클라이언트는 바뀔 수 있지만, 씬 계층 읽기, 스크립트 생성, 컴포넌트 수정, 콘솔 확인 같은 자동화 단위는 동일한 원칙으로 운영된다.
실무에서는 작은 작업 단위, 읽기 우선, 계획 승인, Git 기준점, 프리팹 백업, diff 검토가 기본이다. 이 규칙이 있어야 AI가 에디터 안에서 실제 작업을 수행해도 프로젝트를 통제할 수 있다.
다음 단계에서는 같은 관점을 Unreal로 확장해 보자. 엔진은 달라져도 원칙은 같다. AI에게 에디터 권한을 줄수록, 자동화보다 먼저 작업 경계와 검증 기준을 설계해야 한다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.