2일 만에 20개의 MCP App을 구축하며 얻은 교훈
저희 팀은 이틀 만에 20개의 MCP App을 구축했습니다. 이를 통해 이 도구들이 무엇을 할 수 있고, 어떤 부분에서 한계가 있는지 명확하게 파악할 수 있었습니다.
MCP App은 MCP 스펙의 첫 번째 공식 확장 기능입니다. 도구가 결과와 함께 UI 리소스를 반환할 수 있게 해줍니다. 호스트는 이 UI를 샌드박스 처리된 iframe 내에서 렌더링합니다. 채팅창에서 표, 차트, 양식(form)을 직접 보여줄 수 있습니다.
시각적 정보는 종종 텍스트보다 효과적입니다. 차트는 CSV 파일보다 낫고, 풀 리퀘스트(pull request) 목록은 텍스트 뭉치보다 읽기 쉽습니다.
저희가 배운 교훈은 다음과 같습니다:
• App은 서버 내부에 존재합니다 MCP App은 호스팅된 URL이 아닙니다. HTTP가 아닌 MCP를 통해 가져옵니다. UI 코드는 MCP 서버와 함께 배포됩니다.
• React와 Vite를 사용하세요
기존 디자인 시스템을 활용하기 위해 React를 사용했습니다. /ui 폴더에 하나의 Vite 프로젝트를 설정했습니다. 빌드 시 모든 TSX 파일에 대해 하나의 HTML 파일이 생성됩니다.
• 텍스트는 여전히 기본 규약(contract)입니다 호스트가 MCP App을 지원하지 않으면 UI 속성을 무시합니다. 사용자는 텍스트 응답만 보게 됩니다. 정답을 UI에만 담지 마세요. 그렇게 하면 터미널 클라이언트를 사용하는 사용자에게는 도구가 제대로 작동하지 않습니다. 사용자의 절반은 텍스트만 볼 것이라고 가정하고 항상 설계하세요.
• 일관되지 않은 레이아웃을 예상하세요 모든 호스트는 스펙을 다르게 구현합니다. ChatGPT는 넓게 렌더링하고, Claude는 좁게 렌더링합니다. 모바일은 또 다릅니다. 처음부터 좁은 너비에서도 레이아웃이 재배치(reflow)되도록 설계하세요.
• 개발 루프가 느립니다 아직 표준 테스트 도구가 없습니다. 매번 클라이언트에서 직접 빌드, 설치 및 확인을 해야 합니다. 일반적인 프론트엔드 작업에 비해 느리게 느껴집니다.
• App에서 비밀 정보를 수집하지 마세요 App은 샌드박스 iframe에서 실행됩니다. 호스트는 그 내용을 볼 수 있습니다. 양식 필드에 API 키나 OAuth 토큰을 절대 넣지 마세요. 민감한 데이터가 필요한 경우 별도의 보안 양식을 사용하세요.
지금 시작한다면:
- UI를 서버 내부에 번들링하세요.
- 멀티 페이지 Vite 설정을 사용하세요.
- 기존 디자인 시스템을 직접 가져오세요.
MCP App은 초기 단계이며 스펙은 계속 변하고 있습니다. 툴링은 미비하지만, 배포할 가치가 충분합니다.
출처: https://dev.to/arcade/lessons-from-building-20-mcp-apps-in-2-days-1f98
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi