AI BUSINESS · 2026.08.27
AI 에이전트, 챗봇에서 멈추면 업무가 자동화되지 않습니다
사내 문서를 잘 찾아 답하는 AI를 만들었다고 해보겠습니다. 직원은 “미수금이 큰 고객을 찾아줘”라고 물을 수 있습니다. 하지만 AI가 목록만 알려주고 담당자가 다시 ERP를 열어 확인하고 CRM에 기록하고 메일을 보내야 한다면, AI는 생겼지만 업무 흐름은 거의 그대로입니다. 실제 자동화는 AI가 회사 시스템과 안전하게 연결될 때 시작됩니다.
챗봇과 업무용 에이전트의 차이
챗봇은 질문을 받고 답을 만드는 것만으로도 역할을 할 수 있습니다. 반면 업무용 에이전트는 답변 이후의 단계가 중요합니다. 필요한 데이터를 찾고, 정해진 규칙을 확인하고, API를 호출하거나 담당자에게 승인 요청을 보내야 합니다.
| 단계 | 챗봇 중심 | 업무 에이전트 중심 |
|---|---|---|
| 데이터 | 업로드한 문서 중심 | ERP·CRM·DB·엑셀·외부 API 조회 |
| 결과 | 답변·요약 | 답변 + 업무 실행 후보 생성 |
| 실행 | 사람이 다른 시스템에서 처리 | API 호출·등록·알림·워크플로 실행 |
| 통제 | 대화 권한 | 사용자·데이터·도구별 권한과 승인 |
| 운영 | 대화 기록 | 입력·판단·도구 호출·결과까지 추적 |
예: 영업팀의 미수금 관리
매주 영업팀장이 미수금 고객을 확인한다고 가정해보겠습니다. 기존에는 ERP에서 자료를 내려받고, 고객별 담당자를 CRM에서 찾고, 엑셀로 우선순위를 정리한 뒤 담당자에게 연락을 요청합니다.
에이전트를 붙인다면 “30일 이상 미수금 중 500만원 이상 고객을 찾아 담당자별로 정리해줘”라는 요청에서 시작할 수 있습니다. 시스템은 ERP에서 미수금을 조회하고 CRM에서 담당자를 확인한 뒤, 연락 초안을 만들고 담당자의 승인 후 업무 목록에 등록할 수 있습니다.
AI가 글을 잘 쓰는지가 아니라 ERP에서 정확한 고객을 읽고, CRM의 올바른 담당자를 찾고, 허용된 작업만 실행하는지가 운영 품질을 결정합니다.
구축 전에 먼저 그려야 하는 5가지
1. 업무의 시작과 끝
“영업을 AI로 자동화”처럼 넓게 잡으면 구현 범위가 끝없이 커집니다. “매일 오전 미수금 고객을 추려 담당자에게 검토 목록을 만든다”처럼 시작 조건과 완료 상태를 명확하게 잡아야 합니다.
2. 읽어야 할 데이터
ERP 주문·매출, CRM 고객·담당자, Google Sheets, 사내 DB처럼 필요한 데이터의 원본을 정합니다. 같은 고객이 시스템마다 다른 이름이나 ID를 쓰는 경우에는 매핑 규칙도 필요합니다.
3. 실행할 도구
조회만 할지, CRM에 메모를 남길지, Slack·메일 알림을 보낼지, ERP에 상태를 변경할지 구분합니다. 에이전트가 사용할 기능을 작은 API나 도구 단위로 제한하면 통제하기 쉽습니다.
4. 사람이 승인할 지점
모든 자동화를 무인으로 만들 필요는 없습니다. 고객에게 실제 메일을 보내거나 가격·계약·환불 정보를 변경하는 작업은 AI가 초안을 만들고 사람이 승인한 뒤 실행하는 구조가 현실적입니다.
5. 실패했을 때의 처리
ERP API가 멈추거나 고객 ID가 매칭되지 않거나 AI가 필요한 값을 확신하지 못할 수 있습니다. 이때 억지로 실행하지 않고 담당자 검토함으로 보내는 경로와 로그가 있어야 합니다.
권한은 ‘AI 사용 가능 여부’보다 더 세밀해야 합니다
직원이 AI에 접속할 수 있다고 해서 모든 사내 데이터를 볼 수 있어서는 안 됩니다. 영업 담당자는 자신이 맡은 고객만 볼 수 있고 재무 담당자는 전체 미수금을 볼 수 있는 식으로 기존 업무 권한을 에이전트에도 반영해야 합니다.
도구 권한도 나눠야 합니다. 예를 들어 ERP 조회는 허용하지만 금액 수정은 금지하고, CRM 메모 등록은 허용하되 고객 발송은 승인 후 가능하도록 설계할 수 있습니다.
처음부터 완전 자동화를 목표로 하지 않는 편이 좋습니다
| 도입 단계 | AI 역할 | 리스크 |
|---|---|---|
| 1단계 | 조회·검색·요약 | 낮음 |
| 2단계 | 업무 초안·실행 제안 | 낮음~중간 |
| 3단계 | 사람 승인 후 API 실행 | 중간 |
| 4단계 | 낮은 위험 업무 자동 실행 | 업무별 관리 필요 |
이렇게 권한을 단계적으로 넓히면 실제 데이터와 예외 사례를 확인하면서 자동화 범위를 늘릴 수 있습니다. 무엇보다 현업이 시스템을 신뢰할 시간을 확보할 수 있습니다.
FDE가 필요한 이유는 모델과 현업 사이에 시스템이 있기 때문입니다
현업은 “미수금 관리를 자동화하고 싶다”고 말합니다. AI 개발자는 모델과 프롬프트를 생각할 수 있습니다. 하지만 실제 구현에는 ERP API, CRM 데이터 구조, 사용자 권한, 승인 절차, 오류 처리, 로그와 운영 비용까지 함께 들어갑니다.
FDE(Forward Deployed Engineer) 성격의 역할은 이 사이를 연결합니다. 업무를 작은 실행 단위로 나누고, 필요한 데이터를 찾아 연결하고, AI가 호출할 도구와 사람의 승인 구간을 설계해 데모가 아니라 실제 업무 흐름으로 만드는 것입니다.
도입 전에 확인할 질문
- AI가 답변만 하면 되는가, 실제 시스템에서 다음 작업까지 해야 하는가?
- 업무에 필요한 원본 데이터는 어디에 있는가?
- 읽기와 쓰기 권한을 각각 어디까지 허용할 것인가?
- 반드시 사람이 승인해야 하는 작업은 무엇인가?
- 실패·누락·중복 실행을 어떻게 발견하고 복구할 것인가?
- 누가 무엇을 실행했는지 나중에 추적할 수 있는가?
FAQ
AI 에이전트가 ERP를 직접 조작하는 건 위험하지 않나요?
아무 제한 없이 모든 권한을 주는 방식은 피해야 합니다. 필요한 조회 API와 제한된 실행 API만 제공하고, 중요한 변경은 승인 단계를 두는 방식으로 위험을 줄일 수 있습니다.
기존 ERP에 API가 없으면 에이전트를 만들 수 없나요?
API가 가장 관리하기 좋지만 시스템에 따라 DB 연동, 파일 교환, RPA 등 다른 방법을 검토할 수 있습니다. 다만 데이터 정합성과 오류 복구를 고려해 연결 방식을 선택해야 합니다.
RAG만 구축하면 업무 에이전트가 되는 건가요?
RAG는 문서나 지식을 찾아 답변에 활용하는 데 유용하지만, 실제 업무 실행에는 ERP·CRM 조회, 도구 호출, 권한, 승인, 로그 같은 별도의 시스템 설계가 필요합니다.
Voxen은 AI와 실제 업무 시스템 사이를 연결합니다
Voxen은 AI 모델을 붙이는 데서 끝내지 않고 데이터 수집·데이터 엔지니어링·AI 자동화·API·대시보드·맞춤 업무 시스템을 실제 프로세스에 연결합니다. ERP·CRM·엑셀처럼 흩어진 데이터와 업무 흐름을 살펴, AI가 어디까지 읽고 판단하고 실행해야 효과가 나는지부터 설계합니다.