AI에게 화면 조작을 맡기기 전에 고려할 점: API, MCP Tool, Skill, E2E의 경계

AI 에이전트에게 '사용자를 비활성화해 달라'고 요청하면, 화면을 열어 대상을 검색하고 버튼을 누르고 완료 메시지를 읽는 동작으로 이어지기 쉽습니다.

이는 사람이 평소에 사용하는 조작으로는 자연스럽습니다. 하지만 AI에게 같은 작업을 맡기는 경로로서는, 화면 조작이 가장 효율적이라고 할 수는 없습니다. 화면은 읽기(read), 대기(wait), 클릭 위치, 표시 문구, 모달 등의 변화를 모두 처리해야 합니다. 도중에 실패하더라도 무엇이 업데이트되었는지 화면만으로는 판단할 수 없습니다.

반면에, 대상의 상태를 가져오거나 변경하는 API가 있고 필요한 작업을 안전한 단위로 호출할 수 있다면, AI는 화면을 거치지 않고도 업무를 진행할 수 있습니다.

본 기사에서는 AI가 외부 시스템을 다룰 때의 화면 조작(Screen Operation), API, MCP Tool, Skill의 역할과 비용을 정리합니다. 아울러 실행 경로(Execution Path)와 검증 경로(Verification Path)를 분리하고, E2E를 화면 조작과 동등한 실행 경계로 취급하지 않고 테스트의 분류로서 위치시킵니다.

화면 조작이나 E2E를 없애야 한다는 주장은 아닙니다. 화면으로만 확인할 수 있는 것은 E2E 테스트로 검증하고, 데이터의 획득 및 변경은 가능한 한 화면보다 내부적인 경계(inner boundary)에서 다루는 것이 AI와 인간 모두에게 효율적이라는 이야기입니다.

화면 조작에는 인간이 무의식적으로 보완하는 정보가 많이 포함되어 있습니다. AI가 브라우저를 조작하면, 그 암묵적인 부분까지 매번 처리해야 합니다.

예를 들어, 사용자 비활성화를 관리 화면에서 진행한다고 가정해 봅시다.

1. 로그인 화면을 열기
2. 인증 정보를 입력하기
3. 사용자 목록으로 이동하기
...

이 경로는 화면의 품질을 확인하는 데는 필요합니다. 하지만 상태 변경만이 목적이라면, 다음과 같은 비용을 지불하고 있습니다.

• 화면 로딩 및 비동기 처리를 기다림
• 표시 문구, DOM 구조, 버튼 배치 변경으로 실패함
• 검색 결과 목록 순서나 동명이인 데이터를 해석함
• 클릭 후에 실제로 업데이트되었는지 별도로 확인해야 함
• 실패 시, UI/통신/업무 처리/DB 중 어디에서 멈췄는지 구분해야 함

이것이 E2E가 나쁘다는 의미는 아닙니다. E2E는 사용자가 실제로 거치는 동선, 입력 제어, 권한에 따른 표시, 화면 이동, 렌더링을 확인하기 위한 테스트입니다.

다만, AI가 내부 상태를 반복적으로 조사하고 수정할 때마다 E2E를 주 경로로 삼으면, 목적 대비 확인 범위가 넓어집니다. 화면을 거치기 때문에 변경하려는 데이터보다 더 많은 불확실성을 안게 됩니다.

'사용자 비활성화' 작업은 다음과 같이 여러 경계에서 실행될 수 있습니다.

여기서 중요한 것은 이들이 같은 계층의 대체물이 아니라는 점입니다.

API는 시스템의 기능입니다. MCP Tool은 AI에게 공개하는 작업을 정리하는 경계입니다. Skill은 그 작업을 사용해 업무를 완료하기 위한 절차입니다. 반면, E2E는 화면을 포함한 사용자 동선을 검증하는 테스트의 분류입니다.

Playwright는 브라우저를 조작하는 수단이며, UI를 포함한 사용자 동선 전체를 검증하는 대표적인 예가 E2E 테스트입니다. AI에게 브라우저를 조작하게 하는 것 자체가 반드시 E2E 테스트가 되는 것은 아닙니다.

상단은 AI가 상태를 획득하고 변경하는 실행 경로입니다. 하단은 사용자가 UI를 사용하는 경로이며, E2E 테스트는 화면이라는 별도의 계약을 확인합니다. 실행 경로와 검증 경로를 분리함으로써, 상태 변경의 실패와 화면상의 결함을 개별적으로 다룰 수 있습니다.

AI가 외부 시스템을 조작하는 방법은 MCP가 등장하기 전부터 있었습니다. GitHub라면 GitHub API, Slack이라면 Slack API, 사내 시스템이라면 그 시스템의 API를 AI 애플리케이션에서 개별적으로 호출할 수 있습니다.

연결처마다 전용 통합(integration)을 만드는 방식으로는, AI 애플리케이션과 외부 시스템의 조합이 늘어날 때마다 연결하거나 호출하는 방법을 구현하고 유지보수해야 합니다.

AI 앱 A ─ GitHub 전용 구현 ─ GitHub API
├ Slack 전용 구현 ─── Slack API
└ 사내 전용 구현 ──── 사내 API
...

Anthropic이 2024년 11월에 공개한 MCP는 AI 애플리케이션과 외부 데이터 및 기능을 연결하는 공통 프로토콜입니다. MCP를 지원하는 애플리케이션은 공통된 방식으로 MCP 서버에 접속하여, 서버가 공개하는 Tool이나 Resource를 이용할 수 있습니다. Anthropic은 MCP 발표에서, 연결 대상마다 개별 구현이 필요했던 상황을 MCP가 해결하고자 하는 과제로 제시했습니다.

AI 앱 A ─ MCP Client ─ MCP ─ GitHub용 MCP Server ─ GitHub API
├ MCP ─ Slack용 MCP Server ─── Slack API
└ MCP ─ 사내MCP Server ────── 사내API
...

이러한 공통화 덕분에 연결별 중복을 줄일 수 있지만, 통합 작업 자체가 사라지는 것은 아닙니다. 연결 대상별 MCP 서버 구현 외에도, 인증, 권한, 서비스 고유의 의미나 조작 단위는 계속 다루어야 합니다.

즉, MCP는 기존 API를 대체하는 것이 아닙니다. API가 각 시스템의 기능을 정의한다면, MCP는 AI 애플리케이션이 외부 기능이나 데이터를 발견하고 공통된 방식으로 이용할 수 있도록 연결을 표준화합니다. MCP Tool 내부에서 REST API나 SDK를 호출하는 구성은 이러한 역할 분담에 따릅니다.

API는 AI 전용 메커니즘이 아닙니다. 웹 화면, 배치(batch), 모바일 앱, 외부 연동, AI 등 어디서든 이용할 수 있는 시스템 기능과 데이터의 진입점입니다.

GET /[email protected]
PATCH /users/usr_123
{...

이 API가 권한 부여(authorization), 입력 검증(input validation), 감사 로그(audit log), 공집합성(idempotency)을 적절히 갖추고 있다면, 화면을 거치는 것보다 적은 단계로 목적을 달성할 수 있습니다. 결과 또한 HTTP 상태 코드, 업데이트 후의 상태, 감사 ID와 같이 구조화되어 받을 수 있습니다.

다만, 기존 API를 그대로 AI에 전달한다고 좋은 것은 아닙니다. 내부 API에는 AI가 공개하고 싶지 않은 필드, 낮은 수준의 업데이트, 여러 호출을 전제로 하는 조작 등이 포함될 수 있기 때문입니다.

예를 들어, 다음 API만을 AI에게 보여준다고 가정해 봅시다.

GET /users/{id}
PUT /users/{id}
POST /audit-logs

AI는 사용자를 가져오고, 업데이트용 대형 JSON을 구성하며, 무관한 항목이 손상되지 않도록 전송하고, 감사 로그도 잊지 않고 기록해야 합니다. 기술적으로는 가능하지만, 업무 조작으로서는 경계가 너무 낮습니다.

API는 우선 인간의 애플리케이션을 포함한 시스템 경계로 설계합니다. AI에게 어디까지 무엇을 시킬지는 그 한 단계 위에서 생각하는 것입니다.

MCP는 AI 애플리케이션과 외부 툴/데이터를 연결하는 공통 프로토콜입니다. MCP 서버는 실행 가능한 Tool, 문맥이 되는 Resource, 정형적인 Prompt 등을 공개할 수 있습니다. MCP 사양에서는 Tool을 모델이 호출하는 함수로 위치시키고 있습니다.

MCP Tool 내부에서 REST API, GraphQL, SDK를 이용하는 구성은 자연스럽습니다. MCP는 API와 경쟁하는 것이 아닙니다.

구현상, MCP Tool이 기존 API의 래퍼(wrapper)여야만 하는 것은 아닙니다. Tool 자체가 백엔드 처리를 구현할 수도 있습니다. 다만 상태 변경의 경우, 권한 부여, 입력 검증, 감사, 업무 규칙을 집약한 Application API 또는 Application Service를 거치는 것이 UI, 배치, AI 모두에서 동일한 제약을 지키기 쉽습니다. 본문에서는 AI에게 공개하는 조작 경계로서 MCP Tool을 정리합니다.

앞서 언급된 낮은 수준의 API에 대해, AI에게는 다음과 같은 Tool을 공개할 수 있습니다.

find_user_by_email(email)
disable_user(user_id, reason)
get_user_status(user_id)

disable_user 내부에서 대상의 현재 상태를 확인하고, 비활성화할 수 있는 전이만 허용하며, 이유와 실행자를 감사 로그에 남길 수 있습니다. 호출하는 쪽의 AI는 '어떤 필드를 남길지'가 아니라, '누구를, 왜 비활성화할지'만 전달하면 됩니다.

이렇게 하면 AI에게 보여주는 조작 이름, 입력, 출력, 권한 부여, 감사를 업무 단위로 맞출 수 있습니다.

기존 API의 모든 엔드포인트를 그대로 MCP Tool로 만들 필요는 없습니다. 다음 조건에 해당한다면, AI용 Tool로 묶을 가치가 있습니다.

• 여러 API를 올바른 순서로 호출할 필요가 있다
• 업데이트 전 상태 확인이나 충돌(競合) 확인이 필수적이다
• 조작 이유나 티켓 번호를 감사 기록에 남길 필요가 있다
• AI에게는 접근시키지 않을 내부 필드가 있다
• 성공/실패를 화면 문구가 아닌 구조화된 결과로 반환하고 싶다

한편, 기존 API가 이미 이 경계를 충족하며 권한 부여(認可)와 감사까지 갖추어져 있다면, 얇은 래퍼(wrapper)를 추가할 필요는 없습니다. MCP Tool을 만드는 목적은 HTTP를 숨기는 것이 아니라, AI가 실수하기 어려운 조작의 경계(操作境界)를 만드는 것입니다.

Skill은 AI에게 재사용 가능한 절차, 판단 기준, 참고 자료, 출력 형식을 제공하는 것입니다. OpenAI의 Skills 설명에서도, MCP 서버가 라이브 데이터와 제어된 조작을 담당하고, Skill은 그것들을 어떤 순서로 사용하고 어떤 결과를 반환할지라는 워크플로우를 담당하는 것으로 설명됩니다.

Skill은 지시문(指示文)만으로 구성되는 것은 아닙니다. SKILL.md에 더해, scripts, references, assets 등의 보조 파일을 포함할 수 있습니다. Skill 작성 가이드에서는 스크립트도 동봉할 수 있다고 설명합니다. 따라서

이 순서로 하면 'MCP를 넣었으니 전부 Tool화한다', 'Skill을 만들었으니 안전해진다', 'AI에 맡기니 화면 자동화가 된다'와 같은 목적과 수단의 역전(逆転)을 피할 수 있습니다.

AI에게 브라우저 조작을 시키는 것은 가능합니다. 하지만, 브라우저 조작과 E2E 테스트는 같지 않습니다. 화면은 인간의 이용 경험을 확인하는 경계이며, 내부 상태를 반복적으로 획득하고 변경하는 주 경로로 삼으면 대기(待機), 표시 변경, 모호한 실패 판정 등의 비용을 안게 됩니다.

• API는 시스템의 기능과 상태를 직접 다루는 진입점입니다.
• MCP Tool은 AI에게 공개할 조작을 안전하고 의미 있는 단위로 정리합니다.
• Skill은 여러 Tool을 사용하여 업무를 진행하는 절차와 판단 기준입니다.
• E2E 테스트는 화면의 흐름, 표시, 입력, 권한을 확인하기 위해 사용합니다. AI의 브라우저 조작 그 자체가 E2E 테스트는 아닙니다.

우선적으로 목적 상태를 어떤 경계에서 획득하고 변경해야 할지 결정합니다. 그 위에 AI용 조작 경계가 필요하다면 MCP Tool을 만들고, 반복하는 업무 절차가 있다면 Skill로 만듭니다. 화면 조작은 화면으로만 확인할 수 있는 것에 한정하고, E2E 테스트는 사용자 흐름(導線) 검증에 사용한다고 하면, AI의 작업도 테스트도 추적하기 쉬워집니다.