AI를 모든 곳에 뿌리는 것을 멈춰라: 진짜 제약 사항은 레버리지(Leverage)가 존재하는 곳에 있다

맥락 및 핵심 사건 분석

최근 한 기업가가 Ben Angel의 칼럼을 통해, AI로 조용히 부를 쌓고 있는 운영자들은 가장 많은 도구(tools), 프롬프트(prompts), 그리고 자동 생성된 콘텐츠를 쌓아 올리는 사람들이 아니라고 주장했습니다. 이 글의 뼈아픈 지점은 다섯 개의 SaaS 제품을 하나로 이어 붙이느라 밤을 지새워 본 사람이라면 누구나 공감할 만한 내용입니다. 시장의 내러티브는 계속해서 "AI를 더 많이 사용하라"고 말하지만, 여전히 많은 창업자들은 모든 결정을 수동으로 내리며 모든 실패의 형태를 직접 감당하고 있습니다. Angel의 반론은 더 날카롭습니다. 금융적 레버리지(financial leverage)를 추출하는 사람들은 수익이나 제품 접근을 실제로 가로막는 한두 가지의 제약 사항(constraints)에 AI를 겨냥한 뒤, 나머지는 의도적으로 건너뜁니다.

중심 사례 연구는 개발자가 아닌 사람도 평이한 영어로 애플리케이션을 설명하고 출시할 수 있게 해주는 노코드(no-code) 빌더입니다. 피상적인 해석은 "이제 AI가 코드를 작성한다"는 것입니다. 하지만 운영적 관점에서의 해석은 다릅니다. 이 제품은 대부분의 사람들을 소프트웨어 제작에서 배제했던 장벽, 즉 "코딩을 할 수 없다"는 벽을 제거하는 것입니다. 그 장벽 자체가 바로 제품입니다. 모델의 점수판이 아니라 패턴 인식(Pattern recognition)이 비즈니스 기술이 됩니다. 즉, 산업을 유지하고 외부인을 가두는 사회적 또는 경제적 관문(gate)을 찾아낸 다음, 그 관문의 붕괴를 제품화하는 것입니다.

동일한 기사에 포함된 배경 수치들은 이러한 격차를 더욱 명확히 보여줍니다. Angel은 2026 Intuit QuickBooks AI 영향 보고서(AI Impact Report)를 인용하며, 미국 기업의 43%가 AI 덕분에 매출이 증가했다고 답한 반면, 매출 감소를 보고한 기업은 2%에 불과하다고 언급했습니다. 이는 마법 같은 모델의 증거가 아닙니다. 이는 추론 (Inference)을 가장 가치 있는 제약 사항 (Constraint)에 배치하는 팀과, 생성 (Generation)을 단순 업무 (Busywork)에 뿌려대는 팀 사이의 운영 격차 (Operator gap)가 벌어지고 있다는 증거입니다. 가장 교훈적인 일화는 반대의 사례입니다. 700명의 상담원 업무를 대체하고 약 4,000만 달러의 이익 개선을 이끌어냈다고 말했던 AI 챗봇을 도입한 한 기업이, 나중에 도입을 철회하고 인간을 다시 채용했습니다. 모두가 4,000만 달러라는 수치를 인용합니다. 하지만 어떤 대화가 자동화되어서는 안 되었는지 묻는 사람은 거의 없습니다. 그리고 바로 그 질문이 지속 가능한 경제성 (Durable economics)과 데모 연극 (Demo theater)을 가르는 지점입니다.

도메인 지식 및 기술적 확장 (Domain Knowledge & Technical Extension)

마케팅 용어 이면에는 이미 프로덕션 팀이 이해하고 있는 스택 (Stack)이 자리 잡고 있습니다: 의도 파악 (Intent capture), 검색 또는 도구 (Retrieval or tools), 정책 게이트 (Policy gates), 평가 (Evaluation), 그리고 인간 에스컬레이션 (Human escalation)입니다. 노코드 (No-code) 방식의 "앱을 설명하세요" 시스템은 자유 형식의 마법이 아닙니다. 그것들은 제약이 있는 컴파일러 (Constrained compilers)입니다. 즉, 스키마 기반 UI 빌더 (Schema-bound UI builders), 타입이 지정된 워크플로 (Typed workflows), 샌드박스 런타임 (Sandboxed runtimes), 권한 모델 (Permission models), 그리고 배포 파이프라인 (Deployment pipelines)으로 구성되며, 그 앞단에 혼란스러운 인간의 의도를 이러한 제약 사항에 매핑하는 언어 모델 (Language model)이 놓여 있는 구조입니다. 매핑이 제대로 작동할 때 비개발자들도 제품을 출시할 수 있습니다. 매핑이 실패할 때, 그 원인은 대개 "모델이 멍청해서"가 아닙니다. 대개는 제품의 의도 (Product intent)가 누락되었거나, 불완전한 도메인 규칙 (Domain rules), 또는 고객이 체감할 때까지 조용한 오류 (Silent wrongness)를 감지하지 못하는 평가 루프 (Evaluation loop) 때문입니다.

이것이 바로 "AI가 코딩을 죽였다"라는 표현보다 장벽 제거 (barrier-removal) 프레임워크가 더 정직한 이유입니다. 코드가 유일한 비용이었던 적은 없었습니다. 전체 시스템에는 인증 (auth), 데이터 경계 (data boundaries), 결제 (billing), 관측성 (observability), 사고 대응 (incident response), 그리고 생성된 워크플로우가 자금이나 개인정보 (PII)를 잘못 전달했을 때의 책임 (liability) 등이 포함됩니다. 대규모 엔지니어링 인력을 위한 자금 조달, 전문 인재 채용, 인프라 구축과 같은 과거의 진입 장벽들은 관리형 API (managed APIs), 서버리스 플랫폼 (serverless platforms), 그리고 파운데이션 모델 (foundation-model) 인터페이스 덕분에 프로토타입의 초기 단계 비용 (first-mile cost)이 압축되면서 완화되었습니다. 하지만 해당 프로토타입을 부하 상황, 규제 상황, 그리고 지원 티켓 (support tickets) 상황에서도 작동 가능하게 만드는 후속 단계 비용 (second-mile cost)을 폐지하지는 못했습니다.

챗봇의 역전 현상도 동일한 아키텍처에 부합합니다. 컨택 센터 자동화 (Contact-center automation)는 명확한 해결 경로와 쉬운 롤백 (rollback)이 가능한, 볼륨이 크고 모호함이 낮은 의도 (intents)에서 번창합니다. 하지만 대화가 중대한 이해관계가 걸려 있거나, 감정적으로 격앙되어 있거나, 다자간 대화이거나, 혹은 모델이 결코 볼 수 없는 명시되지 않은 문맥 (unstated context)에 의존할 때는 실패합니다. "상담원 700명 대체"를 순수한 컴퓨팅 자원 대체로 취급하는 것은 에스컬레이션 설계 (escalation design), 품질 샘플링 (quality sampling), 컴플라이언스 로깅 (compliance logging), 그리고 브랜드 리스크를 무시하는 처사입니다. 기술적인 확장은 명확합니다. 생성형 시스템은 초안 작성과 라우팅 (routing)을 압축하는 데는 탁월하지만, 되돌릴 수 없는 결정에 대한 유일한 권한을 갖게 될 때는 값비싼 보험 (expensive insurance)이 됩니다.

따라서 매출 43% 증가 집단은 리더보드(leaderboard)의 이야기가 아닌 운영 (operations)의 이야기로 읽는 것이 가장 적절합니다. 실제 배포는 측정 가능한 수락률 (acceptance rates), 작업당 해결 비용 (cost-per-resolved-task), 피크 타임 시의 지연 시간 (latency under peak), 그리고 지원 요청이 폭증하기 전에 잘못된 자동화 경로를 더 빠르게 되돌릴 수 있는 능력에 보상을 줍니다. 이러한 지표를 무시하는 벤치마크는 계속해서 데모 (demos)를 찍어내겠지만, 운영자들은 병목 지점 (bottleneck)을 자동화하고 나머지는 그대로 두는 방식으로 조용히 승리할 것입니다.

트레이드오프 (Trade-off) 및 총 소유 비용 (TCO) 분석

총 소유 비용 (TCO, Total Cost of Ownership) 관점에서 볼 때, “AI를 더 많이 사용하라”는 전략은 종종 비용이 많이 드는 전략이 됩니다. 모델의 표면(surface)이 하나씩 추가될 때마다 프롬프트 유지보수 (prompt maintenance), 평가 하네스 (evaluation harnesses), 벤더 종속 (vendor lock-in), 속도 제한 (rate-limit) 계획, 그리고 출력값이 드리프트 (drift)할 때의 온콜 (on-call) 책임이 배수로 증가합니다. 오픈 웨이트 (open weights) 모델을 셀프 호스팅 (self-hosting)하면 토큰당 비용을 줄일 수 있지만, 이 경우 GPU 용량, 파인튜닝 운영 (fine-tune ops), 안전 필터 (safety filters), 그리고 엔지니어링 인력 비용이 다시 청구 항목으로 들어옵니다. 폐쇄형 API (Closed APIs)는 이 구성을 반대로 뒤집습니다. 운영 인력은 줄어들지만, 단위당 비용과 의존성 리스크는 높아집니다. 어떤 패턴도 공짜는 없습니다.

장벽 제거 제품 (Barrier-removal products)은 지출의 중심을 코드 작성에서 제품 정의 및 신뢰 시스템으로 이동시킵니다. 주니어 구현 인력 비용은 절감되지만, 스키마 설계 (schema design), 권한 부여 (permissioning), 감사 추적 (audit trails), 그리고 자동화가 잘못되었을 때 비용이 많이 발생하는 지점에서의 인간 검토 (human review)에는 더 많은 비용을 지불하게 됩니다. 챗봇의 퇴보 (chatbot walk-back) 현상은 TCO의 역설적인 교훈을 보여줍니다. 에스컬레이션 (escalation) 품질을 무시한 표면적인 노동력 절감은 결국 재채용 비용, 고객 이탈, 그리고 평판 손상이라는 형태로 다시 나타납니다. 합리적인 설계는 최대치의 자동화가 아닙니다. 한계 수익이 한계 유지보수 비용을 초과하는 곳에 추론 (inference)을 집중시키고, 영리하게 틀린 답변을 내놓는 것보다 침묵하는 것이 더 저렴한 곳에는 인간을 남겨두는 것입니다.

코멘트: 이것은 더 많은 AI 도구가 백만장자를 만들어낸다는 증거도, 노코드 (no-code)가 엔지니어링을 폐지했다는 증거도 아닙니다. 생성 (generation) 비용은 저렴해지고 제약 사항 발견 (constraint discovery)은 희귀해질 때, 시장은 단 하나의 진정한 병목 현상 (bottleneck)을 자동화하는 창업가에게 다시 가격을 매긴다는 증거입니다. 그리고 진짜 질문은, 당신이 여전히 모델에게 넘겨주기를 거부하고 있는 그 되돌릴 수 없는 대화가 무엇인가 하는 점입니다. (개인적인 견해)