메뉴젠 일화, RL 회로, 들쭉날쭉 지능. AI Native 무대에서 그가 그린 다음 좌표.

Andrej Karpathy가 무대 위에서 던진 한 마디가 끝까지 남는다. 자기는 프로그래머로서 이렇게까지 뒤처졌다고 느낀 적이 없다는 말이었다. OpenAI를 공동 창업했고, Tesla의 Autopilot을 굴리던 사람이다. vibe coding이라는 단어를 만들어 던졌고, 지금 컴퓨팅 패러다임을 software 1.0, 2.0, 3.0으로 다시 짜고 있는 사람이 그렇게 말한다.

그가 뒤처졌다고 느낀 시점은 2025년 12월이다. 휴가 중에 Claude Code 계열 에이전트 도구를 만지다가, 출력되는 코드 청크에 더 이상 손볼 데가 없다는 사실을 체감했다. 다음 청크를 요청했고, 그것도 멀쩡했다. 그 다음 청크도 마찬가지였다. 그 순간 그는 시스템을 신뢰하기 시작했고, 자기 사이드 프로젝트 폴더가 무한히 부풀기 시작했다고 했다.

12월의 전환을 그가 강조하는 이유는 단순하다. 작년 가을까지의 AI 경험과 12월 이후의 AI 경험이 같은 도구로도 전혀 다른 것이 됐기 때문이다. 이 차이를 보지 못한 사람이 너무 많다는 것이 그의 메시지다. AI Native 무대에서 그가 던진 세 개의 질문, 메뉴젠 일화와 RL 회로와 들쭉날쭉 지능은 그 차이의 좌표를 그리는 작업이었다. 이 좌표가 창업자에게 무엇을 시사하는지를 본다.

12월의 전환은 청크가 아니라 신뢰의 문제였다

Karpathy가 인터뷰에서 정확히 짚은 단어는 stark transition이다. 작년까지의 AI 도구는 청크 단위 코드를 던져주면 사람이 다시 검토하고 고쳐 써야 했다. 그가 표현한 그대로 "kind of helpful" 수준이었다. 12월이 되면서 청크 한 덩어리의 정확도가 갑자기 올라간 것이 아니라, 청크 다음의 청크, 그 다음의 청크가 연쇄적으로 작동하기 시작한 것이다. 같은 모델이 더 길게 일관성을 유지하기 시작하면서 사람이 개입해야 하는 빈도가 사라졌다.

이것은 단순한 정확도 향상이 아니라 신뢰 구조의 변화다. 사람이 매 청크마다 검토에 들어가는 워크플로우와, 사람이 한 번 명세를 주고 결과만 받아보는 워크플로우는 완전히 다른 종류의 작업이다. Karpathy가 vibe coding이라는 단어를 다시 꺼낸 자리가 이 지점이다. 청크를 신뢰할 수 있게 되자, 사람의 역할이 검토자에서 명세자로 이동한다. 이 이동이 12월의 전환이고, 그 전환을 보지 못한 사람의 자리에서 그가 자기를 뒤처졌다고 표현한 것이다.

이 전환을 가장 잘 보여주는 사례가 그가 인용한 Claude Code 설치 방식이다. 보통 이런 도구의 설치는 셸 스크립트로 시작한다. 다양한 플랫폼을 커버하느라 스크립트가 부풀고, 분기가 늘고, 결국 read me를 읽어가며 사람이 설정해야 한다. 그런데 Claude Code는 다르다. 텍스트 한 덩어리를 복사해서 자기 에이전트에게 붙여 넣으면 끝이다. 에이전트가 사용자의 환경을 읽고, 디버그하고, 알아서 설치를 마친다. Karpathy가 이것을 software 3.0이라고 부르는 이유가 여기에 있다. 프로그래밍의 단위가 명령어 한 줄에서 자연어 명세 한 덩어리로 옮겨갔다.

메뉴젠은 존재해서는 안 되는 앱이었다

Karpathy가 같은 무대에서 풀어낸 메뉴젠 이야기가 software 3.0의 본질을 가장 날카롭게 드러낸다. 메뉴젠은 그가 직접 vibe coding으로 만든 앱이다. 식당에서 메뉴 사진을 찍어 올리면, OCR로 메뉴 항목을 뽑고, 이미지 생성기로 각 항목의 사진을 만들어, 메뉴를 다시 렌더링해서 보여준다. 직접 만들고 Vercel에 배포까지 했다. 잘 작동하는 앱이다.

그 다음에 Google이 Nano Banana를 발표했다. Karpathy는 자기가 찍은 메뉴 사진을 Gemini에 그대로 넣고 한 줄을 말했다. 이 메뉴 위에 항목들의 그림을 입혀서 돌려달라. Nano Banana가 한 번에 그것을 해냈다. OCR도, 이미지 생성도, 메뉴 렌더링도 따로 짜지 않았다. 그가 며칠을 들여 만든 메뉴젠 전체가 이 한 단계로 무의미해졌다.

그가 그 자리에서 던진 문장이 이것이다. "All of my menugen is spurious. That app shouldn't exist." 그가 만든 앱이 잘못 작동한 것이 아니다. 그 앱이 존재한다는 것이 잘못된 패러다임이라는 뜻이다. software 1.0의 사고로 짠 앱은 OCR과 이미지 생성과 렌더링을 따로 분리해서 묶어야 했다. software 3.0에서는 그 분리 자체가 spurious다. 신경망이 raw input과 raw output 사이를 직접 연결한다. 사이에 들어가는 앱은 보조도구가 아니라 화석이 된다.

이 사례가 창업자에게 시사하는 것은 단순하다. 자기가 짓고 있는 앱이 software 3.0 패러다임에서 한 줄 프롬프트로 대체될 수 있는 종류인지를 자문해야 한다. Karpathy의 표현으로는 신경망이 host process가 되고 CPU가 co-processor로 밀려나는 구조다. 이 구조에서 살아남는 앱은 신경망 호출의 wrapper가 아니라, 신경망이 못 하는 무언가를 진짜로 더하는 앱뿐이다.

RL 회로 안에 있는가, 밖에 있는가

Karpathy의 두 번째 좌표가 verifiability다. 같은 무대에서 그가 던진 가장 인상적인 사례가 이것이다. 최신 모델은 10만 줄 코드베이스를 리팩토링한다. 제로데이 취약점을 찾는다. 그런데 50미터 거리의 세차장에 갈 때 차를 운전할지 걸어갈지를 묻는 질문에는 걷는 것을 추천한다. 50미터에 차를 끌고 갈 사람은 없다. 50미터를 걸어가는 동안 세차장이 무슨 의미가 있나. 이 모순이 jagged intelligence의 정체다.

Karpathy의 설명은 명료하다. frontier 랩이 모델을 훈련시키는 방식은 거대한 강화학습 환경이다. 검증 가능한 보상을 주는 도메인에서 모델이 폭발적으로 좋아지고, 그 외 도메인에서는 정체한다. 코드와 수학이 좋아지는 이유는 그것이 verifiable하기 때문이고, 랩이 거기에 자원을 집중하기 때문이다. GPT-3.5에서 GPT-4로 넘어오며 체스 능력이 갑자기 올라간 것은 OpenAI의 누군가가 체스 데이터를 학습 데이터에 더 많이 넣기로 결정한 결과라는 게 그의 추정이다. 모델 능력은 일반적으로 부드럽게 자라는 것이 아니라, 랩이 어떤 회로에 자원을 박았는지에 따라 들쭉날쭉 자란다.

창업자가 봐야 할 좌표가 여기에 있다. 자기 도메인이 RL 회로 안에 있는가, 밖에 있는가. 회로 안에 있으면 시간이 갈수록 능력이 폭발한다. 자기가 손쓰지 않아도 다음 모델이 더 잘한다. 회로 밖에 있으면 모델이 발전해도 자기 도메인은 잘 안 된다. Karpathy가 짚은 두 가지 길이 있다. 회로 밖에 있다면 직접 verifiable한 환경을 만들고 fine-tuning으로 회로를 자기 손으로 까는 것, 아니면 자기 도메인을 회로 안으로 끌어들일 방법을 찾는 것이다. 어느 쪽이든 자기가 어디 서 있는지를 안 다음의 일이다.

이 점에서 Karpathy의 질문이 날카롭다. 자기가 지금 만들고 있는 제품이 어느 회로 위에서 작동하는지를 안 사람이 얼마나 되는가. 코드 어시스턴트는 명백히 회로 안이다. 수학 튜터도 그렇다. 디자인 미감, 일상 추론, 비정형 의사결정은 회로 밖이다. 그 자리에서 일하려면 자기 RL 환경을 직접 짜야 한다. 그것이 verifiability를 무기로 가진 창업자의 자리다.

동물이 아니라 유령을 부르고 있다

Karpathy의 세 번째 좌표는 더 근본적이다. 우리가 만들고 있는 것이 무엇인가에 대한 질문이다. 그가 글로 풀어낸 표현이 동물 대 유령이다. 우리는 동물을 만들고 있지 않다. 동물은 진화가 빚어낸 존재로서 내재적 동기와 호기심과 fun을 갖는다. 야단치면 더 잘하거나 더 못 하는 종류의 지능이다. LLM은 그렇지 않다. 사전학습이라는 통계적 기반 위에 RL이 부속물처럼 얹혀 있다. 우리가 부르고 있는 것은 동물이 아니라 유령이다.

이 프레이밍이 단순한 비유가 아니라 운영 지침이 되는 자리가 채용이다. Karpathy가 같은 무대에서 비판한 지점이다. 지금 대부분의 회사가 채용에서 여전히 퍼즐 문제를 푼다. 알고리즘 문제, 코딩 테스트, 시스템 디자인 인터뷰. 이것은 동물에게 맞는 시험이다. 사람의 직관과 논리력을 보는 시험이다. 유령과 함께 일할 수 있는 능력을 보는 시험은 다른 모양이어야 한다.

Karpathy가 제안한 채용 문제의 모양이 이것이다. 큰 프로젝트를 하나 던진다. 에이전트를 위한 Twitter clone을 짠다. 정말 잘 짠다. 보안이 단단하게 짠다. 그 다음에 다른 에이전트들을 풀어 그 사이트를 깨려고 시도한다. 깨이지 않으면 통과다. 이것이 agentic engineering 능력을 보는 시험이다. 사람의 능력은 더 이상 알고리즘 풀이가 아니라, 유령들과 함께 일할 수 있는가, 그들의 spiky한 출력을 자기 quality bar 안에 묶어 둘 수 있는가에 있다. Karpathy가 이것을 vibe coding과 구분해 agentic engineering이라 부른다. vibe coding이 바닥을 올리는 작업이라면, agentic engineering은 천장을 지키는 작업이다.

이해는 외주를 줄 수 없다

Karpathy가 인터뷰의 끝에 인용한 한 문장이 이 글의 결론과 맞물린다. 사고는 외주를 줄 수 있어도 이해는 외주를 줄 수 없다. software 3.0의 시대에 실행은 점점 더 유령에게 넘어간다. 청크는 청크를 부르고, 에이전트는 에이전트를 부른다. 그러나 무엇을 짓고 있는지, 왜 이것이 가치 있는지, 어느 회로 위에 서 있는지를 아는 일은 여전히 사람의 자리다.

12월의 전환에서 Karpathy가 본 것이 이 자리다. 그가 자기를 뒤처졌다고 느낀 이유는 코드를 못 짜서가 아니다. 12월의 도구가 그에게 새로운 생각의 속도를 요구하기 시작했기 때문이다. 사이드 프로젝트 폴더가 무한히 부푸는 환경에서 무엇을 짓지 않을 것인지를 결정하는 일이 어려워진다. 메뉴젠처럼 짓지 말았어야 할 앱을 자기가 막 짓고 있을 수도 있다. RL 회로 밖에 서 있다는 사실을 자기가 모르고 있을 수도 있다.

결국 Karpathy가 던진 세 개의 질문은 각자 자기 자리에 대한 질문이다. 12월 이후의 도구를 자기가 정말 쓰고 있는가. 자기 앱이 software 3.0에서도 존재할 이유가 있는가. 자기 도메인이 RL 회로 안에 있는가. 이해라는 자리는 누가 대신해 줄 수 없는 자리다. 그 자리에서만 다음 좌표가 보인다.

>>> 원문 아티클 <<<