Unity Cli, 새로운 게임 프로그래밍 시대를 여는 것인가?

Unity CLI가 나왔습니다. 저는 그동안 유니티 MCP를 꽤 오래 써왔고, 그 한계를 몸으로 겪은 쪽입니다. 이 글에서는 제가 MCP로 작업하며 어디서 막혔는지, Unity CLI가 그 지점을 실제로 건드리는지, 그리고 지금 붙여서 써본 소감을 정리합니다. 인디 개발자들이 왜 Godot으로 넘어갔는지도 같이 다룹니다. 결론부터 말하면 저는 이 변화를 적극 지지하지만, 아직 다 왔다고는 보지 않습니다.

유니티 MCP를 쓰면서 계속 걸렸던 것

MCP를 붙이면 처음엔 신기합니다. 채팅으로 스크립트가 생기고 씬에 오브젝트가 올라갑니다. 문제는 그다음입니다.

제가 실제로 막힌 지점은 세 가지였습니다.

에디터 UI 제어가 안 됨. 인스펙터의 특정 input 필드나 체크박스 하나를 켜고 끄는 일. 이게 컨트롤이 안 됐습니다. 결국 제가 에디터를 열고 손으로 눌러야 했습니다.
디테일한 지시가 어려움. LLM 성능 이슈가 겹치면서, 설명을 아주 길게 붙이지 않으면 원하는 결과가 안 나왔습니다.
그렇게 해서 나온 결과물도 실망스러웠음. 프롬프트에 쓴 시간 대비 산출물이 안 맞았습니다.

이 세 개가 겹치면 “AI가 만들어준다"는 느낌이 아니라 “AI에게 설명하느라 내가 더 일한다"는 느낌이 됩니다. 그 시점에 저는 MCP만으로는 안 되겠다고 판단했습니다.

인디 개발자들이 Godot으로 간 이유

주변을 보면 인디 개발자 상당수가 유니티를 떠나 Godot으로 갔습니다. 라이선스 이슈도 있었지만, 제가 본 최근의 이유는 다릅니다. CLI 명령 컨트롤로 엔진 기능 대부분을 다룰 수 있기 때문입니다.

Claude Code나 Codex 같은 도구를 붙였을 때 차이가 확 납니다. 에이전트가 텍스트 명령만으로 끝까지 갈 수 있는 엔진과, 중간에 사람이 마우스로 개입해야 하는 엔진은 작업 흐름이 완전히 다릅니다.

이건 저만의 인상이 아닙니다. Unity CLI를 오픈소스 모델에 붙여 테스트한 Stefan 3D AI의 영상에서도 같은 이야기가 나옵니다. 이 영상 제작자는 언리얼 엔진으로 동일한 핑퐁 게임을 만들어봤는데, Unity CLI로는 두 번의 프롬프트로 끝난 작업이 언리얼에서는 훨씬 많은 시간과 수정을 요구했다고 설명합니다. 나이아가라 이펙트 테스트에서는 에디터가 세 번 크래시했고 총 7시간이 걸렸다고 합니다. 그리고 “에이전틱 접근에서는 코드 우선 엔진이 훨씬 낫다"며 언리얼 테스트를 중단했다고 밝힙니다.

블루프린트 스파게티를 스크린샷 찍어가며 AI에게 설명하는 작업. 해보신 분은 아실 겁니다. 그게 왜 안 되는지.

Unity CLI가 실제로 바꾸는 지점

유니티는 6.0 버전부터 CLI 기능을 넣었습니다. 이건 사실상 MCP에 대한 유니티의 직접적인 공식 지원입니다. 그동안 커뮤니티가 알아서 붙이던 것을 엔진 제작사가 자기 손으로 만들기 시작한 것입니다.

공식 문서를 보면 CLI의 성격이 분명합니다. Unity Hub 데스크톱 앱 없이 터미널만으로 에디터를 설치하고, 모듈을 추가하고, 프로젝트를 여는 독립 실행 바이너리입니다. 문서는 이걸 CI 파이프라인, 자동화 스크립트, 터미널 우선 워크플로에 적합하다고 소개합니다. 참고로 문서에는 CLI가 아직 experimental 단계라고 명시돼 있습니다.

기본 명령은 이 정도로 단순합니다.

명령	하는 일
`unity install lts`	최신 LTS 에디터 설치
`unity install-modules -e 6000.3.7f1 -m ios`	특정 에디터에 iOS 모듈 추가
`unity editors -i`	설치된 에디터 목록 확인
`unity open ./MyProject`	프로젝트 열기
`unity auth login`	계정 로그인
`unity doctor`	진단 정보 출력

중요한 건 그다음입니다. CLI로 에디터 자체를 제어하려면 Unity Pipeline 패키지를 따로 설치해야 합니다. 문서에도 그렇게 안내돼 있고, 앞의 영상에서도 패키지 매니저에서 com.unity.pipeline을 설치하는 과정이 나옵니다. 이 패키지가 깔려야 에이전트가 해당 프로젝트에 접근할 수 있습니다. CLI 설치와 에디터 제어는 별개의 단계라는 뜻입니다.

엔진을 켜지 않고 엔진을 다룰 수 있어야 한다

저는 여기에 대해 분명한 관점이 있습니다. 엔진을 켜지 않고도 엔진을 다룰 수 있어야 진정한 AI 시대의 게임 엔진입니다.

이유는 간단합니다. 에이전트에게 GUI는 병목입니다. 화면을 캡처하고, 좌표를 찍고, 결과를 다시 스크린샷으로 확인하는 루프는 느리고 부정확합니다. 앞의 영상에서도 언리얼 테스트가 오래 걸린 원인으로 “스스로 확인하려고 스크린샷을 찍는데 그 과정이 길다"는 점을 지적합니다. 반대로 텍스트 인터페이스는 에이전트가 읽고 쓰기에 최적화돼 있습니다.

요즘 개발자들이 에디터조차 지우고 있는 판입니다. 코드를 눈으로 들여다보지 않아도 되는 바이브 코딩, 하네스 코딩 시대가 왔기 때문입니다. 저는 이 흐름이 되돌아가지 않는다고 봅니다. 그렇다면 엔진도 그 흐름에 맞춰 인터페이스를 바꿔야 합니다.

유니티는 그 기반 작업을 시작했습니다. 환영합니다.

Claude Code에 붙여서 써본 소감

Claude Code 터미널 시작 화면

저는 Unity CLI를 Claude Code에 붙여서 이것저것 시도해보고 있습니다. 솔직히 재미있습니다. MCP만 쓰던 시절과 비교하면 왕복 횟수가 줄고, 손이 덜 갑니다.

다만 아직 지원이 완벽하지 않습니다. 더 디테일한 부분의 지원이 이뤄져야 한다고 봅니다. 제가 MCP에서 겪었던 “체크박스 하나 못 건드리는” 문제가 완전히 사라졌다고 말하기는 이릅니다. 문서에도 experimental이라고 적혀 있으니 당연한 일이기도 합니다.

앞의 영상이 공개한 실측 수치도 참고할 만합니다. 스택 게임은 프롬프트 2회에 2시간 17분, 335회 모델 호출, API 기준 약 10달러였습니다. 크로스로드 게임은 프롬프트 4회에 5시간, 544회 호출, 약 23달러였습니다. 타워 디펜스는 3회 프롬프트에 약 4시간, 455회 호출, 약 14달러였습니다. 수박 게임(Suika) 테스트에서는 병합이 끝내 동작하지 않았다고 솔직하게 적고 있습니다.

이 숫자를 어떻게 볼지는 갈립니다. 저는 “간단한 게임 하나에 몇 시간"이라는 점보다 사람이 그 시간 동안 다른 일을 할 수 있다는 점이 핵심이라고 봅니다. 다만 지금 단가로 상업 프로젝트 전체를 돌리기엔 이릅니다. 프로토타입과 실험용으로 보는 게 맞습니다.

지금 시작해보려는 분을 위한 체크리스트

제가 겪은 순서대로 정리하면 이렇습니다.

Unity 6 버전대 프로젝트를 준비합니다. CLI 연동은 이 버전대에서 지원됩니다.
터미널(윈도우는 PowerShell)에서 설치 스크립트로 Unity CLI를 설치합니다. macOS/Linux는 Homebrew(brew install --cask unity-cli), 리눅스는 apt/rpm 저장소도 지원됩니다.
unity --version으로 설치를 확인합니다. 명령을 못 찾으면 PATH를 확인하거나 터미널을 다시 엽니다.
unity auth login으로 로그인합니다. unity auth status로 상태를 확인할 수 있습니다.
프로젝트의 패키지 매니저에서 com.unity.pipeline을 설치합니다. 이게 있어야 에디터 제어가 열립니다.
unity editors 계열 명령으로 CLI가 내 프로젝트를 인식하는지 확인합니다.
사용하는 에이전트에 MCP 설정을 붙입니다. unity mcp configure 계열 명령이 지원하는 클라이언트라면 자동으로, 아니면 MCP 설정 파일을 직접 작성합니다.

앞의 영상 제작자는 지원 목록에 없는 클라이언트를 쓰느라 MCP JSON을 직접 만들었는데, 연결 자체는 문제 없이 됐다고 합니다. 자동 설정이 안 되는 도구를 쓰더라도 크게 걱정할 부분은 아니라는 뜻입니다.

cli는 만병 통치약인가?

특히 Unity Pipeline과 MCP를 이용하면 외부 프로그램이나 AI가 실행 중인 Unity Editor에 명령을 전달할 수 있습니다. 그렇다면 Unity CLI의 Pipeline만 설치하면 사람이 Editor에서 하는 모든 작업을 자동으로 처리할 수 있을까요?

결론부터 말씀드리면 그렇지는 않습니다.

Unity Pipeline은 Unity Editor의 모든 버튼을 대신 클릭해 주는 GUI 자동화 도구가 아닙니다. 외부 프로그램이 Unity Editor에 등록된 명령을 호출할 수 있도록 연결해 주는 통신 계층에 가깝습니다.

Unity Pipeline이란 무엇인가요?

Unity Pipeline은 외부 프로그램에서 실행 중인 Unity Editor를 제어할 수 있도록 Unity가 제공하는 공식 패키지입니다.

전체 구조는 다음과 같습니다.

터미널 또는 AI 에이전트 ↓ Unity CLI / MCP ↓ Unity Pipeline ↓ 등록된 C# Editor 명령 ↓ Unity Editor API ↓ 씬, GameObject, Component, 에셋 변경

Unity Pipeline은 로컬 HTTP API를 통해 CLI의 요청을 Unity Editor로 전달합니다. 이를 이용하면 빌드, 테스트, 개발 자동화 작업과 사용자 정의 Editor 명령을 외부에서 실행할 수 있습니다.

1
2
unity auth login
unity pipeline install

Pipeline 패키지를 설치하고 프로젝트 컴파일이 완료되면 다음 명령으로 연결 상태를 확인할 수 있습니다.

1
2
unity pipeline list
unity status

Editor가 외부에 제공하는 명령은 다음과 같이 조회할 수 있습니다.

1
2
unity command
unity list

Pipeline은 명령을 실행하는 통로입니다

Unity Pipeline을 이해할 때 가장 중요한 점은 Pipeline 자체가 모든 Unity 작업을 제공하는 것은 아니라는 사실입니다.

Pipeline의 핵심 역할은 외부 요청을 Unity Editor에 전달하는 것입니다. 실제로 GameObject를 만들거나 Component를 추가하고 속성을 변경하는 작업은 Unity Editor API 또는 직접 작성한 C# Editor 코드가 담당합니다.

예를 들어 Player GameObject에 Rigidbody를 추가하려면 다음과 같은 기능을 Editor 명령으로 구현해야 합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
using System;
using UnityEditor;
using UnityEngine;

public static class ComponentCommands
{
    public static void AddComponent(
        string objectName,
        string componentTypeName)
    {
        GameObject target = GameObject.Find(objectName);

        if (target == null)
            throw new Exception($"GameObject not found: {objectName}");

        Type componentType = FindComponentType(componentTypeName);

        if (componentType == null ||
            !typeof(Component).IsAssignableFrom(componentType))
        {
            throw new Exception(
                $"Invalid component type: {componentTypeName}");
        }

        if (target.GetComponent(componentType) != null)
            return;

        Undo.AddComponent(target, componentType);

        EditorUtility.SetDirty(target);
        UnityEditor.SceneManagement.EditorSceneManager
            .MarkSceneDirty(target.scene);
    }

    private static Type FindComponentType(string typeName)
    {
        foreach (var assembly in AppDomain.CurrentDomain.GetAssemblies())
        {
            Type type = assembly.GetType(typeName);

            if (type != null)
                return type;
        }

        return null;
    }
}

이 기능을 Pipeline 명령으로 등록하면 CLI나 AI 에이전트에서 다음과 같은 형태로 호출할 수 있습니다.

1
2
3
unity command add-component \
  --object-name Player \
  --component-type UnityEngine.Rigidbody

단, 위 명령은 개념적인 예시입니다. 실제 명령 이름과 옵션은 Pipeline에 등록한 명령의 스키마에 따라 달라집니다.

Inspector 체크박스도 변경할 수 있을까요?

가능합니다.

다만 화면에 보이는 체크박스를 마우스로 직접 누르는 방식이 아니라, 체크박스가 연결된 프로퍼티를 코드로 변경하는 방식입니다.

예를 들어 Light Component의 활성화 체크박스는 다음과 같이 변경할 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Light light = target.GetComponent<Light>();

Undo.RecordObject(light, "Toggle Light");
light.enabled = false;

EditorUtility.SetDirty(light);
EditorSceneManager.MarkSceneDirty(target.scene);

Inspector에 표시되는 직렬화된 bool 필드는 SerializedObject와 SerializedProperty를 이용해 변경할 수 있습니다.

var serializedObject = new SerializedObject(component);
var property = serializedObject.FindProperty("someBooleanField");

property.boolValue = true;
serializedObject.ApplyModifiedProperties();

EditorUtility.SetDirty(component);

이 방법으로 다음과 같은 항목을 제어할 수 있습니다.

GameObject 활성화 상태 Component의 enabled 상태 MonoBehaviour의 직렬화된 bool 필드 ScriptableObject 설정 Prefab에 저장된 프로퍼티 Player Settings와 Build Settings Material 및 에셋 설정

중요한 것은 변경 후 저장 처리입니다. 에셋을 수정했다면 AssetDatabase.SaveAssets()를 호출해야 하며, 씬 오브젝트를 수정했다면 씬을 dirty 상태로 표시한 후 저장해야 합니다.

어떤 기능까지 자동화할 수 있을까요?

Unity의 공개 Editor API로 처리할 수 있는 작업은 상당 부분 자동화할 수 있습니다.

대표적인 예시는 다음과 같습니다.

GameObject 생성, 삭제 및 복제 GameObject 계층 구조 변경 Component 추가 및 제거 Component 속성 변경 씬 열기, 생성 및 저장 Prefab 생성 및 수정 Material과 Texture 설정 ScriptableObject 생성 및 편집 패키지와 에셋 관리 프로젝트 빌드 Edit Mode 및 Play Mode 테스트 실행 메뉴 명령 실행 사용자 정의 개발 도구 실행

Unity 메뉴 중 일부는 다음 API로 실행할 수도 있습니다.

EditorApplication.ExecuteMenuItem(“File/Save”);

따라서 반복적인 프로젝트 설정이나 에셋 처리, 빌드와 테스트 같은 작업은 Pipeline과 Editor 스크립트를 결합했을 때 높은 수준으로 자동화할 수 있습니다.

모든 Editor 기능을 제어할 수 없는 이유

사람이 Unity Editor에서 할 수 있는 모든 행동이 공식 API로 제공되는 것은 아닙니다.

특히 다음 작업은 Pipeline만으로 처리하기 어렵습니다.

임의의 버튼과 창 클릭

Pipeline은 화면 좌표를 이용해 버튼을 누르는 GUI 자동화 도구가 아닙니다. 특정 버튼에 대응하는 Editor API나 명령이 없다면 Pipeline만으로 해당 버튼을 직접 클릭할 수 없습니다.

모달 팝업 처리

확인 대화상자, 파일 선택 창, 운영체제 권한 창처럼 사용자 입력을 기다리는 팝업은 자동화하기 어렵습니다. 특히 운영체제가 관리하는 창은 Unity Editor API의 범위를 벗어납니다.

Scene View의 수동 작업

Scene View에서 오브젝트를 드래그하거나 브러시로 지형을 칠하는 작업은 그대로 재현하기 어렵습니다.

대신 오브젝트의 위치, 회전, 스케일이나 Terrain 데이터를 코드로 직접 변경하는 명령을 만들어야 합니다.

Unity 내부 비공개 기능

공개 API가 없는 내부 Editor 상태는 안정적으로 제어할 수 없습니다. 리플렉션을 이용해 접근할 수도 있지만 Unity 버전이 변경되면 쉽게 동작하지 않을 수 있습니다.

서드파티 플러그인 창

외부 플러그인이 API나 자동화용 명령을 제공하지 않는다면 해당 플러그인의 EditorWindow를 제어하기 어렵습니다. 이 경우 플러그인의 공개 API를 사용하거나 별도의 연동 코드를 작성해야 합니다.

AI와 연결하면 무엇이 달라질까요?

Unity CLI는 MCP 서버 기능도 제공합니다.

MCP는 AI 에이전트가 외부 도구의 목록과 매개변수 구조를 발견하고 호출할 수 있게 해주는 표준 프로토콜입니다.

AI 에이전트 ↓ MCP Unity CLI ↓ Unity Pipeline ↓ Unity Editor 명령

예를 들어 다음과 같은 도구를 Pipeline에 등록할 수 있습니다.

create_game_object delete_game_object add_component remove_component set_component_property open_scene save_scene create_prefab modify_material build_project run_tests

이처럼 필요한 도구를 준비해 두면 사용자는 AI에 자연어로 요청할 수 있습니다.

Player 오브젝트에 Rigidbody를 추가하고 Use Gravity를 꺼주세요.

AI는 이 요청을 해석한 뒤 다음 작업으로 나눌 수 있습니다.

Player GameObject 탐색 Rigidbody Component 추가 useGravity 값을 false로 변경 씬 변경 사항 저장

하지만 AI가 Unity Editor의 모든 기능을 자동으로 이해하는 것은 아닙니다. AI가 실행할 수 있는 범위는 기본적으로 Pipeline을 통해 공개된 도구의 범위와 같습니다.

안정적인 자동화를 위한 설계

모든 작업을 처리하는 하나의 범용 명령을 만들기보다는 작업 단위가 분명한 명령을 제공하는 것이 좋습니다.

예를 들면 다음과 같습니다.

add_component set_serialized_property set_game_object_active create_prefab save_current_scene build_project run_editmode_tests

각 명령에는 다음 요소를 포함하는 것이 좋습니다.

명확한 입력값 대상 오브젝트 검증 실행 전 현재 상태 확인 Undo 지원 씬과 에셋 저장 처리 실패 원인을 포함한 오류 응답 동일한 명령을 다시 실행해도 문제가 생기지 않는 구조

GameObject를 이름으로만 찾는 방식도 피하는 것이 좋습니다. 같은 이름을 가진 오브젝트가 여러 개 존재할 수 있기 때문입니다.

Hierarchy 전체 경로나 GlobalObjectId처럼 대상을 명확하게 식별할 수 있는 값을 사용하는 편이 안전합니다.

그래서 새로운 시대인가

저는 “시대가 열렸다"보다 **“문이 열렸다”**가 정확한 표현이라고 생각합니다.

지금 Unity CLI는 완성품이 아닙니다. 실험 단계고, 제어 범위도 아직 좁습니다. 하지만 방향은 맞습니다. 엔진 제작사가 직접 텍스트 인터페이스를 만들기 시작했다는 사실 자체가 신호입니다. 커뮤니티 플러그인으로 버티던 단계와는 무게가 다릅니다.

제가 바라는 건 하나입니다. 빠른 시일 내에 CLI를 통해 유니티의 모든 기능에 접근하고 수정할 수 있게 되는 것. 인스펙터의 체크박스 하나까지 명령으로 닿을 수 있게 되면, 그때는 정말로 “엔진을 켜지 않고 게임을 만든다"는 말이 성립합니다.

지금 할 수 있는 일은 이것입니다. 작은 프로토타입 하나를 Unity CLI로 만들어보고, 어디서 막히는지 기록해두는 것. 그 기록이 다음 버전에서 무엇이 좋아졌는지 판단하는 기준이 됩니다.

마치며

유니티 MCP는 에디터 UI 제어 불가, 지시의 어려움, 결과물 품질이라는 세 가지 한계가 있었고, 이게 인디 개발자들이 Godot으로 옮겨간 배경입니다.
Unity CLI는 유니티 6.0부터 도입된 기능으로, MCP에 대한 엔진 제작사의 공식 지원이라는 의미가 큽니다.
공식 문서 기준 CLI는 아직 experimental이며, 에디터 제어에는 Unity Pipeline 패키지 설치가 별도로 필요합니다.
코드 우선 엔진이 에이전트 작업에 유리하다는 점은 언리얼과의 비교 테스트에서도 드러납니다.
저는 이 변화를 지지하지만, 지금은 프로토타입 단계로 보는 게 맞다고 봅니다. 지원 범위가 넓어지는 속도가 관건입니다.

자주 묻는 질문

Q. Unity CLI는 어떤 버전부터 쓸 수 있나요?

프로젝트 연동은 Unity 6 버전대에서 지원됩니다. CLI 바이너리 자체는 Unity Hub 없이 독립적으로 설치되며, 이를 통해 다른 버전의 에디터를 설치하는 것도 가능합니다.

Q. Unity CLI를 설치하면 바로 AI로 에디터를 제어할 수 있나요?

아니요. CLI 설치는 에디터 설치와 프로젝트 열기 같은 Hub 작업을 터미널에서 하는 단계까지입니다. 에디터 자체를 제어하려면 프로젝트에 Unity Pipeline 패키지(com.unity.pipeline)를 추가로 설치해야 합니다.

Q. Unity CLI가 있으면 유니티 MCP는 필요 없나요?

Unity CLI와 Pipeline 패키지 조합이 MCP 연동의 공식 경로가 됩니다. 에이전트 쪽에는 여전히 MCP 설정이 필요하고, unity mcp configure 계열 명령이 지원하는 클라이언트는 자동으로, 그렇지 않으면 설정 파일을 직접 작성하면 됩니다.

Q. Unity CLI로 게임 하나 만드는 데 비용이 얼마나 드나요?

공개된 테스트 기준으로 간단한 게임 하나에 API 비용 약 8~23달러, 소요 시간 1시간 30분에서 5시간 사이였습니다. 모델과 프롬프트 방식에 따라 편차가 크므로 참고 수치로만 보시는 게 좋습니다.

Q. 언리얼 엔진 대신 유니티를 써야 하나요?

AI 에이전트로 개발하는 상황에 한정하면 코드 우선 엔진 쪽이 유리합니다. 다만 이건 워크플로 선택의 문제이지 엔진의 우열 문제는 아닙니다. 팀의 기존 자산과 목표 플랫폼이 더 큰 변수입니다.

Unity Cli, 새로운 게임 프로그래밍 시대를 여는 것인가?#

유니티 MCP를 쓰면서 계속 걸렸던 것#

인디 개발자들이 Godot으로 간 이유#

Unity CLI가 실제로 바꾸는 지점#

엔진을 켜지 않고 엔진을 다룰 수 있어야 한다#

Claude Code에 붙여서 써본 소감#

지금 시작해보려는 분을 위한 체크리스트#

cli는 만병 통치약인가?#

그래서 새로운 시대인가#

마치며#

자주 묻는 질문#

Q. Unity CLI는 어떤 버전부터 쓸 수 있나요?#

Q. Unity CLI를 설치하면 바로 AI로 에디터를 제어할 수 있나요?#

Q. Unity CLI가 있으면 유니티 MCP는 필요 없나요?#

Q. Unity CLI로 게임 하나 만드는 데 비용이 얼마나 드나요?#

Q. 언리얼 엔진 대신 유니티를 써야 하나요?#

참고 자료#

이어서 읽어보세요