고객지원팀이 문의 답변을 만드는 업무에 AI를 붙였다고 가정해 보겠습니다. AI는 고객의 질문을 읽고 답변 초안을 빠르게 만듭니다. 그런데 담당자는 제품 모델과 계약 조건을 다시 확인하고, 최신 매뉴얼을 찾아 근거를 대조한 뒤, 초안을 메일 시스템에 복사합니다. 승인자는 처음부터 내용을 다시 읽고 발송을 결정합니다.

초안은 빨라졌지만 고객에게 답변하기까지의 전체 시간은 거의 줄지 않습니다. 기존 절차에 AI 초안 확인이라는 단계만 하나 더 생겼기 때문입니다.

이 문제는 더 좋은 모델로 바꾼다고 바로 해결되지 않습니다. AI를 붙이기 전에 한 업무가 어디서 시작해 언제 끝나는지, 누가 무엇을 판단하고 어느 지점에서 기다리는지 먼저 보여야 합니다.

업무 이름은 범위를 설명하지 못합니다

고객지원 AI, 영업 AI, 사내 지식 챗봇 같은 이름은 프로젝트를 시작하기에는 너무 큽니다. 같은 고객지원 안에서도 문의 분류, 제품 찾기, 계약 확인, 답변 작성, 승인과 발송은 서로 다른 데이터와 권한을 사용합니다.

먼저 실제 업무 한 건을 고릅니다. 자주 반복되고, 시작과 완료가 분명하며, 결과가 맞았는지 확인할 수 있는 일이 좋습니다. 고객의 제품 문의에 답변하는 업무라면 다음처럼 시작과 끝을 정할 수 있습니다.

  • 시작: 고객 문의가 지원함에 접수됨
  • 완료: 승인된 답변이 발송되고 문의 상태가 처리 완료로 바뀜

여기서 답변 초안 작성만 잘라 PoC를 만들면 데모는 쉽게 성공합니다. 하지만 제품을 잘못 골랐을 때의 처리, 최신 문서 확인, 승인 대기와 발송 결과는 측정에서 빠집니다. 실제 운영이 느린 이유가 초안 작성이 아니었다면 성공한 PoC도 전체 업무를 개선하지 못합니다.

저는 전사 AI 도입 회의를 바로 시작하지 않습니다. 먼저 완료 여부를 확인할 수 있는 반복 업무 하나를 고르고, 실제 사례 한 건이 지나간 길을 끝까지 그립니다.

한 건의 경로를 여덟 칸으로 적습니다

복잡한 업무 설계 도구부터 준비할 필요는 없습니다. 화이트보드나 표에 다음 항목만 적어도 빠진 경계가 보입니다.

항목확인할 내용
단계문의 접수, 제품 확인, 문서 검색, 초안, 승인, 발송
입력이 단계가 시작되려면 필요한 정보
원본ERP, 계약 시스템, 승인된 문서 등 믿을 기준
시스템실제로 조회하거나 값을 바꾸는 곳
판단자규칙이나 예외를 최종 결정하는 사람
예외정보가 없거나 서로 다를 때 넘길 곳
출력다음 단계에 전달할 결과
대기 시간작업보다 기다림이 길어지는 지점

문서에 적힌 공식 절차보다 최근 완료된 사례를 따라가는 편이 정확합니다. 실제로는 메신저에서 승인을 받고, 개인 폴더의 파일을 열고, 결과를 다시 ERP에 입력하는 우회 단계가 있을 수 있습니다. 이 경로를 빼면 AI는 존재하지 않는 깔끔한 업무를 자동화하게 됩니다.

AI의 의도된 목적과 사용 맥락, 적용 범위와 사람의 감독 역할은 도입 전에 문서화해야 합니다.[1] 모델을 고르기 전 업무의 경계를 적는 일은 별도의 서류 작업이 아니라, 무엇을 시험하고 어디까지 책임질지 정하는 과정입니다.

규칙, 판단, 예외를 같은 자동화로 묶지 않습니다

업무 순서를 그렸다면 각 단계를 세 종류로 나눕니다.

  • 규칙: 제품 ID가 일치하면 해당 주문을 조회하는 일
  • 판단: 고객 질문에 어떤 계약 조건이 적용되는지 결정하는 일
  • 예외: 제품을 특정할 수 없거나 두 시스템의 값이 다른 경우

규칙은 기존 코드나 워크플로 자동화가 더 안정적일 수 있습니다. 문서를 찾고 초안을 요약하는 일은 AI가 잘 도울 수 있습니다. 계약 해석이나 안전과 관련된 답변처럼 실패 영향이 큰 판단은 근거와 함께 사람이 승인해야 합니다.

세 종류를 모두 AI 에이전트가 처리라고 묶으면 문제가 생겼을 때 원인을 찾기 어렵습니다. 모델이 잘못 판단했는지, ERP 값이 오래됐는지, 승인 규칙이 없었는지 구분할 수 없기 때문입니다.

저라면 첫 버전에서 AI가 맡을 범위를 권한이 확인된 문서 검색과 답변 초안 저장까지로 제한합니다. 외부 발송과 ERP 상태 변경은 기존 시스템이 수행하고, 승인자의 명시적 승인 뒤에만 실행합니다. 운영 기록이 쌓인 뒤 자동화 범위를 넓혀도 늦지 않습니다.

사람 승인을 넣었다면 다시 읽게 만들지 않습니다

최종 확인은 사람이 합니다라는 문장만 붙이면 안전해 보입니다. 그러나 승인자가 AI가 사용한 근거를 찾기 위해 다시 여러 시스템을 열어야 한다면 검토 시간은 줄지 않습니다.

승인 화면에는 최소한 다음 정보가 함께 보여야 합니다.

  • AI가 선택한 제품과 고객 문의 원문
  • 사용한 문서의 제목, 버전과 근거 부분
  • 계약·가격처럼 별도 확인이 필요한 값
  • AI가 확신하지 못한 항목과 예외 표시
  • 실제 발송될 답변과 수신자

승인자의 역할은 AI 문장을 처음부터 다시 작성하는 일이 아닙니다. 잘못된 제품과 오래된 근거, 공개하면 안 되는 정보와 예외를 빠르게 판정하는 일입니다. 이 정보가 한 화면에 모이지 않으면 사람 승인은 자동화 뒤에 붙은 수동 작업이 됩니다.

가장 오래 기다리는 구간부터 줄입니다

많은 AI PoC는 답변 정확도나 초안 생성 시간만 측정합니다. 운영에서는 한 건이 완료되기까지 걸린 시간과 다시 되돌아온 비율도 함께 봐야 합니다.

  • 접수부터 발송까지의 전체 시간
  • 사람이 직접 입력하거나 복사한 횟수
  • 근거를 다시 찾느라 되돌아간 횟수
  • 승인 대기 시간
  • 잘못된 제품·문서 선택으로 수정한 비율
  • 예외가 담당자에게 제대로 전달된 비율

도입 전에 현재 업무 흐름과 기준선을 기록하고, 사람과 에이전트가 함께 일할 전체 과정을 설계해야 이후 결과와 비교할 수 있습니다.[2]

초안 생성이 빨라져도 승인 대기가 대부분을 차지한다면 다음 개발 대상은 더 빠른 모델이 아닙니다. 승인자가 확인할 근거를 한곳에 모으거나, 위험이 낮은 문의의 승인 규칙을 줄이는 일이 먼저입니다.

업무를 그리면 만들지 않아도 될 기능이 보입니다

업무 흐름을 그리는 목적은 큰 AI 시스템의 요구사항을 만드는 데만 있지 않습니다. 오히려 AI를 쓰지 않아도 되는 부분을 찾는 데 가치가 있습니다.

제품명이 시스템마다 달라 매번 사람이 찾는다면 먼저 제품 ID를 연결해야 합니다. 최신 문서를 판별할 수 없다면 문서 승인과 폐기 규칙부터 정해야 합니다. 승인자가 모든 답변을 처음부터 다시 읽는다면 위험도에 따라 검토 범위를 나누는 일이 필요합니다.

이 정리가 끝난 뒤에야 모델에 물을 질문도 구체적으로 바뀝니다.

  • 승인된 문서 안에서 제품에 맞는 근거를 찾을 수 있는가
  • 근거가 없거나 값이 충돌할 때 답변을 멈출 수 있는가
  • 승인자가 확인할 항목을 표시할 수 있는가
  • 실제 검토와 전체 처리 시간을 줄이는가

모델 비교는 이 질문을 같은 사례로 시험할 때 의미가 있습니다. 업무 경계가 없는 상태에서 벤치마크 순위만 비교하면 가장 좋은 모델을 골라도 무엇을 맡길지는 남습니다.

사내 AI의 첫 결과물은 챗봇이 아닙니다

사내 AI 도입의 첫 결과물은 화려한 대화 화면보다 한 업무의 현재 경로를 담은 한 장짜리 문서에 가깝습니다. 시작과 완료, 믿을 원본, 값을 바꾸는 시스템, 판단자, 예외와 대기 시간이 한눈에 보여야 합니다.

그 문서에서 가장 오래 기다리고 가장 많이 되돌아오는 구간을 찾습니다. AI는 그중 문서 검색과 초안처럼 불확실성을 다룰 가치가 있는 부분에 쓰고, 정해진 규칙은 기존 자동화로 처리합니다. 외부 발송과 시스템 수정은 실패 영향을 기준으로 승인 범위를 정합니다.

AI 단계를 하나 더 붙이는 것이 목표가 아닙니다. 고객 문의 한 건이 더 적은 복사와 대기, 더 분명한 책임으로 끝나게 만드는 것이 목표입니다. 모델은 그 흐름이 정해진 뒤에 고르는 도구입니다.

출처