AI 빌더가 중반부터 무너지는 이유 — StateM 논문이 짚은 자리
1.무슨 논문인가
2026년 8월 15일 arXiv에 올라온 StateM(2608.15089)이며, 8월 28일 기준 허깅페이스 인기 논문 1위입니다. 저자는 Ziheng Qin, Yaxin Lu, Zhangyang Atlas Wang, Kai Wang입니다.
다루는 대상은 ‘오래 걸리는 일’을 맡은 AI입니다. 논문 용어로는 장기 과제(long-horizon) 실행이라고 부릅니다. 터미널에서 실제 작업을 시켜 성적을 매기는 Terminal-Bench 2.1이라는 평가를 썼고, 결과는 이렇습니다.
- GPT-5.5 xhigh — 기준 83.1% → 92.1%
- GPT-5.6 Sol xhigh — 95.3% (원점수 기준)
- DeepSeek-V4 Flash — 82.7% → 88.1%
- BusinessBench — 구조가 맞물리는 계열에서 10.04점 상승
중요한 것은 숫자 자체보다 무엇을 바꿔서 얻었는가입니다. 모델을 더 큰 것으로 갈지도, 추가로 학습시키지도 않았습니다. 논문의 표현대로 “모델 가중치를 바꾸지 않고” 실행을 감싸는 바깥 구조만 손봤습니다.
2.핵심 한 문장
초록에 이런 문장이 있습니다. “장기 과제를 맡은 AI는 그 밑의 모델이 각각의 단계를 풀 수 있는 경우에도 실패할 수 있다.”
읽고 넘기기 쉬운데, 실무에서는 이 문장이 거의 전부입니다. 홈페이지 작업이 어그러졌을 때 우리는 보통 “이 모델이 실력이 부족하구나”라고 판단하고 더 비싼 모델로 갈아탑니다. 논문은 그 진단이 자주 틀린다고 말합니다. 개별 단계 — 버튼 하나 만들기, 폼 하나 붙이기 — 는 이미 충분히 해냅니다. 무너지는 지점은 단계와 단계 사이입니다.
사이에서 사라지는 것이 바로 상태입니다. 30분 전에 “가격표는 3단으로, 문의 버튼은 오른쪽 위 고정”이라고 정했다는 사실. 어제 색상 코드를 바꿨다는 사실. 이 결정들이 대화 기록 어딘가에 묻히면, 다음 요청을 처리할 때 그 부분은 없는 것과 같아집니다.
3.홈페이지 작업에서는 이렇게 나타난다
증상은 대체로 셋 중 하나입니다. 되돌아가기, 반복 수정, 그리고 조용한 누락.
되돌아가기 — 소개 페이지를 고쳐달라고 했더니 지난주에 바꾼 로고 위치가 원래대로 돌아와 있습니다. 새 작업을 하면서 이전 상태를 참조하지 않은 결과입니다.
반복 수정 — 같은 폰트 크기를 세 번째 고치고 있습니다. 첫 번째 지시가 어딘가에 남아 있지 않으니, 매번 새 지시로 취급됩니다.
조용한 누락 — 페이지 다섯 개를 만들라고 했는데 네 개만 생겼고, 완료됐다는 답을 받았습니다. 이 경우가 가장 위험합니다. 눈으로 세어보기 전까지는 알 수 없기 때문입니다.
세 증상 모두 모델이 어려운 문제를 못 푼 사례가 아닙니다. 앞에서 무엇이 끝났고 지금 어느 단계인지를 붙들고 있는 장치가 없어서 생긴 일입니다.
4.논문이 넣은 다섯 부품
StateM은 실행 시점에 다섯 가지를 세워둡니다. 각각을 실무 언어로 옮기면 이렇습니다.
지속되는 상태(durable states) — 대화가 길어져도 남는 기록. 채팅 스크롤이 아니라 별도 파일이나 문서에 적힌 현재 상태입니다.
단계별로 좁힌 맥락(phase-local context) — 지금 단계에 필요한 것만 보여줍니다. 처음부터 끝까지 전부 다시 읽히면 오히려 헷갈립니다.
검증되는 전이(checked transitions) — 다음 단계로 넘어가기 전에 조건을 확인합니다. ‘다 됐습니다’를 그냥 믿지 않는 장치입니다.
복구 가능한 런북(recoverable runbooks) — 중간에 끊겨도 처음이 아니라 끊긴 자리에서 다시 시작할 수 있는 절차서입니다.
버전이 붙은 절차(versioned procedural practices) — 한 번 정한 방식이 다음에도 같게 적용되도록 판을 관리합니다.
다섯 개를 관통하는 발상은 같습니다. 기억을 모델 머릿속에 두지 않고 밖에 적어둔다. 그리고 매 단계 그것을 다시 읽힌다는 것입니다.
5.도구 없이 오늘 흉내 낼 수 있는 부분
러버블이나 볼트 같은 화면 기반 빌더에서도 앞의 두 가지는 바로 따라 할 수 있습니다. 프로젝트 안에 결정 기록 문서를 하나 만들고, 요청할 때마다 그것부터 읽히는 방식입니다.
파일 하나를 이렇게 두고 시작하십시오. 형식은 중요하지 않고, 한곳에 모여 있고 매번 참조된다는 점만 지키면 됩니다.
PROJECT_STATE.md
## 확정 (바꾸지 말 것)
- 브랜드 색 #2B5F44 / 보조 #F6F3EC
- 상단 메뉴: 홈 · 진료안내 · 오시는길 · 문의
- 문의 버튼은 모든 페이지 오른쪽 위 고정
## 완료
- [x] 메인 첫 화면
- [x] 진료안내 페이지
- [ ] 오시는길 (지도 미삽입)
- [ ] 문의 폼 (메일 연동 안 됨)
## 이번 단계에서만 할 일
- 오시는길 지도 넣기. 다른 페이지는 건드리지 말 것.요청문 첫 줄은 매번 같게 씁니다. “PROJECT_STATE.md 를 먼저 읽고, 확정 항목은 바꾸지 마. 이번 단계 항목만 처리해.” 두 번째 문장이 실제로 일을 합니다. 범위를 못 박지 않으면 도구는 주변까지 손보고, 그때 되돌아가기가 생깁니다.
세 번째 부품인 ‘검증되는 전이’도 사람 손으로 대신할 수 있습니다. 완료 보고를 받으면 문서의 체크박스를 직접 채우십시오. 화면에서 눈으로 확인한 것만 체크합니다. 앞서 정리한 블로그의 다른 글에서도 같은 원칙을 썼습니다. 기준은 도구가 뭐라고 답했는지가 아니라 관리 화면에 실제로 잡히는지입니다.
6.$15와 $574.68이 말하는 것
논문에서 가장 눈에 띄는 대비는 정확도가 아니라 비용입니다. StateM 구성은 API 사용료가 약 15달러였고, 비교 기준이 된 GPT 참조 실행은 574.68달러였습니다.
약 38분의 1입니다. 실행 구조를 정리하면 같은 일을 훨씬 적은 왕복으로 끝낸다는 뜻이고, 이 부분은 개인이나 작은 가게 입장에서 더 직접적으로 와닿습니다. AI 빌더의 크레딧이 빨리 닳는 이유 중 상당수가 같은 것을 다시 설명하느라 쓰는 분량이기 때문입니다. 앞의 결정 기록 문서 한 장이 아끼는 것은 시간만이 아닙니다.
다만 이 숫자를 그대로 “내 홈페이지 비용도 38분의 1”로 읽으면 안 됩니다. 벤치마크 환경의 측정값이고, 여기에는 구성 요소를 짜맞추는 사람의 시간이 들어 있지 않습니다.
7.그대로 믿으면 안 되는 부분
발표된 지 2주가 안 된 논문이고, 성적은 저자들이 자기 구성으로 낸 값입니다.
세 가지를 구분해 두는 편이 안전합니다. 첫째, 평가 대상이 터미널 작업이지 홈페이지 제작이 아닙니다. 이 글에서 홈페이지 이야기로 옮긴 것은 진단의 구조이지 수치가 아닙니다. 둘째, 등장하는 모델 이름과 판올림은 빠르게 바뀌므로 오늘의 순위표는 다음 달에 다시 봐야 합니다. 셋째, 독립적인 재현 결과는 아직 쌓이는 중입니다.
그럼에도 실무에 옮길 만하다고 보는 이유는, 이 논문이 없어도 같은 처방이 이미 손해를 줄이고 있기 때문입니다. 결정한 것을 문서에 적고 매번 읽히는 습관은 도구가 무엇이든, 논문 수치가 나중에 어떻게 정정되든 손해 볼 일이 없습니다.
§이 글의 근거
논문 제목과 저자, 공개일, 초록의 문장, 그리고 92.1%·95.3%·88.1%·83.1%·82.7%·10.04점·15달러·574.68달러의 수치는 허깅페이스 논문 페이지에 실린 원문 초록에서 확인했습니다. 인기 순위는 Trending Papers 기준입니다. Terminal-Bench 2.1의 공개 순위표는 tbench.ai에서 볼 수 있습니다.
원문 대조에 관해 밝혀둡니다. arXiv 초록 페이지는 이번 확인 과정에서 직접 열리지 않아, 같은 초록을 싣는 허깅페이스 논문 페이지를 1차 대조 대상으로 삼았습니다. 제출일 표기도 8월 15일과 8월 18일이 함께 보여, 본문에는 두 출처가 일치하는 8월 15일만 적었습니다. 논문 본문의 실험 설계, 벤치마크의 과제 수, 재현 코드의 동작 여부는 확인하지 못해 문장째 뺐습니다. 인용한 초록 문장은 영문 원문을 우리말로 옮긴 것입니다.