책에 포함된 노트2026 AI 트렌드: 답변하는 AI에서 실행하는 AI로

에이전틱 AI: 답변에서 실행으로

2026-05-14Views 68약 11분생성형 AI 활용

Summary

감각을 얻은 AI에게 '손'이 생기다

지난 장에서 우리는 AI가 텍스트만 다루는 존재를 넘어 보고, 듣고, 말하는 실시간 인터페이스로 확장되는 장면을 살펴보았다. 멀티모달 AI가 AI에게 감각을 주었다면, 에이전틱 AI는 그 감각 위에 '손'을 붙인다. 이제 AI는 화면 속에서 대답만 하는 상담원이 아니라, 캘린더를 확인하고, 파일을 열고, 시스템에 기록을 남기고, 필요한 경우 주문이나 예약까지 진행하는 실행자에 가까워진다.

예를 들어 사용자가 이렇게 말한다고 해보자.

"다음 달 부산 출장 일정을 잡아줘. 예산은 40만 원 이하이고, 오전 회의에 늦지 않게 도착해야 해."

일반 챗봇은 항공편이나 기차편을 추천하고, 호텔 선택 기준을 설명할 수 있다. 조금 더 똑똑한 챗봇은 일정표 초안도 만들어준다. 그러나 에이전트는 여기서 멈추지 않는다. 사용자의 캘린더를 확인하고, 교통편을 검색하고, 회사 출장 규정을 조회하고, 예산 범위 안의 호텔 후보를 비교하고, 사용자의 승인을 받은 뒤 예약을 진행하고, 일정표를 캘린더에 등록하고, 동료에게 공유 메일을 보낼 수 있다.

이 차이가 바로 에이전틱 AI의 핵심이다. MIT Sloan은 AI 에이전트를 다른 소프트웨어 시스템과 연결되어 인간의 감독을 최소화한 상태로 작업을 수행할 수 있는 AI 시스템으로 설명한다.¹ 말하자면 에이전트는 '무엇을 말할까'보다 '무엇을 할까'를 고민하는 AI다.

에이전틱 AI: 답변에서 실행으로

에이전트는 하나의 모델이 아니라 일하는 구조다

에이전틱 AI를 이해할 때 가장 먼저 버려야 할 오해가 있다. 에이전트는 특정한 하나의 초거대 모델을 뜻하지 않는다. 모델은 엔진에 가깝다. 에이전트는 그 엔진에 핸들, 바퀴, 내비게이션, 브레이크, 계기판을 붙인 업무 수행 구조다.

생성형 AI가 문장을 만드는 기술이라면, 에이전틱 AI는 그 문장 생성 능력을 업무 흐름 속에 넣는다. DeepLearning.AI도 에이전틱 워크플로를 단일 응답 생성이 아니라 여러 단계를 계획하고, 반복적으로 실행하며, 도구 사용과 반성을 통해 결과를 개선하는 방식으로 설명한다.²

실제 에이전트 시스템은 보통 다음 요소로 구성된다.

목표 해석기: 사용자가 원하는 최종 상태를 파악한다. '보고서 써줘'가 아니라 '임원 회의에서 의사결정에 쓸 수 있는 매출 위험 요약을 만들어야 한다'는 목표를 읽어낸다.
계획기: 큰 목표를 작은 단계로 나눈다. 자료 수집, 정리, 분석, 초안 작성, 검증, 전달 같은 하위 작업을 만든다.
도구 호출 계층: 검색, 브라우저, 파일 시스템, 데이터베이스, API, 캘린더, 이메일, 코드 실행 환경 같은 실제 도구를 사용한다.
상태와 기억: 지금 어디까지 했는지, 어떤 선택지를 버렸는지, 사용자가 어떤 기준을 선호하는지 기억한다.
검증과 통제 장치: 결과를 확인하고, 실패하면 다시 시도하며, 위험한 행동은 사람에게 승인을 요청한다.

여기서 가장 중요한 것은 도구 호출이다. 에이전트가 아무 도구도 쓰지 못한다면, 결국 말만 잘하는 상담원에 머문다. 반대로 도구를 가진 에이전트는 현실의 업무 시스템에 손을 뻗을 수 있다. 고객관리 시스템에서 주문 상태를 확인하고, 재고 시스템에서 수량을 읽고, 회계 시스템에 비용 항목을 입력하고, 슬랙에 진행 상황을 공유한다. 그 순간 AI는 답변 엔진에서 업무 엔진으로 바뀐다.

계획–행동–관찰–수정 루프

에이전틱 AI의 심장은 반복 루프다. 이름은 복잡해 보일 수 있지만 원리는 사람이 일하는 방식과 닮았다. 우리는 일을 할 때 한 번에 모든 것을 끝내지 않는다. 목표를 세우고, 자료를 찾고, 해보고, 결과를 확인하고, 틀렸으면 고친다. 에이전트도 비슷하다.

에이전트의 기본 루프는 다음과 같다.

계획: 목표를 이해하고 다음에 무엇을 해야 할지 정한다.
행동: 필요한 도구를 호출해 실제 작업을 수행한다.
관찰: 도구가 반환한 결과, 오류 메시지, 새로 발견한 정보를 읽는다.
수정: 결과가 부족하면 계획을 바꾸고 다시 행동한다.

고객지원 에이전트를 예로 들어보자. 고객이 "택배가 안 왔어요"라고 문의한다. 에이전트는 먼저 주문번호를 찾고, 주문 데이터베이스를 조회한다. 배송사 API를 호출해 현재 위치를 확인한다. 배송 지연 사유가 파업인지, 주소 오류인지, 재고 출고 지연인지 관찰한다. 만약 주소가 잘못되어 반송 중이라면 고객에게 주소 확인 메시지를 보내고, 회사 정책상 재발송이 가능한지 확인한다. 환불 금액이 일정 기준을 넘으면 상담 매니저에게 승인을 요청한다. 승인이 떨어지면 재발송 티켓을 만들고 고객에게 처리 결과를 보낸다.

이 과정에서 에이전트는 단순히 정해진 문장을 출력하지 않는다. 매 단계에서 새 정보를 보고 다음 행동을 바꾼다. 주소 오류일 때와 배송사 지연일 때의 경로가 달라지고, VIP 고객인지 일반 고객인지에 따라 보상 정책 조회가 달라지며, 재고가 없으면 대체 상품 제안으로 방향을 튼다.

이것이 챗봇과 에이전트의 가장 큰 차이다. 챗봇은 대화를 이어간다. 에이전트는 일을 이어간다.

RPA와 무엇이 다른가

기업에는 이미 오래전부터 자동화가 있었다. 대표적인 것이 RPA다. RPA는 Robotic Process Automation의 약자로, 사람이 컴퓨터에서 반복하던 클릭, 복사, 붙여넣기, 입력 작업을 소프트웨어 로봇이 대신 수행하는 방식이다. 예를 들어 매일 오전 9시에 특정 웹사이트에 접속해 파일을 내려받고, 엑셀에 붙여 넣고, 사내 시스템에 업로드하는 업무는 RPA가 잘한다.

RPA는 공장 컨베이어벨트와 비슷하다. 정해진 레일 위에서는 빠르고 정확하다. 하지만 버튼 위치가 바뀌거나, 입력 양식이 달라지거나, 예외 상황이 늘어나면 금방 멈춘다. 반면 AI 에이전트는 비포장도로를 달리는 운전자에 가깝다. 속도는 매번 다를 수 있지만, 길이 조금 바뀌어도 주변을 보고 우회할 수 있다.

BBC R&D는 전통적인 스크립트가 예측 가능하고 테스트하기 쉬운 장점이 있는 반면, AI 에이전트는 사용 방식이 다양하거나 사전에 모든 로직을 작성하기 어려운 불확실한 업무에서 특히 유용하다고 설명한다.³ 이 말은 에이전트가 RPA보다 항상 낫다는 뜻이 아니다. 정해진 규칙이 안정적으로 반복되는 업무라면 RPA나 일반 워크플로가 더 싸고 안전할 수 있다. 에이전트는 예외가 많고, 입력이 매번 다르고, 중간 판단이 필요한 업무에서 빛난다.

구분	잘하는 일	약점	핵심 차이
챗봇	질문 답변, 설명, 요약	직접 실행하지 못함	말로 돕는다
RPA	정해진 클릭과 입력 반복	예외와 변화에 약함	정해진 절차를 반복한다
코파일럿	사용자의 작업을 옆에서 보조	사용자가 계속 지시해야 함	사람의 손을 빠르게 한다
AI 에이전트	목표를 하위 작업으로 나누고 도구를 호출	통제와 검증이 필요함	목표를 향해 일을 진행한다

따라서 기업이 던져야 할 질문은 '에이전트가 멋진가'가 아니다. 더 현실적인 질문은 이것이다. 이 업무는 규칙을 쓰는 편이 나은가, 목표를 주고 판단하게 하는 편이 나은가?

업무 현장: 에이전트가 먼저 들어가는 곳

에이전틱 AI는 공상과학 속 비서처럼 보이지만, 실제 도입은 훨씬 소박한 곳에서 시작된다. 대개 사람의 시간이 많이 들고, 여러 시스템을 오가며, 결과를 확인할 수 있는 업무가 첫 대상이다. TechTarget은 보안 대응, 공급망과 물류, 콜센터, 지식 검색, 헬스케어 운영, 제조, 유틸리티 등 다양한 영역에서 에이전틱 AI 활용이 논의되고 있다고 정리한다.⁴

고객지원에서는 에이전트가 문의를 읽고, 고객의 과거 주문과 상담 이력을 확인하고, 정책 문서를 찾아보고, 단순 문제를 해결하거나 복잡한 문제를 사람에게 넘긴다. 중요한 점은 '넘기는 방식'이다. 예전에는 상담원이 고객에게 처음부터 다시 물어봐야 했다. 에이전트가 잘 설계되어 있으면 사람 상담원은 요약된 배경, 이미 시도한 조치, 추천 해결책을 함께 받는다. 고객은 같은 설명을 반복하지 않아도 된다.

보안 운영에서는 에이전트가 로그를 읽고, 이상 징후를 찾고, 관련 IP나 계정 활동을 추적하고, 위험도를 분류한다. 다만 여기서 에이전트가 곧바로 서버를 차단하거나 계정을 삭제하게 두는 것은 위험할 수 있다. 대신 '격리 후보를 만들고 보안 담당자에게 승인 요청'처럼 중간 통제 지점을 두는 방식이 현실적이다.

공급망 관리에서는 날씨, 항만 지연, 재고, 가격, 대체 공급처 정보를 함께 봐야 한다. 사람이 하려면 여러 화면을 오가며 전화를 걸고 엑셀을 업데이트해야 한다. 에이전트는 이런 정보를 모아 '현재 목표가 최저 비용인지, 납기 준수인지, 품질 안정성인지'에 따라 다른 선택지를 제안할 수 있다.

데이터 정리와 보고서 작성도 유력한 영역이다. 에이전트는 여러 파일에서 데이터를 모으고, 형식을 맞추고, 누락값을 표시하고, 이상치를 찾아내고, 차트를 만들고, 보고서 초안을 작성한다. 사람은 마지막에 수치와 해석을 검토한다. 이것은 단순한 문서 생성이 아니라, 자료 수집부터 검증까지 이어지는 작은 업무 프로세스의 자동화다.

이런 사례들을 관통하는 공통점이 있다. 에이전트는 인간 직무 전체를 한 번에 대체하지 않는다. 먼저 대기, 조회, 분류, 정리, 반복 판단, 초안 작성 같은 업무 조각을 가져간다. 인간은 더 많은 시간을 예외 처리, 관계 조율, 책임 판단, 전략 수립에 쓰게 된다.

현재의 현실선: 짧고 검증 가능한 일부터

에이전틱 AI를 이야기할 때 가장 위험한 태도는 두 가지다. 하나는 '이제 모든 일이 자동화된다'는 과장이고, 다른 하나는 '어차피 틀리니 쓸모없다'는 냉소다. 현실은 그 중간에 있다. 현재의 에이전트는 짧고 검증 가능한 업무에서 꽤 강하다. 하지만 길고 모호하며 책임이 큰 업무에서는 아직 조심스럽게 다뤄야 한다.

좋은 출발점은 이런 업무다.

지난달 고객 문의 1만 건을 주제별로 분류하고 상위 10개 원인을 요약한다.
특정 코드 저장소에서 테스트 실패 원인을 찾아 수정 후보를 제안한다.
회의록을 읽고 담당자별 후속 작업을 프로젝트 관리 도구에 초안으로 등록한다.
신규 리드 정보를 여러 출처에서 보강하고 CRM에 입력할 초안을 만든다.

이 업무들은 결과를 확인할 수 있다. 분류표를 샘플링할 수 있고, 코드는 테스트를 돌릴 수 있고, 후속 작업은 사람이 승인할 수 있고, CRM 입력값은 원본과 대조할 수 있다. 에이전트가 틀려도 발견하고 고치기 쉽다.

반대로 이런 요청은 아직 위험하다.

"우리 회사의 3년 해외 진출 전략을 알아서 실행해줘."

이 말에는 목표도, 권한도, 예산도, 책임 기준도, 중단 조건도 불분명하다. 에이전트는 뭔가를 계속할 수는 있지만, 그 행동이 정말 회사에 좋은지 판단하기 어렵다. 장기 작업에서는 오류가 눈덩이처럼 커질 수 있다. 첫 단계에서 잘못된 가정을 하면 둘째 단계의 검색이 흔들리고, 셋째 단계의 보고서가 왜곡되고, 넷째 단계의 이메일이 잘못된 사람에게 갈 수 있다.

현재 에이전트가 부딪히는 대표적인 한계는 다음과 같다.

맥락 창 한계: 모델이 한 번에 볼 수 있는 정보량에는 한계가 있다. 오래 진행되는 작업에서는 앞선 조건을 놓치거나 왜곡할 수 있다.
잘못된 추론의 누적: 한 번의 작은 착각이 다음 행동의 전제가 되면 전체 작업이 틀어진다.
도구 호출 실패: API가 바뀌거나 권한이 부족하거나 네트워크가 끊기면 계획이 멈춘다.
최신 상태 오해: 방금 변경된 재고, 취소된 회의, 업데이트된 정책을 반영하지 못하면 잘못된 결정을 내릴 수 있다.
비용과 지연 시간 증가: 에이전트가 여러 번 생각하고 여러 도구를 부르면 토큰 비용과 대기 시간이 늘어난다.
권한 오남용 위험: 이메일, 결제, 삭제, 배포 권한이 넓을수록 한 번의 실수가 실제 피해로 이어진다.

특히 사실 판단에는 컴파일러가 없다. 코드는 실행해보면 문법 오류라도 나온다. 하지만 법률 조항, 의료 정보, 재무 판단, 고객 약속은 틀렸는지 바로 드러나지 않을 수 있다. 그래서 에이전트에게 일을 맡길수록 검증 가능한 산출물, 중간 승인, 감사 로그가 중요해진다.

인간이 루프 밖으로 나가면 안 되는 순간

에이전트 도입의 목표는 사람을 완전히 없애는 것이 아니라, 사람이 꼭 필요한 곳에 사람의 주의를 집중시키는 것이다. 그래서 중요한 설계 원칙은 '사람을 언제 끼워 넣을 것인가'다. 이를 흔히 human-in-the-loop, 즉 인간 검토 절차라고 부른다.

모든 단계마다 사람이 승인하면 자동화의 의미가 없다. 반대로 모든 단계를 에이전트에게 맡기면 사고가 난다. 따라서 기업은 위험도에 따라 승인 지점을 나눠야 한다.

사람의 승인이 필요한 대표적인 순간은 다음과 같다.

돈이 이동하거나 예산이 집행되는 순간
고객, 언론, 파트너에게 공식 메시지가 나가는 순간
중요한 데이터가 삭제되거나 대량 수정되는 순간
개인정보, 의료 정보, 금융 정보 같은 민감 데이터가 사용되는 순간
법적 책임, 인사 평가, 안전 조치처럼 설명 책임이 큰 판단을 내리는 순간

이 승인 절차는 에이전트를 못 믿어서 붙이는 장식이 아니다. 자동차의 브레이크와 안전벨트에 가깝다. 좋은 자동차일수록 더 빠르게 달릴 수 있지만, 그래서 더 좋은 제동 장치가 필요하다. 좋은 에이전트일수록 더 많은 일을 할 수 있고, 그래서 더 정교한 통제가 필요하다.

기업 도입: 자율성보다 운영 설계

에이전트 프로젝트가 실패하는 이유는 대개 모델이 말을 못해서가 아니다. 오히려 모델은 그럴듯하게 말을 너무 잘한다. 진짜 어려움은 주변에 있다. 데이터가 흩어져 있고, 권한 체계가 복잡하고, API 문서가 낡았고, 부서마다 업무 정의가 다르며, 실패했을 때 누가 책임지는지 정해져 있지 않다.

MIT Sloan이 소개한 한 의료 AI 에이전트 연구 사례에서도 가장 큰 부담은 프롬프트 작성이나 모델 미세조정이 아니라 데이터 엔지니어링, 이해관계자 조율, 거버넌스, 워크플로 통합 같은 작업이었다. 연구진은 이 부분이 전체 작업의 상당 부분을 차지했다고 설명한다.¹ 현장에서 AI 도입이 어려운 이유가 여기에 있다. 에이전트는 똑똑한 모델만으로 돌아가지 않는다. 회사의 일하는 방식 전체와 연결되어야 한다.

기업이 에이전트를 도입할 때 봐야 할 핵심은 자율성의 크기가 아니라 운영의 품질이다. 에이전트가 얼마나 혼자 돌아다니는지가 아니라, 어디까지 들어갈 수 있고, 무엇을 할 수 있고, 무엇을 하면 안 되며, 실패했을 때 어떻게 멈추고 되돌릴 수 있는지가 중요하다.

기업용 에이전트에는 일종의 직무기술서가 필요하다.

목표: 이 에이전트가 달성해야 할 업무 결과는 무엇인가.
범위: 어떤 시스템, 어떤 데이터, 어떤 고객군까지만 다루는가.
권한: 조회만 가능한가, 수정도 가능한가, 외부 발송도 가능한가.
금지 행동: 삭제, 결제, 계약, 인사 판단처럼 절대 자동 실행하지 않을 행동은 무엇인가.
성공 기준: 정확도, 처리 시간, 비용, 고객 만족도, 오류율 중 무엇으로 평가할 것인가.
에스컬레이션 규칙: 확신이 낮거나 위험이 높을 때 누구에게 넘길 것인가.

또 하나 중요한 것은 오케스트레이션이다. 오케스트레이션은 여러 작업을 순서와 조건에 맞게 지휘하는 것이다. 에이전트가 고객 정보를 조회하고, 문서를 만들고, 승인 요청을 보내고, 승인 후 시스템을 업데이트하는 흐름이 있다면, 중간에 실패했을 때 재시도할지, 중단할지, 이전 상태로 되돌릴지 정해야 한다. 단순히 'AI가 알아서 하겠지'라고 두면 운영 사고가 된다.

감사 로그도 필수다. 누가 어떤 목표를 줬고, 에이전트가 어떤 도구를 호출했으며, 어떤 데이터를 읽고, 어떤 결정을 했고, 어떤 사람이 승인했는지 남아야 한다. 로그가 없으면 개선도, 책임 추적도, 규제 대응도 어렵다.

MCP와 A2A: 에이전트 생태계의 연결 문법

에이전트가 실제 업무를 하려면 도구와 연결되어야 한다. 문제는 기업마다 쓰는 도구가 너무 많다는 점이다. 이메일, 문서 저장소, CRM, ERP, 데이터베이스, 회계 시스템, 보안 도구, 프로젝트 관리 도구가 제각각이다. 에이전트를 만들 때마다 모든 시스템에 별도 연결을 붙인다면 비용이 폭발한다.

그래서 최근 중요해진 흐름이 연결 프로토콜의 표준화다. 대표적인 것이 MCP와 A2A다.

MCP, 즉 Model Context Protocol은 AI 애플리케이션이 외부 시스템에 연결되도록 돕는 오픈 표준이다. 공식 문서는 MCP를 AI 애플리케이션을 외부 데이터, 도구, 워크플로에 연결하는 표준 방식으로 설명하며, USB-C 포트에 비유한다.⁵ USB-C가 충전기와 노트북, 모니터, 저장장치를 같은 규격으로 연결하듯, MCP는 에이전트가 파일, 데이터베이스, 검색 도구, 캘린더, 업무 시스템을 더 일관된 방식으로 사용할 수 있게 한다.

MCP가 중요한 이유는 단순히 연결이 쉬워져서만이 아니다. 도구가 많아질수록 에이전트는 각 도구의 설명과 사용법을 모델의 맥락 창에 넣어야 하는데, 이것이 비용과 속도 문제를 만든다. Anthropic은 MCP와 코드 실행 환경을 함께 쓰면 필요한 도구 정의만 불러오고 중간 데이터를 실행 환경에서 처리해 토큰 사용을 크게 줄일 수 있다고 설명한다.⁶ 에이전트가 수백 개의 도구를 가진 회사에서 일하려면, 이런 효율화가 필수다.

A2A, 즉 Agent2Agent는 이름 그대로 에이전트와 에이전트가 서로 소통하기 위한 프로토콜이다. Google은 A2A를 서로 다른 벤더나 프레임워크로 만들어진 에이전트들이 정보를 안전하게 교환하고 행동을 조율하도록 돕는 오픈 프로토콜로 발표했다.⁷ A2A 공식 문서도 MCP가 주로 에이전트와 도구 사이의 연결을 표준화한다면, A2A는 에이전트와 에이전트 사이의 협업을 표준화한다고 설명한다.⁸

쉽게 말해 MCP는 에이전트의 콘센트이고, A2A는 에이전트들의 무전기다. MCP가 "이 데이터베이스에 어떻게 접속하지?"라는 문제를 줄인다면, A2A는 "저쪽 HR 에이전트에게 후보자 검증을 맡기고 결과를 받아오려면 어떻게 말해야 하지?"라는 문제를 줄인다.

다만 프로토콜이 생겼다고 모든 문제가 해결되는 것은 아니다. 표준은 언어를 맞춰줄 뿐, 판단을 대신하지 않는다. MCP 서버가 연결되어 있어도 권한 설계가 엉망이면 위험하고, A2A로 에이전트들이 대화할 수 있어도 잘못된 목표를 공유하면 함께 엉뚱한 방향으로 달릴 수 있다. 연결 표준은 도로를 깔아준다. 하지만 속도 제한, 신호등, 운전면허, 보험은 여전히 필요하다.

개인 에이전트와 로컬 에이전트의 안전장치

앞으로 에이전트는 회사 시스템뿐 아니라 개인의 일상에도 깊숙이 들어올 것이다. 상시 실행 개인 에이전트는 이메일을 읽고, 첨부파일을 정리하고, 캘린더를 조정하고, 메신저 알림을 요약하고, 온라인 양식을 대신 작성할 수 있다. 로컬 에이전트는 사용자의 노트북이나 스마트폰 안에서 파일을 검색하고, 앱을 실행하고, 시스템 설정을 바꾸고, 코드나 스크립트를 실행할 수 있다.

이것은 매우 편리하다. 동시에 꽤 무섭다. 내 컴퓨터 안에서 일하는 에이전트는 나보다 빠르게 많은 파일을 열 수 있고, 나보다 빠르게 많은 메일을 보낼 수 있으며, 나보다 빠르게 많은 실수를 할 수도 있다.

그래서 개인 에이전트와 로컬 에이전트에는 다음 안전장치가 기본값이 되어야 한다.

최소권한 원칙: 에이전트에게 필요한 권한만 준다. 메일 요약 에이전트에게 메일 발송 권한까지 줄 필요는 없다.
작업별 승인: 조회는 자동으로 하더라도 발송, 결제, 삭제, 외부 공유는 별도 승인을 받게 한다.
민감 데이터 격리: 주민번호, 카드번호, 의료 정보, 비밀문서 같은 데이터는 모델 입력이나 외부 API로 흘러가지 않게 분리한다.
실행 전 미리보기: 에이전트가 보낼 이메일, 수정할 파일, 삭제할 항목을 사용자가 먼저 볼 수 있게 한다.
되돌리기 기능: 잘못된 수정이나 이동을 이전 상태로 복구할 수 있어야 한다.
행위 기록: 언제 어떤 파일을 열었고, 어떤 명령을 실행했고, 어떤 메시지를 보냈는지 남긴다.
예산과 시간 제한: 무한 반복, 과도한 API 호출, 장시간 작업을 막기 위해 토큰·비용·시간 한도를 둔다.

에이전트에게 권한을 준다는 것은 신뢰한다는 뜻이 아니다. 신뢰하되, 제한하고 기록한다는 뜻이다. 사람 직원에게도 회사 법인카드, 고객정보, 관리자 비밀번호를 한꺼번에 주지 않는다. 디지털 동료에게도 같은 원칙이 필요하다.

좋은 위임법: 단계가 아니라 결과를 맡기기

에이전트를 잘 쓰는 사람은 명령을 길게 쓰는 사람이 아니다. 목표를 정확히 주는 사람이다. 기존 자동화에서는 '이 버튼을 누르고, 저 값을 복사하고, 이 칸에 붙여넣어라'가 중요했다. 에이전트에게는 '무엇이 끝난 상태인가'를 알려주는 편이 더 중요하다.

나쁜 요청은 이렇다.

"웹사이트에 들어가서 표를 복사하고 엑셀에 붙여넣고 그래프를 만들어줘."

이 요청도 처리할 수는 있지만, 에이전트는 절차에 묶인다. 웹사이트 구조가 바뀌면 흔들린다. 더 좋은 요청은 이렇다.

"지난 6개월간 경쟁사 세 곳의 가격 변화를 비교해줘. 출처 링크를 남기고, 우리 제품 가격 조정에 영향을 줄 만한 변화만 요약해줘. 확실하지 않은 수치는 추정하지 말고 '확인 필요'로 표시해줘."

두 번째 요청에는 목표, 범위, 산출물, 품질 기준, 금지 행동이 들어 있다. 에이전트가 스스로 검색 경로를 바꿀 여지가 있고, 동시에 함부로 단정하지 못하게 제약도 걸려 있다.

조직이 첫 에이전트를 도입할 때는 다음 순서가 좋다.

작고 반복적인 업무를 고른다: 한 번 실패해도 큰 피해가 없고, 자주 발생하며, 결과 확인이 가능한 업무가 좋다.
완료 조건을 정의한다: 보고서인지, 티켓 생성인지, CRM 업데이트 초안인지 산출물을 분명히 한다.
필요한 도구만 연결한다: 처음부터 모든 시스템을 열지 않는다. 조회 권한부터 시작한다.
승인 지점을 정한다: 외부 발송, 결제, 삭제, 대량 수정 전에는 사람을 넣는다.
그림자 모드로 시험한다: 처음에는 에이전트가 실제 실행하지 않고 '했을 법한 행동'을 기록하게 한다.
로그를 보고 개선한다: 어떤 단계에서 막혔는지, 어떤 데이터가 부족했는지, 어떤 지시가 애매했는지 조정한다.

처음부터 완전 자율 에이전트를 만들려고 하면 실패할 가능성이 높다. 좋은 에이전트 도입은 어린 운전자를 고속도로에 바로 내보내는 일이 아니다. 빈 주차장에서 조작을 익히고, 동네 도로를 달리고, 보조석에 감독자를 태운 뒤, 점차 운전 범위를 넓히는 과정에 가깝다.

향후 5년: 감독형 자율성이 표준이 된다

에이전틱 AI의 미래를 상상하면 두 극단이 떠오른다. 하나는 모든 업무를 AI가 알아서 처리하는 완전 자동 회사다. 다른 하나는 보안과 책임 문제 때문에 에이전트가 결국 장난감으로 남는 미래다. 실제 미래는 그 중간, 즉 감독형 자율성에 가까울 가능성이 크다.

감독형 자율성이란 에이전트가 많은 실행을 맡되, 목표·권한·정책·예외 판단은 인간과 시스템이 함께 통제하는 방식이다. 에이전트는 반복 트랜잭션을 처리하고, 여러 시스템을 오가며 정보를 정리하고, 낮은 위험의 의사결정을 자동화한다. 사람은 정책을 정하고, 예외를 판단하고, 책임이 큰 결정을 승인한다. 시스템은 권한, 로그, 규칙, 모니터링으로 둘 사이의 경계를 관리한다.

향후 5년 동안 에이전트는 대규모 업무 프로세스의 일부를 상당히 바꿀 것이다. 고객 문의의 1차 처리, 구매 요청의 사전 검토, 보안 이벤트의 초기 분석, 매출 보고서 초안, 코드 수정 제안, 일정 조율, 데이터 정리 같은 업무는 점점 더 에이전트에게 넘어갈 가능성이 크다. 하지만 복잡한 책임 판단, 윤리적 결정, 조직 간 갈등 조정, 법적 약속, 고위험 예외 처리는 여전히 인간의 영역으로 남을 것이다.

결국 에이전틱 AI의 본질은 'AI가 인간을 대체한다'가 아니다. 더 정확히 말하면 '업무의 실행 단위가 재편된다'에 가깝다. 사람은 더 이상 모든 클릭과 조회와 복사를 직접 하지 않는다. 대신 목표를 정의하고, 에이전트를 배치하고, 결과를 검토하고, 예외를 판단하는 쪽으로 이동한다.

AI가 답변에서 실행으로 넘어가는 순간, 조직의 질문도 바뀐다.

"AI에게 무엇을 물어볼까?"에서 "AI에게 어떤 일을 맡길까?"로.

그리고 다음 질문은 더 흥미롭다.

한 명의 에이전트가 아니라 여러 에이전트가 함께 일한다면, 회사의 운영체제는 어떻게 바뀔까? 다음 장에서는 이 질문을 따라 멀티에이전트와 에이전틱 운영체제의 세계로 들어간다.