안드레이 카파시 AI Ascent 2026 인터뷰 정리
목차
Sequoia AI Ascent 2026에서 안드레이 카파시가 이야기한 Software 3.0, agentic engineering, jagged intelligence를 정리하고 개인적인 해석을 덧붙입니다. 2026년 4월 20일 Sequoia Capital이 개최한 AI Ascent 2026(네 번째 행사라 AI Ascent IV로 불립니다)에서, 안드레이 카파시(Andrej Karpathy)가 Stephanie Zhan과 fireside chat을 진행했습니다. "vibe coding"이라는 표현을 처음 만든 사람이 그 뒤에 무엇이 오는지를 이야기한 자리였습니다. 이 대화가 인상적이었던 이유는 예측이 아니라 프레임을 주기 때문입니다. "AI가 얼마나 발전할까"가 아니라, "왜 어떤 영역은 빠르게 좋아지고 어떤 영역은 이상하게 멈춰 있는가", "그렇다면 나는 무엇을 붙잡고 있어야 하는가"를 설명하는 축을 제시합니다. 듣고 흘려보내면 남지 않을 것 같아, 핵심 주장과 제 생각을 함께 정리했습니다. 이 글에서는 카파시가 이야기한 순서를 크게 따라가며 다음을 다룹니다. 참고한 자료 중 카파시가 직접 정리해 공개한 Sequoia Ascent 2026 summary 페이지에 요약과 정제된 트랜스크립트가 모두 담겨 있어, 인용은 이 문서를 기준으로 삼았습니다. 카파시는 2025년 12월을 코딩 agent가 질적으로 달라진 시점으로 지목합니다. 2025년 내내 Claude Code, Codex 같은 도구를 써왔지만 그때까지는 계속 손으로 고쳐줘야 했다고 말합니다. 그런데 12월 무렵부터 생성되는 덩어리가 더 커지고, 더 일관성 있고, 더 신뢰할 만해졌다고 이야기합니다. "I couldn't remember the last time I corrected it. I started trusting the system more and more." — 마지막으로 고쳐준 게 언제였는지 기억나지 않았다. 점점 더 시스템을 신뢰하기 시작했다. 특정 벤치마크 점수가 올랐다는 이야기가 아니라, 교정할 일이 체감상 사라졌다는 이야기라는 점이 중요합니다. 능력의 변화를 "무엇을 할 수 있는가"가 아니라 "내가 얼마나 개입해야 하는가"로 측정하고 있는 것입니다. 이 변화가 실무에서 의미하는 바는 프로그래밍의 단위(unit of programming)가 바뀌었다는 것입니다. 카파시의 표현을 그대로 옮기면 이렇습니다. "the unit of programming changed from typing lines of code to delegating larger 'macro actions.'" — 프로그래밍의 단위가 코드를 한 줄씩 타이핑하는 것에서 더 큰 'macro action'을 위임하는 것으로 바뀌었다. 즉 프로그래머의 역할이 코드를 쓰는 사람에서 agent를 조율하는 사람(orchestrator of agents)으로 이동합니다. 손이 하던 일을 입이 하게 되었다는 단순한 이야기가 아니라, 작업을 쪼개고 위임하고 결과를 검수하는 것이 본업이 되었다는 뜻입니다. 카파시가 실제로 agent에게 넘기고 있다고 말한 macro action들은 다음과 같습니다. 목록을 보면 공통점이 있습니다. 전부 "결과를 확인할 방법이 명확한" 작업입니다. test는 통과하거나 실패하고, service는 뜨거나 안 뜨고, 계획은 읽어보면 판단할 수 있습니다. 뒤에서 다룰 verifiability 이야기와 곧바로 이어지는 지점입니다. 카파시는 소프트웨어를 만드는 방식을 세 단계로 정리합니다. 이 구분 자체는 그가 이전부터 이야기해온 것이지만, 이번 대화에서는 Software 3.0에서 무엇이 프로그래밍 인터페이스인지를 더 분명하게 짚습니다. Software 2.0에서 프로그램은 "weight 안으로 학습된다(learned into weights)"고 표현합니다. 그리고 Software 3.0에서는 LLM이 context에 대한 interpreter이고, 우리가 쥔 레버는 context window입니다. "what's in the context window is your lever over the interpreter" — context window에 무엇이 들어 있는지가 interpreter를 조작하는 레버다. 개인적으로 이 문장이 이 대화에서 가장 실용적인 부분이라고 생각합니다. "프롬프트를 잘 쓰자"는 조언은 많이 들어봤지만, context window를 프로그램 그 자체로 보면 관리 대상이 달라집니다. 무엇을 넣을지만이 아니라 무엇을 빼고, 어떤 순서로 쌓고, 어떤 형태로 저장할지가 전부 설계 문제가 됩니다. 카파시가 든 구체적인 예는 설치 스크립트입니다. 여러 플랫폼을 지원하는 복잡한 설치 과정은 전통적으로 취약한 shell script 덩어리로 만들어야 했습니다. Software 3.0에서는 installer가 agent에게 붙여넣는 지시문 블록이 될 수 있습니다. agent는 환경을 직접 읽고, 에러를 디버깅하고, 그 머신에 맞게 적응합니다. 카파시는 이것을 "다른 종류의 프로그램"이라고 부릅니다. "a different kind of program. It is less precise, but more adaptive." — 다른 종류의 프로그램이다. 덜 정확하지만, 더 적응적이다. 정확성을 내주고 적응성을 얻는 교환입니다. 설치 스크립트처럼 "환경이 제각각이라 모든 분기를 미리 적을 수 없는" 문제에서는 이 교환이 충분히 유리합니다. 반대로 결과가 매번 똑같아야 하는 문제라면 손해입니다. 어떤 문제에 어느 쪽을 쓸지 판단하는 것이 새로 생긴 설계 결정이라고 읽었습니다. 카파시는 여기서 한 발 더 나아간 사고 실험을 꺼냅니다. 지금은 신경망이 고전적인 컴퓨터 위에서 돌아가는 한 계층이지만, 그 관계가 뒤집히는 방향을 상상해봅니다. 신경망이 host process가 되고, CPU가 오히려 coprocessor가 되는 구조입니다. 그는 컴퓨팅의 역사를 비유로 씁니다. "In the 1950s and 1960s, it was not obvious which way it would go. We went down the calculator path." — 1950~60년대에는 어느 방향으로 갈지 분명하지 않았다. 우리는 계산기의 길을 갔다. 이 구조에서 그가 그리는 그림은 raw video나 audio를 신경망에 넣고 diffusion으로 그 순간에만 유일한 UI를 렌더링하는 형태입니다. 그렇다면 고전적인 컴퓨팅은 사라지는 것일까요. 그렇지는 않습니다. 결정론적인 작업을 위한 도구로 남되, 종속적인 위치로 내려간다고 봅니다. 다만 이 부분은 카파시 본인도 완성된 설계로 제시하지 않습니다. kernel이나 peripheral 같은 기존 구성 요소가 신경망 쪽에서 무엇에 대응하는지에 대한 매핑은 나오지 않고, 방향성에 대한 이야기에 머무릅니다. 흥미로운 그림이지만, 앞의 Software 3.0 논의와 달리 지금 당장 실무에 적용할 종류의 이야기는 아니라고 봤습니다. 이 섹션이 창업자나 제품을 만드는 사람에게 가장 직접적인 부분입니다. 카파시는 자기가 만든 MenuGen이라는 앱을 스스로 반례로 씁니다. MenuGen은 단순한 일을 합니다. 식당 메뉴 사진을 찍으면, 메뉴에 적힌 요리 이름을 OCR로 읽고, 각 요리의 이미지를 생성해서 UI에 보여줍니다. 이 정도 기능을 위해 실제로 필요했던 것은 frontend 코드, API, image generation, deployment, auth, payment, secret 관리, 그리고 infrastructure였습니다. 익숙한 목록입니다. 우리가 "앱을 만든다"고 할 때 실제로 만드는 것의 대부분입니다. 그런데 Software 3.0의 관점에서 같은 문제를 다시 보면 이렇게 됩니다. 메뉴 사진을 multimodal model에 주고, 요리 이미지를 메뉴 이미지 위에 직접 렌더링하게 한다. 끝입니다. "much of the app disappears. The neural network directly transforms input media into output media. The old software stack was scaffolding around a transformation the model can now perform directly." — 앱의 상당 부분이 사라진다. 신경망이 입력 미디어를 출력 미디어로 직접 변환한다. 기존의 software stack은 이제 모델이 직접 수행할 수 있는 변환을 둘러싼 비계였다. 카파시는 이걸 더 세게 표현합니다. "All of MenuGen is spurious in that framing... That app shouldn't exist." — 그 관점에서 보면 MenuGen 전체가 불필요하다... 그 앱은 존재하지 않아야 한다. 그리고 창업자를 향한 결론을 이렇게 정리합니다. "AI is not just a faster way to build the old apps. Some apps should stop existing as apps." — AI는 단지 기존 앱을 더 빠르게 만드는 방법이 아니다. 어떤 앱은 앱으로 존재하기를 멈춰야 한다. 자기가 만든 앱을 예로 들어 "이건 없어져야 한다"고 말하는 게 이 대화에서 가장 설득력 있는 대목이었습니다. 대부분의 stack이 모델이 직접 못 하던 변환을 우회하기 위한 비계였다면, 모델이 그 변환을 직접 하게 된 순간 비계도 함께 걷혀야 한다는 논리입니다. 자동화의 물결이 코드 생성에만 오는 게 아니라는 이야기로 이어집니다. 카파시가 예로 드는 것은 LLM Wiki 패턴입니다. 매번 RAG로 검색해 답하는 방식 대신, agent가 원본 자료들을 점진적으로 컴파일해서 persistent Markdown wiki로 만들어 나갑니다. 여기에는 요약, entity 페이지, concept 페이지, 상충하는 내용, cross-link, 로그, 그리고 계속 갱신되는 종합이 들어갑니다. "There was no code that could create a knowledge base based on a bunch of messy facts" — 지저분한 사실 덩어리를 기반으로 knowledge base를 만들어낼 수 있는 코드는 없었다. 핵심은 이것이 더 빨라진 작업이 아니라 이전에는 존재하지 않던 작업이라는 점입니다. 지저분한 사람의 문서들을 가로질러 이런 지식 베이스를 견고하게 유지하는 고전적인 프로그램은 쓸 수 없었습니다. 그래서 카파시가 제안하는 전략적 재구성은 질문을 하나 더 두는 것입니다. "do not only ask, 'What existing workflow can AI speed up?' Also ask, 'What information transformation was impossible before, but is now natural?'" — "AI가 어떤 기존 workflow를 빠르게 해줄 수 있는가"만 묻지 말고, "이전에는 불가능했지만 지금은 자연스러운 정보 변환은 무엇인가"도 물어라. 첫 번째 질문만 하면 기존 제품의 개선판이 나오고, 두 번째 질문을 해야 새로운 것이 나온다는 뜻으로 읽었습니다. 여기서부터가 이 대화의 중심 프레임입니다. 카파시는 자동화의 두 세대를 한 문장으로 갈라놓습니다. "Traditional computers automate what you can specify in code. This latest round of LLMs can automate what you can verify." — 전통적인 컴퓨터는 코드로 명세(specify)할 수 있는 것을 자동화한다. 이번 세대의 LLM은 검증(verify)할 수 있는 것을 자동화한다. 짧지만 많은 것을 설명하는 문장입니다. 자동 보상이나 성공 신호가 있는 작업은 모델이 연습을 통해 좋아질 수 있습니다. 그래서 능력이 수학, 코딩, test, benchmark, 엔지니어링 작업 주변에 몰립니다. 이 영역들은 공통적으로 되돌릴 수 있고(resettable), 반복할 수 있고(repeatable), 보상을 줄 수 있습니다(rewardable). 같은 모델을 쓰는데도 coding agent가 일반 chatbot보다 훨씬 잘 작동하는 이유가 여기서 설명됩니다. "Coding gives the model feedback: tests pass or fail, programs run or crash, diffs can be inspected, benchmarks can be measured." — 코딩은 모델에게 피드백을 준다. test는 통과하거나 실패하고, 프로그램은 실행되거나 크래시하고, diff는 검토할 수 있고, benchmark는 측정할 수 있다. 이 프레임이 유용한 건 예측을 뒤집을 수 있기 때문입니다. 어떤 작업에 agent를 붙일지 고민할 때 "이건 어려운 일인가 쉬운 일인가"를 묻는 대신, 이 작업의 성공을 자동으로 판별할 수 있는가를 물으면 됩니다. 사람이 눈으로 봐야만 맞는지 알 수 있는 일이라면, 난이도와 무관하게 agent가 잘하기 어려운 쪽에 속합니다. 반대로 검증 장치를 만들어 붙이는 것 자체가 agent의 성능을 올리는 작업이 됩니다. verifiability만으로는 설명되지 않는 부분이 남습니다. 카파시는 여기에 두 번째 축을 더합니다. 두 번째 축은 frontier lab이 그 작업에 얼마나 신경을 썼는지입니다. pretraining mixture, post-training, synthetic data 생성, 그리고 RL 환경 구성에서 그 작업이 강조되었는지 여부입니다. 카파시는 이를 대략적인 곱으로 표현합니다. 근거로 드는 사례가 체스입니다. GPT-3.5에서 GPT-4로 넘어갈 때 체스 실력이 많이 좋아졌고, 많은 사람들이 이걸 일반적인 능력 향상으로 받아들였습니다. 하지만 카파시는 pretraining set에 체스 데이터가 대량으로 들어갔다는 것이 공개된 정보라고 지적합니다. 데이터 분포 안에 들어왔기 때문에 기본값보다 훨씬 많이 좋아진 것입니다. "Someone at OpenAI decided to add that data, and now there is a capability spike." — OpenAI의 누군가가 그 데이터를 추가하기로 결정했고, 그래서 capability spike가 생겼다. 즉 우리가 보는 모델의 능력 지형은 순수한 지능의 함수가 아니라, 어떤 데이터를 넣기로 누가 결정했는지의 함수이기도 합니다. "frontier models do not come with a manual. They are artifacts of pretraining mixtures, RL environments, benchmark pressure, product priorities, and economic incentives. They spike in some places and behave strangely in others." — frontier model에는 매뉴얼이 딸려 오지 않는다. 이들은 pretraining mixture, RL 환경, benchmark 압력, 제품 우선순위, 경제적 인센티브의 산물이다. 어떤 지점에서는 튀어오르고 어떤 지점에서는 이상하게 동작한다. 이 들쭉날쭉함, 즉 jagged intelligence를 카파시는 유명한 예로 설명합니다. 예전에는 "strawberry에 글자가 몇 개인가"를 모델이 틀리는 것이 대표적인 예였지만 그건 이미 패치되었습니다. 그가 든 새 예는 이렇습니다. "I want to go to a car wash to wash my car, and it's 50 meters away. Should I drive or walk? State-of-the-art models may tell you to walk because it's close." — 세차하러 세차장에 가려고 하는데 50m 거리다. 운전해서 갈까 걸어갈까? 최신 모델은 가깝다는 이유로 걸어가라고 답할 수 있다. 세차장에 걸어가면 세차할 차가 없습니다. 그래서 그는 이렇게 묻습니다. "How is it possible that a state-of-the-art model can refactor a 100,000-line codebase or find zero-day vulnerabilities, yet tells me to walk to the car wash?" — 10만 줄 codebase를 refactor하거나 zero-day 취약점을 찾아내는 최신 모델이, 어떻게 세차장에 걸어가라고 말할 수 있는가? 실무자에게 남는 질문은 하나로 정리됩니다. "You have to figure out which circuits your application is in. If you are not in those circuits, then you have to look at fine-tuning or doing some of your own work." — 당신의 애플리케이션이 어떤 circuit 안에 있는지 알아내야 한다. 그 circuit 안에 없다면, fine-tuning이나 직접 해야 할 작업들을 살펴봐야 한다. 내 작업이 검증 가능하고 학습이 집중된 영역 안에 있다면 날아가고, 밖에 있다면 고전합니다. 밖에 있다면 더 나은 context, 더 나은 도구, fine-tuning, 자체 eval, 자체 RL 환경 중 무언가를 직접 만들어야 합니다. 이 두 축이 곧바로 창업 기회의 지도가 됩니다. 카파시가 창업자에게 권하는 것은 가치 있고(valuable), 검증 가능하고(verifiable), frontier lab이 아직 충분히 학습시키지 않은(undertrained) 영역을 찾는 것입니다. "If you are in a verifiable setting where you can create reinforcement learning environments or examples, then you can potentially do your own fine-tuning and benefit from it." — 검증 가능한 환경에 있어서 RL 환경이나 예제를 만들 수 있다면, 자체 fine-tuning을 해서 이득을 볼 수 있다. 코딩처럼 뻔한 영역은 이미 lab들이 대규모로 투자하고 있습니다. 하지만 경제적으로 중요한 영역 중에 아직 활용되지 않은 잠재적 검증 구조를 가진 곳이 있을 수 있고, 거기가 기회라는 이야기입니다. 이 대화의 제목이기도 한 주제입니다. 카파시는 두 가지를 대립이 아니라 서로 다른 방향의 움직임으로 설명합니다. "Vibe coding is about raising the floor for everyone in terms of what they can do in software." — vibe coding은 소프트웨어로 무엇을 할 수 있는지에 대해 모두의 바닥을 올리는 것이다. "Agentic engineering is about preserving the quality bar of professional software." — agentic engineering은 전문 소프트웨어의 품질 기준을 지키는 것이다. vibe coding은 원하는 것을 말로 설명해서 거의 누구나 소프트웨어를 만들 수 있게 합니다. agentic engineering은 그 위에서 품질, 보안, 유지보수성을 지켜내는 규율입니다. 카파시는 agent의 성질을 이렇게 표현합니다. "You have agents, which are spiky entities. They are fallible and stochastic, but extremely powerful. How do you coordinate them to go faster without sacrificing your quality bar?" — 당신에게는 튀어오르는(spiky) 존재인 agent들이 있다. 이들은 오류를 내고 확률적이지만, 대단히 강력하다. 품질 기준을 희생하지 않으면서 더 빨리 가려면 이들을 어떻게 조율해야 하는가? 그리고 이 규율의 상한이 상당히 높다고 봅니다. "People used to talk about the 10x engineer... People who are very good at this can peak much higher than that." — 사람들이 10x 엔지니어를 이야기하곤 했다... 이걸 아주 잘하는 사람은 그보다 훨씬 높이 올라갈 수 있다. 여기서 중요해지는 스킬은 API 세부사항을 외우는 것이 아니라 storage, memory copy, security boundary 같은 근본 개념을 이해하는 것입니다. 세부사항은 agent가 처리할 수 있기 때문입니다. 작업 방식이 바뀌었으니 사람을 뽑는 방식도 어긋나 있다는 지적이 이어집니다. 카파시가 제안하는 방식은 coding puzzle이 아닙니다. "build a substantial project with agents, deploy it, make it secure, and then have adversarial agents try to break it." — agent와 함께 상당한 규모의 프로젝트를 만들고, 배포하고, 안전하게 만든 다음, adversarial agent들이 그것을 깨보게 하라. 구체적으로는 "agent를 위한 Twitter clone을 만들고, 좋고 안전하게 만든 다음, agent들이 그 위에서 활동을 시뮬레이션하게 하라"는 예를 듭니다. 이렇게 하면 작업 분해, spec 작성, 품질 유지, 코드 리뷰, 시스템 하드닝 능력이 드러납니다. "Watching people in that setting, building a bigger project and using the tooling, is closer to what I would look for." — 그런 환경에서 더 큰 프로젝트를 만들고 도구를 사용하는 모습을 보는 것이, 내가 찾고자 하는 것에 더 가깝다. 대화의 톤이 한 번 바뀌는 지점입니다. 카파시는 LLM이 무엇인지에 대해 이야기합니다. "LLMs are not animals. They do not have biological drives, embodied survival pressure, curiosity, play, or intrinsic motivation." — LLM은 동물이 아니다. 생물학적 욕구, 신체화된 생존 압력, 호기심, 놀이, 내재적 동기를 갖고 있지 않다. "These things are not animal intelligence. If you yell at them, they are not going to work better or worse. They are statistical simulation circuits." — 이것들은 동물의 지능이 아니다. 소리를 질러도 더 잘하거나 더 못하게 되지 않는다. 이들은 통계적 시뮬레이션 회로다. 대신 이들은 사람이 만든 산물의 통계적 시뮬레이션이고, pretraining, post-training, RL, 제품 피드백, 경제적 인센티브에 의해 빚어진 형태입니다. 카파시가 쓰는 표현은 "ghosts, not animals"입니다. 진화가 만든 생물이 아니라, 사람이 남긴 텍스트를 재료로 소환된 유령이라는 비유입니다. 이 프레임의 목적은 철학적 정확성이 아니라 실무적 오류를 줄이는 것입니다. 모델을 사람처럼 대하면 예측이 계속 틀립니다. 카파시는 이들을 "jagged"하고 "alien tools"라고 부르며, 맹신도 무시도 아닌 태도를 권합니다. "The substrate is pretraining, then reinforcement learning bolted on top. It is a mindset: what am I interacting with, what is likely to work, what is not likely to work, and how do I modify it?" — 기반은 pretraining이고, 그 위에 RL이 덧붙여진다. 이건 마음가짐의 문제다. 나는 무엇과 상호작용하고 있는가, 무엇이 작동할 것 같고, 무엇이 작동하지 않을 것 같은가, 그리고 나는 그것을 어떻게 수정하는가? "I don't have five obvious outcomes that make your system better. It is more about being suspicious of the system and figuring it out empirically over time." — 당신의 시스템을 좋게 만드는 다섯 가지 뻔한 결론 같은 건 내게 없다. 시스템을 의심하면서 시간을 들여 경험적으로 파악해 나가는 문제에 더 가깝다. 앞의 jagged intelligence 논의와 같은 결론에 도달합니다. 매뉴얼이 없으니 직접 탐색해서 감각을 만들어야 한다는 것입니다. 지금 소프트웨어는 대부분 사람을 1차 사용자로 두고 만들어져 있습니다. 카파시는 이것이 근본적인 마찰이라고 봅니다. "Every time I am told 'go to this URL' or 'click here,' I think: no." — "이 URL로 가세요" 또는 "여기를 클릭하세요"라는 말을 들을 때마다 나는 생각한다. '아니.' 그가 필요하다고 말하는 것은 agent-native surface입니다. Markdown 문서, CLI, API, MCP server, 구조화된 로그, 그리고 기계가 읽을 수 있는 스키마입니다. "How do we make things agent-native? How do we describe them to agents first, and build automation around data structures that are legible to LLMs?" — 어떻게 하면 agent-native하게 만들 수 있을까? 어떻게 하면 agent에게 먼저 설명하고, LLM이 읽을 수 있는 데이터 구조 위에 자동화를 세울 수 있을까? 문서를 사람이 읽기 좋게 쓰는 것과 agent가 읽기 좋게 쓰는 것이 다르다는 지적이 특히 인상 깊었습니다. 스크린샷과 "여기를 누르세요"로 채운 문서는 사람에게는 친절하지만 agent에게는 아무 정보도 아닙니다. 카파시가 제안하는 정리 방식은 agent가 필요로 하는 것을 sensor와 actuator로 나누는 것입니다. sensor는 세계의 상태를 정보로 바꿔주는 것이고, actuator는 agent가 실제로 변경을 일으킬 수 있게 해주는 것입니다. 이 구분이 유용한 이유는 빠진 부분을 찾기 쉬워지기 때문입니다. agent가 뭔가를 못 하고 있을 때, 상태를 볼 수 없어서인지(sensor 부족) 손을 쓸 수 없어서인지(actuator 부족)를 나누어 물을 수 있습니다. MenuGen이 다시 등장합니다. 이번에는 인프라의 예로서입니다. "The hard part was not writing the code. The trouble was deploying it on Vercel, wiring services, settings, DNS, auth, payments, secrets, and production configuration." — 어려운 부분은 코드를 쓰는 것이 아니었다. 문제는 Vercel에 배포하고, service를 연결하고, 설정, DNS, auth, payment, secret, production 구성을 다루는 것이었다. 그리고 성숙한 agent-native 인프라에 대한 기대를 이렇게 말합니다. "I would hope I could prompt an LLM: build MenuGen. Then I don't touch anything, and it is deployed on the internet." — LLM에게 "MenuGen을 만들어"라고 프롬프트를 넣을 수 있기를 바란다. 그러면 나는 아무것도 만지지 않고, 그것이 인터넷에 배포되어 있다. 더 나아가서는 사람과 조직이 각자 agent 대표를 갖게 될 것이라고 예상합니다. "내 agent가 당신의 agent와 이야기해서 미팅 시간 같은 것을 정할 것"이라는 그림입니다. 작성 속도는 이미 크게 올라갔는데 배포와 운영은 여전히 사람이 클릭해야 한다면, 병목이 코드에서 인프라로 옮겨간 것뿐입니다. agent-native 인프라 이야기는 그 병목을 지목하는 것이라고 읽었습니다. 마지막 주제이면서, 이 대화 전체를 묶는 문장이 나오는 부분입니다. "You can outsource your thinking, but you can't outsource your understanding." — 사고는 외주 줄 수 있지만, 이해는 외주 줄 수 없다. 이 추상적인 문장에 카파시는 아주 구체적인 사례를 붙입니다. MenuGen의 결제 버그입니다. agent는 사용자 확인을 위해 Stripe 구매 내역과 Google 계정을 email 주소로 매칭했습니다. 문제는 두 email이 서로 다를 수 있다는 것입니다. "those can be different emails. The user might not get the credits they purchased." — 그 email들은 서로 다를 수 있다. 사용자가 구매한 credit을 받지 못할 수도 있다. "Why would you use email addresses to cross-correlate funds? You need a persistent user ID. This is the kind of mistake agents still make." — 왜 돈을 상호 연결하는 데 email 주소를 쓰겠는가? persistent user ID가 필요하다. 이것이 agent가 아직도 저지르는 종류의 실수다. 코드는 동작합니다. test도 통과할 수 있습니다. 이 버그는 email이 identity가 아니다라는 판단을 누군가 해줘야만 잡히는 종류의 문제입니다. 앞에서 이야기한 verifiability 프레임을 그대로 적용하면, 이건 자동으로 검증할 신호가 없는 영역입니다. 그래서 사람의 자리가 남습니다. "People have to be in charge of the spec and plan... You are in charge of oversight and the top-level categories. The agents do much of the work underneath." — 사람이 spec과 계획을 책임져야 한다... 당신은 감독과 최상위 범주를 책임진다. agent는 그 아래의 많은 일을 한다. 세부사항은 agent에게 넘길 수 있습니다. 카파시는 "You still have to understand the fundamentals. You need to know that there is underlying tensor storage, that you can manipulate a view of the same storage, or create different storage, which is less efficient." — 여전히 근본은 이해해야 한다. 밑에 tensor storage가 있고, 같은 storage의 view를 조작할 수도 있고, 다른 storage를 새로 만들 수도 있으며 후자가 덜 효율적이라는 것을 알아야 한다. 품질에 대해서도 솔직합니다. "It can be bloated, copy-pasted, awkwardly abstracted, brittle. It works, but it is gross." — 부풀려져 있고, 복사-붙여넣기 되어 있고, 어색하게 추상화되어 있고, 취약할 수 있다. 동작하기는 하는데, 지저분하다. 그리고 agent가 잘 못하는 영역의 예로 자신의 "The models hate this. They can't do it... You feel like you are outside the RL circuits." — 모델들은 이걸 싫어한다. 하지 못한다... RL circuit 밖에 있다는 느낌이 든다. 이 예가 특히 좋았습니다. "코드를 추가하는 것"은 검증 가능하지만 "코드를 덜어내면서 같은 일을 하게 만드는 것"은 자동으로 채점하기 어렵습니다. jagged intelligence의 경계가 어디에 있는지를 보여주는 사례입니다. 그렇다면 사람은 무엇을 해야 하는가에 대한 답입니다. "Information still has to make it into my brain. I am still part of the system... That is constrained by understanding." — 정보는 여전히 내 머릿속으로 들어와야 한다. 나는 여전히 시스템의 일부다... 그것은 이해에 의해 제약된다. "Understanding is still the bottleneck because you cannot be a good director if you do not understand." — 이해가 여전히 병목이다. 이해하지 못하면 좋은 director가 될 수 없기 때문이다. 그래서 카파시가 만드는 도구들은 속도를 올리는 도구가 아니라 이해를 키우는 도구입니다. 앞에서 나온 LLM Wiki가 여기서 다시 등장합니다. "Whenever I see a different projection onto information, I feel like I gain insight. It is synthetic data generation over fixed data." — 정보에 대한 다른 투영을 볼 때마다 통찰을 얻는 느낌이 든다. 고정된 데이터에 대한 synthetic data 생성인 셈이다. 같은 자료를 요약, entity, concept, 상충하는 지점 같은 여러 각도로 다시 펼쳐놓으면 사람의 이해가 올라간다는 이야기입니다. 카파시가 대화의 끝에서 정리하는 것은 희소성이 어디로 이동하는가입니다. 그리고 소프트웨어, 연구, 교육, 지식 노동 전반에 공통으로 적용되는 패턴을 이렇게 제시합니다. "define the context / define the tools / define the feedback loop / define the guardrails / let agents work / preserve human understanding" — context를 정의하고 / 도구를 정의하고 / 피드백 루프를 정의하고 / guardrail을 정의하고 / agent가 일하게 하고 / 사람의 이해를 지킨다. 기존 방식을 단순히 가속하는 것이 아니라 agent를 중심으로 재조직하는 것이라는 점이 요지입니다. 전체를 다시 보면 하나의 축이 반복됩니다. 검증할 수 있는 것은 자동화되고, 검증할 수 없는 것은 사람에게 남는다는 것입니다. Software 3.0에서 context window가 프로그램이 되는 것도, coding agent가 chatbot보다 잘하는 것도, jagged intelligence가 생기는 것도, 그래서 이 대화에서 제가 실무로 가져갈 것은 세 가지로 정리됩니다. "사고는 외주 줄 수 있어도 이해는 외주 줄 수 없다"는 문장이 오래 남습니다. agent에게 일을 넘기는 만큼 이해를 잃는다면 결국 조율할 수 없게 되니, 위임의 속도와 이해의 속도를 함께 맞추는 것이 앞으로의 과제가 될 것 같습니다. 개요
2025년 12월, agentic inflection point
프로그래밍의 단위가 타이핑에서 macro action 위임으로
무엇을 위임할 수 있게 되었나
Software 3.0 — context window가 새로운 프로그램이다
Software 1.0, 2.0, 3.0
단계 사람이 하는 일 프로그램이 존재하는 곳 Software 1.0 명시적으로 코드를 작성한다 소스 코드 Software 2.0 dataset과 objective를 만들고 신경망을 학습시킨다 학습된 weight Software 3.0 prompt, context, tool, example, memory, instruction을 구성한다 context window installer 예시 — 스크립트에서 지시문으로
Neural Computer — 신경망이 host가 되는 확장
AI는 기존 앱을 더 빠르게 만드는 도구가 아니다
MenuGen이 원래 필요로 했던 것들
앱이 사라지는 순간
LLM Wiki — 이전에는 불가능했던 정보 변환
질문을 바꾸기
specify할 수 있는 것 vs verify할 수 있는 것
전통적 소프트웨어는 명세를, LLM은 검증을 자동화한다
coding agent가 chatbot보다 잘하는 이유
jagged intelligence의 두 축
verifiability와 training attention
capability spike ~= verifiability x training attention x data coverage x economic value 내 애플리케이션은 모델의 rail 위에 있는가
verifiable하지만 아직 학습되지 않은 영역 — 창업 기회
vibe coding vs agentic engineering
바닥을 올리는 것과 천장을 올리는 것
채용도 달라져야 한다
ghosts, not animals
LLM은 생물이 아니라 통계적 시뮬레이션이다
의인화 대신 경험적 감각
agent-native 인프라
사람이 클릭하는 UI가 아니라 agent를 1차 사용자로
sensor와 actuator로 나누어 생각하기
MenuGen 배포가 어려웠던 이유
사고는 외주 줄 수 있어도 이해는 외주 줄 수 없다
MenuGen 결제 버그가 보여준 인간 판단의 자리
dim과 axis, reshape, permute, transpose, keepdim 같은 암기성 세부사항을 예로 듭니다. 하지만 근본은 사람이 알고 있어야 합니다.microGPT 프로젝트를 듭니다. 코드를 단순하게 만들려고 할 때 모델들이 힘들어한다는 것입니다. 이해가 병목이다
microGPT도 같은 성격의 산출물입니다. 정보를 이해로 바꾸는 교육적 장치입니다. 마무리
구분 항목 덜 희소해지는 것 코드 생성, API 기억, boilerplate, 초안, 반복적인 셋업 더 희소해지는 것 이해, taste, eval 설계, 보안, 시스템 경계, agent orchestration, 도메인별 피드백 루프 microGPT를 단순화하는 일에서 모델이 막히는 것도, MenuGen 결제 버그가 test를 통과해버리는 것도 모두 같은 축 위에 있습니다. References