Uno Platform은 크로스 플랫폼 .NET 애플리케이션을 구축하기 위해 AI 에이전트를 사용할 때 가장 큰 문제는 코드 작성이 아니라 애플리케이션을 실행한 뒤 코드가 제대로 작동하는지 아는 것이라고 본다. 에이전트는 컴파일과 빌드가 가능한 설정 페이지를 생성할 수 있지만, 레이아웃이나 동작의 오류는 실제 애플리케이션 안에서만 드러날 수 있다.
이 격차를 해소하기 위해 Uno Platform은 Microsoft가 커뮤니티와 협력해 개발하는 공식 MCP C# SDK 패키지를 사용해 C#으로 두 서버를 구축했다. 첫 번째 서버는 지식과 문서를 제공하는 데 초점을 맞추고, 두 번째 서버는 에이전트를 실제로 실행 중인 애플리케이션에 연결해 에이전트가 애플리케이션을 실행하고 검사하고 상호작용할 수 있도록 한다.
서로 다른 두 가지 역할과 시간 주기를 가진 두 서버
Uno Platform의 설계에서 핵심적인 결정은 “무엇이 올바른 상태여야 하는가?”라는 문제와 “지금 무슨 일이 일어나고 있는가?”라는 문제를 분리한 것이었다. 문서 서버는 플랫폼 업데이트가 출시되거나 페이지가 수정될 때 변하는 정보를 다루는 반면, 애플리케이션 서버는 애플리케이션 실행 중에 변하는 특정 실행 세션의 상태를 다룬다.
문서 서버는 mcp.platform.uno/v1 주소에서 공개적으로 호스팅되며, 상태 비저장 방식으로 HTTP를 통해 작동한다. 이 서버는 공식 문서를 검색하고 전체 페이지를 Markdown 형식으로 가져오는 도구를 제공하며, 실행 중인 애플리케이션과 작업하기 위한 규칙과 일반적인 Uno Platform API 사용 규칙도 제공한다. 또한 현재의 모범 사례에 따라 애플리케이션을 생성하는 /new와 기존 코드베이스에 연결된 대화를 초기화하는 /init이라는 두 개의 프롬프트를 포함한다.
공개된 경험에 따르면 이 서버를 호스팅하는 이점은 문서 페이지 하나를 업데이트하면 새 버전이 필요한 NuGet 패키지에 지침을 포함하는 대신, 에이전트가 다음에 서버를 호출할 때 해당 변경 사항이 반영된다는 점이다.
애플리케이션 서버는 개발자의 컴퓨터에서 stdio를 통해 .NET 도구로 작동하며, 에이전트를 Uno DevServer에 연결한다. 이 서버는 단일 세션을 위해 설계된 상태 저장 서버다. Hot Reload를 활성화한 디버그 모드로 애플리케이션을 실행하고, 스크린샷을 캡처하고, 시각적 요소 트리의 XML 표현을 추출한 다음 클릭, 키 누르기, 텍스트 입력, 자동화 요소 동작 호출을 수행할 수 있다.
인터페이스 검증에는 스크린샷 이상의 것이 필요하다
Uno Platform은 시각적 요소 트리 도구가 검증 주기에서 가장 중요한 부분이라고 본다. 스크린샷은 에이전트가 무언가 잘못되어 보인다는 사실을 발견하는 데 도움을 주지만, 요소 트리는 문제를 일으킨 요소와 그 속성을 드러낸다. 실용적으로 표현하면 픽셀은 발견에 적합하고 구조는 진단에 적합하며, 에이전트는 두 가지 모두를 필요로 한다.
플랫폼은 가능한 경우 uno_app_pointer_click을 통한 좌표 클릭 대신 uno_app_element_peer_action을 사용할 것을 권장한다. 좌표 클릭은 창 크기와 픽셀 밀도의 차이에 영향을 받지만 자동화 동작은 요소 자체에 연결되기 때문이다. 또한 이 권장 사항을 별도의 문서가 아니라 도구 설명에 포함했다. 에이전트가 별도 문서를 로드하지 않을 수 있는 반면, 도구 설명은 선택 결정에 직접 영향을 미치기 때문이다.
이러한 도구를 사용하면 에이전트는 인터페이스를 수정한 뒤 애플리케이션을 다시 로드하고, 화면을 캡처하고, 시각적 트리를 읽고, 상호작용 경로를 실행하며, 변경 사항을 전달하기 전에 결과가 요구 사항과 일치하는지 판단할 수 있다. Uno Platform은 이 접근 방식을 웹 애플리케이션용 Playwright 도구와 유사하지만, Windows, macOS, Linux, iOS, Android, WebAssembly에서 실행되는 네이티브 .NET 애플리케이션에 맞춘 방식으로 설명한다.
도구 비용은 컨텍스트 설계의 일부다
이 경험은 MCP에 관한 논의에서 자주 간과되는 실용적 제약에 주목하게 한다. 도구 정의는 어떤 질문을 하기 전부터 모델의 컨텍스트 윈도우를 소비한다. Uno Platform은 문서 서버가 약 6.4천 토큰을 소비하는 반면, 애플리케이션 서버는 약 1.5천 토큰을 소비한다고 밝혔다. 비교를 위해 같은 세션에 통합된 GitHub MCP 서버는 약 5.2천 토큰을 소비한다.
따라서 도구 설명은 단순한 기술 문서가 아니다. 자료에 따르면 도구 설명은 에이전트가 도구를 선택하는 데 영향을 미치는 일종의 지침 또는 프롬프트다. 그러므로 이름, 설명, 입력 스키마를 간결하고 높은 신호 대 잡음비로 유지하는 것이 중요하며, 운영상 중요한 선호 사항은 모델이 결정을 내릴 때 읽는 위치에 포함해야 한다.
개발자에게 실질적으로 달라지는 점은 무엇인가?
Uno Platform은 개별 도구만 제공하는 데 그치지 않고 Skills라고 부르는 기능도 추가한다. Skills는 도구를 언제 어떤 순서로 사용해야 하는지, 작업 완료가 무엇을 의미하는지를 정의하는 구조화된 절차다. 이 라이브러리에는 MVUX, 상태, 데이터 소스, 탐색, 스타일 지정, Uno Toolkit 요소, 테스트와 같은 시나리오가 포함되며, 애플리케이션 서버를 통해 UI 테스트를 자동화하는 uno-testing-ui라는 Skill도 포함된다.
이 구조는 최신 문서, 검사할 수 있는 실행 중인 애플리케이션, 사전 정의된 워크플로 절차를 결합한다. 플랫폼에 따르면 이러한 구성 요소는 브라우저 안에서 완전한 크로스 플랫폼 .NET 애플리케이션을 생성하는 Uno Platform Studio 3.0을 지원한다. 이는 계획과 실행을 위해 Microsoft Agent Framework를 사용하고, 컴파일, 어셈블리 로드, NuGet 변경 사항 해결, 실행 중인 애플리케이션에 결과 다시 로드를 위해 Roslyn 작업 영역에 의존한다.
certi.news의 편집적 해석: 이 경험의 실제 가치는 코드를 작성하는 또 하나의 에이전트를 추가하는 데 있는 것이 아니라, 에이전트를 텍스트 생성기에서 최신 지식 소스에 질의하고 실제 애플리케이션에서 결과를 테스트할 수 있는 주체로 전환하는 데 있다. 또한 두 서버를 분리한 방식은 다른 MCP 프로젝트에도 적용할 수 있는 설계 원칙을 제시한다. 장기 지식과 실행 상태를 분리하고, 형식적인 선호가 아니라 배포 구조에 따라 HTTP 또는 stdio를 선택하라는 것이다.
그러나 이 자료는 이 방식이 인간 검토의 필요성을 없애거나 모든 경우에 애플리케이션의 정확성을 보장한다고 입증하지는 않는다. 자료는 Uno Platform의 경험과 도구를 소개할 뿐, 오류 발견률이나 코드 품질에 대한 독립적인 측정 결과를 제시하지 않는다. 또한 도구 정의 비용과 Uno DevServer 및 로컬 세션에 대한 애플리케이션 서버의 의존성은 팀이 이 모델을 도입하기 전에 평가해야 할 실질적인 제약으로 남아 있다.