멀티 에이전트 팀이 도입되면 생산성은 바로 오르지만, 통제 규칙이 없으면 리스크도 함께 커진다. 운영의 승부처는 ‘더 똑똑한 모델’이 아니라 ‘실패를 다루는 설계’다.
단일 에이전트에서 멀티 에이전트로 넘어온 팀이 가장 먼저 겪는 착각은 이거다. 역할을 나눴으니 안정성도 자동으로 올라갈 거라고 믿는 것. 실제 현장에서는 반대다. 역할이 늘어나면 의존성도 늘고, 한 단계의 작은 오류가 다음 단계에서 더 큰 장애로 증폭된다. Planner가 잘못 분해한 작업을 Worker가 빠르게 실행하고, Reviewer가 늦게 감지하면 이미 배포까지 간 뒤다. 문제는 “누가 틀렸는가”보다 “어디서 멈췄어야 했는가”에 있다.
그래서 멀티 에이전트 운영의 핵심 KPI는 단순 성공률이 아니다.
- 장애를 얼마나 빨리 감지하는가
- 감지 후 손실을 얼마나 제한하는가
- 복구 후 같은 실패를 얼마나 줄였는가
즉, 운영팀은 정답률보다 복구력을 관리해야 한다.
1. 실패 예산(Failure Budget)을 먼저 정해야 자동화가 굴러간다
SRE에서 서비스 신뢰도를 관리할 때 에러 버짓을 쓰듯, 에이전트 팀도 실패 예산을 명시해야 한다. 실패를 0으로 만드는 건 현실적으로 불가능하고, 그 목표는 오히려 실험 속도를 죽인다. 대신 “어디까지는 허용하고, 어디서부터는 반드시 중단할지”를 숫자로 합의해야 한다.
예를 들어 하루 40건의 자동 작업이 있다면 다음처럼 잡을 수 있다.
- 경미 실패(자동 재시도로 복구): 8% 이내
- 중간 실패(사람 승인 필요): 2% 이내
- 치명 실패(외부 전송/배포 롤백): 0.3% 이내
이렇게 예산을 분리하면 운영 의사결정이 빨라진다. 실패가 발생했을 때 감정적으로 “왜 또 깨졌지?”가 아니라, “어느 구간 예산을 초과했는지”부터 본다. 예산 초과 구간에만 규칙을 강화하면 전체 생산성을 유지하면서 위험만 줄일 수 있다. 멀티 에이전트는 강하게 잠그는 게 답이 아니라, 구간별 통제 강도를 다르게 주는 것이 답이다.
2. 승인 게이트는 ‘권한’이 아니라 ‘맥락’ 기준으로 걸어야 한다
많은 팀이 승인 게이트를 “배포는 무조건 승인” 같은 단일 규칙으로 건다. 이 방식은 초반엔 안전해 보이지만 금방 병목이 된다. 더 좋은 방식은 위험 맥락 기반 게이팅이다.
실무에서 효과적인 기준은 보통 네 가지다.
- 변경 범위: 파일 수, 디렉터리 민감도, 운영 경로 포함 여부
- 외부 영향: 사용자 노출 여부, 결제/개인정보/대외 채널 포함 여부
- 불확실성: 모델 응답 일관성, 파서 신뢰도, 셀렉터 안정성
- 누적 이력: 동일 태스크의 최근 실패 횟수, 롤백 빈도
이 네 값으로 위험 점수를 만들고, 점수별로 처리 경로를 분기하면 된다.
- 저위험: 자동 실행 + 사후 로그 리뷰
- 중위험: Reviewer 이중 검수
- 고위험: 사람 승인 + 체크리스트 통과 후 실행
핵심은 승인 요청이 “사람의 감”이 아니라 “점수의 결과”여야 한다는 점이다. 그래야 팀이 커져도 판단 기준이 흔들리지 않는다.
3. 포스트모템 없는 자동화는 같은 장애를 반복한다
자동화 조직의 진짜 실력은 장애가 없을 때가 아니라, 장애 이후에 드러난다. 실패가 발생했을 때 로그만 저장하고 끝내면 다음 주에 거의 같은 문제가 다시 터진다. 포스트모템은 책임 추궁 문서가 아니라, 재발 방지 설계 문서여야 한다.
효율적인 포스트모템 템플릿은 짧고 강해야 한다.
- 사건 요약: 언제, 무엇이, 어디서 잘못됐는가
- 영향 범위: 사용자/데이터/배포 영향이 어디까지였는가
- 1차 원인: Planner/Worker/Reviewer 중 어디서 최초 신호가 있었는가
- 2차 원인: 왜 그 신호가 차단되지 않았는가
- 재발 방지: 규칙 변경, 테스트 추가, 게이트 조정 항목
여기서 중요한 건 “교훈”이 아니라 작동하는 수정 사항이다. 예를 들어 “검수를 강화한다”는 문장은 의미가 없다. 대신 “배포 전 frontmatter schema 검사 훅 추가”, “외부 전송 작업은 고위험 점수 +1”, “동일 오류 2회 시 강제 인계”처럼 시스템이 실행할 수 있는 변경으로 남겨야 한다.
운영 팀이 이 습관을 가지면 실패는 비용이 아니라 자산으로 바뀐다. 매 장애가 다음 자동화를 더 튼튼하게 만들기 때문이다.
4. 멀티 에이전트 팀의 최소 운영 규약(바로 적용 버전)
실무 적용을 위해 복잡한 아키텍처보다 먼저 아래 6가지를 고정하자.
- 경로 고정: 실배포 저장소 절대 경로 명시, 오타/대체 경로 금지
- 입출력 계약: Planner/Worker/Reviewer 결과 포맷(JSON 필수 필드) 고정
- 사전 검사 훅: 파일 존재/스키마/길이/이미지 참조/링크 체크 자동화
- 승인 정책: 위험 점수 기반 분기 규칙 문서화
- 실행 증빙: 커밋 해시 + remote 상태 + 배포 URL 검증까지 보고
- 사후 회고: 실패 건은 24시간 내 포스트모템 작성
이 여섯 개만 적용해도 운영 품질이 눈에 띄게 달라진다. 특히 “커밋됨”과 “실제 노출됨”을 분리해서 검증하는 규칙은 반드시 필요하다. 자동화에서 가장 비싼 실수는 실행 실패가 아니라 성공으로 잘못 보고된 실패다.
결국 멀티 에이전트 시대의 경쟁력은 모델 선택이 아니다. 실패를 허용하되 손실을 제한하고, 실패 이후 시스템을 강화하는 운영 태도다. 자동화를 오래 굴리는 팀은 공통적으로 “잘 돌아갈 때”보다 “깨졌을 때”를 더 잘 설계한다.
질문은 단순하다. 당신의 에이전트 팀은 빠르게 일하는가? 아니면 깨져도 복구되는가?
장기적으로 살아남는 건 언제나 두 번째다.
