대부분의 기업에 에이전트가 필요할까?

업무를 설명하는 회의에서 요즘 가장 자주 등장하는 단어는 에이전트다. 문의를 읽고 답하고, 메일을 분류하고, 표를 채우고, 필요한 시스템에 들어가 다음 일을 처리하는 소프트웨어... 말로 지시하면 알아서 움직이는 디지털 동료의 그림은 매력적이다. 특히 늘 사람이 부족한 조직에서는 더 그렇다.

하지만 자동화 프로젝트가 자주 실패하는 이유는 자동화 도구가 충분히 똑똑하지 않아서만은 아니다. 무엇을 자동화할지 정하기 전에, 지금 일이 어떻게 흘러가는지를 아무도 정확히 설명하지 못하는 경우가 많다. 업무는 사람마다 다르게 처리되고, 예외는 흩어져 있으며, 필요한 데이터는 여러 시스템에 나뉘어 있다. 여기에 에이전트를 올리면 복잡성이 사라지기보다 더 빠르게 움직인다.

많은 기업이 필요한 것은 자율적으로 판단하고 움직이는 에이전트가 아니라, 작고 구체적이며 관리할 수 있는 자동화가 아닐까? 이 말은 에이전트가 쓸모없다는 뜻이 아니다. 다만 ‘에이전트를 도입할까?’보다 앞서 물어야 할 질문이 있다는 뜻이다. ‘어떤 일을, 어떤 조건에서, 어느 정도까지 AI에게 맡길 것인가?’

에이전트는 자동화의 다른 이름이 아니다

먼저 용어를 정리해보자. 규칙 기반 자동화는 정해진 조건에 따라 정해진 동작을 한다. 예를 들어 주문 상태가 ‘결제 완료’로 바뀌면 영수증을 보내는 식이다. 예측형 AI는 과거 데이터에서 패턴을 찾아 점수나 예측을 한다. 생성형 AI는 문서 요약, 답변 초안, 분류처럼 언어를 다루는 작업을 돕는다.

AI 에이전트는 여기서 한 걸음 더 나아간다. 목표를 정하고, 필요한 단계를 정하고, 도구를 선택해 호출하고, 결과를 확인하며 다음 행동을 이어간다. ‘환불 요청을 처리해’라는 말에 주문을 조회하고, 정책을 확인하고, 환불 가능 여부를 판단하고, 환불 시스템에 요청을 등록하는 식이다. 중요한 차이는 문장을 잘 만드는 데 있지 않다. 외부 시스템에 영향을 주는 행동을 여러 단계에 걸쳐 수행한다는 데 있다.

따라서 에이전트가 들어가는 순간, 질문도 달라진다. 답이 조금 어색한가의 문제가 아니라, 잘못된 주문을 취소했는가?, 고객의 개인정보를 엉뚱한 곳에 보냈는가?, 되돌리기 어려운 변경을 했는가?가 된다.

이런 상황에서는 자동화의 자율성이 커질수록, 실수는 답변의 품질 문제에서 업무와 권한의 문제가 된다.

숫자가 말하는 것은 열풍보다 간극이다

Gartner가 250명 이상 기업의 IT 애플리케이션 리더 360명을 조사한 결과, 응답자의 75%는 어떤 형태로든 AI 에이전트를 파일럿, 배포 중이거나 이미 사용한다고 답했다. 그러나 사람의 감독 없이 목표를 수행하는 ‘완전 자율형’ 에이전트를 파일럿, 배포하는 비율은 15%였다. 같은 조사에서 조직 내 AI 거버넌스 체계가 갖춰져 있다고 강하게 동의한 응답자는 13%에 그쳤고, IT, 현업, 경영진 사이에 AI가 해결할 문제에 대한 정렬이 있다고 강하게 답한 비율은 14%였다.

이 수치를 ‘기업은 에이전트를 쓰지 않는다’고 읽으면 안된다. 오히려 넓은 의미의 에이전트 실험은 늘었지만, 사람의 확인 없이 중요한 일을 맡기는 단계는 훨씬 제한적이라는 신호다. 기술의 가능성과 운영의 준비 사이에 간격이 있다는 얘기다.

NIST가 에이전트 도구 사용에 관한 논의에서 강조한 것도 비슷한 현실이다. 에이전트가 어떤 도구를 사용하는 뿐만 아니라, 그 도구가 읽기만 가능한지, 쓰기도 가능한지, 행동이 되돌릴 수 있는지, 외부의 신뢰할 수 없는 정보를 접하는지, 실행 결과를 관찰하고 기록할 수 있는지를 봐야 한다. ‘AI를 붙였다’는 설명만으로는 위험도도 성과도 알 수 없다.

작은 자동화가 이기는 이유

가령 고객센터에 배송 지연 문의가 들어온다고 해보자. 전면 자율형 에이전트는 고객의 말을 이해하고, 주문과 배송 정보를 조회하고, 보상 정책을 확인하고, 답변을 보내거나 보상금을 지급할 수 있다. 멋진 데모다. 그러나 실제 운영에서는 주소 변경, 중복 주문, 부분 배송, 악성 요청, 정책 예외, 시스템 장애가 함께 등장한다.

더 작은 출발점은 문의를 유형별로 분류하고, 주문번호와 배송 상태를 찾아 상담원 화면에 요약을 띄우며, 정책에 맞는 답변 초안을 제안하는 것이다. 이렇게 하면 반복 조회와 초안 작성 시간은 줄이면서도, 고객에게 약속하거나 금전적 조치를 취하는 최종 권한은 사람에게 남길 수 있다.

이렇게 하면 무엇보다 결과를 비교할 수 있다. 도입 전후의 문의당 처리 시간, 상담원 수정률, 잘못된 분류율, 재문의율을 보면 자동화가 실제로 도움이 됐는지 판단할 수 있다. “AI가 일을 잘했다”가 아니라 “어떤 지표가 얼마나 바뀌었는가”를 말할 수 있게 된다.

무엇을 맡길지 결정하는 네 가지 질문

1. 일이 반복되는가? 매번 입력과 판단이 크게 달라지는 일보다, 자주 발생하고 기본 흐름이 일정한 일이 자동화 후보가 되기 쉽다. 반복 횟수만 보지 말고 예외가 얼마나 자주 생기는지도 함께 기록한다.
2. 성공을 측정할 수 있는가? 처리 시간, 오류율, 재작업, 누락 건수, 고객 대기 시간처럼 도입 전 기준선을 만들 수 있어야 한다. 기준선이 없으면 개선인지 착시인지 알기 어렵다.
3. 실패했을 때 되돌릴 수 있는가? 문서 초안을 만드는 일과 송금, 주문 취소, 계정 권한 변경은 같은 위험이 아니다. 초안 생성이나 내부 추천은 비교적 낮은 권한으로 시작할 수 있지만, 외부 발송과 금전, 권한 변경에는 승인 단계와 취소 절차가 필요하다.
4. 필요한 데이터와 권한이 준비되어 있는가? 에이전트는 업무 시스템의 데이터를 읽거나 수정할 수 있어야 제 역할을 한다. 그러나 모든 데이터와 권한을 한꺼번에 열어주는 것은 편리함이 아니라 통제의 부재다. 업무에 필요한 범위로 권한을 제한하고, 어떤 정보와 도구를 사용했는지 로그로 남기는 설계가 먼저다.

자율성은 스위치가 아니라 다이얼이다

에이전트 도입은 ‘사람이 한다’와 ‘AI가 다 한다’ 사이에서 하나를 고르는 일이 아니다. 여러 단계로 설계할 수 있다.

1. 정리: 정보 검색/요약, 판단하고 실행, 문의 요약/주문 정보 조회
2. 제안: 분류/답변 초안/추천, 검토 후 승인, 답변 초안/보상안 추천
3. 제한 실행: 정해진 범위에서 처리, 예외와 고위험 건 승인, 기준 이하 쿠폰 자동 발급
4. 자율 실행: 여러 도구를 연결해 목표 수행, 모니터링/중단/사후 검토, 조건이 명확한 반복 프로세스

좋은 설계는 모든 단계에서 사람에게 확인을 요구하지 않는다. 이렇게 되면 승인 요청이 너무 많아져 형식적인 클릭이 되기 쉽다. 반대로 모든 일을 한꺼번에 맡기지도 않는다. 금액, 개인정보, 외부 발송, 되돌릴 수 없는 변경처럼 영향이 큰 행동에 사람의 확인을 집중한다. 낮은 위험의 반복 작업은 제한된 권한과 충분한 모니터링을 전제로 더 많이 자동화할 수 있다.

NIST의 생성형 AI 위험 관리 지침도 조직과 사용 맥락에 따라 사람의 검토, 추적, 문서화, 관리 감독의 수준을 달리할 수 있다고 설명한다. 핵심은 ‘사람을 끼워 넣었는가’라는 형식이 아니라, 사람이 무엇을 알고 어떤 시점에 개입할 수 있는가다.

출발점은 에이전트 목록이 아니라 업무 지도

실무에서는 먼저 한 업무를 처음부터 끝까지 그려보는 편이 낫다.

• 요청은 어디서 들어오는가?
• 누가 내용을 확인하는가?
• 어떤 시스템을 조회하는가?
• 예외는 누가 판단하는가?
• 최종 결과는 어디에 기록되는가?
• 일이 멈추거나 잘못됐을 때 누가 발견하고 복구하는가?

이 지도를 만들면 자동화 후보가 보인다. 복사, 붙여넣기, 중복 조회, 형식 변환, 반복 안내처럼 정형화된 단계는 규칙 기반 자동화나 기존 시스템 기능으로 해결될 수 있다. 문서에서 정보를 뽑고 요약하거나, 자유형 문의를 분류하고 답변 초안을 만드는 단계에는 생성형 AI가 적합할 수 있다. 여러 시스템에 걸쳐 목표를 해석하고 순서를 조정하며 실행해야 하는 경우에야 에이전트의 가치가 커진다.

이 구분은 에이전트를 저평가하는 것이 아니다. 오히려 에이전트를 가장 복잡하고 비싼 문제에 쓰기 위해, 더 단순한 도구로 충분한 문제를 먼저 걷어내는 일이다.

90일 안에 확인하는 현실적인 첫걸음

1. 첫 2주 동안은 업무 하나를 선정하고 현재 처리 과정을 관찰한다. 실제 사례를 모아 정상 흐름과 예외를 나누고, 처리 시간과 오류/재작업의 기준선을 기록한다. 현업 담당자가 이 과정에 참여해야 한다. 절차서에 적힌 업무와 실제로 돌아가는 업무가 다를 수 있기 때문이다.
2. 그다음 2~4주 동안은 가장 좁은 범위의 자동화를 만든다. 처음에는 읽기 전용으로 정보 검색과 요약을 제공하거나, 사람이 승인하는 초안을 생성하는 방식이 적절하다. 테스트에는 평범한 사례만 넣지 않는다. 정보 누락, 상충하는 규정, 시스템 오류, 악의적인 입력, 모호한 요청도 넣는다.
3. 이후 4~8주 동안 제한된 사용자와 실제 업무에서 운영하면서 지표를 확인한다. 처리 시간이 줄었는지, 정확도는 유지되는지, 사람이 초안을 얼마나 고치는지, 잘못된 행동을 얼마나 빨리 발견하고 되돌릴 수 있는지를 본다. 목표를 달성하고 위험이 통제되면 권한을 한 단계 넓힌다. 그렇지 않으면 범위를 줄이거나 자동화를 멈추고 원인을 고친다.

이 숫자는 보편적인 표준이 아니라 실행을 위한 한 가지 예시다. 중요한 것은 특정 기간이 아니라 작은 범위에서 검증하고, 결과가 확인된 만큼만 자율성을 높이는 순서다.

결국 경쟁력은 ‘에이전트를 몇 개 쓰는가’가 아니다

기업의 AI 논의는 종종 모델 이름과 에이전트 수로 기울어진다. 하지만 고객은 조직이 에이전트를 몇 개 만들었는지보다 답변을 더 빨리 받는지, 오류가 줄었는지, 약속이 지켜졌는지를 경험한다. 직원은 반복 업무가 줄었는지, 예외 처리에 더 많은 시간을 쓸 수 있게 됐는지로 변화를 느낀다.

그래서 시작은 기술보다 업무에 가까워야 한다. 적용할 업무를 고르고, 현재 흐름을 기록하고, 개선하고 싶은 지표를 정해야 한다. 가장 위험이 낮은 단계부터 AI에 맡긴 뒤, 정확도와 복구 가능성을 확인하며 권한을 넓힌다. 이 과정에서 단순한 규칙 자동화가 충분하다면 거기서 멈추는 것도 좋은 결정이다.

AI 에이전트는 목표가 아니라 도구다. 조직에 필요한 것은 자율성 그 자체가 아니라, 신뢰할 수 있는 결과를 더 적은 마찰로 만드는 운영 방식이다. 에이전트를 도입할 준비가 됐는지 묻기 전에, 먼저 업무가 누구에게나 설명될 만큼 명확한지 물어야 한다. 그 질문에 답할 수 있다면, 자동화의 다음 단계도 훨씬 분명해진다.

Source:

• Gartner, 2025년 완전 자율형 AI 에이전트 조사
• NIST, Lessons Learned from the Consortium: Tool Use in Agent Systems
• NIST AI 600-1, Generative Artificial Intelligence Profile