에이전트가 데모를 벗어나면 '상태(state)' 관리가 얼마나 중요한지 다들 간과하는 것 같다
I think people underestimate how much “state” matters once agents leave the demo stage
핵심 요약
데모와 달리 실제 운영 환경은 복잡한 상태 관리 문제로 가득하며, 에이전트의 성능은 지능보다 환경 제어 능력에 좌우됨.
- 데모와 운영의 차이 — 데모는 항상 깨끗한 상태에서 시작하지만, 운영 환경은 온갖 데이터와 세션 잔재가 쌓여 혼란스러움.
- 추론 실패의 원인 — 많은 에이전트의 지능적 오류는 사실 지능 부족이 아니라 상태 관리 실패에서 비롯됨.
- 튜토리얼의 한계 — 대부분의 튜토리얼은 프롬프트만 강조할 뿐 상태 복구, 재시도, 격리 같은 핵심적인 운영 기술을 다루지 않음.
- 상태 관리의 중요성 — 안정적인 에이전트는 더 똑똑한 게 아니라, 더 깨끗한 환경과 엄격한 상태 제어 하에서 작동함.
데모에서 에이전트는 매번 새로 시작하기 때문에 엄청나게 똑똑해 보입니다:
깨끗한 컨텍스트
깨끗한 브라우저 상태
깨끗한 메모리
깨끗한 입력값
운영 환경은 정반대죠 lol
며칠 지나면 갑자기 이런 상황이 발생합니다:
- 완료되지 않은 작업들
- 만료된 세션
- 충돌하는 메모리
- 이전 실행에서 발생한 재시도
- 이상한 상태의 브라우저 탭
- 워크플로우 도중에 사용자가 변경한 사항들
이제 에이전트는 쌓여가는 혼돈 속에서 작동해야 합니다.
최근에 로직 자체는 완벽한 워크플로우를 다룬 적이 있는데, 만료된 세션 하나가 에이전트로 하여금 페이지를 잘못 읽게 만들었고, 그게 메모리를 오염시켜서 몇 시간 동안 이후의 결정에 영향을 준 적이 있습니다.
그때 깨달았죠:
많은 "추론 실패"는 사실 상태 관리 실패입니다.
신뢰할 수 있어 보이는 에이전트들은 보통 더 똑똑한 게 아닙니다. 그냥 더 깨끗한 환경과 더 엄격한 상태 제어 하에서 작동할 뿐이죠.
솔직히 대부분의 튜토리얼이 여기서 완전히 무너집니다. 프롬프트와 오케스트레이션 다이어그램은 보여주지만 다음은 건너뛰거든요:
- 상태 복구
- 재시도
- 정리
- 실행 간 격리
- 작업 후 검증
이게 사실상 가장 어려운 부분인데 말이죠 lol
저도 브라우저 워크플로우에서 이 문제에 크게 부딪혔습니다. 더 제어된 브라우저 레이어로 이동하고 Browser Use나 hyperbrowser 같은 설정을 실험해 본 게 큰 도움이 됐는데, 실행 간 상태가 훨씬 예측 가능해졌기 때문입니다.
운영 환경의 에이전트는 지능보다는 시간이 지남에 따라 엔트로피를 관리하는 게 더 중요하다는 느낌이 들기 시작하네요.
