80%의 기업이 생성 AI를 어떤 형태로든 쓰고 있다. 그런데 McKinsey 최신 데이터에 따르면, 그중 의미 있는 사업 성과를 낸 비율도 거의 같은 수준—즉, 거의 없다. 도구는 넘치는데 결과는 없는 이 현상을 'dev.to'의 Igor Gridel은 80/80 패러독스라고 부른다. 팀에서 AI 구독료가 쌓이는 속도만큼 성과가 보이지 않는다면, 당신이 뭔가를 잘못하는 게 아니다. 업계 전반이 같은 함정에 빠진 것이다.
문제의 핵심은 도구의 품질이 아니다. 도입(adoption)과 통합(integration)의 차이다. ChatGPT 탭, Claude 탭, Perplexity 탭, Notion AI 구독—이건 도입이다. 통합은 도구가 실제 업무 흐름에 녹아들어 '명시적으로 기억해서 켜는 것'이 아니라 '자동으로 동작하는 것'이 되는 상태다. McKinsey는 수직형 AI 유스케이스의 약 90%가 파일럿 단계에 갇혀 있다고 지적한다. Asana는 이를 '파일럿 퍼거토리(pilot purgatory)'라고 명명했다. 성과를 내는 조직과 그렇지 못한 조직의 차이는 AI를 기존 워크플로우에 얹는가, 아니면 워크플로우 자체를 AI 중심으로 재설계하는가에 있다.
두 번째 구조적 결함은 에이전트 아키텍처의 혼동이다. 'dev.to'의 Bo Romir는 업계가 'AI 에이전트'를 하나의 범주로 뭉뚱그리기 때문에 진짜 문제가 생긴다고 진단한다. 실제로 에이전트는 두 가지로 분류된다. Type 1: Persistent Context Agent—Claude Code나 Cursor처럼 코드베이스, 히스토리, 선호를 기억하며 시간이 지날수록 더 유용해지는 에이전트. Type 2: Stateless Decision Function—트랜잭션 하나를 받아 판정을 내리고 끝나는, 메모리 없는 정밀 분류기. 코드 리뷰 자동화, 사기 탐지, 콘텐츠 모더레이션이 여기 해당한다.
두 타입은 실패 방식이 완전히 다르다. Type 1은 컨텍스트 드리프트와 오래된 메모리 오염이 문제고, Type 2는 엣지 케이스의 분류 오류가 문제다. 평가 전략도 다르다. Type 2는 레이블된 데이터셋과 단일 수치 지표로 자동 토너먼트 평가가 가능하지만, Type 1은 장기 누적 맥락을 기준으로 한 정성 평가가 필요하다. 팀이 Type 1이 필요한 자리에 Type 2를 구축하거나, 그 반대를 하면 아무리 좋은 모델을 써도 결과가 안 나온다. 테크 리드라면 에이전트를 도입하기 전에 "이게 기억을 축적해야 하는가, 아니면 정확도 97%로 반복 판정해야 하는가"를 먼저 물어야 한다.
세 번째 결함은 거버넌스 공백이다. ZDNet이 인용한 딜로이트 조사(연매출 5억 달러 이상 기업 515곳 대상)에 따르면, 현재 AI 인프라 의사결정의 51%는 CIO·CTO가 주도하지만 전담 거버넌스 조직이 책임지는 비중은 15%에 불과하다. 기업의 30%는 이미 월 100억 토큰 이상을 소비 중이고, 2028년에는 61%로 늘어날 전망이다. 그런데 딜로이트는 명시적으로 경고한다—초기 토큰 소비 증가는 효율적 활용이 아니라 비효율적 설계와 관리 부재를 반영할 수 있다고. AI 확산이 경쟁력이 아니라 구조적 비용 부담으로 전환될 위험이 여기 있다.
테크 리드 관점에서 이 세 가지 결함은 사실 하나의 근본 원인으로 수렴한다. 속도가 구조를 앞질렀다. Google Cloud가 'AI Sprawl'이라고 부르는 것처럼, 거버넌스 없이 AI 도구를 쌓아가면 기술 부채와 똑같은 일이 벌어진다. 중복, 분절, 마찰. Microsoft의 2025 Work Trend Index는 직원이 하루 275회 맥락 전환을 경험한다고 측정했다. AI 탭이 늘어날수록 생산성이 아니라 인지 부하가 증가하는 구조다.
그렇다면 지금 당장 뭘 해야 하나. 세 가지 실행 포인트를 제안한다.
첫째, 도구 감사(audit)를 먼저 해라. 지금 팀의 AI 구독 목록을 꺼내고, 지난 3주간 실제 업무 흐름에 연결된 것만 남겨라. '탐색용'과 '통합용'을 구분하고, 탐색용은 과감하게 끊어라. 스택 엔비(stack envy)와 스택 핏(stack fit)은 다르다.
둘째, 에이전트 도입 전에 타입을 정의해라. "이 유스케이스는 기억이 필요한가(Type 1), 반복 정확도가 필요한가(Type 2)?" 이 질문 하나가 아키텍처 설계의 80%를 결정한다. Anthropic의 'Building Effective Agents' 가이드가 제시하는 핵심 원칙은 단순하다—단순한 것부터 시작하고, 단순한 방식이 실패한다는 증거가 생겼을 때만 복잡도를 추가해라.
셋째, 거버넌스를 IT 리더 한 명의 판단에 맡기지 마라. 토큰 소비 모니터링, 비용 책임 구조, AI 생성물 품질 검증 체계를 명시적으로 설계해야 한다. 관찰가능성(observability)이 없으면 개선도 없다. 시스템이 아니라 데모 상태에 머무는 것이다.
딜로이트는 "향후 3년이 AI가 경쟁 우위가 될지, 구조적 비용 부담이 될지를 결정짓는 분기점"이라고 말한다. 나는 그 분기점이 더 짧다고 본다. 이미 일부 팀은 도구 과잉 속에서 워크플로우를 재설계하고 있고, 나머지 팀은 파일럿 퍼거토리에서 예산을 소진 중이다. AI 도구의 ROI는 도구 자체가 아니라 그것을 팀 구조와 어떻게 연결하느냐에서 결정된다. 구조를 먼저 짜는 팀이 이긴다.