에이전트 자기개선 하네스 (6/12) — Reflect 파이프라인의 진화
AI 에이전트 장기 기억 관리를 LLM 전담에서 정규표현식 기반 스크립트로 최적화한 과정
핵심 요약
- Reflect 파이프라인은 v0.3(LLM 전담) → v0.5(역전 아키텍처) → 현재(스크립트 강화)로 진화했다
- 데이터가 구조화된 형식으로 굳어지면 LLM 대신 정규표현식 스크립트로 전환하는 것이 합리적이다
- 스크립트 전환으로 테스트 가능성, 예측 가능성, 디버깅 효율성이 모두 향상되었다
배경
AI 에이전트의 장기 기억 관리 시스템인 Reflect 파이프라인은 매일 새벽에 하루 동안 쌓인 임시 메모리를 정리하여 장기 저장소에 반영하는 역할을 한다. 이 파이프라인의 아키텍처를 세 번 바꾸면서 얻은 최적화 경험을 공유한다.
본문
v0.3 (초기): 모든 것을 LLM이 처리
4개 러너 모두 개별 LLM 호출이 필요했다. 단일 실패 지점이 전체 파이프라인을 중단시키는 취약한 구조였다.
v0.5 (역전 아키텍처): 판단과 실행 분리
Manager는 요약 리포트(2k-5k 토큰)만 처리하고, 하위 Runner들이 원본 파일을 1차 처리하는 구조로 전환했다. LLM의 부담을 줄이되 판단 기능은 유지했다.
현재: 스크립트 강화 단계
핵심 전환점은 "대화 로그의 Retain 태그 추출" 작업이었다. 실제 데이터가 완전히 구조화된 형식(- W:, - O(c=0.90):, - S[entity]:)으로 굳어졌기 때문에, LLM에서 Python 정규표현식 스크립트로 변경했다.
구조화된 데이터는 정규표현식으로 추출하고, LLM은 의미 판단과 자연어 생성에만 집중하는 역할 분담이 완성되었다.
시행착오 / 주의사항
LLM은 유연하지만 비결정적(non-deterministic)이다. 같은 입력에 같은 출력을 보장하지 않는다. 데이터 형식이 확정된 후에도 LLM을 계속 사용하면 불필요한 비용과 불안정성을 떠안게 된다. 반대로, 데이터가 아직 유동적인 단계에서 스크립트로 전환하면 형식 변경마다 코드를 수정해야 하는 부담이 생긴다.
전환 타이밍의 판단 기준: 데이터 형식이 2주 이상 변경 없이 안정화되었을 때.
마무리
시스템 안정화 단계에서 구조화 가능한 부분은 스크립트로 전환해야 한다. 스크립트 기반 처리는 테스트 가능하고, 예측 가능하며, 실패 격리를 통한 디버깅이 쉽다. LLM은 정말 LLM이 필요한 곳에만 쓰는 것이 장기 운영의 핵심이다.
댓글
댓글 쓰기