AI 에이전트가 감독 없이 일할 수 있는 시점은 어떻게 판단할까 — Evan Kormos (Coinbase)

URL: https://www.youtube.com/watch?v=_4Ph2dhmUFI 날짜: 2026-10-20 (원본 게시일: 2026-10-19) 채널: aiDotEngineer 발표자: Evan Kormos, Coinbase 플레이어 코치

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==조직의 정책을 바깥 경계로 고정하고, 각 업무 노드의 검증 가능성·추적성·사람 대체 경로를 갖춘 뒤, 통계적 신뢰도가 정책 임계값에 도달할 때 에이전트의 자율성을 단계적으로 넓혀야 한다.==

• 정책은 조직의 제도적 의도이자 에이전트가 따르는 원래의 시스템 프롬프트다.
• 프로세스 전체는 결정론적으로 통제하고, 개별 노드 안의 작업은 에이전트가 적응적으로 수행하게 한다.
• 신뢰는 모델에 대한 느낌이 아니라 대표 데이터셋 평가, 반복 측정, 런타임 추적, 사람 검토로 축적한다.

정책으로 허용 범위와 위험·준수 조건을 정하고, DAG로 업무의 의존성과 통제 지점을 표현한다. 각 노드에서 에이전트가 산출한 결과를 제한된 루프로 점검하며, 실제 데이터의 반복 평가로 신뢰도를 측정한다. 전수 감독에서 표본 검토로, 다시 예외 중심의 사람 개입으로 옮기는 것이 자율 실행으로 가는 경로다.

1. 정책은 조직의 의도이며 실행을 둘러싼 경계다

1.1. 정책을 실행 규칙과 시스템 프롬프트로 다룬다

1. 정책은 조직의 제도적 의도다
   1. 정책은 조직 안에서 일이 처리되는 방식, 특히 위험 관리와 규정 준수를 정한다.
   2. 제도적 의도를 문서로 남겨야 구성원과 시스템이 공통 규칙을 기준으로 판단할 수 있다.
2. 규범적 표현이 허용 범위를 만든다
   1. must, may, should 같은 표현은 무엇을 반드시 해야 하는지, 허용할 수 있는지, 권고하는지를 구분한다.
   2. 이 표현들이 조직 운영의 규칙과 의사결정 기준을 구성한다.
3. 정책은 에이전트의 원래 시스템 프롬프트에 해당한다
   1. 정책을 모델에 전달할 프롬프트 문구로만 축소하지 않고, 조직이 본래 의도한 업무 원칙으로 본다.
   2. 에이전트의 행위는 이 제도적 의도와 위험·준수 경계 안에 머물러야 한다.

1.2. 정책을 만드는 시점과 시스템이 작동하는 시점을 구분한다

1. 빌드 상태와 런타임 상태는 서로 다른 시간축이다
   1. 빌드 상태에서는 정책을 정의하거나 변경하고, 그 정책이 실행 가능한 형태로 반영되는 컴파일 단계를 거친다.
   2. 런타임 상태에서는 실제 업무 시스템이 계속 움직이며 작업과 데이터가 변화한다.
2. 정책 변경은 간헐적이지만 제품 변화는 빠르다
   1. 조직은 정책을 수정하는 동안에도 시스템을 멈추지 않고 계속 운영한다.
   2. 제품 주도 변화(product-driven changes)는 빠르게 일어나므로, 매번 정책을 다시 쓰지 않아도 실행이 대체로 정책에 구속되어야 한다.
3. 빠르게 변하는 실행을 안정된 정책 경계 안에 둔다
   1. 정책 작성·컴파일과 실제 처리 상태를 분리하면, 지속적으로 움직이는 런타임과 통제 기준을 혼동하지 않는다.
   2. 정책은 바깥 경계로 남고, 그 안의 제품 및 업무 실행은 변화에 대응한다.

1.3. 에이전트는 사람·프로세스·기술을 가로지른다

1. 조직 운영은 사람, 프로세스, 기술로 볼 수 있다
   1. 사람은 업무를 판단하고 수행하며, 프로세스는 업무가 흐르는 순서와 통제를 정하고, 기술은 그 흐름을 뒷받침한다.
   2. 에이전트는 세 요소 중 하나에만 속하지 않고 세 요소를 가로지르는 운영 모델이다.
2. 에이전트는 세 요소와 각각 연결된다
   1. 사람과 함께 일하고, 프로세스의 일부를 직접 실행하며, 기술을 사용하면서 기술 구성요소로도 작동한다.
   2. 자율성 설계의 초점은 에이전트가 프로세스와 만나는 지점, 즉 맡길 업무·설정할 경계·출력에 대한 신뢰를 정하는 데 있다.

2. 조직의 업무를 DAG로 표현하고 필요한 통제를 보존한다

2.1. 흐름도와 의존성을 먼저 드러낸다

1. 업무에는 승인과 검증이라는 게이트가 있다
   1. 변경 사항은 실제 반영 전에 승인을 받아야 할 수 있다.
   2. 고객은 계정 개설 전에 신원 확인을 통과해야 할 수 있다.
2. 에이전트 도입은 업무의 병렬화 가능성을 다시 살핀다
   1. 기존에는 비용이 너무 높거나 조정이 복잡해 순차적으로 하던 작업도 있었다.
   2. 서로 독립된 검토를 동시에 실행하고 결과를 합칠 수 있지만, 반드시 필요한 승인과 검사는 그대로 유지한다.
3. DAG는 순환 없는 작업 의존성을 나타낸다
   1. 방향성 비순환 그래프(Directed Acyclic Graph, DAG)는 단계와 단계 사이의 의존성을 표현한다.
   2. 작업은 그래프의 화살표를 따라 앞으로 진행하며, 바깥 프로세스의 흐름은 이전 단계로 되돌아가는 순환 없이 구성된다.

2.2. 정책 중심 업무의 구체적인 DAG 사례

1. 상업 대출(commercial lending)
   1. 대출 업무의 정책 기반 절차와 의존성을 DAG로 표현할 수 있다.
   2. 고객 확인(KYC)과 재무 정보 검토는 병렬로 시작하고, 이후 신용 메모(credit memo), 위험 검토(risk review), 문서화(documentation), 의사결정(decision) 같은 단계로 연결할 수 있다.
2. 지역별 거래소 토큰 상장
   1. 특정 지역의 거래소에 토큰을 상장하는 절차를 하나의 정책 흐름으로 나타낼 수 있다.
   2. 각 지역에 적용되는 요건과 검토가 어느 단계에서 선행되어야 하는지 의존성으로 관리한다.
3. 규제 대상 소프트웨어 배포
   1. 규제 조건 아래에서 소프트웨어를 배포하는 과정을 DAG로 구성할 수 있다.
   2. 에이전트가 소프트웨어 전달에서 이미 효율성과 채택을 보여 준 만큼, 같은 효율을 다른 사업 영역으로 확장해 AI 도입 격차를 줄일 수 있다.
4. Airflow는 DAG를 코드로 관리하는 사례다
   1. Apache Airflow는 워크플로와 그 의존성을 Python 코드로 표현하고 관리하는 오픈소스 소프트웨어다.
   2. 그래프 형태를 사용하면 정책 기반 프로세스의 단계와 진행 조건을 명시적으로 다룰 수 있다.

2.3. 각 DAG 노드 안에는 피드백 순환이 있다

1. 코드 리뷰 노드는 작업을 점검하고 통과 여부를 결정한다
   1. 작업 결과가 다음 단계로 넘어갈 만큼 충분히 좋다고 판단되면 노드가 통과를 허용한다.
   2. 충분하지 않으면 리뷰 피드백을 작업에 반영하고, 기준을 만족할 때까지 다시 반복한다.
2. 노드 내부는 방향성 순환 그래프(DCG)다
   1. 바깥 업무 흐름이 DAG로 앞으로 진행하더라도, 한 노드 안의 작업·검토·수정은 순환을 이룬다.
   2. 방향성 순환 그래프(Directed Cyclic Graph, DCG)는 이 반복 상태와 피드백을 나타내며, LangChain의 LangGraph 같은 도구로 상태를 관리할 수 있다.
3. 실제 그래프는 단순한 코드 리뷰 예시보다 복잡하다
   1. 코드 리뷰 노드는 설명을 위한 단순화이며, 여러 작업과 조건이 얽힌 그래프는 훨씬 복잡해질 수 있다.
   2. 복잡성이 커질수록 흐름·상태·통과 기준을 명시하고 관찰하는 일이 중요해진다.

3. 병렬 처리와 예외 흐름까지 포함해 프로세스를 운영한다

3.1. 내부 협업과 외부 정책 경계를 함께 설계한다

1. 노드 안에서는 사람과 에이전트가 함께 작업한다
   1. 에이전트가 초안이나 검토를 맡고 사람이 결과를 판단하거나 피드백을 보태는 식으로 협업할 수 있다.
   2. 제한된 반복을 통해 결과가 충분한 품질에 도달하면 다음 노드로 넘긴다.
2. 노드 바깥에는 정책 경계가 둘러싼다
   1. 개별 노드의 적응적 작업은 조직 정책을 벗어나지 않아야 한다.
   2. 정책 경계와 각 노드의 검사 기준을 함께 두어 내부의 유연성과 전체 흐름의 통제를 양립시킨다.

3.2. 예외 흐름으로 막힘과 예상 밖의 결과를 다룬다

1. 모든 일이 정상 경로로 끝나지는 않는다
   1. 배포가 취소되거나 보안 기준을 만족하지 못하는 상황은 예외 흐름으로 분기해야 한다.
   2. 예외 처리는 작업이 흐름 중간에 멈춰 갇히지 않도록 하고, 어떤 문제가 발생했는지 알 수 있게 한다.
2. 모든 엣지 케이스를 미리 설계하려 들지 않는다
   1. 가능한 모든 예외를 사전에 나열하는 대신, 관찰 가능한 예외 경로를 마련한다.
   2. 실제로 어떤 일이 생기는지 모니터링해 유의미한 예외를 포착하고 프로세스를 개선한다.

3.3. 에이전트가 속도를 높이면 병목과 작업량이 이동한다

1. 빠른 코드 검토는 후속 단계의 처리량도 요구한다
   1. 코드 리뷰가 빨라지면 설계 또는 보안 스캔도 더 빨리 수행해야 할 수 있다.
   2. 에이전트 도입은 전체 작업량을 늘리고 흐름의 여러 지점에 새로운 부하를 만들 수 있다.
2. 프로세스 전체의 운영 지표를 관찰한다
   1. 병렬화와 효율 향상은 새로운 병목을 만들 수 있으므로, 전체 흐름을 계량화해 확인해야 한다.
   2. 워크플로 도구를 작성하고 구축하는 것보다 프로세스의 운영 가시성(operational visibility)이 더 중요할 수 있다.
3. 가시성을 바탕으로 통제를 유지하면서 용량을 더한다
   1. 흐름을 시각화하면 어디에서 대기와 병목이 발생하는지 파악할 수 있다.
   2. 필수 통제는 유지한 채 병렬 처리 용량을 추가하고, 속도가 빨라진 단계에 맞춰 다음 단계의 처리 능력을 조정한다.

4. 좋은 결과는 좋은 입력과 명확한 완료 기준에서 시작한다

4.1. 신뢰할 수 있는 컨텍스트를 전달한다

1. 입력 품질은 결과 품질과 계산 비용에 영향을 준다
   1. AI 엔지니어링에서는 입력과 출력의 변동성이 중요한 과제다.
   2. 더 높은 품질의 입력은 더 낮은 계산 비용으로 더 나은 결과를 만들 가능성을 높인다.
2. 컨텍스트 모델은 에이전트의 작업 위치를 알려 준다
   1. 정책과 업무 맥락이 잘 정리된 신뢰 가능한 컨텍스트를 에이전트에 제공한다.
   2. DAG의 현재 상태를 에이전트에 주입하면 전체 흐름에서 자신이 어느 위치에 있고 어떤 선행·후속 조건을 지켜야 하는지 알 수 있다.
3. 장기 목표는 루프 비용과 효율 최적화를 요구한다
   1. 목표가 긴 시간 범위로 확장될수록 반복 작업의 비용이 누적된다.
   2. 따라서 루프의 각 실행을 효율적으로 만들고 불필요한 반복을 줄여야 한다.

4.2. 무엇이 충분히 좋은지 정의하고 신뢰할 검사를 둔다

1. 통과 검사는 작업을 다음 단계로 보낼지 결정한다
   1. 검사는 결과가 기준을 만족했는지를 판별하는 지점이다.
   2. 무엇을 좋은 결과라고 볼지 도메인 전문가와 함께 명확하게 정의해야 한다.
2. 검사 자체가 신뢰할 수 있어야 한다
   1. 일관된 평가 방법이 없다면 반복을 더 많이 수행해도 결과가 더 좋아진다고 보장할 수 없다.
   2. 전체 루프의 신뢰성은 그 결과를 판정하는 검사(check)의 신뢰성만큼만 높다.
3. 좋은 입력만큼 좋은 평가 기준도 중요하다
   1. 입력 맥락을 논의하지 않고 출력 품질만 평가하면 신뢰도의 원인을 놓치기 쉽다.
   2. 대표적인 입력 조건과 명확한 완료 기준을 함께 마련해야 결과의 품질을 판단할 수 있다.

5. 확률적 결과에는 통계적 평가와 런타임 추적을 결합한다

5.1. 전통적인 소프트웨어의 신뢰 메커니즘을 출발점으로 삼는다

1. 전통적 소프트웨어는 테스트로 변경의 안전성을 확인한다
   1. 단위 테스트(unit tests)와 테스트 케이스를 전달 흐름에 포함해 코드 변경이 다른 기능을 깨뜨리지 않는지 검사한다.
   2. 이런 체계적 테스트는 소프트웨어 품질에 대한 확신을 만드는 전통적인 신뢰 메커니즘이다.
2. AI를 소프트웨어 품질 개선의 기회로 본다
   1. 내구성 있는 소프트웨어(durable software)를 둘러싼 논의처럼, 품질을 높이는 방향으로 AI를 활용할 수 있다.
   2. 기존 테스트의 강점을 유지하면서 확률적 출력에 맞는 평가 방법을 보완해야 한다.

5.2. 정답 문자열 비교 대신 대표 데이터셋을 반복 평가한다

1. 동일한 요청도 에이전트는 서로 다른 답을 낼 수 있다
   1. 에이전트는 확률적으로 동작하므로 입력이 같아도 출력이 달라질 수 있다.
   2. 서로 다른 여러 답이 모두 허용 가능한 경우에는 하나의 정답 문자열과 일치하는지만 비교할 수 없다.
2. 대표 데이터셋에서 품질을 측정한다
   1. 실제 입력을 대표하는 데이터셋을 만들고, 좋은 결과의 기준을 정의한다.
   2. 평가를 반복된 일련의 실행으로 수행하고 결과를 표본 규모에 걸친 통계적 분석으로 본다.
3. 반복 횟수만으로 품질이 보장되지는 않는다
   1. 반복은 신뢰할 검사가 있을 때만 의미가 있다.
   2. 측정 가능한 품질 기준이 없으면 더 많은 시도가 좋아졌다는 증거가 되지 않는다.

5.3. 평가(evals)와 추적(trace)을 테스트에 더한다

1. 평가는 사전 정의한 기준에 대한 품질 근거를 만든다
   1. 대표 데이터셋과 반복 실행의 평가 결과를 통계적으로 분석한다.
   2. 모델에 대한 막연한 느낌 대신 조사와 통계로 에이전트 품질을 제시한다.
2. 추적은 실제 실행에서 일어난 일을 기록한다
   1. 런타임 추적(trace)은 시스템이 실행되는 동안 어떤 일이 발생했는지 남기는 로그다.
   2. 추적을 통해 사람이 보지 않은 출력도 품질 기준을 충족했는지 확인할 수 있다.
3. 테스트·평가·추적은 상호 보완적인 신뢰 장치다
   1. 전통적 테스트는 코드 변경의 회귀를 검사하고, 평가는 확률적 출력의 품질을 통계적으로 확인한다.
   2. 추적은 운영 중의 실제 행동을 보여 주므로, 세 메커니즘을 함께 사용해 결과 신뢰도를 쌓는다.

6. 자율성은 AI 사용 여부가 아니라 노드별 위임 가능성으로 판단한다

6.1. 각 노드에 적합한 주체와 검증 조건을 따져 본다

1. 에이전트가 노드를 맡을 때의 가치를 비교한다
   1. 각 작업 노드에서 에이전트가 사람보다 더 적합하게 작업을 이끌 수 있는지 살핀다.
   2. 자동화의 목적은 AI를 포함하는 데 그치지 않고, 언젠가 사람 감독을 덜어낼 수 있는지 판단하는 데 있다.
2. 네 가지 실행 가능성 질문을 적용한다
   1. 결과를 정책에 비추어 쉽게 검사할 수 있는가?
   2. 제한된 반복 루프 안에서 실행할 수 있는가?
   3. 실행과 결과를 추적할 수 있는가?
   4. 실패나 불확실성이 생겼을 때 사람에게 되돌릴 수 있는가?
3. 질문에 긍정적으로 답할 수 있는 노드부터 자동화한다
   1. 정책 검사·경계가 있는 루프·추적·사람 fallback을 갖춘 노드는 자동화 적합성이 높다.
   2. DAG 곳곳에서 에이전트 보조를 늘리되, 완전한 위임 여부는 노드의 위험과 통제 조건에 맞춰 정한다.

6.2. 최종 정책 판단은 사람의 책임으로 남길 수 있다

1. 대출 의사결정 노드는 사람 중심으로 둘 수 있다
   1. KYC와 재무 분석 등은 병렬화하더라도 최종 의사결정은 사람이 맡는 편이 적절할 수 있다.
   2. 최종 결정 자체가 정책에 비추어 결과를 확인하는 검사이기 때문이다.
2. 정책 검증 노드는 자율화의 난도가 더 높다
   1. 자동화한 작업의 결과를 다시 정책으로 판정하는 단계는 단순 처리보다 점진적으로 신뢰를 쌓기 어렵다.
   2. 사람의 판단을 언제나 제거하기보다, 정책 경계와 검증 근거가 충분한 단계부터 위임 범위를 넓힌다.

7. 감독에서 표본 검토, 예외 처리로 신뢰를 단계적으로 키운다

7.1. 첫날에는 모든 출력을 사람이 확인한다

1. 사람과 에이전트가 함께 일하며 출력을 전수 검증한다
   1. 초기에는 사람이 에이전트 산출물을 직접 확인해 품질이 충분한지 검증한다.
   2. 전수 검토 결과를 사용해 대표 데이터셋을 다듬고 신뢰 메커니즘이 제대로 설계되었는지 확인한다.
2. 도메인 전문가가 좋은 결과의 기준을 정한다
   1. 해당 업무를 아는 주제 전문가(subject matter experts, SMEs)와 함께 품질 기준을 만든다.
   2. 전문가가 초기 출력을 검증해 데이터와 기준을 현실 업무에 맞게 조정한다.

7.2. 측정된 신뢰도가 정책 임계값에 도달하면 표본을 본다

1. 전수 확인에서 일부 출력의 검토로 전환한다
   1. 측정된 신뢰도가 정책 임계값에 도달하면 사람이 출력 전체가 아니라 일부 표본을 살핀다.
   2. 표본 검토로 사람의 부담을 줄이면서도 에이전트 품질을 계속 관찰한다.
2. 사람이 보지 않은 출력도 추적으로 평가한다
   1. 런타임 추적을 이용해 검토되지 않은 결과가 품질 기준을 계속 만족하는지 체계적으로 확인한다.
   2. 표본만으로 놓칠 수 있는 변화를 추적과 반복 평가로 보완한다.

7.3. 임계값을 넘으면 사람은 예외를 맡되 품질 개선에 계속 참여한다

1. 사람의 역할을 정상 처리에서 예외 처리로 옮긴다
   1. 추가 신뢰 임계값을 통과하면 사람은 모든 작업의 동반자가 아니라 예외 중심의 참여자가 된다.
   2. 오류·불확실성·정책 위반 가능성이 있는 경우에 사람의 판단을 요청한다.
2. 자율화 이후에도 데이터와 품질 기준은 진화한다
   1. 사람은 데이터셋을 정제하고 평가 기준을 개선하는 데 계속 참여한다.
   2. 자동화는 사람의 완전한 퇴장이 아니라, 일상적인 감독을 줄이면서 품질 책임을 유지하는 방식이다.

8. 프로세스는 바깥에서 결정론적으로, 안쪽에서 적응적으로 만든다

8.1. 통제된 흐름과 유연한 노드의 조합이 기본 레시피다

1. 바깥 DAG는 통제와 진행 순서를 보장한다
   1. 승인·검사·정책 경계 같은 필수 조건은 명시된 흐름에 고정한다.
   2. 프로세스 전체는 결정론적(deterministic)으로 운영해 누구나 통과 기준과 책임 지점을 확인할 수 있게 한다.
2. 노드 안의 에이전트는 피드백에 맞춰 적응한다
   1. 각 노드 안에서는 에이전트가 입력·피드백에 따라 작업을 수정하고 제한된 루프를 돈다.
   2. 유연성은 정책 경계 안에서 허용하고, 검사 기준을 통과한 경우에만 바깥 흐름을 진행한다.

8.2. 품질은 여러 역할이 함께 만드는 팀의 책임이다

1. AI 엔지니어는 제품 신호를 작동하는 파이프라인으로 연결한다
   1. 여러 방향에서 들어오는 제품 신호를 받아 잘 만들어진 애플리케이션으로 이어지는 파이프라인을 책임진다.
   2. 머신러닝 운영(Machine Learning Operations, MLOps)을 뒤에서 활용해 모델과 에이전트 시스템을 운영한다.
2. 품질은 특정 모델이나 한 사람에게만 맡길 수 없다
   1. 도메인 전문가가 기준을 제공하고, AI 엔지니어가 시스템과 운영을 만들며, 사람 검토와 평가가 신뢰 근거를 보탠다.
   2. 품질을 팀의 공동 작업으로 다룰 때 제품 신호와 운영 데이터가 개선 과정에 다시 반영된다.
3. 에이전트의 영향은 운영 모델 전체로 확장된다
   1. 에이전트는 사람·프로세스·기술을 가로질러 일하므로 한 노드의 속도 개선이 전체 운영 흐름에 영향을 준다.
   2. 마지막 슬라이드에는 발표에서 다룬 주제의 참고 자료가 실려 있으며, 발표는 감사 인사와 박수로 끝난다.

주요 발언 모음

“정책을 조직의 원래 제도적 의도, 곧 원래의 시스템 프롬프트라고 생각하라.”

“더 높은 품질의 입력은 더 낮은 계산 비용으로 더 나은 결과를 만든다.”

“이 루프는 검사(check)가 신뢰할 수 있는 만큼만 신뢰할 수 있다.”

“바깥은 결정론적으로 유지하고 안쪽은 적응적으로 만들어라.”

“품질은 팀 스포츠다.”

핵심 데이터 & 수치

• 경력 20년: 소프트웨어를 설계·구축·전달해 온 기간이다.
• 금융 서비스 15년: 전체 경력 중 마지막 15년을 엔터프라이즈 금융 서비스에서 보냈다.
• 영상 길이 약 17분 33초: YouTube 메타데이터의 재생 시간은 1,052초다.
• 신뢰도 임계값: 감독에서 표본 검토, 예외 중심 사람 개입으로 옮기는 기준이며, 구체적인 숫자는 제시되지 않았다.
• 통계적 평가: 대표 데이터셋을 반복 실행해 결과를 분석하며, 특정 표본 수나 합격률 수치는 제시되지 않았다.
• 사례 범위: 상업 대출, 특정 지역 거래소 토큰 상장, 규제 대상 소프트웨어 전달이 정책 기반 DAG의 예로 제시됐다.

결론 및 시사점

1. 정책을 실행 경계로 먼저 명문화한다: 조직의 원래 의도와 위험·준수 기준을 must, may, should 같은 규범적 표현으로 분명히 한다.
2. 프로세스와 노드 내부를 서로 다른 그래프로 본다: 외부 업무 흐름은 DAG로 통제하고, 각 노드의 반복·피드백은 DCG로 관리한다.
3. 자동화 후보를 노드별로 선택한다: 정책 검사, 제한된 반복, 추적성, 사람 fallback이 갖춰진 단계부터 에이전트에 맡긴다.
4. 출력 기준과 평가를 먼저 만든다: 도메인 전문가가 좋은 결과를 정의하고 대표 데이터셋·반복 평가·통계·런타임 추적으로 근거를 축적한다.
5. 측정된 신뢰에 맞춰 감독을 줄인다: 전수 검토에서 표본 검토로, 이후 예외 중심 개입으로 옮기되 사람은 데이터와 품질 기준 개선에 계속 참여한다.
6. 처리량이 늘어난 뒤의 병목도 관리한다: 운영 지표로 전체 흐름을 관찰하고, 통제를 유지하면서 후속 단계의 용량을 확장한다.
7. 바깥은 결정론적이고 안쪽은 적응적으로 유지한다: 정책과 승인 순서는 고정하되, 에이전트의 작업은 그 경계 안에서 유연하게 개선한다.