같은 8B 가중치를 같은 머신에서 구동한다. 그런데 에이전트의 도구 호출(Tool Calling) 성공률이 한쪽은 7%, 다른 한쪽은 83%가 된다. 이 차이는 모델의 똑똑함이 아니라, 모델을 '서빙하는 측'의 구조에서 발생한다. 로컬 LLM으로 에이전트를 구축해 본 사람이라면, 도중에 도구 호출을 위한 JSON이 깨져서 전체가 멈춰버리는 그 허탈함을 기억할 것이다.

forge-guardrails (통칭 Forge)는 바로 그 간극을 메우기 위해 등장한 Python 프레임워크로, 자체 호스팅하는 8B 클래스 모델을 26개 시나리오 벤치마크에서 84%까지 끌어올렸다고 공표했다.

전제 조건이 하나 있다. 현재의 AI 에이전트는 "모델에 도구 목록을 전달한다 → 모델이 호출하고 싶은 도구와 인수를 JSON으로 반환한다 → 우리가 실행하고 결과를 돌려준다"라는 루프를 수십 번 반복한다. 프론티어 모델(Frontier Model)은 이 왕복 과정을 상당히 정확하게 수행하지만, 8B 전후의 로컬 모델은 다르다.

실패의 원인은 모델이 문제를 풀지 못해서가 아닌 경우가 많다. 대부분은 형식의 불일치다. OpenAI 형식의 tool_calls로 반환되기를 바라지만, Mistral 계열은 [TOOL_CALLS]를, Qwen 계열은 XML로 반환한다. 도구를 사용해야 할 상황에서 그냥 일반 텍스트를 내뱉거나, 절차의 중간을 건너뛰거나, 루프가 길어져 컨텍스트 제한(Context Limit)에 걸리기도 한다. 모두 단계마다 발생하는 작은 균열이지만, 다단계 에이전트에서는 한 단계만 어긋나도 전체가 실패하므로 성공률은 곱연산으로 급락한다.

Forge의 발상은 모델을 똑똑하게 만드는 것이 아니라, 모델과 애플리케이션 사이에 검증 및 복구 계층을 삽입하는 데 있다. 깨진 도구 호출을 각 방언(Dialect)으로부터 다시 포착하여 OpenAI의 tool_calls 스키마로 정형화하고(rescue parsing), 검증에 실패하면 최대 3회까지 정정 메시지와 함께 재시도하며, 도구가 필요한 상황에서 일반 텍스트를 출력하지 않도록 합성된 respond 도구를 주입한다. 절차를 제약하고 싶을 때는 required_steps나 terminal_tool로 순서를 강제할 수 있다. 요컨대, 모델의 변덕이 애플리케이션에 도달하기 전에 차단하는 것이다.

이 부분은 의도적으로 정리해서 쓰겠다. 출처에 따라 숫자가 다르기 때문이다.

Show HN에서는 "53% → 99%"라는 헤드라인이 눈에 띄었지만, README와 PyPI라는 1차 소스에서 공식적으로 내세우는 숫자는 8B에서 84%다. 99.3%는 도구 호출의 엄격성만을 본 좁은 범위의 수치이며, 26개 시나리오 전체의 값은 아니다. 순수 상태가 "한 자릿수 %"인지 "53%"인지 갈리는 점 또한 사실 이번 발견에서 가장 흥미로운 부분과 직결된다.

그 발견이 바로 서두에 언급한 숫자다. 리뷰에 따르면, 동일한 Mistral-Nemo 12B 가중치라도 llama-server의 네이티브 function calling에서는 정확도가 7%인 반면, Llamafile의 프롬프트 주입 모드에서는 83%가 된다고 보고되었다. 모델은 단 1바이트도 바꾸지 않았다. 도구 정의를 어떻게 전달하고 출력을 어떻게 받느냐 하는 "서빙 계층(Serving Layer)"의 구성만으로 10배 이상의 차이가 발생한다.

여기에 로컬 에이전트가 왜 제대로 작동하지 않는지에 대한 핵심이 있다. 우리는 무심코 "8B라서 무리다"라며 모델 크기 탓을 하지만, 실제로는 서빙 설정의 궁합이 성공률의 대부분을 결정하며, 그 위에 얇은 가드레일(Guardrail)을 얹으면 단숨에 실용적인 영역으로 들어선다. Forge가 보여준 것은 새로운 마법이 아니라, "놓치는 부분을 잡아내면 작은 모델로도 충분히 싸울 수 있다"라는, 소박하지만 재현 가능한 공학이다. 프론티어 모델(Claude Sonnet 4.6)조차 85%에서 98%로 향상된다는 점은 시사하는 바가 크며, 형식 불일치나 컨텍스트 관리는 거대 모델에서도 일정 확률로 발생한다는 것을 의미한다.

설치는 간단하다. Python 3.12 이상이 필요하다 (집필 시점 최신 버전은 0.8.3).

pip install forge-guardrails
# Anthropic 클라이언트 포함 버전
pip install "forge-guardrails[anthropic]"

프로그램에서 사용할 경우, Workflow로 도구와 제약 사항을 정의하고 WorkflowRunner로 루프를 돌린다. 백엔드는 Ollama, llama-server, Llamafile, vLLM, Anthropic을 지원한다.

from forge import Workflow, WorkflowRunner, ToolDef, LlamafileClient
workflow = Workflow(
name="weather",
...

기존 코드를 다시 작성하고 싶지 않다면, 드롭인 (drop-in) HTTP 프록시 (proxy)로 끼워 넣는 것이 더 빠르다. OpenAI와 Anthropic 양쪽 API를 모두 지원하므로, Continue, aider, Cline, Claude Code와 같은 클라이언트의 목적지(endpoint)를 교체하는 것만으로 가드레일 (guardrail)을 적용할 수 있다.

python -m forge.proxy --backend-url http://localhost:8080 --port 8081

만능은 아니다. 1차 정보와 리뷰를 대조해 보면 솔직한 약점들이 보인다. 우선 지연 시간 (latency) 데이터가 공개되지 않았다. 최대 3회의 재시도 (retry) 방식은 성공률을 높이는 대신 실제 경과 시간 (wall-clock time)을 잡아먹을 것이 분명하며, "완료율과 레이턴시 (latency) 사이의 트레이드오프 (trade-off)"가 정량화되지 않았다는 점은 HN (Hacker News)에서도 지적된 부분이다. 합성 respond

도구 (tool) 역시 데이터로 효과가 입증되기는 했으나, 프로덕션 환경에서 상용하기에는 다소 미숙한 우회책이다. 검증이 집중된 모델은 Ministral과 Mistral-Nemo 계열이며, Qwen, Llama 3.x, Gemma는 상대적으로 미흡하다. 또한, MIT 라이선스의 개인 프로젝트인 만큼 사실상 1인 개발에 따른 유지보수 리스크가 뒤따른다.

그럼에도 불구하고, 로컬에서 에이전트 (agent)를 구동하려는 실무자에게는 시도해 볼 가치가 충분하다고 생각한다. 프록시로서 한 줄만 삽입하면, 현재 구동 중인 8B 모델의 성공률이 자신의 워크로드 (workload)에서 얼마나 변하는지 즉시 측정할 수 있다. 이때 주목해야 할 점은 "모델의 크기를 키워야 하는가"가 아니라, "서빙 (serving) 설정을 바꾸는 것만으로 몇 %를 회복할 수 있는가"이다. Forge의 가장 큰 기여는 84%라는 숫자 그 자체보다, 로컬 에이전트의 신뢰성이 모델의 가중치 (weight)가 아닌 서빙 계층 (serving layer)에서 결정될 수 있음을 수치로 증명했다는 데 있다.