대기업 AX 첫 과제 고르는 법: 중요도보다 통제 가능성과 실패 비용을 먼저 보라

AI 도입 후보를 모아 놓으면 대개 가장 큰 과제가 먼저 눈에 들어옵니다. 전사 고객 상담을 바꾸는 에이전트, 생산 계획을 최적화하는 시스템, 여러 조직의 문서를 통합하는 지식 플랫폼처럼 경영진이 설명하기 좋은 과제들입니다.

하지만 대기업 AX의 첫 과제로는 이런 일이 오히려 위험할 수 있습니다. 업무 영향은 크지만, 필요한 데이터가 여러 조직에 흩어져 있거나 예외 규칙이 현업의 경험에만 남아 있거나, 잘못된 결과가 곧 고객 피해·생산 차질·재무 오류로 이어질 수 있기 때문입니다.

첫 과제는 “가장 중요한 문제”가 아니라 “우리 조직이 통제할 수 있는 문제”로 골라야 합니다. 여기서 통제한다는 말은 담당 팀이 데이터 접근권, 업무 담당자, 검토 절차, 결과를 되돌리는 방법을 확보했다는 뜻입니다. 이 조건을 갖춘 작은 업무를 끝까지 운영해 본 경험이 있어야, 이후 더 큰 자동화의 범위와 위험을 현실적으로 판단할 수 있습니다.

첫 과제의 우선순위는 임팩트 하나로 정하지 않는다

AI 후보 과제를 평가할 때 비즈니스 임팩트만 높은 순서로 줄 세우면, 준비되지 않은 대형 과제가 앞에 옵니다. 탐색 단계에서는 아래 네 축을 함께 봐야 합니다.

판단 축	먼저 할 과제의 조건	뒤로 미룰 신호
데이터 통제력	필요한 데이터의 위치, 형식, 책임자가 비교적 명확하다	어느 시스템이 기준 데이터인지 조직마다 다르다
업무 흐름 통제력	시작, 처리, 검토, 완료 기준을 한 팀 또는 명확한 책임자가 관리한다	여러 부서가 각자 다른 방식으로 처리하고 승인권도 나뉘어 있다
실패 비용	틀린 결과를 사람이 검토하거나 원복할 수 있다	오류가 고객 약속, 생산 중단, 계약, 금전 처리로 바로 이어진다
효과 검증 가능성	처리 시간, 누락 건수, 재작업, 검토량처럼 전후 비교할 지표가 있다	무엇이 좋아졌는지 측정할 기준이 없고 만족도만 남는다

이 네 축은 높은 점수를 받은 과제를 찾기 위한 체크리스트라기보다, 선행 조건이 비어 있는 과제를 찾아내는 장치에 가깝습니다. 임팩트가 큰데 데이터 통제력이 낮다면, 그 과제를 포기하라는 뜻은 아닙니다. AI 구현보다 먼저 데이터 책임자와 기준값을 정해야 한다는 뜻입니다.

예를 들어 계약서, 보고서, 점검 기록처럼 문서가 여러 양식으로 흩어져 있다면, 첫 목표를 “AI가 계약 리스크를 판단한다”로 잡기보다 “문서에서 정해진 항목을 추출하고 같은 형식으로 확인하게 한다”로 좁힐 수 있습니다. 후자는 사람이 결과를 검토하기 쉽고, 어떤 문서에서 오류가 났는지도 추적하기 쉽습니다.

자동화 후보를 세 구역으로 나눠라

후보 업무를 한 목록으로 관리하면, 반복 업무와 고난도 판단 업무가 같은 기준으로 경쟁하게 됩니다. 의사결정 회의에서는 아래처럼 세 구역으로 나누는 편이 낫습니다.

1. 지금 검증할 업무: 반복적이고 되돌릴 수 있는 일

첫 과제로 적합한 것은 사람이 규칙에 따라 반복 처리하지만, 처리 전후를 비교하기 쉬운 업무입니다.

• 정해진 양식의 문서에서 항목을 읽어 등록하거나 분류하는 일
• 여러 시스템에 있는 정보를 모아 담당자가 확인할 목록을 만드는 일
• 정기 보고를 위해 자료를 취합하고 초안을 만드는 일
• 문의 내용을 유형별로 분류하고 담당 부서에 배정하는 일
• 누락, 중복, 형식 오류를 찾아 검토 대상으로 표시하는 일

이 업무들의 공통점은 AI가 최종 결정을 독점하지 않아도 가치를 낼 수 있다는 점입니다. 초안 작성, 분류, 추출, 우선순위 제안까지만 맡기고 승인권은 사람에게 남길 수 있습니다. 오류가 나도 원본 자료와 검토 기록을 보고 수정할 수 있어 학습 비용이 과도하게 커지지 않습니다.

2. 준비와 함께 진행할 업무: 가치가 크지만 기반이 부족한 일

두 번째 구역에는 사업적 중요도는 높지만, 바로 자동화하기 어려운 과제가 들어갑니다. 예를 들어 고객 대응 이력을 종합해 다음 조치를 추천하거나, 구매·재고·생산 데이터를 함께 보고 계획을 돕는 업무가 그렇습니다.

이 과제는 AI 개발을 중단할 이유가 아니라, 목표를 둘로 나눌 이유입니다. 첫 번째 목표는 데이터 정의와 업무 규칙을 확인하는 것입니다. 어떤 시스템의 값이 기준인지, 같은 고객이나 품목을 시스템마다 어떻게 식별하는지, 담당자가 예외로 처리하는 조건은 무엇인지 정리해야 합니다. 두 번째 목표는 제한된 범위에서 추천 또는 시뮬레이션을 검증하는 것입니다.

이 단계에서 중요한 산출물은 화려한 데모보다 업무 사전, 데이터 항목 정의, 예외 목록, 검토 책임자입니다. 이 기반이 없으면 모델을 바꾸거나 에이전트를 추가해도 같은 질문이 반복됩니다.

3. 의도적으로 미룰 업무: 잘못되면 회복하기 어려운 일

다음 유형은 첫 자동화 대상에서 제외하는 편이 안전합니다.

• 법률·계약·재무상 확정 판단을 AI 결과만으로 처리하는 업무
• 생산 설비, 보안 통제, 고객 계정처럼 시스템이 직접 실행하는 업무
• 여러 조직의 KPI와 승인권이 충돌하는 업무
• 전문가도 충분한 자료 없이는 결론을 내리기 어려운 업무
• 과거 데이터가 있어도 당시의 맥락과 예외가 기록되지 않은 업무

특히 “AI가 판단하고 실행까지 하게 하자”는 요구는 판단과 실행을 분리해 검토해야 합니다. 추천의 정확도가 어느 수준인지 확인하지 않은 상태에서 실행 권한까지 주면, 오류의 원인을 데이터, 프롬프트, 업무 규칙, 권한 설정 중 어디에서 찾아야 할지도 불명확해집니다.

먼저 사람이 실행하는 흐름에서 추천 품질과 검토 부담을 확인한 뒤, 제한된 조건의 실행 권한을 검토하는 순서가 낫습니다.

데이터가 있다는 말과 업무를 이해했다는 말은 다르다

프로젝트 초기에 “데이터는 이미 있다”는 답을 자주 듣습니다. 그러나 시스템에 저장된 데이터가 자동화에 바로 쓸 수 있다는 뜻은 아닙니다.

데이터 테이블에는 표준 처리 시간만 있지만, 현업은 긴급 주문일 때 다른 순서로 처리할 수 있습니다. 고객 상태는 CRM에 기록돼도, 실제 대응 우선순위는 담당자의 메모나 팀 내부 관행으로 결정될 수 있습니다. 문서의 상태값은 완료인데, 현업은 특정 첨부파일이 있어야 완료로 인정할 수도 있습니다.

따라서 첫 과제를 고를 때는 데이터 보유 여부보다 아래 질문에 답할 수 있는지 확인해야 합니다.

• 이 업무에서 사람이 입력으로 보는 정보는 무엇인가?
• 담당자가 결과를 승인하거나 반려하는 기준은 무엇인가?
• 정상 흐름에서 벗어난 사례는 누가 어떤 방식으로 처리하는가?
• 시스템 값과 현업 판단이 다를 때 무엇을 기준으로 삼는가?
• 결과가 틀렸을 때 어느 단계에서 멈추고 어떻게 수정할 수 있는가?

답이 문서에 없다면, 현업 인터뷰와 실제 처리 기록을 통해 보완해야 합니다. 이 작업은 AI 도입 이전의 부수 업무가 아닙니다. 자동화 범위를 정하는 핵심 작업입니다.

조기 경고 신호가 보이면 PoC의 목표를 바꿔야 한다

PoC가 막히는 이유를 모델 성능으로만 해석하면, 팀은 더 많은 데이터와 더 큰 모델을 요구하게 됩니다. 그러나 아래 신호가 보이면 기술 실험의 목표를 조정하는 편이 낫습니다.

요구사항이 계속 넓어진다.
처음에는 문서 요약이던 일이, 어느새 검색, 결재, 고객 회신, 시스템 등록까지 포함한다면 범위가 흐려진 상태입니다. 첫 검증에서는 업무 한 건의 시작과 끝을 정하고, 그중 AI가 맡을 단계를 하나 또는 둘로 제한해야 합니다.

정답을 판단할 사람이 없다.
결과가 좋은지 확인할 현업 책임자가 없으면, 정확도와 유용성을 논의할 기준도 없습니다. 이 경우에는 모델 평가보다 먼저 업무 오너를 정해야 합니다.

다른 부서의 데이터가 필요한데 참여 약속이 없다.
기술적으로 연결 가능하다는 말만으로는 부족합니다. 데이터 제공 주체가 컬럼 정의, 갱신 주기, 오류 대응에 참여할 수 있는지 확인해야 합니다. 참여하지 않는 조직의 협력이 핵심인 과제는 경영 차원의 조율 없이는 일정이 멈출 가능성이 큽니다.

성공 기준이 ‘AI처럼 보이는 경험’에 머문다.
대화형 화면이나 에이전트 데모는 이해를 돕지만, 사업 효과를 보장하지는 않습니다. 처리 시간 감소, 누락 감소, 검토 대상 선별, 재작업 감소처럼 운영 과정에서 확인할 수 있는 기준을 하나라도 정하는 편이 낫습니다.

첫 프로젝트는 제품 구매보다 운영 계약에 가깝다

AI 플랫폼이나 외부 개발 파트너를 검토할 때도 기능 목록보다 운영 구조를 먼저 확인해야 합니다. 특히 탐색 단계에서는 다음 질문이 중요합니다.

• AI가 접근할 데이터의 범위와 갱신 방식은 누가 결정하는가?
• 답변·분류·추천의 근거를 담당자가 확인할 수 있는가?
• 잘못된 결과를 수정한 뒤 같은 오류가 반복되지 않게 관리할 방법이 있는가?
• 승인 전에는 초안으로만 남기고, 승인 후에만 시스템에 반영하도록 설계할 수 있는가?
• PoC 종료 뒤 누가 데이터, 규칙, 프롬프트, 권한을 운영하는가?

이 질문에 대한 답은 제품의 성능 비교보다 먼저 받아야 합니다. 첫 과제는 도입 성과를 보여주는 자리이면서 동시에 조직이 AI 결과를 검토하고 수정하는 방법을 배우는 자리이기 때문입니다.

대기업의 AX 로드맵은 크게 그려도 됩니다. 다만 다음 분기에 착수할 첫 업무는 한 팀이 책임지고, 필요한 데이터의 출처를 설명할 수 있으며, 결과가 틀려도 사람의 검토와 원복으로 회복할 수 있는 일로 정하십시오. 그 업무에서 데이터의 빈칸, 현업 예외, 승인 책임, 운영 비용을 확인한 뒤에야 더 어려운 판단과 실행 자동화로 갈 근거가 생깁니다.