왜 자동화 루프는 충돌 대신 표류로 실패하는가
스케줄 트리거나 이벤트 훅으로 도는 자동화 파이프라인은 사람이 매번 확인하지 않는다는 전제로 설계됩니다. 문제는 에이전트가 예외를 던지고 멈추는 대신 그럴듯한 산출물을 계속 내놓는다는 점입니다. Anthropic은 평가 아키텍처를 다룬 엔지니어링 글에서, 기존 소프트웨어와 달리 에이전트는 요란하게 충돌하지 않고 조용히 표류·퇴화한다고 지적합니다. 발행형 파이프라인이라면 이 표류가 중복 발행, 깨진 링크, 근거 없는 통계로 나타나므로 실패를 "멈춤"이 아니라 "조용한 저하"로 정의하고 감지 지점을 따로 둬야 합니다.
재시작이 아니라 재개: 상태 저장이 만드는 차이
Anthropic의 멀티에이전트 리서치 시스템 사례는 오케스트레이터가 하위 에이전트에 목표·산출 형식·도구 사용 범위·작업 경계 네 가지를 명시하지 않으면 하위 에이전트가 표류한다고 밝힙니다. 이 네 가지 경계가 곧 파이프라인 단계 사이의 계약입니다. 같은 글은 에이전트가 상태를 유지하고 오류가 누적되는 특성 때문에 실패 시 처음부터 재시작하는 대신, 결정론적 재시도와 체크포인트를 결합해 실패 지점부터 재개하도록 설계했다고 설명합니다.
이런 안전장치는 공짜가 아닙니다. 같은 자료는 멀티에이전트 구성이 단일 대화 대비 토큰을 약 15배 더 소비한다고 밝히면서도, Opus 계열을 오케스트레이터로 Sonnet 계열을 하위 에이전트로 쓴 구성이 단일 에이전트보다 90.2% 높은 성능을 냈다고 보고합니다. 자동화 루프도 체크포인트·재시도 비용을 감수할 구간과 단발 호출로 충분한 구간을 미리 나눠야 토큰 비용이 통제됩니다.
구축 로드맵과 함정: 트리거 자동화 파이프라인 운영 가이드
(a) 기획 단계에서는 완주율부터 숫자로 못박습니다. 트리거 발생부터 최종 커밋까지 파이프라인이 끝까지 도달하는 비율 95% 이상, 외부 API 호출은 지수 백오프로 최대 4회·간격 15초 이상, 발행 전 중복 검사 통과율 100%를 시작 기준으로 둡니다. 이 숫자가 없으면 "일단 돌려보고 문제 생기면 고친다"는 사후 대응으로 흐르기 쉽습니다.
(b) 실패 패턴은 크게 넷입니다. 첫째, 이그레스 차단 같은 네트워크 플레이키니스 — 지수 백오프 재시도 후에도 실패하면 정적 스냅숏 데이터로 폴백하되 그 사실을 결과 보고에 명시합니다. 둘째, 중간 단계에서 프로세스가 죽고 재실행됐을 때 이미 완료된 단계를 다시 수행해 중복 산출물이 생기는 경우 — 날짜와 슬러그를 조합한 멱등 키로 사전 검사해야 막을 수 있습니다. 셋째, 완료 통보용 외부 API가 실패하는 경우 — 본 작업 결과는 되돌리지 않고 통보만 별도로 재시도합니다. 넷째, 렌더링 도구 부재로 이미지 생성 단계가 실패하는 경우 — 대체 자산으로 자동 전환하되 폴백 사용 여부를 반드시 기록합니다.
(c) 운영 체크리스트는 검증 계층을 겹쳐 쌓는 데서 시작합니다. Anthropic의 평가 아키텍처 글은 스위스 치즈 모델을 인용해, 한 계층이 놓친 오류를 다른 계층이 잡도록 여러 검증을 병행해야 한다고 설명합니다. 파이프라인 산출물의 JSON·XML 구조 검증, 커밋 대상 파일 화이트리스트 고정, 배포 후 실제 URL 응답 코드 확인, 링크 무결성 점검을 각각 독립된 계층으로 두고, 실행 ID·트리거 시각·단계별 성공 여부를 로그 필드로 남깁니다.
(d) 개선 루프는 실행마다 남긴 스킵·재시도 로그를 다음 실행의 사전 점검 항목에 반영하는 데서 출발합니다. Claude Code의 평가 체계가 처음에는 형식 준수 같은 좁은 항목만 보다가 점차 과도한 수정 같은 복잡한 행동으로 범위를 넓혔다는 사례처럼, 자동화 루프의 품질 게이트도 초기에는 구조 오류 검출에 집중하고 이후 콘텐츠 중복이나 근거 누락 같은 정성적 항목으로 확장해야 놓치는 사례가 줄어듭니다.
핵심만 남긴 실행 노트
자동화 루프의 신뢰는 무중단 실행이 아니라 표류를 얼마나 빨리 감지해 재개하느냐에서 나옵니다. 완주율·재시도 횟수·중복률을 숫자로 고정하고, 실패 지점부터 재개하는 체크포인트와 멱등 키를 갖추고, 검증 계층을 겹쳐 배포 후까지 확인하면 트리거가 사람 없이 돌아도 결과를 신뢰할 수 있습니다.