Sequoia Ascent 2026에서 진행한 파이어사이드 챗(fireside chat) 영상을 유튜브에 공개했습니다. 이번에 한 가지 실험을 해봤는데, 최근에 작성한 블로그 글과 트윗을 LLM에 모두 학습시킨 뒤, 해당 영상의 스크립트를 읽혀서 두 가지 결과물을 뽑아냈습니다. 하나는 내용 요약이고, 다른 하나는 전사 오류를 교정한 정제 스크립트입니다.
최근 Sequoia Ascent 2026에서 Stephanie Zhan과 파이어사이드 챗을 진행하며, AI 에이전트의 최근 변화와 그것이 소프트웨어에 미치는 의미, 그리고 차세대 AI 네이티브 기업을 어떻게 바라보는지에 대해 창업자들과 이야기를 나눴습니다.
행사 녹취록이 다소 지저분한 편이라, 핵심 내용을 좀 더 깔끔하게 정리하고 싶었습니다. 한마디로 요약하자면, 우리는 새로운 임계점을 넘었다고 생각합니다. LLM은 더 이상 단순한 챗봇이나 자동완성 도구가 아닙니다. 디지털 업무를 위한 새로운 프로그래밍 계층으로 진화하고 있습니다.
이 글은 대화의 핵심을 압축한 버전입니다.
최근 저는 프로그래머로서 이렇게 뒤처진 느낌을 받은 적이 없다고 말했습니다.
프로그래밍 자체가 예전보다 어려워진 게 아닙니다. 문제는 기본 워크플로가 바뀌었다는 점입니다. 2025년 대부분의 기간 동안, Claude Code나 Codex, Cursor 같은 에이전트 도구들은 유용하긴 했지만 잦은 수정이 필요했습니다. 그런데 2025년 12월 무렵, 확연한 변화를 느꼈습니다. 생성된 코드의 단위가 더 커지고, 더 일관성 있고 믿을 만해진 것입니다. 저는 점점 더 많은 작업을 에이전트에게 맡기기 시작했습니다.
프로그래밍의 단위가 코드 한 줄 한 줄을 직접 타이핑하는 것에서, 더 큰 '매크로 액션'을 위임하는 방식으로 바뀌었습니다:
이것이 제가 이 직업이 재편되고 있다고 생각하는 이유입니다. 프로그래머는 단순히 코드를 작성하는 사람을 넘어, 점점 에이전트를 조율하는 오케스트레이터로 변해가고 있습니다.
저는 이것을 일련의 흐름 속에서 다음 단계로 봅니다:
소프트웨어 3.0에서는 컨텍스트 윈도우가 핵심 레버가 됩니다. LLM은 그 컨텍스트를 해석하는 인터프리터로서, 디지털 정보 공간에서 연산을 수행합니다.
설치를 예로 들어보겠습니다. 기존 방식에서는 다양한 환경에 복잡한 도구를 설치하려면, 수많은 조건문으로 가득 찬 취약한 셸 스크립트가 필요했습니다. 소프트웨어 3.0 방식에서는 설치 과정 자체가 에이전트에 붙여 넣는 텍스트 블록이 됩니다. 에이전트가 로컬 환경을 파악하고, 오류를 디버깅하며, 해당 시스템에 맞게 스스로 적응해 설치를 완료합니다.
이것은 전혀 다른 종류의 프로그램입니다. 정밀함은 다소 떨어지지만, 그 대신 훨씬 유연합니다.
저는 MenuGen을 더 깊은 변화를 보여주는 사례로 들었습니다.
MenuGen은 전형적인 웹 앱이었습니다. 식당 메뉴 사진을 찍으면 OCR로 메뉴 이름을 추출하고, 이미지를 생성한 뒤 UI에 결과를 렌더링하는 방식이었습니다. 프론트엔드 코드, API, 이미지 생성, 배포, 인증, 결제, 시크릿 관리, 인프라까지 모든 것이 필요했습니다.
그런데 나중에 소프트웨어 3.0 버전을 보게 됐습니다. 메뉴 사진을 찍어서 멀티모달 모델에 넘기고, 메뉴 이미지 위에 직접 음식 사진을 렌더링해달라고 요청하는 것이 전부였습니다.
이 방식에서는 앱의 상당 부분이 사라집니다. 신경망이 입력 미디어를 출력 미디어로 직접 변환합니다. 기존 소프트웨어 스택 전체가 사실은 모델이 이제 직접 수행할 수 있는 변환을 위한 발판에 불과했던 셈입니다.
창업자들에게 가장 중요한 시사점 중 하나가 바로 이것입니다. AI는 단순히 기존 앱을 더 빠르게 만드는 도구가 아닙니다. 어떤 앱은 아예 앱으로서 존재하기를 멈춰야 합니다.
이 변화는 코딩에만 국한된 이야기가 아닙니다. LLM은 이전에는 프로그래밍할 수 없었던 정보 처리 방식 자체를 자동화합니다.
제가 만든 LLM 위키 패턴이 가장 좋은 예입니다. 질문이 들어올 때마다 원본 문서에서 RAG(검색 증강 생성)로 답하는 방식 대신, 에이전트가 원본 자료를 점진적으로 정리해 지속적인 마크다운 위키로 컴파일합니다. 요약, 엔티티 페이지, 개념 페이지, 모순점, 교차 링크, 로그, 발전하는 종합 정리까지 모두 담깁니다.
기존 프로그램으로는 지저분한 인간의 문서들에서 이런 종류의 지식 베이스를 안정적으로 유지하는 것이 불가능했습니다. 하지만 LLM은 할 수 있습니다.
교훈은 이겁니다. "AI로 어떤 기존 워크플로를 더 빠르게 할 수 있을까?"만 묻지 말고, "이전에는 불가능했지만 이제는 자연스럽게 가능한 정보 변환은 무엇인가?"도 함께 물어야 합니다.
자동화에 관한 제 핵심 프레임워크는 이렇습니다:
어떤 작업에 자동화된 보상이나 성공 신호가 존재한다면, 모델은 그것을 반복 학습할 수 있습니다. 수학, 코딩, 테스트, 벤치마크, 게임, 그리고 많은 엔지니어링 작업이 이렇게 빠르게 향상되는 이유가 바로 이것입니다. 리셋이 가능하고, 반복 가능하며, 보상을 설계할 수 있기 때문입니다.
코딩 에이전트가 일반 챗봇 경험보다 훨씬 뛰어나게 느껴지는 것도 같은 이유입니다. 코딩은 모델에게 피드백을 줍니다. 테스트가 통과되거나 실패하고, 프로그램이 실행되거나 충돌하며, diff를 눈으로 확인하고, 벤치마크로 성능을 측정할 수 있습니다.
이 대화에서 검증 가능성 논제에 중요한 보완점이 하나 더해졌습니다.
모델의 역량은 단순히 어떤 작업이 검증 가능한지의 여부만으로 결정되지 않습니다. 해당 작업이 연구소의 훈련 과정—사후 훈련, 합성 데이터 생성, 강화학습 등—에서 얼마나 집중적으로 다뤄졌는지에도 달려 있습니다.
대략적인 공식으로 나타내면:
capability spike ~= verifiability x training attention x data coverage x economic value
체스가 좋은 예입니다. GPT-4의 체스 실력이 향상됐을 때, 이것이 반드시 전반적인 지능이 고르게 향상된 결과는 아닐 수 있습니다. 훈련 데이터 구성에 체스 데이터가 훨씬 더 많이 포함됐기 때문일 가능성도 있습니다.
이것이 중요한 이유는, 프론티어 모델에는 사용 설명서가 없기 때문입니다. 이 모델들은 사전 학습 데이터 구성, 강화학습 환경, 벤치마크 압력, 제품 우선순위, 경제적 인센티브의 산물입니다. 어떤 영역에서는 뛰어난 성능을 보이고, 다른 영역에서는 기이하게 동작합니다.
따라서 창업자가 실질적으로 던져야 할 질문은 이것입니다. 내 서비스는 모델이 잘 다루는 영역 위에 있는가?
작업이 검증 가능하고 집중적으로 훈련된 영역 안에 있다면, 모델은 빠르게 날아오를 수 있습니다. 그렇지 않다면, 놀랍도록 기본적인 부분에서 실패할 수 있습니다. 더 나은 컨텍스트, 도구, 파인튜닝, 자체 평가(eval), 또는 자체 강화학습 환경이 필요할 수 있습니다.
저는 서로 연관되어 있지만 다른 두 개념을 구분합니다:
바이브 코딩은 프로토타입이나 개인 도구에는 충분합니다. 에이전틱 엔지니어링은 진지한 팀이 필요로 하는 것입니다.
에이전틱 엔지니어는 생성된 코드를 그냥 받아들이지 않습니다. 스펙을 설계하고, 계획을 검토하며, diff를 살피고, 테스트를 작성하고, 평가 루프를 만들고, 권한을 관리하고, 워크트리를 격리하며, 품질을 유지합니다.
제 MenuGen 결제 버그가 좋은 예입니다. 에이전트는 Stripe 구매 내역과 Google 계정을 이메일 주소로 매칭하려 했습니다. 코드 자체는 그럴듯해 보이지만, 시스템 설계로서는 잘못된 것입니다. Stripe 이메일과 Google 로그인 이메일이 다를 수 있기 때문입니다. 영구적인 사용자 ID를 사용해야 한다고 주장하려면, 사람이 충분한 제품 및 엔지니어링 판단력을 갖추고 있어야 합니다.
핵심 역량은 모든 API 세부 사항을 외우는 것이 아닙니다. 텐서 라이브러리가 dim, axis, keepdim, reshape, permute 중 무엇을 사용하는지는 에이전트가 기억해줄 수 있습니다. 인간은 여전히 저장 방식, 뷰, 메모리 복사, 불변성, 동일성, 보안 경계, 시스템 구조와 같은 근본적인 개념을 이해하고 있어야 합니다.
에이전틱 엔지니어링이 새로운 전문 역량이라면, 채용도 그것을 직접 검증하는 방식으로 바뀌어야 합니다.
전통적인 코딩 퍼즐은 점점 시대에 뒤떨어지고 있습니다. 더 나은 면접은 이런 식일 것입니다. 에이전트를 활용해 실질적인 프로젝트를 만들고, 배포하고, 보안을 갖추게 한 다음, 적대적 에이전트들이 이를 공격하게 해보는 것입니다.
이것이 진짜 역량을 검증합니다:
예전에 회자되던 '10배 엔지니어' 개념이 훨씬 극단적인 형태로 실현될 수 있습니다. 에이전틱 워크플로를 완전히 익힌 사람들은 다른 사람들보다 10배를 훨씬 뛰어넘는 성과를 낼 수 있습니다.
창업자들에게 중요한 기회 중 하나는, 가치 있고 검증 가능하면서도 프론티어 연구소가 아직 집중적으로 다루지 않은 도메인을 찾는 것입니다.
모델이 행동을 시도하고 안정적인 보상을 받을 수 있는 도메인 특화 환경을 직접 만들 수 있다면, 기본 모델이 해당 영역에서 아직 뛰어나지 않더라도 파인튜닝이나 강화학습으로 성능을 끌어올릴 수 있을 것입니다.
코딩과 수학처럼 가장 명확한 도메인은 이미 연구소들이 집중적으로 공략하고 있습니다. 하지만 경제적으로 중요한 많은 도메인에는, 아직 활용되지 않은 잠재적인 검증 가능 구조가 숨어 있을 수 있습니다.
그것이 바로 스타트업의 진입 쐐기입니다.
현재 대부분의 소프트웨어는 여전히 화면을 클릭하는 인간을 위해 만들어져 있습니다.
문서에는 "이 URL로 이동해서, 이 버튼을 클릭하고, 이 설정 패널을 여세요" 같은 내용이 적혀 있습니다. 하지만 점점 더 직접 사용하는 주체는 인간이 아닙니다. 인간의 에이전트입니다.
이는 곧 제품이 에이전트 네이티브 인터페이스를 갖춰야 함을 의미합니다:
저는 이것을 센서와 액추에이터의 관점으로 생각합니다. 센서는 세상의 어떤 상태를 디지털 정보로 변환하고, 액추에이터는 에이전트가 무언가를 변경할 수 있게 해줍니다. 미래의 스택은 에이전트가 사람과 조직을 대신해 센서와 액추에이터를 활용하는 방식이 될 것입니다.
MenuGen 배포 경험은 여전히 좋은 기준점이 됩니다. 앱을 만드는 것보다 Vercel 연동, 인증, 결제, DNS, 시크릿, 프로덕션 설정을 하나하나 연결하는 것이 훨씬 힘들었습니다. 성숙한 에이전트 네이티브 세계라면, "MenuGen 만들어줘"라고 말하면 에이전트가 수동 클릭 없이 전체를 배포할 수 있어야 합니다.
제가 제안한 동물 vs. 유령 프레임은 잘못된 직관을 피하기 위한 것입니다.
LLM은 동물이 아닙니다. 생물학적 본능, 신체적 생존 압력, 호기심, 유희, 혹은 동물적 의미의 내재적 동기가 없습니다. 이들은 사전 학습, 사후 훈련, 강화학습, 제품 피드백, 경제적 인센티브에 의해 형성된, 인간 산출물의 통계적 시뮬레이션입니다.
이것이 중요한 이유는, 인간처럼 다루려는 기대가 우리를 오도하기 때문입니다. 이 시스템들은 어떤 순간에는 탁월하다가 다음 순간에는 기이할 정도로 허술할 수 있습니다. 매끄러운 인간의 지성이 아닙니다. 들쭉날쭉하고 낯선 도구입니다.
올바른 자세는 무시도 맹목적인 신뢰도 아닙니다. 경험적 친숙함입니다. 어디서 잘 작동하고 어디서 실패하는지, 무엇을 위해 훈련됐는지, 어떻게 가드레일을 설계할지를 파악하는 것입니다.
마지막은 교육으로 마무리했습니다. 제가 계속 떠올리는 문장이 있습니다:
생각은 위임할 수 있어도, 이해는 위임할 수 없습니다.
에이전트가 더 많은 일을 하더라도, 에이전트를 올바르게 방향 제시하려면 인간의 이해가 여전히 필요합니다. 무엇을 만들 가치가 있는지, 어떤 질문이 중요한지, 어떤 결과가 수상한지, 어떤 트레이드오프가 허용 가능한지를 알아야 합니다.
이것이 제가 LLM 지식 베이스에 주목하는 이유입니다. 단순히 답을 내놓는 기계가 아닙니다. 정보를 이해로 변환하는 도구입니다.
이것은 제 소규모 microGPT 프로젝트와도 연결됩니다. 단일 의존성 없는 파이썬 파일 하나에 GPT 학습과 추론 구현 전체를 담은 것입니다. 교육용 산출물이 인간과 에이전트 모두가 살펴볼 수 있을 만큼 작아집니다. 인간 전문가는 정제된 산출물과 그 뒤에 담긴 안목을 제공하고, 에이전트는 각 학습자에게 이를 대화형으로 설명해줄 수 있습니다.
이 대화의 핵심 논지는, AI가 디지털 업무를 위한 새로운 운영 계층이 되고 있다는 것입니다.
희소성의 중심이 이동하고 있습니다:
창업자들에게 가장 중요한 질문은 다음과 같습니다:
제 현재 세계관은, AI가 단순히 모든 사람이 기존 업무를 더 빠르게 하도록 돕는다는 것이 아닙니다. 업무 자체가 에이전트 중심으로 재편되고 있습니다. 소프트웨어, 연구, 교육, 인프라, 지식 업무 모두가 동일한 패턴의 변형이 되어가고 있습니다:
define the context
define the tools
define the feedback loop
define the guardrails
let agents work
preserve human understanding
편집된 스크립트. 가독성을 위해 가볍게 정리했으며, 명백한 전사 오류를 수정하고 군더더기 표현을 제거했으며, 관련 링크를 일부 추가했습니다.
Konstantine: 여러분 모두 잘 아시는 분입니다. 이 AI 혁명 속에서 AI의 선생님이 된 분이죠. 모든 혁명에는 기술자가 있지만, 교사도 있습니다. 이 변화가 어떻게 일어나는지를 실제로 알려주고 가르쳐주는 사람이요. Andrej가 바로 그 역할을 전 세계적으로 해주고 있습니다.
Tesla 오토파일럿 초창기 멤버이자 OpenAI 공동 창업자인 그는 모든 것을 내려놓고 Eureka Labs를 창업해, 진정한 AI 강사라는 아이디어를 실현하는 데 온전히 뛰어들었습니다. 파트너 Stephanie Zhan과 함께하는 Andrej Karpathy를 환영합니다.
Stephanie: 안녕하세요 여러분. 첫 번째 특별 게스트를 모시게 돼서 기쁩니다. 현대 AI를 직접 만들고, 설명하고, 때로는 이름을 붙이기도 한 분입니다.
OpenAI 공동 창업에 참여했고, Tesla 오토파일럿 구현을 이끌었으며, 가장 복잡한 기술적 전환을 누구나 이해할 수 있으면서도 필연적으로 느껴지도록 만드는 보기 드문 재능을 가진 분입니다.
지난해 바이브 코딩이라는 용어를 만든 것으로 유명하지만, 불과 몇 달 전에는 더욱 충격적인 말을 했습니다. 프로그래머로서 이렇게 뒤처진 느낌을 받은 적이 없다고요. 오늘은 바로 그 이야기에서 시작하겠습니다. Andrej, 함께해 주셔서 감사합니다.
Andrej: 안녕하세요. 함께하게 돼서 기쁩니다.
Stephanie: 몇 달 전에 프로그래머로서 이렇게 뒤처진 느낌을 받은 적이 없다고 하셨는데요. 무엇보다 Andrej 씨 입에서 그런 말이 나왔다는 게 놀랍습니다. 그 감정이 어디서 온 건지 풀어주실 수 있나요? 설레는 느낌이었나요, 아니면 불안한 느낌이었나요?
Andrej: 둘 다 섞여 있었습니다.
여러분처럼 저도 꽤 오랫동안, 아마 지난 1년 동안 Claude Code, Codex, 그리고 비슷한 에이전틱 도구들을 사용해왔습니다. 코드 덩어리 단위로는 아주 잘 작동했지만, 가끔 실수를 해서 직접 수정해야 했습니다. 그래도 도움이 됐습니다.
그러다 12월이 분명한 전환점이 됐습니다. 휴가 중이라 시간이 더 있었는데, 비슷한 경험을 한 분들이 많을 것 같습니다. 최신 모델로 작업하다 보니, 코드 덩어리들이 그냥 잘 나왔습니다. 더 많은 것을 요청해도 여전히 잘 됐습니다. 마지막으로 수정한 게 언제인지도 기억나지 않았습니다. 점점 더 시스템을 신뢰하게 됐습니다.
분명히 확연한 변화였습니다. 많은 분들이 지난해 AI를 ChatGPT 비슷한 것으로 경험하셨겠지만, 12월부터는 다시 한번 제대로 봐야 했습니다. 특히 에이전틱하고 일관된 워크플로 측면에서 근본적으로 달라졌으니까요. 진짜로 작동하기 시작한 겁니다.
그 깨달음이 저를 끝없는 사이드 프로젝트의 토끼굴로 이끌었습니다. 사이드 프로젝트 폴더가 온갖 것들로 가득 찼습니다. 12월 내내 코딩에 매달렸고, 그 파장을 계속 지켜보고 있습니다.
Stephanie: LLM을 새로운 컴퓨터라고 표현하셨는데요. 단순히 더 나은 소프트웨어가 아니라 새로운 컴퓨팅 패러다임이라고요. 소프트웨어 1.0은 명시적 규칙, 2.0은 학습된 가중치, 3.0은 바로 지금 이것이라면, 그 말을 진심으로 믿는 팀은 다음 날부터 무엇을 다르게 만들어야 할까요?
Andrej: 소프트웨어 1.0은 코드를 작성하는 것입니다. 소프트웨어 2.0은 데이터셋을 만들고 신경망을 훈련시켜서 프로그래밍하는 것이고요. 프로그래밍이 데이터셋, 목적 함수, 신경망 구조를 설계하는 일이 됩니다.
그 다음에 일어난 일은, GPT 모델이나 LLM을 충분히 다양한 태스크로 훈련시키면—인터넷에는 수많은 태스크가 담겨 있으니까요—이 모델들이 어떤 의미에서 프로그래밍 가능한 컴퓨터가 된다는 것입니다.
소프트웨어 3.0은 프롬프팅을 통해 프로그래밍하는 것입니다. 컨텍스트 윈도우에 담긴 내용이 인터프리터에 대한 레버가 되고, 그 인터프리터가 바로 LLM입니다. LLM은 컨텍스트를 해석하고 디지털 정보 공간에서 연산을 수행합니다.
이것을 실감하게 해준 예시가 몇 가지 있습니다. OpenClaw가 나왔을 때, 설치하려면 보통 셸 스크립트를 기대하게 됩니다. 그런데 다양한 플랫폼과 환경을 지원하려다 보면 셸 스크립트가 엄청나게 복잡해집니다. 정확한 코드를 작성해야 하는 소프트웨어 1.0의 세계에 갇히게 됩니다.
OpenClaw 설치는 대신 에이전트에 복사해 붙여넣는 텍스트 블록이었습니다. 일종의 스킬처럼요. "이걸 복사해서 에이전트에게 주면 OpenClaw를 설치해줍니다." 이것이 훨씬 강력합니다. 소프트웨어 3.0 패러다임에서 작동하기 때문입니다. 모든 세부 사항을 일일이 명시할 필요가 없습니다. 에이전트가 지능을 갖고 있고, 환경을 살펴보고, 지능적인 행동을 취하며, 루프 안에서 디버깅합니다.
이것이 다른 방식의 사고입니다. "에이전트에게 복사해서 붙여넣을 텍스트는 무엇인가?" 이 질문 자체가 이제 프로그래밍 패러다임의 일부입니다.
또 다른 예가 MenuGen입니다. 식당에 앉아서 메뉴를 받았는데 사진이 없는 경우가 있죠. 뭔지 잘 모르는 음식들이 많습니다. 메뉴 사진을 찍으면 그 음식들이 어떻게 생겼는지 이미지로 볼 수 있으면 좋겠다 싶었습니다.
그래서 앱을 만들었습니다. 사진을 업로드하면 메뉴 이름을 OCR로 추출하고, 이미지 생성기로 사진을 가져온 뒤 보여주는 방식이었습니다. Vercel에서 실행되며 메뉴를 재렌더링합니다.
그러다 소프트웨어 3.0 버전을 보게 됐는데, 정말 충격이었습니다. 사진을 찍어서 Gemini에게 주고, Nano Banana를 써서 메뉴 위에 항목들을 오버레이해달라고 합니다. 그러면 제가 찍은 메뉴 이미지에 음식 사진들이 픽셀로 렌더링된 결과물이 돌아옵니다.
그 관점에서 보면 MenuGen 전체가 불필요합니다. 기존 패러다임에서 작동하는 것이었습니다. 그 앱은 존재해서는 안 됩니다. 소프트웨어 3.0 패러다임에서는 신경망이 더 많은 일을 합니다. 프롬프트나 컨텍스트가 이미지이고, 출력도 이미지입니다. 중간에 있던 앱 기계장치 전체가 필요 없어집니다.
사람들이 프레임을 바꿔야 합니다. 기존 패러다임에서만 생각하며 AI를 기존 것의 속도 향상으로만 볼 것이 아니라, 이제 새롭게 가능해진 것들을 봐야 합니다.
그리고 단순히 프로그래밍이 빨라지는 것이 아닙니다. 이제 자동화 가능한 훨씬 더 일반적인 정보 처리의 이야기입니다. 이전 코드는 구조화된 데이터 위에서 작동했습니다.
제 LLM 지식 베이스 프로젝트를 보면, LLM을 활용해 조직이나 개인을 위한 위키를 만드는 것입니다. 이건 예전 의미의 프로그램이 아닙니다. 지저분한 사실들의 묶음을 바탕으로 지식 베이스를 만드는 코드는 존재하지 않았습니다. 하지만 이제는 문서들을 가져다가 재구성하고, 재정렬하고, 데이터를 새롭게 프레이밍한 흥미로운 것을 만들어낼 수 있습니다.
이전에는 불가능했던 새로운 것들입니다. 저는 계속 이 질문으로 돌아옵니다. 더 빠르게 할 수 있는 것뿐만 아니라, 이전에는 불가능했는데 이제 가능한 것은 무엇인가? 그것이 더 흥미롭습니다.
Stephanie: MenuGen의 발전 과정이 인상적입니다. 더 멀리 외삽해보면, 90년대 웹사이트 구축, 2010년대 모바일 앱, 클라우드 시대 SaaS에 해당하는 2026년의 등가물은 무엇일까요? 지금 대부분 아직 만들어지지 않았지만, 나중에 당연해 보일 것은 무엇일까요?
Andrej: MenuGen 예시를 이어가자면, 많은 코드가 존재해서는 안 됩니다. 신경망이 대부분의 일을 해야 합니다.
그 외삽은 꽤 낯설게 보입니다. 완전한 신경 컴퓨터를 상상할 수 있습니다. 원시 비디오나 오디오를 신경망으로 받아들이고, 그 순간에 고유한 UI를 디퓨전으로 렌더링하는 기기를 상상해보세요.
초기 컴퓨팅 시대에는 컴퓨터가 계산기처럼 생길지 신경망처럼 생길지 사람들이 헷갈려 했습니다. 1950~60년대에는 어느 방향이 될지 명확하지 않았습니다. 우리는 계산기 경로를 걸어서 고전 컴퓨팅을 구축했습니다.
신경망은 현재 기존 컴퓨터 위에서 가상화되어 실행되고 있습니다. 하지만 신경망이 호스트 프로세스가 되고 CPU가 코프로세서가 되는 역전을 상상할 수 있습니다. 지능 연산과 신경망 연산이 FLOPs의 지배적인 사용처가 되는 것이죠.
신경망이 대부분의 무거운 작업을 담당하고, 결정론적 작업을 위한 역사적 흔적으로서 기존 도구를 활용하는 낯선 세계를 상상할 수 있습니다. 실제로 돌아가는 것은 어떤 방식으로 네트워크된 신경망입니다.
이것이 외삽이지만, 우리는 조금씩 그쪽으로 나아가리라 생각합니다.
Stephanie: 검증 가능성에 대해 이야기해보고 싶습니다. 출력을 검증할 수 있는 도메인에서 AI가 더 빠르고 쉽게 자동화할 것이라는 아이디어 말이죠. 그 프레임이 맞다면, 사람들이 생각하는 것보다 훨씬 빠르게 발전할 영역은 어디이고, 안전하다고 생각하지만 실제로는 높은 검증 가능성을 가진 직종은 어디일까요?
Andrej: 전통적인 컴퓨터는 코드로 명세화할 수 있는 것을 자동화합니다. 최근의 LLM들은 검증할 수 있는 것을 자동화할 수 있습니다.
프론티어 연구소들이 LLM을 훈련시킬 때, 검증 보상이 있는 거대한 강화학습 환경에서 훈련합니다. 그 때문에 모델들은 발전하면서 들쭉날쭉한 존재가 됩니다. 수학, 코드, 인접 영역처럼 검증 가능한 도메인에서는 역량이 정점에 달하고, 그렇지 않은 영역에서는 정체되거나 거칠게 남습니다.
검증 가능성에 대해 쓴 것은 이 들쭉날쭉함을 이해하려 했기 때문입니다. 일부는 연구소들이 모델을 훈련하는 방식과 관련이 있습니다. 일부는 연구소들이 무엇에 집중하고 어떤 데이터를 분포에 넣는지와도 관련이 있습니다. 경제적으로 더 가치 있는 영역에는 연구소들이 더 많은 환경을 만들어줍니다. 코드가 좋은 예입니다.
이 믹스에 포함되지 않은 검증 가능한 환경들이 아마 많이 있을 것입니다. 경제적으로 그 역량이 그다지 유용하지 않아서 그런 것이죠.
즐겨 드는 예로, "strawberry"에 글자가 몇 개인가? 라는 질문이 있었습니다. 모델들이 악명 높게 틀렸는데, 지금은 수정됐습니다. 더 최근 예는 이렇습니다. 50미터 떨어진 세차장에 차를 세차하러 가려 하는데, 운전해서 가야 할까요, 걸어가야 할까요? 최신 모델이 가깝다는 이유로 걸어가라고 할 수도 있습니다.
10만 줄 코드베이스를 리팩터링하거나 제로데이 취약점을 찾아낼 수 있는 최첨단 모델이, 세차장까지 걸어가라고 할 수 있다는 게 어떻게 가능한 걸까요? 이게 들쭉날쭉함입니다. 모델이 들쭉날쭉한 한, 루프에 인간이 있어야 합니다. 도구로 다루고, 무엇을 하는지 계속 확인해야 합니다.
검증 가능성에 대한 글은 이 패턴을 이해하려는 시도입니다. "검증 가능하다"와 "연구소가 신경 쓴다"의 어떤 조합인 것 같습니다.
또 다른 일화는 체스입니다. GPT-3.5에서 GPT-4로 넘어가면서 사람들이 체스 실력이 많이 향상됐음을 알아챘습니다. 어떤 사람들은 그게 그냥 전반적인 역량 발전이라고 생각했습니다. 하지만 대량의 체스 데이터가 사전 훈련 데이터에 포함됐다는 것은 이미 공개된 정보라고 생각합니다. 데이터 분포에 포함됐기 때문에, 모델이 기본값보다 훨씬 더 크게 향상된 것입니다.
OpenAI의 누군가가 그 데이터를 추가하기로 결정했고, 이제 역량 스파이크가 생겼습니다. 이것이 제가 이 차원을 강조하는 이유입니다. 우리는 어느 정도 연구소들이 무엇을 하고 어떤 것을 믹스에 넣는지에 달려 있습니다. 그들이 주는 모델을 탐색해야 합니다. 사용 설명서가 없습니다. 어떤 환경에서는 작동하고 다른 환경에서는 그렇지 않습니다.
강화학습에 포함된 회로 안에 있다면, 날아오릅니다. 데이터 분포 밖에 있다면, 고전합니다. 내 애플리케이션이 어떤 회로에 있는지 파악해야 합니다. 그 회로에 없다면, 파인튜닝이나 자체적인 추가 작업을 고려해야 합니다. LLM에서 그냥 나오지 않을 수도 있으니까요.
Stephanie: 오늘 창업자 입장에서, 다루기 가능하고 검증 가능한 문제를 풀고 있는데, 주변을 보니 연구소들이 수학이나 코딩 같은 명확한 도메인에서 이미 탈출 속도에 가까워지고 있다면, 어떤 조언을 해주시겠습니까?
Andrej: 검증 가능성이 현재 패러다임에서 어떤 것을 다룰 수 있게 만드는 이유는, 그것에 막대한 양의 강화학습을 쏟아부을 수 있기 때문입니다.
이것은 연구소들이 직접 집중하지 않더라도 여전히 사실입니다. 강화학습 환경이나 예시를 만들 수 있는 검증 가능한 환경에 있다면, 자체적으로 파인튜닝을 하고 그것으로부터 이익을 얻을 수 있습니다. 그 기술은 근본적으로 작동합니다. 다양한 데이터셋이나 RL 환경이 있다면, 파인튜닝 프레임워크를 사용하고 레버를 당기면, 꽤 잘 작동하는 무언가를 얻을 수 있습니다.
구체적인 예시를 드리고 싶지는 않지만, 현재 프론티어 연구소 믹스에 포함되지 않은 가치 있는 강화학습 환경들을 생각해볼 수 있습니다.
Stephanie: 반대로, 자동화 가능해 보이지만 아직 거리가 있는 것은 무엇인가요? 다른 것들보다 더 안전한 도메인이나 직종이 있을까요?
Andrej: 궁극적으로 거의 모든 것을 어느 정도는 검증 가능하게 만들 수 있습니다. 어떤 것은 더 쉽고 어떤 것은 더 어렵겠지만요. 글쓰기조차도 LLM 심사단을 구성해서 합리적인 결과를 얻는 것을 상상할 수 있습니다.
결국 쉽고 어려움의 문제입니다.
Stephanie: 작년에 바이브 코딩이라는 용어를 만드셨는데요. 지금은 더 진지하고 에이전틱 엔지니어링 느낌의 세계에 있는 것 같습니다. 둘의 차이는 무엇이고, 지금 우리가 있는 것을 뭐라고 부르시겠습니까?
Andrej: 바이브 코딩은 소프트웨어 측면에서 누구나 할 수 있는 것의 하한선을 높이는 것에 관한 겁니다. 누구든 무엇이든 바이브 코딩할 수 있고, 그건 놀라운 일입니다.
에이전틱 엔지니어링은 전문 소프트웨어의 품질 기준을 유지하는 것에 관한 겁니다. 바이브 코딩 때문에 취약점을 도입해서는 안 됩니다. 예전과 마찬가지로 자신의 소프트웨어에 여전히 책임이 있습니다. 더 빠르게 할 수 있을까요? 스포일러: 할 수 있습니다. 문제는 그것을 어떻게 제대로 하느냐입니다.
에이전틱 엔지니어링이라고 부르는 건, 이게 엔지니어링 규율이기 때문입니다. 에이전트들은 들쭉날쭉한 존재입니다. 오류 가능성이 있고 확률적이지만, 엄청나게 강력합니다. 품질 기준을 희생하지 않고 더 빠르게 나아가기 위해 이것들을 어떻게 조율하느냐가 핵심입니다.
바이브 코딩은 하한선을 높입니다. 에이전틱 엔지니어링은 상한선을 끌어올리는 것에 관한 겁니다. 에이전틱 엔지니어 역량의 상한선은 매우 높다고 생각합니다. 예전에 10배 엔지니어를 이야기했는데, 이게 훨씬 더 크게 증폭된다고 생각합니다. 10배가 사람들이 얻을 수 있는 속도 향상이 아닙니다. 이것에 매우 능숙한 사람들은 그것보다 훨씬 더 높은 정점에 도달할 수 있습니다.
Stephanie: 작년에 Sam Altman이 Ascent에 와서, 세대별로 ChatGPT를 다르게 사용한다고 했습니다. 30대는 Google 검색 대체로 쓰고, 10대에게 ChatGPT는 인터넷의 관문이라고요.
코딩에서 그에 해당하는 것은 무엇일까요? OpenClaw, Claude Code, Codex를 사용하는 두 사람을 본다면—한 명은 평범하고 한 명은 완전히 AI 네이티브라면—그 차이를 어떻게 설명하시겠습니까?
Andrej: 사용 가능한 도구들을 최대한 활용하고, 기능들을 쓰고, 자신의 셋업에 투자하는 것에 관한 겁니다.
엔지니어들은 항상 Vim이나 VS Code 같은 도구들로 이렇게 해왔습니다. 이제 도구가 Claude Code, Codex 등이 된 것입니다. 셋업에 투자하고 사용 가능한 것을 활용합니다.
관련해서 드는 생각이 채용입니다. 많은 사람들이 강력한 에이전틱 엔지니어를 채용하고 싶어 하지만, 대부분의 채용 프로세스는 에이전틱 엔지니어 역량에 맞게 개편되지 않았습니다. 여전히 작은 퍼즐을 내주고 있다면, 그건 여전히 옛날 패러다임입니다.
채용은 이런 식이어야 합니다. 큰 프로젝트를 주고 구현하게 해보는 것입니다. 예를 들어, 에이전트를 위한 트위터 클론을 만들되, 잘 만들고 보안도 갖추게 합니다. 그리고 에이전트들이 그 위에서 활동을 시뮬레이션하게 합니다. 그런 다음 열 개의 Codex 에이전트를 써서 배포한 웹사이트를 뚫으려 할 것이고, 뚫려서는 안 됩니다.
그 환경에서 사람들이 더 큰 프로젝트를 만들고 도구를 활용하는 것을 지켜보는 것이, 제가 찾는 것에 더 가깝습니다.
Stephanie: 에이전트가 더 많은 일을 할수록, 줄어들지 않고 오히려 더 가치 있어지는 인간 역량은 무엇일까요?
Andrej: 지금 에이전트들은 인턴 같습니다. 미학, 판단, 안목, 감독은 여전히 인간이 맡아야 합니다.
제가 가장 좋아하는 예가 MenuGen에서 나왔습니다. Google 계정으로 가입하지만, Stripe로 크레딧을 구매합니다. 둘 다 이메일 주소가 있습니다. 제 에이전트는 Stripe 이메일 주소와 Google 이메일 주소를 매칭해서 구매한 크레딧을 할당하려 했습니다.
그런데 그 이메일들이 다를 수 있습니다. 사용자가 구매한 크레딧을 받지 못할 수도 있습니다. 왜 이메일 주소를 써서 자금을 교차 확인하려 하겠습니까? 영구 사용자 ID가 필요합니다. 에이전트들이 여전히 이런 실수를 합니다.
사람들이 스펙과 계획을 책임져야 합니다. "플랜 모드"라는 개념 자체를 완전히 좋아하지는 않지만, 유용하긴 합니다. 더 일반적인 것이 있습니다. 에이전트와 함께 상세한 스펙을 설계하고—거의 문서 수준으로—에이전트가 작성하게 합니다. 감독과 최상위 카테고리는 인간이 맡고, 에이전트들이 그 아래의 많은 작업을 합니다.
또 다른 예로, 신경망에서 텐서를 다룰 때 PyTorch, NumPy, pandas 등에 걸쳐 많은 세부 사항이 있습니다. dim 대 axis, reshape, permute, transpose, keepdim. 저는 이런 것들을 더 이상 외우지 않습니다. 외울 필요가 없으니까요. 이런 세부 사항은 에이전트 인턴이 처리합니다. 에이전트들은 recall이 좋습니다.
하지만 기초는 여전히 이해해야 합니다. 기저 텐서 스토리지가 있고, 같은 스토리지의 뷰를 조작할 수 있거나 다른 스토리지를 만들 수 있는데 그게 덜 효율적이라는 것을 알아야 합니다. 불필요하게 메모리를 복사하지 않으려면 여전히 충분히 이해하고 있어야 합니다.
따라서 안목, 엔지니어링, 설계, 그리고 시스템이 말이 되는지를 인간이 맡습니다. 올바른 것을 요청합니다. 예를 들어, 모든 것을 고유 사용자 ID에 연결하는 것. 에이전트들이 나머지를 채웁니다.
Stephanie: 시간이 지남에 따라 안목과 판단이 덜 중요해질까요, 아니면 상한선이 계속 높아질까요?
Andrej: 향상되길 바랍니다. 지금 향상되지 않는 이유는 아마도 강화학습에 포함되지 않았기 때문일 것입니다. 미학 보상이 없거나, 충분히 좋지 않은 것일 수 있습니다.
코드를 보면 가끔 심장이 내려앉습니다. 항상 놀라운 코드가 나오는 건 아닙니다. 부풀려지거나, 복사-붙여넣기되거나, 어색하게 추상화되거나, 취약할 수 있습니다. 작동은 하지만 보기 좋지 않습니다. 미래 모델에서 이것이 개선되길 바랍니다.
좋은 예가 제 microGPT 프로젝트입니다. LLM 훈련을 최대한 단순화하려 했는데, 모델들이 이걸 아주 싫어합니다. 못 합니다. LLM에게 계속 더 단순화하라고 프롬프트해봤는데, 그냥 안 됩니다. RL 회로 밖에 있는 느낌입니다. 이를 뽑는 것 같습니다.
그래서 지금은 사람들이 이것을 맡습니다. 하지만 향상을 막는 근본적인 이유가 있다고 생각하지 않습니다. 연구소들이 아직 하지 않은 것뿐입니다.
Stephanie: 들쭉날쭉한 형태의 지능으로 돌아와 보겠습니다. 동물 vs. 유령에 대한 글을 쓰셨는데요. 동물이 아닌 유령을 소환하고 있다고요. 데이터와 보상 함수에 의해 형성된, 하지만 진화가 동물을 형성한 방식의 내재적 동기, 재미, 호기심, 역량 강화가 없는 들쭉날쭉한 형태의 지능들.
그 프레임이 왜 중요한가요? 이것들을 구축하고, 배포하고, 평가하고, 신뢰하는 방식에 무엇이 달라지나요?
Andrej: 이것들이 무엇인지 이해하려다 보니 그 글을 쓰게 됐습니다. 이것들이 무엇이고 무엇이 아닌지에 대한 올바른 모델이 있다면, 활용하는 데 더 능숙해질 것입니다.
그 프레임이 직접적인 실용적 힘을 가지는지는 모르겠습니다. 조금 철학적입니다. 하지만 이것들이 동물의 지능이 아니라는 사실을 받아들이는 것에 관한 겁니다. 소리를 지른다고 더 잘하거나 못하게 되지 않습니다. 이것들은 통계적 시뮬레이션 회로입니다. 기반은 사전 학습이고, 그 위에 강화학습이 덧붙여진 것입니다.
마인드셋의 문제입니다. 내가 무엇과 상호작용하고 있는가, 무엇이 효과적일 것 같고 그렇지 않은가, 어떻게 수정할 것인가. 시스템을 더 좋게 만드는 다섯 가지 명확한 결과물이 있는 것이 아닙니다. 시스템에 대해 의심을 품고, 시간을 두고 경험적으로 파악해나가는 것에 더 가깝습니다.
Stephanie: 단순히 대화만 하는 것이 아니라, 실제 권한을 갖고, 로컬 컨텍스트가 있고, 실제로 대신 행동을 취하는 에이전트들과 깊이 작업하고 계십니다. 우리 모두가 그런 세계에서 살게 될 때, 세상은 어떤 모습일까요?
Andrej: 여기 계신 많은 분들이 에이전트 네이티브 환경이 어떤 모습일지 기대하고 계실 것입니다. 모든 것을 다시 써야 합니다. 대부분의 것들이 여전히 근본적으로 인간을 위해 만들어져 있습니다.
프레임워크나 라이브러리를 쓸 때, 문서는 여전히 인간을 위해 쓰여 있습니다. 제가 가장 좋아하는 불만이 이겁니다. 왜 아직도 내가 뭘 해야 하는지 알려주는 거죠? 저는 아무것도 하고 싶지 않습니다. 에이전트에게 복사-붙여넣기할 것이 무엇인가요?
"이 URL로 이동하세요"나 "여기를 클릭하세요"라는 말을 볼 때마다 생각합니다. 아니요. 업계가 세상에 대한 센서와 액추에이터로 워크로드를 분해해야 합니다. 어떻게 것들을 에이전트 네이티브로 만들 것인가? 에이전트에게 먼저 설명하고, LLM이 읽을 수 있는 데이터 구조로 자동화를 구축하는 방법은?
에이전트 퍼스트 인프라가 많이 나오길 바랍니다. MenuGen에서 어려운 부분은 코드를 작성하는 것이 아니었습니다. Vercel에 배포하고, 서비스를 연결하고, 설정, DNS, 인증, 결제, 시크릿, 프로덕션 구성을 처리하는 것이 문제였습니다.
LLM에게 "MenuGen 만들어줘"라고 하면, 아무것도 건드리지 않아도 인터넷에 배포돼 있으면 좋겠습니다. 그것이 우리 인프라가 에이전트 네이티브가 되고 있는지의 좋은 테스트가 될 것입니다.
궁극적으로 사람과 조직이 에이전트 대표성을 갖는 세계로 가고 있다고 생각합니다. 제 에이전트가 당신의 에이전트와 대화해서 미팅 세부 사항이나 다른 업무들을 처리하게 될 것입니다. 대략 그 방향으로 가고 있습니다.
Stephanie: 교육으로 마무리해야 할 것 같습니다. 복잡한 기술 개념을 단순하게 만드는 데 아마 세계 최고 중 한 분이시고, 교육에 대해 깊이 생각하시는 분이잖아요. 지능이 저렴해질 때, 여전히 깊이 배울 가치가 있는 것은 무엇인가요?
Andrej: 최근에 정말 머릿속을 떠나지 않는 트윗이 있었습니다:
생각은 위임할 수 있어도, 이해는 위임할 수 없습니다.
잘 표현된 말입니다. 저는 여전히 시스템의 일부입니다. 정보는 여전히 제 머릿속으로 들어와야 합니다. 우리가 무엇을 만들려 하는지, 왜 할 가치가 있는지, 어떻게 에이전트를 지시할지를 아는 것의 병목이 점점 저 자신이 되고 있습니다.
무언가가 여전히 사고와 처리를 지시해야 합니다. 그것은 이해에 의해 제약됩니다.
이것이 제가 LLM 지식 베이스에 흥미를 느끼는 이유 중 하나입니다. 정보를 처리하는 방법입니다. 정보에 대한 다른 투영을 볼 때마다, 통찰을 얻는 것 같습니다. 고정된 데이터에 대한 합성 데이터 생성인 셈입니다.
기사를 읽을 때, 그 기사들로부터 위키가 쌓여가고 있습니다. 거기에 질문을 던지는 것을 즐깁니다. 궁극적으로 이것들은 이해를 향상시키는 도구입니다. 잘 이해하지 못하면 좋은 지시자가 될 수 없으니, 이해가 여전히 병목입니다.
LLM은 이해에 완전히 뛰어나지 않습니다. 그것은 여전히 인간이 고유하게 맡는 영역입니다. 이해를 향상시키는 도구들은 그래서 더욱 흥미롭고 기대됩니다.
Stephanie: 몇 년 후에 다시 와서, 우리가 완전히 루프에서 자동화됐는지, 이해까지 챙겨주는지 확인하고 싶습니다. 정말 감사합니다, Andrej.
Andrej: 감사합니다.
Konstantine: Stephanie, Andrej, 정말 감사합니다.
