작은 AI 에이전트 PoC도 권한·관찰성·복구 기준부터 설계해야 합니다

AI 에이전트 PoC를 운영 후보로 보려면 “한 번 잘 답했는가”보다 무엇을 할 수 있고, 왜 실패했으며, 어디서 다시 시작할 수 있는지를 먼저 확인해야 합니다.

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

사내에서 작은 AI 에이전트 PoC를 만들 때 가장 먼저 눈에 띄는 성과는 보통 “답변이 그럴듯한가”입니다. 문서를 검색하고, 외부 API를 호출하고, 업무 도구와 연결해 결과를 만들어내면 가능성이 빠르게 보입니다.

하지만 에이전트가 외부 도구, 문서, API와 연결되는 순간 질문은 달라집니다.

• 이 에이전트는 어떤 도구까지 호출할 수 있는가?
• 토큰은 어떤 대상에게만 유효한가?
• 민감정보가 입력되거나 출력될 때 차단할 수 있는가?
• 실패했을 때 어떤 판단과 도구 호출 때문에 실패했는지 추적할 수 있는가?
• 중간에 멈추면 처음부터 다시 해야 하는가, 이어서 복구할 수 있는가?

작은 PoC라도 이 기준이 없으면 운영 리스크가 됩니다. 이번 글에서는 AI 에이전트 운영 PoC를 시작할 때 최소한으로 확인해야 할 기준을 권한, 관찰성, 평가·실패 복구 관점에서 정리합니다.

1. 권한 설계: 에이전트가 “무엇을 할 수 있는가”를 먼저 제한하기

AI 에이전트는 단순 챗봇과 다릅니다. 문서를 읽고, 도구를 호출하고, API를 실행할 수 있습니다. 그래서 PoC 단계에서도 권한 설계를 뒤로 미루면 안 됩니다.

MCP의 2025-06-18 Authorization 사양은 HTTP 기반 MCP 서버의 인증·인가 흐름을 OAuth 2.1 계열 표준에 맞춰 정의합니다. 특히 MCP 서버가 리소스 서버 역할을 하며, 액세스 토큰의 audience 검증과 적절한 토큰 사용을 요구하는 방향을 설명합니다.

출처: MCP Authorization Specification

이 관점에서 PoC 권한 설계의 핵심은 “에이전트가 할 수 있는 일을 넓게 열어두고 나중에 막는 것”이 아닙니다. 처음부터 필요한 범위만 허용해야 합니다.

예를 들어 다음 질문을 먼저 정해야 합니다.

• 에이전트가 읽을 수 있는 문서 범위는 어디까지인가?
• 쓰기·수정·삭제 권한이 필요한가, 아니면 읽기 전용으로 충분한가?
• 외부 API 호출은 어떤 엔드포인트까지 허용할 것인가?
• 토큰은 특정 서버나 리소스에 대해서만 유효하게 검증되는가?
• 사용자 승인 없이 실행하면 안 되는 도구는 무엇인가?

OpenAI Agents SDK도 에이전트 실행 중 입력, 출력, 도구 호출을 통제하기 위한 guardrails와 tripwire 개념을 제공합니다. 입력 가드레일은 에이전트에 들어오는 요청을 검사하고, 출력 가드레일은 최종 응답을 검사합니다. 도구 관련 제어를 통해 특정 조건에서 실행을 중단할 수도 있습니다.

출처: OpenAI Agents SDK Guardrails

결국 작은 PoC의 첫 번째 운영 기준은 다음 한 문장으로 요약할 수 있습니다.

“에이전트가 무엇을 할 수 있는지 설명할 수 없다면, 아직 운영 후보가 아니다.”

2. 관찰성: 최종 답변 로그만으로는 원인을 알 수 없습니다

에이전트 PoC를 테스트하다 보면 이런 상황이 자주 생깁니다.

• 답은 틀렸는데 왜 틀렸는지 모른다.
• 도구를 호출했는지 안 했는지 확인하기 어렵다.
• 검색 결과가 문제였는지, 중간 판단이 문제였는지 구분되지 않는다.
• 같은 요청을 다시 실행했을 때 다른 실패가 나온다.

이때 최종 답변만 저장하는 로그로는 부족합니다. 에이전트 운영에서는 trace, span, tool call 같은 실행 단위를 함께 봐야 합니다.

OpenAI Agents SDK는 tracing을 공식 기능으로 제공하며, trace와 span을 통해 에이전트 실행 과정을 추적할 수 있도록 합니다.

출처: OpenAI Agents SDK Tracing

Google ADK 문서도 복잡한 에이전트에서는 기본적인 입력·출력 모니터링만으로 부족하며, reasoning traces, tool calls, structured logs가 필요하다고 설명합니다.

출처: Google ADK Observability

LangSmith 역시 traces와 production-wide metrics를 중심으로 에이전트 애플리케이션의 관찰성을 제공합니다.

출처: LangSmith Observability

PoC에서 모든 것을 완벽하게 구축할 필요는 없습니다. 그래도 최소한 아래 항목은 남길 수 있어야 합니다.

• 대화 또는 실행 ID
• 호출된 도구 목록
• 도구 호출 입력과 결과
• 중간 오류
• 재시도 여부
• 최종 응답
• 실패 시 중단 지점

이 정보가 있어야 “에이전트가 틀렸다”에서 멈추지 않고, “어떤 단계에서 왜 실패했는가”까지 분석할 수 있습니다.

3. 평가와 실패 복구: 한 번의 성공보다 반복 가능한 기준이 중요합니다

AI 에이전트 PoC에서 흔한 착각은 “데모에서 한 번 잘 됐으니 성공”이라고 판단하는 것입니다. 하지만 운영 후보를 판단하려면 반복 실행에서 성공 조건과 실패 조건이 보여야 합니다.

Google ADK는 에이전트 평가에서 최종 출력만 볼 것이 아니라 trajectory와 tool use를 함께 평가해야 한다고 설명합니다. 답변 결과뿐 아니라 에이전트가 어떤 경로로 판단했고 어떤 도구를 사용했는지도 평가해야 한다는 뜻입니다.

출처: Google ADK Evaluation

이 기준은 실제 업무 PoC에서 중요합니다. 최종 답변이 맞아 보여도 잘못된 도구를 호출했거나, 불필요하게 민감한 문서에 접근했거나, 재현하기 어려운 경로로 우연히 성공했다면 운영 안정성은 낮습니다.

또 하나의 기준은 실패 복구입니다.

LangGraph 문서는 durable execution에서 checkpoint와 store를 통해 중단 후 재개, 실패 복구, human-in-the-loop, fault tolerance를 지원한다고 설명합니다.

출처: LangGraph Durable Execution

작은 PoC라도 다음 질문에 답할 수 있어야 합니다.

• 중간 단계에서 실패하면 어디서부터 다시 시작하는가?
• 같은 도구 호출을 반복해도 안전한가?
• 사람이 개입해야 하는 지점은 어디인가?
• 이전 실행 상태를 저장하고 재개할 수 있는가?
• 실패한 실행과 성공한 실행을 비교할 수 있는가?

운영 전환 여부는 “잘될 때 멋진가”보다 “실패했을 때 설명 가능하고 복구 가능한가”로 판단해야 합니다.

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

아래 기준은 작은 AI 에이전트 PoC를 운영 후보로 검토할 때 바로 사용할 수 있는 최소 체크리스트입니다.

영역	확인 질문	최소 기준
권한 범위	에이전트가 접근 가능한 문서·도구·API 범위가 정의되어 있는가?	필요한 범위만 허용
토큰 검증	토큰이 올바른 대상에게만 사용되는지 확인하는가?	audience 등 대상 검증 기준 확인
도구 가드레일	위험한 도구 호출을 조건에 따라 차단할 수 있는가?	입력·출력·도구 호출 차단 조건 정의
민감정보	민감정보 입력 또는 출력 가능성을 점검했는가?	차단 또는 확인 필요 지점 표시
실행 추적	최종 답변 외에 trace, span, tool call을 남기는가?	실행 ID와 도구 호출 이력 기록
오류 분석	실패 시 어느 단계에서 실패했는지 확인 가능한가?	오류와 중단 지점 기록
평가 기준	최종 출력뿐 아니라 trajectory와 tool use를 평가하는가?	성공·실패 시나리오 정의
재시도	실패 후 재시도 여부와 결과를 구분할 수 있는가?	재시도 로그 기록
체크포인트	중단 후 재개할 수 있는 구조가 있는가?	checkpoint 또는 상태 저장 방식 검토
사람 개입	사람이 승인해야 하는 작업이 구분되어 있는가?	human-in-the-loop 지점 정의

이 체크리스트를 통과하지 못한 PoC가 반드시 실패한다는 뜻은 아닙니다. 다만 운영 후보로 넘기기 전에는 “확인 필요” 상태로 남겨두는 것이 안전합니다.

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

작은 AI 에이전트 PoC는 빠르게 만들 수 있습니다. 하지만 운영 가능한 에이전트는 단순히 답변을 잘하는 시스템이 아닙니다.

운영 가능한 에이전트는 다음을 설명할 수 있어야 합니다.

• 어떤 권한으로 실행되는가
• 어떤 도구를 왜 호출했는가
• 실패했을 때 어디서 멈췄는가
• 다시 실행하거나 복구할 수 있는가
• 최종 답변뿐 아니라 실행 경로도 평가 가능한가

AI 에이전트 운영의 출발점은 거창한 플랫폼이 아니라 작은 기준표일 수 있습니다. 권한, 관찰성, 평가, 실패 복구 기준을 먼저 세우면 PoC의 성공 여부도 더 분명하게 판단할 수 있습니다.

생각해볼 질문: 지금 만들고 있는 에이전트 PoC는 “한 번 성공한 데모”인가요, 아니면 “실패해도 추적하고 복구할 수 있는 운영 후보”인가요?