기업은 지난 2년간 챗봇 도구, 글 작성 플러그인, 고객 서비스 로봇, 사내 지식 Q&A 등 다양한 AI 도구를 다수 도입했습니다. 그러나 실제로 내재화된 역량은 많지 않습니다. 프롬프트는 여전히 개인 컴퓨터에 남아 있고, 업무 프로세스는 문서의 구석진 곳에 흩어져 있으며, 스마트 에이전트가 도입된 후에도 피드백과 개선이 부족하고, 핵심 인력의 근무 시간은 여전히 동일한 유형의 문의로 가득 차 있습니다. 문제는 종종 모델이 충분히 똑똑하지 않기 때문이 아니라,시스템은 “일하기”를 관리 가능한 직무 역량으로 설계하지 않았습니다.。
먼저 명확히 하자: 채팅 창은 왜 직무로 설정할 수 없나요
챗봇은 한 번의 질문에만 응답하고 종료됩니다. 직무는 작업을 연속적으로 이어 받아야 합니다: 정보 수집, 규칙 판단, 시스템 호출, 상태 반영, 그리고 예외 상황이 발생하면 다시 업그레이드합니다. 출장 경비 정산은 대표적인 사례입니다—사용자가 먼저 “출장 경비를 처리해 주세요”라고 말하다가 중간에 “이번 달 한도가 얼마나 남았나요?”라고 묻고, 이후에 영수증 하나를 추가로 제출할 수도 있습니다. 만약 시스템이 각 대화를 모두 새로운 세션으로 간주한다면, 프로세스가 끊기고 문맥이 유실되며, 나중에 문제가 규칙 오류인지 인터페이스 오류인지 되돌아볼 수 없게 됩니다.
업계에서는 이미 지능형 에이전트를 ‘디지털 직원’으로 구축하는 방식이 도입되어 있습니다. 해당 에이전트에 직무와 사번, 역량 범위 및 업무 기록을 부여하고, 수정 가능한 SOP, 지식베이스, 각종 도구와 실행 흐름까지 갖추어 놓습니다. 오픈소스 측면에서는 OpenBMB 등 기관에서 발표한 StaffDeck이 에이전트를 단순한 프롬프트 문장이 아닌 운영 가능한 리소스 조합으로 정의하고 있습니다. 기업이 자체 개발하거나 맞춤 제작할 때 참고할 만한 것은 제품 명칭이 아니라 바로 이러한 객체 모델입니다.
비즈니스 로직: 시스템에는 최소 일곱 가지 유형의 객체가 있어야 합니다.
디지털 직원 시스템을 구축할 때는 먼저 비즈니스 객체를 사양에 반영한 다음, 모델 선정에 대해 논의해야 합니다.
- 직무 프로파일: 이름 또는 역할명, 사번, 직책, 온라인 상태, 서비스 대상. 파일이 없으면 권한과 평가를 어디에도 연결할 수 없습니다.
- 능력 경계: 어떤 영수증을 읽을 수 있는지, 어떤 필드를 작성할 수 있는지, 무엇을 약속할 수 없는지. 경계는 관리자가 수정할 수 있어야 하며, 프롬프트에 고정적으로 기술되어서는 안 됩니다.
- SOP / 프로세스 기반 스킬: 복잡한 프로세스를 노드로 분할하여 조건 분기, 도구 호출, 지식 검색 및 인력 전환을 지원합니다.
- 지식 본체: 주제, 규칙, 출처, 운영 매뉴얼은 각각 별도로 저장되며, 답변은 반드시 출처를 명시할 수 있어야 하고, 검색은 조정이 가능해야 합니다.
- 도구 접속: HTTP 인터페이스 또는 MCP는 한도 조회, 문서 생성, 상태 변경 등을 위해 사용되며, 단순히 문장 하나만 생성하는 데에 쓰이는 것은 아닙니다.
- 정시 작업: 일일 보고서 집계, 시간 초과 처리 독촉, 재고 점검 등과 같은 주기적 업무는 사용자가 먼저 요청하기를 기다릴 수 없습니다.
- 추적 및 피드백: 라우팅, 단계, 도구, 지식 및 응답을 기록하고, 좋아요와 비평을 표시하며, 인력이 개입하면 다음 번 수정으로 이어집니다.
실제 요청에는 종종 여러 작업이 포함됩니다. 디지털 직원은 먼저 경비 정산 SOP로 진입하여 모든 필드를 수집하고 규칙을 판단한 뒤, 한도 조회 SOP로 전환하여 API를 호출해야 합니다. 사용자가 중간에 정책 관련 질문을 하면 현재 노드를 저장한 후, 답변이 완료된 뒤 원래의 프로세스로 복귀해야 합니다. 규칙을 벗어나는 문제에 대해서는 컨텍스트를 생성자 또는 당직자에게 넘겨야 하며, 근거 없이 무리하게 답변하는 것을 금지합니다.
설계 로직: 역할, 상태 머신, 지식 계층화
역할은 어떻게 전환하나요?
적어도 네 가지 유형의 사람들이 있다:작성자(경험을 직원들에게 고정화한다),관리자(권한 관리, 배포, 할당량),사용자(디지털 직원에게 업무를 배정함),당직자(예외를 이어받음). 생성자는 재고 변경 및 가격 수정 권한을 기본적으로 갖지 않아야 하며, 사용자는 전체 프롬프트와 키를 볼 수 없어야 합니다. 오픈 인터페이스도 계층화되어야 합니다: 계정 수준의 키는 리소스 구성 관리를 할 수 있고, 직원 수준의 키는 세션 생성과 자신의 트래킹 기록 읽기만 가능합니다.
SOP는 상태 머신을 사용하고, 대화 기억만 사용해서는 안 됩니다.
자연어로 초안을 생성할 수 있으며, 실행은 반드시 상태 머신을 따라야 합니다: 현재 노드, 이미 수집된 슬롯, 호출 가능한 도구, 실패 시 재시도, 인력 노드. 작업이 중단된 후에는 컨텍스트를 직렬화하여 원래 노드로 돌아가 계속 진행할 수 있어야 합니다. 여러 SOP는 실시간으로 전환할 수 있지만, 전환 시 “어디서 왔는지와 어떤 확인된 정보를 가져왔는지”를 남겨 두어야 하며, 사용자가 양식을 중복 작성하는 것을 방지해야 합니다. 버전과 브랜치는 롤백이 가능해야 하며, 현장에서 프롬프트 문구 하나만 수정해도 바로 배포되므로 이후에는 절대로 책임을 물을 수 없습니다.
지식을 대용량 혼합 검색으로 만들어서는 안 됩니다.
문서, 장, 페이지, 요약에 따라 탐색 가능한 인덱스를 생성하고, 먼저 정보가 어느 범주에 속할 가능성이 높은지 판단한 뒤 원문을 찾아냅니다. 지식 분류는 제도 기준, 제품 설명, A/S 대응 문구, 예외 사례로 나누어 정리하며, 특정 영역을 대상으로 한 검색이 전역 키워드 검색보다 안정적입니다. 각 답변에는 출처, 규칙 및 업무 주제를 연결하여, 테스트 환경에서는 왜 해당 구간이 일치하는지 확인할 수 있어야 합니다. 검색 디버깅은 더 큰 모델로 교체하는 것보다 문제 해결에 훨씬 더 자주 효과적입니다.
개발 및 구현: 인터페이스, 격리, 모니터링, 검수
런타임 시에는 통합된 진입점을 권장하며, 각 기능이 서로 다른 경로를 따르면서 상태가 이탈되는 것을 방지해야 합니다. 기능 탐지, 격리 실행, 아티팩트 무결성 및 할당량 정산은 런타임에서 처리되어야 하며, 약속에 의존해서는 안 됩니다. 기능을 내부 마켓플레이스에 배포하기 전에 권한 스캔을 실시해야 합니다: 인증 헤더, 환경 변수, 연결 자격 증명 등은 일반 읽기 인터페이스에 포함되어서는 안 됩니다.
- 실행 채널: 동기식 스트리밍은 대화에 적합하며, 비동기식 Run + 이벤트 스트림은 연결 끊김 후 재개와 작업 큐에 적합합니다. 두 방식 모두 동일한 커널을 공유합니다.
- 채널 신분: 위챗, 기업 위챗, Feishu, DingTalk은 접속 경로로 활용할 수 있지만, 직원 신분, 대화 및 트레이스는 반드시 통일되어야 하며, 각 채널마다 별도의 기록 시스템을 구축하는 것은 금지됩니다.
- 안전: 모델 구성은 기존 구성 번호만 참조하며, 공급업체 키는 반송되지 않습니다. 도구 결과는 Trace에 입력될 때 비식별화 처리됩니다.
- 인공 보완: 시간 초과, 낮은 신뢰도, 권한 위반, 사용자의 자발적 인력 전환 등 네 가지 상황 모두에서 컨텍스트를 완전히 이관할 수 있어야 합니다.
검수는 단지 ‘채팅 가능 여부’만 확인해서는 안 됩니다. 반복 가능한 일련의 테스트 케이스를 준비하십시오: 정상적인 폐쇄 루프, 중간에 질문 삽입, 한도 부족, 인터페이스 시간 초과, 권한 외 기록, 출처 없을 시 답변 거부 등입니다. 각 테스트 케이스마다 다음 사항을 검증합니다: 노드가 정상 복구되었는지, 문서가 올바르게 기록되었는지, 트레이스가 완전한지, 예외 상황이 담당자에게 전달되었는지 여부를 확인합니다. 샘플 검사 통과율, 시간 초과 처리율, 근거 없는 답변 횟수는 만족도 별점보다 더 적합한 운영 개시 기준으로 활용될 수 있습니다.
출시 순서: 먼저 반복 작업을 한 번 수행합니다.
처음부터 만능 비서를 만들려고 하지 마세요. 영업 추적 요약, 결재 지연 처리, 제도 관련 질의응답, 또는 경비 사전 심사 등에서 매일 반복되는 30분 이상의 작업 단계를 선정한 뒤, 입력·출력·권한·예외에 대해 각각 네 문장으로 정리하고, 여기에 SOP와 읽기 전용 또는 제한된 쓰기 인터페이스 두세 개를 추가하세요. 주요 데이터가 불완전하거나 승인 노드가 명확하지 않을 경우, 먼저 대상과 상태를 보완한 다음에야 지능형 실행을 적용해야 합니다—불량 데이터가 자동화된 이후에는 회사 전체로 더 빠르게 확산될 뿐입니다.
어떻게 하면 설계가 올바르게 이루어졌다고 볼 수 있을까요? 이제는 그룹 채팅으로 재촉하거나 표를 작성하는 방식이 더 이상 주요 경로가 아닙니다. 회의록, 업무 지시 및 집계는 영수증과 대조하여 표본 검사를 할 수 있습니다. 명확히 설명하기 어려운 상황에는 승급 대상이 마련되어 있으며, 민감한 작업은 누군가가 심사하고 로그를 조회할 수 있습니다. 개발이 적합한지 여부를 판단하려면,같은 SOP가 중단된 후에 복구할 수 있습니까?、답변이 출처로 다시 연결될 수 있는지 알려주시겠습니까?、경계 사례가 다음 번 개정에 포함될 수 있습니까. 이 세 가지가 통과되면, 다시 직무를 확대하는 것이 먼저 많은 채팅 창구를 마련하는 것보다 훨씬 안정적입니다.
디지털 직원 시스템의 기술적 난이도는 대화 생성에 있는 것이 아니라, 직무, 프로세스, 지식, 도구 및 이력 등을 버전 관리가 가능한 소프트웨어 객체로 구현하는 데 있다. 프롬프트는 일주일에 열 번씩 변경할 수 있지만, 객체 모델이 한 번 흩어지면 이후 각 기능마다 별도의 코드를 작성해야 한다. 먼저 이 일곱 가지 유형의 객체와 상태 머신을 정상적으로 구동시켜야만 모델 업그레이드를 감당할 수 있다; 그렇지 않으면 매번 모델을 교체할 때마다 새로운 프로젝트가 되는 것이지, 단순한 구성 변경이 아니게 된다.