에이전트를 어떻게 제어할 것인가

3편에서 남긴 질문

3편에서 실행 온톨로지(Execution Ontology)를 이야기했다. 조직의 의사결정과 실행 패턴 — 권한 구조, 프로세스 흐름, 에스컬레이션 경로 — 을 기계가 읽을 수 있는 형태로 명시화한 것이다.

실행 온톨로지가 갖춰지면 에이전트는 연쇄를 닫을 수 있다. 캠페인 바이럴이 재고 소진으로 이어질 때, 에이전트가 발주 조건을 판단하고 허용 범위에서 실행한다.

그런데 바로 여기서 질문이 생긴다.

실행 온톨로지를 어떻게 통제 가능하게 만드는가.

에이전트가 실행 흐름 안에서 움직인다는 것은, 에이전트가 잘못 움직일 때 조직에 실제 영향이 발생한다는 의미다. 발주가 잘못 생성되면 공급망이 움직인다. 고객 상태가 잘못 변경되면 관계가 끊긴다. 빠른 에이전트일수록, 실수도 빠르게 퍼진다.

거버넌스는 에이전트의 자율성을 제거하는 것이 아니다. 자율성이 올바른 방향 안에서 작동하도록 구조화하는 것이다. Rail, Checkpoint, Guardrail이 그 세 가지 구조다.

Rail — 실행 온톨로지의 경계를 코드로 굳히다

철로(Rail)는 기차가 어디로도 갈 수 있는 것처럼 보이지만, 정해진 경로 안에서만 움직이게 하는 구조다.

에이전트의 Rail은 실행 온톨로지에 정의된 경계를 사전에 코드화한 것이다. 에이전트가 실행 가능한 것과 실행할 수 없는 것의 목록. 이 경계 안에서 에이전트는 완전히 자율적이다. 경계 밖은 애초에 시도할 수 없다.

캠페인 시나리오에서 Rail의 예시:

발주 Rail:
  허용: SKU별 일일 발주 한도 내 ERP 발주 생성
  허용: 재고 임계치 도달 시 물류팀장에게 알림 발송
  금지: 발주 한도 초과 ERP 직접 수정
  금지: 공급사 계약 조건 변경
  금지: 재무 계정 직접 접근

고객 데이터 Rail:
  허용: CRM 고객 상태 조회
  허용: 마케팅 동의 고객에게 알림 발송
  금지: 고객 상태 "해지됨"으로 단독 변경
  금지: 계약 조건 수정

Rail 설계의 핵심 원칙은 **최소 권한(Least Privilege)**이다. 에이전트가 "무엇이든 할 수 있는" 상태는 위험하다. "이것만 할 수 있는" 상태가 안전하고 예측 가능하다.

Rail이 너무 좁으면 에이전트가 실질적으로 아무것도 못 한다. Rail이 없으면 에이전트가 예상치 못한 방향으로 달린다. 적절한 Rail은 실행 온톨로지를 먼저 명시화한 뒤에야 설계할 수 있다. 어디까지가 자율 실행 가능한 영역인지를 알아야, 경계를 어디에 그을지 결정할 수 있다.

[!note] Rail과 실행 온톨로지의 관계 Rail은 실행 온톨로지의 권한 구조(Authority)를 코드로 굳힌 것이다. 실행 온톨로지가 "물류팀장은 500만 원 이하 발주를 자율 승인할 수 있다"고 정의하면, Rail은 "에이전트는 500만 원 이하 발주 생성 요청을 직접 처리할 수 있다"로 번역된다.

Checkpoint — 사람이 판단해야 하는 순간을 명시하다

모든 것을 자동화할 수는 없다. 특정 순간에는 사람이 판단해야 한다. Checkpoint는 실행 온톨로지에서 인간 승인이 명시된 지점을 에이전트 워크플로우에 설계하는 것이다.

캠페인 시나리오에서 Checkpoint의 예시:

Checkpoint 1: 발주 금액 임계치
  트리거: 단일 발주 금액 > 500만 원
  행동: 에이전트 일시 중지 → CFO에게 승인 요청 → 응답 대기
  타임아웃: 4시간 이내 응답 없으면 물류팀장으로 에스컬레이션

Checkpoint 2: 신규 공급사 선택
  트리거: 기존 공급사 재고 부족 → 대안 공급사 필요
  행동: 에이전트 후보 목록 생성 → 구매팀 검토 요청
  이유: 공급사 계약은 법적 검토 필요

Checkpoint 3: 전략 전환 감지
  트리거: 캠페인 전환율이 기준 대비 50% 이상 이탈
  행동: 마케팅팀 개입 요청 → 캠페인 전략 재검토
  이유: 수치 이상이 시장 변화인지 데이터 오류인지 사람이 판단해야 함

Checkpoint 설계의 원칙은 하나다. 에이전트가 잘 할 수 있는 것은 자동화하고, 에이전트가 잘 못하는 것은 사람에게 넘긴다. 이 경계를 명확히 아는 것이 좋은 거버넌스 설계자의 역할이다.

Checkpoint가 너무 많으면 모든 결정에 사람이 개입해야 해서 속도가 나지 않는다. 에이전트를 둔 의미가 없다. Checkpoint가 너무 적으면 에이전트가 사람의 판단이 필요한 상황을 혼자 처리한다.

[!note] Checkpoint와 실행 온톨로지의 관계 Checkpoint는 실행 온톨로지의 프로세스 흐름(Process Flow)에서 인간 태스크(Human Task)로 표시된 지점이다. BPMN 2.0 기준으로: <userTask> 요소가 있는 위치가 Checkpoint다. 에이전트는 이 지점에 도달하면 자동으로 멈추고 담당자에게 태스크를 넘긴다.

Guardrail — 실행 중 이탈을 실시간으로 잡아내다

Rail이 사전 정의된 경계라면, Guardrail은 실행 중 실시간으로 작동하는 이탈 감지 장치다.

자동차 도로의 가드레일과 같다. 미리 어디서 이탈할지 알 수 없지만, 벗어나는 순간 원래 경로로 돌아오게 만드는 구조.

Rail이 "에이전트가 하지 않아야 할 것"을 막는다면, Guardrail은 "에이전트가 하고 있는 것이 예상 범위 안인지"를 지속적으로 모니터링한다.

캠페인 시나리오에서 Guardrail의 예시:

Guardrail 1: 발주 속도 이상 감지
  모니터링: 단위 시간당 발주 생성 횟수
  임계치: 시간당 10건 초과
  행동: 에이전트 일시 중지 → 담당자 알림 → 비정상 패턴 확인 요청
  이유: 루프 버그 또는 데이터 오류로 중복 발주 가능성

Guardrail 2: Temporal Hallucination 감지
  모니터링: 에이전트가 참조한 데이터의 타임스탬프
  임계치: 데이터 age > TTL 기준의 3배
  행동: 해당 추론에 불확실성 플래그 추가 → 실행 전 데이터 신선도 재확인

Guardrail 3: 실행 온톨로지 이탈 감지
  모니터링: 에이전트 행동이 실행 온톨로지의 허용 프로세스 흐름과 일치하는지
  임계치: 알 수 없는 프로세스 경로 진입 시도
  행동: 즉시 중단 → 로그 기록 → 관리자 알림

Guardrail 없이 에이전트가 이상 신호를 무시하고 계속 달리면, 작은 문제가 큰 문제가 된다. Rail과 Checkpoint가 사전 설계의 영역이라면, Guardrail은 운영 중 안전망이다.

[!note] Guardrail과 실행 온톨로지의 관계 Guardrail은 실행 온톨로지의 에스컬레이션 경로(Escalation)가 자동화된 형태다. 에이전트의 실제 행동이 실행 온톨로지의 정상 경로에서 이탈하면, 에스컬레이션 경로에 따라 자동으로 사람에게 알리거나 롤백을 트리거한다.

세 구조가 합쳐지면

Rail, Checkpoint, Guardrail은 각각 독립적이지만, 함께 작동할 때 거버넌스가 완성된다.

                    에이전트 실행
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        Rail           Checkpoint    Guardrail
    (사전 경계)      (승인 지점)    (실시간 감지)
    "이것만 가능"   "여기서 멈춰"  "이탈하면 잡아"

캠페인 바이럴 시나리오의 전체 흐름:

에이전트가 재고 소진 감지 (Dynamic)
Rail 확인: 현재 재고 수준에서 자율 발주가 Rail 안에 있는가?
Rail 안이면: 발주 생성 실행 → Guardrail 모니터링 지속
Rail 밖이면: Checkpoint 트리거 → 담당자 승인 요청
실행 중 이상 패턴 감지: Guardrail 발동 → 중단 또는 에스컬레이션

이 구조가 작동하면 에이전트는 빠르게 자율적으로 움직이면서도, 경계와 검토와 복구가 보장된다. 신뢰는 "에이전트가 항상 옳다"에서 오지 않는다. "에이전트가 이탈하면 반드시 잡힌다"에서 온다.

조직 거버넌스와의 동형성

에이전트 거버넌스 설계가 조직 거버넌스 설계와 정확히 같은 구조라는 것이 흥미롭다.

거버넌스 요소	에이전트 시스템	조직
Rail	권한 범위, 행동 제약 목록	정책, 원칙, 위임 전결 규정
Checkpoint	HITL 승인 포인트	결재 라인, 의사결정 위원회
Guardrail	실시간 이상 감지, 자동 롤백	내부 감사, KPI 모니터링, 이상 신고 채널

좋은 조직 거버넌스가 구성원이 자율적으로 일하되 방향을 잃지 않도록 하는 것처럼, 좋은 에이전트 거버넌스는 에이전트가 자율적으로 최적화하되 목적을 잃지 않도록 한다.

3편에서 실행 온톨로지를 명시화하는 것이 조직 실행 구조를 코드로 끌어올리는 작업이었다면, 4편의 거버넌스는 그 코드에 통제 가능성을 부여하는 작업이다.

거버넌스 설계의 실패 패턴

Rail이 너무 좁으면: 에이전트가 실질적으로 아무것도 못 한다. 모든 행동에 사람 승인이 필요하면 자동화 이점이 없다.

Checkpoint가 너무 많으면: 속도가 나지 않는다. 에이전트가 매 단계마다 기다린다.

Guardrail이 없으면: 이상 신호를 무시하고 계속 달린다. 작은 버그가 수십 건의 잘못된 발주로 번진다.

가장 흔한 실패 — 목적 함수 오정의: Rail과 Checkpoint와 Guardrail을 모두 설계했지만, 최적화 목표 자체가 잘못됐다. ROAS를 최적화하도록 설계했는데 실제 원하는 것이 장기 고객 관계였다면, 에이전트는 빠른 전환을 만들면서 신뢰를 갉아먹는다. 거버넌스의 시작은 "무엇을 최적화할 것인가"를 정직하게 정의하는 것이다.

다음 편으로

거버넌스가 잘 작동하려면 한 가지가 선행돼야 한다. 무슨 일이 일어나고 있는지를 알아야 한다. 보이지 않으면 제어할 수 없다.

Rail이 어떻게 작동하는지, Checkpoint가 얼마나 자주 트리거되는지, Guardrail이 어떤 패턴의 이탈을 잡아내는지. 이 정보가 없으면 거버넌스를 개선할 수 없다.

5편 측정에서는 에이전트 시스템에서 보이지 않는 것들을 어떻게 보이게 만들 것인가를 다룬다. Hidden Graph, Sensor, Observatory.

Quantum Jump for Topology 1편. 고객 확보: Agent Web & Trust 2편. 업무 효율화: Team Topology & Message Bus 3편. 빠른 개선: Dynamic, Kinetic and Semantic 4편. 거버넌스: Rail, Checkpoint, Guardrail ← 지금 여기 5편. 측정: Hidden graph, Sensor, Observatory

참고

Melvin Conway — "How Do Committees Invent?" (1968)
NIST SP 800-207, Zero Trust Architecture (2020)
OWASP ASVS — Application Security Verification Standard (에이전트 권한 설계 참조)
Camunda — BPMN Human Task Design Patterns
[[concept__execution-ontology]] — 실행 온톨로지 개념 정의
[[2026-05-24_article3-dynamic-kinetic-semantic-v4]] — 3편: 기억+실행 재배선