AI 에이전트 PoC, 데모보다 먼저 정해야 할 운영 기준

작은 PoC라도 권한, 관찰성, 평가, 실패 복구 기준이 없으면 “작동한 데모”에서 “운영 가능한 후보”로 넘어가기 어렵습니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI 에이전트 PoC를 시작하면 보통 모델 성능부터 보게 됩니다.

“얼마나 똑똑한가”, “도구를 얼마나 잘 쓰는가”, “업무를 어디까지 자동화할 수 있는가”가 자연스럽게 관심사가 됩니다.

그런데 운영 관점에서 먼저 물어야 할 질문은 조금 다릅니다.

• 이 에이전트는 어떤 시스템에 접근할 수 있는가?
• 어떤 작업은 자동 실행해도 되고, 어떤 작업은 사람 승인이 필요한가?
• 실패했을 때 원인을 추적할 수 있는가?
• 위험한 입력이나 출력, 도구 실행 실패를 어떻게 막거나 복구할 것인가?

AI 에이전트 PoC의 목적이 단순 시연이 아니라 운영 가능성 검토라면, 기준은 “잘 대답했는가”에서 끝나지 않습니다.

작은 PoC 단계부터 권한, 로그, 평가, 복구 흐름을 최소 단위로 붙여야 합니다.

1. 첫 기준은 모델 성능이 아니라 권한 경계입니다

AI 에이전트는 단순 챗봇과 다릅니다.

외부 도구를 호출하고, MCP 서버에 접근하고, 사내 시스템과 연결될 수 있습니다. 이때 가장 먼저 정해야 할 것은 “무엇을 할 수 있는가”입니다.

MCP 2025-06-18 Authorization 사양은 HTTP 기반 MCP에서 OAuth 2.1 기반 권한 흐름을 정의합니다.

MCP를 통해 외부 도구나 시스템에 접근하는 에이전트라면, 권한 부여 흐름을 PoC 단계부터 고려해야 한다는 뜻입니다.

출처: MCP Authorization Specification

권한 설계에서 봐야 할 질문은 세 가지입니다.

첫째, 무엇을 자동 실행해도 되는가.

예를 들어 조회성 작업과 변경성 작업은 위험도가 다릅니다. PoC에서도 자동 실행 가능한 작업과 승인 후 실행해야 하는 작업을 나눠야 합니다.

둘째, 무엇은 반드시 사람 승인이 필요한가.

Claude Code Hooks 문서는 PreToolUse, PostToolUse, PermissionRequest 같은 이벤트를 통해 도구 실행 전후에 개입할 수 있는 지점을 제공합니다.

출처: Claude Code Hooks

셋째, 자격증명은 어디서 읽고 어떻게 제한할 것인가.

에이전트가 접근하는 토큰, 키, 내부 시스템 권한은 PoC라고 해서 느슨하게 다룰 수 있는 영역이 아닙니다. 오히려 PoC 단계에서 권한 경계를 작게 잡아야 이후 확장할 때 위험을 줄일 수 있습니다.

정리하면, 에이전트 운영의 출발점은 “이 모델이 얼마나 잘하나”가 아니라 “이 에이전트에게 어디까지 맡길 수 있나”입니다.

2. 보이지 않는 에이전트는 운영할 수 없습니다

PoC에서 자주 놓치는 두 번째 기준은 관찰성입니다.

한 번 성공한 데모만으로는 운영 가능성을 판단하기 어렵습니다. 중요한 것은 실패했을 때 왜 실패했는지 다시 따라갈 수 있느냐입니다.

Claude Code Monitoring 문서는 OpenTelemetry를 통해 metrics, logs/events, 선택적 distributed traces를 내보내 사용량, 비용, 도구 활동을 추적할 수 있다고 설명합니다.

출처: Claude Code Monitoring Usage

또한 OpenTelemetry GenAI semantic conventions는 LLM, agent, tool execution, evaluation, MCP 관련 관측 표준을 별도 저장소에서 다룹니다.

출처: OpenTelemetry GenAI Semantic Conventions

출처: OpenTelemetry GenAI README

AI 에이전트 PoC에서 최소한 남겨야 할 관찰 항목은 다음과 같습니다.

• 사용자 입력
• 모델 호출
• 도구 호출
• 비용
• 에러
• 승인 또는 거부 이벤트

이 항목들이 남지 않으면 “왜 이상한 결과가 나왔는지”, “어떤 도구 호출에서 실패했는지”, “비용이 어디서 발생했는지”를 설명하기 어렵습니다.

PoC의 합격 기준은 멋진 성공 화면이 아닙니다.

실패했을 때 다시 추적할 수 있는 로그와 트레이스가 있는지 봐야 합니다.

3. Guardrail, Eval, 실패 복구 루프까지 작게 붙여야 합니다

운영 가능한 AI 에이전트는 실패하지 않는 시스템이 아닙니다.

실패했을 때 멈추고, 감지하고, 복구하거나 사람에게 넘길 수 있는 시스템입니다.

OpenAI Agents SDK 문서에 따르면 tracing은 기본 활성화되어 있으며, guardrails는 input, output, tool guardrails와 tripwire 개념을 제공합니다.

출처: OpenAI Agents SDK Tracing

출처: OpenAI Agents SDK Guardrails

여기서 중요한 점은 평가 기준을 단순 정답률 하나로 보지 않는 것입니다.

AI 에이전트 PoC의 평가에는 다음 요소가 함께 들어가야 합니다.

• 금지 입력을 차단할 수 있는가
• 위험 출력이나 부적절한 출력을 탐지할 수 있는가
• 도구 실행 실패 시 중단, 재시도, 사람 개입 흐름이 있는가
• 실패 원인을 추적할 수 있는가

OpenAI Evals 문서는 LLM 애플리케이션 신뢰성 확보를 위해 기대 기준 대비 출력을 평가하는 절차를 설명합니다.

출처: OpenAI Evals Guide

다만 기존 Evals 플랫폼은 2026-10-31 read-only, 2026-11-30 종료 예정이라고 공지되어 있어, 플랫폼 전환 이후 권장 대체 워크플로는 확인필요입니다.

따라서 특정 플랫폼 하나에 고정하기보다는 “기대 기준 대비 출력을 평가한다”는 구조 자체를 PoC 초기에 작게 붙이는 편이 안전합니다.

바로 적용하는 체크리스트 또는 비교 기준

AI 에이전트 PoC를 시작하거나 검토할 때는 아래 기준으로 점검해볼 수 있습니다.

권한

• 에이전트가 접근할 수 있는 도구와 시스템이 목록화되어 있는가?
• 자동 실행 가능한 작업과 사람 승인이 필요한 작업이 구분되어 있는가?
• 도구 실행 전 개입 지점이 있는가?
• 자격증명을 어디서 읽는지, 어떤 범위로 제한하는지 정해져 있는가?

관찰성

• 사용자 입력이 기록되는가?
• 모델 호출 기록을 확인할 수 있는가?
• 도구 호출 성공, 실패 기록이 남는가?
• 비용을 추적할 수 있는가?
• 에러와 승인/거부 이벤트가 남는가?
• 실패 상황을 재현할 수 있는 로그나 트레이스가 있는가?

평가와 가드레일

• 금지 입력을 차단하는 기준이 있는가?
• 위험 출력이나 부적절한 출력을 탐지하는 기준이 있는가?
• 도구 실행 실패 시 중단, 재시도, 사람 개입 흐름이 있는가?
• 기대 결과와 실제 출력을 비교하는 평가 절차가 있는가?
• 사용 중인 평가 플랫폼이나 워크플로의 지속 가능성이 확인되어 있는가?

마무리 + 생각해볼 질문 1개

AI 에이전트 PoC는 “한 번 잘 되는 장면”을 만드는 일이 아닙니다.

운영 가능한 후보인지 확인하는 과정입니다.

그래서 작은 PoC라도 권한, 관찰성, 평가, 실패 복구 기준을 먼저 세워야 합니다.

무엇을 자동화할지보다 먼저, 어디까지 맡길 수 있고 어떻게 감시하며 실패 시 어떻게 멈출지를 정해야 합니다.

생각해볼 질문은 이것입니다.

지금 만들고 있는 AI 에이전트가 내일 실패한다면, 우리는 그 이유를 설명하고 안전하게 멈출 수 있을까요?