AI 도입이 실패하는 곳은 모델이 약해서가 아니다
삼성SDS 에이전트 도입률 5%, KT·삼성의 '데이터 구조 정비 없이 AI는 무용지물' 진단. 도입 성패를 가르는 건 모델 선택이 아니라 조직·데이터 준비도와 검증 레이어 설계다.
삼성SDS AX센터가 작년 말 숫자를 하나 공개했다. 에이전트를 검토하거나 파일럿 중인 기업이 많아졌지만, 실제 운영 단계까지 간 비율은 5%에 불과하다는 것이다.
이 숫자를 처음 봤을 때 드는 질문은 하나다. 왜 95%는 못 건넜을까.
흔한 답변은 “모델이 아직 부족해서”다. GPT-5가 나오면, Claude 5가 나오면, 우리 도메인에 맞는 파인튜닝 모델이 나오면. 그 답이 편한 이유는 실행 책임을 미래의 기술로 넘길 수 있어서다.
그런데 현장 진단은 다른 방향을 가리킨다.
모델은 이미 충분하다. 읽을 데이터가 없는 것이 문제다
KT와 삼성이 내부 AI 도입 과정에서 공통으로 부딪힌 벽이 있다. “데이터 못 읽는 AI는 무용지물”이라는 진단이다.
두 회사 모두 모델 성능에는 문제가 없었다. 문제는 AI가 읽어야 할 데이터가 제대로 된 구조로 쌓여 있지 않았다는 것이다. 업무 체계가 정비되어 있지 않으면 아무리 좋은 모델을 붙여도 에이전트는 맥락 없이 작동한다. 엉뚱한 것을 잘 만들거나, 판단의 근거가 없어 멈춘다.
Ethan Mollick(와튼스쿨)이 이 현상을 다른 방식으로 표현한다. AI 도입의 핵심 질문은 “어떤 도구를 살까(IT 구매 결정)“가 아니라 “지능을 어디까지 외주화하고, 사람의 역할을 어떻게 재설계할까(조직 설계)“라는 것이다.
이 두 신호는 같은 결론으로 수렴한다.
도입 성패를 가르는 것은 모델 선택이 아니라 조직·데이터 준비도다.
AI 도입의 진짜 병목은 생성이 아니라 검증이다
“AX = Verification Tax”라는 프레임이 있다. AI 자동화가 만들어내는 산출물을 검증하는 데 드는 비용과 부담이 생각보다 훨씬 크다는 뜻이다.
많이 자동화하는 게 목표가 아니다. 검증 가능하게 자동화하는 것이 목표다.
에이전트가 보고서를 만들었다. 그 보고서가 맞는지 누가, 어떻게, 얼마나 빠르게 확인할 수 있는가. 메모리 레이어가 없으면 에이전트는 같은 실수를 반복하고, 검증 레이어가 없으면 그 실수가 쌓인다. 검증을 사람이 수동으로 처리해야 한다면, 자동화의 속도 이점은 검증 비용에 상쇄된다.
AX가 실질적으로 가져다주는 4가지 부채가 있다.
- 검증 부채: 산출물이 맞는지 확인하는 반복 비용
- 기술 부채: 파편화된 도구와 파이프라인을 계속 고쳐야 하는 비용
- 인지 부채: 에이전트가 무엇을 어떻게 처리했는지 사람이 따라가야 하는 정신적 부담
- 의도 부채: 명확하지 않은 목적으로 에이전트를 붙인 뒤 발생하는 방향 수정 비용
이 네 가지 부채를 설계 단계에서 줄이는 것이 AI 도입의 핵심 엔지니어링이다. 그리고 이 일은 엔지니어보다 PM이 더 잘 볼 수 있는 영역에 있다.
PM이 먼저 해야 할 일은 모델 선택이 아니다
에이전트 도입을 결정하는 자리에 PM이 있다면, 첫 번째 질문은 “어떤 모델을 쓸까”가 되어선 안 된다.
대신 이 네 가지를 먼저 물어야 한다.
1. 의도(Intent): 이 에이전트가 어떤 업무 흐름의 어떤 단계를 맡는가. “AI로 자동화”가 아니라 “이 업무의 이 단계에서 AI가 맡는 범위”가 명확해야 한다.
2. 권한(Permission): 에이전트가 접근할 수 있는 데이터, 실행할 수 있는 액션, 멈춰야 하는 조건이 명시되어 있는가. 권한이 모호하면 에이전트는 너무 많이 하거나 너무 적게 한다.
3. 데이터 준비도(Data Readiness): 에이전트가 읽어야 할 정보가 AI가 소화할 수 있는 구조로 존재하는가. 비정형 문서 더미, 담당자 머릿속에만 있는 지식, 시스템에 흩어진 데이터는 에이전트의 입력이 될 수 없다.
4. 검증 레이어(Verification Layer): 에이전트가 만든 결과를 누가, 어떤 기준으로, 어느 주기로 확인하는가. 사람의 판단이 필요한 지점을 미리 설계해두지 않으면, 에러가 쌓인 뒤에야 발견된다.
이 네 가지가 없는 상태에서 어떤 모델을 붙여도 운영 단계로 넘어가기 어렵다. 그게 95%가 건너지 못한 이유다.
현장 임베드 역할이 생기는 이유
AndrewYNg이 “AI FDE(Forward Deployed Engineer)“라는 개념을 언급한 것도 같은 맥락이다. 고객사 안으로 들어가서 에이전트 워크플로우를 현장 조건에 맞게 함께 설계하는 역할이다.
범용 AI 제품이 아무리 좋아도 조직의 특수한 업무 흐름, 데이터 구조, 검증 기준은 외부에서 알 수 없다. 그 맥락을 알고 있는 사람이 설계에 참여해야 한다. FDE가 그 자리다.
그런데 이 역할은 개념적으로는 PM이 해온 것과 다르지 않다. 고객과 제품 사이의 간극을 좁히고, 의도를 명확히 하고, 운영 조건을 정의하는 것. 에이전트 시대에는 그 대상이 사람이 쓰는 인터페이스가 아니라 에이전트 워크플로우로 확장된 것이다.
결론: 도입 준비도 체크리스트가 먼저다
AI 도입이 실패하는 곳은 모델이 약한 곳이 아니다. 아래 세 가지가 없는 곳이다.
- 에이전트가 읽을 수 있는 데이터 구조
- 에이전트가 멈춰야 할 조건을 아는 권한 설계
- 산출물을 확인할 수 있는 검증 레이어
이 세 가지가 갖춰져 있지 않은 상태에서 모델 성능을 비교하는 것은 순서가 반대다.
PM의 첫 번째 AX 질문은 “어떤 AI를 쓸까”가 아니라 “우리 조직은 에이전트가 실제로 작동하기 위한 조건을 갖추고 있는가”여야 한다.
그 질문이 앞서야 5%가 아닌 다른 숫자가 만들어진다.