Unity CLI라는 이름을 처음 들으면 터미널에서 게임 전체를 만들 수 있다는 뜻인지, 기존 빌드 명령을 편하게 감싼 것인지 헷갈립니다. 이 구분을 하지 않으면 설치는 끝났는데 기대했던 씬 편집은 안 되는 상황을 만나기 쉽습니다.
내가 먼저 보고 싶은 것은 특정 AI가 게임을 몇 분 만에 만들었다는 결과보다 도구의 경계입니다. 에디터를 설치하는 일과 실행 중인 씬을 수정하는 일은 준비해야 할 것이 다릅니다.
CLI와 에디터 연결은 나눠서 본다
Unity 공식 사용 문서에 따르면 CLI는 독립적인 프로그램으로 에디터 설치, 모듈 추가, 프로젝트 열기 등을 다룹니다. 2026년 9월 22일 확인한 문서에는 experimental로 표시되어 있습니다.
에디터를 제어하려면 프로젝트 쪽의 Unity Pipeline 패키지를 준비해야 합니다. 외부 요청이 에디터 기능으로 이어지는 연결입니다. CLI 버전과 프로젝트의 Editor·패키지 버전을 따로 기록해야 하는 이유입니다.
터미널 또는 에이전트
→ CLI의 작업 요청
→ 필요한 경우 프로젝트의 Pipeline 연결
→ Editor 기능 실행
→ 결과 확인과 저장
MCP는 에이전트가 도구를 발견하고 호출하는 연결 방식입니다. 모든 작업에 반드시 MCP가 있어야 하는 것은 아닙니다. 에이전트가 CLI를 직접 실행하는 구성도 가능하므로, 현재 사용하는 클라이언트와 도구의 지원 방식을 확인합니다.
버튼이 아니라 바꿀 데이터를 정한다
예를 들어 Rigidbody의 Use Gravity를 끄는 작업이라면, Inspector의 체크박스를 찾아 누르는 것보다 대상 컴포넌트의 useGravity 값을 바꾸는 작업으로 생각할 수 있습니다.
여기서 어려운 부분은 대입문 하나가 아닙니다. 같은 이름의 오브젝트가 둘이면 어느 것을 수정할지, 컴포넌트가 없으면 추가할지 실패할지, 프리팹 원본과 씬 인스턴스 중 어디를 바꿀지 결정해야 합니다. 명령이 성공해도 저장하지 않았다면 에디터를 다시 열었을 때 사라질 수 있습니다.
직접 자동화 기능을 만들 때는 아래처럼 결과를 확인할 수 있게 작업을 나눕니다.
| 단계 | 남겨야 할 정보 |
|---|---|
| 대상 조회 | 프로젝트·씬·오브젝트 식별자 |
| 변경 전 확인 | 현재 값과 프리팹 연결 상태 |
| 수정 | 변경한 필드와 이전·새 값 |
| 저장 | 저장한 씬 또는 에셋 |
| 재확인 | 다시 읽은 값과 예상값의 일치 |
이 표는 구현 설계 예시입니다. 같은 이름의 CLI 명령이 기본 제공된다는 뜻은 아닙니다. 커스텀 명령은 등록 방식과 실제 스키마가 있어야 호출할 수 있습니다. C# 메서드 하나를 만들었다고 임의의 unity command ... 구문으로 실행할 수 있는 것은 아닙니다.
다시 실행했을 때도 괜찮은 작업인가
에이전트는 응답을 받지 못하면 재시도할 수 있습니다. “Rigidbody를 추가해줘”를 두 번 실행했을 때 컴포넌트가 중복되거나 잘못된 대상에 붙으면 문제가 됩니다. 기존 상태를 조회한 뒤 필요한 변경만 하는 구조가 유리합니다.
Undo 지원도 도움이 되지만 버전 관리와 같은 것은 아닙니다. 씬·프리팹·메타 파일을 포함해 변경 차이를 확인할 수 있어야 합니다. 자동화가 남긴 테스트 오브젝트나 임시 에셋도 함께 검사합니다.
모달 창이나 운영체제 권한 요청, 공개 API가 없는 외부 에디터 확장까지 모두 처리된다고 기대하지는 않습니다. 해당 기능이 명령이나 API로 노출되어 있는지 먼저 확인해야 합니다. 실행 중인 에디터를 제어하는 것과 에디터 프로세스 없이 처리하는 것도 다른 조건입니다.
작은 자동화 하나를 끝까지 확인한다
처음에는 작은 테스트 씬의 값을 읽고, 하나만 바꾸고, 저장한 뒤 다시 여는 작업이면 충분합니다. 그 결과가 믿을 만해진 다음 빌드나 테스트처럼 시간이 긴 작업으로 넓힙니다.
연결이 잘 안 된다면 CLI 연결 문제를 좁히는 글에서 환경과 프로젝트를 나누어 확인할 수 있습니다. 실제 코드 정리의 범위는 리팩토링 글에서 별도로 다룹니다.