스스로 돌아다니며 물체 배치도를 그려라 — AI 공간지능 벤치마크 SpatialScout

물체 목록만 주고 AI가 직접 카메라를 움직여 각 물체 위치를 배치도로 찍게 하는 벤치마크. 최강 모델 Claude Opus 5.5도 평균 겹침 41.71%에 그쳤다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 22일 읽기 16분 조회 0

베이징대·톈진대 연구진이 내놓은 SpatialScout는 VLM(이미지와 글을 함께 이해하는 AI) 에이전트에게 실내 공간을 직접 돌아다니게 하는 벤치마크다. 질문을 던지고 답을 맞히게 하는 기존 시험과 달리, 에이전트가 카메라를 스스로 움직여 방 안을 둘러본 뒤 "어떤 물체가 어디에 있는지"를 배치도로 찍어 제출하게 한다. 여기서 배치도란 방의 생김새까지 복원하는 게 아니라, 각 물체의 중심이 어디인지 3차원 좌표로 찍은 점들의 모음이다.

성적은 "겹침 점수"로 매긴다. 각 물체에는 정답 상자(실제 그 물체가 차지하는 공간)가 있고, 에이전트가 찍은 좌표에 같은 크기의 상자를 올려놓았을 때 정답 상자와 얼마나 포개지는지를 본다. 많이 포개질수록 좌표를 정확히 짚은 것이다.

80개 실내 장면, 3,140개 목표 물체로 시험했다. 성적이 가장 좋았던 Claude Opus 5.5조차 전체 목표에 대한 평균 겹침 점수가 41.71%에 머물렀고, 상자가 거의 완벽히 포개진(IoU 0.9 초과) 목표는 3.25%뿐이었다. 물체가 어디쯤 있는지 대충 아는 것과, 빠짐없이 미터 단위로 정확한 배치도를 만드는 것 사이에는 아직 큰 골이 있다는 뜻이다.

이 논문이 푸는 문제

지금까지 공간지능을 재는 방식은 대부분 질문-답변(QA)이었다. 사진이나 영상을 주고 "물체가 몇 개냐", "왼쪽이냐 오른쪽이냐", "둘 사이 거리가 얼마냐"를 객관식이나 숫자로 묻는 식이다. 이 방식에는 빈틈이 있다. 선택지가 정해져 있으면 추측이나 소거법으로 정답을 맞힐 수 있다. 또 "부엌에는 보통 냉장고가 있다"처럼 언어 모델이 학습 과정에서 익힌 상식만으로도, 공간을 제대로 이해하지 않은 채 그럴듯한 답을 낼 수 있다. 저자들의 표현으로는, 답의 정확도는 공간 이해를 "제한적으로만" 검증한다.

더 근본적인 어긋남이 있다. 실제 에이전트는 가만히 앉아 주어진 사진만 보고 답하지 않는다. 스스로 둘러보며 가려진 곳을 확인하고, 시점을 바꿔 애매한 부분을 해소하고, 여러 장면에서 모은 증거를 하나의 일관된 3차원 그림으로 합쳐야 한다. 관찰 → 추론 → 결정이 꼬리를 물고 도는 이 과정 전체가 공간지능인데, QA는 그 과정의 결과물 한 조각만 들여다본다.

기존 벤치마크(VSR, BLINK, VSI-Bench, OpenEQA 등)도 대부분 이 QA 틀 안에서 답의 정확도를 본다. ESI-Bench·S³-Bench는 에이전트가 능동적으로 상호작용하게 했지만 여전히 질문에 답하는 형식이고, Theory of Space는 지도의 품질을 보되 칸으로 나눈 거친 지도를 다뤘다. SpatialScout의 차별점은 세 가지가 겹치는 자리에 있다. 연속적인 3차원 좌표를 직접 출력하게 하고, 지금까지 그린 배치도를 보고 다음에 어디를 볼지 스스로 고르는 능동 탐험을 요구하며, 여러 단계에 걸친 관찰·인식·대응·좌표 추정을 하나로 묶어 최종 배치도의 품질로 채점한다.

과제는 어떻게 생겼나

과제를 한 문장으로 줄이면 이렇다. 에이전트에게 "이 방에 어떤 물체들이 있다"는 목록과 출발 지점에서 찍은 사진 한 장, 그리고 카메라의 위치와 방향 정보를 준다. 그다음 카메라를 직접 움직여 돌아다니면서 각 물체 중심의 3차원 좌표를 하나의 지도 위에 찍어 제출하게 한다.

불 꺼진 집에 손전등 하나만 들고 들어가는 상황을 떠올리면 된다. 손에는 "의자 셋, 탁자 하나, 화분 둘이 있다"는 쪽지뿐이다. 어디를 비출지는 내가 정하고, 지금까지 그린 배치도를 보며 "아직 저 구석을 못 봤네" 하고 다음 발걸음을 결정한다. 조금 전 본 의자가 다른 각도에서 다시 보이는 그 의자가 맞는지도 스스로 판단해야 한다. 같은 물체를 여러 시점에서 알아보고 하나로 잇는 이 일을 교차 시점 대응(cross-view association)이라 부른다.

에이전트가 쓸 수 있는 도구는 열 가지인데, 하는 일로 묶으면 네 갈래다. 물체 목록을 들춰보고, 카메라를 옮기거나 돌리고, 사진을 찍고, 좌표를 추정해 제출한다(도구 이름은 글 끝 주석에 정리했다). 중요한 설계는 어떤 도구도 정답 위치나 채점 점수를 알려주지 않는다는 점이다. 에이전트는 오로지 자기가 모은 사진 증거만으로 배치도를 세워야 한다.

이 중 좌표를 추정하는 삼각측량 도구가 과제의 묘미를 잘 보여준다. 서로 다른 두 장 이상의 사진에서 "이 픽셀과 저 픽셀이 같은 지점"이라고 짚어주면, 도구는 그 지점의 3차원 좌표를 계산해 준다. 그런데 도구가 해주는 건 기하학 계산뿐이다. 그 두 픽셀이 정말 같은 물체의 같은 부분을 가리키는지, 또 거기서 나온 점이 물체 중심과 얼마나 가까운지는 판단해 주지 않는다. 계산상 오차(잔차)가 작다고 해서 짝을 제대로 맞췄다는 보장도, 중심을 제대로 짚었다는 보장도 없다. 물체 표면의 한 점과, 물체를 감싸는 가상의 상자(축정렬 경계상자, AABB)의 중심은 애초에 다른 점이기 때문이다. 결국 기하학 계산과 "무엇을 가리키는가"라는 의미 판단을 모두 요구하는 지점이다.

실험은 어떻게 설계됐나

장면은 80개, 개별 방부터 아파트 한 채 규모까지 걸쳐 있다. 시뮬레이터로 만들었지만 원본 레이아웃과 물체 배치를 그대로 유지했다(출처별 장면 수는 글 끝 주석에 정리했다). 각 장면에는 30~40개의 목표가 담겨 있고, 목표가 흩어진 반경은 좁게는 1.95m, 넓게는 9.23m에 이른다.

난도를 끌어올리는 장치가 하나 있다. 전체 목표의 약 47.42%(1,489개)는 같은 장면에 똑같이 생긴 물체가 여러 개 있는 경우다(원논문이 밝힌 43.3%와 어긋나는 수치는 글 끝 주석에 정리했다). 똑같은 의자가 네 개 놓여 있으면 "이 좌표가 네 의자 중 어느 것이냐"를 가려야 하므로, 앞서 말한 교차 시점 대응이 훨씬 까다로워진다.

성적은 두 축으로 잰다. 하나는 좌표를 얼마나 정확히 짚었나(위치 정확도), 다른 하나는 물체를 얼마나 빠짐없이 찾았나(포괄도)다. 겹침 점수를 낼 때 빠뜨린 물체는 0점으로 집계한다. 그래서 점수를 두 가지로 보고한다 — "전체 목표 기준"(못 찾은 것도 0점으로 포함)과 "제출한 목표 기준". 이 둘의 차이가 곧 누락이 깎아먹은 몫이다. 중심 오차(미터)는 똑같이 생긴 물체끼리 가장 가까운 것끼리 짝지은 뒤 따로 보고한다.

전체 목표 평균 겹침 점수는 "정확하게, 그리고 빠짐없이" 배치도를 그렸는지를 숫자 하나로 압축한다. 다만 이 한 숫자로는 어디서 틀렸는지 — 못 보고 지나쳤는지, 봤는데 좌표가 어긋났는지 — 를 가릴 수 없다. 그래서 논문은 에이전트가 움직인 경로(궤적)를 하나씩 뜯어보는 분석을 따로 붙였다.

평가한 모델은 일곱 개다(전체 목록은 글 끝 주석에 정리했다). 출력·추론 분량에는 제한을 두지 않았고, 모델과 장면을 하나씩 짝지어 한 번씩 돌렸다.

결과와 의미

전체 목표 평균 겹침 점수는 Claude Opus 5.5가 41.71%로 가장 높았고, GPT-6 Astra가 33.16%로 뒤를 이었다. 제출한 목표만 따지면 각각 46.69%와 약 41%로 올라간다. 전체 기준과 제출 기준 사이의 이 차이가, 못 찾고 빠뜨린 물체가 점수를 끌어내린 몫이다.

정밀도로 눈을 돌리면 그림이 달라진다. 조금이라도 겹친(겹침 점수가 양수인) 비율은 Opus 77.36%, Astra 67.79%로 제법 높다. 그런데 상자가 절반 넘게 포개진(IoU 0.5 초과) 비율은 Opus 47.23%, Astra 35.15%로 떨어지고, 거의 완벽히 포개진(IoU 0.9 초과) 비율은 Opus조차 3.25%, Astra는 1.62%다. "저 근처에 있다"는 거친 배치는 절반 가까이 해내지만, 물체 크기에 맞춰 중심을 정밀하게 짚는 일은 거의 못 한다는 뜻이다. 하위권인 Kimi-K3, Qwen3.8-Max, DeepSeek-V4.1-Flash는 전체 평균 겹침 점수가 한 자릿수에 그쳤고, IoU 0.9 초과 비율은 0.00%였다.

정성 사례는 숫자만으로는 안 보이는 결을 드러낸다. 성공 사례에서 Opus는 35개 목표를 모두 제출하면서 중심 오차 0.073m, 전체 평균 겹침 점수 0.530을 기록했다. 반대로 실패 사례에서 DeepSeek-V4.1-Flash는 40개를 다 제출하고도 중심 오차가 1.000m, 전체 평균 겹침 점수는 0.034에 그쳤다. 다 제출했다고 좋은 배치도가 아니며, 많이 찾는 것과 정확히 짚는 것을 함께 봐야 하는 이유다.

성적이 갈린 이유를 들여다보려면 삼각측량으로 돌아가야 한다. 좌표를 제대로 추정하려면 세 단계를 차례로 통과해야 한다. 같은 의자를 여러 시점에서 같은 의자로 알아보고(대응), 그 의자의 같은 지점을 두 사진에서 똑같이 짚고(픽셀 짝짓기), 거기서 나온 점을 물체 중심으로 옮겨 앉히는(중심 추정) 일이다. 어느 한 단계만 어긋나도 좌표는 크게 빗나간다.

궤적 분석이 이 세 단계와 맞물린다. 저자들은 도구를 비슷한 횟수로 부르고도 성적이 갈린 Astra와 DeepSeek-V4.1을 짝지어 80개 과제의 경로를 뜯어봤다. Astra는 제출한 물체의 99.33%에 삼각측량 근거가 있었고 기하 경고는 2.69%에 그쳤으며, 중심 오차 중앙값이 7.08cm였다. DeepSeek-V4.1은 삼각측량 근거가 63.48%뿐이고 경고가 38.65%, 중심 오차 중앙값이 68.17cm였다. 사진은 오히려 DeepSeek가 더 많이 찍었다(39.63장 대 32.41장). 더 많이 본 쪽이 아니라 세 단계를 또박또박 밟은 쪽이 정확했다는 단서다.

실패 유형 분석도 같은 이야기를 한다. 성공 기준("90% 이상 포괄 + 짝지어진 제출 물체의 평균 중심 오차 0.2m 이하")을 채운 궤적은 40개 중 6개뿐이었다. 실패한 34개에서 가장 흔한 건 물체를 다 찾지 못한 경우(26건)였다. 그다음이 삼각측량 잔차는 작은데도 위치가 크게 틀린 경우(21건)인데, 계산은 깔끔했지만 애초에 다른 물체를 같은 물체로 착각했거나 엉뚱한 지점을 짚은, 즉 앞의 두 단계에서 미끄러진 사례다. 응답 기회를 열 번 넘게 남겨둔 채 덜 찾은 상태로 멈춰버린 경우도 13건이었다.

한계와 남은 질문

저자들이 스스로 인정하는 한계는 비용이다. Claude Opus 5.5는 가장 좋은 성적을 냈지만 과제당 평균 28.85달러로 가장 비쌌고, 이는 오래 이어지는 다른 에이전트 벤치마크에서도 나타나는 경향이라고 적는다. 함께 평가한 오픈소스 모델들은 정확도와 비용의 균형에서 뚜렷한 이점을 보이지 못했다.

내가 보기에 더 중요한 한계는 과제의 조건이 현실보다 후하다는 점이다. 에이전트는 완전한 물체 목록, 카메라의 위치와 방향, 탐색 반경까지 미리 받는다. "무엇을 찾아야 하는지"와 "내가 지금 어디서 어디를 보는지"가 거저 주어지는 셈이다. 진짜 로봇은 이것들을 스스로 알아내야 하므로, SpatialScout는 공간지능의 한 조각 — 능동 탐험, 교차 시점 대응, 좌표 추정 — 을 깨끗이 떼어내 재는 통제된 실험대에 가깝다. 이건 흠이 아니라 설계 의도지만, 이 점수를 곧장 "현실에서 혼자 알아서 하는 능력"으로 번역해선 안 된다.

온틀에 적용한다면

AI PM(프로젝트 매니저 역할을 하는 AI)의 하루에서 가장 조용히 어려운 일이 "아침마다 프로젝트의 진짜 상태를 다시 짜 맞추는 것"이다. 할 일은 Slack에, 블로커는 어제 통화에, 배포 상태는 CI 로그에, 담당자 변경은 누군가의 지나가는 말에 흩어져 있다. AI PM은 이 조각들을 능동적으로 긁어모아 "지금 무엇이 어디에 있고 무엇이 막혀 있는가"를 하나의 상태도로 세워야 한다.

SpatialScout와 겹치는 지점은 딱 여기까지다 — 흩어진 관찰로 상태를 구성하고, 지금까지 세운 그림을 보며 다음에 무엇을 더 확인할지 정한다는 점. 다만 중요한 차이가 있다. SpatialScout의 에이전트는 "찾아야 할 물체 목록"을 완전히 받는다. 적어도 무엇을 빠뜨렸는지 셈은 할 수 있다. 반면 AI PM은 애초에 블로커가 몇 개인지, 무엇을 놓쳤는지조차 모른 채 시작한다. 누락을 재는 일 자체가 온틀에서는 훨씬 어렵다.

그래서 온틀 같은 제품을 평가할 때 "질문에 잘 답하나"로 끝내면 안 된다. SpatialScout가 QA를 상태 구성으로 바꿔 평가 축을 다시 세운 것처럼, 온틀도 사람이 직접 정리한 프로젝트 상태를 정답지로 놓고 다음 세 가지를 재보는 쪽으로 옮겨야 한다.

  • 블로커 누락률: 사람이 꼽은 블로커 가운데 에이전트가 끝내 못 집어낸 비율. 실패 궤적에서 가장 흔한 게 "다 못 찾은 것"이었듯, 좌표 몇 개 어긋난 상태도보다 블로커 하나를 통째로 빠뜨린 상태도가 훨씬 위험하다.
  • 담당자 연결 오류: 할 일과 사람을 잘못 짝지은 비율. 삼각측량에서 잔차는 작아도 엉뚱한 물체를 짚으면 크게 틀렸듯, "출처는 깔끔한데 애초에 잘못된 걸 연결한" 오류는 그럴듯해 보여서 더 잘 샌다.
  • 변경 반영 지연: 상태가 바뀐 뒤 상태도에 반영되기까지 걸린 시간. 더 많은 메시지를 읽는 것보다, 읽은 내용을 이슈 트래커 같은 구조화된 근거에 묶어 제때 갱신하는 쪽이 정확한 상태도를 만든다.

응답 기회를 한참 남긴 채 덜 찾고 멈춰버린 에이전트가 적지 않았다는 대목은 온틀에도 그대로 경고가 된다. "오늘 블로커가 뭐야?"에 그럴듯하게 답하는 에이전트와, 흩어진 소스를 끝까지 훑어 하나도 빠뜨리지 않는 에이전트는 전혀 다른 물건이다.

주석

  • 장면 출처: 장면은 SAPIEN 렌더러를 ManiSkill3로 구동해 만들었고, 원본 레이아웃과 물체 배치를 그대로 유지했다. 출처는 iTHOR·RoboTHOR·ArchitecTHOR·ReplicaCAD·ProcTHOR다. 다만 원논문이 출처별로 밝힌 장면 수(iTHOR 32, RoboTHOR 12, ArchitecTHOR 10, ReplicaCAD 6, ProcTHOR 30)를 더하면 90개로, 본문·표에서 쓰는 전체 장면 수 80개와 맞지 않는다. 원논문 스스로 이 둘을 조정하지 않았으므로, 출처별 구성은 확정된 것으로 보기 어렵다.
  • 목표 총수와 반복 물체 비율: 원논문 §2.2는 목표 총수를 3,410개라고 적지만, 함께 제시한 구성(12개 장면×35개+68개 장면×40개)을 더하면 3,140개다. 이 글은 구성에서 나오는 3,140개를 총수로 삼았다. 반복 물체(같은 장면에 똑같이 생긴 물체가 여럿)는 1,489개이고, 3,140개를 분모로 하면 약 47.42%다. 원논문은 이 비율을 43.3%로 적었으나, 두 총수(3,140 기준 47.42%, 3,410 기준 43.66%) 어느 쪽으로도 그 값이 나오지 않아 원논문 안에서 수치가 어긋난다.
  • 도구 열 가지: 목록 조회(list_entities), 카메라 상태 확인(get_camera_pose, get_camera_intrinsics), 이동·회전(set_camera_position, move_camera, rotate_camera), 촬영(capture_image), 좌표 추정(triangulate_observations), 제출(submit_positions), 종료(finish_mapping).
  • 평가 모델: GPT-6 Astra, GPT-6 Sol, Claude Opus 5.5, Claude Sonnet 5.5, Kimi-K3, Qwen3.8-Max, DeepSeek-V4.1-Flash. 본문 수치는 xhigh 설정 기준이다.
  • 재현성: 이 글은 논문이 보고한 수치를 그대로 옮긴 것으로, 수치의 재현을 보증하지 않는다. 벤치마크 자체가 새것인 만큼 후속 모델·방법과의 비교가 쌓여야 숫자의 의미가 굳는다.

참고자료