Andrew Ng on Coding Agents and Deciding What to Build - https://www.youtube.com/watch?v=qeMMnOiF51A

사실 저는 데이터베이스의 미래에 대해 매우 기대하고 있습니다. 또 다른 질문을 하실 거라는 건 알지만, 한 가지만 말씀드리죠. 지금 세계는 대규모 데이터 센터 구축이 한창이고, AI 학습과 추론을 위한 데이터 센터가 많이 지어지고 있다고 느낍니다. 세상 많은 사람이 아직 제대로 인식하지 못하는 점은, 앞으로 많은 핵심 인프라, 즉 컴퓨터와 스토리지를 인간뿐 아니라 에이전트도 사용하게 되리라는 것입니다. 이런 인프라를 에이전트가 사용하게 되면 엄청난 수요가 생길 것입니다. 그래서 학습과 추론을 위한 AI 데이터 센터 증설뿐 아니라, 오늘날 많은 데이터베이스는 인간의 사용을 전제로 만들어져서 우리가 보거나 조회할 수 있는 데이터 양에는 한계가 있습니다. 하지만 에이전트가 사용하게 되면 컴퓨팅을 위한 핵심 인프라 수요는 계속 치솟을 것이라고 생각합니다. 그래서 저는 이 분야 전반에 매우 낙관적입니다. 네, 정말 놀라운 분야죠. 저희는 이 분야의 한복판에 있다는 게 정말 행운이라고 느끼고, 어제 파트너 데이를 열어서 빌더나 개발자와 함께 일하는 많은 분을 초대했는데, 다들 한결같이 컴퓨팅 자원이 부족하다고 하더군요. 세상으로 쏟아져 들어오는 빌더의 수가 지금 정말 엄청납니다. 네, 맞아요. 그래서 사실 먼저 시작하겠습니다. 당신은 가장 인상적인 이력 중 하나를 가지고 계신데, 제가 다 외우진 못해서요. 겸손하신 걸 알지만, 모르는 분들을 위해 읽어 드리겠습니다. 딥러닝AI의 창립자이시고, AI 펀드의 제너럴 파트너, AI 애스파이어의 매니징 파트너, 코세라의 회장 겸 공동 창업자, 스탠퍼드 대학교 교수이십니다. 이전에는 구글 브레인의 창립 리더, 바이두의 부사장 겸 최고 과학자, 스탠퍼드 AI 연구소의 소장을 지내셨고, 세계에서 가장 영향력 있는 AI 인물을 꼽는 TIME 100 AI 명단에도 오르셨습니다. 우선, 정말 대단하네요. 정말 대단한 삶이네요. 어떻게 계속 스스로를 새롭게 만들고 이 모든 일을 해낼 에너지가 있으신가요? 제 대답은 뻔한 것 같습니다. 여러 조직에서 줄곧 정말 훌륭한 분들과 함께 일할 수 있었던 건 큰 축복이었다는 거죠. 함께 일한 사람들이 없었다면 저 혼자서는 거의 아무것도 이루지 못했을 겁니다. 그래서 정말 축복받았다고 생각합니다. 멋지네요. 멋져요. 좋습니다, 이제 스킬 맵에 대해 이야기하려고 합니다. 제가 설명해 보려 했는데, 당신은 무엇보다 먼저 교육자시니까, 스킬 맵과 현재 하고 계신 일에 대해 간단히 말씀해 주시면 그다음에 깊이 들어가 보겠습니다. 네, 지금 이 시점에서 가장 빠르게 성장하고 있는 가장 흥미로운 직업은 AI 엔지니어링이라고 생각합니다. 여기서 말하는 건 AI 엔지니어라는 직함을 가진 사람만이 아니라, 소프트웨어 엔지니어링, 프런트엔드, 백엔드, DevOps, 모바일 등 다양한 직무에서 일하며 AI 엔지니어링 역량으로 이점을 얻을 수 있는 사람들입니다. 그래서 딥러닝AI 팀은 몇 달에 걸쳐 AI 엔지니어링을 잘 해내는 데 필요한 역량이 무엇인지 정리하는 작업을 많이 했습니다. 그 결과 분류를 하게 되었는데, 1만 건이 넘는 채용 공고를 분석하고, 수십 건의 구조화된 인터뷰를 진행하고, 자체 설문도 여러 번 진행했으며 파트너들과의 대화에서 얻은 관점도 종합했습니다. 그리고 AI 엔지니어링을 잘하는 데 필요한 핵심 역량이 네 가지라는 결론을 얻었습니다. 첫째는 AI 애플리케이션을 구축하고 배포하는 능력입니다. AI 애플리케이션과 일반 애플리케이션의 차이는 불확실성이 있다는 점이죠. 그래서 이를 어떻게 관리할 것인가가 중요합니다. 둘째는 소프트웨어 엔지니어링 기본기입니다. AI가 코드를 많이 작성해 주는 상황에서도 소프트웨어 엔지니어링 기본기를 이해하는 사람, 예를 들어 읽기/쓰기 비율이나 트랜잭션이 무엇인지 아는 사람이 코딩 에이전트를 훨씬 더 잘 조종할 수 있습니다. 셋째는 코딩 에이전트를 활용하는 능력입니다. 마지막은 무엇을 만들지 형성하는 역량인데, 이제 개발자는 누군가 시키는 일을 그대로 구현하는 역할이 아니라 무엇을 만들지 결정하는 데 참여하고 무언가가 만들어지는 과정에도 영향을 미치기 때문입니다. 오늘날 채용 시장에서 제가 보는 것은, 개발자들이, AI 엔지니어라는 직함이 있든, 다른 직함을 가지고 있으면서 AI 엔지니어링 역량을 갖춘 사람이든 수요가 매우 높은데, 이런 역량을 가진 사람을 충분히 찾을 수 없다는 점입니다. 그래서 딥러닝AI는 이 일에 적극적으로 나서서 더 많은 사람이 AI 엔지니어링에 능숙해지도록 돕고자 합니다. 멋지네요. 그리고 스킬 맵 자체에 대해서인데, 먼저 왜 특히 스킬에 초점을 맞추셨나요? 스킬이 가장 중요한 요소 중 하나라는 관점을 가지고 계신 것 같은데, 앞으로도 스킬이 계속 핵심일까요, 아니면 에이전트가 충분히 좋아져서 우리가 직접 맞춤 스킬을 제공하는 데 그렇게 신경 쓸 필요가 없어질까요? 이 부분이 어떻게 진화할 거라고 보시나요? 네, 지금 우리가 하는 일 중에는 에이전트가 대신해 주기를 바라는 것들이 있습니다. 예를 들어 3년 전에는 프롬프트 엔지니어라는 직업에 대한 과대광고가 많았고, 프롬프트 엔지니어가 되면 돈을 얼마나 벌 수 있는지 이야기하곤 했죠. 그때도 이미 분명했던 건데, 이 말은 크리스 매닝이 당시에도 아주 분명하게 말했으니 공을 돌리고 싶습니다. 사람이 LLM에게 무언가를 시키려고 난해한 주문을 외워야 하는 상황은 사라질 것이라는 생각이었죠. LLM이 스스로 그런 난해한 주문을 만들어내는 법을 배울 것이기 때문입니다. 오늘날에도 어떤 부분에서는, 예를 들어 에이전트 무리를 어떻게 관리하느냐 같은 문제에서 사람이 필요한 부분이 있고, 어떤 부분은 더 획일적으로 처리할 수 있습니다. 앞으로 몇 년간 AI 에이전트가 다른 AI 에이전트를 점점 더 잘 관리하게 될 거라고 생각합니다. 그리고 AI가 어떤 일을 넘겨받을지 아닐지를 가르는 핵심 요소 중 하나는 사람이 근본적인 맥락의 우위를 가지고 있는지 여부입니다. 우리가 애플리케이션을 만들 때는 AI 에이전트가 모르는 것을 정말 많이 알고 있습니다. 고객과 대화하면서 어떤 말을 했을 때 그 사람이 묘한 표정을 지었던 기억이 있을 수도 있고, 5년 전에 시장 보고서를 읽고 사람들이 이것은 원하고 저것은 원하지 않는다는 걸 배운 기억이 있을 수도 있죠. 인간은 놀라울 정도로 방대한 범위의 맥락을 갖고 있고, 이 맥락을 끄집어내 핵심적인 결정을 내리는 데 매우 뛰어납니다. 그래서 사람이 근본적인 맥락 우위를 가진 의사결정 영역은, 언젠가 우리 몸에 카메라를 달고 대화하는 모든 사람의 표정을 모니터링하는 날이 오기 전까지는 말이죠, 그건 아주 어려운 길입니다. 그래서 근본적인 맥락 우위를 가진 사람이 오랫동안 맡기를 원하는 업무가 많이 있다고 생각하고, 코딩 에이전트가 하는 훌륭한 작업을 보완하는 그런 가치 있는 일을 할 수 있는 스킬을 사람들에게 제공하는 것이 앞으로 오랫동안 우리가 가게 될 길이라고 봅니다. 그리고 그래서, 코딩 에이전트가 이렇게 훌륭한데도 소프트웨어 엔지니어링 채용 공고 수가 늘어난 것을 보셨을 겁니다. 소프트웨어 엔지니어와 AI 엔지니어의 생산성이 올라가면 우리는 그들이 훨씬 더 많이 필요해지기 때문입니다. 기업들도, 제 팀도 마찬가지로 숙련된 AI 엔지니어를 충분히 찾지 못하고 있습니다. 이 흐름은 계속될 거라고 생각합니다. 네. 그럼 그 부분을 더 파헤쳐 보죠. 두 명의 개발자가 있다고 해 봅시다. 둘 다 실력이 뛰어난 개발자인데, 한 사람이 다른 사람보다 더 좋은 결과를 낸다면, 더 강한 개발자는 오늘날 상대가 하지 않는 어떤 일을 하고 있을까요? 정말 좋은 질문입니다. AI 엔지니어링 스킬 맵을 만들 때 저희가 스스로에게 반복해서 던진 질문 중 하나였습니다. 실제로 많은 사람을 인터뷰했고, 표준 질문 중 하나가 훌륭한 개발자와 덜 훌륭한 개발자를 떠올려 보라는 것이었습니다. 정말 훌륭한 개발자는 덜 뛰어난 개발자와 비교해서 무엇을 하는가? 그리고 그 답변 중 많은 것이 결국 AI 엔지니어링 스킬 맵으로 정리되었습니다. 그리고 그건 한 가지가 아니라 매우 다양한 여러 가지입니다. 하나 예를 들자면, 저희가 강조한 네 가지 핵심 역량 중 첫 번째인 AI 애플리케이션을 구축하고 배포하는 능력이 있습니다. 전통적인 소프트웨어 애플리케이션과 비교한 AI 애플리케이션의 핵심 차별점은 불확실성이 있다는 것이죠. 맞습니다. LLM에 프롬프트를 주든 지도학습 알고리즘을 학습시키든, 어떤 결과가 나올지 미리 알 수 없습니다. 그래서 숙련된 AI 개발자들은 이런 시스템의 성능을, 종종 통계적인 방식으로, 모니터링하는 기법들을 고안했거나 익숙하게 알고 있고, 오류 분석과 평가(evals) 루프를 돌려 체계적으로 개선해 나갑니다. 이런 질문을 던지고 우리 자신의 경험을 돌아보면서, 숙련된 개발자와 초보 개발자 사이의 격차를 한두 가지가 아니라 사실 매우 많은 항목으로 체계적으로 정리하려 했고, 그것을 우리가 AI 엔지니어링 스킬 맵이라고 부르는 형태로 압축했습니다. 그리고 이를 바탕으로 사람들이 이 모든 가치 있는 스킬에서 초보 수준에서 전문가 수준으로 나아가도록 체계적으로 돕고자 합니다. 스킬 맵은 누구나 사용할 수 있나요, 주로 소프트웨어 엔지니어나 관련 배경을 가진 사람을 위한 건가요? 사람들이 스킬 맵 자체를 어떻게 활용하면 좋을까요? 네, 저희는 딥러닝AI에서 '더 배치(The Batch)'라는 주간 뉴스레터를 발행하는데, 5주 연속으로 AI 엔지니어링 스킬 맵에 대해서만 썼고, 실제로 이를 중심으로 커리큘럼을 구성하려는 다른 회사들도 있다고 알고 있는데, 꽤 멋진 일이죠. 개인에게는, 탁월하다는 것이 무엇인지 이해하는 방법이 될 수 있다고 생각합니다. 여러분 중 많은 분이 이미 탁월하시겠지만, 이미 탁월한 영역이 있고 더 탁월해지고 싶은 영역도 있을 테니까요. 그리고 딥러닝AI가 열심히 하고 있는 일 중 하나는 사람들이 AI 엔지니어링 전반에 능숙해질 수 있는 경로를 만드는 것입니다. 다만 교육 분야에서는 딥러닝AI와 다른 회사들 모두 아직 할 일이 남아 있다고 생각합니다. 사람들이 이 모든 AI 엔지니어링 스킬 전반에 걸쳐 능숙해질 수 있도록 더 명확한 경로를 마련해야 하니까요. 궁금한 게 있는데, 몰려드는 사람들은 어떤가요, 경력 있는 개발자들인가요? 아마도 어떤 곡선이 있을 텐데, 경력 많은 개발자 중에는 손에서 놓고 싶어 하지 않는 분들이 있을 겁니다. 저도 그랬는데, 코딩에 몰입하는 걸 정말 좋아했고, 꽤 오랜 시간이 걸렸죠. '좋아, 이제 에이전트에게 맡기자'라고 생각하기까지요. 사람들이 '좋아, 포기하고 모든 걸 스킬 중심으로 전환하겠다'라고 하는 변화가 서서히 일어나고 있나요? 네, 사실 흥미롭습니다. 있잖아요, 웃기게도 저는 사실 손으로 직접 코딩하는 게 그립지 않아요. 네, 네, 맞아요. 그런데 혹시, 그립지 않으세요, 그 몰입 상태 같은 거요. 완전히 집중해서 문제를 붙잡고, 스택 오버플로에 가서 5만 가지를 복사해서 붙여넣던 것도요. 당신은 안 그랬을 수도 있지만, 저는 그랬어요. 그리고 세 시간 동안 한 문제에 매달리다가 마침내 풀리는 순간이 오죠. 이제는 그런 느낌이 별로 들지 않는 것 같아요. 하지만 저도요. 네, 맞아요, 당신도 이런 문제가 있을 거예요. AI 이전에는 하고 싶지만 끝내지 못한 프로젝트 목록이 있었잖아요. 이제 제 목록은, 당신도 그럴 것 같은데, AI 덕분에 우리가 더 생산적이 되었다고들 하는데 오히려 훨씬 더 길어졌죠. 저 스스로를 보면, 손대고 싶지만 시간이 없는 프로젝트가 정말 많습니다. 그리고 우리의 역량이 커지는 동안 제 개인적인 야망은 아마 역량보다 훨씬 더 빠르게 커진 것 같아요. 그래서 네, 다른 종류의 몰입감이죠. 잠들기 전에 코딩 에이전트를 돌려놓고 다음 날 아침 어떤 결과가 나왔는지 보는 것도 이상한 자바스크립트 문법을 디버깅하는 것과는 다른 방식의 몰입이라고 할 수 있겠죠. 하지만 인정해야겠네요, 저는 예전 방식보다 새로운 방식이 더 마음에 드는 것 같습니다. 네, 확실히 더 많은 일을 해내고 있죠, 그건 분명합니다. 그런데 궁금한 게 있는데, 이렇게 빠르게 변하는 시장에서 커리큘럼은 어떻게 설계하시나요? 이 커리큘럼을 매년, 혹은 매달 바꿔야 할 거라고 보시나요? 어떻게 반복 개선하고 계신가요? 흥미로운 점은, 과대광고에서는 AI가 너무 빨리 발전해서 석 달마다 모든 게 바뀐다고 하죠. 하지만 AI 엔지니어링 스킬 맵에서 가장 빨리 변하는 부분은 코딩 에이전트입니다. 지금 우리가 코딩하는 방식은 석 달 전과도 매우 다르고 6개월 전과는 더 다릅니다. 코딩 에이전트 활용법은 매우 빠르게 바뀌고 있죠. 하지만 제가 정말 가치 있다고 보는 나머지 스킬들, 즉 AI 애플리케이션을 구축하고 배포하는 방식을 보면 이런 시스템을 어떻게 조종하고, 배포하고, 모니터링하고, 업데이트하는가에 대한 기본 지식이 많은데, 이는 홍보용 과대광고가 말하는 것보다 훨씬 느리게 변하고 있습니다. 재미있는 점 하나는, 적어도 Astra 이전에는, Astra로 바뀌었을 수도 있지만 잘 모르겠네요, 대부분의 AI 시스템이 데이터 과학자로서도, AI 엔지니어로서도 그리 뛰어나지 않다는 겁니다. 프로젝트에서 무엇을 해야 하냐고 물어보면, 대체로 솔직히 데이터 과학의 경우, 저는 이제 데이터 과학 작업을 손으로 하지 않습니다그렇죠? 비용, 지연 시간, 그리고 속도, 신뢰성입니다. 문제는 기본기를 이해하기 전에는 어떤 트레이드오프가 존재하는지조차 모른다는 점입니다. 그래서 누군가 이해 없이 바이브 코딩을 하면, 코딩 에이전트가 수많은 트레이드오프를 선택하는데, 본인은 그런 선택이 이뤄졌다는 사실조차 모르고 있다가 나중에 문제가 터지는 경우가 아주 많습니다. 그래서 훌륭한 엔지니어들은 필요한 여러 기술 분야의 기본기를 이해하고 있어서 훨씬 더 나은 결정을 내린다고 생각합니다. 하지만 지금 가능해진 일들을 보면 저는 고무적이기도 합니다. 이해 없이 코드를 작성할 수 있게 되었으니까요. 그래도 정말 뛰어난 엔지니어는 경험이 부족한 엔지니어보다 압도적으로 더 나은 결과물을 낸다고 생각합니다. 네, 맞아요. 그 부분에 대해서 말인데요, 스킬 맵의 일부로 '빌드를 형성하는 것(shaping the build)'을 말씀하셨죠. 흥미로운 개념이라고 생각했는데, 빌드를 형성한다는 것이 무엇을 의미하는지 설명해 주실 수 있나요? 네, 만드는 일이 쉬워지면서 병목은 만드는 것보다는 무엇을 만들지 결정하는 것으로 옮겨갔습니다. 예전에는 프론트엔드 엔지니어가 많았는데, 이제는 프론트엔드 엔지니어도 AI의 도움으로 예전에는 불가능했던 수준의 백엔드 작업을 훨씬 많이 할 수 있습니다. 저는 백엔드와 프론트엔드 모두 훨씬 강해졌지만, 솔직히 지금은 AI 시스템의 도움을 받는 서툰 프론트엔드 개발자쯤 될 겁니다. 그래서 많은 개발자들이 좁은 역할에서 풀스택 개발자로 넘어갔습니다. 그런데 그 너머로, 개발자가 무언가를 만들고 나서 프로덕트 매니저가 고객 피드백을 받아 다음에 무엇을 만들지 방향을 잡아주기를 기다리는 것은, 개발자 스스로가 약간의 제품 직관, 약간의 제품 감각을 갖고 있는 경우보다 훨씬 느리다는 것이 드러났습니다. 몇몇 고객이나 사용자와 이야기하고 피드백을 받아서 프로세스를 계속 앞으로 끌고 갈 수 있으니까요. 그래서 개발 분야에서 제가 보고 있는 것은 많은 사람들이 역할을 단순한 구현에서 무엇을 만들지 결정하는 것까지 넓혀가고 있다는 점입니다. 그렇다고 엔지니어가 프로덕트 매니저가 되어야 한다는 뜻은 아닙니다. 다만 일부 제품 결정이나 더 많은 아키텍처 결정을 내릴 수 있는 엔지니어가 몇 년 전의 더 좁은 역할에 머물던 엔지니어보다 훨씬 생산적이라는 뜻입니다. 저희는 이것을 '빌드를 형성하는 것'이라고 부릅니다. 제품 결정에 영향을 줄 수 있고, 어느 정도 제품 감각도 갖추고 있으며 빌드 프로세스 전반을 함께 고민하는 데 도움을 주는 엔지니어를 말합니다. 예를 들어 지금이 MVP를 만들 시점인지, 아니면 견고한 아키텍처를 구축하고 확장성을 고민하는 데 투자할 시점인지, 혹은 고객에게 나가서 피드백을 받을 시점인지, 아니면 어떤 백엔드 기술 스택을 쓸지 더 잘 이해하기 위해 리서치를 할 시점인지 같은 것들입니다. 그래서 빌드 과정의 방향을 이끌 수 있는 개발자는 결국 프로젝트 전체에 훨씬 더 많이 기여하게 됩니다. 그렇다면 시스템을 설계하는 데 시간을 얼마나 써야 할까요? 제가 가장 좋아하는 스킬 중 하나가 있는데, 아실지 모르겠지만, 문서와 함께 철저히 파고드는(grill with docs) 방식으로 아키텍처 결정을 만들어 내는 스킬이에요. 무엇을 만들고 싶은지 한 시간 동안 정확히 캐묻죠. 사람들이 무엇을, 어떻게 만들지에 대해 사전에 얼마나 시간을 들여야 한다고 보시나요? 아니면 일단 MVP를 만들고 나중에 고치면서 반복하는 게 나을까요? 네, 아주 좋은 질문입니다. 이 질문에 답하기 어려운 이유는 답이 단계에 따라 달라지기 때문입니다. 제프 베조스가 말하는 일방향 문(one-way door)과 양방향 문(two-way door)의 구분에 크게 좌우되기도 하고요. 하지만 방향성으로 말하면, 프로젝트 초기 단계에서는 솔직히 어떤 아이디어가 있든 코딩 에이전트에 입력해서 만들어 보고 무엇이 나오는지 보세요. 안전한 방식으로 하고, 민감한 데이터를 유출하지 않고, 나쁜 결과에 대한 보호 장치만 갖춘다면요. 제가 보기에 AI 엔지니어링의 어려움 중 하나는 올바른 결정이 단계에 크게 의존한다는 점입니다. 초기 단계 프로젝트라면 책임감 있고 안전한 방식으로 빠르고 거친 프로토타입을 만들어 보고, 어떻게 되는지 확인하고, 버려도 됩니다. 빠르게 제품을 만들어 보고 결과를 확인하며 빠른 학습을 이끌어낼 수 있습니다. 그리고 아키텍처를 신중하게 고민해야 할 때와 장소도 분명히 있습니다. 재작성 비율은 어느 정도인지, 고객 요구사항은 무엇인지, 민감한 데이터는 무엇인지, 보안 인프라를 어떻게 구성할지 고민하고 실행하는 단계죠. 제가 본 바로는 0에서 1로 가는 스타트업 단계에 정말 뛰어난 엔지니어들을 많이 알고 있고, 성숙한 체계적 단계에 강한 훌륭한 엔지니어들도 많이 알고 있습니다. 하지만 때로는 프로젝트가 어느 단계에 있느냐에 따라 필요한 기술, 속도, 그리고 속도감과 하방 리스크 방어 사이의 균형을 생각하는 방식이 달라집니다. 코딩 에이전트 사용자들을 봐도, 많은 사람들이 항상 계획을 세우고 긴 명세서를 작성해야 한다고 말하는데, 그런 방식이 맞는 경우도 있습니다. 반면 20분 뒤에 잠자리에 들 예정이라면, 대충 몇 가지를 뚝딱 만들어 놓고 코딩 에이전트가 몇 시간 동안 작업하게 한 뒤 다음 날 아침 무엇이 나왔는지 보는 게 맞는 경우도 있습니다. 이렇게 단계에 따라 달라지는 답은 사람들이 배우기에 매우 까다로웠다고 생각합니다. 좋아요, 화제를 바꿔서 질문을 하나 드려야겠어요. 어제 레이턴트 스페이스(Latent Space)의 Swyx와 이야기를 나눴거든요. 아시는지 모르겠지만, 여기서 행사를 취재하고 있는데 꽤 자극적인 말을 했어요. 정확히 인용하지 못할 수도 있지만, "학교는 죽었다" 같은 말이었어요. 혹은 우리가 배우는 방식이 완전히 바뀌어야 한다는 것이었죠. 이런 질문을 많이 받으실 텐데요, 10년 뒤를 내다볼 때 학습이 어떻게 바뀔 거라고 보시는지 궁금합니다. 우리는 어떻게 배우고 있을까요? 지금 학교에서 하는 것과 비슷할까요, 아니면 완전히 다를까요? 바뀔 겁니다. 두 가지 관찰을 말씀드리겠습니다. 먼저, 당연하지만 논쟁적으로 들릴 수도 있는 말을 하나 하겠습니다. 챗봇은 학습에는 형편없습니다. 저는 LLM을 좋아하고 많이 씁니다. 그와 동시에 대학 캠퍼스와 K12에서 우리는 LLM을 사용하는 학생들이 숙제는 더 잘하지만 기말고사는 더 못 본다는 사실을 알고 있습니다. 교육자들은 이것을 직관적으로 알고 있었고, 학생들도 직관적으로 알고 있었지만, 엄밀한 연구들이 점점 더 많이 나오면서 LLM에 인지 작업을 넘기는 것, 즉 학생이 LLM에게 대신 생각하게 하면 더 많은 일을 해내지만 배우는 것은 줄어든다는 점을 보여주고 있습니다. K12와 고등교육, 대학의 정규 교육 환경에서 이에 대한 엄밀한 연구들이 나오고 있지만, 직장인 성인들 사이에서 이런 일이 얼마나 일어나고 있는지는 여전히 과소평가되고 있다고 생각합니다. 저는 코딩 에이전트를 정말 좋아하고, 엄청난 양의 일을 하게 도와줍니다. 하지만 제가 해야 하는 사고가 줄어든다는 점에서, 어떤 부분들은 문제가 있다고 생각합니다. 분명히 해두자면, 학습을 향상시키는 LLM 사용법도 있습니다. 학습에 훌륭한 틱톡 사용법이 있는 것처럼요. 하지만 대부분의 사람들이 소셜 미디어를 쓰는 대부분의 방식은 학습으로 이어지지 않습니다. 그리고 대부분의 사람들이 LLM을 쓰는 대부분의 방식도 학습으로 이어지지 않습니다. 그런데 이것의 반대편은, 우리가 더 잘할 수 있다는 점입니다. 제가 함께 일하는 팀들, 즉 Coursera, Udemy, DeepLearning.AI, Learn Vector는 일을 끝내는 데 초점을 맞추지 않고, 인간의 성장을 가속하는 데 초점을 맞춘 새로운 학습 경험을 만들기 위해 열심히 노력하고 있습니다. 여기 실리콘밸리에서는 프론티어 AI 연구소와 AI 개발 가속에 매우 들떠 있고, 그건 훌륭한 일입니다. 저도 전적으로 찬성합니다. 최근 발표된 회사인 Learn Vector는 Coursera의 초기 투자자가 투자한 회사인데, 저는 AI 개발을 가속하는 것뿐 아니라 인간의 성장을 가속하는 일에도 정말 기대가 큽니다. 저희가 하는 방식은 Learn Vector를 프론티어 AI 연구소처럼, 프론티어 인간 성장 연구소로 키워가는 것입니다. 한 가지 예로, 저는 15년쯤 전에 Coursera가 교육을 바꾸는 데 참여할 수 있었던 것을 행운으로 생각합니다. 하지만 오늘날 그 경험을 돌아보면, 여전히 효과는 있지만 일대다 방식에 매우 가깝습니다. 하나의 강좌를 만들면 모두가 같거나 매우 비슷한 강좌를 듣는 것이죠. 그래도 잘 작동하고, 그 자체로 문제는 없습니다. 하지만 이제는 기술이 있어서 훨씬 더 일대일에 가까운 경험을 만들 수 있고, 그것이 훨씬 더 나을 겁니다. Learn Vector는 아직 구체적으로 어떤 제품이 있는지 발표하지 않았지만, 내부 프로토타입을 보면 정말 낙관적이고, 몇 달 안에 더 공유할 수 있을 겁니다. 정말 기대되네요. 좋아요, 청중에게 실질적인 무언가를 남기고 싶어요. 만약 여기 있는 모든 사람이 앞으로 4주 동안 최고의 AI 개발자가 되기 위해 실력을 쌓을 수 있도록 설계한다면, 앞으로 4주 동안 시간을 어떻게 써야 할까요? 어디로 가야 하고, 무엇을 배워야 할까요? 어떤 도구를 도입해야 할까요? 떠오르는 건 무엇이든 말씀해 주세요. 글쎄요. AI 엔지니어링의 경우, DeepLearning.AI의 목표는 개발자들이 AI 엔지니어링에 능숙해지도록, 이미 능숙하다면 더욱 능숙해지도록 돕는 것입니다. DeepLearning.AI가 제공하는 것을 개선하기 위해서도 열심히 노력하고 있고요. 하지만 저 자신도 DeepLearning.AI 강좌를 많이 들으면서 프론티어 도구가 무엇인지, 음성 스택이나 생성형 UI, 혹은 에이전트용 로컬 메모리 구축에서 최신 기술이 무엇인지 배웁니다. 내부자로서는 DeepLearning.AI가 더 좋아졌으면 하는 부분도 많이 보이지만, 제 학습의 상당 부분은 사실 DeepLearning.AI를 통해 이뤄졌습니다. 여러분도 그것이 도움이 되고 멋지다고 느끼셨으면 좋겠고, 계속 만들어 나가세요. 여러분 모두가 빌더라고 생각합니다. 저는 여전히 한밤중에 너무 자주 깨서 제 코딩 에이전트가 무엇을 하고 있는지 확인하곤 합니다. 한밤중에 깨면 휴대폰으로 바로 작업을 시키시나요? 네, 글쎄요. 휴대폰으로 코딩하는 게 정말 멋지긴 한데, 어쩌면... 잘 모르겠네요. 네. 문자로 하시나요, 아니면 음성으로 코딩 에이전트와 대화하시나요? 음성보다 텍스트를 훨씬 더 많이 쓰고, 평소처럼 맥 미니를 사용합니다. 아, 그렇군요. 흥미롭네요. 약간 업계 내부 이야기인데, 사실 어떤 환경을 쓰시는지 정말 궁금합니다. 자, 우선 일정이 아주 빡빡하신 걸 알고 있는데, 저희 일정에 맞춰 시간을 내주셔서 정말 감사드립니다. 와주셔서 정말 감사하고, 모시게 되어 진심으로 영광입니다. 감사합니다. 그리고 방금 소개해 주신 여러 이력 중에서 제가 가장 마음에 두고 있는, 언급되지 않은 이력은 두 아이의 자랑스러운 아버지라는 점입니다. 그러니까요. 제가 서둘러 가야 하는 이유는 사실 아이들을 학교에서 데려와야 하기 때문입니다. 그게 가장 중요하죠. 네, 보내드릴게요. 정말 감사합니다. 감사합니다. 잡음 속으로 하드웨어와 규칙성.