AI INDUSTRY INTELLIGENCE · SIGNAL & FLOW

카파시 Software 3.0: SaaS가 압축되고 Agent-Native 인프라가 남는다

핵심은 “AI가 코드를 빨리 써준다”가 아닙니다. Software 3.0은 코드보다 컨텍스트가, 화면보다 agent-native substrate가 더 중요해지는 전환입니다. 그래서 투자자는 AI 기능 출시 여부가 아니라 이 제품이 AI에게 먹히는 UI인지, AI가 반드시 써야 하는 운영 계층인지부터 구분해야 합니다.

이 글은 공개 X 영상과 Sequoia 대담에서 나온 Karpathy의 Software 3.0 논의를 장문으로 정리한 글입니다.

영상 길이: 약 17분 16초
화자: Andrej Karpathy
주제: AI agents, Software 3.0, vibe coding, agentic engineering, verifiability

핵심 한 줄

Karpathy의 요지는 이겁니다. LLM은 단순히 코딩을 빠르게 해주는 도구가 아니라, “프롬프트/컨텍스트로 프로그래밍하는 새 컴퓨터”이고, 앞으로 중요한 역량은 AI agent들을 활용해 품질을 유지하면서 훨씬 빠르게 일하는 agentic engineering이 될 것이다.

자세한 내용

1. 왜 “프로그래머로서 이렇게 뒤처진 적이 없다”고 했나

사회자가 Karpathy에게 묻습니다. 몇 달 전 Karpathy가 “프로그래머로서 이렇게 뒤처진 느낌을 받은 적이 없다”고 했는데, 그게 흥분되는 감정이었는지 불안한 감정이었는지 묻습니다.

Karpathy 답변:

둘 다였다.
지난 1년 정도 agentic coding 도구를 써왔는데, 예전에는 코드 조각을 꽤 잘 만들어주지만 자주 고쳐야 했다.
그런데 작년 12월쯤부터 체감이 달라졌다.
최신 모델들은 코드 chunk를 내면 그냥 맞는 경우가 많아졌고, 더 요청해도 계속 괜찮게 나왔다.
어느 순간 “내가 마지막으로 코드를 고친 게 언제였지?” 싶을 정도가 됐다.
그래서 다시 코딩에 빠졌고, side project 폴더가 엄청나게 많아졌다고 말합니다.

핵심은: AI 코딩이 “도움 되는 보조도구”에서 “신뢰하고 일을 맡길 수 있는 agentic workflow”로 넘어간 순간을 체감했다는 것입니다.

2. Software 1.0 / 2.0 / 3.0

Karpathy는 기존의 유명한 구분을 다시 설명합니다.

Software 1.0: 사람이 직접 코드를 쓴다.
Software 2.0: 데이터셋, 목적함수, 신경망 아키텍처를 설계해서 neural network를 훈련시킨다.
Software 3.0: LLM을 대상으로 프롬프트와 컨텍스트 윈도우를 구성하는 것이 프로그래밍이 된다.

그는 LLM을 일종의 “프로그래머블 컴퓨터”처럼 봅니다.

중요한 표현은:

context window가 새로운 프로그램이다.
LLM은 그 context를 해석하는 interpreter처럼 동작한다.
이제 프로그래밍은 단순히 코드를 쓰는 것이 아니라, LLM이 올바르게 행동하도록 텍스트·이미지·문서·지시를 구성하는 일이 된다.

3. OpenClaw 설치 예시 — bash script가 아니라 agent에게 줄 텍스트

Karpathy가 든 첫 번째 예시는 OpenClaw 설치입니다.

예전 방식:

설치를 위해 복잡한 bash script를 만든다.
다양한 OS, 환경, 의존성을 처리하려면 shell script가 점점 복잡해진다.
이건 Software 1.0 방식이다.

새 방식:

설치 방법을 하나의 텍스트 지시로 만든다.
사용자는 그 텍스트를 agent에게 붙여넣는다.
agent가 현재 컴퓨터 환경을 보고, 필요한 명령을 실행하고, 에러가 나면 디버깅한다.

Karpathy는 이걸 훨씬 강력한 방식으로 봅니다.

즉, 앞으로는:

“실행할 코드를 정확히 다 쓰는 것”보다

“agent에게 줄 좋은 instruction bundle을 만드는 것”이 더 중요한 프로그래밍 방식이 된다.

4. MenuGen 예시 — 앱 자체가 필요 없어지는 순간

두 번째 예시는 Karpathy가 만든 MenuGen이라는 사이드 프로젝트입니다.

문제:

식당 메뉴판에는 사진이 없다.
메뉴 이름만 보고는 음식이 뭔지 모를 때가 많다.
그래서 메뉴판 사진을 찍으면, 각 메뉴가 대략 어떤 음식인지 이미지로 보여주는 앱을 만들고 싶었다.

그가 만든 기존 앱 방식:

메뉴판 사진 업로드
OCR로 메뉴 이름 추출
이미지 생성 모델로 각 음식 이미지 생성
Vercel에서 앱으로 다시 렌더링
사용자가 메뉴 사진과 음식 이미지를 함께 봄

그런데 Software 3.0 방식은 훨씬 단순합니다.

메뉴판 사진을 Gemini에 넣고
“Nano Banana를 써서 메뉴판 위에 음식 이미지를 overlay해줘”라고 요청
모델이 바로 원본 메뉴판 이미지 위에 음식 이미지를 넣어줌

Karpathy는 여기서 충격을 받았다고 합니다.

왜냐하면 자신이 만든 MenuGen 앱 전체가 사실상 불필요해졌기 때문입니다.

핵심:

예전에는 앱, OCR, DB, UI, 이미지 생성 pipeline을 만들어야 했다.
이제는 원본 이미지 + 프롬프트 + 멀티모달 모델만으로 해결된다.
즉, 많은 “중간 소프트웨어”가 사라질 수 있다.

그는 이걸 두고:

AI는 기존 앱을 빠르게 만드는 정도가 아니라,

애초에 앱이 필요 없게 만드는 새로운 정보처리 방식이다.

라고 설명합니다.

5. “무엇이 아직 안 만들어졌나?” — neural computer의 가능성

사회자가 묻습니다. 웹사이트, 모바일 앱, SaaS 시대처럼 2026년에 당연해질 새로운 빌드 영역은 무엇인가?

Karpathy는 확답하기보다, 방향을 말합니다.

지금은 neural network가 기존 컴퓨터 위에서 가상화되어 돌아간다.
하지만 앞으로는 반대로 될 수 있다.
즉, neural net이 host process가 되고, CPU나 전통적 컴퓨터는 보조 프로세서처럼 쓰일 수 있다.
raw video, audio, image를 neural net에 넣으면 그 순간에 맞는 UI나 결과물을 diffusion처럼 렌더링하는 방식도 상상할 수 있다.

중요한 비유:

과거 1950~60년대에는 컴퓨터가 calculator처럼 갈지, neural net처럼 갈지 명확하지 않았다.
실제 역사는 calculator/classical computing 쪽으로 갔다.
하지만 이제 neural network가 점점 더 많은 정보처리의 중심이 될 수 있다.

즉, 미래의 컴퓨팅은:

deterministic code가 주인이고 AI가 보조인 구조에서

AI/neural net이 주인이고 code/tool이 보조인 구조로 바뀔 수 있다.

6. Verifiability — 검증 가능한 영역이 가장 빠르게 자동화된다

중반부 핵심 주제는 verifiability, 즉 “결과를 검증할 수 있는가”입니다.

Karpathy의 설명:

전통적 컴퓨터는 명시적으로 코드로 지정할 수 있는 것을 자동화했다.
최신 LLM은 검증할 수 있는 것을 더 쉽게 자동화한다.
frontier lab들은 거대한 RL 환경에서 모델을 훈련시킨다.
이때 reward를 주려면 결과가 맞는지 검증할 수 있어야 한다.
그래서 수학, 코드처럼 정답 검증이 쉬운 영역에서 모델 성능이 크게 올라간다.

하지만 이 때문에 모델 능력은 “jagged”해집니다.

즉:

어떤 영역에서는 말도 안 되게 뛰어나다.
어떤 단순한 상식 문제에서는 이상하게 틀린다.

7. Jagged intelligence — 10만 줄 코드는 고치면서, 세차장은 걸어가라고 한다

Karpathy가 든 예시가 재밌습니다.

예전엔 “strawberry에 r이 몇 개 있나” 같은 문제가 LLM의 약점 사례였습니다.

새로운 예시는:

“세차장에 차를 씻으러 가야 하는데, 50m 떨어져 있다. 차를 몰고 갈까, 걸어갈까?”

최신 모델도 “가까우니 걸어가라”고 답할 수 있다고 합니다.

그런데 같은 모델이:

10만 줄 코드베이스를 리팩터링하거나
zero-day 취약점을 찾거나
복잡한 코딩 작업을 수행할 수 있음

이 모순이 Karpathy가 말하는 jagged intelligence입니다.

핵심:

LLM은 일반 인간처럼 균일하게 똑똑한 게 아니다.
특정 훈련 분포와 검증 가능한 회로 안에서는 매우 강하다.
하지만 distribution 밖에서는 어이없는 실수를 한다.
그래서 인간이 loop 안에 있어야 하고, tool로 다뤄야 한다.

8. 왜 어떤 능력은 갑자기 좋아지고, 어떤 능력은 그대로인가

Karpathy는 모델 능력이 단순히 “전체적으로 조금씩 좋아지는 것”이 아니라고 말합니다.

예시:

GPT-3.5에서 GPT-4로 가면서 체스 능력이 크게 좋아졌다.
많은 사람은 “모델이 전반적으로 좋아져서 그렇다”고 생각했다.
하지만 실제로는 체스 데이터가 pretraining set에 많이 들어갔기 때문일 수 있다.
누군가 OpenAI에서 체스 데이터를 넣었고, 그 결과 체스 능력이 특정하게 튀어올랐다.

즉, 모델 능력은:

모델 크기
RL 환경
데이터 분포
lab이 무엇을 중요하게 넣었는지

에 크게 좌우됩니다.

그래서 사용자는 LLM을 “매뉴얼 없는 이상한 기계”처럼 탐색해야 합니다.

어떤 회로에서는 날아다닌다.
어떤 회로에서는 헤맨다.
내가 만들려는 앱이 어느 회로에 있는지 직접 실험해야 한다.
안 맞으면 fine-tuning이나 자체 RL 환경을 만들어야 한다.

9. 창업자에게 주는 조언

사회자가 묻습니다. 창업자가 지금 회사를 만들 때, 이미 big lab이 math, coding 같은 obvious한 영역을 빠르게 가져가고 있다면 어디를 봐야 하느냐?

Karpathy 답변:

검증 가능성이 높은 domain은 여전히 기회가 있다.
big lab이 직접 집중하지 않는 영역이라도, 그 domain에서 좋은 RL environment를 만들 수 있다면 유리하다.
다양한 데이터셋과 검증 가능한 환경이 있으면 fine-tuning framework를 써서 성능을 끌어올릴 수 있다.
그는 구체적 domain 하나가 떠오른다고 했지만, 무대에서 “답을 공개하고 싶진 않다”는 식으로 말을 아꼈습니다.

핵심은:

창업 기회는 “LLM이 잘하는 일반 영역”이 아니라,

특정 domain에서 검증 가능한 환경과 데이터를 만들 수 있는 곳에 있다.

10. 무엇이 자동화되기 어렵나?

사회자가 반대로 묻습니다. 멀리서 보면 자동화 가능해 보이지만 실제로는 어려운 영역은 무엇인가?

Karpathy는 꽤 강하게 말합니다.

궁극적으로는 거의 모든 것이 어느 정도 검증 가능해질 수 있다.
글쓰기 같은 주관적 작업도 LLM judge council 같은 방식으로 평가할 수 있다.
따라서 “자동화 가능/불가능”의 문제가 아니라, 검증을 만들기 쉬운가 어려운가의 문제다.
장기적으로는 거의 모든 것이 자동화될 수 있다고 봅니다.

11. Vibe coding vs Agentic engineering

마지막 주제는 vibe coding과 agentic engineering의 차이입니다.

Karpathy 설명:

Vibe coding

모든 사람의 software creation floor를 올린다.
비전문가도 앱이나 도구를 만들 수 있게 된다.
“대충 이런 느낌으로 만들어줘”가 가능한 세계다.
접근성, 창작 가능성, 개인 생산성이 크게 올라간다.

Agentic engineering

전문 소프트웨어의 quality bar를 유지하면서 AI agent로 더 빨리 만드는 discipline이다.
보안 취약점이나 품질 저하를 vibe coding 탓으로 허용하면 안 된다.
여전히 만든 사람은 소프트웨어에 책임을 져야 한다.
agent는 강력하지만 fallible하고 stochastic하다.
그래서 여러 agent를 어떻게 조율하고, 검증하고, 품질 기준을 유지할지가 핵심이다.

그는 agentic engineering을 일종의 새로운 공학 discipline으로 봅니다.

핵심 문장:

Vibe coding은 floor를 올린다.

Agentic engineering은 기존 professional software의 quality bar를 유지하면서 ceiling을 크게 올린다.

12. 10x engineer를 넘어서는 사람들

마지막에 Karpathy는 아주 강한 말을 합니다.

예전에는 “10x engineer”라는 표현을 썼지만, agentic engineering을 잘하는 사람은 그보다 훨씬 더 큰 배율의 생산성을 낼 수 있다고 봅니다.

즉:

AI가 단순히 20~30% 빠르게 해주는 도구가 아니다.
agentic workflow를 제대로 설계하는 사람은 생산성 차이가 훨씬 커진다.
10x는 더 이상 큰 숫자가 아닐 수 있다.

내 해석

이 영상의 핵심은 “코딩 자동화”보다 훨씬 큽니다.

Karpathy가 말하는 변화는 세 가지입니다.

프로그래밍의 단위가 코드에서 컨텍스트로 이동

좋은 함수 작성보다, agent가 잘 작동하도록 환경·문서·지시·검증 루프를 구성하는 일이 중요해짐.

앱의 중간층이 사라질 수 있음

MenuGen 예시처럼, 예전엔 앱으로 만들던 많은 workflow가 “원본 입력 + 모델 + 프롬프트”로 대체될 수 있음.

미래의 경쟁력은 agentic engineering

AI에게 일을 시키는 수준이 아니라,
여러 agent를 조율하고,
검증 루프를 만들고,
품질·보안·책임을 유지하면서,
훨씬 빠르게 결과물을 내는 역량이 핵심이 됨.

요약하면 이 영상은 “AI agent 시대의 개발자/창업자가 무엇을 새롭게 배워야 하는가”에 대한 Karpathy식 압축 강의에 가깝습니다.

투자 관점: Software 3.0이 SaaS에 던지는 질문

위 대담을 투자 언어로 바꾸면 핵심은 단순합니다. Software 3.0은 SaaS 생산성 도구가 아니라, 일부 SaaS에는 압축 압력이고 일부 인프라에는 재평가 계기입니다.

Software 3.0은 SaaS 생산성 도구가 아니라 SaaS 압축 압력이다. LLM이 새 interpreter가 되면 일부 CRUD, middleware, 얇은 workflow 앱은 “더 빨리 만드는 대상”이 아니라 raw input → model → output으로 우회되어 사라질 수 있습니다.
가치 포획은 UI가 아니라 agent-native substrate로 이동한다. 기업 데이터, 권한, 감사, 보안, 워크플로우 상태, 결제·정산, 실패 복구를 에이전트가 안전하게 다루게 하는 플랫폼은 더 중요해질 수 있습니다.
투자 질문은 ‘AI를 붙였는가’가 아니라 ‘AI에게 먹히는 화면인가, AI가 써야 하는 인프라인가’다. 기존 SaaS의 기능 수나 seat growth보다, agent가 API·권한·상태·검증을 통해 실제 업무를 끝낼 수 있게 하는지 봐야 합니다.
Verifiability ladder가 adoption 순서를 결정한다. code/math처럼 자동 검증 가능한 영역은 빠르게 commoditize되고, 결제·의료·법무·보안처럼 검증은 가능하지만 비용과 책임이 큰 영역은 통제·감사 인프라가 해자가 됩니다.
인간의 역할은 syntax에서 judgment로 이동한다. API 암기와 boilerplate는 에이전트가 가져가지만, spec, architecture, security, taste, user identity, reconciliation 같은 본질 이해가 없으면 에이전트는 그럴듯하지만 위험한 시스템을 만듭니다.

평안투식 Growth × Liquidity 적용

Growth+ 후보: agent-native 데이터·권한·감사·워크플로우 플랫폼, 검증 가능한 vertical workflow, 보안·관측성·테스트 자동화, enterprise agent runtime.
Growth- 후보: 얇은 UI, 단순 CRUD, 중간 파이프라인, 모델 호출 한 번으로 대체 가능한 feature SaaS.
Liquidity 민감도: agent-native 기대가 높아질수록 AI software multiple은 금리와 위험선호 변화에 더 민감합니다. 숫자 전환 전 narrative-only 상승은 경계해야 합니다.
Kill Switch: 사용량이 늘어도 gross margin, retention, workflow completion, auditability가 따라오지 않으면 token growth는 비용 서사로 반전됩니다.

투자자가 마지막으로 확인할 체크리스트

이 회사 제품은 AI가 직접 대체할 수 있는 화면인가, 아니면 AI가 실제 업무를 끝내기 위해 반드시 통과해야 하는 계층인가?
권한·감사·상태·보안·결제·복구를 붙잡고 있는가, 아니면 단순히 모델 호출 결과를 보기 좋게 보여주는가?
검증 루프가 제품 안에 있는가? 테스트, benchmark, workflow completion, policy compliance를 숫자로 확인할 수 있는가?
사용량 증가가 매출, retention, gross margin, usage expansion으로 이어지는가?
엔터프라이즈 에이전트가 파일럿을 넘어 production workflow에 들어가지 못한다면 thesis를 낮출 준비가 되어 있는가?

확인한 공개 자료

이 글은 공개 영상·대담·Karpathy의 공개 글을 바탕으로 정리한 투자 참고용 해석입니다. 단일 발언만으로 종목 결론을 확정하지 않고, 제품 채택·매출·마진·고객 유지율로 이어지는지 확인해야 합니다.

함께 읽을 글

English version →

이 글은 공개 자료와 평안투 프레임을 결합한 투자 참고용 해석이며, 특정 종목의 매수·매도 권유가 아닙니다.