AX, 업무자동화 무조건 망하는 방법

세 줄 요약

• 무엇을 넣어 어떤 결과를 받아야 하는지 설명하지 못하면서 개발부터 시작하면 반드시 범위가 폭발한다.
• 실제 업무를 하는 사람을 빼고 AI팀이나 외주사만으로 만들면 데모는 나와도 현업에는 정착하지 않는다.
• PoC 성공은 운영 성공이 아니다. 데이터·권한·비용·예외·KPI·유지보수 담당자가 없으면 확산할수록 더 빨리 망한다.

AX를 망치는 가장 쉬운 방법은 거창한 AI 전략을 세우는 것이 아니다. 최신 모델을 계약하고, 해커톤을 열고, 챗봇과 에이전트를 만든 다음 실제 업무가 무엇이 달라졌는지 아무도 설명하지 못하게 만들면 된다. 화면은 생기고 발표 자료도 채워지지만 일하는 방식은 그대로다.

AI 도입과 AX는 같은 말이 아니다. AI 도입은 도구를 가져오는 일이고, AX는 그 도구 때문에 입력·판단·승인·예외 처리와 성과가 달라지는 일이다. 도구가 설치됐는데 업무가 그대로라면 AX는 시작하지도 않은 것이다.

1. 기능과 아웃풋 요구사항을 제대로 설명할 수 없을 때 액션부터 시작하기

“반복 업무를 AI로 줄이자”는 목표가 아니다. 어떤 자료가 들어오고, 사람이 지금 무엇을 판단하며, 어떤 형식의 결과가 나와야 하고, 틀렸을 때 누가 어떻게 바로잡는지를 설명해야 목표가 된다. 이 설명이 없으면 AI와 개발자는 빈칸을 추측으로 채운다.

힐링페이퍼 인터뷰에는 직원이 Notion 최고 관리자 권한을 요청한 사례가 나온다. 이유를 묻자 AI가 API 발급에 그 권한이 필요하다고 했다는 답이 돌아왔다. AI는 주어진 문제를 풀기 위해 가능한 구현 경로를 제시했을 뿐, 그 권한이 조직 보안상 적절한지, API 없이 해결할 더 작은 방법이 있는지는 결정하지 않았다.

웹서비스를 만들겠다고 시작한 요구도 계속 질문해 보면 스크립트 하나, Claude 스킬 하나, Chrome 확장 하나로 끝나는 경우가 많았다. 문제를 모르면 가장 거대한 구현으로 달려가고, 문제를 알면 가장 작은 도구를 고를 수 있다.

자동화 착수 전에 한 장으로 답해야 하는 것

AX에 관한 한 유튜브 영상은 이 차이를 “기술에서 시작하면 용도를 찾고, 페인포인트에서 시작하면 솔루션을 찾는다”는 구조로 설명한다. 최신 에이전트를 먼저 선택하면 조직 안에서 그 도구를 쓸 만한 일을 찾아다니게 된다. 반대로 매일 한 시간이 사라지는 구간, 반복 오류가 나는 구간, 고객 불만으로 이어지는 구간부터 찾으면 AI가 필요한지조차 나중에 판단할 수 있다.

성공한 자동화는 결과물이 구체적이었다

같은 인터뷰에서 HR 담당자는 여러 면접관과 회의실이 연속으로 비는 시간을 찾아 일정을 잡는 도구를 만들었다. 입력은 날짜와 면접관 목록, 판단은 연속된 공통 빈 시간과 회의실, 출력은 예약 가능한 일정이었다. 사람이 하루 한 시간 이상 쓰던 일이 5분 미만으로 줄었다.

디자이너가 만든 Chrome 확장도 문제와 출력이 선명했다. 사용자 매뉴얼용 화면에서 불필요한 요소를 지우고 임시 문구를 실제 문구로 바꾼 뒤 지정 크기로 캡처하는 도구였다. 회사에 공개하자 같은 작업을 하던 운영팀까지 바로 가져갔다. 자동화가 퍼진 이유는 AI가 화려해서가 아니라 누가 언제 무엇을 얻는지가 한 문장으로 설명됐기 때문이다.

2. 현업을 빼고 AI팀·외주사에게 전부 맡기기

업무를 가장 잘 아는 사람은 대개 자동화를 만드는 사람이 아니다. 중앙 AI팀이나 외주사는 모델과 시스템을 알지만, 월말에 숫자가 왜 뒤집히는지, 어떤 고객 요청이 예외인지, 규정상 무엇을 사람이 승인해야 하는지는 모른다. 현업을 인터뷰 대상이나 최종 사용자로만 두면 가장 중요한 판단 기준이 개발 과정에서 빠진다.

McKinsey의 2025년 조사에서 생성형 AI의 EBIT 영향과 가장 크게 연결된 조직 속성은 25개 항목 중 워크플로의 근본적 재설계였다. 그런데 생성형 AI 사용 조직 중 실제로 일부 워크플로를 근본적으로 재설계했다고 답한 비율은 21%였다. 도구는 도입했지만 일을 다시 설계한 조직은 아직 소수라는 뜻이다.

BCG의 10-20-70 원칙도 같은 결론을 낸다. AI 전환 노력의 10%는 알고리즘, 20%는 기술과 데이터, 나머지 70%는 사람과 프로세스에 써야 한다는 기준이다. 모델을 고르고 시스템을 붙이는 일보다 역할, 의사결정, 교육, 피드백과 변화 관리가 더 크다.

현업은 요구사항 제공자가 아니라 제품 책임자다

힐링페이퍼는 중앙 조직이 모든 도구를 대신 만들어 주는 방식만으로는 현업의 AI 역량이 늘지 않는다고 봤다. 그래서 운영·재무·HR 같은 각 팀에서 관심과 실행력이 있는 사람을 선발해 자기 팀의 문제를 함께 해결하고, 이후 동료의 문제에 해결 방식을 제안할 수 있는 내부 에이블러로 키웠다.

이 구조에서 중앙팀의 역할은 사라지지 않는다. 공통 플랫폼, 보안 기준, 모델과 데이터 접근, 재사용 가능한 구성요소를 제공한다. 다만 어떤 문제를 풀지, 결과가 맞는지, 다음 개선이 무엇인지는 현업 프로세스 오너가 결정한다.

Target은 매장 직원의 피드백 뒤에 확산했다

Target의 Store Companion은 매장 업무 질문, 신규 직원 코칭과 운영 지원을 위한 생성형 AI 도구다. Target은 이를 곧바로 약 2,000개 매장에 뿌리지 않았다. 먼저 약 400개 매장에서 시험하고 팀원 피드백으로 경험을 개선한 뒤 전 매장 수십만 명에게 확대했다.

여기서 중요한 것은 챗봇이라는 형식이 아니다. 실제 매장 직원이 업무 중 묻는 질문에 붙였고, 작은 현장 배포에서 나온 피드백을 확산 조건으로 삼았다. 현업이 빠진 AX는 현업이 쓸 수 없고, 현업이 소유한 자동화만 업무 안에서 살아남는다.

3. PoC가 돌아가면 운영까지 성공했다고 선언하기

PoC는 “이 기술로 한 번 가능한가”를 확인한다. 운영은 “매일 다른 입력이 들어와도 비용과 품질을 통제하며 계속 가능한가”를 증명한다. 둘은 완전히 다른 시험이다.

힐링페이퍼의 해커톤에서도 결과가 갈렸다. 당시에는 만들어졌지만 운영이 어렵거나 품질이 낮아 쓰지 못한 도구가 있었고, 오류·예외·보안을 탐지하는 시스템처럼 이후에도 사용된 도구가 있었다. 같은 행사와 같은 AI 환경에서 생긴 차이는 데모의 완성도가 아니라 운영할 문제와 주인이 있었는지였다.

확산할수록 비용·가치·위험이 동시에 커진다

Gartner는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 전망하며 원인으로 비용 상승, 불명확한 사업가치, 부족한 위험 통제를 꼽았다. 현재 프로젝트 다수가 과대 기대에 끌린 초기 실험이나 PoC이고, 실제 규모로 배포할 때의 비용과 복잡성을 놓친다는 분석이다.

IBM이 인용한 2025년 C-suite 연구에서는 AI 이니셔티브 중 기대한 ROI를 낸 비율이 25%, 전사 규모로 확장된 비율은 16%였다. 개인이 시간을 절약했다는 말과 회사의 손익이 개선됐다는 말 사이에는 큰 간격이 있다. 절약한 시간이 어디에 재투입됐는지, 처리량·오류·매출·고객 경험이 얼마나 달라졌는지를 연결해야 한다.

데모를 운영으로 바꾸는 여덟 가지 조건

NIST의 생성형 AI 프로파일도 위험 관리를 마지막 보안 검사로 두지 않는다. 조직의 목표, 법적 요구, 위험 허용 수준에 맞춰 설계·개발·사용·평가의 생애주기 전체에서 관리하도록 구성한다. 운영은 완성된 데모에 보안을 붙이는 일이 아니라 처음부터 누가 어떤 조건으로 쓸지 정하는 일이다.

확실하게 망하는 실행 순서

1. 최신 모델과 솔루션부터 계약한다해결할 문제는 도입 뒤에 현업에서 찾기로 한다.
2. “생산성 향상”을 목표로 적는다현재 시간·오류·비용과 목표값은 측정하지 않는다.
3. AI팀과 외주사만 회의한다현업은 마지막 시연에서 처음 결과를 본다.
4. 정상 입력 하나로 데모를 만든다예외, 권한, 실패 복구와 실제 데이터 품질은 나중으로 미룬다.
5. 접속자와 프롬프트 수를 성과로 보고한다업무 시간·오류·고객 경험과 손익 변화는 연결하지 않는다.
6. 전사 배포부터 한다작은 팀에서 소유자와 운영 방식을 검증하지 않는다.
7. 프로젝트가 끝나면 담당자를 해산한다모델·업무·데이터가 바뀐 뒤 결과를 고칠 사람이 없다.

반대로 시작하려면 ‘자동화 계약서’ 한 장부터 쓴다

이 문서를 채우지 못하면 자동화할 준비가 안 된 것이다. 모델을 더 조사할 때가 아니라 현재 업무를 관찰할 때다. 문서를 채울 수 있다면 웹서비스, 에이전트, 스크립트, 확장 프로그램 중 가장 작은 구현을 고르고 한 팀에서 운영 검증을 시작하면 된다.

자주 묻는 질문