소개

Andrej Karpathy는 OpenAI 공동 창업자이자 Tesla 자율주행(Autopilot)의 실질적 구현 책임자입니다. "vibe coding"이라는 용어를 만들어낸 장본인이기도 하며, 복잡한 기술 개념을 누구나 이해할 수 있게 설명하는 것으로 잘 알려져 있습니다.

전환점 — 뒤처진다는 느낌

2025년 12월, Karpathy는 프로그래머로서 처음으로 뒤처진다는 느낌을 받았다고 합니다. 설레임과 불안이 동시에 밀려오는 감정이었다고 이야기했습니다.

그 이전까지는 AI 코딩 에이전트 도구들이 코드 덩어리를 만들어주되 가끔 수정이 필요했습니다. 그런데 12월을 기점으로 최신 모델들이 코드를 그냥 잘 만들어내기 시작했고, 마지막으로 직접 수정한 게 언제인지 기억조차 안 날 정도가 되었다고 합니다. 시스템을 점점 더 신뢰하게 되면서 vibe coding으로 자연스럽게 이어졌다고 합니다.

이 시점부터 진정한 의미의 에이전트 중심의 일관된 작업 흐름(agentic coherent workflow) 이 실제로 작동하기 시작했다고 봅니다.

Software 3.0 패러다임

Karpathy는 소프트웨어 발전을 세 단계로 나눠서 설명합니다.

단계 정의
Software 1.0 명시적 코드 작성
Software 2.0 데이터셋 + 신경망 훈련. 프로그래밍 = 데이터셋 배열 + 목적 함수 + 신경망 구조 설계
Software 3.0 프롬프팅. 컨텍스트 윈도우가 LLM이라는 인터프리터를 제어하는 레버

GPT나 LLM을 인터넷 전체로 훈련하면 암묵적으로 모든 태스크를 동시에 학습하게 됩니다. 그렇게 해서 어떤 의미에서 프로그래밍 가능한 컴퓨터가 되는 것입니다. Software 3.0에서 프로그래밍 패러다임은 "에이전트에게 복사-붙여넣기 할 텍스트는 무엇인가?"로 바뀝니다.

OpenClaw 설치 예시

OpenClaw 설치를 구현한다고 가정해 보겠습니다. 전통적인 Software 1.0 방식은 셸 스크립트를 작성하는 것입니다. 그런데 다양한 플랫폼과 컴퓨터를 지원하다 보면 셸 스크립트가 엄청나게 복잡해집니다.

Software 3.0 방식의 실제 OpenClaw 설치는 에이전트에게 복사-붙여넣기 할 텍스트 덩어리 하나입니다. 에이전트가 해당 텍스트를 받아서:

  • 스스로 지능을 패키징해 지시를 따르고
  • 현재 환경과 컴퓨터를 보고 지능적으로 행동하며
  • 루프 안에서 스스로 디버깅합니다

모든 세부 사항을 정확하게 명시할 필요가 없습니다. 훨씬 더 강력한 패러다임입니다.

Menu Genen 예시

레스토랑 메뉴에 사진이 없어서 음식을 모르는 경우가 많습니다. 이를 위해 Karpathy는 메뉴 사진을 업로드하면 OCR로 항목을 읽고 이미지 생성기로 음식 사진을 생성해 보여주는 앱을 Vercel에 배포했습니다.

그런데 Software 3.0 버전은 단순히 Gemini에게 사진을 주고 "NanoBanana를 사용해서 메뉴 위에 항목들을 오버레이해"라고 말하면 끝입니다. NanoBanana는 원본 메뉴 사진과 동일한 이미지를 반환하되 픽셀 안에 각 항목을 실제로 렌더링해 넣습니다. Menu Genen 앱 전체가 불필요해진 것입니다.

Software 3.0 패러다임은 훨씬 더 원시적입니다. 신경망이 점점 더 많은 일을 하고, 프롬프트/컨텍스트는 그냥 이미지이고, 출력도 이미지입니다. 중간에 앱이 필요 없습니다.

새로운 가능성 — LLM 지식 베이스

이전 코드는 구조화된 데이터만 다뤘습니다. 그런데 이제는 조직이나 개인을 위한 위키를 LLM이 만들어주는 것이 가능해졌습니다. 코드로 사실들에 기반한 지식 베이스를 만드는 건 이전에는 불가능했습니다. 이제는 문서들을 가져와서 다른 방식으로 재컴파일하고, 재배치하고, 새로운 관점으로 재구성할 수 있습니다.

기존 것을 더 빠르게 하는 것뿐만 아니라, 이전에는 불가능했던 새로운 기회들이 더 흥미롭습니다.

미래 방향 — 계산기 경로와 신경망 경로

컴퓨팅 초기(50~60년대)에는 컴퓨터가 계산기처럼 될지 신경망처럼 될지 불분명했습니다. 결국 계산기 경로로 갔고, 지금 신경망은 기존 컴퓨터 위에서 가상화되어 실행되고 있습니다.

앞으로는 이 구조가 뒤집힐 수 있습니다. 신경망이 호스트 프로세스(host process)가 되고, CPU가 보조 프로세서(coprocessor)가 되는 구조입니다. 도구 사용(tool use)은 결정적 작업을 위한 역사적 부속물처럼 되고, 신경망이 대부분의 무거운 일을 하는 세계가 되는 것입니다. 그 진행 과정은 아직 미정입니다.

2026년 사후 관점 — 아직 구축되지 않은 것들

인터뷰에서 흥미로운 질문이 던져졌습니다. 90년대 웹사이트 만들기, 2010년대 모바일 앱 만들기, 클라우드 시대 SaaS 만들기처럼, 2026년에 사후 관점(hindsight)으로 보면 완전히 당연해 보일, 하지만 아직 대부분 구축되지 않은 것은 무엇인가?

Karpathy의 답은 이렇습니다. Menu 예시로 돌아가면, 많은 코드가 존재할 필요가 없고 신경망이 대부분의 일을 하는 구조가 될 것입니다. 완전한 신경 컴퓨터(neural computer), 즉 원시(raw) 비디오나 오디오를 입력으로 받아서 그 순간에만 존재하는 독특한 UI를 확산 모델(diffusion)로 렌더링하는 장치를 상상할 수 있다고 합니다.

핵심은 "기존 것을 빠르게 만드는 것"이 아니라, 새로운 패러다임에서 비로소 가능해진 것들을 재구성해서 찾는 것입니다.

검증 가능성

이 인터뷰에서 가장 중요한 개념 중 하나입니다.

핵심 명제: LLM은 검증 가능한(verifiable) 영역을 쉽게 자동화합니다.

자동화 조건
전통적 컴퓨터 코드로 명시할 수 있는 것
LLM 검증 가능한(verifiable) 것

LLM이 수학, 코드 같은 영역에서 능력이 높은 이유는 강화학습(RL) 훈련 시 검증 보상을 주었기 때문입니다. 프론티어 연구소들의 훈련이 거대한 강화학습 환경이기 때문에, 검증 가능한 영역에서는 능력이 높지만 그렇지 않은 영역에서는 들쭉날쭉합니다(jagged).

들쭉날쭉함의 구체적 사례

Strawberry 예시(구버전): "strawberry에 몇 글자가 있냐?"라는 질문에 모델들이 오답을 내었던 유명한 일화입니다. 현재는 수정되었습니다.

세차장 예시(최신): "세차장이 50미터 거리에 있는데 운전할까 걸을까?"라는 질문에 최신 모델들은 "너무 가깝다, 걸어가라"고 답합니다. Opus 4.7이 10만 줄 코드베이스를 리팩토링하거나 제로데이 취약점을 찾을 수 있는데, 상식적인 판단을 못 하는 것이 들쭉날쭉함(jagged)의 핵심입니다.

들쭉날쭉함의 원인

검증 가능성(verifiability) × 연구소가 해당 영역에 투자한 정도의 조합입니다.

체스 사례: GPT-3.5에서 GPT-4로 넘어가면서 체스 능력이 급상승했는데, 많은 사람들이 자연스러운 진화라 생각했지만 실제로는 사전 훈련(pre-training) 데이터셋에 체스 데이터가 대량 추가되었기 때문입니다. 우리는 연구소들이 데이터에 무엇을 넣는지에 어느 정도 종속되어 있다는 점을 인식해야 합니다.

결론적으로, 강화학습(RL) 회로 안에 있으면 날아다니고 데이터 분포 밖에 있으면 고생합니다. 그래서 루프 안에 인간이 있어야 하고, 도구로 다루며 계속 접촉해야 합니다.

창업자를 위한 조언

수학, 코딩 같은 가장 명확한 검증 가능 영역에서는 연구소들이 이미 탈출 속도(escape velocity)에 도달한 것 같습니다. 그 외의 영역에서 창업자가 취할 수 있는 접근 방식은 다음과 같습니다.

검증 가능성을 직접 만드는 것: 검증 가능한 환경을 직접 설계해서 강화학습(RL) 예시를 생성하면, 자체 미세 조정(fine-tuning)으로 이득을 볼 수 있습니다. 연구소가 직접 집중하지 않더라도 검증 가능한 환경이 있으면 스스로 미세 조정 프레임워크로 레버를 당겨서 꽤 좋은 결과를 얻을 수 있습니다.

결국 거의 모든 것이 자동화 가능합니다: 어떤 것은 쉽고 어떤 것은 어렵지만, 글쓰기 같은 것도 LLM 심사위원단을 만들어 합리적인 검증 결과를 얻을 수 있습니다. 결국 모든 것이 어느 정도 검증 가능해지고, 모든 것이 자동화될 수 있다는 것이 Karpathy의 견해입니다.

바이브 코딩 vs 에이전트 기반 엔지니어링

바이브 코딩(Vibe Coding) 에이전트 기반 엔지니어링(Agentic Engineering)
대상 누구나 전문 개발자
목표 소프트웨어 진입 장벽(바닥) 높이기 전문 소프트웨어의 품질 기준 유지
특징 빠르게 무언가 만들기 속도 + 품질 + 보안 동시 달성
비유 바닥을 높이는 것 천장을 높이는 것

에이전트 기반 엔지니어링(agentic engineering)은 일종의 엔지니어링 규율입니다. 에이전트들은 뾰족하고(spiky) 확률적이지만(stochastic) 매우 강력합니다. 이들을 조율해서 속도를 높이면서 품질 기준을 유지하는 것이 핵심입니다.

과거 “10x 엔지니어” 개념이 있었는데, 에이전트 기반 엔지니어링 능력의 천장은 그보다 훨씬 더 큰 배율이 된다고 합니다.

AI 원주민이란 무엇인가

Sam Altman이 세대별 ChatGPT 사용 방식 차이를 언급한 적이 있습니다. 30대는 구글 검색 대체로, 10대는 인터넷 입문으로 사용한다는 것입니다. 코딩 도구에서도 유사한 스펙트럼이 존재합니다.

평범한 사용자와 AI 원주민(AI native)의 차이는 도구가 제공하는 모든 기능을 최대한 활용하고, 자신의 설정에 투자하는 것입니다. 과거에 vim이든 VS Code든 도구를 가장 잘 쓰는 엔지니어가 좋은 엔지니어였듯이, 지금은 Claude Code나 다른 에이전트 도구들을 최대한 활용하고 설정에 투자하는 모습이 AI 원주민처럼 보입니다.

채용 방식의 변화

강력한 에이전트 기반 엔지니어를 채용하려면 기존 알고리즘 퍼즐 방식이 아니라, 큰 프로젝트(예: Twitter 클론)를 주고 다음과 같이 평가해야 한다고 합니다.

  1. 잘 만들고 보안도 좋게 만들게 한다
  2. 에이전트들로 활동을 시뮬레이션한다
  3. 10개의 최신 모델로 공격하게 해서 뚫리지 않게 한다

인간의 역할 — 심미안과 판단력

현재 에이전트는 인턴 수준입니다. 여전히 인간이 해야 하는 것들이 있습니다.

미학적 감각(aesthetics)과 심미안(taste): 코드가 군더더기가 많고(bloated) 복붙이 난무하고 깨지기 쉬운(fragile) 추상화로 가득한 경우 인간이 잡아야 합니다. Micro GPT 프로젝트에서 LLM에게 최대한 단순하게 만들라고 해도 못 합니다. 강화학습(RL) 회로 밖에 있는 느낌이라고 합니다.

판단력(judgment): 무엇을 만들고 왜 가치가 있는지 판단하는 것입니다. 에이전트와 함께 매우 상세한 스펙(문서 같은 것)을 만들고, 에이전트가 코드를 작성하게 하되, 최상위 카테고리와 감독은 인간이 담당해야 합니다.

기본 개념 이해: PyTorch API 세부사항(keep_dims vs keep_dim, axis vs dim 같은 것)은 에이전트(인턴)가 잘 기억하니 잊어도 됩니다. 하지만 텐서의 기반 뷰(underlying view)와 저장 구조(storage) 같은 기본 개념은 여전히 알아야 불필요한 메모리 복사를 방지할 수 있습니다.

구체적 실패 사례

Menu Genen에서 Google 계정으로 가입하고 Stripe로 결제하는 상황을 생각해 보겠습니다. 둘 다 이메일 주소를 갖고 있습니다. 에이전트가 Stripe 이메일로 Google 이메일에 크레딧을 연결하려 했는데, 영구 사용자 식별자(persistent user ID)가 없어서 이메일로 매칭하려다 실패했습니다. 이런 종류의 실수를 아직 합니다.

심미안의 미래

현재 강화학습(RL)에 미학적 비용이나 보상이 없기 때문에 모델이 못 하는 것일 가능성이 크다고 합니다. 근본적으로 막는 것은 없고 연구소가 아직 하지 않은 것뿐입니다. 미래 모델에서 개선되길 기대한다고 했습니다.

들쭉날쭉한 지능 — 유령을 소환하다

Karpathy가 쓴 “동물 vs 유령(animals vs ghosts)” 글의 핵심은 이렇습니다. 우리는 동물 지능을 만드는 게 아니라 유령을 소환하고 있다는 것입니다.

  • 진화에서 나온 내재적 동기(재미, 호기심, 자기 효능감(empowerment))가 없습니다
  • 데이터와 보상 함수(reward function)에 의해 형성된 들쭉날쭉한 지능(jagged intelligence)입니다
  • 통계적 시뮬레이션 회로로, 사전 훈련(pre-training)은 통계이고 그 위에 강화학습(RL)이 붙은 것입니다

이 글을 쓴 이유는 LLM이 무엇인지 머릿속에서 정리하기 위해서라고 합니다. 그것을 잘 이해하면 더 잘 사용할 수 있기 때문입니다.

실용적 의미: 소리를 지른다고 더 잘하지 않습니다. 무엇이 작동할지 의심스럽게 보는 태도가 필요합니다. 명확한 5가지 방법 같은 건 없고, 시간이 지나면서 알아가는 과정입니다.

에이전트 친화적 세상

현재 가장 불편한 부분은 모든 것이 아직 인간을 위해 작성되어 있다는 점입니다.

프레임워크나 라이브러리 문서가 여전히 인간을 대상으로 쓰여 있습니다. “이걸 하세요” 대신 **“에이전트에게 복사-붙여넣기 할 것은 무엇인가?”**를 알려줘야 합니다.

에이전트 친화적 전환 방향

  • 작업 부하를 감지기와 구동기(sensors and actuators)로 분해합니다
  • LLM이 읽기 쉬운 데이터 구조를 자동화합니다
  • 에이전트에게 먼저 설명하고 LLM이 읽기 쉬운 구조로 만들어야 합니다

인프라가 에이전트 친화적인지 테스트하는 방법

Menu Genen 블로그를 작성할 때, 코드 작성보다 Vercel에 배포하는 것이 더 힘들었다고 합니다. 여러 서비스를 연결하고, 설정으로 들어가고, DNS를 설정하는 과정이 번거로웠습니다.

"Menu Genen을 만들어"라는 프롬프트 하나로 아무것도 건드리지 않고 인터넷에 배포까지 되는 세상이 바로 인프라가 에이전트 친화적(agent native)이 된 상태입니다. 이것이 좋은 테스트 기준이 된다고 합니다.

최종 비전

사람과 조직을 위한 에이전트 대리인(agent representation) 이 생기고, 내 에이전트가 상대방 에이전트와 만나 세부 사항을 조율하는 세상이 올 것이라고 합니다.

교육과 이해

인터뷰의 마지막 주제는 교육이었습니다.

“너는 생각은 아웃소싱할 수 있지만, 이해는 아웃소싱할 수 없다.”

인간은 여전히 시스템의 일부입니다. 정보가 뇌로 들어와야 합니다. 무엇을 만들고 있는지, 왜 가치가 있는지, 에이전트를 어떻게 지휘할지 판단하는 병목이 인간입니다. 이해(understanding)가 생각과 처리를 지휘하는 데 필수적입니다.

LLM 지식 베이스 활용

기사를 읽을 때마다 위키를 만들고 질문을 하는 것이 합성 데이터 생성(synthetic data generation) 역할을 한다고 합니다. 정보의 다른 투영(projection)을 볼 때마다 이해가 깊어집니다. 이런 도구들이 이해를 강화하는 데 도움이 됩니다.

LLM이 이해를 잘 못하기 때문에 인간이 지휘자(director) 역할을 해야 합니다.

열린 질문: 몇 년 후에 인간이 완전히 루프 밖으로 자동화될지, 이해까지 맡기게 될지는 지켜봐야 한다는 말로 인터뷰를 마무리했습니다.