“요즘 프로그래머로서 이렇게 뒤처진 느낌이 든 적이 없었다.” AI 분야에서 가장 많이 인용되는 연구자 중 한 명인 Andrej Karpathy가 올해 초 공개적으로 한 말입니다. OpenAI 공동 창업자이자 Tesla Autopilot을 이끈 사람이 이렇게 말한다면 —무언가 달라졌다는 신호일 겁니다.
Karpathy가 Sequoia Ascent 2026 행사에서 진행한 파이어사이드 챗 내용을 본인 블로그에 정리해 공개했습니다. 2025년 12월을 기점으로 AI 에이전트 도구가 질적으로 달라졌다는 체감에서 시작해, Software 3.0이라는 새로운 패러다임과 개발자 역할의 변화를 다루고 있습니다.
출처: Sequoia Ascent 2026 summary – Andrej Karpathy
2025년 12월, 무언가 바뀌었다
Karpathy는 Claude Code, Codex 같은 에이전트 도구를 꾸준히 써왔지만, 2025년 12월이 전환점이었다고 말합니다. 그전까지는 에이전트가 코드를 만들어도 자주 수정해야 했습니다. 그런데 12월부터는 결과물을 수정한 기억이 잘 나지 않을 정도로 품질이 올라갔고, 더 큰 단위의 작업을 맡겨도 무리 없이 처리해냈다는 겁니다.
개발 단위가 달라졌습니다. 코드 한 줄을 타이핑하던 방식에서, “이 기능 구현해줘”, “이 서브시스템 리팩토링해줘”, “테스트 작성하고 실패하면 수정해줘” 같은 거시적 지시로 바뀐 것이죠. Karpathy는 이걸 “프로그래머의 역할이 코드 작성자에서 에이전트 오케스트레이터로 전환되는 신호”라고 봅니다.
Software 3.0: 컨텍스트 창이 새로운 프로그램이다
Karpathy가 정리한 소프트웨어 진화의 세 단계는 이렇습니다.
- Software 1.0 — 사람이 명시적인 코드를 작성
- Software 2.0 — 사람이 데이터셋과 목표를 설계하면, 프로그램이 가중치(weights)로 학습
- Software 3.0 — 프롬프트와 컨텍스트로 LLM을 프로그래밍
Software 3.0에서 핵심 레버는 컨텍스트 창입니다. LLM이 인터프리터고, 그 인터프리터에 무엇을 넣느냐가 곧 프로그래밍입니다.
그가 든 예시입니다. MenuGen이라는 앱을 만든 적이 있는데, 레스토랑 메뉴 사진을 찍으면 OCR로 음식명을 추출하고, 이미지 생성기로 음식 사진을 만들어 보여주는 앱이었습니다. 프론트엔드, API, 배포, 인증, 결제까지 전형적인 소프트웨어 스택이 필요했죠.
그런데 나중에 Software 3.0 버전을 보게 됩니다. 메뉴 사진을 멀티모달 모델에 주면서 “메뉴 위에 음식 이미지를 직접 렌더링해줘”라고 하면 — 모델이 입력 이미지를 직접 출력 이미지로 변환해버립니다. 앱 스택 전체가 불필요해진 것입니다. Karpathy의 표현을 빌리면, “MenuGen이라는 앱은 존재할 필요가 없었던 것”입니다.
AI 능력이 들쭉날쭉한 이유: 검증 가능성 프레임
“state-of-the-art 모델이 10만 줄 코드베이스를 리팩토링하면서, 세차장까지 걸어야 하냐 운전해야 하냐는 못 맞힐 수 있다.” Karpathy가 직접 든 예시입니다.
이 들쭉날쭉함(jaggedness)을 설명하는 것이 그의 검증 가능성(verifiability) 프레임입니다.
기존 소프트웨어는 명세할 수 있는 것을 자동화했습니다. LLM은 검증할 수 있는 것을 자동화합니다. 코딩이 유독 빠르게 발전한 이유가 여기 있습니다. 테스트가 통과하거나 실패하고, 프로그램이 실행되거나 오류가 납니다. 모델이 즉각적인 피드백을 받을 수 있는 환경이라는 뜻이죠.
반면 세차장 문제는 다릅니다. 정답을 자동으로 판별하기 어렵고, 훈련 데이터에도 많지 않습니다. 검증 가능성이 낮은 영역은 모델이 훈련을 충분히 받지 못하고, 결과적으로 엉뚱한 대답이 나옵니다.
그는 여기에 “labs의 관심”을 또 하나의 축으로 추가합니다. 경제적으로 가치 있고 검증 가능한 영역일수록 훈련 데이터와 강화학습 환경이 집중되고, 능력이 급격히 좋아집니다. 즉 내가 사용하려는 도메인이 이 “훈련된 회로” 안에 있느냐 없느냐가 모델 활용의 현실적인 기준입니다.
Vibe Coding vs. Agentic Engineering
Karpathy가 직접 만든 용어인 vibe coding과, 그가 이번에 새롭게 정의하는 agentic engineering의 차이가 이 대화의 핵심입니다.
Vibe coding은 바닥을 높입니다. 누구나 원하는 것을 말만 해도 소프트웨어를 만들 수 있게 됩니다.
Agentic engineering은 천장을 높입니다. 전문 소프트웨어의 품질 기준을 유지하면서 에이전트를 조율하는 공학적 규율입니다. 보안 취약점을 방치하거나, 잘못된 시스템 설계를 그냥 넘기지 않습니다.
MenuGen 결제 버그가 좋은 예시입니다. 에이전트가 Stripe 결제와 Google 계정을 이메일 주소로 연결하는 코드를 작성했는데, 두 이메일이 다를 수 있다는 점을 놓쳤습니다. 작동하는 코드지만 잘못된 설계입니다. Karpathy는 이 부분을 사람이 반드시 잡아야 한다고 말합니다. “에이전트는 인턴이고, 사람이 스펙과 방향을 책임져야 한다”는 거죠.
기술적 세부 사항 — PyTorch에서 dim이냐 axis냐, reshape이냐 permute냐 — 은 에이전트가 기억합니다. 사람은 더 이상 외울 필요 없습니다. 하지만 텐서 스토리지의 개념, 메모리 복사 비용, 시스템 경계 같은 근본 원리는 여전히 사람의 몫입니다.
“이해는 위탁할 수 없다”
대화의 마지막에 Karpathy가 소개한 트윗 한 줄입니다.
You can outsource your thinking, but you can’t outsource your understanding.
에이전트가 더 많이 일할수록, 사람은 방향을 제시하는 역할이 됩니다. 무엇을 만들 가치가 있는지, 어떤 결과가 이상한지, 어떤 트레이드오프가 수용 가능한지 — 이것들은 이해 없이는 판단할 수 없습니다.
이 글에서 담지 못한 내용 — 에이전트 네이티브 인프라, 스타트업을 위한 검증 가능한 도메인 찾기 전략, 채용 방식의 변화 — 은 원문에서 확인할 수 있습니다.
답글 남기기