2026년 AI 혁명, Agentic AI와 LAM이 업무 자동화를 바꾸는 7가지 이유

AI에게 “보고서를 작성해줘”라고 요청했을 때, 과거에는 그럴듯한 초안을 받는 데서 끝났습니다. 사용자는 다시 자료를 찾고, 수치를 검증하고, 형식을 다듬고, 관계자에게 메일을 보내야 했습니다.

하지만 2026년의 기대치는 달라졌습니다. 이제 우리는 AI가 관련 문서와 시장 데이터를 검색하고, 필요한 정보를 정리하며, 보고서 초안을 작성한 뒤, 검토 요청 메일까지 전송하는 장면을 기대합니다. 핵심은 더 이상 무엇을 생성했는가가 아닙니다. 목표한 업무를 실제로 완료했는가입니다.

이 변화의 중심에는 에이전트형 AI(Agentic AI)와 Large Action Model(LAM)이라는 흐름이 있습니다. 기존 생성형 AI가 텍스트·이미지·코드 같은 콘텐츠를 만들어 내는 데 강했다면, 에이전트형 AI는 목표를 이해한 뒤 여러 단계의 작업을 계획하고 실행합니다.

예를 들어 월간 영업 보고서를 준비하는 업무를 생각해 볼 수 있습니다.

• CRM에서 이번 달 매출 데이터를 조회합니다.
• 전월·전년 동기 데이터와 비교합니다.
• 이상 수치나 주요 변동 요인을 찾아냅니다.
• 사내 문서와 시장 자료를 참조해 해석을 보완합니다.
• 보고서를 작성하고 담당자에게 검토를 요청합니다.
• 승인된 결과물을 지정된 채널에 배포합니다.

이 과정에서 AI의 산출물은 단순한 “보고서 문장”이 아닙니다. 데이터를 조회하고, 도구를 호출하며, 시스템 상태를 확인하고, 예외 상황에 대응하는 행동의 연속, 즉 워크플로우 자체입니다.

AI의 경쟁 기준은 생성 품질에서 실행 능력으로

전통적인 LLM 기반 서비스는 대체로 프롬프트 → 응답 구조로 작동합니다. 질문을 입력하면 답변을 받고, 초안 작성을 요청하면 결과물을 받습니다. 이 방식은 여전히 강력하지만, 사용자가 최종 실행자라는 점은 변하지 않습니다.

반면 에이전트형 AI는 다음과 같은 순환 구조를 지향합니다.

1. 이해: 사용자의 목표와 업무 맥락을 파악합니다.
2. 계획: 목표를 달성하기 위한 하위 작업으로 나눕니다.
3. 실행: API, 데이터베이스, 이메일, 협업 도구, 업무 시스템을 호출합니다.
4. 확인: 결과가 정상인지 검증하고 오류·누락을 찾습니다.
5. 재계획: 실패나 예외가 발생하면 다른 경로를 선택하거나 사람에게 승인을 요청합니다.

이때 LAM은 ‘행동’을 중심에 둔 모델·시스템 계열로 볼 수 있습니다. 언어를 이해하는 LLM이 “무엇을 해야 하는지” 파악한다면, LAM 관점의 AI는 “어떤 도구를 어떤 순서로 사용해 실제로 끝낼지”에 초점을 맞춥니다.

생성형 AI가 유능한 조언자라면, 에이전트형 AI는 권한과 절차 안에서 업무를 수행하는 디지털 동료에 가깝습니다.

AI가 일을 끝내려면 필요한 것들

물론 업무를 실제로 수행하는 AI는 모델 성능만으로 완성되지 않습니다. 신뢰할 수 있는 실행을 위해서는 여러 기술 계층이 함께 갖춰져야 합니다.

• 지식 연결: 사내 문서, 위키, 티켓, 데이터베이스에서 정확한 정보를 찾는 RAG 및 검색 체계
• 도구 연동: CRM, ERP, 메일, 캘린더, 코드 저장소, 협업 플랫폼과 연결되는 API 및 툴 인터페이스
• 메모리와 상태 관리: 이전 작업 내용, 현재 진행 단계, 사용자 선호와 승인 이력을 유지하는 기능
• 권한 통제: 최소 권한 원칙, 비밀키 관리, 승인 단계, 민감 작업 제한
• 관측과 감사: 무엇을 판단했고 어떤 도구를 호출했으며 결과가 어땠는지 기록하는 행동 로그

그래서 ‘자율적으로 행동하는 AI’는 단순히 더 똑똑한 챗봇을 뜻하지 않습니다. 모델, 데이터, 도구, 워크플로우, 보안 체계가 결합된 새로운 업무 자동화 구조를 의미합니다.

앞으로 AI 경쟁력은 답변의 자연스러움만으로 평가하기 어려워질 것입니다. 얼마나 정확하게 이해하는지, 어떤 권한 아래 안전하게 행동하는지, 그리고 무엇보다 사람의 개입을 최소화하면서 업무를 어디까지 완료하는지가 더 중요한 기준이 됩니다.

AI 시대, LLM과 LAM을 가르는 결정적 차이

같은 질문을 받은 두 AI가 있다고 가정해 보겠습니다.

“거래처에 이번 달 실적 보고서를 이메일로 보내줘.”

한쪽은 이렇게 답합니다.

“이메일 제목은 ‘3월 실적 보고서 전달드립니다’로 작성하고, 보고서를 첨부한 뒤 수신자에게 발송하세요.”

다른 한쪽은 다르게 움직입니다.

1. CRM에서 거래처 담당자와 이메일 주소를 확인합니다.
2. 분석 시스템에서 이번 달 실적 데이터를 조회합니다.
3. 보고서 파일을 생성하고 오류 여부를 점검합니다.
4. 발송 전 사용자 승인을 요청하거나, 사전 허용된 범위에서 이메일을 보냅니다.
5. 발송 결과를 기록하고 실패 시 재시도하거나 담당자에게 알립니다.

두 시스템의 차이는 단순히 말을 더 잘하느냐에 있지 않습니다. 핵심은 AI가 실제 업무를 수행할 수 있도록 설계된 권한, 도구, 실행 구조에 있습니다.

LLM은 답을 만들고, LAM은 일을 끝낸다

LLM(Large Language Model)은 언어를 이해하고 생성하는 데 강점을 둡니다. 질문에 답하고, 문서를 요약하며, 코드 초안을 작성하고, 복잡한 내용을 자연스러운 문장으로 정리합니다.

반면 LAM(Large Action Model)은 행동 중심의 AI 모델 또는 시스템 계열을 가리킵니다. 목표를 받으면 필요한 단계를 계획하고, 외부 도구와 시스템을 호출하며, 결과에 따라 다음 행동을 조정합니다.

구분	LLM	LAM
핵심 역할	언어 이해와 콘텐츠 생성	목표 달성을 위한 행동 계획·실행
주된 산출물	답변, 요약, 코드, 문서, 이미지 설명	실제 완료된 업무와 워크플로우 결과
기본 흐름	프롬프트 → 응답	목표 → 계획 → 도구 호출 → 결과 확인 → 재계획
외부 시스템 접근	선택적, 주로 정보 제공 중심	API·DB·메일·CRM·캘린더 등과 적극 연동
실패 대응	오류 내용을 설명	재시도, 대체 경로 탐색, 인간에게 에스컬레이션
대표 활용	문서 작성, 고객 응대, 검색 Q&A	티켓 처리, 보고서 발송, 일정 조정, 코드 수정·테스트

쉽게 말해 LLM이 유능한 조언자라면, LAM 기반 에이전트는 권한과 도구를 갖춘 업무 수행자에 가깝습니다.

결정적 차이는 ‘행동 루프’에 있다

LAM을 단순히 “API를 호출하는 LLM”으로 이해하면 부족합니다. 진짜 차이는 한 번의 호출이 아니라, 목표가 완료될 때까지 상황을 확인하고 다음 행동을 결정하는 행동 루프에 있습니다.

목표 수신
→ 현재 상태 파악
→ 작업 단계 계획
→ 도구 실행
→ 결과 검증
→ 실패 시 재계획 또는 승인 요청
→ 완료 기록

예를 들어 “고객 미팅 일정을 잡아줘”라는 요청을 처리할 때, LLM은 적절한 이메일 문구와 일정 조율 방법을 제안할 수 있습니다. 그러나 LAM 기반 AI는 다음과 같이 동작합니다.

• 고객 정보와 담당자 연락처를 조회합니다.
• 내부 참석자의 캘린더 빈 시간을 확인합니다.
• 가능한 후보 시간을 생성합니다.
• 고객에게 일정 제안 메일을 발송합니다.
• 회신이 오면 내용을 해석합니다.
• 합의된 시간을 캘린더에 등록합니다.
• 관련 회의 링크와 사전 자료를 참석자에게 전달합니다.

여기서 중요한 것은 AI가 단순히 문장을 생성하는 것이 아니라, 환경의 상태를 바꾸는 행동을 한다는 점입니다. 이메일이 실제로 발송되고, 캘린더에 일정이 등록되며, CRM 기록이 갱신됩니다.

LAM은 모델 하나가 아니라 실행 가능한 AI 구조다

현실의 LAM 또는 에이전트형 AI는 하나의 거대한 모델만으로 구성되지 않는 경우가 많습니다. 보통은 여러 계층이 결합된 시스템으로 구현됩니다.

• 이해 계층: 사용자의 자연어 요청, 이메일, 문서, 로그를 해석합니다.
• 계획 계층: 목표를 작은 작업으로 나누고 실행 순서를 정합니다.
• 도구 계층: 이메일, 데이터베이스, 사내 API, 코드 저장소, 브라우저 등을 연결합니다.
• 실행 계층: 정해진 권한 안에서 조회·작성·수정·전송 같은 행동을 수행합니다.
• 검증 계층: 작업 성공 여부, 예외 상황, 정책 위반 가능성을 확인합니다.
• 기억·관측 계층: 이전 작업 이력과 결과를 기록하고 다음 의사결정에 활용합니다.

따라서 LAM의 가치는 “더 긴 답변”이 아니라, AI가 여러 시스템을 오가며 복합 업무를 끝까지 처리하게 만드는 오케스트레이션 능력에서 나옵니다.

행동할 수 있다는 것은, 더 큰 책임을 뜻한다

LLM의 오류는 대체로 잘못된 답변이나 부정확한 요약으로 끝날 수 있습니다. 그러나 LAM은 실제 행동을 수행하기 때문에 오류의 영향도 커집니다.

잘못된 수신자에게 파일을 보내거나, 승인되지 않은 데이터를 수정하거나, 재고 수량을 잘못 변경하면 즉시 금전적·법적·보안상 문제가 발생할 수 있습니다. 그래서 기업 환경의 LAM은 성능만큼 다음 조건이 중요합니다.

• 최소 권한 원칙에 따른 접근 제어
• 고위험 작업 전 인간 승인(Human-in-the-Loop)
• 실행 이력과 근거를 남기는 감사 로그
• 금액·계약·개인정보 관련 정책 검증
• 실패 시 되돌릴 수 있는 롤백과 예외 처리

결국 LLM과 LAM의 경계는 매우 명확합니다. LLM이 무엇을 해야 하는지 말해주는 AI라면, LAM은 통제된 권한과 검증 체계 안에서 그 일을 실제로 수행하는 AI입니다. AI 경쟁의 다음 무대가 답변의 품질을 넘어 실행의 신뢰성으로 이동하는 이유도 바로 여기에 있습니다.

AI 에이전트의 두뇌를 해부하다: 지각·계획·행동·학습

에이전트에게 업무를 맡긴 순간, AI는 더 이상 한 번의 답변을 만드는 도구가 아닙니다. 작은 운영팀처럼 움직이기 시작합니다. 이메일을 읽고, 사내 지식을 검색하고, 업무를 단계로 나누고, 각 시스템에 명령을 내린 뒤 결과에 따라 계획을 다시 바꿉니다.

이 과정의 핵심은 단일 모델의 성능보다 지각·계획·행동·학습이 연결된 운영 구조에 있습니다. Agentic AI와 Large Action Model(LAM)은 이 네 가지 기능을 결합해 “질문에 답하는 AI”를 “목표를 수행하는 AI”로 확장합니다.

지각: AI가 업무 환경을 읽는 단계

에이전트는 먼저 자신이 처한 상황을 이해해야 합니다. 사용자의 자연어 요청만 읽는 것이 아니라 이메일, 채팅, CRM 기록, 데이터베이스 응답, 시스템 로그, 사내 문서 등 다양한 정보를 수집합니다.

예를 들어 사용자가 “이번 주 미처리 고객 문의를 정리하고 긴급 건은 담당자에게 배정해 줘”라고 요청했다고 가정해 보겠습니다. 에이전트는 다음과 같은 정보를 지각해야 합니다.

• 고객 문의 티켓의 상태와 생성 시점
• 고객 등급 및 계약 정보
• 기존 담당자와 업무 가능 시간
• 사내 SLA 기준과 긴급도 규칙
• 과거 유사 문의의 처리 이력

이 단계에서는 LLM과 RAG가 중요한 역할을 합니다. LLM은 자연어 요청의 의도와 조건을 해석하고, RAG는 사내 문서나 지식 저장소에서 업무 기준을 찾아옵니다. 멀티모달 환경이라면 화면, 이미지, PDF, 표 안의 정보까지 함께 읽어야 합니다.

다만 지각은 단순한 데이터 수집이 아닙니다. 에이전트는 수집한 정보 중 무엇이 현재 목표와 관련 있는지 판단하고, 부족한 정보가 있으면 추가 조회를 요청해야 합니다. 잘못된 지각은 이후 모든 판단을 흔드는 출발점이 됩니다.

계획: 목표를 실행 가능한 작업으로 쪼개는 단계

지각한 정보를 바탕으로 AI 에이전트는 목표를 작은 작업으로 분해합니다. 이것이 에이전트형 AI가 일반적인 챗봇과 가장 크게 달라지는 지점입니다.

일반 챗봇은 “미처리 고객 문의를 정리하는 방법”을 설명할 수 있습니다. 반면 에이전트는 실제 업무를 다음과 같이 계획합니다.

1. 티켓 시스템에서 미처리 문의를 조회한다.
2. SLA와 고객 등급을 기준으로 긴급도를 계산한다.
3. 중복 문의와 이미 해결된 문의를 제외한다.
4. 담당자의 전문 분야와 현재 업무량을 확인한다.
5. 긴급 건을 적합한 담당자에게 배정한다.
6. 배정 결과를 CRM과 팀 채널에 기록한다.
7. 예외 항목은 관리자 승인 대기 목록으로 보낸다.

이 과정은 흔히 플래닝(Planning) 또는 태스크 분해(Task Decomposition)라고 부릅니다. 복잡한 목표를 실행 가능한 단계로 바꾸고, 각 단계의 순서와 조건을 결정하는 것입니다.

좋은 계획은 단순히 작업 목록을 만드는 데 그치지 않습니다. 각 작업에 필요한 도구, 권한, 실패 시 대응 방식까지 포함해야 합니다. 예를 들어 담당자 배정 API가 실패하면 재시도할지, 관리자에게 알릴지, 다음 업무로 넘어갈지를 사전에 결정해야 합니다.

행동: LAM이 실제 시스템을 움직이는 단계

계획이 세워졌다면 이제 에이전트는 행동해야 합니다. 이 층이 바로 LAM이 주목받는 이유입니다. 결과물이 문장이나 이미지가 아니라 실제 시스템 안에서 발생한 변화이기 때문입니다.

에이전트의 행동은 다음과 같은 형태로 나타날 수 있습니다.

• 이메일 발송 및 답장 초안 생성
• 캘린더 일정 등록과 회의실 예약
• CRM 고객 정보 업데이트
• 데이터베이스 조회 또는 승인된 범위의 수정
• ERP·재고·인보이스 시스템 처리
• 코드 수정, 테스트 실행, PR 생성
• 티켓 생성, 담당자 배정, 상태 변경
• 사내 메신저 알림과 보고서 전송

이때 AI는 직접 모든 일을 처리하는 것이 아니라, API·워크플로우 엔진·RPA·브라우저 자동화 도구 등을 호출합니다. 즉, LAM은 “행동을 위한 손과 발”이라기보다 여러 도구를 적절한 순서로 조율하는 실행 오케스트레이터에 가깝습니다.

하지만 행동 권한은 반드시 통제되어야 합니다. 조회는 자동으로 수행하더라도, 결제·계약 변경·대외 발송처럼 위험도가 높은 작업은 사람의 승인을 거치도록 설계하는 것이 안전합니다. 이를 위해 최소 권한 원칙, 승인 게이트, 실행 로그, 취소 가능한 작업 구조가 필요합니다.

에이전트의 가치는 얼마나 많은 일을 자동화하느냐보다, 어떤 행동을 어떤 조건에서 안전하게 실행하느냐에 달려 있습니다.

학습과 피드백: 실패 후 계획을 수정하는 단계

현실의 업무 환경은 항상 계획대로 움직이지 않습니다. API가 오류를 반환할 수 있고, 필요한 문서가 누락될 수 있으며, 담당자가 휴가 중일 수도 있습니다. 에이전트가 단순 자동화 도구를 넘어서는 지점은 이런 예외를 감지하고 다음 행동을 조정하는 능력에 있습니다.

예를 들어 고객 문의를 담당자에게 배정하려 했지만 해당 담당자의 업무량이 이미 한도를 넘었다면, 에이전트는 다음 선택지를 검토할 수 있습니다.

• 같은 전문 분야의 다른 담당자를 찾는다.
• 긴급도가 낮은 업무를 재배정한다.
• 관리자에게 승인 요청을 보낸다.
• 고객에게 예상 응답 시간을 안내하는 메시지를 준비한다.

이러한 과정은 피드백 루프로 작동합니다. 행동 결과를 관찰하고, 성공 여부를 평가한 뒤, 필요하면 계획을 수정해 다시 실행합니다. 장기적으로는 성공률, 재시도 횟수, 처리 시간, 사용자 수정 비율, 예외 발생 빈도 같은 지표를 분석해 에이전트의 운영 품질을 개선할 수 있습니다.

다만 여기서 말하는 학습은 항상 모델 자체를 재훈련한다는 뜻은 아닙니다. 많은 엔터프라이즈 환경에서는 세션 메모리, 업무 규칙, 승인 이력, 프롬프트 개선, 도구 선택 정책 등을 조정하는 방식으로 성능을 높입니다. 민감한 업무일수록 무분별한 자동 학습보다 검증 가능한 피드백 체계가 더 중요합니다.

네 계층이 연결될 때, AI는 운영 시스템이 된다

지각·계획·행동·학습은 각각 따로 존재해서는 충분하지 않습니다. 사내 문서를 잘 검색해도 실행 권한이 없으면 업무는 끝나지 않습니다. 도구를 호출할 수 있어도 계획 능력이 부족하면 단순한 매크로에 머뭅니다. 행동 후 결과를 확인하지 않으면 작은 오류가 큰 사고로 번질 수 있습니다.

결국 에이전트형 AI의 구조는 다음과 같이 요약할 수 있습니다.

상황을 읽고 → 목표를 분해하고 → 도구로 실행하고 → 결과를 확인해 다시 판단하는 순환 구조

이 순환이 안정적으로 설계될수록 AI 에이전트는 단순한 생성 도구를 넘어, 실제 비즈니스 프로세스를 다루는 디지털 동료에 가까워집니다.

왜 지금인가: AI가 생성한 문서에서 업무를 끝내는 단계로

기업은 더 이상 AI가 문서를 잘 쓰는 것만으로 만족하지 않습니다. 진짜 질문은 “이 문서가 완성됐는가?”가 아니라 “이 문서 때문에 다음 업무까지 처리됐는가?”입니다.

예를 들어 AI가 고객 미팅 내용을 훌륭하게 요약했다고 해도, 담당자에게 후속 과제가 배정되지 않고 CRM이 업데이트되지 않으며 견적 요청이 생성되지 않는다면 업무의 상당 부분은 여전히 사람이 처리해야 합니다. 생성형 AI의 초기 성과가 ‘초안 작성 시간 단축’에 머물렀다면, 이제 기업은 업무 흐름 전체를 줄이는 ROI를 요구하고 있습니다.

바로 이 지점에서 LAM(Large Action Model)과 에이전트형 AI가 주목받습니다.

콘텐츠 생성의 ROI와 실행 자동화의 ROI는 다르다

기존 생성형 AI는 텍스트, 이미지, 코드, 요약 등 콘텐츠 생산에서 빠른 가치를 증명했습니다. 보고서 초안을 만들고, 고객 문의 답변을 작성하며, 개발자의 코드 작성 속도를 높이는 데 효과적이었습니다.

하지만 기업 환경에서 문서와 답변은 대개 업무의 끝이 아니라 시작입니다.

• 회의 요약 후에는 담당자별 할 일과 일정이 등록되어야 합니다.
• 고객 문의 답변 후에는 주문·환불·기술 지원 시스템이 업데이트되어야 합니다.
• 장애 분석 보고서 후에는 담당자 호출, 티켓 생성, 로그 조회, 복구 절차 실행이 이어져야 합니다.
• 코드 제안 후에는 테스트, 코드 리뷰, 배포 승인, 모니터링까지 연결되어야 합니다.

즉, 기업이 원하는 것은 “좋은 답변”이 아니라 완료된 결과입니다. AI가 단순히 문장을 생성하는 역할을 넘어, 목표를 이해하고 필요한 시스템을 호출하며 작업 완료까지 추적해야 하는 이유입니다.

생성형 AI가 지식 노동의 출발점을 바꿨다면, 에이전트형 AI는 지식 노동의 완료 기준을 바꾸고 있습니다.

성숙한 API와 RPA가 에이전트형 AI의 기반이 되다

에이전트형 AI가 갑자기 등장한 것처럼 보이지만, 실제 토대는 이미 오래전부터 마련돼 있었습니다. 기업은 CRM, ERP, 협업 도구, 클라우드, 데이터베이스, 티켓 시스템 등 수많은 업무 시스템을 API로 연결해 왔습니다. 반복 작업을 자동화하기 위한 RPA 역시 여러 산업에서 활용돼 왔습니다.

다만 기존 자동화에는 한계가 있었습니다.

구분	기존 RPA·워크플로우 자동화	에이전트형 AI·LAM
실행 방식	미리 정의된 규칙과 순서	목표에 따라 계획을 세우고 실행
입력 처리	정형 데이터와 고정된 화면 중심	자연어, 문서, 이메일, 로그, 이미지 등 처리
예외 대응	규칙 밖 상황에서 중단되기 쉬움	상황을 해석하고 재시도·대안 탐색 가능
자동화 범위	반복적이고 예측 가능한 업무	복수 시스템을 넘나드는 복합 업무
핵심 가치	작업 반복 감소	의사결정 보조와 업무 완료율 향상

LAM과 에이전트형 AI는 RPA나 API를 대체하는 기술이라기보다, 이들을 실행 도구로 통합하는 상위 오케스트레이션 계층에 가깝습니다. 사람의 자연어 지시를 업무 목표로 해석하고, 필요한 도구를 선택하며, 결과를 확인한 뒤 다음 행동을 결정합니다.

예컨대 “이번 주 이탈 위험 고객을 찾아 대응해 달라”는 요청을 받으면 에이전트는 다음과 같은 흐름을 수행할 수 있습니다.

1. CRM과 사용 로그에서 대상 고객을 조회합니다.
2. 이탈 위험도와 최근 문의 이력을 분석합니다.
3. 고객별 대응 우선순위와 제안 내용을 만듭니다.
4. 담당 영업팀에 과제를 배정합니다.
5. 필요한 경우 고객에게 안내 메일 초안을 생성합니다.
6. 실행 결과를 CRM에 기록하고 관리자에게 보고합니다.

이 과정에서 AI의 산출물은 단순 보고서가 아닙니다. 분석, 판단, 시스템 업데이트, 업무 배정, 후속 조치가 연결된 실행 결과입니다.

LAM이 주목받는 이유: ‘도구 사용’이 아니라 ‘업무 조율’

LLM이 언어를 이해하고 생성하는 엔진이라면, LAM은 행동을 설계하고 실행하는 관점에 더 가깝습니다. 핵심은 단순한 API 호출 횟수가 아닙니다. 여러 도구의 사용 순서를 결정하고, 중간 결과를 검증하며, 실패했을 때 계획을 수정하는 능력입니다.

에이전트형 AI의 일반적인 실행 흐름은 다음과 같습니다.

• 의도 파악: 사용자의 요청을 목표와 제약 조건으로 해석합니다.
• 계획 수립: 목표를 하위 작업으로 나누고 실행 순서를 정합니다.
• 도구 호출: API, 데이터베이스, 브라우저, 코드 실행 환경, 사내 시스템을 활용합니다.
• 상태 관찰: 작업 성공 여부와 예외 상황을 확인합니다.
• 재계획: 정보가 부족하거나 실행이 실패하면 대안을 찾거나 사람에게 승인을 요청합니다.
• 기록과 보고: 실행 로그와 결과를 남겨 감사·검토·개선에 활용합니다.

이 구조는 “프롬프트를 입력하면 답을 받는” 방식과 본질적으로 다릅니다. AI가 업무 시스템 안에서 행동하려면 모델 성능뿐 아니라 권한 관리, 도구 인터페이스, 상태 관리, 관측성, 승인 절차까지 함께 설계해야 합니다.

기업이 기대하는 다음 ROI는 ‘시간 절감’보다 ‘리드타임 단축’

생성형 AI의 ROI는 주로 개인 생산성 관점에서 측정됐습니다. 문서 작성 시간이 줄었는지, 고객 답변 속도가 빨라졌는지, 코드 초안 생성이 쉬워졌는지 등이 대표적인 지표였습니다.

반면 에이전트형 AI의 ROI는 프로세스 관점에서 측정됩니다.

• 고객 요청부터 처리 완료까지 걸리는 시간
• 티켓 생성 후 해결까지의 리드타임
• 반복 업무의 자동 처리 비율
• 사람의 개입이 필요한 예외 건수
• 업무 재작업률과 오류율
• 승인 대기와 시스템 간 전달 과정에서 발생하는 지연

이 차이는 중요합니다. 개인이 문서를 30% 빠르게 작성해도 업무 프로세스 전체가 그대로라면 기업의 체감 성과는 제한적일 수 있습니다. 반대로 AI가 정보 수집부터 시스템 반영, 담당자 알림, 결과 보고까지 연결하면 여러 부서와 도구 사이에서 발생하던 대기 시간이 크게 줄어듭니다.

따라서 지금의 관심은 “더 똑똑한 챗봇”이 아니라, 업무의 병목을 실제로 제거하는 실행형 AI로 이동하고 있습니다.

자동화 확대만큼 중요한 것은 통제 설계다

실행 권한을 가진 AI는 높은 생산성을 만들 수 있지만, 잘못된 행동의 비용도 커집니다. 이메일 초안의 오류는 수정하면 되지만, 잘못된 환불 처리나 계약 변경, 데이터 삭제는 금전적·법적 문제로 이어질 수 있습니다.

그래서 기업 도입에서는 자율성의 수준을 업무 위험도에 맞춰 구분해야 합니다.

• 낮은 위험 업무: 정보 검색, 문서 분류, 초안 작성, 알림 발송
• 중간 위험 업무: 티켓 생성, 일정 조정, CRM 정보 업데이트
• 높은 위험 업무: 결제 처리, 계약 변경, 개인정보 조회·삭제, 외부 시스템 변경

특히 높은 위험 업무에는 최소 권한 원칙, 실행 전 승인, 세부 행동 로그, 롤백 절차, 이상 행동 탐지가 필수입니다. 에이전트형 AI의 경쟁력은 무조건 많은 일을 자동으로 처리하는 데 있지 않습니다. 필요한 곳에서는 자율적으로 움직이고, 중요한 순간에는 안전하게 멈추는 능력에 있습니다.

결국 LAM과 에이전트형 AI가 부상한 이유는 분명합니다. 기업은 이제 AI에게 “무엇을 써 달라”고만 요청하지 않습니다. “이 일을 끝내 달라”고 요청하기 시작했습니다.

AI 에이전트, 스스로 행동하는 AI를 어디까지 믿을 것인가

AI가 잘못된 답변을 하면 사용자가 내용을 다시 확인하고 고치면 됩니다. 그러나 AI 에이전트가 잘못된 계좌로 송금하거나, 운영 데이터베이스를 삭제하거나, 검증되지 않은 코드를 배포한다면 문제는 단순한 오류로 끝나지 않습니다. 실제 비용, 고객 신뢰, 법적 책임으로 이어질 수 있습니다.

그래서 에이전트형 AI의 핵심 경쟁력은 “얼마나 많은 일을 혼자 할 수 있는가”가 아닙니다. 얼마나 안전하게 행동하고, 필요할 때 멈추며, 모든 과정을 설명할 수 있는가에 달려 있습니다.

답변 오류와 행동 오류는 다르다

기존 생성형 AI의 실패는 대체로 정보 품질 문제였습니다. 사실과 다른 답변, 부정확한 요약, 잘못된 코드 제안이 대표적입니다. 물론 심각할 수 있지만, 대개 사용자가 최종 결과를 검토한 뒤 수정할 여지가 있습니다.

반면 행동 중심 AI는 외부 시스템에 직접 영향을 줍니다.

• CRM의 고객 정보를 수정한다.
• 전자결재를 상신하거나 승인한다.
• 클라우드 인프라 설정을 변경한다.
• 주문을 취소하거나 환불을 처리한다.
• 소스 코드를 배포하고 데이터 삭제 작업을 실행한다.

이 환경에서 오류는 “틀린 문장”이 아니라 되돌리기 어려운 사건이 됩니다. 따라서 자율성을 높일수록 모델 성능만큼이나 권한, 승인, 기록, 복구 체계를 함께 강화해야 합니다.

통제 가능한 자율성을 설계하는 핵심 원칙

에이전트에게 모든 권한을 한 번에 부여하는 방식은 위험합니다. 안전한 도입은 업무의 위험도에 따라 AI의 행동 범위를 단계적으로 나누는 데서 시작합니다.

자율성 단계	AI의 역할	권장 통제 방식
제안	분석, 요약, 실행안 작성	사람이 결과 검토
초안 실행	티켓 생성, 이메일 초안, 보고서 작성	사용자 최종 승인
제한적 실행	정해진 조건의 데이터 조회·업데이트	권한 범위 및 정책 제한
고위험 실행	송금, 삭제, 배포, 계약 처리	다중 승인, 실시간 모니터링, 롤백 필수

핵심은 단순합니다. 읽기 권한은 넓게, 쓰기 권한은 좁게, 되돌릴 수 없는 행동은 엄격하게 설계해야 합니다.

반드시 갖춰야 할 안전장치

에이전트형 AI를 업무 시스템에 연결한다면 다음 장치는 선택이 아니라 기본 요건에 가깝습니다.

• 최소 권한 원칙
  AI 에이전트에는 업무 수행에 필요한 최소한의 권한만 부여해야 합니다. 예를 들어 고객 정보를 조회하는 에이전트가 결제 취소 권한까지 가질 필요는 없습니다.

• 휴먼 인 더 루프(Human-in-the-Loop)
  송금, 계약 승인, 대량 삭제, 운영 배포처럼 영향이 큰 작업은 사람이 마지막 승인 버튼을 누르도록 설계해야 합니다. AI는 실행자가 아니라 판단 보조자 역할을 맡을 수 있습니다.

• 정책 기반 가드레일
  “10만 원 이상 환불은 승인 필요”, “운영 DB 삭제 명령은 차단”, “허용된 리포지토리에만 배포 가능”처럼 명시적인 정책을 시스템 수준에서 적용해야 합니다. 자연어 지시만으로 안전을 보장할 수는 없습니다.

• 행동 로그와 감사 추적성
  AI가 어떤 정보를 읽었고, 어떤 계획을 세웠으며, 어떤 도구를 호출했는지 기록해야 합니다. 사고가 발생했을 때 원인을 분석하고 책임 범위를 판단하려면 변경 불가능한 감사 로그가 필요합니다.

• 롤백과 킬 스위치
  잘못된 배포를 되돌리고, 비정상 행동을 즉시 중단하며, 필요한 경우 에이전트의 모든 외부 연결을 차단할 수 있어야 합니다. 자율 실행 시스템일수록 ‘멈춤’과 ‘복구’ 기능이 중요합니다.

평가 기준도 달라져야 한다

에이전트형 AI를 평가할 때는 단순히 답변 정확도만 보면 부족합니다. 실제 업무에서는 다음과 같은 지표가 더 중요해집니다.

• 작업을 끝까지 완료한 비율
• 잘못된 도구 호출이나 정책 위반 발생률
• 예외 상황에서 사람에게 적절히 이관한 비율
• 재시도 횟수와 처리 시간
• 실행 결과의 복구 가능성
• 사용자 승인 이후의 오류율

즉, 좋은 AI 에이전트란 가장 과감하게 행동하는 시스템이 아닙니다. 불확실할 때 멈추고, 위험할 때 승인받고, 실패했을 때 복구할 수 있는 시스템입니다.

에이전트형 AI 시대의 질문은 “AI에게 일을 맡길 수 있는가”가 아닙니다. 더 중요한 질문은 이것입니다. 이 AI가 행동하는 모든 순간을 조직이 통제하고 설명하며 되돌릴 수 있는가.