AX LABS
← 블로그 에이전트 제품 설계

에이전트는 끝나야 일한다

수렴은 모델 성능이 아니라 루프 설계의 결과다

AX LABS 6분 읽기

현장에서 에이전트 데모는 대체로 그럴듯하다. 파일을 읽고, 도구를 호출하고, 중간 결과를 설명하고, 다시 고친다. 문제는 운영 환경에 들어간 뒤 드러난다. 같은 도구를 반복 호출한다. 근거가 늘지 않는데 계획만 바꾼다. 작은 업무 하나가 긴 실행으로 번진다. 이때 팀은 모델을 바꾸려 한다. 순서가 틀렸다. 먼저 루프를 설계해야 한다.

에이전트 실패는 루프 실패다

2026년의 에이전트 제품은 단발성 답변기가 아니다. OpenAI는 Codex agent loop를 모델 추론, 도구 호출, 도구 결과 반영, 다시 추론하는 반복 구조로 설명한다. 루프는 모델이 더 이상 도구 호출을 내지 않고 사용자에게 응답할 때 끝난다. 이 설명은 중요하다. 종료를 모델의 암묵적 판단에만 맡기면 실행 루프는 제품 통제 밖으로 나간다.

Anthropic도 장기 실행 에이전트에서 harness의 역할을 강조한다. Claude Code와 Claude Agent SDK는 subagents, hooks, checkpointing, permissions 같은 장치를 통해 긴 작업을 더 안전하게 위임하도록 진화했다. 핵심은 모델이 똑똑해졌다는 말이 아니다. 모델 주변의 실행 장치가 두꺼워졌다는 뜻이다.

운영 가능한 에이전트는 좋은 프롬프트로 완성되지 않는다. 멈춤, 진척, 비용을 판정하는 루프 장치로 완성된다.

종료조건은 성공과 실패를 같이 정의한다

많은 팀이 성공 조건만 쓴다. “리포트를 작성한다”, “이슈를 해결한다”, “고객 문의를 처리한다.” 이것은 목표이지 종료조건이 아니다. 종료조건은 실행기가 판정할 수 있어야 한다.

종료조건은 세 가지로 나눈다.

  1. 성공 종료: 산출물이 스키마, 테스트, 승인 조건을 통과한다.
  2. 보류 종료: 추가 권한, 데이터, 사람 판단 없이는 다음 행동이 불가능하다.
  3. 실패 종료: 반복, 충돌, 예산 초과, 품질 미달이 감지된다.

실패 종료를 명시하지 않으면 에이전트는 성실하게 실패를 연장한다. 특히 사내 시스템과 연결된 에이전트는 “더 찾아보겠다”가 비용, 지연, 권한 리스크로 바뀐다. OpenAI Agents SDK의 guardrails와 tracing, Anthropic의 containment 논의가 같은 방향을 가리킨다. 에이전트는 행동 능력을 얻을수록 실행 경계가 먼저 필요하다.

진행도는 말이 아니라 상태로 기록한다

에이전트가 “거의 완료했다”고 말하는 것은 진행도가 아니다. 진행도는 다음 루프 판단에 쓰이는 상태여야 한다. Anthropic의 long-running agent harness 글은 초기화 스크립트, 진행 로그, 체크포인트 같은 실행 장치를 다룬다. 이 패턴은 코드 에이전트에만 해당하지 않는다. 리서치, 심사, 정산, 영업 운영 에이전트도 같은 원리로 움직인다.

설계 항목 약한 루프 수렴하는 루프
목표 자연어 지시 판정 가능한 완료 기준
진행도 모델의 설명 상태 파일, 작업 큐, 산출물 diff
반복 판단 다음 행동을 모델이 선택 동일 행동·무진척·충돌을 harness가 감지
사람 개입 마지막 검수 보류 종료 시점의 승인·입력
재시작 처음부터 다시 실행 checkpoint에서 재개

진행도 설계의 핵심은 “무엇이 달라졌는가”다. 새 정보가 없고, 산출물 diff가 없고, 실패 원인 분류가 같으면 다음 루프는 진행이 아니다. 그 시점에는 재시도보다 종료가 맞다.

예산 게이트는 비용 통제가 아니라 제품 기능이다

예산 게이트를 회계 장치로 보면 늦다. 에이전트 제품에서 예산은 실행 품질의 일부다. AutoLab 논문은 장기 폐쇄 루프 최적화 과제를 엄격한 wall-clock budget 안에서 평가하며, 일부 모델이 조기 종료하거나 예산을 소진한다고 지적한다. 이 관찰은 현장과 맞다. 긴 작업에서 문제는 “할 수 있느냐”가 아니라 “정해진 시간과 비용 안에서 의미 있게 전진하느냐”다.

예산 게이트는 최소 네 단계를 둔다.

  1. 실행 전: 업무 유형별 토큰, 시간, 도구 호출 한도 설정
  2. 실행 중: 반복 도구 호출, 동일 입력, 무진척 루프 감지
  3. 임계점: 저비용 모델 전환, 범위 축소, 사람 승인 요청
  4. 종료 후: trace 기준으로 비용 대비 산출물 품질 리뷰

이 구조가 없으면 고성능 모델을 붙여도 운영팀은 불안해서 권한을 열지 않는다. 권한이 닫히면 에이전트는 실제 업무를 하지 못한다.

루프 엔지니어링부터 설계해야 한다

루프 엔지니어링은 에이전트를 “더 오래 생각하게” 만드는 일이 아니다. 반대로 필요한 만큼만 돌고, 더 돌 이유가 없으면 멈추게 만드는 일이다.

AX LABS가 에이전트 설계에서 먼저 보는 것도 이 지점이다. 어떤 모델을 쓸지보다 어떤 종료조건으로 닫을지, 진행도를 어디에 남길지, 예산 게이트를 누가 승인할지를 먼저 정한다. 그래야 PoC가 운영으로 넘어간다.

에이전트 실행 루프는 제품의 심장부다. 심장부를 프롬프트에 맡기지 말고 AX Ops 관점에서 설계하라. AX Ops 방법론 →

참고