AI Agent 입력값 검증, 자동화가 틀린 데이터로 실행되지 않게 막는 기준
AI Agent가 메일 발송, 문서 처리, 승인 요청을 실행하기 전에 입력 데이터와 업무 조건을 어떻게 검증해야 하는지 실무 체크리스트로 정리합니다.
AI Agent는 사람이 “이 파일 처리해줘”, “이 고객에게 답장해줘”, “이 데이터를 CRM에 반영해줘”라고 넘긴 일을 실제 행동으로 이어갑니다. 그래서 프롬프트를 잘 쓰는 것만큼 중요한 것이 입력값 검증입니다.
입력 데이터가 비어 있거나, 형식이 다르거나, 권한 밖 정보가 섞였는데도 자동화가 그대로 실행되면 작은 오류가 고객 응대, 결제, 보안 사고로 커질 수 있습니다.
핵심 요약
- AI Agent 입력값 검증은 “잘못된 데이터로 실행하지 않게 멈추는 장치”입니다.
- 검증 기준은 파일 형식, 필수 항목, 권한, 최신성, 중복, 실행 범위, 사람 승인 조건으로 나눠 정리하는 것이 좋습니다.
- 검증 실패를 단순 오류로 숨기지 말고, 담당자가 바로 이어받을 수 있는 예외 큐와 로그를 함께 설계해야 합니다.
- 처음부터 모든 업무에 적용하기보다 고객 발송, 비용 발생, 데이터 수정처럼 리스크가 큰 단계부터 적용하는 편이 현실적입니다.
왜 AI Agent에는 입력값 검증이 더 중요할까
일반 챗봇은 틀린 답을 해도 사람이 다시 질문하면 끝나는 경우가 많습니다. 하지만 AI Agent는 답변에서 멈추지 않고 메일을 보내거나, 티켓 상태를 바꾸거나, 문서를 업로드하는 실행형 자동화로 이어집니다.
이때 문제는 모델의 추론 능력만이 아닙니다. 애초에 들어온 데이터가 맞는 업무인지, 필요한 항목이 모두 있는지, 이 Agent가 처리해도 되는 범위인지가 먼저 확인되어야 합니다.
실무 기준은 간단합니다. “좋은 답을 만들 수 있나?”보다 먼저 “이 입력으로 실행해도 안전한가?”를 확인해야 합니다.
1. 필수 입력값을 먼저 고정한다
자동화 업무마다 반드시 필요한 값이 있습니다. 예를 들어 견적 메일 초안을 만드는 Agent라면 고객명, 요청 범위, 회신 기한, 담당자, 첨부 파일 여부가 필요할 수 있습니다.
이 항목을 프롬프트 안에서만 느슨하게 요구하면 누락을 놓치기 쉽습니다. 업무 시작 전에 필수 필드 목록을 별도로 두고, 비어 있으면 실행하지 않는 방식이 더 안전합니다.
- 고객/거래처 식별값
- 업무 유형과 처리 범위
- 첨부 파일 또는 원문 데이터 위치
- 마감일, 금액, 수량처럼 결과에 영향을 주는 숫자
- 실행 후 되돌리기 어려운 액션 여부
2. 형식 검증과 의미 검증을 분리한다
이메일 주소에 @가 있는지, 날짜가 YYYY-MM-DD인지 확인하는 것은 형식 검증입니다. 필요하지만 충분하지는 않습니다.
AI 자동화에서는 의미 검증도 필요합니다. 날짜 형식은 맞지만 이미 지난 날짜인지, 금액은 숫자지만 승인 한도를 넘는지, 첨부 파일은 PDF지만 다른 고객 문서가 섞였는지 확인해야 합니다.
- 형식 검증: 이메일, 전화번호, 날짜, 파일 확장자, JSON 스키마처럼 기계적으로 확인할 수 있는 기준
- 의미 검증: 업무 맥락상 가능한 값인지, 승인 범위 안인지, 담당 팀이 처리할 수 있는 요청인지 확인하는 기준
- 정책 검증: 개인정보, 계약 정보, 결제 정보처럼 Agent가 접근하거나 전송해도 되는지 확인하는 기준
3. 권한 밖 데이터는 “잘 처리”하지 말고 멈춘다
많은 자동화 사고는 Agent가 엉뚱한 일을 해서가 아니라, 너무 열심히 처리해서 생깁니다. 권한 밖 파일이나 다른 고객 정보가 들어왔을 때 요약을 잘 만들면 오히려 문제가 됩니다.
사내 AI 비서나 RAG 기반 Agent라면 입력값 검증 단계에서 사용자 권한, 문서 접근권한, 요청 목적을 함께 확인해야 합니다. 권한이 애매하면 답변을 만들기보다 담당자 확인으로 넘기는 것이 맞습니다.
- 요청자가 해당 문서를 볼 수 있는가
- Agent가 이 데이터 유형을 처리하도록 허용되어 있는가
- 외부 발송이나 저장소 업로드가 포함되는가
- 개인정보·계약서·가격표처럼 별도 승인 대상인가
4. 중복 실행과 재시도를 별도 기준으로 다룬다
AI Agent는 실패했을 때 재시도하도록 만들기 쉽습니다. 하지만 입력값 검증 없이 재시도하면 같은 고객에게 메일이 여러 번 가거나, 같은 주문이 두 번 처리될 수 있습니다.
실행 전에 요청 ID, 원문 파일 해시, 고객 ID, 처리 상태를 확인해 “이미 처리된 입력인지”를 확인해야 합니다. 특히 메일 발송, CRM 업데이트, 결제·환불 요청처럼 외부에 흔적이 남는 업무는 멱등성 기준이 필요합니다.
5. 검증 실패 메시지는 담당자가 이어받을 수 있게 쓴다
검증 실패를 “오류가 발생했습니다”로만 남기면 운영자는 원인을 다시 찾아야 합니다. 실패 로그에는 어떤 기준에서 막혔는지, 누가 확인해야 하는지, 재실행하려면 무엇을 고쳐야 하는지가 들어가야 합니다.
- 누락된 필드: 예) 고객 이메일 없음
- 형식 오류: 예) 납기일이 날짜 형식이 아님
- 정책 오류: 예) 개인정보 포함 문서라 자동 발송 보류
- 중복 의심: 예) 같은 요청 ID가 이미 처리됨
- 다음 조치: 담당자 확인, 데이터 수정, 승인 요청, 수동 처리
AI Agent 입력값 검증 체크리스트
- 업무별 필수 입력값 목록이 문서화되어 있다.
- 형식 검증과 의미 검증 기준이 분리되어 있다.
- 개인정보·계약·결제 정보처럼 민감 데이터 처리 기준이 있다.
- 권한 밖 문서나 다른 고객 데이터가 들어오면 자동 처리하지 않는다.
- 중복 실행을 막기 위한 요청 ID 또는 파일 해시 기준이 있다.
- 검증 실패 시 담당자가 볼 수 있는 예외 큐와 로그가 남는다.
- 사람 승인 없이 실행 가능한 범위와 반드시 승인해야 하는 범위가 구분되어 있다.
- 테스트 데이터로 정상/누락/권한오류/중복 케이스를 검증했다.
작게 시작하는 적용 순서
- 먼저 고객 발송, 외부 시스템 수정, 비용 발생 업무처럼 리스크가 큰 자동화 1개를 고릅니다.
- 그 업무가 실행되기 전에 반드시 확인해야 할 입력값 5~10개를 적습니다.
- 누락, 형식 오류, 권한 오류, 중복 입력 케이스를 테스트 데이터로 만듭니다.
- Agent가 실행하지 말아야 할 경우를 예외 큐로 보내고, 운영자가 확인할 문구를 정합니다.
- 실제 운영에서는 검증 실패 로그를 모아 규칙을 조금씩 보완합니다.
자주 묻는 질문
Q. 프롬프트에 “잘 확인하고 처리해”라고 쓰면 충분하지 않나요?
충분하지 않습니다. 프롬프트는 모델의 행동 지침이고, 입력값 검증은 실행 전 통제 장치입니다. 중요한 업무일수록 코드, 워크플로우, 승인 정책에서 별도로 막아야 합니다.
Q. 모든 자동화에 같은 검증 규칙을 적용하면 되나요?
기본 구조는 비슷하지만 업무별 필수값과 위험도는 다릅니다. 내부 문서 요약, 고객 메일 발송, CRM 수정, 결제 요청은 각각 멈춰야 할 기준이 달라야 합니다.
Q. 검증을 많이 넣으면 자동화 속도가 느려지지 않나요?
처음에는 단계가 늘어 보일 수 있습니다. 하지만 운영 중 잘못 실행된 일을 되돌리는 비용이 훨씬 큽니다. 속도가 필요한 업무도 최소한의 필수값·권한·중복 검증은 두는 편이 안전합니다.
Q. HeyRatty는 어떤 부분을 도와줄 수 있나요?
HeyRatty는 업무 흐름을 먼저 분해하고, Agent가 실행해도 되는 조건과 사람이 확인해야 하는 조건을 함께 설계합니다. 이미 쓰고 있는 Notion, Slack, CRM, 메일, 문서 저장소와 연결할 때 입력값 검증과 예외 처리까지 포함해 자동화 구조를 잡을 수 있습니다.
참고 및 이미지 출처
- OWASP Input Validation Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- 이미지 출처: Wikimedia Commons, File:Wikidata consistency interactions.svg, author/owner Evolution and evolvability, license CC BY 4.0, direct thumbnail URL used for this post.