왜 로컬 배포 현장에서는 모델 대신 설정이 승부처가 되는가
하드웨어 설계 툴처럼 컴포넌트 사양과 명명 규칙 자체가 미출시 제품 정보를 드러내는 영역에서는 호스팅형 상용 API를 쓸 수 없어, 팀은 4비트로 양자화한 오픈소스 모델을 로컬에서 구동하는 선택지밖에 남지 않습니다. 밀라노 폴리테크닉 연구진이 7개 로컬 모델을 MCP 툴콜링 벤치마크로 비교했더니, 같은 Gemma 4 E4B 모델도 설정에 따라 기대 호출 커버리지(ECC)가 0.811에서 0.168까지 떨어졌습니다. 모델을 바꿀 수 없는 조건에서는 히스토리 범위·시스템 프롬프트·툴 설명이라는 세 개 설정 축이 사실상 유일한 레버가 됩니다.
포괄적 설명이 대다수 조합에서 이긴 이유
42개 모델-과제군 조합 가운데 35개(83%)에서 최고 성능을 낸 설정은 파라미터 의미와 제약, 실패 조건까지 담은 포괄적 툴 설명이었습니다. 최소 설명으로 줄이면 모든 모델에서 툴 실패율이 대략 두 배로 뛰었는데, 14개 툴의 설명을 아껴 절감되는 토큰은 약 2,000개에 불과합니다. 설명을 줄여 버는 토큰 비용보다 실패율 상승이 훨씬 비싼 거래인 셈입니다.
구축 로드맵과 함정: 로컬 MCP 에이전트 설정 체크리스트
신규 로컬 모델을 붙이기 전에 합격선부터 코드로 선언합니다. 기대 호출 커버리지(ECC) 0.85 이상, 툴 실패율(TFR) 5% 이하, 불필요 호출 비율(EVCR) 5% 이하를 최소 배포 기준으로 두고, 상태를 이어받아야 하는 히스토리·크로스 세션 과제는 독립 과제와 분리된 별도 골든셋으로 관리합니다. Llama 3.1 8B는 독립 과제 평균 ECC 0.753이었지만 세션 상태를 복원해야 하는 과제에서는 0.139로 82% 낮아졌으므로, 하나의 합격선으로 두 유형을 같이 재면 세션 의존 실패가 평균에 묻힙니다.
few-shot 예시를 넣으면 대체로 도움이 된다는 통념은 모델마다 다르게 작동합니다. 대다수 모델은 few-shot 유무에 따른 ECC 변화가 0.04 이내였지만, Gemma 4 31B는 0.956에서 0.571로, Gemma 4 E4B는 0.731에서 0.179로 급락했습니다. 틀린 답을 내는 대신 아예 행동을 멈추는 무응답 붕괴라 응답 로그만 봐서는 원인을 알기 어렵습니다.
새 모델을 파이프라인에 넣을 때는 few-shot 포함·제외 두 버전을 반드시 A/B로 비교한 뒤 기본값을 정합니다. 배포 후에도 무호출 정확도(NCA)를 별도 지표로 관측해, 응답 자체가 사라지는 비율이 오르면 few-shot 프롬프트를 먼저 의심하는 순서를 로그 대시보드 알림 규칙에 명시해 둡니다.
툴 설명을 최소화하면 토큰은 아끼지만 실패율은 거의 모든 모델에서 두 배로 뛰었습니다. 이 실패는 조용히 쌓입니다. 응답 자체는 나오지만 파라미터를 빠뜨리거나 잘못된 컴포넌트를 참조하는 식이라, 최종 텍스트 출력만 보는 모니터링으로는 잡히지 않습니다.
그래서 상태를 바꾸는 툴콜링 에이전트는 최종 응답이 아니라 호출 단위로 채점해야 합니다. 로그 표준 필드로 모델 ID, 히스토리 범위(세션 누적 또는 과제별 초기화), 시스템 프롬프트 유형, 툴 설명 상세도, ECC·EVCR·TFR·NCA 네 지표를 남기면 설정 축을 바꿨을 때의 영향을 즉시 비교할 수 있습니다. 로컬 배포 환경에서는 컴포넌트 사양·명명 규칙 같은 기밀 필드를 로그에서 마스킹하는 절차도 배포 전 체크리스트에 넣어야 합니다.
멀티에이전트 분해는 만능 해법이 아닙니다. 약한 워커 Llama 3.1 8B는 단일 ReAct 에이전트 0.554에서 Plan-and-Act 분해 0.718로, 특히 히스토리 과제는 0.113에서 0.650으로 크게 개선됐습니다. 반면 강한 워커 Gemma 4 26B를 같은 6개 핵심 과제군에 분해 구조로 투입하면 오히려 커버리지가 떨어졌고, 세션이 길어지는 60과제 규모의 Hard-Noise 과제군에서만 0.858에서 0.950으로 다시 이득을 봤습니다. 워커가 약하거나 세션이 길 때만 분해를 켜는 조건부 규칙이 필요합니다.
온도 0·0.5·1.0에 걸친 반복과 10회 재실행으로 확인한 결과 강한 모델의 순위는 안정적이었지만(예: Gemma 4 26B의 ECC는 0.881~0.896 범위), 한 번의 설정 탐색으로 끝내도 되는 것은 아닙니다. 매주 실패 로그에서 무응답 붕괴·세션 상태 유실·불필요 호출 비율이 높은 조합을 추려 골든셋에 역주입하고, 설정 변경과 모델 교체를 분리된 로그 항목으로 남겨야 다음 주 지표 변동의 원인을 구분할 수 있습니다.
바로 쓰는 체크리스트
로컬·기밀 제약으로 모델을 마음대로 바꿀 수 없는 팀이라면 히스토리 범위·시스템 프롬프트·툴 설명 세 축을 모델 선택보다 먼저 탐색 대상으로 올려야 합니다. 툴 설명은 아끼지 않고, few-shot은 모델별로 A/B 검증하며, 멀티에이전트 분해는 약한 워커·긴 세션 조건에서만 켭니다. 호출 단위 채점과 축별 로그 필드를 갖추면 같은 모델이라도 설정만으로 ECC 0.168과 0.990 사이 어디에 놓일지 스스로 결정할 수 있습니다.
참고 링크
Benchmarking AI Agents for Hardware Design Automation via MCP Tool Calling — arXiv