챗봇 다음에 오는 것
지금까지의 AI 활용은 대체로 "물어보면 답해 주는 도구"에 가까웠습니다. 이메일 초안을 써 달라고 하면 써 주고, 긴 문서를 요약해 달라고 하면 요약해 주고, 아이디어를 달라고 하면 여러 안을 제시했습니다. 이 정도만으로도 개인 생산성, 마케팅, 고객 서비스, 개발, 재무, HR 업무는 크게 달라졌습니다.
그런데 다음 단계는 조금 다릅니다. 앞으로의 AI는 단순히 대답하는 데서 멈추지 않고, 업무의 일부를 실제로 수행합니다. 고객 문의를 읽고, 고객 등급을 확인하고, 환불 정책을 찾아보고, 필요한 경우 티켓을 만들고, 담당자에게 넘기고, 처리 결과를 기록합니다. 개발팀에서는 장애 알림을 읽고, 로그를 조회하고, 원인을 추정한 뒤, 관련 이슈를 만들고, 담당 엔지니어에게 필요한 정보를 정리해 줍니다.
이 변화의 핵심은 AI가 "문장 생성기"에서 "업무 수행 단위"로 바뀐다는 데 있습니다. 이제 AI를 잘 쓴다는 말은 좋은 프롬프트를 쓰는 것만 뜻하지 않습니다. 어떤 데이터를 연결할지, 어떤 도구를 허용할지, 어디까지 자동 실행하게 할지, 언제 사람에게 승인을 받을지, 실패하면 어떻게 멈출지를 함께 설계하는 일이 됩니다.
이 장은 그 마지막 지도를 그리는 장입니다. 단순 챗봇을 넘어 여러 도구를 사용하는 AI 에이전트와, 텍스트·이미지·음성·영상·문서를 함께 이해하는 멀티모달 AI를 어떻게 안전하게 도입할지 살펴보겠습니다.
AI 어시스턴트와 AI 에이전트는 다르다
먼저 용어를 분명히 해야 합니다. 많은 조직이 AI 어시스턴트와 AI 에이전트를 같은 말처럼 사용하지만, 실제 도입에서는 둘을 구분해야 합니다.
AI 어시스턴트는 사용자의 요청에 반응합니다. "이 회의록을 요약해 줘", "고객에게 보낼 답장을 써 줘", "이 표에서 핵심 인사이트를 찾아줘"처럼 사람이 일을 정의하면 AI가 답변이나 초안을 제공합니다. 어시스턴트는 매우 유용하지만, 기본적으로 사용자가 다음 행동을 결정합니다.
AI 에이전트는 한 걸음 더 나아갑니다. 목표를 받고, 목표를 달성하기 위해 필요한 절차를 나누고, 적절한 도구나 데이터베이스, API를 호출하고, 실행 결과를 확인한 뒤, 다음 행동을 결정합니다. Microsoft의 AI 에이전트 도입 가이드에서도 에이전트를 생성형 AI 모델, 지시문, 검색, 액션, 메모리 같은 구성 요소를 바탕으로 입력을 해석하고 적절한 행동을 선택하는 소프트웨어로 설명합니다.1
예를 들어 "이번 달 미수금 위험 고객을 정리해 줘"라는 요청을 생각해 봅시다. 어시스턴트는 미수금 위험 고객을 판단하는 기준이나 보고서 양식을 제안할 수 있습니다. 반면 에이전트는 회계 시스템에서 미수금 데이터를 조회하고, CRM에서 고객 이력을 확인하고, 최근 커뮤니케이션 기록을 요약하고, 위험 등급을 매긴 뒤, 담당 영업사원에게 보낼 안내 초안까지 만들 수 있습니다.
차이는 명확합니다. 어시스턴트는 답을 줍니다. 에이전트는 일을 진행합니다.
실무에서는 다음처럼 구분하면 쉽습니다.
AI 어시스턴트: 질문 답변, 요약, 초안 작성, 아이디어 제안처럼 사람의 판단을 돕는다.
액션형 에이전트: 특정 조건에서 티켓 생성, 상태 업데이트, 이메일 초안 작성, 데이터 입력처럼 제한된 행동을 수행한다.
자동화형 에이전트: 여러 단계의 업무를 계획하고 실행하며, 예외 상황만 사람에게 넘긴다.
여기서 중요한 점은 "에이전트가 더 고급이니 무조건 에이전트로 가야 한다"가 아닙니다. 모든 업무에 에이전트가 필요한 것은 아닙니다. 회의록 요약, 문서 초안, 자료 조사처럼 실행 권한이 필요 없는 일은 어시스턴트만으로 충분합니다. 반대로 조회, 입력, 발송, 승인 요청, 시스템 변경처럼 실제 업무 시스템에 영향을 주는 순간부터는 에이전트 설계가 필요합니다.
에이전트는 '똑똑한 직원'이 아니라 '권한을 가진 시스템'이다
에이전트를 도입할 때 가장 흔한 착각은 AI를 사람처럼만 생각하는 것입니다. "우리 팀에 똑똑한 인턴이 한 명 생겼다"는 표현은 직관적이지만, 보안과 운영 측면에서는 위험합니다. 사람 인턴은 회사 시스템에 접속하려면 계정을 받아야 하고, 권한이 제한되며, 중요한 일을 하기 전에는 상사에게 물어봅니다. 에이전트도 똑같이 다뤄야 합니다.
에이전트는 말을 잘하는 프로그램이 아니라 권한을 가진 시스템입니다. 고객 정보를 읽을 수 있고, 이메일을 보낼 수 있고, 데이터베이스를 수정할 수 있고, 결제나 환불 같은 민감한 작업을 실행할 수도 있습니다. 그렇기 때문에 "무엇을 할 수 있는가"보다 "무엇을 못 하게 막을 것인가"를 먼저 정해야 합니다.
에이전트 설계의 출발점은 세 가지 질문입니다.
이 에이전트의 목표는 무엇인가?
이 목표를 위해 꼭 필요한 데이터와 도구는 무엇인가?
잘못 실행되었을 때 피해가 어디까지 번질 수 있는가?
예를 들어 고객 응대 에이전트라면 고객 문의를 읽고, 주문 상태를 조회하고, 반품 정책을 확인하고, 답변 초안을 작성하는 권한은 필요할 수 있습니다. 하지만 모든 고객의 결제 정보를 내려받거나, 임의로 대량 환불을 실행하거나, 내부 관리자 계정을 변경하는 권한은 필요하지 않습니다.
이 단순한 구분이 실제로는 매우 중요합니다. OWASP의 AI Agent Security Cheat Sheet는 에이전트 보안의 핵심으로 도구 권한 최소화, 민감 작업에 대한 명시적 승인, 메모리와 컨텍스트 보호, 출력 검증, 감사 가능한 로그를 강조합니다.2 결국 좋은 에이전트는 "많이 할 수 있는 AI"가 아니라 "해야 할 일을 제한된 권한 안에서 안정적으로 하는 AI"입니다.
작은 업무 흐름에서 시작하라
AI 에이전트 도입은 전사 혁신 슬로건으로 시작하면 실패하기 쉽습니다. "전 부서에 AI 에이전트를 도입하자"는 말은 멋지지만, 너무 넓고 모호합니다. 처음부터 고객, 재무, 법무, 보안, 인사, 영업 시스템을 모두 연결하려 하면 기술보다 조직 조율에서 지칩니다.
첫 시작은 작아야 합니다. 단, 너무 사소해서 가치가 안 보이면 안 됩니다. 좋은 출발점은 반복적이고, 규칙이 어느 정도 있으며, 데이터가 있고, 성과를 숫자로 확인할 수 있는 업무입니다.
대표적인 후보는 다음과 같습니다.
고객 문의 1차 분류와 답변 초안 작성
IT 지원 티켓의 우선순위 분류와 담당자 배정
영업 리드 점수화와 후속 연락 추천
재고 확인과 품절 위험 알림
주간 보고서 초안 작성과 지표 이상 탐지
채용 후보자 서류 요약과 면접 질문 초안 작성
이런 업무는 실패하더라도 피해 범위를 제한하기 쉽고, 도입 효과를 측정하기도 좋습니다. 예를 들어 IT 티켓 분류 에이전트라면 평균 분류 시간, 재분류율, 담당자 만족도, 미처리 티켓 감소율을 볼 수 있습니다. 고객 문의 에이전트라면 첫 응답 시간, 상담원 수정률, 고객 만족도, 에스컬레이션 비율을 추적할 수 있습니다.
처음부터 "완전 자동화"를 목표로 하지 않아도 됩니다. 오히려 좋은 파일럿은 사람의 검토를 포함합니다. AI가 분류하고, 사람이 확인하고, 잘못된 사례를 모아 지침을 개선합니다. 이 과정을 거치면 조직은 AI가 어디서 강하고 어디서 약한지 몸으로 이해합니다.
30일, 60일, 90일 로드맵
에이전트 도입은 기간을 짧게 끊어야 합니다. 너무 긴 프로젝트는 중간에 목표가 흐려지고, 너무 짧은 실험은 장난감 데모로 끝납니다. 실무에서는 30일, 60일, 90일 단위가 적당합니다.
30일: 파일럿을 만든다
첫 30일의 목표는 "작게 작동하는 에이전트"를 만드는 것입니다. 이때 중요한 것은 기술적으로 화려한 데모가 아니라, 실제 업무 흐름 안에서 쓸 수 있는 최소 기능입니다.
먼저 하나의 업무를 고릅니다. 예를 들어 고객 문의 분류라고 합시다. 이 업무의 입력은 고객 메시지이고, 출력은 문의 유형, 긴급도, 추천 답변, 담당 팀입니다. 여기까지는 명확합니다. 그다음 에이전트가 접근할 수 있는 자료를 정합니다. FAQ, 반품 정책, 배송 정책, 제품 설명서 정도면 충분할 수 있습니다.
30일 파일럿에서는 자동 실행을 제한하는 편이 좋습니다. 고객에게 바로 답장을 보내기보다 상담원에게 답변 초안을 제시하게 합니다. 티켓을 자동 종료하기보다 종료 추천만 하게 합니다. 재고 발주를 직접 실행하기보다 발주 필요 알림과 근거를 제시하게 합니다.
이 단계의 성공 기준은 다음처럼 잡을 수 있습니다. "상담원이 답변 초안을 60% 이상 활용한다", "문의 분류 정확도가 85% 이상이다", "평균 1차 처리 시간이 30% 줄었다"처럼 숫자로 확인 가능한 기준이어야 합니다.
60일: 팀 업무에 붙인다
다음 60일의 목표는 파일럿을 팀의 실제 업무 루틴에 붙이는 것입니다. 이때부터는 에이전트를 쓰는 사람의 경험이 중요해집니다. AI가 아무리 똑똑해도 업무 화면을 오가며 복사·붙여넣기를 해야 한다면 오래 쓰기 어렵습니다.
팀 적용 단계에서는 에이전트를 기존 업무 시스템과 연결합니다. 고객 서비스라면 상담 툴, CRM, 주문 조회 시스템과 이어야 합니다. IT 운영이라면 티켓 시스템, 모니터링 도구, 지식 문서와 연결해야 합니다. 영업이라면 CRM, 이메일, 캘린더, 리드 유입 채널이 연결 대상입니다.
단, 연결이 많아질수록 위험도 커집니다. 그래서 60일 단계에서는 역할별 접근 제어를 반드시 넣어야 합니다. 고객 응대 에이전트가 주문 상태는 읽을 수 있지만 결제 정보는 볼 수 없게 하고, 영업 에이전트가 리드 정보를 업데이트할 수는 있지만 계약 금액을 임의 변경할 수 없게 하는 식입니다.
이 단계에서는 사용자의 피드백 루프도 만들어야 합니다. 상담원이 "이 답변은 부정확함", "정책 근거가 부족함", "고객 어조에 맞지 않음"이라고 표시할 수 있어야 합니다. 에이전트는 한 번 만들고 끝나는 도구가 아니라, 계속 조정하는 운영 대상입니다.
90일: 조직 확장 포트폴리오를 만든다
90일의 목표는 "어디에 더 확장할지"를 결정하는 것입니다. 성공한 파일럿을 무작정 복제하는 것이 아니라, 업무 포트폴리오를 만들어야 합니다.
이때 후보 업무를 두 축으로 배치하면 좋습니다. 하나는 업무 효과입니다. 시간을 많이 줄이는가, 비용을 낮추는가, 고객 경험을 개선하는가, 리스크를 줄이는가를 봅니다. 다른 하나는 실행 위험입니다. 민감정보를 다루는가, 외부 발송을 하는가, 금전 거래를 일으키는가, 법적 책임이 큰가를 봅니다.
효과는 크고 위험은 낮은 업무부터 확장합니다. 예를 들어 보고서 초안 작성, 티켓 분류, 내부 지식 검색, 회의 요약은 좋은 확장 후보입니다. 반대로 자동 환불, 계약 승인, 대규모 고객 발송, 보안 정책 변경은 효과가 크더라도 사람 승인 단계를 넣고 천천히 가야 합니다.
90일이 지나면 조직은 최소한 다음 네 가지를 갖고 있어야 합니다. 첫째, 성과가 확인된 에이전트 사례. 둘째, 실패 사례와 개선 기록. 셋째, 권한·로그·승인 기준. 넷째, 다음 확장 후보 목록입니다. 이 네 가지가 있으면 AI 도입은 이벤트가 아니라 운영 체계가 됩니다.
멀티모달 AI는 현장의 눈과 귀가 된다
에이전트가 "일을 수행하는 AI"라면, 멀티모달 AI는 "여러 형태의 정보를 함께 이해하는 AI"입니다. 기존 AI가 텍스트 중심이었다면, 멀티모달 AI는 이미지, 음성, 영상, 문서, 센서 데이터까지 함께 다룹니다. TileDB의 설명처럼 멀티모달 AI는 텍스트, 이미지, 오디오, 비디오, 센서 신호 같은 여러 데이터 유형을 하나의 이해 체계 안에서 통합해 더 풍부한 판단을 가능하게 합니다.3
이 변화는 생각보다 큽니다. 회사의 많은 정보는 깔끔한 텍스트가 아닙니다. 현장 사진, 콜센터 녹취, 제품 불량 이미지, 회의 영상, 스캔 문서, CCTV, 장비 센서, 손글씨 메모, 프레젠테이션 슬라이드처럼 다양한 형태로 흩어져 있습니다. 사람이 보기에는 자연스럽지만, 기존 시스템이 처리하기에는 까다로운 정보들입니다.
멀티모달 AI는 이런 자료를 함께 읽습니다. 예를 들어 제조 현장에서 작업자가 설비 사진을 찍어 올리면 AI가 이미지에서 이상 징후를 찾고, 과거 정비 기록과 비교하고, 작업 매뉴얼의 관련 부분을 찾아 조치 방법을 안내할 수 있습니다. 고객 상담에서는 통화 음성의 감정 변화, 상담 내용 텍스트, 고객 이력, 후속 이메일을 함께 분석해 불만 원인을 정리할 수 있습니다. 교육 부서에서는 기존 PDF 매뉴얼과 강의 영상을 바탕으로 짧은 학습 콘텐츠와 퀴즈를 만들 수 있습니다.
멀티모달 AI의 대표적인 활용 장면은 다음과 같습니다.
현장 점검: 설비 사진, 점검표, 센서 데이터를 함께 분석해 이상 여부를 확인한다.
회의 기록: 음성, 화면 공유, 채팅, 문서를 함께 요약해 결정 사항과 할 일을 정리한다.
고객 상담 분석: 통화 녹취, 상담 메모, 고객 이력, 감정 신호를 함께 보고 불만 원인을 찾는다.
제품 검수: 제품 이미지와 불량 기준 문서를 함께 비교해 검수 보조를 한다.
교육 콘텐츠 제작: 매뉴얼, 영상, 슬라이드, 음성을 바탕으로 개인화된 학습 자료를 만든다.
단, 멀티모달 AI는 입력이 다양해지는 만큼 위험도 다양해집니다. 사진에는 고객 얼굴이나 차량 번호가 찍힐 수 있고, 음성에는 민감한 개인정보가 들어갈 수 있으며, 문서 이미지에는 계약 조건이나 계좌 정보가 포함될 수 있습니다. 그래서 멀티모달 프로젝트는 모델 선택보다 데이터 점검이 먼저입니다.
시작 전에 반드시 물어야 합니다. 이 이미지와 음성의 출처는 명확한가. 촬영·녹음·분석에 대한 동의가 있는가. 개인정보나 영업비밀이 포함되어 있는가. 품질이 너무 낮아 AI가 엉뚱하게 해석할 가능성은 없는가. 오래된 데이터와 최신 데이터가 섞여 판단을 흐리지는 않는가.
멀티모달 AI는 멋진 기능이 아니라 데이터 위생을 요구하는 기술입니다. 눈과 귀가 많아질수록, 무엇을 보게 할지와 무엇을 보지 못하게 할지를 더 세심하게 정해야 합니다.
여러 에이전트가 함께 일할 때 생기는 문제
처음에는 에이전트 하나로 시작합니다. 고객 문의 에이전트, 재고 확인 에이전트, 보고서 작성 에이전트처럼 말입니다. 그런데 조직이 AI를 계속 도입하면 에이전트는 여러 개가 됩니다. 고객 에이전트는 주문 정보를 확인하려 하고, 재고 에이전트는 창고 시스템을 조회하며, 재무 에이전트는 미수금을 확인하고, 보안 에이전트는 이상 접근을 감시합니다.
이때부터 문제는 "AI 하나가 잘 답하는가"가 아니라 "AI들이 서로 충돌하지 않고 일하는가"가 됩니다.
예를 들어 고객 에이전트가 VIP 고객의 불만을 해결하기 위해 즉시 교환을 제안했다고 해 봅시다. 재고 에이전트는 해당 제품의 재고가 부족하다고 판단합니다. 재무 에이전트는 그 고객에게 미수금이 있다고 알려 줍니다. 보안 에이전트는 이 요청이 평소와 다른 지역에서 들어왔다고 경고합니다. 이 상황에서 어떤 에이전트의 판단이 우선일까요? 누가 최종 결정을 내릴까요? 어디까지 자동으로 진행하고 어디서 멈춰야 할까요?
멀티 에이전트 환경에서는 조율 규칙이 필요합니다. 사람 조직에도 역할과 결재선이 있듯이, 디지털 동료에게도 역할과 권한, 우선순위, 중단 조건이 있어야 합니다.
이때 기본 원칙은 다섯 가지입니다.
최소 권한: 각 에이전트는 자신의 업무에 꼭 필요한 데이터와 도구만 사용한다.
역할별 접근 제어: 고객, 재무, 보안, HR 에이전트의 접근 범위를 분리한다.
도구 호출 승인: 이메일 발송, 결제, 삭제, 외부 API 호출 같은 민감 행동은 승인 단계를 둔다.
실행 한도: 하루 발송 수, 조회 건수, 비용, 반복 횟수, 실행 시간을 제한한다.
감사 로그: 어떤 에이전트가 어떤 근거로 어떤 도구를 호출했는지 기록한다.
여기에 실패 규칙도 필요합니다. 에이전트가 같은 작업을 세 번 실패하면 중단할지, 다른 에이전트에게 넘길지, 사람에게 알릴지 정해야 합니다. 외부 API가 응답하지 않을 때 계속 재시도하면 비용과 장애가 커질 수 있습니다. 잘못된 데이터가 들어왔을 때 억지로 답을 만들면 더 큰 사고로 이어집니다.
좋은 에이전트 시스템은 스스로 실행하지만, 통제 가능합니다. 자율성과 통제는 반대말이 아닙니다. 오히려 통제 장치가 있어야 자율성을 안심하고 넓힐 수 있습니다.
프롬프트 관리만으로는 부족하다
초기 AI 도입에서는 프롬프트가 중심이었습니다. "어떻게 지시해야 좋은 답이 나오는가"가 중요했습니다. 물론 여전히 중요합니다. 하지만 에이전트 시대에는 프롬프트 관리만으로 부족합니다.
에이전트 운영 환경에는 최소한 세 가지 기반이 필요합니다. 데이터 아키텍처, 통합 표준, 모니터링 체계입니다.
데이터 아키텍처는 AI가 참고할 지식과 업무 데이터를 어떻게 정리하고 연결할지에 관한 문제입니다. 사내 문서, 정책, 제품 정보, 고객 데이터, 거래 데이터가 제각각 흩어져 있으면 에이전트는 일관된 판단을 하기 어렵습니다. 검색 증강 생성, 즉 RAG를 쓰더라도 원본 문서의 최신성, 권한, 품질이 관리되지 않으면 잘못된 답을 그럴듯하게 만들 수 있습니다.
통합 표준은 에이전트가 외부 도구와 어떻게 연결되는지에 관한 문제입니다. 일정, 이메일, CRM, ERP, 데이터베이스, 파일 저장소, 코드 저장소, 티켓 시스템을 제각각 연결하면 나중에 유지보수가 어려워집니다. 최근에는 AI 애플리케이션과 외부 시스템을 표준 방식으로 연결하려는 흐름도 강해지고 있습니다. MCP는 AI 클라이언트가 데이터 소스, 도구, 데이터베이스, 업무 흐름을 일관된 방식으로 발견하고 연결하도록 돕는 개방형 표준으로 설명되며, 2026년 로드맵에서도 확장성, 비동기 작업, 감사 추적, SSO 같은 엔터프라이즈 준비 요소가 강조됩니다.4
모니터링 체계는 에이전트가 실제로 무엇을 하는지 보는 장치입니다. 단순히 "응답이 빠른가"만 보면 안 됩니다. 어떤 문서를 검색했는지, 어떤 도구를 호출했는지, 비용이 얼마나 들었는지, 실패율은 어떤지, 사람이 얼마나 수정했는지, 민감정보 노출 시도는 없었는지 확인해야 합니다.
특히 에이전트는 비동기 작업을 많이 합니다. 사용자가 요청한 뒤 바로 끝나는 것이 아니라, 백그라운드에서 자료를 모으고, 여러 시스템을 조회하고, 결과를 기다렸다가 다음 단계를 실행할 수 있습니다. 따라서 작업 상태 관리가 필요합니다. 시작됨, 진행 중, 대기 중, 실패, 재시도, 사람 승인 대기, 완료 같은 상태가 명확해야 합니다.
오류 복구도 중요합니다. 중간에 실패했을 때 처음부터 다시 할지, 실패한 단계만 재시도할지, 이미 실행된 작업을 되돌릴 수 있는지 정해야 합니다. 예를 들어 고객에게 이메일을 보낸 뒤 CRM 업데이트가 실패했다면 어떻게 할까요? 이메일은 이미 나갔으니 단순 재시도만으로 해결되지 않습니다. 이런 상황을 대비해 실행 순서와 보상 절차를 설계해야 합니다.
사람 승인은 속도를 늦추는 장치가 아니다
많은 팀이 사람 승인 단계를 귀찮게 여깁니다. "AI를 도입했는데 왜 또 사람이 확인해야 하느냐"는 말이 나옵니다. 하지만 사람 승인은 자동화를 방해하는 장치가 아니라, 자동화를 더 멀리 보내기 위한 안전장치입니다.
모든 일에 사람이 승인할 필요는 없습니다. 낮은 위험의 작업은 자동 실행해도 됩니다. 예를 들어 공개 문서 검색, 내부 FAQ 요약, 임시 초안 작성, 읽기 전용 조회는 자동화하기 쉽습니다. 반대로 고객에게 메시지를 발송하거나, 금액을 변경하거나, 계약 문구를 확정하거나, 계정을 삭제하거나, 보안 정책을 바꾸는 일은 사람 승인이 필요합니다.
실무에서는 작업을 위험도에 따라 나누면 좋습니다.
낮은 위험: 읽기, 요약, 분류, 초안 작성. 자동 실행 가능.
중간 위험: 내부 시스템 업데이트, 태그 변경, 담당자 배정. 조건부 자동 실행 가능.
높은 위험: 외부 발송, 금액 변경, 법적 문서 수정, 개인정보 처리. 사람 승인 필요.
치명적 위험: 삭제, 결제 실행, 권한 변경, 보안 설정 변경. 다중 승인 또는 자동 실행 금지.
이렇게 나누면 팀원들도 AI를 더 신뢰합니다. "AI가 마음대로 할지도 모른다"는 불안이 줄고, "위험한 일은 반드시 멈춘다"는 확신이 생기기 때문입니다.
좋은 승인 화면은 단순히 "승인하시겠습니까?"라고 묻지 않습니다. 에이전트가 무엇을 하려는지, 왜 하려는지, 어떤 데이터를 근거로 삼았는지, 실행되면 어떤 영향이 있는지 보여 줘야 합니다. 사람은 AI의 결론만 보는 것이 아니라, 판단 가능한 근거를 봐야 합니다.
에이전트 보안은 실행 직전에 잡아야 한다
에이전트 보안에서 특히 중요한 순간은 도구 호출 직전입니다. AI가 "이 파일을 삭제하겠다", "이 고객에게 이메일을 보내겠다", "이 API를 호출하겠다", "이 명령어를 실행하겠다"고 결정한 바로 그 순간입니다. 이때 가로채서 검사할 수 있어야 합니다.
최근 에이전트 보안 도구들이 강조하는 방향도 여기에 가깝습니다. Microsoft의 Agent Governance Toolkit은 에이전트의 행동을 실행 전에 가로채 정책을 적용하는 런타임 거버넌스를 지향하며, 목표 탈취, 도구 오남용, 메모리 오염, 연쇄 실패, 비정상 에이전트 같은 위험 범주를 다룹니다.5 연구 영역에서도 AgentTrust처럼 파일 작업, 셸 명령, HTTP 요청, 데이터베이스 질의 같은 도구 호출을 실행 전 평가해 허용, 경고, 차단, 검토로 판정하는 접근이 제안되고 있습니다.6
핵심은 사후 감사만으로는 부족하다는 것입니다. 이미 고객에게 잘못된 이메일이 발송되었거나, 파일이 삭제되었거나, 민감 데이터가 외부로 나간 뒤에는 로그가 있어도 피해를 되돌리기 어렵습니다. 로그는 필요하지만, 위험한 실행은 사전에 멈출 수 있어야 합니다.
실무적으로는 다음과 같은 장치를 둘 수 있습니다.
파일 삭제, 대량 다운로드, 외부 전송, 결제, 권한 변경 같은 행동은 기본 차단 또는 승인 대기로 둔다.
에이전트가 사용할 수 있는 명령어, API, 데이터 경로를 허용 목록 방식으로 제한한다.
같은 행동을 짧은 시간에 반복하면 자동 중단한다.
비용이 큰 모델 호출이나 대량 처리 작업에는 예산 한도를 둔다.
민감정보가 출력이나 외부 요청에 포함되면 마스킹하거나 차단한다.
보안은 마지막에 붙이는 장식이 아닙니다. 에이전트의 실행 경로 안에 들어가야 합니다.
꿀팁: 책임 있는 AI 운영 체크리스트 5가지
AI 거버넌스라는 말을 들으면 복잡한 위원회, 긴 정책 문서, 어려운 법률 검토부터 떠올리기 쉽습니다. 물론 대규모 조직이나 규제 산업에서는 정교한 체계가 필요합니다. 하지만 시작 단계에서는 다섯 가지 체크리스트로 단순화해도 충분히 많은 사고를 줄일 수 있습니다.
첫째, 데이터 보호입니다. 에이전트가 어떤 데이터를 읽고 쓰는지 목록화해야 합니다. 개인정보, 결제 정보, 건강 정보, 계약 정보, 영업비밀은 별도 표시하고, 필요하지 않으면 입력 단계에서 제거하거나 마스킹합니다. 특히 음성, 영상, 이미지에는 예상치 못한 민감정보가 포함될 수 있으므로 멀티모달 데이터는 더 신중히 봐야 합니다.
둘째, 편향 점검입니다. AI가 특정 고객군, 지원자, 직원, 지역, 성별, 연령에 불리한 판단을 반복하지 않는지 확인해야 합니다. HR, 금융, 보험, 교육, 공공 서비스처럼 사람의 기회와 권리에 영향을 주는 분야에서는 결과의 정확도만큼 공정성도 봐야 합니다.
셋째, 사람 승인입니다. 고위험 업무는 자동 실행하지 않습니다. 외부 발송, 금액 변경, 계약 확정, 계정 정지, 채용 탈락, 법적 판단처럼 영향이 큰 일은 사람의 승인 단계를 넣습니다. 사람 승인은 AI를 불신해서가 아니라 책임의 위치를 명확히 하기 위해 필요합니다.
넷째, 기록 보관입니다. 에이전트가 어떤 입력을 받았고, 어떤 문서를 참고했고, 어떤 도구를 호출했고, 어떤 결과를 냈는지 남겨야 합니다. 기록이 없으면 개선도 어렵고, 사고가 났을 때 원인도 찾기 어렵습니다. 단, 로그에 민감정보를 그대로 남기는 것도 위험하므로 로그 자체의 보안과 보존 기간도 정해야 합니다.
다섯째, 정기 평가입니다. AI는 한 번 잘 작동했다고 계속 잘 작동하지 않습니다. 업무 정책이 바뀌고, 데이터가 바뀌고, 고객 행동이 바뀌고, 모델도 업데이트됩니다. 그래서 정확도, 비용, 업무 절감 효과, 실패 사례, 사용자 만족도, 보안 이벤트를 정기적으로 리뷰해야 합니다. Databricks의 2026년 AI 에이전트 관련 보고서도 평가 도구와 거버넌스가 AI 프로젝트의 프로덕션 전환에 중요한 차이를 만든다고 강조합니다.7
이 다섯 가지를 한 문장으로 줄이면 이렇습니다. "데이터를 조심히 쓰고, 편향을 살피고, 위험한 일은 사람이 승인하고, 모든 실행을 기록하고, 주기적으로 다시 평가한다." 이 문장만 지켜도 AI 도입의 수준은 크게 올라갑니다.
바로 써먹는 에이전트 설계 템플릿
에이전트를 만들 때는 프롬프트부터 쓰지 말고, 설계서를 먼저 써 보세요. 복잡한 문서가 아니어도 됩니다. 아래 항목을 채우면 에이전트의 범위가 훨씬 선명해집니다.
1. 에이전트 이름
예: 고객 문의 분류 에이전트
2. 목표
예: 들어온 고객 문의를 유형, 긴급도, 담당 팀으로 분류하고 답변 초안을 작성한다.
3. 입력 데이터
예: 고객 메시지, 주문 번호, 제품명, 고객 등급, 문의 채널
4. 참고 지식
예: FAQ, 배송 정책, 반품 정책, 제품 매뉴얼, 최근 공지
5. 허용 도구
예: 주문 상태 조회, 고객 이력 조회, FAQ 검색, 티켓 생성
6. 금지 도구 또는 금지 행동
예: 결제 정보 조회, 환불 실행, 고객 등급 변경, 외부 메일 자동 발송
7. 사람 승인 조건
예: 보상 요청, 법적 위협, 개인정보 삭제 요청, VIP 고객 불만, 금액 관련 문의
8. 성공 지표
예: 분류 정확도 85% 이상, 상담원 초안 활용률 60% 이상, 첫 응답 시간 30% 단축
9. 실패 시 처리
예: 정책 근거를 찾지 못하면 "확인 필요"로 표시하고 상담원에게 넘긴다.
10. 로그 항목
예: 입력 시간, 분류 결과, 참고 문서, 도구 호출, 상담원 수정 여부, 최종 처리 결과
이 템플릿은 단순하지만 강력합니다. 에이전트가 해야 할 일과 하지 말아야 할 일을 한눈에 보여 주기 때문입니다. 특히 "금지 행동"과 "사람 승인 조건"을 비워 두지 않는 것이 중요합니다.
멀티모달 프로젝트를 시작하기 전 묻는 질문
멀티모달 AI는 기능 시연이 화려합니다. 이미지를 올리면 설명하고, 회의 영상을 요약하고, 제품 사진에서 이상을 찾는 모습을 보면 당장 도입하고 싶어집니다. 하지만 현업 프로젝트에서는 입력 데이터의 품질이 성패를 가릅니다.
시작 전에 다음 질문을 던져 보세요.
이미지, 음성, 영상, 문서의 출처와 사용 권한이 명확한가?
개인정보, 얼굴, 음성, 위치 정보, 차량 번호, 계좌 정보가 포함되어 있지는 않은가?
데이터 품질이 업무 판단에 충분한가?
사람마다 라벨링 기준이 달라 모델이 혼란스러워하지는 않는가?
AI가 틀렸을 때 사람이 쉽게 확인하고 수정할 수 있는가?
결과를 어디에 저장하고, 누가 다시 볼 수 있는가?
예를 들어 제품 검수 AI를 만든다고 합시다. 불량 사진이 충분하지 않거나, 불량 기준이 작업자마다 다르거나, 조명과 촬영 각도가 제각각이면 AI는 안정적으로 판단하기 어렵습니다. 이때는 모델을 바꾸기보다 촬영 기준, 라벨링 기준, 검수 기준부터 정리해야 합니다.
회의 요약 AI도 마찬가지입니다. 녹음 품질이 낮고, 참석자 이름이 불명확하고, 화면 공유 자료가 따로 저장되지 않으면 요약 품질이 떨어집니다. 좋은 멀티모달 AI는 좋은 모델만으로 만들어지지 않습니다. 좋은 입력 습관과 데이터 관리가 함께 있어야 합니다.
조직에 필요한 새 역할
에이전트와 멀티모달 AI가 확산되면 조직 안의 역할도 달라집니다. 모든 직원이 개발자가 될 필요는 없지만, 많은 직원이 AI와 함께 일하는 법을 배워야 합니다.
앞으로 중요해질 역할은 다음과 같습니다.
업무 오너: 어떤 문제를 풀 것인지, 성공 기준이 무엇인지 정의한다.
AI 제품 관리자: 사용자 경험, 업무 흐름, 지표, 개선 우선순위를 관리한다.
데이터 담당자: 데이터 품질, 권한, 최신성, 분류 체계를 관리한다.
에이전트 운영자: 에이전트 성능, 비용, 실패 사례, 로그를 모니터링한다.
보안·컴플라이언스 담당자: 접근 제어, 감사, 규정 준수, 위험 평가를 맡는다.
현업 리뷰어: AI 결과를 검토하고 실제 업무 기준에 맞게 피드백한다.
작은 조직이라면 한 사람이 여러 역할을 맡아도 됩니다. 중요한 것은 역할 이름이 아니라 책임이 비어 있지 않는 것입니다. "AI가 알아서 하겠지"라고 두는 순간, 아무도 품질과 위험을 책임지지 않는 상태가 됩니다.
실패하는 도입의 공통 패턴
AI 에이전트 프로젝트가 실패할 때는 대개 비슷한 패턴을 보입니다.
첫 번째는 기술부터 고르는 것입니다. "어떤 모델이 제일 좋은가", "어떤 에이전트 프레임워크를 쓸까"부터 시작하면 업무 문제가 뒤로 밀립니다. 좋은 시작은 언제나 "어떤 반복 업무를 줄일 것인가", "무엇을 측정할 것인가"입니다.
두 번째는 데이터를 과소평가하는 것입니다. 사내 문서가 오래되었고, 같은 정책이 여러 버전으로 존재하고, 고객 데이터가 중복되어 있고, 권한 체계가 흐릿한데 AI만 붙이면 혼란이 빨라질 뿐입니다.
세 번째는 권한을 넓게 주는 것입니다. 빨리 만들기 위해 모든 API와 데이터베이스 접근을 허용하면 데모는 쉬워집니다. 하지만 운영으로 넘어가는 순간 보안팀, 법무팀, 고객 신뢰의 벽에 부딪힙니다.
네 번째는 성과를 기분으로 판단하는 것입니다. "좋아 보인다", "똑똑하다", "쓸 만하다"는 말만으로는 확장할 수 없습니다. 처리 시간, 정확도, 수정률, 비용, 오류율, 만족도 같은 지표가 있어야 합니다.
다섯 번째는 실패 사례를 숨기는 것입니다. AI가 틀린 사례는 부끄러운 것이 아니라 개선 자산입니다. 실패 사례를 모아야 프롬프트도, 데이터도, 권한도, 승인 기준도 좋아집니다.
마지막 로드맵: 보조에서 동료로
이 책의 첫 장에서 우리는 좋은 AI 활용 사례를 볼 때 문제, 적용 방식, 측정 가능한 결과를 함께 보자고 했습니다. 마지막 장의 결론도 같습니다. 에이전트와 멀티모달 AI 역시 유행어가 아니라 문제 해결 방식입니다.
AI 도입은 다음 순서로 성숙해집니다.
처음에는 개인이 어시스턴트를 씁니다. 글을 쓰고, 요약하고, 아이디어를 얻습니다. 그다음 팀이 반복 업무에 AI를 붙입니다. 문의를 분류하고, 보고서를 만들고, 리드를 선별합니다. 이후에는 에이전트가 업무 시스템과 연결되어 제한된 행동을 실행합니다. 마지막으로 여러 에이전트와 멀티모달 AI가 함께 일하며, 사람은 목표와 기준, 예외 판단, 윤리적 책임을 맡습니다.
이 흐름에서 가장 중요한 태도는 균형입니다. AI를 과소평가하면 기회를 놓칩니다. AI를 과신하면 사고가 납니다. 좋은 조직은 AI에게 일을 맡기되, 책임까지 떠넘기지는 않습니다. AI가 빠르게 움직일 수 있도록 길을 열어 주되, 위험한 구간에는 신호등과 브레이크를 둡니다.
앞으로의 AI 활용은 "질문에 답하는 도구"에서 "업무를 함께 수행하는 디지털 동료"로 확장됩니다. 하지만 훌륭한 동료는 그냥 생기지 않습니다. 역할을 정하고, 필요한 정보를 주고, 권한을 조절하고, 피드백을 주고, 함께 일하는 규칙을 만들어야 합니다.
AI 에이전트와 멀티모달 AI의 시대에도 기본은 변하지 않습니다. 작은 문제에서 시작하고, 성과를 측정하고, 위험을 통제하고, 사람의 판단을 남겨 두는 것. 이 네 가지를 지키는 조직이 AI를 가장 오래, 가장 안전하게, 가장 실속 있게 활용하게 될 것입니다.
참고
1AI Agent Adoption Guidance for Organizations - Cloud Adoption Framework | Microsoft Learn
2AI Agent Security Cheat Sheet - OWASP Cheat Sheet Series
3What is multimodal AI: A complete 2026 guide
4MCP 2026 Roadmap: 4 Priorities Transforming AI Agent Integrations and Enterprise Readiness
5Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents
6AgentTrust: Runtime Safety Evaluation and Interception for AI Agent Tool Use
72026 State of AI Agents: Enterprise Insights on Building AI | Databricks
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.