🤖 AI

OR-Space: A Full-Lifecycle Workspace Benchmark for Industrial Optimization Agents

본 논문은 기존 일회성 문제 정의 평가를 넘어, 지속적이고 다중 산출물 환경 내에서 모델 구축, 수정, 그리고 근거 기반 설명을 포함하는 현실적인 다단계 과제를 수행하는 산업 최적화 에이전트를 평가하도록 설계된 전체 수명 주기 워크스페이스 벤치마크인 OR-Space 를 소개합니다.

원저자: Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

게시일 2026-05-28

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

새로운 공장을 운영하기 위해 천재적인 새로운 비서를 고용한다고 상상해 보세요. 그들이 단순히 그 일에 대해 이야기하는 것이 아니라, 실제로 그 일을 해낼 수 있는지 확인하고 싶을 것입니다.

오랫동안 우리는 이러한 AI 비서들 ( "LLM 에이전트"라고 함) 을 테스트하는 방식을 완벽하게 작성된 레시피 카드를 주는 것과 같았습니다. 그 카드에는 다음과 같이 적혀 있었습니다. "여기는 문제, 여기는 재료, 여기는 수학 공식입니다. 이제 이를 해결하는 코드를 작성하세요."

AI 가 코드를 올바르게 작성하면 금색 스타를 주었습니다. 하지만 현실 세계에서는 공장 관리자들이 완벽한 레시피 카드를 받지 못합니다. 대신 그들은 스티키 노트가 붙어 있고, 스프레드시트가 있으며, 작년의 오래된 코드가 있고, 상사가 "아, 참, 다음 달 규칙을 바꿔야 합니다"라고 말하는 이메일이 쌓인 지저분한 책상을 마주하게 됩니다.

OR-Space는 AI 가 그 지저분하고 현실적인 책상을 다룰 수 있는지 확인하도록 설계된 새롭고 훨씬 더 어려운 테스트입니다.

AI 를 테스트하는 세 가지 방법

이 논문은 OR-Space(Operations Research Space)라는 벤치마크를 소개합니다. 단일 질문 대신, 전체 "작업 공간"(파일로 구성된 디지털 폴더) 을 AI 에게 제공하고 실제 공장에서 발생하는 세 가지 다른 유형의 업무를 수행하도록 요청합니다.

구축 (건축가):
- 상황: AI 에게 비즈니스 메모, 숫자가 적힌 스프레드시트, 그리고 빈 코드 파일이 담긴 폴더를 건넵니다.
- 작업: AI 는 메모를 읽고 숫자의 의미를 파악한 뒤, 공장의 문제를 해결하기 위해 처음부터 새로운 컴퓨터 프로그램을 작성해야 합니다.
- 주의할 점: 메모는 모호할 수 있고, 스프레드시트의 열은 지저분할 수 있습니다. AI 는 완벽한 가이드 없이 텍스트와 데이터 사이의 연결고리를 찾아야 합니다.
수정 (수리공):
- 상황: 공장이 마음을 바꿨습니다. 아마도 트럭이 더 생겼거나 안전에 대한 새로운 규칙이 생겼을 것입니다. AI 에게는 이전 프로그램과 새로운 규칙이 제공됩니다.
- 작업: AI 는 이미 작동하던 부분을 망치지 않으면서 새로운 규칙에 맞춰 이전 코드를 업데이트해야 합니다.
- 주의할 점: 이는 사람들이 여전히 살고 있는 집을 리모델링하는 것과 같습니다. AI 가 더 이상 의미가 없는 변수 이름을 이전 코드에서 복사해 오면 전체 시스템이 충돌합니다. 논문은 일부 AI 들이 이전 코드로 혼란을 겪으며 실수를 그대로 복사하려는 반면, 더 똑똑한 AI 들은 무엇을 유지하고 무엇을 버려야 할지 안다고 밝혔습니다.
설명 (번역가):
- 상황: 컴퓨터가 문제를 해결했지만, 수학 전문가가 아닌 공장 관리자가 "왜 남쪽 창고 대신 북쪽 창고로 트럭 5 대를 보냈다고 결정했나요?"라고 묻습니다.
- 작업: AI 는 해결책, 코드, 그리고 데이터 로그를 검토하여 진실된 답변을 제시해야 합니다.
- 주의할 점: AI 는 임의로 이야기를 지어낼 수 없습니다. 그 결정을 강제했던 스프레드시트의 특정 줄이나 코드의 특정 규칙을 지적해야 합니다. 만약 추측하면 감점됩니다.

이 테스트가 다른 이유 ("작업 공간" 대 "프롬프트")

저자들은 이전 테스트들은 플래시카드와 같다고 주장합니다. AI 에게 깔끔하고 분리된 문제를 보여주면 답을 내놓는 방식입니다.

OR-Space 는 실제 사무실과 같습니다.

파일은 분리되어 있습니다: 요구사항은 Word 문서에, 숫자는 CSV 파일에, 코드는 Python 파일에 있습니다. AI 는 이 모든 파일을 열고 읽으며 어떻게 서로 연결되는지 파악해야 합니다.
"그라운딩" 문제: 플래시카드 테스트에서는 AI 가 단어를 인식하기 때문에 정답을 추측할 수 있습니다. 하지만 OR-Space 에서는 AI 가 메모의 "용량 (capacity)"이라는 단어를 스프레드시트의 "최대 적재량 (max_load)"이라는 열과 올바르게 연결하지 못하면 실패합니다. 논문은 이를 "그라운딩 (grounding)"이라고 부르며, 단어를 실제 데이터에 연결하는 것을 의미합니다.

그들이 발견한 것 (결과)

연구진은 이 새로운 테스트에서 이용 가능한 "가장 똑똑한" 20 개의 서로 다른 AI 모델을 테스트했습니다. 결과는 다음과 같습니다.

보여지는 것보다 어렵습니다: 최고의 AI 들조차 어려움을 겪었습니다. 일부는 문제의 "플래시카드" 버전은 해결할 수 있었지만, 지저분한 파일 폴더를 탐색해야 할 때는 종종 실패했습니다.
오래된 코드는 양날의 검입니다: AI 가 모델을 수정하는 데 도움이 되도록 이전 코드를 제공받았을 때, 가장 똑똑한 AI 들은 이전 코드를 유용한 힌트로 활용하여 더 좋아졌습니다. 하지만 약한 AI 들은 이전 코드의 실수를 맹목적으로 복사 (더 이상 존재하지 않는 변수를 사용하려는 시도 등) 하여 더 나빠졌습니다.
"설명" 격차: 일부 AI 는 코드 작성에는 뛰어나지만 설명에는 형편없었습니다. 그들은 수학을 풀 수는 있었지만, 가지고 있던 파일들을 바탕으로 그 선택을 왜 했는지 설명할 수는 없었습니다.
"파일 시스템" 페널티: 논문은 AI 들이 실제로 폴더를 탐색하고 파일을 읽어야 할 때 ("파일시스템" 모드), 동일한 정보가 하나의 거대한 텍스트 블록에 붙여넣어졌을 때보다 성능이 떨어졌음을 발견했습니다. 이는 정보를 찾고 조직화하는 것 자체가 단순한 포맷팅 문제가 아닌 하나의 기술임을 증명합니다.

결론

이 논문은 AI 를 완벽한 프롬프트에서 코드를 얼마나 잘 작성하는지로만 테스트해서는 안 된다고 결론 내립니다. 물류, 제조, 금융과 같은 실제 산업에서 유용하려면 AI 는 다음 능력을 테스트받아야 합니다.

지저분한 문서 더미에서 올바른 정보를 찾아내는 능력.
기존 시스템을 망치지 않고 업데이트하는 능력.
지어낸 이야기가 아닌 실제 파일의 증거를 바탕으로 결정을 설명하는 능력.

OR-Space 는 이러한 AI 에이전트들을 위한 새로운 "운전 면허 시험"으로, 그들을 주차장 (완벽한 프롬프트) 에서 번잡한 도시 거리 (실제 작업 공간) 로 이동시키는 역할을 합니다.

기술 요약: OR-Space

문제 제기

운영 연구 (OR) 분야의 대규모 언어 모델 (LLM) 에이전트에 대한 기존 벤치마크는 실제 산업 워크플로우의 복잡성을 대폭 추상화해 왔습니다. 현재의 평가 방식은 OR 작업을 "원샷(one-shot)" 문제로 축소하여, 에이전트가 자체적으로 완결된 텍스트 프롬프트를 수학 모델링이나 솔버 코드 형태로 변환하는 데 중점을 둡니다. 이 접근법은 산업용 OR 의 두 가지 결정적 특성을 포착하지 못합니다:

작업 공간 설정: 실제 세계의 에이전트는 비즈니스 요구사항, 구조화된 데이터 (CSV/JSON), 코드 산출물, 솔버 피드백, 그리고 여러 파일에 분산된 이해관계자 상호작용을 포함하는 지속적이고 다중 산출물 환경 내에서 작동합니다.
수명 주기 설정: 산업용 OR 는 반복적입니다. 엔지니어는 단순히 한 번 솔루션을 생성하는 것이 아니라, 초기 모델을 구축하고 변경된 비즈니스 규칙이나 솔버 피드백에 따라 이를 수정하며, 최종 의사결정을 비전문가 이해관계자에게 설명합니다.

결과적으로, 현재 벤치마크는 에이전트가 다중 산출물 작업 공간과 모델링 수명 주기의 여러 단계를 거쳐 신뢰할 수 있는 최적화 작업을 수행할 수 있는지 여부를 판단할 수 없습니다.

방법론

저자들은 산업용 최적화 에이전트를 평가하기 위해 설계된 전체 수명 주기 작업 공간 벤치마크인 OR-Space를 소개합니다. 이 방법론은 지속 가능한 실행 가능한 작업 공간과 수명 주기 중심 작업 파이프라인이라는 두 가지 핵심 축을 중심으로 구성됩니다.

1. OR 작업 공간 형식화

OR 작업 공간 ( $W$ ) 은 구조화되고 지속 가능하며 실행 가능한 환경으로 정의됩니다:
$W = \langle D, P, S, E, M \rangle$

$D$ (문서): 목표와 요구사항을 설명하는 자연어 산출물 (예: business_requirement.md).
$P$ (파라미터): 정제 및 스키마 정렬이 필요한 경우가 많은 수치 입력을 포함하는 구조화된 데이터 파일 (CSV, JSON).
$S$ (코드): 휴리스틱 스크립트, 부분 템플릿, 또는 레거시 구현을 포함한 코드 산출물.
$E$ (환경): 파일 입출력, 솔버 실행 (Gurobi, COPT, PuLP, HiGHS), 그리고 리소스 제약을 지원하는 Docker 기반 샌드박스.
$M$ (지표): 벤치마크 하네스에 의해 사용되는 평가 지표 (에이전트에게는 숨겨짐).

모든 컨텍스트를 단일 프롬프트로 직렬화하는 이전 벤치마크와 달리, OR-Space 는 에이전트가 이러한 분산된 산출물 간에 정보를 찾아내고 연결하며 근거를 마련하도록 요구합니다.

2. 수명 주기 중심 작업 모드

OR-Space 는 IndustryOR 벤치마크에서 확장된 100 개의 기본 문제에서 파생된 세 가지 순차적 작업 모드를 정의합니다:

구축 ( $T_{Build}$ ): 에이전트는 비즈니스 문서와 데이터 파일을 사용하여 빈 코드 발판에서 솔버 준비가 된 최적화 모델을 처음부터 구축합니다.
수정 ( $T_{Revise}$ ): 에이전트는 업데이트된 요구사항 하에서 기존 최적화 워크플로우를 수정합니다. 여기에는 Revise-code(레거시 코드 수정), Revise-model(수식만 수정), Revise-all과 같은 변형이 포함됩니다. 에이전트는 새로운 제약 조건이나 변수를 통합하면서도 유효한 이전 논리를 유지해야 합니다.
설명 ( $T_{Explain}$ ): 에이전트는 문서, 데이터, 코드, 솔버 출력 (예: 듀얼 변수, 슬랙 값) 에 분산된 증거를 활용하여 솔루션, 제약 조건, 비즈니스 영향에 대한 근거 있는 질문에 답변합니다.

3. 평가 프로토콜

구축 및 수정: 솔버 점수 기반 지표로 평가됩니다. 제출물이 오류 없이 실행되고 "Optimal" 상태를 반환하며, 기준 참값 오라클에 대해 상대적 목적 함수 오차가 $\le 1\%$ 일 경우 정답으로 간주됩니다.
설명: 근거 기반 "LLM-as-judge" 평가 기준에 따라 평가됩니다. 점수는 정밀 커버리지 (35%), 추론 (35%), 근거 (20%), 답변 품질 (10%), 그리고 할루시네이션 패널티 (최대 -12) 를 기반으로 산정됩니다.
실패 분석: 이 프레임워크는 실행 오류, 실행 불가능한 수식, 잘못된 목적 함수, 그리고 부실한 설명을 포함한 구체적인 실패 모드를 기록합니다.

주요 기여

한계점 식별: 본 논문은 기존 OR 벤치마크가 자체 완결형 작업 공간 설정과 원샷 작업 설정에 시달리고 있어, 실제 산업 워크플로우의 다중 산출물 및 수명 주기 중심 특성을 과소평가하고 있음을 지적합니다.
OR-Space 벤치마크: 요구사항, 데이터, 코드, 솔버 출력이 여러 파일에 분산된 지속 가능한 실행 가능한 작업 공간을 중심으로 구축된 새로운 벤치마크입니다.
작업 모드: 모델 구축, 유지 관리, 의사소통을 포착하는 세 가지 수명 주기 중심 모드 (구축, 수정, 설명) 의 정의.
평가 프레임워크: 데이터 근거, 수정 일관성, 설명 충실성을 포함한 작업 공간 기반 작업에서 에이전트의 능력과 실패 모드를 분석하기 위한 프로토콜.

결과

저자들은 벤치마크를 통해 20 개의 모델 (폐쇄형 최첨단 모델, 소형 API 기반 모델, 오픈소스 모델) 을 평가했습니다. 주요 발견 사항은 다음과 같습니다:

작업 공간 근거는 어렵습니다: 최첨단 에이전트조차 작업 공간 기반 모델 구축에 어려움을 겪습니다. 최고 구축 점수는 72.0%(gemini-3.1-pro) 였으며, 대부분의 최첨단 모델은 53~68% 범위에 머물렀습니다. 이는 정제된 프롬프트에 비해 분산된 산출물에서 데이터 스키마와 비즈니스 의미를 복원하는 것이 얼마나 어려운지를 보여줍니다.
레거시 코드는 신호이자 잡음입니다: Revise 작업에서 강력한 모델 (예: gpt-5.4, claude-opus-4-6) 은 레거시 코드를 신호로 활용하여 성능을 개선하는 경우가 많았습니다 (예: gpt-5.4는 59% 에서 79% 로 향상). 반면, 약한 모델이나 "플래시" 모델은 성능이 급격히 하락하는 경우가 많았습니다 (예: gemini-3-flash는 23% 포인트 하락). 이는 이러한 모델들이 구현 세부사항을 잡음으로 취급하거나 솔버가 아닌 임포트를 복사했음을 시사합니다.
설명 가능성은 별개입니다: Explain 성능은 Build 및 Revise 점수와 약하게 상관관계 ( $r \approx 0.16-0.28$ ) 를 보였습니다. 실행 가능한 모델을 구축한 일부 모델은 이를 충실하게 설명하지 못했습니다 (예: gemini-2.5-pro는 수정 인스턴스의 69% 를 해결했지만, 설명 점수는 32.2 에 불과했습니다).
인터페이스 영향: 파일 시스템 인터페이스를 사용하는 것 (플랫 프롬프트 직렬화 대비) 은 일반적으로 코드 생성 작업 (구축 및 수정) 에서 성능을 각각 평균 8.2 및 12.2% 포인트 감소시켰습니다. 이는 파일 탐색과 스키마 검사가 외형적인 문제가 아닌 실질적인 어려움임을 나타냅니다.
컨텍스트 민감성: 코드 컨텍스트에 공식 수식을 추가하는 것은 강력한 모델에는 일반적으로 도움이 되었지만 경량 모델에는 해로울 수 있었습니다. 수식 전용 컨텍스트는 코드 기반 컨텍스트보다 더 취약한 것으로 나타났습니다.

중요성과 주장

본 논문은 OR-Space 를 고립된 텍스트 생성에서 견고하고 솔버 기반의 엔지니어링 워크플로우로 평가 패러다임을 전환하는 필수적인 변화로 위치시킵니다. 저자들은 다음과 같이 주장합니다:

신뢰성 격차: 개방형 다중 산출물 작업 공간을 탐색하는 것은 현재 LLM 에이전트에게 매우 어려운 과제로 남아 있으며, 텍스트 전용 벤치마크가 대부분 숨겨온 데이터 매핑 및 제약 조건 근거에서의 체계적 실패를 노출시킵니다.
실용적 준비도: OR-Space 는 산업용 OR 의 반복적이고 다단계적인 특성을 시뮬레이션함으로써 최적화 에이전트의 실용적 준비도를 측정하기 위한 엄격한 기반을 제공합니다.
실패 모드: 이 벤치마크는 수학적 모델링 오류, 데이터 근거 오류, 그리고 할루시네이션된 제약 조건을 구분하는 세밀한 실패 귀속을 가능하게 하여, 에이전트를 실제 환경에 배포하는 데 필수적입니다.

이 연구는 LLM 이 고립된 수식 생성 작업에서는 유망한 모습을 보이지만, 지속 가능한 작업 공간과 전체 수명 주기에 걸쳐 신뢰할 수 있는 OR 엔지니어링을 수행하는 능력은 현재 제한적이며, 에이전트 신뢰성, 실패 모드, 그리고 작업 공간 상호작용에 대한 추가 연구가 필요하다고 결론 내립니다.