Andrej Karpathy 인터뷰, 바이브 코딩에서 에이전틱 엔지니어링으로

^{source aiacent}

인터뷰어: 오늘 첫 특별 게스트를 모시게 되어 정말 기쁩니다. 그는 현대 AI를 만드는 데 기여했고, 그것을 사람들에게 설명했으며, 때로는 그 흐름에 새 이름을 붙이기도 했습니다. 바로 이 사무실에서 OpenAI를 공동창업하는 데 함께했고, 초기 Tesla Autopilot이 제대로 작동하도록 만드는 데도 핵심 역할을 했죠. 작년에는 “바이브 코딩(vibe coding)”이라는 말을 만든 것으로 알려졌는데, 최근에는 그보다 더 놀라운 말을 했습니다. 프로그래머로서 어느 때보다 뒤처진 느낌을 받는다고요. 오늘은 그 이야기부터 시작해보겠습니다. Andrej, 함께해 주셔서 감사합니다.

Andrej Karpathy: 네, 안녕하세요. 오늘 이 자리를 함께 시작할 수 있어 기쁩니다.

인터뷰어: 몇 달 전, 프로그래머로서 어느 때보다 뒤처진 느낌이라고 말했습니다. 다른 사람도 아니고 당신이 그렇게 말했다는 점이 특히 놀라웠습니다. 그 느낌을 조금 풀어 설명해 주실 수 있을까요? 설레는 경험에 가까웠나요, 아니면 불안함에 가까웠나요?

Andrej Karpathy: 둘 다였습니다. 지난 1년 정도 저도 많은 분들처럼 Claude Code 같은 에이전트형 코딩 도구들을 계속 써 왔습니다. 처음에는 꽤 유용했지만, 코드 조각을 만들어 주면 가끔 틀리는 부분이 있어서 제가 직접 고쳐야 했습니다. 그러다 12월이 분명한 전환점이 됐습니다. 그때 저는 잠시 쉬는 중이라 시간이 좀 더 있었고, 그래서 최신 모델들을 더 깊게 써볼 수 있었습니다. 그런데 어느 순간부터 모델이 만들어 주는 코드 조각들이 별다른 수정 없이 받아들일 만한 수준으로 나오기 시작했습니다. 더 요청해도 계속 괜찮은 결과가 나왔고, 마지막으로 제가 직접 고친 게 언제였는지 기억이 나지 않을 정도가 됐습니다. 그렇게 시스템을 점점 더 신뢰하게 되었고, 자연스럽게 바이브 코딩을 하고 있었습니다. 저는 이 변화가 꽤 급격했다고 봅니다.

많은 사람은 작년의 AI를 ChatGPT 비슷한 경험으로만 기억할 텐데, 12월 이후에는 다시 봐야 했습니다. 특히 에이전트가 하나의 흐름 안에서 일관되게 작업을 이어가는 능력이 실제로 작동하기 시작했기 때문입니다. 그 깨달음 이후로 저는 끝없이 사이드 프로젝트를 벌이게 됐습니다. 제 사이드 프로젝트 폴더에는 온갖 실험이 가득하고, 저는 계속 바이브 코딩을 하고 있습니다.

인터뷰어: LLM을 새로운 컴퓨터라고 말해 왔습니다. 단순히 더 나은 소프트웨어가 아니라 완전히 새로운 컴퓨팅 패러다임이라는 뜻이죠. 소프트웨어 1.0은 명시적 규칙, 소프트웨어 2.0은 학습된 가중치, 소프트웨어 3.0은 지금의 LLM이라는 관점입니다. 팀이 이 관점을 진짜로 받아들이면, 다음 날부터 무엇을 다르게 만들게 될까요?

Andrej Karpathy: 소프트웨어 1.0에서는 사람이 직접 코드를 씁니다. 소프트웨어 2.0에서는 데이터셋을 만들고 신경망을 학습시키는 방식으로 프로그래밍합니다. 그러니까 데이터셋, 목적 함수, 신경망 구조를 어떻게 구성하느냐가 프로그래밍이 되는 셈이죠. 그런데 충분히 큰 작업 집합 위에서 GPT나 LLM을 훈련하면, 이 모델들은 어떤 의미에서 프로그래밍 가능한 컴퓨터처럼 됩니다.

소프트웨어 3.0에서는 프로그래밍이 프롬프팅으로 바뀝니다. 컨텍스트 창에 무엇을 넣느냐가 LLM이라는 인터프리터를 움직이는 핵심 제어 수단이 됩니다. 이 인터프리터는 주어진 문맥을 해석하고, 디지털 정보 공간에서 계산을 수행합니다.

OpenClaw 설치 방식이 이 전환을 실감하게 한 사례였습니다. 보통 어떤 도구를 설치한다고 하면 셸 스크립트를 떠올립니다. 그런데 다양한 플랫폼과 컴퓨터 환경을 지원하려다 보면 셸 스크립트가 금방 아주 복잡해집니다. 그건 여전히 소프트웨어 1.0식 사고방식, 즉 코드를 아주 정확하게 써서 모든 경우를 처리하려는 방식입니다. 반면 OpenClaw 설치는 에이전트에게 붙여 넣을 텍스트 묶음에 가깝습니다. “이걸 복사해서 에이전트에게 주면 설치해 준다”는 일종의 작은 스킬인 셈이죠. 에이전트는 자신의 추론 능력으로 환경을 살펴보고, 지시를 따라가며, 필요한 행동을 하고, 문제가 생기면 그 안에서 디버깅합니다. 그래서 이제 중요한 질문은 “어떤 코드를 쓸 것인가”만이 아니라 “에이전트에게 어떤 텍스트를 건넬 것인가”가 됩니다. 그것이 새로운 프로그래밍 패러다임입니다.

인터뷰어: 그 관점을 더 극단적으로 보여 주는 사례도 있나요?

Andrej Karpathy: MenuGen이 그런 예였습니다. 식당에 가면 메뉴에는 보통 사진이 없습니다. 저는 메뉴 항목 중 30%, 때로는 50% 정도가 정확히 어떤 음식인지 잘 모를 때가 많았습니다. 그래서 메뉴 사진을 찍으면 각 항목이 대략 어떻게 생겼을지 보여 주는 앱을 만들고 싶었습니다.

제가 바이브 코딩으로 만든 앱은 사진을 업로드하면 OCR로 메뉴 항목을 읽고, 메뉴를 다시 렌더링하고, 이미지 생성기를 사용해 각 음식의 그림을 만들어 보여 주는 방식이었습니다. Vercel에서 돌아가도록 배포까지 했죠. 그런데 나중에 소프트웨어 3.0식 버전을 보고 충격을 받았습니다.

메뉴 사진을 Gemini에 주고, Nano Banana로 음식 이미지를 메뉴 위에 덧입히라고 말하면 됐습니다. 그러면 제가 찍은 메뉴 사진 자체를 유지한 채, 그 픽셀 위에 음식들이 렌더링되어 돌아왔습니다. 그 순간 제가 만든 MenuGen 앱의 상당 부분이 불필요하다는 걸 깨달았습니다. 그 앱은 이전 패러다임 안에서 문제를 풀고 있었던 겁니다.

소프트웨어 3.0은 훨씬 더 직접적입니다. 신경망이 더 많은 일을 하고, 입력 문맥은 이미지이며, 출력도 이미지입니다. 중간에 앱이 있을 필요가 없을 수 있습니다. 그래서 중요한 것은 기존 일을 더 빠르게 하는 프레임에 갇히지 않는 것입니다. 이제는 완전히 새로운 일이 가능해졌습니다. 이건 코드만의 문제가 아니라 더 일반적인 정보 처리의 자동화입니다. 예를 들어 제 LLM 지식베이스 프로젝트에서는 LLM이 개인이나 조직을 위한 위키를 만듭니다. 예전에는 여러 문서와 사실을 바탕으로 지식베이스를 재구성하는 프로그램을 쓰기 어려웠습니다. 지금은 문서를 가져와 다른 방식으로 재컴파일하고, 재정렬하고, 새로운 관점의 자료로 바꿀 수 있습니다. 저는 기존에 하던 일을 더 빠르게 하는 것보다, 이전에는 불가능했던 일을 할 수 있게 된 점이 더 흥미롭습니다.

인터뷰어: MenuGen의 변화가 흥미롭습니다. 그 방향으로 더 생각해 보면, 1990년대의 웹사이트, 2010년대의 모바일 앱, 클라우드 시대의 SaaS에 해당하는 2026년의 명백한 기회는 무엇일까요?

Andrej Karpathy: MenuGen 예로 돌아가면, 많은 코드는 애초에 존재할 필요가 없습니다. 신경망이 대부분의 일을 하게 되는 거죠. 그 방향으로 더 생각해 보면 상당히 낯선 모습이 나옵니다. 완전히 신경망으로 작동하는 컴퓨터를 상상할 수 있습니다. 예를 들어 어떤 장치가 원시 비디오나 오디오를 받아 신경망에 넣고, 확산 모델이 그 순간에 맞는 UI를 바로 렌더링하는 식입니다.

초기 컴퓨팅 시절에는 컴퓨터가 계산기처럼 될지, 신경망처럼 될지 명확하지 않았다고 생각합니다. 1950년대와 1960년대에는 어느 쪽으로 갈지 아직 분명하지 않았죠. 결국 우리는 계산기 쪽 경로를 택했고, 고전적 컴퓨팅을 만들었습니다. 지금의 신경망은 그 기존 컴퓨터 위에서 가상화되어 실행되고 있습니다.

하지만 앞으로는 많은 것이 뒤집힐 수도 있습니다. 신경망이 호스트 프로세스가 되고, CPU는 결정적 작업을 위한 보조 프로세서가 되는 식입니다. 신경망 기반 지능 계산이 연산량의 대부분을 차지하게 되면, 신경망이 무거운 일을 맡고 도구 사용은 결정적 작업을 처리하는 보조 수단처럼 남을 수 있습니다. 그 전망은 아주 낯설지만, 아마 우리는 단계적으로 그 방향으로 갈 것입니다.

인터뷰어: 검증 가능성 이야기를 해 보고 싶습니다. AI는 출력물을 검증할 수 있는 영역을 더 빠르고 쉽게 자동화한다는 관점입니다. 그 관점이 맞다면 사람들이 생각하는 것보다 훨씬 빠르게 움직일 일은 무엇이고, 안전하다고 여겨지지만 사실은 검증 가능성이 높은 직업은 무엇일까요?

Andrej Karpathy: 전통적 컴퓨터는 코드로 명세할 수 있는 일을 쉽게 자동화합니다. 반면 최근의 LLM은 검증할 수 있는 일을 쉽게 자동화합니다. 프런티어 AI 연구소들이 LLM을 훈련할 때, 거대한 강화학습 환경에서 검증 보상을 줍니다. 그래서 모델들은 수학, 코드, 그 주변처럼 검증 가능한 영역에서 능력이 크게 올라가고, 그렇지 않은 영역에서는 성능이 아직 고르지 못합니다.

제가 검증 가능성에 대해 쓴 이유는 이 모델들이 왜 이렇게 들쭉날쭉한지 이해하고 싶었기 때문입니다. 일부는 모델 훈련 방식과 관련이 있고, 일부는 연구소들이 무엇에 집중하고 어떤 데이터를 넣는지와 관련이 있습니다.

경제적으로 가치가 큰 영역일수록 환경이 더 많이 만들어지고, 연구소들도 그런 설정을 훈련에 넣으려 합니다. 코드가 좋은 예입니다. 한동안 “strawberry에 r이 몇 개 있는가” 같은 문제가 들쭉날쭉함의 대표 사례였습니다. 지금은 어느 정도 패치되었겠지만, 요즘 제 예시는 이겁니다. “차를 씻으러 세차장에 가려고 하는데, 세차장이 50미터 떨어져 있다. 운전해야 하나, 걸어가야 하나?” 최신 모델도 너무 가깝다며 걸어가라고 답할 수 있습니다.

같은 모델이 10만 줄짜리 코드베이스를 리팩터링하거나 제로데이 취약점을 찾을 수 있는데도, 세차장에는 걸어가라고 말하는 겁니다. 모델의 성능이 이렇게 고르지 않은 이상, 사람은 여전히 작업 흐름 안에서 판단하고 확인해야 합니다. 모델을 도구로 다루고, 무엇을 하는지 계속 살펴봐야 합니다.

제가 보기에 패턴은 “검증 가능한가”와 “연구소들이 신경 쓴 영역인가”의 조합에 가깝습니다. 모델에는 매뉴얼이 없습니다. 어떤 영역이 강화학습의 회로 안에 있었는지, 어떤 영역이 데이터 분포 바깥인지 직접 탐색해야 합니다. 바깥에 있다면 기본 LLM에서 그냥 나오기를 기대하지 말고, 파인튜닝이나 자체 작업을 고려해야 합니다.

인터뷰어: 창업자 입장에서 보면 어떨까요? 검증 가능한 문제를 풀려고 하는데, 수학과 코딩처럼 명백한 영역에서는 이미 연구소들이 빠르게 앞서 나가고 있습니다. 이런 상황에서 창업자들에게 어떤 조언을 하겠습니까?

Andrej Karpathy: 검증 가능성은 현재 패러다임에서 어떤 문제를 다루기 쉽게 만듭니다. 검증 가능한 설정이라면 거기에 많은 강화학습을 적용할 수 있기 때문입니다. 그리고 그 사실은 연구소들이 직접 집중하지 않는 영역에서도 여전히 유효합니다.

여러분이 어떤 영역에서 검증 가능한 강화학습 환경이나 예제를 만들 수 있다면, 자체 파인튜닝으로 이점을 얻을 수 있습니다. 이건 근본적으로 작동하는 기술입니다. 충분히 다양하고 큰 데이터셋, 강화학습 환경, 예제가 있다면 선호하는 파인튜닝 프레임워크로 꽤 잘 작동하는 결과를 얻을 수 있습니다. 구체적인 예를 많이 말하고 싶지는 않지만, 아직 주요 연구소들이 충분히 다루지 않은 가치 있는 강화학습 환경들이 있다고 생각합니다.

인터뷰어: 반대로 멀리서 보면 자동화될 것 같지만 실제로는 어려운 것은 무엇이라고 봅니까?

Andrej Karpathy: 결국 거의 모든 것은 어느 정도 검증 가능하게 만들 수 있다고 봅니다. 다만 어떤 것은 더 쉽고, 어떤 것은 더 어렵습니다. 글쓰기 같은 영역도 LLM 심사위원단을 두면 어느 정도 합리적인 평가를 만들 수 있습니다. 그래서 핵심은 가능과 불가능이라기보다 쉽고 어려움의 차이에 가깝습니다. 궁극적으로는 모든 것이 자동화 가능하다고 생각합니다.

인터뷰어: 작년에는 “vibe coding”이라는 말을 만들었고, 지금은 조금 더 진지한 “agentic engineering”의 세계에 와 있는 것 같습니다. 둘의 차이는 무엇이고, 지금 우리가 있는 상태를 뭐라고 부르겠습니까?

Andrej Karpathy: 바이브 코딩은 모두가 소프트웨어로 할 수 있는 일의 바닥을 끌어올리는 것입니다. 누구나 무언가를 바이브 코딩할 수 있게 되는 건 놀랍고 대단한 일입니다. 반면 에이전틱 엔지니어링은 전문 소프트웨어가 원래 지켜야 했던 품질 기준을 보존하는 일입니다.

바이브 코딩을 했다는 이유로 취약점을 넣어서는 안 됩니다. 예전과 마찬가지로 자신의 소프트웨어에 책임이 있습니다. 다만 더 빨리 갈 수 있느냐는 질문이 남고, 답은 “갈 수 있다”입니다. 문제는 어떻게 제대로 하느냐입니다.

저는 에이전틱 엔지니어링을 하나의 공학적 훈련 체계로 봅니다. 에이전트는 능력이 들쭉날쭉하고, 오류를 내며, 확률적으로 움직이지만, 매우 강력합니다. 이런 에이전트들을 어떻게 조율해서 품질 기준을 희생하지 않고 더 빨리 갈 것인가가 에이전틱 엔지니어링의 영역입니다. 바이브 코딩은 바닥을 올리는 일이고, 에이전틱 엔지니어링은 상한을 올리는 일입니다. 제가 보기에는 잘하는 사람들의 상한이 매우 높고, 예전의 10x 엔지니어라는 표현보다 훨씬 더 큰 차이가 날 수 있습니다.

인터뷰어: AI 네이티브하게 코딩하는 사람과 그렇지 않은 사람을 비교한다면 어떤 차이가 보일까요? OpenClaw, Claude Code, Codex 같은 도구를 쓰는 두 사람을 본다고 했을 때요.

Andrej Karpathy: 결국 주어진 도구에서 최대한 많은 것을 끌어내는 태도라고 생각합니다. 기능을 제대로 활용하고, 자기 작업 환경에 투자하는 겁니다. 예전 엔지니어들이 Vim이나 VS Code 같은 도구를 자기 손에 맞게 다듬고 최대한 활용했듯이, 지금은 Claude Code나 Codex 같은 도구를 얼마나 잘 끌어내느냐가 중요합니다.

채용 방식도 관련이 있습니다. 강한 에이전틱 엔지니어를 뽑고 싶어 하는 곳은 많지만, 대부분의 채용 프로세스는 아직 그 능력을 평가하도록 바뀌지 않았습니다. 작은 퍼즐을 풀게 하는 방식은 여전히 예전 패러다임입니다. 오히려 큰 프로젝트를 주고 구현하게 해야 합니다. 예를 들어 에이전트를 위한 Twitter 클론을 만들게 하고, 아주 좋고 안전하게 만들게 한 다음, 여러 에이전트로 활동을 시뮬레이션하고, 또 다른 Codex 인스턴스들로 그 웹사이트를 깨뜨려 보게 하는 식입니다. 그들이 깨뜨리지 못해야 합니다. 그런 큰 프로젝트 안에서 도구를 어떻게 활용하는지를 보는 편이 더 맞다고 봅니다.

인터뷰어: 에이전트가 더 많은 일을 하게 될수록, 덜 중요해지는 것이 아니라 더 중요해지는 인간의 기술은 무엇일까요?

Andrej Karpathy: 지금으로서는 취향, 판단, 설계, 감독이 더 중요해진다고 봅니다. 에이전트는 놀라울 만큼 유능한 인턴에 가깝습니다. 그래서 사람은 여전히 미학적 기준과 설계 판단을 세우고, 결과를 감독하는 역할을 맡아야 합니다.

MenuGen에서 있었던 일이 좋은 예입니다. 사용자는 Google 계정으로 가입하고, Stripe 계정으로 크레딧을 구매했습니다. 두 계정 모두 이메일 주소가 있었고, 제 에이전트는 Stripe 이메일과 Google 이메일을 맞춰 크레딧을 연결하려 했습니다. 그런데 사용자는 Stripe와 Google에 서로 다른 이메일을 쓸 수 있습니다. 영구적인 사용자 ID에 연결해야 하는데 이메일을 임의로 맞춘 것이죠. 이런 종류의 이상한 설계 실수는 사람이 잡아야 합니다.

그래서 저는 사람이 명세와 계획을 책임져야 한다고 봅니다. 에이전트와 함께 매우 상세한 명세를 설계하고, 문서를 만들게 하고, 큰 구조와 감독은 사람이 맡는 식입니다. 세부 구현은 상당 부분 에이전트에게 맡길 수 있습니다. 예를 들어 PyTorch, NumPy, pandas 사이의 작은 API 차이는 더 이상 모두 기억할 필요가 없습니다. keepdims인지 keepdim인지, dim인지 axis인지, reshape,permute, transpose가 어떻게 다른지 같은 세부는 에이전트가 잘 기억합니다. 하지만 텐서가 같은 저장 공간을 바라보는 뷰인지, 아니면 별도 저장 공간을 새로 만드는 연산인지는 이해해야 합니다. 불필요한 메모리 복사를 피하려면 이런 기본 원리를 알아야 합니다. API 세부는 넘길 수 있어도, 기본 원리와 설계 판단은 여전히 사람이 맡아야 합니다.

인터뷰어: 그 취향과 판단도 시간이 지나면 덜 중요해질까요, 아니면 천장만 계속 높아질까요?

Andrej Karpathy: 개선되기를 바랍니다. 지금 잘 안 되는 이유는 아마 그것이 강화학습의 일부가 아니기 때문일 겁니다. 미학에 대한 비용이나 보상이 충분하지 않거나, 아직 잘 설계되지 않은 것이겠죠.

모델이 만든 코드를 실제로 보면 가끔 놀랄 때가 있습니다. 항상 훌륭한 코드는 아닙니다. 불필요하게 비대하고, 복사 붙여넣기가 많고, 어색하고 깨지기 쉬운 추상화가 있습니다. 작동은 하지만 정말 지저분할 때가 있습니다. 미래 모델에서는 개선되기를 바랍니다. MicroGPT 프로젝트도 그 예입니다. 저는 LLM 학습을 가능한 한 단순하게 설명하고 구현하려고 했는데, 모델들은 이런 단순화를 잘하지 못합니다. 계속 더 단순하게 만들라고 프롬프트해도 잘 안 됩니다. 강화학습 회로 바깥에 있는 느낌입니다. 빠르게 나아가는 느낌이 아니라 억지로 끌고 가는 느낌이죠. 그래서 지금은 여전히 사람이 이 부분을 책임지고 있습니다. 다만 근본적으로 불가능하다고 보지는 않습니다. 연구소들이 아직 충분히 하지 않았을 뿐일 수 있습니다.

인터뷰어: 들쭉날쭉한 지능으로 다시 돌아가 보겠습니다. “동물이 아니라 유령을 소환하고 있다”는 글을 쓴 적이 있습니다. 데이터와 보상 함수에 의해 만들어진 지능이지만, 진화 과정에서 생겨난 내적 동기, 재미, 호기심 같은 것은 갖고 있지 않다는 관점입니다. 이 관점이 왜 중요하고, 시스템을 만들고 배포하고 평가하고 신뢰하는 방식에 무엇을 바꿉니까?

Andrej Karpathy: 제가 그 글을 쓴 이유는 이들이 무엇인지 이해하고 싶었기 때문입니다. 무엇이고 무엇이 아닌지에 대한 좋은 모델을 가지고 있으면 더 능숙하게 사용할 수 있습니다. 이 비유가 실제로 엄청난 실용적 힘을 갖는지는 모르겠습니다. 조금 철학적인 면도 있습니다. 하지만 이들이 동물적 지능이 아니라는 사실을 받아들이는 것은 중요합니다. 소리를 지른다고 더 잘하거나 못하는 존재가 아닙니다. 이들은 통계적 시뮬레이션을 하는 회로에 가깝습니다. 기반에는 사전학습, 즉 통계가 있고, 그 위에 강화학습이 덧붙습니다. 그래서 무엇이 잘 작동할지, 무엇이 잘 작동하지 않을지, 어떻게 수정해야 할지에 대한 마음가짐을 잡는 데 도움이 됩니다. 시스템을 더 좋게 만드는 다섯 가지 명확한 결론이 바로 나오는 것은 아닙니다. 다만 의심하고, 시간이 지나며 파악하는 태도에서 시작합니다.

인터뷰어: 이제 단순히 대화만 하는 에이전트가 아니라 실제 권한과 로컬 맥락을 가지고 사용자를 대신해 행동하는 에이전트와 깊게 일하고 있습니다. 우리 모두가 그런 세계에 살기 시작하면 무엇이 달라질까요?

Andrej Karpathy: 많은 사람이 에이전트 중심 환경이 어떤 모습일지 기대하고 있을 겁니다. 모든 것이 다시 쓰여야 합니다. 지금은 대부분이 여전히 사람을 위해 쓰여 있습니다. 프레임워크나 라이브러리 문서도 기본적으로 사람에게 설명합니다. 그런데 저는 종종 “왜 아직도 나에게 무엇을 하라고 말하지?”라고 느낍니다.

저는 제가 직접 무언가를 하고 싶은 게 아닙니다. “내 에이전트에게 무엇을 붙여 넣으면 되는가”가 알고 싶은 겁니다. 그래서 해야 할 일을 세계를 읽는 센서와 세계에 영향을 주는 액추에이터로 나눠 생각해야 합니다. 어떻게 에이전트 중심으로 만들 것인가, 어떻게 에이전트에게 먼저 설명할 것인가가 중요합니다. LLM이 읽기 쉬운 데이터 구조와 자동화도 필요합니다.

MenuGen에서도 어려웠던 부분은 코드 작성이 아니라 배포였습니다. Vercel에 배포하려면 여러 서비스를 연결하고, 설정 메뉴를 열고, DNS를 구성해야 했습니다. 저는 LLM에게 “MenuGen을 만들어라”라고 말하면 아무것도 만지지 않아도 인터넷에 배포되는 상태를 원합니다. 그게 인프라가 에이전트 중심으로 바뀌었는지를 보는 좋은 테스트가 될 수 있습니다. 결국 사람과 조직을 대표하는 에이전트가 생기는 세계로 갈 것이라고 봅니다. 제 에이전트가 당신의 에이전트와 회의나 세부사항을 조율하는 식입니다.

인터뷰어: 마지막으로 교육 질문을 드리겠습니다. 지능의 비용이 낮아지는 다음 AI 시대에 깊이 배울 가치가 여전히 남아 있는 것은 무엇일까요?

Andrej Karpathy: 최근에 본 트윗 하나가 계속 머릿속에 남아 있습니다. 대략 “생각은 아웃소싱할 수 있지만, 이해는 아웃소싱할 수 없다”는 말이었습니다. 저는 그 표현이 아주 좋다고 생각합니다. 저는 여전히 시스템의 일부입니다.

정보는 여전히 제 머릿속으로 들어와야 합니다. 무엇을 만들고 있는지, 왜 만들 가치가 있는지, 제 에이전트를 어떻게 지휘할지 알아야 합니다. 오히려 제가 병목이 되어 가고 있다고 느낍니다. 그래서 LLM 지식베이스에 관심이 많습니다. 그것은 제가 정보를 처리하는 방식입니다. 같은 정보를 다른 관점으로 다시 볼 때 저는 통찰을 얻습니다. 기사를 읽으면 그 기사들로 제 위키가 쌓이고, 저는 거기에 질문하는 것을 좋아합니다. 고정된 데이터 위에서 합성 데이터를 만들어 보는 여러 프롬프트라고 볼 수도 있습니다. 결국 이런 도구들은 이해를 강화하는 도구입니다. 그 이해는 여전히 병목입니다. 이해가 부족하면 좋은 지휘자가 될 수 없습니다. LLM이 이해를 특히 잘한다고 보기는 어렵고, 우리는 여전히 그 부분을 고유하게 책임지고 있습니다.

인터뷰어: 몇 년 뒤 다시 돌아와서 우리가 완전히 작업 흐름 밖으로 밀려났는지, 그리고 그들이 이해까지 맡게 되었는지 볼 수 있으면 좋겠습니다. 오늘 함께해 주셔서 정말 감사합니다.