#Agent 하나가 멈췄는데 왜 전체 스케줄링 클러스터가 무너지는가 — 생산 안정성 3층 거버넌스

← 전체 목차 · 이전: 여러 Agent가 같은 MCP 서버를 함께 써도 되는가 · 다음: 일시정지 후 어떻게 작업을 재개하는가

사고 시나리오: 온라인에서 Agent 작업 하나가 갑자기 멈추고, 스케줄링 클러스터 자원이 전부 점유되며, 업무 인터페이스가 전부 타임아웃된다. "로그를 켜고, 느린 작업을 찾고, 도구 호출에 타임아웃을 걸고, 컨텍스트 길이를 제한한다"는 입문급 4종 세트는 관측·정위·제한·자원 통제를 다 갖춘 것처럼 보이지만, 고장이 단일 지점이고 타임아웃으로 끊을 수 있고 컨텍스트는 잘라내도 된다는 세 가지 암묵적 전제 위에 서 있다. 이 전제들이 순환 의존 교착, 협업 자원 경합, 대유량 스케줄링 눈사태 앞에서 차례로 무너진다.

#5대 고빈도 장애 시나리오

타임아웃은 호출을 끊을 뿐 의존 고리를 풀지 못한다. 순환 의존은 구조 문제이므로 진짜 대책은 교착 탐지 + 순환 차단, 그리고 협업 층에서 통일 재정할 조정기다. "컨텍스트 길이 제한"도 손실이 있는 절단이라 장기 작업의 핵심 중간 결론을 잘라버릴 수 있다 — 대책은 슬라이딩 윈도우 + 벡터 검색으로, 근접 연속성은 윈도우가, 밀려난 정보는 필요 시 검색으로 불러온다.

#1층 — 업무 등급 분류: 먼저 "누구를 구할지" 정한다

모든 Agent가 같은 우선순위를 공유하면 백그라운드 콘텐츠 생성 작업 하나가 핵심 거래를 밀어낼 수 있다. 분류는 뒤따르는 모든 자원 격리·강등 수단의 전제다.

#2층 — 선정위 후최적화, 장애 유형별 대응

공통 정위: 전링크 트레이싱 + 스케줄링 대시보드 + Token 소모 로그 + 도구 호출 트레이스 → 근본 원인 특정
도구 호출 교착   → 회로 차단 재시도 + 멱등 검증, 순환 호출 방지
컨텍스트 Token 폭발 → 슬라이딩 윈도우 + 벡터 검색, Token 총량 통제
스케줄링 눈사태   → Agent 풀링 + 대기열 등급 분리
다중 Agent 교착  → 조정기 도입 + 타임아웃 강제 종료 메커니즘
장시간 작업 블로킹 → 분할 실행 + 비동기 처리 + 상태 영속화

"먼저 정위, 후 최적화"가 이 기준선의 핵심이다. 전형적인 실패 사례는 정위를 건너뛰고 바로 최적화(타임아웃 추가, 캐시 추가)로 갔기 때문이었고, 그 결과 최적화가 엉뚱한 지점에 꽂혔다.

#3층 — 생산 배치의 이상 처리 디테일

1. 대유량 시나리오에서 핵심 Agent에는 자원 격리 + 다중 복제본 재해 대응을 붙여 단일 지점 장애가 클러스터를 끌어내리지 않게 한다.
2. Agent 온라인 배치 전 안전 평가·성능 부하 테스트·나쁜 사례 테스트를 반드시 거친다 — 온라인 즉시 장애를 막는다.
3. Token 소모·응답 시간·실패율 임계치 및 경보를 설정해 잠재 리스크를 사전에 발견한다.
4. 이력 회화와 상태 데이터를 정기 정리해 단일 Agent 자원 점유를 통제한다.
5. 빠르게 최적화할 수 없는 장애를 만나면 기초 대형모델 호출 또는 정적 규칙으로 임시 강등해 서비스 전체 가용성을 지킨다.
6. Prompt·로직 심사 메커니즘을 세워 배치 전 부적격 설계를 걸러내 원천에서 장애 발생을 막는다.

여섯 항목이 장애 생애주기 전체를 덮는다 — 사전(심사·부하 테스트·Prompt 검토) → 사중(경보 임계치·강등 폴백) → 사후(상태 정리·재해 대응).

#핵심 통찰

1. Agent의 생산 장애는 본질적으로 분산 시스템 장애이지 프레임워크 사용법 문제가 아니다 — 교착, 눈사태, 우선순위 역전, 멱등, 재해 대응이라는 어휘 전부가 전통 고가용성 공학에서 왔고 작용 대상만 Agent와 도구 호출로 바뀌었을 뿐이다. 백엔드/SRE 경험은 그대로 옮겨오고, 프레임워크 경험만 있는 쪽은 옮겨올 기반이 없다.
2. 타임아웃은 만능 종료 수단이 아니다 — 호출은 끊지만 의존 고리는 못 끊는다 — 순환 의존과 자원 교착은 구조 문제이므로 정답은 교착 탐지 + 순환 차단, 그리고 협업 층에서의 통일 재정 조정기다.
3. 컨텍스트 관리는 "절단"에서 "검색"으로 격상돼야 한다 — 손실 있는 절단은 장기 작업의 핵심 중간 결론을 날려버릴 수 있다. 슬라이딩 윈도우 + 벡터 검색은 윈도우로 최근 연속성을, 검색으로 밀려난 정보를 필요 시 불러와 Token 총량을 통제하면서도 정보 완전성을 지킨다.
4. 느림과 시스템적 느림은 다른 병이다 — 단일 지점인지 정체인지 먼저 판정하고 약을 고를 것 — 단일 지점은 타임아웃/재시도/확장으로, 시스템적 정체는 스케줄링 자체를 손봐야 한다 — 풀링으로 병행 총량을 제한, 대기열 등급 분리로 우선순위 역전을 막는다. 정체에 재시도를 얹으면 자가 DDoS가 된다.
5. 다중 Agent 협업의 비용은 병행성이 아니라 일관성이다 — 작업 분할 혼란, 도구 중복 호출은 자원 낭비와 결과 불일치라는 이중 손실을 낳는다. 멱등 검증은 중복 실행의 부작용을, 조정기는 분할·귀합의 재정권을 각각 해결한다.
6. 존량 시스템의 정답은 항상 "어떻게 그레이 출시하고 어떻게 폴백할 것인가"를 포함한다 — 최적 기술 방안도 안전하게 배포할 수 없으면 실전에서는 0점이다. 그레이 출시 + 폴백은 가점 항목이 아니라 필수 항목이다.
7. 업무 분류는 모든 격리 수단의 전제다 — "핵심 거래/고객센터"와 "백그라운드 분석/콘텐츠 생성"의 분류가 먼저 있어야 자원 격리·트래픽 제한·우선순위 대기열이 근거를 갖는다. 분류를 건너뛰고 격리부터 하면 파라미터를 감으로 잡는 설정만 남는다.
8. 최고급 장애 처리는 장애가 발생하지 않게 만드는 것이다 — Prompt·로직 심사 메커니즘으로 배치 전 부적격 설계를 걸러내는 것은 나머지 모든 수단이 "이미 난 병을 고치는" 것과 달리 품질을 설계 심사 단계로 왼쪽 이동시키는 유일한 항목이다.

#엔지니어링 실전 Tips

• "먼저 정위 후 최적화"를 강제 기준선으로 삼을 것. 추가하는 모든 타임아웃 값, 캐시, 병행 수는 트레이싱 링크나 트레이스 데이터를 가리킬 수 있어야 하며, 아니면 그냥 감으로 파라미터를 만지는 것이다.
• 네 가지 관측 설비를 동시에 갖출 것. 전링크 트레이싱(호출 토폴로지·소요시간), 스케줄링 대시보드(대기열·자원), Token 소모 로그(컨텍스트 증가), 도구 호출 트레이스(외부 의존) — 로그만 있고 트레이스가 없으면 "느리다"는 알아도 "어디서 느린지"는 못 짚는다.
• 멱등 검증은 회로 차단 재시도와 짝으로 다닐 것. 멱등 없는 재시도는 증폭기다 — 다중 Agent가 도구를 중복 호출하는 상황에서 한 번의 중복이 N번의 부작용으로 번진다.
• 풀링과 대기열 등급 분리는 서로 다른 문제를 푼다. 풀링은 병행 총량 제한(자원 점유 방지), 등급 분리는 우선순위 역전 방지(핵심 작업이 백그라운드 작업 뒤로 밀리는 것 방지) — 풀링만 하고 등급 분리를 안 하면 핵심 요청이 여전히 굶을 수 있다.
• 장시간 작업엔 상태 영속화까지 설계할 것, 비동기화만으로는 부족하다. 분할 + 비동기는 블로킹을 프런트에서 치우는 것뿐이고, 상태 영속화가 있어야 인스턴스 재시작·복제본 전환 후에도 작업이 이어서 돈다 — 이것이 다중 복제본 재해 대응이 성립하는 전제다.
• 경보 임계치는 업무가 체감하기 전에 걸 것. Token 소모·응답 시간·실패율은 각각 비용·경험·가용성 축에 대응한다 — 임계치 경보의 가치는 "잠재 리스크를 미리 발견"하는 데 있으니, 사고 확인기로 설정하면 의미가 없다.
• 강등 최저선을 미리 준비할 것. 기초 대형모델 호출 또는 정적 규칙 폴백 — "이 장애는 빠르게 최적화가 안 된다"는 것을 인정하고 미리 퇴로를 마련하는 것이 현장에서 강행 수리하는 것보다 서비스 전체 가용성을 더 확실히 지킨다.