LLM에 대화 기록 전부 먹이는 건 끝났다: 구글 SKILL.state로 토큰 94% 줄인 방법
안녕하세요! 최근 AI 에이전트를 개발하고 운영하시는 분들이라면 누구나 공감할 만한 가장 큰 고민거리가 있죠. 바로 끝없이 치솟는 API 비용과, 세션이 길어질수록 에이전트가 길을 잃고 헤매는 ‘컨텍스트 오염(Context pollution)’ 문제입니다.
지금까지 우리는 에이전트의 성능을 높이기 위해 컨텍스트 윈도우 크기를 늘리는 데 집중해 왔어요. 하지만 최근 구글 연구진이 발표한 논문은 이러한 기존의 상식에 정면으로 도전합니다. 대화 기록을 통째로 유지하는 대신, 필요한 정보만 ‘상태(State)’로 남기고 과거의 기록은 과감히 버리는 ‘SKILL.state’ 기법을 제안했거든요.
오늘은 이 논문이 왜 AI 에이전트 메모리 아키텍처의 패러다임을 바꿀 수 있는지, 그리고 실무에 적용할 때 어떤 점을 주의해야 하는지 자세히 파헤쳐 볼게요.
1. 무한 컨텍스트 윈도우의 함정과 패러다임의 전환
AI 에이전트가 다단계 워크플로우를 수행할 때, 기존의 LangGraph 같은 프레임워크 스타일은 주로 ‘대화 기록(History)’ 전체를 컨텍스트에 누적해서 전달하는 방식을 취해왔습니다. 에이전트가 과거에 무슨 일을 했는지 잊지 않게 하려는 의도였죠.
하지만 이 방식은 치명적인 단점이 있습니다. 세션이 길어질수록 컨텍스트 윈도우 한계에 부딪히게 되고, 불필요한 정보까지 섞여 들어가며 추론 성능이 떨어집니다. 무엇보다 매번 방대한 토큰을 처리해야 하니 API 요금이 기하급수적으로 늘어나게 되죠. 개발자들 사이에서도 이른바 ‘컨텍스트 윈도우 과부하(Context window overload)’ 현상에 대한 피로감이 커지고 있었습니다.
구글 연구진이 제안한 SKILL.state는 이 문제를 구조적으로 해결합니다. 핵심 원리는 아주 단순하면서도 강력한데요. 에이전트가 추론 과정에서 대화 기록 전체를 유지하는 대신, 현재의 구조화된 상태(structured state)와 최신 관측값만을 입력으로 받고 이전 기록은 폐기해버리는 것입니다. 에이전트는 향후 단계에 필요하다고 판단되는 정보만을 스스로 골라내어 상태(state)에 기록합니다.
2. 압도적인 Gemini-3-Flash 벤치마크 결과
그렇다면 이 새로운 구조가 실제로 얼마나 효과가 있었을까요? 구글 연구진은 Gemini-3-Flash 벤치마크를 통해 100단계에 이르는 복잡한 웨어하우스 작업(Warehouse task)을 테스트했습니다.
결과는 놀라웠습니다. 전체 대화 기록을 유지하는 기존의 LangGraph 스타일 베이스라인은 무려 1,062,387 토큰을 사용했고, 정확도는 0.91에 그쳤습니다. 반면 SKILL.state 기법을 적용한 에이전트는 단 65,408 토큰만을 사용하면서도 정확도는 0.94로 오히려 소폭 상승했습니다.
- 기존 베이스라인: 1,062,387 토큰 (정확도 0.91)
- SKILL.state: 65,408 토큰 (정확도 0.94)
결과적으로 기존 대비 토큰 사용량을 94%(약 16배)나 절감한 것입니다. 비용은 16분의 1로 줄이면서 정확도는 더 높아졌으니, LLM 에이전트 비용 최적화 측면에서 가히 혁신적인 수치라고 할 수 있죠.
3. 업계의 반응과 SKILL.state가 가진 명확한 트레이드오프
이 94%라는 극적인 토큰 사용량 절감 수치가 발표되자, Reddit(r/artificial) 등 글로벌 AI 커뮤니티는 비용 절감 가능성에 놀라워하며 큰 화제로 삼았습니다. 단순히 프롬프트를 깎거나 컨텍스트 윈도우를 늘리는 1차원적인 해결책이 아니라, 에이전트의 상태를 채팅 기록과 분리하여 명시적이고 영구적으로 관리하는 근본적인 아키텍처 변화가 필요하다는 업계의 지적과도 정확히 일치했기 때문이죠.
하지만 무조건 장점만 있는 것은 아닙니다. 기술 매체인 daily.dev는 이를 두고 ‘유연성을 희생하고 효율성을 얻는 설계적 트레이드오프(Trade-off)’라고 분석했습니다. 재고 관리나 복잡한 다단계 워크플로우처럼 중간 상태 스키마가 잘 정의된 작업에는 매우 적합하지만, 그렇지 않은 경우에는 리스크가 따릅니다.
커뮤니티에서도 현실적인 우려가 제기되었는데요. 에이전트가 미래에 어떤 정보가 필요할지 미리 완벽하게 예측해서 상태(State)에 기록해두지 못하면, 결국 과거 기록이 지워졌기 때문에 해당 정보를 처음부터 다시 검색(retrieve)해야 한다는 것입니다. 예측에 실패했을 때 치러야 하는 페널티가 존재하므로, 실효성이 떨어질 수 있다는 회의론도 존재합니다.
4. 실무 도입 전 체크해볼 심화 질문들 (FAQ)
이러한 구조적 변화를 프로젝트에 도입하려고 할 때, 많은 개발자분들이 아래와 같은 실무적인 궁금증을 가지실 텐데요. 리서치 과정에서 자주 누락되지만 반드시 짚고 넘어가야 할 두 가지 질문을 정리해 보았습니다.
Q. 미리 정의된 스키마(Schema)에 맞지 않는 예기치 못한 변수나 정보가 긴 세션 중에 발생했을 때, SKILL.state 아키텍처는 구체적으로 어떻게 이를 처리하나요?
논문의 핵심은 에이전트가 스스로 판단해 유용한 정보를 기록한다는 점입니다. 하지만 스키마가 지나치게 경직되어 있다면 예기치 못한 정보를 담아내기 어렵습니다. 따라서 실무에 적용할 때는 필수적인 정형 데이터 필드 외에도, 에이전트가 자유롭게 메모를 남길 수 있는 유연한 ‘자유 양식(Free-text) 메모리 필드’를 상태 스키마 내에 함께 설계해 두는 것이 안전한 완충재 역할을 할 수 있습니다.
Q. 상태(state)를 성공적으로 업데이트하고 검증(validate)하는 데 사용된 구체적인 프롬프트 구조나 시스템 인스트럭션 원문은 무엇인가요?
에이전트가 과거 기록 없이도 올바르게 다음 행동을 결정하려면, 시스템 인스트럭션이 기존보다 훨씬 더 정교해야 합니다. ‘현재 상태를 기반으로 다음 액션을 결정하라’는 지시뿐만 아니라, ‘이번 관측값에서 향후 작업에 필요할 수 있는 단서를 추출해 상태를 업데이트하라’는 명시적인 상태 관리 프롬프트가 필수적으로 포함되어야 합니다. (정확한 인스트럭션 원문은 구글의 공식 논문 부록에서 확인하실 수 있습니다.)
마치며: 이제는 ‘상태(State)’ 중심으로 재설계할 때
구글의 SKILL.state 논문은 우리에게 명확한 메시지를 던지고 있습니다. 에이전트가 똑똑해지기를 바라며 모든 대화 기록을 욱여넣는 방식은 이제 수명을 다했다는 것이죠.
만약 현재 개발 중인 AI 에이전트가 긴 세션에서 자꾸 환각(Hallucination)을 일으키거나 감당하기 힘든 API 비용을 발생시키고 있다면, 지금 사용 중인 LangGraph 상태 관리 방식이나 메모리 아키텍처를 점검해 볼 필요가 있습니다. 대화 기록에 의존하는 방식을 멈추고, 에이전트가 스스로 구조화된 상태를 업데이트해 나가는 State-driven 아키텍처로의 전환을 작은 테스트부터 시작해 보세요. 비용은 줄이고 성능은 높이는 새로운 돌파구가 되어줄 거예요!
