90일 AX 파일럿 설계

AX는 거대한 선언으로 시작할 수 있지만, 성과는 작은 파일럿에서 증명된다. 첫 파일럿의 목적은 완성된 AI 시스템을 만드는 것이 아니다. 우리 회사의 실제 업무에서 AI가 쓸모 있는지, 안전하게 운영할 수 있는지, 확산할 만한 가치가 있는지를 검증하는 것이다.

90일은 짧다. 그러나 문제를 좁히고, 데이터를 준비하고, 프로토타입을 만들고, 현업 테스트와 성과 평가까지 하기에는 충분한 시간이다. 오히려 90일 안에 검증하지 못하는 과제라면 첫 과제로는 너무 크다.

파일럿은 데모가 아니라 검증이다

많은 기업의 AI 파일럿은 데모에서 끝난다. 회의실에서 몇 가지 질문을 넣어 보고, 그럴듯한 답변이 나오면 성공처럼 보인다. 하지만 실제 업무는 다르다. 데이터가 흩어져 있고, 예외 상황이 많고, 사용자는 바쁘며, 보안과 승인 절차도 필요하다.

따라서 AX 파일럿은 다음 질문에 답해야 한다.

• 이 업무의 문제는 충분히 명확한가?

• AI가 들어갔을 때 업무 흐름이 실제로 줄어드는가?

• 필요한 데이터에 접근할 수 있는가?

• 현업 사용자가 반복해서 쓸 의지가 있는가?

• 품질과 리스크를 관리할 수 있는가?

• 성공하면 다른 부서나 유사 업무로 확산할 수 있는가?

파일럿은 기술 가능성을 보여 주는 행사가 아니다. 업무 변화 가능성을 증명하는 실험이다.

첫 과제는 작고 명확해야 한다

첫 AX 과제는 회사에서 가장 크고 중요한 문제일 필요가 없다. 오히려 너무 큰 문제는 실패 확률이 높다. 여러 부서가 얽혀 있고, 데이터 권한이 복잡하며, 성과가 늦게 나타나기 때문이다.

좋은 첫 과제는 작지만 반복된다. 문제 정의가 분명하고, 데이터가 준비되어 있으며, 현업 담당자가 적극적이다. 실패해도 조직 전체에 큰 피해를 주지 않지만, 성공하면 확산 가능성이 보인다.

예를 들어 다음과 같은 과제가 첫 파일럿에 적합하다.

• 고객지원 상담원이 과거 답변과 정책 문서를 바탕으로 답변 초안을 받는다.

• 영업 담당자가 고객 업종과 이전 제안서를 참고해 제안서 초안을 만든다.

• 인사 담당자가 채용 공고와 지원자 이력서를 기준에 맞게 1차 정리한다.

• 재무팀이 반복되는 증빙 검토 항목을 자동으로 체크한다.

• 경영지원팀이 회의록에서 결정 사항과 후속 과제를 자동으로 정리한다.

반대로 다음 과제는 첫 파일럿으로 위험하다.

• 전사 모든 문서를 한 번에 연결하는 지식 AI

• 고객에게 바로 자동 응답하는 무인 상담 시스템

• 채용 합격 여부를 AI가 단독으로 판단하는 시스템

• 재무·법무 의사결정을 자동 승인하는 시스템

• 기존 ERP, CRM, 그룹웨어를 모두 바꾸는 대규모 프로젝트

첫 과제의 기준은 화려함이 아니다. 검증 가능성이다.

과제 선정의 다섯 가지 조건

90일 파일럿 후보는 다음 다섯 가지 조건으로 평가한다.

이 다섯 조건 중 특히 중요한 것은 현업 참여도다. 데이터가 조금 부족해도 현업이 적극적이면 보완할 수 있다. 반대로 현업이 관심 없으면 좋은 모델을 만들어도 쓰이지 않는다.

파일럿 과제는 현업 책임자가 자기 문제로 받아들여야 한다. IT나 전략 부서가 대신 정한 과제는 현장에서 힘을 잃기 쉽다.

범위는 한 업무 흐름으로 좁힌다

첫 파일럿의 범위는 넓게 잡지 않는다. 한 부서, 한 업무, 한 사용자 그룹, 제한된 데이터 범위로 시작한다.

예를 들어 고객지원 AX를 한다고 해서 고객센터 전체를 바꾸려 하면 안 된다. 다음처럼 좁혀야 한다.

• 대상 업무: 환불·교환 문의 답변 지원

• 대상 사용자: 1차 상담원 10명

• 데이터 범위: 최근 1년 상담 이력, 환불 정책 문서, 제품 FAQ

• AI 역할: 답변 초안 작성과 관련 문서 추천

• 사람 역할: 상담원이 최종 답변 검토 후 발송

• 제외 범위: 자동 발송, 고위험 클레임, 법적 분쟁 상담

범위를 좁히면 세 가지 장점이 있다.

첫째, 데이터 준비가 쉬워진다. 둘째, 품질 평가가 명확해진다. 셋째, 실패했을 때 원인을 찾기 쉽다. AX 파일럿에서 범위를 좁히는 것은 소극적인 선택이 아니다. 성공 확률을 높이는 설계다.

90일 실행 일정

90일 파일럿은 다섯 단계로 나누는 것이 좋다. 핵심은 마지막에 평가 시간을 반드시 남겨 두는 것이다. 많은 파일럿이 개발에 시간을 모두 쓰고, 정작 성과를 검증하지 못한 채 끝난다.

1~15일: 문제를 숫자로 정의한다

첫 2주는 기술 검토보다 문제 정의가 중요하다. 현재 업무가 어떻게 진행되는지, 어디에서 시간이 걸리는지, 어떤 오류가 반복되는지 확인한다.

이때 반드시 기준값을 잡아야 한다. 예를 들어 답변 작성에 평균 12분이 걸리는지, 문서 검색에 하루 1시간이 드는지, 검토 오류가 월 30건 발생하는지 측정한다. 기준값이 없으면 파일럿 후 성과를 말할 수 없다.

이 단계의 핵심 산출물은 파일럿 차터다. 차터에는 문제, 범위, 목표, 제외 범위, 참여자, 일정, 지표, 리스크를 한 장으로 정리한다.

16~30일: 데이터와 리스크를 먼저 본다

AI 파일럿은 데이터를 연결하는 순간 현실적인 문제가 드러난다. 문서가 오래되었거나, 파일명이 제각각이거나, 권한 체계가 없거나, 개인정보가 섞여 있을 수 있다.

이 단계에서는 다음을 확인한다.

• AI가 사용할 수 있는 데이터는 무엇인가?

• 최신 문서와 폐기 문서를 구분할 수 있는가?

• 개인정보와 기밀정보는 제거하거나 제한할 수 있는가?

• 사용 권한은 직무와 역할에 맞게 나눌 수 있는가?

• 답변 품질을 평가할 샘플 질문과 정답 기준이 있는가?

데이터 준비는 완벽할 필요가 없다. 하지만 최소한 파일럿 범위 안에서는 믿을 수 있어야 한다. 오래된 규정 문서로 답변하는 AI는 없는 것보다 위험하다.

31~50일: 작동하는 프로토타입을 만든다

프로토타입은 완성품이 아니다. 그러나 실제 업무 흐름 안에서 작동해야 한다. 사용자가 별도 화면에 들어가 복잡한 절차를 거쳐야 한다면 사용률은 떨어진다.

프로토타입 설계에서 중요한 것은 네 가지다.

• 입력: 사용자가 무엇을 넣는가?

• 처리: AI가 어떤 데이터와 도구를 사용하는가?

• 출력: 어떤 형식으로 결과를 제공하는가?

• 검토: 사람이 어디서 확인하고 수정하는가?

이 단계에서는 로그 구조도 함께 설계해야 한다. 어떤 질문이 들어왔는지, 어떤 문서를 참고했는지, 답변이 채택되었는지, 사용자가 어떻게 수정했는지 기록해야 한다. 로그가 없으면 개선도 어렵고, 성과 증명도 어렵다.

51~70일: 현업 테스트로 실제 사용성을 본다

파일럿의 승부는 현업 테스트에서 난다. 테스트 사용자는 너무 많을 필요가 없다. 5~20명 정도의 핵심 사용자로도 충분하다. 중요한 것은 실제 업무에서 반복적으로 쓰게 하는 것이다.

현업 테스트에서는 다음을 관찰한다.

• 사용자가 AI 결과를 신뢰하는가?

• 답변을 그대로 쓰는가, 많이 수정하는가?

• 업무 시간이 실제로 줄어드는가?

• 어떤 질문에서 오류가 자주 나는가?

• 사용자가 불편해하는 지점은 무엇인가?

• AI가 업무 흐름을 방해하지 않는가?

이 단계에서는 사용자를 비난하면 안 된다. 사용자가 쓰지 않는다면 이유가 있다. 결과 품질이 낮을 수도 있고, 화면이 불편할 수도 있으며, 기존 업무 방식과 맞지 않을 수도 있다. 파일럿의 목적은 그 이유를 찾는 것이다.

71~90일: 성과와 확산 가능성을 판단한다

마지막 20일은 평가 기간이다. 이때는 처음에 정한 기준값과 비교해야 한다. 막연히 반응이 좋았다는 말로는 부족하다.

성과 평가에는 정량 지표와 정성 피드백을 함께 담는다. 시간 절감률, 오류 감소율, 사용률 같은 숫자와 함께 사용자가 어떤 업무에서 도움을 받았는지, 어떤 상황에서는 쓰기 어려웠는지 기록한다.

또한 확산 비용도 추정해야 한다. 파일럿은 10명이 썼지만, 전사 확산은 500명이 쓸 수 있다. 이때 필요한 라이선스 비용, 인프라 비용, 운영 인력, 교육 시간, 보안 검토 비용을 함께 봐야 한다.

성공 지표는 시작 전에 정한다

파일럿이 끝난 뒤에 지표를 찾으면 대부분 좋은 숫자만 고르게 된다. 성공 지표는 시작 전에 정해야 한다. 그래야 실험이 되고, 의사결정이 가능해진다.

AX 파일럿 지표는 다섯 묶음으로 볼 수 있다.

여기에 리스크 지표도 반드시 포함해야 한다.

• 개인정보 노출 건수

• 금지된 답변 생성 건수

• 사람 검토 없이 처리된 고위험 건수

• 출처 없는 답변 비율

• 사용자가 신고한 오류 건수

AX 파일럿은 성과만 보는 실험이 아니다. 성과와 위험을 함께 보는 실험이다.

현업과 IT는 공동 책임을 져야 한다

AI 파일럿이 실패하는 흔한 이유는 책임이 한쪽으로 쏠리기 때문이다. 현업은 IT가 알아서 만들어 주기를 기대하고, IT는 현업이 요구사항을 명확히 주지 않는다고 느낀다. 이런 구조에서는 파일럿이 도구 구축으로 끝난다.

역할은 나누되 책임은 공유해야 한다.

회의 방식도 단순해야 한다. 주 1회 진행 상황을 보고하고, 주 1회 현업 데모를 한다. 이슈는 문서로 남긴다. 중요한 결정은 누가, 언제, 어떤 근거로 내렸는지 기록한다.

공동 책임의 핵심은 같은 목표를 보는 것이다. IT의 목표가 시스템 완성이고, 현업의 목표가 업무 단축이며, 경영진의 목표가 비용 절감이면 서로 다른 방향으로 움직인다. 파일럿 차터에서 하나의 성공 기준을 합의해야 한다.

사람의 검토 지점을 설계한다

첫 파일럿에서 AI가 단독으로 중요한 결정을 내리게 해서는 안 된다. 특히 고객 응대, 채용, 금융, 의료, 법무, 인사 평가처럼 사람에게 직접 영향을 주는 업무는 반드시 검토자가 있어야 한다.

사람의 검토 지점은 세 가지로 나눌 수 있다.

첫째, 사전 검토다. AI가 사용할 데이터와 규칙을 사람이 정리한다.

둘째, 실행 전 검토다. AI가 만든 답변, 문서, 추천을 사람이 확인한 뒤 사용한다.

셋째, 사후 검토다. 실제 사용 결과와 오류 사례를 모아 다음 개선에 반영한다.

파일럿 단계에서 중요한 것은 속도보다 신뢰다. 신뢰가 생기면 자동화 범위를 조금씩 넓힐 수 있다. 신뢰가 없는데 자동화부터 넓히면 조직은 AI를 위험한 도구로 인식한다.

파일럿 운영 원칙

90일 동안 다음 원칙을 지키면 실패 가능성을 줄일 수 있다.

첫째, 예외를 모두 해결하려 하지 않는다. 파일럿은 전체 업무의 100%가 아니라 반복적이고 대표적인 60~70%를 먼저 다룬다.

둘째, 처음부터 완전 자동화를 목표로 하지 않는다. 초안 작성, 추천, 검토 지원처럼 사람을 보조하는 방식이 첫 단계에 적합하다.

셋째, 사용자의 수정 내용을 기록한다. AI 결과를 사람이 어떻게 고치는지가 가장 좋은 학습 데이터다.

넷째, 보안과 권한을 나중으로 미루지 않는다. 작은 파일럿이라도 실제 데이터가 들어가면 운영 기준이 필요하다.

다섯째, 실패 기준도 정한다. 성과가 없거나 리스크가 크면 중단할 수 있어야 한다. 중단은 실패가 아니라 잘못된 확산을 막는 의사결정이다.

종료 후 판단 기준: 중단, 보완, 확산

90일이 끝나면 세 가지 중 하나를 선택해야 한다.

중단

성과가 작고, 사용률이 낮고, 리스크가 크며, 개선해도 확산 가능성이 낮다면 중단한다. 이때 중요한 것은 배운 점을 남기는 것이다. 어떤 데이터가 부족했는지, 어떤 업무에는 AI가 맞지 않았는지, 어떤 조건이 충족되어야 다시 시도할 수 있는지 정리한다.

보완

성과 가능성은 있지만 품질, 데이터, 사용성, 운영 체계가 부족하다면 보완한다. 예를 들어 답변 품질은 좋지만 사용자가 화면을 불편해한다면 UI를 고친다. 사용률은 높지만 오류가 반복된다면 평가 데이터셋과 검토 기준을 강화한다.

보완은 무기한 연장이 아니다. 추가 30일 또는 60일처럼 기한을 정해야 한다.

확산

성과가 명확하고, 사용자가 반복적으로 쓰며, 리스크가 통제되고, 기술 구조가 재사용 가능하다면 확산한다. 단, 확산은 단순히 사용자 수를 늘리는 일이 아니다. 교육, 운영 지원, 비용 관리, 권한 관리, 품질 모니터링이 함께 가야 한다.

확산 판단에는 다음 기준을 사용한다.

이 기준을 통과하지 못하면 확산하지 않는다. AX에서 가장 위험한 것은 작은 성공을 과대 해석해 성급하게 전사 배포하는 것이다.

90일 파일럿 차터

파일럿을 시작하기 전 다음 항목을 한 문서로 정리한다.

• 과제명

• 담당 부서와 책임자

• 해결하려는 업무 문제

• 현재 기준값

• 파일럿 범위

• 제외 범위

• 사용할 데이터

• AI의 역할

• 사람의 검토 지점

• 성공 지표

• 리스크와 대응 방안

• 참여 사용자

• 90일 일정

• 예산과 필요한 자원

• 종료 후 의사결정 기준

차터는 형식 문서가 아니다. 범위를 지키고, 책임을 나누고, 성과를 판단하기 위한 기준선이다. 파일럿 중간에 요구가 계속 늘어날 때도 차터가 있어야 원래 목표로 돌아갈 수 있다.

작은 성공이 큰 전환의 출발점이다

90일 파일럿의 목표는 작게 이기는 것이다. 그러나 작게 끝나서는 안 된다. 첫 파일럿은 다음 파일럿을 더 빠르게 만들고, 다음 확산을 더 안전하게 만드는 자산이 되어야 한다.

그래서 파일럿이 끝나면 결과물뿐 아니라 운영 자산을 남겨야 한다. 검증된 프롬프트, 평가 데이터셋, 권한 기준, 로그 구조, 사용자 교육 자료, 성과 리포트, 실패 사례가 모두 다음 과제의 기반이 된다.

AX 전환은 한 번에 전사 혁신을 완성하는 방식으로 진행되지 않는다. 작고 명확한 과제에서 시작해, 업무 흐름을 바꾸고, 성과를 증명하고, 재사용 가능한 구조를 쌓아 가는 방식으로 진행된다.

첫 90일은 그 출발점이다. 이 기간에 기업은 AI가 가능한지보다 더 중요한 것을 확인한다. 우리 조직이 AI를 업무 안으로 받아들일 준비가 되어 있는지를 확인한다.