AI Agent 출력값 검증, 잘못된 결과가 다음 시스템으로 넘어가지 않게 막는 기준
AI Agent가 만든 JSON·메일·SQL·파일 경로·도구 호출 결과를 그대로 실행하지 않고, 스키마·업무 규칙·보안·사람 승인으로 검증하는 실무 기준을 정리합니다.
AI Agent가 요청을 잘 이해했더라도 결과는 틀릴 수 있습니다. 문제는 그 결과가 CRM, 메일, 파일 저장소, 데이터베이스, 결제나 업무 API로 곧바로 넘어갈 때 커집니다.
출력값 검증은 프롬프트를 더 길게 쓰는 기술이 아닙니다. 모델 결과를 신뢰하지 않은 상태에서 형식, 업무 규칙, 보안, 권한을 통과한 데이터만 다음 단계에 넘기는 운영 경계입니다.
핵심 원칙: 모델이 만든 값은 답이 아니라 검증 대기 중인 외부 입력으로 취급합니다.
핵심 요약
- 모델 출력은 사용자 입력과 같은 불신 경계에서 시작합니다.
- JSON 파싱 성공과 스키마 일치는 1차 관문일 뿐, 실행 허가를 뜻하지 않습니다.
- 금액, 수신자, 상태 전이, 문서 권한 같은 업무 규칙은 결정론적 코드로 다시 확인합니다.
- 검증 실패는 기본적으로 실행 차단, 격리, 제한된 재시도, 사람 승인 중 하나로 분기합니다.
1. 출력값이 지나가는 경로부터 그립니다
검증 규칙은 모델 종류보다 결과가 도착할 목적지에 따라 달라집니다. 화면에 보여 줄 문장과 고객에게 발송할 메일, 데이터베이스에 쓸 값은 위험도가 같지 않습니다.
OWASP는 모델 출력이 다른 구성요소로 전달되기 전에 검증, 정제, 처리가 부족한 상태를 Improper Output Handling으로 설명합니다. 브라우저, 백엔드, 확장 도구마다 필요한 방어가 다르다는 뜻입니다.
대표 처리 경로
- 모델이 텍스트, JSON 또는 도구 호출 인자를 생성합니다.
- 파서와 스키마 검증기가 구조와 타입을 확인합니다.
- 업무 규칙과 보안 검사를 통과한 결과만 실행기 또는 화면으로 보냅니다.
이 경로에서 모델과 실행기 사이가 가장 중요한 신뢰 경계입니다. 검증기는 모델 응답을 해석하되, 모델이 요구한 권한이나 행동을 그대로 승인하면 안 됩니다.
입력 검증과 출력 검증은 역할이 다릅니다
입력 검증은 모델에 들어갈 자료와 요청 조건을 확인합니다. 출력 검증은 모델이 만든 결과가 다음 시스템의 계약과 정책을 지키는지 확인합니다. 둘 중 하나만 있어도 안전한 자동화가 되지 않습니다.
2. 1차 관문은 형식과 스키마 검증입니다
먼저 시스템이 기대하는 출력 계약을 코드로 고정합니다. 자연어 설명만 두지 말고 필드, 타입, 허용값, 길이, 누락 처리까지 기계가 검사할 수 있어야 합니다.
- 필수 필드, 데이터 타입, 중첩 구조가 계약과 일치하는지 확인합니다.
- 허용값 목록, 숫자 범위, 날짜 형식, 문자열 길이와 패턴을 제한합니다.
- 정의하지 않은 추가 필드는 기본 차단하고 필요한 필드만 명시적으로 허용합니다.
- 거절 응답, 빈 값, 잘린 응답, 파싱 오류를 정상 결과와 다른 상태로 분리합니다.
OpenAI의 Structured Outputs는 제공한 JSON Schema에 모델 응답을 맞추는 기능을 설명합니다. JSON 형식만 보장하는 모드와 달리 스키마 준수를 목표로 하므로 구조 오류를 줄이는 데 유용합니다.
다만 스키마가 맞아도 고객 번호가 실제로 존재하는지, 환불 금액이 승인 한도 안인지, 수신자가 발송 대상인지까지 보장하지는 않습니다. 구조 검증 다음에 업무 검증이 반드시 이어져야 합니다.
예시: 상담 문의를 CRM에 등록할 때
- 모델은 회사명, 연락처, 문의 유형, 요약, 다음 행동을 정해진 객체로 반환합니다.
- 파서가 JSON을 읽고 스키마 검증기가 필수값과 허용 유형을 확인합니다.
- 실패한 결과는 CRM에 쓰지 않고 실패 사유와 함께 격리 큐로 보냅니다.
- 통과한 객체만 중복 확인과 고객 동의 같은 업무 규칙 검사를 진행합니다.
3. 2차 관문은 업무 규칙과 의미 검증입니다
형식이 맞는 값 중에서도 실행하면 안 되는 값이 있습니다. 이 단계에서는 우리 조직의 정책과 현재 상태를 기준으로 결과의 의미를 확인합니다.
결정론적으로 확인할 업무 규칙
- 메일 수신자가 허용된 고객·파트너인지, 수신 동의와 제외 목록을 통과했는지 확인합니다.
- 금액, 할인율, 수량, 날짜가 승인 범위와 업무 마감 조건 안에 있는지 확인합니다.
- 주문·티켓·계약 상태가 현재 버전에서 허용된 다음 상태로만 이동하는지 확인합니다.
- RAG 답변의 인용 문서가 실제로 존재하고 요청자에게 열람 권한이 있는지 확인합니다.
- 고객 ID, 문서 ID, 담당자 ID처럼 외부 시스템의 식별자가 실제 레코드와 일치하는지 확인합니다.
형식이 맞다는 것과 실행해도 된다는 것은 다른 문제입니다.
두 번째 모델로 결과를 평가하는 방식은 보조 신호로 쓸 수 있습니다. 하지만 금액 한도, 허용 상태, 도메인 목록, 접근권한처럼 명확한 규칙은 코드와 원본 시스템 조회가 최종 판정을 맡는 편이 안전합니다.
4. 3차 관문은 보안과 사용 문맥입니다
같은 문자열도 HTML, SQL, 파일 경로, 셸 명령, 메일 본문에서 위험이 달라집니다. 출력값은 사용될 문맥에 맞춰 인코딩하고, 실행 가능한 형태로 직접 연결하지 않습니다.
- 웹 화면에 표시할 값은 HTML·Markdown 문맥에 맞게 이스케이프하고 임의 스크립트를 허용하지 않습니다.
- 데이터베이스 작업은 모델이 만든 SQL을 직접 실행하지 않고 준비된 쿼리와 허용된 파라미터만 사용합니다.
- 파일 경로, URL, 외부 도메인은 허용 목록과 기준 디렉터리 안에서만 해석합니다.
- 도구 호출은 허용된 함수와 인자만 받고, 비밀정보·개인정보·권한 상승 요청은 별도 정책으로 차단합니다.
OWASP는 모델 출력을 일반 사용자 입력처럼 취급하고, 문맥별 인코딩과 파라미터화, 로깅을 적용하라고 권고합니다. 프롬프트에서 금지한다고 적는 것만으로 실행 경계를 대체할 수 없습니다.
위험한 출력은 버리지 말고 격리합니다
검증 실패 결과는 실행 경로와 분리된 격리 저장소에 최소한으로 남깁니다. 원문 전체를 무기한 저장하기보다 실패 유형, 검증기 버전, 필요한 참조값을 기록해 재현과 개선에 활용합니다.
5. 통과, 재생성, 차단, 사람 승인을 나눕니다
모든 실패를 같은 방식으로 재시도하면 비용과 중복 실행만 늘 수 있습니다. 실패 원인과 업무 위험도에 따라 다음 행동을 고정합니다.
- 자동 통과: 낮은 위험의 읽기 전용 결과가 모든 검증을 통과한 경우
- 제한된 재생성: 누락 필드나 형식 오류처럼 다시 만들면 회복 가능한 경우
- 즉시 차단: 보안 정책, 접근권한, 금지 행동을 위반한 경우
- 사람 승인: 발송, 삭제, 결제, 권한 변경처럼 되돌리기 어렵거나 영향이 큰 경우
판정 결과도 운영 데이터로 남깁니다
성공 여부만 저장하면 왜 막혔는지 알 수 없습니다. 검증 결과는 원인 분석과 회귀 테스트에 다시 쓸 수 있는 형태로 남깁니다.
- 검증 단계, 실패 코드, 규칙 또는 스키마 버전
- 모델, 프롬프트, 도구 정의의 버전과 실행 시각
- 민감한 원문 대신 추적 가능한 참조값·해시와 최종 처리 상태
가장 작은 도입 순서
- 읽기 전용 업무 하나를 골라 실제 결과를 실행하지 않고 검증 판정만 기록합니다.
- 정상, 누락, 경계값, 금지값, 공격성 문자열 샘플로 검증기를 시험한 뒤 쓰기 작업으로 확대합니다.
출력값 검증 도입 체크리스트
- 모델 출력이 도착하는 화면, API, 데이터베이스, 파일, 메일 목적지를 모두 적었다.
- 목적지별 스키마와 버전 관리 방식을 정했다.
- 금액, 날짜, 상태 전이, 수신자, 권한 규칙을 결정론적 코드로 분리했다.
- HTML 인코딩, 준비된 쿼리, 경로·도메인 허용 목록을 적용했다.
- 검증 실패 시 기본 동작을 실행 차단으로 정했다.
- 재생성 횟수와 사람 인계 조건을 제한했다.
- 실패 코드, 검증기 버전, 최종 상태를 민감정보 없이 기록한다.
- 정상·오류·경계값·공격 샘플을 회귀 테스트에 넣었다.
여덟 항목이 모두 정리되기 전에는 외부 쓰기 작업을 바로 자동 실행하지 않는 편이 좋습니다. 먼저 검증 결과를 관찰하고, 반복적으로 통과하는 범위만 단계적으로 넓히세요.
자주 묻는 질문
Q1. Structured Outputs를 쓰면 별도 검증이 필요 없나요?
아닙니다. 스키마 준수는 구조 계약을 지키는 데 도움을 주지만, 실제 고객 존재 여부, 승인 한도, 접근권한, 현재 업무 상태 같은 외부 사실과 정책은 별도로 확인해야 합니다.
Q2. 다른 AI 모델을 검증기로 쓰면 되나요?
문장 품질이나 애매한 분류의 보조 평가에는 쓸 수 있습니다. 다만 권한, 금액, 허용값, 상태 전이처럼 명확한 규칙은 코드와 원본 시스템 조회가 최종 판정을 맡아야 합니다.
Q3. 검증 실패는 무조건 재시도해야 하나요?
형식 누락처럼 회복 가능한 오류만 제한적으로 재생성합니다. 보안 위반, 권한 부족, 금지 행동은 재시도하지 않고 차단하거나 사람에게 넘깁니다.
Q4. 사람 승인은 어디에 두는 게 좋나요?
외부 발송, 데이터 삭제, 결제, 계약 변경, 권한 부여처럼 되돌리기 어렵거나 고객 영향이 큰 행동 직전에 둡니다. 읽기 전용 결과까지 모두 승인하게 만들면 운영이 금방 병목됩니다.
HeyRatty가 도와드릴 수 있는 범위
HeyRatty는 AI Agent가 만든 결과를 바로 실행하지 않도록 스키마, 업무 규칙, 승인 분기, 실패 격리, 감사 로그를 실제 업무 흐름에 맞춰 설계합니다. 현재 자동화에서 어디가 무검증 연결인지부터 점검하고 싶다면 작은 읽기 전용 업무부터 함께 정리할 수 있습니다.
참고 및 이미지 출처
- OWASP GenAI Security Project — LLM05:2025 Improper Output Handling
- OpenAI Developers — Structured model outputs
- JSON Schema — What is JSON Schema?
- 이미지: Encik Tekateki, Quality Control of Ceramic Mugs · CC BY-SA 4.0. Wikimedia Commons 외부 원본을 사용했으며 로컬 생성 이미지는 없습니다.