카파시가 SA 2026에서 한 말 - 생각은 외주 할 수 있지만, 이해는 외주 할 수 없다.

2026년 4월 30일 Andrej Karpathy 가 Sequoia Ascent 2026 에서 fireside chat 을 했습니다. 본인이 직접 정리한 글이 블로그에 올라와서 (https://karpathy.bearblog.dev/sequoia-ascent-2026/) 내용 정리해봤습니다.

카파시가 누구인지 부터 잠깐 소개하고 갈게요: OpenAI 공동창업자, Tesla Autopilot 디렉터를 거쳐 지금은 Eureka Labs 에서 AI 교육 작업 중. 2025 년 "vibe coding" 이라는 용어를 만든 사람이기도 합니다.

이번 강연은 본인이 "never felt more behind as a programmer" 라고 말한 게 시작점이었어요. 카파시 같은 사람이 프로그래머로서 뒤처졌다 고 느꼈다는 게 무슨 의미인지가 핵심 주제.

1. 2026년 12월이 agentic 변곡점이었다

카파시 본인 발언:

"2025 년 한 해 동안 Claude Code, Codex 같은 에이전트 도구들은 유용했지만 자주 수정해야 했다. 12 월쯤 step change 가 왔다. 휴가 중이라 시간이 많았는데, 생성된 코드 덩어리가 그냥 잘 작동했다. 계속 요청해도 계속 잘 나왔다. 마지막으로 수정한 게 언제였는지 기억이 안 났다."

이게 "단순한 자동완성" → "실제로 작업을 위임할 수 있는 도구" 로의 전환점이었다는 진단. 카파시는 이 시점을 기준으로 프로그래밍의 단위가 코드 줄에서 macro action 으로 바뀌었다 고 봅니다:

• "이 기능 구현해줘"
• "이 서브시스템 리팩토링해줘"
• "이 라이브러리 조사해줘"
• "테스트 짜고 돌리고 실패하면 고쳐줘"

프로그래머가 코드 작성자 가 아니라 에이전트 오케스트레이터 로 재정의되고 있다는 얘기입니다.
아마 계속 에이전틱 코딩을 해오신 분이면 공감하실거라고 생각해요. 저도 올 3월부터 코드를 거의 안들여다보기 시작했거든요.

2. Software 3.0 - 컨텍스트 윈도우가 프로그램

카파시의 분류:

Software 3.0 에서는 컨텍스트 윈도우가 메인 레버 입니다. LLM 은 그 컨텍스트를 해석하는 인터프리터.

구체 예시 하나가, 복잡한 도구 설치할 때 옛날에는 OS 별 조건문이 잔뜩 들어간 shell script 가 필요했어요. Software 3.0 버전에서는 에이전트에 붙여넣는 텍스트 블록 하나면 됩니다. 에이전트가 로컬 환경 읽고, 에러 디버깅하고, 머신에 맞게 적응해서 설치 완료. 덜 정밀한 대신 더 적응적인 프로그램 형태. (이미 깃헙 레포 주소 복사하셔서 터미널에이전트에 복붙하고 이거 설치해줘 하시는 분 많으실거라 믿습니다? ㅎㅎ)

3. MenuGen - 앱 자체가 사라지는 사례

카파시가 만든 MenuGen 이라는 사이드 프로젝트가 좋은 예시. 식당 메뉴 사진을 찍으면 음식 이미지를 생성해주는 앱입니다. 전통적 구조:

• 프론트엔드 코드
• OCR API
• 이미지 생성 API
• 배포 / 인증 / 결제 / 시크릿 / 인프라

다 필요했어요. 그런데 Software 3.0 버전:

• 메뉴 사진을 Gemini 한테 넘김
• Nano Banana 로 메뉴 이미지 위에 음식 이미지를 직접 렌더링하라고 지시
• 끝

앱 전체가 사라짐. 신경망이 입력 미디어를 출력 미디어로 직접 변환합니다. 옛날 소프트웨어 스택은 모델이 이제 직접 할 수 있는 변환의 비계 (scaffolding) 였을 뿐.

카파시의 결론:

"AI 는 단순히 옛날 앱을 더 빠르게 만드는 방법이 아니다. 어떤 앱들은 앱으로 존재하기를 멈춰야 한다."

4. Verifiability - AI 가 어디서 가장 빨리 움직이는가

카파시의 핵심 자동화 프레임워크:

• 전통적 소프트웨어는 명시할 수 있는 것 을 자동화
• LLM 과 강화학습은 검증할 수 있는 것 을 자동화

자동 보상이나 성공 신호가 있는 작업이면 모델이 연습할 수 있어요. 그래서 수학, 코딩, 테스트, 벤치마크, 게임이 빠르게 개선되는 거. 모두 리셋 가능 / 반복 가능 / 보상 가능 한 영역입니다.

코딩 에이전트가 일반 챗봇보다 극적으로 좋아 보이는 이유도 이것. 코딩은 모델한테 피드백을 줍니다 - 테스트가 통과하거나 실패하거나, 프로그램이 돌거나 크래시하거나, diff 가 검사 가능하거나.

5. Jagged Intelligence - 두 축으로 갈라지는 능력

verifiability 만으로는 부족하다는 게 강연의 중요한 refinement. 모델 능력은 두 가지에 달려 있어요:

1. 작업이 검증 가능한가 (verifiability)
2. 랩이 그 작업에 training attention 을 쏟았는가

대략적 공식:

capability spike ≈ verifiability × training attention × data coverage × economic value

체스가 좋은 예시. GPT-4 가 체스를 잘하게 된 게 일반 지능이 매끄럽게 향상돼서 가 아니라 체스 데이터를 훈련 mix 에 많이 넣어서 일 가능성. 누군가 OpenAI 에서 그 데이터 추가를 결정했고, 그 결과 capability spike 가 나타난 거.

카파시 표현 그대로:

"State-of-the-art 모델이 10 만 줄 코드베이스를 리팩토링하고 zero-day 취약점을 찾을 수 있는데, 50m 떨어진 세차장에 걸어가라고 한다. 이게 jaggedness 다."

창업자 관점에서 중요한 질문은 "내 작업이 모델의 rails 위에 있는가". 검증 가능하고 많이 훈련된 영역에 있으면 모델이 날아갑니다. 아니면 의외로 기본적인 실패를 합니다.

6. Vibe Coding vs Agentic Engineering

카파시가 직접 만든 vibe coding 이라는 용어와 이번에 강조한 agentic engineering 의 구분:

vibe coding 은 프로토타입·개인 도구용으로 좋아요. agentic engineering 은 진지한 팀이 필요로 하는 것.

agentic engineer 는 생성된 코드를 무조건 받지 않습니다. 스펙을 설계하고, 계획을 감독하고, diff 를 검사하고, 테스트를 작성하고, 평가 루프를 만들고, 권한을 관리하고, worktree 를 분리하고, 품질을 유지합니다.

7. MenuGen 의 결제 버그 일화 - 인간 판단이 왜 필요한가

이게 강연에서 가장 구체적인 예시입니다. MenuGen 에서 결제 시스템 만들 때 에이전트가 Stripe 결제와 Google 로그인을 이메일 주소로 매칭 시키려고 했어요. 코드는 그럴듯하게 짜졌는데, 시스템 설계로는 틀린 거.

Stripe 이메일과 Google 로그인 이메일이 다를 수 있거든요. 사용자가 결제한 크레딧이 안 들어갈 수도 있는 상황. 정답은 persistent user ID 로 묶는 것. 이건 "코드가 작동하는가" 가 아니라 "시스템이 올바른가" 의 영역.

카파시 본인의 진단:

"프런티어 스킬은 모든 API 디테일을 외우는 게 아니다. 에이전트는 dim 인지 axis 인지, reshape 인지 permute 인지 잘 기억한다. 인간은 여전히 밑바닥 개념을 이해해야 한다 - 저장 공간, 뷰, 메모리 복사, 불변성, 정체성, 보안 경계, 시스템의 모양."

8. 채용도 바뀌어야 한다

agentic engineering 이 새 전문 스킬이라면 채용도 그걸 직접 테스트해야 한다는 주장. 전통적 코딩 퍼즐(우리 나라의 경우는 코테 정도 입니다) 은 점점 안 맞아요.

카파시가 제안한 면접:

"에이전트와 함께 큰 프로젝트를 구축해보세요. 배포해서 안전하게 만든 다음, 적대적 에이전트들이 그걸 깨려고 시도하게 합니다."

이 면접이 테스트하는 진짜 스킬:

• 작업을 에이전트용으로 분해할 수 있는가
• 유용한 스펙을 작성할 수 있는가
• 빠르게 움직이면서 품질을 유지할 수 있는가
• 생성된 작업을 리뷰할 수 있는가
• 시스템을 보안화·강화할 수 있는가
• 에이전트를 leverage 로 쓰는가, slop 을 만드는가

옛날 "10x 엔지니어" 개념이 훨씬 극단화될 수 있다는 얘기. agentic workflow 를 마스터한 사람은 다른 사람들보다 10x 보다 훨씬 더 잘할 수 있다는 진단입니다.

9. Agent-Native 인프라 - 사람이 아닌 에이전트를 위한 설계

대부분 소프트웨어가 여전히 사람이 화면 클릭하는 것 을 가정하고 만들어져 있어요. 문서는 "이 URL 로 가서 이 버튼 클릭하고 이 설정 패널 여세요" 라고 말합니다. 카파시 표현:

"내 가장 큰 pet peeve. 왜 사람들이 아직도 나한테 뭘 하라고 말하는가? 나는 아무것도 안 하고 싶다. 에이전트한테 복붙할 게 뭔지를 알려달라."

agent-native 인프라가 가져야 할 것들:

• Markdown 문서
• CLI
• API
• MCP 서버
• 구조화된 로그
• 머신 판독 가능한 스키마
• 복붙 가능한 에이전트 지침
• 안전한 권한 관리
• 감사 가능한 액션
• 헤드리스 설정 흐름

카파시는 이걸 sensors / actuators 개념으로 설명. sensor 는 세계 상태를 디지털 정보로 변환, actuator 는 에이전트가 무언가를 바꿀 수 있게 함. 미래 스택은 사람과 조직을 대신해서 sensor 와 actuator 를 쓰는 에이전트들.

10. Ghosts, Not Animals

카파시의 다른 글 Animals vs. Ghosts 의 framing 이 강연에도 등장합니다.

LLM 은 동물이 아닙니다. 생물학적 동기, 신체화된 생존 압박, 호기심, 놀이, 동물적 의미의 내재 동기가 없어요. 사전훈련 + 사후훈련 + RL + 제품 피드백 + 경제적 인센티브가 만들어낸 인간 산출물의 통계적 시뮬레이션.

이게 중요한 이유는 의인화 기대가 잘못 인도하기 때문. 이 시스템들은 한 순간 똑똑하다가 다음 순간 이상하게 멍청합니다. 매끄러운 인간 마음이 아니라 jagged 한 외계의 도구 들. 적절한 자세는 경험적 친숙함: 어디서 작동하고, 어디서 실패하고, 무엇을 위해 훈련됐고, 어떻게 가드레일을 칠 수 있는지 배우는 것.

11. 가장 핵심 - "생각은 외주, 이해는 외주 안 됨"

강연 마지막의 인용:

"You can outsource your thinking, but you can't outsource your understanding."

(카파시 본인이 트위터에서 본 누군가의 표현을 인용한 것이라고 합니다)

에이전트가 더 많은 일을 해도 인간은 여전히 이해 가 필요합니다. 뭐가 만들 가치가 있는지, 어떤 질문이 중요한지, 어떤 결과가 의심스러운지, 어떤 trade-off 가 받아들일 만한지 알아야 해요.

LLM 은 답변 기계 가 아니라 정보를 이해로 변환하는 도구 가 돼야 한다는 게 카파시의 비전. 본인이 만들고 있는 microGPT 프로젝트 (단일 파일 GPT 구현) 와 LLM 지식 베이스 작업(요건 약간 다른 방향으로 저도 secall이란걸 만들었고 많은 분들이 만들고 있어요)이 다 이 방향.

"인간 전문가는 정제된 산출물과 그 뒤의 taste 를 기여한다. 에이전트는 그걸 각 학습자에게 인터랙티브하게 설명할 수 있다."

큰 그림 - 무엇이 희소해지는가

카파시의 정리:

창업자한테 카파시가 던지는 질문들:

• 주된 사용자가 사람을 대신하는 에이전트 가 될 때 뭐가 가능해지는가
• 어떤 워크플로우가 sensor / actuator / verifiable loop 으로 재구축될 수 있는가
• 어떤 소프트웨어가 직접적 모델 변환으로 사라져야 하는가
• 어떤 도메인이 가치 있고 검증 가능한데 아직 프런티어 랩들이 많이 훈련 안 한 영역인가
• 품질을 보존하기 위해 인간 판단이 반드시 루프 안에 남아야 하는 부분은 어디인가

카파시 본인의 결론:

"내 현재 세계관은 AI 가 단순히 모두를 옛날 일에 더 빠르게 만드는 게 아니다. 일 자체가 에이전트 중심으로 재조직되고 있다는 것이다. 소프트웨어, 연구, 교육, 인프라, 지식 작업 모두 같은 패턴의 변주가 되고 있다 - 컨텍스트를 정의하고, 도구를 정의하고, 피드백 루프를 정의하고, 가드레일을 정의하고, 에이전트가 일하게 두고, 인간 이해를 보존한다."

정리

이 강연이 작년 vibe coding 강연의 1 년 후 후속편 같은 자료입니다. 작년에는 "누구나 소프트웨어를 만들 수 있게 됐다" 였다면 올해는 "이제 진지한 분야로 옮겨가야 한다" 정도. agentic engineering 이 새 전문 분야로 형성되고 있다는 진단.

가장 인상적인 부분은 "December 2025 가 변곡점" 같은 구체적 시점 명시. 카파시 같은 사람이 "이때부터 다르더라" 라고 말하는 건 마케팅 톤이 아니라 본인 사이드 프로젝트 폴더가 random things 로 가득 차게 된 자기 경험에서 나온 발언이라고 봐요.

다만 카파시 자신도 인정하듯 모델은 여전히 jagged 합니다. 코드베이스 10 만 줄 리팩토링하면서 동시에 50m 거리 세차장에 걸어가라고 합니다. 이 jaggedness 때문에 인간이 루프 안에 있어야 하는 영역이 여전히 명확합니다.

원문: https://karpathy.bearblog.dev/sequoia-ascent-2026/
강연 영상: https://www.youtube.com/watch?v=96jN2OCOfLs

출처

• Karpathy, "Sequoia Ascent 2026 summary", karpathy.bearblog.dev, 2026-04-30 (1차 자료, 본인 작성)
• 본 글의 모든 인용은 위 블로그 글에 명시된 카파시 본인 정리 + 본인이 손본 transcript 에서 추출
• 강연 영상: YouTube https://www.youtube.com/watch?v=96jN2OCOfLs
• 참조 글: Karpathy "Animals vs. Ghosts", "Verifiability" (둘 다 본인 블로그)