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

큰 실행은 두 번 막아야 한다

Reviewer-agent는 승인자가 아니라 실행 차단기다

AX LABS 6분 읽기

현장에서 대용량 배치 사고는 대개 모델이 틀려서 나지 않는다. 실행 전에 사람이 대충 읽고 넘긴 plan, 맞는 듯 보이는 GPU 요청, 실제로 돌려본 적 없는 rollback script가 한꺼번에 통과해서 난다. 작은 자동화에서는 이 허술함이 로그 한 줄로 끝난다. GPU 클러스터, HPC 큐, 전사 데이터 배치에서는 비용·대기열·데이터 상태가 같이 흔들린다.

실행 승인은 리뷰가 아니라 차단이어야 한다

Reviewer-agent compute gate의 역할은 결재선을 하나 더 만드는 것이 아니다. 실행 가능한 산출물을 막는 것이다. 특히 GPU·HPC·대용량 배치는 한번 큐에 올라가면 취소도 비용이다. Slurm 26.05는 실행 중 메모리 한도 조정, Prometheus GPU allocation 통계 확장 같은 운영 기능을 강화했다. Kubernetes v1.36도 AI/ML·batch workload를 위해 Workload API와 PodGroup 기반 스케줄링을 발전시키고 있다. 인프라는 점점 더 세밀하게 제어된다. 그래서 agent 쪽 gate도 더 세밀해야 한다. (slurm.schedmd.com)

큰 compute 실행의 위험은 실행 명령에 있지 않다. 실행 명령을 만들기 전의 가정에 있다.

이 gate는 세 가지를 독립 산출물로 받는다. 첫째 plan이다. 어떤 데이터, 어떤 코드, 어떤 체크포인트, 어떤 종료 조건으로 실행하는지 적는다. 둘째 resource estimate다. GPU, CPU, memory, storage, wall time, topology 제약, quota 영향을 분리한다. 셋째 rollback script다. 실패했을 때 무엇을 되돌리고 무엇은 보존할지 명령 수준으로 적는다.

이중 루프는 작성자와 검증자를 분리한다

첫 번째 루프는 실행 agent가 만든다. 실행 agent는 목표를 작업 단위로 쪼개고, 실행 manifest와 예상 자원, 실패 시나리오를 낸다. 이때 산출물은 설명문이 아니라 실행 전 계약서다.

두 번째 루프는 reviewer-agent가 별도로 돈다. reviewer는 같은 prompt를 보강해서 읽지 않는다. 다른 근거로 다시 계산한다. scheduler dry-run, quota 조회, 데이터 snapshot 확인, rollback dry-run을 호출한다. Anthropic이 Claude Code의 hooks, subagents, checkpoint를 장시간 자율 작업의 통제 장치로 설명하고, OpenAI가 agent action에서 명시적 확인·중단·sandbox를 강조한 이유도 같다. agent가 오래 움직일수록 중간 차단점이 설계 대상이 된다. (anthropic.com)

항목 실행 agent 산출 reviewer-agent 검증
plan 작업 순서와 명령 의존성, 입력 데이터, 종료 조건 충돌 확인
resource estimate 필요한 GPU·CPU·memory·시간 quota, queue, topology, 동시 실행 영향 재계산
rollback script 복구 명령 dry-run, 권한, 보존 대상, 재실행 가능성 확인
승인 조건 실행 가능 주장 불일치가 없을 때만 submit token 발급

resource estimate는 비용표가 아니라 스케줄링 조건이다

많은 조직이 resource estimate를 예산 항목으로만 본다. 틀렸다. estimate는 scheduler가 받아들일 수 있는 조건이고, 다른 팀의 대기열을 밀어낼 수 있는 약속이다. NVIDIA Run:ai on DGX Cloud 문서는 project·department quota, compute resource, training workload의 자원 할당을 운영 단위로 다룬다. Kubernetes ResourceQuota도 namespace 단위 총량 제약을 제공한다. 즉 자원 요청은 개인의 추정이 아니라 공유 클러스터의 계약이다. (docs.nvidia.com)

Reviewer-agent는 estimate를 세 갈래로 본다.

  • 상한: 요청 자원이 정책과 quota를 넘는가.
  • 정합성: plan의 데이터 크기·병렬도·checkpoint 주기와 estimate가 맞는가.
  • 대안: 낮은 우선순위 queue, 축소 샘플, 분할 배치로 바꿀 수 있는가.

여기서 중요한 것은 사람에게 모든 판단을 돌리지 않는 것이다. 사람은 예외를 승인한다. reviewer-agent는 정상 경로를 통과시키거나 막는다.

참고: 게이트는 문서가 아니라 회로다

이 설계의 최소 구현은 간단하다. 실행 요청을 바로 scheduler로 보내지 않는다. 먼저 run bundle을 만들고, reviewer-agent가 별도 tool 권한으로 검증하고, 통과 시에만 submit token을 발급한다. 실패하면 수정 요청이 아니라 차단 사유와 재작성 조건을 돌려준다.

참고한 최근 12개월 이내 1차 출처는 다음과 같다.

GPU 실행을 agent에게 맡기려면 먼저 agent가 실행하지 못하게 만드는 회로부터 설계해야 한다. 이 회로가 AX Ops의 agent 운영 설계다. AX Ops 방법론 →