Unity CLI 발표, AI 코딩 시대의 대세를 맞설순 없었다.
인디 게임 개발자 커뮤니티를 들여다보면 지난 1~2년 사이 유독 자주 올라온 글이 있다. “유니티 접고 Godot으로 넘어갔다.”
이유는 놀랄 만큼 비슷했다. Claude Code나 Codex 같은 터미널 기반 AI로 작업하는데, 유니티가 그 흐름에 도무지 붙지 않는다는 것이다.
Godot은 씬 파일이 사실상 텍스트라 커맨드라인으로 주무를 여지가 넓다. 반면 유니티는 에디터를 켜야 뭐라도 시작됐다. AI한테 “이 오브젝트 좀 옮겨줘"라고 시키려면 결국 YAML 메타파일을 직접 뜯는 수밖에 없었고, 그건 조금만 건드려도 깨졌다.
그런데 유니티가 CLI 지원 패키지를 발표했다. 나는 이걸 기능 하나 추가된 소식으로 안 본다. 떠난 사람들의 판단 근거 자체를 흔들 수 있는 변화다.
왜 다들 Godot으로 갔는지부터
AI 코딩 도구를 제대로 굴려본 사람은 안다. 지금 개발의 무게중심은 IDE가 아니라 터미널이다. 손으로 코드를 치는 시간보다, 에이전트에게 맥락을 넘기고 명령을 던지고 나온 결과를 검토하는 시간이 훨씬 길어졌다.
이 방식에서 목을 조르는 건 언제나 하나다. “AI가 그 도구를 만질 수 있느냐.”
터미널에서 명령으로 굴러가는 도구는 AI가 잘 다룬다. 텍스트니까. 반대로 마우스 드래그로만 되는 도구는 에이전트 입장에선 그냥 벽이다.
게임 엔진은 후자에 가까웠다. 특히 유니티 에디터는 보이는 대로 만드는 위지위그(WYSIWYG) 구조라 사람 손에는 더없이 편하지만, 에이전트에게는 들어갈 문이 없었다. “AI 시대엔 유니티 말고 다른 엔진이 낫다"는 말이 괜히 나온 게 아니다. Unity Korea 채널의 CLI 사용설명서 영상에서도 김재익 애드버킷이 같은 지점을 짚는다. 유니티 에셋이 단순 파일이 아니라 YAML 메타파일을 끼고 있는 복잡한 구조라 AI가 잘 못 다룬다는 의견이 많았다고.
정리하면 이탈은 감정이 아니었다. 도구가 안 맞으니 맞는 쪽으로 옮겨간 것뿐이다.
Unity CLI가 연 건 ‘에디터 없이 들어가는 문’
Unity CLI의 핵심은 명령어가 몇 개 늘었다는 게 아니다. 에디터를 띄우지 않고도 유니티 프로젝트를 건드릴 수 있는 공식 통로가 생겼다는 점이다.
CLI만으로 이런 일들이 된다.
| 하려는 일 | 명령 |
|---|---|
| 버전 확인 | unity --version |
| 업그레이드 | unity upgrade |
| 로그인 | 유니티 계정 로그인 명령 |
| 라이선스 활성화·목록 | license activate / license list |
| 설치 가능 에디터 조회·설치 | editors / install LTS |
| 템플릿 조회 | template list --editor <버전> |
| 프로젝트 생성 | project new --template <템플릿> |
| 프로젝트 열기 | 프로젝트 경로에서 unity open |
설치부터 터미널을 붙잡을 필요가 없다. 유니티 허브 3.21부터 상단 도구 상자에 ‘Unity CLI’ 메뉴가 생겼고, 버튼 한 번이면 10~20초 만에 끝난다.
실무자 눈으로 봤을 때 짚고 넘어가고 싶은 건 경로 처리다. 허브에서 에디터 설치 경로와 프로젝트 생성 경로를 미리 정해두면 CLI가 그 값을 기본으로 물고 간다. AI 에이전트에게 일을 맡길 때 파일이 엉뚱한 데 떨어지는 건 생각보다 짜증 나는 사고다. 시작 전에 이것부터 잡아두는 걸 권한다.
밑에서 굴러가는 건 파이프라인 패키지
CLI가 무슨 수로 에디터를 조종하나 싶을 텐데, 답은 ‘Unity Pipeline’이라는 패키지다. 이번에 같이 나온 층이다.
흐름은 이렇다.
- 사람 또는 AI 에이전트가 Unity CLI에 명령을 던진다.
- CLI가 내부 프로토콜로 파이프라인 패키지에 신호를 보낸다.
- 파이프라인 안에는 에디터 서버와 런타임 서버가 있고, HTTP와 JSON으로 데이터를 주고받는다.
- 그 결과가 실제 프로젝트에 반영된다.
프로토콜을 알 필요는 없다. 그건 CLI가 감당하는 몫이다. 쓰는 사람은 명령어만 알면 된다. 통로가 터미널로만 제한되지도 않는다. 직접 만든 웹페이지나 애플리케이션에서도 이 파이프라인을 호출할 수 있다.
여기서 자리 하나가 눈에 띄게 비어 있다. 에이전트다. CLI는 사람이 직접 타이핑해도 되지만, 텍스트 명령 체계를 가장 잘 쓰는 건 결국 AI다. 이번 발표의 무게중심도 거기 있다고 본다.
월 10달러 내야 한다는 오해
MCP 얘기를 빼놓을 수 없다. 올해 초 유니티가 소개했던 MCP는 AI 어시스턴트와 한 몸이었다. 에디터를 띄우고, 설정에서 AI 메뉴로 들어가 별도 MCP 항목에서 서버를 열고 모델을 붙이는 방식이었다.
이걸 Unity CLI MCP가 통째로 대체한다. 영상에서는 에디터에 있던 기존 MCP 서버 연결 도구가 점차 deprecate될 예정이라고 못 박는다.
오해 하나도 여기서 풀린다. “유니티 MCP 쓰려면 Unity AI를 월 10달러 결제해야 한다"고 알고 있는 사람이 아직 많은데, 이제 그럴 필요가 없다. Unity CLI MCP는 공짜다. Claude나 Codex는 물론이고 로컬에 띄운 AI까지 MCP로 엮을 수 있다.
이 부분이 1인 개발자에게는 특히 크다. 혼자 만드는 사람에게 월 구독은 도구를 시험조차 못 해보게 만드는 문턱이다. 써보고 아니면 버리면 되는 것과, 돈을 내야 써볼 수 있는 것 사이에는 생각보다 큰 간극이 있다.
붙이는 순서는 다섯 단계
영상 시연을 순서대로 옮기면 이렇다.
- AI 도구 설치 — 데스크톱 앱이든 CLI든 평소 쓰던 걸 그대로 쓴다. 로컬 AI도 된다.
- MCP 구성 — 터미널에
unity mcp configure를 치면 지원 목록이 뜬다. Claude, VS Code, Kiro, Codex, Kimi, OpenCode 등이 올라와 있고, 뒤에 해당 이름을 붙이면 MCP 서버 항목이 추가된다. - 스킬 주입 — 구글에 ‘Unity Skills’를 검색하면 유니티가 깃허브에 공개한 스킬 저장소가 나온다. zip을 받아 풀고 Claude 설정의 스킬 탭에 올리거나, README에 적힌 NPX 자동 설치를 쓴다.
- 파이프라인 설치 — 프로젝트 경로에서
unity pipeline install. 사실 AI에게 프로젝트를 열게 하면 “파이프라인이 없는데 설치할까요?“라고 먼저 물어온다. - 연결 확인 —
unity status로 서버가 떴는지 보고, AI에게 “Unity CLI MCP 연결하고 지금 씬 점검해봐"라고 시켜본다.
여기서 하나 덧붙이면, Claude로 작업할 때 CLI 명령이 매번 달라서 권한을 하나하나 수동 허용하다 보면 작업이 계속 끊긴다. 영상에서도 자동 허용을 권한다. 나도 CLI 도구를 붙일 때는 같은 이유로 자동 허용을 켜두는 편이다. 대신 프로젝트가 git으로 관리되고 있는지는 반드시 먼저 확인하자. 되돌릴 수 있어야 마음 놓고 맡길 수 있다.
기획 몇 줄로 게임이 나왔다
영상 후반부에 총알 피하기 게임을 만드는 장면이 나온다. 흐름이 꽤 인상적이었다.
간단한 기획을 프롬프트로 넣자 AI가 어떤 스크립트가 필요한지 스스로 판단하고 만들기 시작한다. 이 과정 전체가 Unity CLI 명령으로 굴러간다. 테스트 관련 명령도 마련돼 있어서 테스트 코드까지 같이 나왔다.
더 흥미로운 대목은 밸런싱이었다. “게임 밸런스에 맞게 다듬어달라"고 하니 Claude가 직접 플레이하면서 레벨 디자인을 검증한다. 총알 생성에 문제가 있어 수정을 요청하자 곧바로 반영했고, 테스트 결과를 표로 정리해 내놨다.
발표자가 직접 해보니 AI보다 빨리 죽었다는 얘기가 나오는데, 웃고 넘길 장면만은 아니다. AI가 만든 걸 AI가 검증하는 루프가 이미 돌아가고 있다는 뜻이니까.
진짜 강점은 속도가 아니라 ‘결정론’
영상이 꼽은 이 워크플로의 특징은 두 가지다.
첫째, 결정론적이다. AI에는 노이즈가 있다. 같은 프롬프트를 줘도 접근 방식과 결과물이 매번 미묘하게 다르다. 그런데 CLI는 명령어가 정해져 있다. 준비된 명령 중에서 에이전트가 골라 쓰는 구조라 결과의 흔들림이 줄어든다. 덤으로 토큰 소모도 억제된다.
나는 이 지점이 가장 실용적이라고 본다. AI로 개발할 때 사람을 지치게 하는 건 성능이 아니라 예측 불가능성이다. 어제 되던 게 오늘 안 되면, 검증에 쓰는 시간이 개발에 쓰는 시간을 넘어선다. 명령어 집합이 고정돼 있다는 건 그 불안을 구조적으로 깎아낸다는 뜻이다.
둘째, 가만있어도 좋아진다. 지금 CLI는 베타(experimental)고, 유니티는 정식 버전까지 명령어를 계속 갱신하겠다고 했다. 내 AI를 더 똑똑하게 만들지 않아도, CLI 명령어가 다듬어지면 결과물 품질이 따라 올라간다.
뒤집어 보면 지금은 베타라는 사실을 감안해야 한다는 얘기이기도 하다. 상용 프로젝트를 통째로 얹기보다는 프로토타입이나 반복 작업부터 붙여보는 게 현실적이다.
그래서 돌아갈 만한가
내 결론은 “고민할 이유는 확실히 생겼다"다.
Godot으로 옮긴 사람들 중에 Godot 자체가 더 좋아서 간 경우는 의외로 적다. AI와 맞물리는 도구가 필요했을 뿐이다. 그 이유가 사라지면 판단의 전제도 달라진다. 유니티가 쌓아온 에셋스토어, 빌드 타깃, 널려 있는 레퍼런스는 여전히 만만치 않은 자산이니까.
물론 조건이 붙는다. 유니티가 이 CLI를 정식 버전까지 제대로 끌고 가야 한다. 베타에서 멈추거나 명령어 커버리지가 부족한 채 방치되면 떠난 사람들은 돌아오지 않는다.
다만 유니티에게 다른 선택지가 있어 보이진 않는다. AI 시대에 게임 엔진의 CLI 지원은 옵션이 아니라 전제 조건이 됐다. 이번 발표는 유니티도 그 흐름을 거스를 수 없다고 판단했다는 신호로 읽힌다.
당장 할 수 있는 건 명확하다. 허브를 3.21로 올리고, 도구 상자에서 CLI를 설치하고, 쓰던 AI에 MCP를 붙여 프로토타입 하나 만들어보는 것. 판단은 그다음에 해도 늦지 않다.
마치며
- 인디 개발자들이 Godot으로 옮긴 건 엔진 취향이 아니라 CLI 기반 AI 도구와의 궁합 문제였다.
- Unity CLI는 에디터 없이 프로젝트를 다루는 공식 통로를 열었고, 그 아래에서 Unity Pipeline 패키지가 에디터·런타임 서버로 동작한다.
- 에디터 안에 있던 기존 MCP 연결 도구는 deprecate 예정이고, Unity CLI MCP는 무료로 Claude·Codex·로컬 AI와 붙는다.
- 가장 큰 실익은 속도가 아니라 결정론이다. 정해진 명령어를 쓰니 AI 노이즈와 토큰 소모가 함께 줄어든다.
- 아직 베타이므로 상용 프로젝트 전체보다는 프로토타입과 반복 작업부터 얹어보는 편이 안전하다.
자주 묻는 질문
Q. Unity CLI를 쓰려면 돈을 내야 하나?
아니다. 예전에는 유니티 MCP를 쓰려면 Unity AI 결제가 필요하다는 인식이 있었지만, Unity CLI MCP는 무료로 쓸 수 있다고 영상에서 설명한다. 평소 쓰던 Claude, Codex, 로컬 AI를 그대로 연결하면 된다.
Q. 설치는 어떻게 하나?
유니티 허브를 3.21 이상으로 올리면 상단에 도구 상자 메뉴가 생긴다. 거기서 Unity CLI를 골라 설치 버튼을 누르면 끝이다. 터미널에 직접 명령을 넣는 방법도 있지만 허브 쪽이 훨씬 간단하다. 업데이트도 같은 메뉴에서 하거나 unity upgrade로 처리할 수 있다.
Q. MCP 연결에 파이프라인 패키지가 꼭 필요한가?
MCP로 실제 개발 작업을 하려면 필요하다. 프로젝트 경로에서 unity pipeline install을 실행하거나, AI에게 프로젝트를 열게 하면 대개 먼저 설치를 제안한다. 다만 스킬만 넣고 프로젝트를 여는 정도는 MCP 없이도 된다.
Q. Godot에서 유니티로 다시 돌아갈 만한가?
CLI를 기준으로 엔진을 골랐던 사람이라면 다시 비교해볼 이유가 생겼다. 다만 현재 Unity CLI는 베타다. 진행 중인 프로젝트를 통째로 옮기기보다는 작은 프로토타입으로 워크플로를 먼저 검증해보길 권한다.
Q. AI로 개발하면 결과가 매번 달라지지 않나?
그 편차를 줄이는 게 CLI 방식의 핵심이다. 정해진 명령어 집합에서 에이전트가 골라 쓰는 구조라 결정론적으로 작동하고, 부수적으로 토큰 소모도 줄어든다.
참고 자료
- Unity Korea, 「Unity CLI MCP 사용설명서」 (YouTube)