클라이언트의 AX 프로젝트가 실패하는 구조적 이유: IT 에이전시가 본 현실
목차(7)
한줄 요약
AI 에이전트를 만드는 것과 조직이 실제로 바뀌는 것은 전혀 다른 문제다.
본문
엔터프라이즈 AX(AI 전환) 프로젝트는 IT 에이전시 입장에서 가장 까다로운 유형의 의뢰 중 하나다. 기술적으로 완성도 있는 결과물을 납품해도, 클라이언트 조직이 그것을 받아들일 준비가 안 되어 있으면 프로젝트는 조용히 사장된다. 최근 AI 에이전트 개발 의뢰가 급증하면서, 우리가 목격하는 실패 패턴도 점점 선명해지고 있다.
에이전시가 납품해도 쓰지 않는 이유는 따로 있다
AI 에이전트 개발을 의뢰하는 기업 중 상당수는 "무엇을 만들지"는 있지만 "누가 어떻게 운영할지"는 정해져 있지 않다. 완성된 에이전트를 내부에 이식하는 순간, 유지보수 담당자가 코드 구조를 이해하지 못하거나, 문제가 생겼을 때 책임 소재가 불분명해지는 상황이 발생한다.
에이전시 입장에서 보면 이것은 클라이언트만의 문제가 아니다. 개발 단계에서 인수인계 가능성을 고려한 코드 설계, 운영 매뉴얼, 장애 대응 시나리오까지 범위에 포함시키지 않으면 납품 이후 관계가 단절되거나 끝없는 유지보수 요청이 이어진다. 기술을 만드는 것과 그 기술이 조직 안에서 살아남도록 설계하는 것은 별개의 작업이다.
클라이언트의 기대치와 실제 결과물 사이의 간극
의뢰 초기에 클라이언트가 가져오는 기대는 대개 두 가지 방향으로 나뉜다. 첫째는 "AI가 알아서 다 해줄 것"이라는 과도한 기대, 둘째는 "이걸 만들면 비용이 바로 줄 것"이라는 즉각적 ROI에 대한 기대다.
현실은 다르다. 생성형 AI 기반 에이전트의 본질은 작업을 빠르게 처리하는 증강 도구지, 판단 자체를 대체하는 자율 시스템이 아니다. 에이전트가 잘못된 결과를 내놓았을 때 책임지는 구조는 여전히 사람에게 남는다. 에이전시가 이 지점을 명확히 하지 않으면, 나중에 "왜 이렇게 실수가 많냐"는 클레임이 돌아온다. 프로젝트 시작 전에 AI 결과물의 정확도 수준, 검증 방법, 오류 발생 시 대응 주체를 계약서 수준으로 정리해두는 것이 필수다.
개발 속도를 높였는데 왜 전체 프로세스는 그대로인가
바이브 코딩이나 LLM 기반 개발 도구 덕분에 에이전시의 프로토타입 개발 속도는 실제로 빨라졌다. 문제는 개발 속도가 빨라진다고 클라이언트의 의사결정 속도, 내부 검토 속도, 배포 승인 속도가 같이 빨라지지 않는다는 점이다.
에이전시가 하루 만에 MVP를 만들어 와도, 클라이언트 내부에서 보안 검토, 법무 검토, 경영진 승인을 받는 데 3주가 걸리면 전체 납기는 달라지지 않는다. 더 심각한 경우는, 빠른 개발 속도를 보고 클라이언트가 범위를 계속 확장하는 패턴이다. 처음엔 챗봇 하나였다가, 슬랙 연동이 붙고, 레포트 자동화가 붙고, 어느새 전사 AI 플랫폼을 만들고 있는 상황이 된다. 초기 요건 정의와 범위 합의를 단단히 해두지 않으면 에이전시도 클라이언트도 같이 소모된다.
에이전시가 놓치기 쉬운 조직 내 레이어 차이
같은 클라이언트 사 안에도 여러 레이어가 공존한다. AI 도입에 적극적인 리더십, 리스크 관리를 우선하는 IT 담당 부서, 정확도 100%를 당연히 여기는 현업 담당자. 이 세 집단이 동시에 프로젝트 이해관계자로 존재한다.
에이전시가 이 구조를 이해하지 못하면 엉뚱한 사람과만 소통하다 프로젝트가 표류한다. 기술 스펙을 결정하는 사람, 예산을 쥔 사람, 실제로 사용할 사람이 따로 있다. 각 레이어에게 필요한 언어와 논리가 다르다. 경영진에게는 비용과 시간, IT 부서에게는 보안과 유지보수 가능성, 현업에게는 사용 편의성과 오류 처리 방식을 중심으로 커뮤니케이션해야 한다. 에이전시가 단순한 개발 외주사가 아니라 중재자 역할을 해야 하는 이유다.
성과를 측정하지 않으면 재계약도 없다
가장 치명적인 실수 중 하나는 프로젝트 시작 시점에 성과 측정 기준을 정해두지 않는 것이다. 에이전트를 납품하고 나면 "잘 쓰고 있겠지"로 흘러가기 쉽다. 하지만 클라이언트 내부에서 베이스라인이 없으면 도입 전후를 비교할 수 없고, 비교할 수 없으면 성과도 없는 것처럼 보인다.
에이전시 입장에서 이것은 레퍼런스와 재계약 모두를 잃는 문제다. 납품 전에 반드시 도입 전 현황 데이터를 클라이언트와 함께 기록해두고, 몇 주 후 측정 시점을 계약에 명시해야 한다. 숫자로 "이 에이전트 덕분에 이렇게 바뀌었다"를 보여줄 수 있을 때, 다음 프로젝트 논의가 시작된다.
자주 묻는 질문
Q.AI 에이전트 개발을 외주로 맡길 때 가장 먼저 정해야 할 것은 무엇인가?
에이전트가 내놓는 결과물의 오류 허용 범위와 그 책임 주체를 먼저 합의해야 한다. 생성형 AI는 100% 정확도를 보장하지 않기 때문에, 오류 발생 시 누가 검토하고 수정할지 프로세스를 미리 설계해두지 않으면 운영 단계에서 분쟁이 생긴다. 기술 스펙보다 이 부분이 선행되어야 한다.
Q.에이전시가 만든 AI 에이전트를 기업 내부에 안정적으로 이식하려면 어떻게 해야 하나?
납품 단계에서 내부 담당자가 실제로 유지보수할 수 있는 수준의 문서화와 인수인계 세션이 필수다. 코드 구조 설명, 주요 파라미터 수정 방법, 오류 로그 해석 방법을 포함한 운영 가이드를 함께 납품해야 한다. 보안 취약점 검토 결과도 별도로 제공하면 내부 IT 부서의 수용성이 높아진다.
Q.AX 프로젝트에서 ROI를 어떻게 증명할 수 있나?
도입 전 현황 지표를 반드시 사전에 기록해두어야 한다. 처리 시간, 오류 건수, 담당자 투입 시간 등 측정 가능한 지표를 베이스라인으로 설정하고, 에이전트 투입 후 동일 기준으로 재측정하는 구조를 만들어야 한다. 측정 체계 없이 시작하면 아무리 효과가 있어도 숫자로 증명하기 어렵고, 다음 예산 승인도 어려워진다.