AI 활용 초기에는 ‘환각’이 주요 리스크로 다뤄졌습니다. 실제로 존재하지 않는 정보를 사실처럼 답하거나, 근거가 부족한 내용을 그럴듯하게 제시하는 문제가 대표적이었습니다. 하지만 AI Agent가 등장하면서 위험의 성격도 달라지고 있습니다.
AI Agent는 질문에 답하는 데서 멈추지 않고, 외부 시스템에 접근해 데이터를 조회하고, 도구를 호출하며, 업무 프로세스의 다음 단계를 실행할 수 있습니다. AI가 ‘말하는 시스템’에서 ‘실행하는 시스템’으로 확장되고 있는 것입니다.
이제 AI Agent의 안전성은 모델의 답변 품질만으로 판단하기 어렵습니다. 실제 업무 시스템과 연결되는 순간, 잘못된 판단은 데이터 변경, 시스템 제어, 업무 프로세스 오류와 같은 실행 리스크로 이어질 수 있기 때문입니다.
따라서 기관과 기업은 AI Agent가 얼마나 정확하게 답하는지만이 아니라, 정해진 업무 범위 안에서 안전하게 실행되는지도 함께 관리해야 합니다. 그렇다면 AI Agent 활용 과정에서는 어떤 위험을 고려해야 할까요? 대표적인 실행 리스크를 세 가지 관점에서 살펴보겠습니다.
AI Agent 활용의 위험요소
[1] 응답과 실제 실행 결과가 일치하지 않는 경우
기존 환각이 없는 정보를 사실처럼 말하는 문제라면, AI Agent에서는 “실행했다”는 응답과 실제 시스템 결과가 어긋나는 문제가 발생할 수 있습니다. 예를 들어 Agent가 “고객 문의 티켓을 종료했습니다”라고 답했지만, 실제 ITSM 시스템에서는 상태가 그대로일 수 있습니다. 또는 “보고서를 발송했습니다”라고 했지만, 메일 발송 기록은 남아 있지 않을 수도 있습니다.
이는 단순한 답변 오류보다 더 위험합니다. 사용자가 Agent의 완료 응답을 믿고 다음 업무를 진행할 수 있기 때문입니다. 이런 상황이 반복되면 업무 누락, 중복 처리, 고객 대응 지연, 감사 실패로 이어질 수 있습니다. 따라서 AI Agent 운영에서는 Agent가 무엇을 말했는지뿐 아니라, 실제 시스템에서 어떤 변화가 있었는지 확인할 수 있어야 합니다.
[2] 허용된 실행 범위를 벗어나는 경우
AI Agent는 외부 도구와 연결될수록 더 많은 일을 할 수 있습니다. 하지만 그만큼 본래 허용된 범위나 절차를 벗어날 가능성도 커집니다.
예를 들어 다음과 같은 상황이 발생할 수 있습니다.
조회만 허용된 Agent가 데이터를 수정하는 경우
특정 프로젝트 문서만 봐야 하는 Agent가 다른 부서 저장소까지 검색하는 경우
승인 절차 없이 외부 API를 호출하는 경우
실패한 작업을 반복해서 재시도하다가 의도하지 않은 실행 경로로 이동하는 경우
문제는 이런 상황이 단순한 오류에서만 발생하지 않는다는 점입니다. Agent가 여러 도구를 조합하고, 실패한 작업을 스스로 다시 시도하며, 목표 달성을 위해 다른 방법을 찾는 과정에서도 허용 범위를 벗어날 수 있습니다. 생산성을 높이는 능력이 통제되지 않은 실행으로 이어질 수 있는 것입니다.
따라서 Agent 운영에서는 좋은 답변을 만들도록 하는 것만으로는 부족합니다. Agent가 어떤 도구를 사용할 수 있는지, 어떤 데이터에 접근할 수 있는지, 어떤 상태를 바꿀 수 있는지, 어떤 경우에는 사람의 승인이 필요한지를 미리 정해야 합니다
[3] 개별 실행은 정상처럼 보여도 전체 업무 맥락에서는 위험해지는 경우
AI Agent의 실행은 단계별로 보면 문제가 없어 보일 수 있습니다. 그러나 전체 업무 흐름이나 조직의 정책까지 함께 보면 예상하지 못한 위험으로 이어질 수 있습니다. 예를 들어 Agent가 각각의 시스템에서는 허용된 데이터만 조회했더라도, 여러 데이터를 조합하는 과정에서 외부에 공개되면 안 되는 정보가 만들어질 수 있습니다. 또는 비용을 줄이기 위해 사용률이 낮은 리소스를 회수했지만, 실제로는 장애 대응이나 특정 배치 작업에 필요한 예비 자원이었을 수도 있습니다.
이런 문제는 단일 프롬프트 필터나 개별 API 권한만으로는 잡기 어렵습니다. Agent의 행동이 전체 업무 흐름, 보안 기준, 운영 상황 안에서 어떤 의미를 갖는지 함께 살펴봐야 합니다. 결국 AI Agent의 안전성은 개별 실행이 성공했는지를 확인하는 데서 끝나지 않습니다. 그 실행이 조직의 규칙과 실제 업무 맥락 안에서 안전하게 이루어졌는지까지 확인해야 합니다.
기업과 기관이 준비해야 할 대응 방안
AI Agent를 안전하게 활용하려면 단순한 가드레일을 넘어, 실행 전 과정을 관리할 수 있는 운영 체계가 필요합니다. 가드레일은 유해 응답이나 정책 위반을 줄이는 데 중요한 역할을 하지만, 실행형 AI에서는 권한, 도구 호출, 상태 변화, 감사 가능성까지 함께 관리해야 합니다.
[1] 실행 범위와 권한을 명확히 설계해야 합니다
AI Agent를 도입할 때는 먼저 허용할 업무와 제한할 업무를 구분해야 합니다. 모든 업무를 Agent에게 맡기기보다, 위험도에 따라 적용 범위를 단계적으로 넓히는 접근이 필요합니다.
초기에는 문서 검색, 로그 요약, 정책 조회처럼 데이터를 읽고 정리하는 조회형 업무나, 장애 원인 후보 제시, 대응 방안 추천처럼 판단을 보조하는 추천형 업무부터 적용하는 것이 적절합니다. 이후 티켓 생성, 보고서 초안 작성, 알림 문안 생성처럼 사람이 확인한 뒤 실행하는 보조 실행 업무로 확장할 수 있습니다.
반면 데이터 삭제, 시스템 배포, 권한 변경, 외부 전송, 비용 발생, 운영 시스템 설정 변경처럼 되돌리기 어렵거나 조직에 직접 영향을 줄 수 있는 업무는 별도의 통제가 필요합니다. 이러한 업무는 자동화 대상에 포함하더라도 승인 절차와 예외 기준을 먼저 마련해야 합니다.
권한 설계도 함께 이루어져야 합니다. Agent에게 업무 목표만 주는 것이 아니라, 실행 가능한 범위까지 함께 정의해야 합니다. 특히 다음 기준은 초기 설계 단계에서 반드시 확인해야 합니다.
Agent가 어떤 데이터에 접근할 수 있는가
어떤 API나 시스템을 호출할 수 있는가
조회만 가능한가, 수정·삭제·전송까지 가능한가
어떤 실행에는 사람의 승인이 필요한가
실패 시 어디까지 재시도하거나 복구할 수 있는가
안전한 Agent는 자유롭게 실행하는 Agent가 아니라, 설계된 권한과 제약 안에서 실행하는 Agent입니다.
[2] 실행 전후의 상태를 검증하고 로그를 남겨야 합니다
Agent가 “완료했습니다”라고 응답했다고 해서 실제 업무가 완료된 것은 아닙니다. 실행 전후의 상태를 비교해 실제 시스템에서 어떤 변화가 있었는지 확인할 수 있어야 합니다.
예를 들어 티켓을 종료하는 Agent라면 다음 항목을 확인해야 합니다.
실행 전 티켓 상태
Agent가 호출한 도구와 호출 결과
실제 상태 변경 여부
변경된 상태가 허용된 업무 흐름에 맞는지 여부
Agent의 응답과 시스템 상태의 일치 여부
이 과정이 있어야 완료되지 않은 일을 완료했다고 보고하는 실행 환각을 발견할 수 있습니다.
이를 위해 Agent 운영 로그는 단순 채팅 이력보다 넓게 관리되어야 합니다. 사용자 요청, 참조 데이터, 프롬프트와 응답, 도구 호출 이력, 권한 사용 이력, 상태 변경 이력, 승인 및 반려 이력, 실패와 재시도 이력이 함께 남아야 합니다. Agent 운영에서 중요한 질문은 “왜 그런 답변을 했는가”에서 “왜 그런 실행을 했는가”로 이동합니다. 이를 설명할 수 있어야 기업 업무에 Agent를 안정적으로 확장할 수 있습니다.
[3] 업무 상태와 실행 규칙을 명확히 설계해야 합니다
안전한 AI Agent 운영은 프롬프트에 “조심해서 실행하라”고 적는 것으로 해결되지 않습니다. Agent가 실행되는 업무 세계 자체가 설계되어 있어야 합니다. 도메인 모델링은 특정 업무에서 가능한 상태, 역할, 권한, 정책, 허용된 상태 전이, 예외 조건, 승인 흐름, 금지된 행동을 명시적으로 정의하는 과정입니다.
예를 들어 장애 대응 Agent라면 단순히 “장애를 해결하라”가 아니라, 장애 접수, 영향도 분석, 대응 방안 추천, 승인 대기, 조치 실행, 결과 검증, 보고 및 종료와 같은 업무 상태가 정의되어야 합니다. 그리고 각 상태마다 허용되는 행동과 금지되는 행동이 구분되어야 합니다.
이때 핵심은 업무 흐름을 Agent의 추론에만 맡기지 않는 것입니다. 어떤 상태에서 어떤 데이터를 조회할 수 있는지, 어떤 조건에서 조치를 추천할 수 있는지, 어떤 단계에서 사람 승인이 필요한지, 어떤 상태 전이는 금지되는지를 사전에 정의해야 합니다. 이렇게 해야 Agent는 매번 확률적 추론에만 의존하지 않고, 설계된 업무 좌표 안에서 판단하고 실행할 수 있습니다.
[4] 사람이 확인해야 할 지점과 예외 상황을 정해야 합니다
AI Agent의 목표는 모든 업무에서 사람을 제거하는 것이 아닙니다. 중요한 지점에서 사람이 더 정확하게 판단할 수 있도록 실행 흐름을 정리하는 것이 현실적인 접근입니다. 특히 외부 고객이나 파트너에게 정보가 전달되는 경우, 개인정보·기밀정보·계약정보가 포함되는 경우, 시스템 설정이나 권한·배포·리소스 상태가 변경되는 경우, 비용이 발생하거나 서비스 안정성에 영향을 줄 수 있는 경우에는 사람의 승인이 필요합니다.
또한 실패, 재시도, 중단, 롤백 기준도 함께 마련해야 합니다. Agent가 실패한 실행을 반복하거나, 허용되지 않은 경로로 우회하거나, 복구 권한을 넘어서는 조치를 수행하지 않도록 예외 처리 범위를 정해야 합니다. 따라서 휴먼 인 더 루프는 단순한 안전장치가 아니라, Agent가 처리할 수 있는 업무와 사람이 판단해야 하는 업무를 나누는 운영 설계로 봐야 합니다.
앞서 살펴본 것처럼 AI Agent를 안전하게 활용하려면 실행 범위, 권한, 상태 검증, 로그, 업무 규칙, 사람 승인과 예외 처리 기준이 함께 마련되어야 합니다. 하지만 이러한 요소를 개별 시스템이나 수작업 중심으로 관리하기는 쉽지 않습니다. AI Agent가 실제 업무 환경에 적용될수록 데이터, 모델, 프롬프트, 도구, 워크플로우, 모니터링은 하나의 운영 흐름 안에서 연결되어야 합니다.
이때 AI 통합 플랫폼은 안전한 Agent 운영 체계를 마련하는 기반이 될 수 있습니다.
예를 들어 에이프리카의 치타(Cheetah)는 AI 모델과 LLM 서비스 운영을 위한 플랫폼으로, 데이터셋 관리, 벡터 스토어, 프롬프트 관리, 모델 평가, ML·LLM 파이프라인 자동화, 모델 배포, 모니터링 등을 지원합니다. 이를 통해 기업과 기관은 AI 서비스가 어떤 데이터와 연결되고, 어떤 모델과 프롬프트를 거쳐 동작하며, 운영 과정에서 어떤 변화가 발생하는지 보다 체계적으로 관리할 수 있습니다.
Serengeti AI Agent Studio는 실제 업무에 적용되는 AI Agent를 구성하고 운영하기 위한 기반으로 활용될 수 있습니다. 업무 흐름에 맞는 Agent를 설계하고, 필요한 도구와 워크플로우를 연결하며, 사람의 검토가 필요한 지점을 포함한 실행 구조를 마련하도록 지원합니다.
이러한 플랫폼을 활용하면 AI 개발과 운영, Agent 기반 업무 자동화를 분리된 활동이 아니라 하나의 체계로 관리할 수 있습니다. 또한 AI Agent가 어떤 데이터에 접근하고, 어떤 도구를 호출하며, 어떤 업무 흐름 안에서 실행되는지 추적할 수 있어 운영 안정성과 감사 가능성을 높이는 데 도움이 됩니다.
AI Agent의 안전성은 성능을 제한하는 요소가 아닙니다. 오히려 안전성이 확보되지 않은 Agent는 기업 환경에서 지속적으로 활용되기 어렵습니다. 이제 기업과 기관은 AI Agent를 단순한 자동화 도구가 아니라, 실제 업무 흐름 안에서 관리하고 검증해야 할 실행 주체로 바라봐야 합니다.
AI Agent 안전한 활용 관련 FAQ
Q1. AI Agent의 안전성은 기존 생성형 AI의 안전성과 무엇이 다른가요?
기존 생성형 AI는 잘못된 답변이나 환각이 주요 위험이었다면, AI Agent는 실제 업무를 실행한다는 점에서 위험의 범위가 더 넓습니다. 데이터 조회, API 호출, 시스템 변경처럼 실제 상태를 바꾸는 작업이 포함되기 때문에 답변의 정확성뿐 아니라 실행 과정과 결과까지 함께 관리해야 합니다.
2. AI Agent 운영에서 AgentOps는 왜 필요한가요?
AI Agent는 모델만 안정적으로 운영한다고 충분하지 않습니다. 어떤 데이터를 참고했는지, 어떤 도구를 호출했는지, 어떤 작업을 실행했는지, 결과가 실제 시스템에 정상 반영됐는지까지 추적해야 합니다. AgentOps는 이러한 실행 전 과정을 관리하고 모니터링하기 위한 운영 체계입니다.
3. AI Agent는 어떤 업무부터 도입하는 것이 좋나요?
초기에는 문서 검색, 로그 분석, 보고서 초안 작성, 장애 원인 추천처럼 위험도가 낮고 결과를 검증하기 쉬운 업무부터 적용하는 것이 좋습니다. 이후 운영 경험과 통제 체계를 충분히 확보한 뒤 권한 변경, 배포, 외부 전송 등 실행 위험이 큰 업무로 확대하는 것이 바람직합니다.
4. 휴먼 인 더 루프는 어떤 업무에 적용해야 하나요?
모든 작업에 사람의 승인을 요구할 필요는 없습니다. 다만 데이터 삭제, 권한 변경, 외부 전송, 비용 발생, 고객 영향, 서비스 중단 가능성이 있는 작업은 사람이 최종 확인하도록 설계하는 것이 안전합니다. 핵심은 업무 위험도에 따라 승인 기준을 다르게 적용하는 것입니다.
5. AI Agent 운영에서 실행 로그는 어디까지 남겨야 하나요?
단순한 채팅 기록만으로는 부족합니다. 사용자 요청, 참조 데이터, 프롬프트와 응답, 도구 호출, 권한 사용, 상태 변경, 승인·반려, 실패·재시도 이력까지 함께 기록해야 합니다. 그래야 장애 원인 분석, 보안 점검, 감사 대응, 운영 개선이 가능합니다.