제네릭 툴은 SQL보다 못했다: MCP 도메인 툴링 패턴과 Model Demotion 리뷰

원문 정보

Bartolomeo Bogliolo, "From SQL Generation to Tool Selection: A Domain-Oriented Pattern for MCP Servers", arXiv:2608.22063 [cs.AI], 2026-08-22 제출, DOI 10.48550/arXiv.2608.22063. 소속 표기 없이 단독 게재. 하니스 코드·벤치마크 아티팩트를 GitHub(github.com/meob/mcp-blueprint, github.com/meob/mcp-blueprint-benchmark)에 공개.

동료심사를 거치지 않은 프리프린트입니다. 저자는 벤치마크에서 비교한 세 설계 중 하나인 참조 구현체 MCP Blueprint의 개발자 본인이라, 자신이 만든 도구가 자신이 설계한 벤치마크에서 가장 높은 점수를 받은 구조입니다. 별도의 자금 출처 표기는 없습니다. 다만 하니스 코드·과제 정의·채점 규칙·프리즌한 팩·셀 단위 원시 결과(체크당 1개 JSON)까지 전부 공개해 외부 재현 경로를 열어 뒀다는 점은 상쇄 요인입니다. 원문 전문은 이 세션의 실시간 접근이 막혀 있어, 사이트 자동 수집 파이프라인이 2026-08-25T21:48:41Z에 받아 둔 arXiv HTML 전문 스냅숏으로 대조했습니다.

연구 개요

연구 질문은 하나입니다. LLM 에이전트가 MCP(Model Context Protocol)로 기업 데이터베이스에 접근할 때, 매번 SQL을 생성하게 하는 대신 미리 정의한 도메인 툴 중 하나를 고르게 하면 정확도·비용·필요 모델 크기가 어떻게 달라지는가입니다. 저자는 이를 "도메인 지향 툴링 패턴"으로 정식화하고, SQL 합성을 의도 분류로 바꾸면 같은 요청을 더 작은 모델로도 처리할 수 있다는 관찰을 "Model Demotion"이라 이름 붙였습니다.

검증은 참조 구현체 MCP Blueprint로 만든 재현성 벤치마크로 진행했습니다. Sakila 샘플 DB(고객·대여 이력)를 세 가지 MCP 서버 설계로 노출합니다 — (A) 6개 테이블 DDL을 시스템 프롬프트에 넣고 SQL 실행 툴 하나만 주는 원시 SQL, (B) 5개 도메인 툴(고객 계정 요약·대여 이력·영화 추천·재고 조회·고객 검색)이 조인·비즈니스 규칙을 서버 SQL에 캡슐화한 버티컬 팩, (C) 테이블 지향 툴 4개에 설명만 얕게 붙인 제네릭 팩입니다. 3B~8B급 로컬 모델 4종(llama3.2:3b, qwen2.5:3b, qwen2.5:7b, llama3.1:8b)에 17개 고객 응대 과제를 온도 0·시드 42로 3회씩 반복시켜 4×3×17×3=612셀을 계획했고, MCP 서버 기동 중 파이프 행업으로 3셀(0.5%)을 잃어 609셀을 완주했습니다(2026-08-20 실행, 커밋 b386d58). 채점은 LLM 심사가 아니라 실시간 DB에서 계산한 정답과 대조하는 규칙 기반 체크입니다.

핵심 결과

세 설계의 평균 정확도는 버티컬 팩(B) 0.939, 원시 SQL(A) 0.666, 제네릭 팩(C) 0.605였습니다. B는 완전 정답 비율이 85%(174/204)인 반면 A는 33%(67/201), C는 31%(63/204)에 그쳤고, 0점 셀 비율은 C가 9%(19개)로 가장 높았습니다 — 툴을 붙였다고 무조건 좋아지는 게 아니라, 설계가 얕으면 원시 SQL보다도 나빠질 수 있다는 뜻입니다.

모델별로도 B가 항상 가장 높았고(0.90 밑으로 내려간 적이 없음), 이득은 작은 모델에서 가장 컸습니다. llama3.2:3b는 원시 SQL에서 완전 정답 6/51(0.583)에 그쳤지만 도메인 툴에서는 42/51(0.929)로 올라갔습니다 — Model Demotion 가설의 경험적 근거로 저자가 제시하는 지점입니다.

비용 지표는 기준을 구분해서 읽어야 합니다. 셀당 평균 토큰(총 토큰 기준)은 B 3,056·C 2,894·A 3,953으로 격차가 크지 않지만, 정답 하나당 비용으로 환산하면 벌어집니다.

모델별 정답당 비용(원시 SQL 대비 버티컬 팩) 절감 배율은 llama3.2:3b 약 11.6배, qwen2.5:3b 약 3.7배, qwen2.5:7b 약 2.0배, llama3.1:8b 약 2.3배였습니다. 논문은 이 연구에서 가장 저렴한 완전 정답이 8B급 모델이 SQL을 쓴 결과가 아니라 3B급 모델이 도메인 툴을 쓴 결과라는 점을 경제적 핵심 주장으로 제시합니다.

신뢰도 평가

믿을 근거는 세 가지입니다. 첫째, 채점이 LLM 심사가 아니라 실행 중 DB 상태와 대조하는 규칙 기반 체크라 평가자 편향이 끼어들 여지가 적습니다. 둘째, 네 모델 전부에서 B가 A·C를 앞서는 방향이 일관됩니다. 셋째, 하니스·과제·채점 규칙·프리즌한 팩·셀 단위 원시 결과까지 전부 공개해 외부 재현이 가능합니다.

감안할 점도 논문이 스스로 상세히 적어 뒀습니다. 첫째, 버티컬 팩(B)과 채점 규칙이 같은 17개 과제를 두고 함께 만들어졌습니다 — 별도의 held-out 과제로 확인하지 않았으므로 정확도 격차 일부는 "과제에 맞춰 설계한 툴"의 효과일 수 있습니다. 둘째, Sakila는 6개 테이블 DDL이 컨텍스트에 통째로 들어가는 작은 스키마라 오히려 원시 SQL(A)에 유리한 조건이며, DDL이 컨텍스트에 안 들어가는 실제 기업 스키마에서는 격차가 더 벌어질 것으로 저자는 예상하지만 검증하지는 않았습니다. 셋째, 로컬 3B~8B 모델·고정 디코딩(온도 0) 조건만 다뤄, 프런티어 클라우드 모델에서 원시 SQL과의 격차가 줄어들지는 미검증입니다. 넷째, 저자가 벤치마크에서 가장 앞선 설계(B)의 참조 구현체 개발자 본인이라는 이해상충이 있습니다. 상반된 시각으로는, 텍스트-투-SQL 계열 연구(Spider·BIRD·DIN-SQL 등)는 SQL 생성 품질 자체를 높이는 방향을 취하는데, 이 논문은 그 생성 단계를 서빙 경로에서 아예 제거하는 상반된 접근을 취합니다 — 논문은 이를 경쟁이 아니라 상호보완으로 규정합니다.

리뷰어 판단

첫째, 이 논문에서 실무적으로 가장 무거운 결과는 0.939라는 최고점이 아니라 제네릭 팩(C)이 원시 SQL(A)보다도 낮은 0.605에 머물렀다는 사실이라고 판단합니다. "MCP 툴로 감쌌으니 안전해졌다"는 가정이 이 벤치마크에서는 성립하지 않았고, 툴 존재 여부와 툴 설계 품질을 같은 것으로 취급하면 오히려 퇴보할 수 있다는 경고로 읽힙니다.

둘째, Model Demotion을 비용 절감 전략으로만 읽는 것은 이 결과를 과소평가한다고 봅니다. 정답당 비용이 최대 11.6배 줄었다는 것은 단순히 "더 싼 모델을 쓸 수 있다"가 아니라, 도메인 규칙을 서버 SQL로 한 번 캡슐화해 두면 그 이후 모든 요청에서 모델이 반복적으로 스키마를 이해하고 조인을 재구성하는 비용 자체가 사라진다는 뜻입니다. 사람이 데이터를 볼 때마다 스키마를 새로 설명해야 하는 조직이라면, 이 재사용 효과가 모델 등급을 낮추는 것보다 더 큰 레버일 수 있습니다.

셋째, task-aligned scoring 한계는 저자가 스스로 밝힌 만큼 진지하게 받아들여야 한다고 봅니다. 17개 과제 안에서 툴과 채점 기준을 함께 설계했으므로, 0.939를 새로운 미지의 요청에도 그대로 적용되는 상한으로 오독하면 안 됩니다. 실무에 옮길 때는 "우리 도메인의 실제 반복 질문을 얼마나 잘 커버했는가"를 별도로 측정해야, 이 논문의 격차가 재현될지 판단할 수 있습니다.

실무 적용

• 반복 질문부터 툴로 캡슐화 — 사용자가 실제로 반복해서 묻는 질문(고객 조회, 대여 이력, 재고 확인 등)을 먼저 목록화하고, 그 질문에 맞춰 조인·비즈니스 규칙을 서버 SQL에 미리 박아 둔 도메인 툴부터 만듭니다.
• 툴 설계를 API 계약처럼 다루기 — 파라미터는 사람이 읽을 수 있는 이름으로, 설명은 라우팅 신호로 기능하도록 공들여 씁니다. C의 실패는 "툴이 있다"와 "툴이 잘 설계됐다"가 다르다는 것을 보여 줍니다.
• 도구 존재와 도구 설계를 분리해 검증 — 새 MCP 서버를 배포하기 전, 얕은 제네릭 팩이 원시 SQL보다 나은지부터 자체 데이터로 확인합니다. 나쁜 툴은 툴이 없는 것보다 나쁠 수 있습니다.
• 커버 밖 요청에는 탈출구를 남기기 — 예외적 질문은 도메인 엔지니어가 검토해 새 YAML/SQL 정의를 커밋하는 사람 개입 경로로 흡수하고, 기본 경로는 원시 SQL로 되돌리지 않습니다.
• 정답당 비용으로 모델 등급 재검토 — 셀당 토큰이 아니라 정답당 토큰·지연으로 비교해, 도메인 툴 도입 후 실제로 더 작은 모델로 내려도 되는 구간이 있는지 자체 트래픽으로 측정합니다.

결론

이 논문의 실질적 기여는 새로운 SQL 생성 기법이 아니라, MCP 서버에서 "툴을 노출한다"와 "툴을 잘 설계한다"가 전혀 다른 결과를 낳는다는 것을 수치로 보인 데 있습니다. 잘 설계한 도메인 툴 팩은 정확도 0.939·정답당 비용 최대 11.6배 절감이라는 이득을 냈지만, 설계가 얕은 제네릭 팩은 원시 SQL보다도 낮은 0.605에 머물렀습니다. 다만 툴과 채점 기준이 같은 17개 과제 안에서 함께 만들어졌다는 점, 작은 스키마·로컬 소형 모델만 다뤘다는 점, 저자가 비교 대상 도구의 개발자 본인이라는 점은 그대로 남는 한계입니다. MCP 툴 설계의 세부 스키마 원칙은 검색이 함수 호출이 될 때: Vectorize를 MCP 툴로 감싸는 설계 가이드에서 이어집니다.

참고 링크

• From SQL Generation to Tool Selection: A Domain-Oriented Pattern for MCP Servers — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용(스냅숏 경유)
• 검색이 함수 호출이 될 때: Vectorize를 MCP 툴로 감싸는 설계·실패·운영 기준 — sunny34.com 블로그