우리는 주말 동안 즐기는 AI 사이드 프로젝트의 황금기에 살고 있습니다. 바이브 코딩 (vibe coding)과 LLM (대규모 언어 모델) 덕분에, 여러분은 커피 한 잔을 마시는 동안 빈 화면에서 시작해 기발한 아이디어를 작동하는 앱으로 만들어낼 수 있습니다.

하지만 그 캐주얼한 프로토타입 (prototype)을 대규모 기업 환경으로 가져가려는 순간, 거대한 벽에 부딪히게 됩니다. 경직된 인프라 (infrastructure), 엄격한 컴플라이언스 (compliance) 규칙, 그리고 무언가 잘못되는 것을 두려워하는 리더십 팀이 여러분의 추진력을 꺾어버릴 것입니다.

수치는 꽤 참혹합니다. AI 프로토타입 중 단 5%만이 프로덕션 (production) 단계에 도달합니다. 나머지 95%는 기업의 연옥 속으로 사라집니다.

소셜 미디어에서 사람들이 번개처럼 빠른 속도로 AI 기능을 출시하는 것을 지켜보는 동안, 여러분이 끝없는 기업 내부 검토 루프에 갇혀 있는 상황은 미칠 듯이 답답할 수 있습니다. 이 간극을 어떻게 메울 수 있을지 알아내기 위해, 저는 YouTube의 엔지니어링 현장을 조사하여 그들이 이러한 속도 대 리스크 (speed-vs-risk)의 역설을 어떻게 다루는지 살펴보았습니다.

속도 대 리스크의 역설 (The Speed-vs-Risk Paradox)

혼자 개발할 때는 실패 비용이 저렴합니다. AI 에이전트 (agent)가 제대로 작동하지 않으면, 프롬프트 (prompt)를 수정하고 다시 시작하면 그만입니다.

하지만 회사 내부에서는 제약 없는 AI 에이전트가 제멋대로 돌아다니게 두는 것이 거대한 폭발 반경 (blast radius)을 생성합니다. Emergent의 첫 번째 에피소드에서 AI 엔지니어링 리더인 Addy Osmani는 개인 프로젝트에서 10개의 병렬 에이전트를 실행했던 것에 대해 이야기했습니다. 변경 사항이 적절히 격리되지 않았기 때문에 기술 부채 (technical debt)가 즉각적으로 쌓였고, 그의 앱 중 두 개가 재앙적인 수준으로 망가졌습니다.

이제 20년 된 코드베이스 (codebase)에서 수십억 명의 사용자를 처리하는 YouTube 규모에서의 그러한 리스크를 상상해 보십시오. 실험적인 코드가 제멋대로 실행되도록 내버려 둘 수는 없습니다. 하지만 전통적인 컴플라이언스 파이프라인 (compliance pipelines)은 몇 달이 걸리며, 데모가 실제로 승인될 때쯤이면 AI 모델들은 이미 진화해 버려 여러분의 기능은 구식이 되어버립니다.

YouTube의 AI 프로토타이핑 스택 (Prototyping Stack) 도입

Google Deepmind 소속이자 전 YouTube 엔지니어인 Benji Bear는 인프라 철학을 완전히 바꿈으로써 이 문제를 해결했습니다. 그의 팀은 수동 검토 (manual reviews) 속도를 높이려고 시도하는 대신, 실험 (experimentation) 과정을 메인라인 프로덕션 서버 (mainline production servers)로부터 분리(decouple)했습니다.

그들은 개발자들에게 가장 큰 두 가지 병목 현상을 해결해 주는 프로토타이핑 스택 (Prototyping Stack)을 구축했습니다:

• 안전한 라이브 데이터 레이어 (Safe, Live Data Layer): 가짜 데이터로 진공 상태에서 테스트하는 대신, 개발자들은 Google AI Studio 템플릿을 사용하여 아이디어를 부트스트랩 (bootstrap) 합니다. 이 템플릿들은 플레이리스트, 동영상, 채널과 같은 라이브 컴포넌트에 대해 사전 인증된 읽기 전용 API 액세스를 허용하는 보안 Google Cloud 프록시 서버 (proxy server)에 연결됩니다. 이를 통해 핵심 데이터베이스를 오염시키거나 충돌시킬 위험 없이 기술적 정확성을 확보할 수 있습니다.

• 라이브 UI 인젝션 (Live UI Injection): 기능이 실제 사용자에게 어떻게 느껴지는지 확인하기 위해, 개발자들은 클라이언트 사이드 확장 래퍼 (client-side extension wrappers)를 사용하여 실험적인 UI를 로컬 브라우저에 직접 인젝션 (inject) 합니다. 이는 프로덕션 코드 (production code)로부터 완전히 격리되어 있으므로, 업데이트를 몇 분 만에 안전하게 스테이징 (staged) 하고 테스트할 수 있습니다.

이러한 설정으로 전환함으로써, YouTube는 단 하나의 기능을 검토하는 데 몇 분기(quarters)가 걸리던 방식에서, 몇 주 만에 여러 성공적인 프로토타입(예: YouTube Recap)을 사용자 조사 연구로 바로 출시할 수 있는 방식으로 변화했습니다.

버려지는 코드 (Throw-Away Code)를 수용하라

이 방식이 작동하게 하려면 상당히 거대한 심리적 변화가 필요합니다. 바로 버려지는 코드 (throw-away code)를 수용해야 한다는 점입니다.

엔지니어로서 우리는 결점 없고 영구적인 인프라 (infrastructure)를 작성하도록 훈련받았습니다. 하지만 프로토타입 코드 (prototype code)는 지저분해도 괜찮습니다. 그 유일한 목표는 사용자들이 실제로 그 기능에 관심을 갖는지 검증하는 것입니다. 정리되지 않은 혼란스러운 AI 생성 스크립트를 엔터프라이즈 코드베이스 (enterprise codebase)에 직접 강제로 밀어 넣고 정제하려고 시도하는 것은 아키텍처적 함정 (architectural trap)입니다.

대신, Google AI Studio를 사용하여 첫날부터 매우 정확한 베이스라인 (baseline)을 구축할 수 있습니다. 사용자 테스트를 실행하고 데이터를 살펴보세요. 만약 아이디어가 성공적이라면, 그 지저분한 스크립트는 버리십시오. 이미 베이스라인 파라미터 (baseline parameters)가 작동한다는 것을 증명했기 때문에, 프로덕션 (production)을 위한 깨끗한 버전을 다시 작성하는 것은 훨씬 더 빠르고, 저렴하며, 안전해집니다.

무언가를 망가뜨리지 않고 빠르게 움직이기

95%의 실패율은 실수로 간주되어서는 안 됩니다. 그것은 전략이 되어야 합니다. AI는 코드 생성을 믿을 수 없을 정도로 저렴하게 만들었으며, 우리의 역할을 구문 수호자 (syntax gatekeepers)에서 시스템 아키텍트 (System Architects)로 변화시켰습니다.

이제 우리의 역할은 팀이 초고속으로 안전하게 실패할 수 있도록 하는 읽기 전용 샌드박스 (read-only sandboxes)와 격리된 파이프라인 (isolated pipelines)을 설계하는 것입니다. 가장 큰 리스크는 지저분한 AI 코드로 서버를 망가뜨리는 것이 아닙니다. 검증 루프 (validation loops)가 너무 느려서 기술적 파도를 놓치는 것입니다.

전체적인 기술적 분석, 개발자 인터뷰, 그리고 AI 프로토타이핑 스택 (AI Prototyping Stack)에 대한 심층적인 내용을 확인하려면, YouTube에서 Emergent의 첫 에피소드를 확인하세요.