-- 전 테슬라 AI 담당 이사였던 안드레이 카파티를 환영합니다. 안녕하세요, 정말 많은 분들이 오셨네요.
-- 저는 오늘 인공지능 시대의 소프트웨어에 대해 이야기하게 되어 기쁩니다. 여기 계신 많은 분들이 학사, 석사, 박사 학생이시고 곧 업계에 진출할 것이라고 들었습니다. 저는 지금이 업계에 진출하기에 정말 독특하고 매우 흥미로운 시기라고 생각합니다. 근본적으로 그 이유는 소프트웨어가 다시 변하고 있기 때문입니다. 제가 '다시'라고 말하는 이유는 이 강연을 이미 했었기 때문입니다. 하지만 소프트웨어는 계속해서 변하기 때문에 저는 새로운 강연을 만들 자료가 많습니다. 소프트웨어는 매우 근본적으로 변하고 있다고 생각합니다. 대략적으로 말해서 소프트웨어는 70년 동안 그렇게 근본적인 수준에서 많이 변하지 않았습니다. 그리고 지난 몇 년 동안 두 번 정도 빠르게 변했다고 생각합니다. 그래서 해야 할 일이 엄청나게 많고, 작성하고 다시 작성해야 할 소프트웨어도 엄청나게 많습니다.
-- 소프트웨어의 영역을 한번 살펴보겠습니다. 이것을 소프트웨어 지도로 생각한다면, 이것은 맵 오브 깃허브(map of GitHub)라는 정말 멋진 도구입니다. 이것은 작성된 모든 소프트웨어와 같습니다. 이것들은 디지털 공간에서 작업을 수행하기 위한 컴퓨터 지침입니다. 이곳을 확대해 보면 이것들은 모두 다른 종류의 저장소이고, 이것이 작성된 모든 코드입니다. 몇 년 전 저는 소프트웨어가 변화하고 있고 새로운 유형의 소프트웨어가 존재한다는 것을 관찰했습니다. 저는 당시 이것을 소프트웨어 2.0이라고 불렀습니다. 여기서 아이디어는 소프트웨어 1.0은 컴퓨터를 위해 직접 작성하는 코드이고, 소프트웨어 2.0은 기본적으로 신경망, 특히 신경망의 가중치라는 것이었습니다. 이 코드를 직접 작성하는 것이 아니라, 데이터 세트를 튜닝하고 최적화 프로그램을 실행하여 신경망의 매개변수를 생성합니다. 당시에는 신경망이 의사결정 트리와 같은 다른 종류의 분류기로만 여겨졌다고 생각합니다. 그래서 저는 이러한 프레임워크가 훨씬 더 적절하다고 생각했으며, 이제 우리는 실제로 깃허브와 유사한 것을 가지고 있습니다.
-- 소프트웨어 2.0 영역에서 허깅 페이스(Hugging Face)는 기본적으로 소프트웨어 2.0의 깃허브와 같다고 생각합니다. 또한 모델 아틀라스(model atlas)도 있고, 궁금하시면 거기에 작성된 모든 코드를 시각화할 수 있습니다. 참고로 가운데에 있는 거대한 원은 이미지 생성기인 플럭스(flux)의 매개변수입니다. 그래서 누군가가 플럭스 모델 위에 튜닝을 할 때마다 이 공간에 깃 커밋(git commit)을 생성하고 다른 종류의 이미지 생성기를 만듭니다.
-- 그래서 기본적으로 소프트웨어 1.0은 컴퓨터를 프로그래밍하는 컴퓨터 코드이고, 소프트웨어 2.0은 신경망을 프로그래밍하는 가중치입니다. 여기 알렉스넷(AlexNet) 이미지 인식 신경망의 예시가 있습니다. 지금까지 우리가 익숙했던 모든 신경망은 이미지에서 카테고리로 분류하는 등 고정된 기능을 하는 컴퓨터와 같았습니다. 그리고 제가 생각하기에 근본적으로 바뀐 것은 대규모 언어 모델(LLM)을 통해 신경망이 프로그래밍 가능하게 되었다는 점입니다.
-- 그래서 저는 이것을 상당히 새롭고 독특하다고 봅니다. 이것은 새로운 종류의 컴퓨터이며, 제 생각에는 **소프트웨어 3.0**이라는 새로운 명칭을 부여할 가치가 있습니다. 기본적으로 여러분의 프롬프트가 이제 LLM을 프로그래밍하는 프로그램이 됩니다. 놀랍게도 이 프롬프트들은 영어로 작성됩니다. 그래서 이것은 매우 흥미로운 프로그래밍 언어입니다.
-- 어쩌면 차이점을 요약하자면, 예를 들어 감성 분류를 한다면 파이썬 코드를 작성하여 감성 분류를 하거나, 신경망을 훈련시키거나, 대규모 언어 모델에 프롬프트를 입력할 수 있습니다. 여기서 이것은 몇 개의 짧은 프롬프트이고, 이것을 변경하여 컴퓨터를 약간 다른 방식으로 프로그래밍할 수 있다고 상상할 수 있습니다.
-- 그래서 기본적으로 우리는 소프트웨어 1.0, 소프트웨어 2.0을 가지고 있으며, 이제 깃허브의 많은 코드가 더 이상 단순한 코드만이 아니라는 것을 아마 보셨을 겁니다. 코드 사이에 많은 영어가 섞여 있습니다. 그래서 저는 새로운 종류의 코드가 증가하는 카테고리가 있다고 생각합니다. 이것은 새로운 프로그래밍 패러다임일 뿐만 아니라, 우리의 모국어인 영어로 되어 있다는 것이 저에게는 놀랍습니다. 그래서 몇 년 전 이것이 저를 놀라게 했을 때, 저는 이것을 트윗했고 많은 사람들의 관심을 끌었습니다. 이것이 바로
-- 제 현재 고정된 트윗은 우리가 이제 컴퓨터를 영어로 프로그래밍하고 있다는 놀라운 사실입니다. 제가 테슬라에 있을 때 오토파일럿을 개발하고 있었고, 차가 운전하도록 만들려고 노력했습니다. 당시 저는 이 슬라이드를 보여주었는데, 자동차에 대한 입력이 하단에 있고 소프트웨어 스택을 통해 조향과 가속을 생성한다고 상상할 수 있습니다. 저는 당시 오토파일럿에 소프트웨어 1.0 코드인 C++ 코드가 엄청나게 많다는 것을 관찰했습니다. 그리고 그 안에는 이미지 인식을 수행하는 일부 신경망이 있었습니다. 저는 시간이 지남에 따라 오토파일럿을 개선하면서 기본적으로 신경망의 기능과 크기가 커졌고, 그 외에 모든 C++ 코드가 삭제되고 있었으며, 원래 1.0으로 작성된 많은 기능들이 2.0으로 마이그레이션되는 것을 관찰했습니다. 예를 들어, 다른 카메라의 이미지와 시간에 따른 정보의 통합은 신경망에 의해 수행되었고, 우리는 많은 코드를 삭제할 수 있었습니다. 그래서 소프트웨어 2.0 스택은 말 그대로 오토파일럿의 소프트웨어 스택을 먹어치웠습니다.
-- 저는 당시 이것이 정말 놀랍다고 생각했고, 우리는 다시 같은 현상을 보고 있습니다. 기본적으로 새로운 종류의 소프트웨어가 스택을 먹어치우고 있습니다. 우리는 완전히 다른 세 가지 프로그래밍 패러다임을 가지고 있습니다. 그리고 만약 여러분이 이 산업에 진출한다면 이 모든 것에 능숙한 것이 매우 좋은 생각이라고 생각합니다. 왜냐하면 각각의 패러다임은 약간의 장단점이 있고, 어떤 기능은 1.0으로, 2.0으로, 또는 3.0으로 프로그래밍하고 싶을 수 있기 때문입니다. 신경망을 훈련시킬 것인가요, 아니면 단순히 LLM에 프롬프트를 입력할 것인가요, 아니면 이것이 명시적인 코드 조각이어야 할까요? 이 모든 결정을 내려야 하며, 실제로 이러한 패러다임 사이를 유연하게 전환할 수 있어야 합니다.
-- 그래서 지금 제가 다루고 싶은 것은 먼저 첫 부분에서 LLM에 대해 이야기하고, 이 새로운 패러다임과 생태계를 어떻게 생각해야 하는지, 그리고 그것이 어떤 모습인지, 이 새로운 컴퓨터가 어떤 모습이고 생태계가 어떤 모습인지에 대해 이야기하고 싶습니다. 저는 실제로 수년 전 앤드루의 이 인용문에 깊은 인상을 받았습니다.
-- 앤드루는 제 바로 다음에 연설할 것 같습니다만, 그는 당시 "인공지능은 새로운 전기다"라고 말했습니다. 저는 그 말이 매우 흥미로운 점을 포착한다고 생각합니다. **LLM은 현재 분명히 유틸리티의 속성을 가지고 있는 것처럼 느껴집니다.**
-- 그래서 오픈AI, 제미니, 엔트로픽 등 LLM 연구소들은 LLM을 훈련시키는 데 자본 지출(capex)을 합니다. 이것은 그리드를 구축하는 것과 비슷합니다. 그리고 우리 모두에게 API를 통해 그 지능을 제공하는 데 운영 지출(opex)이 들어갑니다. 이것은 토큰 백만 개당 얼마를 지불하는 방식과 같이 사용량에 따라 과금되는 접근 방식을 통해 이루어집니다. 우리는 이 API에 대해 낮은 지연 시간, 높은 가동 시간, 일관된 품질 등 매우 유틸리티와 같은 많은 요구 사항을 가지고 있습니다.
-- 전기에서는 송전 스위치가 있어서 전력원을 그리드, 태양광, 배터리 또는 발전기 등으로 전환할 수 있습니다. LLM에서는 아마 오픈 라우터(open router)를 통해 기존의 다른 유형의 LLM들을 쉽게 전환할 수 있을 겁니다. LLM은 소프트웨어이기 때문에 물리적 공간을 두고 경쟁하지 않습니다. 그래서 기본적으로 여섯 개의 전력 공급자를 가지고 있고, 그들 사이를 전환하는 것이 괜찮습니다. 왜냐하면 그들이 그렇게 직접적인 방식으로 경쟁하지 않기 때문입니다.
-- 그리고 저는 지난 며칠 동안 실제로 많은 LLM이 중단되어 사람들이 꼼짝 못하고 일을 할 수 없었던 것이 좀 흥미롭다고 생각합니다. 최첨단 LLM이 중단될 때 세상에 지능 브라운아웃(intelligence brownout)이 발생하는 것이 흥미롭습니다. 이는 그리드에서 전압이 불안정할 때와 비슷하며, 이 모델에 대한 의존도가 높아질수록 행성은 점점 더 멍청해집니다. 이는 이미 매우 극적이며 앞으로도 계속 증가할 것이라고 생각합니다.
-- 그러나 LLM은 유틸리티의 속성만을 가지고 있는 것은 아닙니다. 그들은 또한 팹(fab, 반도체 제조 공장)의 속성도 가지고 있다고 말하는 것이 공정하다고 생각합니다. 그 이유는 LLM을 구축하는 데 필요한 자본 지출이 실제로 매우 크기 때문입니다. 단순히 발전소를 짓는 것과 같은 것이 아닙니다. 엄청난 양의 돈을 투자하는 것이고, 기술 트리가 매우 빠르게 성장하고 있다고 생각합니다. 그래서 우리는 LLM 연구소 내부에 심층적인 기술 트리, 연구 개발 비밀이 집중되는 세상에 살고 있습니다. 하지만 저는
-- 이 비유가 조금 모호해지는 면도 있습니다. 제가 언급했듯이 이것은 소프트웨어이고, 소프트웨어는 매우 유연하기 때문에 방어력이 떨어집니다. 그래서 잠재적으로 생각해 볼 만한 흥미로운 점이라고 생각합니다. 4나노미터 공정 노드가 특정 최대 플롭스(flops)를 가진 클러스터와 같다고 비유할 수 있습니다. 엔비디아 GPU를 사용하면서 소프트웨어만 다루고 하드웨어는 다루지 않는다면 팹리스(fabless) 모델과 비슷하다고 생각할 수 있습니다. 하지만 실제로 자체 하드웨어를 구축하고 구글처럼 TPU에서 훈련한다면, 이는 팹을 소유하는 인텔(Intel) 모델과 비슷합니다.
-- 그래서 여기에는 몇 가지 타당한 비유가 있다고 생각합니다. 그러나 실제로 제 생각에 가장 타당한 비유는 **LLM이 운영 체제와 매우 강한 유사성을 가진다**는 점입니다. 이것은 단순한 전기나 물이 아닙니다. 수도꼭지에서 나오는 상품이 아닙니다. 이것들은 이제 점점 더 복잡해지는 소프트웨어 생태계입니다. 그래서 단순히 전기와 같은 간단한 상품이 아닙니다.
-- 생태계가 매우 유사한 방식으로 형성되고 있다는 점이 저에게는 흥미롭습니다. 윈도우나 맥 OS와 같은 몇몇 폐쇄형 소스 제공업체가 있고, 그 다음에는 리눅스와 같은 오픈 소스 대안이 있습니다. 그리고 LLM의 경우에도 몇몇 경쟁하는 폐쇄형 소스 제공업체가 있고, 아마 라마(Llama) 생태계는 현재 리눅스와 같은 것으로 성장할 수 있는 것에 가깝게 근접해 있다고 생각합니다.
-- 아직은 매우 초기 단계라고 생각합니다. 왜냐하면 이것들은 단순한 LLM에 불과하기 때문입니다. 하지만 우리는 이것들이 훨씬 더 복잡해질 것이라는 것을 보기 시작했습니다. LLM 자체에 관한 것만이 아닙니다. 모든 도구 사용과 다중 모달리티, 그리고 그 모든 것이 어떻게 작동하는지에 관한 것입니다. 그래서 제가 얼마 전 이런 깨달음을 얻었을 때, 저는 그것을 스케치해보려고 했고, LLM이 새로운 운영 체제와 같다는 생각이 들었습니다. 그래서 LLM은 새로운 종류의 컴퓨터이고, CPU에 해당합니다. 컨텍스트 창은 메모리와 같고, LLM은 모든 것을 사용하여 문제 해결을 위해 메모리와 컴퓨팅을 조율합니다.
-- 이러한 능력들을 보면 분명히 운영 체제와 매우 유사하게 보입니다. 예를 들어, 몇 가지 더 비유를 들자면, VS Code를 다운로드하고 싶다면 윈도우, 리눅스 또는 맥에서 실행할 수 있습니다. 마찬가지로 커서(Cursor)와 같은 LLM 앱을 GPT, 클라우드 또는 제미니(Gemini) 시리즈에서 실행할 수 있습니다. 드롭다운 메뉴일 뿐입니다. 그래서 그런 면에서도 비슷합니다.
-- 제가 생각하기에 더 인상적인 비유는 우리가 마치 1960년대 시대에 있는 것 같다는 점입니다. 이 새로운 종류의 컴퓨터에 대한 LLM 컴퓨팅 비용은 여전히 매우 비쌉니다. 그래서 LLM은 클라우드에 중앙 집중화될 수밖에 없고, 우리 모두는 네트워크를 통해 상호작용하는 씬 클라이언트(thin client)와 같은 존재입니다. 우리 중 누구도 이 컴퓨터들을 완전히 활용하지 못하고 있습니다. 따라서 클라우드에서 컴퓨터를 실행할 때 우리 모두가 배치(batch)의 한 차원이 되는 시분할(time sharing)을 사용하는 것이 합리적입니다.
-- 이 시기에 컴퓨터는 실제로 그랬습니다. 운영 체제는 클라우드에 있었고, 모든 것이 스트리밍되었으며, 배칭이 있었습니다. 그래서 개인 컴퓨팅 혁명은 아직 일어나지 않았습니다. 경제적이지 않기 때문에 말이 안 됩니다. 하지만 일부 사람들은 시도하고 있다고 생각합니다. 그리고 맥 미니(Mac mini)와 같은 기기들이 일부 LLM에 매우 적합하다는 것이 밝혀졌습니다. 왜냐하면 배치 원(batch one) 추론을 할 경우 이것은 모두 메모리 바운드(memory bound)이기 때문에 실제로 작동합니다. 저는 이것들이 개인 컴퓨팅의 초기 징후일 수도 있다고 생각합니다. 하지만 아직 실제로 일어나지는 않았습니다. 이것이 어떤 모습일지 명확하지 않습니다. 아마 여러분 중 일부는 이것이 무엇인지, 어떻게 작동하는지, 또는 무엇이 되어야 하는지를 발명할 수 있을지도 모릅니다.
-- 한 가지 더 비유를 들자면, 제가 챗 또는 다른 LLM과 텍스트로 직접 대화할 때마다 터미널을 통해 운영 체제와 대화하는 것 같은 느낌이 듭니다. 그냥 텍스트이고 운영 체제에 직접 접근하는 것입니다. 그리고 저는 아직 일반적인 방식으로 GUI가 발명되지 않았다고 생각합니다. 챗이 텍스트 버블과 다른 GUI를 가져야 할까요? 물론 곧 우리가 살펴볼 일부 앱에는 GUI가 있지만, 모든 작업에 걸쳐 일반적인 GUI는 없습니다.
-- 만약 그렇다면 모든 작업에 걸쳐 GUI가 있을 것입니다. LLM이 기존 운영 체제나 초기 컴퓨팅과는 상당히 독특한 방식으로 다른 몇 가지 점이 있습니다. 저는 이번에 특히 다르다고 생각하는 한 가지 특징에 대해 글을 썼습니다. 그것은 **LLM이 기술 확산의 방향을 뒤집는다**는 것입니다. 이는 일반적으로 기술에서 나타나는 현상입니다. 예를 들어, 전기, 암호화, 컴퓨팅, 비행, 인터넷, GPS와 같은 많은 새로운 혁신 기술들은 일반적으로 정부와 기업이 먼저 사용합니다. 왜냐하면 새롭고 비싸기 때문입니다. 그리고 나중에야 소비자에게 확산됩니다.
-- 하지만 저는 LLM이 마치 뒤집힌 것 같다고 생각합니다. 초기 컴퓨터는 탄도학이나 군사 용도에 관한 것이었을지 모르지만, LLM은 달걀을 어떻게 삶는지 같은 것에 관한 것입니다. 이것은 분명히 저의 많은 사용 사례 중 하나입니다. 그래서 저는 우리가 새로운 마법 같은 컴퓨터를 가지고 있고, 그것이 제가 달걀을 삶는 것을 돕고 있다는 것이 정말 흥미롭습니다. 정부가 군사 탄도학이나 특수 기술과 같은 정말 미친 짓을 하는 것을 돕는 것이 아닙니다. 실제로 기업과 정부는 이러한 모든 기술의 채택에 뒤처지고 있습니다. 그래서 이것은 거꾸로 되어 있고, 이것이 우리가 이 기술을 어떻게 사용하고 싶은지, 또는 첫 번째 앱들이 어디에 있는지 등의 일부 사용 사례에 영향을 미친다고 생각합니다.
-- 지금까지 요약하자면, LLM 연구소, LLM은 정확한 용어라고 생각합니다만, LLM은 복잡한 운영 체제입니다. 컴퓨팅의 1960년대쯤과 같고, 우리는 컴퓨팅을 다시 처음부터 하고 있습니다. 그리고 현재 시분할 방식으로 유틸리티처럼 배포되어 이용 가능합니다.
-- 새롭고 전례 없는 것은 LLM이 소수의 정부나 기업의 손에 있지 않다는 것입니다. 우리 모두의 손에 있습니다. 왜냐하면 우리 모두가 컴퓨터를 가지고 있고, 그것은 단지 소프트웨어일 뿐이기 때문입니다. 챗은 수십억 명의 사람들에게 순식간에, 하룻밤 사이에 우리의 컴퓨터로 전송되었습니다. 이것은 미친 일이고, 이런 상황이라는 것이 저에게는 좀 미친 일입니다. 이제 우리가 이 산업에 뛰어들어 이 컴퓨터들을 프로그래밍할 때입니다. 이것은 정말 놀라운 일이라고 생각합니다. LLM을 프로그래밍하기 전에 우리는 시간을 들여 이것들이 무엇인지 생각해 보아야 합니다.
-- 이들이 무엇인지에 대해 생각해 보아야 하며, 저는 특히 그들의 심리에 대해 이야기하는 것을 좋아합니다. 제가 LLM에 대해 생각하는 방식은 그들이 일종의 인간 영혼과 같다는 것입니다. 그들은 인간의 확률적 시뮬레이션입니다. 그리고 이 경우의 시뮬레이터는 자동 회귀 트랜스포머(auto regressive transformer)입니다. 트랜스포머는 신경망입니다. 그것은 토큰 수준에서 덩어리, 덩어리, 덩어리, 덩어리, 덩어리 식으로 진행되며, 각 덩어리마다 거의 동일한 양의 컴퓨팅이 필요합니다.
-- 그리고 이 시뮬레이터는 물론 일부 가중치를 포함하며, 우리는 인터넷의 모든 텍스트 등을 사용하여 이 시뮬레이터를 학습시켰습니다. 그리고 결과적으로 이러한 종류의 시뮬레이터가 만들어집니다. 인간을 기반으로 훈련되었기 때문에 인간과 유사한, 나타나는 심리를 가지고 있습니다.
-- 첫 번째로 눈에 띄는 것은 물론 LLM이 백과사전적인 지식과 기억력을 가지고 있다는 것입니다. 그들은 어떤 한 인간보다 훨씬 더 많은 것을 기억할 수 있습니다. 왜냐하면 그들은 너무나 많은 것을 읽었기 때문입니다. 이것은 실제로 제가 사람들에게 꼭 보라고 권하는 영화인 '레인맨(Rainman)'을 생각나게 합니다. 정말 놀라운 영화이고 저는 이 영화를 사랑합니다. 더스틴 호프만은 거의 완벽한 기억력을 가진 자폐성 서번트입니다. 그는 전화번호부를 읽고 모든 이름과 전화번호를 기억할 수 있습니다. 저는 LLM도 이와 매우 비슷하다고 생각합니다. 그들은 샤(Shaw) 해시와 다양한 종류의 것들을 매우 쉽게 기억할 수 있습니다. 그래서 그들은 어떤 면에서는 분명히 초능력을 가지고 있지만, 제가 말하자면 많은 인지적 결함도 가지고 있습니다.
-- 그들은 상당히 많이 환각을 일으키고, 내용을 지어내며, 충분하지는 않더라도 자기 지식에 대한 아주 좋은 내부 모델을 가지고 있지 않습니다. 이것은 개선되었지만 완벽하지는 않습니다. 그들은 들쭉날쭉한 지능을 보여줍니다. 그래서 그들은 일부 문제 해결 영역에서는 초인적인 능력을 발휘하지만, 인간이라면 기본적으로 하지 않을 실수를 저지를 것입니다. 예를 들어, 그들은 9.11이 9.9보다 크다고 주장하거나, 'strawberry'에 'r'이 두 개 있다고 주장할 것입니다. 이것들은 몇 가지 유명한 예시이지만, 기본적으로 넘어질 수 있는 거친 모서리가 있습니다. 그래서 그것도 독특하다고 생각합니다. 그들은 또한 순행성 기억상실증을 겪습니다.
-- 아, 그리고 저는 여러분의 조직에 합류한 동료가 시간이 지남에 따라 조직을 학습하고 조직에 대한 엄청난 양의 맥락을 이해하고 얻게 될 것이며, 집에 가서 잠을 자고 지식을 통합하여 시간이 지남에 따라 전문성을 개발할 것이라는 사실을 암시하고 있습니다. LLM은 본질적으로 이런 일을 하지 못하며, 이는 LLM의 R&D에서 아직 제대로 해결되지 않은 문제라고 생각합니다.
-- 그래서 컨텍스트 창은 일종의 작업 기억과 같으며, 기본적으로 더 똑똑해지지 않기 때문에 작업 기억을 매우 직접적으로 프로그래밍해야 합니다. 그리고 많은 사람들이 이런 식으로 비유에 걸려 넘어지는 것 같습니다. 대중문화에서는 '메멘토'와 '50가지 첫 데이트'라는 두 영화를 추천합니다. 이 두 영화에서 주인공들의 가중치는 고정되어 있고, 매일 아침 컨텍스트 창이 지워집니다. 이런 일이 발생하면 직장에 가거나 관계를 맺는 것이 정말 문제가 됩니다. 그리고 이런 일은 항상 일어납니다.
-- 한 가지 더 지적하고 싶은 것은 LLM 사용의 보안 관련 제약입니다. 예를 들어, LLM은 상당히 잘 속으며, 프롬프트 주입 위험에 취약하고 데이터를 유출할 수 있습니다. 그 외에도 보안 관련하여 고려해야 할 많은 사항들이 있습니다.
-- 요컨대, 여러분은 많은 인지적 결함과 문제점을 가진 이 초인적인 존재를 동시에 고려해야 합니다. 우리는 어떻게 이들을 프로그래밍하고, 그들의 결함을 우회하며, 그들의 초인적인 능력을 활용할 수 있을까요?
-- 이제 저는 이러한 모델을 어떻게 사용해야 하는지에 대한 기회와 가장 큰 기회들이 무엇인지에 대해 이야기하고 싶습니다. 이것은 포괄적인 목록이 아니라, 이 강연에서 흥미롭다고 생각한 몇 가지 사항일 뿐입니다. 제가 가장 기대하는 첫 번째는 제가 **부분 자율 앱(partial autonomy apps)**이라고 부르는 것입니다. 예를 들어, 코딩의 예를 들어보겠습니다. 여러분은 분명히 챗에 직접 가서 코드를 복사 붙여넣기하고 버그 보고서 등을 복사 붙여넣기하며 코드를 얻고 모든 것을 복사 붙여넣기할 수 있습니다. 왜 그렇게 해야 할까요?
-- 왜 그렇게 하시겠습니까? 왜 운영 체제에 직접 접속하시겠습니까? 이에 전용 앱을 사용하는 것이 훨씬 더 합리적입니다. 그래서 많은 분들이 커서(Cursor)를 사용한다고 생각합니다. 저도 그렇습니다. 커서는 여러분이 원하는 것입니다. 챗에 직접 가고 싶지 않을 것입니다. 커서는 모든 LLM 앱에서 유용하다고 생각하는 많은 속성을 가진 초기 LLM 앱의 아주 좋은 예라고 생각합니다.
-- 특히, 우리는 사람이 이전처럼 모든 작업을 수동으로 수행할 수 있는 전통적인 인터페이스를 가지고 있습니다. 하지만 그 외에도 이제 우리는 더 큰 덩어리로 작업을 수행할 수 있는 LLM 통합 기능을 가지고 있습니다. LLM 앱의 공유되고 유용한 속성 중 몇 가지를 지적하고 싶습니다.
-- 첫째, LLM은 기본적으로 컨텍스트 관리를 많이 수행합니다. 둘째, 그들은 여러 LLM 호출을 조율합니다. 커서의 경우, 내부적으로 모든 파일에 대한 임베딩 모델, 실제 채팅 모델, 코드에 차이점(diff)을 적용하는 모델이 있으며, 이 모든 것이 여러분을 위해 조율됩니다.
-- 제가 생각하기에 항상 완전히 인식되지는 않는 정말 큰 한 가지는 **애플리케이션별 GUI와 그 중요성**입니다. 왜냐하면 여러분은 운영 체제에 텍스트로 직접 이야기하고 싶지 않을 것이기 때문입니다. 텍스트는 읽고 해석하고 이해하기 매우 어렵습니다. 또한 이러한 작업 중 일부를 텍스트로 직접 수행하고 싶지 않을 것입니다. 그래서 빨간색과 녹색으로 변한 것처럼 차이점을 보는 것이 훨씬 낫고, 무엇이 추가되고 무엇이 삭제되는지 볼 수 있습니다. 커맨드 Y로 수락하거나 커맨드 N으로 거부하는 것이 훨씬 쉽습니다. 텍스트로 입력할 필요가 없어야 합니다. 그래서 GUI는 사람이 이러한 오류가 있는 시스템의 작업을 감사하고 더 빠르게 진행할 수 있도록 합니다. 이 점에 대해서는 나중에 다시 조금 더 이야기하겠습니다.
-- 제가 지적하고 싶은 마지막 기능은 제가 **자율성 슬라이더(autonomy slider)**라고 부르는 것입니다. 예를 들어, 커서에서는 탭 자동 완성을 사용할 수 있습니다. 여러분이 주로 주도권을 가집니다. 코드 덩어리를 선택하고 커맨드 K를 사용하여 그 코드 덩어리만 변경할 수 있습니다. 커맨드 L을 사용하여 전체 파일을 변경하거나, 커맨드 I를 사용하여 전체 리포지토리에서 원하는 대로 마음껏 작업할 수 있습니다. 이것이 바로 완전 자율 에이전트 방식입니다.
-- 그래서 여러분이 자율성 슬라이더를 담당하며, 당면한 작업의 복잡성에 따라 해당 작업에 기꺼이 포기할 자율성의 양을 조절할 수 있습니다. 비교적 성공적인 LLM 앱의 한 가지 더 예를 보여드리자면 퍼플렉시티(Perplexity)가 있습니다.
-- 퍼플렉시티는 커서에서 제가 방금 지적했던 것과 매우 유사한 기능들을 가지고 있습니다. 많은 정보를 패키징하고, 여러 LLM을 조율하며, 작업 중 일부를 감사할 수 있는 GUI를 가지고 있습니다. 예를 들어, 출처를 표시하고 여러분은 그것들을 검토할 수 있습니다. 그리고 자율성 슬라이더가 있어서 빠른 검색을 하거나, 조사를 하거나, 심층 조사를 하고 10분 후에 돌아올 수 있습니다. 이것은 모두 여러분이 도구에 포기하는 다양한 수준의 자율성입니다.
-- 그래서 제 질문은 많은 소프트웨어가 부분적으로 자율적이 될 것이라고 느낀다는 것입니다. 그것이 어떤 모습일지 고민하고 있습니다. 그리고 제품과 서비스를 유지하는 많은 분들은 어떻게 제품과 서비스를 부분적으로 자율적이게 만들 것인가입니다. LLM이 사람이 볼 수 있는 모든 것을 볼 수 있을까요? LLM이 사람이 할 수 있는 모든 방식으로 행동할 수 있을까요? 그리고 사람은 이 활동을 감독하고 루프 안에 머무를 수 있을까요? 왜냐하면 다시 말하지만, 이것들은 아직 완벽하지 않은 오류가 있는 시스템이기 때문입니다. 포토샵 등에서 차이점(diff)은 어떤 모습일까요? 그리고 현재 많은 전통적인 소프트웨어에는 인간을 위해 설계된 모든 스위치와 그런 것들이 있습니다. 이 모든 것이 바뀌고 LLM이 접근할 수 있게 되어야 합니다.
-- 많은 LLM 앱에서 제가 강조하고 싶은 한 가지는 충분한 관심을 받지 못하는 것 같지만, 우리는 이제 AI와 협력하고 있다는 것입니다. 보통 AI가 생성을 하고, 우리는 인간으로서 검증을 합니다. 이 루프를 가능한 한 빠르게 만드는 것이 우리의 이익입니다. 그래야 많은 작업을 할 수 있습니다.
-- 저는 이것을 할 수 있는 두 가지 주요 방법이 있다고 생각합니다. 첫째, 검증 속도를 크게 높일 수 있습니다. 그리고 GUI는 이것에 매우 중요하다고 생각합니다. GUI는 우리 머리 속에 있는 컴퓨터 비전 GPU를 활용하기 때문입니다. 텍스트를 읽는 것은 힘들고 재미없지만, 시각적인 것을 보는 것은 재미있고 뇌로 가는 고속도로와 같습니다.
-- 뇌로 가는 고속도로와 같습니다. 그래서 GUI는 시스템을 감사하고 시각적 표현을 하는 데 일반적으로 매우 유용하다고 생각합니다. 둘째, **AI를 제어해야 한다**고 말하고 싶습니다. 많은 사람들이 AI 에이전트에 대해 지나치게 흥분하고 있다고 생각합니다.
-- 제게는 제 저장소에 10,000줄의 코드 차이점(diff)을 받는 것은 유용하지 않습니다. 왜냐하면 저는 여전히 병목 현상이기 때문입니다. 10,000줄이 즉시 나온다 해도, 저는 이것이 버그를 유발하지 않고, 올바른 일을 하고 있으며, 보안 문제가 없는지 확인해야 합니다. 그래서 저는 이 두 가지의 흐름을 매우 빠르게 만드는 것이 우리의 이익이며, AI를 제어해야 한다고 생각합니다. 왜냐하면 AI가 지나치게 과잉 반응하기 때문입니다.
-- 제가 AI 보조 코딩을 할 때 이렇게 느낍니다. 그냥 코드 조각을 작성할 때는 모든 것이 좋고 훌륭하지만, 실제로 작업을 완료하려고 할 때는 지나치게 과잉 반응하는 에이전트가 모든 종류의 작업을 수행하는 것이 좋지 않습니다. 이 슬라이드는 별로 좋지 않아서 죄송합니다. 하지만 저는 여러분 중 많은 분들처럼 제 코딩 워크플로우에서 이러한 에이전트를 활용하고 AI 보조 코딩을 하는 방법을 개발하려고 노력하고 있습니다. 그리고 제 작업에서 저는 항상 너무 큰 차이점을 받는 것을 두려워합니다. 저는 항상 작고 점진적인 덩어리로 작업합니다. 모든 것이 좋은지 확인하고 싶고, 이 루프를 매우 빠르게 돌리고 싶습니다. 그리고 저는 하나의 구체적인 작은 덩어리들을 작업합니다. 그래서 많은 분들이 LLM과 작업하는 비슷한 방식을 개발하고 있다고 생각합니다.
-- 저는 또한 LLM과 작업하기 위한 이러한 모범 사례를 개발하려는 여러 블로그 게시물을 보았습니다. 최근에 읽은 것 중 하나는 꽤 좋다고 생각했고, 몇 가지 기술을 논의했으며, 그 중 일부는 AI를 제어하는 방법과 관련이 있습니다. 예를 들어, 프롬프트가 모호하다면 AI는 여러분이 원했던 것을 정확히 수행하지 못할 수 있고, 그 경우 검증이 실패할 것입니다. 검증이 실패하면 여러분은 다시 시작하게 될 것입니다. 그래서 프롬프트에 더 구체적으로 시간을 투자하는 것이 훨씬 합리적입니다. 이는 성공적인 검증의 가능성을 높여줍니다.
-- 성공적인 검증을 하고 앞으로 나아갈 수 있습니다. 그래서 저는 우리 중 많은 사람들이 이런 종류의 기술을 찾게 될 것이라고 생각합니다.
-- 제 작업에서도 저는 현재 AI와 LLM이 있는 상황에서 교육이 어떤 모습일지에 관심이 많습니다. 그리고 저에게는 AI를 어떻게 제어할 것인지에 대한 많은 생각이 들어갑니다. 챗에 가서 "물리학을 가르쳐줘"라고 말하는 것이 그냥 작동한다고 생각하지 않습니다. AI가 길을 잃기 때문에 이것은 작동하지 않는다고 생각합니다.
-- 그래서 저에게는 이것이 실제로 두 개의 별도 앱입니다. 예를 들어, 코스를 만드는 교사용 앱이 있고, 그 코스를 가져와 학생들에게 제공하는 앱이 있습니다. 두 경우 모두 우리는 이제 감사 가능한 코스라는 중간 결과물을 가지고 있으며, 그것이 좋고 일관성이 있는지 확인할 수 있습니다. 그리고 AI는 특정 강의 계획서, 특정 프로젝트 진행 등과 관련하여 제어됩니다. 그래서 이것은 AI를 제어하는 한 가지 방법이며, 훨씬 더 높은 성공 가능성을 가지고 있고, AI가 길을 잃지 않을 것이라고 생각합니다.
-- 한 가지 더 비유하고 싶은 것은 제가 부분 자율성에 대해 낯설지 않다는 것입니다. 저는 테슬라에서 5년 동안 이것에 대해 작업했고, 이것 또한 부분 자율성 제품이며 많은 기능을 공유합니다. 예를 들어, 계기판에 오토파일럿의 GUI가 있어서 신경망이 무엇을 보는지 등을 보여줍니다. 그리고 우리는 제가 재직하는 동안 사용자를 위해 점점 더 많은 자율 작업을 수행한 자율성 슬라이더를 가지고 있습니다.
-- 아주 간략하게 말씀드리고 싶은 이야기는 제가 자율 주행 차량을 처음 운전한 것이 2013년이었다는 것입니다. 웨이모(Whimo)에서 일하는 친구가 있었는데, 그가 팔로 알토(Palo Alto) 주변을 운전해 보라고 제안했습니다. 저는 당시 구글 글래스(Google Glass)를 사용하여 이 사진을 찍었는데, 여러분 중 많은 분들은 너무 어려서 그것이 무엇인지도 모를 수도 있습니다. 하지만 그때는 정말 대유행이었고, 우리는 이 차를 타고 팔로 알토 고속도로와 거리를 약 30분 동안 운전했습니다. 이 운전은 완벽했습니다. 개입이 전혀 없었습니다. 그리고 이것은 지금으로부터 12년 전인 2013년이었습니다.
-- 12년 전이었습니다. 그때 이 완벽한 주행, 완벽한 데모를 경험했을 때 "와, 자율 주행이 임박했구나. 이게 그냥 작동하다니, 믿을 수 없어"라고 느꼈기 때문에 저에게는 충격적이었습니다. 하지만 12년이 지난 지금도 우리는 자율 주행에 대해 작업하고 있습니다. 우리는 여전히 주행 에이전트에 대해 작업하고 있으며, 심지어 지금도 문제를 정말 해결했다고 말할 수 없습니다. 웨이모(Whimo)가 돌아다니는 것을 보면 무인차처럼 보이지만, 여전히 많은 원격 조작과 많은 운전에서 사람이 개입하고 있습니다. 그래서 우리는 아직 성공을 선언하지도 못했습니다. 하지만 저는 이 시점에서 분명히 성공할 것이라고 생각하지만, 오랜 시간이 걸렸습니다.
-- 그래서 저는 이것이 소프트웨어가 정말 까다롭다고 생각합니다. 운전이 까다로운 것과 같은 방식이라고 생각합니다. 그래서 저는 "2025년은 에이전트의 해다"와 같은 말을 들으면 매우 걱정됩니다. 저는 이것이 에이전트의 10년이 될 것이며, 상당한 시간이 걸릴 것이라고 생각합니다. 우리는 인간을 루프 안에 두어야 합니다. 우리는 이것을 신중하게 해야 합니다. 이것은 소프트웨어입니다. 여기서는 진지하게 생각합시다.
-- 제가 항상 생각하는 한 가지 더 비유는 **아이언맨 수트**입니다. 저는 항상 아이언맨을 좋아합니다. 기술과 그것이 어떻게 전개될 것인지에 대해 여러 면에서 매우 정확하다고 생각합니다. 제가 아이언맨 수트에서 좋아하는 점은 그것이 증강(augmentation)이면서 토니 스타크가 운전할 수 있다는 점이고, 또한 에이전트라는 점입니다. 일부 영화에서는 아이언맨 수트가 상당히 자율적이어서 날아다니며 토니를 찾고 이런저런 일을 합니다. 그래서 이 자율성 슬라이더는 우리가 증강을 만들 수도 있고 에이전트를 만들 수도 있다는 것입니다. 우리는 두 가지 모두를 하고 싶어 하지만, 이 단계에서는 오류가 있는 LLM 등과 작업할 때는 아이언맨 로봇보다는 아이언맨 수트를 만들고 싶다고 말하고 싶습니다.
-- 화려한 자율 에이전트 데모를 만드는 것보다는 부분 자율 제품을 만드는 것이 더 중요합니다. 그리고 이러한 제품들은 맞춤형 GUI와 UI/UX를 가지고 있습니다. 우리는 이것을 통해 인간의 생성과 검증 루프를 매우 빠르게 만들려고 노력하고 있습니다. 하지만 우리는 원칙적으로 이 작업을 자동화하는 것이 가능하다는 사실을 놓치지 않고 있습니다. 그리고 제품에는 자율성 슬라이더가 있어야 하며, 여러분은 이 자율성 슬라이더를 어떻게 조절하여 제품을 더 자율적으로 만들 수 있을지 생각해야 합니다.
-- 시간이 지남에 따라 제품을 더 자율적으로 만들 수 있도록 그 자율성 슬라이더를 어떻게 조절할 수 있을지 생각해야 합니다. 그러나 이것이 바로 이러한 종류의 제품에서 많은 기회가 있다고 제가 생각하는 방식입니다.
-- 이제 조금 다른 방향으로 전환하여 제가 매우 독특하다고 생각하는 또 다른 차원에 대해 이야기하고 싶습니다. 소프트웨어에서 자율성을 허용하는 새로운 유형의 프로그래밍 언어가 있을 뿐만 아니라, 제가 언급했듯이 영어로 프로그래밍된다는 점이 이 자연스러운 인터페이스입니다. 그리고 갑자기 모든 사람이 프로그래머가 됩니다. 왜냐하면 모든 사람이 영어와 같은 자연어를 구사하기 때문입니다. 그래서 이것은 저에게 매우 긍정적이고 흥미로우며, 또한 전례가 없는 일입니다.
-- 예전에는 소프트웨어에서 무언가를 하려면 5년에서 10년을 공부해야 했습니다. 더 이상 그렇지 않습니다. 혹시 '**바이브 코딩(vibe coding)**'이라는 말을 들어본 사람이 있을지 모르겠습니다. 이 트윗이 이것을 소개한 것인데, 지금은 주요 밈이 되었다고 들었습니다.
-- 이것에 대한 재미있는 이야기는 제가 트위터를 15년 정도 해왔지만, 어떤 트윗이 바이럴이 되고 어떤 트윗이 시들해져 아무도 신경 쓰지 않는지 여전히 전혀 모른다는 것입니다. 저는 이 트윗이 후자가 될 것이라고 생각했습니다. 그냥 생각의 흐름이었을 뿐인데, 이것이 완전히 밈이 되었습니다. 정말 알 수 없지만, 아마도 많은 사람들이 느끼고 있었지만 말로 표현할 수 없었던 무언가에 공감대를 형성하고 이름을 붙여준 것 같습니다. 그래서 이제 위키백과 페이지도 있고, 이것은 마치 중요한 기여와 같습니다.
-- 허깅페이스의 톰 울프(Tom Wolf)가 공유한 아름다운 영상을 정말 좋아합니다. 이 아이들은 바이브 코딩을 하고 있습니다. 저는 이것이 정말 건전한 영상이라고 생각합니다. 이 영상을 보고 미래에 대해 어떻게 나쁘게 생각할 수 있겠습니까? 미래는 훌륭합니다. 이것이 소프트웨어 개발의 입문 마약과 같은 역할을 할 것이라고 생각합니다. 저는 이 세대의 미래에 대해 비관론자가 아닙니다. 그리고 네, 이 영상을 정말 좋아합니다.
-- 그래서 저도 바이브 코딩을 조금 시도해 보았습니다. 너무 재미있었기 때문입니다. 그래서 바이브 코딩은 존재하지 않는 매우 특별한 것을 만들고 싶을 때, 그리고 토요일이라서 그냥 즉흥적으로 해보고 싶을 때 정말 좋습니다. 그래서 저는 이 iOS 앱을 만들었는데, 사실 스위프트(Swift)로 프로그래밍할 줄 모릅니다. 하지만 정말 기본적인 앱을 만들 수 있었다는 것에 정말 놀랐습니다. 설명할 필요는 없지만, 정말 시시한 앱입니다. 하지만 이것은 단 하루 만에 작업한 것이었고, 그날 저녁 제 휴대폰에서 실행되었습니다. 저는 "와, 정말 대단하다"고 생각했습니다. 스위프트를 5일 동안 읽거나 할 필요가 없었습니다.
-- 저는 또한 '메뉴젠(Menu Genen)'이라는 앱을 바이브 코딩했습니다. 이것은 현재 서비스 중이며 menu.app에서 사용해 볼 수 있습니다. 저는 기본적으로 식당에 가서 메뉴를 읽는데, 어떤 것이 무엇인지 전혀 모르겠고 사진이 필요한 문제가 있었습니다. 이런 앱이 없어서 "야, 내가 바이브 코딩해야겠어"라고 생각했습니다.
-- 그래서 이것이 어떤 모습인지 설명하자면, menu.app에 접속하여 메뉴 사진을 찍으면 메뉴젠이 이미지를 생성합니다. 회원 가입 시 모든 사람에게 5달러의 무료 크레딧이 제공됩니다. 따라서 이것은 현재 제 삶에서 주요 비용 센터입니다. 저는 메뉴젠으로 엄청난 돈을 잃고 있습니다.
-- 하지만 메뉴젠에 대해 저에게 흥미로웠던 점은 바이브 코딩 부분의 코드가 실제로는 메뉴젠 코딩의 쉬운 부분이었다는 것입니다. 대부분의 어려움은 실제로 인증, 결제, 도메인 이름, 베르셀(Vercel) 배포를 갖출 수 있도록 현실화하려고 했을 때였습니다. 이것은 정말 어려웠습니다. 이 모든 데브옵스(devops) 작업은 코드가 아니었습니다. 브라우저에서 클릭하는 작업이었고, 매우 느렸으며, 또 다른 한 주가 걸렸습니다. 그래서 메뉴젠 데모가 몇 시간 만에 제 노트북에서 작동했다는 점이 정말 흥미로웠고, 그것을 현실화하려고 한 주가 더 걸렸습니다.
-- 그 이유는 이것이 정말 짜증났기 때문입니다. 예를 들어, 웹 페이지에 구글 로그인을 추가하려고 한다면, 이것이 매우 작다는 것을 알지만, 이 클럭(Clerk) 라이브러리가 이것을 통합하는 방법에 대한 엄청난 양의 지침을 알려줍니다. 이것은 미친 짓입니다. URL로 이동하여 이 드롭다운을 클릭하고, 이것을 선택하고, 저기로 이동하여 저것을 클릭하라고 알려줍니다. 마치 컴퓨터가 제가 무엇을 해야 할지 알려주는 것과 같습니다.
-- 컴퓨터가 제가 해야 할 행동을 지시하는 것과 같습니다. '네가 해! 왜 내가 이걸 해야 하지? 젠장.' 저는 이 모든 지침을 따라야 했습니다. 이건 미친 짓이었습니다.
-- 그래서 제 강연의 마지막 부분은 에이전트를 위해 구축할 수 있는지에 초점을 맞춥니다. 저는 이 작업을 하고 싶지 않습니다. 에이전트가 이것을 할 수 있을까요? 감사합니다.
-- 대략적으로 말해서, 디지털 정보의 새로운 소비자이자 조작자 범주가 있다고 생각합니다. 예전에는 GUI를 통한 인간이나 API를 통한 컴퓨터뿐이었지만, 이제는 완전히 새로운 것이 있습니다. 에이전트는 컴퓨터이지만 인간과 같은 존재입니다. 그들은 인간 영혼과 같습니다. 인터넷에 인간 영혼이 있고, 그들은 우리의 소프트웨어 인프라와 상호작용해야 합니다. 우리가 그들을 위해 구축할 수 있을까요? 이것은 새로운 일입니다.
-- 예를 들어, 여러분의 도메인에 robots.txt를 두어 웹 크롤러가 여러분의 웹사이트에서 어떻게 행동해야 하는지 지시하거나 조언할 수 있습니다. 마찬가지로 llm.txt 파일을 가질 수 있는데, 이것은 LLM에게 이 도메인이 무엇에 관한 것인지 알려주는 간단한 마크다운 파일입니다. 이것은 LLM에게 매우 읽기 쉽습니다. 만약 LLM이 대신 웹 페이지의 HTML을 가져와서 파싱하려고 한다면, 이것은 오류가 많고 어렵고 망가질 것이며 작동하지 않을 것입니다. 그래서 우리는 LLM에게 직접 말할 수 있고, 그럴 가치가 있습니다.
-- 현재 엄청난 양의 문서가 사람들을 위해 작성되어 있습니다. 그래서 목록, 볼드체, 그림과 같은 것들을 볼 수 있는데, 이것은 LLM에게 직접 접근 가능하지 않습니다. 그래서 저는 이제 일부 서비스들이 많은 문서를 LLM 전용으로 전환하는 것을 보고 있습니다. 베르셀(Vercel)과 스트라이프(Stripe)가 그 선두 주자이지만, 제가 이미 본 몇 군데 더 있습니다. 그들은 마크다운 형식으로 문서를 제공하는데, 마크다운은 LLM이 이해하기에 매우 쉽습니다. 이것은 훌륭합니다.
-- 제 경험에서 한 가지 간단한 예를 더 들자면, 아마 스리 블루 원 브라운(Three Blue One Brown)을 아는 분들도 있을 겁니다. 그는 유튜브에 아름다운 애니메이션 비디오를 만듭니다. 네, 저는 그가 만든 매님(Manim) 라이브러리를 정말 좋아합니다. 저도 제 것을 만들고 싶었습니다. 매님 사용법에 대한 광범위한 문서가 있습니다. 그래서 저는 실제로 그것을 읽고 싶지 않아서 전체 내용을 LLM에 복사하여 붙여넣고 제가 원하는 것을 설명했습니다. 그랬더니 LLM이 제가 원했던 애니메이션을 바로 코딩해 주었습니다.
-- 정말 제가 원했던 대로였습니다. 저는 "와, 대단하다"고 생각했습니다. 그래서 만약 우리가 문서를 LLM이 읽을 수 있도록 만들 수 있다면, 엄청난 양의 사용 사례를 열어줄 것이고, 이것은 정말 멋진 일이며 더 많이 일어나야 한다고 생각합니다.
-- 제가 지적하고 싶었던 또 다른 점은 아쉽게도 여러분은 문서를 마크다운으로 변환하는 쉬운 부분만 하는 것이 아니라, 실제로 문서를 변경해야 한다는 것입니다. 왜냐하면 문서에 '클릭'이라는 단어가 있다면 이것은 좋지 않습니다. LLM은 현재 이 동작을 본질적으로 수행할 수 없을 것이기 때문입니다. 그래서 베르셀(Vercel)은 예를 들어, '클릭'이라는 단어가 나올 때마다 LLM 에이전트가 여러분을 대신하여 수행할 수 있는 동등한 Curl 명령으로 대체하고 있습니다. 저는 이것이 매우 흥미롭다고 생각합니다.
-- 그리고 물론 엔트로픽(Enthropic)의 모델 컨텍스트 프로토콜이 있습니다. 이것 또한 디지털 정보의 새로운 소비자이자 조작자로서 에이전트에게 직접 말하는 프로토콜입니다. 그래서 저는 이러한 아이디어에 대해 매우 낙관적입니다.
-- 제가 정말 좋아하는 또 다른 점은 LLM 친화적인 형식으로 데이터를 수집하는 데 도움이 되는 여러 작은 도구들이 곳곳에 있다는 것입니다. 예를 들어, 제 nanoGPT 저장소와 같은 깃허브 저장소에 가면 이것을 LLM에 넣어 질문할 수 없습니다. 왜냐하면 이것은 깃허브의 인간 인터페이스이기 때문입니다. 그래서 URL을 깃허브에서 'get ingest'로 바꾸면 실제로 모든 파일을 하나의 거대한 텍스트로 연결하고 디렉토리 구조 등을 생성합니다. 그리고 이것은 여러분이 가장 좋아하는 LLM에 복사하여 붙여넣을 준비가 되어 있으며, 여러분은 작업을 할 수 있습니다.
-- 아마도 이것의 더 극적인 예는 딥 위키(deep wiki)일 것입니다. 여기서는 파일의 원시 콘텐츠뿐만 아니라, 이것은 데본(Devon)에서 온 것인데, 데본이 기본적으로 깃허브 저장소를 분석하고, 데본이 기본적으로 여러분의 저장소만을 위한 전체 문서 페이지를 구축합니다. 이것이 LLM에 복사하여 붙여넣기에 훨씬 더 도움이 될 것이라고 상상할 수 있습니다. 그래서 저는 URL만 바꾸면 LLM에 무언가를 접근 가능하게 만드는 모든 작은 도구들을 좋아합니다. 이것은 모두 좋고 훌륭하며, 더 많이 있어야 한다고 생각합니다.
-- 한 가지 더 언급하고 싶은 것은 미래에 LLM이 이것을 할 수 있다는 것이 절대적으로 가능하다는 것입니다. 이것은 심지어 미래가 아니라 오늘날의 일입니다. 그들은 돌아다니며 클릭할 수 있을 것입니다.
-- 그들이 클릭할 수 있을 것이지만, 저는 여전히 LLM과 중간에서 만나서 LLM이 이 모든 정보에 더 쉽게 접근할 수 있도록 하는 것이 매우 가치 있다고 생각합니다. 왜냐하면 이것은 여전히 사용하기에 상당히 비싸고 훨씬 더 어렵기 때문입니다. 그래서 저는 많은 소프트웨어에 있어서 라이브 플레이어 유형의 저장소나 디지털 인프라가 아닌 곳에서는 앱을 적용하지 않는 긴 꼬리가 있을 것이라고 생각합니다. 그리고 우리는 이러한 도구들이 필요할 것입니다. 하지만 다른 모든 경우에는 어떤 중간 지점에서 만나는 것이 매우 가치 있다고 생각합니다.
-- 그래서 저는 양쪽 모두에 대해 낙관적입니다. 요약하자면, 이 산업에 진출하기에 정말 놀라운 시기입니다. 우리는 엄청난 양의 코드를 다시 작성해야 합니다. 엄청난 양의 코드는 전문가와 코더에 의해 작성될 것입니다.
-- 이러한 LLM은 유틸리티와 같고 팹과 같지만, 특히 운영 체제와 같습니다. 그러나 아직 매우 초기 단계입니다. 마치 1960년대의 운영 체제와 같습니다. 그리고 많은 비유들이 서로 교차한다고 생각합니다. 이러한 LLM은 우리가 함께 작업하는 방법을 배워야 하는 오류가 있는 인간 영혼과 같습니다. 그리고 그렇게 제대로 하려면 우리는 우리의 인프라를 그에 맞춰 조정해야 합니다.
-- 이러한 LLM 앱을 구축할 때, 저는 LLM과 효과적으로 작업하는 몇 가지 방법과 그것을 가능하게 하는 몇 가지 도구, 그리고 이 루프를 매우 빠르게 돌리고 기본적으로 부분 터널링 제품을 만드는 방법을 설명했습니다. 그리고 네, 많은 코드가 에이전트를 위해 더 직접적으로 작성되어야 합니다.
-- 그러나 어쨌든 아이언맨 수트 비유로 돌아가서, 앞으로 10년 동안 우리가 보게 될 것은 대략적으로 슬라이더를 왼쪽에서 오른쪽으로 옮기는 것이라고 생각합니다. 그것이 어떤 모습일지 매우 흥미로울 것이며, 여러분 모두와 함께 그것을 만들기를 고대합니다.
-