에이전트가 실패할 때 대부분 모델 탓을 합니다. 할루시네이션이 났다, 컨텍스트를 잘못 이해했다, 도구 호출이 어긋났다고. 저는 그게 절반만 맞다고 봅니다.

최근 15개 agentic-loop 논문을 종합한 리뷰에서 반복해서 나오는 결론이 있습니다. 에이전트 루프의 실패는 모델 품질보다 verifier 부재와 비용 설계 누락에서 온다는 것입니다. 모델을 교체해도 같은 지점에서 같은 방식으로 실패합니다. 루프 구조 자체가 문제이기 때문입니다.

루프의 본체는 두 가지다

에이전트 루프를 “LLM이 도구를 호출하고 결과를 반환하는 사이클”로만 보면 놓치는 게 있습니다. 루프의 진짜 본체는 따로 있습니다.

첫째, 외부에서 검증 가능한 verifier입니다. 모델 스스로 “이게 맞아”라고 판단하게 놔두면 안 됩니다. 테스트 실행 결과, 다른 에이전트의 피드백, 사전 정의된 완료 조건 — 외부 기준으로 매 단계 검증이 이뤄져야 합니다. verifier가 없으면 루프는 종료 기준을 찾지 못하거나, 잘못된 결과를 성공으로 처리하고 멈춥니다.

둘째, **성공당 비용(cost per success)**입니다. 루프가 몇 번 돌았는지가 아니라, 원하는 결과를 얻는 데 실제로 얼마가 들었는지가 운영 지표여야 합니다. 이를 추적하지 않으면 에이전트는 자원을 소진하면서 아무도 모르게 실패합니다.

Deep Agents 4요소

LangChain 창업자 hwchase17이 정리한 FRESH 프레임워크를 기반으로, 프로덕션 수준의 에이전트에는 4가지 요소가 함께 설계돼야 합니다.

1. 계획(Planning) 단발 프롬프트가 아니라, 목표를 하위 작업으로 분해하고 순서를 정하는 계획 레이어입니다. 목표가 모호하면 계획이 만들어지지 않고, 루프는 방향 없이 돕니다. 계획 레이어는 PRD와 맞닿아 있습니다. “에이전트가 어떤 목표를 받았을 때 어떤 순서로 움직이는가”를 PM이 먼저 정의해야 합니다. 이 정의가 없으면 루프는 실행마다 다른 경로를 탑니다.

2. 파일 컨텍스트(File Context) 에이전트의 작업 기억은 짧은 컨텍스트 창이 아니라 파일입니다. 코드, 명세, 이전 실행 결과를 파일로 관리하면 컨텍스트가 초기화된 후에도 에이전트가 상태를 복원할 수 있습니다. karpathy가 반복해서 강조하는 포인트가 여기 있습니다. “LLM의 네이티브 저장소는 파일이다.” 파일로 관리하지 않으면 에이전트는 세션이 끝날 때마다 처음부터 다시 시작합니다.

3. 서브에이전트(Subagents) 하나의 에이전트가 모든 걸 처리하게 하면 안 됩니다. 검색, 코드 실행, 검증, 보고서 작성을 각각 다른 에이전트에게 위임하고, 오케스트레이터는 조율만 합니다. 역할 분리가 루프 품질을 결정합니다. 서브에이전트를 쓰면 각 역할의 성공·실패가 독립적으로 측정되고, verifier를 붙이기도 훨씬 쉬워집니다.

4. 장기 메모리(Long-term Memory) 세션이 끝나도 유지되는 메모리입니다. 이전 실행에서 무엇이 실패했는지, 어떤 도구가 효과적이었는지를 축적해야 에이전트가 같은 실수를 반복하지 않습니다. 장기 메모리 없이 에이전트를 반복 실행하면 비용만 늘고 품질은 제자리입니다.

PM이 직접 설계해야 할 것

4요소 중 PM이 가장 먼저 손댈 부분은 계획과 verifier입니다.

계획은 기획 문서 작성과 다르지 않습니다. 목표 → 하위 작업 → 우선순위 → 완료 조건. 이 흐름을 에이전트 루프에 맞게 구조화하는 것이 PM의 역할입니다. 모델이 알아서 계획을 세울 것이라 믿는 순간, 루프는 매 실행마다 다른 결과를 냅니다.

verifier는 QA의 에이전트 버전입니다. “이 에이전트가 성공했다고 판단하는 기준은 무엇인가?” — 이 질문에 답이 없으면 루프는 끝나지 않거나, 잘못된 결과를 성공으로 처리합니다.

100 Agents를 운영하면서 가장 비싸게 배운 교훈이 여기 있습니다. verifier 없이 배포한 에이전트는 반드시 무한 루프나 잘못된 종료로 이어집니다. 반대로 verifier를 외부화하면 — 단위 테스트, 실행 로그, 다른 에이전트의 검토 결과 — 문제를 루프 내에서 잡을 수 있습니다. 그리고 verifier가 외부화되면 성공당 비용도 측정 가능해집니다.

비용 설계까지 끝내야 한다

성공당 비용을 추적하지 않는 에이전트 시스템은 예산을 모릅니다. 루프가 10번 돌아서 성공했을 때와 50번 돌아서 성공했을 때의 비용은 5배 차이가 납니다. 이를 추적하면 두 가지를 얻습니다.

하나는 최적화 신호입니다. 어떤 경로가 성공당 비용이 낮은지 보이기 시작합니다. 어떤 서브에이전트가 병목인지, 어떤 verifier가 루프를 불필요하게 늘리는지가 드러납니다.

또 하나는 비즈니스 모델입니다. outcome 기반 과금으로 이동하려면 성공당 비용을 알아야 합니다. 모르면 outcome 단가를 정할 수 없습니다. 에이전트 비즈니스의 경쟁이 과금 단위 설계로 이동하는 지금, 이 숫자는 PM이 반드시 가지고 있어야 할 운영 데이터입니다.

에이전트 루프는 기술 문제가 아닙니다. verifier를 외부화하고, Deep Agents 4요소를 정의하고, 성공당 비용을 추적하는 것 — 이게 PM이 에이전트 루프에서 해야 할 설계 작업입니다.

당신의 에이전트 루프에는 외부 verifier가 있습니까?