커스텀 래퍼 없이 툴을 연결하는 MCP와 Qwen3.6

로컬 AI 모델을 활용해 업무 자동화를 구축하다 보면 모델의 추론 능력은 뛰어나지만 정작 내부 DB나 API를 직접 제어하지 못해 매번 파이썬 래퍼 코드를 짜야 하는 불편함에 부딪힌다. 모델의 출력값과 실제 툴 실행 사이를 하드코딩으로 잇고, API 명세가 바뀔 때마다 연결 코드를 수정하는 작업은 소모적이다. 이러한 통합 비용 문제를 해결하는 것이 Anthropic이 제안한 MCP(Model Context Protocol) 표준과 이를 지원하는 Qwen3.6-35B-A3B 모델의 조합이다.

MCP는 AI 툴 연결을 위한 오픈 표준으로, 툴을 MCP 서버로 한 번만 정의하면 이를 지원하는 모든 클라이언트와 모델이 별도의 통합 코드 없이 해당 툴을 발견하고 호출할 수 있게 한다. Qwen3.6-35B-A3B는 이러한 MCP 기반 에이전트 작업에 특화되어 훈련된 로컬 모델이다. 클라우드 의존성 없이 로컬 하드웨어 환경에서 구동되므로 데이터 보안이 중요한 기업 환경에 적합하다.

실제 구현 사례로 GitHub 저장소의 오픈 이슈를 읽고, 관련 코드를 검색해 수정안을 작성한 뒤 풀 리퀘스트(PR)를 생성하는 개발 비서를 로컬에서 구축할 수 있다. 이 과정에서 모델은 MCP 서버가 제공하는 툴의 이름과 입력 스키마를 읽고 호출할 툴을 결정하며, 실제 실행은 클라이언트가 담당하고 그 결과값이 다시 모델에게 전달되어 다음 단계의 추론으로 이어진다.

35B의 지식을 3B의 비용으로 처리하는 MoE 구조

보통 30B가 넘는 대형 모델을 로컬 PC에서 구동하면 VRAM 부족으로 실행이 어렵거나 추론 속도가 느려진다. Qwen3.6-35B-A3B 모델은 전체 파라미터 35B 중 추론 시점에 3B만 활성화하는 MoE(Mixture of Experts) 구조를 채택했다. 모델 이름의 A3B는 이 활성 파라미터 수를 의미한다. 레이어당 256개의 전문가를 배치하고 토큰당 8개의 전문가와 1개의 공유 전문가에게만 연산을 배분하는 라우팅 방식을 사용하여, 35B 모델의 지식 용량은 유지하면서 계산 비용은 3B 모델 수준으로 낮췄다.

내부 레이어 구성은 효율성과 정확도를 위해 하이브리드 방식을 쓴다. 총 40개의 레이어 스택 내에서 Gated DeltaNet(선형 어텐션)과 Gated Attention(전체 어텐션)을 3:1 비율로 배치했다. Gated DeltaNet은 연산 복잡도를 낮춰 긴 문맥을 처리할 때 메모리와 계산 시간을 줄이며, Gated Attention 레이어는 토큰 간의 모든 관계를 계산해 복잡한 논리 구조와 깊은 관계 추론을 보완한다. 500개가 넘는 파일이 담긴 대규모 저장소를 분석하는 에이전트에게는 이 3:1 하이브리드 구조가 성능을 결정한다.

기본 문맥 창은 262,144 토큰이며 YaRN(Yet another RoPE extensioN) 스케일링을 적용하면 최대 1,010,000 토큰까지 확장 가능하다. 에이전트가 소스 파일을 읽고 툴 호출 이력을 유지하며 다단계 계획을 추적하는 과정에는 상당한 여유 공간이 필요하다. 문맥이 부족해 이전 기록을 잃어버리면 에이전트는 툴 실행 결과를 임의로 지어내는 환각 현상을 일으키며 작업에 실패하기 때문이다.

JSON-RPC 2.0 기반의 MCP 프로토콜 작동 방식

MCP는 툴 연결의 불편함을 해결하기 위해 stdio 또는 HTTP 전송 기반의 JSON-RPC 2.0 프로토콜을 채택했다. 클라이언트가 서버에 연결되는 시점에 `tools/list` 호출을 통해 서버가 노출하는 도구 목록을 탐색한다. 서버는 각 도구의 이름, 상세 설명, JSON Schema로 정의된 입력값 규격을 반환하며, 모델은 이 스키마를 어떤 도구를 어떤 인자로 호출해야 하는지 판단하는 계약서로 활용한다.

실제 작동 과정은 모델의 결정과 실행 주체를 엄격하게 분리한다. 모델이 특정 도구를 사용하기로 결정하고 구조화된 호출 객체를 생성하면, 실제 실행은 MCP 클라이언트가 담당한다. 클라이언트는 서버에 `tools/call` 요청을 보내고, 서버는 내부 로직을 통해 작업을 수행한 뒤 결과값을 반환한다. 이후 클라이언트는 이 결과물을 도구 역할 메시지로 변환하여 다시 대화 맥락에 주입하며, 모델은 이를 읽고 다음 추론을 이어가거나 최종 답변을 내놓는다.

과거의 로컬 AI 구현 방식은 모델의 출력 형식이 바뀌면 도구 실행부의 파이썬 코드를 일일이 수정해야 하는 강한 결합 구조였다. 반면 MCP는 모델과 툴 사이의 연결 고리를 표준화하여 결합도를 낮춘다. 개발자가 MCP 서버를 한 번만 정의해두면, 이를 지원하는 모든 호환 클라이언트와 모델에서 별도의 통합 코드 없이 즉시 기능을 사용할 수 있어 개발 공수를 줄인다.

현장에서 달라지는 비용과 판단

Qwen3.6 기반 에이전트를 구현하는 경로는 크게 두 가지로 나뉜다. Qwen-Agent는 전체 루프를 자동으로 처리해 구축 속도가 빠르다. 반면 Raw SDK 방식은 메시지 제어와 에러 처리, 툴별 재시도 로직, 감사 로그 기록까지 세밀하게 조정할 수 있다. 특히 Raw SDK에서는 `tool_to_session` 라우팅 딕셔너리를 통해 각 툴 이름을 해당 MCP 세션에 매핑하므로, 에이전트가 서버 위치를 몰라도 자유롭게 호출할 수 있다. 단순 프로토타입은 Qwen-Agent가 유리하지만, 툴 호출 결과에 대한 증적이 필요한 기업용 서비스라면 Raw SDK를 선택해야 한다.

추론 정확도를 높이기 위해 Qwen3.6는 `<thought>` 태그 내에 Chain-of-Thought 추론 과정을 생성하는 Thinking Mode를 지원한다. 이 모드를 활성화하면 작업 복잡도에 따라 턴당 1,000에서 5,000개의 토큰이 추가로 생성되어 응답 시간은 길어지지만, 모델이 툴 호출 전 스스로 논리적 오류를 검토하여 잘못된 인자값 전달로 인한 실행 실패 횟수를 줄인다.

실무에서는 작업 성격에 따라 모드를 다르게 설정해야 한다. 디렉토리 목록 확인, 파일 읽기/쓰기, 커밋으로 이어지는 기계적인 루프는 Non-thinking Mode가 속도 면에서 유리하다. 반면 여러 단계의 복잡한 논리적 추론이 필요한 작업은 Thinking Mode를 권장한다.

SGLang 기반 배포와 KV 캐시 최적화 실무

실무 도입 시에는 SGLang이나 vLLM 같은 추론 서버를 사용한다. 두 도구 모두 OpenAI 호환 API를 제공하므로 기존 API 호출 로직을 그대로 활용할 수 있다. 서버 구동 확인을 위해 다음 명령어를 입력한다.

bash

curl http://localhost:30000/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "qwen3.6", "messages": [{"role": "user", "content": "hi"}]}'

응답 JSON 데이터 내에 choices 배열이 정상적으로 출력된다면 서빙 레이어가 안정적으로 구축된 상태다. 이후 실제 에이전트 구동을 위한 라이브러리를 설치한다.

pip install qwen-agent

설치한 qwen-agent는 모델과 MCP 서버 사이의 통신 루프를 자동으로 처리하는 프레임워크다. 개발자가 모델 출력값을 파싱하고 도구를 실행해 다시 입력값으로 넣어주는 반복적인 래퍼 코드를 짤 필요 없이, 도구 정의와 비즈니스 로직에만 집중할 수 있게 한다.

실제 운영 환경의 추론 속도는 KV 캐시(이전 토큰들의 계산 값을 저장해 재사용하는 메모리 영역) 최적화 설정에 따라 달라진다. 특히 5턴 이상의 긴 대화가 이어지는 세션에서는 `preserve_thinking` 설정을 True로 지정해 모델이 생성한 사고 과정의 흔적을 다음 턴까지 유지해야 한다. SGLang의 `--enable-prefix-caching` 옵션과 이 설정을 조합하면 서버가 대화의 공통된 앞부분을 인식해 중복 계산을 방지하며, 이는 매 턴마다 전체 문맥을 다시 계산하는 낭비를 없애 토큰 생성 속도를 실질적으로 높인다.

로컬 AI 에이전트 구축의 핵심은 이제 개별 툴을 연결하기 위해 파이썬 래퍼 코드를 짜는 노동이 아니라, 표준 프로토콜 위에서 하드웨어 자원을 어떻게 배분하느냐의 문제로 바뀐다. 모델의 지식 규모와 실제 추론 비용을 분리한 MoE 구조와 MCP의 범용성이 만났기에 구현된 결과다.

결국 실무 효율은 하드웨어 사양별 배포 경로를 선택하고 preserve_thinking 옵션으로 추론의 깊이를 조절하는 세밀한 설정에 따라 달라진다. 자신의 VRAM 환경에 맞는 배포 경로를 선택하고 두 옵션을 조합하는 것으로 로컬 환경의 추론 효율을 최적화할 수 있다.