Y Combinator가 말하는 AI-Native Company의 모습
최근 Y Combinator가 공개한 몇 개의 영상을 연달아 보다 보면 하나의 공통된 메시지가 반복해서 등장한다.
AI를 기존 회사에 기능처럼 붙이는 것만으로는 부족하다.
ChatGPT를 쓰고, Claude Code나 Codex를 도입하고, 직원들이 AI로 문서를 더 빨리 작성하게 만드는 정도는 AI 시대에 맞는 회사의 완성형이 아니라는 것이다.
YC가 이야기하는 더 근본적인 변화는 다음과 같다.
AI가 존재한다는 사실을 전제로 회사의 제품, 조직, 업무 방식 자체를 처음부터 다시 설계해야 한다.
이를 세 개의 영상은 서로 다른 관점에서 설명한다.
- 무엇을 팔 것인가
- 회사를 어떻게 운영할 것인가
- 그 회사가 어떻게 스스로 개선되게 만들 것인가
세 영상을 하나로 합치면, YC가 그리고 있는 AI-Native Company의 모습이 꽤 선명하게 드러난다.
1. AI를 팔지 말고, AI가 수행한 일을 팔아라
첫 번째 변화는 제품에서 시작한다.
전통적인 SaaS는 고객에게 소프트웨어를 제공한다.
예를 들어 회계 SaaS라면 고객이 직접 데이터를 입력하고 기능을 사용해 회계 업무를 처리한다.
구조를 단순화하면 이렇다.
고객 → Software → 고객이 업무 수행
AI Copilot도 본질적으로 크게 다르지 않다.
고객 → AI Tool → 고객이 업무 수행
AI가 일부 작업을 대신해주긴 하지만 최종적으로 일을 수행하는 주체는 여전히 고객이다.
YC가 이야기하는 AI-native service company는 여기서 한 단계 더 나아간다.
고객 → 결과 요청 → AI가 업무 수행 → 완성된 결과 제공
예를 들어 고객에게 세금 신고 AI를 제공하는 대신 세금 신고 자체를 완료해서 전달하는 회사를 만드는 것이다.
고객은 AI를 사용하고 싶은 것이 아니다.
고객이 원하는 것은 결국 일이 끝나는 것이다.
그래서 AI 시대의 중요한 질문은
“어떤 AI 기능을 만들까?”
보다
“사람들이 지금 다른 사람이나 회사에 돈을 주고 맡기고 있는 일 중 무엇을 AI가 수행할 수 있을까?”
에 가까워진다.
이 변화가 중요한 이유는 시장의 크기 때문이다.
SaaS가 경쟁하는 시장은 주로 소프트웨어 예산이다.
하지만 AI 서비스 회사가 경쟁하는 시장은
- 회계
- 세무
- 법률
- 보험
- 의료 행정
- 고객지원
- 컨설팅
- 운영
처럼 훨씬 큰 서비스 비용과 인건비 시장이다.
즉 AI 스타트업이 기존 SaaS 시장을 조금 더 효율적으로 만드는 것이 아니라, 기존의 서비스 산업 전체를 다시 설계할 가능성이 생긴다.
2. AI 발전이 우리 회사를 없앨까, 더 강하게 만들까
AI 비즈니스를 만들 때 중요한 질문도 하나 있다.
기반 모델이 훨씬 좋아졌을 때 우리 회사는 더 강해지는가?
예를 들어 어떤 서비스가 단순히 GPT를 예쁜 UI로 감싸놓은 정도라면 모델이 좋아질수록 고객이 직접 GPT를 사용할 가능성이 커진다.
회사의 가치가 오히려 감소할 수 있다.
반대로 좋은 AI-native service는 AI가 좋아질수록 경제성이 개선된다.
AI 성능 향상
→ 자동화할 수 있는 작업 증가
→ 인간 개입 감소
→ 처리량 증가
→ 비용 감소
→ 마진 증가
즉 모델 발전이 경쟁 위협이 아니라 회사의 성장을 가속하는 구조여야 한다.
이를 YC에서는 일종의 Sam Altman Test처럼 설명한다.
“Sam Altman이 내일 훨씬 뛰어난 모델을 발표했을 때 우리 회사에 좋은 소식인가, 나쁜 소식인가?”
좋은 AI-native 회사라면 답은 좋은 소식이어야 한다.
3. 회사를 AI 위에서 돌아가는 시스템으로 만들어라
제품을 AI-native하게 만드는 것만으로는 충분하지 않다.
회사 내부도 같은 방식으로 다시 설계할 수 있다.
기존 회사는 보통 이런 형태다.
직원 → 팀장 → 부서장 → 임원 → CEO
정보가 아래에서 위로 올라가고, 의사결정은 다시 위에서 아래로 내려온다.
관리자의 업무 중 상당 부분은 사실 다음과 같은 일이다.
- 정보 취합
- 요약
- 전달
- 업무 배분
- 진행 상황 확인
- 일정 관리
- 문제 escalation
즉 조직의 상당 부분이 일종의 Human Middleware 역할을 한다.
AI가 검색, 요약, 분석, 모니터링, routing을 할 수 있게 되면 이 구조도 달라질 수 있다.
YC가 제안하는 방향은 회사를 Fully Queryable Company로 만드는 것이다.
회사에서 발생하는 모든 중요한 정보를 AI가 읽고 이해할 수 있게 만든다.
예를 들면:
- Slack
- 이메일
- Google Docs
- Notion
- GitHub
- Linear/Jira
- 고객지원 기록
- Sales Call
- 회의 녹취
- CRM
- 제품 사용 데이터
- 매출 지표
등이다.
그러면 AI에게 이런 질문을 할 수 있다.
지난 한 달 동안 고객들이 가장 많이 요청한 기능은 무엇인가?
우리가 현재 개발하고 있는 기능과 고객 요구가 일치하는가?
지난 Sprint가 예상보다 늦어진 이유는 무엇인가?
이 고객이 이탈한 가장 가능성 높은 이유는 무엇인가?
AI가 단순히 인터넷 지식을 가지고 답하는 것이 아니라 우리 회사의 역사와 맥락을 이해하고 답하는 것이다.
이것이 일종의 Company Brain이다.
4. 중요한 것은 모델보다 Context다
AI가 회사 업무를 제대로 수행하려면 충분한 Context가 필요하다.
우리는 종종 AI에게 매우 적은 정보를 주고는 결과가 좋지 않다고 평가한다.
하지만 사람에게도
- 회사가 무엇을 만드는지 모르고
- 고객이 누구인지 모르고
- 이전 회의를 볼 수 없고
- GitHub에 접근할 수 없고
- 어떤 전략적 결정을 했는지도 모르는 상태에서
“다음에 무엇을 해야 할지 결정해봐”라고 한다면 좋은 답을 기대하기 어렵다.
AI도 마찬가지다.
따라서 중요한 것은 단순히 좋은 LLM을 사용하는 것이 아니라
LLM + Company Context
를 만드는 것이다.
앞으로 AI 회사의 중요한 기술적 자산 중 하나는 모델 자체보다 회사의 맥락을 얼마나 잘 구조화하고 AI에게 제공할 수 있는가가 될 가능성이 크다.
5. 중요한 업무는 반드시 Artifact를 남겨야 한다
Fully Queryable Company를 만들기 위해서는 또 하나의 원칙이 필요하다.
중요한 일이 발생했다면 반드시 기록이 남아야 한다.
예를 들어 창업자 두 명이 커피를 마시면서 가격 정책을 변경하기로 결정했다고 하자.
하지만 그 결정이 어디에도 기록되지 않았다면 AI가 보는 회사 세계에서는 그 결정이 존재하지 않는 것과 같다.
그래서 AI-native 회사에서는 중요한 업무가 발생하면 가능한 한 Artifact를 남긴다.
회의를 했다면 transcript가 남고,
제품 결정을 했다면 decision document가 남고,
코드를 수정했다면 PR이 남고,
고객과 이야기했다면 conversation 기록이 남는다.
이를 한 문장으로 표현하면:
Record Everything.
다만 모든 데이터를 그대로 LLM의 Context Window에 집어넣는다는 뜻은 아니다.
원본 데이터는 시간이 지나면서
Raw Data → Summary → Category → Knowledge → Company Context
처럼 압축되고 구조화되어야 한다.
여기서부터 AI-native company는 단순한 SaaS 회사가 아니라 하나의 지식 시스템에 가까워진다.
6. 회사 업무를 Closed Loop로 만들어라
정보를 AI가 읽을 수 있게 만드는 다음 단계는 AI가 행동하게 만드는 것이다.
기존 회사의 업무는 상당수가 Open Loop다.
예를 들어:
회의 → 결정 → 개발 → 출시
하고 끝난다.
나중에 누군가 생각나면
“그 기능 효과 있었나?”
라고 확인한다.
AI-native 회사는 업무를 Closed Loop로 만든다.
구조는 대략 다음과 같다.
Sense → Decide → Act → Evaluate → Learn → 다시 Sense
Sense
현실을 관찰한다.
- 고객 문의
- 제품 사용 데이터
- 장애 로그
- 매출
- 지원 티켓
Decide
문제를 분석하고 다음 행동을 결정한다.
Act
실제로 행동한다.
- 코드 수정
- CRM 업데이트
- 문서 작성
- 고객 메시지 초안
- 데이터 분석
Evaluate
행동 결과를 측정한다.
Learn
결과를 다음 행동의 Context로 다시 사용한다.
그리고 이 과정이 반복된다.
7. 예를 들어 제품 개발도 하나의 AI Loop가 된다
회원가입 Funnel을 예로 들어보자.
방문 → 가입 → Onboarding → 결제
AI가 제품 데이터를 계속 관찰하다가
Onboarding 3단계에서 이탈률이 지나치게 높다.
는 사실을 발견할 수 있다.
그러면 다음과 같은 Loop가 가능하다.
문제 발견
→ 원인 분석
→ 개선안 생성
→ A/B Test 구현
→ 배포
→ 결과 측정
→ Winner 선택
→ 다음 Bottleneck 탐색
기존에는 사람이
“이번 Sprint에는 Conversion Rate를 개선해볼까?”
라고 생각해야 일이 시작됐다.
AI-native system에서는 시스템 자체가 문제를 탐색하고 개선 작업을 제안할 수 있다.
8. Customer Support와 Product Development의 경계도 흐려진다
예를 들어 고객센터에
“CSV Export 기능 없나요?”
라는 문의가 반복적으로 들어온다고 해보자.
기존 회사에서는:
고객 문의
→ Support 팀
→ Slack 공유
→ Product Manager
→ 회의
→ Roadmap
→ Engineering
이라는 긴 과정을 거칠 수 있다.
AI-native 회사에서는 다음과 같은 흐름도 가능하다.
Support tickets
→ AI가 요청을 clustering
→ 빈도와 고객 가치 분석
→ 현재 제품 전략과 비교
→ 기능 구현 가치 판단
→ Coding Agent가 구현
→ QA Agent 검토
→ Human Approval
→ 배포
즉 고객 피드백에서 제품 개선까지 이어지는 전체 과정이 하나의 Loop가 된다.
9. 개발자의 역할도 코드 작성에서 Spec과 Evaluation으로 이동한다
소프트웨어 개발에서도 비슷한 변화가 나타난다.
기존에는 개발자가 대부분의 코드를 직접 작성했다.
AI Coding Agent가 발전하면서 구조가 점점 이렇게 바뀐다.
Spec + Tests / Evaluation
↓
Coding Agent
↓
코드 생성
↓
테스트
↓
실패
↓
Agent 수정
↓
통과할 때까지 반복
이 구조에서 사람의 중요한 역할은
“코드를 어떻게 구현해야 하는가?”
보다
“무엇을 만들어야 하고, 어떤 조건을 만족하면 성공인가?”
를 정의하는 것이다.
즉 개발자의 핵심 역량이
Code Writing
에서
Problem Definition + Spec + Evaluation
쪽으로 이동하기 시작한다.
10. 한 명의 사람이 여러 Agent를 지휘하는 조직
이런 구조가 발전하면 사람 한 명이 만들어낼 수 있는 Output도 크게 증가한다.
예전에는 한 개발자가 하나의 작업을 수행했다면 앞으로는 한 사람이 여러 Agent를 동시에 관리할 수 있다.
예를 들어:
Engineer
- Research Agent
- Coding Agent
- Testing Agent
- Debugging Agent
- Documentation Agent
를 동시에 운영한다.
이 때문에 YC에서는 다소 과장된 표현이지만 1,000x Engineer, 심지어 10,000x Engineer 같은 표현까지 사용한다.
핵심은 천재 개발자가 등장한다는 뜻이 아니다.
한 사람이 AI 시스템을 통해 수많은 작업을 병렬로 수행할 수 있게 된다
는 의미다.
11. Headcount를 늘리기 전에 Token을 늘려라
여기서 조직 운영 원칙도 달라진다.
기존 회사에서는 일이 많아지면 자연스럽게 이렇게 생각한다.
“사람을 더 채용해야겠다.”
AI-native company는 먼저 이렇게 질문한다.
“현재 팀이 Agent를 더 활용해서 처리할 수 없는가?”
이를 YC에서는 재미있게
Burn Tokens, Not Headcount
또는 Token Maxing
이라는 표현으로 설명한다.
예를 들어 새로운 개발 업무가 늘어났다고 해서 개발자를 바로 5명 더 채용하기보다,
- Coding Agent
- Research Agent
- Test Agent
- Automation
을 이용해 기존 팀의 Output을 먼저 확대한다.
API 비용이 수천 달러 증가하더라도 그것이 수명의 인건비를 대체할 수 있다면 경제적으로는 훨씬 저렴할 수 있다.
물론 단순히 Token을 많이 쓰는 것이 목표라는 의미는 아니다.
핵심은:
인간 노동을 추가하기 전에 computational intelligence를 추가한다.
는 사고방식이다.
12. AI가 일을 하는 것보다 더 중요한 단계: AI가 자신을 개선한다
세 번째 YC 영상에서 가장 흥미로운 부분은 여기다.
단순히 AI가 업무를 수행하는 것으로 끝내지 않는다.
AI가 자신의 실패를 관찰하고 시스템 자체를 개선할 수 있다.
YC 내부 사례 중 하나에서는 직원 질문에 답하는 Agent가 있었다.
처음에는 평범한 RAG Agent였다.
그런데 여기에 또 다른 Agent를 붙였다.
두 번째 Agent의 역할은:
첫 번째 Agent가 답하지 못한 질문을 관찰하는 것
이었다.
예를 들어 첫 번째 Agent가 어떤 데이터에 접근하지 못해 질문에 실패한다.
그러면 Monitoring Agent가
왜 답하지 못했는가?
를 분석한다.
필요한 Database View가 없다면:
DB View 설계
→ 코드 작성
→ Pull Request 생성
→ Code Review
→ Merge
→ Deploy
까지 진행한다.
그 결과 다음 날 같은 질문을 받으면 이제 첫 번째 Agent가 답할 수 있게 된다.
이 순간부터 AI 시스템은 단순히 업무를 수행하는 도구가 아니다.
AI가 자신이 일을 더 잘할 수 있도록 환경 자체를 개선하기 시작한다.
YC가 말하는 Recursive Self-Improving Loop다.
13. 결국 회사는 수많은 AI Loop의 집합이 될 수 있다
이를 전체적으로 보면 미래의 회사는 다음처럼 보일 수 있다.
Human Founder / DRI
↓
Company Brain
↓
Product Agent
Engineering Agent
Research Agent
Support Agent
Operations Agent
↓
각 Agent가 Tools와 Data를 사용
↓
결과 측정
↓
Company Brain 업데이트
↓
다음 행동
↓
반복
여기서 인간이 완전히 사라진다는 뜻은 아니다.
오히려 인간의 역할이 바뀐다.
AI가 잘하는 것은:
- 검색
- 분석
- 반복
- 모니터링
- 최적화
- Routing
- 실행
이다.
인간이 담당하는 것은:
- 새로운 전략
- 가치 판단
- 책임
- 윤리
- 관계
- 협상
- 모호한 상황에서의 판단
같은 영역이다.
즉 인간은 시스템의 모든 작업을 직접 수행하는 존재에서
목표를 정하고 중요한 판단을 내리는 존재
로 이동한다.
14. Operation 자체가 Product가 된다
AI-native service company에서 중요한 또 하나의 변화는 운영 자체가 제품이 된다는 점이다.
고객 입장에서는 회사 내부에서 AI를 얼마나 쓰는지 중요하지 않다.
고객이 보는 것은:
- 결과가 정확한가
- 빠른가
- 일관적인가
- 가격이 합리적인가
이다.
따라서 회사는 내부적으로 다음 지표를 집요하게 관리해야 한다.
- Automation Rate
- Human Intervention Rate
- Cycle Time
- Throughput
- Error Rate
- Cost per Task
- Output Variance
특히 Variance가 중요하다.
예를 들어 AI 결과가
95점 → 94점 → 96점 → 40점 → 95점
이라면 평균적으로는 좋아 보여도 서비스로 사용하기 어렵다.
오히려
88점 → 89점 → 87점 → 90점 → 88점
처럼 안정적인 결과가 고객에게 더 신뢰를 줄 수 있다.
그래서 Human-in-the-loop 역시 AI의 한계를 보완하기 위한 임시 장치라기보다 품질 편차를 통제하는 시스템 구성요소로 볼 수 있다.
15. Preserve Data, Throw Away Software
AI 시대에 소프트웨어 자체의 가치도 조금 달라질 수 있다.
과거에는 내부 Dashboard 하나를 만드는 데도 몇 주나 몇 달이 걸릴 수 있었다.
그래서 Software는 중요한 자산이었다.
하지만 Agent가 내부 Tool을 몇 시간 만에 만들 수 있다면 상황이 달라진다.
필요함
→ Agent가 만듦
→ 사용
→ 필요 없어짐
→ 삭제
→ 나중에 필요하면 다시 생성
이런 식으로 Software가 점점 Disposable해질 수 있다.
반대로 계속 중요해지는 것은:
- 고객 데이터
- 회사의 역사
- 의사결정
- 비즈니스 Context
- Process
- Knowledge
- Skills
이다.
그래서 YC가 제안하는 관점 중 하나를 압축하면:
Preserve Data, Throw Away Software.
소프트웨어보다 Context가 더 중요한 자산이 될 수 있다는 이야기다.
16. 세 영상을 하나로 연결하면
세 영상은 사실 하나의 흐름을 말하고 있다.
1단계 — 무엇을 팔 것인가
AI를 팔지 말고 AI가 수행한 결과를 팔아라.
Software가 아니라 Work를 판매한다.
2단계 — 그 회사를 어떻게 운영할 것인가
회사 전체를 AI가 이해하고 실행할 수 있는 시스템으로 만들어라.
Company Brain과 Fully Queryable Company를 만든다.
3단계 — 그 시스템을 어떻게 성장시킬 것인가
AI의 실행 결과가 다시 시스템으로 들어와 시스템 자체를 개선하게 만들어라.
Recursive Self-Improving Loop를 만든다.
세 단계를 합치면 이렇게 된다.
Customer
↓ 결과 요청
AI-Native Company
↓
Company Brain
↓
AI Agents + Human Experts
↓
업무 수행
↓
결과 측정
↓
Knowledge 업데이트
↓
Agent / Process 개선
↓
다음 작업
↺
AI 기능이 있는 회사와 AI-Native Company는 다르다
앞으로 거의 모든 회사가 AI를 사용할 것이다.
하지만 AI를 사용한다고 해서 모두 AI-native company인 것은 아니다.
기존 조직에 ChatGPT, Claude, Copilot을 추가하는 것은 AI-enabled company에 가깝다.
AI-native company는 애초부터 질문이 다르다.
사람이 이 일을 해야 하는가?
사람이 정보를 전달해야 하는가?
사람이 매번 문제를 발견해야 하는가?
사람이 직접 코드를 작성해야 하는가?
회사의 경험이 다음 업무에 자동으로 반영되고 있는가?
그리고 이런 질문을 반복하면서 회사 전체를 다시 설계한다.
결국 YC가 그리고 있는 미래의 스타트업은 많은 사람이 AI를 사용하는 회사라기보다,
소수의 사람이 수많은 AI Agent와 자동화된 Loop를 지휘하는 회사
에 더 가깝다.
AI가 직원의 생산성을 조금 올려주는 시대에서,
AI가 회사의 업무를 수행하고,
회사가 그 결과를 학습하고,
AI가 다시 더 나은 방식으로 일을 수행하는 시대로 넘어가는 것이다.
그리고 이 변화가 충분히 진행된다면 미래 스타트업에서 가장 중요한 경쟁력은 단순히 어떤 모델을 사용하느냐가 아닐 가능성이 높다.
오히려 중요한 것은
회사의 Context를 얼마나 잘 축적하고, 그것을 AI가 실행 가능한 형태의 Loop로 만들 수 있는가
일 것이다.
AI 시대의 회사는 결국 하나의 거대한 소프트웨어가 아니라,
계속해서 관찰하고, 판단하고, 행동하고, 배우는 살아 있는 시스템에 가까워질지도 모른다.
원문 및 영상 출처
- 원문: jaytsol.tistory.com
- How to Build an AI-Native Services Company — Y Combinator
- How To Build A Company With AI From The Ground Up — Y Combinator
- Building And Structuring An AI Native Company — YC Root Access