AI 네이티브 회사 만드는 법: Y Combinator (youtube.com) ↗

• Diana(YC 파트너)의 메시지: AI를 회사 옆에 두는 도구로 보지 말고, 회사 자체를 AI 위에서 다시 짜라. 같은 조직도 그대로 두고 AI만 끼우면 변화의 본질을 놓침
• 진짜 변화는 생산성 향상이 아니라 “옛날 팀 전체가 하던 일을 1명이 끝내는” 새 능력. 1명에 에이전트를 여러 개 붙이면 1000명 몫까지 가능
• 핵심 실천 세 가지. (1) 회사 안 모든 정보를 AI가 읽을 수 있게 정리, (2) 코드는 AI가 짜고 사람은 “뭘 만들지”만 정의, (3) 중간관리자 자리를 AI가 대신
• 인원 늘리지 말고 AI 사용량을 늘리는 운영, 즉 토큰 맥싱으로 가야. 큰 회사는 옛 절차 풀고 적응하느라 늦지만, 1인기업·작은 팀은 처음부터 이렇게 짤 수 있어 가장 유리

회사를 AI가 통째로 읽게 만든다는 게 무슨 뜻?

• 옛날 회사는 정보가 회의·DM·머릿속·이메일·문서에 흩어져 있어 AI가 분석할 수가 없음
• 새 방식은 회의 다 자동 기록, DM·이메일 줄이고 채널마다 에이전트, 매출·영업·엔지니어링·인사 데이터를 한 대시보드로 통합
• 이렇게 해두면 에이전트가 Linear·Slack·고객 피드백·Notion·세일즈 콜까지 다 보고 “다음 2주에 뭘 해야 하는지”까지 직접 제안. 일부 YC 회사는 시간 절반에 처리량 10배
• 핵심은 결과까지 자동으로 챙겨서 다음 행동에 반영되는 한 바퀴를 회사가 도는 것. 자동 온도 조절기처럼 결과 보고 다음을 스스로 잡는 구조

코드는 AI가 짜고, 사람은 “뭘 만들지”만 정한다

• 옛날: 엔지니어가 코드를 한 줄씩 직접 작성
• 새 방식(소프트웨어 팩토리): 사람은 “이걸 만들어줘”(스펙)와 “이게 됐는지 어떻게 알지?”(테스트)만 쓰고, 에이전트가 코드 짜고 테스트 통과할 때까지 알아서 반복
• 이미 일부 회사는 코드 저장소에 손으로 쓴 코드가 0줄, 스펙·테스트만 둠 (Strong DM AI팀)
• 1명 엔지니어가 에이전트 떼에 둘러싸이면 옛날엔 못 만들던 걸 만들 수 있게 됨. 1000배·10000배 엔지니어가 가능해진 메커니즘이 이거

중간관리자가 사라지면 누가 남나?

• 중간관리자가 본질적으로 하는 일은 “정보를 위·아래로 옮기는 것”. AI가 그 일을 대신하면 사람이 정보 전달자로 일할 자리가 없어짐
• Block의 Jack Dorsey도 같은 결론. 회사 자체를 AI 한복판 + 사람은 가장자리에서 가이드만 하는 구조로 재설계해야
• 미래 회사에 남는 3가지 유형
  • IC (직접 만드는 사람): 엔지니어만 아니라 영업·CS·운영 다 포함. 회의에 발표 자료 말고 작동하는 프로토타입을 들고 옴
  • DRI (결과 책임자): 한 가지 결과(고객·매출·제품)에 끝까지 책임. 다른 사람 일을 조율하는 게 아니라 본인이 결과를 만들어냄
  • AI 파운더 타입: 직접 만들고 본보기로 끌어감. AI 전략을 위임 말고 본인이 최전선
• 토큰 맥싱: 인원 대신 AI 사용량을 늘림. API 청구서가 불편할 정도로 커도 옛날 인건비보다 훨씬 쌈

영역	예전 회사	AI 네이티브 회사
AI 위치	곁에 두는 도구	회사를 굴리는 엔진
정보 흐름	사람이 위아래로 옮김	AI가 자동 처리 + 다음 행동에 반영
코드 생산	엔지니어가 직접 작성	사람은 스펙·테스트, 코드는 AI
비용 구조	직원 수 늘리기	AI 사용량 늘리기

”토큰 맥싱”이 정확히 무슨 뜻?

인원 대신 AI 사용량(토큰)을 적극 늘리는 운영. 한 사람이 AI에 일을 많이 시키면 옛날 큰 팀 몫을 처리 가능. API 청구서가 커도 인건비보다 훨씬 싸다는 주장.

DRI는 매니저와 뭐가 다른가?

DRI는 한 가지 결과에 끝까지 책임지는 사람. 다른 사람 일을 조율하는 게 아니라 본인이 그 결과를 직접 만들어냄. “1명 1결과, 숨을 곳 없음”이 핵심.

1인기업이 이걸 왜 신경 써야 하나?

Diana의 결론이 “작은 사람일수록 유리하다”여서. 풀어야 할 기존 시스템·다시 가르칠 직원이 없으니 처음부터 AI 네이티브로 짤 수 있음.

1인기업 관점

“작을수록 유리하다”가 핵심인 듯. 다만 1인기업이 “회사가 결과 보고 스스로 고치는 구조”를 어떻게 실제로 만들지는 모호한 게 함정. usedesktop 만들면서도 회의·DM·결정이 다 본인 머릿속에서 일어나서 “AI가 검색하게” 만들기 자체가 어려움. 1인 버전은 작업·고객 응대·코드 변경을 전부 텍스트 로그로 남겨두는 것에서 시작하는 게 현실적인 듯.

---

관련: Block의 위계 → 지능 계층 재설계 글이 같은 주장을 더 자세히 다룸. 1000배 엔지니어 얘기는 에이전트 수보다 기본기가 중요하다는 반론도 같이 보면 균형이 맞음.