연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T01. LLM 에이전트 오케스트레이션과 하네스
이 주제만 보기- T01-13유사문제2025년 이후
Why Do Multi-Agent LLM Systems Fail?
한국어 검토 보기
해결 문제
- 에이전트를 여럿 붙여도 벤치마크 점수가 별로 안 오른다.
- 왜 실패하는지 정리된 분류가 없다.
핵심 구조
- 대표 프레임워크 7종에서 실행 기록을 대량 수집해 사람이 주석을 달았다.
- 실패 유형 14가지를 뽑아 3개 묶음으로 정리했다. 명세와 설계 문제, 에이전트 사이 어긋남, 과제 검증 실패.
- 주석 일치도를 통계로 검증하고 모델 자동 판정기를 만들어 대규모로 분류했다.
주요 결과
- 주석자 간 일치도 카파 0.88.
- 모델과 과제를 바꿔도 같은 실패 유형이 반복된다.
- 프롬프트만 손봐서는 안 되고 구조를 바꿔야 하는 실패가 상당수다.
한계
- 분류 체계라 해결책 자체는 아니다.
- 수집 시점의 프레임워크와 모델에 묶여 있다.
- 자동 판정기의 오분류 가능성이 남는다.
우리 기능과의 연결
- 제조 AI 분석과 업무 실행 에이전트를 여러 개로 묶을 때 생기는 실패를 미리 점검하는 문제와 같은 문제를 다룬다.
발표 표기 주의
- 본회의 포스터가 아니다. 데이터셋과 벤치마크 트랙의 spotlight다. 트랙 이름과 등급을 함께 적어야 맞다.
- arXiv abs 페이지 Comments에는 "ArXiv v3"만 있고 학회 표기가 없다. 학회 정보는 OpenReview에서 확인했다.
- 같은 논문이 NeurIPS 2025 LLM Evaluation 워크숍에도 포스터로 따로 올라와 있다. 대표 표기는 데이터셋과 벤치마크 트랙 쪽이다.
- T01-19유사문제2025년 이후
tau^2-Bench: Evaluating Conversational Agents in a Dual-Control Environment
한국어 검토 보기
해결 문제
- 앞선 tau-bench는 에이전트만 도구를 쓴다. 사용자는 말만 한다.
- 실제 상담은 다르다. 사용자도 자기 기기를 직접 만진다. 둘이 같은 환경을 함께 건드린다.
핵심 구조
- 통신사 상담을 무대로 삼는다. 에이전트와 사용자가 같은 환경을 함께 조작한다.
- 이 상황을 Dec-POMDP로 정의한다. 여러 주체가 각자 일부만 보면서 함께 결정하는 수학 모형이다.
- 부품을 조합해 과제를 여러 개 자동으로 만들어 내는 생성기를 붙인다.
- 사용자 모사기를 능력과 행동 제약으로 나눠 현실에 가깝게 만든다.
- 추론이 틀려서 실패한 경우와 상대와 손발이 안 맞아 실패한 경우를 나눠 본다.
주요 결과
- 에이전트 혼자 조작하는 조건에서 둘이 함께 조작하는 조건으로 바꾸면 성능이 크게 떨어진다.
- 사람과 환경을 나눠 쓰는 협업 자체가 별도의 어려움이라는 것을 수치로 보였다.
한계
- 통신 분야 하나에 집중해 다른 산업으로 그대로 옮기기 어렵다.
- 사용자를 모델이 연기하므로 실제 사람 행동과 차이가 있다.
- 최근 논문이라 외부 재현과 후속 검증이 아직 적다.
우리 기능과의 연결
- 현장 작업자와 에이전트가 같은 MES 화면을 동시에 만지는 상황을 재는 문제와 같은 문제를 다룬다.
제목 표기 주의
- 정본 제목은 그리스 문자를 쓴 τ^2-Bench다. 본문에서는 읽기 쉽게 tau^2-Bench로 적는다.
- 12번 tau-bench의 후속 연구다.
- T01-12유사문제2025년 이후
tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
한국어 검토 보기
해결 문제
- 기존 벤치마크는 사람과의 대화, 업무 규칙 준수를 재지 않는다.
- 한 번 성공한 것과 매번 성공하는 것을 구분하지 않는다.
핵심 구조
- 사용자 역할을 모델이 연기하게 하고 에이전트에게 도메인 API와 규정 문서를 준다.
- 대화가 끝난 뒤 데이터베이스 최종 상태를 정답 상태와 비교해 채점한다.
- 같은 과제를 여러 번 돌려 모두 성공한 비율을 재는 pass^k 지표를 제안한다.
주요 결과
- 최신 함수호출 에이전트도 과제 성공률 50% 미만.
- 같은 과제를 반복하면 일관성이 급격히 떨어진다.
한계
- 소매와 항공 두 분야 중심이라 산업 현장 규정과는 다르다.
- 사용자 역할을 모델이 연기해 실제 사람 행동과 차이가 있다.
- 최종 상태만 비교해 과정의 잘못은 잡지 못한다.
우리 기능과의 연결
- 업무 실행 에이전트가 사내 규정을 지키며 매번 같은 결과를 내는지 검증하는 문제와 같은 문제를 다룬다.
제목 표기 주의
- 정본 제목은 그리스 문자를 쓴 τ-bench다. 본문에서는 읽기 쉽게 tau-bench로 적는다.
- Sierra 연구팀이 낸 벤치마크다.
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 환경은 다루지 않는다.
우리 기능과의 연결
- 사내 도구를 늘려갈 때 어느 단계에서 먼저 막히는지 짚어보는 데 쓰는 지도다. 개별 기법을 고르기 전 전체 지형을 보는 용도다.
검토 메모
- 이 주제의 대표 서베이다. 개별 벤치마크 논문만 늘어놓으면 지형을 못 본다. 그래서 넣었다.
푸는 문제
- 도구 사용 연구가 몇 년 사이 폭발했다. 용어와 분류가 제각각이라 뭐가 뭔지 정리가 안 된다.
T05. 사람 검토와 승인 절차 (human in the loop, approval workflow)
이 주제만 보기- T05-21유사문제2025년 이후
Human-In-the-Loop Software Development Agents (HULA)
한국어 검토 보기
해결 문제
- 자동 코딩 에이전트가 끝까지 혼자 하면 결과를 믿기 어렵다. 사람이 중간에 계획과 코드를 손볼 수 있어야 한다.
핵심 구조
- 계획 수립, 코드 작성, 검토 단계로 나눈다. 각 단계 사이에 사람이 승인하거나 수정하는 지점을 둔다. Atlassian JIRA 안에 실제로 붙여서 운영했다.
주요 결과
- 실제 업무에 투입해 평가했다. 개발자들은 계획 초안 잡기와 단순 과제 코드 작성에서 시간과 노력이 줄었다고 봤다. 다만 코드 품질은 일부 사례에서 여전히 문제였다.
한계
- 한 회사 환경이다. 정량 지표보다 사용자 인식 조사 비중이 크다. 복잡한 과제에서는 효과가 약하다.
우리 기능과의 연결
- 업무 실행 에이전트를 단계로 쪼개고 단계마다 승인 지점을 두는 방식에 대한 유사문제다.
검토 메모
- 전체 저자: Wannita Takerngsaksiri, Jirat Pasuksmit, Patanamon Thongtanunam, Chakkrit Tantithamthavorn, Ruixiong Zhang, Fan Jiang, Jing Li, Evan Cook, Kun Chen, Ming Wu
T06. RAG, 지식그래프, 온톨로지, 출처 추적
이 주제만 보기- T06-14유사문제2025년 이후
Enhancing retrieval-augmented generation for interoperable industrial knowledge representation and inference toward cognitive digital twins
한국어 검토 보기
해결 문제
- 제조 데이터가 늘고 복잡해지면서 온톨로지, 지식그래프, 디지털 트윈만으로는 표현과 추론이 버겁다.
- 규칙 기반 추론은 확장이 어렵다.
한계
- 저널 원문이 구독 접근이라 이번 조사에서 실험 수치까지는 확인하지 못했다. 확인된 범위는 초록 수준 기여 내용까지다.
- AAS 표준에 맞춘 데이터가 있어야 적용된다.
아키텍처
- RAG를 두 방향으로 손봤다.
- 첫째, 자산관리쉘(AAS)을 인코딩해 RAG 안에서 지식 표현으로 쓴다.
- 둘째, 대조 선택 손실로 LLM을 미세조정해 RAG 안에서 추론에 쓴다.
- 목표는 인지형 디지털 트윈이다.
우리 회사와의 관계
- 설비 데이터 수집과 QFactory MES의 표준 정보 모델 위에 RAG를 얹는, 우리가 겪는 문제와 같은 문제를 다룬다.
T07. 구조화 출력, 스키마 검증, 문서 이해
이 주제만 보기- T07-11유사문제2025년 이후
JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models
JSONSchemaBench
한국어 검토 보기
해결 문제
- 구조화 출력 도구가 여럿인데, 무엇이 얼마나 잘 되는지 공정하게 비교할 기준이 없었다.
핵심 구조
- 실제 현장에서 쓰이는 JSON 스키마 1만 건을 모아 벤치마크를 만든다. 평가 축을 셋으로 나눈다. 형식을 지킨 출력을 얼마나 빨리 만드는가, 다양한 제약 종류를 얼마나 넓게 지원하는가, 나온 내용의 품질은 어떤가.
주요 결과
- Guidance, Outlines, llama.cpp, XGrammar, OpenAI, Gemini 등 6개 방식을 공식 JSON Schema 테스트 모음과 함께 비교했다. 각 방식이 지원하지 못하는 스키마 영역이 있음을 보였다.
한계
- 벤치마크 시점의 구현 기준이다. 도구가 빨리 바뀌어 수치는 금방 낡는다.
- 왜 우리와 관련 있나. 우리 스키마가 실제로 강제 가능한지, 어떤 엔진을 골라야 하는지 판단하는 평가 틀로 쓸 수 있다.
T08. OCR, VLM과 산업 현장 표시장치 판독
이 주제만 보기- T08-1유사문제2025년 이후
Do Vision-Language Models Measure Up? Benchmarking Visual Measurement Reading with MeasureBench
MeasureBench (계측기 판독 평가 묶음)
한국어 검토 보기
해결 문제
- 사람은 눈금과 바늘을 보면 값을 바로 읽는다. 요즘 시각언어모델은 이걸 잘 못 한다. 그 실력을 재는 잣대가 없었다.
핵심 구조
- 계측기 이미지와 질문을 짝지은 평가 묶음을 만들었다. 실제 사진과 합성 이미지를 같이 쓴다.
- 합성 쪽은 바늘 각도, 눈금, 조명을 바꿔가며 자동으로 찍어내는 생성 절차를 붙였다.
- 합성 데이터로 강화학습 미세조정도 해봤다.
주요 결과
- 가장 좋은 최신 모델도 계측기 판독에서 크게 헤맸다.
- 전형적인 실패는 바늘이나 눈금의 위치를 잘못 짚는 것이다. 글자와 숫자는 읽는데 지시 위치를 놓쳐서 값이 크게 틀린다.
- 합성 데이터 강화학습 미세조정은 합성과 실사진 양쪽에서 성능을 올렸다.
한계
- 평가 위주라서 현장 배치용 모델을 내놓은 건 아니다.
- 합성 이미지가 실제 공장의 먼지, 반사, 흔들림을 다 담지는 못한다.
우리 기능과의 연결
- 설비 데이터 수집에서 통신이 안 되는 아날로그 계기를 카메라로 읽어 값으로 바꾸는 일과 같은 문제다.
T12. 영상 이해와 근거 선택 (Vision-Language Model)
이 주제만 보기- T12-13유사문제2025년 이후
Video-MME: The First-Ever Comprehensive Evaluation Benchmark of Multi-modal LLMs in Video Analysis
한국어 검토 보기
핵심 구조
- 특징 네 가지를 내세운다. 영역 다양성(시각 영역 6개, 세부 분야 30개), 시간 길이 다양성(11초부터 1시간까지), 입력 다양성(프레임에 자막과 오디오까지), 사람 전문가 주석.
- 규모는 영상 900편, 총 254시간, 질의응답 쌍 2700개다. 모두 사람이 직접 붙였다.
주요 결과
- 상용 모델 중에서는 Gemini 1.5 Pro가 가장 좋았고 공개 모델을 크게 앞섰다.
- 영상이 길어질수록 성능이 떨어지는 공통 약점을 보였다.
- 자막과 오디오를 같이 넣으면 성능이 오른다는 점도 보였다.
한계
- 일반 영상 도메인이다. 제조 현장 영상은 포함되지 않는다.
- 객관식 평가라 근거 제시 능력은 직접 재지 않는다.
푸는 문제
- 영상용 멀티모달 LLM을 종합적으로 재는 자리가 없었다.
- 짧은 영상만 재거나, 영역이 한쪽에 치우친 데이터셋이 대부분이었다.
우리 기능과의 관계
- 긴 영상 이해 성능을 재는 최신 국제 기준이다. 후보 모델을 고를 때 비교 근거로 쓸 수 있다.
T16. 제조 지식그래프와 시맨틱 레이어
이 주제만 보기- T16-7유사문제2025년 이후
Fault Cause Identification across Manufacturing Lines through Ontology-Guided and Process-Aware FMEA Graph Learning with LLMs
한국어 검토 보기
해결 문제
- FMEA(고장 유형과 영향 분석) 문서는 라인마다 따로 쌓인다. 새 라인에서 고장이 나면 옛 문서를 재활용하기 어렵다.
핵심 구조
- OGPAL이라는 틀이다. 언어모델이 온톨로지를 길잡이 삼아 여러 라인의 FMEA 문서에서 정보를 뽑는다. 뽑은 걸 하나의 지식그래프로 합친다. 관계형 그래프 합성곱 신경망에 공정 순서를 반영한 점수 함수를 붙여, 링크 예측으로 고장 원인을 순위 매긴다.
주요 결과
- 자동차 압력 센서 조립 라인 사례에서 nDCG@20이 0.719였다. 검색 증강 생성 방식 0.450, 일반 관계형 그래프 신경망 0.559보다 높았다.
한계
- 한 도메인 사례 연구다. FMEA 문서 품질이 회사마다 달라 일반화가 불확실하다. 아직 학회 심사를 거친 정식 발표본은 아니다.
우리 기능과의 연결
- 제조 AI 분석에서 불량 원인을 과거 사례 문서로부터 순위 매겨 제시하는 문제와 유사하다.
T17. 자연어를 SQL로 바꾸기와 근거 기반 보고서 생성
이 주제만 보기- T17-5유사문제2025년 이후
Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows
Spider 2.0
한국어 검토 보기
해결 문제
- 실제 기업 업무는 질문 하나에 SQL 하나가 아니다. 여러 질의를 이어 붙이는 작업이다.
핵심 구조
- 실무 유래 문제 632개. 컬럼 1,000개 넘는 데이터베이스. BigQuery, Snowflake 같은 클라우드 환경.
- 모델이 메타데이터와 SQL 문서와 코드베이스를 뒤져야 푼다. 답이 100줄 넘는 경우도 있다.
주요 결과
- o1-preview 기반 코드 에이전트가 21.3%만 풀었다. 같은 모델이 Spider 1.0은 91.2%, BIRD는 73.0%였다.
한계
- 난이도가 높아 점수 차이로 세부 개선을 구분하기 어렵다. 클라우드 환경 의존이 커서 재현 비용이 든다.
우리 기능과의 연결
- 우리 AI 보고서와 업무 실행 에이전트도 질의 하나가 아니라 여러 단계 작업을 이어야 하므로 같은 난이도의 문제를 다룬다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기