Inside YC's AI Playbook

Chapter 1 · 해설: 와우멘토

Inside YC's AI Playbook

A WOW Mentor strategy teardown.

오늘 와우멘토가 해부할 주제는 스타트업을 키우는 것으로 유명한 Y Combinator가, 정작 자기 조직 안에서는 AI를 어떻게 쓰고 있는가 하는 이야기입니다. 이 대화에는 게리 탄과, 예전에 옵티마이즐리라는 A/B 테스트 도구를 만들었고 지금은 YC의 모든 에이전트 인프라를 직접 지은 파트너 피트 쿠먼이 등장합니다. 그는 지난 몇 년간 YC가 주로 AI 회사에 투자해 왔고, 그 회사들에게 건네던 조언을 이제는 자기 조직에 그대로 적용해 왔다고 말합니다. 흥미롭게도 사람들은 YC가 스타트업에게 만들라고 권하는 바로 그 도구들을 YC 스스로도 안에서 짓고 쓰고 있다는 사실을 잘 모른다고, 그는 덧붙입니다. AI 이전 시대에 태어난 조직을 초-AI-네이티브 조직으로 개조하는 이 일을, 피트가 앞장서 이끌어 왔다는 것입니다. 와우멘토가 이 영상을 고른 이유는 분명합니다. 남에게 조언하는 조직이 그 조언을 자기 몸에 먼저 실험한 기록은 드물고, 그 실험 노트에는 다른 어떤 발표보다 정직한 전략이 담겨 있기 때문입니다. 이야기의 출발점은 뜻밖에도 재무팀이었습니다. 그는 약 1년 전, 몇 명의 엔지니어와 함께 재무팀의 워크플로를 돕는 작은 프로젝트를 시작했다고 말합니다. 저널 엔트리를 기록하고 priced round를 남기는, YC를 실제로 굴러가게 하는 사소하지만 복잡한 일들이었습니다. 그런데 그 과정에서 그는 이상한 루프를 발견합니다. 재무팀이 복잡한 재무 절차를 엔지니어에게 설명하면, 엔지니어가 그 절차를 통째로 감싸는 결정론적 전용 소프트웨어를 만들어 돌려주고, 그러면 다시 재무팀이 그것을 쓰는 식이었습니다. 와우멘토가 여기서 주목하는 지점은, 이 루프가 단순히 '비효율적'이라는 불평이 아니라 통제권이 엉뚱한 곳에 놓여 있다는 진단이었다는 사실입니다. 워크플로를 아는 사람은 재무팀인데, 그것을 코드로 옮길 권한은 엔지니어에게만 있었습니다. 그가 세운 원래 목표는 이 크레이지한 루프에서 소프트웨어 엔지니어를 빼내고, 재무팀이 러비 코드가 아니라 영어 프롬프트로 자기 워크플로를 스스로 인코딩하도록 만드는 것이었습니다. 같은 시기에 그는 자기 자신의 노트북에서 전혀 다른 세계를 경험하고 있었습니다. 윈드서프와 커서 같은 1세대 에이전트 코딩 도구가 자리를 잡았고, 마침 Claude Code가 등장하던 무렵이었습니다. 그는 그 도구들이 자신에게 초능력을 주는 것 같았다고 말합니다. 회사에서 소프트웨어를 짓는 낡고 고전적인 방식과, 자기 기계에서 벌어지던 새로운 방식 사이의 간극이 점점 더 벌어지는 것을 그는 지켜보았습니다. 회사에서는 좁은 상자 안에서 조심스럽게 움직이는데, 집에서는 무엇이든 할 수 있는 이 분열 — 와우멘토가 이 대화 전체의 뿌리로 짚는 것이 바로 이 격차입니다. YC 내부에서 벌어진 모든 실험은 결국 '집에서 느낀 자유를 일터로 가져오는 일', 그 하나의 문장으로 요약됩니다. 뒤에 나올 오픈 클로 같은 흐름이 예고하듯, 세상을 가로막던 것은 보안과 프라이버시와 잘못될 수 있는 모든 것에 대한 걱정이었고, 걱정을 조금 덜어내는 순간 이 도구들이 믿기 힘들 만큼 강력해진다는 것을 그는 반복해서 강조합니다. 흥미로운 대목은, 첫 번째 마법이 에이전트 코딩이 아니라 SQL이었다는 점입니다. 게리 탄은 몇 년 전 LLM이 막 나왔지만 아직 에이전트 코딩은 없던 시절, 그들이 실패한 스타트업으로 여러 번 봤던 아이디어가 바로 'LLM에게 SQL을 쓰게 하는 것'이었다고 말합니다. 그런데 이번에는 그것이 작동했습니다. 엔지니어 배경이 전혀 없는, 다만 매우 똑똑한 재무팀 사람들이 이 도구로 진짜 질문을 던지기 시작한 것입니다. 처음의 전용 도구는 곧 더 일반적인 에이전트 루프로 다시 쓰였고, 여기에 YC 전용 도구들을 담는 공유 툴 레지스트리가 붙었습니다. 그다음 재러드라는 파트너가 두 개의 도구를 만듭니다. 하나는 데이터베이스에 대해 읽기 전용 SQL 쿼리를 돌리는 도구, 다른 하나는 모델 파일을 읽는 도구였습니다. 그는 자신이 규칙을 어기는 기분이었다고 털어놓습니다. 처음엔 좁게 제한된 도메인의 도구만 있었는데, 성에 차지 않아 결국 프로덕션 데이터베이스에 '무엇이든 짓밟을 수 있는' 완전한 접근 권한을 준 도구를 밤늦게 몰래 배포했다는 것입니다. 그리고 그것은 아주, 아주 잘 작동했습니다.

왜 겨우 SQL 쿼리가 그렇게 강력했을까요. 와우멘토가 여기서 강조하는 것은 YC가 가진 남다른 이점입니다. YC는 존재해 온 내내 대부분 자체 소프트웨어 위에서 돌아갔고, 그 소프트웨어는 모두 하나의 Postgres 데이터베이스에 얹혀 있었습니다. 투자한 모든 회사가 담긴 회사 테이블, 창업자 테이블, 재무 거래 테이블, 그리고 파트너가 사내 CRM에 남긴 메모까지 — 다른 회사들이 외부 SaaS에 맡기는 기능들을 YC는 전부 직접 지었기 때문에, 세상에서 가장 중요한 맥락이 한곳에 모여 있었습니다. 그래서 그는 이제 "지난 네 배치 동안 우주 관련 회사에 투자한 투자자를 전부 보여 줘" 같은 질문을 던질 수 있게 되었다고 말합니다. 스키마가 어떻게 짜여 있는지에 대한 약간의 설명만 얹으면, 에이전트는 이 사업에 관한 거의 임의의 질문에 답할 수 있었습니다. 그가 처음 그 장면을 봤을 때를 '마법의 순간'이라 부르는 것은 과장이 아닙니다. 와우멘토가 여기에 덧붙이는 관찰은, 다른 회사들이 컴퍼니 테이블 하나조차 세일즈포스나 외부 SaaS에 흩어 두는 동안 YC는 그 모든 것을 자체 소프트웨어로 지어 한 스키마 안에 눕혀 두었다는 점, 바로 그 '오래된 결정'이 지금의 이점으로 되돌아왔다는 사실입니다. 즉 AI 시대의 무기는 갑자기 산 것이 아니라, 오래전에 통제권을 남에게 넘기지 않았던 조직에게 이자처럼 붙어 있었던 것입니다. 그런데 진짜 변화는 답을 얻기 쉬워졌다는 데 있지 않았습니다. 그는 이것이 질문의 '수'와 '대담함'을 동시에 폭발시켰다고 말합니다. 예전 BI 도구 시절에는 "우주 회사에 투자한 투자자가 누구냐" 같은 질문 하나에 몇 시간의 SQL 작성이 필요했고, 정말 중요하지 않으면 아예 시도하지 않았습니다. 와우멘토가 이 대목에 붙이는 이름은 제번스 역설입니다. 무언가를 얻는 비용이 급격히 떨어지면 그 소비는 오히려 폭증한다는 것입니다. 데이터 사이언스팀의 문을 두드리고 백로그가 처리되기를 기다려야 한다면 사람은 질문을 훨씬 덜 하게 됩니다. 반대로 팀 사이의 왕복이 사라지면, 감히 던지지 못했던 크고 복잡한 질문이 쏟아집니다. 와우멘토가 이 지점을 중요하게 짚는 이유는, 대부분의 조직이 AI의 성과를 '기존 질문에 더 빨리 답하기'로만 상상하기 때문입니다. 그러나 이 대화가 증언하는 진짜 도약은 답의 속도가 아니라 질문의 지평 자체가 넓어지는 데 있습니다. 예전에는 던질 엄두조차 못 내던 질문이 일상이 되면, 조직이 자기 자신에 대해 알 수 있는 것의 총량이 달라집니다. 그가 2026년인 지금도 대다수 조직이 여전히 옛 세계, 즉 몇 시간짜리 SQL과 부서 간 대기줄의 세계에 산다고 말할 때, 와우멘토는 그 격차가 곧 기회의 크기라고 읽습니다. 갈 길이 멀다는 사실이야말로 지금 이 게임이 흥미로운 이유라는 것입니다. 옛 세계의 조직이 어떻게 날개를 달 수 있느냐는 질문에, 게리 탄은 데이터 사이언스의 역사를 끌어옵니다. 구글 초기 엔지니어들이 스키마와 조인 대신 맵리듀스가 가능한 하나의 큰 테이블, 즉 빅테이블을 만들어야 했던 것처럼, 지금 다시 같은 일이 벌어지고 있다는 것입니다. 그는 이것을 카파시 스타일의 지식 LLM 위키라 부르며, 자신이 만든 G brain을 예로 듭니다. 여러 시스템에 접근할 수 있는 오픈 클로에 데이터를 끌어와, 자신에게 의미 있는 스키마로 정규화가 아니라 오히려 비정규화한다는 것입니다. 에이전트 검색에 최적화된 형태로 데이터를 눕히는 이 작업에는 RAG, 그래프 RAG, 하이브리드 RRF, 리랭킹처럼 검색에 관해 알려진 모든 기법이 들어갑니다. 그리고 에이전트에게 '영혼'과 데이터를 주고 그것이 사용자를 알게 되면, 마치 모퉁이 너머를 보듯 질문의 의도까지 해석해, 그를 정말 잘 아는 사람만이 줄 수 있을 법한 답을 내놓는다고 그는 말합니다. 그는 이 도구들이 MCP와 CLI 모두를 잘 다루지만 오히려 CLI에서 조금 더 낫다고 관찰하며, 그래서 데이터를 깔끔한 API 뒤에 숨기기보다 에이전트가 직접 훑을 수 있는 형태로 눕혀 두는 편을 택합니다. 와우멘토가 여기서 뽑아내는 실천 원칙은 하나입니다. 데이터를 MCP로 감싸는 것도 가능하지만, 지금은 에이전트가 이해하기 좋은 형태로 비정규화해 '에이전트를 위한 빅테이블'을 만들어 두는 편이 더 강하다는 것입니다. 그다음 그는 우리가 아직 에이전트의 '싱글 플레이어 시대'에 있다고 진단합니다. Claude Code, 코덱스, Pi, 오픈 클로, 헤르메스 같은 인기 있는 하니스는 모두 한 명의 사람이 한 대의 기계에서 쓰도록 설계되었고, 그 환경에서는 무엇이든 할 수 있어 재미있고 강력합니다. 아직 아무도 잘 풀지 못한 문제는 그 초능력을 팀과 조직 단위로 끌어올리는 '멀티 플레이어 하니스'입니다. 그리고 그가 두 살만 넘으면 이미 '레거시'인 조직에게 권하는 두 가지 토대가 여기서 나옵니다. 첫째는 앞서 말한 공통 맥락 레이어, 즉 중요한 내부 맥락이 최대한 모인 데이터 창고입니다. 모노레포 안의 코딩 에이전트가 더 효율적이듯, 모든 것이 한 스키마에 담긴 단일 데이터베이스 위의 에이전트가 훨씬 강했다는 것입니다. 둘째는 내부 툴 레지스트리입니다. 처음엔 SQL 쿼리 능력을 포함해 20개 남짓이던 도구가, 팀마다 필요할 때마다 더해지며 지금은 350개가 넘습니다. 오피스 아워를 관리하고, 저널 엔트리를 기록하고, 행사를 운영하는 도구들이 한곳에 모이면, 사내 에이전트뿐 아니라 각자의 기계에서 도는 Claude Code에서도 그것을 쓸 수 있게 됩니다. 와우멘토가 강조하는 것은, 도구를 한곳에 모으는 행위 자체가 사람과 에이전트를 같은 능력의 지평에 세운다는 점입니다.

… The rest of this chapter continues in the full edition, available with a subscription.

Listen to this chapter