AI에 메모리를 더 줬더니, 더 둔해졌다. 그 이유는 다음과 같다.
Source: Dev.to
트위터에서는 듣지 못할 RAG와 컨텍스트 윈도우에 관한 진실
개발자 커뮤니티에서는 LLM의 컨텍스트 윈도우를 최대한 크게 하면 애플리케이션이 더 똑똑해진다고 생각합니다.
하지만 실제로는 더 어리석어집니다.
저는 최근 개인 AI 에이전트 스택의 아키텍처를 수정했는데, openclaw.json 설정에서 컨텍스트 윈도우를 200 k 토큰에서 1 백만 토큰으로 늘렸습니다. 전체 프로젝트 레포지토리와 과거 API 통합 정보를 프롬프트에 주입하면 완벽하고 컨텍스트를 인식하는 실행이 가능할 것이라는 가정이었습니다.
그 결과, 에이전트가 흐트러졌습니다.
페이로드를 1 백만 토큰으로 늘리니 지연 시간은 당연히 급증했지만, 진짜 문제는 정확도였습니다. 모델이 변수를 환상하게 만들어내고 프롬프트 끝에 명확히 정의된 명령을 놓치기 시작했습니다. 마치 주의 집중력이 크게 감소한 느낌이었습니다.
AI 에이전트를 구축하는 사람들에게 역설적인 교훈은 제약이 집중을 만든다는 점입니다. 더 좁은 컨텍스트 윈도우는 모델이 즉각적인 작업에만 고정되도록 강제합니다. 실제 API와 외부 시스템을 다루는 에이전트를 배포할 때, 전혀 관련 없는 스크립트의 README 파일 때문에 산만해져서 환상을 일으키길 원하지 않을 겁니다.
이러한 시스템을 구축하는 대부분의 엔지니어가 이제 같은 결론에 도달하고 있습니다: 극히 제한적이고 관련성 높은 검색을 사용한 200 k 토큰이 실제 프로덕션 환경에서는 1 백만 토큰 데이터 덤프보다 근본적으로 더 뛰어나다는 점입니다.
시스템 프롬프트가 토큰 제한보다 중요하다
토큰 제한은 제가 다른 개발자의 코드를 검토할 때 가장 큰 실패 요인이 아닙니다. 가장 큰 실패는 기본 시스템 프롬프트에 의존하는 것입니다.
제 로컬 배포 스택에서는 SOUL.md라는 강력한 성격 및 운영 문서를 강제합니다. 이것은 단순히 친절한 지시가 아니라, 에이전트가 다음을 수행하도록 정의하는 핵심 운영 로직입니다:
- 들어오는 웹훅 파싱
- JSON 응답 구조화
- 변수를 추측하기보다 오류를 발생시킬 시점 결정
에이전트의 운영 파라미터와 행동 경계를 명시적으로 정의하지 않으면, 기본적인 일반 어시스턴트 행동으로 전락합니다. 일반적인 행동은 파이프라인을 깨뜨립니다.
래퍼 라이브러리보다 아키텍처가 우선
외부 API 폴링부터 로컬 파일 시스템 변형까지 자동화 작업을 수행할 때, 프롬프트의 아키텍처는 제가 사용하는 래퍼 라이브러리의 문법적 설탕보다 훨씬 중요합니다.
현재 시장에서의 격차는 LLM을 호출하기 위해 어떤 파이썬 라이브러리를 사용할지 아는 것이 아니라, 상호작용을 어떻게 설계할지에 대한 이해에 있습니다.
새로운 마이크로서비스를 스택에 배포할 때, 여러분은:
- 입력과 출력에 대한 엄격한 계약을 정의한다.
- 재시도 로직, 폴백, 모니터링을 구현한다.
AI 호출도 정확히 같은 방식으로 다루어야 합니다. 강력한 제약을 설정하고, 실행 루프의 “영혼”을 정의하며, 특정 요청에 필요한 것만 정확히 포함하도록 컨텍스트 윈도우를 크게 제한하는 것이, 로컬 터미널 데모에서 멋져 보이는 것에 그치지 않고 실제로 신뢰할 수 있는 에이전트를 만드는 방법입니다.
행동 촉구
현재 자율 에이전트를 구축하고 있다면, 컨텍스트 윈도우를 적극적으로 제한하고 있나요, 아니면 여전히 모든 것을 페이로드에 쏟아넣고 모델이 스스로 해결하길 기대하고 있나요? 현장에서 겪고 있는 상황을 알려 주세요.