Andrej Karpathy의 2025년 LLM 연간 리뷰

(karpathy.bearblog.dev)

14P by GN⁺ 3일전 | ★ favorite | 댓글 2개

2025년은 검증 가능한 보상 기반 강화학습(RLVR) 이 LLM 훈련의 새로운 핵심 단계로 부상하며, 기존 사전훈련-SFT-RLHF 파이프라인에 추가됨
LLM이 수학·코드 퍼즐 등 검증 가능한 환경에서 스스로 추론 전략을 발전시키며, 인간이 보기에 "사고"처럼 보이는 문제 해결 방식을 습득함
Cursor가 LLM 앱의 새로운 레이어를 정의하며, 특정 버티컬에서 컨텍스트 엔지니어링과 복잡한 LLM 호출 오케스트레이션을 수행하는 방식 제시
Claude Code가 사용자의 로컬 컴퓨터에서 실행되는 LLM 에이전트의 첫 설득력 있는 사례로 등장하며, AI와의 새로운 상호작용 패러다임 제시
바이브 코딩(Vibe Coding) 이 비전문가도 영어만으로 프로그램을 만들 수 있게 하며, 소프트웨어 개발의 민주화와 직업 정의 변화 예고

1. 검증 가능한 보상 기반 강화학습(RLVR)의 부상

2025년 초까지 LLM 프로덕션 스택은 사전훈련(Pretraining), 지도 미세조정(SFT), 인간 피드백 강화학습(RLHF) 의 3단계 구조였음
RLVR(Reinforcement Learning from Verifiable Rewards) 이 새로운 주요 단계로 추가되어, 수학·코드 퍼즐 등 자동 검증 가능한 보상에 대해 LLM을 훈련시킴
LLM이 스스로 문제를 중간 계산 단계로 분해하고 다양한 문제 해결 전략을 개발하는 "추론"과 유사한 행동을 자발적으로 습득
- 이러한 전략은 최적의 추론 트레이스가 무엇인지 불명확하여 이전 패러다임에서는 달성하기 어려웠음
- LLM이 보상 최적화를 통해 자신에게 맞는 방식을 스스로 찾아야 함
SFT/RLHF와 달리 RLVR은 객관적이고 게이밍 불가능한 보상 함수에 대해 훨씬 긴 최적화가 가능
RLVR의 높은 비용 대비 성능(capability/$) 으로 인해 원래 사전훈련용 컴퓨팅 자원이 RLVR로 재배치됨
- 2025년 역량 진보의 대부분은 유사한 크기의 LLM에 더 긴 RL 실행을 적용하는 방식으로 정의됨
테스트 시점 컴퓨팅 조절이라는 새로운 노브(및 스케일링 법칙)가 등장하여, 더 긴 추론 트레이스 생성과 "사고 시간" 증가로 역량 조절 가능
OpenAI o1(2024년 말)이 첫 RLVR 모델 시연이었고, o3 출시(2025년 초) 가 직관적으로 차이를 느낄 수 있는 변곡점

2. 유령 vs. 동물 / 불균일한 지능(Jagged Intelligence)

2025년에 LLM 지능의 "형태" 를 더 직관적으로 이해하기 시작함
LLM은 "동물을 진화/성장시키는" 것이 아니라 "유령을 소환하는" 것
- 신경 아키텍처, 훈련 데이터, 훈련 알고리듬, 최적화 압력 모두 다르므로 지능 공간에서 매우 다른 존재가 생성됨
인간 신경망은 정글에서 종족의 생존을 위해 최적화되었지만, LLM 신경망은 인류의 텍스트 모방, 수학 퍼즐 보상 수집, LM Arena에서의 업보트 획득을 위해 최적화됨
검증 가능한 도메인에서 RLVR이 가능해지면서 LLM이 해당 영역에서 역량이 "스파이크" 되어 불균일한 성능 특성 을 보임
- 동시에 천재 박학다식자이면서 혼란스러운 초등학생처럼 행동하며, 몇 초 만에 탈옥에 속아 데이터 유출 가능
벤치마크에 대한 신뢰 상실과 무관심 발생
- 벤치마크는 거의 정의상 검증 가능한 환경이므로 RLVR과 합성 데이터 생성의 약한 형태에 즉시 취약
- 벤치마크맥싱(benchmaxxing) 과정에서 팀들이 벤치마크 임베딩 공간 인근에 환경을 구성하여 커버
- 테스트 셋 학습이 새로운 기술로 자리잡음
"모든 벤치마크를 통과하면서도 AGI에 도달하지 못하는" 상황은 어떤 모습일까?
관련글

3. Cursor / LLM 앱의 새로운 레이어

Cursor의 급격한 성장과 함께 "LLM 앱"의 새로운 레이어가 드러남
- "Cursor for X"라는 표현이 사용되기 시작
Cursor 같은 LLM 앱이 특정 버티컬을 위해 LLM 호출을 번들링하고 오케스트레이션함
1. 컨텍스트 엔지니어링 수행
2. 여러 LLM 호출을 점점 복잡한 DAG로 오케스트레이션하며 성능과 비용 균형 조절
3. 휴먼 인 더 루프를 위한 애플리케이션별 GUI 제공
4. "자율성 슬라이더" 제공
이 새로운 앱 레이어가 얼마나 "두꺼운지" 에 대한 논의 활발
- LLM 랩이 모든 애플리케이션을 점령할지, LLM 앱을 위한 기회가 있을지 논쟁
LLM 랩은 일반적으로 유능한 대학생을 배출하는 경향이 있지만, LLM 앱은 특정 버티컬에서 프라이빗 데이터, 센서, 액추에이터, 피드백 루프를 공급하여 이들을 조직하고 미세조정하며 실제 전문가로 활성화할 것으로 예상

4. Claude Code / 컴퓨터에 상주하는 AI

Claude Code(CC)가 LLM 에이전트의 첫 설득력 있는 시연으로 등장
- 도구 사용과 추론을 루프 방식으로 연결하여 확장된 문제 해결 수행
CC는 사용자의 컴퓨터에서 프라이빗 환경, 데이터, 컨텍스트와 함께 실행됨
OpenAI는 초기 Codex/에이전트 노력을 ChatGPT에서 오케스트레이션되는 클라우드 컨테이너 배포에 집중하여 방향을 잘못 잡음
- 단순히 localhost가 아닌 클라우드에 집중
에이전트 스웜이 클라우드에서 실행되는 것이 "AGI 엔드게임"처럼 느껴지지만, 현재는 불균일한 역량의 중간적이고 느린 도약 세계
- 에이전트를 개발자 컴퓨터에서 직접 실행하는 것이 더 합리적
중요한 구분은 "AI 작업"이 어디서 실행되느냐가 아니라, 이미 존재하고 부팅된 컴퓨터, 설치, 컨텍스트, 데이터, 시크릿, 구성, 저지연 상호작용에 관한 것
Anthropic이 이 우선순위를 정확히 파악하고 CC를 간결한 CLI 폼팩터로 패키징
- AI가 Google처럼 방문하는 웹사이트가 아니라 컴퓨터에 "상주하는" 작은 영혼/유령이라는 새로운 상호작용 패러다임

5. 바이브 코딩(Vibe Coding)

2025년은 AI가 영어만으로 다양한 인상적인 프로그램을 만들 수 있는 역량 임계값을 넘은 해
- 코드 존재 자체를 잊고 프로그래밍 가능
"vibe coding"이라는 용어를 트윗에서 코인했으나, 얼마나 널리 퍼질지 예상하지 못함
바이브 코딩으로 프로그래밍이 고도로 훈련된 전문가만의 영역이 아닌, 누구나 할 수 있는 것으로 변화
LLM이 다른 모든 기술과 달리 일반인이 전문가, 기업, 정부보다 훨씬 더 많은 혜택을 받는 사례
바이브 코딩은 일반인에게 프로그래밍 접근을 제공할 뿐 아니라, 훈련된 전문가가 그렇지 않으면 작성되지 않았을 (바이브 코딩된) 소프트웨어를 훨씬 더 많이 작성하도록 함
구체적 사례:
- nanochat에서 기존 라이브러리 채택이나 Rust 심층 학습 없이 Rust로 커스텀 고효율 BPE 토크나이저를 바이브 코딩
- menugen, llm-council, reader3, HN time capsule 등 존재했으면 하는 것들을 빠른 앱 데모로 바이브 코딩
- 단일 버그를 찾기 위해 일회성 앱 전체를 바이브 코딩 - 코드가 갑자기 무료, 일시적, 유연, 일회용
바이브 코딩이 소프트웨어를 테라포밍하고 직업 정의를 바꿀 것

6. Nano Banana / LLM GUI

Google Gemini Nano Banana가 2025년의 가장 놀라운 패러다임 전환 모델 중 하나
LLM이 1970~80년대 컴퓨터와 유사한 다음 주요 컴퓨팅 패러다임이라는 세계관에서, 유사한 종류의 혁신이 근본적으로 유사한 이유로 발생할 것
- 퍼스널 컴퓨팅, 마이크로컨트롤러(인지 코어), 인터넷(에이전트의) 등의 등가물이 등장할 것
UIUX 측면에서 LLM과 "채팅" 하는 것은 1980년대 컴퓨터 콘솔에 명령을 내리는 것과 유사
텍스트는 컴퓨터(및 LLM)에게 선호되는 원시 데이터 표현이지만, 사람에게는 선호되는 형식이 아님
- 특히 입력 측면에서 사람들은 텍스트 읽기를 싫어함 - 느리고 노력이 필요
사람들은 정보를 시각적이고 공간적으로 소비하는 것을 좋아하여 전통 컴퓨팅에서 GUI가 발명됨
마찬가지로 LLM은 사람의 선호 형식인 이미지, 인포그래픽, 슬라이드, 화이트보드, 애니메이션/비디오, 웹 앱 등으로 소통해야 함
현재 초기 버전은 이모지와 마크다운 같은 것들 - 제목, 굵게, 기울임, 목록, 표 등으로 텍스트를 "시각적으로 꾸미고" 배치
Nano Banana가 LLM GUI의 모습에 대한 첫 초기 힌트
- 이미지 생성 자체만이 아니라, 텍스트 생성, 이미지 생성, 세계 지식이 모델 가중치에 모두 얽힌 결합 역량이 중요

TLDR; 종합정리

2025년은 LLM의 흥미롭고 약간 놀라운 해였음
LLM이 예상보다 훨씬 똑똑하면서 동시에 예상보다 훨씬 멍청한 새로운 종류의 지능으로 부상
어쨌든 LLM은 매우 유용하며, 현재 기술 수준에서도 업계가 그 잠재력의 10%도 채 활용하지 못하고 있다고 생각
시도해 볼 만한 아이디어는 무궁무진하며, 개념적으로 이 분야는 아직 갈 길이 멀어 보임
(겉보기에는 역설적이지만) 앞으로 빠르고 지속적인 발전이 있을 것이라고 믿는 동시에 아직 해야 할 일이 많다고 생각

▲

laeyoung 2일전 [-]

"menugen, llm-council, reader3, HN time capsule 등 존재했으면 하는 것들을 빠른 앱 데모로 바이브 코딩"

바이브 코딩의 아버지답게 바이브 코딩으로 만드는 것들이 제가 만든 사소한 것들는엄청 다르네요. 🤣

답변달기

▲

GN⁺ 3일전 [-]

Hacker News 의견들

나에게 올해 가장 인상 깊은 혁신은 Claude Code였음
Cursor는 좋은 개념 증명이었지만, 실제로 내가 LLM을 코딩에 쓰게 만든 건 Claude Code였음
Claude가 생성하는 코드는 거의 내가 직접 쓴 코드와 같아서, 마치 내 생각을 읽는 것 같음
덕분에 Claude가 만든 코드를 유지보수하기도 쉬움
코드 스타일을 90~95% 정도 예측할 수 있고, 나보다 훨씬 빠르게 작성함
Gemini도 인상적이지만, 특히 Nano Banana는 그래픽 디자인에 유용함
코딩에는 아직 Gemini를 써보지 않았음. Claude Code가 너무 잘해서 더 빠르게 코딩하면 오히려 결정 피로가 올 것 같음
나는 아키텍처나 UX 결정을 서두르지 않고, 하루 이틀 고민한 뒤 구현을 시작하는 편임. 한 방향으로 가기 시작하면 되돌리기 어렵고, 매몰비용 오류로 잘못된 선택을 고집하게 되기 때문임
- 나는 이제 Cursor를 쓸 이유를 거의 못 느끼고 있음
  IntelliJ IDEA에 Claude Code 플러그인을 설치해서, IDE는 코드 탐색이나 리뷰용으로만 씀
  이제 두 줄 이상 직접 코드를 쓴 기억이 없음
  Claude Code 덕분에 생산성이 최소 5배 이상 향상되었고, 테스트 작성 비용이 거의 없어서 테스트 커버리지도 훨씬 좋아졌음
  Claude와 함께 계획을 세우고, 질문하고, 구현시키고, 리뷰하고, 수정 요청하는 식으로 완전한 AI 에이전트 워크플로우를 사용 중임
  수동 코딩은 전혀 없음. 완전 제로임
- Nano Banana Pro는 제대로 다룰 줄 안다면 정말 미친 도구임
  이런 걸 공개했다는 게 아직도 믿기지 않음
- 나는 처음엔 GLM 코딩 플랜(월 2달러 정도)을 쓰며 에이전트 코딩에 입문했음
  하지만 매번 Claude에게 코드를 더 우아하고 읽기 쉽게 만들어달라고 요청하다가, 그냥 Claude Code로 갈아탐
  GLM도 좋은 프롬프트를 쓰면 꽤 근접하지만, 하루 0.6달러로 그런 걱정을 안 해도 된다면 고민할 필요가 없다고 느낌
- 매달 새로운 툴을 평가할 시간이 없어서 Cursor에 정착했음
  같은 모델을 쓰면서 내가 놓치고 있는 게 뭔지 궁금함
Karpathy의 글을 좋아하지만, 요즘은 “It’s not X, it’s Y” 같은 LLM식 문장 구조를 보면 본능적으로 움찔하게 됨
3년 전엔 아무렇지 않았는데, 이제는 이런 문체가 완전히 망가진 느낌임
- 맞음, 이제 그걸 지적받고 나니 나도 그 문체가 눈에 밟혀서 안 보이질 않음
- 예전엔 문장에 em dash(—) 를 자주 썼는데, 사람들이 내 글을 “AI가 쓴 것 같다”고 해서 글쓰기 방식을 바꿔야 했음
- Karpathy의 글을 읽으러 왔는데, 이젠 그냥 LLM에게 물어보는 게 나을지도 모르겠다는 생각이 듦
- 나는 LLM 이전부터 이런 문장을 싫어했음
  “It’s not just a website…” 같은 문장은 수사적 군살(rhetorical fat) 이라고 부름
  이런 군살을 제거하면 단조롭지만 명확한 문장이 됨
  특히 “little spirit” 같은 표현은 과장된 느낌이라 눈을 굴리게 됨
  물론 저자는 강조를 위해 장식한 것이겠지만, 내 글쓰기 이상과 맞지 않아 거부감이 생김
  “It’s not just about image generation…” 같은 문장은 불필요한 개념적 긴장감을 줌
  차라리 “이미지 생성이 텍스트 생성과 결합될 때 더 멋지다”고 쓰는 편이 낫다고 생각함
- 이제 그 문체가 눈에 밟혀서 인터넷을 즐기기가 힘들어졌음
훌륭하고 현실적인 리뷰였음
“LLM이 예상보다 똑똑하면서도 동시에 멍청하다”는 말이 걱정됨
어떤 쪽을 마주하게 될지 어떻게 알 수 있을까?
코딩에서는 오류를 쉽게 감지할 수 있지만, 일반 영역에서는 어렵지 않나 생각함
또 “일반인들이 전문가보다 LLM의 혜택을 더 본다”는 주장에 대해, 과거 AppleScript나 VB, 비주얼 프로그래밍도 그런 기대가 있었지만 결국 AI는 똑똑한 검색엔진처럼 쓰이고 있음
하지만 그 영역이 바로 환각(hallucination) 이 가장 심한 곳이라 문제라고 생각함. 해결책이 궁금함
Andrej의 낙관적인 태도는 좋지만, 2025년에 산업 권력 집중이 어떻게 변했는지, 오픈소스와 로컬 추론, 하드웨어 제약 같은 주제에 대한 그의 시각도 듣고 싶음
예를 들어 그는 Claude Code가 “로컬에서 실행된다”고 표현했지만, 실제로는 TUI만 로컬이고 추론은 클라우드에서 이루어짐
이런 구조가 2026년 이후 어떻게 발전할지 궁금함
- CC의 요점은 데이터와 환경 컨텍스트에 관한 것이지, 연산 위치에 관한 게 아님
  클라우드 설정이 불편한 이유는 계산 때문이 아니라 UI/UX와 사용자 루프 때문임
- llama.cpp가 이제 Anthropic 메시지 포맷을 지원해서 Claude Code와 함께 쓸 수 있음
- 로컬에서 실행 가능한 흥미로운 코딩 에이전트 중 하나는 OpenAI Codex임
  Ollama에서 호스팅되는 gpt-oss 모델과 함께 실행할 수 있음
  codex --oss -m gpt-oss:20b 같은 식으로, 더 큰 모델(120b)도 가능함
- Karpathy가 말한 “로컬에서 실행되는 에이전트”는 LangChain 같은 웹 서비스가 아니라, LLM API를 호출하는 소프트웨어 래퍼(Harness) 를 의미함
  이 에이전트는 Bash를 호출하고, 파일 시스템을 다루며, OS 상에서 거의 모든 일을 할 수 있음
  즉, 모델은 멀리 떨어진 두뇌, 에이전트는 기계 슈트 같은 개념임
- Claude Code 부분은 다소 모호하게 쓰였다고 생각함
  그는 추론이 아니라 에이전트가 로컬에서 실행된다는 의미로 쓴 듯함
  OpenAI가 Codex를 클라우드 중심으로 설계한 반면, CC는 로컬 우선 접근을 택했다는 점을 강조한 것 같음
  하지만 이런 구분은 훨씬 명확히 설명될 필요가 있음
Karpathy가 말한 “동물을 기르는 것 vs 유령을 소환하는 것”이라는 RLVR 비유가 현재의 비정형 지능(jagged intelligence) 을 설명하는 완벽한 모델이라고 느낌
우리는 일반적 생존자를 만드는 게 아니라, 검증 가능한 보상에 맞춰 특정 영역만 과최적화하고 있음
또 “vibe coding으로 인한 일회성 소프트웨어” 개념도 공감됨
문제 하나 디버깅하려고 임시 앱을 만들고 바로 삭제하는 흐름이 진짜 변화처럼 느껴짐
- 하지만 “동물 vs 유령” 비유가 그리 통찰력 있다고는 생각하지 않음
  인간과 동물은 진짜 지능적 존재지만, LLM은 인간의 산출물을 좁은 범위에서 반향할 뿐임
  진정한 인공지능이 되려면 자율성, 지속적 학습, 호기심, 가상적 신체성 같은 특성이 필요함
  대부분의 동물은 본능적이지만, 인간처럼 일반화된 학습 능력을 가진 존재만이 진정한 지능을 가짐
- 다만 지금의 LLM 사용은 보조금 덕분에 가능한 수준임
  실제 비용을 지불해야 할 때도 이런 일회성 앱 제작이 계속될지는 지켜봐야 함
- 나는 이미 몇 달째 그렇게 쓰고 있음. 정말 즐거움
  내 글에 정리했는데, Jupyter가 시작한 일을 마무리하는 스택임
  함수형 펜스(fence) 구조로, 호출 가능하고 조합 가능함
  MCP와 같은 형태이며, 별도 학습 없이 패턴만 익히면 됨
  심지어 18세기 피아노 교육법과 컨텍스트 엔지니어링을 연결하는 함수자(functor) 도 존재함
Karpathy가 말한 “LLM이 이미지, 슬라이드, 화이트보드 등 사용자 선호 형식으로 소통해야 한다”는 부분이 흥미로움
하지만 LLM이 매번 사용자별로 새로운 UX를 만든다면, 예측 불가능한 인터페이스 지옥이 될 수도 있음
“이 앱에서 Command-W는 뭘 할까?” 같은 상황이 생길 것임
- 반대로, 최근 에이전트 중 일부는 접근성(accessibility) 을 신경 쓰기 시작했음
  Codex 같은 경우는 인간보다 더 꼼꼼하게 챙김
- 인간의 실제 커뮤니케이션 방식을 보면, 1위는 텍스트/음성, 2위는 이미지일 것 같음
- 하지만 사실 LLM이 이미 그 문제를 해결했음
  LLM 자체가 최고의 UI임
  여러 언어와 추상 개념을 이해하므로, 굳이 무작위 UI를 생성할 필요가 없음
  나는 비영어권 사용자로서 독일어 단어를 섞어 써도 잘 이해해줌
많은 AI 인플루언서들이 “텍스트 UI는 사라질 것”이라 확신하지만, 실제로는 텍스트 인터페이스가 여전히 중심임
- 며칠 전 AI 3D 모델링 툴 구독을 취소하려다 5분 동안 버튼을 못 찾았음
  결국 요금제 카드의 저대비 점 3개 메뉴 안에 숨겨져 있었고, 클릭하니 AI 챗봇 대화창이 열렸음
  “unsubscribe” 프롬프트를 입력해야만 버튼이 나타났음
  이런 자동응답 전화식 UX를 앱에 도입하는 건 끔찍하다고 느낌
  프론트엔드 엔지니어로서 이런 트렌드가 무섭게 느껴짐
- 내 평생 동안 사람들은 점점 대화보다 문자 입력을 더 많이 하게 된 것 같음
Andrej가 올해의 고속 모델들(Gemini 3 Flash, Grok 4 Fast)에 대해 어떻게 생각하는지 궁금함
이렇게 빠르고 싸고 좋은 모델들이 등장했는데, 커뮤니티는 거의 주목하지 않는 듯함
시각적 인터페이스를 위한 LLM 비전이 실현되려면 이런 모델이 필수일 것 같음
- 아마도 이런 소형 모델들은 대형 모델의 증류(distillation) 버전일 가능성이 큼
  대형 모델이 생성한 추론 흔적(reasoning traces) 으로 학습했을 것이라 추측함
- Sasha Luccioni의 연구를 참고해보길 추천함
2025년은 훈련 데이터에 유령이 깃들기 시작한 해이기도 함
이제 X(트위터)의 절반은 LLM이 LLM에게 답하는 구조임
즉, 데이터셋 내부에서 호출이 일어나는 상황임
- 이런 LLM 계정을 구별하는 팁이 있다면 알고 싶음. 봇과 논쟁하고 싶지 않음
o3가 전환점이었다는 말에 공감함
어떤 사람은 o3나 o4-mini가 사실상 gpt-5급이었다고 말했음
하지만 이름이 생소해서 주목받지 못했고, 대신 gpt-5는 점진적 개선만 보여서 실망스러웠음
o4-mini는 대화체 언어가 어색해서 기본 모델로는 부적절했겠지만, “gpt-5 pro” 같은 이름으로 $20 요금제에 넣었으면 좋았을 것 같음
- 나도 동의함. 당시 o3를 써본 사람이 거의 없었고, 이름이 이상해서 관심을 못 받았음
  지금 돌이켜보면 그때가 메이저 릴리스 타이밍이었다고 생각함

답변달기