AI는 제안하고, 시스템은 검증해야 한다.

AI가 무엇을 할지 결정 → AI가 그것을 해도 되는지 결정 → AI가 그것을 실행

사용자 의도 (User Intent)
    ↓
AI 에이전트 (AI Agent)
...

{
  

제어 계층(control layer)은 요청이 구조적으로 유효한지, 대상이 존재하는지, 요청된 작업이 허용되는지, 그리고 추가적인 제어가 필요한지를 독립적으로 확인할 수 있습니다.

모델 자체가 이러한 결정을 내릴 필요는 없습니다.

## 테스트 통과가 권한을 의미하지 않는다

코딩 에이전트(coding agent)가 결제 서비스(payment service)를 변경한다고 상상해 봅시다.

테스트는 통과합니다.

보안 검사도 통과합니다.

빌드는 성공합니다.

아티팩트는 서명됩니다.

그러면 모델은 다음과 같이 제안합니다:

> 프로덕션에 배포(Deploy to production)한다.

이전 결과들은 해당 소프트웨어가 기술적으로 수용 가능할 수는 있음을 확립해 줄 뿐입니다.

하지만 현재 주체(actor)가 이를 배포할 권한이 있다는 것은 확립해주지 않습니다.

여기서 중요한 분리가 발생합니다:

이러한 질문들은 서로 다른 계층에 속합니다.

이러한 분리는 또한 모델의 추론 과정(reasoning process)을 변경하지 않으면서 아키텍처를 감사하고 수정하기 쉽게 만듭니다.

## 강력한 에이전트가 무제한 권한을 필요로 하지는 않는다

추론과 실행을 분리하는 것이 에이전트를 약하게 만들 필요는 없습니다. 

엔지니어링 에이전트는 여전히 광범위한 역량을 가질 수 있습니다:

-   저장소 검사(inspect repositories)
-   브랜치 생성(create branches)
-   파일 수정(modify files)
-   테스트 실행(run tests)
-   로그 검사(inspect logs)
-   배포 계획 생성(generate deployment plans)
-   인프라 변경 제안(propose infrastructure changes)

시스템은 단순히 다음과 같은 영향도가 높은 작업에 더 강력한 제어를 적용할 수 있습니다:

-   프로덕션 배포(production deployment)
-   자격 증명 순환(credential rotation)
-   데이터베이스 마이그레이션(database migration)
-   파괴적인 인프라 변경(destructive infrastructure changes)
-   금융 거래(financial transactions)

에이전트는 복잡한 작업을 추론하는 능력을 유지합니다.

단지 그 역량이 자동으로 무제한 권한이 되는 것만 아닐 뿐입니다.

## 도구 접근성뿐 아니라 행동으로 생각하라

또 다른 아키텍처적 실수는 제어 범위를 오직 도구 접근성에 국한하는 것입니다.

예를 들어:

도구 접근성은 종종 너무 거칩니다(too coarse). 

더 유용한 질문은 다음과 같습니다:

에이전트가 어떤 자원(resource)을 대상으로, 어떤 제약 조건(constraints) 하에서 어떤 행동(action)을 시도하고 있는지? 

따라서 제어 계층(control layer)은 다음과 같은 것에 대해 추론할 수 있습니다: 

이제 시스템은 동일한 기반 도구(underlying tool)를 사용하는 행동들을 구별할 수 있게 됩니다.

예를 들어, 배포 API(deployment API)는 스테이징(staging)과 프로덕션(production) 모두에 배포할 수 있는 기능을 가질 수 있습니다. 단순히 이 API에 접근할 수 있다는 사실만으로는 특정 프로덕션 배포가 허용되어야 하는지 알 수 없습니다.

의미 있는 제어 단위(meaningful unit of control)는 단순히 도구의 존재 여부가 아니라 **행동과 그 행동이 발생하는 맥락(context)**입니다.

## 에이전트가 위임(Delegating)을 시작할 때

한 에이전트가 다른 에이전트에게 작업을 위임할 때는 경계(boundary)가 더욱 중요해집니다.

다음 상황을 고려해 봅시다:

조달 에이전트(procurement agent)는 구매가 필요하다고 판단할 수 있습니다.

하지만 오케스트레이터가 해당 구매를 요청했다는 사실만으로 조달 에이전트에게 무제한의 지출 권한이 자동으로 주어지는 것은 아닙니다.

이제 시스템은 요청된 행동 이상을 이해해야 합니다:

이는 더 깊은 권한 부여 문제(authorization problem)를 야기합니다: **행위자(actors) 간에 어떻게 권한이 위임되는가**.

그 문제는 기본적인 실행 모델(basic execution model)에 억지로 끼워 넣기보다는 별도의 계층을 가질 자격이 있습니다.

## 더 나은 사고 모델(A Better Mental Model)

다음과 같은 방식 대신:

다음과 같이 생각해야 합니다:

AI는 시스템 안에 위치합니다.

AI가 시스템 자체가 되는 것은 아닙니다.

이는 아키텍처에 확률적(probabilistic) 행동을 하는 컴포넌트를 둘러싼 안정적인 제어 경계(stable control boundary)를 제공합니다.

모델은 변경될 수 있습니다.

모델은 업그레이드될 수 있습니다.

모델은 대체될 수 있습니다.

주변의 실행 제어(surrounding execution controls)는 유지될 수 있습니다.

## 원칙(The Principle)

AI 에이전트에게 더 많은 도구(tools)를 제공한다고 해서 자동으로 더 많은 권한을 부여한다는 의미는 아닙니다.

목표는 AI가 행동하는 것을 막는 것이 아닙니다.

목표는 **행동을 제안할 수 있는 능력(ability to propose an action)**과 **그것을 실행할 권한(authority to execute it)**을 분리하는 것입니다.

**AI는 제안하고. 시스템은 검증하며. 인프라가 실행합니다.**

그리고 에이전트들이 다른 에이전트를 대신하여 행동하기 시작하면, 다음 질문은 피할 수 없게 됩니다:

**실제로 그 행동을 수행할 권한을 누가 가지고 있는가?**