AI 에이전트 뜻과 AI 업무자동화의 차이, 기업이 에이전트 구축에서 막히는 지점

AI 에이전트는 답하는 데서 그치지 않고 사내 시스템을 조회하고 판단해 작업을 실행하는 AI입니다. 규칙대로만 움직이는 AI 업무자동화와 달리 상황에 따라 다음 행동을 고릅니다. 기업의 AI 에이전트 구축은 두 번째 에이전트에서 막히고, 원인은 권한과 연결에 있습니다.

올해 초 인사팀에 규정 문의 에이전트를 만들었습니다.

직원이 '육아휴직 중 상여금은 어떻게 되나요?'라고 물으면 취업규칙 제31조를 찾아 답합니다. 월 90건이던 인사팀 문의 응대가 월 30건으로 줄었습니다. 경영진은 '이걸 전 부서에 하자'고 했습니다.

석 달 뒤, 두 번째 에이전트는 아직 없습니다.

IT팀: '총무팀 자산 대장은 ERP에 있어서 에이전트가 읽으려면 연동 개발이 필요합니다.'

총무팀: '그리고 자산 폐기는 승인이 걸려 있어서 에이전트가 처리하면 안 됩니다.'

AX 담당자: '그러면 에이전트가 조회만 하고 승인은 사람이 하면 되지 않나요?'

IT팀: '그 권한 구조를 새로 짜야 합니다.'

첫 에이전트가 쉬웠던 이유는 규정 문서만 읽으면 됐기 때문입니다. 두 번째부터는 시스템 연동, 권한, 승인 문제가 따라옵니다. 기업의 AI 에이전트 구축이 막히는 지점은 대개 여기입니다.

이 글은 AI 에이전트 뜻을 챗봇, AI 자동화와 비교해 정리하고, 왜 두 번째 에이전트에서 막히는지, 어떤 업무부터 어떤 순서로 구축해야 막히지 않는지에 답합니다.

1. AI 에이전트 뜻은 무엇이고 챗봇과 어디가 다른가

먼저 이 글에서 말하는 AI 에이전트의 뜻부터 정리할 필요가 있습니다.

AI 에이전트는 목표를 받으면 필요한 정보를 스스로 조회하고, 다음에 할 일을 판단하고, 시스템에서 작업을 실행하는 AI입니다. 핵심은 '실행'입니다. 챗봇은 묻는 말에 답하고 끝납니다. 에이전트는 답을 찾기 위해 시스템을 열고, 필요하면 결과를 다른 시스템에 입력합니다.

세 가지가 자주 섞입니다. 챗봇, AI 자동화(RPA), AI 에이전트입니다.

AI 업무자동화와 AI 에이전트의 차이가 가장 중요합니다. 둘 다 '자동'이라는 말이 붙지만 성격이 다릅니다.

AI 업무자동화가 하는 일

'매월 말일에 지출 내역을 ERP에서 내려받아 양식에 붙여 재무팀에 보낸다.' 순서가 정해져 있고 매번 같습니다. 양식이 바뀌면 멈춥니다.

AI 에이전트가 하는 일

'이번 달 지출 중 예산 대비 20% 넘게 쓴 항목을 찾아 담당자에게 사유를 물어보고 정리해서 보고해 줘.' 어떤 항목이 걸릴지, 누구에게 물을지, 답이 늦으면 어떻게 할지를 에이전트가 판단합니다.

앞의 것은 손이 많이 가는 일을 대신하고, 뒤의 것은 판단이 필요한 일의 일부를 대신합니다.

기업들은 이미 이 방향으로 움직이고 있습니다. McKinsey의 2025년 조사에서 응답 기업의 62%가 AI 에이전트를 실험하고 있다고 답했고, 23%는 최소 한 개 업무에서 에이전트를 본격 운영 단계로 확장했다고 답했습니다.

실험하는 기업은 많고, 운영 단계까지 간 기업은 넷 중 하나입니다. 그 사이에 이 글이 다루는 두 번째 에이전트 문제가 있습니다.

AI 에이전트는 답하는 AI가 아니라 조회하고 판단해 실행하는 AI입니다.

2. 첫 에이전트는 되는데 두 번째 에이전트는 왜 막히는가

도입부의 회사처럼 첫 에이전트는 몇 주 만에 만들고, 두 번째는 몇 달째 못 만드는 회사가 많습니다. Gartner는 2027년 말까지 에이전트 AI 프로젝트의 40% 이상이 비용과 불분명한 가치 때문에 중단될 것으로 전망했습니다.

저희 팀에서도 고객사의 첫 에이전트와 두 번째 에이전트 계획을 나란히 놓고 보면, 중단되는 이유는 세 가지로 정리됩니다.

이유 1. 첫 에이전트는 문서만 읽었습니다.

규정 문의, 매뉴얼 검색, FAQ 응대는 문서를 읽고 답하면 끝납니다. 시스템에 쓰지 않습니다. 그래서 권한 문제도, 연동 문제도 없습니다. 두 번째 에이전트가 자산 대장, 근태 기록, 견적 이력처럼 시스템 안의 데이터를 다루기 시작하면 처음 보는 문제가 한꺼번에 나옵니다.

이유 2. 권한 구조가 없습니다.

사람은 자기 권한으로 시스템에 들어갑니다. 에이전트는 누구의 권한으로 들어가야 할까요. 관리자 권한을 주면 팀장만 볼 수 있는 급여 정보가 사원에게 답으로 나갑니다. 권한을 안 주면 아무것도 조회하지 못합니다. 질문한 사람의 권한을 그대로 물려받아 그 범위에서만 조회하는 구조가 있어야 하는데, 첫 에이전트에서는 이 구조를 만든 적이 없습니다.

인사팀: '에이전트가 급여 데이터를 읽으면 안 되나요?'

AX 담당자: '읽되, 질문한 사람이 볼 수 있는 범위까지만 읽어야 합니다. 그 구조가 먼저입니다.'

이유 3. 승인 단계를 설계하지 않았습니다.

자산 폐기, 휴가 승인, 발주처럼 실행에 책임이 따르는 업무는 에이전트가 끝까지 처리하면 안 됩니다. 어디까지 에이전트가 하고 어디서부터 사람이 승인하는지 정해야 합니다. 이 설계가 없으면 현업은 '에이전트가 멋대로 처리할까 봐' 반대하고, 보안팀은 '책임 소재가 없다'고 반대합니다.

첫 에이전트가 쉬웠던 회사

규정 문서를 읽고 답하는 에이전트. 시스템 연동 없음, 권한 구조 없음, 승인 설계 없음.

두 번째 에이전트에서 막힌 회사

시스템 데이터를 읽고 입력하는 에이전트. 연동, 권한, 승인 세 가지가 한꺼번에 필요한데 준비된 것이 없음.

두 번째 에이전트가 막히는 이유는 기술이 아니라 권한 구조와 승인 설계가 없기 때문입니다.

3. AI 에이전트 구축은 어떤 업무부터 시작해야 하는가

두 번째 에이전트까지 이어 가는 방법은 첫 에이전트를 고를 때부터 두 번째를 염두에 두는 것입니다. 업무를 고르는 기준은 세 가지입니다.

기준 1. 반복이 많고 측정이 되는 업무

'월 몇 건, 건당 몇 분'으로 적을 수 있어야 합니다. 인사팀 규정 문의(월 90건, 건당 15분), 총무팀 비품 신청 처리(월 120건, 건당 10분), 영업팀 기존 고객 문의 회신(월 200건, 건당 20분)처럼 적습니다. 측정이 되면 효과를 보여 줄 수 있고, 효과가 보이면 다음 부서를 설득할 수 있습니다.

기준 2. 조회는 넓고 실행은 좁은 업무

에이전트가 읽어야 할 시스템은 여러 개여도 됩니다. 다만 에이전트가 직접 바꾸는 것은 한 가지로 좁힙니다. 예를 들어 '연차 잔여일 확인 후 승인 요청 생성'은 인사 시스템을 읽고 승인 요청 하나를 만듭니다. 승인은 팀장이 합니다. 이렇게 하면 권한 구조와 승인 설계를 작은 범위에서 먼저 만들어 볼 수 있습니다.

기준 3. 다음 에이전트와 데이터를 공유하는 업무

첫 에이전트가 읽기 시작한 데이터를 두 번째 에이전트도 쓰게 고릅니다. 인사 규정 문의 에이전트가 취업규칙과 인사 시스템을 읽게 만들었다면, 두 번째는 같은 데이터를 쓰는 입사자 온보딩 에이전트로 갑니다. 연동을 새로 하지 않아도 됩니다.

구축 순서는 다음과 같습니다.

적용 업무 선정 → 권한 구조 설계 → 승인 단계 설계 → 첫 에이전트 구축 → 4주 운영 기록 → 같은 데이터를 쓰는 두 번째 에이전트

• 적용 업무 선정: 세 기준으로 부서별 반복 업무 두세 개를 적습니다.
• 권한 구조 설계: 에이전트가 질문한 사람의 권한을 물려받아 그 범위에서만 조회하도록 정합니다. 이 단계를 보안팀과 함께 합니다.
• 승인 단계 설계: 에이전트가 끝내는 일과 사람이 승인하는 일을 나눕니다. 처음에는 승인 범위를 넓게 잡습니다.
• 첫 에이전트 구축: 담당자가 자기 업무로 직접 만들거나, 시스템 연계가 필요하면 전문 인력이 맞춤 제작합니다.
• 4주 운영 기록: 몇 건을 처리했는지, 사람이 몇 건을 고쳤는지, 어디서 멈췄는지 기록합니다. 이 기록으로 승인 범위를 조정합니다.
• 두 번째 에이전트: 첫 에이전트가 읽는 데이터를 같이 쓰는 업무로 갑니다.

AI 에이전트 구축은 업무 하나를 자동화하는 일이 아니라, 다음 에이전트가 함께 쓸 권한과 데이터 구조를 만드는 일입니다.

4. 에이전트가 늘어난 다음에 생기는 문제

두 번째 에이전트를 넘기면 세 번째, 네 번째는 빨라집니다. 그때 새로운 문제가 생깁니다. 에이전트끼리 연결되지 않는 문제입니다.

인사팀 에이전트, 총무팀 에이전트, IT팀 에이전트가 각각 따로 돌아가면 입사자 한 명이 들어올 때 세 부서가 각자 에이전트에 같은 정보를 넣습니다. 에이전트는 늘었는데 사람 일은 줄지 않습니다.

에이전트가 늘기만 한 회사

부서마다 에이전트가 있지만 서로 결과를 주고받지 않음. 입사 처리에 세 부서가 각각 입력.

에이전트가 연결된 회사

입사 확정 한 번에 계정 생성, 자리 배정, 교육 일정 등록이 순서대로 실행됨. 사람은 마지막에 확인.

여러 에이전트와 시스템을 하나의 업무 흐름으로 연결하고 순서를 조율하는 것을 오케스트레이션이라고 부릅니다. 에이전트가 하나일 때는 필요 없고, 둘이 되는 순간 필요해집니다. 3장의 구축 순서에서 '같은 데이터를 쓰는 두 번째 에이전트'를 강조한 이유가 여기에 있습니다. 데이터를 공유하는 에이전트는 연결하기 쉽습니다.

비용 문제도 이때 나타납니다. 에이전트가 늘면 AI 사용량이 늘고, 사용자 수 기준 요금제에서는 쓰지 않는 사람의 요금이 확산 예산을 줄입니다. 에이전트 수가 늘수록 사용자 수가 아니라 실제 사용량(토큰) 기준으로 비용을 관리해야 어느 에이전트가 얼마나 쓰는지 보입니다.

에이전트가 둘 이상이 되면 구축보다 연결과 비용 관리가 주된 과제가 됩니다.

5. 자주 묻는 질문

AI 에이전트와 AI 업무자동화(RPA)는 같이 쓸 수 있나요?

같이 씁니다. 순서가 정해진 반복 작업은 RPA가 빠르고 싸고, 판단이 필요한 부분은 에이전트가 맡습니다. 에이전트가 판단한 결과를 RPA가 시스템에 입력하는 구성이 흔합니다.

AI 에이전트 구축에 개발자가 꼭 필요한가요?

업무에 따라 다릅니다. 문서를 읽고 답하거나 정해진 화면에서 작업하는 에이전트는 담당자가 화면 녹화로 자기 업무를 가르쳐 직접 만들 수 있습니다. ERP, 인사 시스템처럼 사내 시스템과 연계가 필요한 에이전트는 개발 인력이 맞춤 제작합니다.

에이전트가 틀린 판단을 하면 누가 책임지나요?

승인 단계를 둔 업무는 승인한 사람이, 에이전트가 끝까지 처리한 업무는 그 범위를 정한 회사가 책임집니다. 그래서 처음에는 승인 범위를 넓게 잡고, 운영 기록을 보며 줄여 갑니다. 모든 처리 내역이 기록으로 남아야 어디서 틀렸는지 찾을 수 있습니다.

사내 데이터를 읽는 에이전트는 보안상 위험하지 않나요?

읽는 범위를 어떻게 정하느냐에 달렸습니다. 질문한 사람의 권한을 물려받아 그 범위에서만 조회하면, 사람이 직접 시스템을 보는 것과 같은 범위입니다. 관리자 권한으로 모든 데이터를 읽게 하는 구성이 위험합니다.

첫 에이전트로 가장 많이 고르는 업무는 무엇인가요?

인사 규정 문의 응대가 가장 많습니다. 문의가 많고, 규정 문서가 이미 있고, 답이 틀리면 바로 드러나기 때문입니다. 다만 두 번째 에이전트를 생각하면 처음부터 인사 시스템을 함께 읽게 만드는 편이 좋습니다.

6. 우리 회사 에이전트 구축은 어디서 막혀 있을까

☐ 첫 에이전트가 읽는 데이터가 문서뿐인가, 시스템도 포함하는가?

☐ 에이전트가 누구의 권한으로 시스템을 조회하는지 정해져 있는가?

☐ 에이전트가 끝내는 일과 사람이 승인하는 일이 나뉘어 있는가?

☐ 적용 업무가 '월 몇 건, 건당 몇 분'으로 적혀 있는가?

☐ 두 번째 에이전트가 첫 에이전트와 같은 데이터를 쓰도록 계획돼 있는가?

☐ 에이전트별 처리 건수와 사용량이 기록되고 있는가?

이 질문 중 절반 이상에 답하기 어렵다면, 에이전트 기술이 아니라 권한과 승인 구조가 정리되지 않은 상태입니다.

그래서 AX 담당자가 먼저 물어야 할 질문은 '어떤 에이전트를 만들까'가 아닙니다.

에이전트가 누구의 권한으로 어디까지 읽을 것인가.

어디까지 에이전트가 하고 어디서부터 사람이 승인할 것인가.

두 번째 에이전트는 첫 번째와 어떤 데이터를 같이 쓸 것인가.

이 세 질문에 답이 나오면 첫 에이전트는 몇 주면 되고, 두 번째 에이전트도 수월하게 구축됩니다.

CLAP Nexus에서는

두 번째 에이전트에서 막히는 이유였던 권한 구조와 승인 설계를, 에이전트마다 새로 만들지 않고 플랫폼에서 한 번에 정합니다.

CLAP Nexus는 맞춤형 에이전트 구축부터 전사 AI 활용 및 관리까지 통제할 수 있는 AX 플랫폼입니다. 직원이 질문하면 에이전트는 그 직원이 볼 수 있는 범위까지만 조회해 답합니다. 사원이 물으면 자기 급여만, 팀장이 물으면 팀원 것까지 나옵니다. 인사팀은 급여 데이터가 다른 부서에 보일 걱정을 덜고, 보안팀은 사람이 보는 범위와 같다는 점을 확인하고 승인합니다.

에이전트는 세 가지 방식으로 만듭니다. CLAP이 만든 에이전트를 설치해 쓰거나, 담당자가 화면 녹화로 자기 업무를 가르쳐 직접 만들거나, 사내 시스템과 연계가 필요한 업무는 CLAP이 맞춤 제작합니다. 모든 에이전트의 처리 내역은 기록으로 남아, 누가 어떤 에이전트로 어떤 업무를 대신했는지 다음 부서가 보고 다시 씁니다. 요금은 사용자 수가 아니라 토큰 사용량 기준이라 에이전트가 늘어도 쓰지 않는 사람의 비용은 생기지 않습니다.

[ CLAP Nexus 더 알아보기 ]

참고 자료

• McKinsey, 「The state of AI」, 2025, https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
• Gartner, 보도자료 「Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027」, 2025, https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027