연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T03. tool use, function calling과 MCP
- T03-13유사문제2025년 이후
Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions
한국어 검토 보기
핵심 구조
- MCP 서버 수명주기를 4단계 16개 활동으로 정리했다.
- 공격자를 4종류로 나누고 위협 시나리오 16개를 분류했다.
- 대표 위협은 도구 설명문 오염, 설치 프로그램 위장, 무단 접근, 갱신 시점에 몰래 바꾸기다.
- 실제 사례 연구로 위험을 검증했다.
- 단계별 대응책을 제시했다.
주요 결과
- 도구 설명문 자체가 공격 통로가 된다. 모델이 설명문을 그대로 믿기 때문이다.
- 서버 갱신 후 동작이 바뀌어도 사용자가 모른다.
- 현재 MCP 생태계에 인증, 서명, 감사 체계가 부족하다.
한계
- 정량 측정보다 분류와 사례 중심이다.
- MCP 사양이 빠르게 바뀌어서 특정 시점 분석이다. 이 논문이 다룬 시점 이후 사양이 두 번 더 바뀌었다.
- 제안한 대응책 대부분이 아직 구현 검증 전이다.
우리 기능과의 연결
- 업무 실행 에이전트가 외부 도구 서버를 붙일 때 생기는 보안 문제와 같다. 제조 현장 데이터에 접근하는 도구를 승인하고 감사하는 설계와 직결된다.
검토 메모
- 연도와 출처를 나눠 적어야 하는 항목이다. arXiv 등록은 2025-03-30이고 최신판이 2025-10-07(v3)이다. 학술지 정식 게재본은 ACM TOSEM이고 Crossref 등록 날짜가 2026-02-16이라 게재 연도는 2026이다. arXiv 초록 페이지에는 아직 학술지 표기(journal-ref)가 붙어 있지 않다. 그래서 DOI는 Crossref에서 따로 대조했다.
푸는 문제
- MCP는 새 표준이라 보안 분석이 없었다. 서버를 아무나 만들어 배포할 수 있는 구조라 공급망 위험이 크다.
- T03-12유사문제2025년 이후
The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models
한국어 검토 보기
핵심 구조
- 추상구문트리로 생성된 호출을 파싱해 비교한다. 문자열 비교가 아니다. 함수 수천 개까지 확장된다.
- 직렬 호출과 병렬 호출을 모두 잰다.
- 여러 프로그래밍 언어를 다룬다.
- 전문가가 만든 함수와 커뮤니티 기여 함수를 섞었다.
- 한 번짜리 호출 평가에서 여러 턴, 여러 단계 에이전트 평가로 범위를 넓혔다.
주요 결과
- 요즘 모델은 한 번짜리 호출은 잘한다.
- 기억, 상황에 따른 판단, 긴 호흡 추론은 여전히 약하다.
- 함수 호출 평가의 사실상 표준 자리를 잡았다.
한계
- 추상구문트리 비교는 인자 값의 의미까지는 못 본다.
- 리더보드 특성상 과적합 위험이 있다.
- 실행 결과보다 호출 형태 중심 평가 비중이 크다.
우리 기능과의 연결
- 우리 모델이 사내 함수를 정확히 부르는지 자동 채점하는 문제와 같다. 구문 트리 비교 방식은 사내 평가 자동화에 그대로 대응된다.
푸는 문제
- 함수 호출이 맞았는지 판정하기가 어렵다. 문자열이 달라도 의미가 같을 수 있다. 게다가 현실적인 함수 모음을 구하기도 어렵다.
- T03-9유사문제2025년 이후
Tool Learning with Foundation Models
한국어 검토 보기
핵심 구조
- 도구 학습을 두 갈래로 나눈다. 도구로 모델을 돕는 쪽(tool-augmented)과 모델로 도구를 부리는 쪽(tool-oriented)이다.
- 일반 절차를 네 단계로 정리한다. 의도 이해, 도구 이해, 계획과 추론, 도구 실행.
- 사람의 도구 사용에 대한 인지과학 논의를 끌어와 틀을 잡는다.
- 대표 도구 18종으로 실험을 돌려 비교한다.
- 남은 과제를 정리한다. 신뢰성, 도구를 새로 만드는 문제, 개인화, 안전성이다.
주요 결과
- 흩어져 있던 연구를 하나의 분류 체계로 묶었다.
- 도구 개수가 늘 때 계획 단계가 병목이 된다는 점을 공통 관찰로 짚었다.
- 도구 사용의 신뢰성 문제를 별도 항목으로 세웠다.
한계
- 서베이라 새 방법을 제안하지 않는다.
- 2023~2024년 기준이라 MCP 같은 표준화 흐름은 거의 안 다룬다.
- 실험 비교가 18종에 한정된다. 기업용 API 환경은 다루지 않는다.
우리 기능과의 연결
- 사내 도구를 늘려갈 때 어느 단계에서 먼저 막히는지 짚어보는 데 쓰는 지도다. 개별 기법을 고르기 전 전체 지형을 보는 용도다.
검토 메모
- 이 주제의 대표 서베이다. 개별 벤치마크 논문만 늘어놓으면 지형을 못 본다. 그래서 넣었다.
푸는 문제
- 도구 사용 연구가 몇 년 사이 폭발했다. 용어와 분류가 제각각이라 뭐가 뭔지 정리가 안 된다.
- T03-1구조대응
WebGPT: Browser-assisted question-answering with human feedback
한국어 검토 보기
핵심 구조
- GPT-3를 미세조정해서 텍스트 기반 웹 브라우저를 쓰게 만들었다.
- 브라우저 조작을 명령어 집합으로 정의했다. 검색, 링크 클릭, 스크롤, 인용 뜨기, 답 쓰기다.
- 사람이 실제로 브라우징하며 답을 만드는 시연을 모아 모방학습을 했다.
- 그 뒤 사람 선호 비교로 보상모델을 만들고 그걸로 최적화했다.
- 답을 쓸 때 근거 문단을 함께 모아 붙이게 했다.
주요 결과
- ELI5 데이터셋에서 최종 모델의 답이 사람 시연자의 답보다 56% 비율로 선호됐다.
- 레딧에서 가장 많은 표를 받은 답보다 69% 비율로 선호됐다.
- 근거를 함께 내놓게 해서 사람이 사실 여부를 확인할 길을 열었다.
한계
- 사람 시연과 사람 비교 라벨이 대량으로 필요하다. 비용이 크다.
- 브라우저 명령이 사람이 미리 짜둔 고정 집합이다.
- 사람이 선호하는 답과 진실인 답이 항상 같지는 않다.
- 웹 자체가 틀린 정보를 담고 있으면 그대로 인용한다.
우리 기능과의 연결
- 모델이 정해진 조작 명령으로 외부 시스템을 뒤져 근거를 모으고, 그 근거를 붙여 답을 쓰는 구조와 대응한다. AI 보고서에서 출처를 달아 쓰는 흐름과 같은 틀이다.
검토 메모
- 도구 사용 계보의 앞자리라 넣었다. 아래 MRKL(2022-05)보다 반년 앞선다.
푸는 문제
- 언어모델이 긴 답을 지어낸다. 근거를 못 댄다. 학습 시점 이후의 사실을 모른다. 사람이 답을 검증할 방법도 없다.
- T03-2구조대응
MRKL Systems: A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning
한국어 검토 보기
핵심 구조
- 모듈을 여러 개 붙인 구조다. 이름이 MRKL이다. 모듈형 추론, 지식, 언어의 앞글자다.
- 모듈은 두 종류다. 신경망 모듈(언어모델 포함)과 기호 모듈(계산기, 환율 변환, 데이터베이스 조회, 날씨 조회 같은 것)이다.
- 앞단에 라우터를 둔다. 라우터가 사용자의 자연어 입력을 읽고 어느 모듈로 넘길지 고른다.
- 언어모델은 자연어를 모듈이 알아듣는 입력으로 바꾸는 역할을 맡는다.
- AI21 Labs가 Jurassic-X라는 이름으로 실제 구현했다.
주요 결과
- 언어모델 하나를 키우는 대신 모듈을 붙여서 약점을 메우는 길을 제시했다.
- 계산 같은 작업은 언어모델이 직접 하지 말고 기호 모듈로 넘기는 게 낫다는 점을 정리했다.
- 지식을 갱신할 때 모델을 다시 학습하지 않고 모듈만 갈아 끼우면 된다는 점을 보였다.
한계
- 성능을 재는 표준 벤치마크가 없다. 구조 제안 성격의 논문이다.
- 라우터가 잘못 고르면 뒤가 다 틀린다. 라우팅 정확도가 병목이다.
- 모듈을 사람이 미리 정의해 붙여야 한다. 모듈이 늘면 관리가 어렵다.
- Jurassic-X가 닫힌 상용 시스템이라 외부 재현이 어렵다.
우리 기능과의 연결
- 사용자의 말 한마디를 받아 어느 사내 기능으로 넘길지 고르는 앞단 라우팅 구조와 대응한다. 여러 도구를 앞단 라우터로 갈라 보내는 방식의 기준선이다.
푸는 문제
- 언어모델 하나만으로는 못 하는 일이 있다. 최신 정보를 모른다. 회사 내부 자료를 모른다. 계산 같은 딱 떨어지는 추론을 못 한다. 새 정보를 넣으려면 다시 학습해야 해서 비용이 크다.
- T03-6유사문제
API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs
한국어 검토 보기
핵심 구조
- 실제로 실행되는 평가 환경을 만들었다. API 도구 73개다.
- 대화 314건, API 호출 753건을 사람이 라벨링했다.
- 능력을 세 가지로 나눠 잰다. 부를지 판단하기, 검색해서 고르기, 계획해서 여러 개 엮기.
- 학습셋은 1,000개 도메인, API 2,138개, 대화 1,888건이다.
- 이 학습셋으로 Alpaca 기반 Lynx를 학습시켰다.
주요 결과
- GPT-3.5가 GPT-3보다 도구 사용에서 낫다. GPT-4는 계획에서 특히 낫다.
- Lynx는 기반 모델 대비 26점 넘게 올랐다. 다만 GPT-4에는 못 미친다.
한계
- API 개수가 실제 기업 환경보다 적다.
- 합성 대화 위주라 실제 사용자의 애매한 말투를 덜 반영한다.
- 정답 호출과 문자열 비교에 가까운 평가라 다른 경로의 정답을 놓칠 수 있다.
우리 기능과의 연결
- 우리 사내 API를 모델이 제대로 고르고 부르는지 재는 사내 평가셋 설계 문제와 같다.
푸는 문제
- 도구를 붙인 모델이 실제로 얼마나 잘하는지 재는 기준이 없었다. 계획, 검색, 호출을 나눠서 재야 하는데 그런 척도가 없었다.
- T03-7구조대응
Gorilla: Large Language Model Connected with Massive APIs
한국어 검토 보기
핵심 구조
- LLaMA를 API 호출 생성에 맞춰 미세조정했다.
- 문서 검색기를 붙였다. 검색기가 최신 API 문서를 물어오면 모델이 그걸 보고 호출을 만든다.
- 검색기를 붙인 채로 학습한다. 그래서 검색 결과가 흔들려도 덜 무너진다.
- 평가용으로 APIBench를 만들었다. HuggingFace, TorchHub, TensorHub API 모음이다.
- 추상구문트리(AST, 코드를 나무 모양 구조로 바꾼 것)로 지어낸 호출을 잡아낸다.
주요 결과
- API 호출 작성에서 GPT-4를 앞섰다.
- 없는 함수를 지어내는 현상이 크게 줄었다.
- 문서가 바뀌어도 검색기만 갱신하면 따라간다.
한계
- 세 개 머신러닝 허브 API에 치우쳤다. 일반 기업 API는 덜 다룬다.
- 대체로 한 번 호출 기준이다. 여러 단계 대화는 약하다.
- 검색기 품질에 성능이 크게 묶인다.
우리 기능과의 연결
- QFactory MES 내부 함수 목록이 버전마다 바뀌는 상황에서, 문서 검색을 붙여 호출을 만드는 구조와 대응한다.
푸는 문제
- API 개수가 많아지면 모델이 없는 함수나 없는 인자를 지어낸다. API 문서는 계속 바뀌는데 학습한 모델은 옛날 버전에 묶인다.
- T03-8후보
ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs
한국어 검토 보기
핵심 구조
- ToolBench를 만들었다. 실제 API 16,464개, 49개 분류다.
- 명령문과 정답 경로를 ChatGPT로 자동 생성했다.
- 깊이우선탐색 기반 결정 트리를 쓴다. 한 경로가 막히면 되돌아가 다른 도구를 시도한다.
- ToolEval이라는 자동 평가기를 붙였다.
- 이 데이터로 LLaMA를 학습해 ToolLLaMA를 만들었다.
주요 결과
- ToolLLaMA가 ChatGPT에 준하는 도구 사용 성능을 냈다.
- 학습 때 못 본 API 목록에도 일반화됐다.
- 되돌아가기를 쓰는 탐색이 단순 연쇄 방식보다 통과율을 올렸다.
한계
- 정답을 ChatGPT로 만들어서 교사 모델의 편향과 오류가 그대로 섞인다.
- 외부 공개 API에는 죽어 있는 주소가 많다. 재현이 어렵다.
- 탐색 트리를 넓히면 호출 비용이 급증한다.
- 평가기 자체가 언어모델이라 판정이 흔들린다.
우리 기능과의 연결
- 도구 수백 개 규모에서 검색과 되돌아가기를 붙이는 방식이라, 사내 도구가 늘었을 때 적용 후보다.
검토 메모
- 연도가 헷갈리기 쉬운 항목이다. arXiv 등록은 2023-07-31이고 최신판이 2023-10-03이다. 2024는 ICLR 게재 연도다. arXiv 초록 페이지에는 학회 표기(journal-ref)가 붙어 있지 않다. ICLR 2024 게재는 DBLP 서지로 확인했다. OpenReview는 봇 확인 화면이 떠서 원문을 열지 못했다. 그래서 OpenReview 식별자는 적지 않는다.
푸는 문제
- 공개 모델은 도구 사용이 약하다. 학습 데이터가 없어서다. 게다가 실제 API는 수만 개고 서로 얽혀 있다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기