클라이언트가 AI 도입해도 일하는 방식이 안 바뀌는 이유

한줄 요약

AI 도입 프로젝트가 실패하는 건 기술 문제가 아니라 업무 분석 부재 문제다.

본문

AI 전환(AX) 프로젝트의 성패는 얼마나 좋은 모델을 붙이느냐가 아니라, 클라이언트의 일하는 방식을 얼마나 정확히 파악했느냐에 달려 있다. 에이전시 입장에서 AX는 단순한 기능 개발이 아니다. 클라이언트 조직이 어떻게 일하고, 어디서 막히고, 어떤 언어를 쓰는지를 먼저 이해해야 하는 컨설팅 성격의 작업이다.

그런데 현장에서는 여전히 "ChatGPT API 연동해주세요" 수준의 요청이 많다. 클라이언트도 뭘 원하는지 정확히 모르는 상태에서 예산을 집행하고, 에이전시는 요건 명세대로 개발만 한다. 결과물은 그럴듯하지만 실제로는 아무도 안 쓴다. 왜 이런 일이 반복될까.

AI 기능보다 먼저 물어야 할 것들

요건 정의 미팅에서 "어떤 AI 기능을 원하세요?"라고 묻는 건 시작점이 틀렸다. 먼저 물어야 할 건 "지금 어떤 업무를 어떻게 처리하고 있나요?"다.

클라이언트의 업무가 규칙 기반의 반복 작업인지, 판단과 해석이 필요한 비정형 작업인지에 따라 AI 설계 방향이 완전히 달라진다. 전자라면 자동화 파이프라인을 짜는 게 맞고, 후자라면 사람의 의사결정을 보조하는 구조로 가야 한다. 이 구분 없이 그냥 LLM 붙여주면 클라이언트는 "쓸 게 없다"는 반응을 보인다.

실제 프로젝트 초기 단계에서 업무 유형 분류만 제대로 해도 개발 범위가 훨씬 명확해진다. 에이전시가 이 작업을 선행하지 않으면, 개발 중반에 스코프가 흔들리거나 납품 후 사용률이 0에 수렴하는 결과로 이어진다.

조직의 언어를 학습시키지 않으면 AI는 이방인이 된다

AI가 아무리 잘 작동해도 클라이언트 조직 내에서 이질감이 느껴지면 외면받는다. 가장 흔한 원인은 조직 내부의 언어와 맥락을 AI가 반영하지 못할 때다.

산업별, 기업별로 같은 단어가 다른 의미로 쓰이는 경우가 많다. 내부 약어, 보고 문화, 특정 상황에서의 표현 방식 등이 모두 조직마다 다르다. 이런 맥락을 시스템 프롬프트나 RAG 설계에 녹여내지 않으면, AI는 기술적으로 정확하지만 현장에서는 "뭔가 어색하다"는 피드백을 받는다.

에이전시 입장에서 이 작업은 단순한 프롬프트 튜닝이 아니다. 클라이언트 조직의 문서, 보고서, 회의록 등을 분석해서 실제 사용되는 표현과 맥락을 파악하는 사전 리서치가 필요하다. 이게 빠진 AX 프로젝트는 기능은 있지만 현장 흡수율이 낮다.

병목 구간을 찾지 않으면 AI는 엉뚱한 곳에 붙는다

클라이언트가 "전반적으로 업무 효율을 높이고 싶다"고 말할 때, 에이전시가 해야 할 일은 전체 업무 흐름을 펼쳐놓고 실제 병목이 어디서 발생하는지 짚어내는 것이다.

시간이 가장 많이 소요되는 단계, 반복적으로 오류가 나는 구간, 특정 담당자에게 의존도가 집중된 지점 — 이런 곳이 AI 개입의 우선순위가 되어야 한다. 그런데 현실에서는 클라이언트가 "보고서 작성이 번거롭다"고 하면 보고서 자동화만 붙이고 끝내는 경우가 많다. 실제 병목은 보고서를 쓰기 전 데이터 수집 단계인데도.

업무 흐름 전체를 매핑하고 병목 구간을 특정하는 작업은 개발 시작 전에 반드시 해야 할 사전 설계다. 이걸 에이전시가 주도할 수 있느냐 없느냐가 프로젝트 품질을 가른다.

에이전시가 AX 프로젝트를 제대로 끝내려면

좋은 AX 프로젝트는 개발 완료가 아니라 실제 사용으로 완성된다. 클라이언트 조직에서 AI가 일상적으로 쓰이기 시작할 때 비로소 프로젝트가 성공한 것이다.

그러려면 에이전시는 개발자이기 이전에 관찰자여야 한다. 클라이언트가 어떤 리듬으로 일하는지, 보고 주기는 어떻게 되는지, 정보가 어디에 쌓이고 어디서 사라지는지를 파악해야 한다. 기술 스택 결정은 그다음이다.

AX 프로젝트를 단순 개발 외주로 접근하는 에이전시는 결국 납품 후 방치되는 시스템을 계속 만들게 된다. 반면 클라이언트의 일하는 방식을 먼저 이해하는 에이전시는 같은 예산으로 실제로 쓰이는 시스템을 만든다. 그 차이가 장기 파트너십으로 이어진다.