챗봇에게 "근처 맛집 좀 찾아줘"라고 했다가, 몇 마디 뒤 "아니, 조용한 카페로 바꿔줘"라고 말을 바꾼 적이 있을 것이다. 이때 챗봇은 어디까지 기억하고, 무엇을 버려야 할까? 사람이라면 '맛집'은 이미 폐기된 요구라는 걸 안다. 그런데 LLM 에이전트(사람 대신 작업을 수행하는 AI)는 종종 이미 버려진 요구를 붙들고 최종 답을 낸다. 연구진은 이 실패를 '의도 표류(intent drift)' — 바뀐 대화 속에서 낡은 의도가 결과를 오염시키는 현상 — 라고 부른다.
이 연구가 처음으로 그 실패를 제대로 측정했다. 검증 가능한 과제를 통제된 대화로 바꾸는 벤치마크 IntentFlux(여기서 벤치마크란 성능을 재는 표준 시험 문제집)로 수치화하고, 생성 직전에 '지금 유효한 요구사항'을 명시적으로 챙기는 StateForge로 손실의 일부를 되돌렸다.
실제 대화는 한 번에 깔끔하게 떨어지지 않는다. 사용자는 먼저 뭔가를 시키고, 나중에 값 하나를 고치고, 제약 하나를 거둬들이고, 마지막에 "그럼 그걸로 해줘"라고 한다. 에이전트는 이 흐름에서 어떤 조각이 아직 살아 있는 요구인지를 스스로 가려내야 한다. 이미 교체되거나 철회된 조각이 최종 답이나 도구 호출에 계속 영향을 주면, 그게 의도 표류다.
여기서 흔한 오해 하나를 짚고 넘어가자. 의도 표류는 "모델이 대화를 까먹는 것"이 아니다. 오히려 반대다. 폐기됐어야 할 정보를 또렷이 기억하고 적극적으로 사용해서 결과를 틀리게 만드는 실패다. 망각이 아니라 오사용인 셈이다.
기존 멀티턴(여러 차례 주고받는) 대화 평가도 이 문제의 언저리는 건드렸다. 정보를 조금씩 쪼개 흘리면 모델이 과제를 놓친다는 연구(Laban et al., 2025), 인자 공개·수정·과제 전환을 더하면서 원래 채점기를 유지한 평가(Tack et al., 2026)가 있었다. 하지만 이들은 "에이전트가 결국 바뀐 과제를 따라갔는가"를 볼 뿐, 낡은 의도가 답을 망친 실패를 다른 멀티턴 오류와 떼어 보지는 못했다. 이걸 똑바로 재려면 두 가지가 동시에 필요하다. 최종 의도가 무엇인지 확실히 알고 있어야 하고, 낡은 정보를 잘못 쓰면 과제 결과가 실제로 달라지도록 설계해야 한다.
IntentFlux의 발상은 단순하다. 정답 채점기가 이미 존재하는 과제(코드, 수학, SQL, 데이터-텍스트 변환, 요약, 도구 사용)를 가져와, 그 과제를 '의도가 변하는 대화'로 분해한다. 핵심은 원래 채점기를 그대로 보존한다는 점이다. 대화가 아무리 꼬여도 정답 기준은 처음 과제의 것 그대로이므로, 점수가 떨어졌다면 그건 과제가 어려워져서가 아니라 대화 구조 때문이라고 말할 수 있다.
낡은 정보를 심는 방식이 영리하다. 두 종류인데, 예시부터 보자.
이 마지막 조건이 중요하다. 거둬들인 제약이 단어만 안 맞는 수준이 아니라 채점에 직접 영향을 주는 것만 남기기 때문에, 에이전트가 낡은 미끼를 붙들고 있으면 반드시 점수로 드러난다. 낡은 상태를 '썼는지 안 썼는지'를 과제 성공 여부로 테스트할 수 있게 만든 것이다.
측정 설계도 깔끔하다. 같은 최종 과제를 (1) 단일 턴으로 바로 주는 clean 조건과 (2) 의도가 변하는 대화에서 복원해야 하는 drift 조건으로 짝지어 비교한다. 두 조건의 완전 정답률(현재 진짜 의도 기준으로 완벽히 맞힌 비율) 차이가 의도-표류 격차(IDG)다. 턴 수가 늘어난 것 자체가 원인일 가능성을 걸러내려고, 의도 수정 없이 턴만 늘린 대조군도 따로 뒀다.
처방이 StateForge다. 이름 그대로 상태를 '벼려낸다'. 과제를 푸는 일과 의도를 관리하는 일을 분리해서, 별도의 추적기(tracker) 모델이 폐기된 의도 항목과 거기서 파생된 결론을 걸러내 '지금 유효한 상태'를 추정한 뒤, 그 유효 상태를 기존 대화 이력에 명시적으로 덧붙여 실행 에이전트에게 함께 넘긴다. 폐기된 정보를 상태에서 덜어내는 것이지, 실행 모델의 전체 입력에서 대화 이력까지 들어내는 것은 아니다. 답을 만들기 전에 책상 위에 '지금 유효한 요구사항' 메모를 한 장 올려두고 시작하는 셈이다.
수치는 초록과 본문에 명시된 것만 인용한다. 핵심 결과는 세 가지다.
| 실험 | 조건 | 평균 과제 점수 |
|---|---|---|
| 627개 보정 풀 | 쉬움 → 어려움 | 0.476 → 0.384 |
| General-Test(125과제) | 기본 멀티턴 → StateForge | 0.367 → 0.467 |
첫째, 낡은 정보가 쌓일수록 성적이 떨어졌다. 627개 과제를 대상으로, 대화에 폐기·철회된 정보가 많아지도록 난이도를 올렸더니 평균 점수가 0.476에서 0.384로 내려갔다. 다만 이 실험은 변형·미끼·길이를 하나하나 떼어낸 것이 아니라 '낡은정보 부하'를 통째로 올린 것이므로, "낡은 정보가 많아지면 성능이 떨어진다"까지는 말할 수 있어도 어느 요인이 얼마나 기여했는지는 이 숫자만으로 가를 수 없다.
둘째, 떨어진 이유는 대화가 길어서가 아니라 의도가 바뀌어서였다. 최근 LLM 여덟 종 전부에서, 같은 최종 과제라도 대화에서 복원해야 할 때(drift)가 단일 턴으로 줄 때(clean)보다 완전 정답률이 뚜렷이 낮았다. 반면 의도 수정 없이 턴만 늘린 대조군은 단일 턴과 비슷했다. 채점 기준을 처음 과제에 고정해 두었고 길이 대조군까지 함께 봤기 때문에, 이 하락은 과제 난이도나 턴 수가 아니라 의도 변경에서 온다고 비교적 강하게 말할 수 있다.
셋째, 고치긴 했지만 완전히는 아니었다. 자연스레 나오는 반론 — "대화 이력을 그냥 요약·압축하면 되지 않나?" — 부터 짚자. 논문은 이력만 줄이는 외부 보조 장치 두 종(굴림 요약, 2단계 압축)을 시험했지만 손실이 안정적으로 복구되지 않았다. 압축은 "무엇이 남았나"는 줄여주지만 "남은 것 중 무엇이 아직 유효한가"는 풀어주지 않기 때문이다. StateForge는 바로 그 유효성 판정을 명시적으로 떠안아 General-Test 평균을 0.367에서 0.467로 끌어올렸다. 그런데 여기서 한 발 더 나간 진단이 흥미롭다. 추정한 상태 대신 정답 최종 의도를 그대로 주입해도 성능은 더 오르되 단일 턴 clean 점수까지는 회복되지 않았다. 유효 요구사항을 완벽히 알려줘도, 지저분한 대화 이력이 눈앞에 그대로 남아 있으면 모델은 여전히 흔들린다는 뜻이다. 상태 추정 오류는 손실의 '중요한 일부'일 뿐 전부가 아니었다.
한 가지 실용적 발견도 있다. 상태를 관리하는 역할은 과제를 푸는 본 모델보다 훨씬 작은 모델로도 감당할 수 있었다 — 논문은 상태 유지를 더 작은 추적기로 '증류'해 넘길 수 있다고 보고한다. 역할이 좁으면 가벼운 모델로 충분할 수 있다는 신호다.
저자들도 솔직하다. IDG는 "대화에서 최종 의도를 복원하는 데 드는 총손실"을 잡는 지표일 뿐, 변형·미끼·길이 가운데 어느 것이 범인인지 하나씩 분리해 주지는 않는다. 사용자 역할을 흉내 내는 시뮬레이터와 답안을 채점하는 판정자를 모두 한 모델(DeepSeek-V4-Flash)이 맡았다는 점도 검증 타당성 질문을 남긴다. 사후 점검에서 주석된 최종 의도를 General-Test 과제의 95%에서 되살릴 수 있었다는 품질 관리 수치는 있지만, 시뮬레이터가 만든 대화가 실제 사용자 수정의 결을 얼마나 닮았는지는 별개 문제다. 무엇보다 StateForge는 '부분적 완화'다. 정답 상태를 줘도 단일 턴을 못 따라잡는 잔차가 남아 있고, 그 잔차의 정체는 아직 열려 있다.
온틀의 AI PM이 자주 부딪히는 실패가 정확히 이것이다. 요청보드를 떠올려보자.
고객이 월요일에 "엑셀 수집 붙여줘, 네이버 쇼핑 기준으로"라고 적는다. 수요일에 "아 쇼핑 말고 카페24 주문 데이터로 바꿔줘"라고 덧붙인다. 금요일에 "일단 그 일일 알림은 빼고 가자"라며 제약 하나를 거둬들인다. PM이 주말에 실행(개발 task 생성, 배포)에 들어갈 때 유효한 스펙은 '카페24 주문 수집, 알림 제외'다. 그런데 긴 대화 이력을 통째로 읽은 에이전트는 첫 턴의 '네이버 쇼핑'(변형)이나 이미 거둬들인 '일일 알림'(미끼)을 되살려 엉뚱한 task를 깐다. 고객 입장에선 "분명히 바꿨는데 왜 또 그걸로 했냐"가 되고, 신뢰가 깨진다.
이 연구가 그 장면을 두 지점에서 바꾼다. 첫째, 실행 직전에 '현재 유효 요구사항' 상태를 명시적으로 세워두고 거기서 파생된 낡은 결론까지 걷어낸 다음 task를 생성한다. 요청보드의 코멘트 스레드를 단순 요약하는 게 아니라, 교체·철회를 반영한 능동 스펙으로 접어두는 것이다. 둘째, 그 상태 추적을 실행 에이전트와 분리된 작은 모듈로 둘 수 있다. 상태 유지를 더 작은 추적기로 넘길 수 있다는 결과는, 온틀이 전사 모델 라우팅 표준 안에서 상태 유지라는 좁은 역할에 가벼운 모델을 전담 배치하는 설계가 비용 대비 합리적일 수 있음을 시사한다.
다만 정답 상태를 줘도 잔차가 남는다는 경고를 함께 새긴다. PM이 유효 스펙을 완벽히 정리해 넘겨도, 실행 단계가 전체 대화 로그를 그대로 끌어안고 있으면 또 흔들릴 수 있다. 따라서 온틀은 유효 스펙을 세우는 데서 멈추지 않고, 실행 에이전트에 넘기는 컨텍스트 자체를 유효 상태 중심으로 좁히는 방향으로 다음 AI PM 아키텍처를 구체화한다.