마크 큐반이 지적한 'AI는 아직 완성되지 않았다'와 기업 도입의 구현 격차에 대한 관점

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

RAISE Summit 발언에서 마크 큐반은 기업들이 수천 명을 채용하고 일부 업체가 고객사에 선행 배치 엔지니어를 두는 현실을 근거로 AI가 아직 '완성' 단계에 있지 않다고 말했다. 모델에게 특정 검색을 수행해 주간 리포트를 생성·이메일 전송하라고 시켜도 모델이 주로 JSON이나 코드 형태의 초안만 내놓고 반복적인 수정이 필요하다는 점이 실무 적용의 병목으로 나타났다. Lovable의 주간 77만 개 애플리케이션 같은 채택 지표는 도구는 이미 널리 사용되고 있으나 비엔지니어 중심의 생성물이 많아 통합·운영 역량이 더 중요해졌음을 보여준다. 따라서 기술 자체의 완성 여부보다 모델 출력을 신뢰 가능한 서비스로 연결하는 구현 능력이 현재의 핵심 경쟁력이며 이 격차를 메우는 쪽이 창업과 제품화에서 유리한 위치를 점할 것임이 분명하다.

주요 논점

01찬성다수

AI는 모델만으로 완전한 솔루션이 되지 않으며 대규모 채용과 현장 엔지니어 배치가 이를 방증한다고 주장했다.

02찬성다수

모델 출력이 JSON이나 코드 형태로만 제공되고 파이프라인 통합이 부재한 상태가 빈번하므로 구현 역량이 사업 기회로 전환된다고 보았다.

합의점 vs 논쟁점

합의점

모델 호출만으로 끝나지 않는 엔드투엔드 통합 문제는 실무에서 빈번하게 발생하며 이를 해결하는 역량이 가치 있다는 점에서 의견 일치가 이루어지고 있다.

논쟁점

일부는 대기업의 대규모 채용이 반드시 기술의 미완성의 증거는 아니라고 보며 채용은 조직 성장과 사업 확장 전략의 결과일 수 있다는 견해에서 논쟁이 발생할 여지가 있다.

실용적 조언

모델이 제공하는 구조화된 출력(JSON이나 코드)을 신뢰 가능한 서비스로 연결하려면 출력 검증과 포스트프로세싱을 자동화하는 파이프라인을 설계해야 한다. 입력에서 모델 호출까지는 단순하지만 출력 후 검증·정규화·외부 API 호출·스케줄러 연동 같은 단계가 필요하며 이 모든 단계를 코드화하고 모니터링해야 안정적 운영이 가능하다. 이러한 작업을 표준화하면 비엔지니어 사용자의 생성물을 실제 업무 자동화로 전환할 수 있다.
제품 관점에서는 비엔지니어가 만든 에셋을 안전하게 운영하기 위한 권한·검증·롤백 메커니즘을 포함하는 플랫폼을 우선 구축해야 한다. 비즈니스 요구에 따라 템플릿화된 프롬프트와 출력 스키마를 제공하고, 이상치 탐지 및 휴먼인더프루프(workflow) 지점을 명확히 정의하면 신뢰도와 채택률을 동시에 높일 수 있다. 이러한 플랫폼 방식의 접근은 개별 모델 성능의 차이에 덜 민감하면서도 실무 적용 속도를 높인다.

섹션별 상세

마크 큐반은 AI가 '끝난 기술'이라면 대기업이 대규모 채용을 하지 않을 것이라고 지적하며 기업 채용 동향을 근거로 제시했다. 그가 말한 핵심 흐름은 대기업이 모델을 내부적으로 도입하려 할 때 모델 호출 자체 외에 추가적인 인간 엔지니어링 작업이 투입된다는 점이다. 구체적 근거로 Microsoft의 대규모 채용과 Anthropic·OpenAI의 고객사 현장 엔지니어 배치 사례를 언급했다. 이로 인해 그는 기술 자체의 완성도보다 실무적 통합 능력이 경쟁 우위의 열쇠가 된다고 판단했다.

구체적 실패 양상으로 큐반은 모델에게 특정 검색을 실행해 보고서를 생성하고 주간 이메일로 전송하라고 시켰을 때 모델이 완전한 자동화 결과를 내주지 못한다고 지적했다. 입력(요청)→모델 추론→출력(보통 JSON이나 코드 형태)이 생성되는 과정에서 출력의 품질이 낮거나 구조화가 불충분해 사람이 반복해서 수정하고 재요청해야 하는 흐름이 반복된다는 점을 지적했다. 해당 사례는 모델이 단일 호출로 끝나는 해결책을 제공하지 못하고 파이프라인 수준의 엔지니어링이 필요함을 증거로 제시한다. 결과적으로 신뢰성 높은 자동화를 만들려면 출력 검증·포스트프로세싱·스케줄링 같은 운영 레이어가 필수적임이 드러난다.

큐반은 Lovable 사례를 인용해 매주 77만 개의 애플리케이션이 만들어지는 통계를 소개하며 채택 속도와 사용자층의 분포를 지적했다. 그 수치에서 30%만이 미국 기반이며 20%만이 엔지니어라는 점이 모델 도구가 엔지니어가 아닌 다른 집단에게도 널리 사용되고 있음을 시사한다. 이 데이터는 도구는 존재하지만 비엔지니어 중심의 생성물이 증가함에 따라 시스템 통합·사용자 경험·신뢰성 확보가 더 중요해졌다는 근거가 된다. 따라서 비개발자 사용자를 위한 엔드투엔드 솔루션과 플랫폼화가 중요한 사업 기회로 부각된다.

큐반의 결론은 AI 자체의 완성도가 아니라 그 완성도와 실무 적용 간의 간극이 바로 기업가들이 공략할 영역이라는 점이다. 그는 'AI가 완전하지 않다'는 사실 자체가 시장 기회를 만들며, 이 격차를 메우는 사람이 승리한다고 보았다. 이 논지는 기술적 성숙도를 전제로 한 투자가 아니라, 실제 운영·통합 역량에 투자하는 전략을 정당화한다. 따라서 창업자와 제품팀은 모델 출력의 신뢰성 확보와 배포·운영 파이프라인 설계에 자원을 집중해야 한다.

용어 해설

프롬프트 엔지니어링(Prompting): — 프롬프트 엔지니어링은 모델 입력 텍스트를 구조화하여 원하는 출력을 유도하는 기법이다. 입력(질의) 설계→모델 추론→출력 후처리라는 순서로 작동하며 신뢰도와 정확도를 높이는 데 핵심 역할을 한다. 본문에서는 모델이 단순 출력만 내놓고 파이프라인 통합이 부족할 때 프롬프트 설계와 후처리가 얼마나 중요한지 이해하는 데 이 개념이 필요하다.
MLOps(모델 운영)(MLOps): — MLOps는 모델을 개발 환경에서 운영 환경으로 배포하고 지속적으로 모니터링·업데이트하는 일련의 실무 과정이다. 코드·데이터·모델 버전 관리, 배포 파이프라인, 모니터링과 롤백 메커니즘으로 구성되어 실제 서비스 요구를 충족시킨다. 글의 맥락에서는 LLM 출력물을 안정적으로 이메일 발송·주간 리포트 자동화 같은 업무로 연결하려면 MLOps 단계의 구현이 필수임이 드러난다.
시스템 통합(System Integration): — 시스템 통합은 AI 모델의 출력을 기존 소프트웨어·데이터·업무 플로우와 연결해 엔드투엔드 자동화를 완성하는 작업이다. 입력 수집→모델 호출→출력 파싱·검증→외부 API 호출·알림 전송 같은 처리 흐름을 설계하고 안정화하는 것이 핵심이다. 본문에서는 모델이 JSON이나 코드만 내놓고 끝나는 현상이 바로 통합 단계의 부재에서 기인한다고 설명된 맥락이어서 이 용어가 중요하다.

언급된 도구

Claude중립

대화형 언어 모델로서 검색·요약·구조화된 출력 생성에 사용되는 모델

ChatGPT중립

대화형 언어 모델로서 텍스트 생성과 구조화된 응답 산출에 활용되는 제품