📄 한국 공공 API 도구호출 벤치마크, 9B가 27B 따라잡았다

공공기관이 외부 AI를 못 쓰는 이유, 그리고 그 다음 문제

민원 데이터나 행정 정보를 다루는 기관은 외부 API에 데이터를 넘기기 어렵다. 데이터 주권 규제가 강해질수록 "우리 서버 안에서 도는 오픈소스 모델"에 대한 요구가 커지는 이유다. 그런데 여기서 잘 이야기되지 않는 두 번째 문제가 있다. 오픈소스 모델을 들여왔다고 끝이 아니라, 그 모델이 실제 정부 API를 여러 번 이어서 호출하는 일을 제대로 해내야 한다는 것이다. 2026년 9월 4일 arXiv에 공개된 KOPA-Bench 논문은 바로 이 지점을 다룬다.

무엇을 했는가

연구진은 두 가지를 내놓았다. 하나는 한국 공공 오픈 API를 기반으로 한 벤치마크이고, 다른 하나는 학습 데이터를 만드는 방법이다.

논문이 지적하는 출발점은 명확하다. 오픈소스 모델은 다단계 도구호출 환경에서 일관되게 성능이 뒤처지는데, 정작 그 격차를 재는 벤치마크가 없었다는 것이다. 측정 도구가 없으면 개선했는지도 알 수 없다.

EDGE는 어떻게 작동하는가

다단계 도구호출 학습 데이터를 만들 때 가장 흔한 방식은 큰 모델에게 "이런 시나리오를 지어내라"고 시키는 것이다. 문제는 그렇게 만든 시나리오가 실제로는 실행되지 않는 경우가 많다는 점이다. A라는 API의 출력 형식이 B라는 API의 입력 형식과 안 맞으면, 그럴듯해 보이는 학습 데이터가 사실은 거짓말이 된다.

EDGE는 순서를 뒤집는다. 먼저 각 도구의 출력이 다른 도구의 입력으로 들어갈 수 있는 관계를 그래프로 그린다. 그다음 그 연결을 실제 라이브 API에 호출해본다. 호출이 성공한 연결만 그래프에 남기고, 검증된 연결만 따라가며 다단계 경로를 만들어낸다. 그러니까 "될 것 같은 조합"이 아니라 "실제로 된 조합"만 학습 데이터가 된다. 이름에 들어간 '실행 기반(execution-grounded)'이 이 뜻이다.

그래서 진짜 의미하는 것

가장 많이 인용될 숫자는 "9B가 27B에 근접했다"일 것이다. 여기서 두 가지를 구분해서 읽어야 한다.

첫째, 이것은 9B 모델이 27B 모델보다 근본적으로 똑똑해졌다는 뜻이 아니다. 비교 대상은 같은 계열의 튜닝되지 않은 27B다. 즉 "제대로 만든 학습 데이터로 특정 작업에 맞춰 학습하면, 세 배 큰 범용 모델을 그 작업에서 따라잡을 수 있다"는 이야기다. 도메인이 좁고 도구 목록이 정해져 있는 공공 API 환경은 이 전략이 특히 잘 통하는 조건이다.

둘째, 그럼에도 이 결과는 실무적으로 크다. 온프레미스 도입에서 모델 크기는 곧 GPU 비용이고, 27B 대신 9B로 같은 일을 할 수 있다면 도입 문턱 자체가 달라진다. 게다가 개선이 KOPA-Bench 안에서만 나타난 것이 아니라 BFCL이라는 별도의 도구호출 벤치마크에서도 나타났다는 점은, 학습이 벤치마크에 과적합된 것만은 아니라는 신호다.

한계도 있다. 145개 과제는 실제 공공 API 생태계 전체에 비하면 작은 표본이고, 라이브 API에 의존하는 방식은 API 스펙이 바뀌면 데이터도 함께 낡는다. 또 논문은 벤치마크와 합성 방법을 제시한 것이지, 실제 기관에 배치해 운영한 결과를 보고한 것은 아니다.

마무리

한국어 AI 논의는 대체로 "모델이 한국어를 잘하느냐"에 머물러 왔다. 이 논문은 그다음 질문을 던진다. 한국어를 잘하는 것과 한국의 행정 시스템을 실제로 다룰 줄 아는 것은 다른 문제다. 공공 부문 AI 도입을 검토한다면, 모델 선택보다 먼저 봐야 할 것은 "우리 API를 대상으로 한 평가 기준이 있는가"일지 모른다.

출처: Dain Kim, Eungi Cho, Kyumin Kim, Shinyeong Noh, Kyuseong Lim, 「Multi-Step Tool-Calling over Korean Open Public APIs: A Benchmark and a Data-Synthesis Recipe」, arXiv:2609.05395, 2026년 9월 4일.