Unity CLI를 사용한 UI Toolkit 프로토타이핑

영상: Prototyping UI Toolkit with Unity CLI
채널: Unity
길이: 18분 34초
언어: 영어
스크립트:
Photoshop이나 Figma에서 게임 인터페이스를 목업(mocked up)으로 만드셨나요? 이를 UI Toolkit을 사용해 작동하는 프로토타입으로 만들어 보겠습니다. Unity CLI와 Agent를 사용하여 진행할 것입니다. 템플릿부터 시작하여 컨셉 아트를 추가하고, 각 화면을 설명한 다음, 한 발 물러나서 Agent가 구축하도록 맡깁니다. 여기서 보이는 모든 것은 Unity Editor에서 실시간으로 작동합니다. 터미널에서 만들어진 것이죠. CLI는 Agent에게 프로젝트를 검사하고, 변경 사항을 만들고, 반복적으로 개선할 수 있는 수단을 제공합니다. 이 과정은 에디터 내에서 클릭하는 일이 전혀 없습니다. 디자인을 UI Toolkit으로 손으로 옮기는 데 며칠이 걸릴 필요 없이, 같은 오후에 기능적인 프로토타입을 얻을 수 있습니다. 포함된 샘플을 보고, 워크플로우를 직접 테스트해보고, 자신만의 디자인에 Unity CLI를 사용해 보세요. 기본적인 설정이 이미 완료된 템플릿 프로젝트가 설명에 링크되어 있습니다. 이 템플릿은 공식 Unity agent 스킬 위에 프로젝트 레벨의 지침을 추가합니다. 따라서 Agent는 처음부터 Unity와 프로젝트 구조를 모두 알게 됩니다. 또한, 이 템플릿에는 UI 조립을 위해 구축된 몇 가지 사용자 지정 CLI 명령이 포함되어 있습니다. 본질적으로 이 프로젝트는 Agent에게 무엇을 만들지 알려주는 브리핑 자료인 셈입니다. 여기에 아트워크가 있고, 화면별 짧은 설명과 몇 가지 지원 문서가 있습니다. 이것들이 작동하는 데 필수적인 것은 아니지만, 기능적인 UI를 더 빠르게 얻는 데 도움이 될 것입니다. 템플릿이 어떻게 구성되었는지 더 자세히 다루겠습니다. 하지만 먼저, CLI가 실제로 작동하는 것을 보겠습니다. 터미널을 열고 Agent를 시작하세요. Claude Code, Codex CLI 또는 모든 셸 기반 Agent가 작동합니다. 이 데모에서는 Claude Code 데스크톱 앱을 보여주지만, 일반 터미널도 동일하게 작동합니다. 시작은 두 줄입니다. Agent에게 프로젝트 루트에 있는 마크다운 파일(markdown file)을 가리키고 메인 메뉴를 구축하라고 지시한 다음, 완료되면 스크린샷을 요청하세요. 그러면 Agent가 작업을 시작합니다.

파일을 작성하고, Unity에 재컴파일하도록 지시하며, 씬(scene)을 조립한 다음, 첫 번째 스크린샷을 찍습니다. 이 스크린샷이 피드백 루프를 시작합니다. 그리고 여기서부터 패턴은 반복됩니다. 에이전트가 변경 사항을 만들고, 결과를 살펴본 다음, 무엇을 했는지 보여줍니다. CLI는 에디터와 실시간 연결(live connection)을 유지하므로 작업하는 동안 업데이트되는 것을 지켜볼 수 있습니다. 그런 다음 방향을 제시합니다. 이 과정이 진행되는 동안, 당신은 아트 디렉터이자 리드 개발자 역할을 동시에 수행하게 됩니다. 첫 번째 경로에서 에이전트는 전반적인 구조를 만듭니다. 그 이후로는 무엇을 해야 할지 알려주는 당신에게 의존합니다. 현재 UI가 어떻게 보이는지 말해주세요. 어떤 모습이어야 하는지 말하고, 컨셉 아트(concept art)를 가리키며 에이전트에게 되돌려줍니다. 무언가가 원래 디자인에서 벗어난 부분이 있다면 그렇게 말하세요. 에이전트는 이를 위해 자체 도구를 구축하여 참고 자료에 맞춰 자르기(cropping)와 확대/축소(zooming)를 할 수 있게 합니다. 에디터는 내내 실시간 상태(live)입니다. 따라서 플레이 모드(play mode)로 진입하여 UI를 직접 클릭해 볼 수 있습니다. 물론 코드, UXML, 스타일 시트(style sheets), 그리고 C-sharp도 검사하고 싶을 것입니다. 무언가가 올바른 패턴을 사용하지 않거나 단순히 당신의 기준에 미치지 못한다면, 그것 역시 에이전트에게 전달할 메모가 됩니다. 메인 메뉴가 형태를 갖출 때까지 계속 진행합니다. 그리고 같은 방식으로 나머지 세 개의 화면(로딩 화면, 임무 화면, 설정)을 설정할 때까지 계속합니다. 이 구성 요소들(loadout), 미션 화면, 그리고 설정입니다. 이 특정 데모를 실행하는 과정에서 에이전트는 많은 부분을 스스로 잘 처리했습니다. 모든 부분이 그런 것은 아닙니다. 하지만 그것이 당신의 역할 중 일부입니다. 수정을 하고 방향을 제시하는 것입니다. 컨셉 아트에 얼마나 가깝게 착륙할지는 당신의 결정입니다. 에이전트는 당신이 멈추라고 할 때까지 계속 작업할 것입니다. 때로는 에이전트가 추가적인 손길과 지도가 필요할 수도 있습니다. 예를 들어, 저희 컨셉 아트에는 제목에 사용자 정의된 'A' 모양이 있습니다. 에이전트는 원래 그것을 건너뛰고 글꼴(font)의 'A'만 사용했습니다. 우리가 원하는 대로 작동하게 하려면, 에이전트가 예술 작품의 윤곽선(outline)을 추적하도록 만들기 위해 몇 번 반복해야 했습니다.

이것은 비율을 측정하고 Painter 2D에서 그린 사용자 지정 시각적 요소를 채웠습니다. 그리고 다른 때에는 요청한 것보다 더 좋은 것을 얻게 될 것입니다. 컨셉 아트에 있던 해시계 모양은 문장 주변을 공전하는 작은 행성체로 돌아왔습니다. 브리프(brief)에서는 그런 것을 요구하지 않았지만, 그것이 화면에서 나온 저희가 가장 좋아하는 디테일이었습니다. 그래서 우리는 그냥 행복한 우연으로 남겨두기로 했습니다. 이것이 우리가 사용자 인터페이스를 구축할 방식입니다. 이제 작동하게 만드는 구성 요소들을 살펴보겠습니다. CLI부터 시작하겠습니다. Unity CLI는 에디터와 별개의 프로그램입니다. Unity 내부에서 어떤 작업을 하려면, 에디터 내부에 명령을 수신하는 무언가가 필요합니다. 그것이 바로 파이프라인 패키지(pipeline package)인데, 로컬 포트에서 실행되는 작은 HTTP 서버입니다. 터미널에서 명령을 보내면, 파이프라인은 일치하는 메서드를 찾고, 이를 실행한 다음, 결과를 다시 보냅니다. 이 템플릿에는 이미 이것이 설치되어 있습니다. 자신만의 프로젝트의 경우, 단 한 줄이면 됩니다. Unity pipeline install를 입력합니다. 그런 다음 프로젝트 디렉토리에서 에디터를 엽니다. 로딩이 완료되면, 그것이 Unity pipeline list 또는 실제로 연결된 에디터 목록을 보여주는 Unity status로 응답하는지 확인하세요. 터미널이 주 인터페이스입니다. 텍스트 인터페이스는 에이전트(agent)에게 이 방식이 효율적으로 작동하게 만드는 핵심 요소입니다. 에이전트는 명령을 보내고, 결과를 읽은 다음, 다음에 무엇을 할지 결정할 수 있습니다. 마우스를 전혀 만지지 않고도 말이죠. 하지만 에디터에 대한 연결이 그것을 어떻게 사용할지에 대한 지식과는 다릅니다. 에이전트는 또한 컨텍스트(context)가 필요합니다. 우리가 무엇을 만들고 있는지, 프로젝트가 어떻게 구성되어 있는지, 그리고 사용 가능한 도구를 어떻게 사용하는지 알아야 합니다. Unity는 일련의 에이전트 스킬(agent skills), 즉 에이전트가 Unity를 사용해야 하는 공식 지침을 게시합니다. Cloud Code나 Codex로 작업하는 경우, 공식 Unity 플러그인을 다운로드하고 설치하여 이 스킬들을 얻을 수 있습니다. 스킬들은 플러그인과 함께 자동으로 제공됩니다. 아래 링크된 페이지에서 선택한 에이전트와의 최신 호환성을 확인하세요. 그렇지 않다면, 스킬들은 공개 레포지토리(public repo)에서 이용 가능합니다.

이러한 스킬들은 거기서 직접 가져올 수 있습니다. 이들은 에이전트와 무관하기 때문에, Cloud, Codex, Copilot, Cursor 등 무엇을 사용하든 동일한 파일입니다. 이 특정 데모에 중요한 두 가지 스킬이 있습니다. Unity CLI 스킬은 CLI 자체를 다룹니다. 설치 방법, 파이프라인 패키지, 그리고 프로젝트별 도구를 작성하는 방법을 포함합니다. UI Toolkit 스킬은 UXML, USS, 데이터 바인딩을 다룹니다. 에이전트가 프로젝트 파일을 읽기 전에 이미 Unity와 UI Toolkit에 대해 알고 있습니다. 여전히 필요한 것은 실제로 실행할 수 있는 명령어 목록입니다. 이것이 바로 CLI에서 나옵니다. 워크플로우는 터미널과 에디터를 나란히 열어두는 것입니다. 사용자가 입력하는 모든 명령어는 앞에 열린 세션으로 전달됩니다. 터미널에 Unity 명령어를 입력해 보세요. Unity 명령어가 터미널을 채우고, 우리는 위로 스크롤하여 살펴볼 수 있습니다. 이것이 라이브 에디터가 응답하는 방식입니다. 140개가 넘는 명령어들이 있습니다. 사실상 이것은 셸(shell)에 노출된 에디터의 API입니다. 예를 들어 Capture GameView는 에이전트가 스크린샷을 찍고, 그 결과를 목표했던 것과 비교할 수 있게 합니다. 그리고 에이전트는 이런 방식으로 자신의 작업을 평가합니다. 명령어 목록은 확장 가능하며, 템플릿에는 UI 조립만을 위해 몇 가지가 추가되었습니다. '그룹별로 보기(Group By)' 옵션을 사용하여 각각의 출처를 확인할 수 있습니다. 소스 파일들은 Assets/UI Scripts/Editor에 있습니다. 이것들은 CLI 명령 속성(attribute)으로 표시된 평범한 public static C# 메서드들입니다. 이 속성을 에디터 스크립트에 추가하면 CLI가 이를 실행할 수 있습니다. UI Click은 버튼을 클릭하고 어떤 화면이 나타나는지 보고합니다. UI Tree는 UI Toolkit Element Tree를 JSON 형태로 반환합니다. 위치(Positions), 가시성(Visibility), 이름(Names) 등이 포함됩니다. 그리고 UI Validate는 UI가 좋은 상태인지 확인합니다. 구조적 변경 후마다 실행해야 합니다. 물론 이것들은 예시에 불과합니다. 모든 프로젝트는 다른 명령어 세트로 끝나게 됩니다. 필요한 것들이 바로 그것들입니다. 에이전트가 다른 것을 보길 원하나요? 그에 대한 명령어를 작성하세요. 사용자의 에이전트는 지침이 필요하며, 이 모든 것은 한 곳에서 시작됩니다.

프로젝트 루트에 있는 마크다운 파일인 AgentBrief.md입니다. 이 파일은 에이전트가 가장 먼저 읽는 파일이며, 여기서 기본적인 규칙을 설정합니다. 에이전트가 어떻게 작동하는지, 무엇을 만질 수 있고 무엇을 만질 수 없는지, 그리고 자신의 출력을 어떻게 검사할지를 정의합니다. 또한 허브 역할을 합니다. 모든 것을 자체적으로 담기보다는 프로젝트의 나머지 부분들을 가리킵니다. 이전에 설치했던 공식 Unity 스킬들, 코드를 일관되게 유지하기 위한 스타일 가이드, 그리고 나중에 다시 다룰 플레이북이 있습니다. 여기에는 'brief'라는 폴더도 연결되어 있는데, 이곳에서 무엇을 만들지 계획합니다. 그 안에는 게임 자체를 설명하는 또 다른 마크다운 파일인 Game.md가 있습니다. 이름, 외관, 캐릭터, 임무 등이 여기에 포함됩니다. 그리고 컨셉 아트를 넣습니다. 이것이 목표입니다. 각 화면이 어떻게 보여야 하는지를 나타내며, 에이전트가 일치시키려고 노력하는 대상입니다. 무엇을 디자인하든, 각 화면을 이미지로 내보내서 여기에 넣습니다. 그리고 'screens' 폴더에는 각 화면에 대한 전체 페이지 설명이 들어갑니다. 그것이 무엇을 위한 것인지, 위에서 아래까지 각 영역에 무엇이 위치하는지, 콘텐츠가 어디서 오는지, 그리고 어떤 화면과 연결되는지가 명시됩니다. 시작할 수 있도록 빈 템플릿이 있습니다. 이 모든 것은 assets 폴더 외부에 위치합니다. 따라서 Unity는 이를 임포트하지 않습니다. 이것은 에이전트를 위한 지침이며 배포될 아트워크가 아닙니다. 만약 이 모든 것을 작성하는 것이 너무 많게 느껴진다면, 에이전트에게 맡기세요. 에이전트에게 템플릿을 가리키고, 각 화면에 대한 대략적인 설명과 아트워크를 제공한 다음, 마크다운 작성을 시키세요. 에이전트는 종종 여러분이 명시하지 않은 세부 사항까지 채워 넣습니다. 다만, 그것을 기반으로 구축하기 전에 돌아온 내용을 반드시 읽어보세요. 템플릿에 각 화면의 대략적인 설명과 아트워크를 제공하고, 마크다운 작성을 시키세요. 에이전트는 종종 여러분이 명시하지 않은 세부 사항까지 채워 넣습니다. 다만, 그것을 기반으로 구축하기 전에 돌아온 내용을 반드시 읽어보세요. 아니면 예제를 다시 만들고 싶다면, 최종 'brief'는 samples 폴더에 있습니다. 이것을 루트의 빈 파일과 하나씩 복사한 다음, 나머지 샘플들은 삭제하세요.

정말로 이게 전부입니다. 몇 가지 아트워크와 작성된 지침만 있으면 됩니다. 다른 어떤 UI를 디자인할 때 시작하는 장소와 같습니다. 다만, 스펙을 읽는 사람이 에이전트라는 점이 다릅니다. 공식 에이전트 스킬(agent skills)은 에이전트가 Unity에서 일반적으로 어떻게 작동하는지 다룹니다. 여기 문서의 게임 UI 플레이북(game UI playbook)은 프로젝트 수준의 지침을 추가합니다. 파일이 어디에 가야 하는지, 화면 구조는 어떻게 되어야 하는지, 무엇을 이름 붙여야 하는지를 말입니다. 그리고 중요한 부분이 있습니다. 이것을 앉아서 그냥 작성하는 것이 아닙니다. 작업하면서 쓰여집니다. 왜냐하면 이 내용 대부분은 처음 시도했을 때 잘못되었던 것들의 목록이기 때문입니다. 예를 들어, 에이전트가 잘못된 해상도나 렌더 모드를 선택할 수 있습니다. 당신이 에이전트를 수정해 주면, '다음에 다시는 하지 않도록 이것을 기록하라'고 말합니다. 그러면 그것이 스스로에게 항목을 추가합니다. 다음 세션에서 이 파일을 시작하기 전에 읽습니다. 그리고 그 실수는 돌아오지 않습니다. 이것은 여러분의 플레이북이 반드시 저희 것과 같아 보이지 않을 것이라는 의미입니다. 프로젝트를 구축함에 따라 진화할 것입니다. 이 템플릿의 플레이북은 의도적으로 채워져 있습니다. 처음부터 그렇게 많이 필요해서가 아니라, 이미 어느 정도 메모리를 가진 에이전트가 경로를 벗어날 가능성이 적기 때문입니다. 여러분은 첫 오후 시간을 저희가 이미 저질렀던 같은 실수를 반복하는 대신 자체 디자인에 쓸 수 있게 됩니다. 이것을 요구사항이라기보다는 출발점(headstart)으로 간주하십시오. 이는 에이전트가 우리가 이미 포착한 실수들을 피하도록 돕지만, 새로운 실수를 포착하는 방법으로서도 존재합니다. 바로 여기에 저희의 검증 루프(verification loop)가 들어옵니다. 이 섹션은 에이전트에게 간단한 규칙을 부여합니다. 시각적 변경을 만든 후, 완료라고 부르기 전에 결과를 살펴보고라는 것입니다. 따라서 에이전트는 변경을 만들고, Unity에서 확인하며, 그 결과를 개요와 비교합니다. 만약 무언가 잘못되었다면, 조정하고 다시 확인하는 식입니다. 저희는 이 UI에 대한 특정한 아이디어가 있으며, 에이전트가 그것을 구축하기를 원합니다. 우리는 에이전트를 안내하고 싶지, 반대로 하고 싶지 않습니다. 에이전트의 행동을 위해 우리가 설정한 모든 것이 하나의 깔끔한 다이어그램 안에 들어맞습니다.

왼쪽에는 입력창이 있습니다. 이것이 우리가 시작하게 만든 두 줄의 프롬프트였습니다. 그런 다음 에이전트는 루프에 들어가서 그 상태를 유지합니다. 지금까지 이 네 단계 모두를 보았습니다. 관찰(Observe). 실제 상태를 얻습니다. 픽셀을 위해 게임 뷰를 캡처합니다. 숫자를 위해 UITree를 사용합니다. 지각(Perceive). 돌아온 것을 해석합니다. 이미지를 보세요. 잘려 있지는 않나요? 읽을 수 있나요? 아트워크와 일치하나요? 계획하고 결정(Plan and decide). 변경할 단 하나의 다음 항목을 고릅니다. 변수 하나씩입니다. 그런 다음 행동(Act). 코드를 작성합니다. 재컴파일합니다. 플레이 모드에 다시 진입합니다. 그리고 바로 관찰로 돌아옵니다. 이 루프는 그 아래의 다섯 가지 요소 위에서 실행됩니다. 이 비디오에서 우리가 설정한 모든 것은 이 상자들 중 하나에 있습니다. 도구(Tools)는 CLI 명령어입니다. 이것은 에디터의