인공지능 도입

AI 도입 — 은 이미 돌아가는 프로세스 안에 모델을 끼워 넣는 일이지, 그 옆에 별도의 시스템을 세우는 일이 아닙니다. 모델은 회사의 데이터를 읽고 거기에서 규칙성을 찾아 결정을 내놓습니다; 그 결정에 따른 행동은 프로세스가 사는 시스템 — CRM, ERP, 창고 프로그램, POS, 포털, 메신저 — 이 수행합니다.

그래서 프로젝트는 모델을 고르는 데서가 아니라 네 가지 답에서 시작합니다: 어떤 데이터가 있고 상태가 어떤가; 어떤 결정을 내려야 하는가; 그 결정을 누가 무엇으로 수행하는가; 무엇이 나아졌는지를 어떤 숫자로 볼 것인가. 넷 중 하나라도 없으면 모델은 아무도 책임지지 않는 데이터 출처를 하나 더 더할 뿐입니다.

AI가 필요 없는 곳. 규칙이 한 줄로 서술된다면 — «재고가 다섯 개 아래이면 구매팀에 알림» — 그것은 규칙으로 씁니다: 더 싸고, 예측 가능하며, 한 줄씩 검증할 수 있습니다. AI는 기준이 수십 개이고 시간에 따라 바뀌며 사람이 지금까지 «눈대중으로» 결정해 온 곳에 알맞습니다: 문의의 분류, 수요의 추정, 이례적인 처리의 탐지, 형식이 제각각인 문서에서의 항목 추출.

모은 데이터는 바로 쓸 수 있는 상태가 아닙니다: 같은 품목이 세 가지 이름으로 불리고, 단위가 뒤섞여 있고, 절반의 기록에 필수 항목이 없으며, 일부 행은 같은 작업의 중복입니다. 그런 데이터로 학습한 모델은 규칙성을 찾는 것이 아니라 그 무질서를 재현합니다.

AI의 처리 는 여기에서 세 가지 과제를 맡습니다: 기록을 같은 형태로 맞추기, 없는 곳에 기준을 채워 넣기, 그리고 원본 데이터에는 존재하지 않던 카테고리로 대상을 나누기.

• 정규화 — 날짜, 숫자, 단위, 전화번호, 주소, 등록 정보의 통일된 형식
• 이름의 대조 — «케이블 VVGng 3x2,5», «VVG-ng 3*2.5», «케이블 vvgng 3x2.5 GOST»가 하나의 품목으로 모입니다
• 빠진 값의 채움 — 없는 카테고리, 브랜드, 단위를 카드의 나머지 항목으로 추정합니다
• 분류 — 상품은 그룹으로, 문의는 주제로, 결제는 비용 항목으로, 거래처는 세그먼트로 분류됩니다
• 특성의 추출 — 설명에서 사양을 뽑아냅니다: 용량, 무게, 출력, 성분, 유통기한
• 중복 찾기 — 같은 거래처의 카드 두 개나 같은 납품의 문서 두 개를 문자열의 일치가 아니라 항목의 조합으로 찾아냅니다
• 모순의 검사 — 마이너스 재고, 주문일보다 이른 출고일, 품목 합계와 다른 문서 총액

행동: 확신이 높은 수정은 자동으로 적용되고 원래 값과 함께 로그에 기록됩니다; 애매한 것은 낱낱의 메일이 아니라 하나의 목록으로 마스터의 소유자에게 확인을 받으러 갑니다.

이것이 왜 별도의 업무인가

데이터의 품질은 프로젝트 전에 한 번 하는 청소가 아니라 계속되는 프로세스입니다: 마스터는 매일 늘어나고, 공급처는 가격표의 형식을 바꾸며, 매니저는 기존 카드를 찾는 대신 새로 등록합니다. 그래서 정제의 규칙과 모델은 데이터와 함께 시스템에 살면서 적재할 때마다 적용됩니다.

수정마다 작성자 — 규칙 또는 모델 — 와 시각, 옛 값과 새 값이 있습니다. 형식주의가 아닙니다: 이력이 없으면 지난달 리포트가 오늘 왜 다른 숫자를 보여 주는지 확인할 수 없습니다.

결과

마스터가 가지를 치기를 그치고, 상품군과 비용 항목별 리포트가 서로 맞아떨어지며, 데이터 준비가 분석 프로젝트 기간의 대부분을 잡아먹기를 그칩니다.

보통의 리포트는 물어본 것에 답합니다: 월별 매출, 지점별 판매, 창고별 재고. 질문은 사람이 던지므로, 누군가 볼 생각을 한 것만 딱 그만큼 보입니다.

AI의 처리 는 여기에서 방향을 바꿉니다: 모델이 스스로 단면을 훑어보고 지표의 움직임이 예상과 다른 곳을 가져옵니다. «그래프를 그려 줘»가 아니라 «평소와 다른 일이 벌어지는 세 곳은 여기이고, 그것은 이것과 연관돼 있습니다»입니다.

지능형 분석이 하는 일:

• 세그먼트화 — 고객, 판매 지점, 상품이 미리 정해 둔 카테고리가 아니라 실제 행동으로 묶입니다
• 지표의 분해 — 매출의 하락을 카테고리, 지점, 채널, 평균 구매액의 기여로 나눕니다: 정확히 무엇이 주저앉았는지 보입니다
• 사건 사이의 연관 — 주문, 고객, 지점의 어떤 특징이 거부, 반품, 결제 지연, 고객 이탈과 자주 함께 나타나는지
• 위험의 평가 — 주문이 취소될, 청구서가 기한 안에 결제되지 않을, 고객이 구매를 그만둘 확률
• 주목의 순위 — 확인이 필요한 대상의 목록을 가나다순이 아니라 예상 손실순으로 정렬
• 일상 언어로 하는 질의 — 데이터에 말로 묻고, 답에는 반드시 출처와 기간이 붙습니다

행동: 발견한 것은 대시보드에 남지 않고 수신자와 기한이 붙은 과제가 됩니다: 매출이 떨어진 지점을 확인하기, 위험군의 고객에게 연락하기, 반품이 늘어난 카테고리를 점검하기.

반복 업무란 하루에 수십 번 되풀이되고 주의는 필요하지만 전문성은 필요 없는 작업입니다: 메일의 데이터를 카드로 옮기기, 결제를 항목으로 분류하기, 담당자 배정하기, 문서의 구비 여부 확인하기, 상태 찍기.

AI의 처리 는 입력이 정형화되지 않은 곳에 필요합니다: 메일은 말로 쓰였고, 문서는 낯선 형식으로 왔고, 요청은 고객마다 다르게 적혔습니다. 모델이 그런 입력을 구조로 만들면, 그다음은 예측 가능하고 검증할 수 있는 보통의 규칙이 프로세스를 맡습니다.

자동 모드로 넘어가는 것:

• 들어오는 메일과 요청의 분류
• 문의의 주제와 긴급도의 판단
• 담당자와 기한의 배정
• 고객 카드와 거래의 등록
• 문서에서의 데이터 추출
• 문서와 주문·청구서의 대조
• 결제를 항목과 계약으로 분류하기
• 문서 묶음의 구비 여부 확인
• 전형적인 문의에 대한 답변의 작성
• 번역과 문서의 표현 통일
• 양식에 따른 명세와 증명서의 준비
• 설명에 따른 상품 카드 항목의 채움
• 시작 전 요청의 완전성 검사
• 작업 대기열의 우선순위 배치
• 근무조, 하루, 구역별 요약
• 사건에 따른 담당자 알림

행동과 결과: 작업은 시스템이 수행하고 작성자, 시각, 원래 값과 함께 로그에 기록됩니다. 직원은 데이터 입력에서 예외의 처리로 옮겨 갑니다 — 모델이 확신하지 못하거나 오류의 대가가 큰 사례로.

데이터: 거래명세서, 청구서, 확인서, 계약서, 사양서, 지급 지시서, 신청서, 장비 사양서, 첨부가 있는 메일. 형식은 제각각입니다: pdf, 휴대폰 사진, 스캔, 내보낸 파일, 종이 원본.

AI의 처리: 문자 인식, 문서 종류의 판별, 항목과 표 부분의 추출, 품목과 마스터의 대조, 문서를 주문·계약·거래처와 잇기. 항목마다 값과 그에 대한 확신도를 돌려줍니다.

무엇을 추출하는가:

• 양쪽의 등록 정보 — 이름, 등록 번호, 주소, 계좌 정보
• 번호와 날짜 문서의, 그리고 계약·청구서·주문에 대한 참조
• 표 부분 — 품목, 수량, 가격, 금액, 세율
• 합계 — 세전 금액, 세금, 결제할 총액, 통화
• 기한과 조건 — 결제 기한, 납품 조건, 보증, 위약금
• 서명과 도장 — 진위가 아니라 유무: 진위는 법적 효력이 있는 문서 관리의 문제입니다

행동: 문서를 주문·청구서와 대조하고, 차이는 목록으로 내놓으며, 문서는 처리되거나 특정 직원의 확인으로 넘어갑니다. 결과: 문서 입력이 별도의 직무이기를 그치고, 차이는 월 마감이 아니라 결제 전에 발견됩니다.

경계는 어디에 있는가

인식은 어떤 문서 묶음에서도 100%의 정확도를 주지 않습니다 — 그럴 필요도 없습니다. 뜻은 다른 데 있습니다: 시스템이 어떤 항목을 믿고 어떤 항목의 확인을 요구하는지 보여 줍니다. 담당자는 문서를 통째로 입력하는 대신 표시된 몇 개 항목만 확인합니다.

원본의 품질이 나쁜 것은 조용한 오류의 핑계가 되지 않습니다: 흔들린 사진, 잘린 페이지, 빠진 사양서 둘째 장은 명시적으로 표시되어 사유와 함께 보낸 쪽으로 되돌아갑니다.

결과

처리 속도가 들어오는 물량에 좌우되기를 그치고, 회계와 구매는 문서의 상태를 직원 각자의 메일함이 아니라 하나의 목록에서 봅니다.

데이터: 메일, 웹사이트의 요청, 메신저의 메시지, 통화의 전사, 지원 채팅의 대화, 후기와 평가. 모두 지금까지 사람이 읽고 분류해 온 자유 형식의 텍스트입니다.

AI의 처리: 문의를 주제와 하위 주제로 분류하고, 긴급도와 어조를 판단하며, 본문에서 주문 번호, 상품명, 주소를 비롯한 개체를 추출하고, 문의를 고객의 이력과 잇습니다. 같은 사유로 반복된 문의는 하나의 사례로 합쳐집니다.

행동: 요청이 항목이 채워진 채로 담당 그룹의 대기열에 들어가고, 대응 기한은 긴급도로 계산되며, 재문의는 우선순위가 올라가고, 고객은 번호와 예상 기한이 담긴 확인을 받습니다.

결과: 문의가 아침까지 공용 메일함에 놓여 있기를 그치고, 책임자는 «불만이 많다»가 아니라 구조를 봅니다: 어떤 주제의 흐름이 늘어나는지, 어디에서 답변 시간이 길어지는지, 어떤 제품이 재문의를 부르는지.

흐름 전체를 뜯어보면 얻는 것

개별 문의는 사례를 말해 주고, 흐름 전체는 제품과 프로세스를 말해 줍니다. 기간별 주제 분류는 무엇이 질문을 부르는지 보여 줍니다: 알기 어려운 안내, 상품 설명의 오류, 주문서 작성의 특정 단계에서의 오류, 한 배송 업체의 지연.

그래서 주제는 머리에서 지어내지 않습니다: 먼저 문의를 뜻에 따라 자동으로 묶고, 그렇게 나온 그룹을 손으로 다듬어 목록으로 고정합니다. 그다음 그 목록은 제품과 함께 살아가고, 새 그룹은 시스템이 제안합니다.

봇은 하나의 모델이 아니라 서로 이어진 여러 부분입니다. 이 구분은 실무적으로 중요합니다: 부분마다 고장의 원인, 지표, 고치는 방법이 다릅니다.

• 질문의 이해 — 사람이 무엇을 하고 싶어 하고 어떤 값을 말했는지: 주문 번호, 날짜, 상품, 주소
• 지식에서의 검색 — 답의 바탕이 될 문서 조각과 기록의 선별
• 시스템에의 접근 — 허용된 작업의 묶음: 주문 조회하기, 요청 만들기, 배송일 바꾸기. 하나하나가 명시적으로 서술되며 봇에게 임의의 행동은 없습니다
• 답의 작성 — 모델은 찾은 것과 시스템에서 받은 것만으로 답을 만듭니다; 출처에 없는 것은 답에 나타나지 않습니다
• 보내기 전의 검증 — 답은 출처와, 행동은 사용자의 권한과 한도와 대조합니다
• 사람에게 넘기기 — 에스컬레이션의 규칙: 낮은 확신도, 반복된 질문, 부정적인 반응, 금지 목록의 주제
• 로그 — 무엇을 물었고, 무엇이 검색됐고, 봇이 무엇을 했으며 무슨 근거로 했는지. 이것이 없으면 불만을 확인할 수 없습니다

연결 채널은 웹사이트와 개인 계정, 메신저, 메일, 음성 인식이 붙은 전화선, 사내 포털과 직원의 업무 화면입니다. 다만 논리는 하나입니다: 채널은 입력의 형태를 바꿀 뿐 봇에게 허용된 일을 바꾸지 않습니다.

답은 어디에서 오는가

봇은 여러분의 문서를 «기억»하지 않습니다 — 질문하는 순간에 그것을 찾아 찾은 것으로 답합니다. 그래서 규정을 고치면 모델을 다시 학습시킨 뒤가 아니라 올리는 즉시 반영되고, 그래서 답마다 출처가 있습니다.

봇은 어떻게 시작하는가

가장 먼저 실제 질문의 묶음을 모읍니다 — 대화, 문의, 사내 채팅에서. 그것으로 시작 전에 봇을 검증합니다: 답을 출처와 맞춰 보고, 오류는 원인별로 살펴봅니다. 그러고 나서야 봇을 사용자에게 여는데, 보통 처음에는 한 그룹에만 엽니다.

사내 어시스턴트는 고객용 봇과 데이터가 다릅니다: 사내 정보를 다루고 특정 직원의 권한 안에서 일합니다. 창고 담당자와 재무 책임자가 같은 질문을 해도 답이 다릅니다 — 볼 수 있는 문서가 다르기 때문입니다.

어시스턴트가 업무 자리에서 하는 일:

• 규정에 따라 답합니다 — 어떻게 작성하는지, 누가 결재하는지, 기한은 얼마인지, 어떤 양식인지를 조항 링크와 함께
• 대상에 대한 요약을 모읍니다 — 고객, 거래, 계약, 주문, 기기: 이력, 남은 질문, 다가오는 기한
• 초안을 준비합니다 — 메일, 견적서, 문의에 대한 답, 과제의 설명, 회의록
• 직원을 대신해 기록합니다 — 통화나 회의의 결과가 과제, 기한, 카드의 갱신으로 바뀝니다
• 요청을 작성합니다 — 인사, 구매, 기술 지원으로: 항목은 스무 칸짜리 양식이 아니라 대화에서 채워집니다
• 근무조 요약을 준비합니다 — 그 기간 동안 구역에서 무슨 일이 있었고, 무엇이 닫히지 않았으며, 무엇이 결정을 필요로 하는지

결과: 직원은 필요한 문서를 찾고, 규정을 떠올리고, 양식을 채우는 데가 아니라 일에 시간을 씁니다. 어시스턴트는 사람을 대신해 결정하지 않습니다 — 준비하는 부분을 덜어 줍니다.

사내 지식은 한곳에 모여 있는 경우가 드뭅니다: 규정은 이 폴더에, 계약은 저 폴더에, 기술 문서는 또 다른 곳에 있고, 답의 절반은 대화 속에 있습니다. 파일 이름으로 하는 검색은 여기에서 통하지 않습니다, 사람이 찾는 것은 문서가 아니라 답이기 때문입니다.

데이터: 규정과 지시, 계약과 부속서, 기술·설계 문서, 매뉴얼, 해결된 문의의 데이터베이스, 회의록, 각종 목록, 대화 보관함 — 소유자와 접근 등급을 밝혀서.

AI의 처리: 문서를 조각으로 나누고 조각마다 뜻으로 색인합니다; 질문은 제목이 아니라 조각과 대조합니다. 답은 찾은 것으로 만들고 인용, 그리고 문서·쪽·개정판에 대한 링크를 함께 붙입니다.

행동과 결과: 직원이 동료를 찾아다니는 대신 몇 초 만에 출처가 붙은 답을 받습니다; 애매한 경우는 인용으로 확인합니다; 오래된 문서는 바로 드러납니다 — 2년 전 개정판에서 답이 왔다면 답에 그대로 적힙니다.

지식베이스를 쓸모 있게 만드는 것

• 하나의 입구 — 출처를 새 저장소로 손수 옮기는 것이 아니라 색인에 연결합니다
• 판과 날짜 — 조각마다 문서의 개정판을 압니다; 현행과 보관본이 구분됩니다
• 권한은 상속됩니다 — 출처 시스템에서 상속되므로 색인이 접근 제한을 우회하는 길이 되지 않습니다
• 사건에 따른 갱신 — 바뀐 문서는 한 달에 한 번의 일정이 아니라 곧바로 다시 색인됩니다
• 피드백 — «답이 도움이 되지 않음»을 화면에서 표시하면 질문과 함께 확인으로 넘어갑니다
• 빈틈이 보입니다 — 출처를 찾지 못한 질문이 목록으로 모입니다: 없는 규정을 쓰라는 과제입니다

지식베이스가 하지 않는 것

문서 관리 시스템을 대신하지도, 진실의 출처가 되지도 않습니다: 법적 효력이 있는 문서는 그것이 서명되고 보관된 곳에 남습니다. 색인은 그것을 찾아 인용하는 방법이지, 따로 살아가는 사본이 아닙니다.

요청은 자유로운 형식으로 어느 채널로든 들어옵니다: 메일, 메시지, 웹사이트의 양식, 전화, 첨부 파일. 도입 전에는 사람이 그것을 읽고 데이터를 시스템으로 옮기고 유형을 정하고 담당자를 배정합니다 — 여기에 몇 분에서 대기열에서의 몇 시간이 걸립니다.

AI의 처리: 요청의 유형을 판별하고, 항목 — 대상, 주소, 기한, 연락처, 계약 번호 — 을 추출하고, 완전성을 확인하고, 긴급도를 평가하며, 요청을 고객과 그의 이력에 잇습니다. 빠진 것은 같은 채널에서 자동으로 되묻습니다.

행동: 요청이 항목이 채워진 채로 시스템에 등록되고, 규칙에 따라 그룹이나 담당자가 배정되고, 기한이 붙고, 번호가 담긴 확인이 발송됩니다. 같은 사유의 중복은 두 번째 요청을 만들지 않고 서로 묶입니다.

결과: 담당자가 완성된 요청을 받아 확인이 아니라 일에서 시작합니다. 접수에서 배정까지의 시간이 누가 언제 공용 메일함을 열었는지에 좌우되기를 그칩니다.

요청의 여정

무엇을 설정하는 것이 중요한가

• 요청 유형의 목록과 담당자 배정 규칙
• 유형마다의 필수 항목 — 그것이 없으면 추가 확인이 작동하지 않습니다
• 계약과 우선순위에 따른 대응 기한
• 같은 사유의 반복 문의를 묶는 규칙

모델은 언제나 틀립니다 — 문제는 얼마나 자주, 어디에서, 그리고 그 대가가 얼마인지입니다. 그래서 도입마다 두 묶음의 숫자가 있습니다: 모델 자체의 품질과 프로세스의 변화. 앞의 것은 엔지니어에게, 뒤의 것은 사업에 중요하며, 둘이 저절로 일치하지는 않습니다.

• 정밀도와 재현율 — 하나의 평균값이 아니라 분류마다 따로: 드물지만 비싼 분류가 흔한 분류보다 중요합니다
• 자동 결정의 비율 — 정해진 확신 기준에서 사람 없이 지나간 작업이 몇 건인지
• 수정의 비율 — 자동 결정 가운데 사람이 취소하거나 고친 것이 몇 건인지
• 작업 시간 — 접수에서 종료까지를, 도입 전의 기준선과 비교해
• 오류의 대가 — 놓치는 것의 대가와 오탐의 대가; 기준은 지표의 보기 좋음이 아니라 이 비율에 맞춰 정합니다
• 데이터의 드리프트 — 시스템을 한 줄도 고치지 않았는데 품질이 떨어지게 만드는 입력 데이터 구성의 변화

확신 기준은 상수가 아니라 조절 손잡이입니다. 그것을 올리면 자동화는 줄고 오류도 줄며, 내리면 그 반대입니다. 값은 해당 프로세스에서 오류가 얼마나 비싼지에 따라 고릅니다.

패널에서 무엇이 보이는가

출시 이후의 운영

모델은 한 번 납품하고 끝나는 것이 아닙니다. 데이터는 바뀝니다: 새 상품, 새 문의 주제, 새 문서 형식, 새 공급처가 생깁니다. 그래서 프로젝트에는 최신 데이터로의 정기적인 품질 점검, 일정이나 기준 미달에 따른 재학습, 그리고 사람이 결정을 고친 사례의 검토가 들어갑니다.

담당자의 수정은 가장 값진 학습 자료입니다: 별도의 묶음으로 모아 다음 학습에 씁니다. 그렇게 시스템은 남의 데이터가 아니라 자기 업무로 나아집니다.