🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

클라우드의 인공지능 에이전트가 사용자 기기의 엑셀 파일과 로컬 도구를 호출할 수 있도록, 브라우저 확장 프로그램과 로컬 브리지를 이용해 MCP 메시지를 웹소켓·네이티브 메시징·표준 입출력 사이에서 중계한 구현 사례다.

📌 핵심 요약

• MCP는 인공지능 애플리케이션과 외부 데이터·도구의 연결을 표준화하지만, 원격 MCP 클라이언트가 사용자 기기에서 실행되는 로컬 MCP 서버에 접근하는 구성은 기본 전송 방식만으로 직접 해결되지 않는다.
• 제시된 구조는 클라우드 에이전트 런타임, 브라우저 확장 프로그램, 사용자 기기의 MCP 브리지, 로컬 MCP 서버라는 네 구성요소로 이루어진다.
• 도구 호출은 웹소켓을 통해 브라우저 확장 프로그램에 전달된 뒤 네이티브 메시징으로 브리지에 도착하며, 브리지는 봉투 형식을 제거한 원본 JSON-RPC 메시지를 표준 입출력으로 MCP 서버에 전달한다.
• 에이전트는 MCP 초기화 절차를 마친 후 매 사용자 메시지마다 도구 목록을 조회하고, 세션 식별자와 JSON-RPC 요청 식별자에 연결된 비동기 대기 객체로 여러 동시 요청의 응답을 구분한다.
• 브리지는 MCP 서버를 자식 프로세스로 계속 실행하고 두 개의 비동기 입출력 루프와 큐를 사용하며, 예시 배포에는 계정 권한, 개발 도구, 브라우저 확장 프로그램 설치, 로컬 브리지 등록과 런타임 식별자 설정이 필요하다.

🧩 주요 포인트

1. 클라우드에 중앙 배포된 에이전트와 사용자 기기의 로컬 파일을 연결함으로써, 에이전트 관리는 중앙화하면서 파일 처리는 로컬 도구에 맡길 수 있다.
2. 중계 계층은 전송 구간별 포장만 변환하고 MCP의 JSON-RPC 내용은 수정하지 않으므로, 기존 표준 MCP 서버를 별도 프로토콜 변경 없이 활용할 수 있다.
3. 짧은 유효기간의 서명된 연결 주소, 자동 재연결, 동적 도구 검색, 요청별 응답 매칭을 결합해 연결 만료와 복수 도구 호출을 사용자 흐름 안에서 처리한다.

🧠 상세 정리

1. 클라우드 에이전트와 로컬 파일 사이의 간극

이 글의 출발점은 인공지능 에이전트는 클라우드에서 실행되지만 사용자의 스프레드시트는 노트북에 저장되어 있다는 구조적 간극이다. 2024년 11월 앤트로픽이 공개한 MCP는 인공지능 애플리케이션이 외부 데이터와 도구에 연결되는 방식을 표준화하며, 같은 기기의 프로세스끼리 통신하는 표준 입출력과 원격 통신용 스트리밍 HTTP 전송을 지원한다. 그러나 MCP 클라이언트가 원격 환경에 있고 MCP 서버가 사용자 기기에 있는 조합은 이 두 방식만으로 자연스럽게 연결되지 않는다. 특히 엑셀과 로컬 파일을 주로 다루는 재무 관리자와 분석가에게는 중앙 배포된 에이전트가 브라우저 문맥을 활용하면서 사용자 기기의 파일에도 작업할 수 있는 통로가 필요하다. 글은 출시 후 1년 안에 4만 1천 건이 넘는 대화를 처리한 내부 재무 보조 시스템에서 사용한 방식을 단순화해 재현한다고 설명한다.

2. 네 구성요소로 분리한 전체 구조

전체 구조는 클라우드 에이전트 런타임, 브라우저 확장 프로그램, 로컬 MCP 브리지, 로컬 MCP 서버의 네 부분으로 나뉜다. 클라우드 런타임은 스트랜즈 에이전트를 호스팅하며 MCP 클라이언트로서 도구 검색과 도구 호출 요청을 생성한다. 브라우저 확장 프로그램은 사용자에게 채팅 화면을 제공하는 동시에 웹소켓으로 연결된 클라우드 런타임과 네이티브 메시징으로 연결된 로컬 브리지 사이에서 메시지를 양방향으로 중계한다. 로컬 브리지는 브라우저가 등록된 네이티브 메시징 호스트를 통해 시작하는 패스트MCP 프록시로, 브라우저의 메시지 봉투와 MCP의 원시 JSON-RPC 사이를 변환한다. MCP 서버는 브리지와 같은 기기에서 실행되기 때문에 표준 입출력 전송을 그대로 사용하며, 각 구성요소는 사용자 인터페이스·원격 추론·전송 변환·실제 로컬 도구 실행이라는 역할을 분담한다.

3. 도구 호출이 왕복하는 과정

사용자가 브라우저 확장 프로그램에서 메시지를 보내면 확장 프로그램은 미리 서명된 웹소켓을 통해 클라우드 런타임과 통신한다. 에이전트가 도구를 필요로 할 때는 MCP JSON-RPC 요청을 MCP용 봉투와 세션 식별자로 감싸 확장 프로그램에 보내고, 확장 프로그램은 중계에 필요한 내부 내용을 네이티브 메시징으로 로컬 브리지에 전달한다. 브리지는 봉투에서 JSON-RPC 내용을 꺼낸 뒤 이를 수정하지 않고 표준 입출력을 통해 MCP 서버로 넘기며, 예시에서는 budget.xlsx를 대상으로 read_sheet 도구를 호출한다. MCP 서버가 반환한 응답은 반대 경로를 따라 브리지에서 다시 봉투에 담기고, 확장 프로그램을 거쳐 클라우드 런타임으로 전달된다. 이처럼 각 구간은 필요한 포장 계층만 추가하거나 제거하고 실제 MCP 요청과 응답 내용은 보존하므로, 에이전트는 최종 도구 결과를 받아 생성을 이어갈 수 있다.

4. 에이전트 연결·초기화·도구 검색

브라우저 측 패널은 시작할 때 백그라운드 스크립트와 네이티브 브리지를 거쳐 미리 서명된 웹소켓 주소를 요청한다. 브리지는 사용자 기기에 있는 자격 증명과 전용 소프트웨어 개발 도구를 이용해 배포된 런타임 식별자 범위로 제한된 서명 주소를 만들며, 이 주소의 유효기간은 5분이고 자격 증명 자체는 사용자 기기를 떠나거나 브라우저에 들어가지 않는다. 연결이 주소 만료나 네트워크 중단으로 끊기면 패널은 2초 뒤 새 주소를 요청해 자동으로 다시 연결한다. 에이전트는 도구를 조회하기 전에 프로토콜 버전을 담은 초기화 요청, 서버 기능 응답, 초기화 완료 알림으로 구성된 표준 MCP 절차를 수행하고 나서 도구 목록과 도구 호출 요청을 보낸다. 또한 매 사용자 메시지마다 도구 목록을 다시 받아 각 스키마를 에이전트 도구로 감싸므로 서버에 추가된 도구는 에이전트 코드를 바꾸지 않아도 다음 요청부터 나타난다.

5. 동시 요청의 식별과 네이티브 메시징

에이전트가 보내는 각 JSON-RPC 요청에는 고유 식별자가 부여되며, 대기 중인 비동기 응답 객체는 세션 식별자와 JSON-RPC 식별자의 조합으로 등록된다. 웹소켓을 통해 응답이 돌아오면 같은 조합을 가진 객체를 찾아 완료시키기 때문에 여러 도구 호출이 동시에 진행되더라도 어떤 응답이 어떤 요청에 해당하는지 구분할 수 있다. 브라우저 확장 프로그램과 로컬 프로세스의 연결에는 별도 네트워크 권한이나 메시지마다 반복되는 사용자 승인을 요구하지 않는 네이티브 메시징을 사용하며, 크롬과 파이어폭스가 이 방식을 지원한다. 브라우저는 정해진 위치의 매니페스트에서 실행 파일 경로와 허용된 확장 프로그램 출처를 확인하고, 확장 프로그램의 연결 호출을 받으면 등록된 셸 스크립트를 통해 파이썬 환경과 브리지 프로세스를 시작한다. 이 로컬 프로세스는 네이티브 연결이 유지되는 동안 계속 실행되어 반복 요청을 처리한다.

6. 메시지 프레이밍과 브리지 내부 처리

네이티브 메시징의 각 메시지는 JSON을 UTF-8로 인코딩한 뒤 본문 길이를 나타내는 32비트 리틀엔디언 헤더를 앞에 붙이는 형식으로 전달된다. 로컬 호스트가 브라우저로 보낼 수 있는 단일 메시지의 최대 크기는 1메가바이트이고, 브라우저에서 호스트로 보내는 메시지의 최대 크기는 64메비바이트다. 브리지는 입력 경로에서 표준 입력의 4바이트 길이 헤더를 제거하고 JSON 본문과 봉투를 해석해 원시 JSON-RPC를 추출하며, 출력 경로에서는 MCP 응답을 다시 봉투에 넣고 길이 헤더를 붙인다. 내부적으로는 브라우저 메시지를 입력 큐에 넣는 주 루프와 MCP 서버의 응답을 출력 큐에서 읽어 브라우저로 보내는 배경 루프가 패스트MCP 프록시를 사이에 두고 동시에 실행된다. 이 분리는 느린 도구의 완료를 기다리는 동안에도 다음 요청을 받아들일 수 있게 하며, 브라우저의 요청 시점과 로컬 서버의 처리 속도를 서로 분리한다.

7. 로컬 MCP 서버의 지속 실행과 구성

MCP 서버는 브리지가 시작될 때 자식 프로세스로 한 번 실행되고 브리지 연결이 유지되는 동안 계속 살아 있으므로 요청마다 새 프로세스를 만드는 비용이 없다. 패스트MCP 프록시는 입력 큐에서 메시지를 꺼내 서버 프로세스의 표준 입력으로 전달하고, 서버의 표준 출력에서 받은 응답을 출력 큐에 넣는다. 실행할 서버는 mcp.json 파일에 명령과 인수로 정의되며, 예시의 엑셀 서버는 python3 명령으로 excel_server.py를 실행하도록 설정된다. 글은 새로운 MCP 서버를 추가하는 작업이 설정 한 줄 수준의 변경으로 가능하고, 메시지 전달에 필요한 세부 처리는 브리지가 담당한다고 설명한다. 따라서 로컬 도구 서버는 표준 MCP 인터페이스에 집중할 수 있고 브라우저 전용 메시지 형식이나 원격 웹소켓 연결을 직접 구현할 필요가 없다.

8. 준비 조건·비용·배포 절차

예시를 배포하려면 사용할 모델에 접근 가능한 계정, 관련 런타임·인프라 구성·역할 생성·저장소 권한, 자격 증명이 설정된 명령줄 도구와 대상 리전에 준비된 개발 키트 환경이 필요하다. 로컬 소프트웨어 조건은 파이썬 3.10 이상, 노드 20 이상, 매니페스트 버전 3의 사이드 패널을 지원하는 구글 크롬과 깃이며, 전용 명령줄 도구와 개발 키트도 전역 설치한다. 글이 제시한 예상 설정 시간은 배포, 확장 프로그램 설치, 브리지 등록을 포함해 약 15분이고, 클라우드 런타임은 호출 단위로 과금되어 유휴 비용이 없으며 모델 사용량에는 토큰 기준 요금이 적용되고 나머지 구성요소는 로컬에서 실행된다. 배포 절차는 표본 저장소 복제, 설정 스크립트 실행, 에이전트 생성과 소스 파일 복사, 런타임 배포, 출력된 런타임 식별자 확인, bridge_config.json에 해당 식별자 입력 순으로 제시된다. 다만 제공된 본문은 브리지 설정 예시 중간에서 끝나므로 그 이후의 확장 프로그램 설치와 실제 시험 절차는 이 원문 범위에서 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 핵심 문제는 MCP 자체의 도구 규격이 아니라 원격 클라이언트와 로컬 서버라는 배치 형태이며, 해결책도 JSON-RPC를 바꾸기보다 서로 다른 전송 구간을 이어 주는 중계 계층에 집중한다.
• 네이티브 메시징은 허용된 확장 프로그램만 로컬 프로세스를 시작하도록 제한하면서 장시간 연결을 제공하고, 웹소켓 서명에 쓰이는 자격 증명은 사용자 기기에 남겨 브라우저로 전달하지 않는다.
• 도구 목록의 반복 조회, 지속 실행되는 서버 프로세스, 큐 기반 양방향 루프, 요청별 비동기 응답 매칭을 결합함으로써 서버 도구 추가와 복수 도구 호출을 에이전트 코드의 고정된 도구 정의 없이 처리한다.

✅ 액션 아이템

• 클라우드 에이전트 런타임·브라우저 확장·로컬 MCP 브리지·로컬 MCP 서버 네 구성요소의 연결 경계를 정의한다.
• 중계 계층이 전송 구간 포장만 변환하고 JSON-RPC 본문은 유지하는지 웹소켓·네이티브 메시징·표준 입출력 경로로 점검한다.
• 세션 식별자와 JSON-RPC 요청 식별자로 동시 요청 응답을 구분하고, 메시지마다 도구 목록을 다시 조회하는 기준을 정한다.

❓ 열린 질문

• 짧은 유효기간의 서명된 연결 주소가 만료될 때 자동 재연결만으로 사용자 흐름을 끊지 않고 복구할 수 있는가?
• 브리지가 자식 프로세스로 유지하는 로컬 MCP 서버에서 복수 동시 호출의 응답 매칭 실패를 어떻게 판단할 것인가?
• 중앙 관리 에이전트와 로컬 파일 처리 분리를 유지하려면 계정 권한·확장 설치·브리지 등록·런타임 식별자 설정의 최소 범위는 무엇인가?