Claude 4 시대를 위한 에이전트 리팩토링: 복잡한 샤딩을 버리고 3-에이전트 루프를 코드로 구현하는 법

레거시 샤딩에서 3-Agent 루프로의 데이터 마이그레이션 전략

기존 LangChain이나 AutoGPT가 밀어붙였던 마이크로 샤딩은 실패했습니다. 단계를 수십 개로 쪼개면 논리 체인은 정교해 보일지 몰라도, 실제로는 각 호출마다 문맥이 잘려 나가며 비결정성만 높입니다. Claude 3.5나 곧 출시될 4 모델처럼 추론 능력이 비약적으로 상승한 LLM을 쓸 때는 전략을 바꿔야 합니다. 파편화된 노드들을 붙잡고 씨름하지 마십시오. 대신 Planner가 제어하는 중앙 집중형 상태 관리 구조로 통합해야 합니다.

성공적인 아키텍처 전환을 위해 우선 기존의 마이크로 태스크들을 하나의 클래스 내 메서드로 묶어 도구 저장소(Tool Box)로 캡슐화하십시오. 그다음 모든 에이전트가 참조하는 단일 State 객체를 정의합니다. 여기에는 plan (단계별 계획), history (도구 실행 로그), artifacts (생성 데이터) 필드가 반드시 들어가야 합니다.

LangGraph의 리듀서 기능을 활용해 각 에이전트가 작업을 마칠 때마다 이 공유 상태를 업데이트하게 만드십시오. 문맥 단절을 물리적으로 차단하면 중복 토큰 전송이 사라집니다. 실제로 이 구조로 전환한 팀들은 API 비용을 30% 이상 즉각 절감했습니다.

Evaluator를 위한 정량적 채점표 코드 구현

에이전트가 뱉어내는 결과물이 "괜찮아 보인다"는 식의 주관적인 판단은 배포 환경에서 시한폭탄이나 다름없습니다. LLM-as-a-Judge 패턴을 도입하되, 이를 반드시 코드 수준에서 강제해야 합니다. Evaluator 에이전트는 Generator의 결과물을 정확성, 일관성, 가독성, 효율성이라는 4가지 지표로 쪼개어 숫자로 환산해야 합니다.

Pydantic 라이브러리를 사용해 평가 결과가 특정 JSON 스키마를 따르도록 강제하십시오.

• RubricScore 클래스를 선언하고 각 지표를 1~5점 사이의 정수 필드로 설정합니다.
• 프롬프트 안에 각 점수대별 구체적인 충족 조건(예: 효율성 5점은 시간 복잡도 $O(n)$ 이하 달성 시 부여)을 명시합니다.
• 평균 점수가 4.0점 미만이면 Merge Block을 실행해 CI/CD 파이프라인에서 배포를 자동 중단하고 재작업 신호를 보냅니다.

이런 자동화 검증 시스템을 구축하면 사람이 대조하며 5시간씩 걸리던 검증 작업이 10분 이내로 줄어듭니다. 기계적인 채점은 냉정하지만, 그만큼 시스템의 예측 가능성을 높입니다.

Anthropic Prompt Caching을 활용한 비용 최적화

에이전트 루프가 돌기 시작하면 무서운 속도로 토큰이 쌓입니다. 시스템 지침과 도구 정의를 매번 다시 보내는 건 돈을 길바닥에 버리는 짓입니다. Claude의 프롬프트 캐싱은 캐시된 토큰에 대해 일반 요금의 10% 수준만 부과합니다. 이 혜택을 보려면 프롬프트 구조를 정적인 부분에서 동적인 부분 순서(Tools → System → Messages)로 배치하는 접두사 매칭 전략을 써야 합니다.

• 변하지 않는 지침과 도구 정의를 최상단에 두고 cache_control 중단점을 설정하십시오.
• 사용자 메시지 안에는 <system-reminder> 태그를 써서 가변 정보를 삽입합니다. 이렇게 해야 상단 접두사의 캐시가 깨지지 않습니다.
• 대화가 길어지는 20블록 룩백 윈도우 지점마다 전략적으로 추가 중단점을 배치하십시오.

캐싱 전략을 제대로 설계하면 API 호출 비용을 최대 90%까지 깎을 수 있습니다. 응답 속도 또한 체감될 정도로 빨라집니다. 돈과 시간 모두를 챙기는 유일한 방법입니다.

무한 루프 방지를 위한 서킷 브레이커 설계

Generator와 Evaluator가 서로 고집을 피우며 합의하지 못하면 에이전트는 데드락에 빠집니다. 이건 단순한 오류가 아니라 비용 폭주로 이어지는 재앙입니다. 이를 막기 위해 작업 횟수와 응답 유사도를 감시하는 다중 계층 서킷 브레이커가 필요합니다. 특히 이전 응답과 현재 응답의 코사인 유사도가 0.95 이상이라면, 에이전트가 같은 말을 반복하며 멍청하게 루프를 돌고 있다는 명확한 신호입니다.

1. 메인 루프에 단일 세션 최대 횟수(Max-Turn Limit)를 15회로 제한하는 카운터를 넣으십시오.
2. 세션별 최대 허용 비용(Budget Cap)을 설정하고 API 게이트웨이에서 실시간으로 감시합니다.
3. 차단기가 작동하면 즉시 실행 트레이스를 요약해 Slack으로 쏘고 인간(Human-in-the-loop)의 개입을 요청하십시오.

에이전트에게 전권을 맡기는 건 용감한 게 아니라 무책임한 겁니다. 안전 장치가 없는 에이전트 시스템은 운영하지 않는 편이 낫습니다.

에이전트 팀 전용 관찰성 대시보드

세 에이전트가 뒤섞여 일하는 과정은 블랙박스입니다. 어디서 병목이 생기는지 모르면 개선도 불가능합니다. OpenTelemetry 표준을 따르는 추적 시스템을 붙여 에이전트 간 메시지 흐름을 시각화하십시오. Redis 기반의 체크포인팅을 구현해두면 시스템이 뻗더라도 처음부터 다시 시작할 필요 없이 마지막 성공 지점부터 이어갈 수 있습니다.

API 응답 헤더에서 cache_read_input_tokens 값을 뽑아내 대시보드에 그리십시오. 캐시 히트율이 낮다면 프롬프트 구조가 잘못되었다는 증거입니다. 또한 루프가 수렴하는 속도를 지표화해 관리하면 프롬프트 엔지니어링의 성과를 숫자로 증명할 수 있습니다. PostgreSQL에 세션 ID와 아티팩트 버전을 저장해두면 에이전트 팀이 과거에 어떤 지점에서 헤맸는지 정밀하게 복기할 수 있습니다. 기록되지 않는 에이전트는 결코 똑똑해지지 않습니다.