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 및 로컬 세션에 대한 애플리케이션 서버의 의존성은 팀이 이 모델을 도입하기 전에 평가해야 할 실질적인 제약으로 남아 있습니다.