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

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

그래서 사람이 손으로 맞춥니다. 이 창에서 숫자를 읽고 저 창에 다시 칩니다. 재입력에만 주 8~15시간을 씁니다. 그렇게 손으로 채워도 CRM 정확도를 60% 언저리 위로 못 올립니다.

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

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

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

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

최근 상담을 겹쳐 놓으니 증상 세 가지가 똑같았습니다. 툴 개수, CRM 정확도, 재입력 노동. 업종도 규모도 다른데 세 증상을 한 묶음으로 겪고 있었어요.

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

그가 쓴 문장이 이겁니다.

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

이 회사들은 대상을 못 정해서 멈춰 있습니다.

증상 세 가지는 서로 물려 있습니다. 툴을 늘릴수록 같은 고객 정보를 여러 곳에 따로 적게 됩니다. 흩어진 값을 사람이 손으로 맞추니 정확도를 더 올리지 못해요.

정확도를 못 믿으니 아무도 그 표를 안 보고, 못 믿는 표를 보완하려고 각 부서가 또 자기 시트를 만듭니다. 한 바퀴 돌 때마다 부서끼리 더 단절됩니다.

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

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

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

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

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

이 순서를 지키면 각 단계에서 앞 단계를 검산할 수 있습니다. 스키마를 짜다 보면 부서마다 다르게 쓰던 항목 이름을 찾게 돼요. 워크플로를 그리다 보면 아무도 책임지지 않는 구간을 발견합니다.

에이전트는 두 번 걸러진 절차 위에서 일합니다. 반대로 에이전트를 먼저 세우면 검산할 기회를 두 번 다 버리고 시작하는 거죠.

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

피어스는 그 기간을 통째로 첫 단계에 씁니다. 그것도 최소치예요.

피어스가 짜 놓은 도입 절차는 다섯 단계입니다. 현재 상태 진단, 아키텍처 설계, 구축, 마이그레이션, 도입률 관리. 진단이 맨 앞이고요.

부서별 담당자를 붙잡고 60분에서 90분씩 인터뷰합니다. 회사가 이미 굴리는 절차를 문장으로 받아 적는 작업이에요.

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

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

피어스가 인터뷰 길이를 그렇게 잡은 이유가 있습니다. 30분짜리 면담으로는 담당자가 공식 절차를 읊고 끝나요. 그 시간을 넘겨야 담당자가 "사실은 그거 제가 매주 금요일에 손으로 다시 만듭니다" 같은 말을 꺼냅니다. 진단으로 캐내려는 대상이 바로 그 말입니다.

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

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

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

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

피어스의 일정표에서 시간을 가장 많이 쓰는 일은 회사가 지금 어떻게 굴러가는지 확정하고, 그 위에 뼈대를 다시 세우는 일입니다. 만드는 구간은 오히려 짧습니다.

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

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

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

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

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

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

실패는 왜 기술 밖에서 시작할까요?

피어스는 실패 패턴 다섯 가지를 꼽았는데, 하나도 기술 문제가 아닙니다.

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

그가 쓴 진단이 이겁니다.

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

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

피어스가 본 작은 회사와 큰 회사는 같은 패턴으로 엎어졌어요. 예산을 서른 배 더 쓴 회사가 같은 결과를 낸다면, 돈으로는 결과를 못 바꾼다는 뜻입니다. 큰 회사는 더 비싼 도구를 사고, 작은 회사는 더 싸게 새로 지을 뿐이에요. 둘 다 무엇을 만들지 모르는 상태 그대로입니다.

남는 생각

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

새 모델 소식도 화려한 데모도 없이 도입 절차만 발로 적어 내려간 글을 그만큼 많은 사람이 공유했어요. 많은 회사가 같은 단계에서 멈춰 있다는 뜻이겠죠.

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

저도 같은 순서로 일합니다. 파이프라인을 새로 짤 때 모델을 먼저 고르지 않아요. 어떤 파일이 어디에 모이고 누가 언제 그걸 읽는지부터 적습니다. 그걸 못 적은 채 자동화를 도입하면 하루 만에 어긋나요. 순서를 지키면 넣은 자동화를 그대로 계속 돌릴 수 있습니다.

점검은 질문 하나면 끝납니다. 어떤 표를 누가 언제 채우는지 문장으로 적을 수 있는가. 못 적는 회사는 무엇을 사도 작년 문제를 그대로 안고 갑니다.

---