AI 에이전트가 "스스로 자료를 조사한다"고 할 때, 우리는 보통 검색창에 질문을 넣고 상위 몇 개 링크를 요약하는 장면을 떠올린다. 이 논문이 던지는 과제는 그 수준을 한참 넘어선다. 영상 한 편에서 단서를 뽑고, 살아있는 웹 — 지금 이 순간에도 바뀌는 실제 웹사이트들 — 을 돌아다니며 서로 다른 사이트·문서·데이터셋을 직접 열어 증거를 잇고, 끝내 사실로 검증되는 답 하나에 도달하라는 것이다.
여기서 딥서치(Deep Search)란 AI가 스스로 검색하고 자료를 열어 증거를 모아 답을 찾는 조사 과정을 가리킨다. 연구진은 이런 딥서치 과제 200개를 모은 시험 세트(벤치마크) OpenDS-World를 만들고, 12개 최신 모델과 사람에게 같은 과제를 풀렸다. 단, 손에 쥐여 준 도구는 달랐다 — 모델에겐 검색·브라우저 같은 조사 도구를, 사람에겐 평범한 브라우저 하나만. 가장 잘한 모델(GPT-6 Astra)이 39.0%, 사람은 1,000번의 독립 시도에서 평균 21.1%를 맞혔다. 둘 다 절반에 한참 못 미친다.
논문이 드는 예가 선명하다. 통계 사이트 Our World in Data의 한 페이지를 떠올려 보자. 한 화면 안에 설명 글과 차트 그림이 같이 있고, 그 아래에는 같은 숫자를 담은 데이터 파일이 여러 형태로 걸려 있다.
여기서 '어떤 지역의 몇 년도 수치 하나'를 꺼내야 한다고 해보자. 그 숫자는 화면에 바로 떠 있지 않다. 지역을 고르고, 기간을 지정하고, 그렇게 걸러진 표 파일을 내려받아 그 안에서 필요한 값을 집어내야 비로소 답이 나온다. 사람이라면 몇 번 클릭하고 눈으로 훑으면 끝낼 일이다.
하지만 에이전트에게는 매 단계가 판단이다. '지금 무엇을, 어떻게 열어야 하는가'를 스스로 정해야 하는 미로다. 클릭 하나하나는 익숙해 보여도, 그 익숙한 동작을 어떤 순서로 몇 번 이어 붙여야 답에 닿는지는 전혀 다른 문제다. 그리고 현실의 웹은 대부분 이렇게 생겼다. 같은 사실이 어떤 곳엔 그래프 이미지로, 어떤 곳엔 팟캐스트 음성으로, 또 어떤 곳엔 내려받아야만 열리는 데이터 파일로 흩어져 있다.
기존의 딥서치 평가도 이런 어려움을 외면한 건 아니다. 이미지·영상에 담긴 정보, 동적인 인터페이스를 조작해야 하는 탐색, 여러 웹사이트를 오가는 상호작용은 저마다 따로 다뤄져 왔다. 열린 웹 검색, 여러 번 주고받는 검색, 여러 출처를 엮는 추론으로도 평가 방식은 꾸준히 발전해 왔다. 다만 이 어려움들을 하나의 과제 안에 한꺼번에 엮어 평가한 사례가 드물었다. 매체·형식·접근 방식이 제각각인 자료를 '열어서 꺼내는' 능력을, 긴 증거 사슬 위에서 통합적으로 요구하는 평가가 비어 있었던 것이다.
OpenDS-World는 이 복잡함을 세 축으로 정리하고, 세 축이 한꺼번에 맞물리도록 과제를 짰다.
앞의 Our World in Data 페이지가 바로 이 세 축을 한 화면에 담고 있다. OpenDS-World가 선을 긋는 지점이 여기다. 세 축을 각각 따로 시험하는 게 아니라, 하나의 연결된 증거 사슬 안에 함께 심어 두었다는 것. 가상 투어를 돌려보고, 조건을 입력하고, 데이터 묶음을 내려받아 그 안의 숫자를 꺼내는 조작이 답으로 가는 길목마다 놓여 있다.
점수를 보기 전에, 무엇을 어떻게 쟀는지부터 짚자. 모델에게는 영상·음성·텍스트로 된 질문만 주어진다 — 정답도, 거기까지 가는 증거의 경로도 알려주지 않는다. 대신 모든 모델에 똑같은 도구(웹 검색, 브라우저 조작, 받아온 자료에서 증거를 꺼내는 처리)와 똑같은 규칙을 준다. 사람에게는 LLM 도구 없이 평범한 브라우저만 쥐여 준다. 답은 '하나로 떨어지는 사실'과 맞는지로 채점한다.
이 조건에서 가장 먼저 눈에 들어오는 건 절대 점수의 낮음이다. 최고 성능 모델 GPT-6 Astra가 200개 전체에서 39.0%에 그쳤다. 사람은 더 낮았다. 50명이 과제당 5명씩 독립적으로 붙은 1,000번의 시도에서 평균 21.1%였다.
두 숫자를 'AI가 사람을 이겼다'로 읽으면 안 된다. 애초에 조건이 다른 별개의 측정이기 때문이다. 39.0%는 한 모델이 200문제를 푼 정확도, 21.1%는 사람 1,000회 시도의 평균이고, 사람은 LLM 도구 없이 맨손으로 붙었다. 모델이 더 높게 나온 건 이 과제군에서 자동 탐색과 대량 열람의 이점이 분명하다는 뜻이지, 조사 능력 일반에서 앞섰다는 뜻은 아니다. 그리고 1등이 39%라는 절대값은, '현실 웹 심층 조사'가 아직 멀었다는 신호다.
사람의 성적을 문제별로 쪼개 보면 난이도가 고르지 않다. 절반이 조금 넘는 과제는 다섯 명 중 누군가는 풀었지만, 나머지 절반 가까이는 다섯 명 모두 손을 들었다. 들인 시간까지 아래 표에 함께 정리했다.
| 지표 | 값 | 읽는 법 |
|---|---|---|
| 다섯 명 중 1명 이상 성공 | 115개(57.5%) | 절반 넘는 과제는 '누군가는 푸는' 수준이다 |
| 다섯 명 전원 실패 | 85개(42.5%) | 그만큼 많은 과제가 아무에게도 안 뚫렸다 |
| 시도당 평균 소요 | 약 38.8분 | 한 문제에 이만큼 매달렸다 |
다섯 명 전원 성공은 1개(0.5%)뿐으로 '쉬운 문제'는 사실상 없었다. 과반(3명 이상) 성공도 29개(14.5%)에 그쳐 '웬만하면 풀리는' 과제는 15%에 못 미친다. 노동량으로 보면 1인당(20문제) 평균 12.92시간·중앙값 9.44시간, 합계 약 646시간이 들었다. 주관적 난이도(0 쉬움~5 어려움)는 평균 3.884·중앙값 4였고, 4~5점이 65.5%(5점 43.0%·4점 22.5%), 0점(쉽다)은 한 건도 없었다.
점수 자체보다 눈여겨볼 관찰이 하나 있다. 도구를 더 많이 호출하고 실행 시간을 더 써도 정확도가 반드시 오르지는 않았다는 것이다. 조사를 자동화할 때 가장 흔한 직관 — '더 많이 검색하게 하면 더 잘 찾겠지' — 를 데이터가 비껴간 셈이다.
왜 그럴까. 여기서부터는 결과를 이해하려는 해석이다(논문이 직접 측정한 건 호출·시간이 정확도와 비례하지 않는다는 사실까지다). 몇 가지 가능성이 겹친다. 하나는 조사가 사슬처럼 이어진다는 점이다. 앞 단계에서 출처를 잘못 고르면, 그 뒤로 아무리 많이 뒤져도 '틀린 답을 떠받치는 근거'만 쌓인다. 검색량이 느는 게 오히려 헛발질의 누적일 수 있다. 하지만 다른 설명도 가능하다. 애초에 어려운 문제라 호출이 늘어난 것일 수도 있고, 자료에 접근하지 못해 같은 시도를 반복하느라 호출만 불어난 것일 수도 있다. 호출이 많다는 사실 하나로는 이 셋을 가를 수 없다. 어느 쪽인지 분간하려면 '어느 단계에서 무엇이 막혔는지'를 단계별로 기록해 봐야 한다 — 이 숙제는 뒤의 「한계와 남은 질문」에서 다시 만난다.
분명한 건, 많이 뒤지는 게 아니라 제대로 뒤지는 게 관건이라는 점이다. 관건은 어느 출처를 열지, 중간에 맞는지 확인하고 넘어갈지, 언제 멈출지 같은 판단에 있다. 저자들도 그 원인을 정보원 선택·도구 조율·검색 전략 조정·긴 호흡의 실행 관리(long-horizon management, 여러 단계에 걸친 조사를 끝까지 끌고 가는 능력)의 한계로 읽는다. 비용·종료 시점·실패 복구·예산 같은 측면의 분석도 함께 담겨 있다.
이런 점수를 받아내려면 과제부터 특별하게 만들어야 한다. OpenDS-World 설계의 핵심은 과제를 거꾸로 짓는다는 점이다. 보통은 질문을 먼저 만들고 답을 찾지만, 여기서는 증거의 사슬을 먼저 엮은 뒤 그 사슬을 뒤집어 질문으로 만든다. 말로만 들으면 추상적이니, 설명을 위한 가상의 사례를 하나 세워 따라가 보자. 영상에 어떤 건물이 등장한다고 하자.
1단계 — 출발점 잡기(현실 앵커, Real-World Anchor). 모든 과제는 공개된 영상 한 편에서 출발한다. 주석자가 화면과 소리를 함께 분석해 '이 영상에서만 알아낼 수 있는' 대상 하나를 집어낸다. 우리 예에서는 화면 속 그 건물이다. 핵심 조건은, 그 건물이 영상 페이지에 적힌 글만 읽어서는 알 수 없고 반드시 영상·음성을 봐야 특정된다는 것. 그래야 과제가 단순 텍스트 검색으로 풀리지 않는다. 이렇게 잡은 건물은 Wikidata 항목 하나에 유일하게 대응되어야 한다. Wikidata는 세상의 인물·장소·사물마다 고유 번호를 붙여 정리해 둔 공개 데이터베이스인데, 여기 하나로 못박아 두면 '그 건물'이 누가 봐도 딱 하나의 대상으로 정해져 나중에 답이 애매해지는 걸 막는다.
2단계 — 사슬 늘리기(웹 증거 확장, Open-Web Evidence Expansion). 그 건물에서 출발해, 주석자가 검색으로 다음 대상을 찾아 잇는다. 이를테면 그 건물의 설계자(인물)를 확인하고, 다시 그 설계자의 다른 작품(대상)으로 넘어가는 식이다. 한 마디를 넘어갈 때마다 모달리티·형식·접근 유형이 다양해지도록 자료를 일부러 고른다. 그리고 각 마디는 한 출처에만 기대지 않고 여러 독립 출처로 교차 확인한다. 이 과정을 안정적인 종착점에 닿을 때까지 이어 간다.
3단계 — 질문으로 뒤집기(Question Inversion). 마지막 대상을 정답으로 두고, 지금까지 쌓은 사슬 전체를 서로 맞물리는 조건들로 바꿔 질문을 만든다. 중간의 건물·설계자·작품은 이름을 그대로 드러내지 않고, 앞선 증거에서 유추해야 하는 '간접 지칭'으로 가린다. 단서 하나하나는 답을 직접 가리키지 않지만, 조건이 겹칠수록 후보가 좁혀져 결국 답 하나로 모인다. 명시된 단어를 그대로 검색해서는 풀리지 않고, 중간 대상들 사이의 숨은 연결을 복원해 사슬을 되짚어야만 풀리는 것이다.
여기에 검수가 두 겹 붙는다. 10명의 독립 리뷰어가 보존된 출처 링크로 사슬을 되밟으며, 증거가 타당한지(사실 정확성, 복수 출처 교차확인, 마디 간 연결의 근거)와 과제가 타당한지(질문의 명확성, 조건의 일관성, 답의 유일성)를 점검한다. 사실 오류·증거 부족·답이 여럿인 경우는 버린다. 이 필터를 통과한 200개만 최종 벤치마크에 남았다.
평가는 12개 모델에 똑같은 도구와 똑같은 규칙을 주고 돌린다. 도구 접근권을 통일했기에, 성적 차이가 '좋은 도구를 썼느냐'가 아니라 '어떻게 조사했느냐'에서 온다는 걸 가려 볼 수 있다. 그래서 이 점수가 재는 건 '한 번의 검색 실력'이 아니다. 여러 매체·형식·조작을 매 단계 조율하며 긴 사슬을 끝까지 끌고 가는 능력이다. 실제로 개별 과제의 82.5%가 두 개 이상의 모달리티를 섞어 쓴다. 자료가 무엇을 얼마나 포괄하는지는 아래 표에 정리했다.
| 항목 | 값 | 읽는 법 |
|---|---|---|
| 주석된 자료 항목 | 787개, 과제당 평균 3.94개 | 한 문제를 풀려면 평균 네 곳 가까이 거쳐야 한다 |
| 포괄 범위 | 4개 모달리티·42개 형식·7개 접근 유형 | 매체뿐 아니라 파일 구조와 조작 방식까지 넓게 깐다 |
| 모달리티 등장률 | 텍스트 99.5%·이미지 44.5%·비디오 35.5%·오디오 16.0% | 텍스트는 거의 늘 끼지만, 증거는 텍스트에만 있지 않다 |
저자들이 분명히 인정하는 한계는, 현재 에이전트들이 도구 조율과 긴 호흡의 실행 관리에서 계속 흔들린다는 점이다. 모델마다 전략이 크게 갈리고 그 전략이 정확도로 이어지지 않는다는 건, 아직 안정적인 방법이 정립되지 않았다는 뜻이다.
설계에서 오는 한계도 있다. 하나는 재현성이다. 과제가 살아있는 웹을 전제로 하는 만큼, 시간이 지나면 페이지가 바뀌거나 사라질 수 있다. 연구진은 출발점 영상을 아카이브해 과제 입력과 함께 배포한다고 밝혔지만, 사슬 중간의 외부 자료까지 모두 고정하기는 본질적으로 어렵다. 다른 하나는 답의 성격이다. 답이 유일한 사실 하나로 떨어지도록 깎아낸 설계는 채점을 깨끗하게 만들지만, 실제 조사에서 흔한 '정답이 여럿이거나 판단이 필요한' 질문은 평가 범위 밖에 둔다. 영상에서 출발한다는 공통 형식 자체도 입력에 특정한 편향을 준다.
그리고 39%든 21%든, 이 점수는 '어느 단계에서 왜 무너지는가'까지 알려주지는 않는다. 앞서 호출 수만으로는 헛발질인지 난이도인지 접근 실패인지 가릴 수 없다고 했는데, 바로 그 분간이 여기서도 걸린다. 사슬의 어느 마디에서 끊기는지, 모달리티를 바꾸다 막히는지 상호작용 조작에서 막히는지는 이 결과만으로 구분하기 어렵다. 그 실마리는 도메인별·속성별·영상 길이별 분석을 함께 봐야 가려진다.
이 결과를 온틀의 조사 기능에 적용한다면 어떻게 될까. 여기서부터는 논문의 결론이 아니라 우리의 판단이다.
온틀의 AI PM에게 이런 지시가 들어왔다고 하자. "경쟁 서비스 세 곳의 요금제를 분기별 추이까지 정리해줘." 현실에서 이 정보는 한 곳에선 제품 소개서 PDF 안의 표에, 한 곳에선 지역과 좌석 수를 입력해야 숫자가 나오는 가격 계산기 뒤에, 또 한 곳에선 유튜브 데모 영상의 화면 자막에 흩어져 있다. 상위 검색 링크만 요약해서는 닿지 못하는, 앞서 본 '여러 매체 + 조작이 필요한 접근'이 겹친 과제다.
게다가 '분기별 추이'는 과거의 값을 요구한다. 지금 화면의 가격이 아니라, 각 분기에 어떤 지역·좌석 조건에서 얼마였는지, 그 숫자를 어디서 봤는지까지 남겨야 비로소 '추이'가 된다. 조건 하나만 어긋나도 서로 다른 기준의 숫자를 한 줄에 늘어놓는 셈이 된다.
그래서 우리가 택한 설계는 이렇다(현재 구현된 방식이 아니라, 이 논문을 읽고 세운 방향이다). 긴 조사를 한 방에 끝내는 똑똑한 에이전트에 맡기지 않고, 마디마다 끊어 검증하는 체크포인트형 파이프라인으로 짠다. PM 에이전트가 분기별 수치를 받아올 때 각 값에 조회 조건(지역·좌석·시점)과 출처 링크를 함께 달고, 교차 확인이 안 된 값은 '미확인'으로 표시해 사람 PM에게 올린다.
중요한 건 못 채운 경우를 어떻게 다루느냐다. 특정 분기의 과거 가격을 끝내 못 찾았다면 빈칸이 아니라 '확보 실패'로 남기고, 출처는 찾았지만 좌석 조건이 안 맞는 숫자라면 '조건 불일치'로 따로 표시한다. 그래야 사람이 무엇을 더 확인해야 할지 한눈에 들어온다.
이렇게 하면 사람 PM은 전체를 처음부터 뒤지는 대신 표시된 부분만 들여다보면 된다. 검토 시간이 크게 줄 것이라 기대하지만, 이건 아직 우리가 검증해야 할 가설이지 측정된 효과는 아니다. 적어도 자동화가 사람의 일을 지우는 대신, 사람이 판단할 지점을 또렷하게 남긴다는 방향만큼은 분명하다.
조사 자동화를 점검할 때 실제로 확인해 볼 항목이다.
형식은 자료가 담긴 파일·데이터 구조를 말합니다 — 웹페이지, 문서, 그림·소리 파일, 그리고 내려받아 전용 도구로 열어야 하는 데이터 파일까지 폭이 넓습니다. 접근 유형은 증거를 꺼내기 위한 조작 방식의 분류로, 페이지 이동·조건 입력·기간 지정·화면 조작·구조화 질의·자원 다운로드 등을 가리킵니다. 핵심은, 같은 '텍스트'라도 어떤 구조에 어떤 방식으로 접근해야 하느냐가 제각각이고, 이 벤치마크가 그 폭을 일부러 넓게 깔았다는 점입니다.