Executive Summary

주요 수치

출처: LongDS-Bench (arXiv:2605.30434)

아래 네 숫자가 붕괴의 크기와 원인을 함께 보여줍니다. 앞의 둘은 붕괴가 얼마나 큰지를, 뒤의 둘은 그것이 왜 기억이 아니라 상태 관리의 문제인지를 가리킵니다.

2026년 5월 저장대학교와 앤트그룹 공동 연구진이 공개한 LongDS-Bench는 이제까지의 데이터 분석 벤치마크와 결이 다릅니다. 기존 벤치마크는 대체로 독립된 질문 하나를 던지고 답을 채점합니다. 하지만 현실의 데이터 분석은 그렇게 흘러가지 않습니다. 코호트를 정의하고, 필터를 걸고, 중간 지표를 만들고, 그 정의를 며칠 뒤에 슬쩍 바꾸고, 어제 고정해 둔 버전으로 되돌아가 답하는 일이 여러 턴에 걸쳐 얽힙니다.

연구진은 이 흐름을 재현하려고 실제 Kaggle 노트북에서 68개 과제를 뽑아 멀티턴 대화로 재구성했습니다. 지구과학, 비즈니스, 교육, 스포츠, 사회공헌, 커뮤니티까지 여섯 개 도메인에 걸쳐 있고, 과제당 평균 33턴, 전체 2,225턴 규모입니다. 중요한 것은 이 턴들이 서로 독립적이지 않다는 점입니다. 한 요청은 평균 11.3턴 이전의 상태에 의존했고, 한 턴은 평균 2.9개의 앞선 상태를 동시에 참조해야 했습니다. 앞에서 무엇을 어떻게 정의했는지 놓치는 순간 뒤가 통째로 흔들리는 구조입니다.

연구진은 이렇게 이어지는 작업을 지탱하는 것을 '분석 상태(analytical state)'라고 부릅니다. 단순히 이전에 나온 숫자가 아니라, 어떤 범위에서 어떤 정의와 가정을 걸고 계산했는지의 맥락 전체입니다. 이를테면 "지난 분기 북미 고객 중 재구매자를 제외한 신규 고객의 LTV" 같은 조건들이 턴마다 쌓이면, 에이전트는 지금 어떤 조건이 유효한지를 계속 추적해야 합니다. 과제는 이 상태를 다루는 방식에 따라 다섯 가지 패턴을 담고 있었습니다.

과제 하나에는 평균 5.8번의 Rollback 턴과 8.6번의 Composition 턴이 들어 있었습니다. 되돌아가고 겹쳐 쌓는 일이 예외가 아니라 기본값이라는 뜻입니다. 사람 분석가라면 노트와 코드 셀에 자연스럽게 남겨 두는 맥락을, 에이전트는 매 턴 스스로 붙잡아야 했습니다.

다섯 개 프론티어 모델을 같은 68과제에 올렸을 때, 1등도 겨우 절반 문턱에서 멈췄습니다. Gemini-3.1-Pro가 평균 48.45%로 가장 높았고, 그 뒤로 GPT-5.4, Claude-4.6-Sonnet, Kimi-K2.6, DeepSeek-V4-Pro 순이었습니다. 참고로 이 채점은 사람 검증과 93.11% 일치(Cohen's κ = 0.86)해, 점수 자체를 의심하기는 어렵습니다.

평균값보다 무서운 것은 과제 안에서의 변화입니다. 초반 턴에서는 그럭저럭 맞히던 모델들이, 같은 과제의 후반 턴으로 갈수록 급격히 틀렸습니다. 초반과 후반의 정확도 차이가 거의 47%p에 달했습니다. 앞부분만 지켜본 사람이라면 "쓸 만하다"고 판단했을 바로 그 모델이, 뒷부분에서 조용히 무너지고 있었던 것입니다.

이 대목이 실무에서 특히 위험합니다. 데이터 분석 결과는 대개 마지막 몇 턴의 산출물, 이를테면 최종 집계와 결론에서 나옵니다. 그런데 정확도가 무너지는 지점도 바로 그 후반부입니다. 앞의 탐색은 그럴듯한데 마지막 답이 틀리는 패턴은, 검토자가 알아채기 가장 어려운 실패 형태입니다.

연구진은 실패 사례를 뜯어보고 원인을 크게 두 갈래로 나눴습니다. 코딩·플래닝·도메인 추론 같은 전통적 에러가 31~48%였고, 나머지 52~69%는 긴 작업에서만 생기는 '롱 호라이즌 에러'였습니다. 절반이 넘는 실패가 모델의 지능이 부족해서가 아니라, 이어지는 상태를 다루지 못해 발생했다는 뜻입니다. 이 롱 호라이즌 에러는 다시 세 종류로 갈립니다.

여기서 흥미로운 역설이 드러납니다. 우리가 흔히 걱정하는 것은 "AI가 앞의 내용을 까먹는다"는 쪽입니다. 그런데 정작 그 단순 기억 실패(Context Memory)는 가장 작은 범주였습니다. 정보를 꺼내는 일은 비교적 쉬웠습니다. 진짜로 무너진 곳은 정보를 제대로 적용하는 지점, 즉 어떤 상태가 지금 유효한지 판단하고(State Management) 그것을 다음 계산에 옳게 넘기는(Cascade) 대목이었습니다.

가장 큰 범주인 Cascade Error가 왜 위험한지는 이름 그대로입니다. 초반에 정의 하나를 잘못 잡으면, 그 위에 쌓인 필터와 집계와 결론이 전부 오염됩니다. 후반 정확도가 47%p나 주저앉은 이유가 여기 있습니다. 후반이 특별히 어려워서가 아니라, 초반에 어긋난 상태가 후반까지 흘러와 답을 갉아먹은 것입니다. 한 번의 미세한 상태 드리프트가 뒤의 모든 턴을 조용히 물들입니다.

직관적으로는 이렇게 생각하기 쉽습니다. 후반부가 어렵다면, 에이전트에게 더 많이 생각하고 더 많이 시도할 여유를 주면 되지 않을까. LongDS-Bench의 결과는 그 기대를 정면으로 반박합니다. 연구진은 "추가 스텝이 반드시 성능을 높이지는 않는다"고 못 박습니다.

가장 또렷한 증거가 순위표 안에 있습니다. 테스트한 모델 중 스텝을 가장 많이 쓴 쪽은 Claude-4.6-Sonnet이었습니다. 그런데 그 성적은 훨씬 적게 움직인 Gemini-3.1-Pro보다 낮았습니다. 더 열심히, 더 많이 시도한 모델이 진 셈입니다. 시도 횟수와 정확도가 나란히 가지 않는다는 것은, 병목이 노력의 양이 아니라 다른 곳에 있다는 신호입니다.

연구진의 리셋 실험은 그 다른 곳을 가리킵니다. 에이전트는 후반으로 갈수록 탐색 스텝 자체가 줄어드는 경향을 보였습니다. 초반에 어긋난 상태가 이미 후반 전체를 오염시킨 뒤라, 더 많은 스텝을 준다 한들 잘못된 토대 위에서 헛도는 것입니다. 예산을 키우는 대신 상태를 바로잡는 지점을 만들어야 하는 이유입니다.

이 블로그는 롱 호라이즌 에이전트의 실패를 두 번 다뤘습니다. 한 번은 약한 하네스가 에이전트를 죽인다는 인프라의 문제였고, 다른 한 번은 1년을 버틴 에이전트의 비밀이 똑똑함이 아니라 메모장이었다는 기억의 문제였습니다. LongDS-Bench는 그 흐름의 세 번째 장면입니다. 이번에는 데이터 분석이라는 구체적인 작업에서, 실패의 원인이 스텝 부족도 기억 부족도 아닌 '상태 유지'임을 68과제 2,225턴으로 못 박았습니다.

이를 데이터의 관점에서 읽으면 결론은 분명합니다. 에이전트가 붙잡아야 할 분석 상태 — 정의와 범위, 가정과 중간 결과 — 는 결국 외부에 명시적으로 관리해야 할 데이터입니다. 그 데이터가 어떤 정의로 언제 갱신됐고 어느 버전이 지금 유효한지가 구조화돼 있지 않으면, 아무리 똑똑한 모델이라도 후반부에서 길을 잃습니다. 자율화 시대의 병목은 더 큰 추론력이 아니라, 붙잡을 상태를 얼마나 잘 설계해 두었는가입니다.

그래서 질문은 이렇게 바뀝니다. 지금 우리 팀이 에이전트에게 넘긴 다단계 데이터 작업은, 앞부분이 그럴듯하다는 이유로 뒷부분의 오염을 놓치고 있지는 않은가. 점검할 지점은 세 가지입니다. 중간 정의와 가정을 명시적으로 저장·참조하는 구조가 있는가. 이전 버전으로 되돌아가는 Rollback을 테스트해 봤는가. 그리고 정확도가 초반에만 좋은 것은 아닌지, 후반 턴을 따로 검증하고 있는가. 더 큰 모델로 갈아타기 전에, 붙잡을 상태부터 정돈할 차례입니다.

• 1.Xu, K., Lu, X., Qiao, S., Ding, Z., Xu, H., Liang, L., & Zhang, N. (2026). "LongDS-Bench: On the Failure of Long-Horizon Agentic Data Analysis." arXiv:2605.30434. — 실제 Kaggle 노트북 기반 68개 과제·2,225턴 멀티턴 데이터 분석 벤치마크. 최고 모델 Gemini-3.1-Pro 평균 48.45%, 초반 대비 후반 정확도 약 47%p 급락. 전체 실패의 52~69%가 롱 호라이즌 에러(Cascade > State Management > Context Memory)이며, 추가 스텝이 성능을 보장하지 않음을 확인.