AI 에이전트 로컬 실행, 흔한 함정과 해결법

로컬에서 AI 에이전트를 돌릴 때 2026년 가장 흔한 착각은 "모델만 더 크면 에이전트가 잘 돈다"는 믿음이다. 실제로 에이전트를 무너뜨리는 건 한 번의 실수가 아니라 '루프에서 곱해지는 실패'다. 에이전트는 도구를 부르고 결과를 보고 또 부르는 연쇄인데, 한 번 호출 신뢰도가 95%라도 8스텝이면 0.95^8 ≈ 66%로 3분의 1이 그냥 깨진다. 그리고 실패는 랜덤이 아니라 두 갈래로 뭉친다: 아예 도구를 안 부르거나(omission), 부르되 JSON·인자가 틀린다(malformed). 이 글은 로컬 에이전트 고유의 함정을 증상 → 원인 → 해결 순으로 수치와 함께 정리한다.

쉽게 말하면: 에이전트 루프는 릴레이 이어달리기다. 주자 한 명(한 호출)이 95%로 바통을 잘 넘겨도, 여덟 명이 이어달리면 어딘가서 한 번 떨어뜨릴 확률이 3분의 1이다. 그래서 "더 빠른 주자(큰 모델)"보다 바통을 놓쳤을 때 다시 잡는 규칙(스키마 검증·승인 게이트)이 완주를 좌우한다.

에이전트가 왜 몇 스텝 못 가 무너지나?

per-call 실패가 루프에서 복리로 곱해지기 때문이다. 95% 호출이라도 8스텝이면 ~66%까지 떨어지고, 작은 모델은 2~3스텝만 넘어도 일관성을 잃는다. 실패의 정체를 보면 malformed 호출이 표본의 약 32% — 틀린 도구 이름(db_query 대신 database_query), 깨진 JSON·누락 인자, 환각 파라미터다. 나머지 큰 축은 omission(도구를 아예 안 부름) — 진단에서 qwen2.5:3b는 오류의 약 89%가 omission으로, 얕은 절차적 추론을 드러냈다. 해결의 1순위는 모델 교체가 아니라 엄격한 JSON 스키마 + 검증기(validator)다 — 스키마와 검증을 붙이면 작은 모델이 큰 모델의 함수호출 신뢰도를 따라잡거나 넘어선다. 그리고 승인 게이트(human-in-the-loop)가 per-call 실패를 복구해, 자율 에이전트보다 실전 성공률이 높다.

모델을 키우면 해결되나?

아니다 — 크기는 도구호출 신뢰도를 보장하지 않는다. 한 평가에서 llama3.3 70B가 0.607로, Qwen3 14B의 0.971보다 크게 뒤졌다(70B가 8B급보다 나빴다). BFCL V4의 능력 바닥선은 뚜렷하다: Qwen3.5 27B 68.5% · 9B 66.1%에서 4B 50.3% · 2B 43.6%로 급락 — 범용 에이전트의 실용 하한은 대략 7~9B다. 단 이건 harness(평가 틀)에 크게 의존한다 — 같은 llama3.3 70B가 MCP 서버 테스트에선 well-formed 호출률 ~97%로 최상위였다(대신 48GB+ VRAM 필요). 반대편 낙관론도 있다: 13개 로컬 모델 평가에서 크기와 도구호출 품질은 유의미한 상관이 없었고, 3.4GB Qwen3.5 4B가 97.5%(40중 1실패)로 훨씬 큰 모델들을 이겼다. 결론: 크기가 아니라 argument 정확도·스키마 준수·harness가 신뢰도를 가른다. 그래서 벤치 점수는 방향 신호로만 쓰고 자기 에이전트 스택이 진짜 벤치다.

조용히 신뢰도를 갉아먹는 설정은?

인프라 오설정이 포맷 신뢰도를 소리 없이 떨어뜨린다. 대표는 num_ctx를 VRAM 실제 용량보다 크게 잡는 것 — 그러면 조용한 CPU 폴백으로 절반이 CPU에서 돌며 도구호출 포맷 신뢰도가 저하된다(구조화된 호출은 나오지만 형식이 흔들린다). 또 하나: Gemma 4는 기본이 reasoning 강제라 도구호출이 content가 아니라 reasoning_content로 새는데, 이땐 --jinja --chat-template-kwargs '{"enable_thinking":false}'로 꺼야 한다. 반대로 잘 맞춘 로컬 셋업은 견고하다 — 단일 RTX 3090에서 30+ 연속 호출을 크래시 없이 버틴 보고가 있고, Qwen3.5 35B-A3B는 16GB VRAM(--cpu-moe)에서 실전 기본값으로 쓴다. 마지막 함정은 컨텍스트 초과 — 긴 멀티턴 트레이스가 창을 넘기면(Tau/SWE-Bench 샘플이 흔히 초과) 평가·실행이 무효가 된다. 그래서 루프는 스텝을 줄이고 요약·게이트로 컨텍스트를 관리해야 한다. 핵심 교훈: 프레임워크(LangChain·CrewAI 등)는 있는 능력을 증폭할 뿐, 없는 능력을 만들지 못한다 — 오케스트레이션·스키마·오류복구가 모델만큼 중요하다.

그래서 안전한 로컬 에이전트 세팅은?

핵심은 "스텝을 줄이고, 스키마·검증기로 호출을 강제하고, 컨텍스트·설정의 조용한 폴백을 막는 것"이다.

• 루프·복구: 스텝 최소화(복리 실패 완화), 승인 게이트로 per-call 복구, 작은 모델은 2~3스텝 이내로.
• 호출 강제: 엄격 JSON 스키마 + 검증기로 malformed 차단, 범용은 7~9B+, 선택은 BFCL/자기 스택 실측(크기 아님).
• 설정·컨텍스트: num_ctx를 VRAM에 맞춰 CPU 폴백 차단, Gemma 4는 thinking off, 긴 트레이스는 요약으로 컨텍스트 관리. 모든 선택은 자기 도구셋으로 A/B 후 고정.

함께 읽기: 로컬 LLM, VRAM은 얼마나 필요할까, MCP vs 함수 호출: 로컬 에이전트에 도구 붙이기

함께 읽기: AI 에이전트 로컬 실행, 직접 돌려본 속도·품질 비교, 로컬에서 돌리는 오픈 LLM, 2026 현황과 추천

참고 링크

• Berkeley Function Calling Leaderboard(BFCL)
• Qwen3 / Qwen-Agent(함수호출 프레임워크)
• 에이전트 도구호출 신뢰도 진단(arXiv)
• Schema-First 도구 API 통제연구(arXiv)
• 소형 에이전트 모델 서베이(arXiv)

참고: 복리 수치(0.95^8≈66%)·malformed ~32%·omission ~89%·BFCL(27B 68.5/9B 66.1/4B 50.3/2B 43.6)·llama3.3 70B 0.607 vs Qwen3 14B 0.971·num_ctx CPU 폴백 같은 수치·동작은 2026년 공개 벤치·arXiv·harness 기준이며 모델·버전·평가틀·도구셋에 따라 달라진다(영구 수치 아님, 벤치는 harness 의존). Qwen3.5→3.6, Gemma 3→4로 세대가 넘어가고 BFCL V4는 재현 이슈가 보고됐으니 카드·리더보드를 확인하라. 반드시 자기 도구셋·에이전트 스택으로 검증하라. 로컬 에이전트 스택은 빠르게 바뀌니 분기별로 다시 본다.