AI는 이제 대답보다 '결과'를 요구받는다
불과 몇 년 전만 해도 생성형 AI를 잘 쓰는 사람은 "질문을 잘하는 사람"이었다. 같은 도구를 쓰더라도 어떤 사람은 평범한 답을 얻었고, 어떤 사람은 보고서 초안, 마케팅 문구, 코드 예제, 회의록 요약까지 순식간에 뽑아냈다. 그래서 한동안 기업 교육의 핵심은 프롬프트였다. "역할을 부여하라", "맥락을 충분히 주라", "출력 형식을 지정하라" 같은 조언이 쏟아졌다.
하지만 2026년의 AI 흐름은 그다음 단계로 넘어가고 있다. 이제 중요한 질문은 "AI에게 무엇을 물어볼 것인가?"가 아니라 "AI가 어떤 일을 끝까지 수행하게 만들 것인가?"이다. 사용자가 한 번 질문하면 AI가 답변을 생성하는 수준을 넘어, 목표를 이해하고, 필요한 정보를 찾고, 여러 도구를 호출하고, 중간 결과를 검토하고, 최종 산출물을 만들어내는 방향으로 진화하고 있다. 이것이 생성형 AI에서 에이전트 AI로 넘어가는 변화의 핵심이다.
생성형 AI가 '말을 잘하는 동료'였다면, 에이전트 AI는 '일의 일부를 맡길 수 있는 실행자'에 가깝다. 물론 완전히 자율적인 직원처럼 아무 일이나 믿고 맡길 수 있다는 뜻은 아니다. 오히려 지금 중요한 것은 AI의 자율성을 어디까지 허용하고, 어떤 순간에 사람이 개입해야 하며, 어떤 기준으로 결과를 검증할지 설계하는 능력이다.
이 변화는 단순한 기능 추가가 아니다. 기업의 업무 방식, 조직 구조, 인재 역량, IT 아키텍처를 함께 바꾸는 흐름이다. 생성형 AI를 도입한 기업은 많지만, 실제 수익과 생산성 향상으로 연결한 기업은 아직 제한적이다. 2026년에는 많은 기업이 "AI를 써봤다"에서 "AI가 실제 업무를 처리한다"로 넘어가야 하는 압박을 받게 된다. Gartner의 전망을 인용한 보도에 따르면 2026년에는 80%가 넘는 기업이 생성형 AI 애플리케이션을 시험하거나 배포할 것으로 예상되며, 2023년의 5% 미만과 비교하면 도입 속도가 얼마나 빠른지 알 수 있다1. 그러나 도입이 곧 성과를 의미하지는 않는다. 그래서 에이전트 AI가 주목받는다. 이제 AI는 콘텐츠를 만드는 도구를 넘어, 업무 흐름 속에서 결과를 만들어내는 시스템으로 평가받기 시작했다.
생성형 AI의 첫 번째 무대: 콘텐츠 생성
생성형 AI의 대중화는 텍스트에서 시작되었다. 사용자는 자연어로 요청하고, AI는 그럴듯한 문장을 생성했다. 이메일을 다듬고, 블로그 글을 쓰고, 기획안의 뼈대를 만들고, 복잡한 개념을 쉽게 설명하는 일에서 생성형 AI는 즉각적인 효용을 보여주었다. 이전의 AI가 주로 분류, 예측, 추천에 강했다면 생성형 AI는 새로운 콘텐츠를 만들어냈다. 텍스트뿐 아니라 이미지, 음성, 영상, 코드까지 생성할 수 있게 되면서 AI의 사용 범위는 빠르게 넓어졌다.
이 단계에서 핵심 역량은 '입력과 출력'이었다. 사용자가 얼마나 좋은 입력을 주느냐에 따라 AI의 출력 품질이 달라졌다. 그래서 프롬프트 엔지니어링이 중요해졌다. AI에게 역할을 지정하고, 배경 정보를 넣고, 원하는 형식을 알려주면 결과가 좋아졌다. 예를 들어 "신제품 홍보 문구를 써줘"라고 묻는 것보다 "30대 직장인을 대상으로 한 구독형 생산성 앱의 랜딩페이지 첫 화면 문구를 세 가지 톤으로 작성해줘"라고 요청하면 훨씬 쓸 만한 결과가 나왔다.
하지만 이 방식에는 한계가 있었다. AI가 답을 만들어주긴 하지만, 그 답을 실제 업무에 반영하는 과정은 여전히 사람이 해야 했다. 고객 문의 답변을 생성해도 CRM에 기록하고, 환불 정책을 확인하고, 배송 시스템에서 상태를 조회하고, 고객에게 최종 메시지를 보내는 일은 따로 남았다. 보고서 초안을 만들어도 데이터 수집, 표 정리, 사실 확인, 승인 요청은 사람이 이어서 처리해야 했다.
즉 생성형 AI는 '작업 조각'을 빠르게 만들었지만, '업무 전체'를 끝내지는 못했다. 기업 입장에서 보면 이것은 중요한 차이다. 작업 조각이 빨라지는 것만으로는 조직 전체의 성과가 자동으로 개선되지 않는다. 한 사람의 문서 작성 시간은 줄어들 수 있지만, 결재 단계가 그대로이고, 데이터가 흩어져 있으며, 최종 의사결정이 지연된다면 전체 리드타임은 크게 줄지 않는다.
그래서 다음 질문이 등장했다. AI가 단지 문장을 생성하는 데 그치지 않고, 업무 목표를 받아서 필요한 절차를 스스로 진행할 수는 없을까?
멀티모달, 도구 사용, API 호출이 만든 두 번째 도약
생성형 AI가 에이전트 AI로 발전할 수 있었던 이유는 모델 자체가 똑똑해졌기 때문만은 아니다. 더 중요한 변화는 AI가 외부 세계와 연결되기 시작했다는 점이다. 초기의 생성형 AI는 대화창 안에서 주어진 정보만 바탕으로 답변했다. 반면 최신 AI 시스템은 텍스트, 이미지, 음성, 영상 같은 여러 형태의 입력을 함께 이해하고, 검색 도구나 데이터베이스, 업무용 소프트웨어, 외부 API를 호출할 수 있다.
멀티모달은 여러 종류의 데이터를 함께 다루는 능력을 뜻한다. 예전에는 사용자가 "이 표를 설명해줘"라고 말하려면 표 내용을 텍스트로 옮겨야 했다. 이제는 이미지나 PDF를 올리고 "이 계약서의 위험 조항을 찾아줘"라고 요청할 수 있다. 제조 현장에서는 설비 사진과 센서 데이터를 함께 보고 이상 징후를 판단할 수 있고, 의료 행정에서는 진료 기록과 음성 메모를 함께 정리할 수 있다.
도구 사용은 AI가 계산기, 검색 엔진, 코드 실행 환경, 문서 저장소, 사내 지식베이스 같은 외부 기능을 필요에 따라 사용하는 능력이다. 사람도 모든 것을 머릿속에서 해결하지 않는다. 회계 담당자는 ERP를 열고, 개발자는 Git 저장소를 확인하고, 영업 담당자는 CRM에서 고객 이력을 본다. 에이전트 AI 역시 목표를 달성하기 위해 적절한 도구를 선택해야 한다.
API 호출은 이 흐름을 실제 업무와 연결한다. API는 소프트웨어끼리 데이터를 주고받고 기능을 실행하도록 해주는 통로다. AI가 "고객의 주문 상태를 확인한다"는 말은 실제로는 주문 관리 시스템의 API를 호출해 배송 상태를 가져오는 일일 수 있다. "환불을 처리한다"는 말은 결제 시스템에 요청을 보내고, 재고 시스템을 갱신하고, 고객에게 안내 메시지를 발송하는 여러 API 호출의 묶음일 수 있다.
이때 AI는 더 이상 대화창 안의 글쓰기 도구가 아니다. 업무 시스템 위에 얹힌 조정자에 가까워진다. 사용자가 "지난 분기 영업 성과를 분석하고 다음 주 임원회의용 보고서를 준비해줘"라고 요청하면, 에이전트는 CRM에서 영업 데이터를 가져오고, 데이터 웨어하우스에서 매출 추이를 확인하고, 전 분기 보고서 양식을 참고하고, 주요 변동 요인을 요약한 뒤, 슬라이드 초안을 만들 수 있다. 마지막에는 사람에게 검토 요청을 보내고, 수정 의견을 반영할 수도 있다.
이런 변화 때문에 생성형 AI와 에이전트 AI의 경계는 점점 더 중요해진다. IBM은 생성형 AI를 텍스트, 이미지, 영상, 코드 같은 새로운 콘텐츠를 만들어내는 기술로 설명하는 반면, 에이전트 AI는 제한된 감독 아래 목표를 추구하며 결정을 내리고 행동하는 시스템으로 구분한다2. 쉽게 말해 생성형 AI가 "무언가를 만들어주는 AI"라면, 에이전트 AI는 "무언가를 해내기 위해 움직이는 AI"이다.
에이전트 AI는 어떻게 일하는가
에이전트 AI를 이해하려면 사람의 업무 수행 과정을 떠올려보면 쉽다. 예를 들어 팀장이 직원에게 "이번 달 이탈 고객 원인을 분석하고 개선안을 가져오세요"라고 지시했다고 하자. 직원은 곧바로 보고서를 쓰지 않는다. 먼저 어떤 고객이 이탈했는지 정의하고, 데이터를 어디서 가져올지 확인하고, 고객군을 나누고, 인터뷰나 문의 기록을 살펴보고, 원인을 추정하고, 개선안을 만들고, 상사에게 설명할 형태로 정리한다.
에이전트 AI도 비슷한 구조로 움직인다. 다만 사람이 머릿속으로 하던 판단을 시스템 설계 안에 넣어야 한다. 일반적으로 에이전트형 시스템은 목표를 입력받고, 그 목표를 작은 작업으로 나누며, 필요한 도구와 데이터를 선택하고, 실행 결과를 평가하면서 다음 행동을 결정한다. 연구와 산업계의 설명을 종합하면 현대적 AI 에이전트는 대형 언어 모델을 중심에 두고 메모리, 계획, 도구 사용, 외부 환경과의 상호작용 같은 구성 요소를 결합한다3.
조금 더 쉽게 풀어보면 에이전트의 기본 작동 원리는 다음 흐름으로 이해할 수 있다.
목표 이해: 사용자가 원하는 최종 결과가 무엇인지 파악한다.
작업 분해: 목표를 달성하기 위해 필요한 단계를 작은 일로 나눈다.
실행과 검증: 도구를 사용해 각 단계를 수행하고, 결과가 기준에 맞는지 확인한다.
수정과 반복: 오류나 부족한 부분이 있으면 다시 정보를 찾거나 다른 방법을 시도한다.
보고와 승인: 최종 결과를 사람이 이해할 수 있는 형태로 제시하고, 필요한 경우 승인을 요청한다.
여기서 중요한 것은 '자율성'이 전부가 아니라는 점이다. 에이전트 AI가 모든 일을 마음대로 처리하게 만드는 것이 목표는 아니다. 좋은 에이전트 설계는 어느 단계까지 AI가 실행하고, 어느 단계에서 사람이 승인하며, 어떤 행동은 금지할지 명확히 정한다. 예를 들어 고객 지원 에이전트가 배송 상태 안내까지는 자동으로 할 수 있지만, 고액 환불이나 법적 분쟁 가능성이 있는 답변은 반드시 사람에게 넘기도록 설계할 수 있다.
이 구조를 흔히 "사람이 운전대를 잡고 AI가 엔진을 돌리는 방식"이라고 설명할 수 있다. 사람이 모든 페달을 직접 밟지는 않지만, 목적지와 경로의 큰 원칙, 위험 상황에서의 판단은 사람이 책임진다. 에이전트 AI 시대의 핵심 역량은 AI에게 더 많은 권한을 주는 것이 아니라, 적절한 권한과 책임의 경계를 설계하는 것이다.
질문을 잘하는 능력에서 일을 끝내게 설계하는 능력으로
생성형 AI 초기에는 프롬프트가 경쟁력이었다. 같은 모델을 쓰더라도 더 구체적으로 묻고, 예시를 잘 주고, 원하는 형식을 명확히 지정하면 결과가 달라졌다. 그러나 에이전트 AI 시대에는 프롬프트만으로 충분하지 않다. 한 번의 좋은 질문보다 중요한 것은 업무 전체를 AI가 처리할 수 있는 구조로 바꾸는 일이다.
예를 들어 "고객 불만을 줄이는 방법을 알려줘"라는 질문은 생성형 AI에게 던질 수 있는 좋은 질문일 수 있다. 하지만 에이전트 AI 관점에서는 부족하다. 실제로 고객 불만을 줄이려면 문의 데이터를 수집하고, 불만 유형을 분류하고, 반복 원인을 찾고, 관련 부서의 처리 시간을 비교하고, 개선 과제를 만들고, 실행 후 지표를 추적해야 한다. 이때 필요한 것은 멋진 질문이 아니라 실행 가능한 업무 설계다.
에이전트 AI를 잘 활용하는 조직은 업무를 다음과 같이 바라본다. 먼저 목표를 명확히 정의한다. "고객 만족도를 높인다"는 목표는 너무 넓다. "배송 지연 관련 문의의 평균 해결 시간을 30% 줄인다"처럼 측정 가능한 목표가 필요하다. 다음으로 AI가 접근할 수 있는 데이터와 도구를 정한다. 주문 관리 시스템, 상담 기록, 배송사 API, 고객 메시지 템플릿 등이 여기에 해당한다. 그리고 AI가 자동으로 처리할 수 있는 범위와 사람이 승인해야 하는 범위를 나눈다. 마지막으로 결과를 평가할 지표를 둔다. 처리 시간, 재문의율, 고객 만족 점수, 오류율 등이 될 수 있다.
이것이 바로 '질문 능력'에서 '완료 설계 능력'으로의 이동이다. 앞으로의 AI 경쟁력은 프롬프트 문장 몇 개를 잘 쓰는 데서 끝나지 않는다. AI가 일을 끝까지 수행하도록 목표, 데이터, 도구, 권한, 검증, 책임을 하나의 흐름으로 설계하는 데서 나온다.
이 변화는 소프트웨어 개발 방식에도 영향을 준다. 과거에는 사용자가 애플리케이션의 버튼을 누르고 메뉴를 찾아가며 작업했다. 앞으로는 사용자가 목표를 말하면 여러 시스템에 흩어진 기능을 에이전트가 대신 호출하는 방식이 늘어난다. ERP, CRM, 협업 도구, 데이터 분석 도구는 여전히 존재하지만, 사용자는 모든 화면을 직접 오가지 않을 수 있다. AI가 업무 흐름의 앞단에서 사용자의 의도를 해석하고, 뒤에서는 여러 시스템을 연결해 실행하는 구조가 된다.
파일럿은 많은데 생산 전환은 어려운 이유
많은 기업이 생성형 AI 파일럿을 진행했다. 사내 챗봇, 문서 요약, 코드 보조, 상담 답변 추천, 마케팅 문구 생성 같은 실험은 빠르게 만들 수 있다. 그러나 파일럿이 실제 운영 시스템으로 넘어가는 순간 난이도는 급격히 올라간다. 데모에서는 그럴듯했는데, 현업에 넣어보면 오류가 나오고, 데이터 권한 문제가 생기고, 보안팀이 우려하고, 법무팀이 검토를 요구하고, 사용자는 기존 업무 방식과 맞지 않는다며 외면한다.
Deloitte는 생성형 AI를 사용하는 기업 중 2025년에 25%가 에이전트 AI 파일럿이나 개념검증을 시작하고, 2027년에는 그 비율이 50%로 늘어날 수 있다고 전망했다. 동시에 생성형 AI 파일럿 중 전체 생산 단계로 넘어가는 비율은 30%에 그친다고 지적한다4. 이 숫자가 말해주는 것은 분명하다. 기업은 AI 실험을 많이 하고 있지만, 실험을 운영으로 바꾸는 능력은 아직 부족하다.
왜 이런 일이 반복될까? 첫 번째 이유는 데이터다. 에이전트 AI는 말만 잘해서는 업무를 끝낼 수 없다. 정확한 고객 정보, 최신 제품 정책, 권한이 정리된 문서, 표준화된 업무 기록이 필요하다. 그런데 많은 기업의 데이터는 부서별로 흩어져 있고, 같은 고객도 시스템마다 다른 이름으로 저장되어 있으며, 최신 규정은 문서함 어딘가에 묻혀 있다. AI는 이런 혼란을 마법처럼 해결하지 못한다. 오히려 데이터가 엉망이면 더 빠르게 엉뚱한 결론에 도달할 수 있다.
두 번째 이유는 업무 프로세스다. 파일럿은 보통 기존 업무의 한 조각을 자동화한다. 예를 들어 상담 답변 초안을 AI가 써주는 식이다. 하지만 전체 고객 지원 업무는 답변 작성만으로 끝나지 않는다. 본인 확인, 주문 조회, 정책 판단, 예외 처리, 기록 저장, 후속 안내가 이어진다. 중간 단계가 연결되지 않으면 AI가 만든 초안은 사람의 복사와 붙여넣기 부담만 조금 줄일 뿐이다.
세 번째 이유는 책임과 통제다. 에이전트가 외부 시스템을 호출하고 실제 행동을 실행하면 위험도 커진다. 잘못된 고객에게 환불을 해주거나, 부정확한 법률 안내를 보내거나, 내부 기밀을 외부 도구로 전송할 수 있다. 따라서 운영 단계에서는 권한 관리, 로그 기록, 승인 절차, 모니터링, 예외 처리 체계가 필수다. 이것을 갖추지 않으면 AI는 편리한 도구가 아니라 통제하기 어려운 위험 요소가 된다.
네 번째 이유는 성과 측정의 착각이다. AI가 어떤 직원의 문서 작성 시간을 20% 줄였다고 해서 회사의 인건비가 곧바로 20% 줄어드는 것은 아니다. 남는 시간이 더 가치 있는 업무로 이동해야 하고, 병목이 되는 승인 단계나 데이터 정리 단계도 함께 개선되어야 한다. MIT Sloan은 에이전트 AI 구현에서 실제로 무거운 작업은 프롬프트 조정이 아니라 데이터 엔지니어링, 이해관계자 조율, 거버넌스, 업무 통합 같은 일이라고 설명한다5. 결국 AI 프로젝트의 성패는 모델 성능만이 아니라 조직 운영의 세부 설계에서 갈린다.
자동화가 아니라 업무 재설계가 필요하다
기업이 흔히 저지르는 실수는 에이전트 AI를 기존 업무에 덧붙이는 자동화 도구로만 보는 것이다. "지금 사람이 하던 일을 AI가 대신하게 하자"는 접근은 출발점으로는 자연스럽지만, 거기서 멈추면 큰 효과를 얻기 어렵다. 에이전트 AI의 진짜 가치는 기존 업무를 더 빠르게 반복하는 데만 있지 않다. 업무 자체를 다시 설계할 때 나타난다.
예를 들어 보고서 작성 업무를 생각해보자. 기존 방식은 담당자가 데이터를 모으고, 엑셀을 정리하고, 차트를 만들고, 문장을 쓰고, 상급자에게 검토받는 흐름이다. 단순 자동화 접근은 AI에게 보고서 초안을 쓰게 하는 데 그친다. 그러나 업무 재설계 접근은 다르다. 먼저 보고서가 왜 필요한지 묻는다. 의사결정에 필요한 핵심 지표는 무엇인가? 매번 반복되는 표와 문장은 무엇인가? 사람이 반드시 해석해야 하는 부분은 어디인가? 자동으로 갱신되어도 되는 부분은 어디인가?
이렇게 보면 보고서 업무는 "문서 작성"이 아니라 "의사결정 정보 전달"이라는 더 큰 목적을 가진다. 에이전트는 매주 데이터를 자동 수집하고, 이상치를 탐지하고, 이전 주와 달라진 점을 요약하고, 필요한 경우 담당자에게 질문을 보내며, 최종 보고서는 사람이 판단을 더해 승인하는 방식으로 바뀔 수 있다. 문서를 쓰는 속도보다 중요한 것은 의사결정까지 걸리는 시간을 줄이는 것이다.
고객 지원도 마찬가지다. 단순 자동화는 챗봇이 더 많은 문의에 답하게 만드는 것이다. 업무 재설계는 고객이 문의하기 전에 문제를 감지하고, 고객별 상황에 맞게 해결 경로를 제시하며, 반복 문의의 원인을 제품과 운영 프로세스에 피드백하는 구조를 만드는 것이다. 이 경우 에이전트는 상담원을 대체하는 존재라기보다 고객 경험을 둘러싼 여러 시스템을 연결하는 조정자가 된다.
업무 재설계를 위해서는 세 가지 질문이 필요하다.
이 업무의 최종 목적은 무엇인가?
AI가 맡으면 좋은 반복적·탐색적·연결형 작업은 무엇인가?
사람이 반드시 판단해야 하는 예외, 책임, 관계의 영역은 어디인가?
이 질문에 답하지 않고 AI를 붙이면 기존의 비효율이 더 빠른 속도로 반복될 뿐이다. 반대로 업무의 목적과 흐름을 다시 정의하면 에이전트 AI는 단순한 비용 절감 도구를 넘어 새로운 운영 모델의 출발점이 된다.
실제 업무에서 에이전트가 맡게 될 범위
에이전트 AI가 가장 먼저 자리 잡을 영역은 업무가 디지털 시스템 안에서 이루어지고, 결과를 비교적 명확히 검증할 수 있으며, 반복 빈도가 높은 곳이다. 모든 영역에서 완전 자동화가 일어나는 것은 아니지만, 사람과 AI의 역할 분담은 빠르게 바뀔 가능성이 크다.
코딩: 보조자를 넘어 작업 단위 수행자로
소프트웨어 개발은 생성형 AI의 효과가 가장 빨리 드러난 분야 중 하나다. 코드 자동완성, 테스트 코드 생성, 오류 설명, 리팩터링 제안은 이미 많은 개발자의 일상에 들어왔다. 에이전트 AI는 여기서 한 단계 더 나아간다. 개발자가 "이 기능을 추가해줘"라고 요청하면 에이전트는 관련 파일을 찾고, 코드를 수정하고, 테스트를 실행하고, 실패 원인을 분석하고, 풀 리퀘스트 초안을 작성할 수 있다.
물론 개발 에이전트가 전체 개발자를 대체한다는 뜻은 아니다. 실제 서비스 코드는 복잡한 요구사항, 보안, 성능, 기존 아키텍처, 사용자 경험을 함께 고려해야 한다. 에이전트가 만든 코드는 검토가 필요하고, 중요한 설계 결정은 여전히 사람이 내려야 한다. 하지만 작은 버그 수정, 테스트 보강, 문서 업데이트, 반복적인 마이그레이션 작업은 에이전트가 상당 부분 맡을 수 있다. 개발자는 모든 줄을 직접 쓰는 사람에서, 요구사항을 정의하고 품질을 검토하며 시스템 설계를 책임지는 사람으로 이동한다.
고객 지원: 답변 생성에서 문제 해결로
고객 지원에서 생성형 AI는 이미 상담 답변 초안 작성과 FAQ 응답에 활용되고 있다. 에이전트 AI는 여기서 고객의 문제를 실제로 해결하는 방향으로 확장된다. 고객이 "주문한 물건이 아직 오지 않았어요"라고 말하면 에이전트는 주문 번호를 확인하고, 배송 상태를 조회하고, 지연 사유를 파악하고, 보상 정책을 검토한 뒤, 고객에게 가능한 선택지를 제시할 수 있다.
중요한 것은 감정과 예외다. 고객이 화가 나 있거나, 고액 주문이거나, 법적 분쟁 가능성이 있거나, 정책상 애매한 상황이면 AI가 자동으로 마무리해서는 안 된다. 이때 에이전트의 좋은 역할은 사람 상담원에게 필요한 정보를 정리해 넘기는 것이다. 고객의 이력, 현재 상황, 가능한 해결책, 주의해야 할 표현을 요약해주면 상담원은 더 빠르고 정확하게 대응할 수 있다.
보고서 작성: 문서 생산에서 의사결정 지원으로
보고서 작성은 많은 조직에서 시간 소모가 큰 업무다. 에이전트는 정기 보고서의 데이터를 수집하고, 변동 요인을 찾고, 그래프를 만들고, 핵심 메시지를 초안으로 작성할 수 있다. 더 나아가 "이번 달 비용이 왜 늘었는가?" 같은 질문에 대해 회계 데이터, 구매 내역, 프로젝트 일정, 인력 투입 정보를 연결해 원인을 추적할 수 있다.
이 영역에서 사람의 역할은 숫자와 문장의 진위를 확인하고, 맥락을 해석하며, 조직의 전략적 판단을 더하는 것이다. AI가 "클라우드 비용이 18% 증가했다"고 말할 수는 있지만, 그것이 신제품 출시를 위한 의도된 투자였는지, 불필요한 리소스 낭비였는지는 사람이 비즈니스 맥락 속에서 판단해야 한다.
영업 운영: 리드 관리에서 다음 행동 추천까지
영업 조직에서는 고객 정보가 CRM, 이메일, 미팅 기록, 제안서, 계약 시스템에 흩어져 있다. 에이전트는 이 정보를 모아 고객별 상황을 정리하고, 다음 접촉 시점과 메시지를 추천하고, 제안서 초안을 만들며, 계약 갱신 위험을 감지할 수 있다.
예를 들어 어떤 고객이 최근 지원 문의를 많이 남겼고, 제품 사용량은 줄었으며, 계약 만료일이 다가오고 있다면 에이전트는 이를 갱신 위험 신호로 표시할 수 있다. 영업 담당자에게 "이 고객은 가격 협상보다 사용성 문제 해결이 우선일 가능성이 높다"는 식의 힌트를 줄 수도 있다. 영업은 관계와 신뢰가 중요한 영역이므로 사람이 고객과의 대화를 주도해야 하지만, 에이전트는 준비와 추적, 기록의 부담을 크게 줄여준다.
IT 운영: 장애 대응의 속도를 바꾸다
IT 운영에서는 로그, 모니터링 알림, 배포 이력, 인프라 상태, 보안 이벤트가 끊임없이 발생한다. 에이전트 AI는 이 많은 신호를 묶어 장애 원인을 추정하고, 과거 유사 사례를 찾고, 대응 절차를 제안하며, 승인된 범위 안에서 복구 작업을 실행할 수 있다.
예를 들어 서비스 응답 시간이 급격히 느려졌을 때 에이전트는 최근 배포 내역, 데이터베이스 쿼리 증가, 클라우드 리소스 사용량, 외부 API 지연 여부를 함께 확인할 수 있다. 단순히 "CPU 사용률이 높다"고 알려주는 것이 아니라 "30분 전 배포된 검색 기능 변경 이후 특정 쿼리의 응답 시간이 증가했고, 이로 인해 웹 서버 대기열이 늘었다"는 식으로 상황을 연결해준다. 운영자는 이 정보를 바탕으로 롤백, 스케일 아웃, 쿼리 제한 같은 조치를 더 빠르게 선택할 수 있다.
사람은 사라지는가, 아니면 역할이 바뀌는가
에이전트 AI 이야기가 나오면 자연스럽게 일자리 걱정이 따라온다. AI가 목표를 이해하고 실행까지 한다면 사람은 무엇을 해야 할까? 이 질문에 대한 답은 단순하지 않다. 일부 반복 업무는 줄어들 것이고, 특정 직무의 초급 업무는 AI에 의해 크게 바뀔 수 있다. 그러나 기업 운영에서 사람의 역할이 사라진다고 보기는 어렵다. 오히려 사람의 역할은 실행자에서 감독자, 설계자, 판단자로 이동한다.
생성형 AI 시대의 사람은 AI에게 좋은 입력을 주는 사용자였다. 에이전트 AI 시대의 사람은 AI가 움직일 수 있는 환경을 설계하고, 결과를 검토하며, 책임 있는 결정을 내리는 감독자가 된다. 이는 단순히 "AI를 감시한다"는 뜻이 아니다. 어떤 목표를 추구할지, 어떤 기준으로 성공을 판단할지, 어떤 위험은 감수할 수 없을지 정하는 역할이다.
예를 들어 인사팀에서 에이전트가 채용 후보자의 이력서를 요약하고 면접 일정을 조율할 수 있다. 하지만 어떤 인재를 뽑을지, 후보자의 잠재력을 어떻게 볼지, 조직 문화와의 적합성을 어떻게 판단할지는 사람이 맡아야 한다. 금융 서비스에서 에이전트가 대출 서류를 검토하고 위험 신호를 표시할 수 있다. 하지만 예외적인 고객 상황을 고려한 최종 판단과 규제 책임은 사람이 져야 한다.
MIT Sloan은 에이전트 AI가 디지털 환경에서 목표를 달성하기 위해 도구를 사용하고 거래나 상호작용까지 수행할 수 있다고 설명하면서도, 조직이 비즈니스 효과와 위험을 함께 평가하는 전략을 세워야 한다고 강조한다6. 에이전트 AI가 강력할수록 사람의 판단과 거버넌스는 더 중요해진다. 자율성이 커질수록 책임의 설계도 정교해야 하기 때문이다.
앞으로 조직은 "사람이 모든 일을 수행하는 구조"에서 "사람이 목표와 기준을 세우고 AI가 많은 실행을 담당하는 구조"로 이동한다. 이 변화는 관리 방식도 바꾼다. 관리자는 사람에게만 업무를 배분하는 것이 아니라, 사람과 AI 에이전트가 함께 일하는 흐름을 설계해야 한다. 직원은 AI를 경쟁자로만 볼 것이 아니라, 자신의 업무 범위를 넓혀주는 실행 파트너로 다루는 능력을 길러야 한다.
에이전트 AI를 도입할 때 반드시 정해야 할 것들
에이전트 AI 도입은 기술 프로젝트이면서 동시에 운영 모델 전환이다. 따라서 "어떤 모델을 쓸 것인가"보다 먼저 정해야 할 것이 있다. 바로 목표, 권한, 데이터, 검증, 책임이다.
먼저 목표가 명확해야 한다. "업무 효율화"는 너무 추상적이다. "고객 문의 1차 응답 시간을 50% 단축한다", "월간 보고서 작성에 들어가는 수작업 시간을 절반으로 줄인다", "장애 원인 분석 시간을 평균 20분 줄인다"처럼 측정 가능한 목표가 필요하다. 목표가 흐릿하면 에이전트는 그럴듯한 활동은 많이 하지만 실제 성과를 만들지 못한다.
다음은 권한이다. 에이전트가 정보를 조회만 할 수 있는지, 문서를 수정할 수 있는지, 고객에게 메시지를 보낼 수 있는지, 결제나 환불 같은 트랜잭션을 실행할 수 있는지 단계별로 나누어야 한다. 권한은 한 번에 넓게 주기보다 낮은 위험의 업무부터 시작해 점진적으로 확대하는 편이 안전하다.
데이터도 중요하다. 에이전트가 접근하는 문서가 최신인지, 고객 정보가 정확한지, 민감 정보가 적절히 보호되는지 확인해야 한다. 잘못된 지식베이스를 연결한 에이전트는 자신감 있게 틀린 답을 할 수 있다. 특히 사내 정책, 법률, 보안 지침처럼 오류의 비용이 큰 영역에서는 데이터 출처와 업데이트 주기를 관리해야 한다.
검증 체계도 필요하다. 에이전트가 만든 결과를 어떤 기준으로 평가할지, 실패했을 때 어떻게 되돌릴지, 사람이 언제 개입할지 정해야 한다. 로그를 남기고, 의사결정 경로를 추적하고, 반복 오류를 학습할 수 있는 구조가 있어야 한다. 에이전트가 "왜 이런 행동을 했는지" 설명할 수 없다면 운영 환경에서 신뢰를 얻기 어렵다.
마지막은 책임이다. AI가 실행했더라도 책임은 조직에 남는다. 따라서 에이전트의 행동을 승인한 사람, 운영 정책을 정한 부서, 데이터 품질을 관리한 팀, 보안 통제를 담당한 조직의 역할이 분명해야 한다. 에이전트 AI 시대의 거버넌스는 단순한 윤리 선언이 아니라 실제 업무 권한과 책임의 설계다.
작은 에이전트에서 시작해 업무 네트워크로 확장하라
에이전트 AI를 도입한다고 해서 처음부터 거대한 자율 시스템을 만들 필요는 없다. 오히려 실패 확률을 낮추려면 작고 구체적인 업무에서 시작하는 편이 좋다. 좋은 시작점은 반복적이고, 디지털 데이터가 충분하며, 성공 기준이 분명하고, 오류가 발생해도 되돌릴 수 있는 업무다.
예를 들어 "전사 지식 업무를 모두 자동화하겠다"는 목표는 너무 크다. 대신 "신규 입사자의 IT 계정 신청과 장비 요청 과정을 자동 안내한다"처럼 좁은 업무를 선택할 수 있다. 이 업무는 필요한 정보가 비교적 명확하고, 기존 시스템과 연결하기 쉽고, 예외 상황도 정의할 수 있다. 성공하면 비슷한 방식으로 휴가 신청, 비용 정산, 사내 문의, 계약 검토 보조 등으로 확장할 수 있다.
처음에는 조회와 추천 중심으로 시작하고, 다음 단계에서 초안 작성, 그다음 단계에서 제한적 실행, 마지막 단계에서 조건부 자동 실행으로 발전시키는 방식이 안전하다. 이 과정에서 사람의 개입 지점을 줄여가되, 완전히 없애는 것을 목표로 삼을 필요는 없다. 많은 업무에서 최적의 형태는 완전 자동화가 아니라 사람과 AI의 협업이다.
장기적으로는 여러 에이전트가 함께 일하는 구조가 등장한다. 고객 지원 에이전트가 고객 문제를 파악하면, 주문 에이전트가 배송 상태를 확인하고, 정책 에이전트가 보상 가능 여부를 검토하며, 메시지 에이전트가 고객에게 보낼 답변을 작성할 수 있다. 이때 전체 흐름을 조율하는 오케스트레이션이 중요해진다. 오케스트레이션은 여러 시스템과 에이전트가 충돌하지 않고 하나의 목표를 향해 움직이도록 순서를 정하고 조정하는 일이다. 이 주제는 뒤에서 초자동화와 AI 오케스트레이션을 다룰 때 다시 깊게 살펴볼 것이다.
에이전트 시대의 진짜 경쟁력
생성형 AI가 처음 등장했을 때 많은 사람은 AI가 얼마나 자연스럽게 글을 쓰는지에 놀랐다. 하지만 시간이 지나면서 더 중요한 질문이 나타났다. "이 AI가 우리 회사의 실제 성과를 바꾸는가?" 에이전트 AI는 이 질문에 대한 한 가지 답이다. AI가 답변을 생성하는 것을 넘어, 업무 흐름 속에서 목표를 달성하도록 만드는 것이다.
그러나 에이전트 AI의 성공은 모델의 성능만으로 결정되지 않는다. 오히려 기업의 기본기가 더 중요해진다. 데이터가 정리되어 있는가? 업무 프로세스가 명확한가? 시스템이 API로 연결되어 있는가? 권한과 책임이 설계되어 있는가? 사람이 AI의 결과를 검토하고 개선할 역량을 갖추었는가? 이런 질문에 답할 수 있는 조직이 에이전트 AI의 가치를 먼저 얻는다.
앞으로의 AI 경쟁력은 "누가 더 좋은 질문을 하는가"에서 "누가 AI가 일을 끝까지 수행할 수 있는 환경을 설계하는가"로 이동한다. 프롬프트는 여전히 중요하지만, 그것은 시작점일 뿐이다. 진짜 차이는 목표를 구조화하고, 데이터를 연결하고, 도구를 통합하고, 검증 체계를 만들고, 사람이 개입할 지점을 정하는 데서 생긴다.
에이전트 AI는 마법사가 아니다. 잘못 설계하면 빠르게 실수하는 시스템이 될 수 있다. 하지만 잘 설계하면 조직의 많은 지식 노동을 다시 배치하는 강력한 엔진이 된다. 사람이 모든 단계를 직접 수행하던 시대에서, 사람이 방향을 정하고 AI가 실행을 맡는 시대로의 전환. 이것이 생성형 AI 이후의 가장 중요한 변화다.
다음 장에서는 이러한 AI 애플리케이션을 실제 서비스로 만들기 위해 필요한 기술들을 살펴본다. 모델을 고르는 일만으로는 충분하지 않다. 검색 증강, 벡터 데이터베이스, 평가 체계, 배포와 모니터링, 보안과 비용 관리가 함께 맞물릴 때 비로소 AI는 실험실을 나와 제품과 서비스가 된다.
참고
1The future of generative AI: 10 trends to follow in 2026
3AI Agents: Evolution, Architecture, and Real-World Applications
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.