Stanford CS230 | Autumn 2025 | Lecture 9: Career Advice in AI

[Andrew Ng]: 오늘은 AI 커리어 조언에 대해 여러분과 이야기해보려고 합니다. 예년에는 이 강의를 대부분 혼자 진행하곤 했는데, 올해는 제가 몇 가지 생각만 공유한 뒤 제 좋은 친구 Laurence Moroney에게 마이크를 넘기려고 합니다. Laurence는 이 강연을 위해 시애틀(Seattle)에서 샌프란시스코(San Francisco)까지 와 주셨고, 지금 채용 시장에서 무엇을 보고 있는지에 대한 폭넓은 시장 관점과 AI 커리어를 성장시키는 팁을 함께 나눠줄 겁니다. 저는 슬라이드 두 장과, Laurence에게 넘기기 전에 공유하고 싶은 생각 하나만 더 이야기하겠습니다. 저는 지금이 AI로 무언가를 만들고, AI 커리어를 구축하기에 ‘역대 최고의 기회’라고 느낍니다. 몇 달 전 소셜 미디어와 전통 미디어에서 ‘AI가 둔화되는 것 아니냐’는 질문들이 보였고, “GPT-5가 그렇게 좋냐?” 같은 말도 있었습니다. 제 생각엔 사실 꽤 좋습니다. 그런데도 ‘진전이 느려졌나?’라는 질문이 나온 이유 중 하나는, AI의 벤치마크를 ‘정답률 100% = 완벽한 답’으로 놓으면 빠르게 개선하더라도 결국 100% 위로는 갈 수 없기 때문입니다. 하지만 제 사고에 큰 영향을 준 연구가 하나 있는데, M-E-T-R, METR라는 조직의 작업입니다. 이들은 시간이 흐르면서 AI가 할 수 있는 과업의 복잡도가 어떻게 바뀌는지, ‘사람이 그 과업을 수행하는 데 걸리는 시간’으로 측정했습니다. 몇 년 전에는 GPT-2가 사람이 몇 초면 하는 일을 할 수 있는 정도였다고 치면, 이후에는 사람이 4초, 8초, 1분, 2분, 4분 걸리는 작업까지 점점 처리할 수 있게 됐습니다. 이 연구는 AI가 할 수 있는 과업 길이가 **7개월마다 두 배(doubling)**가 된다고 추정합니다. 이 지표로 보면, 사람이 어떤 일을 하는 데 걸리는 시간으로 정의한 ‘과업 복잡도’가 매우 빠르게 두 배가 되고 있으니, AI는 계속 진전할 거라는 쪽으로 저는 낙관적입니다. 같은 연구에서 더 작은 데이터셋이긴 하지만 ‘AI 코딩’은 두 배가 되는 시간이 더 짧아서 70일 정도일 수도 있다고 주장했습니다. 예를 들어 과거엔 제가 10분, 20분, 40분 걸려 쓰던 코드가 있었는데, AI가 점점 더 많은 부분을 해내는 식입니다. 그래서 제가 지금이 ‘골든 에이지’라고 보는 이유는 크게 두 가지 테마로 요약됩니다. 첫째, 더 강력하고 더 빠르다는 것입니다. 이 방 안의 여러분 모두는 이제 AI 빌딩 블록을 활용해, 불과 1년 전에는 지구상 누구도 만들기 어려웠던 수준의 강력한 소프트웨어를 만들 수 있습니다. AI 빌딩 블록에는 대규모 언어 모델(LLM), 에이전틱(agentic) 워크플로, 음성 AI(voice AI), 그리고 물론 딥러닝(deep learning)이 포함됩니다. 흥미롭게도 많은 LLM이 딥러닝에 대해 ‘그럭저럭 기본 수준’의 이해를 하고 있습니다. 최전선(frontier) 모델에게 최첨단 신경망 구현을 시켜보세요. 예를 들어 transformer 네트워크 구현을 시켜보면, 생각보다 나쁘지 않게 도와줍니다. 이렇게 강력한 빌딩 블록이 1~2년 전엔 없었거나 매우 다루기 어려웠는데, 이제는 그것들로 누구도 못 했던 일을 해내는 소프트웨어를 만들 수 있습니다. 둘째, AI 코딩으로 소프트웨어를 작성하는 속도 자체가 그 어느 때보다 빨라졌습니다. 저는 개인적으로 도구의 최전선(frontier)을 따라가는 것이 중요하다고 느낍니다. AI 코딩 도구는 정말 빠르게 변합니다. 제 경우 몇 달 전부터 개인적으로 가장 좋아하는 도구가 Cloud Code가 되었고(이전 세대 도구에서 넘어왔습니다), 그리고 GPT-5 출시 이후에는 OpenAI Codex가 엄청난 진전을 이뤘다고 느낍니다. 또한 오늘 아침 Gemini 3가 출시됐는데, 저도 아직 오늘 아침이라 직접 만져볼 시간은 없었습니다만, 또 하나의 큰 도약처럼 보입니다. 그래서 제게 3개월마다 ‘가장 좋아하는 코딩 도구가 뭐냐’고 물으면, 아마 바뀔 겁니다. 최소한 6개월마다, 어쩌면 3개월마다 바뀔 수 있습니다. 이런 도구에서 반 세대(half a generation)만 뒤처져도 생산성이 솔직히 꽤 떨어집니다. “AI는 너무 빠르게 움직이고 다 변한다”는 말을 많이 하지만, AI 코딩 도구는 특히 그 속도가 정말 엄청납니다. 이처럼 더 강력한 소프트웨어를 더 빨리 만들 수 있게 되면서, 제가 예전보다 훨씬 더 강하게 강조하는 조언이 있습니다. 그냥 가서 무언가를 만드세요. 스탠퍼드(Stanford) 수업을 듣고, 온라인 코스를 듣고, 그리고 무엇보다도 뭔가를 직접 만들어보세요. Laurence가 ‘다른 사람에게 보여주기’도 이야기할 텐데, 지금은 그 기회가 이전보다 훨씬 큽니다. 다만 여기에는 좀 이상한 함의가 하나 있습니다. 점점 ‘명확히 쓰인 소프트웨어 스펙(spec)’에서 코드로 가는 것이 쉬워질수록, 병목(bottleneck)은 무엇을 만들지 결정하는 일로 옮겨갑니다. 혹은 실제로 무엇을 만들고 싶은지에 대한 그 ‘스펙’을 쓰는 일 자체가 병목이 됩니다. 제가 소프트웨어를 만들 때, 저는 루프를 돈다고 생각합니다. 코드를 쓰고, 유저 피드백(user feedback)을 얻고, 이것을 PM(product management) 작업이라고 봅니다. 피드백을 바탕으로 ‘유저가 좋아하는 것/싫어하는 것’, ‘UI가 너무 어렵다’, ‘이 기능은 원한다/저 기능은 원치 않는다’를 파악해 무엇을 만들지에 대한 관점을 바꾸고, 그 루프를 여러 번 반복해 유저가 사랑하는 제품으로 수렴하는 것입니다. AI 코딩 덕분에 ‘빌드’ 자체는 훨씬 싸고 빨라졌습니다. 그런데 역설적으로 병목은 ‘무엇을 만들지’로 이동합니다. 그래서 실리콘밸리(Silicon Valley)와 많은 테크 회사에서 흔히 말하던 엔지니어 대 PM 비율(Eng to PM ratio)이 하락하는 추세를 봅니다. 예전엔 PM 1명이 제품 스펙을 써서 엔지니어 4:1, 7:1, 8:1 정도를 돌린다는 말이 있었는데(이런 숫자는 회사마다 제각각이라 대충 참고만 해야 합니다), 지금은 PM이 AI로 엔지니어만큼 빨리 빨라지진 않았기 때문에 비율이 내려가서 2:1 혹은 1:1에 가까운 팀도 봅니다. 또 하나는, 엔지니어가 제품을 정말 빨리 움직이게 할 수 있다면 ‘엔지니어’와 ‘PM’을 한 사람으로 합치는 방향도 보인다는 겁니다. 물론 엔지니어 중에는 유저와 이야기하고 공감(empathy)하는 일을 즐기지 않는 분들도 있습니다. 하지만 유저와 대화하고 피드백을 받고, 유저에 대한 깊은 공감을 바탕으로 무엇을 만들지 결정할 수 있는 엔지니어들은, 제가 지금 실리콘밸리에서 보는 사람들 중 가장 빠르게 움직이는 집단입니다. 저는 커리어 초기에, 한 역할에서 엔지니어들에게 ‘제품 일을 더 하라’고 설득하려다 실수한 적이 있습니다. 좋은 엔지니어들에게 ‘너희는 좋은 PM이 아니다’라는 식으로 느끼게 해서 상처를 줬고, 그건 제가 몇 년 동안 후회한 실수였습니다. 그래서는 안 됐습니다. 그런데 지금 제가 “엔지니어가 제품 일을 더 해보라”고 말하는 게, 어쩌면 같은 실수를 반복하는 것 같아 조금 찜찜하기도 합니다. 그럼에도 불구하고, 제가 코드를 쓰면서 동시에 유저와 대화해 ‘다음에 무엇을 할지’를 제품적으로 결정할 수 있으면 속도가 확 빨라집니다. 누군가가 제품을 고객에게 가져가는 것을 기다릴 필요가 없고, 그냥 코드를 쓰고, 다음에 뭘 해야 하는지 감(gut)을 가지고, 그 속도로 반복(iterate)할 수 있으니까 실행 속도(velocity of execution)가 훨씬 빨라집니다. 그리고 Laurence에게 넘기기 전 마지막으로 하나만 더. 커리어를 항해(navigate)할 때, 학습 속도와 성공 수준을 매우 강하게 예측하는 요인 중 하나는 ‘내가 어떤 사람들에 둘러싸여 있는가’입니다. 우리는 사회적 동물이고, 주변 사람에게서 배웁니다. 사회학(sociology) 연구에 따르면 가장 가까운 친구 5명이 흡연자면 내가 흡연자일 확률이 높다고 합니다. (제발 담배는 피우지 마세요. 그냥 예시입니다.) 반대로 “가까운 친구 5~10명이 정말 मेहन하게 일하고, 빠르게 배우고, AI로 세상을 더 낫게 만들려는 사람들”이면, 나도 그럴 확률이 높을 것 같다는 건 거의 확실하다고 봅니다. 주변 사람이 우리를 प्रेरस(inspire)합니다. 좋은 사람들과 함께 일하면 그 자체가 나를 앞으로 끌어줍니다. 스탠퍼드에서는 훌륭한 학생과 교수진이 있고, 또 하나의 강점은 ‘connective tissue’입니다. 최첨단 AI 랩(frontier labs)에서 일하는 많은 사람들은 스탠퍼드 여러 교수들의 제자였던 경우가 많습니다. 그 관계망 덕분에, 인터넷에 아직 공개되지 않은 최전선 지식(bleeding edge AI)을 우리는 관계와 우정으로 더 빨리 듣기도 합니다. 어떤 회사가 뭔가를 했을 때, 교수진의 친구가 다른 곳에 전화를 걸어 “그거 진짜 되냐?”고 확인하는 식입니다. 이런 촘촘한 관계망이 우리를 끌어올립니다. 저 개인적으로도, 어떤 기술 방향을 고민하다가 최전선 연구에 가까운 사람(스탠퍼드 연구자나 프런티어 랩 사람)과 통화 한두 번으로 몰랐던 사실을 듣고, 프로젝트의 기술 아키텍처(technical architecture)를 바꾼 적이 많습니다. 그래서 스탠퍼드에 있는 동안 친구를 만들고 이 connective tissue를 활용하세요. 관계망에서 얻는 작은 조언들—“그거 해봐”, “그건 하지 마”, “그건 PR이야 무시해”—이런 것들이 프로젝트 방향을 조향(steer)하는 데 큰 차이를 만듭니다. 스탠퍼드는 세계에 좋은 대학이 많지만, ‘leading AI groups’와 연결된 관계망의 풍부함 측면에서 지금 이 시점의 스탠퍼드는 정말 독특한 위치에 있다고 생각합니다. PR처럼 들리기 싫지만, 진짜로 그렇게 느낍니다. 그리고 취업을 할 때도, 회사 로고가 아니라 ‘매일 같이 일할 사람들’이 커리어 성공에 훨씬 더 중요합니다. 제가 이전에 수업에서 반복해 말한 이야기 하나가 있는데, 스탠퍼드 학생 한 명이 유명 AI 브랜드 회사에서 오퍼를 받았는데, 그 회사가 “어떤 팀에 배정될지는 말 못 한다. 로테이션/매칭 시스템이 있다. 먼저 계약서에 사인해라. 그다음에 프로젝트를 정하겠다”라고 했습니다. 그 학생은 부모님도 자랑스러워하고, 흥미로운 AI 프로젝트를 기대하며 입사했습니다. 그런데 사인한 뒤 배정된 곳은 회사의 백엔드 Java 결제(payment processing) 시스템이었습니다. Java 백엔드 결제를 하고 싶은 분들을 폄하하는 게 아닙니다. 훌륭한 일입니다. 다만 이 학생은 AI를 하려고 온 사람이었는데 AI 프로젝트가 아니었던 겁니다. 그는 약 1년 동안 매우 좌절했고, 결국 1년쯤 지나 회사를 떠났습니다. 더 안타까운 건, 제가 CS230에서 이 이야기를 이미 했는데도, 몇 년 뒤 또 다른 학생이 같은 회사에서 비슷한 경험을 했다는 것입니다(프로젝트는 결제가 아니었지만 ‘원하는 AI가 아닌’ 다른 일이었습니다). 그래서 “내가 실제로 매일 함께 일할 팀이 누구인지”를 최대한 확인하고, 나를 प्रेर는 사람들에 둘러싸이도록 하는 게 중요합니다. 회사가 끝까지 팀 배정을 말해주지 않는다면, 저는 솔직히 걱정이 됩니다. 가장 ‘핫한’ 로고의 회사보다, 로고는 덜 핫해도 정말 좋은 팀—똑똑하고 मेहन하게 일하고 AI로 좋은 일을 하려는 팀—을 찾으면 더 빨리 배우고 커리어가 더 잘 성장하는 경우가 많습니다. 우리는 로고의 흥분에서 배우는 게 아니라, 매일 같이 일하는 사람에게서 배웁니다. 제가 지금 주는 조언의 1순위는 이겁니다. 강력한 소프트웨어를 더 빠르게 만들기가 그 어느 때보다 쉬워졌습니다. 그러니 책임감 있게 하세요. 남을 해치는 소프트웨어는 만들지 마세요. 동시에, 여러분 각자가 만들 수 있는 것이 너무 많습니다. 세상에는 아이디어가 사람보다 훨씬 많고, 그것을 만들 수 있는 기술을 가진 사람은 부족합니다. 신입 구직이 어려워졌다는 얘기도 있지만, 동시에 많은 팀은 숙련된 사람을 충분히 찾지 못합니다. 어떤 프로젝트는 여러분이 만들지 않으면 아무도 안 만들 수도 있습니다. 그러니 남을 해치지만 않으면, 허락을 기다릴 필요가 없습니다. 누가 먼저 하길 기다릴 필요도 없습니다. 실패 비용이 낮아졌습니다. 주말 하나를 날리더라도 배우면 그걸로 충분히 괜찮습니다. 마지막으로, 어떤 곳에서는 ‘남에게 열심히 일하라’고 말하는 것이 정치적으로 올바르지 않다고 여겨지기도 합니다. 저는 그냥 말하겠습니다. 열심히 일하세요. 물론 어떤 사람은 삶의 국면상 열심히 일할 수 없는 시기가 있습니다. 저도 아이들이 태어난 직후 잠깐은 열심히 못 했습니다. 부상이나 장애 등 타당한 이유로 지금 열심히 못 하는 분들도 있습니다. 그분들을 존중하고 지원해야 합니다. 그럼에도, 제가 본 제 박사과정 학생들 중 성공한 사람은 모두 정말 열심히 했습니다. 새벽 2시에 하이퍼파라미터 튜닝(hyperparameter tuning)하는 것—저도 해봤고, 지금도 가끔 합니다. 만약 여러분이 열심히 일할 수 있는 처지라면, 지금은 기회가 너무 많습니다. 저처럼 주말과 밤에 코딩하고 만들고 유저 피드백을 받는 것이 재미있다면, 그렇게 ‘lean in’하면 성공 확률이 올라갑니다. 어떤 사람은 제가 열심히 일하라고 말해서 싫어할 수도 있겠지만, 솔직히 열심히 하는 사람은 더 많은 일을 해냅니다. 다만 열심히 못 하는 분들도 존중해야 합니다. 주말에 멍하니 TV를 보기 vs 주말에 에이전틱 코더(agentic coder)를 돌려서 뭔가를 시도하기—저는 거의 항상 후자를 고르겠습니다. (아이들과 같이 보는 쇼라면 전자도 합니다.) 이제 제 이야기는 여기까지 하고, 제 친구 Laurence Moroney에게 무대를 넘기겠습니다. Laurence는 오랜 기간 온라인 교육을 해왔고, TensorFlow와 PyTorch를 많은 사람에게 가르쳤습니다. 구글(Google)에서 오랫동안 lead AI advocate였고, 지금은 Arm에서 팀을 이끌고 있습니다. 저는 그의 책도 여러 권 읽었고, 최근에는 PyTorch 책(Introduction to PyTorch)도 냈는데 아주 훌륭합니다. [Laurence Moroney]: 감사합니다. Andrew가 방금 말한 ‘같이 일할 사람을 고르는 것’의 중요성을 반대 방향에서도 강조하고 싶습니다. 회사가 여러분을 인터뷰할 때, 회사도 ‘함께 일할 사람’을 고르는 겁니다. 좋은 회사는 함께 일할 사람을 정말 신중히 고릅니다. 저는 지난 18개월 동안 특히 젊은 사람들 멘토링을 많이 했는데, 그중 한 청년의 이야기를 들려드리겠습니다. 그는 매우 교육을 잘 받았고 경험도 훌륭했고, ‘초엘리트 코더(super elite coder)’였습니다. 어떤 도전도 다 풀어낼 수 있는 사람이었는데, 4월에 직장에서 해고(layoff)됐습니다. 그는 의료 소프트웨어(medical software) 분야에 있었고, 그 업계는 크게 바뀌고 있었으며 연방정부(Federal government)에서 여러 영역의 자금이 줄며 해고를 겪었습니다. 그런데 그 청년은 해고 직전에 여자친구와 헤어졌고, 몇 주 뒤에는 반려견이 죽었습니다. 상태가 좋지 않았습니다. 몇 달 뒤 저는 그와 앉아 그의 구직 상황을 봤는데, 그는 지원한 직업을 스프레드시트로 추적하고 있었고, 무려 300개가 넘는 지원을 기록하고 있었습니다. 그중 일부는 Meta 같은 회사에서 면접 프로세스에 들어갔고, Microsoft도 있었고, 또 다른 대형 테크 회사도 있었습니다. 많은 면접 루프(loop)를 돌았고, 그는 매번 “나는 정말 잘했다. 코딩도 다 풀었다. 사람들과도 대화가 잘됐다”고 느꼈습니다. 그런데 매번 거의 하루 안에 리크루터가 전화해 “불합격”이라고 했습니다. 정말 가슴이 무너졌죠. 또 어디였냐면, Jeff Bezos의 회사—Amazon이 아니라, Bezos의 다른 회사—에서도 인터뷰를 봤다고 했습니다. 저는 그와 모의면접(mock interview)을 하며 조정(fine tuning)하기 시작했는데, 너무 좋은 후보인데도 뭐가 문제인지 바로는 안 보였습니다. 그러다 저는 일부러 ‘매우 سخت한 인터뷰’를 해보기로 했습니다. 어려운 LeetCode도 주고, 코드의 구석 케이스(corner case)도 들이대고, 위기 상황에서 어떻게 반응하는지 봤습니다. 그가 보인 반응은 채용 팸플릿에 적힌 조언을 그대로 따른 것이었습니다. 그런 팸플릿에는 “의견을 말할 기회가 있으면 버텨라(stand your ground). backbone을 가져라. 흔들리지 마라” 같은 말이 있습니다. 그는 그걸 “굉장히 공격적으로 버텨라”로 해석했던 겁니다. 제가 그의 코드에 구멍을 지적하고, 안 될 수 있는 케이스를 던지면, 그는 ‘등을 세우는’ 과정에서 면접 환경에서 적대적(hostile)으로 보였습니다. 인터뷰어 입장에서 보면, 그는 전형적인 ‘10x engineer’일 수 있지만, 그런 태도라면 저는 팀에 두고 싶지 않습니다. 우리는 그 부분을 함께 고쳤고, 조정했습니다. 이상한 건 그는 원래 정말 좋은 사람이었다는 겁니다. 다만 잘못된 조언을 그대로 따랐던 거죠. 그다음 그가 지원하던 회사는 ‘팀워크’를 매우 중시하는 곳이었는데, 좋은 소식은 그가 그 회사에 합격했다는 겁니다. 그는 해고되기 전 직장보다 연봉이 두 배(double)로 올랐고, 지금 돌아보면 ‘6개월의 fun employment’였다고 말합니다. 하지만 그 시기엔 정말 힘들었습니다. 그래서 여러분도, 여러분이 회사를 고르는 것처럼 회사도 여러분을 고른다는 점을 기억하세요. “버텨라”는 조언은 좋지만, 그 과정에서 ‘jerk’가 되지 마세요. 저는 Laurence입니다. 저는 ChatGPT가 ‘딸기(strawberry)에 노(oars)가 몇 개나 있는지’ 생각하는 것보다 더 많은 ‘수십 년’ 동안 테크 업계에서 일해왔습니다. Microsoft에서 오래 일했고, Google에서도 오래 일했고, Reuters 같은 곳에서도 일했고, 스타트업에서도 미국과 해외에서 일했습니다. 오늘 제가 이야기하고 싶은 건, 특히 AI에서 지금 커리어 지형이 어떻게 생겼는가입니다. Andrew가 말한 것처럼 스탠퍼드 네트워크와 프레스티지(prestige)를 활용할 수 있고, 저는 “가진 무기를 다 쓰라(use every weapon you have)”고 말하고 싶습니다. 왜냐하면 지금의 지형은 이상적이지 않습니다. 뉴스를 보면 대규모 테크 해고(massive tech layoffs), 채용 둔화, 이런 것들이 보입니다. 하지만 올바르게 접근하면 나쁜 일만은 아닙니다. 그래서 우선 ‘잡 마켓 리얼리티 체크’부터 하죠. (강의실에) 여러분은 주니어인가요? 올해 졸업? 내년? 대체로 3학년/4학년?—그럼 이번 여름 졸업이겠네요. 지금 이미 구직 중인 분? 꽤 있네요. 성공한 분?… 거의 없고 한 분 있네요. 여러분도 체감하겠지만, 주니어(graduate level) 채용이 크게 둔화했고, 화제성 있는 해고가 헤드라인을 장악합니다. Google에서 제가 있었을 때도 사상 최대 해고가 있었고, Amazon, Microsoft 등에서도 해고를 봤습니다. 엔트리 레벨 포지션이 부족해 ‘느껴집니다(feels)’. 저는 ‘feels’에 밑줄을 치고 싶은데, 조금 뒤에 더 자세히 설명하겠습니다. 경쟁은 치열합니다. 그런데 걱정해야 하냐? 저는 ‘아니다’라고 말합니다. 올바른 방식으로 접근하면, 특히 AI 지형이 얼마나 빠르게 변하는지 이해하면, 올바른 마인드셋을 가진 사람은 잘 될 겁니다. AI 채용 지형이 바뀌는 이유는 AI 산업 자체가 바뀌기 때문입니다. 저는 처음 AI에 1992년에 들어갔고, AI 윈터(AI winter) 직전에 잠깐 일하다가 크게 무너지는 걸 봤습니다. 그래도 AI에 ‘물렸다’가 아니라 ‘중독됐다’고 할 정도로 관심이 남았고, 2015년 Google이 TensorFlow를 런칭할 때 다시 깊게 들어와 AI 붐을 함께 봤습니다. 그런데 2021~2022년에는 글로벌 팬데믹(global pandemic)이 있었고, 산업 전반의 둔화가 왔습니다. 회사들은 매출과 ‘직접 매출을 만드는 일’로 피벗(pivot)해야 했습니다. Google에서 TensorFlow는 오픈소스(open-source)였고 직접 매출을 만들지 않았기 때문에 축소가 시작됐고, 전 세계 많은 회사가 채용을 줄였습니다. 그 다음 2022~2023년으로 가면, 팬데믹에서 나오며 ‘채용을 안 했던 누적(logjam)’이 있었고, 동시에 AI가 폭발적으로 부상했습니다. 세상이 AI-first로 바뀌며 모든 회사가 미친 듯이 채용해야 했습니다. 그 결과 2022~2023년에는 ‘오버하이어링(overhiring)’이 발생했고, 자격이 충분치 않은 사람이 더 높은 포지션을 받기도 했습니다. AI가 이력서에 있다는 이유만으로 채용되는 일도 있었고, 인재 쟁탈전(talent grabs)과 ‘일단 데려와서 나중에 뭘 할지 생각하자’ 같은 일이 많았습니다. 그리고 2024~2025년은 ‘대각성(the great wake-up)’입니다. 많은 회사가 오버하이어링을 깨닫고, 업무에 비해 덜 준비된 사람들(underqualified)이 많다는 걸 알게 됩니다. 이제 회사들은 AI 스킬에 훨씬 조심스럽습니다. 하지만 이 조정 국면에서도, 전략적으로 접근하면 기회는 여전히 크고 많습니다. 그래서 오늘은 여러분이 그걸 어떻게 하느냐를 이야기하려 합니다. 제가 보는 성공의 3가지 기둥(pillars)이 있습니다. 지금은 이력서에 ‘AI’만 써서 뽑히는 시대가 아니고, 이 3가지 기둥을 ‘말’로만이 아니라 ‘보여줘(show)’야 합니다. 하지만 보여주기는 오히려 지금이 역사상 가장 쉬운 때입니다. Andrew가 말한 것처럼 ‘프롬프트로 코드를 만들어내는(prompt things into existence)’ 능력이 있습니다. Andrew는 ‘vibe code’라는 말은 싫어하지만, 어쨌든 프롬프트로 구현을 빨리 만들어 보여줄 수 있습니다. Andrew가 엔지니어와 PM 이야기를 했는데, 저도 비슷한 경험이 있습니다. 저는 Google에 두 번 인터뷰했다가 두 번 떨어졌습니다. Microsoft에서 성공했고 책도 20권+ 썼고 대학 강의도 했는데도요. 두 번은 PM 직군으로 봤는데 떨어졌고, 엔지니어로 봤더니 “왜 진작 안 왔냐”고 하며 뽑았습니다. 그만큼 ‘좋은 엔지니어’가 중요합니다. 그리고 엔지니어 대 PM 비율이 바뀌는 시대엔 엔지니어링 스킬이 더 값집니다. 세 기둥 중 첫째는 ‘깊이 있는 이해(understanding in depth)’입니다. 두 가지 의미가 있습니다. 하나는 학문적으로, 머신러닝(machine learning)과 모델 아키텍처(architecture)를 깊이 이해해 논문(papers)을 읽고 이해하고, 그것을 실제로 적용하는 능력입니다. 다른 하나는 트렌드(trends)의 ‘맥을 짚는’ 능력입니다. 신호 대비 잡음(signal-to-noise)에서 신호가 우세한 곳이 어디인지 감을 갖는 것입니다. 둘째는 ‘비즈니스 포커스(business focus)’입니다. Andrew가 아까 정치적으로 올바르지 않을 수도 있는 말을 했는데, 저도 비슷하게 하나 하겠습니다. ‘하드워크(hard work)’는 모호한 말이니, 저는 “사람은 측정하는 대로 된다(you are what you measure)”고 봅니다. 요즘 996(오전 9시~오후 9시, 주 6일) 같은 게 열심히 일하는 척도로 나오지만, 그건 ‘시간’의 척도이지 ‘성과’의 척도는 아닙니다. 하루 8시간이나 6시간만 일해도 매우 생산적일 수 있습니다. 저는 ‘투입 시간’이 아니라 ‘산출(output)’로 측정합니다. 저는 책을 많이 썼는데, Andrew가 들었던 그 책은 약 2개월 만에 썼습니다. 사람들이 “너는 16시간씩 일하냐?”고 묻지만, 제 비결은 야구(baseball)입니다. 야구는 TV로 보면 3.5~4시간 걸리는 느린 경기라서, 저는 야구를 배경으로 틀어놓고 글을 씁니다. 그게 제 ‘하드워크’의 방식이었습니다. 그래서 여러분도 ‘열심히’의 정의를 산출로 두고, 그 산출을 내가 원하는 비즈니스 방향과 정렬(alignment)시키라고 말하고 싶습니다. “지금 하는 일에 맞춰 산출하지 말고, 내가 하고 싶은 일에 맞춰 산출하라.” 제가 Google에 세 번째 도전에서 들어갔을 때도 같은 원리였습니다. 당시 Cloud 팀 인터뷰를 보면서, 저는 Java 책을 막 썼고, Google Cloud에서 Java로 할 수 있는 걸 보여주고자 했습니다. 그래서 기술적 분석(technical analytics)으로 주가 예측(stock price prediction)하는 Java 앱을 Cloud에서 돌리는 코드를 만들었습니다. 그 결과 면접 루프가 “버스에 골프공 몇 개 들어가냐” 같은 질문이 아니라, 제 코드에 대해 묻는 시간이 됐습니다. 주도권이 제게 왔고, 제가 아는 것에 대해 이야기할 수 있었습니다. AI에서도 마찬가지입니다. 내가 원하는 포지션에 맞춰 제품/코드 산출을 만들어 보여주고, 그 산출이 회사 비즈니스와 어떻게 연결되는지 설명할 수 있어야 합니다. 셋째 기둥은 ‘딜리버리 편향(bias towards delivery)’입니다. “아이디어는 싸고, 실행이 전부(Ideas are cheap, execution is everything).” 저는 면접에서 아이디어만 푹신한 사람도 많이 봤고, 반대로 덜 멋진 아이디어지만 아주 잘 그라운딩(grounding)한 사람도 봤습니다. 합격은 보통 후자였습니다. 이제 ‘지금 AI에서 일하는 현실’로 가보죠. 불과 2~3년 전만 해도 “이미지 분류기(image classifier) 하나 만들 수 있으면” 엄청 대우받고 6자리 연봉과 주식을 받곤 했습니다. 지금은 그렇지 않습니다. 지금은 P 단어, 즉 ‘프로덕션(production)’입니다. 새 모델을 만들든, 모델을 최적화하든, 유저를 이해하든, UX가 매우 중요하든, 모든 것이 프로덕션으로 수렴합니다. 회사들은 바텀라인(bottom line)을 최적화하고 있고, 저는 “바텀라인의 바텀라인은 바텀라인이다”라는 말을 합니다. 그래서 현실 1: 비즈니스 포커스는 이제 협상 불가(non-negotiable)입니다. 여기서 제가 또 정치적으로 올바르지 않을 수도 있는 말을 하겠습니다. 지난 10년간 대기업, 특히 실리콘밸리에서는 사람의 ‘전인적 자기(whole self)’를 직장으로 가져오게 하는 문화가 강했고, 그 과정에서 다양한 사회 이슈 활동(activism)이 회사 안으로 들어왔습니다. 저는 활동 자체가 나쁘다고 말하는 게 아닙니다. 정의(justice) 관련 원인을 지지하는 것도 전혀 문제 없습니다. 하지만 제 경험상 ‘과도한 비중(overindexing)’은 비즈니스보다 활동을 우선하게 만들고, 회사가 거기에 발목 잡히는 경우가 있었습니다. 예를 들어 약 2년 전 Google에서 어떤 활동가들이 Google Cloud 책임자의 사무실에 침입해 sit-in을 하고, 그의 책상 위에 화장실을 보고… 같은 일이 있었습니다. 이건 활동이 선을 넘은 사례입니다. 그 결과 좋은 의도까지도 함께 손상되며, 해고가 늘고, 활동이 억제되고, 비즈니스 포커스가 더 강하게 비협상 요소가 되었습니다. 지금은 진자(pendulum)가 반대편으로 크게 흔들리는 중입니다. 현실 2: 리스크 완화(risk mitigation)가 업무의 일부입니다. 특히 AI에서는 더 중요합니다. 어떤 비즈니스 프로세스를 ‘휴리스틱(heuristic) 컴퓨팅’에서 ‘지능형(intelligent) 컴퓨팅’으로 전환할 때의 리스크를 이해하고, 어떻게 완화할지 설명하는 마인드셋은 면접에서도 매우 강력한 스킬입니다. 현실 3: 책임(responsibility)의 정의가 진화하고 있습니다. 예전에는 “모두를 위해 AI가 작동해야 한다”가 먼저였고, 그 다음이 “비즈니스에 도움이 돼야 한다”인 경우도 있었는데, 지금은 “AI가 작동하고, 비즈니스를 드라이브하고, 그 다음 모두를 위해 작동해야 한다”로 우선순위가 재정렬되는 흐름이 있습니다. 과거의 뒤집힌 우선순위가 유명한 실패를 낳기도 했습니다. 제가 예로 하나 보여드리겠습니다. (창을 넘기며) 텍스트-투-이미지(text-to-image)로 유명한 Gemini에서 몇 년 전 있었던 일입니다. 저는 responsible AI를 많이 다뤘는데, 여기서 중요한 건 대표성(representativeness)과 편향(bias) 문제입니다. 예를 들어 “의사(doctors)” 이미지를 생성하면 학습셋에 남성이 많으면 남성 의사가 더 나오기 쉽고, “간호사(nurses)”는 여성이 많으면 여성 간호사가 나오기 쉽습니다. 이는 부정적 고정관념을 강화할 수 있습니다. 그래서 저는 Gemini가 이런 편향을 어떻게 상쇄하려는지 테스트해보려 했습니다. 저는 “여름 드레스를 입고 밀짚모자를 쓴 젊은 Asian 여성이 옥수수밭(cornfield)에서 iPhone을 집중해서 바라본다” 같은 프롬프트를 넣었고, 아름다운 이미지가 나왔습니다. 그 다음 “Indian”으로 바꾸니 인도 여성 이미지가 잘 나왔고, “Black”으로 바꾸니 왜인지 3장만 나왔지만 프롬프트를 따랐습니다. “Latina”도 4장이 나왔고, 한 장은 Hermione Granger처럼 보이기도 했지만 전반적으로 괜찮았습니다. 그런데 “Caucasian”을 넣자 무슨 일이 벌어졌을까요? “요청은 이해하지만, 사람 이미지를 생성하면 해로운 고정관념/편향을 낳을 수 있어 생성할 수 없다”라는 메시지가 나왔습니다. 매우 조악한 안전 필터(safety filter)였습니다. 방금 전까지 사람 이미지를 생성해놓고, ‘Caucasian’ 같은 단어를 트리거로 막아버린 겁니다. 저는 “Caucasian” 대신 “white”로 바꿔도 같은 식으로 거부당했고, 심지어 “지금은 사람 이미지를 만들지 않는다” 같은 말로 제 앞에서 거짓말까지 했습니다(방금 만들었으면서요). 그럼 제가 어떻게 우회했을까요? 저는 “Irish woman”을 요청했습니다. 그러자 문제 없이 ‘아일랜드 여성’ 이미지가 생성됐습니다. 그런데 모든 이미지에서 빨간 머리(red hair)였습니다. 저는 아일랜드에서 자랐고 아일랜드는 빨간 머리 비율이 세계에서 가장 높은 편이지만, 그래도 약 8% 정도입니다. 그런데 ‘아일랜드=빨간 머리’로 고정해 그리는 건 또 다른 문제를 낳을 수 있습니다. 중국의 어떤 지역에서는 ‘악마(demon)’를 빨간 머리로 묘사하기도 한다고 저는 들었습니다. 그러니까 여기서 책임 있는 AI가 어떤 관점에서는 다양성을 확보하려다, 다른 관점에서는 새로운 편향과 모욕 경계선의 문제를 만들었습니다. 안전 필터를 만든 사람들은 이 문제를 떠올리지 못했던 겁니다. 제가 말하는 “책임의 진화”는 이런 방향입니다. 책임은 이제 사회적 의제를 넘어서 ‘비즈니스 평판(reputation)을 손상시키지 않게 하는 것’ 같은 더 하드한 제약과도 결합합니다. (질문) 누군가 “역사적 맥락에서 인종/민족이 섞여 나오는 문제도 있었다고 들었다”고 말하자, 저는 “맞다. 예를 들어 ‘사무라이(samurai)’를 그리면 다양성 편향을 맞추려다 프롬프트를 가로채서 ‘다양한 배경의 사무라이’가 나오고, 남녀 사무라이, 여러 인종 사무라이가 섞이며 역사적 사실성과 충돌하는 문제가 있었다”는 취지로 답하겠습니다. 당시엔 프롬프트를 인터셉트(intercept)해 공정성(fairness)을 높이려는 매우 순진한(naive) 해결책이 들어가 있었고, 그로 인해 평판이 손상됐습니다. 지금은 많이 개선됐지만, 그 사례가 교훈입니다. 이제 ‘vibe coding’ 이야기로 가보겠습니다. 밈(meme)으로는 “코드 생성이 엔지니어를 쓸모없게 만든다”는 말이 돌지만, 저는 그게 전체 진실은 아니라고 봅니다. 숙련된 엔지니어일수록 이런 도구를 더 잘 씁니다. 저는 여러분이 ‘trusted advisor(신뢰받는 조언자)’ 관점으로 생각하길 권합니다. 면접이든 컨설팅이든, 회사를 상대로 “이게 어떤 함의를 갖는가”를 설명할 수 있어야 합니다. 생성 코드의 함의를 이해하는 가장 좋은 프레임은 ‘기술 부채(technical debt)’입니다. (질문) 기술 부채라는 표현을 아냐고 물었더니, 대부분 모른다고 해서 잠깐 설명하겠습니다. 부채(debt)를 생각해봅시다. 집을 사면서 50만 달러를 30년 모기지로 빌리면 이자 포함 상환액이 대략 두 배가 되어 100만 달러를 갚게 됩니다. 하지만 그 부채는 집 가치 상승, 렌트 회피 등으로 정당화될 수 있으니 ‘좋은 부채’일 수 있습니다. 반대로 신용카드 고금리로 충동구매를 하면, 200달러짜리 신발이 상환할 때 500달러가 될 수도 있는데, 그 가치는 보통 그만큼 나오지 않으니 ‘나쁜 부채’입니다. 소프트웨어도 똑같습니다. 무엇을 만들든 부채가 생깁니다. 버그, 지원, 새로운 요구사항, 마케팅, 피드백 대응… 이런 것들이 모두 부채입니다. 부채를 피하는 유일한 방법은 아무것도 하지 않는 것입니다. 그래서 질문은 “vibe coding으로 무언가를 만들 때, 내가 떠안는 기술 부채가 그만한 가치가 있느냐”입니다. 부채는 버그 수정, 유지보수 설득, 문서화, 기능 추가 등 ‘나중에 갚아야 하는 추가 작업’입니다. 소프트 부채(soft debt)와 하드 부채(hard debt)도 있습니다. 저는 스타트업들과 일할 때, 많은 팀이 “Replit이나 GPT나 Anthropic을 열고 빨리 프로토타입을 만들자, 투자자를 만나자”로 달려가는 걸 봅니다. 물론 가능하지만, debt, debt, debt가 항상 따라옵니다. 좋은 금융인은 부채를 잘 관리해 부자가 되고, 좋은 코더는 기술 부채를 잘 관리해 부자가 된다고 저는 말합니다. 그럼 ‘좋은 기술 부채(모기지)’는 어떻게 만들고, ‘나쁜 기술 부채(고금리 신용카드)’는 어떻게 피하나? 첫째, 목표(objectives)가 명확해야 합니다. 무작정 ChatGPT를 켜고 코드를 뽑기 전에 무엇을 만들지 분명해야 합니다. 둘째, 비즈니스 가치(business value)를 전달했는가입니다. 멋진 웹사이트를 몇 시간 동안 만들었는데 “그래서 뭐?”가 되면 부채만 남습니다. 셋째, 인간의 이해(human understanding)입니다. 아무도 이해 못 하는 코드가 최악의 부채입니다. 나만 이해하고 나중에 더 좋은 직장으로 떠나면, 회사는 그 코드에 종속됩니다. 그래서 문서화, 명확한 알고리즘, 변수명 정리 같은 기본이 중요합니다. 또 다른 나쁜 부채는 ‘문제 없는 해법(해법이 먼저인)’입니다. “망치만 있으면 모든 게 못으로 보인다.” 대기업에서 사람들이 막 만들어 체크인(check-in)해버리면 좋은 코드와 나쁜 코드가 섞여 스파게티(spaghetti) 코드가 됩니다. 제가 지금 겪는 사례로는 macOS 앱을 SwiftUI로 만들 때, 학습셋에는 iOS 코드가 훨씬 많아서, 모델이 계속 iOS API를 제안하는 문제가 있습니다. 프롬프트로 고치려다 보면 점점 스파게티가 되고, 결국 수동으로 많이 고쳐야 합니다. 그리고 ‘권위가 실력보다 우선(authority over merit)’도 나쁜 부채입니다. 어떤 VP가 신용카드로 Replit을 결제해 뭔가를 만들어놓으면, 그걸 고치는 건 누굽니까? 팀입니다. 이제 ‘하이프(hype) 사이클’로 가보죠. 저는 하이프가 우주에서 가장 강한 힘 중 하나라고 생각합니다. 특히 AI와 크립토(crypto) 같은 뜨거운 분야는 nonsense가 넘칩니다. 소셜 미디어의 화폐(currency)는 정확성(accuracy)이 아니라 참여(engagement)입니다. LinkedIn조차도 ‘영향력자(influencers)’가 Gemini나 GPT로 쓴 글로 참여를 농사짓는(farming engagement) 곳이 되어가고, 플랫폼은 그런 글을 보상하도록 설계되어 있습니다. 여러분이 신호와 잡음을 걸러내고, 주변을 신호 쪽으로 이끄는 사람이라면 큰 경쟁력이 됩니다. 좋아요/댓글 같은 빠른 피드백은 아닐지 몰라도, 면접이나 일에서 신호를 가져오면 엄청난 가치가 됩니다. 제가 하이프 사례를 하나 들겠습니다. 작년에 ‘에이전트(agent)’가 유행하자, 유럽의 한 회사가 “에이전트 구현을 도와달라”고 했습니다. 그때 제가 던진 가장 근본 질문은 “왜(why)?”였습니다. CEO는 “다들 에이전트로 비용 절감하고 비즈니스가 좋아진다더라”라고 했고, 출처는 LinkedIn과 Twitter 같은 곳이었습니다. 저는 계속 질문을 파고들어, 결국 그가 원하는 건 ‘세일즈팀 효율을 높이는 것’이라는 본질로 도달했습니다. “세일즈팀 효율을 높인다”는 문장에는 AI도 에이전트도 없습니다. 그러니 신뢰받는 조언자로서, 저는 ‘AI shill’이 아니라 ‘효율을 높이는’ 문제를 풀어야 합니다. 세일즈는 미팅 전 숙제(리서치)가 많고, 회사 웹사이트/LinkedIn을 뒤지는 데 시간이 낭비됩니다. 웹사이트 구조는 제각각이라 인지 부하(cognitive load)가 큽니다. 그 회사의 세일즈는 80% 시간을 리서치에, **20%**를 실제 판매(selling)에 쓰고 있었고, 커미션이 중요한 세일즈에게는 비효율이 컸습니다. 그래서 목표를 “20% 효율 개선”으로 두고, 그 다음에 AI와 에이전틱 AI를 도입했습니다. 그럼 AI와 에이전틱 AI의 차이는 무엇일까요? 저는 에이전틱 AI를 네 단계로 봅니다. 1) 의도(intent) 이해(LLM이 강함), 2) 계획(planning: 사용할 툴을 선언하고 단계로 쪼갬), 3) 실행(execution: 툴을 사용), 4) 성찰(reflect: 의도를 달성했는지 확인, 아니면 루프로 복귀). 이 프레임으로 파일럿을 만들었더니, 낭비 시간을 10~15% 절감했습니다. 그리고 의도치 않은 결과(unintended consequences)로 세일즈가 더 행복해졌습니다. 평균 세일즈가 몇 %p 더 팔고, 돈을 더 벌고, 일이 덜 고통스러워진 겁니다. 몇 시간 걸리던 리서치를 몇 분으로 줄인 브리프(brief)가 영업을 돕고, 모두에게 win-win-win이었습니다. 반대로 하이프에 끌려 “에이전트 만들어!”만 외치면, 스코핑(scoping)이 안 되어 실패합니다. 저는 “McKinsey가 지난주에 AI 프로젝트의 **85%**가 실패한다고 보고했다”는 이야기도 들었습니다. 주요 이유는 잘 스코프되지 않고 하이프 밴드왜건(bandwagon)에 올라타기 때문입니다. 최근 하이프 예시는 “소프트웨어 엔지니어링은 끝났다”, “할리우드(Hollywood)는 끝났다”, “연말까지 AGI” 같은 것들입니다. 저는 사우디아라비아(Saudi Arabia)에서 FYI라는 행사 디너에서 한 생성형 AI 회사 CEO가 “내년 이맘때면 프롬프트 하나로 90분 영상을 만들 수 있다. 그러면 할리우드 bye-bye”라고 말하는 걸 들었습니다. 하지만 2년이 지난 지금도 프롬프트 하나로 90분 영상을 만들진 못합니다. 설령 가능해도, 영화 전체 스토리를 담는 프롬프트는 무엇이냐는 문제가 남습니다. 이런 하이프는 관심을 끌지만, 여러분은 ‘왜(why)’를 묻고 신호를 찾아야 합니다. 그래서 하이프 항해 전략은: 트렌드를 객관적으로 평가하고, 진짜 기회를 보며, 유행성 방해물(fashionable distractions)은 무시하고, 리더십에 기술적 현실(technical reality)을 설명하는 능력을 갖추는 것입니다. 제가 들은 흥미로운 코칭 중 하나는 “가능한 한 평범하게(mundane) 설명하라”였습니다. 평범하게 만들수록 디테일이 보이고, 비기술 분야 전문가도 그 위에서 창의적으로 움직일 수 있습니다. 이제 전반 지형은 기회가 많지만, 리스크도 있습니다. 저는 타이타닉(Titanic)의 “빙산이 вперед(iceberg right ahead)” 장면을 떠올립니다. 그 전에 망루(crow’s nest) 두 사람이 추워서 그 얘기만 하고 쌍안경(binoculars)은 항구에 두고 와 버렸다는 장면이 있는데, 저는 그게 AI 산업의 은유라고 봅니다. 리스크를 보는 사람과 장비가 필요합니다. AI 버블(bubble) 이야기가 나오는데, 버블은 늘 있었습니다. 닷컴 버블(dotcom bubble)도 터졌지만 Amazon, Google 같은 ‘제대로 한 회사’는 살아남아 오히려 번성했습니다. pets.com 같은 “만들면 사람들이 온다” 마인드로 슈퍼볼 광고를 했지만 트래픽을 감당 못 하던 곳들은 사라졌습니다. AI 버블의 구조는 위에 하이프, 그 아래 대규모 VC 투자(massive VC investment), 비현실적 밸류에이션(unrealistic valuations), #MeToo 제품(남이 하니 나도) 같은 층이 있고, 맨 아래 아주 작은 ‘진짜 가치(real value)’가 있습니다. 저는 이미 VC 투자 분위기가 더 조심스러워지고 있다고 봅니다. 향후 5년을 보면, 저는 AI가 크게 두 갈래로 갈라질(bifurcation) 거라 봅니다. 하나는 ‘빅 AI’—더 큰 모델로 AGI와 더 큰 가치로 가려는 GPT/Gemini/Claude 같은 hosted 모델입니다. 다른 하나는 ‘스몰 AI’—오픈소스(open source)라는 말보다는 ‘오픈 웨이트(open weights)’ 혹은 ‘셀프 호스팅(self-hostable) 모델’이라 부르고 싶은 모델들입니다. 저는 Y Combinator에서 80% 회사가 중국발 작은 모델을 쓴다는 글을 읽었다고 했습니다. 중국은 서구처럼 초대형 모델에만 올인하지 않아 작은 모델에서 앞서갈 수도 있습니다. 어쨌든 앞으로는 “누군가가 대신 호스팅해주는 모델”과 “내가 직접 호스팅하는 모델”로 갈라질 가능성이 큽니다. 이 ‘셀프 호스팅’ 쪽은 아직 덜 서비스되는(underserved) 영역이라 기회가 큽니다. 그리고 이 영역에서 중요한 스킬은 파인튜닝(fine-tuning)입니다. 오픈 웨이트 모델을 특정 다운스트림 과업(downstream task)에 맞게 파인튜닝하는 능력입니다. 제가 직접 겪은 예로, 저는 할리우드 스튜디오들과도 일하는데, 스튜디오는 지식재산(IP)을 극단적으로 보호합니다. James Cameron의 Avatar와 관련한 소송 이야기도 있습니다. 그만큼 IP 민감도가 높아, 스튜디오는 GPT/Gemini 같은 서드파티에 시놉시스나 스토리를 넘기려 하지 않습니다. 그런데 LLM의 큰 기회는 ‘창작’만이 아니라 ‘분석(analysis)’입니다. 어떤 영화가 왜 흥행했고, 어떤 영화는 왜 실패했는지, 개봉 시기와 성과의 관계 등, 마진이 얇은 영화 산업에서 이런 분석은 큰 가치입니다. 이를 위해서는 영화 내용을 모델에 넣어야 하니, 셀프 호스팅 작은 모델이 유리합니다. 작은 모델은 계속 똑똑해지고 있습니다. “오늘의 7B 모델이 어제의 50B만큼 똑똑하다” 같은 식으로, 1년 뒤 7B는 과거의 300B 수준에 가까워질 것이라는 방향성 이야기도 있습니다. 법률/의료 등 프라이버시가 중요한 곳도 마찬가지입니다. 그래서 저는 버블이 터져도 살아남으려면: фундаментals에 집중하고, 진짜 솔루션을 만들고, 비즈니스를 이해하고, 무엇보다 스킬을 다변화(diversify)하라고 말합니다. 특정 API나 프레임워크만 하는 ‘원트릭 포니(one trick pony)’는 업계가 바뀌면 뒤처질 수 있습니다. (질문) NVIDIA가 특정 문제에 딱 맞는 사람을 뽑는다는데, ‘특정 분야 깊이’ vs ‘다변화’ 중 무엇이 중요하냐는 질문에 대해 저는, 특정 분야에 깊어지는 건 좋지만 “그것만 할 수 있는 상태”는 위험하다고 답했습니다. 열정이 있는 분야는 깊게 파되, 앱을 얹는 능력, 스케일링, 소프트웨어 엔지니어링, UX 등 ‘모델 지식 밖’의 스킬로 확장해야 합니다. 저는 또한 ‘스몰 AI’가 다음 큰 흐름이라고 믿습니다. Arm에서 하는 일도 그와 연결됩니다. 우리는 ‘AI everywhere all at once’로 가고 있고, AI=CPU+GPU라는 고정관념도 바뀌고 있습니다. 모바일에서는 SME(Scalable Matrix Extensions) 같은 기술로 CPU에서 AI 워크로드를 돌리는 혁신이 진행 중이고, Vivo와 Oppo 같은 중국 폰 벤더가 SME 지원 칩을 넣은 폰을 내기도 했습니다. 별도 칩이 필요 없고 전력/공간이 유리합니다. Alipay 사례로, 사진에서 ‘스시 먹은 장소’ 같은 것을 검색해 슬라이드쇼를 만드는 기능은 보통 백엔드가 필요합니다. 하지만 백엔드 방식은 1) 프라이버시(사진을 제3자에 공유), 2) 레이턴시(업로드/처리/다운로드), 3) 클라우드 운영 비용 문제가 있습니다. 이를 디바이스에서 자체 모델로 처리하면 사진은 기기 밖으로 안 나가고, 레이턴시가 줄고, 백엔드 비용도 절감됩니다. Apple도 이 흐름에 강하게 투자하고 있고, WWDC에서 A-series/M-series의 neural cores 같은 얘기를 하는 것도 같은 맥락입니다. 저는 그래서 Apple과 Apple Intelligence에 대해 ‘상당히 bullish’하다고 말했습니다. 마지막으로 저는 ‘artificial intelligence’의 숨은 부분은 ‘artificial understanding(인공적 이해)’라고 말하곤 합니다. 모델이 나 대신 이해하고, 그 이해를 바탕으로 새로운 것을 만들어주면, 여러분은 초능력(superpowers)을 갖게 됩니다. 제가 짧은 데모를 하나 보여드렸습니다. 제 아들이 아이스하키(ice hockey)를 하는 사진을 기반으로 “골을 넣는 장면”을 만들려 했는데, 저는 의도(intent)를 제대로 전달하지 못해, 실제로는 관중 없는 연습장인데 AI가 관중을 그려 넣고, 아들이 골을 크게 빗나가도 모두가 환호하고, 막대기가 두 개가 되고, 이름도 틀리는 결과가 나왔습니다. 저는 이걸 에이전틱 워크플로로 풀지 않았습니다. 즉, 1) 의도 이해, 2) 사용할 툴(예: Veo)의 특성 이해, 3) 계획, 4) 실행과 반성의 루프를 거치지 않았던 겁니다. 반면 제가 자문하는 영화 생성 스타트업에서는 같은 엔진을 쓰더라도, 전체 스토리 컨텍스트, 8초 제한, 대사 명확성 같은 제약을 LLM에 함께 주고, LLM이 제가 못 쓰는 수준의 상세하고 영화적(loquacious, descriptive) 프롬프트를 작성하게 하자 감정(emotion) 표현이 훨씬 나아졌습니다. (질문) 에이전틱 워크플로로 개선된 건가, 아니면 하키 데이터 부족 같은 학습셋 편향 때문인가에 대해 저는, 같은 대상 비교는 아니지만 “의도 이해 단계에서 LLM이 샷/앵글/감정 표현을 더 잘 묘사해주는 것”이 매우 컸고, 툴(Veo)의 특성(액션에 약하고 슬로우 카메라 풀로 감정에 강함)을 반영해 계획을 세운 것이 비용(영상 생성은 4개에 2~3달러)을 절약하며 성공률을 높였다고 답했습니다. (질문) AI 산업에서 가장 놀란 점은? 저는 하이프가 생각보다 훨씬 강하게 의사결정을 지배한다는 것, 그리고 단기 이익을 장기 선보다 우선하는 경향이 놀라웠다고 답했습니다. 예로 Google의 TensorFlow 프로페셔널 서티피케이트(professional certificate) 프로그램은 연간 10만~15만 달러 정도 비용이 들었고, 시리아(Syria)에 살던 청년이 서티피케이트로 독일로 옮겨 가족을 돕는 등 엄청난 선한 영향과 goodwill이 있었지만, 직접 매출이 없다는 이유로 종료됐습니다. 또 다른 놀라움은 ‘AI로 성공할 것 같지 않던 사람’이 AI로 엄청난 성과를 내는 사례들입니다. 예를 들어 제 아이스하키 선수 출신 친구는 13살에 학교를 그만뒀다고 스스로 “가장 멍청한 사람”이라 말하지만, 비영리 단체 운영 보고서를 만들 때 컨설팅 비용 연간 15만 달러를 쓰던 걸 ChatGPT로 2시간 만에 자동화해 절약했고, 그 돈이 취약계층 아이들의 장비/레슨으로 들어가게 됐습니다. (질문) 엔지니어가 아닌 인문계 등은 하이프를 어떻게 내비게이션하나? 저는 그게 우리가 ‘trusted advisor’로 도울 기회라고 답했습니다. 보상 메커니즘(정확성보다 참여)을 이해시키고, 비전문가의 지능과 강점을 존중하며 어려운 부분을 함께 풀어주면 됩니다. (질문) 과학 연구에서 AI/ML은 언제 좋고 언제 조심해야 하나? 저는 가능한 한 강력한 도구를 쓰되 결과를 현실에 대조해 검증하라고 답했습니다. 예로 웨일스(Wales)의 연구자가 뇌암(brain cancer) 연구에서 GPU 접근이 병목이었는데, 부서에 GPU 1개를 10명이 나눠 쓰며 화요일 오후 반나절만 쓸 수 있었고, 저는 Google Colab을 보여줘 클라우드 GPU를 무료로 쓰게 하며 연구 속도를 크게 올린 사례가 있었습니다. (질문) AI가 사회적 평등/불평등의 힘이 되나? 저는 “둘 다 될 수 있고, 둘 다 아닐 수도 있다”고 했습니다. 도구는 사용 방식에 달렸고, 저는 ‘선의(good intent)를 가정하되 악의(bad intent)에 대비하라’는 원칙을 말했습니다. [Andrew Ng]: (마무리) 오늘 좋은 토론과 질문 감사했고, Laurence에게 큰 박수 부탁드립니다.