거버넌스가 갖춰진 AI 에이전트 시스템을 구축하는 방법

에이전트는 거짓말을 합니다. 그것이 문제입니다.

대부분의 멀티 에이전트 프레임워크(multi-agent frameworks)가 말해주지 않는 진실이 하나 있습니다: AI 에이전트는 거짓말을 합니다. 에이전트는 실패했을 때 성공했다고 보고할 것입니다. 가이드라인을 준수했다고 확인하면서도 실제로는 조용히 위반할 것입니다. 모든 것이 괜찮다고 말하겠지만, 실제로는 그렇지 않을 것입니다.

저는 가족의 물류 관리부터 콘텐츠 파이프라인, 클라이언트 프로젝트에 이르기까지 모든 것을 관리하는 40개 이상의 자율 에이전트(autonomous agents)를 운영하고 있습니다. 이들은 인간의 감독 없이 매일 수천 개의 결정을 내립니다. 이것이 작동하는 유일한 이유는 제가 컨텍스트 수준의 지침(context-level instructions)을 신뢰하는 것을 멈추고, 실행(action) 레이어에서 거버넌스(governance)를 시작했기 때문입니다.

AI 에이전트 분야에서 대부분의 "거버넌스"는 더 많은 지침, 더 많은 컨텍스트, 더 많은 토큰(tokens)을 추가하는 것을 의미합니다. 즉, 모델이 따를 수도 있고 따르지 않을 수도 있는 더 많은 _제안(suggestions)_을 하는 것입니다. 그것은 거버넌스가 아닙니다. 그것은 희망 사항일 뿐입니다. 진정한 거버넌스는 **에이전트가 취할 수 있는 행동에 대한 결정론적 제어(deterministic control)**와 더불어, 전략적이고 검증 가능한 방식으로 행동을 조종할 수 있는 능력을 의미합니다.

3계층 거버넌스 프레임워크

수개월간의 반복 작업과 수많은 화려한 실패 끝에, 저는 제안하는 것, 강제하는 것, 그리고 _거부하는 것_을 분리하는 3계층 아키텍처(three-layer architecture)로 결정했습니다.

거버넌스 패턴: 원시적인 방식은 거부하고, 거버넌스가 적용된 도구를 제공하며, 에이전트를 그 방향으로 유도하십시오

레이어 1: 지침 (조종, Steering)

지침은 제안입니다. 시행착오에 토큰을 낭비하지 않고 에이전트를 올바른 경로로 안내합니다. 볼링장의 가드레일(guardrails)이라고 생각하십시오. 공이 대략적으로 경로를 유지하게 해주지만, 스트라이크를 보장하지는 않습니다.

여기에 포함되어야 할 사항:

• 스타일 선호도 및 관례
• 모호한 상황에 대한 의사결정 프레임워크 (decision frameworks)
• 워크플로우 순서 ("B를 하기 전에 A를 수행하라")
• 커뮤니케이션 톤 및 포맷팅 규칙

한계점: 지침(Instructions)은 확률적(probabilistic)입니다. 모델이 95%의 확률로 지침을 따를 수도 있지만, 규모가 커지면 그 5%의 실패율이 빠르게 누적됩니다. 에이전트가 세션당 200번의 결정을 내린다면, 매 실행마다 지침 위반(instruction violations)이 발생하게 됩니다.

레이어 2: 확장 기능 (Extensions, 결정론적 도구)

매번 정확하게 수행되어야 하는 작업이 필요할 때, 이를 도구(tool)로 정의합니다. 확장 기능(Extensions)은 모델의 온도(temperature), 프롬프트 드리프트(prompt drift), 또는 컨텍스트 윈도우 오버플로(context window overflow)와 관계없이 일관된 결과를 생성하는 결정론적 워크플로우(deterministic workflows)로 에이전트의 자유로운 행동을 대체합니다.

패턴: 가공되지 않은 방식(raw way)을 거부함 → 관리된 방식(governed way)을 정의함 → 에이전트를 관리된 도구로 유도함.

제 시스템의 실제 사례를 들어보겠습니다. 저는 에이전트가 가공되지 않은 git commit을 실행하도록 두지 않습니다. 대신, 커밋 메시지 형식을 강제하고, 공동 저자(co-author) 트레일러를 추가하며, 브랜치 보호(branch protection)를 검증하고, 작업 내용을 로그로 남기는 dev_commit 확장 도구를 구축했습니다. 에이전트는 단 하나의 도구를 호출하지만, 다섯 가지의 거버넌스(governance) 이슈가 자동으로 처리됩니다.

여기에 포함되어야 할 것:

• 여러 단계의 조정이 필요한 워크플로우 (Workflows)
• 부수 효과(side effects)가 발생하는 작업 (파일 쓰기, API 호출, 배포)
• 감사 추적(audit trails) 또는 일관된 형식이 필요한 프로세스
• "적당히" 수준으로는 충분하지 않은 모든 것

레이어 3: 훅플로우 (Hookflows, 거부/차단)

훅플로우(Hookflows)는 면역 체계입니다. 이는 모든 도구 호출 시 — 실행되기 전(before) —에 결정론적으로 작동하며, 모든 동작을 거부, 수정 또는 게이트(gate)할 수 있습니다. 동작이 인프라 수준에서 차단되기 때문에 에이전트에게 실수를 저지를 기회조차 주지 않습니다.

여기에 포함되어야 할 것:

• 보안 경계 (출력물에 비밀 정보 포함 금지, 가공되지 않은 API 호출 금지)
• 브랜드 보호 규칙 (경쟁사를 부정적으로 언급하지 말 것)
• 데이터 거버넌스 (확장 도구 없이 보호된 파일에 쓰기 금지)
• 안전이 중요한 작업 (최신성 주의 사항 없이 아동의 위치를 언급하지 말 것)

핵심 통찰: hookflow(훅플로우)는 제로 트러스트(zero-trust) 보장을 제공하는 유일한 계층입니다. 지침(Instructions)은 무시될 수 있습니다. 도구(Tools)는 오용될 수 있습니다. 하지만 도구 호출을 거부하는 실행 전 훅(pre-execution hook)은 제안이 아니라 물리 법칙과 같습니다.

의사결정 프레임워크 (The Decision Framework)

새로운 거버넌스 요구사항을 마주할 때, 저는 다음과 같은 의사결정 트리(decision tree)를 통해 검토합니다:

각 새로운 요구사항에 적합한 거버넌스 계층을 선택하는 방법

질문	답변 → 계층
이것이 발생하기를 원치 않는 활동인가?	→ Hookflow (거부)
...

토큰 낭비 문제는 왜 세 가지 계층이 모두 함께 작동해야 하는지를 잘 보여줍니다. 만약 제가 git commit을 차단하기 위해 훅플로우(hookflow)만 사용한다면, 에이전트는 이를 시도하고, 거부 메시지를 받고, 다시 대안을 찾는 과정에서 토큰을 낭비하게 됩니다. 여기에 지침(instruction)을 추가하면 ("raw git 대신 항상 dev_commit을 사용하세요") 낭비되는 시도를 방지할 수 있습니다. 훅(hook)은 지침이 실패할 때(그리고 지침은 반드시 실패하게 되어 있습니다)를 대비한 안전망으로서 남게 됩니다.

무질서 없는 자율성: 에스컬레이션 모델 (The Escalation Model)

거버넌스는 단순히 차단하는 것만이 아닙니다. 에이전트가 언제 자유롭게 행동해야 하는지, 반대로 언제 에스컬레이션(escalation, 상위 단계로 보고)해야 하는지를 아는 것에 관한 것입니다. 저의 프레임워크는 필터 기반 접근 방식을 사용합니다:

다음의 경우 자율적으로 행동하십시오:

• 해당 동작을 제어하는 결정론적 도구(deterministic tool)가 있는 경우
• 동작이 에이전트가 선언한 도메인(domain) 내에 있는 경우
• 동작이 되돌릴 수 있거나 위험 부담이 낮은 경우

다음의 경우 에스컬레이션하십시오:

• 에이전트가 자신의 결정에 확신이 없는 경우
• 동작이 도메인 경계를 넘나드는 경우
• 동작이 되돌릴 수 없으며 위험 부담이 큰 경우 (주요 구매, 의료 결정, 데이터 삭제 등)

규모의 문제는 실재합니다. 모든 것을 검토할 수는 없습니다. 저의 해결책은 **다른 에이전트를 검토하는 검토 에이전트 (review agents)**를 두는 것이며, 검토 에이전트가 발견한 내용을 바탕으로 거버넌스 계층 (governance layer)을 지속적으로 보강하는 것입니다. 이는 밑바닥부터 끝까지 품질 보증 (QA)을 수행하는 방식이며, 인간은 진정으로 새로운 상황이 발생했을 때만 루프 (loop)에 개입합니다.

고통스럽게 얻은 교훈: 신뢰가 아닌 증명

제가 저지른 가장 비용이 많이 든 아키텍처 설계 실수는 정확성을 강제하기 위해 컨텍스트 (context)에 의존한 것이었습니다. 컨텍스트 중심의 거버넌스는 다음과 같은 이유로 취약합니다:

1. 컨텍스트 윈도우 (Context windows) 초과 — 장시간 실행되는 에이전트는 초기 지침을 잃어버립니다.
2. 모델 업데이트로 인한 동작 변화 — 특정 모델 버전에서 작동하던 것이 다음 버전에서는 작동하지 않을 수 있습니다.
3. 에이전트의 환각 (Confabulation) — 에이전트는 실제로 수행하지 않은 행동에 대해 설득력 있는 확인 내용을 생성할 수 있습니다.

해결책은 워크플로 (workflow)가 실행되었다는 _증명 (proof)_을 요구하는 것입니다. 특정 콘텐츠가 에이전트의 응답에 존재할 수 있는 유일한 방법은 그것이 알려진 결정론적 흐름 (deterministic flow)에서 나왔을 때뿐입니다. 저는 이 패턴의 개념 증명 (PoC)으로서 암호화된 승인 게이트 (cryptographic approval gates)를 구축했습니다. 이는 에이전트가 승인되었다고 _주장_하는 것이 아니라, 인간이나 검토 프로세스가 실제로 행동을 승인했음을 증명하는 디지털 서명입니다.

이는 Cloud Security Alliance의 에이전트 신뢰 프레임워크 (Agentic Trust Framework)의 원리와 동일합니다. 즉, 지침을 통해 신뢰를 가정하는 것이 아니라 증거를 통해 신뢰를 검증하는, AI 에이전트에 적용된 제로 트러스트 (zero-trust) 거버넌스입니다.

거버넌스 성숙도 모델

처음부터 거버넌스가 갖춰진 에이전트 시스템을 구축하고 있다면, 제가 권장하는 단계는 다음과 같습니다:

거버넌스 성숙도 발전 과정 — 단순한 컨텍스트 스티어링 (context steering)에서 자기 개선형 메타 거버넌스 (self-improving meta-governance)까지

레벨 1: 컨텍스트 수준의 스티어링 (Context-Level Steering)

가드레일 (guardrails)을 명확하게 표현하고 이를 효과적으로 문서화하는 능력을 숙달하세요. 명확한 지침을 작성하십시오. 모델이 무엇을 안정적으로 따르고 무엇을 따르지 않는지 학습하십시오. 빌더(builders)의 90%가 이 단계에 머물러 있으며, 단순한 단일 에이전트 (single-agent) 시스템에는 이 정도로도 충분히 잘 작동합니다.

다음 단계로 넘어갈 때: 에이전트가 지침을 일관되게 따르지 않는다는 것을 인지했을 때입니다. 이는 컨텍스트 수준의 거버넌스 (context-level governance)가 한계에 도달했다는 신호입니다.

레벨 2: 단순 결정론적 가드 (Simple Deterministic Guards)

기본적인 훅플로우 (hookflows)를 추가하십시오. 즉, 절대 발생해서는 안 되는 거부 패턴 (deny patterns)을 설정하는 것입니다 (출력 내 비밀 정보 포함, 보호된 경로에 대한 쓰기 작업 등). 이것이 여러분의 첫 번째 제로 트러스트 (zero-trust) 보증입니다.

레벨 3: 거버넌스가 적용된 도구 워크플로우 (Governed Tool Workflows)

자유 형식의 행동을 확장 도구 (extension tools)로 교체하십시오. 이것은 가장 레버리지가 높은 계층입니다. 단순히 나쁜 행동을 차단하는 것이 아니라, '올바른' 행동이 '유일한' 행동이 되도록 만드는 것입니다.

레벨 4: 적응형 거버넌스 (Adaptive Governance)

학습하는 정책 (policies)입니다. 새로운 실패 모드 (failure mode)가 나타나면 거버넌스 계층이 스스로를 업데이트합니다. 새로운 훅플로우, 새로운 도구 제약 조건, 업데이트된 지침 등이 포함됩니다. 시스템은 모든 실수를 통해 더 강력해집니다. AI 에이전트를 위한 런타임 거버넌스 (runtime governance for AI agents)에 관한 연구는 이를

• 새로운 에이전트가 거버넌스를 자동으로 상속받음 (모든 도구 호출 시 훅(hook)이 실행됨)
• 흔한 실수들이 불가능해짐 (단순히 권장되지 않는 수준이 아님)
• 규모가 커질수록 품질이 향상됨 (더 많은 검토 데이터 → 더 나은 검토 에이전트)
• 시스템의 감사(auditable)가 가능함 (턴별 평가 (per-turn evaluation)를 통해 런타임 시 동적 거버넌스 제공)

Microsoft의 Agent Governance Toolkit과 Azure의 Cloud Adoption Framework for AI agents는 기업들이 단일한 프롬프트 엔지니어링 (prompt engineering)보다는 정책 중심적이고, 감사 가능하며, 계층화된 거버넌스라는 동일한 방향으로 움직이고 있음을 입증합니다.

핵심 요약 (The Bottom Line)

만약 당신의 AI 거버넌스 전략이 "더 나은 프롬프트를 작성하는 것"이라면, 당신은 모래 위에 성을 쌓고 있는 것입니다. 프롬프트는 제안일 뿐입니다. 거버넌스는 인프라입니다.

저렴한 비용으로 방향을 잡기 위해 지침(instructions)부터 시작하세요. 지침이 실패할 때는 훅 플로우(hookflows)로 단계적으로 넘어가세요. 워크플로가 매번 올바르게 수행되어야 할 때는 확장 도구(extension tools)를 구축하세요. 그리고 에이전트의 자기 보고(self-report)를 절대, 절대로 신뢰하지 마세요. 올바른 일이 일어났다는 결정론적 증거(deterministic proof)를 요구해야 합니다.

성숙도 곡선 (maturity curve)은 여기에도 적용됩니다. 초기 단계의 거버넌스는 오버헤드(overhead)처럼 느껴집니다. 하지만 성숙한 거버넌스는 자유처럼 느껴집니다. 왜냐하면 하단의 가드레일(guardrails)에 대한 확신이 있을 때 에이전트에게 더 많은 자율성을 부여할 수 있기 때문입니다.

당신의 에이전트는 당신에게 거짓말을 할 것입니다. 그 거짓말이 불가능하도록 시스템을 구축하십시오.