Unity코드 아키텍처와 품질

unity-cli 워크플로우

Unity 에디터를 셸에서 바로 제어하고 상태를 읽는 unity-cli 기반 흐름을 Codex와 함께 쓰는 관점에서 정리합니다.

마지막 수정 2026년 3월 20일

기본 패턴

bash
unity-cli status
unity-cli editor play --wait
unity-cli console --lines 20 --filter all
unity-cli exec "EditorSceneManager.GetActiveScene().name" --usings UnityEditor.SceneManagement

설명

  • unity-cli는 Unity 에디터를 HTTP 기반 커넥터와 셸 명령 조합으로 바로 조작하게 해 주므로, Codex처럼 터미널 실행에 강한 에이전트와 궁합이 좋습니다.
  • README 기준으로 Connector 패키지를 넣으면 Unity가 열릴 때 자동으로 인스턴스를 등록하고, CLI는 이를 찾아 포트와 상태를 확인한 뒤 명령을 보냅니다.
  • 따라서 별도 MCP 도구 레이어 없이도 상태 확인, 플레이 모드 전환, 콘솔 읽기, C# 실행, 메뉴 실행, 프로파일러 조회 같은 작업을 쉘 커맨드로 바로 다룰 수 있습니다.
  • 이 접근은 "도구 프로토콜 설계"보다 "Codex가 셸 명령을 조합해 Unity를 운영"하는 흐름에 더 잘 맞습니다.
  • 특히 CI성 검증, 간단한 에디터 조작, 로그 수집, one-off C# 질의처럼 짧고 직접적인 작업에 강점이 있습니다.

짧은 예제

text
실전 흐름
1. `unity-cli status`로 연결 상태 확인
2. `editor play --wait`로 플레이 모드 진입
3. `console`로 오류와 경고 수집
4. `exec`로 필요한 값이나 상태를 직접 C#으로 질의
5. 필요하면 `--project`나 `--port`로 다른 인스턴스 선택

빠른 정리

관점사용 포인트
접근 방식셸 명령으로 Unity 직접 제어
강점빠른 setup, Codex와 높은 궁합
잘 맞는 경우상태 확인, 로그 수집, 짧은 에디터 제어
주의 대상exec는 매우 강력하므로 범위 명시 필요
멀티 인스턴스--project, --port로 선택 가능

주의할 점

README는 Unity가 백그라운드일 때 업데이트가 늦어질 수 있으니 Editor Throttling을 꺼 두라고 권합니다. 또 exec는 사실상 C# 실행 권한이므로, Codex에게 맡길 때는 "무엇을 읽고 무엇은 바꾸지 말라"는 경계를 더 또렷하게 주는 편이 좋습니다.

참고 링크

1 sources