많은 기업들이 이미 비즈니스 부서에 대규모 모델 계정을 개설해 두었고, 고객 서비스팀에도 챗봇이 도입되었습니다. 석 달이 지나면 흔히 보이는 광경은 다음과 같습니다: 핵심 인력들은 여전히 그룹 채팅에서 제도를 반복해서 설명하고, 결재 처리가 초과되더라도 여전히 사람이 직접 관리하며, 챗봇이 정책 내용을 잘못 전달해도 지식 베이스는 아무도 수정하지 않고, 경영진은 ‘대화 횟수’만 확인할 뿐 실제로 얼마나 일을 처리했는지는 알 수 없습니다. 결국 구매한 것은 AI일 뿐, 관리는 여전히 단순한 도구에 머물러 있습니다; 진짜로 부족한 것은 직무별로 실행 가능한 디지털 동료를 관리하는 것입니다 .

챗봇과 디지털 직원은 관리 대상이 다릅니다
| 차원별 | 챗봇 / 개인 비서 | 직무별 관리되는 디지털 직원 |
|---|---|---|
| 관리 입구 | 애플리케이션 계정, 대화 횟수 | 성명, 직무, 사번, 온라인 상태, 호평률, 성장 기록 |
| 역량의 출처 | 한 문단의 프롬프트, 개인이 저장한 문서 | 직무 파일 + SOP + 지식 베이스 + 도구 + 기억 |
| 업무 수행 방식 | 질문 하나에 답변 하나 | 노드별 실행, 중단·재개·인력 전환 가능 |
| 지식 | 키워드 검색 또는 전체 텍스트를 문맥에 삽입 | 주제, 규칙, 출처, 매뉴얼까지 추적 가능, 검색 조정 가능 |
| 시스템 협업 | 대부분 대화창에 머물러 있음 | 인터페이스를 통해 영수증 처리, 상태 변경, 정기 작업 수행 |
| 리뷰 | 대화 기록으로 책임 분석 어려움 | 트레이스 기록을 통해 경로, 도구 및 근거를 파악하고, 피드백을 반영하여 수정 진행 |
| 평가 | 사용 여부 | 본업이 대체되었는지, 결과를 샘플링할 수 있는지, 예외 상황을 누가 담당하는지 확인 |
업계 오픈소스 프로젝트 StaffDeck은 이 점을 매우 명확하게 밝혔습니다: 기업용 스마트 에이전트의 핵심은 ‘답변을 할 수 있다’는 것이 아니라, 실제 업무를 안정적으로 처리할 수 있는지 여부입니다. 이는 프로세스, 지식, 반복이라는 세 가지 축을 통해, 프로세스가 통제되지 않고, 지식이 추적 불가능하며, 역량이 축적되지 않는 문제를 해결합니다. 기업이 반드시 동일한 제품을 도입할 필요는 없지만, 이 세 가지 신뢰성 요소는 자체 관리 요구사항에 반드시 포함되어야 합니다.
비즈니스 관리는 어떻게 해야 할까요? 신입사원을 관리하듯이, 플러그인을 관리하듯이 하지 말아야 합니다
디지털 직원의 파일을 작성하는 일은 신입사원의 입사 절차와 같은 맥락입니다. 파일에는 최소한 직무 설명서, 서비스 대상, 권한 목록, 지식 범위, 사용 가능한 도구, 금지 사항 등이 포함되어야 합니다. 관리자는 해당 직원이 몇 명을 지원했는지, 몇 건의 업무를 완료했는지, 어떤 유형의 불만이 집중되고 있는지, 최근에 어떤 SOP를 수정했는지 등을 확인할 수 있어야 합니다. 이러한 정보가 없다면, 소위 ‘AI를 도입했다’는 것은 단지 새로운 접근 창구가 생겼을 뿐입니다.
권한 분리는 반드시 서비스 시작 전에 이루어져야 합니다. 금액 조회, 재고 변경, 고객 약속 등 중요한 작업은 기본적으로 인력의 확인을 거쳐야 합니다. 읽기 전용 조회, 업무 촉구, 초안 작성 등은 자유롭게 허용될 수 있지만, 영수증 작성, 마스터 데이터 변경, 외부 발송 등은 반드시 할당량과 승인이 필요합니다. 개인 초안 작성부터 부서 내 재활용에 이르기까지, 어떤 시스템을 호출했는지, 증빙 자료를 가져왔는지 여부를 반드시 검토해야 합니다. 공공 공간이나 템플릿은 초기 비용을 낮출 수 있지만, 원본은 사용자가 직접 수정해서는 안 됩니다—수정은 복제본과 버전에서 이루어져야 합니다.
세 가지 신뢰성 요소는 각각 세 가지 관리 장부에 대응합니다
프로세스 장부: SOP가 과연 완료될 수 있는지 여부
빈번한 클로즈드 루프를 상태 머신으로 표현합니다: 출장 사전 심사, 계약서 인감 확인 촉구, 주문 지연 점검, 고객 서비스 업그레이드 등. 각 노드에서는 무엇을 수집하고, 어떤 인터페이스를 호출하며, 어떤 조건에서 인력으로 전환하는지를 명확히 기록합니다. 사용자가 중간에 추가 질문을 하더라도, 시스템은 진행 상황을 기억하고, 답변 후 원래 노드로 돌아가야 하며, 다시 처음부터 설명하도록 하지 않습니다. 여러 프로세스를 연결하여, 예를 들어 먼저 경비 정산 후 잔액 확인 순서로 진행할 수 있으며, 이미 확인된 필드는 그대로 유지됩니다. 프로세스 장부의 책임자는 비즈니스 매니저이며, 정보화 부서가 따로 ‘로봇 대화 스크립트’를 관리하는 것이 아닙니다.
지식 장부: 답변에 근거가 있는지 여부
제도, 제품 정책, 운영 매뉴얼을 추적 가능한 자산으로 분리합니다. 직원이 “이번 달 출장 예산”을 물으면, 디지털 직원은 제도 조항과 인터페이스 반환값을 명시해야 하며, 그럴듯한 숫자를 만들어내는 것이 아닙니다. 지식 업데이트는 공식 발표를 통해 이루어지고, 개인 위챗으로 파일을 전송해서는 안 됩니다. 검색 결과가 잘못되었다면, 지식 운영팀은 어느 부분이 잘못되었는지 파악한 뒤 구조를 수정해야 하며, 단순히 “더 정확하게 해주세요”라는 프롬프트만 추가해서는 안 됩니다.
반복 장부: 실수가 발생했을 때 되돌릴 수 있는지 여부
완전한 트레이스를 통해 한 번의 실패를 세분화하여 분석할 수 있습니다: 경로 오류, 도구 시간 초과, 지식 만료 등. 좋아요와 비난만으로는 부족하며, 인력이 기록과 경계 사례 목록을 인수해야 합니다. 매주 고정적으로 10개의 실패 경로를 검토하면, 모델 할당량을 또다시 구매하는 것보다 훨씬 더 활용도를 높일 수 있습니다. 반복 장부의 책임자는 비즈니스와 정보화 부서를 동시에 맡아야 하며, “모델이 또 업그레이드됐는데 현장에서는 여전히 같은 실수”라는 상황을 방지해야 합니다.

실행 단계 네 가지를 통해 사람 관리에서 직무 관리로 전환합니다
- 특정 직무의 반복적인 업무 중 한 부분을 선정합니다 : 영업 회의록, 결재 촉구, 제도 관련 질의응답 또는 경비 사전 심사 등, 목표는 이 부분의 초과근무를 줄이는 것이지, 전사적으로 도우미를 교체하는 것이 아닙니다.
- 입력, 출력, 권한, 예외를 명확히 기록합니다 : 어떤 영수증을 읽고, 어떤 결과를 도출하며, 누가 볼 수 있고 누가 보낼 수 있는지, 누구에게 넘겨야 하는지 명확히 규정합니다. 네 문장으로도 명확히 설명되지 않으면 서비스를 시작해서는 안 됩니다.
- 기존 메인 테이블과 메시지를 받아들입니다 : 기존 테이블이나 촉구 그룹을 대체할 수 있어야만 실제로 사용된다고 볼 수 있습니다. 채팅창에만 머물러 있다면, 현장에서는 여전히 위챗을 사용하게 됩니다.
- 핵심 노드에서 인력 심사를 실시하고, 샘플링 검사를 거친 뒤 확대합니다 : 외부 약속, 재고 변경, 가격 조정 등은 반드시 누군가의 확인을 받아야 합니다. 샘플링 검사 통과율, 시간 초과 처리율, 재작업 횟수를 모니터링합니다.
채널은 위챗, 기업 위챗, Feishu 또는 DingTalk을 연결할 수 있어, 직원들이 기존 업무 창구에서 업무를 배정받을 수 있도록 편리함을 제공하지만, 관리 콘솔은 반드시 하나의 체계로 통합되어야 합니다: 동일한 사번, 동일한 대화, 동일한 트레이스. 그렇지 않으면 “로봇은 그룹에서 한 말을 하고, 시스템에서는 다른 말을 한다”는 문제가 다시 발생할 수 있습니다.
어떻게 관리가 제대로 이루어졌는지 판단하는 방법
네 가지 사항을 살펴봅니다: 본업이 대체되었는지, 즉 사람에게 먹이를 주어야 하는 창구가 하나 늘어났는지 여부; 결과를 샘플링할 수 있는지, 회의록과 촉구가 영수증과 연동되는지 여부; 예외 상황을 누가 담당하는지, 대화창에만 머물러 있지 않은지 여부; 권한이 명확히 규정되어 있고 로그를 확인할 수 있는지 여부. 이번 주에는 한 직무에서 매일 반복되는 30분 이상의 업무를 선정해, 직무 설명서의 ‘인수인계 가능’ 항목에 기록합니다; 다음 주에는 이 부분이 기존 결재나 장부에 연동될 수 있는지 살펴봅니다. 만약 연동되지 않는다면, 우선 프로세스와 마스터 데이터를 보완하고, 모델 확대는 나중에 진행해야 합니다.
디지털 직원을 잘 관리하면, 불명확하거나 놓치거나 같은 문제를 열 번씩 묻는 등의 숨은 손실을 절감할 수 있습니다; 관리를 잘못하면, 오히려 잘못된 정책을 고객에게 더 빠르게 전파하게 될 뿐입니다. 먼저 직무별로 파일을 작성하고, SOP에 따라 처리한 뒤, 경로를 따라 수정하는 것이, “어느 대규모 모델을 사용해야 하는가”를 놓고 논쟁하는 것보다 관리 문제의 본질에 훨씬 더 가깝습니다. 경영진 주간 회의에서 대화량만 보고한다면, 아직도 도구 관리에 머물러 있다는 의미입니다; “촉구 클로즈드 루프 수, 근거 없는 답변 수, 인력 인수 이유”를 보고할 수 있게 된다면, 비로소 디지털 동료가 조직에 통합되었음을 의미하며, 시험 사용 명단에만 머물러 있지 않다는 뜻입니다.