【제4회】Microsoft Agent Framework로 배우는 AI 에이전트 설계 원칙: 신뢰 경계(Trust Boundary)를 설계하여
요약
본 글은 AI 에이전트가 자율적으로 행동할 때 발생할 수 있는 '의도하지 않은 행동' 리스크를 관리하기 위한 핵심 원칙인 '신뢰 경계(Trust Boundary)' 설계를 다룹니다. 잘못된 코드 예시들을 통해 입력 및 출력 검증 과정에서 신뢰 경계 설계가 얼마나 중요한지 강조합니다. Agent Framework에서는 `FunctionMiddleware`를 사용하여 도구 호출을 기록하고 검증하는 입력 측의 안전장치를 제공하며, 출력 측에서는 'Human-in-the-loop' (HITL) 방식을 통해 승인 단계를 구현할 수 있습니다. 특히 워크플로 레벨에서 제어 가능한 `ctx.request_info()`는 기존 방식의 한계를 극복하고 더 유연한 신뢰 경계 설정을 가능하게 합니다.
핵심 포인트
- AI 에이전트 시스템은 자율성만큼 '의도하지 않은 행동' 리스크 관리가 중요하며, 이를 위해 신뢰 경계(Trust Boundary) 설계가 필수적이다.
- 입력 측 안전장치로는 `FunctionMiddleware`를 활용하여 도구 호출을 기록하고 검증할 수 있다.
- 출력 측에서는 Human-in-the-loop (HITL) 방식을 통해 인간의 승인 단계를 거쳐 신뢰 경계를 설정해야 한다.
- 도구 레벨의 단순 승인(`approval_mode`)보다 워크플로 레벨에서 제어 가능한 `ctx.request_info()`가 더 유연하고 강력한 신뢰 경계 설정을 제공한다.
- 시스템 안정성을 위해 Tool 인자에 대한 타입 정의와 감사 로그(Audit Log)를 반드시 확보해야 한다.
서론
AI 에이전트의 "대단함"은 인간의 지시를 해석하여 자율적으로 행동할 수 있다는 점에 있습니다. 하지만 이는 동시에 "의도하지 않은 행동을 취할 리스크"이기도 합니다.
제4회는 신뢰 경계 (Trust Boundary) 설계를 테마로 합니다.
잘못된 코드 (1): 입력 검증 없이 도구(Tool)를 호출함
import asyncio
from agent_framework.openai import OpenAIChatClient
# 메일 전송 구현(SMTP 접속 등)은 본고의 본 주제가 아니므로 생략함
...
잘못된 코드 (2): 출력 검증·승인 없이 외부로 내보냄
import asyncio
from agent_framework.openai import OpenAIChatClient
async def main():
...
둘 다 "작동하는" 코드입니다. 하지만 실무에서 사용하기에는 너무 위험합니다.
무엇이 문제인가: 신뢰 경계 설계의 결여
Agent Framework에서의 해결책
FunctionMiddleware로 Tool 호출을 기록·검증한다
입력 측:
import asyncio
from typing import Annotated
from collections.abc import Awaitable, Callable
...
출력 측: 생성·리뷰·승인을 분리한다
출력 측의 신뢰 경계를 설계하는 방법으로, 도구(Tool) 레벨과 워크플로(Workflow) 레벨의 두 가지를 제시합니다.
approval_mode="always_require"
도구 레벨의 승인 게이트: @tool(approval_mode="always_require")를 지정하면, Agent가 도구를 호출하려는 순간 인간의 승인을 요구합니다. 데코레이터 하나로 승인 게이트를 마련할 수 있는 가장 심플한 방법입니다.
import asyncio
from agent_framework import tool
from agent_framework.openai import OpenAIChatClient
...
단, 인간에게 제시되는 정보는 도구 인자(본문 텍스트)에 한정되며, approve/deny의 2가지 선택지뿐입니다. 반려 코멘트를 받아 Agent에게 재작성을 시키는 루프를 만들 수 없으며, 승인 타이밍도 "Agent가 도구를 호출하려는 순간"으로 고정됩니다.
ctx.request_info()
워크플로 레벨의 승인: ctx.request_info()는 approval_mode의 3가지 제약을 각각 해소합니다.
approval_mode의 제약 | ctx.request_info()를 통한 해소 |
|---|---|
| 제시 정보가 도구 인자에 한정됨 | request_data에 임의의 구조체를 전달할 수 있음 |
| 승인·거절의 2가지 선택지뿐임 | response_type에 임의의 타입을 지정할 수 있음 |
| 승인 타이밍이 도구 호출 순간으로 고정됨 | 워크플로의 임의의 단계에 명시적으로 배치할 수 있음 |
import asyncio
from dataclasses import dataclass
from agent_framework import (
...
무엇이 개선되었는가
| 관점 | ❌️ 개선 전 | ⭕️ 개선 후 |
|---|---|---|
| 입력의 타입 제약 | 없음 (Agent의 판단에 맡김) | Pydantic 모델로 타입을 보장 |
| ... |
신뢰 경계 설계 원칙
AI 에이전트 시스템에서의 신뢰 경계 전체상:
[외부 입력]
→ 입력 검증 (타입·제약)
→ [Agent]
...
- 입력 측:
FunctionMiddleware로 Tool 호출을 기록·검증한다 - 인간 경계:
Human-in-the-loop를 통해 의사결정의 책임을 인간이 갖는다
요약
- 타입 정의가 없는 Tool 인자와 감사 로그(Audit Log)의 결여는 장애 발생 시 원인 추적을 불가능하게 만든다
- 생성과 승인이 분리되지 않은 것은 업무 사고의 원인이 된다
- Agent Framework의 FunctionMiddleware로 Tool 호출을 기록·검증하고,
approval_mode...
또는 워크플로 (Workflow) 레벨의 **HITL (Human-In-The-Loop)**을 통해 출력 측의 신뢰 경계 (Trust Boundary)를 설정합니다.
다음 회차에서는 "로그 및 재시도 (Retry) 로직을 각 Agent에 직접 작성하는" 문제와 AgentMiddleware에 대해 해설하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기