'포스트잇' 한 장으로 100만 토큰을 대체하다? 구글 SKILL.state의 혁신과 숨은 함정
안녕하세요! 최근 AI 에이전트를 개발하거나 백엔드 파이프라인을 구축해 보신 분들이라면 누구나 공감할 만한 가장 큰 골칫거리가 하나 있죠. 바로 눈덩이처럼 불어나는 '토큰 비용'과 'LLM context window'의 한계예요.
복잡한 작업을 수행하는 에이전트는 세션이 길어질수록 대화 기록(History)이 쌓이게 되고, 결국 프롬프트가 기하급수적으로 길어지면서 API 비용 폭탄을 맞거나 모델이 중요한 맥락을 놓치는 현상이 발생하곤 합니다. 그런데 최근 구글 연구진이 이 문제를 아주 우아하게 해결한 **'SKILL.state'**라는 새로운 접근법을 논문으로 발표했어요. 놀랍게도 성능 저하 없이 토큰 사용량을 무려 94%나 줄였다고 하는데요. 과연 어떤 마법을 부린 것인지, 그리고 실무에 바로 적용해도 무방할지 꼼꼼히 파헤쳐 볼게요!
1. 기존 방식(LangGraph) vs 구글 SKILL.state
기존에 널리 쓰이는 LangGraph 스타일의 에이전트 아키텍처는 기본적으로 '모든 대화 기록(History)을 유지'하는 방식을 취해요. 에이전트가 어떤 고민을 했고, 어떤 도구를 썼는지 전체 스크립트를 계속 프롬프트에 누적해서 다음 단계의 입력으로 넘겨주는 식이죠. 당연히 세션이 길어질수록 토큰 낭비가 심해집니다.
반면, 구글이 제안한 SKILL.state는 전체 대화 기록을 과감히 폐기합니다. 대신 '구조화된 현재 상태(State)'와 '최신 관찰(Observation)'만을 입력으로 사용하는 아키텍처를 채택했어요.
이를 두고 한 레딧 유저는 아주 찰떡같은 비유를 남겼는데요. **'에이전트가 무거운 전체 대본을 낑낑대며 들고 다니는 대신, 중요한 것만 쏙쏙 적어두는 포스트잇(sticky note) 한 장만 주머니에 넣고 다니는 것과 같다'**라고 표현했어요. 정말 와닿는 비유죠?
2. 토큰 94% 절감, 그런데 더 똑똑해졌다고?
가장 궁금해하실 부분은 역시 '데이터'일 텐데요. 구글 연구진은 Gemini-3-Flash benchmark를 활용해 100단계에 이르는 복잡한 창고(warehouse) 작업 환경에서 두 방식을 비교 테스트했어요.
- 기존 전체 기록 유지 방식: 1,062,387 토큰 사용 / 정확도 0.91
- SKILL.state 방식: 65,408 토큰 사용 / 정확도 0.94
결과는 놀라웠습니다. SKILL.state는 토큰 사용량을 약 16배(약 94%)나 절감하면서도, 오히려 정확도는 0.94로 기존 방식보다 높게 나타났어요.
어떻게 이런 일이 가능했을까요? SKILL.state 환경에서 에이전트는 추론 과정 중 '미래 단계에 유용할 것 같은 정보'를 스스로 판단해 상태(state)에 기록합니다. 그리고 이전의 낡은 대화 기록은 미련 없이 버리죠. 덕분에 세션이 아무리 길어져도 입력 프롬프트의 크기가 일정하게 유지되는 엄청난 AI Agent token optimization(토큰 최적화) 효과를 누릴 수 있게 된 거예요. 불필요한 과거 정보가 프롬프트에서 사라지니, 모델이 쓸데없는 정보에 주의력을 뺏기지 않아 정확도까지 소폭 상승하는 결과를 낳은 셈입니다.
3. 완벽한 만능키? 전문가들이 말하는 숨은 함정
이처럼 AI 에이전트 비용 절감 측면에서 혁명적인 방법론이지만, 안타깝게도 완벽한 만능키는 아니에요. 이 논문이 발표된 후 업계 전문가들과 커뮤니티에서는 객관적이고 날카로운 분석들이 쏟아져 나왔습니다.
① 유연성(Flexibility)과 효율성(Efficiency)의 트레이드오프
전문가들은 이 설계가 에이전트가 기억해야 할 모든 정보가 '구조화된 상태 스키마' 안에 깔끔하게 담길 수 있을 때만 유효하다고 지적해요. 만약 작업에 구조화된 형식으로 정의하기 힘든 모호하고 복잡한 정보가 포함되어 있다면? 단순히 히스토리를 버리는 것만으로는 시스템이 제대로 유지될 수 없다는 거죠.
② 미래를 예측해야 하는 에이전트
에이전트가 미래 단계에서 '무엇이 필요할지' 미리 이해하고 있어야만 유용한 정보를 상태에 기록할 수 있어요. 만약 중요한 정보를 상태에 적어두는 것을 깜빡했다면, 나중에 그 정보를 찾기 위해 다시 처음부터 검색해야 하는 비효율이 발생할 수 있습니다.
③ '조용한 실패(Quiet Failures)'에 대한 공포
커뮤니티에서 가장 큰 공감을 얻은 우려 사항이에요. 에이전트가 상태를 완벽하게 요약한 것처럼 그럴듯하게 보여주면서도, 실제로는 은밀하게 아주 중요한 제약 조건 하나를 누락해 버리는 '조용한 실패'가 발생할까 봐 두렵다는 반응이 많았어요. 개발자 입장에서는 디버깅하기 가장 까다로운 유형의 오류죠.
④ 보안 취약점 (Prompt Injection)
상태를 지속적으로 업데이트하는 아키텍처 특성상, 외부 입력에 의해 상태 값이 오염될 경우 프롬프트 인젝션 공격에 훨씬 더 취약해질 수 있으니 Agent state management에 각별한 주의가 필요하다는 지적도 제기되었습니다.
💡 자주 묻는 질문 (FAQ)
이쯤 되면 실무 적용을 고민하며 몇 가지 궁금증이 생기실 텐데요. 많은 분들이 놓치기 쉬운 핵심 질문 두 가지를 짚어드릴게요.
Q. 비구조화된 텍스트나 복잡한 맥락이 필수적인 작업(예: 긴 문서 분석, 창의적 글쓰기)에서도 SKILL.state 방식이 기존 기록 유지 방식보다 우수한가요?
A. 전문가들의 분석에 따르면, 그렇지 않을 가능성이 높습니다. 앞서 언급했듯 SKILL.state는 정보가 구조화된 형식에 딱 맞아떨어질 때 빛을 발합니다. 긴 문서의 미묘한 뉘앙스나 창의적인 맥락을 '상태'라는 틀 안에 완벽히 압축하기는 매우 어렵기 때문에, 이런 작업에서는 오히려 맥락이 유실되어 성능이 떨어질 수 있습니다.
Q. 상태(state)를 매 단계 업데이트하고 검증할 때 발생하는 지연 시간(Latency)이나 추가적인 컴퓨팅 비용은 어느 정도인가요?
A. 토큰 비용 자체는 94%가 줄어들지만, 매 스텝마다 에이전트가 '이 정보를 상태에 기록할지 말지'를 판단하고 상태 모델을 업데이트하는 별도의 추론 과정이 필요합니다. 따라서 전체 토큰 비용은 극적으로 감소하더라도, 각 단계별로 발생하는 레이턴시는 시스템 설계에 따라 기존보다 늘어날 수 있다는 점을 아키텍처 기획 단계에서 반드시 고려해야 합니다.
마치며: LangGraph alternative를 찾고 있다면?
구글의 SKILL.state는 무한정 늘어나는 LLM 프롬프트의 굴레를 끊어낼 수 있는 매우 매력적인 대안(LangGraph alternative)입니다. 특히 반복적이고 구조화된 작업(예: 데이터 추출, 시스템 관리, 정형화된 워크플로우)을 수행하는 에이전트라면 당장 도입을 고려해 볼 만큼 압도적인 비용 절감 효과를 자랑하죠.
하지만 반대로 '조용한 실패'나 '유연성 부족'이라는 명확한 한계도 존재합니다. 따라서 성공적인 도입을 위해서는 내 에이전트가 수행하는 작업의 특성을 정확히 파악하고, 상태(state) 스키마를 얼마나 빈틈없이 꼼꼼하게 설계하느냐가 관건이 될 것입니다.
오늘 당장 여러분이 개발 중인 AI 에이전트의 토큰 사용량을 프로파일링 해보시는 건 어떨까요? 불필요한 대화 기록이 컨텍스트 윈도우를 낭비하고 있다면, '포스트잇' 방식의 상태 기반 아키텍처 도입을 테스트해 볼 완벽한 타이밍일지도 모릅니다!
