https://youtu.be/96jN2OCOfLs?si=Lb2CEu7NThhoPw_B
Andrej Karpathy: From Vibe Coding to Agentic Engineering
Andrej Karpathy (co-founder of OpenAI, former head of AI at Tesla, and now founder of Eureka Labs) talks with Sequoia partner Stephanie Zhan at AI Ascent 202...
www.youtube.com
첫 번째 특별 게스트를 모시게 되어 정말 기쁩니다. 이분은 현대 AI를 구축하고 설명하며 때로는 그 이름을 다시 정의하는 데 기여해 온 분입니다. 이 사무실 바로 여기서 OpenAI를 공동 창립하는 데 도움을 주셨고 테슬라에서 오토파일럿이 실제로 작동하게 만든 장본인이기도 합니다. 또한 가장 복잡한 기술적 변화를 접근하기 쉽고 필연적인 것처럼 느끼게 만드는 드문 재능을 가지고 계시죠. 작년에 바이브 코딩이라는 용어를 만들어낸 것으로도 잘 알려져 있지만 최근 몇 달 사이에는 더욱 놀라운 말씀을 하셨습니다. 프로그래머로서 지금처럼 뒤처진다고 느낀 적이 없다는 것이었죠. 오늘 이야기는 여기서부터 시작하겠습니다. 안드레이 카파시 님 와주셔서 감사합니다.
네 안녕하세요. 시작하게 되어 기쁩니다.
불과 몇 달 전 프로그래머로서 지금처럼 뒤처진다고 느낀 적이 없다고 하셨는데요. 당신 같은 분이 그런 말씀을 하시다니 정말 놀랍습니다. 그 감정이 어떤 것이었는지 설명해 주실 수 있나요? 즐거움이었나요 아니면 불안함이었나요?
둘 다 섞여 있었습니다. 저도 여러분 중 많은 분처럼 지난 1년 동안 클로드나 코덱스 같은 에이전트 도구들을 사용해 왔습니다. 코드 조각을 짜는 데는 아주 유용했지만 가끔 실수를 하면 직접 수정해야 했죠. 그런데 작년 12월이 저에게는 명확한 전환점이었습니다. 휴가 기간이라 시간이 좀 더 있었는데 최신 모델들을 사용하면서 코드 뭉치들이 그냥 완벽하게 나오는 걸 발견했습니다. 더 많은 걸 요구해도 계속 잘 작동했죠. 마지막으로 코드를 직접 수정한 게 언제인지 기억이 안 날 정도였습니다. 시스템을 점점 더 신뢰하게 되었고 결국 계속해서 바이브 코딩을 하고 있는 저를 발견했습니다. 이건 정말 극적인 변화였습니다. 많은 사람이 작년에 챗GPT를 경험했지만 12월 이후의 변화는 근본적으로 다릅니다. 특히 에이전트 기반의 일관된 워크플로우가 실제로 작동하기 시작했다는 점이 그렇습니다. 그 깨달음 이후 저는 수많은 사이드 프로젝트를 진행하며 이 변화의 파급력을 지켜보고 있습니다.
LLM을 새로운 컴퓨터로 보는 관점에 대해서도 많이 말씀하셨죠. 단순히 더 나은 소프트웨어가 아니라 완전히 새로운 컴퓨팅 패러다임이라는 것인데요. 소프트웨어 1.0은 명시적인 규칙 2.0은 학습된 가중치였다면 3.0은 바로 이것이라고 하셨습니다. 만약 이것이 사실이라면 이를 믿는 팀은 무엇을 다르게 구축하게 될까요?
정확합니다. 소프트웨어 1.0에서는 코드를 직접 작성하고 2.0에서는 데이터셋을 만들고 신경망을 훈련시켜 프로그래밍합니다. 그리고 소프트웨어 3.0은 프로그래밍이 프롬프팅으로 변하는 단계입니다. 컨텍스트 윈도우 안에 있는 내용이 LLM이라는 해석기를 작동시키는 레버가 되는 것이죠. 오픈클락 설치를 예로 들어보겠습니다. 보통은 복잡한 쉘 스크립트를 실행해야 하고 다양한 플랫폼에 맞추다 보면 스크립트가 엄청나게 복잡해집니다. 하지만 소프트웨어 3.0 패러다임에서는 에이전트에게 텍스트 뭉치를 복사해서 붙여넣기만 하면 됩니다. 에이전트가 자체적인 지능을 가지고 환경을 파악하고 명령을 따르며 루프를 돌며 디버깅까지 수행해서 설치를 완료합니다. 훨씬 더 강력하죠. 제가 만든 메뉴젠 앱도 마찬가지입니다. 처음에는 사진을 업로드하면 메뉴를 렌더링하고 이미지를 생성하는 복잡한 코드를 직접 짰지만 소프트웨어 3.0 버전은 그냥 사진을 제미나이에게 주고 이걸 메뉴 위에 덮어씌워 줘라고 말하는 수준입니다. 신경망이 점점 더 많은 일을 처리하게 되면서 앱 자체가 존재할 필요가 없어지는 것이죠. 이제는 기존 패러다임의 속도를 높이는 수준을 넘어 이전에는 불가능했던 새로운 기회들이 열리고 있습니다.
검증 가능성에 대해서도 이야기해보고 싶습니다. AI가 출력을 검증할 수 있는 영역을 더 빠르고 쉽게 자동화할 것이라는 개념인데요. 이 프레임워크가 맞다면 사람들이 생각하는 것보다 훨씬 빠르게 변화할 업무나 직업은 무엇일까요?
전통적인 컴퓨터는 코드로 명시할 수 있는 것을 자동화하지만 최신 LLM은 검증할 수 있는 것을 자동화합니다. 모델들이 훈련되는 방식 때문인데 검증 가능한 도메인에서 능력이 최고조에 달했다가 그렇지 않은 영역에서는 정체되는 경향이 있습니다. 제가 검증 가능성에 대해 쓴 이유는 왜 이런 모델들의 능력이 들쭉날쭉한지 이해하기 위해서였습니다. 예를 들어 딸기라는 단어에 r이 몇 개 들어있는지 틀리던 모델이 10만 라인의 코드를 리팩토링하거나 제로데이 취약점을 찾아내기도 하죠. 하지만 세차장이 50미터 거리에 있는데 차를 몰고 갈지 걸어갈지 물으면 걸어가라고 답합니다. 차를 씻으러 가는 건데 말이죠. 이런 들쭉날쭉함은 우리가 모델을 도구로 대하고 루프 안에 머물러야 한다는 신호입니다. 오픈AI가 체스 데이터를 프리트레이닝 세트에 대량으로 넣었을 때 모델의 체스 실력이 급상승한 것처럼 우리는 모델이 어떤 데이터를 학습했는지에 따라 능력이 결정되는 환경에 있습니다.
검증 가능한 도메인에서 문제를 해결하려는 창업자들에게 조언을 해주신다면요?
검증 가능성은 현재 패러다임에서 문제를 해결 가능하게 만듭니다. 대량의 강화학습을 투입할 수 있기 때문이죠. 만약 여러분이 검증 가능한 환경에 있다면 직접 파인튜닝을 수행하여 큰 이점을 얻을 수 있습니다. 이는 단순히 모델이 주는 대로 쓰는 것을 넘어 직접 레버를 당겨 성능을 높일 수 있다는 뜻입니다.
작년에는 바이브 코딩을 말씀하셨고 지금은 에이전트 엔지니어링이라는 좀 더 진지한 단계에 와 있습니다. 이 둘의 차이는 무엇인가요?
바이브 코딩은 소프트웨어로 무엇을 할 수 있는지에 대한 바닥을 높여주는 것입니다. 누구나 무엇이든 코딩할 수 있게 되죠. 반면 에이전트 엔지니어링은 전문적인 소프트웨어의 품질 기준을 유지하는 것에 관한 것입니다. 바이브 코딩을 한다고 해서 보안 취약점을 만들어서는 안 되며 여전히 자신의 소프트웨어에 책임을 져야 합니다. 에이전트라는 강력하지만 때로는 불안정한 존재들을 어떻게 조율해서 품질을 희생하지 않고 속도를 높일 것인가의 문제입니다. 저는 이것이 하나의 엔지니어링 규율이 될 것이라고 봅니다. 이전에는 10배 뛰어난 엔지니어를 이야기했다면 이제는 그 격차가 훨씬 더 커질 것입니다.
세대마다 챗GPT를 사용하는 방식이 다르다는 이야기가 있습니다. 코딩에서도 비슷한 현상이 있을까요?
도구의 기능을 최대한 활용하고 자신의 설정에 투자하는 것이 중요합니다. 빔이나 VS Code를 쓰던 것처럼 이제는 클로드나 코덱스를 얼마나 잘 다루느냐의 싸움입니다. 채용 방식도 바뀌어야 합니다. 퍼즐 맞추기식 시험이 아니라 에이전트용 트위터 클론을 만들고 보안까지 완벽하게 구축해 보라는 식의 큰 프로젝트를 주고 어떻게 구현하는지 지켜봐야 합니다.
에이전트가 더 많은 일을 하게 될 때 인간의 어떤 기술이 더 가치 있어질까요?
미학 판단력 취향 그리고 감독 능력이 여전히 중요합니다. 에이전트는 일종의 인턴 같은 존재입니다. 전체적인 설계와 계획은 인간이 맡아야 합니다. 예를 들어 데이터 구조를 설계할 때 에이전트는 세부적인 API 사용법은 잘 알지만 왜 이 구조가 필요한지에 대한 근본적인 이해는 부족할 수 있습니다. 인간은 큰 틀에서의 설계와 디자인이 제대로 작동하는지 확인하는 역할을 하게 될 것입니다.
마지막으로 교육에 대해 묻고 싶습니다. 지능이 저렴해지는 시대에 깊이 있게 배울 가치가 있는 것은 무엇일까요?
최근 제 마음을 사로잡은 문구가 있습니다. 생각은 아웃소싱할 수 있지만 이해는 아웃소싱할 수 없다는 말입니다. 우리는 여전히 시스템의 일부이며 무엇을 왜 만들어야 하는지 결정하기 위해 정보는 우리 뇌로 들어와야 합니다. 저는 LLM을 이해를 돕는 도구로 활용하는 것에 매우 열광하고 있습니다. 기사를 읽을 때 나만의 위키를 구축하고 질문을 던지며 통찰을 얻는 식이죠. 결국 LLM은 이해를 증진시키기 위한 강력한 도구이며 그 이해의 주체는 여전히 인간입니다.
몇 년 후 우리가 에이전트에게 완전히 맡기고 루프에서 벗어나게 될지 정말 궁금하네요. 오늘 함께해주셔서 감사합니다 안드레이.
감사합니다.
==============
◦ We are excited to welcome our first special guest who has helped build modern AI then explain modern AI and occasionally rename modern AI. 그는 현대 AI를 구축하고 설명하며 때때로 현대 AI에 새로운 이름을 부여하는 데 도움을 준 첫 번째 특별한 손님을 환영하게 되어 기쁩니다.
He co founded OpenAI inside this very office and was the one who got Autopilot working at Tesla back in the day. 그는 이 사무실 안에서 OpenAI를 공동 창립했고 예전에 Tesla에서 Autopilot을 작동시킨 사람이었습니다.
He possesses a rare gift of making the most complex technical shifts feel both accessible and inevitable. 그는 가장 복잡한 기술적 변화들을 누구나 접근할 수 있고 피할 수 없는 것으로 느끼게 만드는 드문 재능을 가지고 있습니다.
You all know him for coining the term vibe coding last year but in recent months he said something even more startling. 여러분 모두는 그가 작년에 바이브 코딩이라는 용어를 만든 것으로 알고 있지만 최근 몇 달 동안 그는 더 놀라운 말을 했습니다.
He has never felt more behind as a programmer. 그는 프로그래머로서 그 어느 때보다 뒤처진 느낌을 받은 적이 없다고 말했습니다.
That is where we begin today. 오늘 우리는 바로 그 지점에서 시작합니다.
Thank you Andre for joining us. 참여해 주셔서 감사합니다 Andre.
◦ Yeah hello I am excited to be here and to kick us off. 네 안녕하세요 여기 와서 대화를 시작하게 되어 기쁩니다.
Okay so just a couple of months ago you said you have never felt more behind as a programmer. 좋아요 그래서 불과 몇 달 전 당신은 프로그래머로서 그 어느 때보다 뒤처진 느낌을 받은 적이 없다고 말했습니다.
That is startling to hear from you of all people. 당신에게서 그런 말을 듣는 것은 정말 놀랍습니다.
Can you help us unpack that feeling. 그 감정을 조금 풀어서 설명해 줄 수 있나요.
Was it exhilarating or unsettling. 그것이 흥미진진한 것이었나요 아니면 불안한 것이었나요.
◦ Yeah it was a mixture of both for sure. 네 확실히 둘 다 섞여 있었습니다.
First of all like many of you I have been using agentic tools such as Alpha code adjacent systems for a while maybe over the last year since they came out. 우선 많은 분들처럼 저도 지난 1년 정도 에이전트 도구들 특히 Alpha code와 유사한 시스템들을 사용해 왔습니다.
They were very good at producing chunks of code. 그 도구들은 코드의 상당한 부분을 잘 생성해 주었습니다.
Sometimes they would make mistakes and you had to edit the output and that was somewhat helpful. 가끔 실수를 해서 출력을 편집해야 했고 그 정도는 도움이 되었습니다.
Then December became a clear turning point for me. 그러다가 12월이 저에게 명확한 전환점이 되었습니다.
I was on a break so I had a bit more time and I think many other people experienced something similar. 저는 휴식 중이어서 시간이 조금 더 있었고 많은 다른 사람들도 비슷한 경험을 했을 것이라고 생각합니다.
I started to notice that with the latest models the chunks just came out fine without issues. 저는 최신 모델들을 사용하면서 코드 덩어리들이 그냥 문제없이 잘 나오는 것을 알아차리기 시작했습니다.
I kept asking for more and they just kept coming out fine. 더 많이 요청했는데도 계속해서 잘 나왔습니다.
I cannot even remember the last time I had to correct the output. 마지막으로 출력을 수정한 때를 기억할 수 없을 정도였습니다.
I simply trusted the system more and more. 저는 그저 그 시스템을 점점 더 신뢰하게 되었습니다.
And then I realized I was vibe coding. 그리고 마침내 제가 바이브 코딩을 하고 있다는 것을 깨달았습니다.
◦ It was a very stark transition. 그것은 매우 극명한 전환이었습니다.
I tried to emphasize this on X because many people last year experienced AI mainly as a ChatGPT adjacent tool. 저는 이것을 X에서 강조하려고 노력했습니다. 왜냐하면 많은 사람들이 작년에 AI를 주로 ChatGPT와 유사한 도구로 경험했기 때문입니다.
But you really had to look again starting from December because things changed fundamentally especially with the emergence of coherent agentic workflows that actually started to work reliably. 그러나 12월부터 다시 살펴봐야 했습니다. 사물들이 근본적으로 변했기 때문입니다. 특히 실제로 안정적으로 작동하기 시작한 일관된 에이전트 워크플로우 때문이었습니다.
That realization sent me down the entire rabbit hole of infinite side projects. 그 깨달음은 저를 무한한 사이드 프로젝트의 깊은 토끼굴 속으로 빠뜨렸습니다.
My side projects folder became extremely full with all kinds of random experiments and I have been coding almost nonstop. 제 사이드 프로젝트 폴더는 온갖 무작위 실험들로 가득 차게 되었고 저는 거의 쉬지 않고 코딩을 하고 있습니다.
That shift really happened around December and I have been exploring its repercussions ever since. 그 변화는 정말 12월쯤에 일어났고 저는 그 이후로 그 영향들을 계속 탐구하고 있습니다.
◦ You have spoken a great deal about the idea of LLMs as a new kind of computer. 당신은 LLMs를 새로운 종류의 컴퓨터로 보는 아이디어에 대해 많이 이야기해 왔습니다.
It is not merely better software but an entirely new computing paradigm. 그것은 단순히 더 나은 소프트웨어가 아니라 완전히 새로운 컴퓨팅 패러다임입니다.
Software 1.0 was built on explicit rules. 소프트웨어 1.0은 명시적인 규칙들 위에 구축되었습니다.
Software 2.0 was built on learned weights inside neural networks. 소프트웨어 2.0은 신경망 안의 학습된 가중치들 위에 구축되었습니다.
Software 3.0 is what we are experiencing now. 소프트웨어 3.0은 바로 지금 우리가 경험하고 있는 것입니다.
If this is truly the case what does a team do differently the moment they actually internalize this truth. 만약 이것이 진실이라면 팀은 이 진실을 실제로 내면화하는 순간 무엇을 다르게 하게 될까요.
◦ Right exactly. 맞습니다 정확히 그렇습니다.
In Software 1.0 I write code directly. 소프트웨어 1.0에서는 제가 직접 코드를 작성합니다.
In Software 2.0 I program by creating datasets and training neural networks so the act of programming becomes arranging datasets along with objectives and network architectures. 소프트웨어 2.0에서는 데이터셋을 만들고 신경망을 훈련함으로써 프로그래밍을 합니다. 그래서 프로그래밍 행위는 데이터셋을 배열하고 목표와 네트워크 구조를 다루는 것이 됩니다.
And then what happened is that with LLMs you can now describe what you want in natural language and the system generates working code for you. 그리고 나서 일어난 일은 LLMs와 함께 이제 자연어로 원하는 것을 설명하면 시스템이 작동하는 코드를 생성해 준다는 것입니다.
This is Software 3.0 where the LLM itself functions as the new computer that understands intent and produces the implementation. 이것이 소프트웨어 3.0으로 LLM 자체가 의도를 이해하고 구현을 생산하는 새로운 컴퓨터 역할을 수행합니다.
You program by prompting or by orchestrating chains of agents rather than writing every line yourself. 당신은 모든 줄을 직접 쓰는 대신 프롬프팅을 하거나 에이전트들의 연쇄를 조율함으로써 프로그래밍을 합니다.
◦ Agents now serve as the new installer for software projects. 에이전트들은 이제 소프트웨어 프로젝트를 위한 새로운 설치 프로그램 역할을 수행합니다.
You simply describe the desired application and the agent sets up the environment installs all necessary dependencies and scaffolds the initial codebase. 당신은 원하는 애플리케이션을 설명하기만 하면 에이전트가 환경을 구성하고 필요한 모든 의존성을 설치하며 초기 코드베이스를 구축합니다.
This completely changes how new projects begin compared to traditional workflows that required manual setup from scratch. 이것은 처음부터 수동으로 설정해야 했던 전통적인 워크플로우와 비교할 때 새로운 프로젝트가 시작되는 방식을 완전히 바꿉니다.
Menu generation versus raw prompts represents another practical evolution in how we interact with these systems. 메뉴 생성 대 원시 프롬프트는 우리가 이러한 시스템과 상호작용하는 방식의 또 다른 실질적인 진화를 나타냅니다.
Instead of writing long unstructured prompts you can work with structured interfaces that the agent dynamically provides. 긴 비구조화된 프롬프트를 작성하는 대신 에이전트가 동적으로 제공하는 구조화된 인터페이스를 활용할 수 있습니다.
◦ By 2026 it has become obvious that agentic workflows are turning into the default approach for professional software development. 2026년이 되면서 에이전트 워크플로우가 전문 소프트웨어 개발의 기본 접근 방식으로 자리 잡고 있다는 것이 명백해졌습니다.
Verifiability remains a central challenge because LLMs possess jagged skills. 검증 가능성은 여전히 중심적인 도전 과제로 남아 있습니다. 왜냐하면 LLMs는 들쭉날쭉한 능력을 가지고 있기 때문입니다.
They excel in certain areas yet can fail surprisingly in others. 그들은 특정 영역에서는 뛰어나지만 다른 영역에서는 놀랍게도 실패할 수 있습니다.
You cannot blindly trust every output they produce. 당신은 그들이 생산하는 모든 출력을 맹목적으로 신뢰할 수 없습니다.
This is precisely why agentic engineering places heavy emphasis on supervision careful inspection thorough testing and continuous evaluation loops. 이것이 바로 에이전트 공학이 감독과 세심한 검사 철저한 테스트 그리고 지속적인 평가 루프를 강하게 강조하는 이유입니다.
◦ We should think of LLMs not as animals that we train but as ghosts that we summon. 우리는 LLMs를 우리가 훈련하는 동물이 아니라 우리가 소환하는 유령으로 생각해야 합니다.
They are jagged statistical and summoned entities that exist in a space between order and chaos. 그들은 질서와 혼돈 사이의 공간에 존재하는 들쭉날쭉하고 통계적이며 소환된 존재들입니다.
Directing them effectively requires a new form of taste judgment and deep understanding. 그들을 효과적으로 지휘하기 위해서는 새로운 형태의 취향과 판단력 그리고 깊은 이해가 필요합니다.
You can outsource a great deal of your thinking to these systems. 당신은 이러한 시스템들에게 생각의 상당 부분을 아웃소싱할 수 있습니다.
Yet you can never outsource your own understanding and responsibility for the final result. 그러나 최종 결과에 대한 당신 자신의 이해와 책임은 절대로 아웃소싱할 수 없습니다.
◦ Vibe coding raised the floor by allowing almost anyone to create software simply by describing what they want. 바이브 코딩은 거의 누구나 원하는 것을 설명하는 것만으로 소프트웨어를 만들 수 있게 함으로써 바닥을 높였습니다.
It made software creation more accessible and fun especially for prototypes and personal tools. 그것은 특히 프로토타입과 개인 도구를 위해 소프트웨어 생성을 더 접근 가능하고 즐거운 것으로 만들었습니다.
Agentic engineering raises the ceiling by introducing the professional discipline required to coordinate fallible agents while preserving correctness security taste and long term maintainability. 에이전트 공학은 오류가 있을 수 있는 에이전트들을 조정하면서 정확성 보안 취향 그리고 장기적인 유지보수성을 보존하는 데 필요한 전문적인 규율을 도입함으로써 천장을 높입니다.
Vibe coding works beautifully for quick experiments. 바이브 코딩은 빠른 실험에는 아름답게 작동합니다.
Agentic engineering is what serious teams and production systems actually need. 에이전트 공학은 진지한 팀과 프로덕션 시스템이 실제로 필요로 하는 것입니다.
The agentic engineer never blindly accepts generated code. 에이전트 엔지니어는 생성된 코드를 맹목적으로 받아들이지 않습니다.
They design clear specifications supervise plans inspect every diff write rigorous tests create evaluation loops manage permissions isolate worktrees and uphold the highest standards of quality. 그들은 명확한 사양을 설계하고 계획을 감독하며 모든 차이를 검사하고 엄격한 테스트를 작성하며 평가 루프를 만들고 권한을 관리하며 작업 트리를 격리하고 최고 수준의 품질을 유지합니다.
This is the serious craft that sits on top of the initial vibe. 이것이 초기 바이브 위에 자리 잡은 진지한 장인 정신입니다.
◦ Agents are now everywhere and they continue to learn and improve rapidly. 에이전트들은 이제 어디에나 존재하며 계속해서 빠르게 학습하고 개선되고 있습니다.
The modern workflow consists of constant thoughtful interaction with these agents rather than solitary line by line coding. 현대적인 워크플로우는 고독한 줄 단위 코딩 대신 이러한 에이전트들과의 지속적이고 사려 깊은 상호작용으로 구성됩니다.
As founders and engineers we must develop entirely new skills in directing orchestrating and verifying these systems. 창립자와 엔지니어로서 우리는 이러한 시스템들을 지휘하고 조율하며 검증하는 완전히 새로운 기술을 개발해야 합니다.
The future belongs to those who can orchestrate intelligence at scale while maintaining deep human judgment over what truly matters. 미래는 규모에 맞춰 지능을 조율할 수 있으면서도 무엇이 진정으로 중요한지에 대한 깊은 인간적 판단력을 유지하는 사람들에게 속합니다.
This paradigm shift is already reshaping what it means to be a programmer and to build meaningful technology in the age of Software 3.0. 이 패러다임 전환은 이미 프로그래머가 된다는 것과 소프트웨어 3.0 시대에 의미 있는 기술을 구축한다는 것의 의미를 재구성하고 있습니다.
◦ This paradigm shift is already reshaping what it means to be a programmer and to build meaningful technology in the age of Software 3.0. 이 패러다임 전환은 이미 프로그래머가 된다는 것과 소프트웨어 3.0 시대에 의미 있는 기술을 구축한다는 것의 의미를 재구성하고 있습니다.
The jagged nature of intelligence means some tasks fall perfectly on the models rails while others remain stubbornly off them. 지능의 들쭉날쭉한 본성은 일부 작업이 모델의 레일에 완벽하게 맞는 반면 다른 작업은 완고하게 벗어나 있다는 것을 의미합니다.
Verifiability and training attention form the two main axes that determine where automation succeeds first. 검증 가능성과 훈련 주의력이 자동화가 먼저 성공하는 곳을 결정하는 두 가지 주요 축을 형성합니다.
◦ For founders the practical question becomes whether your core problem sits on those rails where the model excels. 창립자들에게 실질적인 질문은 당신의 핵심 문제가 모델이 뛰어난 그 레일 위에 있는지 여부가 됩니다.
If it does you can move extremely fast by leaning into agentic workflows and letting the ghosts handle large portions of the implementation. 만약 그렇다면 에이전트 워크플로우에 의지하고 유령들이 구현의 큰 부분을 처리하게 함으로써 극도로 빠르게 움직일 수 있습니다.
If it does not you must design careful human in the loop processes or choose a different problem altogether because forcing the model off its rails leads to fragile unreliable systems. 그렇지 않다면 신중한 인간 참여 루프 프로세스를 설계하거나 아예 다른 문제를 선택해야 합니다. 왜냐하면 모델을 레일에서 벗어나게 강요하면 취약하고 신뢰할 수 없는 시스템으로 이어지기 때문입니다.
Automation should target areas of high verifiability first because those are where the summoned entities can be trusted with less constant oversight. 자동화는 높은 검증 가능성 영역을 먼저 목표로 삼아야 합니다. 왜냐하면 그곳이 소환된 존재들을 더 적은 지속적 감독으로 신뢰할 수 있는 곳이기 때문입니다.
◦ The old software stack often served as scaffolding around transformations that the model can now perform directly without all the intermediate layers. 오래된 소프트웨어 스택은 종종 모델이 이제 중간 계층들 없이 직접 수행할 수 있는 변환들 주위의 비계 역할을 했습니다.
This means artificial intelligence is not simply a faster way to build the old applications we already knew. 이것은 인공 지능이 우리가 이미 알고 있던 오래된 애플리케이션들을 더 빠르게 구축하는 방법이 아니라는 것을 의미합니다.
Instead entirely new categories of software and services become possible when you design workflows natively for agents rather than for human users clicking through menus and settings pages. 대신 에이전트들을 위해 네이티브하게 워크플로우를 설계할 때 인간 사용자가 메뉴와 설정 페이지를 클릭하는 대신 완전히 새로운 범주의 소프트웨어와 서비스가 가능해집니다.
The founder opportunity lies in building the infrastructure that lets agents execute reliably across APIs knowledge bases and reasoning frameworks without constant human translation. 창립자의 기회는 에이전트들이 지속적인 인간 번역 없이 API 지식 베이스 그리고 추론 프레임워크 전반에 걸쳐 안정적으로 실행할 수 있게 하는 인프라를 구축하는 데 있습니다.
◦ Even as agents take over more of the execution the irreplaceable human role remains in setting direction applying taste and maintaining living understanding of why something matters in the larger context. 에이전트들이 실행의 더 많은 부분을 차지하더라도 방향을 설정하고 취향을 적용하며 무언가가 더 큰 맥락에서 왜 중요한지에 대한 살아있는 이해를 유지하는 대체 불가능한 인간의 역할은 남아 있습니다.
You can outsource a great deal of thinking to these statistical ghosts yet the final judgment on value correctness and long term consequences stays with the one who summons and directs them. 당신은 이러한 통계적 유령들에게 생각의 상당 부분을 아웃소싱할 수 있습니다. 그러나 가치 정확성 그리고 장기적 결과에 대한 최종 판단은 그들을 소환하고 지휘하는 사람에게 남아 있습니다.
This is why agentic engineering emphasizes not just speed but the disciplined preservation of quality security and maintainability across every change and every generated artifact. 이것이 에이전트 공학이 단순한 속도가 아니라 모든 변경과 모든 생성된 인공물에 걸쳐 품질 보안 그리고 유지보수성의 규율 있는 보존을 강조하는 이유입니다.
The ghosts are powerful and increasingly coherent yet they remain jagged and fundamentally statistical in their nature. 유령들은 강력하고 점점 더 일관되지만 그들의 본성에서 여전히 들쭉날쭉하고 근본적으로 통계적입니다.
Only through careful orchestration continuous evaluation and human taste do they produce results worthy of professional production systems that real users and businesses can depend on. 신중한 조율 지속적인 평가 그리고 인간의 취향을 통해서만 그들은 실제 사용자와 비즈니스가 의존할 수 있는 전문 프로덕션 시스템에 걸맞은 결과를 생산합니다.
◦ The feeling of being behind is not a personal failing or sign of inadequacy but a natural signal that the frontier of what intelligence can do is moving faster than any single mind can track in isolation. 뒤처진 느낌은 개인적인 실패나 부족함의 표시가 아니라 지능이 할 수 있는 것의 프론티어가 어떤 단일한 마음도 고립되어 추적할 수 없을 정도로 빠르게 움직이고 있다는 자연스러운 신호입니다.
It invites every engineer and founder to step into the new discipline of agentic engineering where we evolve from lone writers of syntax into conductors and curators of summoned intelligence. 그것은 모든 엔지니어와 창립자가 구문의 고독한 작성자에서 소환된 지능의 지휘자이자 큐레이터로 진화하는 새로운 규율인 에이전트 공학 안으로 들어서도록 초대합니다.
In this larger arc of intelligence augmentation across human history the human contribution evolves from producing every artifact by hand to curating the conditions under which powerful yet imperfect entities can create reliably and at scale. 인간 역사 전반에 걸친 지능 증강의 이 더 큰 흐름 속에서 인간의 기여는 모든 인공물을 손으로 생산하는 것에서 강력하지만 불완전한 존재들이 안정적으로 그리고 규모 있게 창조할 수 있는 조건을 큐레이팅하는 것으로 진화합니다.
The universe of code and creation continues to unfold in ways that reward those who learn to work with these jagged statistical ghosts rather than against them. 코드와 창조의 우주는 이러한 들쭉날쭉한 통계적 유령들과 함께 일하는 법을 배우는 사람들에게 보상을 주는 방식으로 계속 펼쳐지고 있습니다.
Those who develop the taste judgment and orchestration skills will not only keep up but will shape what comes next in the ongoing story of minds extending minds.
++++++
**00:02**
1. **We're so excited for our very first special guest.**
첫 번째 특별 게스트를 모시게 되어 정말 기쁩니다.
2. **He has helped build modern AI, then explain modern AI, and then occasionally rename modern AI.**
그는 현대 AI를 만드는 데 기여했고, 또 그것을 설명해 왔으며, 때로는 현대 AI의 이름까지 다시 붙여 왔습니다.
3. **He actually helped co-found OpenAI right inside of this office, was the one who actually got autopilot working at Tesla back in the day.**
그는 바로 이 사무실에서 OpenAI를 공동 창립하는 데 참여했고, 예전에는 테슬라에서 오토파일럿이 작동하도록 만든 사람이기도 합니다.
4. **And he has a rare gift of making the most complex technical shifts feel both accessible and inevitable.**
그는 가장 복잡한 기술적 변화를 누구나 이해할 수 있고 또 필연적인 것처럼 느끼게 만드는 드문 재능을 가지고 있습니다.
5. **You all know him for having coined the term vibe coding last year, but just in the last few months he said something even more startling, that he's never felt more behind as a programmer.**
여러분은 그가 작년에 “vibe coding”이라는 용어를 만든 사람으로 알고 계실 텐데, 그런데 지난 몇 달 동안 그는 더 놀라운 말을 했습니다. 프로그래머로서 이렇게 뒤처진다고 느낀 적이 없다고 말한 것입니다.
6. **That's where we're starting today.**
오늘은 바로 그 지점에서 시작하겠습니다.
7. **Thank you, Andre, for joining us.**
함께해 주셔서 감사합니다, 안드레.
8. **Yeah, hello. I'm excited to be here and to kick us off.**
네, 안녕하세요. 이 자리에 오게 되어 기쁘고, 시작하게 되어 설렙니다.
9. **Okay, so just a couple months ago you said that you've never felt more behind as a programmer.**
좋습니다. 몇 달 전, 당신은 프로그래머로서 이렇게 뒤처진다고 느낀 적이 없다고 말했죠.
10. **That's startling to hear from you of all people.**
당신 같은 분에게서 그런 말을 들으니 정말 놀랍습니다.
11. **Um can you help us unpack that?**
그 말을 좀 풀어서 설명해 주실 수 있을까요?
12. **Was that feeling exhilarating or unsettling?**
그 느낌은 짜릿한 쪽이었나요, 아니면 불안한 쪽이었나요?
---
**01:00**
13. **Uh yeah, mixture of both for sure.**
네, 분명히 두 가지가 섞여 있었습니다.
14. **Uh well, first of all, um I guess like as many of you I've been using agentic tools like Alpha code adjacent things uh for a while, maybe over the last year as it came out.**
우선, 여러분 중 많은 분들과 마찬가지로 저도 지난 1년 정도 동안 에이전트형 도구, 예를 들면 알파코드에 가까운 것들을 꽤 오래 써 왔습니다.
15. **And it was very good at, you know, chunks of code.**
그리고 그런 도구들은 코드의 일부 덩어리를 처리하는 데는 매우 뛰어났습니다.
16. **And sometimes it would mess up and you have to edit them, and it was kind of helpful.**
가끔은 실수를 해서 제가 직접 수정해야 했지만, 그래도 꽤 도움이 되었습니다.
17. **And then I would say December was this clear point where for me uh I was on a break, so I had a bit more time.**
그리고 제게는 12월이 분명한 전환점이었습니다. 휴식 중이어서 시간이 좀 더 있었기 때문입니다.
18. **I think many other people were similar.**
다른 많은 사람들도 비슷했을 거라고 생각합니다.
19. **And uh I just start to notice that with the latest models uh the chunks just came out fine.**
그런데 최신 모델에서는 코드 조각들이 그냥 잘 나왔다는 걸 느끼기 시작했습니다.
20. **And then I kept asking for more, and just came out fine.**
더 많은 것을 계속 요청해도, 역시 잘 나왔습니다.
21. **And then I can't remember the last time I corrected it.**
그리고 언제 마지막으로 제가 그것을 수정했는지 기억나지 않을 정도가 되었습니다.
22. **And then I was I just uh you know, trusted the system more and more.**
그러다 보니 저는 시스템을 점점 더 신뢰하게 되었습니다.
23. **And then I was vibe coding.**
그러고 나서 저는 vibe coding을 하고 있었습니다.
24. **>> >> And uh so it was kind of a I do think that it was a very stark transition.**
그래서, 제 생각에는 아주 급격한 전환이었습니다.
25. **I think that a lot of people actually I tried to I tried to stress this on uh Twitter and or X because I think a lot of people experienced AI uh last year as ChatGPT adjacent thing, uh but you really had to look again, and you had to look as of December uh because things have changed fundamentally and uh especially on this like agentic coherent workflow that really started to actually work.**
사실 많은 사람들이 작년에 AI를 ChatGPT 비슷한 것 정도로만 경험했다고 생각해서, 저는 이 점을 트위터나 X에서 강조하려고 했습니다. 하지만 정말 다시 봐야 했고, 특히 12월 시점부터는 다시 봐야 했습니다. 왜냐하면 상황이 근본적으로 바뀌었고, 특히 에이전트형의 일관된 워크플로우가 실제로 작동하기 시작했기 때문입니다.
26. **Um and so I would say that um yeah, it was just that realization that really uh had me um go down the whole rabbit hole of just, you know, infinity side project.**
그래서 제게는 그 깨달음이, 말하자면 무한히 이어지는 사이드 프로젝트의 토끼굴로 들어가게 만든 계기였습니다.
27. **Uh my side projects folder is like extremely full with lots of random things and uh just I've been coding all the time.**
제 사이드 프로젝트 폴더는 정말 온갖 잡다한 것들로 가득 차 있고, 저는 그냥 계속 코딩만 하고 있습니다.
28. **Uh so uh yeah, that kind of happened in December, I would say.**
네, 그런 일이 12월에 일어났다고 말할 수 있겠습니다.
29. **And I was looking at the repercussions of that since.**
그리고 그 이후로 저는 그 파급효과를 계속 보고 있었습니다.
30. **Um you've talked a lot about this idea of LLMs as a new computer.**
당신은 LLM을 새로운 컴퓨터로 보는 개념에 대해 많이 이야기해 왔습니다.
31. **Um that it isn't just better software, it's a whole new computing paradigm.**
그것은 단순히 더 나은 소프트웨어가 아니라, 완전히 새로운 컴퓨팅 패러다임이라는 것이죠.
32. **And um software 1.0 was explicit rules, software 2.0 was learned weights, software 3.0 is this.**
소프트웨어 1.0은 명시적인 규칙이었고, 소프트웨어 2.0은 학습된 가중치였으며, 소프트웨어 3.0은 바로 이것이라는 뜻입니다.
33. **Um if that's actually true, what does a team build differently the day they actually believe this?**
만약 그 말이 사실이라면, 팀은 그걸 진심으로 믿는 순간 무엇을 다르게 만들어야 할까요?
34. **Right.**
그렇죠.
35. **So uh yeah, exactly.**
네, 정확합니다.
36. **So software 1.0 I'm writing code, software 2.0 I'm actually programming by creating data sets and training uh training neural networks.**
소프트웨어 1.0에서는 제가 코드를 쓰고, 소프트웨어 2.0에서는 데이터셋을 만들고 신경망을 훈련시키는 방식으로 프로그래밍을 합니다.
37. **So the programming is kind of like arranging data sets and maybe some objectives and neural network architectures.**
즉 프로그래밍은 데이터셋을 배치하고, 어떤 목표와 신경망 구조를 설계하는 일에 가깝습니다.
38. **And then what happened is that basically if you train one of these GPT models or LLMs on a sufficiently large set of tasks implicit basically implicitly because by training on the internet you have to multitask all the things that are in the data set.**
그리고 무슨 일이 생기냐면, GPT 모델이나 LLM을 충분히 큰 작업 집합으로 훈련시키면, 인터넷 전체를 학습하는 과정에서 데이터셋에 있는 모든 것을 사실상 멀티태스킹하게 됩니다.
39. **Uh these actually become kind of like a programmable computer in a certain sense.**
그러면 이것들은 어떤 의미에서는 프로그래밍 가능한 컴퓨터처럼 됩니다.
40. **So software 3.0 is kind of about uh you know, your programming now turns to prompting and what's in the context window is your lever over the interpreter that is the LLM that is kind of like interpreting your context and uh performing computation in the digital digital information space.**
그래서 소프트웨어 3.0은 이제 프로그래밍이 프롬프트 작성으로 바뀌고, 컨텍스트 윈도우 안에 있는 것이 LLM이라는 인터프리터를 조종하는 지렛대가 된다는 뜻입니다. LLM은 당신의 컨텍스트를 해석하고 디지털 정보 공간에서 연산을 수행하는 존재와 비슷합니다.
41. **So I guess um yeah, that's kind of the transition and I think there's a few examples of that really drove it home for me and maybe that might be instructive.**
그래서 이런 것이 전환의 핵심이라고 생각하고, 저에게 그걸 아주 분명하게 보여준 몇 가지 예가 있습니다. 아마도 그 예들이 도움이 될 수 있을 것입니다.
42. **Uh so for example, when you when Open Claw came out when you want to install Open Claw, you would expect that normally this is a bash bash script like a shell script.**
예를 들어, OpenClaw가 나왔을 때 설치하려면 보통은 bash 스크립트, 즉 셸 스크립트가 있을 거라고 생각하게 됩니다.
43. **So, run the shell script to run uh to install OpenClaw.**
그러니까 셸 스크립트를 실행해서 OpenClaw를 설치하는 식입니다.
44. **Um but the thing is that in order to target lots of different platforms and lots of different types of computers you might run an OpenClaw, uh this these shell scripts usually ballooned up and become extremely complex.**
그런데 다양한 플랫폼과 다양한 종류의 컴퓨터를 지원하려면, 이런 셸 스크립트는 보통 점점 비대해지고 매우 복잡해집니다.
45. **But the thing is you're still stuck in a software 1.0 universe of wanting to write the code.**
하지만 문제는 여전히 코드를 직접 쓰려는 소프트웨어 1.0의 세계에 머물러 있다는 점입니다.
46. **And actually the OpenClaw installation is a is a copy-paste of a bunch of text that you're supposed to give to your agent.**
사실 OpenClaw 설치는 에이전트에게 넘겨줄 몇 줄의 텍스트를 복사해 붙여넣는 일에 가깝습니다.
47. **Uh so, basically it's it's a little skill of uh you know, copy-paste this and give it to your agent and it will install OpenClaw.**
즉, “이걸 복사해서 에이전트에게 주면 OpenClaw를 설치해 준다”는 작은 기술입니다.
48. **And the reason this is a lot more powerful is you're working now in the software 3.0 paradigm where you don't have to precisely uh spell out, you know, all the individual details of that setup.**
이것이 훨씬 강력한 이유는, 이제 소프트웨어 3.0 패러다임에서 작업하기 때문에 설정의 모든 세부사항을 일일이 정확히 적어 줄 필요가 없기 때문입니다.
49. **The agent has its own intelligence that it packages up and then it kind of like follows the instructions and it looks at your environment, your computer, and it kind of like performs intelligent actions to make things work and debugs things in the loop.**
에이전트는 자체적인 지능을 가지고 있어서 그것을 활용하고, 지시를 따르며, 당신의 환경과 컴퓨터를 살펴보고, 일을 작동시키기 위해 지능적인 행동을 수행하며, 그 과정에서 디버깅도 합니다.
50. **And it's just like so much more powerful, right?**
그리고 이것은 훨씬 더 강력합니다, 그렇죠?
51. **So, I think that's a very different kind of like way of thinking about it.**
그래서 저는 이것이 완전히 다른 방식의 사고라고 생각합니다.
52. **It's just like, what is the piece of text to copy-paste to your agent?**
핵심은 “에이전트에게 복사해 붙여넣을 텍스트 조각이 무엇인가?”입니다.
53. **That's the programming paradigm now.**
지금의 프로그래밍 패러다임은 바로 그것입니다.
54. **I think one more maybe uh example that comes to mind that is even more extreme than that is when I was building um MenuGen.**
그보다 더 극단적인 예로 떠오르는 것이 하나 더 있는데, 제가 MenuGen을 만들 때였습니다.
55. **So, MenuGen is this idea where you um you come to a restaurant, they give you a menu, there's no pictures usually, so I don't know what any of these things are.**
MenuGen은 이런 아이디어입니다. 식당에 가면 메뉴를 받는데 보통 사진이 없어서, 저는 그게 무엇인지 잘 모릅니다.
56. **Uh usually I like 30% of the things I don't have no idea what they are, 50%.**
보통은 음식의 30% 정도는 전혀 뭔지 모르겠고, 50%는 아예 감이 안 옵니다.
57. **So, I wanted to take a photo of the restaurant menu and to get pictures of what those things might look like in a generic sense.**
그래서 식당 메뉴를 사진으로 찍고, 각 항목이 대체로 어떻게 생겼을지 보여 주고 싶었습니다.
58. **And so, I built I built coded this app that basically lets you upload a photo and it does all this stuff and it runs on Vercel and uh it basically re-renders the menu and it gives you like all the items and it gives you a picture that it uses an image um you know, generator uh for to basically OCR all the different titles, uh use the image generator to get pictures of them and then shows it to you.**
그래서 저는 사진을 업로드하면 이런저런 처리를 하고 Vercel에서 실행되는 앱을 코딩했습니다. 이 앱은 메뉴를 다시 렌더링하고 모든 항목을 보여 주며, 이미지 생성기를 사용해 각 항목의 제목을 OCR로 읽고, 이미지 생성기로 그 항목들의 사진을 만들어 보여 줍니다.
59. **And then I saw the software 3.0 version of this, which is which blew my mind, which is literally just take your photo, give it to Gemini, and say use Nano Banana to overlay the the things onto the menu."**
그런데 저는 이것의 소프트웨어 3.0 버전을 보게 되었고, 정말 충격적이었습니다. 그냥 사진을 찍어서 Gemini에 넣고, “Nano Banana를 사용해서 메뉴 위에 해당 항목들을 덧씌워라”라고 하면 되는 것이었습니다.
60. **Uh Uh and Nana Banana basically returned an image that is exactly the picture of the menu that I took, but it actually put into the pixels, it rendered the different things in the menu.**
그러자 Nano Banana는 제가 찍은 메뉴 사진과 정확히 같은 이미지를 돌려주면서, 픽셀 안에 실제로 각 항목을 렌더링해 넣었습니다.
61. **And this blew my mind because actually all of my menu gen is spurious.**
그리고 이게 저를 완전히 놀라게 했습니다. 왜냐하면 사실 제 MenuGen은 전부 군더더기였기 때문입니다.
62. **It's working in the old paradigm that app shouldn't exist.**
그것은 애초에 존재하지 말았어야 할 구식 패러다임에서 작동하고 있었습니다.
63. **Uh and uh yeah, the software 3.0 paradigm is a lot more kind of raw.**
네, 소프트웨어 3.0 패러다임은 훨씬 더 날것에 가깝습니다.
64. **It just um your neural network is doing more and more of the work, and your prompt or context is just the image, and the output is an image, and there's no need to have any of the app in between.**
신경망이 점점 더 많은 일을 하고, 프롬프트나 컨텍스트는 그냥 이미지일 뿐이며, 출력도 이미지이고, 그 사이에 앱이 끼어들 필요가 없습니다.
65. **Um so, I think that people have to kind of like reframe, you know, not to work in the existing paradigm of what things existed and just think about it as a speed up of what exists.**
그래서 사람들은 기존에 존재하던 것들을 단순히 더 빠르게 만드는 관점으로만 보지 말고, 관점을 다시 설정해야 한다고 생각합니다.
66. **It's actually like new things are available now.**
사실 이제는 새로운 것들이 가능해졌습니다.
67. **And going back to your programming question, it's not even I think that's also an example of working in the in the old mindset because it's not just about programming and programming becoming faster.**
그리고 다시 프로그래밍 질문으로 돌아가면, 그것도 옛 사고방식의 예라고 생각합니다. 왜냐하면 이건 단지 프로그래밍이 더 빨라지는 문제만은 아니기 때문입니다.
68. **This is more general information processing that is automatable now.**
이것은 이제 더 일반적인 정보 처리 자체가 자동화 가능해졌다는 뜻입니다.
69. **So, um it's not just even about code.**
따라서 이건 단지 코드의 문제만도 아닙니다.
70. **So, previous code worked over a kind of like structured data, right?**
이전의 코드는 일종의 구조화된 데이터 위에서 작동했죠.
71. **And uh you write code over structured data.**
그리고 우리는 구조화된 데이터 위에 코드를 작성합니다.
72. **But like for example with my LLM knowledge bases project, um uh basically you get LLMs to create wikis for your organization or for you in person, etc.**
하지만 예를 들어 제 LLM 지식베이스 프로젝트에서는, LLM이 조직이나 개인을 위한 위키를 만들게 할 수 있습니다.
73. **This is not even a program.**
이건 엄밀히 말해 프로그램도 아닙니다.
74. **This is not something that could exist before because there was no there was no code that would create a knowledge base based on a bunch of facts.**
왜냐하면 과거에는 여러 사실을 바탕으로 지식베이스를 만들어 주는 코드가 존재하지 않았기 때문입니다.
75. **But now you can just take these documents and uh basically uh recompile them in a different way, and uh reorder them, and create something that is uh new and interesting uh as a reframing of the data.**
하지만 이제는 이런 문서들을 가져다가 다른 방식으로 다시 컴파일하고, 재배열해서, 데이터를 새롭게 재해석한 흥미로운 결과물을 만들 수 있습니다.
76. **And so, these are new things that weren't possible.**
그래서 이런 것들은 이전에는 불가능했던 새로운 일들입니다.
77. **Uh and so, I think this is uh something that I keep trying to get back to as to not only what can we do that existed that is faster now, but I think there's new opportunities of just things that couldn't be possible before.**
그래서 저는 단지 기존에 가능하던 일을 더 빠르게 할 수 있는가만이 아니라, 과거에는 불가능했던 새로운 기회가 무엇인지 계속 생각하려고 합니다.
78. **And I almost think that that's more exciting.**
그리고 저는 오히려 그것이 더 흥미롭다고 생각합니다.
79. **I love the menu gen progression and dichotomy that you laid out, and I think even I'm sure many folks here followed your own progression of programming from last October to early January, February this year.**
방금 말씀하신 MenuGen의 발전 과정과 대비가 정말 좋았습니다. 그리고 여기 계신 많은 분들도 지난 10월부터 올해 1월 초, 2월까지의 당신의 프로그래밍 변화 과정을 지켜봤을 거라고 생각합니다.
80. **If you extrapolate that further, what is the 2026 equivalent for building websites in the '90s, building mobile apps in the 2010s, building SaaS in the last cloud era?**
그것을 더 확장해서 보면, 2026년에 해당하는 “90년대의 웹사이트 만들기”, “2010년대의 모바일 앱 만들기”, “클라우드 시대의 SaaS 만들기”는 무엇일까요?
81. **What will look completely obvious in hindsight that is still mostly unbuilt today?**
나중에 돌아보면 너무나 당연해 보이지만, 지금은 아직 거의 만들어지지 않은 것은 무엇일까요?
**08:02**
82. **Um >> >> Well, going with the example of MenuGen, I guess.**
음, MenuGen 예시를 이어서 말씀드리면 좋겠습니다.
83. **So, a lot of this code shouldn't exist and it's just neural networks doing most of the work.**
그래서 이런 코드의 상당수는 사실 존재하지 않아도 되고, 신경망이 대부분의 일을 하면 됩니다.
84. **Um I do think that the extrapolation looks very weird because you could basically imagine I don't think I Yeah, so you could imagine completely neural computers in a certain sense.**
저는 이걸 더 확장해서 생각하면 꽤 이상하게 보인다고 생각합니다. 왜냐하면 어떤 의미에서는 완전히 신경망으로 이루어진 컴퓨터를 상상할 수 있기 때문입니다.
85. **Uh you feed a raw videos like imagine a device that takes raw videos or audio into basically what's a neural net and uses diffusion to render a UI that is kind of like, you know, unique for that moment in a certain sense.**
원시 영상이나 오디오를 입력하면, 그것을 사실상 신경망에 넣고 디퓨전을 사용해 그 순간에 맞는 독특한 UI를 렌더링하는 장치를 상상해 보세요.
86. **And um I kind of feel like in the early days of computing actually, people were a little bit confused as to whether computers would look like calculators or computers would look like neural nets.**
그리고 컴퓨팅 초기에는 사람들이 컴퓨터가 계산기처럼 생길지, 아니면 신경망처럼 생길지 조금 헷갈려 했던 것 같다고 느낍니다.
87. **And in '50s and '60s, it was not really obvious which way would go.**
1950년대와 60년대에는 어느 쪽으로 갈지 정말 분명하지 않았습니다.
88. **And of course, we went down the calculator path and ended up building classical computing and then neural nets are currently running virtualized on existing computers.**
그리고 결국 우리는 계산기 경로를 택해 고전적 컴퓨팅을 구축했고, 지금의 신경망은 기존 컴퓨터 위에서 가상화된 형태로 돌아가고 있습니다.
89. **But you could imagine I think that a lot of this will flip and that the neural net becomes kind of like the host process.**
하지만 저는 앞으로 많은 것이 뒤집혀서, 신경망이 일종의 호스트 프로세스가 되는 상황을 상상할 수 있다고 생각합니다.
90. **And the CPUs become kind of like the co-processor.**
그러면 CPU는 일종의 보조 프로세서가 됩니다.
91. **So, we saw the diagram of, you know, intelligence compute is going to neural networks is going to take over and become the dominant spend of flops.**
그래서 우리는 지능 연산이 신경망으로 넘어가고, 그것이 FLOPS의 지배적인 사용처가 될 것이라는 그림을 보았습니다.
92. **So, you could imagine something really weird and foreign when where neural nets are doing most of the heavy lifting, they're using tool use as just like, you know, historical appendage for some kinds of like deterministic tasks.**
그래서 매우 낯설고 이상한 상황을 상상할 수 있습니다. 신경망이 대부분의 무거운 작업을 처리하고, 도구 사용은 일부 결정론적 작업을 위한 역사적 부속물처럼 쓰이는 모습입니다.
93. **But what's really running the show is these neural nets that are networked in a certain way.**
하지만 실제로 전체를 이끄는 것은 특정한 방식으로 연결된 이 신경망들입니다.
94. **Um so, you can imagine something extremely foreign as the extrapolation, but I think we're going to probably get there sort of piece by piece.**
그래서 매우 낯선 미래를 상상할 수 있지만, 아마도 우리는 그것에 조금씩 도달하게 될 것이라고 생각합니다.
95. **And I don't Yeah, I don't that that progression is TBD, I would say.**
다만 그 전개가 어떻게 될지는 아직 정해지지 않았다고 말하고 싶습니다.
96. **>> >> I'd love to talk a little bit about um, uh, this concept of verifiability.**
검증 가능성이라는 개념에 대해 조금 더 이야기해 보고 싶습니다.
97. **The fact that AI will automate faster and more easily domains where the output can be verified.**
AI는 결과를 검증할 수 있는 분야를 더 빠르고 쉽게 자동화한다는 점 말입니다.
98. **Um, if that framework is right, what work is about to move much faster than people realize?**
만약 그 프레임이 맞다면, 사람들 생각보다 훨씬 빨리 변할 일은 무엇일까요?
99. **And what professions do we have that people actually think are safe, but they're actually highly verifiable?**
그리고 사람들은 안전하다고 생각하지만 사실은 매우 검증 가능한 직업에는 어떤 것들이 있을까요?
100. **Uh, yes, so I I spent uh, some time writing about verifiability and um, basically like traditional computers can easily automate what you can specify in code.**
네, 저는 검증 가능성에 대해 글을 쓰는 데 시간을 좀 썼습니다. 기본적으로 전통적인 컴퓨터는 코드로 명시할 수 있는 것을 쉽게 자동화할 수 있습니다.
101. **And uh, kind of this latest round of LLMs can easily automate what you can uh, verify in a certain in a certain sense.**
그리고 이번 최신 LLM들은 어떤 의미에서는 검증할 수 있는 것을 쉽게 자동화할 수 있습니다.
102. **Uh, because the way this works is that when frontier labs are training these LLMs, these are giant reinforcement learning environments.**
왜냐하면 최첨단 연구소가 이런 LLM을 훈련시킬 때, 그것은 거대한 강화학습 환경과 같기 때문입니다.
103. **So, they are given a verification rewards.**
즉, 검증 보상이 주어집니다.
104. **And then because of the way that these models are trained, they end up basically uh, progressing and creating these like jagged entities that really peak in capability in kind of like verifiable domains like math and code and adjacent.**
그리고 그런 방식으로 훈련된 모델들은 결국 울퉁불퉁한 형태의 능력을 가진 존재가 되며, 수학이나 코드 같은 검증 가능한 영역과 그 주변 분야에서 성능이 특히 두드러집니다.
105. **And kind of like stagnate and are a little bit um, you know, rougher on the edges when uh, things are not kind of like in that in that space.**
반면 그 범위를 벗어나는 영역에서는 정체되거나 조금 더 거칠게 나타납니다.
106. **So, I think the reason I wrote about verifiability is I'm trying to understand why these things are so jagged.**
그래서 제가 검증 가능성에 대해 쓴 이유는, 왜 이런 것들이 그렇게 울퉁불퉁한지 이해하려고 했기 때문입니다.
107. **Um, and some of it has to do with how the labs train the models, but I think some of it also has to do with um, the focus of the labs and what they happen to put into the data distribution.**
그 이유의 일부는 연구소들이 모델을 훈련하는 방식과 관련이 있지만, 또 일부는 연구소가 어디에 집중하고 어떤 데이터를 데이터 분포에 넣느냐와도 관련이 있다고 생각합니다.
108. **Uh, because some things basically are significantly more valuable in economy and end up creating more environments because the labs wanted to work in those settings.**
왜냐하면 어떤 것들은 경제적으로 훨씬 더 가치가 커서, 연구소들이 그런 환경에서 작업하려고 하면서 더 많은 환경이 만들어지기 때문입니다.
109. **So, I think code is a good example of that.**
그래서 코드가 그 좋은 예라고 생각합니다.
110. **There's probably lots of verifiable environments they could think about that happen not to make it into the mix because they're just not that useful to have the capability around.**
아마도 검증 가능한 환경은 많이 떠올릴 수 있지만, 그 능력을 갖추는 것이 그다지 유용하지 않아서 실제로는 섞이지 않은 것들이 많을 겁니다.
111. **Um, but I think to me the big um, I guess like the big mystery is uh, the favorite example for a while was that how many letters are are in a strawberry?**
하지만 제게 가장 큰 수수께끼는, 한동안 유명했던 예시인 “strawberry에 글자가 몇 개 있느냐”였습니다.
112. **And the models would famously get this wrong and it's an example of jaggedness.**
모델들은 이 문제를 유명할 정도로 틀렸고, 그것이 바로 울퉁불퉁함의 예였습니다.
113. **Uh, the models now patch this, I think, but the new one is I want to go to a car wash to wash my car, and it's 50 m away, should I drive or should I walk?**
지금은 그 문제가 수정된 것 같지만, 새로운 예시는 “차를 세차하러 가고 싶은데 50미터밖에 안 떨어져 있다. 차를 몰고 가야 하나, 걸어가야 하나?”입니다.
114. **And state-of-the-art models today will tell you to walk because it's so close.**
그리고 오늘날의 최첨단 모델들은 너무 가깝다는 이유로 걸어가라고 답합니다.
115. **How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000 like >> >> code base a line code base or find zero-day vulnerabilities and yet tells me to walk to this car wash?**
어떻게 최첨단 Opus 4.7이 동시에 10만 줄짜리 코드베이스를 리팩토링하거나 제로데이 취약점을 찾아내면서도, 정작 세차장에는 걸어가라고 말할 수 있는 걸까요?
116. **This is insane.**
이건 정말 말이 안 됩니다.
117. **And to whatever extent these models are remain jagged, it's an indication that number one, maybe something slightly off.**
이런 모델들이 여전히 울퉁불퉁하다면, 그것은 첫째로 어딘가 조금 잘못되었다는 신호일 수 있습니다.
118. **Or number two, you need to actually be in the loop a little bit and you need to treat them as tools and you do have to kind of stay in touch with what they're doing.**
둘째로는, 실제로 어느 정도는 사람이 루프 안에 있어야 하고, 이들을 도구로 대하면서 무엇을 하는지 계속 확인해야 한다는 뜻일 수 있습니다.
119. **And so I think all of my writing, long story short, about verifiability is just trying to understand um why these things are jagged, is there any pattern to it?**
정리하자면, 제가 검증 가능성에 대해 쓴 모든 글은 결국 왜 이런 것들이 울퉁불퉁한지, 그리고 그 안에 어떤 패턴이 있는지를 이해하려는 시도였습니다.
120. **And I think it's a some kind of combination of verifiable plus labs care.**
제 생각에는 그것이 검증 가능성과 연구소의 관심 정도가 결합된 어떤 결과인 것 같습니다.
121. **Maybe one more anecdote that is instructive is from GPT-3.5 to GPT-4, people noticed that chess improved a lot and I think a lot of people thought, oh well, it's just a progression of the capabilities.**
또 하나 도움이 되는 일화가 있습니다. GPT-3.5에서 GPT-4로 넘어갈 때 체스 실력이 많이 좋아졌는데, 많은 사람들이 그걸 단순한 능력 향상으로 생각했습니다.
122. **But actually it's it's more that I think this is public information, I think I saw it on the internet.**
하지만 사실은, 제가 알기로 공개된 정보인데, 인터넷에서 본 적이 있습니다.
123. **Um a huge amount of like data of chess made it into the pre-training set.**
체스 관련 데이터가 사전학습 데이터에 엄청나게 많이 들어갔습니다.
124. **And just because it's in the data distribution, basically the model improved a lot more than it would just by default.**
그리고 그것이 데이터 분포 안에 들어가 있었기 때문에, 모델은 기본적으로 개선되는 것보다 훨씬 더 많이 향상되었습니다.
125. **So someone at OpenAI decided to add this data and now you have a capability that just peaked a lot more.**
즉 OpenAI의 누군가가 그 데이터를 추가했고, 그 결과 해당 능력이 훨씬 더 크게 향상된 것입니다.
126. **And so that's why I think I'm stressing this dimension of it as we are slightly at the mercy of whatever the labs are doing, whatever they happen to put into the mix and you have to actually explore this thing that they give you that has no manual and it works in certain settings but maybe not in some settings and you have to kind of explore it a little bit and if you're in the circuits that were part of the RL, you fly and if you're in the circuits that are out of the data distribution, you're going to struggle and you have to kind of figure out which which circuits you're in in your application.**
그래서 저는 이 차원을 강조하는 것입니다. 우리는 어느 정도는 연구소가 무엇을 하느냐, 그들이 무엇을 혼합에 넣느냐에 좌우됩니다. 그리고 설명서도 없이 주어진 이 도구를 직접 탐색해야 합니다. 어떤 상황에서는 잘 작동하지만 어떤 상황에서는 아닐 수 있고, 조금 실험해 봐야 합니다. 강화학습의 회로 안에 있으면 아주 잘 되지만, 데이터 분포 밖의 회로에 있으면 고전할 것이므로, 자신의 응용이 어느 회로에 해당하는지 알아내야 합니다.
127. **And if you and if you're not in the circuits, then you have to really look at fine-tuning and doing some of your own work because it's not going to necessarily come out of the LLM out of the box.**
만약 그 회로 안에 있지 않다면, 파인튜닝을 하거나 직접 작업을 해야 합니다. LLM이 기본 상태에서 저절로 해 주지 않을 수 있기 때문입니다.
좋습니다. 끝까지 이어서 번역하겠습니다.
---
**13:02**
128. **I'd love to come back to the concept of jagged intelligence in a little bit.**
조금 뒤에 울퉁불퉁한 지능이라는 개념으로 다시 돌아가 보고 싶습니다.
129. **Um if you were a founder today and thinking about building a company, you are trying to solve a problem that you think is tractable, something that uh is a domain that is verifiable, but you look around and you think, "Oh my gosh, well the labs have really really started uh got getting to escape velocity and the ones that seem most obvious, math, coding, and others."**
오늘날 당신이 창업가라면 회사를 만든다고 생각해 보겠습니다. 당신은 해결 가능하다고 생각하는 문제, 즉 검증 가능한 영역의 문제를 풀고자 하지만, 주변을 보면 “세상에, 연구소들이 정말로 탈출 속도에 가까워졌고, 가장 뻔해 보이는 분야들, 즉 수학, 코딩 같은 것들까지도 다들 파고들고 있네”라고 느끼게 됩니다.
130. **What would your advice be to to the founders in the audience?**
청중에 있는 창업가들에게 어떤 조언을 해 주시겠습니까?
131. **Um So, I think maybe that comes to the previous question of I do think that verifiability because it um Let me think.**
제 생각에는 이것이 아까 질문과 이어지는 것 같습니다. 검증 가능성이라는 것이, 음, 잠깐 생각해 보겠습니다.
132. **So, verifiability makes something tractable in the current paradigm because you can throw huge amount of RL at it.**
검증 가능성은 현재 패러다임에서 어떤 문제를 다루기 쉽게 만듭니다. 왜냐하면 거기에 엄청난 양의 강화학습을 투입할 수 있기 때문입니다.
133. **Um so, maybe one way to see it is that uh that remains true even if the labs are not focusing on it directly.**
그러니까, 한 가지 방식으로 보면, 연구소가 직접 그 분야에 집중하지 않더라도 그 사실은 여전히 유효합니다.
134. **So, if you are in a a verifiable setting where you could create these RL environments or examples, then that actually sets you up to potentially do your own fine-tuning and you might benefit from that.**
따라서 강화학습 환경이나 예시를 만들 수 있는 검증 가능한 분야에 있다면, 직접 파인튜닝을 할 수 있는 기반이 되고, 그로부터 이득을 볼 수 있습니다.
135. **But, that is fundamentally technology that just works.**
하지만 본질적으로 그것은 그냥 작동하는 기술입니다.
136. **You can pull a lever.**
레버를 당기면 됩니다.
137. **If you have huge amount of diverse data sets of RL environments, etc., uh you can use your favorite fine-tuning framework and um and uh pull the lever and get something that actually uh works pretty well.**
다양한 강화학습 환경 데이터셋을 아주 많이 가지고 있다면, 자신이 선호하는 파인튜닝 프레임워크를 사용해서 레버를 당기고, 실제로 꽤 잘 작동하는 결과를 얻을 수 있습니다.
138. **So, um I don't know what the examples of this might be.**
그래서 구체적인 예가 무엇인지는 저도 잘 모르겠습니다.
139. **Um but I do think there are some very valuable uh reinforcement learning environments that people could think of that I think are not part of the**
하지만 사람들이 생각해 볼 수 있는 매우 가치 있는 강화학습 환경이 분명 있다고 생각하며, 그것들은 아직 그 안에 포함되지 않았다고 봅니다.
140. **Yeah, I don't want to give away the answer, but there is one domain that I think is very uh Oh, okay. Sorry. I don't mean to vague post on on the stage, but uh there are some examples of this.**
네, 답을 너무 직접적으로 말하고 싶지는 않지만, 제가 보기엔 매우 중요한 한 분야가 있습니다. 아, 죄송합니다. 무대에서 애매하게 말하려는 것은 아니지만, 이런 예가 몇 가지 있습니다.
141. **On the flip side, what do you think still feels automatable only from a distance?**
반대로, 아직은 멀리서 보기에는 자동화 가능해 보이지만 실제로는 그렇지 않은 것은 무엇이라고 생각하시나요?
142. **I do think that ultimately almost everything can be made uh verifiable to some extent, some things easier than others.**
저는 궁극적으로 거의 모든 것을 어느 정도는 검증 가능하게 만들 수 있다고 생각합니다. 다만 어떤 것은 더 쉽고 어떤 것은 더 어렵습니다.
143. **Um because even for like things that are like writing or so on, you can imagine having a council of LLM judges and probably get get to some get something reasonable out of the from from this kind of an approach.**
글쓰기 같은 것조차도 LLM 심사위원들로 구성된 위원회를 두면, 그런 방식으로 어느 정도 합리적인 결과를 얻을 수 있다고 상상할 수 있습니다.
144. **So, it's more about what's easy or hard.**
그러므로 핵심은 무엇이 쉽고 무엇이 어려운가입니다.
145. **Um So, I I do think that ultimately um Uh yeah, I think uh Everything.**
그래서 저는 궁극적으로, 네, 모든 것이 가능합니다라고 생각합니다.
146. **>> >> Everything is automatable.**
모든 것은 자동화할 수 있습니다.
147. **Amazing. Okay.**
놀랍습니다. 좋습니다.
148. **Um so, last year you coined the term vibe coding and today we're in a world that feels a little bit more serious, more agentic engineering.**
작년에 당신은 “vibe coding”이라는 용어를 만들었고, 오늘날 우리는 조금 더 진지하고 더 에이전트적인 엔지니어링의 세계에 살고 있습니다.
149. **What do you think is the difference between the two and what would you actually call what we're in today?**
두 개념의 차이는 무엇이라고 보시며, 지금 우리가 있는 이 시대를 실제로 뭐라고 부르시겠습니까?
150. **Uh yeah, so I would say vibe coding is about raising the floor for everyone in terms of what they can do in software.**
제 생각에는 vibe coding은 소프트웨어에서 사람들이 할 수 있는 것의 최저선을 끌어올리는 것입니다.
151. **So, the floor rises, everyone can vibe code anything, and that's amazing, incredible.**
즉, 기준선이 올라가서 누구나 무엇이든 vibe code를 할 수 있게 되고, 그것은 정말 놀랍고 대단합니다.
152. **But then I would say agentic engineering is about preserving the quality bar of what existed before in professional software.**
반면 에이전트형 엔지니어링은 전문 소프트웨어에서 이전에 유지되던 품질 기준을 지키는 데 관한 것입니다.
153. **So, you're not allowed to introduce uh vulnerabilities due to vibe coding.**
즉, vibe coding 때문에 취약점을 만들어서는 안 됩니다.
154. **Um you're um you're still responsible for your software just as before, but can you go faster?**
여전히 이전과 마찬가지로 자신의 소프트웨어에 책임을 져야 하지만, 더 빨리 할 수 있느냐가 문제입니다.
155. **And spoiler is you can, but how do you how do you do that properly?**
결론부터 말하면 가능합니다. 하지만 그걸 어떻게 제대로 하느냐가 핵심입니다.
156. **And so, to me agentic engineering when I I call it that because I do think it's kind of like an engineering discipline.**
그래서 제가 그것을 agentic engineering이라고 부르는 이유는, 그것이 일종의 공학적 분야라고 보기 때문입니다.
157. **You have these agents which are these like spiky entities, they're a bit fallible, a little bit stochastic, but they are extremely powerful.**
이런 에이전트들은 뾰족하고 다소 불완전하며, 약간 확률적이지만, 매우 강력한 존재들입니다.
158. **And it's how do you how do you coordinate them to go faster without sacrificing your quality bar?**
중요한 것은 이들을 어떻게 조율해서 품질 기준을 해치지 않으면서 더 빠르게 가게 하느냐입니다.
159. **And doing that well and correctly um is the the realm of agentic engineering.**
그것을 제대로 잘 수행하는 것이 agentic engineering의 영역입니다.
160. **Um so, I kind of see them as as different.**
그래서 저는 두 개념을 서로 다르게 봅니다.
161. **Like one is about maybe raising the raising the floor, and the other is about um you know, extrapolating.**
하나는 기준선을 올리는 것이고, 다른 하나는 확장해 나가는 것입니다.
162. **And what I'm seeing I think is there is a very high ceiling on agent engineer uh capability.**
제가 보기에는 agentic engineering 능력에는 매우 높은 천장이 있습니다.
163. **And you know, people used to talk about the 10x engineer previously.**
예전에는 사람들이 10배 엔지니어에 대해 이야기하곤 했습니다.
164. **I think that this is uh is magnified a lot more.**
하지만 이제는 그것보다 훨씬 더 커졌다고 생각합니다.
165. **Uh 10x is uh is not uh the speed up you gain.**
10배는 이제 얻는 속도 향상을 충분히 설명하지 못합니다.
166. **And I think uh it does seem to me like people who are very good at this um peak a lot more than 10x uh from from my perspective right now.**
그리고 제 관점에서는, 이것을 아주 잘하는 사람들은 10배를 훨씬 넘어서 성과가 치솟는 것처럼 보입니다.
167. **I really like that framing.**
저는 그 관점이 정말 마음에 듭니다.
168. **Um one thing that when Sam Altman came to AI sent last year, one memorable thing he said was that people of different generations use ChatGPT differently.**
샘 알트먼이 지난해 AI 행사에 왔을 때 했던 기억에 남는 말 중 하나는, 세대에 따라 ChatGPT를 다르게 사용한다는 것이었습니다.
169. **So, if you're in your 30s, you use it as a Google search replacement, but if you're in your teens, ChatGPT is your gateway to the internet.**
그래서 30대라면 그것을 구글 검색 대체재로 쓰지만, 10대라면 ChatGPT가 인터넷으로 들어가는 관문이라는 것입니다.
170. **What is the parallel here in coding today?**
그렇다면 오늘날 코딩에서의 대응 관계는 무엇일까요?
171. **If we were to watch two people code using open claw, cloud code, codex, one you'd consider mediocre at it and one you would consider fully AI native, how would you describe the difference?**
OpenClaw, Cloud Code, Codex 같은 도구를 사용하는 두 사람을 본다고 해봅시다. 한 사람은 평범하고, 다른 한 사람은 완전히 AI 네이티브라고 느껴진다면, 그 차이를 어떻게 설명하시겠습니까?
172. **I mean, I think it's just trying to get the most out of the tools that are available, utilizing all of their features, investing into your own kind of setup.**
제 생각에는 그냥 사용 가능한 도구를 최대한 활용하고, 기능을 모두 쓰고, 자기만의 환경에 투자하는 것입니다.
173. **So, just like previously, all the engineers are used to basically getting the most out of the tools you use, either it's Vim or VS Code or now it's you know, cloud code or codex or so on.**
예전처럼 엔지니어들은 Vim이든 VS Code든, 지금은 Cloud Code나 Codex든, 사용하는 도구에서 최대한을 끌어내는 데 익숙합니다.
174. **Um just investing into your setup and utilizing a lot of the, you know, tools that are available to you.**
즉, 자신의 설정에 투자하고 자신에게 제공되는 도구들을 많이 활용하는 것입니다.
175. **Um and I think it just kind of looks like that.**
제 생각엔 결국 그런 모습입니다.
176. **I do think that maybe related thought is um a lot of people are maybe hiring for this, right?**
관련된 생각 하나는, 많은 사람들이 이런 역량을 기준으로 채용하고 있다는 점입니다.
177. **Because they want to hire strong agentic engineers.**
왜냐하면 강한 agentic engineer를 뽑고 싶어 하기 때문입니다.
178. **I do think that what I'm seeing is that the, you know, most people are still not refactored their their hiring process for agentic engineer capability, right?**
그런데 제가 보기에는 대부분의 사람들이 아직 채용 과정을 agentic engineer 역량에 맞게 재구성하지 못했습니다.
179. **Like if you're giving out puzzles to solve, then this is still the old paradigm.**
예를 들어 문제풀이 퍼즐을 내는 방식이라면, 그것은 여전히 옛 패러다임입니다.
180. **I would say that hiring have to has to look like give me a really big project and see someone implement that big project.**
제 생각에는 채용이란 “큰 프로젝트를 하나 주고, 그것을 누가 구현하는지 보자”는 식이어야 합니다.
181. **Like let's write, say a Twitter clone for agents and then make it really good, make it really secure, and then have some agents simulate some activity on this Twitter.**
예를 들어 에이전트를 위한 트위터 클론을 만들고, 그것을 아주 좋고 아주 안전하게 만든 뒤, 몇몇 에이전트가 그 트위터에서 활동을 시뮬레이션하게 해 보자는 식입니다.
182. **And then I'm going to use 10 codex 5.4 x high to try to break your break your this website that you deployed and they're going to try to basically break it and they should not be able to break it.**
그리고 제가 Codex 5.4 x high 10개를 써서 당신이 배포한 웹사이트를 깨뜨리려 할 것이고, 그들이 아무리 시도해도 웹사이트를 깨지 못해야 합니다.
183. **And so maybe it looks like that, right?**
어쩌면 그런 식이 되어야 할 것입니다, 그렇죠?
184. **And so yeah, watching people in that that setting and building some bigger projects and utilize utilizing the tooling is maybe what I would look at for the most part.**
그래서 그런 환경에서 사람들이 어떻게 하는지 보고, 더 큰 프로젝트를 만들고, 도구를 활용하는 모습을 보는 것이 제가 주로 볼 부분이라고 생각합니다.
185. **And as agents do more, what human skill do you think becomes more valuable, not less?**
에이전트가 더 많은 일을 하게 될수록, 오히려 덜 중요해지는 것이 아니라 더 중요해질 인간의 기술은 무엇이라고 생각하시나요?
186. **Also, yeah, it's a good question.**
네, 좋은 질문입니다.
187. **I think um Well, right now the answer is that the agents are catalog these internal entities, right?**
제 생각에는, 현재로서는 에이전트가 이런 내부 요소들을 정리하고 있다는 점이 답인 것 같습니다.
188. **So it's remarkable um you basically still have to be in charge of the aesthetics, the the judgment, the taste, and a little bit of oversight.**
놀랍게도 아직은 미학, 판단, 취향, 그리고 약간의 감독은 여전히 사람이 맡아야 합니다.
189. **And maybe one one of my favorite examples of like the the weirdness of agents is um for menu gen, you sign up with a Google Google account, but you purchase credits using a Stripe account and both of them have email addresses.**
에이전트의 이상함을 보여 주는 제가 좋아하는 예 중 하나는 MenuGen입니다. 사용자는 Google 계정으로 가입하지만, 크레딧은 Stripe 계정으로 구매하고, 둘 다 이메일 주소를 사용한다는 점입니다.
190. **And my agent actually tries to basically um like when you purchase credits, it assigned it using the email address from Stripe to the Google email address.**
그런데 제 에이전트는 크레딧을 구매하면 Stripe의 이메일 주소를 Google 이메일 주소에 연결하려고 했습니다.
191. **Like there wasn't a persistent user ID that that for people.**
사람마다 지속적인 사용자 ID가 있는 구조가 아니었던 것입니다.
192. **It was trying to match up the email addresses, but you could use different email address for your Stripe and your Google and basically would not associate the funds.**
에이전트는 이메일 주소를 맞추려 했지만, Stripe와 Google에 서로 다른 이메일을 사용할 수 있었기 때문에 결국 자금이 연결되지 않았습니다.
193. **And so this is the kind of thing that these agents still will make mistakes about.**
이런 것이 아직도 에이전트가 실수하는 유형입니다.
194. **It's like why would you use email addresses to try to cross-correlate the funds?**
자금을 서로 연결하려고 이메일 주소를 쓰는 게 말이 되느냐는 겁니다.
195. **They can be arbitrary.**
이메일은 임의적일 수 있습니다.
196. **You can use different emails, etc.**
서로 다른 이메일을 써도 됩니다.
197. **Like this is such a weird thing to do.**
정말 이상한 방식입니다.
198. **So I think people have to be in charge of this spec, this plan, and actually don't even like the plan mode.**
그래서 저는 사람이 이 명세와 계획을 책임져야 한다고 생각합니다. 사실 저는 plan mode도 별로 좋아하지 않습니다.
199. **I would I mean, obviously it's very useful, but I think there's something more general here where you have to work with your agent to design a spec that is very detailed and maybe it's a maybe basically the docs and then get the agents to write them.**
물론 매우 유용하긴 하지만, 더 일반적으로는 에이전트와 함께 아주 상세한 명세를 설계해야 하고, 어쩌면 문서를 먼저 만들고 그걸 에이전트가 작성하게 해야 한다고 생각합니다.
200. **And you're in charge of the oversight and the top-level categories, but the agents are doing a lot of the under the hood.**
당신은 감독과 상위 범주를 맡고, 에이전트는 내부의 많은 부분을 처리합니다.
201. **And so I think you're not caring about some of the details.**
그래서 어떤 세부 사항들은 신경 쓰지 않게 됩니다.
202. **So as an example also with um, a race or tensors in neural networks, um there's a ton of details between PyTorch and NumPy and all the different like pandas and so on for all the different little API details.**
예를 들어 신경망의 배열이나 텐서와 관련해서도 PyTorch와 NumPy, 그리고 pandas 같은 여러 API 세부사항 사이에는 엄청나게 많은 차이가 있습니다.
203. **And I'll I already forgot about the keep dims versus keep dim or whether it's dim or axis or reshape or permute or transpose.**
저는 벌써 keep dims와 keep dim, dim과 axis, reshape, permute, transpose 같은 것들을 잊어버렸습니다.
204. **I don't remember this stuff anymore, right?**
이제 이런 것들은 기억하지 못합니다, 그렇죠?
205. **Because you don't have to.**
왜냐하면 그럴 필요가 없기 때문입니다.
206. **This is the kind of details that are handled by the intern because they have very good recall.**
이런 세부사항은 기억력이 매우 좋은 인턴이 처리하는 종류의 일입니다.
207. **And but you still have to know for example that um, you know, there's underlying tensor, there's an underlying view and then you can view of the same storage or you can have different storage which will be less efficient.**
하지만 예를 들어 밑바탕에 텐서가 있고, 그 위에 뷰가 있으며, 같은 저장소를 참조하는 뷰를 만들 수도 있고, 더 비효율적인 다른 저장소를 가질 수도 있다는 점은 여전히 알아야 합니다.
208. **As we still have to have an understanding of what this stuff is doing and some of the fundamentals um, so that you're not copying memory around unnecessarily and so on.**
이런 것들이 무엇을 하는지, 기본 원리가 무엇인지 이해하고 있어야 불필요하게 메모리를 복사하는 일을 피할 수 있습니다.
209. **But uh, the details of the APIs are now handed off.**
하지만 API 세부사항은 이제 넘겨도 됩니다.
210. **So it um, you're in charge of the taste, the engineering, the design uh, and that it makes sense and that you're asking for the right things and that you're saying that okay, that these have to be unique user IDs that we're going to tie everything to.**
따라서 당신은 취향, 공학, 디자인을 책임지고, 전체가 말이 되는지, 올바른 것을 요구하고 있는지, 그리고 모든 것을 연결할 고유 사용자 ID가 필요하다고 말하는 역할을 맡습니다.
211. **Um, and so you're doing some of the design and development and the engineers are doing the fill in the blanks.**
즉, 당신은 설계와 개발의 일부를 맡고, 엔지니어들은 빈칸을 채웁니다.
212. **And that's currently kind of like where we are and I think that's what everyone of course is seeing I think right now.**
그리고 그것이 현재 우리가 있는 지점이며, 물론 지금 모두가 보고 있는 것이라고 생각합니다.
213. **Do you think there's a chance that this um, taste and judgment matters less over time or will the ceiling just keep rising?**
시간이 지나면 이런 취향과 판단의 중요성이 줄어들 가능성이 있다고 보시나요, 아니면 한계선은 계속 높아질까요?
214. **Um, yeah, it's a good question.**
네, 좋은 질문입니다.
215. **I would say um, I mean I'm hoping that the that it improves.**
제 생각엔, 저는 그것이 개선되길 바랍니다.
216. **I think probably the reason it doesn't improve right now is again it's not part of the RL.**
지금 개선되지 않는 이유는 아마도 그것이 강화학습의 일부가 아니기 때문이라고 생각합니다.
217. **There's probably no aesthetics cost or reward or it's not good enough or something like that.**
아마 미학적 비용이나 보상이 없거나, 충분히 좋지 않거나, 그런 이유일 것입니다.
218. **Um, I do think that when you actually look at the code, sometimes I get a little bit of a heart attack because it's not like super amazing code necessarily all the time and it's very bloated and there's a lot of copy-paste and there's awkward abstractions that are brittle and like it works but it's just really gross.**
실제 코드를 보면 가끔 심장이 철렁합니다. 항상 엄청나게 훌륭한 코드는 아니고, 매우 비대하며, 복사-붙여넣기가 많고, 어색하고 취약한 추상화가 많아서, 돌아가긴 하지만 정말 지저분합니다.
219. **Um, and I do I do hope that this can improve in future models.**
저는 미래의 모델에서는 이것이 개선되기를 바랍니다.
220. **Um, a good example also is this uh, you know, the micro GPT project uh, which where I was trying to simplify uh LLM training to be as simple as possible.**
좋은 예로는 micro GPT 프로젝트가 있습니다. 저는 LLM 훈련을 가능한 한 단순하게 만들려고 했습니다.
221. **The models hate this.**
모델들은 이런 걸 싫어합니다.
222. **They can't do it.**
모델들은 그걸 잘 못합니다.
223. **I tried to I keep I kept trying to prompt an LLM to simplify more, simplify more, and it just can't**
저는 LLM에게 “더 단순하게, 더 단순하게”라고 계속 프롬프트를 줬지만, 전혀 못 했습니다.
224. **You feel like you're outside of the RL circuits.**
마치 강화학습 회로 밖에 있는 느낌입니다.
225. **It feels like it you're obviously, you know, you're pulling teeth.**
분명히 보이듯이, 정말 이를 뽑아내는 느낌입니다.
226. **It's not like light speed.**
전혀 빛의 속도처럼 진행되지 않습니다.
227. **So, I think um I do think that people are still remain in charge of this, but I do think that there's nothing fundamental again that's preventing it.**
그래서 저는 여전히 사람이 이 일을 책임지고 있다고 생각하지만, 근본적으로 그것을 막는 것은 없다고 생각합니다.
228. **It's just the labs haven't done it yet almost.**
다만 연구소들이 아직 그걸 하지 않았을 뿐입니다.
229. **Yeah.**
네.
230. **So, I'd love to come back to this idea of uh jagged forms of intelligence.**
그래서 다시 울퉁불퉁한 형태의 지능이라는 개념으로 돌아가 보고 싶습니다.
231. **You wrote a little bit about this with uh very thought-provoking piece around animals versus ghosts.**
당신은 동물과 유령을 대비한 매우 생각할 거리를 주는 글에서 이 주제에 대해 조금 썼습니다.
232. **Um and the idea is that we're not building animals.**
그 핵심 아이디어는 우리가 동물을 만들고 있는 것이 아니라는 점입니다.
233. **We are summoning ghosts.**
우리는 유령을 소환하고 있는 것입니다.
234. **Um and these are jagged forms of intelligence that are shaped by data and reward functions, but not by intrinsic motivation or fun or curiosity or empowerment, uh things that kind of came about via evolution.**
이런 것들은 데이터와 보상 함수에 의해 형성된 울퉁불퉁한 지능 형태이지만, 진화로 생겨난 내재적 동기, 재미, 호기심, 자율성 같은 것은 없습니다.
235. **Um why does that framing matter?**
왜 그런 프레임이 중요할까요?
236. **And what does it actually change about how you build and deploy and evaluate or even trust them?**
그리고 그것이 실제로 이들을 만들고, 배포하고, 평가하고, 심지어 신뢰하는 방식에 무엇을 바꾸나요?
237. **Uh yes, so Yeah, I think the reason I wrote about this is because I'm trying to wrap my head around what these things are, right?**
네, 제가 이 글을 쓴 이유는 이 존재들이 무엇인지 머릿속에 정리하려고 했기 때문입니다.
238. **Because if you have a good model of what they are or are not, then you're going to be more competent at uh using them.**
왜냐하면 그것들이 무엇인지, 무엇이 아닌지에 대한 좋은 모델이 있으면, 그것들을 더 능숙하게 사용할 수 있기 때문입니다.
239. **Um and I do think that um I don't know if it has I'm not sure if it actually has like real power.**
그리고 이것이 실제로 큰 힘이 있는지는 잘 모르겠습니다.
240. **>> >> I think it's a little bit of philosophizing.**
약간 철학적인 이야기라고 생각합니다.
241. **But I do think that um I think it's just um coming to terms with the fact that these things are not, you know, animal intelligences.**
하지만 저는 이것이 결국 이런 것들이 동물적 지능이 아니라는 사실을 받아들이는 일이라고 생각합니다.
242. **Like if you yell at them, they're not going to work better or or worse or it doesn't have any impact.**
예를 들어 소리친다고 더 잘 작동하거나 더 나빠지지도 않고, 아무 영향도 없습니다.
243. **Um and uh it's all just kind of like these statistical simulation circuits where the the substrate is pre-training, so like statistics.**
이건 전부 어떤 통계적 시뮬레이션 회로 같은 것이고, 그 기반은 사전학습, 즉 통계입니다.
244. **And then but then there's RL bolting on top, so it kind of like increases the disadvantages and um maybe it's just kind of a mindset of what I'm coming into or what's likely to work or not likely to work or how to modify it, but I don't actually I don't know that I have like here are the five obvious outcomes of how to make your system better.**
거기에 강화학습이 덧붙여져 있어서 단점을 더 키우는 면도 있습니다. 그래서 제 관점은, 무엇이 잘 작동할지, 무엇이 안 될지, 어떻게 수정할지에 대한 마음가짐에 가깝고, “시스템을 개선하는 다섯 가지 명확한 결과”를 제시할 수 있는 건 아닙니다.
245. **It's more just being suspicious of it and um figuring out over time.**
그냥 이것을 의심해 보고, 시간이 지나며 알아가는 것에 가깝습니다.
246. **That's where it starts.**
그렇게 시작하는 것입니다.
247. **Okay, so you are so deep in working with agents that don't just chat. They have real permissions. They have local contacts. They actually take action on your your behalf.**
좋습니다. 당신은 단순히 대화만 하는 것이 아닌 에이전트와 아주 깊이 일하고 있습니다. 그들은 실제 권한을 가지고 있고, 로컬 연결도 있으며, 실제로 당신을 대신해 행동합니다.
248. **What does the world look like when we all start to live in that world?**
우리가 모두 그런 세계에서 살기 시작하면 세상은 어떻게 보일까요?
249. **Yeah, I think I think a lot of people probably here are excited about what this agentic you know, native agentic environment looks like and everything has to be rewritten.**
네, 아마 여기 계신 많은 분들도 이런 에이전트 네이티브 환경이 어떤 모습일지 기대하고 있을 것입니다. 그리고 모든 것이 다시 작성되어야 합니다.
250. **Everything is still fundamentally written for humans and has to be moved around.**
지금의 모든 것은 근본적으로 인간을 위해 작성되어 있고, 다시 옮겨야 합니다.
251. **I still use most of the time when I use different frameworks or libraries or things like that.**
저도 여전히 여러 프레임워크나 라이브러리를 쓸 때 대부분 그렇습니다.
252. **They still have docs that are fundamentally written for humans.**
문서도 여전히 근본적으로 인간을 위해 쓰여 있습니다.
253. **This is my favorite pet peeve.**
이건 제가 가장 좋아하는 불만거리입니다.
254. **Like I don't Why are people still telling me what to do?**
왜 아직도 사람들이 저한테 뭘 하라고 말하는 거죠?
255. **Like I don't want to do anything.**
저는 아무것도 하고 싶지 않은데요.
256. **What is the thing I should copy paste to my agent?**
에이전트에게 복사해서 붙여넣을 것은 무엇인가요?
257. **>> >> So it's just every time I'm told, you know, go to this URL or something like that.**
그래서 누가 저에게 “이 URL로 가라” 같은 말을 할 때마다 늘 답답합니다.
258. **It's just like ah.**
그냥 아, 하고 한숨이 나옵니다.
259. **>> >> You know.**
아시겠죠.
260. **So um everyone is I think excited about how do we decompose the workloads that need to happen into fundamentally sensors over the world, actuators over the world.**
그래서 저는 모두가, 실제로 필요한 작업을 세계를 감지하는 센서와 세계에 작용하는 액추에이터로 어떻게 분해할지에 대해 기대하고 있다고 생각합니다.
261. **How do we make it agent native?**
어떻게 하면 그것을 에이전트 네이티브하게 만들 수 있을까요?
262. **Basically describe it to agents first.**
기본적으로 먼저 에이전트에게 설명하는 것입니다.
263. **Um then I have a lot of automation around you know, the Yeah, around data structures that are very legible to the LLMs.**
그리고 저는 LLM이 잘 읽을 수 있는 데이터 구조를 중심으로 많은 자동화를 해 두었습니다.
264. **So I think yeah, I'm hoping that there's a lot of agent first infrastructure out there and that you know, for MenuGen famously when I wrote the not I'm not sure how famously, but when I wrote the blog post about MenuGen a lot of the work a lot of the trouble was not even writing the code for MenuGen.**
그래서 저는 에이전트 우선 인프라가 많이 나오길 바랍니다. MenuGen 이야기를 하자면, 그걸 소개하는 블로그 글을 썼을 때, 문제의 상당수는 MenuGen 코드를 쓰는 데 있는 것이 아니었습니다.
265. **It was deploying it on Vercel because I had to work with all these different services and I just string them up and I just go to their settings and the menus, and you know, configure my DNS, and it was just so annoying.**
Vercel에 배포하는 과정이 더 문제였습니다. 여러 서비스들을 연결해야 했고, 그 설정 메뉴들을 일일이 열어 보고 DNS를 구성해야 했는데, 정말 너무 번거로웠습니다.
266. **And so, that's a good example of I would hope that MenuGen that I could give a prompt to an LLM, build MenuGen, and then I didn't have to touch anything, and it's deployed in that same way on the internet.**
그래서 좋은 예는, LLM에게 프롬프트만 주면 MenuGen을 만들고, 저는 아무것도 건드릴 필요 없이 인터넷에 그대로 배포되는 것입니다.
267. **I think that would be a good kind of a test for whether or not a lot of our infrastructure is becoming more and more agent native.**
저는 그것이 우리의 많은 인프라가 점점 더 에이전트 네이티브해지고 있는지 판단하는 좋은 시험이 될 것이라고 생각합니다.
268. **And then ultimately, I would say yeah, I I do think we're going towards a world where there's agent representation for people and for organizations, and um you know, I'll have my agent talk to your agent to figure out some of the details of our meetings or things like that.**
그리고 궁극적으로는 사람과 조직 모두를 위한 에이전트 대리 시스템의 세계로 가고 있다고 생각합니다. 제 에이전트가 당신의 에이전트와 대화해서 회의 세부사항 같은 것을 정리하는 식이 될 것입니다.
269. **So, >> >> um I do think that that's roughly where things are going, but um yeah, I think everyone here is excited about that.**
그래서 대체로 그 방향으로 가고 있다고 생각하지만, 네, 여기 계신 모두가 그 점에 기대를 갖고 있다고 봅니다.
270. **I really like the visual analogy of sensors and actuators. I actually hadn't thought of that. That's super interesting.**
센서와 액추에이터라는 시각적 비유가 정말 마음에 듭니다. 저는 사실 그걸 생각해 본 적이 없어서, 매우 흥미롭습니다.
271. **>> Right.**
맞습니다.
272. **Um okay, I think we have to end on a question about education, um because you are probably one of the very best in the world at making complex technical concepts simple and deeply thoughtful about how we design education around it.**
자, 교육에 대한 질문으로 마무리해야 할 것 같습니다. 당신은 아마도 복잡한 기술 개념을 단순하게 풀어내는 데 세계 최고 수준의 한 사람이고, 그것을 바탕으로 교육을 어떻게 설계할지에 대해서도 깊이 생각해 온 분이기 때문입니다.
273. **Um what still remains worth learning deeply when intelligence gets cheap as we move into the next era of AI?**
AI의 다음 시대에 지능이 저렴해질 때, 여전히 깊이 배울 가치가 있는 것은 무엇일까요?
274. **Yeah.**
네.
275. **Uh there was a tweet that blew my mind recently, and I keep thinking about it like every other day.**
최근 제 ذهن을 완전히 흔든 트윗이 하나 있었는데, 저는 거의 이틀에 한 번씩 그 생각을 하고 있습니다.
276. **It was something along the lines of um you can outsource your thinking, but you can't outsource your understanding.**
대략 “생각은 외주를 줄 수 있지만, 이해는 외주를 줄 수 없다”는 내용이었습니다.
277. **And um I think that's really nicely put.**
저는 그 말이 정말 잘 표현했다고 생각합니다.
278. **I so yeah, because I still I'm still part of the system, and I still I still have to somehow information still has to make it into my brain, and I feel like I'm becoming a bottleneck of just even knowing what we're trying to build, why is it worth doing, uh how do I direct you know, how do I direct my my agents, and so on.**
네, 왜냐하면 저도 여전히 시스템의 일부이고, 정보는 여전히 제 뇌로 들어와야 하기 때문입니다. 저는 우리가 무엇을 만들고 있는지, 왜 그것을 해야 하는지, 그리고 제 에이전트들을 어떻게 이끌어야 하는지조차 제가 병목이 되는 느낌을 받습니다.
279. **So, I do still think that ultimately something has to direct the thinking and the processing, and so on.**
그래서 결국에는 어떤 존재가 생각과 처리를 이끌어야 한다고 여전히 생각합니다.
280. **And um that's still kind of fundamentally constrained somehow by understanding.**
그리고 그것은 어떤 의미에서 여전히 이해라는 것에 근본적으로 제약됩니다.
281. **And this is one reason I also was very excited about all the all the knowledge bases because I feel like that's that's a way for me to process information.**
이 때문에 저는 지식베이스들에도 매우 기대가 컸습니다. 그것이 제가 정보를 처리하는 방법이라고 느꼈기 때문입니다.
282. **And anytime I see a different projection onto information, I always like feel like I gain insight.**
그리고 정보를 다른 방식으로 투영해 보는 걸 볼 때마다, 저는 늘 통찰을 얻는 느낌을 받습니다.
283. **So, it's really just a lot of prompts for me to do synthetic data generation kind of over over some fixed data.**
그래서 제게는 고정된 데이터 위에서 합성 데이터 생성을 하게 만드는 여러 프롬프트와 같습니다.
284. **Uh, I so I really enjoy uh whenever I read an article, I have my uh you know, my wiki that's being built up from these articles.**
저는 글을 읽을 때마다 그 글들로부터 제 위키가 쌓여 가는 것을 정말 즐깁니다.
285. **And I love asking questions about things or um and I I think that ultimately these are tools to enhance understanding in a certain way.**
저는 어떤 것에 대해 질문하는 것을 좋아하고, 결국 이런 도구들은 어떤 방식으로든 이해를 강화하는 수단이라고 생각합니다.
286. **And this is still kind of like a bit of a bottleneck because then you can't direct the uh you you can't be a good director if you still uh cuz the LLMs certainly don't excel at understanding.**
그리고 이것은 여전히 약간의 병목입니다. LLM들이 분명 이해에는 능하지 않기 때문에, 당신이 이해하지 못하면 제대로 지휘할 수 없습니다.
287. **You still are uniquely in charge of that.**
그 부분은 여전히 당신만이 책임질 수 있습니다.
288. **So, uh yeah, I think uh tools to that effect I think are incredibly interesting and exciting.**
그래서 그런 목적의 도구들은 정말 흥미롭고 기대된다고 생각합니다.
289. **I'm excited to be back here in a couple years and to see if we've been fully automated out of the loop and they actually take care of understanding as well.**
몇 년 뒤에 다시 이곳에 와서, 우리가 완전히 루프에서 빠지고 그들이 이해까지 맡게 되었는지 보게 되기를 기대합니다.
290. **Uh thank you so much for joining us, Andre.**
함께해 주셔서 정말 감사합니다, 안드레.
291. **We really appreciate it.**
정말 감사드립니다.