7월 7일, Box는 자사의 MCP Server가 Slack 및 Agentforce와 연동되어 작동하는 방식에 대한 분석 내용을 발표했습니다. 이번 사건의 핵심은 간단합니다. 파일 저장소가 단순히 문서를 보관하고 다운로드하는 장소에서 벗어난다는 것입니다. 저장소는 에이전트가 직접 접근하는 '실행 계층 (Layer of Actions)'이 됩니다. 에이전트는 자신의 시스템으로 복사본을 가져오지 않고도 필요한 파일을 찾고, 읽고, 그 내용에 따라 답변하며 다음 단계를 실행할 수 있습니다.

이는 새로운 챗봇이나 또 다른 LLM (Large Language Model) 래퍼(wrapper)에 관한 이야기가 아닙니다. 이것은 프로토콜에 관한 것입니다. Model Context Protocol (MCP)은 서버를 통해 모델에 외부 도구에 대한 접근 권한을 부여하는 표준화된 방식이며, 이 서버는 자신의 기능을 설명합니다. Box는 자사의 저장소 위에 이러한 서버를 구축했으며, Slack 및 Salesforce의 Agentforce를 통한 두 가지 구체적인 연결 시나리오를 선보였습니다. Box의 데이터에 따르면, 두 시나리오 모두 7월 7일 제품 로드맵에 포함되었습니다.

이제 무엇이 구체적으로 변했는지, 어디에 엔지니어링적 가치가 있는지, 그리고 직접 검증해 볼 만한 벤더의 약속은 무엇인지 분석해 보겠습니다. 만약 당신이 문서 작업을 위한 에이전트를 구축하고 있다면, 이 아키텍처를 이해하는 것은 콘텐츠를 어디에 저장하고 어떻게 접근 권한을 부여할지 선택하는 데 드는 수 주간의 시간을 절약해 줍니다.

Box가 7월 7일에 구체적으로 발표한 내용은 무엇인가?

Box는 MCP Server를 기업용 콘텐츠와 에이전트 사이의 가교(bridge)로 설명했습니다. 이전에는 에이전트가 내부 문서에 기반하여 답변할 수 있도록 하기 위해 파일을 추출하고, 파싱(parsing)하고, 벡터 데이터베이스(vector database)에 저장하며, 변경 사항이 있을 때 동기화하는 파이프라인(pipeline)을 구축해야 했습니다. 각 복사본은 접근 권한이 원본과 달라질 수 있는 별개의 지점이 됩니다.

MCP는 이 모델을 바꿉니다. 에이전트는 문서를 자신에게 가져오지 않습니다. 대신 Box 서버에 "이 거래처와의 계약서를 찾아줘", "최신 버전의 정책을 보여줘", "이 청구서에서 금액을 추출해줘"라고 요청합니다. 서버는 Box의 경계(perimeter) 내부에서 요청을 수행하고 결과를 반환합니다. 문서는 물리적으로 제자리에 남아 있습니다.

Box의 표현에 따르면, 여기서의 핵심 가치는 시스템 간에 콘텐츠를 복사하지 않고도 콘텐츠를 다루는 것입니다. 이는 벤더(vendor)의 주장이며, 프로토콜의 아키텍처(architecture)로부터 논리적으로 도출됩니다. 하지만 7월 7일 기준으로 독립적인 도입 지표는 없으므로, 실제 사용 규모를 평가하기에는 아직 이릅니다.

두 가지 발표된 시나리오:

• Slack. 사용자가 업무용 채팅에서 문서에 관한 질문을 하면, 에이전트(agent)가 필요한 파일을 찾기 위해 Box MCP Server에 요청하여 답변합니다.
• Agentforce. Salesforce의 에이전트 플랫폼(agent platform)이 동일한 콘텐츠 계층(content layer)에 접근하여 Box 문서를 CRM 비즈니스 프로세스에 통합합니다.

두 시나리오 모두 동일한 서버에 의존합니다. 연결되는 클라이언트(client)만 달라질 뿐입니다.

첫 번째 실질적인 결론: 콘텐츠가 이미 Box에 있다면, 데이터 추출 및 동기화(synchronization)라는 인프라 계층 전체를 잠재적으로 제거할 수 있습니다. 이것이 벡터 검색(vector search)이 전혀 필요 없다는 뜻은 아니지만, 에이전트의 진입점(entry point)이 소스(source) 쪽으로 이동함을 의미합니다.

MCP는 어떻게 구성되며, 왜 제품이 아닌 프로토콜인가?

MCP는 클라이언트(모델 또는 에이전트)와 서버(도구 또는 데이터 소스)가 무엇을 할 수 있는지에 대해 어떻게 협의하는지를 기술합니다. 서버는 기능(functions), 리소스(resources), 요청 템플릿(request templates)과 같은 일련의 역량을 선언합니다. 클라이언트는 표준 계약(standard contract)에 따라 이를 호출합니다. 핵심은 동일한 서버가 각 클라이언트에 맞춰 통합(integration) 코드를 다시 작성할 필요 없이 다양한 클라이언트와 작동한다는 점에 있습니다.

바로 이 점 때문에 Box는 Slack과 Agentforce를 하나의 서버에서 보여줄 수 있었습니다. Box 서버 입장에서는 접속한 대상이 메신저인지 CRM 에이전트인지 중요하지 않습니다. 서버는 검색, 메타데이터 읽기, 콘텐츠 추출, 파일 작업 등의 역량을 제공할 뿐입니다. 클라이언트는 이를 자신의 인터페이스에서 어떻게 사용할지를 결정합니다.

MCP 클라이언트의 설정은 일반적으로 어떤 서버에 연결할지, 그리고 어떤 권한을 가질지를 지정하는 작은 JSON 형태입니다. 클라이언트가 콘텐츠 서버를 등록하는 가상의 예시는 다음과 같습니다:

{
  "mcpServers": {
    "box-content": {
...

scope에 주목하십시오. 여기서 권한은 추상적인 개념이 아니라, 에이전트가 실제로 수행할 수 있는 동작을 정의하는 것입니다. Box는 자체 권한 모델 위에 액세스를 구축하며, 이는 위험(Risks) 섹션에서 다시 다룰 중요한 지점입니다.

두 번째 중요한 점은 프로토콜이 특정 모델에 종속되지 않는다는 것입니다. MCP 서버는 Claude, GPT, Gemini 또는 해당 프로토콜을 사용할 수 있는 다른 어떤 모델의 에이전트에서도 호출할 수 있습니다. 이때 모델 자체는 교체 가능한 부품으로 남습니다. 즉, 서버는 데이터를 제공하고, 그 데이터를 바탕으로 추론하는 것은 사용자가 연결한 LLM (Large Language Model)입니다.

여기서 자주 혼동되는 두 가지 개념을 구분하는 것이 유용합니다. Box MCP Server는 콘텐츠에 대한 액세스 문제를 해결합니다. 이는 어떤 모델로 사고할지의 문제를 해결하는 것이 아닙니다. 러시아 팀에게 이러한 분리는 실용적입니다. 기업 파일에 대한 액세스는 내부 인프라를 통해 차단하고, 모델 자체에 대한 액세스는 별도의 계층으로 관리할 수 있기 때문입니다. 예를 들어, provod.ai를 통해 OpenAI 및 Anthropic SDK와 호환되는 단일 API로 Claude, GPT, Gemini, DeepSeek 및 Qwen을 호출할 수 있으며, 키와 base_url만 변경하면 됩니다. 이것은 Box MCP 서버를 대체하거나 문서 자체에 대한 액세스를 제공하는 것이 아니라, MCP 아키텍처에서 교체 가능한 부분인 모델 계층(Model Layer)에 관한 것입니다.

실제로 이 계층을 교체하는 것은 모델 클라이언트에서 단 두 줄의 코드만으로 이루어집니다:

from openai import OpenAI

client = OpenAI(
...

그 후 이 클라이언트를 사용하는 에이전트는 평소와 같이 콘텐츠를 가져오기 위해 MCP 서버에 요청합니다. 콘텐츠는 별도로, 모델은 별도로 분리하는 이러한 계층화(Layering)가 바로 MCP 접근 방식을 유연하게 만드는 핵심입니다.

Slack과의 연동은 무엇을 제공하는가?

Slack 시나리오는 가장 직관적입니다. 직원이 채널이나 스레드에 질문을 작성하면, 에이전트가 Box의 실제 문서를 바탕으로 답변합니다. 모델의 기억이나 오래된 데이터 내보내기(Export)가 아니라, 저장소에 있는 파일의 현재 버전을 기반으로 합니다.

실질적인 가치는 컨텍스트(Context)를 전환할 필요가 없다는 점에 있습니다. 사람은 이미 Slack에 있고, 논의도 그곳에서 진행 중입니다. 이전에는 계약서의 특정 조항을 찾기 위해 저장소로 이동하여 검색하고, 열고, 복사해야 했습니다. 이제 요청은 대화 내에 머물러 있으며, 에이전트가 백그라운드에서 검색 및 추출을 수행합니다.

Box의 설명에 따르면, 에이전트는 MCP Server를 통해 콘텐츠에 접근합니다. 즉, 복사본이 아닌 소스(Source)에서 직접 답변합니다. 이는 고전적인 동기화 문제(Desynchronization)를 해결합니다. 만약 문서가 5분 전에 업데이트되었다면, 에이전트는 원본을 읽기 때문에 새로운 버전을 즉시 확인할 수 있습니다.

중요한 점은 이것이 측정된 사례가 아닌 벤더(Vendor) 측의 시나리오라는 것입니다. Box는 설계 의도대로 어떻게 작동하는지를 보여줍니다. 대규모 볼륨에서 검색이 얼마나 정확하게 작동하는지, 그리고 모호한 요청에 대해 에이전트가 어떻게 행동하는지는 여러분의 데이터를 통해 직접 확인해야 합니다. 그 어떤 프레젠테이션도 실제 문서군(Corpus)을 대상으로 한 테스트를 대신할 수는 없습니다.

Agentforce와의 연동은 무엇을 제공하는가?

Agentforce는 Salesforce의 에이전트 플랫폼입니다. 여기서는 논리가 다릅니다. 채팅 중인 사람이 아니라, 비즈니스 프로세스 내부의 에이전트가 주체입니다. 예를 들어, 거래(Deal)를 처리할 때 에이전트에게는 계약서, 제안서 또는 사양서가 필요합니다. 이전에는 이러한 문서들이 CRM과 분리되어 Box에 별도로 존재했으므로, 이를 연결하려면 데이터 추출을 포함한 통합(Integration) 구축이 필요했습니다.

MCP Server를 통해 Box의 콘텐츠는 Agentforce 에이전트가 직접 사용할 수 있게 됩니다. CRM에서 거래를 진행하는 에이전트는 자신의 작업 단계의 일부로 저장소에서 최신 문서를 가져올 수 있습니다. 콘텐츠와 프로세스가 중간 복사본 없이 하나의 지점에서 결합됩니다.

엔터프라이즈 콘텐츠의 경우, 이는 근본적인 변화입니다. 일반적으로 문서는 콘텐츠 관리 시스템 (CMS)에 존재하고, 작업은 프로세스 시스템에 존재합니다. MCP는 수동으로 유지 관리해야 하는 또 다른 커넥터 수준이 아니라, 프로토콜 수준에서 이들 사이의 경계를 제거합니다.

그리고 권한 상속에 대해 다시 한번 주의를 당부합니다. Agentforce 에이전트가 Box의 파일에 접근할 때, 접근 권한이 CRM 측에서 새로 설정되는 것이 아니라 Box로부터 읽혀지는 것이 매우 중요합니다. Box는 자체 권한 모델을 기반으로 액세스를 구축하지만, 특정 결합 환경에서 실제 ACL (Access Control List) 상속이 제대로 이루어지는지 확인하는 것은 구현 시 여러분의 과제입니다. 이는 프로덕션(Production) 환경에 적용하기 전 가장 먼저 테스트해야 할 사항입니다.

어디에서 문제가 발생하며, 무엇이 여러분의 몫으로 남는가?

아키텍처는 아름답지만, 정직한 한계점들이 존재합니다. 소스에 명시되지 않은 수치를 추측하지 않고, 설명과 일반적인 엔지니어링 논리에서 드러나는 부분들을 분석해 보겠습니다.

접근 권한 - 주요 리스크. 이 모델의 모든 가치는 에이전트가 사용자가 보는 것과 정확히 동일한 것만을 본다는 점에 달려 있습니다. 만약 ACL 상속이 어딘가에서 깨진다면, 에이전트는 직원이 봐서는 안 될 문서를 채팅창에 제공할 수 있습니다. Box는 자체 권한 모델 위에서 액세스를 보장한다고 주장하지만, 7월 7일 기준으로 통합 환경에서 이 메커니즘을 독립적으로 검증할 수 있는 방법은 없습니다. 다양한 접근 권한 수준을 가진 계정들로 테스트하십시오.

작업 감사 (Audit). 에이전트가 파일을 읽기만 하는 것이 아니라 파일에 대해 작업을 수행할 때는 로그가 필요합니다: 누가, 무엇을, 언제, 누구의 이름으로 수행했는지에 대한 기록입니다. 투명한 감사 기능이 없다면, 에이전트가 저장소에서 수행하는 작업에 대한 통제력을 잃게 됩니다. 이는 두 가지 통합 사례 각각에 대해 별도로 확인해야 할 사항입니다.

검색 품질. MCP는 접근 권한을 제공하지만, 에이전트가 올바른 문서를 찾을 것이라고 보장하지는 않습니다. 방대하고 노이즈가 많은 데이터셋에서는 검색이 빗나갈 수 있습니다. 이는 프로토콜의 문제는 아니지만 사라지는 문제도 아니며, 쿼리(Query) 및 메타데이터 (Metadata) 설정을 통해 해결해야 합니다.

생태계 의존성. 시나리오는 Box, Slack 및 Agentforce에 묶여 있습니다. 만약 당신의 콘텐츠가 Box에 있지 않다면, 이 특정 조합은 당신에게 직접적으로 맞지 않습니다. 당신의 저장소(Storage) 위에 자신만의 MCP 서버를 구축해야 합니다.

이 접근 방식이 해결하지 못하는 점도 별도로 언급하겠습니다. 이 방식은 저장소를 비즈니스 프로세스 자동화 플랫폼으로 만들어주지는 않습니다. 오케스트레이션 (Orchestration)은 여전히 클라이언트가 구축합니다. 또한, 이는 구현을 대체하지 않습니다. 권한 설정, 메타데이터 (Metadata) 및 에이전트 시나리오 설정은 팀의 몫입니다. 그리고 모델 계층 (Model Layer)을 없애지도 않습니다. 문서에 대해 사고하는 것은 여전히 당신이 별도로 연결할 LLM (Large Language Model)의 역할입니다.

비교: 복제 vs MCP를 통한 액세스

해결책을 구체화하기 위해 두 가지 접근 방식을 표로 정리하겠습니다. 이는 제품 순위가 아닌 아키텍처 (Architecture)에 대한 엔지니어링 비교입니다.

표의 주요 결론: MCP는 복제 계층을 제거하고 소스에 대한 액세스 지점을 이동시키지만, 권한 상속의 정확성에 대한 책임은 당신에게 넘깁니다. 이는 공짜 점심이 아니라 일종의 트레이드오프 (Trade-off)입니다.

표를 통해 알 수 있듯이, 두 접근 방식 모두에서 모델 계층은 별개입니다. 에이전트에 어떤 LLM을 연결할지는 콘텐츠 액세스 방식이 어떻게 구성되어 있는지와는 독립적인 문제입니다.

실무에서 어떻게 접근해야 할까?

모델을 직접 다뤄보고 싶다면, 다음과 같은 간결한 실행 순서가 있습니다. 반드시 Box일 필요는 없으며, 저장소 위의 모든 MCP 서버에 동일한 원칙이 적용됩니다.