클라이언트 회사에 AI를 붙이기 전에 개발사가 먼저 알아야 할 것

한줄 요약

AI 도입 프로젝트가 실패하는 이유는 기술이 아니라 클라이언트 조직의 구조에 있다.

외주 개발을 통해 AI 기능을 붙이는 프로젝트가 늘고 있지만, 완성된 시스템이 실제 업무에 제대로 안착하는 경우는 생각보다 훨씬 적다. 기술 자체가 문제인 경우는 드물다. 대부분은 클라이언트 조직이 그 기술을 받아들일 준비가 되어 있지 않아서다. 개발사 입장에서 이 현실을 이해하고 있느냐 없느냐에 따라, 같은 산출물이 성공 사례가 되기도 하고 조용히 묻히는 레거시가 되기도 한다.

제품에 AI를 붙이는 것과 조직을 바꾸는 것은 다른 문제다

클라이언트가 원하는 게 무엇인지 정확히 파악하는 것이 프로젝트의 출발점이다. 그런데 많은 경우에 클라이언트 스스로도 이 둘을 구분하지 못한 채로 개발 의뢰를 한다.

하나는 제품이나 서비스 자체에 AI를 붙이는 것이다. 챗봇을 달거나, 추천 알고리즘을 넣거나, 이상 감지 기능을 추가하는 식이다. 이건 범위가 비교적 명확하고, 요구사항을 정의하고 개발하는 일반적인 외주 프로젝트 방식으로 접근할 수 있다.

다른 하나는 조직이 돌아가는 방식 자체에 AI를 끌어들이는 것이다. 보고 체계, 의사결정 흐름, 예산 배분, 데이터 공유 방식 같은 것들이다. 이건 기술 프로젝트가 아니라 조직 변화 프로젝트다. 개발사가 코드를 납품한다고 해서 끝나는 게 아니다.

문제는 클라이언트가 두 번째를 원하면서 첫 번째 방식으로 의뢰한다는 데 있다. "AI로 업무 효율을 높이고 싶다"는 요구가 실제로는 보고서 자동화 툴 하나를 원하는 건지, 팀 전체의 의사결정 방식을 바꾸겠다는 건지 처음부터 명확히 확인해야 한다.

왜 AI 에이전트는 클라이언트 조직 안에서 막히는가

개발사가 AI 에이전트를 구축해서 납품했을 때, 실제 운영에서 가장 자주 막히는 지점은 데이터 연동 문제가 아니다. 조직 안에 암묵적으로 존재하는 규칙들이다.

모든 조직에는 공식 문서에 없는 운영 방식이 있다. 특정 결재를 받으려면 공식 조직도에 없는 누군가를 먼저 설득해야 한다. 비용 처리 기준이 담당자 머릿속에만 있다. 거래처마다 실제 적용 조건이 다르지만 어디에도 쓰여 있지 않다.

사람은 조직에 들어가서 몇 주만 지나면 이런 '실제 지도'를 자연스럽게 익힌다. AI 에이전트는 그럴 수 없다. 에이전트는 문서에 있는 것만 읽을 수 있다. 프로세스가 기록되어 있지 않으면 에이전트는 작동을 멈추거나, 더 나쁜 경우엔 틀린 방향으로 계속 실행한다.

외주 개발사 입장에서 이게 의미하는 바는 하나다. 요구사항을 받을 때 "이 프로세스가 문서로 정의되어 있습니까?"를 반드시 확인해야 한다는 것이다. 없다면, 그걸 먼저 만드는 작업이 개발보다 앞서야 한다. 그 단계를 건너뛰면 납품 이후의 트러블이 고스란히 개발사 책임으로 돌아온다.

섀도우 AI는 클라이언트 조직 안에 이미 있다

클라이언트 담당자와 킥오프 미팅을 하다 보면 종종 이런 말을 듣는다. "저희 팀 일부가 이미 챗GPT를 쓰고 있어요. 근데 회사 공식 승인은 아직이에요."

이게 섀도우 AI다. 공식 승인 없이 직원 개인이 AI 툴을 업무에 쓰고, 회사 내부 데이터를 외부 서비스에 입력하고, 관리자는 그 사실을 정확히 파악하지 못하는 상태. 이미 많은 조직에서 일어나고 있다.

개발사가 이 상황에서 해야 할 일은 클라이언트를 나무라는 게 아니다. 이 신호를 프로젝트 범위 정의에 활용하는 것이다. 섀도우 AI가 퍼진 팀은 공식 시스템이 현장의 속도를 따라가지 못하고 있다는 뜻이다. 개발사가 만들 시스템이 그 속도보다 느리거나 불편하면, 납품 이후에도 결국 비공식 툴이 계속 쓰인다. 도입 효과가 없다는 평가를 받는 건 당연한 수순이다.

그러니 클라이언트의 실제 업무 환경을 파악할 때, 공식 승인된 툴 목록만 볼 게 아니라 현장에서 실제로 쓰이는 것들을 함께 조사해야 한다. 만들어야 할 시스템의 기준선은 거기서 시작된다.

---

납품 이후를 고려한 설계: 기록, 권한, 책임

기술적으로 동작하는 AI 시스템을 만드는 것과, 조직 안에서 지속적으로 운영될 수 있는 시스템을 만드는 것은 다르다. 후자를 위해 개발 단계에서 미리 챙겨야 할 것들이 있다.

첫째, 에이전트의 모든 행동은 추적 가능해야 한다. 언제, 어떤 입력을 받아서, 어떤 판단을 거쳐, 무엇을 실행했는지 기록으로 남아야 한다. 클라이언트가 "왜 이런 결과가 나왔냐"고 물었을 때 답할 수 없는 시스템은, 신뢰를 잃는 건 시간문제다.

둘째, 권한 체계를 명확히 해야 한다. 에이전트가 어떤 작업을 실행할 때 그건 누구의 권한으로 하는 건지, 어디까지 접근할 수 있는지 초기 설계에 반드시 포함해야 한다. 기존 시스템의 권한 체계는 사람을 기준으로 짜여 있다. 에이전트가 그 체계 안에서 어떤 위치에 있는지 클라이언트와 명확히 합의해야 한다.

셋째, 고객 데이터 처리 방식을 문서로 만들어야 한다. 외부 모델 API를 쓴다면 클라이언트 데이터가 어디로 가는지, 학습에 활용되지 않는다는 걸 어떻게 확인할 수 있는지, 계약서에 명시 가능한 수준으로 정리되어 있어야 한다. 클라이언트가 기업 고객을 상대한다면 이건 선택 사항이 아니다.

이 세 가지를 납품 전에 정리하지 않으면, 운영 단계에서 생기는 문제는 모두 개발사로 귀결된다. 클라이언트가 감당해야 할 운영 리스크를 개발 단계에서 미리 구조화해주는 것, 이게 단순 외주와 기술 파트너의 차이다.