앤드류 응: AI로 더 빠르게 구축하기

Y Combinator 구독자 1,700,000명

요약

이 강연은 AI Fund에서 쌓은 스타트업 구축 노하우를 공유하며 실행 속도가 성공의 핵심임을 강조한다. 에이전트 AI, AI 스택, 애플리케이션 레이어 기회 등 최신 기술 트렌드를 소개하고, 구체적 아이디어 정의, AI 코딩 어시스턴트 활용, 빠른 사용자 피드백 전술, 모두를 위한 코딩 등을 통해 스타트업이 속도를 높일 수 있는 구체적 실천법을 제시한다.

주요 키워드

execution speed agentic AI concrete ideas AI coding assistance feedback loop AI stack responsible AI democratization of coding one-way door product management

하이라이트

🔑 실행 속도가 스타트업 성공 확률을 좌우하는 강력한 예측 변수임을 강조한다.
⚡️ 구체적인 아이디어는 개발 방향을 명확히 해 팀이 빠르게 제품을 검증하거나 수정하게 돕는다.
🚀 에이전트 AI 기반 순환적 워크플로우는 단일 프롬프트 방식보다 더 나은 업무 결과물을 제공한다.
📌 AI 코딩 어시스턴트를 활용하면 프로토타입은 10배, 프로덕션 코드는 30~50% 더 빠르게 작성할 수 있다.
🌟 코드베이스 재작성 비용이 크게 낮아져 아키텍처 결정이 Two-way door처럼 바뀐다.
🔍 다양한 제품 피드백 전술(직감→동료→낯선 사람→프로토타입→A/B 테스트)을 계층별로 소개한다.
💡 모든 직무에서 코딩 역량을 갖추면 AI 도구를 효과적으로 활용해 생산성을 높일 수 있다.
⚖️ AI 자체가 안전·위험을 결정하지 않으며, 책임감 있는 적용이 진정한 안전을 가져온다.

용어 설명

Agentic AI(에이전트 AI)

AI가 스스로 순환적 워크플로우를 계획·실행해 복합 업무를 처리하는 기술

AI 스택

반도체·클라우드·파운데이션 모델·애플리케이션으로 구성된 AI 생태계의 기술 계층 구조

Concrete idea(구체적 아이디어)

엔지니어가 즉시 개발 가능한 수준으로 충분히 세분화·정의된 제품 아이디어

One-way door & Two-way door

되돌리기 힘든 결정(One-way)과 쉽게 철회 가능한 결정(Two-way)을 구분해 속도와 위험을 관리하는 개념

RAG(Retrieval-Augmented Generation)

외부 데이터베이스로부터 정보를 검색해 AI 생성 결과에 반영하는 기법

AI 코딩 어시스턴트

GitHub Copilot, AWS CodeWhisperer 등 AI 기반 코드 자동완성·생성 도구

피드백 루프

소프트웨어 개발→사용자 피드백→제품 개선 과정을 반복하며 PMF(Product–Market Fit)를 찾아가는 순환 구조

Pivot(피벗)

데이터에 기반해 사업 가설이 틀렸을 때 새로운 구체적 아이디어로 방향을 신속히 전환하는 과정

AI Fund에서 매달 스타트업을 공동 설립하며 얻은 교훈을 공유하며, 실행 속도를 스타트업 성공의 강력한 예측 변수로 제시한다. 새로운 AI 기술이 스타트업 구축 속도를 가속화하는 배경을 설명한다.

[00:00] 앤드류 응이 스타트업 스쿨에서 AI 펀드의 경험을 바탕으로 한 강연을 시작하며, 한 달에 평균 하나씩 스타트업을 만들면서 얻은 교훈들을 공유하겠다고 소개합니다.

[00:30] 스타트업 성공의 핵심은 실행 속도라고 강조하며, 새로운 AI 기술이 스타트업들의 속도를 크게 향상시킬 수 있다고 설명합니다.

[01:13] AI 스택 구조를 설명하면서 반도체, 클라우드, 파운데이션 모델 순으로 쌓인 구조에서 실제로 가장 큰 기회는 애플리케이션 레이어에 있다고 강조합니다.

반도체→클라우드(하이퍼스케일러)→파운데이션 모델→애플리케이션으로 구성된 AI 스택을 소개하고, 가장 큰 사업 기회는 최종 사용자 가치를 창출하는 애플리케이션 레이어에 있음을 강조한다.

[02:06] 지난 1년간 가장 중요한 AI 기술 트렌드로 에이전트 AI의 부상을 언급하며, 마케터들이 이 용어를 남용하여 의미가 희석되었지만 기술적으로는 매우 중요하고 많은 스타트업 기회를 제공한다고 설명합니다.

모델을 단일 프롬프트로 쓰는 대신 아웃라인 작성→웹 리서치→초안 작성→비판·수정의 순환적 에이전트 워크플로우를 통한 개선 방법과, 이를 쉽게 구현해 주는 에이전트 오케스트레이션 레이어를 설명한다.

[02:45] Andrew Ng는 현재 대부분의 사람들이 LLM을 사용하는 방식이 선형적이고 제한적이라고 설명합니다. 마치 백스페이스 없이 한 번에 에세이를 써달라고 요청하는 것과 같다고 비유하며, 이는 인간에게도 AI에게도 최적의 작업 방식이 아니라고 지적합니다.

[03:18] 에이전트 워크플로우의 개념을 소개하며, 이는 AI가 단계별로 작업을 수행할 수 있게 합니다. 먼저 개요를 작성하고, 웹 리서치를 하고, 초안을 작성한 후 비판하고 수정하는 반복적인 과정을 통해 훨씬 더 나은 결과물을 만들어낼 수 있다고 설명합니다.

[03:47] AI 펀드의 실제 경험을 바탕으로 에이전트 워크플로우의 효과를 증명합니다. 복잡한 컴플라이언스 문서, 의료 진단, 법적 문서 분석 등 다양한 프로젝트에서 이 방식이 성공과 실패를 가르는 핵심 요소였다고 밝힙니다.

[04:17] AI 스택의 최신 발전 사항을 업데이트하며, 새로운 에이전트 오케스트레이션 레이어가 등장했다고 설명합니다. 이 레이어는 애플리케이션 빌더들이 하부 기술 계층을 더 쉽게 조정할 수 있게 해주며, 여전히 애플리케이션 레이어가 가장 가치 있는 부분이라고 강조합니다.

‘AI로 헬스케어 자산 최적화’ 같은 모호한 표현 대신 ‘병원 MRI 예약 최적화 앱’처럼 엔지니어가 즉시 개발할 수 있을 만큼 명확한 구체성을 갖춘 아이디어가 속도를 보장한다고 강조한다.

[04:52] 스타트업의 빠른 실행을 위한 핵심 원칙으로 '구체적인 아이디어'의 중요성을 강조합니다. 구체적인 아이디어란 엔지니어가 바로 구축할 수 있을 정도로 세부사항이 명시된 것으로, 막연한 개념 대신 실행 가능한 구체적인 솔루션을 제시해야 한다고 설명합니다.

우선 하나의 명확한 가설(아이디어)에 집중해 빠르게 구축하고, 사용자 반응으로 증명하거나 포기한다. 전문가의 직관적 판단을 데이터 없이도 신속한 의사결정 메커니즘으로 활용한다.

[05:28] Andrew Ng는 구체적인 아이디어의 중요성을 강조하며 병원 MR 장비 예약 시스템을 예시로 제시합니다. 막연한 아이디어보다는 구체적인 아이디어가 엔지니어들이 빠르게 구축할 수 있게 하고, 성공 여부를 신속히 판단할 수 있게 한다고 설명합니다.

[05:43] 이메일 생산성 향상을 위한 AI 활용을 예시로 들어 막연한 아이디어와 구체적인 아이디어의 차이점을 설명합니다. Gmail 연동 자동화 기능처럼 구체적인 아이디어는 즉시 구현 가능하지만, 막연한 아이디어는 해석의 여지가 너무 많다고 지적합니다.

[05:59] 창업가들이 빠지기 쉬운 함정에 대해 경고합니다. 의료 자산 최적화 같은 막연한 아이디어는 사람들로부터 찬사를 받지만 실제로는 구축하기 어렵다고 설명합니다. 막연할 때는 거의 항상 맞다고 여겨지지만, 구체적일 때는 맞고 틀림을 빠르게 검증할 수 있다고 강조합니다.

[06:16] AI 펀드에서 팀에게 구체적인 아이디어에 집중하라고 요청하는 이유를 설명합니다. 구체적인 아이디어는 명확한 방향을 제시하고 팀이 빠르게 구축하여 검증하거나 반증할 수 있게 해준다고 말합니다.

[06:28] 좋은 구체적인 아이디어를 찾기 위해서는 전문가가 되어 오랫동안 문제에 대해 생각해야 한다고 설명합니다. 코세라 창업 전 온라인 교육에 대해 수년간 연구하고 사용자들과 대화한 경험을 사례로 제시합니다.

[06:41] 오랫동안 특정 분야에 대해 생각해온 전문가의 직감이 신속한 의사결정에 매우 유용하다고 설명합니다. 데이터보다도 경험에 기반한 직감이 스타트업에게는 더 빠르고 효과적인 의사결정 메커니즘이 될 수 있다고 강조합니다.

[07:58] 성공한 스타트업들의 공통적인 특징은 한 번에 하나의 명확한 가설에 집중한다는 것입니다. 리소스가 제한된 스타트업은 여러 가지를 동시에 시도할 수 없기 때문에 하나를 선택해 집중하고, 데이터가 잘못되었다고 말하면 즉시 피벗합니다.

[08:22] AI 펀드에서도 이런 패턴을 보입니다. 한 가지를 끈질기게 추구하다가 세상이 틀렸다고 말하면 완전히 다른 것으로 전환하되, 똑같은 결단력과 끈질김을 유지합니다.

[08:34] 새로운 데이터가 나올 때마다 피벗한다면 그 분야에 대한 지식 기반이 약하다는 신호입니다. 해당 주제에 대해 더 오래 생각해본 전문가를 찾는 것이 더 빠른 진전을 위해 중요합니다.

[08:57] AI 코딩 지원으로 인해 구축 피드백 루프가 급속히 변화하고 있습니다. 많은 애플리케이션을 구축할 때 가장 큰 위험은 고객 수용도로, 기술적 구현보다는 고객이 관심을 갖지 않는 것이 문제입니다.

엔지니어→PM→사용자 피드백 순환을 AI 코딩 어시스턴트로 가속화, 프로토타입은 10배 빠르고 프로덕션 코드는 30~50% 속도 향상을 경험한다. 초기엔 느슨해도 최종에는 보안·확장성 확보가 필요하다.

[09:25] 애플리케이션 스타트업에서는 소프트웨어를 구축하고(엔지니어링 태스크), 사용자 피드백을 받고(제품 관리 태스크), 이를 바탕으로 조정하는 루프를 반복하여 제품 시장 적합성을 찾아갑니다.

[09:46] AI 코딩 지원 덕분에 신속한 엔지니어링이 가능해졌습니다. 엔지니어링 속도는 빨라지고 비용은 줄어들면서, 스타트업이 이 피드백 루프를 실행하는 메커니즘이 변화하고 있습니다.

[10:08] 소프트웨어 개발을 두 가지 유형으로 나누어 생각할 수 있습니다. 첫 번째는 아이디어를 테스트하기 위한 빠르고 더러운 프로토타입이고, 두 번째는 거대한 프로덕션 준비 코드베이스를 작성하고 유지하는 것입니다.

[10:30] AI 시스템을 사용한 프로덕션 품질 코드 작성은 30-50% 정도 빨라졌지만, 빠르고 간단한 프로토타입 제작에서는 10배 이상 빨라졌다고 설명합니다.

[10:51] 독립적인 프로토타입 제작이 빠른 이유로 레거시 소프트웨어와의 통합이 적고, 안정성과 보안성 요구사항이 낮다는 점을 들며, 테스트 단계에서는 안전하지 않은 코드도 괜찮다고 조언합니다.

모든 직무가 코딩 역량을 갖추고 AI 도구를 지휘할 때 생산성이 극대화된다. 단순한 코딩 지식이 도메인별 전문성을 더해 더 정교한 AI 결과물을 만들어 낸다.

[11:34] 스타트업들이 20개의 프로토타입을 만들어 혁신을 추구하는 체계적 접근법을 소개하며, 개념증명의 비용을 낮추면 많은 시도가 실패해도 괜찮다고 설명합니다.

[11:56] '빠르게 움직이고 망가뜨리라'는 구호가 나쁜 평판을 얻었지만, '빠르게 움직이되 책임지라'는 접근법으로 책임감을 유지하면서도 빠르게 움직일 수 있다고 제안합니다.

[12:08] AI 지원 코딩 환경의 발전 과정을 설명하며, GitHub Copilot의 자동완성부터 Cursor, Windsurf 같은 AI 지원 IDE, 그리고 최근의 고도로 에이전트 기반인 코딩 어시스턴트까지의 변화를 소개합니다.

[12:40] o3과 Claude Code 같은 최신 도구들이 개발자 생산성을 크게 향상시키고 있으며, 심지어 반 세대나 한 세대 정도 뒤처진 도구를 사용해도 큰 차이가 난다고 강조합니다.

[13:05] 앤드류 응이 최신 AI 도구를 사용하는 팀과 그렇지 않은 팀의 차이에 대해 설명하며, 소프트웨어 엔지니어링에 대한 접근방식이 몇 개월 사이에 완전히 달라졌다고 언급합니다.

[13:15] AI 도구로 인해 코드 작성 비용이 급격히 감소하면서, 코드가 예전만큼 가치 있는 산출물이 아니게 되었다고 설명합니다. 팀에서는 한 달에 세 번이나 코드베이스를 완전히 다시 구축했다고 합니다.

[13:38] 제프 베조스의 '양방향 문 vs 단방향 문' 개념을 소개하며, 소프트웨어 아키텍처 선택이 예전에는 되돌리기 어려운 단방향 문이었지만 지금은 상황이 달라졌다고 설명합니다.

[14:10] 팀에서 기술 스택을 선택하고 일주일 후 마음을 바꿔 코드베이스를 버리고 새로운 스택에서 다시 만드는 일이 자주 발생한다고 합니다. 소프트웨어 엔지니어링 비용이 현저히 낮아졌기 때문입니다.

[14:33] 지금이 모든 사람이 AI로 구축할 수 있게 권한을 부여하기 좋은 시기라고 주장합니다. 지난 한 해 동안 AI 자동화를 이유로 코딩을 배우지 말라고 조언한 것을 최악의 직업 조언이라고 비판합니다.

[14:54] 역사적 예시를 들어 펀치 카드에서 키보드로, 어셈블리에서 고급 언어로 발전할 때마다 도구가 쉬워지면서 더 많은 사람들이 프로그래밍을 배우게 되었다고 설명합니다.

[15:24] 논란의 여지가 있는 의견으로, 모든 직무의 모든 사람이 코딩을 배울 때가 되었다고 주장하며, 자신의 팀에서 CFO, 인재 담당자, 리크루터 등이 모두 코딩을 배우고 있다고 언급합니다.

[15:35] 팀 전체가 코딩을 배우는 것의 중요성을 강조하며, 프론트 데스크 직원부터 모든 팀원이 코딩 능력을 갖추고 있어 각자의 업무에서 더 나은 성과를 내고 있다는 실제 경험을 공유합니다.

[15:52] 미드저니로 배경 아트를 생성하는 프로젝트에서 미술사 지식이 있는 팀원이 더 정확한 프롬프트를 작성해 우수한 결과를 얻었던 사례를 통해, 컴퓨터에게 정확히 원하는 것을 지시하는 능력의 중요성을 설명합니다.

[16:38] 미래에는 컴퓨터에 대한 깊은 이해를 가진 사람들이 더 큰 성과를 낼 것이며, 코딩을 배우는 것이 AI를 효과적으로 활용하는 최고의 방법이 될 것이라고 예측합니다.

[17:01] 소프트웨어 엔지니어링이 빨라지면서 제품 관리 업무가 병목이 되고 있다는 현상을 관찰하며, 여러 팀에서 제품 엔지니어링과 디자인이 새로운 제약사항이 되고 있다고 분석합니다.

[17:26] 과거 실리콘 밸리의 PM 대 엔지니어 비율이 1:4에서 1:7이었던 것과 달리, 엔지니어들의 생산성 향상으로 인해 이 비율이 PM 1명당 엔지니어 0.5명으로 역전되는 새로운 트렌드를 목격하고 있다고 설명합니다.

[18:09] Andrew Ng가 PM과 엔지니어 비율에 대한 팀의 제안을 소개하며, 엔지니어 수의 두 배만큼 PM을 두자는 흥미로운 제안에 대해 언급합니다.

[18:25] 코딩 능력이 있는 PM과 제품 감각이 있는 엔지니어의 중요성을 강조하고, 스타트업에서 신속한 피드백 전술의 필요성을 설명합니다.

[18:45] 제품 피드백을 얻는 다양한 전술들을 빠르고 부정확한 것부터 느리고 정확한 것까지 체계적으로 분류하여 소개합니다.

제품 자체 직감→3명 동료→낯선 사람(카페·로비 인터뷰)→소규모 프로토타입→100명 테스터→A/B 테스트 순으로 속도와 정확도를 조정하며 사용자 반응을 빠르게 얻는 다양한 전술을 제시한다.

[18:59] 가장 빠른 피드백 방법으로 직접 제품을 보고 직감에 의존하는 것을 제시하며, 전문가라면 이것이 효과적임을 설명합니다.

[19:08] 친구나 팀원 3명에게 피드백 요청하는 방법과 3-10명의 모르는 사람들에게 피드백을 받는 방법을 소개합니다.

[19:23] 커피숍이나 호텔 로비 같은 사람들이 많이 지나다니는 곳에서 모르는 사람들에게 정중하게 피드백을 요청하는 실제 경험을 공유합니다.

[19:53] 커피숍에서 일하는 사람들이 산만해질 핑계를 원한다는 통찰을 바탕으로, 실제로 호텔 로비나 커피숍에서 제품 결정을 내린 경험을 설명합니다.

[20:09] 100명의 테스터에게 프로토타입을 보내는 방법과 A/B 테스트에 대해 언급하며, 일반적인 생각과 달리 A/B 테스트가 가장 느린 전술 중 하나임을 지적합니다.

[20:35] A/B 테스트 결과를 단순히 제품 선택에만 사용하지 말고, 데이터를 세심하게 분석해 직관을 연마하고 의사결정의 품질을 향상시켜야 한다고 설명합니다.

[20:58] 예상과 다른 테스트 결과가 나왔을 때 사용자에 대한 정신 모델을 업데이트하여 더 빠르고 정확한 제품 결정을 내릴 수 있도록 해야 한다고 강조합니다.

[21:23] AI를 이해하는 것이 실제로 개발 속도를 높여준다는 점을 언급하며, 그 이유를 설명하기 시작합니다.

[21:33] 모바일, 마케팅, HR 등 성숙한 기술과 직무 분야는 많은 전문가들이 있어 지식이 널리 퍼져있지만, AI는 신흥 기술이라 전문 지식이 제한적이라고 설명합니다.

AI 기술이 성숙하지 않아 전문가 풀도 적으므로, 올바른 기술적 판단이 스타트업 속도를 10배 이상 좌우할 수 있다. 최신 AI 빌딩 블록을 학습해 조합 역량을 키워야 한다.

[22:13] AI를 실제로 이해하는 팀들이 그렇지 않은 팀들보다 우위를 가질 수 있다고 설명하며, 기술적 결정의 중요성을 강조합니다.

[22:34] 올바른 기술적 결정을 내리면 며칠 안에 문제를 해결할 수 있지만, 잘못된 결정을 내리면 몇 달 동안 막다른 길을 쫓을 수 있다고 경고합니다.

[23:00] 기술적 판단에서 잘못된 선택을 하면 단순히 두 배 늦어지는 것이 아니라 막다른 길을 쫓느라 10배나 더 오래 걸린다고 설명합니다. 올바른 기술적 판단력이 스타트업 속도를 크게 좌우한다고 강조합니다.

[23:26] 지난 2년간 생성형 AI 도구와 구성 요소들이 폭발적으로 증가했으며, 프롬프팅, RAG, 임베딩, 파인튜닝 등 다양한 AI 빌딩 블록들이 등장했다고 설명합니다. 이들로 1년 전에는 불가능했던 소프트웨어를 구축할 수 있게 되었습니다.

[24:07] AI 구성 요소들을 레고 블록에 비유하여 설명합니다. 하나의 구성 요소로도 멋진 것을 만들 수 있지만, 여러 구성 요소를 결합하면 조합론적으로 또는 기하급수적으로 더 많은 것을 만들 수 있다고 강조합니다.

[24:54] Deep Learning 코스 카탈로그를 통해 새로운 AI 구성 요소들을 학습하고 있으며, 이를 통해 1-2년 전에는 불가능했던 소프트웨어 애플리케이션을 조합론적으로 만들 수 있게 되었다고 설명합니다.

[25:25] 발표를 마무리하며 스타트업 성공에는 속도 외에도 많은 요소가 중요하지만, AI Fund가 투자하는 스타트업들을 관찰한 결과를 바탕으로 질문을 받겠다고 합니다.

구체적 아이디어, AI 코딩 어시스턴스, 제품 피드백 전술, 기술 학습을 통해 실행 속도를 극대화하면 스타트업의 성공 확률이 높아진다. 속도와 책임감 있는 실행을 모두 갖추는 것이 핵심이다.

[25:38] Andrew Ng는 AI 펀드가 투자하는 스타트업들을 관찰한 결과, 경영진의 빠른 실행 능력이 성공 확률과 매우 높은 상관관계를 보인다고 말합니다. 속도를 얻기 위해서는 구체적인 아이디어에 집중하는 것이 중요하며, 임원으로서 의사결정의 속도와 품질 모두 중요하지만 특히 속도가 절대적으로 중요하다고 강조합니다.

[26:00] AI 코딩 지원을 통한 빠른 프로토타이핑은 개발 속도를 향상시키지만, 병목현상을 제품 결정에 대한 사용자 피드백을 받는 것으로 이동시킵니다. 따라서 빠른 피드백을 얻기 위한 다양한 전술이 필요하며, 커피숍에서 모르는 사람들과 대화하는 것 같은 사용자 리서치 기술도 기업가들에게 중요한 역량이라고 제안합니다.

[26:41] 첫 번째 질문은 AI가 발전하면서 인간이 도구를 개발하는 것과 도구를 더 잘 사용하는 것 중 어느 것이 더 중요한지에 대한 것입니다. Andrew Ng는 AGI가 과대평가되었다고 생각하며, 오랫동안 인간이 할 수 있지만 AI가 할 수 없는 일들이 많을 것이라고 답변합니다.

[27:08] 미래에 가장 강력한 사람들은 컴퓨터가 정확히 원하는 것을 하도록 만들 수 있는 사람들이라고 예측합니다. 도구를 따라잡는 것이 중요하며, 일부는 도구를 만들 수도 있지만 다른 사람들이 만든 도구들을 잘 활용하는 것도 중요합니다. AI를 사용할 수 있는 사람들이 그렇지 않은 사람들보다 훨씬 더 강력해질 것이라고 강조합니다.

[27:34] 두 번째 질문은 컴퓨팅의 미래에 관한 것으로, 더 강력한 AI로 나아가면서 컴퓨팅이 어디로 향하고 있는지에 대한 질문입니다. 질문자는 GPU를 우주로 보내거나 핵 발전소 데이터센터 같은 극단적인 아이디어들을 언급합니다.

[28:00] Andrew Ng는 무엇이 과대광고이고 무엇이 실제인지 구분하는 프레임워크를 제시합니다. 지난 2년 동안 몇몇 기업들이 홍보, PR, 펀드레이징, 영향력 목적으로 특정 것들을 과대광고했으며, AI가 새로운 분야였기 때문에 이들이 팩트체크 없이 거의 모든 것을 주장할 수 있었다고 분석합니다.

[28:29] 앤드류 응은 AI 분야에서 발생하는 과장된 이야기들에 대해 비판적 시각을 제시합니다. 기술이 제대로 이해되지 않았던 초기에는 많은 기업들이 사실 확인 없이 과장된 주장을 펼쳤다고 설명합니다.

[28:42] AI로 인한 인류 멸종 가능성, 모든 일자리 소멸, 새로운 모델 하나로 수천 개 스타트업을 쉽게 없앨 수 있다는 주장들이 모두 과장되었다고 지적합니다. 이런 이야기들이 특정 기업들의 자금 조달에 도움이 되었다고 분석합니다.

[29:21] Jasper와 같은 소수 회사들이 실제로 어려움을 겪었지만, 수천 개의 스타트업을 쉽게 없애는 것은 현실적이지 않다고 반박합니다. AI 전력 소비에 대한 과장된 주장들도 비판합니다.

[29:54] 질문자가 AI 분야의 과장과 불확실성을 인정하면서, 가장 위험한 편향이나 과장된 이야기들을 식별하여 더 현실적인 시각을 갖는 방법에 대해 묻습니다.

[30:25] 앤드류 응은 '위험한 AI' 이야기가 과장되었다고 답변합니다. AI를 전기와 같은 강력한 도구로 비유하며, 유익한 목적과 해로운 목적 모두로 사용될 수 있다고 설명합니다.

[30:41] AI 안전성이라는 용어 사용을 피하는 이유를 설명합니다. 안전성은 기술 자체의 속성이 아니라 우리가 그것을 어떻게 적용하느냐에 달려있다고 주장합니다.

[30:57] 전기 모터 비유를 통해 자신의 논점을 강화합니다. 전기 모터가 유용한 기계나 무기 모두에 사용될 수 있듯이, 제조업체는 하류 사용법을 통제할 수 없으며, 안전성은 적용 방식에 달려있다고 결론짓습니다.

[31:17] AI 기술의 안전성은 기술 자체가 아니라 우리가 그것을 어떻게 적용하느냐에 달려 있습니다. AI 안전성보다는 '책임감 있는 AI'라는 관점으로 접근해야 하며, 우리의 사용 방식이 기술의 결과를 좌우합니다.

[31:38] 최근 월스트리트 저널의 AI 통제 실패에 관한 기사처럼, 언론에서는 실험실의 극단적인 사례를 과장해서 보도하는 경향이 있습니다. 기술이 복잡하다 보니 많은 사람들이 이런 과장된 이야기에 현혹되고, 이는 오픈 소스 소프트웨어에 대한 공격 도구로도 사용되고 있습니다.

[32:17] 하루 만에 모든 것이 파괴될 수 있고 VIP 코드로 쉽게 복제 가능한 현재 상황에서, 예비 창업자들은 어떻게 비즈니스를 구상해야 할까요? 이는 현재 많은 창업자들이 직면한 핵심적인 고민입니다.

[32:34] 사업을 시작할 때 걱정해야 할 것들은 많지만, 가장 중요한 것은 사용자들이 사랑하는 제품을 만드는 것입니다. 시장 진출 채널, 경쟁사, 기술 모드 등도 중요하지만, 사용자가 정말 원하는 제품을 만들지 못하면 가치 있는 비즈니스를 구축하기 어렵습니다.

[33:05] 핵심 제품 문제를 해결한 후에는 고객 도달 채널, 가격 정책, 경쟁 우위(해자) 등을 고려해야 합니다. 하지만 해자는 과장되는 경향이 있으며, 대부분의 비즈니스는 제품으로 시작해서 점진적으로 해자를 구축해나갑니다.

[33:40] AI 펀드에서는 비즈니스를 평가할 때 이런 모든 요소들을 종합적으로 분석합니다. 2-6페이지의 상세한 분석 메모를 작성해서 투자 결정을 내리며, 현재 시점에서는 아직 아무도 만들지 않은 기회들이 상당히 많다고 봅니다.

[34:04] 현재 AI 애플리케이션 레이어에는 엄청난 기회가 있으며, 아직 만들어지지 않은 것들이 그것을 만들 수 있는 기술자들보다 훨씬 많다고 설명합니다.

[34:19] 사람들이 원하고 사랑하는 제품을 만드는 데 집중하고, 나머지는 과정에서 해결해 나가라고 조언합니다.

[34:28] 스탠포드 박사과정 연구원이 AI 도구들의 벽돌 비유와 관련하여 에이전트 시스템의 누적 효과에 대해 질문합니다.

[35:13] 토큰 비용에 대해 걱정하지 말라고 조언하며, 대부분의 스타트업은 토큰 비용이 문제가 될 정도로 성공하기 어렵다고 설명합니다.

[35:44] 토큰 비용이 문제가 되는 경우에도 프롬프팅, 파인튜닝, 증류 등의 엔지니어링 솔루션으로 해결할 수 있다고 말합니다.

[36:08] 고객 서비스 챗봇 예시를 들어 에이전트 워크플로우가 실제로 여러 단계를 통합하여 성장하는 모습을 보여줍니다.

[36:34] 서로 다른 빌딩 블록 제공업체들 간의 전환을 쉽게 만들도록 소프트웨어를 설계하는 팁을 제공합니다.

[36:45] 앤드류 응이 LLM 모델 선택에 대한 실용적 접근법을 설명합니다. 자동 평가 시스템을 통해 성능이 좋은 모델로 즉시 전환하며, 파운데이션 모델의 전환 비용이 낮아 유연성을 유지한다고 강조합니다.

[37:35] 교육 분야 AI의 두 가지 패러다임을 소개합니다. 교사 생산성 향상(자동채점, 자동화)과 개인 맞춤형 AI 튜터 제공이라는 두 방향성을 제시하며, 현재 다양한 실험이 진행되고 있다고 설명합니다.

[38:10] 구체적인 교육 AI 사례들을 언급하며 현재 상황을 분석합니다. 코세라 코치, 딥러닝.ai의 챗봇, 듀오링고의 언어학습 등의 성공사례가 있지만, 전체 교육 분야의 AI 변화 방향은 아직 실험 단계라고 평가합니다.

[38:54] AI 교육의 미래 전망과 현실적 한계를 논의합니다. 과거 AGI에 대한 과장된 기대와 달리, 교육 업무의 복잡성을 인정하며 향후 10년간 점진적인 에이전트 AI 워크플로우 개발이 필요하다고 전망합니다.

[39:17] 앤드류 응 교수가 AI 에이전트 워크플로우와 교육 분야의 매핑이 아직 진행 중이며, 최종 단계가 명확하지 않은 상태라고 설명합니다.

[39:32] 청중이 AI의 긍정적 잠재력과 함께 경제적 불평등 악화 등의 부정적 결과에 대한 우려를 표현하며, 빠른 개발과 책임감 있는 접근법의 균형에 대해 질문합니다.

[40:09] 앤드류 응 교수가 근본적으로 사람들을 더 나아지게 하지 않는다면 하지 말라고 조언하며, AI 펀드에서 윤리적 이유로 여러 프로젝트를 중단한 경험을 공유합니다.

[40:37] 모든 직무에서 AI를 아는 사람들이 더 생산적이라는 사례를 들며, 마케팅 팀 직원들이 코딩을 배워 더 나아진 경험을 공유합니다.

[41:07] 다른 청중이 온라인 강의에 감사를 표하며 AI가 강력해지면서 실제 능력과 대중의 인식 사이 격차가 벌어지는 문제에 대해 질문합니다.

[41:43] 앤드류 응 교수가 딥러닝 AI 지식의 확산과 모든 사람이 AI로 구축할 수 있도록 역량을 갖추는 것의 중요성에 대해 언급합니다.

[41:50] AI 발전의 두 가지 주요 위험에 대해 설명합니다. 첫 번째는 사람들을 충분히 빠르게 따라오게 하지 못하는 것이고, 두 번째는 모바일 생태계처럼 게이트키퍼가 혁신을 제한하는 것입니다.

[42:15] 특정 기업들이 AI의 위험성을 과장하여 오픈소스를 막으려 하고 있으며, 캘리포니아의 SB 1047 같은 법안을 통해 대규모 파운데이션 모델의 게이트키퍼가 되려고 한다고 지적합니다.

[42:40] 이런 규제는 실제로는 아무도 더 안전하게 하지 못하면서 오픈소스와 오픈 웨이트 소프트웨어 배포를 어렵게 만들고, 소수의 게이트키퍼만 남겨두어 혁신의 자유를 제한한다고 경고합니다.

[00:00] 모두 만나서 정말 기쁩니다.

[00:02] 오늘은 여러분이 스타트업 스쿨 학생들이니까

[00:05] 제가 AI 펀드에서 스타트업을 만들면서

[00:07] 배운 교훈들을 공유해드리고 싶습니다.

[00:09] AI 펀드는 벤처 스튜디오로

[00:12] 한 달에 평균 하나씩 스타트업을 만들고 있습니다.

[00:14] 그리고 우리는 스타트업을 공동창업하기 때문에

[00:16] 직접 코드를 짜고, 고객들과 이야기하고

[00:18] 피처 디자인과 가격 결정까지

[00:19] 모든 것에 깊이 관여하고 있습니다.

[00:21] 그래서 우리는 다른 사람들이 스타트업을 만드는 걸 지켜보는 것이 아니라

[00:23] 실제로 현장에서

[00:25] 기업가들과 함께 스타트업을 만드는

[00:26] 많은 경험을 쌓아왔습니다.

[00:28] 오늘 제가 여러분과 나누고 싶은 건

[00:30] 제가 스타트업을 만들면서 배운 교훈들

[00:32] 특히 변화하는 AI 기술과

[00:34] 그것이 가능하게 하는 것들에 대한 이야기입니다.

[00:36] 그리고 오늘의 주제는 '속도'에 초점을 맞추겠습니다.

[00:38] 스타트업을 만들고 싶은 분들에게

[00:41] 스타트업 성공 확률을 예측하는 강력한 지표는

[00:44] 실행 속도라고 생각합니다.

[00:45] 그리고 저는 실제로

[00:47] 정말 빠르게 일을 처리하는

[00:50] 기업가들과 경영진들을 매우 존경합니다.

[00:52] 그리고 새로운 AI 기술은

[00:54] 스타트업들이 훨씬 빠르게 움직일 수 있게 해줍니다.

[00:58] 그래서 제가 오늘 여러분과 공유하고 싶은 것은

[01:00] 솔직히 말씀드리면 지금도 2-3개월마다 변화하고 있는

[01:03] 그런 모범사례들입니다.

[01:04] 이런 것들이 여러분에게 속도를 가져다주고

[01:06] 결국 더 높은 성공 확률을 가져다주길 바랍니다.

[01:08] 속도에 대해 깊이 들어가기 전에

[01:09] 많은 사람들이 제게 묻습니다.

[01:11] "앤드류, 스타트업 기회가 어디에 있나요?"

[01:13] 이것이 제가 생각하는 AI 스택입니다.

[01:15] 가장 아래 층에는 반도체 기업들이 있고

[01:17] 그 위에 클라우드 하이퍼스케일러들이 구축되어 있습니다.

[01:20] 그리고 그 위에

[01:22] 많은 AI 파운데이션 모델 회사들이

[01:24] 구축되어 있습니다.

[01:27] 그리고 비록 많은 PR 관심과 과대광고가

[01:28] 이러한 기술 레이어들에 집중되어 있지만

[01:31] 정의상 가장 큰 기회는

[01:33] 애플리케이션 레이어에 있어야 합니다.

[01:36] 왜냐하면 실제로 애플리케이션들이

[01:38] 더 많은 수익을 창출해야

[01:40] 파운데이션, 클라우드, 반도체 기술 레이어들에

[01:43] 비용을 지불할 수 있기 때문입니다.

[01:45] 어떤 이유에서인지 미디어와 소셜미디어는

[01:47] 애플리케이션 레이어에 대해

[01:49] 그리 많이 이야기하지 않지만

[01:52] 스타트업을 만들고 있는 여러분들에게는

[01:54] 정의상 가장 큰 기회가

[01:57] 거기에 있어야 합니다.

[01:58] 물론 스택의 모든 레이어에

[02:00] 기회가 있기는 하지만요.

[02:02] 지난 1년 동안 많이 변한 것 중 하나는

[02:04] 스택의 모든 레이어에 기회가 있다는 것입니다.

[02:05] 지난 1년 동안 많이 변한 것 중 하나는

[02:07] AI 기술 트렌드에 관한 것인데

[02:10] 만약 AI에서 가장 중요한 기술 트렌드가 뭐냐고 묻는다면

[02:13] 저는 에이전트 AI의 부상이라고 말하겠습니다.

[02:15] 약 1년 반 전에 제가 여러 곳을 돌아다니며

[02:18] AI 에이전트가 중요할 수 있다는 것을

[02:20] 사람들에게 설득하려고 강연을 했을 때

[02:21] 작년 여름경에 마케터들이

[02:24] 이 용어를 가져다가 스티커처럼 사용해서

[02:27] 보이는 모든 것에 붙여댈 거라고는

[02:29] 상상도 못했습니다.

[02:32] 이로 인해 그 용어가 의미를 잃게 되었지만

[02:33] 제가 여러분과 공유하고 싶은 것은

[02:35] 기술적 관점에서

[02:37] 왜 에이전트 AI가 흥미롭고 중요한지

[02:40] 그리고 또한 훨씬 더 많은 스타트업 기회를

[02:42] 열어주는지에 대한 것입니다.

[02:45] 기회들이 있습니다. 그런데 우리 대부분이 LLM을 사용하는 방식은

[02:47] 프롬프트를 통해 결과물을 생성하도록 하는 것입니다. 그리고 LLM이

[02:49] 무언가를 출력하게 하는 방식은 마치

[02:52] 사람이나 이 경우엔 AI에게 가서

[02:55] 첫 번째 단어부터 마지막 단어까지

[02:57] 백스페이스를 전혀 사용하지 않고

[02:59] 한 번에 에세이를 써달라고

[03:01] 부탁하는 것과 같습니다. 그리고

[03:03] 인간인 우리는 이런 선형적인

[03:06] 순서로 타이핑하도록 강요받을 때

[03:08] 최고의 글쓰기를 하지 못합니다.

[03:10] 그리고 AI 역시 마찬가지입니다.

[03:12] 하지만 이런 선형적인 방식으로

[03:14] 쓰도록 강요받는 어려움에도 불구하고

[03:16] 우리의 LLM들은 놀랍도록 잘 수행합니다.

[03:18] 에이전트 워크플로우를 통해 우리는

[03:20] AI 시스템에게 먼저 에세이 개요를 작성하고

[03:22] 필요하다면 웹 리서치를 하고

[03:24] 웹 페이지를 가져와서 컨텍스트에 넣고

[03:26] 첫 번째 초안을 작성하고

[03:27] 그 초안을 읽고 비판하고 수정하는

[03:30] 과정을 반복하도록 요청할 수 있습니다.

[03:31] 그래서 우리는 모델이 사고하고

[03:33] 리서치하고 수정하고 다시 돌아가서

[03:35] 더 많은 사고를 하는

[03:37] 반복적인 워크플로우를 갖게 됩니다.

[03:39] 이런 루프를 여러 번 반복함으로써

[03:41] 더 느리긴 하지만 훨씬 더 나은

[03:43] 결과물을 만들어냅니다.

[03:45] AI 펀드가 진행한 많은 프로젝트들에서

[03:47] 복잡한 컴플라이언스 문서 추출부터

[03:49] 의료 진단, 복잡한 법적 문서에 대한

[03:52] 추론까지 모든 것에서

[03:55] 이런 에이전트 워크플로우가

[03:57] 작동하는 것과 그렇지 않은 것 사이의

[03:59] 엄청난 차이를 만든다는 것을 발견했습니다.

[04:01] 하지만 해야 할 많은 작업들과

[04:03] 구축해야 할 가치 있는 비즈니스들은

[04:06] 여전히 기존 워크플로우나 새로운

[04:07] 워크플로우를 가져와서 이를

[04:09] 어떻게 에이전트 워크플로우로

[04:11] 구현할지 알아내는 것입니다.

[04:12] AI 스택에 대한 그림을 업데이트하자면

[04:14] 작년에 등장한 것은 애플리케이션 빌더들이

[04:17] 하부 기술 계층에 대한 많은 호출을

[04:20] 오케스트레이션하거나 조정하는 데 도움이 되는

[04:23] 새로운 에이전트 오케스트레이션 레이어입니다.

[04:26] 그리고 좋은 소식은 오케스트레이션 레이어가

[04:28] 애플리케이션 구축을 더욱 쉽게 만들었다는 것입니다.

[04:30] 하지만 애플리케이션 레이어가

[04:32] 스택에서 가장 가치 있는 레이어여야 한다는

[04:34] 기본 결론은 애플리케이션 레이어에

[04:36] 편향이나 집중을 둔 채로

[04:38] 여전히 유효하다고 생각합니다.

[04:40] 이제 스타트업이 더 빠르게 움직일 수 있는

[04:41] 모범 사례들에 대해 자세히 설명하겠습니다.

[04:44] AI 펀드에서 우리는 오직

[04:46] 구체적인 아이디어에만 집중한다는 것이

[04:48] 밝혀졌습니다.

[04:51] 제게 구체적인 아이디어, 구체적인 제품

[04:52] 아이디어란 엔지니어가 가서 구축할 수 있을

[04:57] 정도로 충분한 세부사항이 명시된 것입니다.

[05:00] 예를 들어 AI를 사용해서 의료 자산을

[05:02] 최적화하자고 말한다면

[05:05] 그건 사실 구체적인 아이디어가 아닙니다.

[05:07] 너무 막연합니다. 만약 AI를 사용해서

[05:10] 의료 자산을 최적화하는 소프트웨어를

[05:13] 만들자고 말한다면

[05:14] 서로 다른 엔지니어들이 완전히 다른

[05:16] 일을 할 것이고, 구체적이지 않기 때문에

[05:17] 빠르게 구축할 수 없고

[05:19] 속도를 낼 수 없습니다.

[05:21] 반면에 병원이 MR 기계 슬롯을

[05:23] 온라인으로 예약할 수 있게 해서

[05:24] 사용률을 최적화하는 소프트웨어를

[05:27] 작성하자는 구체적인 아이디어가 있다면

[05:28] 병원이 환자들로 하여금 MR 장비 예약을 온라인으로 할 수 있도록 해서 이용률을 최적화하는 소프트웨어를 만들어보자.

[05:31] 이게 좋은 아이디어인지 나쁜 아이디어인지는 모르겠어요.

[05:33] 실제로 이미 시장에서 이런 비즈니스를 하고 있기도 하고요.

[05:34] 하지만 이건 구체적이고

[05:36] 그것은 엔지니어들이 빠르게 구축할 수 있다는 의미입니다.

[05:38] 만약 이게 좋은 아이디어라면 알게 될 것이고

[05:39] 좋은 아이디어가 아니라면 그것도 알게 될 겁니다.

[05:41] 하지만 구체적인 아이디어를 가지는 것이 속도를 가져다줍니다.

[05:43] 반면에 누군가 '이메일 개인 생산성을 위해 AI를 사용해보자'라고 말한다면

[05:45] 너무 많은 해석이 가능합니다. 그건 구체적이지 않아요.

[05:47] 하지만 누군가 Gmail과 연동되는 앱을 만들어서

[05:49] 적절한 프롬프트를 사용해 전체 이메일을 필터링하는 자동화를 구축해달라고 말한다면

[05:51] 그것은 구체적입니다. 저는 오늘 오후에도 그걸 만들 수 있어요.

[05:54] 따라서 구체성은 속도를 가져다줍니다.

[05:55] 많은 창업가들에게 기만적인 부분은

[05:57] 막연한 아이디어들이 많은 찬사를 받는 경향이 있다는 것입니다.

[05:59] 만약 당신이 친구들에게 'AI를 이용해서 의료 자산 활용을 최적화해야 한다'고 말한다면

[06:00] 모든 사람들이 그것이 훌륭한 아이디어라고 말할 것입니다.

[06:02] 하지만 실제로는 훌륭한 아이디어가 아닙니다.

[06:04] 적어도 구축할 수 있는 것이라는 관점에서는 말이죠.

[06:06] 막연할 때는 거의 항상 맞습니다.

[06:09] 하지만 구체적일 때는 맞을 수도 있고 틀릴 수도 있어요.

[06:10] 어느 쪽이든 괜찮습니다. 훨씬 빠르게 발견할 수 있으니까요.

[06:12] 그리고 이것이 스타트업에게 중요한 것입니다.

[06:14] 구체적인 아이디어를 실행하는 측면에서

[06:16] 저는 AI 펀드에서 팀에게 구체적인 아이디어에 집중하라고 요청합니다.

[06:17] 왜냐하면 구체적인 아이디어는 명확한 방향을 제시하고

[06:19] 팀이 정말 빠르게 달려가서 그것을 구축할 수 있기 때문입니다.

[06:21] 그리고 검증하거나 입증하거나 반증해서 작동하지 않는다는 결론을 내릴 수 있습니다.

[06:22] 어느 쪽이든 괜찮습니다. 그래서 우리는 빠르게 할 수 있고

[06:25] 좋은 구체적인 아이디어를 찾는 것은 보통

[06:27] 누군가가 - 당신이 될 수도 있고 - 전문가가 되어서 오랫동안 문제에 대해 생각해야 한다는 것이 밝혀졌습니다.

[06:28] 예를 들어, 실제로 코세라를 시작하기 전에

[06:31] 저는 수년간 온라인 교육에 대해 생각하고 사용자들과 대화하면서

[06:33] 좋은 에듀테크 플랫폼을 만들기 위해 필요한 것이 무엇인지에 대한 제 자신의 직관을 키웠습니다.

[06:36] 그리고 그 긴 과정을 거친 후에 - Y Combinator에서는 이를 아이디어 미로 탐험이라고 부르기도 하는데 -

[06:39] 오랫동안 생각해본 후에 발견한 것은

[06:41] 오랫동안 이에 대해 생각해온 사람들의 직감이

[06:43] 신속하게 의사결정을 내리는 데 매우 좋을 수 있다는 것입니다.

[06:45] 즉, 오랫동안 이에 대해 생각하고 고객들과 대화한 후에

[06:47] 이 전문가에게 '이 기능을 구축해야 할까요, 아니면 저 기능을 구축해야 할까요?'라고 물어보면

[06:49] 즉각적인 결정인 직감이 실제로 놀랍도록 좋은 대리 지표가 될 수 있습니다.

[06:51] 의사결정을 위한 놀랍도록 좋은 메커니즘이 될 수 있습니다.

[06:54] 그리고 제가 AI를 다루고 있다는 것을 알고 있으니 '오, 데이터가 필요하다'고 말할 것이라고 생각할 수도 있습니다.

[06:55] 물론 저는 데이터를 좋아하지만, 많은 스타트업에게 데이터를 얻는 것은

[06:57] 실제로 의사결정을 위한 느린 메커니즘이라는 것이 밝혀졌습니다.

[06:59] 그리고 좋은 직감을 가진 전문가는 종종 신속한 의사결정을 위한 훨씬 더 나은 메커니즘입니다.

[07:01] 그리고 또 다른 중요한 것은

[07:58] 성공한 스타트업들이 보여주는 또 다른 패턴은

[08:00] 항상 어느 순간에든 하나의 명확한 가설을 추구하고 있다는 것입니다

[08:02] 그것을 구축하고 중국 병원 시장에 판매하려고 시도하고 있죠

[08:05] 음, 스타트업은

[08:06] 동시에 10가지를 헤지하고 시도할 리소스가 없습니다

[08:09] 그래서 하나를 선택해서 밀어붙이고

[08:11] 데이터가 그 아이디어에 대한 신뢰를 잃으라고 말한다면

[08:14] 사실 그건 완전히 괜찮습니다

[08:16] 그냥 즉시 피벗해서

[08:18] 완전히 다른 구체적인 아이디어를 추구하면 됩니다

[08:20] 그게 바로

[08:22] AI 펀드에서 자주 경험하는 일입니다

[08:24] 우리는 한 가지를 끈질기게 추구합니다

[08:26] 세상이 우리가 틀렸다고 말할 때까지 결단력을 가지고 말이죠

[08:28] 그러면 바뀌어서 완전히 다른 것을 추구합니다

[08:30] 똑같은 결단력과

[08:32] 똑같은 끈질김으로 말이죠

[08:34] 그리고 제가 본 또 다른 패턴은

[08:37] 새로운 데이터가 나올 때마다 피벗한다면

[08:39] 아마도 너무 약한 지식 기반에서 시작하고 있다는 뜻일 겁니다

[08:41] 맞죠?

[08:42] 고객과 대화할 때마다

[08:44] 완전히 마음을 바꾼다면

[08:45] 아마도 그 분야에 대해

[08:47] 정말 고품질의 구체적인 아이디어를 가질 만큼

[08:48] 충분히 알지 못한다는 뜻일 겁니다

[08:51] 그 주제에 대해 더 오래 생각해본

[08:52] 누군가를 찾는 것이

[08:54] 더 빠르게 나아가기 위해 더 나은 길로 인도할 수 있습니다

[08:57] 제가 자주 생각하는 또 다른 것은

[08:58] 구축 피드백 루프입니다

[09:00] 이것은 AI 코딩 지원으로 우리가 구축하는 방식에 있어

[09:02] 급속히 변화하고 있습니다

[09:05] 많은 애플리케이션을 구축할 때

[09:07] 가장 큰 위험 중 하나는

[09:08] 고객 수용도입니다, 맞죠?

[09:10] 많은 스타트업이 어려움을 겪는 이유는

[09:12] 우리가 원하는 것을 구축할 수 없어서가 아니라

[09:13] 우리가 뭔가를 구축했는데

[09:15] 아무도 신경 쓰지 않는다는 것이 밝혀지기 때문입니다

[09:17] 그래서 제가 스타트업을 구축하는 많은 방법들

[09:19] 특히 애플리케이션들, 딥테크보다는

[09:21] 기술 스타트업보다는 덜하지만

[09:23] 확실히 애플리케이션 스타트업에서는

[09:25] 우리가 소프트웨어를 구축하는 경우가 많습니다

[09:27] 이것은 엔지니어링 태스크이고

[09:29] 그러면 사용자로부터 피드백을 받습니다

[09:31] 이것은 제품 관리 태스크이고

[09:33] 그러면 다시 돌아가서

[09:35] 사용자 피드백을 바탕으로

[09:36] 무엇을 구축할지에 대한 우리의 견해를 조정하고

[09:39] 다시 돌아가서 더 많은 소프트웨어를 작성하고

[09:40] 이 루프를 여러 번 돌면서

[09:43] 제품 시장 적합성을 향해 반복합니다

[09:46] 그런데 Andre가 말한 것처럼

[09:48] AI 코딩 지원을 통해

[09:52] 신속한 엔지니어링이

[09:53] 이전에는 불가능했던 방식으로 가능해지고 있습니다

[09:56] 훨씬 더 실현 가능해지고 있습니다

[09:59] 엔지니어링 속도가 빠르게 향상되고 있고

[10:01] 엔지니어링 비용도 빠르게 줄어들고 있습니다

[10:04] 이것은 우리가 스타트업을

[10:06] 이 루프를 중심으로 움직이는 메커니즘을 바꿉니다

[10:08] 제가 하는 소프트웨어에 대해 생각해볼 때

[10:09] 아마도 두 가지 주요 버킷으로 나눌 수 있습니다

[10:11] 때때로 저는 아이디어를 테스트하기 위해

[10:13] 빠르고 더러운 프로토타입을 구축합니다

[10:14] 새로운 고객 서비스 챗봇을 구축한다든지

[10:16] 법적 문서를 처리하는 AI를 구축한다든지

[10:18] 무엇이든 빠르고 더러운 프로토타입을 구축해서

[10:20] 작동하는지 보는 것입니다

[10:21] 제가 하는 다른 유형의 소프트웨어는

[10:23] 프로덕션 소프트웨어를 작성하고 유지하는 것

[10:26] 레거시 소프트웨어를 유지하는 것

[10:28] 이런 거대한 프로덕션 준비 코드베이스들입니다

[10:30] 신뢰할 수 있는 데이터를 찾기가 어려웠습니다.

[10:32] 이에 대한 엄밀한 데이터를 찾기가 어려웠어요.

[10:34] 프로덕션 품질의 코드를 작성할 때

[10:36] AI 시스템으로 30-50% 정도 빨라졌을 겁니다.

[10:38] 정확한 수치를 찾기는 어렵지만요.

[10:40] 그럴듯하다고 생각하지만

[10:42] 빠르고 간단한 프로토타입을 만들 때는

[10:44] 50% 빨라진 게 아니라

[10:46] 쉽게 10배는 빨라졌고 아마 그보다 훨씬 빨라졌을 겁니다.

[10:48] 10배보다 훨씬 빨라졌고 몇 가지 이유가 있습니다.

[10:51] 독립적인 프로토타입을 만들 때는

[10:53] 기존 소프트웨어와의 통합이 적고

[10:55] 레거시 소프트웨어와의 통합이 적습니다.

[10:57] 인프라, 레거시 데이터 필요성도 적고

[11:00] 또한 요구사항, 안정성, 심지어 확장성과

[11:03] 보안성도 훨씬 낮습니다.

[11:06] 사람들에게 안전하지 않은 코드를 작성하라고 말하면

[11:07] 안 된다는 걸 알고 있어요.

[11:09] 잘못된 말 같지만, 저는 팀에게

[11:11] 자주 이렇게 말합니다. '안전하지 않은 코드를 작성해도 된다'고요.

[11:12] 왜냐하면 이 소프트웨어가 당신의 노트북에서만 실행되고

[11:14] 본인이 본인의 노트북을 악의적으로 해킹할 계획이 없다면

[11:16] 안전하지 않은 코드여도 괜찮거든요.

[11:18] 하지만 물론 작동하는 것 같으면

[11:20] 다른 사람에게 배포하기 전에 보안을 강화해야 합니다.

[11:22] 개인정보 유출, 민감한 데이터 유출 같은 것들은

[11:24] 매우 피해가 크니까요.

[11:26] 그래서 배포하기 전에는 보안과 확장성을 확보해야 하지만

[11:27] 단순히 테스트하는 것뿐이라면 괜찮습니다.

[11:30] 점점 더 많은 스타트업들이

[11:32] 체계적으로 혁신을 추구하고 있습니다.

[11:33] 20개의 프로토타입을 만들어서 어떤 것이 작동하는지 보는 방식으로요.

[11:34] AI에 대한 걱정이 있다는 걸 알고 있습니다.

[11:37] 많은 개념증명이 프로덕션으로 이어지지 않거든요.

[11:39] 하지만 개념증명의 비용을 충분히 낮추면

[11:41] 많은 개념증명이 빛을 보지 못해도 괜찮다고 생각합니다.

[11:45] '빠르게 움직이고 망가뜨리라'는 구호가

[11:46] 나쁜 평판을 얻었다는 걸 알고 있어요.

[11:48] 실제로 망가뜨렸으니까요.

[11:50] 어떤 팀들은 이를 통해 빠르게 움직이면

[11:51] 안 된다고 생각하게 되었지만

[11:53] 그건 실수라고 생각합니다.

[11:56] 저는 팀에게 '빠르게 움직이되 책임지라'고 말하는 편입니다.

[11:58] 실제로 책임감을 유지하면서도

[12:00] 정말 빠르게 움직일 수 있는 방법들이 많이 있다고 생각합니다.

[12:03] AI 지원 코딩 환경에 대해서는

[12:05] 3-4년 전 코드 자동완성이 있었죠.

[12:08] GitHub Copilot으로 인기를 얻었고

[12:10] 그 다음에 Cursor와 Windsurf 같은

[12:11] AI 지원 IDE의 세대가 나왔습니다.

[12:13] Windsurf와 Cursor를 많이 사용하고 있고

[12:16] 6-7개월 전부터 새로운 세대의

[12:19] 고도로 에이전트 기반인 코딩 어시스턴트들이 나오기 시작했습니다.

[12:21] o3을 코딩에 많이 사용하고 있고

[12:23] Claude Code는 정말 환상적입니다.

[12:26] Claude 4 출시 이후로

[12:28] 몇 개월 후에 다시 물어보면 다른 걸 사용할 수도 있겠지만

[12:31] 도구들이 정말 빠르게 발전하고 있습니다.

[12:33] 하지만 Claude Code는 새로운 세대의

[12:36] 고도로 에이전트 기반인 코딩 어시스턴트로

[12:38] 개발자 생산성을 계속 향상시키고 있습니다.

[12:40] 흥미로운 점은 심지어 반 세대나

[12:43] 한 세대 정도 뒤처져도 실제로는 큰 차이가 난다는 것입니다.

[12:45] 한 세대 뒤처져도 실제로는 큰 차이가 난다는 것입니다.

[12:47] 최신 도구를 사용할 때와 비교해서

[12:49] 제 팀이 정말 다른 접근 방식을 취하고 있다는 걸 발견했습니다.

[12:50] 도구들이 정말 빠르게 발전하고 있지만

[12:51] Claude Code는 이 새로운 세대의

[12:54] 고도로 에이전트 기반인 코딩 어시스턴트로

[12:56] 개발자 생산성을 계속 향상시키고 있습니다.

[12:58] 흥미로운 점은 심지어 반 세대나

[13:00] 한 세대 정도 뒤처져도 실제로는 큰 차이가 난다는 것입니다.

[13:02] 최신 도구를 사용할 때와 비교해서

[13:03] 제 팀이 정말 다른 접근 방식을 취하고 있다는 걸 발견했습니다.

[13:05] 차이가 있습니다. 최신 도구를 사용하는 것과 비교해서 말이죠.

[13:07] 저는 저희 팀이 소프트웨어 엔지니어링에 대해

[13:09] 3개월 전이나 6개월 전과 비교해서도

[13:11] 완전히 다른 접근방식을 취하고 있다는 것을 발견했습니다.

[13:12] 놀라운 점 중 하나는 우리가 코드를

[13:15] 정말 가치 있는 산출물로 생각하는 데 익숙했다는 것입니다.

[13:17] 만들기가 너무 어려웠기 때문이죠.

[13:19] 하지만 소프트웨어 엔지니어링의 비용이

[13:21] 내려가면서 코드는 예전보다

[13:22] 훨씬 덜 가치 있는 산출물이 되었습니다.

[13:24] 그래서 저는 팀에서 지난 한 달 동안

[13:26] 코드베이스를 세 번이나 완전히 다시 구축했습니다.

[13:28] 왜냐하면 더 이상 그렇게 어렵지 않기 때문입니다.

[13:30] 코드베이스를 완전히 다시 구축하는 것이

[13:32] 새로운 데이터 스키마를 선택하는 것도 괜찮습니다.

[13:33] 그렇게 하는 비용이 급격히 떨어졌기 때문입니다.

[13:36] 여러분 중 일부는 제프 베조스의 용어인

[13:38] 양방향 문 대 단방향 문에 대해 들어보셨을 것입니다.

[13:39] 양방향 문은 당신이 내릴 수 있는 결정입니다.

[13:42] 마음을 바꾸면 돌아와서

[13:44] 비교적 저렴한 비용으로 되돌릴 수 있습니다.

[13:45] 반면 단방향 문은 결정을 내리고

[13:47] 마음을 바꾸는 것이 매우 비싸거나

[13:49] 되돌리기 매우 어려운 결정입니다.

[13:51] 따라서 기술 스택의 소프트웨어 아키텍처를 선택하는 것은

[13:52] 예전에는 단방향 문이었습니다.

[13:54] 특정 기술 스택 위에 구축하면

[13:56] 데이터베이스 스키마를 설정하고

[13:58] 그것을 바꾸는 것은 정말 어려웠습니다.

[13:59] 그래서 그것은 단방향 문이었습니다.

[14:01] 완전히 양방향 문이라고 말하고 싶지는 않지만

[14:03] 저는 제 팀이 더 자주

[14:05] 특정 기술 스택에서 구축하고 일주일 후에

[14:10] 마음을 바꿔서 코드베이스를 버리고

[14:12] 새로운 기술 스택에서 처음부터 다시 만드는 것을 발견했습니다.

[14:14] 과장하고 싶지는 않습니다.

[14:16] 우리가 항상 그렇게 하는 것은 아닙니다.

[14:18] 그것을 다시 하는 데는 여전히 비용이 듭니다.

[14:19] 하지만 저는 제 팀이 자주

[14:21] 무엇이 단방향 문이고 무엇이 이제 양방향 문인지

[14:23] 다시 생각하고 있다는 것을 발견했습니다.

[14:25] 소프트웨어 엔지니어링의 비용이

[14:27] 지금은 훨씬 낮기 때문입니다.

[14:28] 그리고 소프트웨어 엔지니어링을 조금 넘어서서

[14:30] 저는 지금이 모든 사람이 AI로 구축할 수 있게

[14:32] 권한을 부여하기 좋은 시기라고 생각합니다.

[14:33] 지난 한 해 동안 많은 사람들이

[14:36] AI가 자동화될 것이라는 근거로

[14:39] 코딩을 배우지 말라고 다른 사람들에게 조언했습니다.

[14:41] 저는 우리가 이것을 지금까지 주어진

[14:43] 최악의 직업 조언 중 하나로 되돌아볼 것이라고 생각합니다.

[14:45] 더 나은 도구들이 소프트웨어 엔지니어링을

[14:49] 더 쉽게 만들수록 더 많은 사람들이 그것을 해야 합니다.

[14:52] 더 적은 사람이 아니라 말이죠.

[14:54] 수십 년 전에 세계가 펀치 카드에서

[14:56] 키보드와 터미널로 이동했을 때

[14:58] 코딩이 더 쉬워졌습니다.

[15:00] 우리가 어셈블리에서 코볼 같은

[15:02] 고급 언어로 옮겨갔을 때

[15:04] 실제로 그때 사람들이 주장한 것은

[15:06] 이제 코볼이 있으니 더 이상 프로그래머가

[15:09] 필요하지 않다는 것이었습니다.

[15:10] 사람들이 실제로 그런 효과에 대한 논문을 썼지만

[15:12] 물론 그것은 틀렸고 프로그래밍 언어는

[15:14] 코딩을 더 쉽게 만들었고

[15:15] 더 많은 사람들이 코딩을 배웠습니다.

[15:19] 텍스트 편집기, IDE, AI 코딩 어시스턴트가

[15:21] 코딩을 더 쉽게 만들수록

[15:24] 더 많은 사람들이 코딩을 배워야 합니다.

[15:26] 저는 논란의 여지가 있는 의견을 가지고 있는데

[15:28] 모든 직무의 모든 사람이

[15:30] 코딩을 배울 때가 되었다고 생각합니다.

[15:32] 실제로 제 팀에서는 CFO, 인재 담당자, 리크루터,

[15:35] 프론트 데스크 직원까지 모든 직원이 코딩을 할 수 있어요.

[15:38] 그리고 저는 실제로 이들 모두가

[15:40] 코딩 능력 덕분에 각자의 업무에서

[15:42] 훨씬 더 나은 성과를 내는 것을 보고 있습니다.

[15:44] 제가 아마도 조금

[15:45] 시대를 앞서가는 것 같고,

[15:46] 대부분의 기업들은 아직 거기까지 도달하지 못했지만

[15:48] 미래에는 모든 사람이 코딩을 할 수 있도록 역량을 강화하면

[15:50] 많은 사람들이 더 생산적이 될 수 있다고 생각합니다.

[15:52] 왜 사람들이 이런 것을 배워야 하는지에 대해

[15:54] 제가 배운 한 가지 교훈을 공유하고 싶습니다.

[15:56] 제가 코세라에서 '모든 사람을 위한 생성 AI'를 가르칠 때

[15:58] 미드저니를 사용해서

[16:00] 이런 배경 아트를 생성해야 했습니다.

[16:02] 팀원 중 한 명이 미술사를 알고 있어서

[16:04] 미드저니에 장르, 팔레트,

[16:07] 예술적 영감에 대한 프롬프트를 입력해서

[16:10] 생성되는 이미지를 매우 잘 제어할 수 있었습니다.

[16:12] 그래서 결국 토미가 생성한 이미지들을

[16:15] 모두 사용하게 되었습니다.

[16:17] 반면에 저는 미술사를 몰라서

[16:19] 이미지 생성에 프롬프트를 입력할 때

[16:21] 저는 '로봇의 예쁜 그림을 만들어주세요'라고

[16:24] 입력하는 정도밖에 할 수 없었습니다.

[16:27] 제 동료가 가진 것과 같은 제어력을

[16:29] 절대 가질 수 없었죠.

[16:31] 그래서 그만큼 좋은 이미지를

[16:34] 생성할 수 없었습니다.

[16:36] 컴퓨터와 관련해서 미래의 가장 중요한 기술 중 하나는

[16:38] 컴퓨터에게 정확히 원하는 것을 말할 수 있는 능력이라고 생각합니다.

[16:40] 그러면 컴퓨터가 대신 해줄 수 있죠.

[16:43] 컴퓨터에 대한 더 깊은 이해를 가진 사람들이

[16:44] 컴퓨터를 명령해서 원하는 결과를

[16:46] 얻을 수 있을 것입니다.

[16:48] 코딩을 배우는 것은 - 직접 코드를 작성할 필요는 없지만

[16:50] AI가 대신 코딩하도록 지시하는 것 -

[16:52] 이것이 오랫동안 최고의 방법으로 남을 것 같습니다.

[16:54] 소프트웨어 엔지니어링이 훨씬 빨라지면서

[16:56] AI를 조종해서 코드를 작성하게 하는 것이

[16:57] 오랫동안 최고의 방법으로 남을 것 같습니다.

[17:00] 소프트웨어 엔지니어링이 훨씬 빨라지면서

[17:01] 제가 보고 있는 또 다른 흥미로운 역학은

[17:04] 제품 관리 업무 - 사용자 피드백을 받고 어떤 기능을 개발할지 결정하는 일 -

[17:07] 이것이 점점 더 병목이 되고 있다는 것입니다.

[17:08] 그래서 지난 한 해 동안 여러 팀에서

[17:10] 매우 흥미로운 역학을 보고 있습니다.

[17:12] 제 팀들 중 많은 곳에서

[17:14] 제품 엔지니어링과 디자인이 병목이라고

[17:17] 불평하기 시작했습니다.

[17:18] 엔지니어들이 너무 빨라졌기 때문입니다.

[17:20] 제가 보고 있는 몇 가지 흥미로운 트렌드는

[17:21] 3, 4, 5년 전 실리콘 밸리에서

[17:22] 다소 의심스러운 경험 법칙들이 있었지만

[17:24] 그럼에도 불구하고 경험 법칙으로는

[17:26] PM 1명당 엔지니어 4명 또는

[17:29] PM 1명당 엔지니어 7명 정도의

[17:31] 제품 관리자 대 엔지니어링 비율이 있었습니다.

[17:33] 이것은 한 알의 소금을 곁들여 받아들여야 하지만

[17:35] 일반적으로 PM 1명당 엔지니어 6-7명이었습니다.

[17:38] 엔지니어들이 훨씬 빨라지면서

[17:40] 무엇을 개발할지 설계하는

[17:42] 제품 관리 업무가 엔지니어들과

[17:43] 같은 속도로 빨라지는 것을 보지 못하고 있습니다.

[17:45] 이 비율이 바뀌는 것을 보고 있습니다.

[17:48] 말 그대로 어제 제 팀 중 한 곳이

[17:50] 저에게 와서 프로젝트를 위한 헤드카운트를 계획할 때

[17:52] 이 팀이 처음으로 제안한 것은

[17:54] PM 1명당 엔지니어 4명이 아니라

[17:57] PM 1명당 엔지니어 0.5명을 두자는 것이었습니다.

[17:59] 내 인생에서 처음으로

[18:01] 이것이 좋은 아이디어인지 확신이 서지 않습니다.

[18:03] 하지만 그들이 실제로 저에게 제안했습니다.

[18:06] PM 1명당 엔지니어 0.5명을 두자고 말이죠.

[18:09] 엔지니어들이요. 팀에서 실제로 제안한 내용은

[18:10] 저에게 아직도 이게 좋은 아이디어인지 모르겠지만

[18:12] 제 인생에서 처음으로 본 것은

[18:13] 매니저들이 저에게 제안한 것이

[18:16] 엔지니어 수의 두 배만큼 PM을 두자는 것이었어요

[18:18] 정말 흥미로운 역학관계였죠. 저는

[18:20] 아직도 이 제안이

[18:21] 좋은 아이디어인지 모르겠지만

[18:22] 세상이 어디로 가고 있는지 보여주는 신호라고 생각해요

[18:25] 그리고 코딩할 수 있는 PM이나

[18:27] 제품 감각이 있는 엔지니어들이

[18:29] 종종 더 나은 성과를 내는 것 같아요. 또 다른

[18:31] 스타트업에서 중요하다고 생각하는 것은

[18:32] 스타트업 리더들에게 중요한 것은

[18:34] 엔지니어링이 너무 빠르게 발전하고 있기 때문에

[18:36] 신속한 피드백을 얻는 좋은 전술이 있다면

[18:38] 무엇을 만들어야 할지에 대한 관점을 형성하는 데

[18:40] 더 빠르게 도움이 되고, 그것이 여러분을 더 빠르게 만들어줍니다

[18:43] 그래서 제가 여러분에게 소개할 것은

[18:45] 전술들의 포트폴리오입니다

[18:47] 제품 피드백을 얻어서 계속해서 형성해나가는

[18:49] 무엇을 만들지 결정하는 것들이죠. 그리고 우리는

[18:51] 목록을 살펴볼 건데, 더 빠르고

[18:54] 정확도가 떨어지는 것부터 더 느리고

[18:55] 더 정확한 전술까지 말이에요. 가장 빠른 전술은

[18:59] 피드백을 얻는 것은 제품을 직접 보고

[19:00] 그냥 직감에 의존하는 것입니다

[19:02] 그리고 만약 여러분이 해당 분야의 전문가라면

[19:04] 이것은 사실 놀랍도록 좋은 방법이에요

[19:06] 여러분이 무엇을 하고 있는지 안다면요

[19:08] 조금 더 느린 방법은 세 명의

[19:10] 친구나 팀원에게 피드백을 요청하는 것이에요

[19:13] 제품을 사용해보고 피드백을 받는 거죠

[19:15] 조금 더 느린 방법은 3명에서 10명의

[19:17] 모르는 사람들에게 피드백을 요청하는 것이에요

[19:20] 제가 제품을 만들 때 알게 된 것은

[19:22] 제가 배운 가장 중요한 기술 중 하나가

[19:23] 커피숍에 앉아 있는 방법이었어요

[19:25] 여행할 때, 제가 여행하면

[19:27] 호텔 로비에 앉아 있곤 해요

[19:29] 사람들이 많이 지나다니는 곳을 찾는 법을 배우고

[19:31] 아주 정중하게 모르는 사람들에게 다가가서

[19:33] 제가 만들고 있는 것에 대해

[19:35] 피드백을 요청하는 거예요

[19:37] 제가 덜 알려져 있을 때는 이게 더 쉬웠어요

[19:38] 사람들이 여러분을 알아보면

[19:40] 조금 더 어색해지죠

[19:42] 저는 실제로 팀과 함께 호텔 로비에 앉아서

[19:44] 사람들이 많이 지나다니는 곳에서

[19:46] 아주 정중하게 모르는 사람들에게

[19:48] "저희가 이런 것을 만들고 있는데

[19:50] 한 번 봐주실 수 있을까요?"라고 물어보고

[19:51] 실제로 커피숍에서 배운 것은

[19:53] 일하고 있는 사람들이 많고

[19:55] 일하기 싫어하는 사람들도 많아서

[19:57] 우리가 그들에게 산만해질 핑계를 주면

[19:59] 그들도 기꺼이 그렇게 해준다는 것이에요

[20:01] 하지만 저는 실제로 수많은 제품 결정을

[20:03] 호텔 로비나 커피숍에서

[20:05] 협력자들과 함께 내려왔어요

[20:07] 그냥 그런 식으로요. 100명의 테스터에게

[20:09] 프로토타입을 보내거나, 만약 여러분이

[20:11] 논리적인 사용자 그룹에 접근할 수 있다면

[20:13] 더 많은 사용자들에게 프로토타입을 보내고

[20:16] 이런 것들은 점점 더 느려지는 전술들이에요

[20:18] 그리고 실리콘밸리에서 우리는

[20:19] A/B 테스트에 대해 이야기하기를 좋아하죠

[20:21] 물론 저도 A/B 테스트를 많이 하지만

[20:24] 많은 사람들이 생각하는 것과 달리

[20:26] A/B 테스트는 제 메뉴에서 가장 느린 전술 중 하나예요

[20:28] 그냥 배포하는 것이 느리거든요

[20:30] 여러분이 얼마나 많은 사용자를 가지고 있는지에 따라 달라지죠

[20:32] 그리고 또 다른 것은

[20:35] 하지만 첫 번째 전략 외에도 일부 팀들은

[20:37] 데이터를 보고 결정을 내리지만

[20:39] 빠진 부분이 있습니다. 제가 A/B 테스트를 할 때

[20:42] A/B 테스트 결과를 단순히 제품 A나

[20:46] 제품 B를 선택하는 데만 사용하지 않습니다.

[20:48] 저희 팀은 종종 앉아서

[20:50] 데이터를 세심하게 분석해 직관을 연마하고

[20:52] 속도를 높이고 첫 번째 전략을 사용해

[20:54] 고품질 결정을 내릴 수 있는 비율을 향상시킵니다.

[20:56] 종종 앉아서 생각해봅니다. '아, 난 생각했는데'

[20:58] 이 제품명이 저 제품명보다

[21:00] 더 잘 작동할 거라고 생각했는데

[21:01] 분명히 사용자에 대한 제 정신 모델이

[21:03] 틀렸구나.' 정말로 앉아서 생각하고

[21:05] 모든 데이터를 사용해 정신 모델을 업데이트하여

[21:07] 제품 결정을 더 빠르게 내릴 수 있는

[21:10] 직감의 품질을 향상시킵니다.

[21:13] 이것이 정말 중요하다는 것이 밝혀졌습니다.

[21:15] 좋습니다. 구체적인 아이디어들에 대해 말씀드렸는데

[21:16] 엔지니어링 속도 향상, 제품 피드백 속도 향상에 대해 말이죠.

[21:20] 마지막으로 다루고 싶은 한 가지는

[21:22] AI를 이해하는 것이 실제로

[21:23] 속도를 높여준다는 것을 봤다는 점입니다.

[21:25] 그리고 이유는 다음과 같습니다.

[21:27] AI 전문가로서 저는 AI를 편향적으로 지지할 수 있지만

[21:29] 왜 그런지 여러분과 공유하고 싶습니다.

[21:31] 모바일 같은 성숙한 기술의 경우

[21:33] 많은 사람들이 오랫동안 스마트폰을 사용해왔습니다.

[21:34] 우리는 모바일 앱이 무엇을 할 수 있는지 어느 정도 알고 있죠.

[21:37] 비기술적인 사람들을 포함해 많은 사람들이

[21:39] 모바일 앱이 무엇을 할 수 있는지에 대한

[21:40] 좋은 직감을 가지고 있습니다.

[21:42] 영업, 마케팅, HR, 법무 같은

[21:44] 성숙한 직무를 살펴보면

[21:45] 모두 정말 중요하고 정말 어렵습니다.

[21:47] 하지만 충분히 오랫동안 마케팅을 해온

[21:49] 마케터들이 충분히 많고

[21:50] 마케팅 전술이 작년에 그리 많이 바뀌지 않았기 때문에

[21:52] 마케팅에 정말 뛰어난 사람들이 많습니다.

[21:55] 정말 중요하고 정말 어렵지만

[21:56] 그 지식이 상대적으로 널리 퍼져있습니다.

[21:58] HR을 어떻게 하는지에 대한 지식은

[22:00] 극적으로 바뀌지 않았기 때문입니다.

[22:02] 지난 6개월 동안 말이죠.

[22:03] 하지만 AI는 신흥 기술이고

[22:05] 따라서 AI를 정말 잘하는 방법에 대한 지식이

[22:07] 널리 퍼져있지 않습니다.

[22:09] 그래서 AI를 실제로 이해하는 팀들은

[22:11] 그렇지 않은 팀들에 비해 우위를 가지고 있습니다.

[22:13] 반면 HR 문제가 있다면

[22:16] 그것을 잘 아는 사람을 찾을 수 있을 것입니다.

[22:18] 하지만 AI 문제라면

[22:20] 실제로 그것을 어떻게 해야 하는지 아는 것이

[22:23] 다른 회사들보다 앞서갈 수 있게 해줄 수 있습니다.

[22:25] 고객 서비스 챗봇에서 어떤 정확도를 얻을 수 있는지

[22:26] 프롬프트 엔지니어링을 해야 하는지

[22:28] 파인튜닝을 해야 하는지, 워크플로우는 어떻게 해야 하는지

[22:30] 음성 출력을 낮은 지연시간으로 어떻게 만들지

[22:32] 이런 많은 결정들이 있는데

[22:34] 올바른 기술적 결정을 내리면

[22:36] 며칠 안에 문제를 해결할 수 있습니다.

[22:37] 잘못된 기술적 결정을 내리면

[22:39] 3개월 동안 막다른 길을 쫓을 수 있습니다.

[22:41] 그리고 제가 놀란 한 가지는

[22:42] 두 가지 가능한 아키텍처 결정이 있다면

[22:45] 그것은 1비트의 정보라는 것입니다.

[22:47] 잘못된 기술적 결정을 내리면

[22:48] 3개월 동안 막다른 길을 쫓을 수 있습니다.

[22:50] 그리고 제가 놀란 한 가지는

[22:52] 두 가지 가능한 아키텍처 결정이 있다면

[22:54] 그것은 1비트의 정보라는 것입니다.

[22:56] 두 가지 가능한 아키텍처 결정이 있다면

[22:58] 그것은 1비트의 정보입니다.

[23:00] 만약 정답을 모른다면

[23:02] 기껏해야 두 배 정도 느려질 뿐입니다

[23:03] 맞죠? 1비트니까 둘 다 해보면 되죠

[23:05] 1비트 정보가 있으면

[23:06] 기껏해야 2배 속도 향상을 얻을 수 있다고 느껴집니다

[23:08] 이론적으로는 어느 정도 맞는 말이겠죠

[23:11] 하지만 실제로 제가 본 것은

[23:13] 잘못된 비트를 선택하면

[23:15] 두 배 느려지는 게 아니라

[23:17] 막다른 길을 쫓느라

[23:19] 10배나 더 오래 걸린다는 것입니다

[23:21] 이것이 바로 올바른 기술적 판단력을 가지고 들어가는 것이

[23:23] 스타트업을 훨씬 빠르게 만드는 이유입니다

[23:26] AI 최신 동향을 파악하는 것이 스타트업에 도움이 되는 또 다른 이유는

[23:29] 지난 2년간 우리에게는

[23:32] 정말 많은 훌륭한 생성형 AI 도구들이나

[23:36] 생성형 AI 구성 요소들이 생겼기 때문입니다

[23:39] 일부 목록을 보면

[23:42] 프롬프팅 워크플로우, 평가, 가드레일

[23:45] RAG, 음성, 비동기 프로그래밍, 많은

[23:47] ETL 임베딩, 파인튜닝, 그래프 DB

[23:49] 모델 통합 방법 등등

[23:52] 빠르게 결합하여 소프트웨어를 구축할 수 있는

[23:54] 길고 훌륭한 구성 요소들의 목록이 있습니다

[23:56] 이 지구상 누구도 구축할 수 없었던 소프트웨어를

[23:58] 불과 1년 전만 해도 말이죠

[24:00] 이것은 스타트업들이 새로운 것을 구축할 수 있는

[24:02] 많은 새로운 기회를 만들어냅니다

[24:04] 제가 이런 구성 요소들에 대해 배웠을 때

[24:06] 실제로 머릿속에 그려지는 그림이 있습니다

[24:07] 하나의 구성 요소를 가지고 있다면, 기본적인 흰색 구성 요소 하나처럼

[24:12] 멋진 것들을 만들 수 있습니다

[24:14] 프롬프팅 방법을 안다면

[24:16] 구성 요소 하나로

[24:17] 놀라운 것을 만들 수 있습니다

[24:19] 하지만 두 번째 구성 요소를 얻는다면

[24:21] 챗봇 구축 방법도 안다면

[24:23] 흰색 레고 블록과 검은색 레고 블록이 있으면

[24:25] 더 흥미로운 것을 만들 수 있습니다

[24:27] 파란색 구성 요소도 얻는다면

[24:29] 더욱 흥미로운 것을 만들 수 있습니다

[24:31] 빨간색 구성 요소 몇 개를 얻고

[24:33] 노란색 작은 것까지 얻으면 더 흥미로워집니다

[24:36] 더 많은 구성 요소를 얻고, 더 많은 구성 요소를 얻으면

[24:38] 더 많은 구성 요소를 얻고, 더 많은 구성 요소를 얻으면

[24:40] 매우 빠르게 이들을 결합하여 만들 수 있는 것들의 수가

[24:43] 조합론적으로 또는

[24:45] 기하급수적으로 증가합니다

[24:48] 따라서 이 모든 훌륭한 구성 요소들을 아는 것은

[24:50] 훨씬 더 풍부한 조합으로 결합할 수 있게 해줍니다

[24:52] Deep Learn이 하는 일 중 하나는

[24:54] 실제로 저도 많은 Deep Learn 코스를 수강합니다

[24:56] 왜냐하면 우리는 함께 일하기 때문입니다

[24:57] 제 생각에는 거의 모든

[24:59] 세계 주요 AI 회사들과 함께 일하고 있고

[25:01] 구성 요소들을 배포하려고 노력합니다

[25:03] 하지만 Deep Learning 코스 카탈로그를 보면

[25:06] 실제로 이런 것들을 봅니다

[25:09] 이런 구성 요소들을 배우기 위해

[25:11] 이 코스들을 수강할 때마다

[25:13] 새로운 것들을 얻고 있다고 느낍니다

[25:15] 조합론적으로 또는

[25:16] 기하급수적으로 더 많은 소프트웨어 애플리케이션을 형성할 수 있는

[25:19] 1-2년 전만 해도 불가능했던 것들을 만들 수 있습니다

[25:21] 자, 정리하자면, 이것이 제 마지막 슬라이드입니다

[25:23] 만약 여러분이 질문이 있으시다면

[25:25] 질문을 받고 싶습니다

[25:27] 제가 발견한 것은

[25:28] 스타트업에 중요한 것들이 많다는 것입니다

[25:31] 속도만이 아니라 말이죠

[25:33] 하지만 AI Fund가 투자하는 스타트업들을 보면

[25:35] 건설 중인 스타트업들을 보면

[25:38] 구축하는 회사들을 보면, 경영진의

[25:40] 빠른 실행 능력이

[25:42] 성공 확률과 매우 높은

[25:44] 상관관계를 보입니다. 그리고 속도를

[25:47] 얻기 위해 우리가 배운 것들 중 하나는

[25:49] 구체적인 아이디어에 집중하는 것입니다.

[25:51] 물론 좋은 구체적인 아이디어여야 합니다.

[25:53] 임원으로서 저는 의사결정의

[25:55] 속도와 품질로 평가받는다고 생각합니다.

[25:57] 둘 다 중요하지만, 속도는 절대적으로 중요합니다.

[26:00] AI 코딩 지원을 통한 빠른 프로토타이핑은

[26:02] 훨씬 빠르게 작업할 수 있게 해주지만

[26:04] 병목현상을 제품 결정에 대한

[26:06] 사용자 피드백을 받는 것으로 이동시킵니다.

[26:08] 그래서 빠른 피드백을 얻기 위한

[26:10] 다양한 전술들을 보유하는 것이 중요하고

[26:12] 커피숍에 가서 모르는 사람들과

[26:14] 대화하는 법을 배우지 않았다면

[26:17] 쉽지 않습니다. 하지만 그냥 존중하면 됩니다.

[26:18] 사람들을 존중하는 것, 그것이 실제로

[26:20] 기업가들이 갖춰야 할 매우 가치 있는

[26:22] 기술이라고 생각합니다. 그리고 또한

[26:24] 기술을 따라잡는 것이 속도를 제공한다고

[26:27] 생각합니다. 그럼 이제 정말

[26:30] 감사합니다.

[26:34] [박수]

[26:40] 질문을 받겠습니다.

[26:41] AI가 발전하면서, 인간이 도구를 개발하는 것과

[26:44] 도구를 더 잘 사용하는 법을 배우는 것 중

[26:47] 어느 것이 더 중요하다고 생각하세요?

[26:50] 지능이 민주화되고 있는 세상에서

[26:52] 어떻게 하면 우리가 여전히 필수적인

[26:55] 존재로 남을 수 있을까요?

[26:57] AGI가 과대평가되었다고 생각하고

[27:01] 오랫동안 인간이 할 수 있지만

[27:04] AI가 할 수 없는 일들이

[27:05] 많이 있을 것이라고 생각합니다. 미래에

[27:08] 가장 강력한 사람들은 컴퓨터가

[27:10] 정확히 원하는 것을 하도록 만들 수 있는

[27:13] 사람들이라고 생각합니다. 그래서

[27:16] 도구를 따라잡는 것이 중요하다고 생각합니다.

[27:18] 우리 중 일부는 도구를 만들 수도 있지만

[27:19] 다른 사람들이 만든 많은 도구들이

[27:21] 있어서 우리는 그냥 사용할 수 있습니다.

[27:23] AI를 사용해서 컴퓨터가 원하는 것을

[27:25] 하도록 만드는 방법을 아는 사람들이

[27:27] 훨씬 더 강력해질 것입니다. 사람들이

[27:28] 할 일이 없어질 것을 걱정하지 마세요.

[27:30] 하지만 AI를 사용할 수 있는 사람들이

[27:32] 그렇지 않은 사람들보다 훨씬 더

[27:33] 강력해질 것입니다.

[27:34] 안녕하세요. 먼저 정말 감사합니다.

[27:36] 당신을 매우 존경하고 있고

[27:38] 우리 많은 사람들에게 진정한

[27:40] 영감을 주는 분이라고 생각합니다.

[27:42] 제 질문은 컴퓨팅의 미래에 관한 것입니다.

[27:45] 더 강력한 AI로 나아가면서

[27:49] 컴퓨팅이 어디로 향하고 있다고

[27:51] 생각하세요? 사람들이 GPU를

[27:53] 우주로 보내자고 말하는 것을 보고

[27:56] 어떤 사람들은 핵 발전소 데이터

[27:58] 센터에 대해 이야기하고 있습니다.

[27:59] 이에 대해 어떻게 생각하세요?

[28:00] 이전 질문에 대한 답변으로

[28:01] 무엇을 말하고 싶은지 고민하고 있는

[28:03] 것이 있었는데, AGI에 대해서

[28:05] 조금 답변해보겠습니다. 이전 질문도

[28:07] 함께 말이죠. 실제로 무엇이 과대광고이고

[28:10] 무엇이 과대광고가 아닌지 결정하는

[28:11] 프레임워크가 하나 있습니다.

[28:14] 지난 2년 동안 몇몇 기업들이

[28:17] 홍보, PR, 펀드레이징, 영향력 목적으로

[28:20] 특정 것들을 과대광고했다고 생각합니다.

[28:24] AI가 너무 새로운 분야였기 때문에

[28:27] 몇몇 기업들은 거의 모든 것을

[28:29] 아무도 사실 확인을 하지 않았습니다

[28:31] 기술이 제대로 이해되지 않았기 때문입니다

[28:33] 그래서 제가 사용하는 판단 기준 중 하나는

[28:36] 기업들을 더 강력해 보이게 만드는

[28:38] 특정 과장된 이야기들이 있다는 것입니다

[28:40] 그런 이야기들이 증폭되어 왔습니다

[28:42] 예를 들어, AI가 너무 강력해서

[28:45] 실수로 인류 멸종을 초래할 수 있다는

[28:48] 생각은 정말 말도 안 됩니다

[28:50] 하지만 이것은 특정 기업들을

[28:53] 더 강력해 보이게 만드는 과장된 이야기이고

[28:54] 확산되어 실제로 특정 기업들의

[28:56] 자금 조달 목표를 도왔습니다

[28:58] AI가 너무 강력해서 곧 아무도

[29:01] 일자리를 갖지 못할 것이라는 말도

[29:02] 사실이 아닙니다

[29:05] 하지만 다시 말하지만 이것도 기업들을

[29:06] 더 강력해 보이게 만들어 과장되었습니다

[29:09] 또는 우리가 너무 강력해서

[29:12] 새로운 모델을 훈련시키는 것만으로

[29:15] 수천 개의 스타트업을 쉽게

[29:16] 없애버릴 수 있다는 과장된 이야기도

[29:18] 사실이 아닙니다

[29:21] 네, Jasper는 문제가 있었습니다

[29:23] 소수의 회사들이 없어졌습니다

[29:25] 하지만 수천 개의 스타트업을 쉽게

[29:28] 없애는 것은 그렇게 쉽지 않습니다

[29:30] AI는 너무 많은 전력이 필요해서

[29:31] 핵발전만이 충분하다는 말도

[29:33] 풍력이나 태양광 같은 것들은

[29:36] 충분하지 않다는 말도 사실이 아닙니다

[29:39] 그래서 이런 것들의 대부분이

[29:42] 우주의 GPU라든지, 모르겠습니다

[29:44] 도전해보세요. 지상의 GPU로도

[29:46] 아직 할 일이 많다고 생각합니다

[29:49] 네, 하지만 이런 과장된 이야기들 중 일부는

[29:51] 증폭되어 왔고, 실제로 일어날 일을

[29:53] 왜곡하고 있다고 생각합니다

[29:54] AI에는 많은 과장이 있고

[29:58] 실제로 우리가 어떻게

[30:00] 미래를 구축해 나갈지에 대해

[30:01] 아무도 확실하지 않습니다

[30:03] 하지만 가장 위험한 편향이나

[30:07] 과장된 이야기들 중에서

[30:10] 사람들이 이야기하거나

[30:13] 독에 빠져서 결국 따라가게 되는

[30:16] 것들 중에서 우리가 피하려 하거나

[30:18] 더 인식하고 있어야 할 것들이

[30:22] 미래를 구축할 때 더 현실적인

[30:23] 시각을 갖게 해줄 것들은 무엇인가요?

[30:25] 위험한 AI 이야기가

[30:27] 과장되었다고 생각합니다

[30:31] AI는 훌륭한 도구지만, 전기와 같은

[30:33] 다른 강력한 도구들처럼

[30:35] 유익한 목적으로 사용할 수 있는

[30:37] 많은 방법이 있습니다. 또한 해로운

[30:41] 방식으로 사용할 수 있는 방법들도 있습니다

[30:42] 저는 AI 안전성이라는 용어를

[30:44] 그다지 많이 사용하지 않습니다

[30:46] 위험한 것들을 만들어야 한다고

[30:48] 생각하기 때문이 아니라

[30:50] 안전성은 기술의 기능이 아니라

[30:53] 우리가 그것을 어떻게 적용하느냐의

[30:55] 기능이라고 생각하기 때문입니다

[30:57] 전기 모터처럼 말입니다

[30:59] 전기 모터 제조업체는 아무도

[31:02] 안전하지 않은 하류 작업에

[31:04] 사용하지 않을 것이라고 보장할 수 없습니다

[31:06] 전기 모터는 달라스 기계나

[31:08] 전기 자동차를 만드는 데 사용될 수 있지만

[31:10] 스마트 폭탄을 만드는 데도 사용될 수 있습니다

[31:13] 하지만 전기 모터 제조업체는

[31:15] 하류에서 어떻게 사용될지 통제할 수 없습니다

[31:17] AI를 적용하는 방식이 안전하거나 안전하지 않게 만드는 것입니다.

[31:19] 그래서 AI 안전성에 대해 생각하는 대신,

[31:21] 저는 종종 책임감 있는 AI에 대해 생각합니다.

[31:23] 왜냐하면 우리가 그것을 책임감 있게 사용하는 방식이

[31:26] 또는 무책임하게 사용하는 방식이

[31:28] 우리가 AI 기술로 구축하는 것이

[31:30] 해롭거나 유익한 결과를 낳는지를 결정하기 때문입니다.

[31:32] 그리고 때로는 뉴스에서 과장되는

[31:34] 정말 이상한 극단적인 사례들이

[31:36] 있다고 생각합니다. 제 생각에는

[31:38] 하루나 이틀 전에 월스트리트 저널에

[31:40] AI가 통제를 잃거나 뭔가에 관한 기사가 있었습니다.

[31:43] 그리고 그 기사가 실험실에서 진행된

[31:45] 극단적인 사례 실험을 가져와서

[31:49] 실제로 진행된 실험실 실험에 비해

[31:51] 정말 불균형적인 방식으로

[31:53] 선정적으로 만들었다고 생각합니다.

[31:55] 그리고 진행된 실험실 실험에 비해

[31:57] 안타깝게도 기술은 이해하기 어렵습니다.

[31:59] 많은 사람들이 더 잘 알지 못하기 때문에

[32:01] 이런 과장된 이야기들이

[32:03] 계속해서 증폭되고 있습니다.

[32:06] 그리고 이것이 오픈 소스 소프트웨어에 대한

[32:07] 무기로 사용되고 있다고 생각합니다.

[32:09] 이는 정말 불행한 일입니다.

[32:11] 당신의 노력에 감사드립니다. 당신의

[32:13] 영향력은 정말 놀랍습니다. 제 질문은

[32:17] 예비 창업자로서 하루 만에

[32:20] 모든 것이 파괴될 수 있는 세상에서

[32:23] 비즈니스를 어떻게 생각해야 할지입니다.

[32:25] 당신이 가진 훌륭한 모드나 제품, 기능이

[32:28] VIP 코드로 복제될 수 있고

[32:30] 경쟁사들이 기본적으로

[32:33] 몇 시간 안에 만들 수 있습니다.

[32:34] 사업을 시작할 때 걱정해야 할

[32:36] 일들이 많다는 것이 밝혀졌습니다.

[32:37] 제가 걱정하는 가장 중요한 것은

[32:41] 사용자들이 사랑하는 제품을 만들고 있는가입니다.

[32:43] 사업을 구축할 때 고려해야 할

[32:46] 많은 것들이 있다는 것이 밝혀졌습니다.

[32:47] 시장 진출 채널, 경쟁사, 기술 모드 등

[32:49] 모든 것이 중요하지만 제가

[32:51] 한 가지에 집중한다면 그것은

[32:53] 사용자들이 정말 원하는 제품을

[32:56] 만들고 있는가입니다. 그것을 해결하기 전까지는

[32:58] 가치 있는 비즈니스를 구축하기가

[33:00] 매우 어렵습니다.

[33:02] 그것을 해결한 후에 다른 질문들이

[33:05] 작용하게 됩니다. 고객에게 도달할

[33:07] 채널이 있는가? 장기적인 가격 정책은?

[33:09] 당신의 해자는 무엇인가?

[33:11] 해자는 과장되는 경향이 있다고 생각합니다.

[33:14] 실제로 더 많은 비즈니스가

[33:16] 제품으로 시작해서

[33:18] 결국 해자로 발전한다고 생각합니다.

[33:21] 소비자 제품 브랜드는 다소 더

[33:24] 방어 가능합니다. 그리고 많은

[33:26] 추진력이 있다면 당신을

[33:28] 따라잡기가 더 어려워집니다.

[33:30] 하지만 엔터프라이즈 제품의 경우

[33:33] 엔터프라이즈에 진입하기 어려운

[33:35] 채널들이 있다면 해자가 더

[33:37] 고려 대상이 될 수 있습니다. 그래서

[33:40] AI 펀드가 비즈니스를 볼 때

[33:43] 실제로 우리는 이런 요소들에 대한

[33:45] 상당히 복잡한 분석을 하고

[33:47] 2페이지에서 6페이지 정도의 설명 메모를

[33:49] 작성해서 진행할지 여부를

[33:51] 결정하기 전에 분석합니다.

[33:55] 이 모든 것들이 중요하지만

[33:57] 지금 이 시점에서 기회의 수,

[34:00] 즉 아무도 만들지 않은 가능한

[34:01] 것들의 양이 상당하다고 생각합니다.

[34:04] 아직 세상에 만들어지지 않은 것들이 많은데, 이는

[34:06] 그것들을 만들 수 있는 기술을 가진 사람들보다

[34:08] 훨씬 많다는 것 같습니다. 따라서 확실히

[34:10] 애플리케이션 레이어에서는

[34:12] 아직 아무도 작업하지 않은

[34:14] 새로운 것들을 만들 수 있는

[34:16] 여백이 많다고 느껴집니다. 그리고 저는

[34:19] 사람들이 원하는 제품을 만드는 데

[34:20] 집중하라고 말하고 싶습니다. 사람들이 사랑하는 제품을요.

[34:23] 그리고 나머지는 과정에서

[34:25] 해결해 나가면 됩니다. 물론 이런 중요한 것들을

[34:27] 과정에서 해결해야 하죠.

[34:28] 안녕하세요, 교수님. 훌륭한 강연에

[34:30] 감사드립니다. 저는 스탠포드의

[34:32] 박사과정 연구원입니다.

[34:34] 강연에서 사용하신 비유가 매우 흥미롭다고 생각합니다.

[34:37] 현재 AI 도구들이 벽돌과 같고

[34:39] 축적을 통해 구축될 수 있다고 말씀하셨는데,

[34:42] 그러나 지금까지는

[34:44] AI 도구들 통합의 누적적

[34:47] 기능 확장을 보기 어려운데,

[34:49] 이는 종종 의도 분산에 기반한

[34:51] 기능 스택에 의존하고

[34:53] 토큰과 시간 오버헤드의

[34:55] 동적 문제를 동반하기 때문입니다.

[34:59] 이는 정적 엔지니어링과는

[35:01] 다른 점인데, 향후 에이전트 간

[35:04] 누적 효과의 가능성에 대해

[35:06] 어떻게 생각하시는지

[35:08] 궁금합니다. 그런데 잠깐,

[35:10] 그에 대해 몇 가지 간단한 말씀을 드리자면,

[35:13] 방금 에이전트 LLM 토큰

[35:15] 비용에 대해 언급하셨는데,

[35:17] 개발자들에게 가장 흔히 드리는 조언은

[35:21] 일단 토큰 비용에 대해서는

[35:23] 걱정하지 말라는 것입니다.

[35:25] 소수의 스타트업만이

[35:27] 사용자들이 제품을 너무 많이 사용해서

[35:30] 토큰 비용이 문제가 되는

[35:32] 행복한 상황에 처하게 됩니다.

[35:34] 문제가 될 수는 있습니다. 저도

[35:36] 여러 팀에서 사용자들이

[35:37] 우리 제품을 좋아해서

[35:39] 생성 AI 요금을 보니

[35:42] 정말 문제가 될 정도로

[35:44] 급증하는 경험을 했습니다.

[35:46] 하지만 실제로는

[35:48] 토큰 사용 비용이 문제가 되는

[35:50] 지점에 도달하기가 정말 어렵습니다.

[35:52] 그리고 제가 참여한 팀들에서

[35:55] 사용자들이 토큰 비용을 문제로 만들 만큼

[35:57] 운이 좋았던 경우, 종종

[36:00] 엔지니어링 솔루션을 통해

[36:01] 곡선을 굽혀서 다시 비용을 줄일 수 있었습니다.

[36:03] 프롬프팅이나 파인튜닝, 증류 등의

[36:06] 최적화 방법을 통해서 말이죠.

[36:08] 그리고 제가 보고 있는 것은

[36:10] 실제로 여러 다른 단계들을

[36:12] 통합하는 에이전트 워크플로우들입니다.

[36:14] 예를 들어, 고객 서비스 챗봇을 만들 때,

[36:16] 프롬프팅을 사용하고,

[36:18] 결과를 증류를 통해 최적화하고,

[36:20] 평가 시스템을 구축하고, 가드레일을 만들고,

[36:22] 고객 서비스 챗봇이 정보를 얻기 위해

[36:23] RAG 기능이 필요할 수도 있습니다.

[36:25] 사용자에게 피드백을 제공하기 위해서요.

[36:28] 그래서 실제로 이런 것들이

[36:31] 성장하는 것을 보고 있습니다.

[36:34] 하지만 여러분을 위한 한 가지 팁은

[36:35] 저는 종종 서로 다른 빌딩 블록

[36:38] 제공업체들 간의 전환을

[36:40] 비교적 쉽게 만들도록 소프트웨어를 설계합니다.

[36:43] 예를 들어, LLM 위에 구축된

[36:45] 어떤 LLM을 사용하는지 물어보시는데, 솔직히 저도 모릅니다. 왜냐하면 저희는 평가 시스템을 구축해놨거든요.

[36:47] 새로운 모델이 출시되면 빠르게 평가를 돌려서

[36:50] 새 모델이 기존 모델보다 나은지 확인합니다.

[36:52] 그리고 새 모델의 평가 결과가 더 좋으면 바로 새 모델로 전환하죠.

[36:56] 그래서 저희가 매주 사용하는 모델은 계속 변해요.

[36:59] 가끔은 엔지니어들이 저한테 알리지도 않고

[37:02] 모델을 바꾸기도 합니다. 평가 결과가 더 나은 모델이 나오면 말이죠.

[37:05] 결국 파운데이션 모델의 전환 비용이 상당히 낮다는 것을 발견했어요.

[37:09] 그래서 저희는 소프트웨어 아키텍처를 그렇게 설계했습니다.

[37:12] AI Suite도 오픈소스화했는데, 제가 동료들과 함께 작업한 것으로

[37:14] 모델 전환을 더 쉽게 만들어 줍니다.

[37:18] 오케스트레이션 플랫폼의 전환 비용은 조금 더 어렵긴 하지만

[37:22] 빌딩 블록 선택에서 유연성을 유지하면

[37:25] 서로 다른 것들을 계속 쌓아 올리면서도

[37:29] 더 빠르게 개발할 수 있다는 것을 발견했어요.

[37:31] 도움이 되었길 바랍니다.

[37:33] 정말 감사합니다.

[37:34] 교육 분야의 AI 세계에는 주로 두 가지 패러다임이 있습니다.

[37:37] 하나는 AI가 교사들을 더 생산적으로 만들 수 있다는 것입니다.

[37:39] 채점 자동화와 숙제 자동화 같은 것들 말이죠.

[37:42] 하지만 또 다른 학파는

[37:44] 모든 학생이 개인 튜터를 갖게 될 것이라고 봅니다.

[37:46] 모든 학생이 AI로부터 피드백을 받고

[37:48] 개인 맞춤형 질문을 받는 튜터를 가질 수 있다는 거죠.

[37:51] 이 두 패러다임이 어떻게 융합될지,

[37:53] 그리고 향후 5년 동안 교육이

[37:54] 어떤 모습일지 어떻게 보시나요?

[37:57] 모든 사람이 에듀테크에 변화가 오고 있다고 느끼지만

[37:59] 아직 파괴적 혁신이 일어나지는 않았다고 봅니다.

[38:00] 많은 사람들이 다양한 것들을 실험하고 있다고 생각해요.

[38:02] 코세라에는 코세라 코치가 있는데

[38:03] 실제로 정말 잘 작동합니다.

[38:06] 딥러닝.ai는 AI 교육에 더 집중하고 있고

[38:08] 내장된 챗봇도 있어요.

[38:10] 많은 팀들이 자동채점을 실험하고 있죠.

[38:12] 딥러닝.ai 웹사이트에는 저와 닮은 아바타가 있어서

[38:14] 대화하고 싶으시면 대화할 수 있습니다.

[38:18] 딥러닝.ai에서요.

[38:19] 그리고 언어 학습 같은 특정 영역에서는 듀오링고 같은 서비스가

[38:23] AI가 어떻게 변화시킬지가 더 명확해졌어요.

[38:25] 하지만 더 넓은 교육 분야에서

[38:28] AI가 정확히 어떻게 변화시킬지는

[38:30] 아직 많은 실험이 진행되고 있다고 봅니다.

[38:32] 제가 일부 작업을 하고 있는 칸 아카데미가 하고 있는 것이

[38:35] K-12 교육에 매우 유망하다고 생각하지만

[38:37] 제가 보기에는 솔직히 엄청난 실험이 진행되고 있지만

[38:42] 최종 결과물이 무엇인지는 아직 명확하지 않습니다.

[38:44] 교육이 초개인화될 것이라고 생각하지만

[38:47] 그 워크플로우가 아바타인지, 텍스트 챗봇인지

[38:49] 어떤 워크플로우인지는 아직 확실하지 않아요.

[38:54] 몇 년 전 AGI가 곧 나올 것이고

[38:57] 모든 것이 쉬워질 것이라는 과장된 기대가 있었습니다.

[38:58] 그것은 과장이었어요.

[39:00] 현실은 업무가 복잡하다는 것입니다.

[39:03] 교사, 학생, 사람들은 정말 복잡한 워크플로우를 가지고 있어요.

[39:07] 앞으로 10년 동안 우리는 수행해야 할 작업을 살펴보고

[39:09] 그것을 어떻게 에이전트 AI 워크플로우에 매핑할지 알아낼 것입니다.

[39:17] 에이전트 워크플로우와 교육은 이러한 매핑이

[39:20] 아직 진행 중인 분야 중 하나입니다만

[39:22] 아직 충분히 성숙하지 않아서

[39:25] 최종 단계가 명확하지 않은 상태입니다.

[39:27] 그래서 우리 모두 계속 노력해야 한다고 생각합니다.

[39:29] 네, 계속 노력해야죠.

[39:31] 좋습니다. 좋습니다. 정말 감사합니다

[39:32] 앤드류 박사님.

[39:32] 감사합니다. 안녕하세요, 제 질문은

[39:35] AI가 많은 긍정적인 잠재력을 가지고 있지만

[39:37] 또한 많은 부정적인 결과에 대한

[39:38] 잠재력도 있다는 것입니다

[39:41] 경제적 불평등을 악화시키는 것과 같은

[39:43] 문제들 말입니다. 그리고 여기 있는

[39:44] 많은 스타트업들이 좋은 일을 하겠지만

[39:46] 동시에 그들의 제품 특성상

[39:48] 일부 부정적인 결과에도

[39:50] 기여하게 될 것입니다.

[39:51] 그래서 궁금한 것은

[39:53] AI 개발자인 우리가 어떻게

[39:56] 제품 개발과 AI 제품의 잠재적인

[39:59] 사회적 부작용 사이에서

[40:01] 균형을 맞춰야 하는지, 그리고

[40:04] 어떻게 빠르게 움직이면서도

[40:06] 말씀하신 대로 책임감 있게

[40:08] 행동할 수 있는지입니다.

[40:09] 마음 속 깊이 들여다보고, 근본적으로

[40:12] 당신이 만들고 있는 것이

[40:13] 사람들을 전반적으로 더 나아지게 하지 않을 것 같다면

[40:17] 하지 마세요. 맞습니다. 간단하게 들리지만

[40:18] 실제로는 그 순간에 매우 어려운 일입니다.

[40:20] AI 펀드에서 우리는 여러 프로젝트를 종료했습니다.

[40:22] 재정적 이유가 아니라

[40:23] 윤리적 이유로 말입니다.

[40:25] 여러 프로젝트를 검토했는데

[40:26] 경제적 타당성은 매우 확실했지만

[40:28] 우리는 이것이 세상에 존재하는 것을 원하지 않는다고 말하고

[40:31] 그런 이유로 프로젝트를 중단했습니다.

[40:32] 더 많은 사람들이 그렇게 했으면 좋겠습니다.

[40:34] 그리고 모든 사람을 함께 데려가는 것에 대해 걱정하고 있습니다.

[40:37] 제가 보고 있는 것은 엔지니어링이 아닌

[40:40] 모든 종류의 직무에 있는 사람들이

[40:42] AI를 알고 있으면 모르는 것보다

[40:44] 훨씬 더 생산적이라는 것입니다.

[40:46] 예를 들어 우리 마케팅 팀에서

[40:49] 마케터들은 코딩을 알고 있습니다.

[40:51] 솔직히 말해서 그들은

[40:52] 모르는 사람들보다 훨씬 앞서 나가고 있었습니다.

[40:55] 그래서 모든 사람이 코딩을 배웠고

[40:56] 그러면서 더 나아졌습니다.

[40:58] 하지만 모든 사람을 함께 데려가려고 노력하는 것이

[41:00] 모든 사람이 AI로 구축할 수 있도록

[41:02] 역량을 갖추게 하는 것

[41:04] 그것이 우리 모두가 해야 할 일의

[41:06] 중요한 부분이 될 것이라고 생각합니다.

[41:07] 저는 선생님의 큰 팬이고

[41:09] 온라인 강의에 감사드립니다.

[41:11] 선생님의 강의가 딥러닝을

[41:13] 세계에 훨씬 더 접근 가능하게 만들었습니다.

[41:16] 그리고 제 질문도 교육에 관한 것입니다.

[41:18] AI가 더 강력해지고 널리 퍼지면서

[41:20] 실제로 할 수 있는 것과

[41:23] 사람들이 인식하는 것 사이에

[41:25] 점점 더 큰 차이가 생기는 것 같습니다.

[41:28] 그래서 일반 대중에게

[41:31] 딥러닝에 대해 교육하는 것이

[41:33] 기술자들만 교육하는 것이 아니라

[41:36] 사람들이 AI가 실제로 무엇을 하는지

[41:38] 그리고 어떻게 작동하는지를

[41:41] 더 잘 이해하도록 하는 것이 중요한지에 대해 어떻게 생각하시나요?

[41:43] 그 지식이 확산될 것이라고 생각합니다.

[41:45] 딥러닝 AI를 통해 모든 사람이

[41:47] AI로 구축할 수 있도록 역량을 갖추게 하고 싶습니다.

[41:48] 그래서 우리가 작업하고 있습니다. 우리 중 많은 사람들이 작업하고 있습니다. 제가 말씀드리고 싶은 것은

[41:50] 제가 생각하는 주요 위험을 말씀드리겠습니다.

[41:52] 두 가지 위험이 있다고 생각합니다. 하나는

[41:55] 사람들을 충분히 빠르게 따라오게 하지 못할 경우인데,

[41:56] 이 문제는 해결할 수 있을 것으로 생각합니다.

[41:58] 또 다른 위험은 모바일 생태계를 보면

[42:00] 실제로 모바일폰이

[42:02] 그리 흥미롭지 않다는 점입니다.

[42:04] 그 이유 중 하나는

[42:06] 안드로이드와 iOS라는 두 개의 게이트키퍼가 있기 때문입니다.

[42:08] 그들이 허용하지 않으면

[42:10] 모바일에서 특정 기능을 시도할 수 없습니다.

[42:12] 이것이 혁신가들의 발목을 잡는다고 생각합니다.

[42:14] AI의 위험성은

[42:15] 특정 기업들에 의해 이용되고 있습니다.

[42:18] 그들은 오픈소스를 막으려고 하는데

[42:21] 대규모 파운데이션 모델의

[42:23] 게이트키퍼가 되고 싶어하는 기업들이 있기 때문입니다.

[42:24] 따라서 AI의 위험성을 과장하여

[42:27] 가짜 위험을 부풀려서

[42:30] 규제 당국이 캘리포니아의

[42:32] SB 1047 같은 법안을 통과시키도록 하는 것은

[42:35] 다행히 우리가 막을 수 있었지만

[42:37] 이런 법안들은 실제로는 아무도 더 안전하게 하지 못하면서

[42:40] 부담스러운 규제 요건만 만들어

[42:42] 개발자들이 오픈소스와

[42:43] 오픈 웨이트 소프트웨어를

[42:45] 배포하는 것을 매우 어렵게 만듭니다.

[42:47] 불평등의 위험 중 하나는

[42:49] 이런 끔찍한 규제 접근법들이

[42:52] 성공한다면 - 저는 직접 회의실에서

[42:54] 일부 기업들이 규제 당국에게

[42:56] 사실이 아닌 말을 하는 것을 들었습니다.

[42:58] 따라서 이런 주장들의 위험성은

[43:00] 이런 규제 제안들이 성공하여

[43:03] 규제를 통해 소수의 게이트키퍼만

[43:04] 남기게 되면서 모든 사람이

[43:07] 소수 기업들의 허가를 받아야

[43:09] 모델을 파인튜닝하거나

[43:11] 특정 방식으로 프롬프트를 작성할 수 있게 되는 것입니다.

[43:13] 이것이 혁신을 막고

[43:15] 정보의 확산을 방해하여

[43:17] 많은 스타트업들이 자유롭게

[43:19] 원하는 것을 책임감 있게 구축할 수 있는

[43:22] 혁신의 자유를 막게 됩니다.

[43:24] 따라서 우리가 오픈소스와

[43:26] 오픈 웨이트 모델에 대한

[43:29] 이런 공격 라인을 막아내고

[43:31] 좋은 진전을 이루었지만

[43:32] 위협은 여전히 존재합니다.

[43:34] 그렇다면 결국 우리는

[43:36] 지식의 확산을 이룰 수 있고

[43:38] 모든 사람을 함께 데려갈 수 있을 것입니다.

[43:40] 하지만 오픈소스를 보호하기 위한 싸움은

[43:42] 지금까지 승리하고 있지만

[43:44] 싸움은 여전히 계속되고 있으며

[43:45] 오픈소스를 보호하기 위한

[43:47] 노력을 계속해야 합니다.

[43:50] 여러분 모두 감사합니다.

[43:52] 뵙게 되어 정말 기뻤습니다. 감사합니다.