OpenClaw의 컨텍스트 관리, 토큰 집약적이고 구조적 결함 있다는 비판 받아

레딧 사용자가 OpenClaw의 아키텍처, 특히 컨텍스트 관리 접근법을 표적으로 한 상세한 비판을 게시했습니다. 이 게시글은 프레임워크가 게으른 전부-아니면-무(全有全無) 컨텍스트 덤프를 통해 LLM의 컨텍스트 창을 '쓰레기 매립지'로 취급함으로써 상태를 비효율적으로 처리한다고 주장합니다.

OpenClaw의 컨텍스트 처리 방식

출처에 따르면, OpenClaw는 적절한 상태 관리와 일시적 상태 격리가 부족합니다. 에이전트가 단계를 밟을 때마다 새로운 액션이 무조건 글로벌 히스토리에 추가됩니다. 세 번의 턴 안에 프롬프트는 다음과 같은 것들로 부풀려집니다:

• 글로벌 시스템 프롬프트
• 사용자의 전체 장기 기억 파일
• 사용 가능한 모든 도구 목록
• 마지막 명령의 원시 출력
• 이전의 모든 액션들

작은 모델들의 문제점

게시글은 Flash나 Mini 변종 같은 더 빠르고 저렴한 모델에서 OpenClaw를 실행할 때 발생하는 일을 설명합니다:

• 작은 모델들은 50,000개 이상의 오래된 터미널 출력, 도구 로그, 글로벌 페르소나 프롬프트에 익사할 때 '중간에서 길을 잃는' 증후군을 겪습니다
• 이 모델들은 문자 그대로 원래 목표를 잊어버립니다
• 작업이 이미 완료되었다는 환각을 일으키거나
• 정확히 같은 인자로 정확히 같은 도구를 호출하는 무한 루프에 갇히게 됩니다

Claude Opus 의존성

이 비판은 OpenClaw의 프론티어 모델 의존성까지 확장됩니다:

• OpenClaw는 에이전트가 '매우 유능하다'고 주장하지만, 이 능력은 Claude Opus 같은 거대한 프론티어 모델에 의지함에서 비롯됩니다
• Claude Opus는 80,000토큰의 '쓰레기 불덩이'를 응시하면서도 79,500토큰의 쓸모없는 역사적 부풀림을 성공적으로 무시하고 다음 단계를 추론할 수 있습니다
• 이는 프레임워크가 잘 구축된 것 같은 착시를 일으키지만, 실제로는 Opus가 아키텍처적 무능함을 가리고 있는 것입니다
• 사용자들은 설계가 잘못된 컨텍스트를 위한 '화려한 쓰레기 필터' 역할을 하는 최첨단 LLM을 사용하기 위해 Opus 등급 API 가격을 지불하게 됩니다

아키텍처 권장사항

게시글은 무력보다는 더 나은 엔지니어링을 주장합니다:

• 간단한 다단계 브라우저나 터미널 작업에 조 단위 파라미터 모델이 필요해서는 안 됩니다
• 올바르게 설계된다면, 루프는 모델이 환경을 관찰하도록 강제하고 지금 당장 보아야 할 것과 절대적으로 필요 없는 것을 정확히 공급해야 합니다
• 이 접근법은 더 저렴하고 빠른 모델을 사용하여 훨씬 적은 컴퓨팅으로 동일한 성공률을 달성할 수 있습니다