대표가 “AI로 이 업무를 자동화하자”고 결정했는데, 정작 담당자에게 물으면 처리 순서와 예외 기준이 사람마다 다르다는 경우가 많습니다. 이때 필요한 첫 투자는 모델이나 챗봇이 아닐 수 있습니다. 누가 어떤 정보를 받아, 어떤 판단을 거쳐, 누구에게 넘기는지를 기록하고 책임지는 체계를 먼저 만드는 편이 낫습니다.
중소·중견기업의 AX는 AI 기능을 하나 더 붙이는 프로젝트가 아니라, 담당자의 머릿속에 있던 업무를 측정 가능하고 이전 가능한 운영 체계로 바꾸는 일입니다. AI는 그 체계 위에서 반복 입력을 줄이고, 분류를 돕고, 누락을 찾아내며, 사람이 더 빠르게 판단하도록 지원합니다. 업무 기준이 없는 상태에서 AI부터 붙이면 자동화 범위와 책임 소재가 함께 흐려집니다.
이 글의 목적은 “AI를 도입할까 말까”를 추상적으로 논의하는 데 있지 않습니다. 지금 회사가 AI 파일럿을 시작해도 되는지, 아니면 업무 기록과 데이터 정비를 먼저 해야 하는지를 판별하고 실행 순서를 잡는 데 있습니다.
시작점은 AI 아이디어가 아니라 업무 한 단위의 진단이다
“영업 AI”, “생산 AI”, “사내 챗봇”처럼 넓은 이름으로 프로젝트를 시작하면 요구사항이 계속 커지기 쉽습니다. 진단 대상은 부서 전체가 아니라 하나의 업무 흐름으로 좁히는 편이 좋습니다. 예를 들어 주문 접수부터 출고 확정까지, 견적 요청부터 승인까지, 고객 문의부터 담당자 배정까지처럼 시작과 끝이 분명한 흐름을 고릅니다.
이 단계에서 경영진은 해당 업무가 회사 손익, 고객 신뢰, 납기, 리드타임 중 무엇에 영향을 주는지 먼저 정해야 합니다. 실무자는 현재 사용하는 메신저, 엑셀, ERP, 이메일, 종이 문서와 함께 실제 처리 순서를 설명해야 합니다. 리더의 설명만으로 설계하지 않는 이유도 여기에 있습니다. 공식 절차와 현장에서 돌아가는 절차가 다를 수 있기 때문입니다.
진단 단계의 산출물
- 업무의 시작 조건, 종료 조건, 입력물과 결과물
- 담당자, 승인자, 다음 단계 수신자
- 정상 처리 규칙과 자주 발생하는 예외 상황
- 현재 기록 위치와 데이터 누락 구간
- 업무 성과를 판단할 지표와 측정 방법
- AI가 아니라도 먼저 해결할 수 있는 병목 목록
여기서 한 장짜리 업무 흐름도를 만들 수 없다면, AI 요구사항을 확정하기에는 이릅니다. 흐름도를 그릴 때 특정 담당자만 아는 판단이 여러 번 등장하거나, “상황을 보고 알아서 처리한다”가 핵심 단계라면 암묵 운영 비중이 높다는 신호입니다.
AI를 미뤄야 하는 신호와 바로 시험할 수 있는 조건
업무가 사람에게 의존한다고 해서 AI를 영원히 도입할 수 없다는 뜻은 아닙니다. 다만 아래 신호가 많다면 AI 구축보다 기록과 표준화에 먼저 예산과 시간을 배정하는 편이 안전합니다.
| 관찰되는 신호 | 먼저 해야 할 일 | AI를 서두르면 생길 수 있는 문제 |
|---|---|---|
| 주문·발주·상담 내용이 메신저와 개인 파일에 흩어져 있다 | 입력 채널과 필수 항목을 정한다 | AI가 무엇을 기준 데이터로 볼지 정할 수 없다 |
| 같은 품목·고객·상태를 담당자마다 다르게 쓴다 | 코드, 명칭, 상태값의 기준을 합의한다 | 분류와 집계 결과가 서로 충돌한다 |
| 예외 처리를 특정 베테랑만 할 수 있다 | 예외 유형, 판단 근거, 승인 권한을 기록한다 | AI가 틀렸을 때 수정하거나 책임질 사람이 없다 |
| 시스템은 있지만 현장에서 입력하지 않는다 | 입력 부담과 입력 시점을 업무 흐름에 맞춘다 | 빈 데이터가 쌓여 분석과 자동화 모두 약해진다 |
| 자동화가 틀리면 고객, 납기, 정산에 큰 피해가 난다 | 사람 검토와 되돌리기 절차를 설계한다 | 작은 오류가 출고·청구·고객 응대로 번질 수 있다 |
반대로 AI 파일럿을 검토할 조건도 분명합니다. 입력 데이터가 일정한 기준으로 쌓이고, 결과를 맞고 틀림으로 판정할 수 있으며, 애매한 건 사람이 맡는 경계가 정해져 있어야 합니다. 예를 들어 비정형 문장에서 주문 정보를 추출하는 업무라면, AI가 모든 주문을 확정하도록 맡기기보다 신뢰도가 낮거나 필수 항목이 빠진 건을 검토 대기열로 보내는 방식이 적합할 수 있습니다.
핵심은 자동화율이 아닙니다. 틀린 결과가 나왔을 때 누가, 얼마나 빨리, 어떤 근거로 고치는지가 설계되어 있어야 합니다.
표준화 단계에서 결정해야 할 네 가지
업무를 시스템으로 옮길 때 문서만 늘어나는 경우가 있습니다. 이를 피하려면 표준화의 목적을 “설명서 작성”이 아니라 “다음 사람이 같은 기준으로 처리할 수 있게 만들기”로 잡아야 합니다.
첫째, 입력 기준을 정합니다. 누가 어느 시점에 어떤 필드를 입력하는지, 비어 있어도 되는 값은 무엇인지 합의합니다. 이 기준이 없으면 데이터 품질 책임도 생기지 않습니다.
둘째, 상태값과 용어를 통일합니다. 예를 들어 ‘접수’, ‘확인 중’, ‘보류’, ‘완료’가 무엇을 뜻하는지와 상태를 바꿀 권한을 문서화합니다. 같은 단어가 다른 행동을 뜻하면 대시보드와 AI 결과도 신뢰하기 어렵습니다.
셋째, 예외 처리 경로를 만듭니다. 표준 흐름보다 예외가 중요할 때가 많습니다. 재고 불일치, 고객 요청 변경, 승인 지연, 누락 데이터처럼 자주 생기는 예외를 유형별로 분류하고, 담당자와 처리 기한을 정합니다.
넷째, 데이터 책임자를 지정합니다. 시스템 관리자와 데이터 책임자는 같은 사람이 아닐 수 있습니다. 화면이 열리는지 보는 역할과 품목 기준, 고객 정보, 업무 상태의 품질을 결정하는 역할을 구분해야 합니다.
표준화 단계의 산출물
- 업무 흐름도와 역할별 책임표
- 데이터 사전: 항목명, 의미, 허용값, 입력 주체
- 예외 처리 목록과 승인 경로
- 화면·양식·업무 알림의 최소 요구사항
- 데이터 품질 점검 항목과 수정 책임자
이 산출물이 갖춰지면 ERP 개편, 업무 앱 구축, 데이터 통합, AI 에이전트 도입 중 무엇을 먼저 할지도 판단하기 쉬워집니다. 기록이 생기지 않는 것이 문제라면 입력 도구를 바꾸는 일이 먼저입니다. 기록은 있으나 분류와 반복 확인에 시간이 많이 든다면 그때 AI 지원 기능을 검토할 수 있습니다.
AI 요구사항은 기능 목록 대신 통제 조건으로 작성한다
AI 도입 요구사항에 “문의 내용을 분석한다”, “발주를 자동 등록한다”만 적으면 공급자와 내부 팀이 서로 다른 결과를 상상할 가능성이 큽니다. AI가 무엇을 할지뿐 아니라, 무엇을 해서는 안 되는지도 함께 정해야 합니다.
요구사항에는 다음 조건을 포함하는 편이 좋습니다.
- AI가 읽을 데이터와 읽지 말아야 할 데이터는 무엇인가
- AI가 제안만 하는 구간과 자동 확정하는 구간은 어디인가
- 사람이 검토해야 하는 불확실한 결과는 어떻게 표시되는가
- 잘못 등록된 결과를 누가 어떤 절차로 되돌리는가
- 처리 근거, 수정 이력, 승인 이력을 어디에 남기는가
- 모델 오류, 연동 장애, 데이터 누락이 발생했을 때 업무를 계속하는 대체 경로는 무엇인가
- 처리량, 응답 시간, 사용 비용을 누가 어떤 주기로 확인하는가
외부 개발사나 솔루션 사업자와 논의할 때도 데모 화면보다 이 질문에 대한 답을 확인하는 편이 낫습니다. 특히 “데이터가 부족하면 어떻게 시작하는가”, “정확하지 않은 결과를 어디에서 사람에게 넘기는가”, “운영 담당자가 규칙을 바꾸려면 어떤 권한과 교육이 필요한가”를 구체적으로 물어야 합니다.
검증은 정확도 발표가 아니라 업무 변화 확인으로 끝낸다
AI 파일럿은 모델 성능 수치만 보고 종료하기 쉽습니다. 그러나 경영진이 확인할 대상은 AI가 답을 잘했는지에만 그치지 않습니다. 업무가 더 빠르고 안전하게 흘렀는지, 담당자가 오류를 고칠 수 있는지, 고객 대응이나 손익 판단이 개선됐는지를 함께 봐야 합니다.
검증 기간에는 기존 방식과 새 방식을 일정 범위에서 병행하고, 결과를 비교할 수 있게 운영합니다. 이때 AI가 처리한 건, 사람이 수정한 건, 검토 대기열로 보낸 건을 구분해 기록해야 개선 포인트가 보입니다. 사람의 수정이 계속 같은 유형에서 발생한다면 모델을 바꾸기 전에 데이터 기준이나 업무 규칙부터 고쳐야 할 수 있습니다.
검증 단계의 산출물
- 승인·반려·수정 결과가 남는 테스트 기록
- 오류 유형별 원인과 개선 담당자
- 자동 처리 가능 범위와 사람 검토 범위
- 장애·오류 발생 시 수동 전환 절차
- 파일럿 지속, 확장, 중단을 판단하는 기준
AI가 업무를 대신 처리하는 범위를 넓히는 결정은 이 검증 결과를 본 뒤에 내려야 합니다. 특히 고객 안내, 가격, 계약, 출고, 정산처럼 되돌리기 어려운 업무는 보수적으로 시작하는 편이 합리적입니다.
운영 인계의 기준은 매뉴얼 전달이 아니라 첫 수정이다
프로젝트가 끝난 뒤 외부 파트너가 없으면 아무도 규칙을 고치지 못하는 상태라면, 시스템은 곧 이전 방식으로 돌아갈 가능성이 큽니다. 운영 인계에서는 두꺼운 매뉴얼보다 내부 담당자가 실제로 할 수 있는 행동을 남겨야 합니다.
최소한 한 명은 데이터 기준 변경, AI 결과 검토, 오류 신고, 권한 요청, 기능 개선 요청의 창구를 맡아야 합니다. 기술 담당자가 없는 조직이라면 모든 문제를 직접 해결하게 하기보다, 무엇을 확인하고 어떤 정보를 모아 지원을 요청해야 하는지부터 익히게 하는 편이 현실적입니다.
운영 책임자는 첫 장애나 첫 예외 상황을 처리하면서 시스템을 자기 업무로 받아들입니다. 따라서 계약이나 내부 계획에는 안정화 기간, 지원 범위, 수정 요청 절차, 접근 권한, 교육 대상과 인수 기준을 미리 포함해야 합니다.
지금 AI 도입 여부를 결정해야 한다면, 먼저 핵심 업무 하나를 골라 흐름도와 데이터 사전을 만들어 보십시오. 그 문서가 현업과 리더 사이에서 합의되고, 예외가 발생했을 때 누가 판단할지 정해졌다면 AI 파일럿을 시작할 준비가 된 것입니다. 그 단계에 도달하지 못했다면, 그 빈칸을 채우는 일이 AI보다 앞선 AX 투자입니다.
