AI Agent가 PoC를 넘어 실제 업무에 적용되면서 Agent에게 어디까지 맡기고, 어디에서 통제할 것인가가 중요한 과제가 되고 있습니다. 문서 요약이나 초안 작성과 달리, Agent가 사내 시스템과 Tool을 직접 활용하기 시작하면 잘못된 판단이 실제 업무나 시스템 변화로 이어질 수 있기 때문입니다.
이에 따라 AI Agent가 정해진 범위 안에서 안전하게 판단하고 행동할 수 있도록 돕는 ‘가드레일(Guardrail)’의 중요성도 커지고 있습니다. 가드레일은 Agent의 행동 범위를 정하고, 예상하지 못한 판단이나 실행이 실제 업무에 영향을 주지 않도록 제어하는 역할을 합니다. 가드레일은 단순히 부적절한 입력이나 출력을 걸러내는 것만으로는 충분하지 않습니다. 어떤 데이터와 Tool에 접근할 수 있는지, 어디까지 자동으로 실행할 수 있는지, 어떤 작업에는 사람의 확인이 필요한지까지 함께 설계해야 합니다.
또한 실제 업무에 적용한 이후에는 처음 정한 기준이 제대로 작동하는지 계속 확인하고, 새로운 위험이나 예외 상황이 발견될 때마다 가드레일을 보완해야 합니다. AI Agent의 가드레일을 설계하고 운영할 때 특히 확인해야 할 다섯 가지를 정리했습니다.
1. 가드레일은 ‘실제 행동이 일어나는 지점’에 더 강하게 적용해야 합니다
가드레일은 보통 프롬프트 인젝션이나 개인정보, 허용하지 않은 요청을 입력 단계에서 걸러내는 기능으로 많이 알려져 있습니다. 하지만 AI Agent에서는 입력 단계의 검증만으로 충분하지 않습니다.
Agent는 업무를 처리하면서 새로운 문서를 읽고, 검색 결과와 Tool의 실행 결과를 바탕으로 다음 행동을 계속 결정합니다. 처음 받은 요청에는 문제가 없더라도 여러 단계를 거치는 과정에서 예상하지 못한 행동으로 이어질 수 있습니다.
예를 들어 고객지원 Agent가 문의 확인부터 주문 조회, 환불 처리까지 맡는다면 가장 중요한 확인 지점은 최초 요청이 아니라 실제 환불이 실행되기 직전입니다. 이 단계에서 잘못된 주문을 선택하거나 허용 범위를 넘는 금액을 처리하면 곧바로 실제 업무에 영향을 줄 수 있기 때문입니다.
실행 직전에는 최소한 다음과 같은 조건을 다시 확인해야 합니다.
작업 대상과 요청 내용이 정확히 일치하는지
현재 상태에서 실제 실행이 가능한 작업인지
금액이나 데이터 범위가 허용 기준을 넘지 않는지
되돌리기 어려운 작업이라면 별도 승인이 필요한지
이 원칙은 환불뿐 아니라 이메일 발송, 파일 삭제, DB 수정, 시스템 설정 변경에도 그대로 적용됩니다.
모든 행동에 같은 수준의 통제를 적용할 필요는 없습니다. 정보 조회와 데이터 수정은 위험도가 다르고, 외부 전송이나 삭제처럼 되돌리기 어려운 작업일수록 더 엄격한 검증이 필요합니다. 따라서 가드레일은 입력 단계에만 집중하기보다 실제 시스템이나 업무에 영향을 주는 실행 단계에서 위험도에 맞게 적용하는 것이 중요합니다. 특히 결과를 되돌리기 어렵거나 영향 범위가 큰 작업일수록 실행 직전의 검증과 승인 절차를 강화해야 합니다.
결국 중요한 것은 가드레일의 개수가 아니라 어떤 행동을 어느 시점에서 통제할 것인지 정확하게 설계하는 것입니다.
2. Agent의 ‘판단’과 실제 ‘실행 권한’은 분리해야 합니다
AI Agent의 강점은 상황을 해석하고 필요한 다음 행동을 스스로 결정할 수 있다는 데 있습니다. 장애 원인을 분석해 서비스 재시작이 필요하다고 판단하거나, 고객 요청을 처리하기 위해 특정 데이터를 수정해야 한다고 결정하는 식입니다.
다만 업무상 필요한 행동을 판단하는 것과 그 행동을 실제로 실행할 권한이 있는지는 분리해서 봐야 합니다. Agent가 다음 행동을 정하더라도 실행 여부까지 모델의 판단에 맡기기보다, 별도의 정책과 권한 체계에서 다시 확인하는 구조가 필요합니다.
실제 실행 여부는 다음과 같은 기준에 따라 판단할 수 있습니다.
누가 작업을 요청했는지
어떤 Agent가 실행하려는지
어떤 데이터와 시스템을 대상으로 하는지
조회·수정·삭제 중 어떤 작업인지
현재 부여된 권한으로 실행 가능한지
별도의 승인 절차가 필요한지
이런 구분이 필요한 이유는 권한까지 모델의 판단에 맡길 경우 안전장치 역시 모델의 해석에 의존하게 되기 때문입니다.
예를 들어 Prompt에 “중요한 파일은 삭제하지 마”라고 적어둘 수는 있습니다. 하지만 더 확실한 방법은 해당 Agent에게 삭제 권한 자체를 주지 않는 것입니다. 모델이 지시를 잘 따를 것이라고 기대하는 것과 시스템이 실행을 막는 것은 안전성에서 큰 차이가 있습니다.
판단과 권한을 분리하면 모델이나 Prompt를 변경하더라도 조직에서 정한 실행 기준은 그대로 유지할 수 있습니다. 여러 종류의 Agent와 모델을 함께 운영할수록 이런 구조가 더 중요해집니다. Agent는 무엇을 해야 할지 판단할 수 있습니다. 실제로 그 행동을 허용할지는 별도의 기준으로 결정해야 합니다.
3. Tool의 수보다 Agent가 가진 ‘권한의 범위’를 봐야 합니다
Agent에 Tool을 하나씩 연결하다 보면 자연스럽게 ‘무엇을 더 할 수 있을까’에 관심이 갑니다. CRM, 이메일, ERP, 데이터베이스, 개발 도구 등을 연결할수록 Agent가 처리할 수 있는 업무도 빠르게 늘어납니다.
하지만 운영 단계에서는 반대 질문도 필요합니다.
“이 Agent가 잘못 움직였을 때 어디까지 영향을 줄 수 있는가?”
같은 이메일 Tool을 사용하더라도 메일을 검색하는 Agent와 외부로 메일을 발송할 수 있는 Agent의 위험도는 다릅니다. 개발 환경에서도 코드를 읽고 분석하는 것과 운영 시스템에 직접 배포하는 것은 전혀 다른 권한입니다.
그래서 Agent에는 업무 수행에 필요한 범위만 열어주는 최소 권한 원칙이 중요합니다.
전체 데이터가 아니라 필요한 업무 데이터만 접근
조회와 수정 권한을 구분
삭제·외부 전송·대량 내보내기는 별도 제한
높은 권한은 필요한 시간에만 부여
Agent가 사용할 수 있는 Tool도 업무별로 제한
사용자가 가진 권한을 Agent에게 그대로 넘기는 것도 주의해야 합니다. 관리자가 Agent를 사용한다고 해서 Agent까지 모든 관리자 기능을 사용할 필요는 없습니다.
실행 기록도 마찬가지입니다. 누가 요청했고, 어떤 Agent가 어떤 권한으로 어떤 Tool을 사용했는지가 남아 있어야 합니다. 그래야 문제가 발생했을 때 단순히 ‘AI가 작업했다’는 수준에서 끝나지 않고 실제 원인과 영향을 확인할 수 있습니다.
이런 기록은 보안 사고뿐 아니라 운영 장애를 분석할 때도 유용합니다. 여러 Agent가 같은 시스템에 접근하는 환경이라면 어떤 Agent가 어떤 시점에 어떤 데이터를 변경했는지를 확인할 수 있어야 문제를 빠르게 좁힐 수 있기 때문입니다. Agent 설계에서는 무엇을 더 연결할 것인가만큼 무엇을 굳이 열어둘 필요가 없는지도 중요합니다.
4. Agent가 활용하는 정보의 ‘출처와 신뢰 수준’을 구분해야 합니다
AI Agent가 실제 업무를 맡기 시작하면 활용하는 정보의 출처도 빠르게 늘어납니다. 사내 문서와 업무 DB뿐 아니라 이메일, 업로드 파일, 웹 검색 결과, 외부 API, MCP 서버에서 가져온 정보까지 하나의 업무 흐름에 들어올 수 있습니다. 이때 주의해야 할 부분이 있습니다. Agent가 읽는 외부 자료 안에는 사실이나 업무 데이터뿐 아니라 Agent의 행동을 바꾸려는 지시가 포함될 수도 있습니다.
사용자는 “거래처 이메일에서 주문 내용을 정리해줘”라고 요청했지만, Agent가 읽은 첨부파일 안에 기존 지시를 무시하고 특정 정보를 외부로 전송하라는 내용이 숨어 있을 수 있습니다. Agent가 이를 문서 속 정보가 아니라 새로운 명령으로 받아들이면 간접 프롬프트 인젝션(Indirect Prompt Injection)으로 이어집니다.
그래서 Agent가 사용하는 정보는 출처와 성격에 따라 다르게 다뤄야 합니다.
시스템 정책과 조직이 직접 관리하는 기준 정보는 Agent 행동의 기준으로 사용
내부 문서와 업무 데이터는 접근 권한을 확인한 뒤 활용
이메일, 업로드 파일, 웹 검색 결과, 외부 MCP 데이터는 그대로 행동 지시로 사용하지 않음
외부 자료는 필요한 정보만 추출해 다음 단계로 전달
핵심은 외부 정보를 막는 데 있지 않습니다. 실제 업무에서는 외부 데이터가 반드시 필요합니다. 업무에 참고할 정보와 Agent가 따라야 할 명령을 구분하는 것이 핵심입니다.
예를 들어 이메일 전체를 다른 Agent나 Tool에 그대로 넘기기보다 주문번호, 고객명, 수량, 요청 유형처럼 실제 업무에 필요한 값만 뽑아 전달할 수 있습니다. 이렇게 하면 외부 문서에 포함된 불필요한 지시가 다음 단계까지 그대로 전달되는 위험을 줄일 수 있습니다.
업무에 따라서는 Agent에게 다음 행동을 완전히 자유롭게 맡기지 않는 방법도 있습니다. ‘조회’, ‘수정 요청’, ‘승인 요청’, ‘종료’처럼 미리 정해둔 범위 안에서만 다음 행동을 선택하도록 하는 것입니다.
이 부분은 Context 설계와도 밀접하게 연결됩니다. Agent에게 많은 정보를 제공한다고 항상 더 정확한 판단으로 이어지는 것은 아닙니다. 정보의 양뿐 아니라 어디에서 온 정보인지, 얼마나 신뢰할 수 있는지, 실제 행동에 어디까지 영향을 줄 수 있는지를 함께 설계해야 합니다.
5. 가드레일은 운영 데이터를 바탕으로 계속 개선해야 합니다
아무리 꼼꼼하게 설계해도 처음부터 모든 상황을 예상하기는 어렵습니다. 실제 업무에 Agent를 적용하면 테스트 과정에서 만나지 못했던 요청과 데이터 조합, Tool 사용 방식, 예외 상황이 계속 나타납니다.
그래서 운영 단계에서는 단순히 ‘가드레일이 몇 번 작동했는가’만 보면 안 됩니다. 위험한 행동을 제대로 막지 못하는 것도 문제지만, 정상적인 업무를 반복해서 차단하는 것도 Agent의 활용도를 떨어뜨립니다.
최종 결과만 평가하는 것도 부족합니다. 결과는 맞았지만 중간에 필요하지 않은 데이터에 접근했거나, 잘못된 Tool을 호출한 뒤 우연히 정상적인 결과를 만들었을 수도 있습니다.
운영 과정에서는 다음과 같은 부분을 함께 확인해야 합니다.
업무에 맞는 데이터와 Tool을 선택했는지
허용된 권한 안에서 행동했는지
중요한 작업 전에 필요한 검증을 거쳤는지
불필요한 반복 호출이나 실행 오류는 없었는지
정상적인 업무가 가드레일 때문에 계속 막히고 있지는 않은지
실제 운영에서 발견된 문제는 평가 항목으로 다시 활용하는 것이 좋습니다. 특정 문서에서 프롬프트 인젝션이 발생했다면 같은 유형의 공격을 다시 시험할 수 있는 평가 사례로 남기고, 가드레일을 수정한 뒤 같은 문제가 다시 발생하지 않는지 확인합니다.
'문제 발견 → 평가 항목 추가 → 가드레일 보완 → 재검증' 이런 과정이 반복돼야 가드레일도 실제 업무 환경에 맞게 정교해집니다.
Agent가 늘어나면 사용하는 모델과 Tool, 데이터, 권한도 다양해지고 가드레일 정책과 실행 기록 역시 여러 곳으로 흩어지기 쉽습니다. 이때는 개별 Agent를 따로 관리하기보다 정책과 권한, Tool 사용 내역, 실행 기록, 평가 결과를 일관된 기준으로 관리할 수 있는 운영 기반이 필요합니다. LLMOps나 AI 운영 플랫폼의 역할이 중요해지는 이유입니다.
다만 가드레일의 목적은 Agent의 행동을 최대한 제한하는 데 있지 않습니다. 업무의 영향도에 따라 자동 실행, 추가 확인, 사람의 승인 등 자율성의 범위를 다르게 적용하는 것이 더 현실적입니다. 결국 좋은 가드레일은 Agent가 스스로 처리해도 되는 영역과 다시 확인해야 하는 영역을 명확히 나누고, 실제 운영 결과에 맞춰 그 기준을 계속 조정하는 것입니다.
FAQ. AI Agent 가드레일에 대해 자주 묻는 질문
Q1. AI Agent 가드레일은 일반적인 LLM 가드레일과 무엇이 다른가요?
일반적인 LLM 가드레일이 유해한 입력과 출력을 통제하는 데 초점을 둔다면, AI Agent 가드레일은 권한, Tool 사용, 실행 조건, 승인 절차 등 실제 행동까지 통제해야 한다는 점에서 범위가 더 넓습니다.
Q2. 모든 Agent 작업에 사람의 승인이 필요한가요?
모든 작업에 승인을 요구할 필요는 없습니다. 정보 조회는 자동 처리하고, 수정·외부 전송은 추가 검증을 거치며, 삭제나 대량 변경처럼 영향이 큰 작업에만 승인을 요구하는 등 위험도에 따라 자율성 수준을 다르게 설정하는 것이 효과적입니다.
Q3. Prompt에 금지 규칙을 명확히 작성하면 충분한가요?
Prompt만으로는 충분하지 않습니다. “파일을 삭제하지 않는다”는 지시보다 삭제가 필요 없는 Agent에게 삭제 권한 자체를 부여하지 않는 방식이 더 확실합니다. 행동 지침과 실제 실행 권한은 분리해 관리해야 합니다.
Q4. MCP나 외부 Tool을 연결할 때 가장 먼저 확인해야 할 것은 무엇인가요?
Agent가 어떤 데이터와 기능까지 사용할 수 있는지를 먼저 확인해야 합니다. MCP 연결 자체를 신뢰의 기준으로 삼기보다 서버와 Tool별 접근 권한, 허용 작업, 데이터 범위를 각각 제한하는 것이 중요합니다.
Q5. AI Agent 가드레일이 제대로 작동하는지는 어떻게 평가하나요?
차단 횟수만으로는 충분하지 않습니다. 위험한 행동을 제대로 막았는지, 정상 업무를 과도하게 차단하지 않았는지와 함께 어떤 데이터와 Tool을 사용하고 어떤 과정을 거쳐 실행했는지까지 확인해야 합니다. 운영 중 발견된 문제는 평가 항목으로 추가해 재검증하는 것이 좋습니다.
Q6. Agent가 많아지면 가드레일 관리 방식도 달라져야 하나요?
Agent가 늘어나면 모델과 Tool, 데이터, 권한, 실행 기록도 함께 복잡해집니다. 이 단계에서는 정책과 권한, Tool 사용 내역, 실행 기록, 평가 결과를 일관된 기준으로 관리할 수 있는 운영 체계가 중요하며, LLMOps나 AI 운영 플랫폼의 필요성도 커집니다.
