LLM Tool Calling - Middleware 만들기

시리즈: LLM Tool Calling 내부 원리부터 에이전트 직접 구현까지

이 시리즈는 사용자의 자연어 한 줄이 tool 실행으로 바뀌는 내부 처리 과정을 단계별로 해부하고, 최종적으로 오픈소스 모델 + 자체 middleware로 나만의 에이전트를 직접 구현하는 것까지 도달하는 과정이다.

편	내용	핵심
1편	전체 조감도	자연어 → tool 실행까지 5개 레이어의 존재를 확인
2편	Chat Template	JSON이 모델에 직접 들어가지 않는다
3편	Tokenization	모델은 텍스트를 읽지 못한다 - 토큰 ID와 control token
4편	모델 추론	”tool을 쓸까 말까” 판단과 constrained decoding
5편	Tool 실행	tool_use를 받은 클라이언트의 실행 루프
6편	Native vs Non-native	같은 기능, 다른 구조 → Middleware
7편 (본문)	Middleware 만들기	프롬프트 조립 + 출력 파싱 + 실행 루프 직접 구현
8편	오픈소스 모델 로컬 구축	Ollama/vLLM으로 로컬 LLM 서빙
9편	나만의 에이전트	모델 + Middleware = 에이전트 완성

---

• Tool Calling Middleware는 Non-native 모델에 없는 tool calling 레이어(Chat Template, 출력 파서, 실행 루프)를 외부에서 구현하는 소프트웨어 계층
• tool 정의 → 시스템 프롬프트 텍스트 변환, 모델 출력 → tool call 패턴 감지 및 JSON 추출, tool 실행 → 결과 피드백의 3가지 역할을 담당하는 변환/실행 루프
• Hermes, XML 등 텍스트 기반 프로토콜로 모델과 통신하며, Native 모델의 control token + constrained decoding 대신 정규식 파싱에 의존하는 구조

해당 개념이 필요한 이유

• 6편에서 Non-native 모델에는 Chat Template, 출력 파서, Constrained Decoding 등 5개 레이어 중 대부분이 없다는 것을 확인했다. 이 글에서는 그 없는 레이어를 직접 코드로 구현한다
• “Middleware를 만든다”는 것이 구체적으로 어떤 코드를 작성하는 것인지 확인해야, 8편에서 로컬 모델에 연결할 수 있다
• Qwen 공식 문서의 표현대로, function calling은 본질적으로 prompt engineering으로 구현된다. 이 사실을 코드로 직접 확인한다

AS-IS

sequenceDiagram
    autonumber
    participant User as 사용자
    participant LLM as 모델 가중치

    User->>LLM: "서울 날씨 알려줘"
    LLM-->>User: "서울의 현재 날씨를 확인할 수 없지만,<br/>일반적으로 2월은 춥습니다..."
    Note over User,LLM: tool 정의를 전달할 방법이 없다<br/>tool call 형식 출력도 나오지 않는다

TO-BE

sequenceDiagram
    autonumber
    participant User as 사용자
    box 애플리케이션
        participant MW as Middleware
        participant Tool as Tool 함수
    end
    participant LLM as 모델 가중치

    User->>MW: "서울 날씨 알려줘"
    MW->>LLM: tool 정의 포함 텍스트 프롬프트
    LLM-->>MW: "...<tool_call>{...get_weather...}</tool_call>"
    MW->>MW: tool call 패턴 감지 + JSON 추출
    MW->>Tool: get_weather("Seoul") 실행
    Tool-->>MW: {temperature: "15°C", condition: "맑음"}
    MW->>LLM: tool 결과 포함 프롬프트
    LLM-->>MW: "서울의 현재 날씨는 15°C이며 맑습니다"
    MW-->>User: 최종 응답
    Note over MW,Tool: tool 정의와 실행 함수는 개발자가 작성<br/>Middleware는 프롬프트 변환 + 파싱 + 실행 루프를 담당

Middleware의 3가지 역할

6편에서 Middleware가 “없는 레이어를 외부에서 메운다”고 했다. 구체적으로 3가지 역할이다:

sequenceDiagram
    autonumber
    participant User as 사용자
    box 애플리케이션
        participant MW as Middleware
        participant Tool as Tool 함수
    end
    participant LLM as 모델 가중치

    User->>MW: "서울 날씨 알려줘"

    Note over MW: 역할 1: 프롬프트 조립<br/>tool JSON → 시스템 프롬프트 텍스트
    MW->>LLM: 프로토콜에 맞춘 텍스트 프롬프트
    LLM-->>MW: "...<tool_call>{...get_weather...}</tool_call>"

    Note over MW: 역할 2: 출력 파싱<br/>정규식으로 tool call 감지 → JSON 추출
    MW->>Tool: get_weather("Seoul") 실행
    Tool-->>MW: {temperature: "15°C", condition: "맑음"}

    Note over MW: 역할 3: 실행 루프<br/>tool 결과를 모델에 피드백
    MW->>LLM: tool 결과 포함 프롬프트
    LLM-->>MW: "서울의 현재 날씨는 15°C이며 맑습니다"

    MW-->>User: 최종 응답

역할	대체하는 Native 레이어	하는 일	다이어그램
프롬프트 조립	Chat Template	tool JSON → 시스템 프롬프트 텍스트 변환	2번
출력 파싱	출력 파서 + Constrained Decoding	모델 출력에서 <tool_call> 패턴 감지 → JSON 추출	3번
실행 루프	SDK의 toolRunner	tool 실행 → 결과를 모델에 피드백 → 추가 tool call 확인 → 반복	4~7번

프로토콜 - Middleware와 모델이 약속하는 형식 (2,3번과 6,7번 과정)

위 다이어그램에서 Middleware와 모델이 통신하는 과정(2,3번과 6,7번)에는 약속이 필요하다. “tool 정의를 어떤 텍스트로 전달하고, 모델은 tool call을 어떤 텍스트로 표현할 것인가” — 이것이 프로토콜이다.

Native 모델에서는 control token이 이 역할을 했다 (3편). Middleware에서는 control token이 없으므로, 일반 텍스트 패턴으로 대체한다.

대표적인 프로토콜 2가지:

Hermes 프로토콜

NousResearch Hermes 모델이 정의하고, Qwen3 등 tool calling fine-tuning된 오픈소스 모델이 채택한 형식이다. <tool_call> XML 태그 안에 JSON을 넣는다:

모델 출력:
<tool_call>
{"name": "get_weather", "arguments": {"location": "Seoul"}}
</tool_call>

시스템 프롬프트에서 tool 정의도 JSON으로 전달한다:

You are provided with function signatures within <tools></tools> XML tags:
<tools>
[{"type": "function", "function": {"name": "get_weather", ...}}]
</tools>

For each function call return a json object with function name and arguments
within <tool_call></tool_call> XML tags:
<tool_call>
{"name": "<function_name>", "arguments": <args_json_object>}
</tool_call>

XML 프로토콜

tool 이름과 인자를 모두 XML 태그로 표현하는 형식이다. ai-sdk-tool-call-middleware의 morphXmlToolMiddleware가 이 방식을 사용한다:

모델 출력:
<tool_call>
<tool_name>get_weather</tool_name>
<location>Seoul</location>
</tool_call>

파라미터 이름이 XML 태그 이름이 되므로, JSON 파싱 없이 XML 파싱만으로 인자를 추출할 수 있다.

어떤 프로토콜을 선택하는가

	Hermes	XML
tool call 인자	JSON 객체	XML 태그
파싱 난이도	JSON.parse 필요	XML 태그 추출만
적합한 모델	Hermes format으로 fine-tuning된 모델 (Qwen3, Hermes 등)	fine-tuning 없는 범용 모델
사용하는 구현체	hermesToolMiddleware, qwen3CoderToolMiddleware	morphXmlToolMiddleware

핵심 기준: 모델이 어떤 형식으로 학습되었는가. 4편에서 확인한 것처럼, fine-tuning은 모델이 특정 패턴을 생성할 확률을 높인다. Qwen3가 Hermes 형식으로 fine-tuning되었다면, Hermes 프로토콜을 사용해야 해당 패턴의 생성 확률이 가장 높다.

fine-tuning 없는 범용 모델이라면? In-context learning에 의존해야 한다. 시스템 프롬프트에 형식을 상세히 지시하고, 모델이 그 지시를 따르기를 기대한다. 이 경우 XML 프로토콜이 더 나을 수 있다. XML은 웹 데이터에서 자주 등장하므로, 범용 모델도 XML 태그 패턴에 어느 정도 익숙하기 때문이다.

이 글에서는 Hermes 프로토콜로 구현한다. Qwen3 등 실제 사용할 모델이 이 형식을 지원하고, 가장 널리 쓰이는 형식이기 때문이다.

Tool 실행 - 함수 호출과 결과 반환 (4,5번 과정)

프로토콜이 Middleware↔모델 사이의 텍스트 통신 규약이라면, 4,5번은 Middleware↔Tool 사이의 코드 통신이다. 프로토콜과 무관하게, 일반적인 함수 호출이다.

• 4번 (MW→Tool): Middleware가 출력 파싱으로 추출한 tool 이름("get_weather")과 인자({"location": "Seoul"})로, 등록된 함수를 찾아 호출한다. 5편에서 다룬 “tool 이름 → 함수 매핑 → 실행”과 동일하다.
• 5번 (Tool→MW): Tool 함수가 실행 결과를 JSON으로 반환한다. 이 결과가 6번에서 프로토콜 형식으로 모델에 피드백된다.

// 4번: tool 이름으로 함수를 찾아 호출
const tool = tools[parsedToolCall.name];       // "get_weather" → 함수 매핑
const result = await tool.execute(parsedToolCall.arguments);  // 실행
 
// 5번: 함수가 JSON으로 결과 반환
// result = { temperature: "15°C", condition: "맑음" }

tool 정의와 실행 함수는 개발자가 애플리케이션에 작성한다. Middleware는 이 함수를 호출하고 결과를 받아 모델에 전달하는 역할만 한다.

프로토콜과 Tool 실행을 정리했으니, 이제 3가지 역할을 코드로 구현한다.

역할 1: 프롬프트 조립

첫 번째 역할은 tool 정의 JSON을 시스템 프롬프트 텍스트로 변환하는 것이다. 2편에서 Claude의 API 서버가 하던 일을 우리가 직접 한다.

interface ToolDefinition {
  name: string;
  description: string;
  parameters: Record<string, unknown>; // JSON Schema
}
 
function assembleToolPrompt(tools: ToolDefinition[]): string {
  // tool 정의를 Hermes 형식의 JSON 배열로 변환
  const toolDefs = tools.map((t) => ({
    type: "function",
    function: {
      name: t.name,
      description: t.description,
      parameters: t.parameters,
    },
  }));
 
  return [
    "You are a function calling AI model.",
    "You are provided with function signatures within <tools></tools> XML tags:",
    "<tools>",
    JSON.stringify(toolDefs, null, 2),
    "</tools>",
    "",
    "For each function call return a json object with function name and arguments",
    "within <tool_call></tool_call> XML tags:",
    "<tool_call>",
    '{"name": "<function_name>", "arguments": <args_json_object>}',
    "</tool_call>",
  ].join("\n");
}

이 함수가 하는 일은 단순하다. tool JSON을 받아서, 모델이 이해할 수 있는 텍스트로 감싸는 것이다. 출력 예시:

You are a function calling AI model.
You are provided with function signatures within <tools></tools> XML tags:
<tools>
[
  {
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "Get the current weather in a given location",
      "parameters": {
        "type": "object",
        "properties": {
          "location": { "type": "string" }
        },
        "required": ["location"]
      }
    }
  }
]
</tools>
 
For each function call return a json object with function name and arguments
within <tool_call></tool_call> XML tags:
<tool_call>
{"name": "<function_name>", "arguments": <args_json_object>}
</tool_call>

2편에서 Claude의 시스템 프롬프트가 "In this environment you have access to a set of tools..." 로 시작했던 것과 동일한 역할이다. 형식만 다를 뿐, 하는 일은 같다: tool 정의를 텍스트로 모델에게 알려주는 것.

tool 실행 결과를 피드백할 때도 프롬프트에 포함해야 한다:

function assembleToolResult(
  toolName: string,
  result: string
): string {
  return [
    "<tool_response>",
    `{"name": "${toolName}", "content": ${result}}`,
    "</tool_response>",
  ].join("\n");
}

역할 2: 출력 파싱

두 번째 역할은 모델이 생성한 텍스트에서 tool call 패턴을 감지하고 JSON으로 추출하는 것이다. 4편에서 API 서버의 출력 파서가 하던 일이다.

모델의 실제 출력은 이런 텍스트다:

날씨를 확인해보겠습니다.
 
<tool_call>
{"name": "get_weather", "arguments": {"location": "Seoul"}}
</tool_call>

이 텍스트에서 <tool_call> 태그를 찾고, 안의 JSON을 추출해야 한다:

interface ParsedToolCall {
  name: string;
  arguments: Record<string, unknown>;
}
 
function parseToolCalls(text: string): ParsedToolCall[] {
  const pattern = /<tool_call>\s*([\s\S]*?)\s*<\/tool_call>/g;
  const toolCalls: ParsedToolCall[] = [];
 
  let match;
  while ((match = pattern.exec(text)) !== null) {
    const jsonStr = match[1].trim();
    const parsed = JSON.parse(jsonStr);
    toolCalls.push({
      name: parsed.name,
      arguments: parsed.arguments,
    });
  }
 
  return toolCalls;
}

정규식 /<tool_call>\s*([\s\S]*?)\s*<\/tool_call>/g이 핵심이다. <tool_call> 과 </tool_call> 사이의 내용을 캡처하고, [\s\S]*?로 줄바꿈을 포함한 모든 문자를 매칭한다.

이 부분이 Native 모델과 가장 큰 차이가 발생하는 지점이다. Native 모델은 control token으로 tool call 영역을 명확히 구분하고, constrained decoding으로 valid JSON을 보장한다 (3편, 4편). Middleware는 정규식 매칭과 JSON.parse에 의존한다. 모델이 <tool_call> 태그를 정확히 닫지 않거나, JSON이 깨져 있으면 파싱이 실패한다.

이 한계는 에러 핸들링 섹션에서 다룬다.

tool call 유무로 응답 분기

파싱 결과를 바탕으로 응답을 분기한다:

function classifyResponse(text: string):
  | { type: "tool_calls"; calls: ParsedToolCall[]; textBefore: string }
  | { type: "text"; content: string } {
 
  const toolCalls = parseToolCalls(text);
 
  if (toolCalls.length > 0) {
    // <tool_call> 앞의 텍스트 추출 (모델의 사전 설명)
    const textBefore = text.split("<tool_call>")[0].trim();
    return { type: "tool_calls", calls: toolCalls, textBefore };
  }
 
  return { type: "text", content: text };
}

이것이 5편의 stop_reason: "tool_use" vs stop_reason: "end_turn" 분기와 동일한 역할이다. Native 모델은 API 서버가 stop_reason을 설정해주지만, Middleware에서는 텍스트에 <tool_call> 패턴이 있는지 직접 확인해야 한다.

역할 3: 실행 루프

세 번째 역할은 프롬프트 조립 → 모델 호출 → 출력 파싱 → tool 실행 → 결과 피드백을 반복하는 것이다. 5편에서 SDK의 toolRunner가 하던 일이다.

interface Tool {
  description: string;
  parameters: Record<string, unknown>;
  execute: (args: Record<string, unknown>) => Promise<unknown>;
}
 
type Message = { role: string; content: string };
 
async function toolCallingLoop(
  model: { generate: (opts: { system: string; messages: Message[] }) => Promise<{ text: string }> },
  tools: Record<string, Tool>,
  prompt: string,
  maxSteps: number = 5
): Promise<string> {
  // 역할 1: 프롬프트 조립
  const toolDefs = Object.entries(tools).map(([name, t]) => ({
    name,
    description: t.description,
    parameters: t.parameters,
  }));
  const systemPrompt = assembleToolPrompt(toolDefs);
 
  const messages: Message[] = [{ role: "user", content: prompt }];
 
  for (let step = 0; step < maxSteps; step++) {
    // 모델 호출
    const response = await model.generate({
      system: systemPrompt,
      messages,
    });
 
    // 역할 2: 출력 파싱
    const classified = classifyResponse(response.text);
 
    if (classified.type === "text") {
      return classified.content; // 최종 텍스트 응답 → 루프 종료
    }
 
    // tool call이 있으면 → 실행 후 결과 피드백
    messages.push({ role: "assistant", content: response.text });
 
    for (const toolCall of classified.calls) {
      const tool = tools[toolCall.name];
      if (!tool) {
        throw new Error(`Unknown tool: ${toolCall.name}`);
      }
 
      // tool 실행
      const result = await tool.execute(toolCall.arguments);
      const resultStr = JSON.stringify(result);
 
      // 결과를 메시지에 추가 → 다음 루프에서 모델에 전달
      messages.push({
        role: "tool",
        content: assembleToolResult(toolCall.name, resultStr),
      });
    }
    // 다시 루프 시작 → 모델이 추가 tool call 또는 최종 응답 생성
  }
 
  return "최대 단계에 도달했습니다.";
}

5편의 멀티턴 tool calling 시퀀스 다이어그램을 코드로 구현한 것이다. 루프의 종료 조건은 두 가지:

• classifyResponse가 "text" 반환 → 모델이 최종 응답 생성 (= stop_reason: "end_turn")
• step >= maxSteps → 최대 단계 도달 (= Vercel AI SDK의 stopWhen: stepCountIs(5))

사용 예시

// 실행
const answer = await toolCallingLoop(
  ollamaModel,
  {
    get_weather: {
      description: "Get the current weather in a given location",
      parameters: {
        type: "object",
        properties: { location: { type: "string" } },
        required: ["location"],
      },
      execute: async ({ location }) => ({
        temperature: "15°C",
        condition: "맑음",
        location,
      }),
    },
  },
  "서울 날씨 알려줘"
);
 
console.log(answer);
// → "서울의 현재 날씨는 15°C이며 맑습니다."

이것이 Middleware의 전체 구현이다. assembleToolPrompt + parseToolCalls + toolCallingLoop 3개 함수로 Non-native 모델에서 tool calling이 동작한다.

에러는 반드시 발생한다

Qwen 공식 문서는 이렇게 경고한다:

“It is not guaranteed that the model generation will always follow the protocol even with proper prompting or templates.”

Native 모델에서는 constrained decoding이 valid JSON을 100% 보장했다 (4편). Middleware에는 이 안전장치가 없다. 모델은 자유롭게 아무 토큰이나 생성할 수 있으므로, 에러는 가능성이 아니라 확실성이다.

주요 에러 유형과 대응

에러	원인	대응
태그 미닫힘	<tool_call> 열고 </tool_call> 없이 종료	정규식 매칭 실패 → 텍스트 응답으로 처리
JSON 파싱 실패	{"name": "get_weather", "arguments": {location: Seoul}} (따옴표 누락)	try-catch로 감싸고 재시도 또는 fallback
존재하지 않는 tool	모델이 정의에 없는 tool 이름 생성	tool 이름 검증 후 에러 메시지를 모델에 피드백
타입 불일치	"temperature" (string) 대신 temperature (number)	JSON Schema 기반 타입 강제 변환

에러 핸들링을 추가한 파싱 함수:

function parseToolCallsSafe(text: string): {
  toolCalls: ParsedToolCall[];
  errors: string[];
} {
  const pattern = /<tool_call>\s*([\s\S]*?)\s*<\/tool_call>/g;
  const toolCalls: ParsedToolCall[] = [];
  const errors: string[] = [];
 
  let match;
  while ((match = pattern.exec(text)) !== null) {
    try {
      const parsed = JSON.parse(match[1].trim());
 
      if (!parsed.name || typeof parsed.name !== "string") {
        errors.push(`Invalid tool name: ${JSON.stringify(parsed.name)}`);
        continue;
      }
 
      toolCalls.push({
        name: parsed.name,
        arguments: parsed.arguments ?? {},
      });
    } catch (e) {
      errors.push(`JSON parse failed: ${match[1].trim().slice(0, 100)}`);
    }
  }
 
  return { toolCalls, errors };
}

에러가 발생하면 모델에 에러 메시지를 피드백하여 재시도할 수 있다. 이것은 Vercel AI SDK가 tool 실행 에러를 tool-error content part로 모델에 전달하여 LLM이 자체 복구하도록 하는 것과 같은 원리다.

Vercel AI SDK Middleware로 조립하기

지금까지 만든 3개 함수(assembleToolPrompt, parseToolCalls, toolCallingLoop)는 Middleware의 원리를 이해하기 위한 것이었다. 실제 프로덕션에서는 Vercel AI SDK의 middleware 구조에 맞춰 패키징한다.

Vercel AI SDK의 wrapLanguageModel은 3가지 후킹 포인트를 제공한다:

후킹 포인트	역할	우리가 만든 함수
transformParams	모델에 전달되기 전 파라미터 변환	assembleToolPrompt (프롬프트 조립)
wrapGenerate	doGenerate 실행을 감싸기	parseToolCalls (출력 파싱)
wrapStream	doStream 실행을 감싸기	parseToolCalls의 스트리밍 버전

import { type LanguageModelV3Middleware } from "ai";
 
const toolCallMiddleware: LanguageModelV3Middleware = {
  // 역할 1: 프롬프트 조립
  transformParams: async ({ params }) => ({
    ...params,
    prompt: {
      ...params.prompt,
      system: assembleToolPrompt(params.tools ?? []),
    },
    // tool 정의는 시스템 프롬프트로 이동했으므로 제거
    tools: undefined,
  }),
 
  // 역할 2: 출력 파싱
  wrapGenerate: async ({ doGenerate }) => {
    const result = await doGenerate();
    const { toolCalls, errors } = parseToolCallsSafe(result.text ?? "");
 
    if (toolCalls.length > 0) {
      return {
        ...result,
        toolCalls: toolCalls.map((tc) => ({
          toolCallType: "function" as const,
          toolCallId: crypto.randomUUID(),
          toolName: tc.name,
          args: JSON.stringify(tc.arguments),
        })),
        finishReason: "tool-calls" as const,
      };
    }
 
    return result;
  },
};

이제 이 middleware를 모델에 감싸면 된다:

import { wrapLanguageModel, generateText, tool, stepCountIs } from "ai";
import { createOllama } from "ollama-ai-provider";
import { z } from "zod";
 
const ollama = createOllama();
 
// middleware로 모델 감싸기
const wrappedModel = wrapLanguageModel({
  model: ollama("qwen3:8b"),
  middleware: toolCallMiddleware,
});
 
// 이제 native tool calling처럼 사용
const result = await generateText({
  model: wrappedModel,
  tools: {
    get_weather: tool({
      description: "Get the current weather",
      parameters: z.object({ location: z.string() }),
      execute: async ({ location }) => ({
        temperature: "15°C",
        condition: "맑음",
      }),
    }),
  },
  stopWhen: stepCountIs(5),
  prompt: "서울 날씨 알려줘",
});

개발자 입장에서는 native tool calling API와 동일한 인터페이스를 사용한다. middleware가 내부에서 프롬프트 조립 → 출력 파싱 → 실행 루프를 처리한다.

실제 구현체: @ai-sdk-tool/parser

직접 middleware를 만들 수도 있지만, 이미 검증된 구현체가 있다. ai-sdk-tool-call-middleware는 4가지 프로토콜을 지원한다:

import {
  hermesToolMiddleware,       // Hermes: JSON in <tool_call> tags
  morphXmlToolMiddleware,     // XML: 파라미터를 XML 태그로
  yamlXmlToolMiddleware,      // YAML-XML: XML 태그 + YAML body
  qwen3CoderToolMiddleware,   // Qwen3 전용
} from "@ai-sdk-tool/parser";
 
// 모델에 맞는 프로토콜 선택
const wrappedModel = wrapLanguageModel({
  model: ollama("qwen3:8b"),
  middleware: hermesToolMiddleware,
});

커스텀 프로토콜도 만들 수 있다:

import { createToolMiddleware, hermesProtocol } from "@ai-sdk-tool/parser";
 
const customMiddleware = createToolMiddleware({
  protocol: hermesProtocol,
  toolSystemPromptTemplate: (tools) =>
    `Use these tools: ${JSON.stringify(tools)}`,
});

스트리밍 환경에서는 tool-input-start, tool-input-delta, tool-input-end 이벤트를 통해 tool call 파싱 과정을 점진적으로 처리하며, 에러 발생 시 providerOptions.toolCallMiddleware.onError 콜백으로 커스텀 처리가 가능하다.

다음 편: 모델도 직접 띄울 수 있나?

이 글에서 Middleware의 3가지 역할을 코드로 구현했다. 프롬프트 조립, 출력 파싱, 실행 루프 — 이 3개 함수만으로 Non-native 모델에서 tool calling이 동작한다.

하지만 지금까지 ollama("qwen3:8b") 같은 모델 호출을 당연하게 사용했다. 이 모델은 어디서 실행되고 있는 걸까? 오픈소스 모델을 로컬에서 직접 띄우려면 어떻게 해야 할까?

다음 편에서 Ollama와 vLLM으로 오픈소스 모델을 로컬에 서빙하는 과정을 다룬다. 특히, vLLM의 --tool-call-parser hermes 옵션으로 서빙 레벨에서 Middleware 역할을 수행하는 것도 확인한다.

참고 문서

• NousResearch Hermes 2 Pro - Hermes 프로토콜의 원본 정의, <tool_call> + JSON 형식
• Qwen3 Function Calling - Hermes-style tool use 채택, “function calling is essentially prompt engineering”
• Vercel AI SDK - Language Model Middleware - wrapLanguageModel, transformParams/wrapGenerate/wrapStream 구조
• ai-sdk-tool-call-middleware - Hermes/XML/YAML-XML 프로토콜 기반 tool call middleware 실제 구현체
• @ai-sdk-tool/parser npm - hermesToolMiddleware, morphXmlToolMiddleware 패키지
• Vercel AI SDK - Tool Calling - generateText의 tool 실행 루프, stopWhen, tool-error 처리