에이전트 컨텍스트를 파일로 마운트한 이유

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Production agent의 컨텍스트 검색은 모델 선택만의 문제가 아니라 데이터를 실행 환경에 전달하는 data-plane architecture 결정으로 볼 수 있습니다. 글에서는 Slack, Notion, Linear 데이터를 매번 MCP로 조회하는 방식과 허용 데이터를 미리 동기화해 sandbox 파일로 마운트하는 방식을 20개 cross-application scenario와 180회 blind comparison으로 비교했습니다. 파일 마운트 방식은 선호 답변 70%, LLM cost 27% 감소, end-to-end latency 32% 감소, tool call 61% 감소, token 약 40% 감소를 기록했으며, 이는 reasoning 가속보다 애플리케이션 데이터 탐색 감소에서 비롯됐습니다. 다만 freshness, permissions, state 분리, write review, journaling과 conflict recovery가 필요하므로 파일과 MCP 중 하나를 고르기보다 read-heavy discovery용 context plane과 transactional action용 live action plane을 분리하는 구성이 핵심입니다.

실용적 조언

Broad한 자료 탐색과 종합을 수행하는 production agent에는 실행 전에 허용된 데이터를 파일로 materialize하는 context plane을 두는 방식을 검토할 수 있습니다. 동기화 경계는 webhook, polling 또는 pre-run synchronization으로 명확히 정하고, staleness를 별도 상태로 관측해야 합니다. 반대로 외부 시스템의 변경을 수반하는 transactional action과 동기화 지연을 허용할 수 없는 작업은 live API나 MCP 경로에 남겨야 합니다.
파일 기반 동기화 계층에서는 sandbox마다 필요한 source와 subtree만 전달해 broad application credential을 피해야 합니다. Remote state, mounted state, last synchronized state를 서로 분리해 기록하고, agent edit는 source에 반영하기 전에 inspectable operation plan으로 검토해야 합니다. 중단된 write를 안전하게 복구하려면 journaling, idempotency, explicit conflict handling을 마련하고 silent retry에 의존하지 않아야 합니다.

섹션별 상세

작성자는 에이전트의 컨텍스트 검색을 단순한 모델 행동이 아니라 production data-plane architecture 결정으로 봅니다. Slack, Notion, Linear 데이터를 매 실행마다 official MCP integration으로 조회하는 방식과, 허용된 데이터를 미리 동기화해 sandbox 안에 파일로 마운트하는 방식을 비교했습니다. 20개 cross-application scenario에 paired trial을 세 번씩 적용하고, 동일한 agent harness·model·prompt·machine 조건에서 180회 blind comparison을 수행했다는 점이 비교의 기반입니다.

파일로 마운트한 방식은 runtime MCP retrieval보다 70%의 시나리오에서 선호 답변을 만들었고, LLM cost를 27%, end-to-end latency를 32% 줄였습니다. Tool call은 61%, token 사용량은 약 40% 감소했습니다. 작성자는 에이전트의 reasoning 자체가 크게 빨라진 것이 아니라 애플리케이션 데이터를 탐색하는 시간이 줄어든 결과로 해석하며, 한 launch-risk 조정 시나리오에서는 병렬 filesystem operation이 약 0.3초에 한 evidence-gathering stage를 처리한 반면 MCP 방식은 21회 호출과 약 30초의 tool-call time을 포함해 같은 단계에 약 1분이 걸렸다고 밝혔습니다.

파일 기반 컨텍스트는 단순한 cache가 아니라 freshness, permissions, state, write review, recovery를 갖춘 production data plane으로 운영해야 합니다. 변경 사항은 webhook·polling·pre-run synchronization boundary를 통해 도착해야 하며 staleness를 관측할 수 있어야 하고, 각 sandbox에는 해당 실행에 필요한 source와 subtree만 제공해야 합니다. Remote state·mounted state·last synchronized state를 분리해 추적하고, agent edit에는 inspectable operation plan과 journaling·idempotency·explicit conflict handling을 적용해야 하므로 connector maintenance, storage, synchronization lag, conflict resolution, recovery testing이라는 추가 비용도 발생합니다.

작성자는 파일과 MCP 중 하나를 전면적으로 선택하기보다 두 개의 plane을 분리하는 방식을 제시합니다. Broad하고 read-heavy한 discovery와 synthesis에는 mounted context plane을 사용하고, transactional operation·narrow lookup·동기화 지연을 허용할 수 없는 데이터에는 live action plane을 사용합니다. Locality Cloud는 이 mounted context plane의 managed implementation이며, 동기화 계층을 조직 내부에 둘 필요가 있는 경우를 위해 on-premises option도 제공한다고 밝혔습니다.

이미지 분석

Diagram
이미지는 Locality를 중앙 workspace로 두고 Notion과 Local files에서 데이터를 받아 에이전트가 사용할 수 있는 형태로 구성하는 흐름을 나타냅니다. 중앙 영역에는 freshness와 위험 변경을 확인하는 review gate, 양방향 sync, conflict resolution이 표시되어 있어, 본문의 mounted context plane이 단순 파일 저장소가 아니라 동기화와 변경 검토를 포함한 운영 계층이라는 설명과 연결됩니다.
Locality가 Notion과 로컬 파일을 에이전트 workspace에 연결하고 검토·양방향 동기화·충돌 해결을 제공하는 구조도입니다.

용어 해설

MCP: — MCP는 에이전트가 실행 중에 Slack, Notion 같은 외부 애플리케이션의 데이터와 기능을 호출하도록 연결하는 프로토콜이다. 매번 원격 조회를 수행하므로 최신 데이터 접근에는 유리하지만 호출 횟수와 지연 시간이 늘어날 수 있다.
데이터 플레인(Data Plane): — 데이터 플레인은 에이전트가 실제 업무 데이터를 읽고 처리하는 실행 경로다. 이 글에서는 애플리케이션 데이터를 미리 동기화해 파일로 마운트하는 영역을 가리키며, 조회 성능과 권한·최신성 관리가 핵심 운영 과제가 된다.
컨텍스트 플레인(Context Plane): — 컨텍스트 플레인은 에이전트가 답변이나 판단을 만들기 전에 폭넓은 자료를 읽고 종합하는 경로다. 파일 시스템에 동기화된 데이터를 제공하면 읽기 중심의 탐색과 합성을 빠르게 처리할 수 있지만, 동기화 지연과 권한 범위를 함께 관리해야 한다.
액션 플레인(Action Plane): — 액션 플레인은 에이전트가 외부 시스템에 변경을 기록하거나 트랜잭션을 실행하는 경로다. 동기화 지연을 허용하기 어려운 작업과 좁은 범위의 조회에는 live API나 MCP를 사용하고, 파일 기반 컨텍스트 경로와 분리하는 구조가 적합하다는 관점이다.
멱등성(Idempotency): — 멱등성은 동일한 쓰기 요청이 여러 번 처리돼도 최종 상태가 한 번 처리한 결과와 같도록 만드는 성질이다. 동기화가 중단된 뒤 재시도할 때 중복 변경이나 상태 왜곡을 막기 위해 작업 기록과 함께 요구된다.

언급된 도구

Slack중립

에이전트가 검색하거나 사전 동기화하는 업무 데이터의 원천

Notion중립

에이전트 컨텍스트로 제공되는 문서 데이터의 원천

Linear중립

제품 계획과 작업 데이터를 제공하는 원천 애플리케이션

MCP중립

에이전트 실행 중 외부 애플리케이션 데이터를 조회하거나 작업을 호출하는 연결 방식

언급된 리소스

문서Locality: Why Filesystems Perform Better Than MCPs for Production Agents