N개의 도구를 M개의 모델에 연결하려면 과거에는 N×M개의 어댑터가 필요했습니다. MCP는 도구 측과 모델 측을 분리해 양쪽이 프로토콜을 한 번씩만 구현하면 상호 연결할 수 있게 합니다. 이 글은 그 설계 선택, 브라우저 환경과 페이지 동작의 추상화, 그리고 아직 해결되지 않은 부분을 설명합니다.
Agent가 실제로 일을 하려면 결국 브라우저에서 작업하는 경우가 많습니다. 로그인, 게시, 데이터 수집, 양식 입력 등이 그렇습니다. 기술적으로 어려운 점은 클릭할 수 있느냐가 아니라 브라우저를 Agent에 맡길 때 발생하는 연동 비용입니다.
N×M 연동의 늪
시장에 N개의 도구와 M개의 모델이 있다고 가정해 봅시다. 도구 제공자는 각 모델마다 연동 코드를 작성해야 하고, 모델 측도 각 도구마다 어댑터 계층을 만들어야 합니다. 양쪽이 각각 유지보수하므로 전체 구현 수는 N×M이 됩니다.
문제는 이것이 곱셈이라는 점입니다. 도구 하나가 늘면 작업 하나가 늘어나는 것이 아니라, 그 도구를 모든 모델과 각각 연결해야 합니다. 반대로 모델이 새 버전으로 바뀌면 이미 연결된 도구도 다시 검증해야 할 수 있습니다. 기능이 아무리 좋아도 특정 모델용 어댑터가 없으면 사용할 수 없고, 도구는 유통 단계에서 막히게 됩니다.
초기에는 각자 구현할 수밖에 없었습니다. 환경 목록 조회, 브라우저 시작, 페이지 읽기처럼 같은 작업도 호출자가 바뀌면 다시 작성해야 했고, 로직도 자주 달랐습니다. 어떤 구현은 대기를 클라이언트에 두고, 다른 구현은 서버에 두었습니다.
프로토콜이 양쪽을 분리한다
MCP(Model Context Protocol)는 2024년 말 공개되었습니다. 도구 검색과 호출을 표준 형식으로 정의해 무엇을 노출할지, 매개변수를 어떻게 설명할지, 어떤 구조를 반환할지를 프로토콜 안에 규정합니다.
구조는 Agent가 MCP Client에 연결되고, Client가 프로토콜에 따라 여러 MCP Server에 연결되며, 실제 기능은 Server 뒤에 있는 형태로 바뀝니다. 구현량은 N×M에서 N+M으로 줄어듭니다. 모델 측은 클라이언트를 한 번 구현하고, 도구 측은 서버를 한 번 구현하면 됩니다.
역할은 세 가지뿐입니다. Host는 모델이 실행되는 애플리케이션이며 클라이언트를 시작합니다. Client는 프로토콜 클라이언트 구현으로, 일반적으로 Server 하나당 하나가 대응합니다. Server는 도구 제공자가 작성하며 기능을 표준화된 도구로 노출합니다.
현재 통신 방식은 두 가지입니다. 로컬 모드는 표준 입력과 출력을 사용하며 클라이언트와 서버가 같은 머신에 있습니다. 경로가 짧고 설정이 적어 자동화에서 많이 사용됩니다. 원격 모드는 HTTP 또는 WebSocket을 사용하며 분산 배포에 적합하지만, 인증과 네트워크 경계를 더 명확히 설계해야 합니다.
브라우저에서는 세 가지 계층이 노출된다
브라우저 환경을 프로토콜에 연결하면 노출되는 기능은 대체로 세 계층으로 나뉩니다.
가장 위는 환경 계층입니다. 계정의 환경 목록을 조회하고, 설정에 따라 새 환경을 만들고, 지정한 환경을 시작하고, 네트워크 출구를 연결하고, 사용 후 종료합니다. 예전에는 이런 동작이 각 업체의 API에 흩어져 있었지만, 이제는 모델이 찾아서 호출할 수 있는 도구가 됩니다. 시작 후에는 보통 포트나 WebSocket 주소 같은 디버깅 엔드포인트가 반환되며, 이를 Selenium이나 Puppeteer 같은 드라이버에 넘길 수 있습니다.
중간은 페이지 계층입니다. 주소 열기, DOM 또는 접근성 트리 읽기, 탭 전환, 스크린샷 촬영을 수행합니다.
가장 아래는 동작 계층입니다. 클릭, 입력, 스크롤, 특정 조건이 충족될 때까지 대기, 팝업 처리 등이 포함됩니다.
핵심 변화는 동작의 수가 아닙니다. 환경이 직접 작성해야 하는 코드에서 Agent가 스스로 선택해 사용할 수 있는 리소스로 바뀐다는 점입니다. 목표만 명확히 말하면 새 환경을 만들지 기존 환경을 재사용할지, 어떤 순서로 호출할지를 Agent가 결정할 수 있습니다. 여러 환경을 병렬로 사용할 때 특히 분명합니다. 스케줄링이 스크립트에 하드코딩되는 대신 프롬프트에 들어갑니다.
현재도 해결되지 않은 부분
프로토콜은 연결을 해결하지만 정확성을 해결하지는 않습니다. 쉽게 놓칠 수 있는 문제가 몇 가지 남아 있습니다.
도구 설명의 품질이 호출 결과를 좌우합니다. 매개변수가 잘못되거나 잘못된 도구를 선택해도 프로토콜은 해결해 주지 못합니다. 도구가 많아질수록 설명 자체가 컨텍스트를 차지하므로 수와 세분화 수준 사이에서 균형이 필요합니다. 너무 거칠면 모델이 하나의 도구가 어떤 일을 할 수 있는지 알기 어렵고, 너무 잘게 나누면 컨텍스트가 먼저 가득 찹니다.
권한과 감사도 아직 초기 단계입니다. 많은 Server가 로컬 단일 머신 형태로 실행되며 시작부터 상당한 권한을 가지고, 세밀한 권한 부여와 호출 기록이 부족합니다. 원격 모드에서는 누가 연결할 수 있고 무엇을 볼 수 있는지부터 정해야 합니다.
페이지 안정성 문제도 사라지지 않습니다. 요소를 찾지 못하거나, 로딩 순서가 불안정하거나, 로그인 세션이 만료되거나, CAPTCHA가 나타나는 경우에는 여전히 대기, 재시도, 대체 처리가 필요합니다. 프로토콜은 진입점만 통일합니다.
생태계의 성숙도도 균일하지 않습니다. Server마다 지원하는 리소스 유형, 반환 구조, 오류 코드가 완전히 같지 않습니다. 여러 Server를 조합해 하나의 작업을 만들 때는 오케스트레이션 로직을 직접 작성해야 하는 경우가 많습니다. 프로토콜 자체도 계속 발전하고 있으므로 버전 간 동작 차이에 주의해야 합니다.
또 하나의 경계도 분명히 해야 합니다. 프로토콜은 모델이 도구를 어떻게 호출하는지를 다룰 뿐, 작업 자체가 규정에 맞는지를 판단하지 않습니다. 데이터 수집이 허가되었는지, 계정 사용 목적이 정당한지, 플랫폼 규칙을 위반하는지는 각각 별개의 판단이며 연결이 얼마나 매끄러운지와는 관계가 없습니다.
다중 환경에서는 환경 간 격리 여부와 네트워크 출구, 시간대, 언어가 한 세트로 맞춰져 있는지가 연동 방식보다 결과에 더 큰 영향을 주는 경우가 많습니다. PurpleMark는 환경 격리 계층에서 AI 도구가 호출할 수 있는 환경 생성, 시작, 네트워크 설정 인터페이스를 제공하며 하나의 클라이언트에서 이를 스케줄링할 수 있습니다.
이 글은 기술 원리를 설명하기 위한 내용입니다. 관련 프로토콜과 도구는 법률과 규정을 준수하여 사용하세요.
