직원마다 챗봇 계정은 있습니다. 그런데 월요일 아침 주간 보고서는 여전히 누군가 세 시간을 들여 만들고, 3주째 답이 없는 거래처 목록은 여전히 누군가 엑셀을 뒤져 뽑습니다. 챗봇이 답을 잘 주지 못해서가 아닙니다. 답을 받아 옮기고, 올리고, 다음 주에 또 하는 일이 여전히 사람 몫이기 때문입니다.
이 차이가 챗봇과 AI 에이전트(AI 직원)의 차이입니다. 이 글을 쓴 그린다에이아이는 회사 메신저에서 일하는 AI 직원 Ara를 만듭니다. 그래서 제품 이야기를 하기 전에, 어떤 제품을 고르든 도입 전에 확인해야 할 기준부터 적었습니다.
핵심 요약
- 챗봇은 답을 돌려주고, AI 에이전트는 결과물을 돌려줍니다. 차이는 업무 시스템을 읽고 조작하는지, 그리고 그 과정이 기록되는지에 있습니다.
- 가트너는 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 비용 증가, 불분명한 가치, 부적절한 위험 통제로 취소될 것으로 전망했습니다. 기능보다 통제 설계가 먼저입니다.
- 도입 전에 확인할 것은 여섯 가지입니다. 어디서 일하나, 무엇을 돌려주나, 무엇을 할 수 있나, 어디서 멈추나, 무엇이 남나, 데이터를 어디에 두나.
- 시작은 팀 하나, 업무 두세 개입니다. 회사 밖으로 나가는 일은 사람이 승인하는 구조로 시작합니다.
챗봇·코파일럿·RPA·AI 에이전트는 무엇이 다른가
AI 에이전트는 목표를 받으면 필요한 도구를 골라 여러 단계를 스스로 실행하고, 결과물과 실행 기록을 남기는 AI입니다. 부서의 반복 업무를 맡기는 기업용 AI 에이전트를 "AI 직원"이라고 부르기도 합니다.
| 구분 | 누가 시작하나 | 돌려주는 것 | 업무 시스템 조작 | 기록 | 잘 맞는 일 |
|---|---|---|---|---|---|
| 챗봇 | 사람의 질문 | 답(글) | 하지 않음 | 대화 기록 | 질문·요약·번역 |
| 코파일럿 | 작업 중인 사람의 호출 | 제안(문장·코드) | 사람이 적용 | 앱마다 다름 | 문서·코드 작성 보조 |
| RPA | 정해 둔 규칙·일정 | 규칙대로 처리한 입력 | 정해 둔 화면만 | 실행 로그 | 형식이 고정된 반복 입력 |
| AI 에이전트(AI 직원) | 사람의 부탁 또는 일정 | 결과물(파일·초안·보고서)과 실행 기록 | 허용된 도구 안에서 | 실행마다 기록 | 판단이 조금 섞인 반복 업무 |
RPA와 가장 크게 다른 점은 "정해 둔 규칙 밖"을 다룰 수 있다는 것입니다. RPA는 화면의 버튼 위치가 바뀌면 멈추지만, 에이전트는 거래처마다 다른 메일 내용을 읽고 다른 초안을 씁니다. 그만큼 더 많은 일을 할 수 있고, 그만큼 통제가 더 중요해집니다.
하나 더 주의할 것이 있습니다. 가트너는 같은 발표에서 에이전트를 표방하는 수천 곳의 벤더 가운데 실제 에이전트 기능을 갖춘 곳을 약 130곳으로 추정했습니다. 기존 챗봇에 이름만 바꿔 다는 "에이전트 워싱"이 흔하다는 뜻입니다. 아래 여섯 가지 질문은 그 둘을 가르는 데도 쓸 수 있습니다.
도입 전에 확인할 6가지
1. 어디서 일하나 — 새 툴인가, 쓰던 메신저인가
새 툴은 새 습관을 요구합니다. 로그인할 곳이 하나 늘면 처음 몇 주는 쓰다가 결국 원래 방식으로 돌아가는 경우가 많습니다. 반대로 팀이 이미 대화하는 Slack, Microsoft Teams, 카카오톡, 네이버웍스 안에서 부를 수 있으면, 동료에게 부탁하듯 스레드에서 맡기고 결과를 같은 자리에서 받습니다.
벤더에게 물을 것: "우리 팀이 쓰는 메신저에서 부를 수 있나요? 채팅에 붙이고 싶지 않은 부서는 대시보드나 API로만 쓸 수 있나요?"
2. 무엇을 돌려주나 — 답인가, 결과물인가
"거래처별 팔로업 메일은 이렇게 쓰면 좋습니다"라는 답과, 거래처 12곳의 초안이 담긴 파일이 스레드에 올라오는 것은 다른 일입니다. 결과물이 돌아와야 사람의 일이 실제로 줄어듭니다.
한 가지 더 볼 것은 "일하는 방법이 회사에 남느냐"입니다. 팔로업 메일의 톤, 보고서 양식, 확인 기준 같은 방법이 담당자 머릿속이 아니라 파일로 남으면, 담당자가 바뀌어도 다음 실행은 같은 품질로 돌아갑니다.
벤더에게 물을 것: "결과물은 어떤 형식으로 돌아오나요? 우리 회사의 양식과 기준을 어디에, 어떻게 남기나요?"
3. 무엇을 할 수 있나 — 권한은 '빼기'로 설계한다
에이전트가 할 수 있는 일은 연결된 도구가 정합니다. 그래서 권한은 필요한 것을 더하는 방식보다, 연결된 앱마다 쓸 도구를 켜고 끄는 방식이 안전합니다. 꺼 둔 도구는 누구도 쓸 수 없어야 하고, 부서별 동료에게 주는 도구 목록은 회사가 허용한 범위에서 빼기만 할 수 있어야 합니다. 새로 연결한 앱의 기본값은 읽기 전용이 맞습니다.
벤더에게 물을 것: "앱마다 도구를 켜고 끌 수 있나요? 기본값은 읽기 전용인가요? 부서별로 쓸 수 있는 도구를 다르게 정할 수 있나요?"
4. 어디서 멈추나 — 자율성 등급과 사람의 승인
모든 업무에 같은 자율성을 줄 필요는 없습니다. 업무마다 "초안까지만", "확인 후 실행", "직접 실행" 가운데 하나를 고르고, 발송·삭제·결제·배포처럼 회사 밖으로 나가거나 되돌리기 어려운 일은 미리보기와 함께 멈춰 담당자 승인을 기다리게 합니다. 미국 국립표준기술연구소(NIST)의 AI 위험관리 프레임워크도 사람의 감독 절차를 정의하고 문서화하라고 권합니다.
| 업무 예시 | 권하는 등급 | 이유 |
|---|---|---|
| 매주 월요일 주간 보고서 | 직접 실행 | 사내용이고, 틀려도 다음 보고에서 바로잡을 수 있다 |
| 들어온 문의의 답변 초안 | 초안까지만 | 고객이 읽는 문장이라 사람이 다듬어 보낸다 |
| 답 없는 거래처 팔로업 메일 | 확인 후 실행 | 초안은 맡기고, 발송은 담당자가 승인한다 |
| 결제·계약 변경 | 사람이 직접 | 되돌리기 어렵다 |
승인은 누가 할 수 있는지도 확인합니다. 로그인한 사람만 승인할 수 있어야 하고, 자동화에 쓰는 API 키가 자기 요청을 스스로 승인할 수 있으면 안 됩니다.
벤더에게 물을 것: "업무별로 자율성을 다르게 정할 수 있나요? 관리자가 특정 앱의 실행을 항상 승인받게 강제하거나 아예 막을 수 있나요?"
5. 무엇이 남나 — 실행 기록과 감사
에이전트가 무엇을 읽었고, 무엇을 했고, 무엇이 나갔는지 실행마다 남아야 합니다. 실패한 실행도 남아야 합니다. 이 기록은 세 가지에 쓰입니다. 사고가 났을 때 원인을 찾는 감사, 결과가 이상할 때 고치는 디버깅, 그리고 파일럿에서 시간·품질·채택을 재는 측정입니다. 개인정보에 닿은 접근이라면 누가, 언제, 어디서 접근했는지까지 남아야 보안팀의 기준을 통과합니다.
벤더에게 물을 것: "실행 기록을 우리가 직접 볼 수 있나요? 보존 기간을 정하고, 보안 관제 시스템으로 내보낼 수 있나요?"
6. 데이터는 어디에 두나 — 학습 사용, 격리, 배포 위치
마지막은 데이터입니다. 회사 데이터가 요청을 처리하는 데만 쓰이고 모델 학습에 쓰이지 않는지, 회사마다 실행 환경이 격리되는지, 연결 계정의 토큰이 암호화되어 저장되는지를 확인합니다. 업종에 따라서는 배포 위치가 결정적입니다. 클라우드로 충분한 회사도 있고, 사내망이나 완전히 분리된 망 안에 두어야 하는 회사도 있습니다.
벤더에게 물을 것: "우리 데이터가 모델 학습에 쓰이나요? 전용 환경이나 사내망에 설치할 수 있나요?" 보안팀이 물을 질문 전체는 AI 도입 보안성 검토 체크리스트에 정리해 두었습니다.
부서별로 처음 맡기기 좋은 일
새 프로세스를 만들 필요는 없습니다. 지금 매주 하고 있는 일 가운데 고르면 됩니다. 오른쪽 칸이 사람이 남는 자리입니다.
| 부서 | 처음 맡기기 좋은 일 | 사람이 남는 자리 |
|---|---|---|
| 영업 | 답 없는 거래처 팔로업 초안, 미팅 전 회사·담당자 브리핑 | 발송 승인, 협상 |
| 재무·경영지원 | 매주 정해진 시간의 주간 보고, 미수금 현황과 단계별 안내문 | 안내문 발송 승인 |
| 마케팅 | 고객 검색어로 만든 한 달치 콘텐츠 기획, 카드뉴스·배너 초안 | 발행 전 검수 |
| 고객지원·운영 | 문의 분류와 회사 문서 기반 답변 초안, 회의 후 결정·담당·기한 정리 | 답변 최종 확인 |
| 인사·경영진 | 공고 기준에 맞춘 지원서 검토, 출처가 달린 시장 리서치 | 채용·투자 결정 |
| IT·개발 | 배포 후 에러 추이 확인, 고객이 읽을 릴리스 노트 | 게시 승인 |
AI의 효과가 가장 크게 나타나는 곳이 어디인지도 참고할 만합니다. 한 회사의 고객지원 상담원 5천여 명을 추적한 연구에서 AI 도움을 받은 상담원의 생산성은 평균 15% 늘었고, 경력이 짧은 상담원일수록 효과가 컸습니다. 사람이 최종 답변을 고르는 구조에서 나온 결과라는 점도 기억해 둘 만합니다.
예시: AI 직원이 들어온 팀의 한 주
아래는 여러 부서가 AI 직원 하나와 일하는 한 주를 그린 예시입니다. 시간과 업무는 가상입니다.
| 요일·시간 | 부서 | 일어나는 일 | 상태 |
|---|---|---|---|
| 월 09:00 | 재무 | 지난주 매출·지출 주간 보고서가 재무 채널에 올라온다 | 정해진 시간에 자동 |
| 월 11:20 | 영업 | 3주 넘게 답 없는 거래처마다 팔로업 초안이 준비된다 | 승인 대기 |
| 화 08:30 | 고객지원 | 밤새 들어온 문의가 분류되고 답변 초안이 붙어 있다 | 초안 |
| 수 14:00 | 마케팅 | 다음 달 콘텐츠 기획과 카드뉴스 초안이 스레드에 올라온다 | 초안 |
| 목 16:00 | IT | 배포 후 에러 추이를 확인하고 릴리스 노트를 쓴다 | 승인 대기 |
| 금 17:00 | 경영진 | 이번 주 무엇을 읽고, 했고, 내보냈는지 실행 내역이 정리된다 | 정해진 시간에 자동 |
이 표에서 먼저 보셔야 할 것은 AI가 한 일이 아니라 사람이 남아 있는 자리입니다. 사내에서 끝나는 일은 정해진 시간에 돌고, 고객이 읽는 글은 초안으로 멈추고, 회사 밖으로 나가는 일은 승인 앞에서 기다립니다.
도입은 어떻게 시작하나
전사 도입을 먼저 결정할 필요는 없습니다. 순서는 네 단계입니다.
- 진단 상담: 팀이 매주 반복하는 일과 연결할 시스템을 확인합니다.
- 파일럿: 팀 하나가 업무 두세 개를 맡깁니다. 업무 지시서 작성과 시스템 연동을 누가 맡는지 계약 전에 정해 둡니다(Ara는 저희가 맡습니다).
- 확산: 부서별 동료를 추가하고, 승인 규칙과 권한을 조직에 맞게 설계합니다.
- 운영: 매월 실행 기록을 함께 점검하며 맡길 일을 늘리거나 줄입니다.
어떤 업무를 첫 파일럿으로 고를지는 AX 첫 업무 고르는 5가지 기준에 채점표로 정리해 두었습니다. Ara는 이 순서 그대로 도입합니다. 부서별 유즈케이스와 안전 장치는 Ara 소개에서 볼 수 있습니다.
자주 묻는 질문
AI 에이전트와 RPA는 무엇이 다른가요?
RPA는 정해 둔 규칙과 화면 순서를 그대로 반복하고, 형식이 바뀌면 멈춥니다. AI 에이전트는 목표를 받아 필요한 도구를 고르고, 거래처마다 다른 메일이나 문서를 읽어 다른 결과물을 만듭니다. 형식이 완전히 고정된 입력 작업은 RPA가, 판단이 조금 섞인 반복 업무는 에이전트가 잘 맞습니다. API가 없는 옛 화면은 에이전트가 사람처럼 다루게 할 수도 있는데, 이때도 제출 전에는 사람의 승인을 받게 두는 것이 안전합니다.
직원이 AI에게 잘못 시키면 회사 밖으로 나가지 않나요?
통제가 제대로 설계된 에이전트라면 켜 둔 도구만 쓰고, 발송·삭제·결제처럼 밖으로 나가는 일은 미리보기와 함께 멈춰 담당자 승인을 기다립니다. Ara는 앱마다 도구 스위치가 있어 꺼 둔 도구는 누구도 쓸 수 없고, 승인은 로그인한 멤버만 할 수 있습니다.
회사 데이터가 AI 모델 학습에 쓰이나요?
도입 전에 반드시 계약과 설정으로 확인해야 하는 항목입니다. Ara는 고객 데이터를 요청을 처리하는 데만 쓰고 모델 학습에 쓰지 않으며, 워크스페이스마다 격리된 환경에서 실행합니다. 클라우드, 전용 테넌트, 사내망, 완전 망분리 가운데 배포 위치를 고를 수 있습니다.
카카오톡이나 네이버웍스에서도 AI 직원을 쓸 수 있나요?
제품마다 다릅니다. Ara는 Slack, Microsoft Teams, 카카오톡, 네이버웍스를 비롯해 Telegram, Google Chat, Discord 등에서 부를 수 있고, 채팅에 붙이고 싶지 않다면 대시보드만 써도 됩니다. 팀이 쓰는 언어로 답하고, 업무 언어를 정해 두면 보고서와 승인 카드도 그 언어를 따릅니다.
