그래서 최근 성숙한 팀들은 에이전트 운영을 binary하게 보지 않습니다. 자동 또는 수동, 승인 또는 거절처럼 두 단계로만 나누지 않고, 리스크와 불확실성에 따라 실행자 → 검증자 → 상위 모델 또는 전용 런타임 → 사람 리뷰어 → 최종 책임자로 이어지는 Escalation Policy Ladder를 둡니다. 저는 이 흐름이 Harness Engineering에서 말한 실행 프레임, Test Evidence Pipeline의 증거 묶음, Capability Lease의 작업 단위 권한, Agent Handoff Packet의 전달 구조를 한 축으로 묶는 계층이라고 봅니다. 실행자가 혼자 다 처리하는 시대가 아니라면, 승격 규칙이 곧 운영 체계입니다. 전체 흐름을 먼저 훑고 싶다면 /posts/ 아카이브에서 최근 에이전트 운영 거버넌스 글을 순서대로 따라가도 맥락이 잘 이어집니다.

중요한 점은 escalation이 꼭 “더 큰 모델을 부른다"는 뜻이 아니라는 사실입니다. 때로는 상위 추론 모델로 보내는 것이고, 때로는 schema validator나 policy engine으로 보내는 것이고, 때로는 specialist runtime이나 sandbox replay로 넘기는 것이고, 때로는 사람 승인으로 멈추는 것입니다. 결국 핵심은 문제가 생긴 뒤 사람을 호출하는 구조가 아니라, 문제 가능성이 커지는 순간 더 적절한 판단 계층으로 질서 있게 옮기는 구조입니다.

이 글에서 얻는 것

• Escalation Policy Ladder가 단순 human-in-the-loop보다 왜 더 실전적인 구조인지 이해할 수 있습니다.
• 어떤 조건에서 validator, 상위 모델, specialist runtime, 사람 리뷰어로 승격해야 하는지 숫자 기준을 잡을 수 있습니다.
• 과승격으로 속도를 잃는 경우와 과소승격으로 사고를 내는 경우를 어떤 지표로 구분할지 판단할 수 있습니다.

핵심 개념/이슈

1) 지금 문제는 자동화 부족보다 “승격 경계 부재"다

실무에서 에이전트 품질 사고는 흔히 모델 정확도 문제처럼 보이지만, 실제 운영 원인은 더 앞에 있는 경우가 많습니다.

• 확신이 낮은데도 같은 세션이 끝까지 실행한다.
• evidence가 부족한데도 그냥 PR을 만든다.
• 권한 범위가 커졌는데 같은 실행자가 계속 진행한다.
• 장시간 작업이 꼬였는데도 handoff 없이 재시도만 반복한다.
• 외부 전송이나 운영 변경으로 범위가 넓어졌는데 인간 검토로 못 올라간다.

이런 상황에서 필요한 것은 “더 똑똑한 모델"이 아니라, 언제 계층을 바꿔야 하는가를 정하는 정책입니다. 그래서 Escalation Policy Ladder의 핵심은 모델 라우팅 최적화보다 운영 경계 고정에 있습니다. 이 흐름은 이미 컨텍스트 엔지니어링은 프롬프트가 아니라 런타임 거버넌스 경쟁이다에서 예고됐습니다. 당시에도 중요한 것은 정답률보다 세션 토큰/툴 호출/모델 승격 조건을 수치로 정하는 일이었습니다. 이제 그 승격 개념이 더 넓은 운영 계층으로 확장되는 셈입니다.

2) escalation 대상은 “더 큰 모델” 하나가 아니라 여러 판단 계층이다

현장에서 escalation을 모델 업그레이드로만 이해하면 금방 막힙니다. 실제 ladder는 아래처럼 여러 방향으로 갈라집니다.

• validator escalation: 형식, 정책, 민감도 검사 계층으로 승격
• advisor escalation: 상위 추론 모델이나 reviewer model로 승격
• runtime escalation: 일반 세션에서 specialist runtime, replay sandbox, dedicated harness로 이동
• human escalation: 사람 리뷰어, 운영자, 최종 승인자에게 승격
• ownership escalation: 기술 판단을 넘어서 서비스 owner나 보안 책임자에게 전환

예를 들어 문서 초안 작성은 validator만 거쳐도 충분할 수 있습니다. 하지만 infra 설정 변경은 상위 모델 자문을 붙이더라도 최종적으로 사람 승인으로 올라가야 할 수 있습니다. 또 긴 디버깅 작업은 같은 세션에서 버티기보다 Stateful Sandbox Snapshot 기반 specialist runtime으로 넘기는 편이 낫습니다. 반대로 범위가 좁고 evidence가 충분한 low-risk 코드 수정은 사람까지 안 올라가도 됩니다.

핵심은 escalation이 “막는다"가 아니라 더 맞는 판단자에게 넘긴다는 점입니다. 그래서 ladder는 제동장치이면서 동시에 throughput 장치이기도 합니다.

3) 좋은 ladder는 난이도보다 “리스크 × 불확실성 × 범위"로 승격한다

아래 표처럼 한 장으로 기준을 고정해 두면, 회의 때마다 “이번 건 느낌상 위험해 보여요” 같은 말로 흔들릴 일이 확실히 줄어듭니다.

이 표의 장점은 조건을 정성 표현에서 정량 문장으로 옮겨 준다는 점입니다. risk score, evidence completeness, retry count처럼 숫자로 바꿀 수 있는 지표는 최대한 숫자로 박아 두는 편이 좋습니다.

많은 팀이 escalation 조건을 “어려운 작업이면 올린다” 정도로 적는데, 이건 실전에서 거의 쓸모가 없습니다. 어려운 작업의 정의가 애매하기 때문입니다. 더 실전적인 기준은 아래 세 축입니다.

1. 리스크: 잘못되면 복구 비용과 영향 반경이 얼마나 큰가
2. 불확실성: 모델 또는 런타임이 현재 판단에 얼마나 확신이 낮은가
3. 범위: 변경 파일 수, 시스템 수, 데이터 민감도, 외부 영향이 얼마나 넓은가

그래서 ladder는 아래처럼 설계하는 편이 낫습니다.

• risk score 7/10 이상이면 사람 또는 owner escalation 검토
• evidence completeness 80% 미만이면 validator/advisor escalation
• 수정 파일 수가 10개 초과이거나 서비스 영향 범위가 2개 이상이면 review escalation
• 외부 전송, 배포, 권한 변경, 삭제가 포함되면 human approval escalation 필수
• 동일 작업에서 retry가 2회 초과되면 같은 계층 재시도보다 상위 계층 승격 우선

이 구조는 Change Intelligence Control Plane과 닮아 있습니다. 좋은 control plane이 diff를 그대로 읽지 않고 위험도와 증거를 함께 보듯, 좋은 escalation도 “어려워 보인다"가 아니라 위험, 증거, 범위, 복구 가능성을 함께 봐야 합니다.

4) ladder가 의미 있으려면 lease, receipt, handoff가 같이 움직여야 한다

계층만 나눠 놓고 경계 정보가 없으면 escalation은 단순 전달이 됩니다. 실무에서 진짜 중요한 것은 “왜 올렸는가"와 “올라간 뒤 무엇을 이어받는가"입니다.

그래서 최소한 아래 연결이 있어야 ladder가 운영 단위로 작동합니다.

• Capability Lease: 현재 계층에서 허용된 범위가 무엇인가
• Execution Receipt: 지금까지 실제로 무엇이 실행됐는가
• Handoff Packet: 다음 계층이 무엇을 이어받아야 하는가
• Evidence Bundle: 어떤 테스트, 로그, diff, 판단 근거가 모였는가

예를 들어 에이전트가 코드 3개 수정 후 테스트 2개만 통과한 상태에서 escalation한다고 해 보겠습니다. 이때 그냥 “사람 검토 필요"라고 넘기면 리뷰어는 다시 맥락을 읽어야 합니다. 반대로 Execution Receipt와 Agent Handoff Packet이 붙어 있으면, 리뷰어는 무엇을 수정했는지, 무슨 테스트가 통과했는지, 어떤 권한 범위였는지, 왜 여기서 멈췄는지를 한 번에 봅니다. ladder의 목적은 계층을 늘리는 것이 아니라 계층 전환 비용을 줄이는 것입니다.

5) 진짜 KPI는 승격률 자체가 아니라 “과승격과 과소승격의 균형"이다

초기 도입 팀은 escalation rate를 낮추는 것을 좋은 일로 착각하기 쉽습니다. 하지만 승격률이 낮다고 운영이 성숙한 것은 아닙니다. 위험한 작업이 적절히 안 올라가는 missed escalation이 더 위험할 수 있습니다. 반대로 뭐든 사람에게 올리면 throughput이 급격히 떨어집니다.

그래서 최소한 아래 지표를 같이 봐야 합니다.

• over_escalation_rate: 굳이 상위 계층으로 안 올라도 됐던 비율
• missed_escalation_incident_rate: 올라갔어야 할 작업이 안 올라가 문제를 낸 비율
• escalation_to_resolution_p95: 승격 후 해결까지 걸린 시간
• escalation_evidence_completeness: 승격 건 중 필요한 근거가 함께 올라간 비율
• repeat_escalation_rate: 같은 작업이 사다리를 오르내리며 다시 승격되는 비율

권장 출발값 예시는 아래 정도가 현실적입니다.

• high-risk 작업의 missed escalation: 1% 미만
• low-risk 작업의 over escalation: 15% 미만
• escalation packet evidence completeness: 95% 이상
• escalation-to-resolution p95: 30분 이내
• 동일 작업 repeat escalation: 10% 미만

핵심은 승격을 줄이는 것이 아니라, 비싼 승격은 꼭 필요할 때만 하고 필요한 승격은 놓치지 않는 것입니다.

실무 적용

1) 최소 Escalation Policy Ladder는 4단이면 충분하다

처음부터 7단, 8단 계층으로 설계하면 운영자가 더 헷갈립니다. 대부분 팀은 아래 4단으로 시작하면 충분합니다.

1. Executor: 기본 실행 계층, low-risk 작업 처리
2. Validator/Advisor: schema, policy, 상위 추론 검토 계층
3. Specialist Runtime or Reviewer: replay sandbox, code review runtime, domain specialist
4. Human Owner/Approver: 최종 책임자, 운영자, 보안 리뷰어

중요한 것은 각 단계의 역할을 문장 하나로 고정하는 것입니다.

• Executor: 정의된 범위 안에서 실행한다.
• Validator/Advisor: 실행 가능성, 품질, 정책 충돌을 판정한다.
• Specialist/Reviewer: 높은 불확실성 또는 장기 작업을 재현 가능한 환경에서 좁힌다.
• Human Owner: 복구 비용이 큰 결정에 책임을 진다.

이 구조는 Harness Engineering에서 말한 실행자와 handoff 조건, Schema Constrained Output + Runtime Validator에서 말한 accept/repair/escalate 3분류, Approval-Driven Auto-Remediation의 승인 경계와 자연스럽게 맞물립니다.

2) 의사결정 기준(숫자·조건·우선순위)

실무에서는 아래 순서로 판단하면 과도하게 흔들리지 않습니다.

1순위, 외부 영향 여부

• 외부 전송, 배포, 권한 변경, 삭제 포함 시 human escalation 필수
• 고객 데이터, 비밀값, 규정 민감 영역 접근 시 human 또는 security escalation

2순위, 증거 충분성

• evidence completeness 80% 미만이면 validator/advisor escalation
• 테스트 또는 재현 로그가 없는 변경은 specialist runtime 또는 reviewer escalation

3순위, 범위와 복구 비용

• 수정 파일 10개 초과, 서비스 영향 2개 이상, 롤백 난이도 높음이면 reviewer escalation
• 예상 blast radius가 한 팀 경계를 넘으면 owner escalation

4순위, 불확실성과 반복 실패

• 동일 작업 retry 2회 초과 시 상위 계층 승격
• confidence 0.7 미만 또는 contradictory evidence 감지 시 advisor escalation
• 작업 지속시간 15분 초과 + progress ambiguity 존재 시 handoff/runtime escalation

이때 추천 우선순위는 리스크 보호 > 근거 확보 > 범위 통제 > 속도 최적화입니다. 속도는 마지막입니다.

3) 단계별 exit rule을 명시해야 escalation loop가 줄어든다

계층이 늘어날수록 중요한 것은 “언제 올릴까” 못지않게 “언제 여기서 끝내고 언제 다시 내려보낼까"입니다. exit rule이 없으면 같은 작업이 실행자와 리뷰어 사이를 왔다 갔다 합니다.

예를 들어 아래처럼 적는 편이 좋습니다.

• Executor → Validator: schema/policy warning 1회 이상 또는 confidence < 0.7
• Validator → Specialist Runtime: evidence 부족이 아니라 재현 환경 부족일 때
• Specialist Runtime → Human: 재현은 됐지만 trade-off 결정이 남았을 때
• Human → Executor 재하향: 승인 scope와 success criteria가 다시 명확해졌을 때

핵심은 계층마다 다음 계층으로 올리는 이유와 다시 실행 계층으로 되돌리는 조건을 같이 적는 것입니다. 그래야 ladder가 one-way approval queue가 아니라, 실제로 throughput을 높이는 구조가 됩니다.

4) escalation packet 템플릿을 고정하면 사람 피로가 크게 줄어든다

실제로 운영에 넣을 때는 역할별로 어떤 판단을 맡길지도 같이 붙여 두는 편이 좋습니다. 같은 4단 ladder라도 누가 무엇을 결정하는지가 흐리면 다시 approval queue로 무너집니다.

이 구분이 있으면 validator가 owner처럼 행동하거나, owner가 매번 사소한 evidence 누락까지 직접 보게 되는 병목을 줄일 수 있습니다.

실무에서는 승격 자체보다 승격 메시지 품질이 더 자주 문제입니다. 그래서 저는 아래 필드를 강하게 고정하는 편을 추천합니다.

• why_escalated: 왜 여기서 올렸는가
• risk_summary: 무엇이 위험한가
• evidence_refs: 테스트, 로그, diff, receipt 링크
• current_scope: 현재 권한과 변경 범위
• decision_needed: 다음 계층이 무엇을 결정해야 하는가
• recommended_next_action: 권장 다음 행동 1~3개

이 템플릿은 Agent Handoff Packet을 사람과 상위 런타임 승격용으로 좁혀 쓴 형태라고 보면 됩니다. 손으로 긴 설명을 쓰는 것보다, 다음 계층이 지금 무엇을 판단해야 하는지를 구조화하는 쪽이 훨씬 낫습니다.

5) 4주 도입 순서

1주차: 최근 사고와 과잉 승인 사례를 같이 모은다
missed escalation 5건, over escalation 5건만 모아도 ladder 설계 감이 생깁니다.

2주차: 4단 ladder와 exit rule 고정
작업군별로 executor, validator, specialist, human owner 역할을 한 줄씩 씁니다.

3주차: receipt, lease, handoff 연결
escalation이 단순 알림이 아니라 근거 묶음을 들고 올라가도록 Execution Receipt와 Capability Lease를 연결합니다.

4주차: KPI 측정과 threshold 조정
over-escalation, missed-escalation, resolution time을 보며 1, 2개 규칙만 조정합니다. 처음부터 정교화하려 하면 실패합니다.

트레이드오프/주의점

첫째, 계층이 많아질수록 느려질 수 있습니다. 그래서 무조건 계층을 추가하기보다, 각 계층이 실제로 다른 판단을 하는지 확인해야 합니다.

둘째, 모델 confidence 하나로 승격하면 위험합니다. confidence는 근거 부족이나 scope expansion을 잘 반영하지 못할 수 있습니다. risk와 evidence를 같이 봐야 합니다.

셋째, 사람 승격을 만능 해법처럼 쓰면 reviewer burnout이 옵니다. low-risk 작업은 validator와 specialist runtime 선에서 닫아야 합니다.

넷째, handoff 품질이 낮으면 escalation 자체가 병목이 됩니다. 상위 계층이 처음 10분을 맥락 재구성에 쓰면 ladder는 이름만 남습니다.

다섯째, owner escalation과 approval escalation을 섞으면 책임이 흐려집니다. 의견 자문이 필요한 것과 최종 책임 승인이 필요한 것은 분리하는 편이 낫습니다.

체크리스트 또는 연습

체크리스트

• 자동 또는 수동 두 단계가 아니라 최소 3~4단 escalation 계층을 정의했다.
• escalation 조건을 난이도가 아니라 리스크, 불확실성, 범위로 적었다.
• 외부 전송, 배포, 권한 변경, 삭제는 human escalation 규칙이 있다.
• escalation packet에 why, risk, evidence, decision_needed가 들어간다.
• receipt, lease, handoff가 escalation과 연결된다.
• over-escalation과 missed-escalation을 같이 측정한다.

연습 과제

1. 현재 쓰는 AI 워크플로 1개를 골라 executor, validator, specialist runtime, human owner 네 계층으로 다시 나눠 보세요. 지금은 어떤 계층이 비어 있는지 적어 보세요.
2. 최근 위험했던 작업 3건을 골라, 왜 더 일찍 escalation되지 않았는지 리스크/증거/범위 세 칸으로 재분석해 보세요.
3. 반대로 굳이 사람까지 올라갔던 low-risk 작업 3건을 골라, validator나 specialist runtime에서 닫을 수 있었는지 기준을 적어 보세요.

자주 부딪히는 운영 질문

Q1. 스타트업처럼 사람 수가 적은 팀도 ladder를 나눠야 할까?

그렇습니다. 사람 수가 적을수록 더 필요합니다. 계층을 사람 수만큼 늘리라는 뜻이 아니라, 어떤 판단을 같은 사람의 다른 역할로 처리할지라도 경계를 분리하라는 의미에 가깝습니다. 예를 들어 한 명의 팀 리드가 validator와 final approver를 모두 맡더라도, “증거가 충분한지 확인하는 단계"와 “위험을 감수하고 승인하는 단계"를 문장으로 분리해 두면 피로도와 실수를 동시에 줄일 수 있습니다.

Q2. 상위 모델 승격이 꼭 좋은 답일까?

아닙니다. 불확실성이 높다고 해서 항상 더 큰 모델을 부르는 것은 비용만 늘리고 책임 경계를 흐릴 수 있습니다. 스키마 위반, 포맷 오류, 근거 부족처럼 판단보다 검증이 필요한 문제는 validator가 더 싸고 정확합니다. 반대로 재현 환경이 꼬인 문제는 model escalation보다 specialist runtime escalation이 훨씬 낫습니다. 승격은 “누가 더 똑똑한가"보다 “누가 지금 문제를 가장 싸고 명확하게 좁힐 수 있는가"로 결정하는 편이 실전적입니다.

Q3. 팀에 바로 적용하려면 오늘 무엇부터 시작하면 좋을까?

가장 먼저 할 일은 최근 한 달 작업 중 올라갔어야 했는데 안 올라간 건과 굳이 올라갈 필요 없었던 건을 각각 3건씩 고르는 것입니다. 이 6건만 재분석해도 지금 팀이 missed escalation에 더 취약한지, over escalation에 더 취약한지 감이 옵니다. 그다음에는 외부 전송, 배포, 권한 변경, 삭제 네 가지에만 human escalation을 강제하고, 나머지는 evidence completeness와 retry count 규칙부터 얹는 식으로 작게 시작하는 편이 좋습니다.

관련 글

• Harness Engineering, 에이전트 성능보다 실행 프레임이 중요해진다
• Test Evidence Pipeline
• Stateful Sandbox Snapshot
• Capability Lease
• Execution Receipt
• Change Intelligence Control Plane
• Context Contract Registry
• Agent Handoff Packet