operating model fallback and escalation_ko

운영 모델: Fallback and Escalation

언어: 🇺🇸 English | 🇰🇷 한국어

Fallback and Escalation은 closed-loop reasoning을 여러 작업 크기에 적용하는 운영 모델이다. 핵심은 단순 retry가 아니라, mismatch가 발생한 위치에 맞춰 적절한 layer로 되돌아가고 다시 앞으로 나아가는 것이다.

이 모델에서 fallback은 후퇴가 아니다. 더 나은 기준으로 다시 전진하기 위한 교정이다.

Contents

• 8단계 운영 루프
• Focus Layers
• Micro
• Meso
• Macro
• Meta
• Escalation
• Practical Reading
• 관련 문서

8단계 운영 루프

비자명한 작업은 다음 흐름을 따른다.

1. 의미론적 분절
2. 잠정적 스킬 선택
3. 시작 지점 결정
4. 서브태스크 검증
5. 결합
6. 결합 산출물 검증
7. 작업 필요성 검증
8. 반복 또는 종료

첫 스킬 선택은 확정이 아니라 가설이다. 작업 중 reference와 맞지 않으면 분절 단위, 스킬 선택, 결합 방식, 작업 필요성까지 다시 본다.

Focus Layers

Ghost-ALICE OS는 작업 초점을 네 layer로 본다.

Layer	검증 대상	fallback 권한
micro	단일 도구 호출, 단일 편집, 단일 확인	호출 재시도, 인자 수정, 작은 편집 폐기
meso	하나의 sub-task 산출물	sub-task 재작성, 분해 단위 조정
macro	결합된 산출물 전체	일부 sub-task 재작업, 결합 방식 변경, 구조 재설계
meta	작업 자체의 필요성	작업 폐기, 범위 축소, 별도 작업으로 분리

focus는 micro에서 meta로 한 방향으로만 커지지 않는다. mismatch 위치에 따라 좁아지거나 넓어진다.

Micro

micro layer는 가장 작은 단위다. 예를 들면 한 번의 파일 읽기, 한 줄 수정, 한 명령 실행이다.

검증 기준은 단순하다.

• 명령이 성공했는가
• 출력 형식이 기대와 맞는가
• 읽은 파일이 맞는가
• 편집 대상이 boundary 안에 있는가

micro mismatch는 보통 비용이 낮다. 하지만 micro pass가 macro pass를 뜻하지는 않는다.

Meso

meso layer는 하나의 sub-task를 본다. 예를 들면 문서 한 절 정리, 특정 설치 절차 검토, 한 스킬의 설명 정리 같은 단위다.

여기서는 산출물이 의도한 역할을 실제로 수행하는지 본다.

• 이 sub-task가 사용자 요구와 맞는가
• 필요한 source를 모두 봤는가
• output이 schema나 문서 계약을 만족하는가
• 다음 sub-task와 결합 가능한가

meso mismatch가 나오면 sub-task를 다시 쓰거나 분해 단위를 바꾼다.

Macro

macro layer는 여러 sub-task를 결합한 전체 결과를 본다.

부분은 모두 맞아도 전체가 틀릴 수 있다. 예를 들면 각 문서는 깨끗해졌지만 README에서 링크가 끊기거나, 개별 패치는 맞지만 공개 릴리즈 메시지가 흐려지는 경우다.

macro 검증은 다음을 본다.

• 부분들이 서로 모순하지 않는가
• 전체 산출물이 원래 의도와 일치하는가
• public/private boundary가 유지되는가
• 완료 claim이 evidence와 연결되는가

macro mismatch는 구조 재설계까지 갈 수 있다.

Meta

meta layer는 작업 자체를 검증한다.

새 작업, 새 파일, 새 검증 cycle, 후속 제안이 떠오르면 바로 실행하지 않는다. 먼저 물어야 할 질문은 하나다.

이 작업이 정말 필요한가.

필요성 판단은 다음 기준을 본다.

• 실제 문제 evidence가 있는가
• 지금 하지 않으면 회귀 위험이 커지는가
• 회복 비용 대비 이득이 충분한가
• 기존 scope 안에서 해결 가능한가
• 공개 문서에 남길 가치가 있는가

이 layer가 없으면 에이전트는 쉽게 padding, speculative work, manufactured follow-up을 만든다.

Escalation

에이전트가 혼자 닫을 수 없는 claim은 사람에게 넘긴다. 특히 다음 경우는 escalation 후보다.

• 외부 법령, 정책, 계약 해석
• 숫자, 성능, 재무, 보안 claim
• public release boundary가 애매한 문서
• private/customer context가 섞일 수 있는 결정
• 여러 source가 서로 충돌하는 경우

Escalation은 실패가 아니다. 에이전트가 판정 권한 밖으로 나가지 않는다는 신호다.

Practical Reading

이 모델을 실제 작업에서 읽으면 다음과 같다.

• 작은 성공이 전체 성공을 의미하지 않는다.
• 전체 mismatch가 나오면 작은 단위로 되돌아갈 수 있다.
• 새 아이디어가 떠올라도 필요성 검증 전에는 작업이 아니다.
• 완료는 evidence map으로 닫힌다.

Ghost-ALICE OS는 앞으로 가기 위해 되돌아간다. 이것이 fallback-forwarding의 의미다.

관련 문서

• 설계 철학: Floor, Not Ceiling
• 운영 모델: Closed-Loop Reasoning
• Ghost-ALICE OS 전체 설계