Agentic AI와 LAM이 바꾸는 AI 에이전트의 시대, 무엇이 달라질까?

지금까지 AI의 역할은 주로 답변을 만드는 일에 머물렀습니다. 회의록을 요약하고, 보고서 초안을 작성하고, 이미지를 생성하며, 코드를 제안하는 방식입니다. 사람이 그 결과를 확인한 뒤 복사하고, 시스템에 입력하고, 승인 요청을 올리는 마지막 단계는 직접 처리해야 했습니다.

하지만 이제 AI는 답변을 넘어 업무를 실행하는 주체로 진화하고 있습니다.

예를 들어 사용자가 “이번 달 매출 변동 원인을 분석하고 보고해줘”라고 요청하면, 새로운 AI 에이전트는 단순히 분석 방법을 설명하지 않습니다. ERP에서 매출·비용 데이터를 조회하고, 전월 대비 이상치를 탐지하며, 관련 부서 데이터를 추가로 확인합니다. 이후 보고서를 작성하고, 담당자에게 검토 요청을 보내거나 승인 워크플로까지 생성할 수 있습니다.

AI의 다음 경쟁은 더 그럴듯한 문장을 만드는 능력이 아니라, 더 안전하고 정확하게 실제 일을 끝내는 능력에서 시작됩니다.

AI가 생성에서 실행으로 이동하는 이유

생성형 AI의 초기 경쟁은 명확했습니다. 누가 더 자연스러운 글을 쓰는지, 더 사실적인 이미지를 만드는지, 더 빠르게 코드를 생성하는지가 핵심이었습니다. 그러나 기업 현장에서 진짜 비용과 시간이 발생하는 곳은 콘텐츠 생성 자체보다 그 이후의 반복 업무입니다.

문서를 읽고 핵심 정보를 추출하는 일, 여러 시스템에서 데이터를 확인하는 일, 이메일을 보내고 티켓을 생성하는 일, 결재를 요청하고 결과를 기록하는 일은 대부분 사람이 연결해 왔습니다.

이 지점에서 Agentic AI가 등장합니다. Agentic AI는 언어 모델에 도구 호출, 메모리, 계획 수립, 외부 시스템 연동 기능을 결합한 구조입니다. 즉, AI가 사용자의 목표를 이해한 뒤 필요한 작업을 순서대로 계획하고 실행하도록 만드는 방식입니다.

기존 챗봇이 “ERP에서 매출 데이터를 조회하세요”라고 안내했다면, 에이전트형 AI는 권한 범위 안에서 ERP에 접속해 실제 데이터를 조회하고 다음 단계로 넘어갑니다.

AI 에이전트는 무엇을 다르게 하는가

AI 에이전트의 핵심은 단순한 대화가 아니라 목표 기반의 행동 루프입니다. 일반적으로 다음과 같은 흐름으로 작동합니다.

1. 상황 이해
   사용자의 요청, 사내 문서, 데이터베이스, 화면 정보, 이메일 등 다양한 정보를 읽습니다. 텍스트뿐 아니라 문서 이미지와 표를 이해하는 비전 언어 모델도 활용할 수 있습니다.

2. 계획 수립
   목표를 달성하기 위해 필요한 일을 작은 단계로 나눕니다. 예를 들어 “정산 보고서 작성”은 데이터 조회, 누락 항목 확인, 이상치 분석, 보고서 작성, 승인 요청이라는 작업으로 분해됩니다.

3. 도구와 시스템 호출
   API를 호출하거나, 데이터베이스를 조회하거나, 사내 SaaS와 연동합니다. 경우에 따라서는 브라우저나 애플리케이션 UI를 조작해 사람이 하던 화면 기반 업무를 수행합니다.

4. 결과 검증과 다음 행동 결정
   실행 결과가 예상과 다르면 원인을 확인하고 다른 경로를 선택합니다. 데이터가 부족하면 추가 자료를 요청하거나, 정책상 위험한 단계라면 사람에게 승인받도록 전환할 수 있습니다.

이 구조에서 AI는 더 이상 “잘 말하는 비서”가 아닙니다. 정해진 권한, 규칙, 감사 기록 안에서 업무 흐름을 실제로 움직이는 디지털 실행자에 가까워집니다.

LAM, 행동을 설계하는 AI 모델의 등장

이 흐름을 설명하는 개념 중 하나가 LAM(Large Action Model)입니다. LLM이 언어를 이해하고 생성하는 데 강점이 있다면, LAM은 소프트웨어를 조작하고 API와 상호작용하며 업무 프로세스를 실행하는 데 초점을 둡니다.

쉽게 말하면 LLM은 “무엇을 해야 하는지”를 판단하고 설명하는 두뇌라면, LAM은 그 판단을 실제 클릭·호출·입력·승인 요청으로 옮기는 실행 계층입니다.

LAM 기반 AI는 다음과 같은 업무에 활용될 수 있습니다.

• ERP·CRM·그룹웨어에서 필요한 데이터 조회
• 고객 문의를 분류하고 티켓 자동 생성
• 인보이스와 계약서를 읽어 핵심 항목 추출
• 재고 이상 징후를 감지하고 담당자에게 알림 발송
• 코드 저장소를 분석해 수정 사항 반영 및 테스트 실행
• 회의 일정 생성, 메일 초안 작성, 결재선 등록
• 여러 시스템을 오가며 하나의 업무를 엔드투엔드로 처리

특히 기업 환경에서는 기존 RPA와의 결합이 중요합니다. 규칙 기반 RPA가 정해진 화면과 절차를 반복하는 데 강했다면, AI 에이전트는 자연어 요청과 비정형 문서를 이해해 더 유연하게 예외 상황에 대응할 수 있습니다. 이는 단순 자동화에서 지능형 업무 오케스트레이션으로의 이동을 의미합니다.

진짜 경쟁력은 실행의 범위가 아니라 통제력

다만 AI가 직접 행동하기 시작할수록 중요한 것은 “얼마나 많은 일을 할 수 있는가”만이 아닙니다. 더 중요한 질문은 어디까지 스스로 실행하도록 허용할 것인가입니다.

보고서 초안 작성처럼 되돌리기 쉬운 업무는 자동화 범위를 넓힐 수 있습니다. 반면 결제, 계약 변경, 고객 데이터 수정, 운영 환경 배포처럼 영향이 큰 작업에는 사람의 승인과 명확한 권한 관리가 필요합니다.

따라서 좋은 AI 에이전트는 무조건 많은 권한을 가진 시스템이 아닙니다. 다음 원칙을 갖춘 시스템에 가깝습니다.

• 작업별 권한 범위를 세밀하게 제한한다.
• 실행 전·후의 로그를 남겨 추적 가능하게 한다.
• 중요한 행동에는 승인 단계를 둔다.
• 오류나 불확실성이 발생하면 사람에게 즉시 넘긴다.
• 잘못된 실행을 취소하거나 복구할 수 있게 설계한다.

생성형 AI 시대의 핵심 질문이 “이 AI는 무엇을 만들어낼 수 있는가”였다면, 에이전트 시대의 질문은 달라집니다. “이 AI는 어떤 조건에서, 어떤 시스템에, 누구의 책임 아래 행동할 수 있는가”가 새로운 기준이 됩니다.

AI가 답변을 멈추고 일을 시작한 순간, 기술의 무게중심도 콘텐츠 생성에서 실행 설계로 옮겨가고 있습니다.

AI, LLM과 LAM 사이에는 무엇이 있는가

“회의 일정을 잡아줘.”

이 한 문장을 받았을 때 LLM은 보통 이렇게 답할 수 있습니다.
“참석 가능 시간을 확인한 뒤, 캘린더에서 빈 시간을 찾고 초대 메일을 보내세요.”

하지만 실제 업무에서는 설명만으로 일이 끝나지 않습니다. 누군가는 참석자들의 캘린더를 조회하고, 시간대와 우선순위를 비교하고, 가능한 후보 시간을 제안해야 합니다. 이어 참석자에게 초대 메일을 보내고, 응답을 반영해 최종 시간을 확정한 뒤 캘린더에 일정을 등록해야 합니다.

이 과정을 실제로 수행하는 것이 AI 에이전트이며, 그 실행 계층을 강조한 개념이 LAM(Large Action Model) 입니다.

LLM은 언어를 이해하고, LAM은 업무를 움직인다

LLM은 자연어를 이해하고 생성하는 데 뛰어납니다. 사용자의 요청을 해석하고, 필요한 절차를 설명하며, 메일 문구나 회의 안건을 작성할 수 있습니다. 그러나 일반적인 LLM 자체는 외부 시스템에 접속해 행동하지 않습니다.

반면 LAM 또는 Agentic AI는 LLM의 언어 능력을 출발점으로 삼아 실제 도구와 연결합니다.

구분	LLM	LAM·AI 에이전트
핵심 역할	이해, 생성, 요약, 질의응답	계획, 도구 호출, 실행, 검증
회의 일정 요청	일정 조율 방법을 설명	캘린더 조회부터 초대 발송, 등록까지 수행
외부 시스템 접근	기본적으로 제한적	API, SaaS, 사내 시스템, UI와 연동
작업 방식	단일 응답 중심	여러 단계를 반복하며 목표 달성
결과물	텍스트·코드·문서	완료된 업무와 변경된 시스템 상태

핵심은 모델 크기의 차이만이 아닙니다. 추론 결과를 실행 가능한 행동으로 변환하는 구조가 있느냐가 결정적입니다.

계획과 행동을 연결하는 AI 에이전트 구조

에이전트는 보통 다음과 같은 순환 구조로 동작합니다.

1. 목표 이해
   LLM이 “회의 일정을 잡아줘”라는 요청에서 참석자, 회의 목적, 희망 기간, 예상 시간 같은 조건을 파악합니다.

2. 계획 수립
   에이전트는 필요한 작업을 세분화합니다.
   예를 들어 참석자 확인 → 캘린더 조회 → 후보 시간 생성 → 메일 발송 → 응답 수집 → 일정 등록과 같은 실행 계획을 만듭니다.

3. 도구 선택 및 호출
   계획에 따라 캘린더 API, 이메일 API, 사내 주소록, 화상회의 솔루션, CRM 또는 협업 도구를 호출합니다.
   이 단계에서 LAM은 “어떤 도구를 어떤 순서로 써야 하는가”를 실행 관점에서 판단합니다.

4. 결과 관찰과 재계획
   모든 참석자의 시간이 맞지 않거나, 특정 참석자가 휴가 중이라면 최초 계획은 실패할 수 있습니다. 에이전트는 결과를 읽고 새로운 후보 시간을 찾거나, 사용자에게 우선순위 판단을 요청합니다.

5. 최종 실행과 기록
   일정이 확정되면 캘린더 이벤트를 생성하고 초대장을 발송합니다. 동시에 실행 내역, 승인 기록, 오류 로그를 남겨 추후 검토가 가능하도록 합니다.

이 흐름은 단순한 챗봇 응답과 다릅니다. 에이전트는 생각하고, 행동하고, 결과를 확인한 뒤 다시 행동하는 폐쇄 루프를 가집니다.

LLM과 LAM 사이를 채우는 핵심 구성 요소

LLM이 곧바로 업무 자동화 시스템이 되는 것은 아닙니다. 실제 Agentic AI에는 언어 모델과 행동 모델 사이를 연결하는 여러 계층이 필요합니다.

• 플래너(Planner)
  큰 목표를 작은 작업으로 나누고, 실행 순서와 조건을 설계합니다.

• 툴 러너(Tool Runner)
  API 호출, 데이터베이스 조회, 파일 처리, 브라우저 조작, 사내 시스템 접근 등을 담당합니다.

• 메모리와 지식 검색
  과거 대화, 사용자 선호, 사내 규정, 프로젝트 문서를 기억하거나 RAG 기반으로 검색합니다.
  예를 들어 “임원 회의는 최소 30분, 화요일 오후 우선” 같은 조직 규칙을 반영할 수 있습니다.

• 검증기(Validator)
  잘못된 수신자에게 메일을 보내거나, 중복 일정을 등록하거나, 권한 없는 데이터를 수정하는 문제를 방지합니다.

• 승인 워크플로
  비용 집행, 계약 변경, 고객 안내처럼 영향이 큰 작업에서는 인간의 최종 승인을 거치도록 설계합니다.

즉, AI 에이전트의 경쟁력은 LLM의 답변 품질만으로 결정되지 않습니다. 계획 정확도, 도구 연결성, 데이터 접근 권한, 오류 복구, 승인 체계가 함께 갖춰져야 합니다.

실행형 AI에서 중요한 것은 ‘자율성의 범위’다

에이전트가 모든 일을 완전히 자동으로 처리해야 하는 것은 아닙니다. 오히려 실무에서는 업무 위험도에 따라 자율성 수준을 나누는 편이 안전합니다.

• 보조형: 일정 후보와 메일 초안만 만들고 사용자가 직접 발송
• 반자동형: 캘린더 조회와 초대장 작성은 AI가 수행, 최종 등록은 사용자 승인
• 자율 실행형: 사전에 정의된 조건 안에서 일정 조율과 등록까지 자동 처리
• 고위험 제한형: 금전, 인사, 법무, 고객 계약 관련 작업은 반드시 승인 절차 적용

따라서 LAM의 본질은 무조건적인 자동화가 아닙니다. 조직의 규칙과 권한 체계 안에서, AI가 어디까지 판단하고 어디서 사람에게 넘길지를 정교하게 설계하는 데 있습니다.

LLM이 업무의 언어를 이해하는 두뇌라면, LAM과 AI 에이전트는 그 두뇌에 손발과 작업 절차를 부여하는 구조입니다. 이제 기업의 경쟁력은 “AI가 얼마나 잘 말하는가”를 넘어, “AI가 얼마나 안전하고 정확하게 일을 끝내는가”로 이동하고 있습니다.

AI 에이전트의 두뇌를 해부하다: 인지부터 행동까지

AI 에이전트가 복잡한 업무를 처리하는 모습은 마치 하나의 거대한 모델이 모든 일을 해내는 것처럼 보입니다. 하지만 실제 내부 구조는 훨씬 정교합니다. 에이전트는 보고(인지), 생각하고 계획하며(추론), 기억을 꺼내고(지식·메모리), 도구를 사용해 행동하는(실행) 여러 레이어가 맞물린 시스템입니다.

이 중 어느 한 부분이라도 흔들리면 결과는 달라집니다. 문서를 제대로 읽지 못하면 잘못된 판단을 내리고, 사내 지식을 찾지 못하면 그럴듯한 일반론만 답합니다. 계획이 부실하면 불필요한 도구를 반복 호출하고, 실행 계층이 불안정하면 최종적으로는 “할 수 있다”는 답변만 남긴 채 실제 업무 처리에는 실패합니다.

좋은 AI 에이전트의 기준은 답변의 문장력이 아니라, 목표를 안전하고 정확하게 끝까지 수행하는 능력입니다.

AI 인지 레이어: 문서·화면·데이터를 읽는 감각 기관

인지 레이어는 에이전트가 외부 세계를 받아들이는 출발점입니다. 사람에게 눈과 귀가 있다면, AI 에이전트에는 언어 모델과 멀티모달 모델, 데이터 커넥터가 있습니다.

핵심 구성 요소는 다음과 같습니다.

• LLM(Large Language Model)
  이메일, 대화, 정책 문서, 업무 요청처럼 자연어로 된 정보를 이해합니다. 사용자의 의도를 파악하고, 긴 문서를 요약하며, 다음 행동에 필요한 정보를 추출합니다.

• VLM(Vision Language Model)
  PDF 레이아웃, 영수증, 계약서 스캔본, 대시보드 화면, 제조 이미지처럼 시각 정보가 포함된 데이터를 해석합니다. 단순 OCR을 넘어 표의 구조, 차트의 의미, 이미지 속 이상 징후까지 이해하는 역할을 맡습니다.

• 기업 시스템 커넥터
  ERP, CRM, 그룹웨어, 데이터베이스, 사내 위키, 메일, 메신저 등과 연결돼 최신 업무 데이터를 가져옵니다. 에이전트가 현실과 단절되지 않으려면 이 연결 계층이 반드시 필요합니다.

예를 들어 “이번 달 매출 변동 원인을 분석해 주세요”라는 요청을 받았다고 가정해 보겠습니다. 인지 레이어는 먼저 사용자의 질문을 해석하고, ERP에서 매출 데이터를 조회하며, 관련 보고서와 회의록을 검색합니다. 이 단계에서 데이터 범위를 잘못 읽거나 문서의 기준일을 놓치면 이후의 모든 판단이 어긋날 수 있습니다.

AI 추론·계획 레이어: 해야 할 일을 작업 단위로 쪼개다

인지가 정보를 받아들이는 과정이라면, 추론·계획 레이어는 그 정보를 바탕으로 무엇을 어떤 순서로 할지 결정하는 두뇌입니다.

에이전트는 단순히 “매출이 감소했습니다”라고 답하는 데서 멈추지 않습니다. 목표를 달성하기 위해 작업을 여러 단계로 분해합니다.

예를 들면 다음과 같은 계획이 만들어질 수 있습니다.

1. 이번 달과 지난달의 매출 데이터를 비교한다.
2. 제품군·지역·고객군별 감소 폭을 분석한다.
3. 재고 부족, 프로모션 종료, 주요 고객 이탈 여부를 확인한다.
4. 관련 회의록과 영업 메모를 검색한다.
5. 원인 후보와 근거를 정리한다.
6. 담당자 검토용 보고서와 후속 조치안을 생성한다.

이 과정에서 LLM은 언어 기반 추론을 담당하고, LCM(Large Concept Model)처럼 고수준 개념 관계와 계획 수립에 초점을 둔 모델 또는 플래너가 보조 역할을 할 수 있습니다. 실제 제품에서는 하나의 독립 모델이라기보다, 프롬프트 전략·워크플로 엔진·규칙·상태 관리가 함께 계획 기능을 구성하는 경우도 많습니다.

중요한 것은 에이전트가 계획을 한 번 세우고 끝내지 않는다는 점입니다. 실행 도중 “데이터 접근 권한이 없음”, “필수 값이 누락됨”, “승인 대기 중” 같은 상황이 발생하면 계획을 수정해야 합니다. 이른바 관찰 → 판단 → 행동 → 재관찰의 반복 루프가 Agentic AI의 핵심입니다.

AI 지식·메모리 레이어: 매번 처음부터 시작하지 않게 하는 기반

업무용 에이전트가 신뢰를 얻으려면, 범용 인터넷 지식만으로 답해서는 부족합니다. 조직의 정책, 제품 정보, 고객 계약 조건, 과거 보고서, 업무 규칙을 근거로 판단해야 합니다. 이 역할을 하는 것이 지식·메모리 레이어입니다.

대표적으로 다음 요소가 사용됩니다.

• RAG(Retrieval-Augmented Generation)
  질문과 관련된 사내 문서, 데이터베이스, 위키를 검색한 뒤 그 내용을 근거로 답변과 계획을 생성하는 방식입니다. 최신 정보를 모델 내부에 다시 학습하지 않아도 된다는 장점이 있습니다.

• 벡터 데이터베이스와 검색 엔진
  단어가 완전히 일치하지 않아도 의미가 유사한 문서를 찾습니다. 예를 들어 “휴가 규정”을 질문했을 때 “연차 사용 지침” 문서를 함께 찾아낼 수 있습니다.

• 단기 메모리
  현재 대화의 맥락, 진행 중인 작업 상태, 직전 도구 호출 결과를 유지합니다. “아까 찾은 계약서 기준으로 다시 계산해 주세요” 같은 요청을 처리할 때 필요합니다.

• 장기 메모리
  사용자의 선호, 반복 업무 패턴, 승인 절차, 이전에 해결한 사례를 저장합니다. 다만 장기 메모리는 개인정보와 민감정보를 다룰 수 있으므로 저장 범위와 보존 기간을 엄격히 설계해야 합니다.

지식·메모리 계층이 약하면 AI 에이전트는 매우 자연스럽게 말하면서도 조직의 실제 기준과 다른 답을 내놓을 수 있습니다. 반대로 검색 근거, 참조 문서, 데이터 기준 시점을 함께 제시하도록 설계하면 결과의 검증 가능성과 신뢰도가 크게 올라갑니다.

AI 행동 레이어: 말이 아니라 업무를 끝내는 실행 엔진

에이전트의 차별점은 여기서 가장 분명하게 드러납니다. 일반적인 생성형 AI가 문서 초안이나 답변을 만드는 데 강점이 있다면, 행동 레이어를 갖춘 에이전트는 실제 시스템에 접속해 업무를 수행합니다.

이 실행 계층은 흔히 LAM(Large Action Model) 또는 도구 사용이 가능한 에이전트 구조로 설명됩니다. LAM은 단일 모델의 고정된 이름이라기보다, 워크플로를 실행하고 소프트웨어와 API를 조작하며 여러 기업 시스템을 연결하는 행동 중심 AI 역량을 가리키는 개념에 가깝습니다.

에이전트가 수행할 수 있는 행동은 다양합니다.

• ERP·CRM·데이터베이스 API 조회 및 업데이트
• 이메일·메신저 초안 작성과 발송 요청
• 캘린더 일정 생성 및 참석자 조율
• 승인 요청 워크플로 생성
• 브라우저 기반 사내 시스템 입력
• 파일 생성, 폴더 정리, 보고서 업로드
• 테스트 실행, 배포 파이프라인 호출, 이슈 등록
• RPA와 연동한 반복 화면 작업 자동화

예를 들어 구매 요청 에이전트는 사용자의 자연어 요청을 이해한 뒤, 예산 잔액을 조회하고, 공급업체 정보를 확인하며, 구매 품목을 등록하고, 결재선을 생성할 수 있습니다. 이때 에이전트는 단순히 “구매 요청서를 작성했습니다”라고 답하는 것이 아니라, 실제 시스템에서 요청서를 만들고 승인 가능한 상태까지 전송해야 합니다.

도구 호출은 반드시 통제돼야 한다

행동 레이어는 강력한 만큼 위험도 큽니다. 잘못된 API 호출 하나가 고객 데이터 변경, 중복 주문, 잘못된 이메일 발송, 권한 없는 정보 노출로 이어질 수 있습니다. 따라서 실행형 AI에는 ‘잘하는 능력’만큼 ‘멈춰야 할 때 멈추는 능력’이 중요합니다.

실무에서는 다음과 같은 안전장치가 필요합니다.

통제 장치	역할
권한 관리	에이전트가 접근 가능한 시스템과 데이터 범위를 제한합니다.
승인 단계	결제, 발주, 고객 발송, 데이터 삭제 같은 고위험 작업은 사람의 최종 승인을 받습니다.
실행 로그	어떤 요청에 따라 어떤 도구를 호출했고, 어떤 결과가 나왔는지 기록합니다.
정책 검증	개인정보, 보안 규정, 금액 한도, 업무 규칙을 실행 전에 점검합니다.
재시도·중단 규칙	오류 발생 시 무한 반복하지 않고, 정해진 횟수 후 담당자에게 넘깁니다.
샌드박스 환경	실제 운영 시스템에 반영하기 전 테스트 환경에서 결과를 검증합니다.

특히 “읽기”와 “쓰기” 권한을 분리하는 설계가 중요합니다. 데이터를 조회하고 분석하는 에이전트에는 비교적 넓은 읽기 권한을 줄 수 있지만, 데이터를 변경하거나 외부로 전송하는 권한은 훨씬 더 엄격하게 관리해야 합니다.

하나의 AI가 아니라, 협업하는 스택으로 봐야 한다

Agentic AI는 만능 모델이 아닙니다. 언어를 이해하는 모델, 문서와 이미지를 보는 모델, 계획을 세우는 컨트롤러, 사내 지식을 검색하는 RAG, 시스템을 조작하는 도구 계층, 그리고 안전을 검증하는 정책 엔진이 함께 작동하는 구조입니다.

이를 간단히 정리하면 다음과 같습니다.

인지: 무엇이 일어나고 있는가?
추론·계획: 무엇을 어떤 순서로 해야 하는가?
지식·메모리: 어떤 근거와 과거 맥락을 참고해야 하는가?
행동: 실제 시스템에서 무엇을 실행할 것인가?
통제: 이 행동은 안전하고 허용되는가?

결국 에이전트의 경쟁력은 모델 하나의 성능만으로 결정되지 않습니다. 정확한 데이터 연결, 안정적인 워크플로, 신뢰할 수 있는 메모리, 견고한 권한 관리, 사람의 개입 지점까지 포함한 전체 스택의 완성도가 실행 성공률을 좌우합니다.

월말 정산부터 코드 배포까지, 실행형 AI의 현장

월말 정산일 아침, 담당자는 더 이상 여러 시스템을 오가며 숫자를 복사하고 엑셀을 대조하는 일부터 시작하지 않아도 됩니다. 실행형 AI 에이전트가 ERP에서 매출·비용 데이터를 조회하고, 전월·전년 동기 대비 변동폭을 분석한 뒤, 이상 항목과 확인이 필요한 거래를 정리해 보고서 초안을 보낼 수 있기 때문입니다.

개발 현장도 마찬가지입니다. 에이전트는 이슈 티켓을 읽고 관련 코드와 문서를 검색합니다. 이후 변경 범위를 제안하고, 코드를 수정하며, 테스트를 실행한 뒤 Pull Request까지 생성합니다. 중요한 차이는 단순히 “답변을 만드는 AI”가 아니라, 기업의 실제 시스템 안에서 검증 가능한 행동을 수행하는 AI라는 점입니다.

월말 정산 에이전트: 조회·분석·보고를 하나의 흐름으로

정산 업무는 반복적이지만 예외가 많습니다. 매출 데이터는 ERP에, 비용 증빙은 그룹웨어나 전자결재 시스템에, 재고 현황은 별도 운영 시스템에 있을 수 있습니다. 기존 RPA는 정해진 화면과 규칙에는 강했지만, 문서 형식이 바뀌거나 예상 밖의 예외가 발생하면 쉽게 멈췄습니다.

실행형 AI는 이 흐름에 자연어 이해와 추론을 더합니다.

“이번 달 광고선전비가 지난달보다 30% 이상 증가한 항목을 확인하고, 원인을 추정해 정산 보고서 초안을 작성해줘.”

이 요청을 받은 에이전트는 다음과 같은 작업을 수행할 수 있습니다.

• ERP·회계 시스템 API를 통해 매출과 비용 데이터를 조회합니다.
• 기준 기간과 비교 기준을 정해 항목별 증감률을 계산합니다.
• 급격한 변동, 중복 전표, 누락 가능성이 있는 증빙을 탐지합니다.
• 계약서, 발주서, 비용 승인 문서 등 사내 지식 베이스를 검색합니다.
• 이상 항목의 근거와 확인 요청 사항을 포함한 보고서 초안을 작성합니다.
• 담당자 검토용 결재 문서 또는 협업 도구 알림을 생성합니다.

여기서 핵심은 AI가 숫자를 “설명”하는 데서 끝나지 않는다는 것입니다. 데이터 조회, 기준 적용, 문서 검색, 보고서 작성, 승인 요청 생성까지 연결하면서 실제 업무 흐름을 전진시킵니다.

다만 정산처럼 재무 영향이 큰 업무에서는 완전 자율 실행보다 승인 기반 자동화가 적합합니다. 예를 들어 에이전트는 보고서 초안과 결재 요청을 만들 수 있지만, 회계 전표 확정이나 지급 실행은 반드시 권한을 가진 담당자가 승인하도록 설계해야 합니다.

코드 에이전트: 이슈에서 Pull Request까지

개발 조직에서 Agentic AI의 가장 빠른 활용 영역 중 하나는 코드 작업입니다. 단순한 코드 자동완성 도구를 넘어, 코드 에이전트는 저장소 전체의 구조와 개발 규칙을 이해한 뒤 여러 도구를 연속으로 사용합니다.

가령 다음과 같은 이슈가 등록됐다고 가정해 보겠습니다.

“주문 취소 API에서 이미 환불이 완료된 주문도 다시 환불 요청되는 문제가 있습니다. 중복 환불을 막고 테스트를 추가해 주세요.”

코드 에이전트는 일반적으로 다음 순서로 움직입니다.

1. 이슈 설명과 관련 로그를 읽습니다.
2. 저장소에서 주문 취소, 결제, 환불 처리와 관련된 파일을 검색합니다.
3. 기존 테스트와 예외 처리 규칙을 파악합니다.
4. 변경해야 할 코드와 예상 영향 범위를 계획합니다.
5. 중복 환불 여부를 검증하는 로직을 추가합니다.
6. 단위 테스트와 통합 테스트를 실행합니다.
7. 실패한 테스트가 있다면 원인을 분석하고 수정안을 제안합니다.
8. 변경 사항, 테스트 결과, 주의 사항을 정리한 Pull Request를 생성합니다.

이 과정에서 AI는 코드 생성 모델만 사용하는 것이 아닙니다. Git, 이슈 트래커, CI/CD, 테스트 프레임워크, 패키지 관리자, 코드 검색 도구 등과 연결됩니다. 즉, LLM이 문제를 해석하고 계획을 세운다면, 행동 계층은 실제 명령 실행과 시스템 조작을 담당합니다.

하지만 코드 배포는 실수가 곧 장애로 이어질 수 있는 영역입니다. 따라서 운영 환경에 직접 배포 권한을 주기보다, 에이전트의 역할을 단계별로 분리하는 편이 안전합니다.

단계	에이전트 권한	사람의 역할
이슈 분석	코드·문서 읽기, 원인 후보 정리	우선순위와 방향 확인
코드 수정	브랜치 생성, 코드 변경, 테스트 실행	변경 내용 리뷰
Pull Request	PR 생성, 테스트 결과 첨부	승인·병합 결정
스테이징 배포	제한된 환경 배포, 검증 리포트 생성	배포 승인
운영 배포	원칙적으로 승인 후 실행	최종 책임 및 모니터링

이 구조는 AI의 속도와 사람의 책임 체계를 함께 확보하는 방식입니다.

실행형 AI를 움직이는 핵심 도구

기업 환경의 에이전트는 하나의 모델만으로 작동하지 않습니다. 실제 업무를 수행하려면 데이터를 읽고, 계획을 세우고, 도구를 호출하고, 결과를 기록하는 여러 계층이 필요합니다.

업무 시스템 연결을 위한 API와 커넥터

ERP, CRM, 그룹웨어, 메일, 메신저, 이슈 트래커, 소스 코드 저장소는 각각 다른 방식으로 동작합니다. 에이전트가 이 시스템을 다루려면 API, 웹훅, 데이터베이스 커넥터, RPA 기반 UI 자동화가 필요합니다.

가능하다면 화면 클릭보다 API 연동을 우선해야 합니다. API는 권한 범위를 세밀하게 제어할 수 있고, 실행 이력도 남기기 쉽습니다. 반면 API가 없는 레거시 시스템은 RPA나 브라우저 자동화를 보조 수단으로 사용할 수 있습니다.

RAG와 지식 베이스

에이전트가 회사의 업무 규정, 개발 가이드, 회계 정책, 보안 절차를 모른다면 위험한 행동을 할 수 있습니다. 따라서 사내 문서와 정책을 검색하는 RAG 기반 지식 레이어가 필요합니다.

예를 들어 정산 에이전트는 비용 처리 기준과 계정과목 정책을 참조해야 하며, 코드 에이전트는 브랜치 전략, 코딩 컨벤션, 배포 기준, 장애 대응 매뉴얼을 확인해야 합니다. 이 지식은 단순 참고 자료가 아니라, 에이전트의 행동 범위를 제어하는 운영 규칙이 됩니다.

워크플로 오케스트레이터

실무 프로세스는 한 번의 호출로 끝나지 않습니다. 데이터 조회 후 검증하고, 결과에 따라 승인 요청을 만들거나 담당자에게 질문해야 합니다. 워크플로 오케스트레이터는 이런 조건 분기와 작업 순서를 관리합니다.

예를 들면 다음과 같은 흐름입니다.

데이터 조회
→ 이상치 분석
→ 신뢰도 확인
→ 기준 미달 시 담당자에게 질문
→ 기준 충족 시 보고서 초안 생성
→ 승인 요청 생성
→ 실행 결과와 로그 저장

이 구조가 있어야 에이전트는 단순 챗봇이 아니라, 반복 가능한 업무 프로세스로 운영될 수 있습니다.

자율성보다 중요한 것: 통제와 안전장치

실행형 AI의 성패는 “얼마나 많은 일을 자동화하는가”보다 “얼마나 안전하게 자동화하는가”에 달려 있습니다. 특히 재무, 고객 정보, 소스 코드, 운영 인프라에 접근하는 에이전트라면 다음 안전장치가 필수적입니다.

• 최소 권한 원칙: 필요한 시스템과 기능에만 접근하도록 권한을 제한합니다. 조회 권한과 수정 권한, 배포 권한을 분리해야 합니다.
• 승인 단계: 금전 지급, 전표 확정, 고객 데이터 변경, 운영 배포처럼 영향이 큰 행동에는 사람의 명시적 승인을 요구합니다.
• 실행 한도: 한 번에 처리할 수 있는 금액, 레코드 수, 코드 변경 범위, API 호출 횟수를 제한합니다.
• 샌드박스 환경: 코드 실행과 자동 수정은 운영 환경이 아닌 격리된 테스트 환경에서 먼저 검증합니다.
• 감사 로그: 에이전트가 어떤 데이터를 읽고, 어떤 근거로 판단했으며, 어떤 API를 호출했는지 추적 가능하게 기록합니다.
• 중단 장치: 이상 행동이 감지되면 즉시 작업을 멈추고 사람에게 넘기는 kill switch와 fallback 절차를 마련합니다.
• 출력 검증: AI가 만든 보고서, 코드, 명령어는 정책 검사와 규칙 기반 검증을 통과해야 다음 단계로 진행됩니다.

특히 “AI가 판단했다”는 문장은 책임의 근거가 될 수 없습니다. 기업 환경에서는 판단 근거, 참조 문서, 실행 결과, 승인자가 모두 연결된 감사 추적성이 필요합니다.

도입의 출발점은 작은 업무 단위다

실행형 AI를 도입할 때 처음부터 전사 자동화를 목표로 삼을 필요는 없습니다. 오히려 규칙은 분명하지만 반복이 많은 업무부터 시작하는 편이 효과적입니다.

예를 들어 다음과 같은 업무가 적합합니다.

• 월말 정산용 데이터 수집과 보고서 초안 작성
• 고객 문의 분류와 담당 부서 배정
• 계약서 조항 비교와 검토 요청 생성
• 장애 알림 요약과 대응 매뉴얼 검색
• 개발 이슈 분석, 테스트 코드 작성, Pull Request 초안 생성
• 재고 이상 탐지와 발주 요청서 초안 작성

이런 업무에서 AI 에이전트는 담당자의 시간을 줄이고, 누락을 낮추며, 업무 흐름을 표준화할 수 있습니다. 다만 최종 목표는 사람을 완전히 배제하는 자동화가 아닙니다. 사람은 판단과 책임이 필요한 지점에 집중하고, 에이전트는 조회·분석·정리·실행처럼 반복적인 연결 작업을 맡는 구조가 현실적인 방향입니다.

월말 정산부터 코드 배포까지, 실행형 AI의 가치는 결국 하나로 모입니다. 답을 잘 만드는 능력을 넘어, 기업의 도구와 규칙 안에서 안전하게 일을 끝까지 처리하는 능력입니다.

AI 에이전트, 스스로 행동해도 믿을 수 있을까

AI가 문서를 잘못 요약하거나 답변에 오류를 내는 문제는 대개 사람이 검토하고 수정할 수 있습니다. 하지만 실행 권한을 가진 AI 에이전트가 결제를 승인하고, 고객 정보를 변경하며, 운영 서버에 코드를 배포한다면 이야기는 달라집니다. 오류는 화면 속 문장이 아니라 즉시 현실의 피해로 이어질 수 있습니다.

Agentic AI와 LAM의 핵심 가치는 ‘답변’이 아니라 ‘실행’입니다. 따라서 도입의 기준도 단순 정확도나 응답 속도가 되어서는 안 됩니다. 더 중요한 질문은 다음 세 가지입니다.

누가 AI에 권한을 부여하는가?
AI의 실행 결과는 누가 책임지는가?
문제가 발생하면 AI를 어떻게 즉시 멈추게 할 것인가?

권한은 한 번에 주지 말아야 한다

AI 에이전트는 ERP, CRM, 이메일, 결제 시스템, 클라우드 콘솔, 코드 저장소 등 여러 도구와 연결될 수 있습니다. 이때 가장 위험한 설계는 사람과 동일한 수준의 광범위한 권한을 한 번에 부여하는 방식입니다.

안전한 AI 에이전트는 최소 권한 원칙(Least Privilege) 을 따라야 합니다. 예를 들어 고객 문의를 분류하는 에이전트에는 티켓 조회와 초안 작성 권한만 주고, 환불 승인이나 고객 정보 삭제 권한은 별도의 승인 절차 뒤에만 실행하도록 분리해야 합니다.

권한은 업무 위험도에 따라 계층화할 수 있습니다.

• 낮은 위험: 문서 검색, 요약, 보고서 초안 작성
• 중간 위험: 일정 등록, 티켓 생성, 재고 데이터 업데이트
• 높은 위험: 결제 승인, 계약 변경, 개인정보 삭제, 운영 배포
• 치명적 위험: 계정 권한 변경, 대규모 송금, 보안 정책 해제

높은 위험 작업일수록 AI가 단독으로 실행하지 않고, 담당자의 명시적 승인이나 다단계 검증을 거치도록 설계해야 합니다.

‘사람의 승인’은 형식이 아니라 통제 장치다

Human-in-the-Loop, 즉 사람의 개입은 AI 자동화를 느리게 만드는 장치가 아닙니다. 오히려 위험한 행동이 실제 시스템에 반영되기 전 마지막으로 작동하는 안전장치입니다.

특히 다음 작업에는 승인 단계를 기본값으로 두는 것이 바람직합니다.

• 외부 고객에게 메일·메시지를 발송하는 작업
• 금액, 가격, 계약 조건을 변경하는 작업
• 개인정보를 조회·수정·삭제하는 작업
• 프로덕션 환경에 코드를 배포하는 작업
• 법무·인사·재무 판단이 포함된 작업

좋은 승인 화면은 단순히 ‘승인’ 버튼만 보여주지 않습니다. AI가 무엇을 근거로 판단했는지, 어떤 시스템에 어떤 변경을 시도하는지, 예상 영향 범위는 어디까지인지를 함께 제시해야 합니다. 담당자는 AI의 결론이 아니라 실행 계획 전체를 검토할 수 있어야 합니다.

책임 추적성이 없다면 자동화는 위험해진다

AI 에이전트가 여러 도구를 호출하고 복잡한 워크플로를 수행할수록, 장애가 발생했을 때 원인을 찾기 어려워집니다. 따라서 모든 실행에는 감사 로그(Audit Trail)가 남아야 합니다.

최소한 다음 정보는 기록하는 것이 좋습니다.

• 어떤 사용자 또는 부서가 AI에 작업을 요청했는가
• AI가 어떤 문서·데이터를 참고했는가
• 어떤 계획을 세우고 어떤 도구를 호출했는가
• 어떤 API 요청과 시스템 변경이 발생했는가
• 누가 승인하거나 거절했는가
• 실패 시 어떤 오류가 발생했고 어떻게 복구했는가

이 기록은 단순한 사후 보고용이 아닙니다. 규제 대응, 보안 조사, 고객 분쟁, 모델 개선을 위한 핵심 데이터가 됩니다. 특히 금융, 의료, 공공, 제조처럼 책임 소재가 중요한 산업에서는 AI의 판단보다 판단과 실행의 이력이 더 중요할 수 있습니다.

실패를 전제로 ‘멈출 수 있는 AI’를 설계해야 한다

AI 에이전트는 항상 정확하지 않습니다. 문서를 잘못 해석할 수 있고, 오래된 정보를 참조할 수 있으며, 예상하지 못한 API 오류나 권한 충돌을 만날 수도 있습니다. 따라서 신뢰할 수 있는 시스템은 실패하지 않는 AI가 아니라, 실패해도 피해를 제한하는 AI입니다.

이를 위해서는 다음과 같은 안전 설계가 필요합니다.

• 킬 스위치: 관리자 또는 담당자가 즉시 실행을 중단할 수 있는 기능
• 실행 한도: 일정 금액, 호출 횟수, 처리 건수, 변경 범위를 제한하는 정책
• 샌드박스: 운영 환경에 반영하기 전 테스트 환경에서 결과를 검증하는 구조
• 롤백: 잘못된 변경을 이전 상태로 되돌릴 수 있는 복구 절차
• 예외 처리: 확신이 낮거나 정책 위반 가능성이 있으면 AI가 자동 실행 대신 사람에게 이관하는 방식
• 모니터링: 비정상적인 행동, 반복 호출, 권한 밖 접근을 실시간 탐지하는 체계

예를 들어 코드 배포 AI는 테스트 통과만으로 운영 배포를 실행해서는 안 됩니다. 변경 파일, 의존성 영향, 보안 검사 결과, 롤백 계획을 함께 제출하고, 승인된 배포 창에서만 제한적으로 실행하도록 해야 합니다.

AI 신뢰는 성능이 아니라 거버넌스에서 나온다

Agentic AI의 경쟁력은 더 많은 일을 대신하는 데 있습니다. 그러나 실행 범위가 넓어질수록 기업이 관리해야 할 위험도 함께 커집니다. 결국 중요한 것은 “AI가 할 수 있는가”가 아니라 “AI가 해도 되는가”를 판단하는 기준입니다.

신뢰할 수 있는 AI 에이전트는 자율적으로 행동하되, 무제한으로 행동하지 않습니다. 권한은 제한되고, 고위험 작업은 승인받으며, 모든 과정은 기록되고, 이상 징후가 보이면 즉시 멈출 수 있어야 합니다.

AI가 업무를 실행하는 시대에는 똑똑한 모델만으로 충분하지 않습니다. 통제 가능한 권한, 설명 가능한 실행, 되돌릴 수 있는 실패 구조가 갖춰질 때 비로소 AI 에이전트는 실험용 도구를 넘어 신뢰할 수 있는 업무 파트너가 됩니다.