현장에서 에이전트 PoC를 보면 초반 데모는 잘 된다. 문서를 읽고, 도구를 호출하고, 초안을 만든다. 문제는 두 번째부터다. 수정 요청이 들어오고, 중간 산출물이 쌓이고, 검증 기준이 바뀌면 에이전트는 같은 일을 반복하거나 이미 틀린 전제를 더 정교하게 밀고 간다. 이때 필요한 것은 더 긴 프롬프트가 아니다. 루프를 나누는 아키텍처다.
하나의 루프는 곧 병목이 된다
많은 에이전트 설계가 하나의 while loop로 시작한다. 모델이 생각하고, tool을 호출하고, 결과를 받아 다음 행동을 정한다. OpenAI도 2026년 Responses API의 컴퓨터 환경 설명에서 orchestrator가 모델 출력, tool 실행, tool 응답 재주입을 task complete까지 반복한다고 설명했다. 이 구조는 출발점으로 맞다.
하지만 운영 업무는 단순한 completion 문제가 아니다. 실행 중에는 속도가 필요하고, 검증 중에는 냉정함이 필요하다. 같은 agent가 두 역할을 동시에 맡으면 자기 산출물을 방어한다. 실패를 발견하기보다 다음 실행 근거를 만든다.
loop-until-dry의 핵심은 “될 때까지 반복”이 아니라 “새 결함과 새 작업이 더 이상 나오지 않을 때까지 계층적으로 말리는 것”이다.
안쪽 루프는 실행을 맡는다. 바깥 루프는 검증과 종료 판단을 맡는다. 둘은 같은 모델을 써도 되지만 같은 상태와 같은 프롬프트를 공유하면 안 된다.
안쪽 루프는 산출물을 만들고, 바깥 루프는 상태를 말린다
Anthropic은 2026년 3월 long-running application development harness 글에서 planner, generator, evaluator의 3-agent 구조를 설명했다. generator-evaluator 루프를 소프트웨어 개발의 code review와 QA에 대응시킨 점이 중요하다. 실행자와 평가자를 분리해야 긴 작업이 산출물로 수렴한다.
AX Ops 관점에서 loop-until-dry는 다음처럼 잡는다.
| 계층 | 책임 | 입력 | 종료 조건 |
|---|---|---|---|
| 안쪽 실행 루프 | 작업 수행, tool 호출, 부분 산출 | 현재 backlog, 작업 컨텍스트 | 이번 작업의 산출물 생성 |
| 중간 정리 루프 | artifact 갱신, memory 압축, 다음 작업 정의 | 실행 trace, 변경분 | backlog가 구조화됨 |
| 바깥 검증 루프 | 품질 판정, 위험 차단, 재작업 지시 | 산출물, 기준, 운영 로그 | 새 결함·새 질문이 없음 |
여기서 dry는 backlog가 비었다는 뜻만 아니다. 검증자가 새 결함을 만들지 않고, 운영 기준이 새 예외를 만들지 않고, 사람에게 물어야 할 미결정 항목이 더 나오지 않는 상태다. 그때만 완료다.
검증 루프는 transcript보다 outcome을 본다
에이전트 실패를 대화 로그로만 보면 놓친다. Anthropic은 2026년 agent eval 글에서 transcript와 outcome을 구분한다. transcript는 tool call과 중간 응답의 전체 기록이고, outcome은 환경의 최종 상태다. 고객 응대 에이전트가 “처리했습니다”라고 말한 것과 실제 주문 상태가 바뀐 것은 다르다.
바깥 검증 루프는 그래서 말투보다 상태를 본다. 파일이 만들어졌는지, 권한 경계를 넘지 않았는지, DB 상태가 맞는지, 승인 없는 실행이 있었는지 본다. LLM judge는 보조 수단이다. 가능한 곳은 code-based grader, rule, API 조회, 샘플 재현으로 닫아야 한다.
안쪽 루프에 많은 context를 넣는 것도 답이 아니다. Anthropic은 2025년 context engineering 글에서 agent loop가 매 턴마다 관련 가능성이 있는 데이터를 계속 생성하며, 이 정보를 반복적으로 정제해야 한다고 설명했다. 바깥 루프가 artifact를 정리하지 않으면 context는 업무 기억이 아니라 쓰레기 더미가 된다.
운영 에이전트는 루프 설계부터 점검한다
loop-until-dry 아키텍처를 설계할 때 먼저 묻는 질문은 세 가지다.
- 실행자가 만들 산출물은 무엇인가.
- 검증자가 볼 최종 상태는 무엇인가.
- 더 이상 반복하지 않아도 되는 dry 조건은 무엇인가.
이 세 질문에 답하지 못한 에이전트는 아직 제품이 아니다. 모델 교체, tool 추가, 프롬프트 보강은 그다음이다. AX LABS가 agent-design에서 먼저 보는 것도 여기다. 에이전트를 똑똑하게 만드는 일보다, 멈출 수 있게 만드는 일이 먼저다.
멀티 루프 합성은 복잡한 구조가 아니다. 실행과 검증을 분리하고, context를 artifact로 정리하고, outcome 기준으로 종료시키는 운영 설계다. 이 설계가 있어야 PoC가 업무 흐름 안으로 들어온다. 더 깊은 설계 원칙은 AX Ops 방법론 →
참고
- OpenAI, “From model to agent: Equipping the Responses API with a computer environment,” 2026: https://openai.com/index/equip-responses-api-computer-environment/
- Anthropic, “Harness design for long-running application development,” 2026: https://www.anthropic.com/engineering/harness-design-long-running-apps
- Anthropic, “Demystifying evals for AI agents,” 2026: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- Anthropic, “Effective context engineering for AI agents,” 2025: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic, “Effective harnesses for long-running agents,” 2025: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
