MCP와 GUI: 기업 업무에 맞는 인터페이스 선택하기

의미를 바탕으로 티켓을 찾고 변경을 준비할 때는 에이전트와의 대화가 편리합니다. 쓰기 전에 여러 필드를 검토할 때는 기존 값과 새 값을 함께 보여주는 양식이 유용합니다. MCP는 애플리케이션을 도구에 연결합니다. 누가 티켓을 수정할 수 있는지는 업무 시스템이 판단해야 합니다.

아래는 사내 서비스 데스크를 가정한 학습용 사례입니다. 직원이 티켓을 읽고 담당자 변경을 제안한 다음 확인을 요청합니다. 특정 제품에 이미 구현된 연동을 설명하지 않습니다. 도구와 필드 이름은 설계를 위한 예시이며, 도입 전에 선택한 시스템에서 구현하고 검증해야 합니다.

읽기, 제안, 쓰기로 나누기

MCP 아키텍처에서 호스트 애플리케이션은 클라이언트를 통해 서버와 통신하고 서버는 도구 등의 기능을 제공합니다. 적절한 이름의 tool이 존재한다고 사용자에게 업무 권한이 생기지는 않습니다.

작업	우선 검토할 인터페이스	허용 조건
사용자가 접근할 수 있는 티켓 찾기	MCP와 대화	서버가 사용자 권한에 따라 결과를 제한
새 담당자 제안	MCP로 초안 작성, 양식으로 비교	제안 단계에서는 기록을 변경하지 않음
변경 확정	GUI 또는 검증된 MCP Apps 양식	정확한 필드를 표시하고 서버가 권한과 최신 상태를 재확인

이 표는 해당 사례에 대한 설계 제안입니다. 일반 GUI도 중요한 값을 숨기거나 보호가 부족한 backend를 호출할 수 있습니다. 실제 쓰기 경로와 검증 증거를 평가해야 합니다.

학습용 티켓 REQ-204의 담당자가 team-a이고 사용자는 team-b로 바꾸려 한다고 가정합니다. 대화로 대상을 찾은 뒤 저장 전에 ID, 기존 값, 새 값, 변경의 영향을 표시하세요. 알림 발송, 접근 권한 변경, 외부 작업 실행 여부도 포함합니다. 제목이 같다는 이유만으로 대상을 선택하면 안 됩니다.

확인을 정확한 변경 내용에 연결하기

내부 확인 객체는 다음처럼 설계할 수 있습니다.

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

이는 애플리케이션 자체 구조이며 MCP 표준이 아닙니다. 저장할 때 서버는 revision과 권한을 대조해야 합니다. 티켓이 이미 바뀌었다면 제안을 다시 보여줘야 합니다. 확인 버튼이 다른 diff를 조용히 적용해서는 안 됩니다.

MCP 사양의 Tools 절은 호출 가시성, 사용자가 작업을 거부할 수 있는 능력, 서버 측 입력 및 접근 검증을 설명합니다. 프로토콜은 특정 확인 인터페이스를 강제하지 않습니다. 따라서 MCP 서버에 접근할 수 있다는 사실을 모든 기업 작업의 허가로 보아서는 안 됩니다.

timeout 후 재시도에 대한 backend 동작을 미리 정하세요. 응답이 유실되면 보관한 작업 식별자로 결과를 먼저 조회합니다. 무조건 재시도하면 알림이 두 번 발송되거나 외부 효과가 반복될 수 있습니다. 이전 담당자로 되돌릴 수 있어도 변경의 모든 결과를 취소할 수 있는 것은 아닙니다.

MCP Apps가 적합한 경우

MCP Apps는 지원하는 클라이언트 안에 서버 도구의 대화형 UI를 표시할 수 있습니다. 호스트는 sandboxed iframe에서 화면을 렌더링합니다. 선택한 클라이언트와 서버 버전이 확장을 지원하면 대화 안에서 필드 비교 양식을 제공할 수 있습니다.

이 사례에서는 티켓, proposed diff, 명확한 적용 및 취소 버튼을 보여줄 수 있습니다. 서버의 인가, revision 검증, 결과 로그는 여전히 필요합니다. iframe의 sandbox는 서비스 데스크 권한을 대체하지 않으며 임의의 서버를 신뢰할 수 있게 만들지도 않습니다.

현재 클라이언트에서 diff를 확실히 보여주거나 기업 확인 절차를 완료하거나 필요한 접근성을 제공할 수 없다면 별도 GUI를 유지하세요. 모델을 사용할 수 없어도 사용자가 ID로 같은 티켓을 열어 실제 상태를 확인할 수 있어야 합니다. 모델 장애 때문에 변경이 저장됐는지 추측하게 해서는 안 됩니다.

시범 환경 구성: 모델은 BetterToken, 티켓은 MCP

시범 환경에서는 Claude Desktop을 클라이언트로 선택하고 API 설정 가이드에 따라 BetterToken을 통해 Claude 모델을 연결할 수 있습니다. Claude provider에 접근 가능한 자신의 API Key와 Gateway Base URL https://bettertoken.ai를 사용하세요. 정확한 필드와 버전별 조건은 가이드에서 확인합니다. 먼저 일반적인 짧은 메시지에 대한 응답을 받아 모델 연결을 독립적으로 검증합니다.

그다음 선택한 클라이언트에서 서비스 데스크의 테스트 MCP 서버를 연결하고 기밀이 없는 티켓 한 건에 접근해 봅니다. BetterToken은 모델 API 계층을 제공합니다. 서비스 데스크 자격 증명, 사용자 권한, 쓰기 확인은 별도로 설정합니다. 모델이 연결됐다고 클라이언트의 특정 모드에서 MCP Apps를 지원하는 것은 아닙니다. 내장 양식을 선택하기 전에 따로 검증하고, 사용할 수 없다면 GUI에서 확인하도록 유지합니다.

BetterToken을 통해 테스트용 모델을 연결한 다음 아래 검사를 수행하세요. 가상 데이터를 사용합니다. 모델에 전달된 MCP 응답 내용이 API 요청에 포함될 수 있습니다. 실제 기업 데이터를 다룰 권한은 조직의 규칙에 따라야 합니다.

실패 상황에서 선택 검증하기

테스트 환경에서 두 역할과 기밀이 없는 티켓을 사용합니다. 한 역할은 담당자를 바꿀 수 있고, 다른 역할은 접근 가능한 기록을 읽을 수만 있습니다. 각 검사의 실제 결과를 남기세요. 아래 표는 기대하는 기준이며 완료된 시험 보고서가 아닙니다.

검사	기대 결과
사용자가 접근할 수 없는 다른 사람의 티켓을 요청	서버가 내용을 노출하지 않고 거부
읽기 전용 역할이 담당자 변경을 확정	서버가 쓰기를 거부
사용자가 proposed diff를 취소	티켓이 그대로 유지
조회 후 revision 변경	저장을 중단하고 다시 확인하도록 요청
저장 후 응답 유실	재시도 여부를 결정하기 전에 상태 확인
모델 사용 불가	GUI에서 실제 상태 조회 가능
키보드와 screen reader로 양식 사용	변경을 이해하고 확정 또는 취소 가능

검사에 실패하면 원인이 해결될 때까지 해당 종류의 쓰기는 기존의 검증된 인터페이스에 남겨두세요. MCP 읽기 기능은 별도로 평가할 수 있습니다. 읽기에도 권한과 결과 범위 제한이 필요합니다.

나중에 추적할 수 있는 기록 남기기

이 사례에서는 사용자, 티켓 ID, 합의된 diff, 원래 revision, 시각, 작업 식별자, backend 결과를 기록하면 유용합니다. 필요 없이 tokens나 비공개 티켓의 전체 내용을 로그에 저장하지 마세요. 로그 보존 및 접근 정책은 조직의 규칙을 따라야 합니다.

시범 운영 후에는 작업마다 결정을 기록합니다. 읽기는 대화, 준비는 초안, 쓰기는 선택한 검증된 양식으로 구분할 수 있습니다. 거부 테스트 결과와 남은 문제의 담당자도 첨부하세요. 권한, 확인, 장애 복구 방식이 명확해진 작업부터 MCP 사용 범위를 넓힐 수 있습니다.