게임 제작 자동화에서 가장 답답한 순간은 코드를 만드는 때보다 결과를 확인하는 때입니다. 스크립트가 파일을 수정해도 누군가는 Unity Editor를 열고, 프로젝트를 로드하고, Play Mode에 들어가고, 로그를 복사해 다시 전달해야 했습니다. AI 코딩 도구를 붙여도 이 마지막 구간이 사람 손에 남으면 “제안하는 에이전트”는 만들 수 있지만 “확인하고 고치는 에이전트”까지 가기는 어렵습니다.
Unity는 2026년 7월 20일 이 간극을 겨냥한 Unity CLI를 공개했습니다. 독립 실행형 unity 바이너리로 Editor와 모듈, 프로젝트, 인증을 관리하고, 실험적 com.unity.pipeline 패키지로 실행 중인 Editor나 개발용 Player에 명령을 보낼 수 있습니다. unity command eval은 Roslyn으로 C# 표현식을 컴파일해 Editor 메인 스레드에서 실행하고 결과를 돌려줍니다. Unity가 보여준 방향은 터미널 편의 기능 하나가 아니라 관찰, 실행, 검증을 한 루프로 묶는 것입니다.
다만 공개 첫날의 결론은 “모든 프로젝트에 AI 에이전트를 연결하자”가 아닙니다. 공식 문서는 Unity CLI와 Pipeline 패키지를 모두 실험적 기능으로 표시합니다. 명령과 문서는 바뀔 수 있고, eval은 Unity API에 넓게 접근할 수 있는 만큼 강력합니다. 이 글은 기능 목록보다 어디부터 자동화하고 어디에 승인선을 둘지 정하는 도입 가이드입니다.
먼저 세 층을 분리해야 합니다
Unity CLI라는 이름 아래에는 서로 다른 책임이 겹쳐 있습니다. 첫 번째 층은 설치와 환경 관리입니다. 독립 실행형 바이너리가 Editor 버전과 플랫폼 모듈을 설치하고, 프로젝트를 알맞은 Editor로 열며, 인증 상태를 다룹니다. Unity Hub의 화면을 통하지 않아도 되므로 새 빌드 머신을 준비하거나 팀의 설치 절차를 코드로 남기기 쉬워집니다.
두 번째 층은 자동화 계약입니다. 공식 문서는 JSON과 TSV 출력, 표준 출력과 표준 오류의 분리, 성공 0, 일반 오류 1, 취소 130이라는 종료 코드 계약을 설명합니다. 사람에게 보기 좋은 로그를 긁어 해석하는 대신 스크립트가 구조화된 결과를 읽을 수 있습니다. CI뿐 아니라 AI 에이전트에도 이 차이가 큽니다. 결과가 모호한 긴 콘솔 문장이 아니라 필드와 상태 코드로 돌아오면 다음 행동의 조건을 명시할 수 있기 때문입니다.
세 번째 층은 실행 중 프로젝트와의 연결입니다. com.unity.pipeline을 설치한 프로젝트는 [CliCommand] 특성을 붙인 정적 메서드를 명령으로 노출할 수 있습니다. 정해 둔 명령으로 부족하면 unity command eval이나 eval_file로 C#을 실행할 수 있습니다. 공식 발표는 이 조합이 실행 중인 씬을 조사하고, 상태를 바꾸고, Play Mode에서 결과를 다시 확인하는 루프를 만든다고 설명합니다.
이 셋을 한 번에 도입하면 실패 원인을 구분하기 어렵습니다. 설치 문제인지, 인증 문제인지, 프로젝트 명령 문제인지, 런타임 상태 문제인지 섞이기 때문입니다. 팀은 CLI로 환경을 재현하는 단계, 등록 명령으로 프로젝트 작업을 제어하는 단계, 제한된 eval로 탐색하는 단계를 따로 승인하는 편이 안전합니다.
VFX 팀에는 “생성”보다 “상태 확인”이 먼저입니다
VFX 제작에서 자동화라는 말을 들으면 에셋이나 이펙트를 자동 생성하는 장면부터 떠올리기 쉽습니다. 하지만 첫 적용처로 더 좋은 것은 반복해서 확인하던 상태를 기계가 읽게 만드는 일입니다. 예를 들어 특정 샘플 씬이 열렸는지, 기대한 VFX Graph 컴포넌트가 활성화됐는지, 테스트 카메라가 정해진 위치에 있는지, Play Mode 진입 뒤 오류 로그가 생겼는지 같은 항목입니다.
여기서 중요한 구분이 있습니다. 위 예시는 Unity CLI가 특정 VFX 전용 명령을 기본 제공한다는 뜻이 아닙니다. 팀이 Unity API와 프로젝트 코드를 이용해 등록 명령을 설계할 수 있다는 사실에서 이어지는 가상 적용 예시입니다. 실제로 어떤 VFX Graph 속성과 렌더링 상태를 읽을 수 있는지는 사용하는 Unity 버전, 패키지 버전, 렌더 파이프라인, 프로젝트 코드에 따라 확인해야 합니다.
가장 작은 시작은 vfx.qa.summary 같은 읽기 전용 명령 하나입니다. 이 명령은 프로젝트 버전, 현재 씬, 활성 카메라, 대상 오브젝트 존재 여부, 오류 로그 수, 테스트 결과만 구조화해 반환합니다. 사람은 그 결과를 보고 다음 단계로 넘어갈지 결정합니다. 이 정도만으로도 “프로젝트를 열어서 상황을 설명하는” 왕복이 줄어듭니다.
그다음에는 결과가 명확한 작업을 붙일 수 있습니다. 가상의 vfx.qa.play 명령이 샘플 씬을 열고 Play Mode를 시작한 뒤, 지정 시간 동안 오류를 모으고 종료한다고 해봅시다. 성공 조건은 화면이 예뻐 보이는지가 아니라 씬 로드 성공, 대상 컴포넌트 발견, 예외 없음, 테스트 종료 같은 기계 판정으로 제한합니다. 미묘한 타이밍, 색감, 실루엣, 과다 발광처럼 예술 판단이 필요한 항목은 여전히 사람이 캡처와 영상을 검토해야 합니다.
이 구분은 Unity 6.5와 Houdini Engine 업그레이드 판단 글에서 골든 씬을 먼저 고정한 이유와도 연결됩니다. 자동화가 빨라질수록 무엇을 성공으로 볼지 먼저 고정해야 합니다. 명령 실행 자체가 성공한 것과 결과물이 제작 기준을 통과한 것은 다른 판정입니다.
CI 전환은 기존 Hub 스크립트를 그대로 바꾸는 일이 아닙니다
새 CLI는 기존 Unity Hub 내장 CLI와 호출 방식이 다릅니다. 공식 마이그레이션 문서는 -- --headless 호출을 unity 명령으로 바꾸고, Editor 버전 인수와 모듈 설치 옵션, 로컬 Editor 등록 문법을 다시 확인하라고 안내합니다. 파이프로 출력을 보낼 때 기본 형식이 사람이 읽는 텍스트가 아니라 TSV가 될 수 있고, 오류가 stdout이 아닌 stderr로 이동한다는 점도 기존 스크립트에 영향을 줄 수 있습니다.
따라서 치환 작업은 명령 이름 검색으로 끝내면 안 됩니다. 먼저 현재 빌드 스크립트가 성공을 어떻게 판단하는지 조사해야 합니다. 콘솔 문자열을 검색하는지, 종료 코드를 보는지, 설치 진행률을 파싱하는지, 로그 경로를 고정해 두었는지 목록으로 만듭니다. 그런 다음 새 CLI의 JSON 출력과 종료 코드에 맞춰 계약 테스트를 작성합니다.
특히 Editor 버전 별칭은 편리하지만 재현 가능한 빌드에는 주의가 필요합니다. lts나 latest는 시간이 지나면 다른 버전을 가리킬 수 있습니다. 개발자 로컬 설치에는 별칭을 쓰더라도 릴리스 CI는 정확한 Editor 버전과 필요한 모듈을 고정하는 편이 좋습니다. Unity CLI가 환경 설치를 단순하게 만들어도 버전 정책까지 대신 정해주지는 않습니다.
Mac의 Rosetta 종료에 대비한 Unity 빌드 체크리스트처럼, 도구 전환은 “새 명령이 실행된다”보다 대상 머신의 아키텍처, 모듈, 인증, 산출물 해시가 다시 만들어지는지를 봐야 합니다. 새 CLI를 붙인 첫 주에는 기존 경로와 새 경로를 나란히 실행하고, 설치 목록과 빌드 결과를 비교하는 방식이 현실적입니다.
에이전트 연결에는 기능 목록보다 권한표가 필요합니다
공식 발표는 Pipeline이 로컬 머신에서 동작하며 개발용 런타임 연결은 localhost 전용이고 기본적으로 꺼져 있다고 설명합니다. eval은 보안 토큰으로 보호됩니다. 좋은 기본선이지만, 토큰이 있다는 사실만으로 팀 운영이 안전해지는 것은 아닙니다. 어떤 명령을 누가 호출하고, 어떤 파일과 씬을 바꿀 수 있으며, 결과를 어디에 기록하는지 별도의 권한표가 필요합니다.
첫 단계에서는 조회 명령과 변경 명령을 분리하는 것이 좋습니다. 조회 명령은 프로젝트 버전, 씬 상태, 로그, 테스트 결과처럼 복구가 필요 없는 정보를 반환합니다. 변경 명령은 임포트, 씬 저장, 에셋 수정, 패키지 변경처럼 프로젝트 상태를 바꿉니다. AI 에이전트에는 조회 권한부터 주고, 변경은 명령별 승인과 버전 관리 diff를 조건으로 추가합니다.
eval은 탐색에 유용하지만 등록 명령보다 넓은 표면을 가집니다. 공식 글대로 Unity와 Editor API에 접근할 수 있으므로, 운영 파이프라인의 기본 인터페이스로 무제한 eval을 두는 것은 피하는 편이 낫습니다. 반복 작업은 [CliCommand]로 좁혀 입력값, 사전 조건, 반환 형식, 실패 상태를 명시하고, eval은 일회성 조사나 승인된 개발 환경에서만 쓰는 정책이 이해하기 쉽습니다.
개발용 Player 연결도 제품 빌드와 섞지 않아야 합니다. 공식 발표는 런타임 컴포넌트를 개발 빌드와 QA에 사용하고 프로덕션에는 넣지 말라고 선을 긋습니다. 빌드 파이프라인에서 해당 컴포넌트와 토큰 설정이 Shipping 또는 배포 구성에 포함되지 않는지 자동 검사해야 합니다. “기본적으로 꺼짐”과 “우리 배포물에 없음”은 서로 다른 증거입니다.
검증 루프는 관찰과 판정을 함께 기록해야 합니다
에이전트가 Editor를 조작할 수 있게 되면 속도는 빨라지지만, 잘못된 성공도 더 빨리 반복할 수 있습니다. 이를 막으려면 한 작업의 기록을 요청, 관찰, 행동, 판정 네 부분으로 남겨야 합니다. 요청에는 목표와 허용 범위를, 관찰에는 변경 전 상태를, 행동에는 실제 실행한 명령과 인수를, 판정에는 기대값과 실제값을 기록합니다.
예를 들어 “이펙트가 재생되지 않는다”는 요청만으로 자동 수정하게 두면 범위가 너무 넓습니다. 먼저 대상 씬과 오브젝트, 컴포넌트 활성 상태, 관련 오류를 읽습니다. 비활성 상태가 확인되더라도 즉시 원본 씬을 저장하지 않고 개발용 복제 씬이나 임시 실행 상태에서 변경합니다. Play Mode를 다시 시작해 같은 검사 항목이 통과하는지 확인한 뒤, 사람이 저장 여부를 결정합니다.
Unity가 소개한 데모도 “바닥을 통과한다”는 보고를 받은 에이전트가 실행 중 씬을 조사하고 비활성 Collider를 찾아 다시 활성화한 뒤 Play Mode로 결과를 확인하는 흐름입니다. 이 사례의 핵심은 AI가 코드를 썼다는 것이 아니라 변경 전후를 같은 환경에서 관찰했다는 점입니다. VFX QA에서도 같은 원칙을 적용해야 합니다. 단순히 명령이 오류 없이 끝났다는 로그가 아니라, 대상 상태가 기대값으로 바뀌었는지를 다시 읽어야 합니다.
시각 결과는 별도 레이어로 남깁니다. 구조화된 상태 검사와 프레임 캡처를 같은 증거 묶음에 넣되, 자동 판정이 가능한 항목과 아티스트 검토가 필요한 항목을 구분합니다. 누락 컴포넌트, 예외, 해상도, 렌더 파이프라인 설정은 자동 검사 후보입니다. 잔상, 가독성, 리듬, 화면 집중도는 사람의 비교 검토가 더 적합합니다.
첫 2주 도입 순서는 이렇게 잡을 수 있습니다
첫째, 빌드 머신이 아닌 개발용 격리 환경에서 CLI 설치와 unity --version, Editor 목록 JSON 출력만 확인합니다. 프로젝트 파일은 바꾸지 않습니다. 둘째, 정확한 Editor 버전과 모듈 조합을 설치하는 재현 테스트를 만듭니다. 셋째, 샘플 프로젝트에 Pipeline 패키지를 넣고 읽기 전용 등록 명령 하나를 노출합니다.
넷째, 명령 결과를 JSON으로 저장하고 같은 프로젝트 상태에서 두 번 실행해 결정적인지 비교합니다. 다섯째, Play Mode 진입과 종료처럼 되돌릴 수 있는 작업을 추가하되 저장은 금지합니다. 여섯째, eval은 승인된 조사 세션에만 열고 토큰과 실행 로그를 별도로 관리합니다. 일곱째, 아티스트가 결과를 읽기 쉬운 짧은 리포트를 만들고 실제로 왕복 시간이 줄었는지 측정합니다.
이 단계에서 성공 기준은 거대한 자율 에이전트가 아닙니다. 한 개의 샘플 프로젝트가 같은 버전으로 열리고, 한 개의 읽기 명령이 같은 결과를 반환하고, 한 개의 가역 작업이 검증까지 끝나는 것입니다. 이 세 가지가 안정적이면 임포트 검사, 테스트 씬 실행, 로그 분류처럼 범위를 넓힐 수 있습니다.
반대로 결과가 매번 달라지거나 토큰 관리가 불명확하거나 개발용 컴포넌트가 배포 구성에 섞인다면 확장을 멈춰야 합니다. 실험적 기능은 빠르게 배울 가치가 있지만, 제작 파이프라인의 신뢰를 담보로 삼을 이유는 없습니다. GPU 크래시 덤프를 AI 분석 루프에 연결한 글에서처럼, AI가 유용해지는 지점은 추측을 늘릴 때가 아니라 도구가 제공한 구조화된 증거를 따라갈 때입니다.
효과도 감상이 아니라 전후 수치로 남기는 편이 좋습니다. 한 건의 VFX 상태 확인에 사람이 Editor를 열고 결과를 전달하는 데 걸린 시간, 자동 명령이 끝난 뒤 사람이 검토하는 시간, 재시도 횟수, 잘못된 성공 판정 수를 각각 기록합니다. 자동화가 명령 실행을 빠르게 해도 검토 부담이나 오탐이 늘었다면 전체 제작 시간은 줄지 않을 수 있습니다. 반대로 아주 작은 조회 명령 하나가 반복 왕복을 줄였다면 더 넓은 쓰기 권한 없이도 이미 가치가 있습니다.
중단 조건은 시작 전에 합의해야 합니다. 같은 입력에서 결과가 달라짐, 프로젝트 원본에 승인되지 않은 변경 발생, 토큰 또는 로그에 민감 정보 노출, 개발 전용 연결의 배포 구성 포함, CLI 업데이트 뒤 계약 테스트 실패 중 하나가 나타나면 자동 실행을 멈추고 사람 검토로 돌아갑니다. 빠른 루프의 목적은 사람을 우회하는 것이 아니라 실패를 더 일찍 발견하는 것입니다.
지금의 판단: 작게 연결하고 검증을 먼저 자동화하기
Unity CLI와 Pipeline 패키지는 Unity 제작 환경이 터미널과 에이전트 자동화에 더 잘 연결되는 중요한 변화입니다. 독립 바이너리, 구조화 출력, 예측 가능한 종료 코드, 프로젝트 등록 명령, 실행 중 Editor와 Player 연결, C# 평가가 한 흐름에 모였습니다. 특히 사람이 콘솔을 복사해 전달하던 구간을 줄이고 에이전트가 스스로 결과를 다시 읽게 할 수 있다는 점이 큽니다.
하지만 현재 상태는 실험적입니다. 기능과 문서가 바뀔 수 있고, eval의 넓은 접근 범위는 권한 설계 없이는 위험합니다. 기존 Hub 자동화와 문법 및 출력 계약도 다릅니다. 전면 교체보다 개발용 환경에서 읽기 전용 명령, 고정된 버전, 구조화된 결과, 명시적 승인선을 먼저 검증해야 합니다.
VFX 팀이라면 생성 자동화보다 QA 요약부터 시작해 보세요. 샘플 씬의 대상 오브젝트와 컴포넌트, 오류 로그, 테스트 상태를 한 번에 읽는 명령 하나만 만들어도 반복 확인 비용을 줄일 수 있습니다. 그 명령이 두 번 같은 결과를 내고, 사람이 판정을 이해할 수 있고, 배포물에 개발용 연결이 남지 않는다면 다음 자동화로 넘어갈 근거가 생깁니다. 이번 변화의 가치는 에이전트가 무엇이든 할 수 있다는 데 있지 않습니다. 한 번 한 일을 스스로 확인할 수 있는 제작 루프를 만들 수 있다는 데 있습니다.
참고 출처
- Unity Technologies, Meet the Unity CLI: manage Unity from your terminal, 2026-07-20: https://unity.com/blog/meet-the-unity-cli
- Unity Documentation, Use the Unity command-line interface: https://docs.unity.com/en-us/unity-cli/use-unity-cli
- Unity Documentation, Unity CLI reference: https://docs.unity.com/en-us/unity-cli/unity-cli-reference
- Unity Documentation, Unity pipeline package: https://docs.unity.com/en-us/unity-production-pipeline/local-tools-cli/unity-pipeline-package