툴 25개에 CRM 정확도 60%, 이 상태에서 먼저 산 게 AI 에이전트였습니다

한 회사에 툴이 스물다섯 개 깔려 있습니다. 영업은 CRM을 보고, 재무는 엑셀을 열고, 고객지원은 또 다른 창을 봅니다. 세 화면에 뜨는 같은 고객 이름이 서로 다릅니다.

그래서 사람이 손으로 맞춥니다. 이 창에서 숫자를 읽고 저 창에 다시 칩니다. 재입력에만 주 8~15시간이 들어갑니다. 그렇게 채워도 CRM 정확도는 60% 언저리에 머뭅니다.

이 상태에서 회사가 처음 사는 물건이 AI 에이전트예요.

루크 피어스는 이 장면을 90건 넘게 봤습니다. 도입 현장을 4년 돌면서요. 그가 정리한 안내서가 X에서 조회 25만을 넘겼습니다. 제목은 「완벽한 AI 도입을 굴리는 법」입니다.

상담 열네 건에서 왜 같은 장면이 반복됐을까요?

피어스는 붐 오토메이션스를 운영합니다. 상대하는 회사는 매출 200만 달러짜리부터예요. 위로는 1억 달러를 넘습니다.

최근 상담을 겹쳐 놓으니 증상 세 가지가 똑같았습니다. 툴 개수, CRM 정확도, 재입력 노동. 업종도 규모도 다른 회사인데 앞서 적은 숫자들이 한 묶음으로 나왔습니다.

피어스는 원인을 사일로에서 찾습니다. 영업이 아는 사실과 재무가 아는 사실이 한 번도 같은 표에 모인 적이 없어요. 그러니 회사 안 누구도 무엇을 자동화해야 하는지 답하지 못합니다.

그가 쓴 문장이 이겁니다.

"이 회사들은 만드는 문제를 겪는 게 아닙니다. 무엇을 만들지 모르는 문제를 겪습니다."

기술이 부족해서 멈춘 게 아닙니다. 대상을 못 정해서 멈춘 겁니다.

증상 세 가지는 서로 물려 있습니다. 툴이 늘어나면 같은 고객 정보가 그 개수만큼 갈라집니다. 갈라진 값을 사람이 손으로 맞추니 정확도가 거기서 더 오르지 않아요. 정확도가 낮으니 아무도 그 표를 믿지 않고, 못 믿는 표를 보완하려고 각 부서가 또 자기 시트를 만듭니다. 한 바퀴 돌 때마다 사일로가 굵어집니다.

왜 순서를 데이터부터 잡아야 할까요?

피어스는 작업 순서를 못 박습니다. 데이터가 먼저입니다. 그다음이 워크플로고, 지능은 맨 마지막이에요.

"작업 순서가 중요합니다. 데이터, 그다음 워크플로, 그다음 지능."

거꾸로 가면 어떻게 되는지는 계산이 쉽습니다. 틀린 값이 섞인 데이터 위에 에이전트를 얹으면, 그 에이전트는 틀린 값을 아주 빠르게 옮깁니다. 사람이 손으로 옮길 때는 눈에 걸리던 오류가 자동화 뒤에는 그냥 통과해요. 속도만 올라가고 신뢰는 떨어집니다.

구축 단계 안에서도 순서가 같습니다. 스키마를 먼저 잡고, 그 위에 워크플로를 올리고, 마지막에 에이전트를 붙입니다. 지능은 토대가 아니라 마감재입니다.

이 순서를 지키면 각 단계가 앞 단계를 검산합니다. 스키마를 짜다 보면 부서마다 다르게 쓰던 항목 이름이 드러나요. 워크플로를 그리다 보면 아무도 책임지지 않는 구간이 드러납니다. 에이전트는 그 두 번 걸러진 자리에 들어갑니다. 반대로 에이전트를 먼저 세우면 검산할 기회를 두 번 다 버리고 시작하는 거죠.

진단에 2주를 쓰면 무엇이 보일까요?

그 기간이 통째로 첫 단계 몫입니다. 그것도 최소치예요.

피어스가 짜 놓은 도입 절차는 다섯 단계입니다. 현재 상태 진단, 아키텍처 설계, 구축, 마이그레이션, 도입률 관리. 진단이 맨 앞이고요. 부서별 담당자를 붙잡고 60분에서 90분씩 인터뷰합니다. 회사가 이미 굴리는 절차를 문장으로 받아 적는 작업이에요.

그러면 숫자가 나옵니다. 재입력 루프 하나가 인건비로 연 4만 달러를 태우고 있었습니다. 아무도 열지 않는 시스템 하나에 5만 달러가 묶여 있었습니다. 진단 전까지 이 회사는 두 금액을 몰랐어요.

여기가 갈림길입니다. 진단을 건너뛴 회사는 자동화 대상을 감으로 고릅니다. 진단을 거친 회사는 인건비를 태우던 그 루프를 지목하죠. 같은 예산으로 전혀 다른 물건을 삽니다.

인터뷰 길이도 그냥 나온 숫자가 아닙니다. 30분짜리 면담으로는 담당자가 공식 절차를 읊고 끝나요. 그 시간을 넘겨야 "사실은 그거 제가 매주 금요일에 손으로 다시 만듭니다" 같은 말이 나옵니다. 진단이 캐내려는 대상이 바로 그 말입니다.

90일 일정표는 왜 지능을 맨 뒤에 두었을까요?

피어스가 제시한 일정표를 그대로 옮기면 이렇습니다.

12주 현재 상태 진단. 34주 아키텍처 설계. 58주 워크플로 구축. 910주 에이전트 투입. 11~12주 컷오버.

앞의 넉 주는 아직 아무것도 만들지 않는 구간입니다. 전체 일정은 열두 주고요. 에이전트가 등장하는 구간은 딱 두 주입니다. 도입 프로젝트라고 부르지만 실제 제작 비중은 절반이 안 돼요.

일정표가 말하는 바가 분명합니다. 이 프로젝트에서 오래 걸리는 일은 만드는 일이 아닙니다. 회사가 지금 어떻게 굴러가는지 확정하고, 그 위에 뼈대를 다시 세우는 일입니다. 만드는 구간은 오히려 짧습니다.

워크플로 구축에 붙은 기간이 에이전트 투입 구간보다 긴 배분도 같은 방향을 가리킵니다. 회사가 돈을 아끼는 자리는 사람이 반복하던 절차를 기계로 옮기는 구간이에요. 에이전트는 그 절차 위에서 판단이 필요한 지점만 맡습니다.

마이그레이션과 도입률을 왜 단계로 따로 세웠을까요?

도입 절차 뒤쪽 두 개가 마이그레이션과 도입률입니다. 만드는 일이 끝난 다음에도 단계가 두 개 더 남아 있다는 뜻이에요.

마이그레이션은 기존 데이터를 새 구조로 옮기는 작업입니다. 정확도를 손보지 않고 그대로 옮기면 새 시스템도 첫날부터 같은 값에서 출발합니다. 옮기기 전에 값을 정리해야 하니, 이 단계에서 회사는 자기 데이터와 한 번 정면으로 마주칩니다.

도입률은 더 노골적입니다. 다 만들어 놓고도 직원이 예전 시트를 계속 쓰면 그 시스템은 아무도 안 쓰는 돈뭉치가 됩니다. 앞에서 나온 그 잠긴 시스템이 바로 이 단계를 건너뛴 결과예요.

피어스가 도입률을 별도 단계로 세운 이유가 여기 있습니다. 납품은 끝이 아니라 중간입니다. 직원이 새 화면을 매일 열기 시작해야 그제야 프로젝트가 끝납니다.

실패 다섯 가지가 왜 전부 기술 밖에 있을까요?

피어스가 실패 패턴을 꼽아 놓았습니다. 하나도 기술 문제가 아닙니다.

모델을 바꿔도, 벤더를 바꿔도, 예산을 두 배로 올려도 그 자리는 그대로 남아요. 실패가 코드 바깥에서 시작하기 때문입니다.

그가 쓴 진단이 이겁니다.

"압도감과 실패는 같은 곳에서 옵니다. 프로세스 없이 프로젝트를 시작하는 것."

압도감과 실패를 한 원인으로 묶은 대목이 눈에 걸립니다. 담당자가 무엇부터 해야 할지 몰라 숨 막히는 상태와, 6개월 뒤 프로젝트가 엎어지는 상태가 같은 뿌리에서 나옵니다. 뿌리는 절차 부재예요.

작은 회사와 큰 회사가 같은 패턴으로 엎어진다는 점도 같은 결론을 받칩니다. 예산이 서른 배 차이 나는데 결과가 같다면, 갈라지는 변수는 돈이 아닙니다. 큰 회사는 더 비싼 도구를 사고, 작은 회사는 더 싸게 새로 지을 뿐이에요. 무엇을 만들지 모르는 상태는 둘 다 그대로입니다.

남는 생각

저는 "프로세스가 곧 제품"이라는 말이 이 글에서 가장 무거운 문장이라고 봅니다.

이 글이 퍼진 폭도 같은 신호로 읽힙니다. 새 모델 소식도 아니고 화려한 데모도 아닌, 도입 절차를 발로 적어 내려간 글이 그만큼 돌았어요. 많은 회사가 같은 자리에서 멈춰 있다는 뜻이겠죠.

도구를 파는 쪽은 제품이 제품이라고 말합니다. 그런데 현장을 겪어 본 사람은 절차 자체가 결과물이라고 말해요. 회사가 받아 가는 진짜 자산은 에이전트가 아니라, 인터뷰로 확정한 "우리 회사는 이렇게 굴러간다"는 문서라는 뜻입니다.

저도 같은 순서로 일합니다. 파이프라인을 새로 짤 때 모델을 먼저 고르지 않아요. 어떤 파일이 어디에 쌓이고 누가 언제 그걸 읽는지부터 적습니다. 그걸 못 적는 날은 자동화를 붙여도 하루 만에 어긋납니다. 순서를 지킨 날은 붙인 자리가 그대로 굴러가고요.

점검은 질문 하나면 끝납니다. 어떤 표를 누가 언제 채우는지 문장으로 적을 수 있는가. 못 적는 회사는 무엇을 사도 작년과 같은 자리에 서 있습니다.

---

원문·소스

• 루크 피어스 아티클 안내 트윗 (@lukepierceops, 조회 25만): https://x.com/lukepierceops/status/2093413799646896231