[arXiv 2605.11633] DORA: 재난 대응 에이전트를 위한 이종 지리공간 추론 벤치마크

Can LLM Agents Respond to Disasters? Benchmarking Heterogeneous Geospatial Reasoning in Emergency Operations

https://arxiv.org/abs/2605.11633

Junjue Wang, Weihao Xuan, Heli Qi, Pengyu Dai, Kunyi Liu, Hongruixuan Chen, Zhuo Zheng, Junshi Xia, Stefano Ermon, Naoto Yokoya | The University of Tokyo, RIKEN AIP, Waseda University, Stanford University | arXiv:2605.11633 | 2026년 5월

---

1. 서론: 재난 대응 에이전트가 어려운 이유

재난 대응은 단순한 이미지 분류 문제가 아니다. 허리케인, 지진, 홍수, 산불, 산사태, 폭발 같은 사건이 발생하면 현장 의사결정자는 위성영상의 피해 흔적, 도로망의 접근성, 병원과 대피소 같은 시설 위치, 시간에 따른 확산 양상, 최종 상황 보고서를 한꺼번에 다뤄야 한다. DORA는 바로 이 복합성을 LLM 에이전트 평가 문제로 끌어온 벤치마크다. 논문은 최신 모델이 원격탐사 이미지를 어느 정도 읽는지보다, 실제 운영 파이프라인을 따라 도구를 고르고 인자를 맞추며 중간 산출물을 다음 단계에 넘길 수 있는지를 묻는다.

이 문제 설정이 중요한 이유는 기존 에이전트 평가와 재난 원격탐사 평가가 서로 다른 구멍을 남겼기 때문이다. WebArena, OSWorld, AgentBench 같은 디지털 환경 벤치마크는 장기 도구 실행을 다루지만 지리공간 데이터의 해상도, 좌표계, 센서 종류, 피해 등급 의미론을 깊게 다루지 않는다. 반대로 xBD나 DisasterM3 같은 재난 데이터셋은 피해 탐지와 시각 질의응답에는 강하지만, 실제 구조·대피·보고 업무처럼 여러 도구를 이어 붙이는 장기 실행을 충분히 측정하지 못한다. DORA는 두 축을 결합해 재난 도메인 grounding과 도구 파이프라인 조합을 동시에 압박한다.

논문의 핵심 질문은 “LLM 에이전트가 재난 대응 업무에 바로 투입될 수 있는가”에 가깝다. 저자들은 45개의 실제 재난 사건에서 515개의 전문가 작성 태스크를 만들고, 108개 MCP 호환 지리공간 도구를 제공하며, 총 3,500단계의 gold tool-call trajectory를 검증한다. 에이전트는 단일 답변을 찍는 대신 segmentation, raster algebra, vector operation, shortest path, POI query, visualization, report generation 같은 도구를 선택하고, 이전 단계에서 나온 mask·polygon·route·scalar 값을 다음 단계 인자로 넘겨야 한다.

결론부터 보면 현재 모델은 이 과정을 안정적으로 버티지 못한다. 가장 높은 평균 최종 답변 정확도는 Gemini-3.0-Flash의 53.74%이고, 전문가 tool trajectory를 그대로 실행한 gold trajectory는 80.48%다. tool-free VLM baseline은 18%대에 머문다. 이 차이는 “비전 모델이 이미지를 못 본다”보다 더 구체적이다. 모델은 어떤 도구를 써야 하는지 어느 정도 짐작해도, tool order, file path, damage class index, GSD, 중간 raster/vector 참조를 정확히 맞추지 못하면서 최종 답변을 잃는다.

Figure 1: DORA의 대표 태스크 예시와 재난 운영 카테고리별 입력·도구 흐름

Figure 1은 DORA가 일반적인 벤치마크 질의와 얼마나 다른지를 보여 준다. 하나의 질문 안에 위성영상, 벡터 레이어, 피해 mask, 도로망, 시설 위치가 들어가고, 답은 “건물 몇 개” 같은 단일 숫자에서 끝나지 않고 지도·경로·보고서 형태로 확장된다. 이 그림은 DORA가 모델의 시각 인식만 보지 않고, 운영 목적을 도구 체인으로 번역하는 능력을 평가한다는 점을 가장 빠르게 설명한다. 각 예시가 요구하는 산출물도 숫자, 지도, 경로, 보고서로 달라져 단일 응답 능력과 구분된다.

1.1 DORA가 겨냥하는 평가 공백

DORA의 차별점은 평가 단위를 “완성된 답변”에만 두지 않는 데 있다. 실제 재난 대응에서는 결과 숫자만 맞아도 안심할 수 없다. 잘못된 damage mask를 만들고 우연히 면적이 비슷하게 나온 경우, 경로 탐색에는 성공했지만 폐쇄 도로를 반영하지 않은 경우, 보고서는 그럴듯하지만 출처가 잘못 연결된 경우가 모두 위험하다. 그래서 논문은 trajectory metric과 final answer metric을 함께 둔다. Tool-Any-Order는 필요한 도구 집합을 알았는지, Tool-In-Order는 순서를 얼마나 맞췄는지, Tool-Exact-Match는 앞부분 실행 prefix를 얼마나 유지했는지, Parameter Accuracy는 올바른 인자를 넣었는지를 본다.

이 설정은 블로그에서 이전에 다룬 Workspace-Bench와도 자연스럽게 연결된다. Workspace-Bench가 업무 파일 생태계에서 관련 파일 노드와 파일 간 관계를 맞히는지를 본다면, DORA는 원격탐사·GIS 데이터 생태계에서 raster, vector, temporal sequence, social geospatial layer의 관계를 맞히는지를 본다. 두 논문 모두 최종 자연어 답변보다 근거가 되는 실행 경로를 평가에 올려야 한다는 흐름에 있다. 다만 DORA는 파일 의존성 그래프 대신 tool-call trajectory와 공간 연산 결과를 중심 증거로 둔다.

이 논문을 읽을 때 특히 중요한 관찰은 “모델이 도구를 몰라서 실패한다”는 단순 설명이 부족하다는 점이다. Instruction-following 조건에서 gold tool order만 알려 주면 trajectory metric은 크게 오르지만 최종 답변은 1.08~4.40%p만 개선된다. 이는 에이전트 실패가 planning과 execution 사이의 어느 한 층에 국한되지 않는다는 뜻이다. 올바른 도구 순서를 알아도, 피해 등급 index를 binary mask로 바꾸는 과정, SAR와 optical input을 구분하는 과정, 이전 observation의 path를 다음 함수 인자로 넣는 과정에서 작은 오류가 누적된다.

2. 배경 및 관련 연구: 범용 에이전트와 재난 원격탐사의 간극

2.1 일반 LLM 에이전트 평가의 한계

최근 LLM 에이전트 연구는 reasoning과 execution을 닫힌 루프로 묶는 방향으로 빠르게 발전했다. ReAct는 생각과 행동을 번갈아 수행하는 기본 패턴을 만들었고, Reflexion은 실패 경험을 바탕으로 자기 수정을 시도하며, Plan-then-Execute는 실행 전에 계획을 분리한다. WebArena와 OSWorld는 웹과 데스크톱 환경에서 실행 신뢰성을 묻고, SWE-bench 계열은 소프트웨어 수정이라는 실사용 문제를 던진다. 그러나 이런 벤치마크는 대개 디지털 인터페이스의 상태 전이와 작업 지시를 중심으로 구성되어, 좌표계·해상도·센서 modality·공간 연산의 의미를 세밀하게 요구하지 않는다.

DORA가 일반 에이전트 벤치마크와 다른 지점은 tool action이 단순 API 호출을 넘어 도메인 지식이 박힌 분석 연산이라는 데 있다. 예를 들어 “피해가 심한 건물 주변 100m 안의 병원”을 찾으려면 building damage segmentation, class composition, raster-to-vector conversion, POI filtering, buffer, intersection을 연결해야 한다. 도구 이름을 맞히는 것만으로는 부족하고, 각 단계가 어떤 공간 객체를 만들어 내며 다음 단계가 어떤 객체 타입을 기대하는지 이해해야 한다. 이는 웹 버튼 클릭이나 SQL query generation보다 더 강한 typed execution 감각을 요구한다.

2.2 원격탐사 에이전트 평가의 발전과 남은 공백

원격탐사 쪽에서도 LLM을 분석 orchestrator로 쓰는 연구가 늘었다. RS-Agent, Change-Agent, GeoLLM-Engine, ThinkGeo, UniVEarth, Earth-Agent, OpenEarthAgent 같은 흐름은 위성영상과 지리공간 도구를 LLM이 호출하게 만든다. 이들은 이미지 해석, change detection, Google Earth Engine API 호출, multi-step geospatial reasoning을 다루지만, 재난 대응이라는 운영 맥락이 요구하는 장기 파이프라인과 책임 있는 의사결정까지 충분히 밀어붙이지는 못했다. DORA는 기존 재난 인식 데이터셋의 imagery를 활용하면서도 평가를 perception에서 operation으로 이동시킨다.

논문이 제시하는 비교표에서 DORA는 515개 태스크, 108개 도구, 8개 modality, 0.015~10m GSD, 1+2+N temporal 설정, 평균 6.8 step trajectory를 가진다. 이 숫자는 단순 규모 자랑을 넘어 평가 설계의 방향을 보여 준다. GAIA나 GTA처럼 일반 QA·도구 사용을 보는 벤치마크보다 재난 도메인성이 강하고, GeoLLM-Engine이나 Earth-Agent처럼 지리공간 도구를 다루는 벤치마크보다 재난 운영 단계와 시간 축을 더 넓게 포함한다. 특히 평균 step 수가 길고 tool modality가 넓기 때문에, 작은 argument error가 뒤 단계 전체를 망가뜨리는 상황을 노출한다.

Benchmark	Domain	#Tasks	#Tools	#Modality	GSD(m)	Temporal	Eval Level	Avg Steps
GAIA	General QA	466	-	2	-	-	Final	-
GTA	General tools	229	14	2	-	-	Step+Final	2.4
WebArena	Web navigation	812	-	2	-	-	Execution	-
GeoLLM-Engine	Geospatial	500K+	175+	1	0.5-30	1	Final	5.2
ThinkGeo	Remote sensing	486	14	2	0.1-30	1+2	Step+Final	3.6
Earth-Agent	Remote sensing	248	104	3	0.3-10	1+N	Step+Final	5.4
OpenEarthAgent	Remote sensing	1169	28	4	0.1-30	1+2	Step+Final	6.0
DORA	Disaster ops.	515	108	8	0.015-10	1+2+N	Step+Final	6.8

Table 1에서 가장 눈에 띄는 부분은 DORA가 remote sensing benchmark를 그대로 키운 형태와 다르다는 점이다. 태스크 수만 보면 OpenEarthAgent가 더 크지만, DORA는 재난 유형, 다중 센서, 시간 축, expert trajectory, final answer를 한 번에 묶는다. 그래서 이 표는 DORA의 위치를 “큰 데이터셋”보다 운영 파이프라인을 보존한 에이전트 평가로 읽게 만든다. 평균 6.8 step은 짧아 보일 수 있지만, 각 step이 raster/vector type과 실제 지리 좌표를 들고 움직이므로 일반 text tool benchmark의 6~7 step보다 훨씬 많은 암묵적 제약을 포함한다.

2.3 위키 흐름에서 보는 연결점

이 프로젝트 위키 기준으로 DORA는 provenance-aware agent evaluation, workspace agent benchmark, meta-cognitive tool use와 연결된다. Workspace-Bench가 “에이전트가 어떤 파일을 근거로 썼는가”를 묻는다면, DORA는 “에이전트가 어떤 geospatial artifact를 어떤 도구로 만들었는가”를 묻는다. Act Wisely 계열의 meta-cognitive tool use가 도구를 쓸지 말지 판단하는 능력을 다룬다면, DORA는 이미 도구를 써야 하는 상황에서 어떤 tool family와 argument schema를 선택하는지를 평가한다.

또 하나의 연결은 Shepherd 같은 runtime substrate 연구다. Shepherd가 typed effect stream을 기록해 meta-agent의 실행을 replay·fork·supervise하는 방향이라면, DORA의 gold trajectory는 재난 대응 tool stream의 정답 경로 역할을 한다. 둘 다 최종 텍스트를 넘어 실행 흔적을 평가 가능한 단위로 올린다. 다만 Shepherd는 에이전트 실행 인프라 자체를 개선하려는 논문이고, DORA는 특정 고위험 도메인에서 현재 에이전트가 얼마나 취약한지 측정하는 benchmark다.

3. 방법론: DORA 데이터셋과 108개 지리공간 도구

3.1 데이터 소스와 재난 사건 구성

DORA는 45개의 실제 재난 사건을 기반으로 한다. 저자들은 xBD의 고해상도 optical pre/post-disaster image pair, DisasterM3와 BRIGHT의 optical-SAR pair, NAIP와 Maxar Open Data Program의 flood progression 및 reconstruction sequence, Landslide4Sense와 GVLM-CD의 multi-spectral terrain scene, RescueNet과 CRASAR-U-DRoIDS의 aerial imagery, NASA ECOSTRESS 기반 thermal layer, OpenStreetMap의 road·POI·facility vector layer를 결합한다. 그 결과 2,850개 remote sensing image, 460개 vector layer, 10개 재난 유형, 5개 대륙 분포가 만들어진다.

이 데이터 구성이 중요한 까닭은 모델이 하나의 이미지 유형에 적응하는 것을 막기 때문이다. optical satellite image만 있으면 damage mask를 만드는 문제로 축소될 수 있지만, SAR가 들어오면 sensor interpretation이 달라지고, DEM·slope가 붙으면 지형 기반 위험 판단이 필요해지며, OSM road network와 POI가 붙으면 피해 인식이 구조·대피·시설 우선순위 문제로 변한다. DORA는 LLM 에이전트에게 “눈으로 보이는 것”과 “지도 위에서 계산해야 하는 것”을 함께 요구한다.

Figure 2: DORA의 데이터 소스, 재난 유형, 지역 분포, 이미지·벡터 레이어 규모

Figure 2는 DORA가 특정 지역이나 센서에 치우친 데이터셋이 아님을 보여 준다. 10개 공개 데이터베이스에서 optical, SAR, multi-spectral, DEM, slope, vector layer를 모으고, 45개 재난 사건을 여러 대륙에 배치한다. 이 다양성은 모델이 단순히 “홍수 사진을 보면 물 영역을 찾는다” 수준에서 멈추지 못하게 하고, 센서와 지리 레이어를 바꿔 가며 실행 계획을 세우도록 압박한다. 지역과 재난 유형이 넓어질수록 암기식 시각 패턴보다 도구 선택과 데이터 해석이 중요해진다.

3.2 태스크 형식: query, data, trajectory, answer

각 DORA 태스크는 네 요소로 정의된다. 자연어 질의 Q는 운영 필요를 표현하고, 데이터 manifest D는 raster와 vector 입력을 묶는다. 전문가가 검증한 tool-call trajectory T*는 tool name, purpose, argument를 순서대로 담고, 최종 answer A*는 scalar, string, point, line, polygon, dictionary, set 같은 typed field로 표현된다. 중요한 점은 trajectory가 단순한 참고 설명에 그치지 않고 replay 가능한 실행 단위라는 것이다. 이전 step의 observation은 다음 step의 symbolic reference가 되고, replay engine은 이를 실제 파일 경로와 수치로 해석한다.

이 구조는 benchmark의 신뢰도를 높인다. 사람이 자연어로만 “이런 과정을 거친다”고 적으면 평가자는 모델의 중간 과정을 정밀하게 비교하기 어렵다. DORA는 trajectory를 JSON meta file 안에 넣고, query·data·trajectory·answer를 서로 연결한다. 그래서 모델이 최종 면적 값만 비슷하게 맞췄는지, 아니면 올바른 mask를 만들고 vectorize한 뒤 polygon intersection을 수행했는지까지 확인할 수 있다. 이는 재난 대응처럼 설명 책임이 중요한 영역에서 특히 필요한 설계다.

Figure 3: DORA 샘플 JSON meta file의 구성: Q, D, T, A

Figure 3은 DORA 샘플이 query와 answer만 가진 데이터 포인트와 다르다는 점을 보여 준다. 데이터 manifest에는 입력 raster와 vector layer가 있고, trajectory에는 도구 호출 순서와 인자 의존성이 들어간다. 이 구조 덕분에 평가는 최종 문장만 채점하지 않고, 에이전트가 실제로 어떤 중간 객체를 만들었는지까지 따라갈 수 있다. 특히 이전 observation이 다음 tool argument로 이어지는 참조 관계를 보존해, 중간 단계의 작은 오류가 어디서 시작됐는지 추적할 수 있다.

3.3 다섯 가지 분석 차원

DORA의 515개 태스크는 다섯 분석 차원으로 나뉜다. T1은 Disaster Perception & Assessment로, 단일 또는 양시점 imagery에서 damaged area, building count, debris volume 같은 원자적 수치를 추출한다. T2는 Spatial Relational Analysis로, proximity, containment, overlay처럼 layer 간 공간 관계를 계산한다. T3는 Disaster Operational Planning으로, geospatial output을 구조 자원 배분, route planning, logistics estimate로 바꾼다. T4는 Temporal Evolution Reasoning으로, 3~5개 observation phase를 반복 분석해 변화 추세를 요약한다. T5는 Multi-modal Report Synthesis로, 앞 단계 결과와 visualization·summarization tool을 묶어 상황 보고서를 만든다.

이 taxonomy는 난이도를 한 줄로 세우지 않는다. T4는 trajectory가 길어도 같은 sub-pipeline을 여러 시점에 반복하는 구조라 모델이 비교적 규칙성을 잡을 수 있다. 반면 T5는 perception, vector analysis, visualization, summarization이 서로 다른 도구 범주를 오가며 연결되므로 이질성이 커진다. 논문은 그래서 raw length보다 tool heterogeneity가 중요한 실패 요인이라고 해석한다. 길고 규칙적인 반복보다 짧더라도 타입이 자주 바뀌는 체인이 더 위험할 수 있다는 점이 DORA의 실험에서 드러난다.

Figure 4: 515개 태스크의 분석 차원과 재난 유형 분포

Figure 4는 DORA가 특정 태스크 유형에 집중하지 않고, perception, spatial relation, operation planning, temporal reasoning, report synthesis를 함께 배치했음을 보여 준다. 안쪽 ring은 분석 차원, 바깥쪽 bar는 disaster type을 나타낸다. 이 분포는 모델이 하나의 피해 탐지 skill만으로 전체 benchmark를 통과하기 어렵게 만들며, 재난 대응 파이프라인 전체를 따라가야 한다는 평가 의도를 강화한다.

Figure 5: DORA 차원별 trajectory 길이와 도구 범주 분포

Figure 5는 DORA의 난이도가 단순히 태스크 수로 설명되지 않는다는 점을 보여 준다. T1은 평균 3.35 step 수준의 선형 perception chain에 가깝지만, T5는 평균 11.96 step으로 길고 tool category가 넓다. 특히 보고서 합성은 피해 mask, 공간 교차, 경로, 지도 렌더링, 텍스트 요약을 이어 붙이므로, 초반 argument 오류가 후반 narrative까지 전파된다. 그래서 이 그림은 DORA가 long-horizon agent 문제를 단순 step 수가 아니라 tool category 전환과 산출물 연결 문제로 본다는 점을 보여 준다.

3.4 MCP 도구 라이브러리

DORA의 tool library는 108개 MCP 호환 도구로 구성된다. Perception tool은 building damage, flood, road damage, landslide, lava, vehicle 같은 disaster-relevant object를 segmentation한다. Raster tool은 area, zonal statistics, threshold, windowing, vectorization을 담당한다. Vector tool은 buffer, intersection, connected component, POI query, graph routing을 수행한다. Logical tool은 loop와 reduce 같은 제어 흐름을 제공하고, Visualization tool은 damage map, route map, report page를 만든다. Summarization tool은 evidence extraction과 report rendering을 고정 backend로 처리한다.

Category	#	Scope	Representative Tools	Output	Implementation
Perception	31	재난 관련 객체 semantic segmentation	seg.building_damage, seg.flood, seg.road_damage	Raster mask	DinoV3, SegFormer, HRNet, SwinUperNet
Raster	18	Raster algebra와 변환	ras.area, ras.diff, ras.vectorize	scalar, polygon	GDAL, Rasterio
Vector	31	GIS operation, graph construction, POI query	vec.intersect, vec.shortest_path, poi.filter_by_damage	scalar, point, line, polygon	Shapely, NetworkX, GeoPandas
Logical	15	Control flow와 planning	logi.loop, logi.reduce	decision	Python
Visualization	11	Map rendering과 report layout	vis.damage_map, vis.route_map, vis.report_page	image	Matplotlib
Summarization	2	Evidence extraction과 rendering	m.extract_evidence, m.summarize	text	Fixed report backend

Table 2는 도구의 폭을 보여 준다. 여기서 눈여겨볼 점은 perception tool과 GIS tool이 분리되어 있다는 것이다. 많은 멀티모달 모델 평가는 이미지 속 객체를 맞히면 끝나지만, DORA에서는 segmentation 결과가 raster mask로 나오고, 이 mask를 vector polygon으로 변환한 뒤, 병원·도로·대피소 같은 social vector layer와 교차해야 한다. 즉 모델은 “무엇이 보이는가”에서 “그 산출물을 어떤 공간 객체로 다루는가”로 넘어가야 한다.

3.5 annotation pipeline

Annotation pipeline은 세 단계다. 첫째, 원격탐사와 재난 관리 배경을 가진 전문가가 scene과 data manifest를 보고 operational query와 symbolic tool trajectory를 작성한다. 둘째, deterministic replay engine이 symbolic reference를 실제 observation 값으로 해석해 gold annotation을 만든다. 셋째, AI-assisted evaluation이 typed answer와 trajectory를 기준으로 모델 출력과 gold를 비교한다. 이 방식은 사람이 쓴 trajectory의 의미론과 실제 계산 결과의 수치 grounding을 함께 확보하려는 절충이다.

Figure 6: 전문가 query 작성, deterministic replay, AI-assisted evaluation으로 이어지는 annotation pipeline

Figure 6은 DORA가 LLM으로 질의를 대량 생성한 benchmark와 다른 지점을 보여 준다. 전문가는 query와 symbolic trajectory를 만들고, replay engine은 그 trajectory를 실제 데이터 위에서 실행 가능한 gold annotation으로 바꾼다. 이 덕분에 도구 호출 순서와 중간 관찰값이 평가 가능한 단위가 되며, 모델이 운 좋게 final answer를 맞히는 경우와 올바른 실행을 수행한 경우를 분리할 수 있다.

4. 실험 설정: 모델, 지표, 채점 규칙

4.1 평가 대상 모델

실험은 상용 모델과 공개 모델을 모두 포함한다. 상용 모델로는 GPT-5.4 계열, Claude-Sonnet-4.6, Gemini-3.0-Flash, Grok-4.1-Fast가 들어가고, 공개 모델로는 Qwen3.5 계열, MiMo-V2-Pro, Step-3.5-Flash, DeepSeek-V3.2, Gemma-4-31B, GPT-OSS-120B, MiniMax-M2.7이 들어간다. 추가로 Qwen3-VL-235B와 Gemini-3.0-Flash는 도구 없이 raw imagery와 question만 받는 tool-free baseline으로 평가된다. 이는 이미지 자체를 보는 능력과 tool-mediated geospatial reasoning 능력을 분리하기 위한 장치다.

모든 에이전트는 기본적으로 ReAct-style loop 아래 구현된다. 모델은 생각하고, 도구를 호출하고, observation을 받아 다음 행동을 정한다. 여기에 Plan-then-Execute, Reflexion, ReWOO 같은 scaffold를 추가 실험으로 비교한다. 중요한 설정은 gold trajectory도 완벽한 GT mask를 쓰지 않는다는 점이다. Gold trajectory는 전문가가 정한 도구 순서와 인자를 실행하지만, perception tool은 모델 기반 도구를 사용한다. 따라서 gold trajectory는 perfect oracle보다는 planning-and-argument oracle에 가깝다.

4.2 trajectory metric

Trajectory metric은 네 가지다. Tool-Any-Order는 gold trajectory에 있는 tool identifier를 순서와 무관하게 얼마나 회수했는지 본다. Tool-In-Order는 tool identifier의 longest common subsequence를 gold 길이로 나누어, 필요한 도구를 어느 정도 순서대로 불렀는지 본다. Tool-Exact-Match는 gold와 prefix가 얼마나 길게 일치하는지 측정해 초반부터 흔들리는지를 본다. Parameter Accuracy는 tool name이 맞은 step에 대해 argument가 맞았는지 평가한다. 이 네 지표를 함께 보면 도구 선택과 도구 사용을 분리할 수 있다.

DORA에서 Parameter Accuracy가 특히 중요하다. 재난 대응 도구는 인자가 조금만 틀려도 의미가 크게 바뀐다. 피해 class index 1,2,3을 모두 “affected”로 묶어야 하는데 3만 넣거나, 0.015m GSD 영상과 10m GSD 영상을 같은 면적 환산으로 다루거나, 이전 step의 mask_path 대신 원본 image_path를 넣으면 downstream output이 완전히 달라진다. 일반 tool-use benchmark에서는 argument mismatch가 단순 API 실패로 보일 수 있지만, DORA에서는 조용히 잘못된 지도와 보고서를 만든다.

4.3 final answer metric

Final answer는 typed field를 atomic scoring operator로 낮춰 채점한다. Scalar는 gold 값에 대한 20% 상대 오차 이내인지 본다. String은 normalization 후 exact match를 쓴다. Point는 20px 이내의 Euclidean distance gate를 사용하고, polygon은 IoU 0.5 이상을 통과 기준으로 둔다. Composite type은 dict, set, list, route 같은 구조를 atomic score 평균 또는 matching 방식으로 확장한다. 이렇게 설계한 이유는 DORA 답변이 단일 텍스트를 넘어 숫자, 위치, 영역, 경로, 보고서 요소가 섞인 structured JSON이기 때문이다.

Operator	Scoring rule	Parameter
scalar	예측값과 gold 값의 상대 오차가 20% 이내인지 평가	relative tolerance 0.2
string	정규화된 예측 문자열과 gold 문자열의 exact match	-
point	예측 좌표와 gold 좌표의 화면상 거리가 20px 이내인지 평가	20px gate
polygon	예측 polygon과 gold polygon의 IoU가 0.5 이상인지 평가	IoU 0.5
composite	dict, set, route 등은 atomic score를 field별로 확장해 평균	atomic rule 상속

Table 3의 채점 규칙은 엄격하면서도 재난 업무의 산출물 형태를 반영한다. 예를 들어 damaged area는 scalar tolerance가 필요하고, 피해 등급은 string match가 필요하며, 대피 지점이나 진앙 추정은 point metric이 맞고, flood boundary나 damage extent는 polygon IoU가 맞다. 이처럼 output type을 분리하지 않으면 모델이 숫자형 문제에서는 강하지만 공간 경계에서는 약한지, 반대로 위치는 대략 맞추지만 문자열 class를 틀리는지 파악하기 어렵다.

4.4 평가 차원의 운영적 의미

논문은 DORA를 단순 평균 점수표로만 보지 않는다. T1~T5 dimension, modality configuration, trajectory length bucket, protocol(AP vs IF), scaffold type별로 결과를 나눠 본다. 이 분해가 중요한 이유는 재난 대응 시스템에서 실패 원인이 서로 다르기 때문이다. 순수 optical damage assessment가 낮다면 perception tool과 class mapping을 의심해야 하고, OSM vector가 붙을 때 급락한다면 spatial relation과 POI grounding을 의심해야 한다. Gold order를 줬는데도 final answer가 거의 안 오르면 tool selection보다 argument grounding과 observation linking이 병목이다.

5. 주요 실험 결과: 최고 모델도 gold trajectory와 큰 간격이 남는다

5.1 전체 점수표

Table 4의 핵심 결과는 명확하다. 도구를 사용하지 않는 VLM baseline은 평균 18%대에 머물고, 도구를 사용하는 가장 강한 에이전트도 53.74%에 그친다. Gold trajectory는 80.48%이므로, 현재 frontier model은 재난 대응 tool library가 주어져도 전문가가 만든 실행 경로를 따라가는 것과 26%p 이상 차이가 난다. 이는 DORA가 단순히 모델에게 어려운 이미지를 던지는 benchmark에 머물지 않고, tool selection, ordering, argument, observation linking, final structured generation 전체를 흔드는 benchmark임을 보여 준다.

Model	AVG	T1 PA	T2 SR	T3 OP	T4 TE	T5 RS	T-Any-O	T-In-Ord	T-Exact-M	ParAcc	Eff.
Gold Trajectory	80.48	71.31	63.19	83.63	90.77	93.50	100	100	100	100	100
Gemini-3.0-Flash tool-free	18.55	5.98	19.91	17.48	29.36	20.03	-	-	-	-	single-step
Qwen3-VL-235B tool-free	18.30	5.53	28.63	12.63	27.75	16.95	-	-	-	-	single-step
Gemini-3.0-Flash	53.74	54.19	49.00	59.82	60.40	45.31	75.17	66.57	35.55	42.63	83.05
Grok-4.1-Fast	52.10	53.07	53.40	54.23	55.28	44.52	59.15	53.19	28.09	31.96	86.83
GPT-5.4	47.63	52.85	50.80	53.50	51.90	29.11	66.84	59.43	31.82	37.71	88.46
Claude-Sonnet-4.6	52.01	54.43	48.23	51.82	60.05	45.53	76.29	66.92	31.43	39.48	75.32
Qwen3.5-397B-A17B	53.45	51.03	53.40	51.82	61.83	49.17	75.44	66.97	32.13	36.50	76.54
Gemma-4-31B	51.17	51.46	49.00	52.33	61.03	42.03	69.89	62.58	32.82	38.23	86.43
MiMo-V2-Pro	52.89	53.68	47.43	55.48	63.58	44.26	74.05	67.13	34.26	38.45	79.11
DeepSeek-V3.2	48.23	49.80	49.15	50.57	50.62	41.01	74.26	65.99	30.39	34.69	72.44
GPT-OSS-120B	35.11	42.70	37.58	42.00	24.43	28.84	48.69	43.60	22.79	26.24	90.42

상용 모델과 공개 모델의 순위도 흥미롭다. Qwen3.5-397B-A17B는 53.45%로 Gemini-3.0-Flash와 0.3%p 차이까지 접근하고, MiMo-V2-Pro와 Gemma-4-31B도 51~53%대의 강한 두 번째 그룹을 만든다. 반면 GPT-OSS-120B는 효율성은 높지만 정확도는 35.11%에 그친다. 논문은 이를 raw parameter scale보다 agentic post-training quality와 tool-use behavior가 더 중요하다는 신호로 해석한다. 실제 DORA에서는 빠르게 적은 도구를 부르는 모델이 효율적으로 보일 수 있지만, 그 도구가 틀리면 재난 운영 관점에서는 위험하다.

5.2 tool-free VLM baseline이 낮은 이유

Tool-free baseline의 18%대 점수는 “거대 VLM이 재난 이미지를 전혀 못 본다”는 뜻만은 아니다. 이 baseline은 raw imagery와 question을 받고 한 번에 답해야 한다. 그러나 DORA 질문은 flood extent, building damage, route accessibility, POI containment, temporal progression 같은 중간 계산을 요구한다. segmentation mask를 만들고, 면적을 세고, vector layer와 교차하고, 도로망 위에서 최단 경로를 찾아야 하는 문제를 한 번의 VLM 응답으로 풀려 하면 정보가 압축되며 오류가 커진다. 따라서 낮은 점수는 tool-mediated reasoning이 필요한 문제라는 것을 확인하는 control 역할을 한다.

이 지점은 멀티모달 에이전트 연구에도 중요한 메시지를 준다. 시각 모델이 더 커지면 DORA 일부 T1 문제는 나아질 수 있다. 하지만 T3나 T5처럼 “피해 인식 결과를 운영 의사결정으로 바꾸는” 문제는 이미지 이해만으로 해결되지 않는다. 필요한 것은 perception output을 GIS object로 바꾸고, domain constraint를 적용하고, final report로 구성하는 실행 루프다. DORA는 멀티모달 모델의 성능을 end-to-end agentic system 성능과 구분해 보게 만든다.

5.3 도구 집합을 알아도 순서와 인자가 무너진다

Table 4에서 Tool-Any-Order와 Tool-Exact-Match의 차이가 크다. 예를 들어 Gemini-3.0-Flash는 T-Any-O 75.17%지만 T-Exact-M은 35.55%다. Claude-Sonnet-4.6도 76.29% 대 31.43%다. 이는 모델이 필요한 도구 종류를 어느 정도 떠올리지만, 순서와 prefix가 쉽게 어긋난다는 뜻이다. 재난 대응 파이프라인에서는 순서 오류가 특히 치명적이다. vectorize 전에 threshold를 적용하지 않거나, buffer 전에 CRS 단위를 확인하지 않거나, route planning 전에 폐쇄 도로를 제거하지 않으면 후속 결과가 모두 잘못된다.

Parameter Accuracy도 같은 문제를 다른 각도에서 보여 준다. Gemini-3.0-Flash의 ParAcc는 42.63%, Claude-Sonnet-4.6은 39.48%, Qwen3.5-397B-A17B는 36.50%다. Tool name을 맞춘 step에서도 절반 이상은 argument가 불완전하거나 틀린다는 뜻이다. 일반 대화형 에이전트에서는 argument가 틀리면 에러 메시지가 나와 self-correction 기회가 생길 수 있다. 하지만 GIS pipeline에서는 잘못된 mask나 polygon이 정상 파일처럼 생성될 수 있고, 모델은 그 관찰값을 믿고 다음 판단으로 넘어간다.

5.4 T5 보고서 합성이 특히 어렵다

차원별 결과를 보면 T5 Multi-modal Report Synthesis가 많은 모델에서 낮다. Gemini-3.0-Flash는 T5 45.31%, GPT-5.4는 29.11%, Gemma-4-31B는 42.03%다. T4 Temporal Evolution Reasoning이 길어도 상대적으로 잘 버티는 모델이 있는 반면, T5는 서로 다른 도구 범주를 이어 붙이며 시각화와 narrative summary까지 요구한다. 논문은 이를 raw trajectory length보다 heterogeneity가 더 큰 병목이라는 근거로 사용한다. 같은 도구를 반복하는 긴 루프보다, 짧더라도 mask, polygon, graph route, map rendering, report text가 섞이는 체인이 더 취약하다.

이 결과는 실제 운영 시스템 설계에도 시사점이 있다. 재난 대응 대시보드에서 “최종 보고서 자동 작성” 버튼을 만드는 것은 매력적이지만, 가장 위험한 부분이 바로 보고서 합성일 수 있다. 앞 단계에서 어떤 mask가 어떤 class를 포함했는지, 도로망에서 어떤 edge를 제거했는지, 경로가 어떤 constraint를 만족했는지, 지도에 표시된 polygon이 어떤 시점 자료에서 왔는지를 추적하지 않으면 보고서는 자연스럽게 보이면서도 근거가 틀릴 수 있다. DORA의 T5 하락은 이 위험을 정량화한다.

5.5 재난 도메인 고유 실패 모드

논문은 실패를 세 범주로 나눈다. 첫째, damage-semantic grounding은 20.3%를 차지한다. “partial damaged”, “total destroyed”, “affected”, “flooded” 같은 표현을 class index list와 연결하지 못하거나, multi-class mask를 binary mask로 바꾸는 과정에서 stale index를 downstream vectorization에 넘긴다. 둘째, sensor-modality mismatch는 14.8%다. raster와 vector operation을 혼동하거나, optical과 SAR, aerial과 satellite, bi-temporal과 multi-spectral 입력을 바꿔 쓰는 오류다. 셋째, disaster-pipeline composition은 56.3%로 가장 크다. compound spatial concept을 잘못 분해하거나, vec.intersect와 vec.buffer 같은 핵심 도구를 빠뜨리거나, downstream tool을 잘못된 intermediate output에 연결한다.

Figure 7: 재난 도메인에서 관찰되는 주요 실패 모드

Figure 7은 DORA가 일반적인 reasoning error보다 더 구체적인 도메인 실패를 드러낸다는 점을 보여 준다. 피해 등급을 class index로 매핑하는 문제, sensor modality와 raster/vector type을 구분하는 문제, compound spatial pipeline을 올바르게 분해하는 문제가 따로 집계된다. 특히 pipeline composition 비중이 크다는 사실은 모델 성능 향상이 단순한 프롬프트 개선보다 typed intermediate 관리와 도구 계약 검증에 달려 있음을 시사한다.

5.6 modality가 늘어날수록 점수가 급락한다

Figure 8은 입력 modality configuration별 성능을 보여 준다. Pure optical 조건에서는 여러 모델이 52~59% 수준까지 올라가지만, OSM vector layer가 추가되면 18~27%로 떨어지고, optical-SAR fusion은 24~36% 수준에 머문다. MS+DEM+Slope 조합도 어렵다. 논문은 auxiliary modality가 늘어나면 단순히 정보가 많아지는 효과보다 tool space와 argument space가 넓어지는 효과가 크고, 각 modality의 coordinate·resolution·semantic assumption이 달라지기 때문에 grounding error가 증폭된다고 해석한다.

Figure 8: 입력 modality configuration별 에이전트 성능 분해

Figure 8은 “데이터를 더 주면 모델이 더 잘한다”는 직관이 재난 대응에서는 쉽게 깨진다는 점을 보여 준다. Optical만 있을 때는 비교적 높은 점수가 나오지만, OSM vector, SAR, DEM, slope가 붙으면 모델은 어떤 도구가 어떤 입력 타입을 기대하는지 더 많이 판단해야 한다. 열 영상처럼 수치 의미가 명확한 modality는 상대적으로 tractable하지만, symbolic fusion과 cross-sensor alignment는 현재 에이전트의 약점으로 남는다.

5.7 trajectory 길이에 따른 compositional fragility

Figure 9는 gold trajectory 길이 bucket별 성능을 비교한다. 짧은 2~3 step pipeline에서는 top model이 gold ceiling과 7% 정도 차이로 따라가지만, 11 step 이상에서는 agent-to-gold gap이 56%까지 벌어진다. 흥미로운 점은 gold ceiling 자체가 긴 pipeline에서 낮아지기보다 오히려 높다는 점이다. 따라서 gap 확대는 underlying task가 본질적으로 더 애매해서라기보다, agent가 step을 추가할 때마다 sequencing error와 argument error를 누적하기 때문으로 해석된다.

Figure 9: Gold trajectory 길이에 따른 agent와 gold 성능 격차

Figure 9는 DORA의 핵심 메시지를 압축한다. 긴 tool pipeline은 전문가 trajectory로 실행하면 높은 ceiling을 유지하지만, LLM 에이전트는 길이가 늘수록 급격히 벌어진다. 이는 장기 에이전트 평가에서 final answer accuracy만 보는 방식이 왜 부족한지 보여 준다. 어느 step에서 path reference가 끊겼는지, 어떤 argument가 downstream으로 전파됐는지 추적해야 실제 개선 지점을 잡을 수 있다.

6. 추가 분석 및 Ablation Study: order hint와 scaffold의 한계

6.1 Auto-planning과 instruction-following 비교

논문은 기본 auto-planning(AP) 조건과 instruction-following(IF) 조건을 비교한다. IF에서는 gold tool order만 추가로 제공하고, 모델은 여전히 tool call을 실제로 발행하며 모든 argument를 직접 추론해야 한다. 결과는 매우 선명하다. Gemini-3.0-Flash의 T-Exact-M은 35.55에서 62.53으로 크게 오르고, Gemma-4-31B는 32.82에서 61.76으로 오른다. 그러나 최종 평균 정확도는 Gemini가 53.74에서 55.71로, Gemma가 51.17에서 52.25로, MiniMax가 48.35에서 52.75로만 오른다.

Protocol	T-Any-O	T-In-Ord	T-Exact-M	ParAcc	AVG
Gold Trajectory	100	100	100	100	80.48
Gemini-3.0-Flash AP	75.17	66.57	35.55	42.63	53.74
Gemini-3.0-Flash IF	82.56	82.03	62.53	53.49	55.71
Gemini Δ AP→IF	+7.39	+15.46	+26.98	+10.86	+1.97
Gemma-4-31B AP	69.89	62.58	32.82	38.23	51.17
Gemma-4-31B IF	79.80	79.63	61.76	50.24	52.25
Gemma Δ AP→IF	+9.91	+17.05	+28.94	+12.01	+1.08
MiniMax-M2.7 AP	62.89	55.19	25.32	29.68	48.35
MiniMax-M2.7 IF	80.85	79.83	50.95	43.98	52.75
MiniMax Δ AP→IF	+17.96	+24.64	+25.63	+14.30	+4.40

Table 5가 보여 주는 핵심은 DORA가 이중 병목을 가진다는 것이다. Gold order를 제공하면 tool sequence 관련 지표는 크게 개선된다. 그러나 final answer는 거의 오르지 않는다. 이는 모델이 “다음에 어떤 도구를 불러야 하는지”를 알아도 “그 도구에 어떤 class index, 어떤 raster path, 어떤 coordinate reference, 어떤 threshold, 어떤 previous observation을 넣어야 하는지”에서 계속 실패한다는 뜻이다. 재난 대응 에이전트의 안정성은 planner만 좋아져도, tool former만 좋아져도 충분하지 않다.

6.2 scaffold 비교: Plan-then-Execute, Reflexion, ReWOO

두 번째 ablation은 scaffold다. Gemma-4-31B 기준으로 ReAct를 기본값으로 두고, Plan-then-Execute, Reflexion, ReWOO를 비교한다. Plan-then-Execute는 평균 정확도를 51.17에서 54.41로 올리고, T-Exact-M과 ParAcc도 개선한다. Reflexion은 52.74로 작게 오른다. ReWOO는 44.26으로 크게 떨어진다. 이 결과는 DORA에서 planning이 도움이 되지만, observation feedback을 제거하거나 자기 반성만 추가한다고 domain grounding 문제가 사라지지 않음을 보여 준다.

Scaffold	AVG	T-Exact-M	ParAcc	Latency (s/task)
ReAct	51.17	32.82	38.23	80
Plan-then-Execute	54.41	38.83	47.27	179
PE Δ	+3.24	+6.01	+9.04	+99
Reflexion	52.74	36.21	40.05	167
Reflexion Δ	+1.57	+3.39	+1.82	+87
ReWOO	44.26	25.18	25.92	82
ReWOO Δ	-6.91	-7.64	-12.31	+2

Plan-then-Execute의 개선은 직관적이다. 재난 대응 파이프라인은 중간 observation에 흔들리며 즉흥적으로 경로를 바꾸기보다, 먼저 데이터 타입과 도구 순서를 크게 잡아 두는 편이 안정적이다. 하지만 latency는 80초에서 179초로 늘고, gold trajectory와의 간격은 여전히 26%p 이상 남는다. Reflexion은 실패가 reasoning slip일 때 유효할 수 있지만, DORA에서는 class index와 file path grounding 같은 저수준 인자 문제가 많아 self-critique만으로 고치기 어렵다. ReWOO는 observation feedback 없이 계획과 실행을 분리하는 구조가 data-heavy GIS task에 맞지 않다는 점을 드러낸다.

6.3 성능 개선의 실제 병목

두 ablation을 합쳐 보면, 다음 세대 재난 대응 에이전트의 개선 방향은 꽤 구체적이다. 첫째, planner는 tool order만 내놓는 수준을 넘어 typed intermediate artifact를 명시해야 한다. 둘째, executor는 tool schema와 argument provenance를 검사해야 한다. 셋째, evaluator는 final answer 이전에 mask, polygon, route, report component별 consistency를 점검해야 한다. 넷째, long-horizon pipeline은 모든 step을 LLM 자유 생성에 맡기기보다, domain-specific workflow template와 constraint solver가 함께 들어가는 편이 안전하다.

DORA는 prompt engineering만으로 해결하기 어려운 문제를 드러낸다. Gold order hint가 final answer를 조금만 올리고, scaffold가 최대 3.24%p만 올린다면, 병목은 surface prompt보다 system interface에 있다. 재난 대응 시스템은 모델에게 “알아서 도구를 써라”라고 맡기기보다, 각 tool output의 type, coordinate, resolution, valid class set, provenance를 runtime이 추적하고, 모델이 다음 action을 제안할 때 schema checker가 잘못된 연결을 막아야 한다. 이는 Shepherd의 typed effect stream과도 맞물리는 방향이다.

6.4 운영 태스크 예시를 통해 본 병목

DORA의 태스크를 실제 실행 경로로 상상해 보면 병목이 더 뚜렷해진다. 예를 들어 홍수 이후 특정 병원 주변의 접근 가능성을 묻는 질의는 먼저 홍수 영역을 segmentation하고, 해당 mask를 threshold와 vectorization으로 polygon화한 뒤, 병원 POI를 필터링하고, 도로망에서 침수 polygon과 교차하는 edge를 제거하고, 마지막으로 대체 경로를 계산해야 한다. 이 과정에서 한 단계라도 입력 타입을 잘못 쓰면 뒤 단계는 정상적으로 실행돼도 의미가 틀어진다. 그래서 DORA의 실패는 “모델이 질문을 이해하지 못했다”보다 “모델이 중간 산출물의 타입과 유효 범위를 보존하지 못했다”에 더 가깝다.

산사태 위험 평가도 비슷하다. multi-spectral image, DEM, slope layer가 함께 들어오면 모델은 산사태 탐지 mask를 만들고, 경사도 조건을 계산하고, 도로 또는 주거지 vector와 교차해 위험 노출을 추정해야 한다. 여기서 DEM은 단순 그림이 아니고, slope는 RGB 채널이 아니며, vector layer는 pixel mask처럼 threshold할 수 없다. 논문이 sensor-modality mismatch를 별도로 집계한 이유가 여기에 있다. 현재 LLM 에이전트는 자연어로 “고도와 경사도를 고려하라”는 지시는 이해하지만, 실제 도구 인자로 들어갈 raster band와 geometry operation을 안정적으로 매핑하는 데 약하다.

보고서 합성 태스크에서는 오류가 더 늦게 드러난다. 초기 segmentation이 틀리면 피해 면적이 틀리고, 피해 면적이 틀리면 우선순위 시설이 틀리며, 그 시설을 기준으로 만든 route map과 narrative summary도 함께 틀린다. 그러나 최종 보고서는 자연어로 매끄럽게 작성될 수 있다. DORA가 T5를 별도 dimension으로 둔 것은 이 위험 때문이다. 재난 대응 보고서는 사람이 읽기에 그럴듯한 문장보다, 어떤 mask·polygon·route·chart가 어떤 데이터에서 파생됐는지가 중요하다. 따라서 T5 점수 하락은 단순한 summarization 실패를 넘어 provenance가 끊긴 상태에서 보고서가 생성되는 위험을 보여 준다.

이 관점에서 DORA는 tool-use benchmark를 넘어 artifact-use benchmark에 가깝다. 도구 호출은 그 자체로 목적이 아니며, 도구가 만든 raster, vector, scalar, map, report component가 다음 판단의 근거가 된다. 현재 에이전트 평가는 tool call 로그를 남기더라도 중간 artifact의 의미를 충분히 검증하지 않는 경우가 많다. DORA는 gold trajectory와 typed answer를 통해 이 빈칸을 메우려 한다. 후속 시스템이 DORA에서 성능을 올리려면 tool name prediction보다 artifact lineage tracking과 schema validation을 먼저 강화해야 한다.

6.5 모델 순위를 해석할 때의 주의점

Table 4에서 모델 순위를 그대로 leaderboard처럼 읽으면 중요한 정보가 일부 사라진다. Gemini-3.0-Flash와 Qwen3.5-397B-A17B는 평균 정확도에서 거의 붙어 있지만, trajectory metric과 efficiency는 서로 다르게 해석될 수 있다. Claude-Sonnet-4.6은 T-Any-O가 높지만 T-Exact-M이 낮아 필요한 도구 집합은 비교적 잘 찾되 정확한 prefix 유지가 약한 편으로 볼 수 있다. GPT-OSS-120B는 efficiency가 높지만 정확도가 낮아, 적은 행동으로 빠르게 결론을 내리는 성향이 실제 재난 파이프라인에서는 위험할 수 있음을 보여 준다.

따라서 DORA에서 좋은 모델은 평균 final answer만 높은 모델보다, tool order, exact prefix, parameter accuracy, modality별 성능, trajectory length별 성능이 고르게 버티는 모델이다. 재난 대응 운영자는 평균 1등 모델보다 특정 failure mode가 예측 가능한 모델을 선호할 수 있다. 예컨대 optical-only T1에서는 강하지만 OSM vector가 붙으면 급락하는 모델은 damage assessment assistant로는 쓸 수 있어도 evacuation planning assistant로는 위험하다. 반대로 평균은 조금 낮아도 parameter accuracy가 안정적인 모델은 human-in-the-loop 환경에서 더 다루기 쉬울 수 있다.

이런 해석은 기존 벤치마크 문화에도 중요한 교훈을 준다. 단일 평균 점수는 연구 커뮤니케이션에는 편하지만, 운영 배치에는 부족하다. DORA가 제공하는 차원별·modality별·trajectory별 분해는 모델 선택을 task profile 기반으로 바꾸는 근거가 된다. 재난 대응 기관이 실제로 AI 도구를 검토한다면 “최고 점수 모델”보다 “우리 업무에서 많은 SAR+OSM routing 태스크를 어디까지 안정적으로 처리하는가”를 먼저 봐야 한다. 이 관점은 최근 LLM routing이나 task-aware evaluation 흐름과도 잘 맞는다.

6.6 DORA가 요구하는 시스템 인터페이스

DORA 결과를 개선하려면 모델 프롬프트만 길게 쓰는 접근은 한계가 있다. 필요한 것은 에이전트와 도구 사이의 인터페이스 재설계다. 각 tool은 입력으로 허용하는 artifact type, coordinate reference, resolution, class vocabulary, temporal index를 machine-readable schema로 노출해야 한다. 모델이 tool call을 제안하면 runtime은 schema compatibility를 검사하고, 누락된 인자나 stale reference를 바로 되돌려야 한다. 이는 단순한 validation layer처럼 보이지만, DORA에서 관찰된 대부분의 argument grounding 오류를 사전에 줄일 수 있는 구조다.

또한 중간 observation은 자연어 요약만으로 모델에게 돌아가면 부족하다. segmentation 결과라면 class distribution, bounding geometry, CRS, pixel-to-meter conversion, source timestamp가 함께 붙어야 하고, vector operation 결과라면 geometry count, area, intersection target, dropped feature 수가 포함되어야 한다. 이렇게 observation을 structured summary로 돌려주면 모델은 다음 step에서 어떤 artifact를 참조해야 하는지 더 명확히 알 수 있다. Shepherd식 typed effect stream이나 provenance-aware agent evaluation이 DORA와 연결되는 지점이 바로 여기에 있다.

마지막으로, high-risk pipeline에서는 모델이 불확실성을 표현할 수 있는 tool action도 필요하다. 현재 benchmark는 대부분 final answer를 내는 방향으로 평가하지만, 실제 재난 대응에서는 “이 입력은 SAR와 optical alignment가 불확실하다”, “OSM road layer의 최신성이 낮다”, “피해 class index가 tool documentation과 충돌한다” 같은 escalation이 매우 중요하다. DORA의 다음 버전은 정답을 내는 능력과 함께, 위험한 상태를 사람에게 올리는 abstention-aware execution을 평가할 수 있다. 그러면 benchmark는 자동화 성능과 함께 안전한 협업 능력까지 측정하게 된다.

7. 한계점 및 향후 연구 방향: 벤치마크의 강점과 남은 질문

DORA는 재난 대응 에이전트 평가를 크게 밀어 올리지만, 한계도 분명하다. 첫째, benchmark가 재현 가능한 open-source data와 tool library 위에 세워진 만큼, 실제 현장 데이터의 불완전성과 지연, 보안 제약, 라이선스 제약, 통신 장애를 모두 반영하지는 못한다. 재난 직후에는 imagery가 늦게 도착하거나 cloud cover가 심하고, 도로 폐쇄 정보가 OSM에 즉시 반영되지 않으며, 현장 보고는 서로 충돌할 수 있다. DORA는 운영 파이프라인을 평가하지만, live incident command 환경의 정보 비동기성까지 완전히 모사하지는 않는다.

둘째, gold trajectory의 존재는 평가를 정밀하게 만들지만, 실제 재난 대응에서는 하나의 정답 trajectory만 존재하지 않을 수 있다. 같은 질의도 먼저 flood extent를 계산한 뒤 POI를 교차할 수도 있고, 위험 시설 후보를 먼저 좁힌 뒤 주변 피해 mask를 계산할 수도 있다. DORA의 trajectory metric은 tool order와 prefix를 평가하는 데 유용하지만, alternative valid plan을 얼마나 허용하는지는 앞으로 더 확장될 수 있다. 물론 논문은 final answer metric도 함께 두어 일부 유연성을 제공하지만, plan diversity와 operational preference까지 평가하려면 더 풍부한 equivalence class가 필요하다.

셋째, perception tool 자체의 오류와 agent planning 오류가 완전히 분리되지는 않는다. Gold trajectory도 model-backed perception tool을 사용하기 때문에 perfect oracle은 아니고, benchmark는 planning-and-argument oracle이라는 표현이 더 정확하다. 이는 현실적인 설정이기도 하지만, 특정 segmentation tool이 약한 disaster type에서는 모델의 계획이 좋아도 최종 답이 낮아질 수 있다. 후속 연구에서는 perception uncertainty를 tool output metadata로 노출하고, 에이전트가 그 불확실성을 다음 단계에서 어떻게 반영하는지 평가하는 방향이 필요하다.

넷째, DORA는 고위험 도메인에서 AI agent를 평가하지만 human-in-the-loop 의사결정 구조를 직접 모델링하지는 않는다. 실제 재난 대응에서는 자동 보고서가 사람 지휘관에게 전달되고, 지휘관은 일부 지도와 수치를 검토해 승인하거나 반려한다. 따라서 다음 단계 benchmark는 모델이 정답을 내는 능력과 함께, 자신이 확신하지 못하는 mask, 모호한 modality, 충돌하는 vector source를 사람에게 어떻게 escalation하는지도 봐야 한다. 이는 safety와 accountability 관점에서 중요하다.

마지막으로, DORA가 사용하는 도구 library는 매우 넓지만 여전히 특정 구현과 schema에 묶여 있다. 다른 기관의 GIS pipeline, 다른 coordinate convention, 다른 재난 관리 표준, 다른 map rendering style을 쓰면 에이전트의 tool transfer가 다시 흔들릴 수 있다. 그래서 DORA 점수는 “재난 대응 일반 지능”이라기보다 “이종 지리공간 도구 체인을 주어진 schema 아래 얼마나 안정적으로 실행하는가”로 읽는 편이 안전하다. 이 해석을 유지하면 benchmark의 가치를 과대평가하지 않고, 실제 시스템화에 필요한 missing layer를 더 정확히 볼 수 있다.

7.1 실제 배치에서 추가로 필요한 평가 축

실제 배치 관점에서 DORA에 추가되면 좋은 축은 시간 지연과 정보 갱신이다. 재난 대응은 한 번의 정적 데이터셋 위에서 끝나지 않는다. 새 위성영상이 몇 시간 뒤 들어오고, 도로 폐쇄 정보가 현장 보고로 갱신되며, 대피소 수용 인원이 바뀐다. 현재 DORA는 temporal evolution reasoning을 포함하지만, 에이전트가 이미 만든 판단을 새로운 observation으로 어떻게 revise하는지는 별도 평가 축으로 더 분리할 수 있다. 이전 보고서의 어떤 수치가 stale 되었는지 표시하고, 새 데이터가 들어왔을 때 어느 tool chain만 다시 실행하면 되는지 판단하는 능력은 운영 비용을 크게 줄일 수 있다.

또 다른 축은 설명 가능성이다. DORA의 structured answer와 trajectory는 설명 가능성의 좋은 출발점이지만, 실제 사용자는 tool 로그 전체를 읽기 어렵다. 따라서 에이전트는 최종 보고서 옆에 “이 결론은 xBD post-disaster optical image, building_damage mask, vec.intersect 결과, hospital POI layer에서 왔다”처럼 짧은 provenance summary를 제공해야 한다. 이 요약은 자연어 설명이면서도 machine-checkable artifact ID를 포함해야 한다. 단순히 “분석 결과에 따르면”이라고 쓰는 보고서는 재난 대응 회의에서 검증 가능한 근거가 부족하다.

마지막 축은 calibration이다. DORA 점수표는 정답 여부를 보여 주지만, 모델이 언제 자신이 틀릴 가능성이 높다고 느끼는지는 별도로 봐야 한다. 재난 대응에서는 낮은 확신의 자동 답변보다, 사람이 확인해야 할 위치와 이유를 정확히 표시하는 시스템이 더 안전할 수 있다. 예컨대 SAR와 optical alignment가 애매하거나, 피해 등급 class vocabulary가 tool documentation과 다르거나, OSM road layer가 오래되었을 때 모델이 final report 생성을 멈추고 검토 요청을 올릴 수 있어야 한다. 이 능력은 일반 leaderboard accuracy에는 잘 드러나지 않는다.

7.2 연구자와 개발자가 바로 가져갈 수 있는 교훈

연구자에게 DORA가 주는 교훈은 benchmark 설계에서 “도메인별 중간 산출물”을 평가 단위로 올려야 한다는 것이다. 코딩 에이전트라면 diff와 test log, 업무 파일 에이전트라면 파일 dependency graph, 재난 대응 에이전트라면 raster mask와 vector geometry, 의료 에이전트라면 evidence span과 guideline criterion이 중간 산출물이다. 이런 산출물을 기록하지 않으면 모델이 어떤 이유로 맞았고 어떤 이유로 틀렸는지 알기 어렵다. DORA는 지리공간 도메인에서 이 원칙을 꽤 구체적인 형태로 보여 준다.

개발자에게 더 직접적인 교훈은 tool schema를 사람이 읽는 문서로만 두지 말라는 점이다. LLM에게 “이 도구는 홍수 영역을 계산한다”라고 설명하는 것과, 해당 도구의 입력 type, band requirement, CRS, class mapping, output path contract를 runtime이 검사하는 것은 전혀 다르다. DORA에서 모델이 실패한 많은 사례는 자연어 지시 부족보다 schema enforcement 부족에 가깝다. 따라서 실제 에이전트 플랫폼은 tool description, JSON schema, artifact registry, validator, replay log를 한 세트로 설계해야 한다.

사용자 조직 입장에서는 DORA 점수를 자동화 가능성의 상한으로 읽기보다, 사람 검수가 어디에 들어가야 하는지 결정하는 지도로 읽는 편이 낫다. T1처럼 비교적 짧은 perception task는 자동 초안 생성 후 spot check로 충분할 수 있지만, T5처럼 여러 도구와 보고서 합성이 얽힌 task는 중간 mask와 route map을 사람이 확인하는 checkpoint가 필요하다. 이처럼 benchmark 분석을 workflow 설계로 번역해야 실제 안전성이 올라간다. DORA의 가치는 모델 순위보다 이런 검수 위치를 숫자로 좁혀 주는 데 있다.

8. 내 해석: 약점 1과 후속 제안 1

나는 이 논문에서 가장 설득력 있는 부분이 final answer와 trajectory를 함께 보는 설계라고 본다. 이전에 정리한 Workspace-Bench는 업무 파일 의존성에서 에이전트가 어떤 파일을 읽고 어떤 관계를 놓쳤는지 보여 줬고, Shepherd는 typed effect stream으로 runtime 수준의 실행 근거를 보존하려 했다. DORA는 이 흐름을 재난 대응 도메인으로 옮겨, mask, polygon, route, report page 같은 중간 산출물을 tool-call trajectory 안에 묶는다. 그래서 “모델이 답을 맞혔다”보다 “모델이 어떤 geospatial artifact를 근거로 답을 만들었는가”를 더 구체적으로 묻는다. 이 점은 고위험 에이전트 평가가 가야 할 방향과 잘 맞는다.

다만 내가 걸리는 약점은 alternative valid workflow의 처리다. 논문은 expert-authored gold trajectory와 replay engine으로 평가의 재현성을 높였지만, 실제 재난 분석에서는 같은 operational goal을 여러 합법적 순서로 달성할 수 있다. 예컨대 시설 우선순위를 먼저 좁힌 뒤 해당 주변의 피해 mask를 계산하는 경로와, 전체 피해 mask를 만든 뒤 시설과 교차하는 경로는 모두 상황에 따라 타당할 수 있다. Tool-Any-Order와 final answer가 일부 유연성을 주지만, Tool-In-Order와 Exact-Match는 특정 expert path에 가까운 에이전트를 더 높게 볼 가능성이 있다. 이 한계는 benchmark 결론을 무너뜨리지는 않지만, trajectory metric을 operational correctness의 유일한 기준으로 읽을 때 주의가 필요하다.

내가 확장한다면 DORA 위에 plan equivalence layer를 붙여 볼 것 같다. 각 태스크에 하나의 gold trajectory만 두는 대신, 핵심 중간 산출물의 dependency graph를 정의하고, 도구 순서는 다르더라도 같은 artifact set과 constraint를 만족하면 부분 점수를 주는 방식이다. Workspace-Bench의 file dependency graph evaluation처럼, DORA도 mask, vectorized polygon, filtered POI, route, visualization component를 노드로 두고, “어떤 산출물이 어떤 산출물에서 파생되었는가”를 평가하면 plan diversity와 provenance를 함께 잡을 수 있다. 그러면 모델이 expert 순서를 그대로 모방하지 않아도, 재난 대응에 필요한 증거 체인을 제대로 구축했는지 더 공정하게 볼 수 있다.

또 하나의 후속 제안은 runtime guardrail이다. DORA 결과를 보면 모델은 gold order를 받아도 argument grounding에서 계속 실패한다. 따라서 다음 시스템은 LLM에게 free-form JSON tool call을 맡기는 대신, 각 단계에서 output type, CRS, GSD, class index domain, file lineage를 runtime이 검증해야 한다. 예를 들어 raster mask를 기대하는 tool에 vector path가 들어가면 즉시 막고, optical-SAR fusion 전에 modality metadata가 일치하는지 확인하며, damage class index가 binary mask로 변환된 뒤 stale index를 쓰면 경고하는 식이다. 이 방식은 모델 성능 향상보다 느려 보일 수 있지만, 재난 대응처럼 오류 비용이 큰 도메인에서는 agent intelligence보다 typed execution contract가 먼저 필요하다.

9. 결론: 재난 대응 에이전트 평가가 보여 주는 다음 병목

DORA는 재난 대응을 위한 첫 agentic benchmark라는 주장에 걸맞게, 단일 이미지 이해나 일반 tool-use를 넘어서는 평가 표면을 만든다. 515개 전문가 태스크, 45개 실제 재난 사건, 10개 재난 유형, 108개 MCP 도구, 3,500개 gold tool-call step은 현재 LLM 에이전트가 어디서 무너지는지 꽤 선명하게 드러낸다. 가장 중요한 결과는 최고 모델도 평균 53.74%에 머물고, gold trajectory 80.48%와 큰 차이가 남는다는 점이다. 이 간격은 도구가 있으면 LLM이 알아서 업무를 완성할 것이라는 낙관을 조정하게 만든다.

논문이 특히 잘 보여 준 병목은 세 가지다. 첫째, 재난 도메인 grounding은 일반 시각·언어 지식으로 충분하지 않다. 피해 등급, sensor modality, raster/vector type, spatial relation의 의미를 정확히 연결해야 한다. 둘째, tool selection과 argument grounding은 분리된 병목이다. Gold tool order를 줘도 final accuracy가 조금만 오르는 결과가 이를 보여 준다. 셋째, compositional fragility는 trajectory length와 tool heterogeneity가 커질수록 급격히 커진다. T5 report synthesis의 낮은 점수는 장기 파이프라인의 마지막 자연어 산출물이 가장 위험한 표면이 될 수 있음을 보여 준다.

DORA가 실용적으로 유용한 이유는 “어떤 모델이 1등인가”보다 “어떤 runtime layer가 부족한가”를 알려 주기 때문이다. 필요한 것은 더 큰 모델만이 아니다. Typed intermediate artifact, schema-checked tool call, provenance-aware trajectory, domain-specific argument validator, uncertainty escalation, human review checkpoint가 함께 필요하다. 이런 층이 없으면 모델은 그럴듯한 재난 보고서를 만들 수 있지만, 그 보고서가 어떤 mask와 polygon과 route에서 왔는지 확인하기 어렵다.

따라서 이 논문은 재난 대응 AI의 가능성을 보여 주면서도, 실제 투입까지 남은 거리를 냉정하게 숫자로 보여 준다. 에이전트는 이미 도구를 부르고 여러 단계로 생각할 수 있지만, 고위험 지리공간 업무에서는 “부른다”와 “정확히 쓴다” 사이가 넓다. DORA의 장점은 그 넓이를 trajectory metric, final answer metric, modality analysis, scaffold ablation으로 쪼개 보여 준다는 데 있다. 후속 연구가 이 benchmark를 기반으로 runtime contract와 plan equivalence를 강화한다면, 재난 대응 에이전트는 단순 데모를 넘어 검증 가능한 운영 보조 시스템에 가까워질 수 있다.

10. 요약 정리

• DORA는 45개 실제 재난 사건, 515개 전문가 태스크, 108개 MCP 지리공간 도구, 3,500개 gold tool-call step으로 구성된 재난 대응 에이전트 벤치마크다.
• 평가는 최종 답변만 보지 않고 Tool-Any-Order, Tool-In-Order, Tool-Exact-Match, Parameter Accuracy로 실행 trajectory를 함께 측정한다.
• 최고 모델 Gemini-3.0-Flash도 평균 53.74%에 머물며, gold trajectory 80.48%와 26%p 이상 차이가 난다.
• Tool-free VLM baseline은 18%대에 그쳐, 재난 대응 문제는 단순 시각 질의응답보다 tool-mediated geospatial reasoning에 가깝다는 점을 확인한다.
• Instruction-following으로 gold tool order를 줘도 final answer는 1.08~4.40%p만 개선되어, tool selection과 argument grounding이 분리된 병목임을 보여 준다.
• 주요 실패 모드는 damage-semantic grounding, sensor-modality mismatch, disaster-pipeline composition이며, 특히 pipeline composition 오류 비중이 가장 크다.
• OSM vector, SAR, DEM, slope 같은 auxiliary modality가 붙으면 성능이 급락해, 데이터가 많아질수록 tool space와 argument space도 함께 어려워진다.
• Plan-then-Execute는 일부 개선을 만들지만 latency가 커지고, Reflexion은 제한적이며, ReWOO는 observation feedback 부족으로 data-heavy task에서 무너진다.
• 후속 연구는 더 큰 모델뿐 아니라 typed execution contract, provenance-aware artifact graph, plan equivalence 평가, human escalation checkpoint를 함께 설계해야 한다.