SpecBox: LLM 생성 스트림으로 MCP 샌드박스 콜드스타트를 예측해 없애는 방법

요약

MCP(Model Context Protocol)가 LLM 에이전트의 표준 도구 연결 프로토콜로 자리잡으면서, 에이전트 서버는 새로운 병목을 마주했다: 도구 샌드박스 콜드스타트. 모델이 use_tool 호출을 생성하는 순간, 격리된 샌드박스를 새로 기동해야 한다면 수백 밀리초의 지연이 매 도구 호출마다 누적된다.

SpecBox(arXiv:2607.23933, Beihang University·University of Leeds·University of Sydney)는 이 문제를 서빙 시스템 관점에서 처음으로 다룬 논문이다. 핵심 통찰은 명확하다: LLM이 use_tool 구조를 완전히 생성하기 전에, 모델이 어떤 도구를 부르려는지 이미 스트리밍 출력에서 읽힌다.

SpecBox는 세 기법을 이 아이디어 위에 쌓는다.

1. 의도 인식 사전 기동(Intent-Aware Prewarming): 모델의 스트리밍 토큰 출력을 실시간 분석해, 완전한 use_tool 호출이 생성되기 전에 필요한 샌드박스 기동을 시작한다. 샌드박스 시작 비용이 추론 시간과 겹쳐진다.
2. 확률적 샌드박스 프리패칭(Stochastic Prefetching): 과거 에이전트 실행 트레이스에서 도구 의존성 그래프를 구성해, 현재 도구 이후 어떤 도구가 올지 미리 워밍한다.
3. 시맨틱 결과 캐싱 + 제로카피 전송: 도구 결과를 정확 일치가 아닌 의미 유사도로 캐싱하고, 공유 메모리로 네트워크 직렬화 없이 전달한다.

평가 결과: MCPBench의 200개 멀티턴 에이전트 궤적, 32개 MCP 호환 도구 서버 환경에서 P99 종단간 지연 최대 2.9배 단축, 피크 메모리 45.9% 감소.

• arXiv:2607.23933 · 2026년 7월 27일 공개
• 구현: AgentScope 통합 프로토타입

문제: MCP 샌드박스의 워밍 딜레마

왜 격리된 샌드박스가 필요한가

MCP는 LLM이 파일 시스템 접근, 코드 실행, 외부 API 호출 등 도구를 안전하게 사용하도록 하는 프로토콜이다. 프로덕션 환경에서 이 도구들은 일반적으로 독립된 프로세스나 컨테이너에서 실행된다. 이유는 두 가지다.

• 보안 격리: 잘못 작성된 도구 코드가 에이전트 서빙 프로세스를 오염시키지 않도록
• 테넌트 격리: 멀티테넌트 서버에서 하나의 사용자 요청이 다른 사용자의 자원에 접근하지 못하도록

두 가지 나쁜 선택지

샌드박스를 항상 켜두기(warm-standby) 와 요청마다 새로 기동(on-demand) 사이에는 모두 문제가 있다.

32개 도구, 100명의 동시 사용자를 가정하면 warm-standby는 최대 3,200개의 샌드박스를 유지해야 한다. On-demand로 가면 각 도구 호출이 300~500 ms의 콜드스타트를 감수한다. 멀티턴 에이전트가 평균 8번 도구를 호출한다면, 이것만으로 2~4초가 낭비된다.

SpecBox는 이 딜레마를 세 번째 선택지로 회피한다: 추론이 진행되는 동안 샌드박스를 미리 기동하되, 필요할 때만.

아키텍처: 세 가지 핵심 기법

기법 1: 의도 인식 사전 기동

어떻게 도구 호출 전에 도구를 예측하는가

LLM이 텍스트를 생성할 때, 도구를 명시적으로 호출하기 수십 토큰 앞에서 이미 의도를 드러낸다.

[생성 중인 토큰 스트림]

"먼저 해당 파일의 내용을 확인해야 합니다."
                    ↑ 여기서 "read_file" 의도 감지

"... `read_file(path='/data/config.json')` 를..."
                    ↑ 완전한 use_tool 호출 (여기서 기존 방식은 샌드박스 시작)

SpecBox의 의도 분석기는 두 단계로 동작한다.

1. 키워드 매칭: "확인", "열어", "실행", "검색" 등 도구 사용을 예고하는 키워드 세트와 패턴을 미리 정의한다. 빠르고 낮은 비용으로 후보 도구를 좁힌다.

1. 시맨틱 임베딩: 키워드 히트가 있을 때 현재까지 생성된 컨텍스트를 임베딩하고, 각 도구 설명(도구의 사용 시나리오를 미리 임베딩한 것)과 유사도를 비교한다. 임계값을 넘으면 해당 도구의 샌드박스 기동 명령을 즉시 보낸다.

핵심은 완전한 use_tool JSON 구조가 생성될 때까지 기다리지 않는다는 점이다. 샌드박스 기동 시간(수백 ms)이 모델이 완전한 도구 호출을 마저 생성하는 시간(수십 ms~수백 ms)과 겹쳐진다.

오예측 처리

분석기가 잘못된 도구를 예측하면 불필요한 샌드박스가 기동된다. SpecBox는 이를 두 가지로 관리한다.

• 예측 정확도 임계값: 유사도 점수가 충분히 높을 때만 사전 기동. 낮은 확신의 예측은 무시한다.
• 유휴 샌드박스 회수: 일정 시간 내에 사용되지 않은 사전 기동 샌드박스는 즉시 종료해 메모리를 회수한다.

기법 2: 확률적 샌드박스 프리패칭

도구 의존성 그래프

에이전트는 도구를 무작위 순서로 쓰지 않는다. 웹 검색 후 파일 읽기, 코드 실행 후 결과 저장처럼 반복되는 패턴이 있다. SpecBox는 과거 에이전트 실행 트레이스를 분석해 이 패턴을 확률 그래프로 만든다.

search_web ──0.73──→ read_file ──0.85──→ code_exec ──0.61──→ write_file
      └──0.31──→ api_call ──0.55──→ code_exec

현재 도구 A가 실행 중이면, A에서 나가는 확률적 엣지를 기준으로 다음에 쓰일 가능성이 높은 도구 B, C를 미리 기동한다. 임계 확률 θ(논문에서 0.5 기본값) 이상인 후속 도구만 프리패칭 대상으로 삼아 메모리 낭비를 막는다.

도구 의존성 그래프 갱신

그래프는 정적이지 않다. 새로운 에이전트 세션이 끝날 때마다 관찰된 도구 시퀀스로 엣지 확률이 베이지안 방식으로 업데이트된다. 새로운 워크플로우 패턴이 추가될수록 예측 정확도가 높아진다.

기법 3: 시맨틱 결과 캐싱 + 제로카피 전송

왜 정확 일치 캐시는 충분하지 않은가

"2026년 한국 GDP는?" 과 "2026년 한국의 국내총생산은 얼마인가?" 는 다른 문자열이지만 사실상 같은 도구 호출이다. 정확 일치 캐시는 이 두 요청 중 두 번째를 캐시 미스로 처리해 불필요한 외부 API 호출을 낸다.

SpecBox의 시맨틱 캐시는 도구 입력을 임베딩 벡터로 변환하고, 코사인 유사도를 기준으로 기존 캐시 항목과 비교한다. 유사도가 충분히 높으면(기본 임계값 0.95) 이전 결과를 반환한다.

제로카피 전송

샌드박스에서 생성된 도구 결과를 에이전트 서버로 전달할 때, 일반적인 방법은 TCP 소켓을 통한 직렬화/역직렬화다. 이미지, PDF, 바이너리 데이터처럼 대형 결과가 있을 때 이 오버헤드는 무시할 수 없다.

SpecBox는 같은 호스트에서 실행되는 샌드박스와 서버 사이에 공유 메모리(POSIX shared memory 또는 mmap)를 사용한다. 샌드박스는 결과를 공유 메모리에 쓰고, 에이전트 서버는 포인터만 받아 직접 읽는다. 직렬화와 네트워크 레이어를 건너뛴다.

평가 결과

실험 설정

• 벤치마크: MCPBench (200개 멀티턴 에이전트 궤적)
• 도구 서버: 32개 오픈소스 MCP 호환 도구 서버
• 비교 기준: 온디맨드 기동(기존 방식)
• 배포 환경: 고동시 멀티테넌트 설정

지연 개선

P99가 P50보다 개선율이 높은 이유는 고부하 상황에서 샌드박스 경합이 심할수록 콜드스타트 비용이 증폭되기 때문이다. SpecBox는 경합이 높을수록 더 효과적이다.

메모리 효율

SpecBox는 On-demand보다 메모리를 더 쓰지만(예측해서 미리 기동하니까), Warm-standby 대비 45.9% 절약한다. 지연과 메모리 모두에서 중간 지점을 찾은 셈이다.

운영자 관점: MCP 에이전트 서버 설계에 주는 시사점

현재 MCP 서빙의 일반적인 구조

대부분의 MCP 서버 구현은 두 패턴 중 하나다.

패턴 A — 프로세스 당 하나의 도구 풀(Warm-standby): 서버 시작 시 모든 도구 서버를 미리 기동. 요청이 없어도 프로세스가 떠 있다. 간단하지만 도구가 많아질수록 메모리 선형 증가.

패턴 B — 요청 당 도구 기동(On-demand): 필요한 순간에만 기동. 메모리 효율적이지만 첫 호출에 항상 콜드스타트가 붙는다.

SpecBox가 주는 교훈은 세 번째 패턴이 실용적임을 보여준다: 추론 진행 중에 미리 기동하고, 쓰인 후엔 즉시 회수.

지금 당장 적용 가능한 아이디어

논문의 전체 구현 없이도 아이디어를 부분 적용할 수 있다.

1. 도구 시퀀스 로깅: 운영 중인 에이전트에서 어떤 도구가 어떤 순서로 호출되는지 먼저 측정한다. 80%의 케이스에서 반복되는 패턴이 있다면 프리패칭이 효과적이다.

1. 캐시 히트율 측정: 동일 파라미터의 도구 호출 반복 비율을 측정한다. 10%만 되어도 캐싱 도입이 의미 있다.

1. 시맨틱 캐시 임계값 보수적으로 설정: 시맨틱 캐시는 잘못 설정하면 다른 결과가 나와야 할 요청을 캐시로 처리하는 문제가 생긴다. 처음에는 임계값을 높게(0.98+) 설정해 정밀도를 희생하지 않도록 한다.

한계와 Open question

• 의도 분석기 품질: 키워드 매칭과 임베딩 품질에 따라 예측 정확도가 달라진다. 특수 도메인 언어(전문 의학/법률 용어 등)에서는 사전 훈련된 범용 임베딩의 성능이 낮을 수 있다.
• 분산 환경: 논문의 평가는 단일 서버 가정이다. 여러 워커에 걸친 샌드박스 라이프사이클 조율은 논문의 범위 밖이다 — Open question.
• 도구 시퀀스 분포 변화: 에이전트 워크플로우가 업데이트되면 의존성 그래프가 오래된 패턴을 반영할 수 있다. 그래프 갱신 주기가 얼마가 적절한지는 명시되지 않았다 — Open question.

요점 정리

SpecBox가 다루는 문제는 MCP 채택이 늘수록 더 중요해진다. 에이전트가 도구를 더 자주, 더 다양하게 쓸수록 샌드박스 콜드스타트는 사용자 경험을 악화시키는 대표적 병목이 된다.

세 기법의 핵심 통찰은 하나로 수렴한다: 결정을 가장 정보가 많을 때 내리되, 실행은 가장 이른 시점에 시작하라. 의도 인식 사전 기동은 모델의 생성 스트림에서 미래를 읽고, 그 정보를 시스템 자원 할당에 즉시 반영한다.

P99 지연 2.9배 단축은 논문 조건에서의 수치지만, 멀티턴 에이전트 궤적에서 도구를 평균 8회 이상 호출한다면 종단간 경험 개선은 누적적으로 크다.

References

• arXiv:2607.23933 — "SpecBox: Speculative Sandbox Scheduling for Efficient LLM Agent Serving" (Yihui Zhang et al., Beihang University / University of Leeds / University of Sydney, 2026.07)
• MCPBench: https://github.com/ise-uiuc/mcpbench (MCP 에이전트 평가 벤치마크)
• AgentScope: https://github.com/modelscope/agentscope (SpecBox 프로토타입 통합 환경)
• MCP 스펙 공식 문서: https://modelcontextprotocol.io/specification
• vLLM disaggregated prefill/decode (관련 배경): https://docs.vllm.ai/en/latest/serving/disagg_prefill.html