Cursor가 Claude와 함께 AI 코딩의 미래를 만드는 방법

Anthropic 구독자 70,600명

요약

이 영상에서는 Anthropic의 Alex와 Cursor 팀이 모여 Claude 모델을 활용해 Cursor가 어떻게 개발자 워크플로를 혁신하는지 이야기합니다. 초기 탭 완성과 단일 파일 편집에서부터 Sonnet 3.5를 통한 멀티 파일 편집, 에이전트 기능, 백그라운드 에이전트까지 주요 기능의 발전 과정을 다룹니다. Cursor 팀이 제품을 자체적으로 개선하는 재귀적 피드백 루프, 검증(verification)과 코드 맛(taste)의 중요성, AI 코드의 민주화 및 미래 개발자 역할 변화도 폭넓게 논의합니다.

주요 키워드

AI coding multi-file edits agentic systems background agent verification tab completion retrieval models taste in code software democratization recursive feedback loop

하이라이트

🔑 Sonnet 3.5 도입으로 탭 완성을 넘어 멀티 파일 편집이 가능해지며 Cursor 채택이 폭발적으로 늘어났다.
⚡️ 에이전트(agent) 기능과 백그라운드 에이전트를 통해 비동기 작업을 병렬로 처리해 개발 생산성을 크게 끌어올린다.
🚀 Cursor팀은 스스로를 최고의 고객으로 삼아 AI 도구를 직접 사용하고 피드백을 반영하는 재귀적 개선 루프를 운영한다.
📌 다음 과제는 검증(verification): 테스트 자동화와 검토 속도 개선으로 소프트웨어 엔지니어링 효율을 극대화해야 한다.
🌟 코드 맛(taste) 강조: 반복 없는 설계, 일관된 스타일, 기존 코드베이스와의 조화 등 클린 코드 원칙이 AI 시대에도 핵심이다.
📌 개발 상황에 따라 Tab 완성, Command K 편집, 에이전트, 백그라운드 에이전트까지 기능 스펙트럼을 자유롭게 활용한다.
🔥 가까운 미래에는 작성되는 코드의 90% 이상이 AI로 생성될 전망이지만, 개발자는 여전히 요구사항 정의와 품질 보증 역할을 수행한다.
🚀 비개발자도 자신만의 대시보드나 툴을 AI로 즉시 생성하면서 소프트웨어 민주화가 가속화된다.

용어 설명

Claude

Anthropic이 개발한 대형 언어 모델로, 프로그래밍과 에이전트 기반 작업에 최적화되어 있다.

Tab completion(탭 완성)

코드 입력 중 다음 코드를 예측·제안해 개발 속도를 높이는 기능이다.

Retrieval models(검색 모델)

대규모 코드베이스에서 관련 문맥을 찾아 AI에게 제공해 멀티 파일 편집을 지원한다.

Agentic systems(에이전트 시스템)

AI가 개발 환경 내에서 스스로 의사결정을 하고 작업을 수행하는 기능이다.

Background agent(백그라운드 에이전트)

비동기식으로 실행되며 PR을 생성하거나 수정안을 제안해 주는 AI 에이전트다.

Verification(검증)

AI가 생성한 코드가 요구사항을 충족하는지 테스트와 검토 과정을 통해 확인하는 단계다.

Anthropic의 Alex와 Cursor 창업자 Aman, Lukas, Jacob가 모여 AI 코딩 도구에 대해 대화를 시작한다. 각자 맡은 역할과 Cursor에서 담당하는 ML·에이전트 업무를 간단히 소개한다.

[00:00] Cursor팀이 소프트웨어 개발에서 AI 활용의 미래에 대해 논의하며, Anthropic의 Alex가 Cursor의 급성장과 변화에 대해 질문을 시작합니다.

런칭 1년 만에 3억 달러 매출을 돌파하고 수백만 개발자가 Cursor를 사용하게 된 배경을 살펴본다. 이 기간 동안 제품이 어떻게 진화했는지를 논의한다.

[00:53] Cursor의 창립자들이 지난 1년간의 주요 변화를 설명합니다. 언어 모델의 잠재력과 3.5 Sonnet의 등장으로 인한 프로그래밍 능력의 단계적 도약에 대해 언급합니다.

탭 완성과 단일 파일 편집 중심이던 Cursor가 Sonnet 3.5 도입 후 검색 모델과 결합해 멀티 파일 편집 기능까지 확장한 과정을 설명한다. 그 결과 사용자 경험이 크게 개선되었다.

[01:23] 초기 Cursor는 탭 완성과 단일 파일 편집에 유용했지만, 3.5 Sonnet과 커스텀 검색 모델의 결합으로 다중 파일 편집이 가능해지면서 대중 채택의 전환점이 되었다고 설명합니다.

[01:57] Alex가 이러한 발전이 자연스러운 진행이었는지, 아니면 3.5 Sonnet 출시 시 갑작스러운 깨달음이었는지 질문하고, Cursor팀은 점진적이었다고 답하며 모델 테스트의 어려움에 대해 토로합니다.

Cursor팀이 Cursor를 써서 Cursor를 개발하는 재귀적 피드백 루프를 운영하며 문제를 직접 발견·해결하는 방식을 소개한다. 기능별 사용 사례와 임팩트를 공유한다.

[02:32] AI 모델들의 점진적 발전으로 코딩 능력이 향상되고, 특히 Sonnet 모델에서 멀티파일 상호작용과 도구 사용 기능이 크게 개선되어 실제 에이전트처럼 작동할 수 있게 되었다는 설명

[02:57] 새로운 모델의 기능이 더 많은 실험과 탐구를 가능하게 하고, 이것이 다시 제품 개발로 피드백되어 새로운 기능 구축의 선순환 구조를 만든다는 대화

[03:09] Cursor 팀이 자신들의 도구를 사용해서 Cursor 자체를 개발하는 자기 개선 피드백 루프에 대한 질문과 일상적인 개발 과정에 대한 궁금증 표현

가장 가벼운 Tab 완성부터 Command K 단위 편집, 에이전트, 백그라운드 에이전트까지 상황에 맞춘 네 단계 워크플로우 스펙트럼을 제시한다. 각 기능의 장단점을 논의한다.

[03:29] 개발 과정에서 개별 사용 사례와 작업 단계에 따라 다른 접근법을 사용한다는 설명. 초기 코드베이스 구성시 Agent 기능, 정확한 편집시 탭 기능, 새로운 코드베이스 탐구시 QA와 검색 기능을 활용

[04:07] Claude 3.7과 3.5 모델이 코드베이스 연구와 컴포넌트 간 상호작용 파악에 뛰어난 성능을 보인다는 언급

[04:16] 이런 기능들을 통해 코드베이스 탐구가 쉬워지고, 사용 과정에서 부족한 영역을 발견하여 개선 작업으로 이어지는 순환 구조에 대한 확인

[04:24] Cursor가 자신들의 문제 해결을 통해 주도되며, 어려움을 겪는 부분을 파악하여 제품을 개선하고, 누구나 새로운 기능을 실험해볼 수 있는 철학을 가지고 있다는 설명

[04:48] 메타적 차원에서의 장점에 대한 질문으로 대화가 전환되는 시점

[04:51] 팀이 자신들의 제품을 직접 사용하는 고객이 되는 것의 장점에 대해 논의하며, 이를 통해 빠른 기능 개발과 효과적인 반복 작업이 가능하다고 설명합니다.

[05:16] AI를 프로그래밍에 활용하는 방식이 개발자마다 다르며, 코드베이스에 대한 친숙함에 따라 다른 도구를 사용한다고 설명합니다. 익숙한 영역에서는 Tab 기능이, 덜 익숙한 영역에서는 모델에 더 많이 의존한다고 합니다.

[06:15] Cursor의 기능들이 스펙트럼을 이루고 있다고 설명하며, Tab(완전 제어), Command K(단일 영역 편집), Agent(다중 파일 편집), 백그라운드 에이전트(전체 PR 처리) 순으로 나열합니다.

[06:45] 백그라운드 에이전트의 개념을 소개하며, 모델들이 엔드투엔드 작업에서 향상되고 있지만 아직 100% 완벽하지 않기 때문에, 90% 완성된 작업에서 개발자가 제어권을 가져가 나머지를 처리할 수 있는 방식을 제안합니다.

백그라운드 에이전트는 가상 개발 환경에서 비동기로 PR을 생성하고 AI가 수정안을 반복 실험하도록 지원한다. 개발자가 성공 사례에만 집중하도록 UX를 설계한 방식도 설명한다.

[07:10] Cursor의 백그라운드와 포그라운드 기능 사이의 빠른 전환의 중요성을 설명하며, 현재 초기 단계지만 3-4개의 변경사항을 동시에 처리할 수 있는 흥미로운 방식들이 있을 것이라고 언급합니다.

[07:41] 백그라운드 에이전트를 새로운 기본 요소로 보고 있으며, 현재는 프롬프트를 백그라운드로 보내 독립적으로 작업을 반복하는 직관적인 방식이지만, 더 많은 통합과 제품적 가치를 만들 수 있다고 설명합니다.

[08:02] 백그라운드 에이전트의 기술적 구현에 대해 설명하며, 작은 독립적인 환경에서 모든 개발 유틸리티와 VS Code 확장 프로그램이 설치되어 있어 에이전트가 이를 활용할 수 있다고 답변합니다.

[08:23] 비동기 작업과 백그라운드 작업의 발전 트렌드에 대해 질문하며, 수천 개의 에이전트가 팀을 이루어 백그라운드에서 문제를 해결하는 미래의 모습에 대해 묻습니다.

수천 개의 에이전트가 병렬로 작업할 때 다음 병목은 코드 검증이라고 지목한다. 테스트 자동화와 검토 효율화로 전체 엔지니어링 속도를 높여야 한다고 강조한다.

[08:45] 소프트웨어 검증과 코드 검증이 다음 병목 지점이 될 것이라고 예측하며, 개발자의 시간 배분을 예시로 들어 코드 작성만 해결해도 소프트웨어 엔지니어링을 3배 이상 빠르게 만들지 못한다고 설명합니다.

[09:13] 코드 리뷰를 더 쉽게 만드는 방법과 에이전트의 변경사항이 단순히 정확한 것이 아니라 개발자의 의도와 일치하는지 확신할 수 있는 방법의 중요성을 강조하며, 명세 부족으로 인한 문제점을 지적합니다.

[09:40] 마이클 CEO가 제안한 의사코드 형태의 코드베이스 표현 방식에 대해 논의합니다. 변경사항을 간결하게 표현하면서도 실제 소프트웨어 변경사항으로 깔끔하게 매핑되는 보장이 있다면 검증 시간을 대폭 단축할 수 있다고 설명합니다.

거대한 코드베이스에서 의존성 설정, DSL 대응, 조직 내부 노하우 반영 등 검증 환경 구성의 어려움을 짚는다. 향상된 검색·문맥 통합으로 이해도를 높이는 전략도 논의한다.

[10:14] 바이브 코딩이 잘 통하는 이유는 검증 과정이 간단하기 때문이라고 분석합니다. 변경사항을 적용한 후 실제로 소프트웨어를 사용해보면서 확인할 수 있지만, 실제 프로덕션 코드베이스에서는 이런 방식이 어렵다고 지적합니다.

[10:35] 독립적인 프로젝트와 수백만 줄의 프로덕션 코드베이스 간의 차이점과 현재 모델들의 대응 수준에 대한 질문이 제기됩니다.

[10:54] 백그라운드 에이전트 개발을 통해 고민한 문제들을 설명합니다. 간단한 저장소에서는 쉽지만, 대규모 엔터프라이즈 코드베이스에서는 의존성 설정이 복잡해서 모델이 테스트를 실행하기 어렵다고 합니다.

[11:29] 개발자가 에이전트를 위한 환경을 쉽게 구성할 수 있도록 하는 방법을 연구하고 있다고 설명합니다. 스냅샷 기능과 빠른 업데이트가 가능한 반복 가능한 환경을 만들어 백그라운드에서 VM을 실행하고 모델이 실험할 수 있게 하는 시스템을 구상하고 있습니다.

반복 금지, 일관성 있는 스타일, 조직 가이드라인 준수 등 깨끗한 설계 원칙이 AI 코딩 시대에도 필수라고 강조한다. AI가 더 많은 코드를 쓰기에 맛과 구조가 중요해진다.

[12:07] 테스트 통과를 통한 정확성 보장 방법에 대해 언급하며, 대규모 코드베이스에서의 추가적인 근본적 문제들이 있다고 시사합니다.

[12:21] 대규모 코드베이스에서는 거의 독립적인 언어처럼 보이는 DSL들을 다루게 되며, 이는 수백만 개의 파일에 걸쳐 수억 개의 토큰으로 구성되어 있습니다.

[12:37] 이 문제를 해결하기 위해 검색 모델 훈련과 다양한 컨텍스트 소스 통합을 포함한 여러 작업을 수행했습니다. 최근 변경사항과 팀원들의 수정 내용을 힌트로 활용하는 것도 포함됩니다.

[13:00] 그러나 단순히 좋은 검색 기능을 제공하는 것만으로는 모델이 코드베이스를 진정으로 이해하기에 불충분합니다. 메모리와 긴 컨텍스트의 조합을 통해 해결하고자 하는 근본적인 문제입니다.

[13:21] 메모리는 모델이 사용 패턴으로부터 학습하도록 하는 흥미로운 접근법이지만, 대규모 코드베이스에서 뛰어난 성능을 내기 위해서는 여전히 원시적인 수준입니다.

[13:38] 대규모 코드베이스에서는 단순히 테스트를 통과시키는 것이 아니라 올바른 방식으로 수행하는 것이 중요합니다. 기존 코드와 일치하도록 만들고 올바른 구조와 가이드라인을 따라야 합니다.

[14:03] 예를 들어, 코드베이스에 여러 디바운스 함수가 있을 때 어떤 것을 사용해야 할지 아는 것은 종종 Slack 메시지 같은 조직적 지식에 의존합니다. 이는 극도로 큰 코드베이스에서 문제 해결을 매우 어렵게 만듭니다.

[14:23] 코드베이스 외부에 존재하는 조직적 지식도 대규모 코드베이스 작업에서 중요한 요인입니다. 현재로서는 주요 병목점은 아니지만, 모델이 코드베이스를 완벽하게 이해하게 된다면 더 중요해질 것입니다.

[14:46] 모델이 완벽해진다면 5배에서 10배 정도의 개선을 얻을 수 있지만, 그 이상은 어렵다. 왜냐하면 PR이나 코드 상태에서 명시적으로 드러나지 않는 정보들과 비즈니스나 영업 같은 외부 요소들이 병목 지점이 되기 때문이다.

[15:11] 미래의 Cursor는 더 많은 시스템과 연결되어야 하지만, 그것이 중요해지기까지는 아직 시간이 필요하다. 현재는 사용자 상호작용과 코드베이스 세부사항, 커밋 내역을 활용해 개선할 여지가 더 많다.

[15:32] 웹페이지가 LLM을 위해 최적화되는 것처럼, 코드도 모델을 위해 변화할 가능성에 대해 논의한다. API 디자인이 이미 LLM이 더 편하게 사용할 수 있도록 조정되고 있으며, 코드 구조도 복잡한 상호작용 대신 간단한 단계로 구성하는 방향으로 변화하고 있다.

2027년까지 AI가 90% 이상의 코드를 생성할 것이라는 전망을 공유한다. 개발자는 요구사항 정의, 품질 보증, UX·도메인 지식 등 고부가가치 업무에 집중하게 된다.

[16:30] 깨끗한 소프트웨어의 원칙은 사람이나 모델이 읽는 것과 관계없이 동일하다. 반복을 피하고 필요 이상으로 복잡하지 않게 만드는 것이 중요하며, 코드에 대한 취향과 깔끔한 솔루션에 대한 감각은 모델이 발전할수록 더욱 중요해질 것이다.

[17:14] 취향에 대한 논의로, 어떤 사람들은 다른 사람들보다 더 많은 취향을 가지고 태어나는 것 같다는 관찰을 제시한다.

[17:21] AI 시대에 프로그래머의 취향과 경험은 여전히 중요하며, 이는 실패와 성공을 통해 개발되는 것입니다.

[17:29] AI가 더 많은 코드를 작성하게 되면서 프로그래머가 게을러지거나 주니어 개발자들이 학습 기회를 잃을 것이란 우려가 제기되고 있습니다.

[17:57] AI 도구들은 교육적으로 매우 유용하며, Command L로 Claude에게 질문해서 개념을 설명받을 수 있어 프로그래머 성장에 도움이 됩니다.

[18:34] 품질은 빠른 반복을 통해 실수하고 실패 원인을 파악하는 과정에서 나오며, AI 모델이 이 반복 과정을 가속화해 더 빠른 학습을 가능하게 합니다.

[18:59] 미래에는 세부사항을 모르지만 효과적으로 작업할 수 있는 엔지니어들이 등장할 것이며, 이들은 UX 취향과 고수준 상호작용 설계에 집중하게 될 것입니다.

비개발자도 AI를 이용해 맞춤형 툴·대시보드를 즉시 생성하는 시대가 온다. 스타트업에서는 높은 인재 밀집도와 빠른 피드백 루프로 혁신을 주도할 수 있다는 커리어 제안을 전한다.

[19:54] 프로그래밍의 본질적 개념에 대해 설명하며, 시스템이 작동하는 방식을 설명하는 것 자체도 프로그래밍의 한 형태라고 언급합니다.

[19:56] Claude 4 모델들(Opus 4, Sonnet 4)의 출시에 대해 논의하며, 새로운 모델들을 Cursor에 통합하는 방법에 대한 생각을 묻습니다.

[20:12] 새로운 모델들, 특히 Sonnet 4에 대한 긍정적인 평가를 제시합니다. 3.5 모델의 장점과 단점을 인정하며, 특히 과도한 적극성과 테스트 수정 문제를 지적합니다.

[20:34] Sonnet 4가 이전 모델의 문제점들을 효과적으로 해결했으며, 지능도 크게 향상되었다고 평가합니다. 비용 대비 성능이 뛰어나며, Opus 4에 대한 기대감을 표현합니다.

[21:02] Anthropic 측에서 테스트 작성과 과도한 적극성 문제를 해결하기 위해 집중적으로 노력했다고 설명합니다. 강화학습에서의 보상 해킹 개념을 언급하며, 이를 80%까지 줄였다고 밝힙니다.

[21:25] 3.5 Sonnet의 개발 배경에 대해 질문합니다. Anthropic에서 코딩 모델의 중요성을 인식하고 집중적으로 개발했다고 설명하며, 단순한 코딩이 아닌 장기적 관점의 복합적 코딩 작업을 수행할 수 있는 첫 번째 모델이었다고 평가합니다.

[22:25] Claude 모델의 발전이 성공적이었고, 이것이 향후 모델 개발의 기반이 되었다고 평가함. 코드 분야에서의 뛰어난 성능이 다른 영역으로의 전이 효과를 가져오며, 에이전트 방식의 추론과 작업 수행 능력 향상으로 이어진다고 설명함.

[23:08] Anthropic의 모델 개발 철학을 설명하며, 안전성을 고려하면서도 모델의 한계를 지속적으로 확장하는 것이 목표라고 강조함. 컴퓨터 사용 기능 같은 새로운 방향으로 발전하여 인간 인터페이스를 직접 조작할 수 있는 능력을 개발하고 있음.

[23:51] Claude의 성격 개발에 많은 노력을 기울이고 있으며, 단순한 코딩 도구가 아닌 사용자의 신뢰할 수 있는 동반자 역할을 할 수 있도록 설계하고 있다고 설명함. Amanda Askell이 이끄는 연구팀이 Claude의 캐릭터 개발을 담당하고 있음.

[24:30] AI 모델이 소프트웨어 엔지니어링과 연구 분야에서 인간을 완전히 대체하기보다는, 기존 작업을 보강하고 확장하는 역할을 할 것이라는 개인적 견해를 표명함. 모델이 코드 작성 같은 기계적인 작업을 담당하면서 더 많은 가능성을 열어준다고 봄.

[24:52] 화자는 컴퓨터공학 전공자로서 현재 AI 모델이 자신보다 더 나은 코드를 생성한다고 인정하면서도, AI 덕분에 오히려 더 많은 일을 할 수 있게 되었다고 설명합니다. 프로토타입과 데모를 빠르게 만들 수 있어 역량이 강화되었다고 느낀다고 말합니다.

[25:40] 2027년 1월 1일 예측에 대한 질문에서, 화자는 1995년 변호사에게 워드프로세서 사용률을 묻는 것과 같다며 AI가 거의 모든 코드 작성에 관여할 것이라고 답합니다. 하지만 개발자의 역할은 코드 이해와 소프트웨어 가이드에서 더욱 중요해질 것이라고 강조합니다.

[26:41] Cursor에서 이미 90% 이상이 AI 생성이며, Agent나 Command K 같은 고수준 기능뿐만 아니라 Tab 기능도 타이핑의 70%를 담당한다고 설명합니다. 소프트웨어 개발의 모든 측면이 AI를 활용하도록 변화할 것이라고 예측합니다.

[27:17] 소프트웨어 온디맨드 가능성에 대한 질문에 대해, 이전에는 소프트웨어를 만들지 않았던 조직의 다양한 기능 담당자들, 특히 영업팀 같은 사람들이 자신만의 도구를 만들게 될 것이라고 전망합니다.

[27:35] AI 도구를 통해 비개발자들도 자신만의 대시보드와 소프트웨어를 구축할 수 있게 되었지만, 여전히 무엇을 만들지에 대한 취향과 판단이 중요하다는 점을 강조합니다.

[28:08] 커뮤니케이션 팀 직원이 Claude를 활용해 직접 Claude.ai의 버그를 수정하는 놀라운 사례를 소개하며, 좋은 직관과 취향을 가진 사람이라면 누구든 많은 것을 할 수 있는 시대가 되었다고 설명합니다.

[28:59] 미래의 소프트웨어는 사용자의 상호작용을 기반으로 실시간으로 변화하는 개인 맞춤형 형태로 발전할 가능성을 제시하며, 자신만의 소프트웨어를 구축하려는 사람보다는 개인 맞춤형 소프트웨어의 혜택을 받을 사람이 더 많을 것이라고 전망합니다.

[00:00] 소프트웨어를 만드는 모든 면에서

[00:01] AI를 어떤 식으로든

[00:02] 활용하게 될 것 같아요.

[00:04] 오늘 여러분을 모시게 되어 정말 기뻐요.

[00:07] 이 대화를 오랫동안 기대해왔습니다.

[00:08] 아시다시피 저는 Alex이고,

[00:11] Anthropic에서 Claude Relations을 이끌고 있습니다.

[00:12] 저는 Lukas이고, Cursor에서 에이전트 시스템을 담당하고 있어요.

[00:15] 저는 Aman입니다.

[00:18] 창립자 중 한 명이고 Cursor에서

[00:19] ML과 검색을 담당하고 있어요.

[00:21] 제 이름은 Jacob Jackson이고,

[00:24] Cursor에서 ML을 담당하고 있습니다.

[00:25] 이 대화가 정말 기대되고

[00:27] Cursor에 대해,

[00:28] 여러분이 구축하고 있는 것과

[00:30] Claude를 어떻게 활용하고 있는지

[00:31] 이야기해보고 싶어요.

[00:33] Cursor에게는 정말 큰 한 해였어요.

[00:34] AI 업계를 따라가고 있는

[00:36] 누구에게나 명백한 일이죠.

[00:38] 여러분은 이제 연 매출 3억 달러 이상으로

[00:40] 단 1년 만에 성장했어요.

[00:42] 정말 놀라운 수백만 명의 개발자들이

[00:43] 이제 Cursor를 사용하고 있어요.

[00:45] 여러분 생각에 무엇이 바뀌었고

[00:47] 오늘의 Cursor 버전이

[00:50] 1년 전과 어떻게 다른가요?

[00:53] 몇 가지 큰 변화가 있었다고 생각해요.

[00:57] 현재 언어 모델의 수준을 고려했을 때

[01:01] 항상 엄청난 잠재력이 있었거든요.

[01:05] 그것들로 얼마나 많은 일을 할 수 있는지에 대한

[01:06] 그리고 Cursor는 아마도

[01:08] 적어도 코딩 분야에서 최초로

[01:10] 그 격차를 조금이나마 줄일 수 있었던

[01:12] 회사 중 하나였어요.

[01:13] 그리고 동시에

[01:14] 이 모델들이 코딩에서 훨씬

[01:15] 훨씬 더 나아지는 것도 봤어요.

[01:16] 3.5 Sonnet이

[01:18] 이런 명확한 첫 번째 사례였다고 생각해요.

[01:20] 프로그래밍에서 이런 단계적 도약을 보여준

[01:23] 그래서 그 전까지는

[01:24] Cursor는 탭 완성 같은 것들에

[01:27] 정말 유용했어요. 다음 편집을 예측하는 거죠.

[01:28] 그것만으로도

[01:29] 꽤 빠르게 성장하고 있었고

[01:31] 단일 파일 내에서의 편집도 가능했어요.

[01:32] 하지만 우리가 발견한 것은

[01:33] 3.5 Sonnet 같은 모델의 지능을

[01:35] 검색용으로 사용하는 몇 가지 다른

[01:38] 커스텀 모델들과 결합하고

[01:40] 이 큰 모델이 만든 편집을 적용하면

[01:42] 이제 다중 파일 편집을

[01:43] 할 수 있는 능력이 생긴다는 거였어요.

[01:44] 그것이 Cursor의 대중 채택으로 이어진

[01:46] 단계적 도약이었다고 생각하고

[01:48] 그 이후로는 모델들이 더 나아지고

[01:50] 우리가 내부적으로

[01:51] 이 모델들을 얼마나 더 밀어붙일 수 있는지에 대해

[01:55] 점점 더 나아지려고 노력하는 조합이었어요.

[01:57] 그것이 자연스러운 진행이었나요?

[01:59] 저절로 나타난 것인지,

[02:00] 아니면 3.5 Sonnet이

[02:04] 처음 나왔을 때

[02:05] 와, 이제 갑자기

[02:06] 이전에는 불가능했던 모든 다른 일들을

[02:08] 할 수 있게 되었다고 느꼈나요?

[02:10] 그게 어떤 느낌이었나요?

[02:12] 다소 점진적이었다고 느꼈어요.

[02:14] 모델 품질에는 이런 단계들이 있지만

[02:16] 이전의 최고 수준 모델에서도

[02:19] 그런 힌트들을 볼 수 있었어요.

[02:20] 사실 우리는 이런 모델들을

[02:23] 맛보기 테스트하는 데

[02:25] 악명 높게 서툴렀어요.

[02:26] 우리가 사용하는 방식이

[02:28] 실제 세상에 내놓고

[02:29] 다른 사람들이 어떻게 사용하는지 보는 것과

[02:31] 매우 다르기 때문이죠. 하지만 힌트들은 있었어요.

[02:32] 시간이 지나면서 새로운 모델들이 나올 때마다

[02:33] 점점 더 나아졌습니다

[02:34] 추론 능력이 더 좋아지고

[02:37] 더 에이전트적인 코딩을 할 수 있게 되었죠

[02:39] 그리고 많은 실험과 시도를 하면서

[02:41] 여러 가지를 시도해보고, 무엇이 효과적인지

[02:43] 무엇이 실패하는지 확인합니다

[02:44] Sonnet이 아마 처음으로

[02:47] 멀티파일 상호작용을

[02:48] 정말 잘 작동하게 만들 수 있었던 모델이었습니다

[02:50] 그리고 그 이후로

[02:51] 도구 사용과 같은 여러 단계적 발전이 있었죠

[02:54] 그러면 실제로

[02:54] 이런 모델들이

[02:55] 에디터 안에서 진짜 에이전트처럼 작동할 수 있게 됩니다

[02:56] 흠, 알겠습니다

[02:57] 그러면 새로운 모델들의 발전과

[02:59] 시간이 지나면서 새로운 기능들이

[03:02] 더 많은 실험과 탐구를 가능하게 하고

[03:04] 그것이 다시 어느 정도

[03:06] 제품으로 피드백되어 새로운 기능을 구축할 수 있게 하는군요

[03:08] 맞습니다

[03:09] 흥미롭네요

[03:10] 그리고 이것이 제가 다음에 하고 싶은

[03:12] 질문으로 이어지는데, 저는 여러 이야기를 들었습니다

[03:14] 여러분 팀이 Cursor로 Cursor를 개발하고 있다는

[03:18] 마치 자기 개선하는

[03:20] 재귀적 피드백 루프 안에서 말이죠

[03:21] 우선, 이것이 어떻게

[03:23] 보이는지

[03:23] 일상적으로 어떤 모습인지

[03:25] Cursor에서 여러분들이

[03:27] 작업하면서

[03:28] 새로운 기능을 개발할 때는 어떤 모습인지 설명해주실 수 있나요?

[03:29] 네, 이것은 개별 직원들의

[03:30] 사용 사례에 따라

[03:32] 많이 달라진다고 생각합니다

[03:33] 그리고 또한 제품의 어떤 부분을

[03:36] 작업하고 있는지에 따라서도

[03:37] 그리고 그 부분이 어떤 단계에 있는지에 따라 많이 달라집니다

[03:40] 처음에 코드베이스나

[03:41] 새로운 기능을 구성할 때는

[03:42] Agent 기능을 사용해서

[03:44] 시작하는 것이 매우 유용하고

[03:46] 그다음에 씽킹 모델들을 사용해서

[03:48] 개별적인 문제들을

[03:49] 직면할 수 있는 상황들을 살펴보죠

[03:52] 그리고 매우 정확한 편집을 할 때는

[03:54] 그것은

[03:55] 많은 탭 기능도 사용하고

[03:58] 처음에 잘 모르는 코드베이스를

[04:00] 시작할 때는

[04:03] QA 기능들을 많이 사용하고

[04:05] 검색을 많이 사용합니다. 그리고 이것도

[04:07] Claude 3.7과

[04:09] 3.5가 정말 뛰어난 부분인데

[04:12] 코드베이스에서 연구하고

[04:13] 특정한 것들이

[04:14] 서로 어떻게 상호작용하는지 파악하는 것입니다

[04:16] 아, 이런 기능들을 사용해서

[04:17] 코드베이스를 탐구하면 과정이 더 쉬워지고

[04:19] 그러면 이런 기능들을 사용하면서

[04:20] 배우게 되는 것이 이 영역에 부족함이 있다

[04:22] 우리가 그 부분을 작업해야겠다는 것이군요

[04:24] 네, 더 쉬워집니다. 저는 Cursor가

[04:25] 우리 자신의 문제를 해결하는 것에

[04:26] 의해 주도되고

[04:27] 우리가 문제 해결에서

[04:29] 어려움을 겪는 부분을

[04:30] 파악하고 Cursor를 더 좋게 만드는 것

[04:32] 그리고 거기서 우리가

[04:33] 무엇을 할 수 있는지 파악하고

[04:35] 많은 실험을 하는 것이라고 생각합니다

[04:37] 우리는 누구나

[04:38] 시도해볼 수 있다는 철학을 가지고 있습니다

[04:41] 제품에 새로운 기능을 추가해보고

[04:44] 내부적으로 어떻게 사용되는지 확인하고

[04:46] 어떤 종류의 피드백을 받는지 확인합니다

[04:48] 좀 더 메타적인 차원에서

[04:49] 장점이 있다고 생각하시나요?

[04:51] 내부적으로 자신들이 최고의 고객이 되는 것에 장점이 있다고 생각하시나요?

[04:54] 100% 그렇다고 생각합니다.

[04:56] 그래서 우리가 새로운 기능을 구축할 때

[04:57] 정말 빠르게 움직일 수 있고

[04:59] 명백히 작동하지 않는 것들을 바로 버릴 수 있어요

[05:02] 왜냐하면 우리 자신에게 정말 솔직할 수 있거든요

[05:04] 그것이 유용한지에 대해서 말이죠

[05:06] 그리고 사용자들에게 배포하지 않고도, 사람들이 어떻게 사용하는지 추적하지 않고도

[05:09] 기능을 계속 진행할지

[05:11] 결정할 수 있어요

[05:12] 그리고 이것이 기능 구축의 반복 주기를

[05:14] 가속화한다고 생각합니다.

[05:16] 네, 전반적으로 우리가 AI를 프로그래밍에 사용하는 방식으로 돌아가서 보면,

[05:19] 회사 내에서 많은 다양성이 있다고 느껴져요

[05:21] 사람마다 사용하는 방식이 다르거든요.

[05:22] 먼저 하고 있는 작업의 종류에 따라

[05:24] 다르다고 생각해요.

[05:25] 예를 들어, 많은 사람들이

[05:27] 정말 익숙한 코드베이스의 부분에서

[05:30] 작업하고 있을 때가 있잖아요.

[05:32] 그 시점에서 모든 것이 머릿속에 있을 때는

[05:34] 직접 코드를 타이핑해서

[05:38] 의도를 전달하는 것이

[05:39] 종종 더 빠를 때가 있어요

[05:41] 그럴 때 Tab 기능이 정말 유용한데

[05:43] 속도를 높여주거든요.

[05:45] 하지만 덜 익숙한 곳에서

[05:46] 작업하거나

[05:47] 많은 코드를 작성해야 할 때는

[05:49] 그 많은 부분을 모델에게

[05:51] 위임할 수 있고, 종종 추론의 일부도

[05:53] 이 모델들에게 맡길 수 있어요

[05:55] 그리고 루카스가 설명한 것처럼

[05:57] 정말 익숙하지 않은 곳에 가게 되면

[05:58] 새로운 코드베이스에

[05:58] 처음 들어갈 때

[06:00] 이 모델들을 사용함으로써

[06:01] 얻을 수 있는 엄청난 단계적 향상이 있어요

[06:04] 그리고 시간이 지나면서

[06:05] 모델이 더 좋아지고

[06:07] Cursor가

[06:08] 이 모델들을 더 잘 사용하게 되면서

[06:09] 더 많은 지식을 가지고 있을 때

[06:11] 더 흐름에 있을 때

[06:12] 코드베이스에 대한

[06:13] 더 많은 지식을 갖게 될 때 더 나은 작업을 할 수 있게 돼요.

[06:14] 그래서 기능이 언제

[06:15] 사용 사례에 가장

[06:17] 적용 가능한지에 대한 변화가 있고

[06:18] 어떤 면에서는 스펙트럼 같은 것이죠.

[06:19] 네, 스펙트럼의 한쪽 끝에는

[06:21] 완전히 통제하고 있을 때를 위한 Tab이 있고

[06:23] 무엇을 하고 있는지 알 때

[06:25] 그 다음에는 Command K가 있어서

[06:26] 단일 영역을 편집할 때,

[06:27] 전체 파일을 편집할 때 사용하고

[06:29] 다른 쪽 끝에는 Agent가 있어서

[06:30] 여러 파일을 편집하는 데

[06:32] 정말 좋고,

[06:34] 그리고 맨 끝에는

[06:36] 우리가 작업 중인

[06:37] 백그라운드 에이전트가 있는데

[06:38] 이것은 기본적으로

[06:39] 전체 PR을 처리하는 데 유용할 수 있어요.

[06:44] 여러분이 방금

[06:45] 백그라운드 에이전트의 프리뷰를 출시했는데요.

[06:46] 백그라운드 에이전트가 무엇인가요?

[06:47] 모델들이

[06:48] 엔드투엔드 작업을 수행하는 데

[06:49] 점점 더 나아지고 있다는 것은 분명하지만

[06:52] 아직 100%는 아니고

[06:53] 100%에 도달하는 데는

[06:55] 시간이 걸릴 것 같아요.

[06:56] 그래서 개발자의 속도를 높이는 방법은

[06:58] 병렬로 작업할 수 있게 하는 것인데,

[06:59] 그냥 백그라운드에서 돌아가게 하는 것과는 달리

[07:00] GitHub에서 확인하는 PR을 생성할 때

[07:03] 90%만 완성되어 있다면

[07:05] 직접 들어가서 제어권을 가져가고 싶어할 거예요

[07:07] 그리고 나머지를 처리하고 싶어하겠죠

[07:08] 그때 Cursor의 기능들을 사용하고 싶어할 테니까요.

[07:10] 나머지 작업을 완료하고 나서 Cursor의 기능들을 활용해서 작업을 하고 싶어 할 겁니다.

[07:12] 그렇게 하기 위해서 말이죠.

[07:14] 그래서 정말로 빠르게

[07:16] 백그라운드와

[07:17] 포그라운드 사이를 이동할 수 있는 능력이 정말 중요합니다.

[07:20] 그리고 생각해보면,

[07:20] 우리는 이 기능의 초기 단계에 있고

[07:23] 정말 흥미로운 방식들이 많이 있을 것 같습니다.

[07:27] 예를 들어 3개나 4개의 변경 사항을

[07:30] 동시에 작업하고

[07:31] 그것들을 빠르게 백그라운드로 보내고

[07:32] 다시 포그라운드로 가져오는 방식으로 말이죠.

[07:35] 이것이 사람들이 Cursor를 사용하는 방식과

[07:37] 전반적인 소프트웨어 개발 방식을

[07:39] 어떻게 바꿀지 지켜보는 것이 흥미로울 것 같습니다.

[07:41] 저희는 백그라운드 에이전트를

[07:42] 정말 다양한 곳에서 사용할 수 있는

[07:44] 새로운 기본 요소로 보고 있습니다. 현재

[07:46] 노출 방식은 꽤 직관적입니다.

[07:48] 프롬프트를 받아서

[07:50] 백그라운드로 보내면

[07:52] 독립적으로 해당 작업을 반복 개선합니다.

[07:54] 하지만 더 많은 통합 방식이 있을 수 있고

[07:56] 이러한 것들이 어떻게 생성될 수 있는지

[07:58] 그리고 그것으로부터 만들 수 있는

[08:00] 많은 제품적 가치가 있다고 생각합니다.

[08:02] 그러면 이것은 코드베이스를 가져다가

[08:03] 가상 머신에 넣는 건가요?

[08:06] 정확히 어떤 전환이 일어나는 건가요?

[08:09] 정확히 맞습니다.

[08:10] 저희는 충분히 작은 독립적인 환경들을 가지고 있어서

[08:11] 모든 개발 환경 유틸리티들이

[08:15] 이미 설치되어 있고

[08:16] 에이전트가 그것들을 사용할 수 있습니다.

[08:18] 그리고 모든 VS Code 확장 프로그램들도

[08:20] 사용 가능하고

[08:21] 그것을 통해 기타 등등을 할 수 있습니다.

[08:23] 우리가 지금 목격하고 있는 트렌드가

[08:26] 비동기 작업,

[08:27] 코딩부터 연구까지 다양한 분야에서의 백그라운드 작업인데,

[08:31] 당신의 관점에서 보면

[08:33] 이것이 어떻게 발전해서

[08:34] 수천 개의 에이전트들이

[08:37] 잠재적으로 작업을 수행하고

[08:39] 전체적인 에이전트 팀이

[08:41] 모든 백그라운드에서 문제를 해결하는 모습이 될까요?

[08:43] 그런 미래는 어떤 모습일까요?

[08:45] 다음 병목 지점은

[08:47] 소프트웨어 검증,

[08:49] 코드 검증이 될 것 같습니다.

[08:51] 모델들이 정말,

[08:52] 정말 많은 코드를 생성하고 작성하는 데

[08:54] 매우 뛰어나져 가고 있지만, 개발자들이

[08:59] 대략적인 수치를 말해보자면,

[09:00] 시간의 30%를 코드 작성에,

[09:03] 30%를 코드 리뷰에,

[09:04] 70%를 코드 작성에 사용한다고 합시다.

[09:06] 코드 작성을 완전히 해결한다고 해도

[09:08] 소프트웨어 엔지니어링을

[09:10] 3배 이상 빠르게 만들지는

[09:11] 못한 것이죠. 그래서

[09:13] 사람들이 코드를 리뷰하는 것을

[09:14] 더 쉽게 만드는 방법과

[09:17] 에이전트가 만드는 변경사항이

[09:19] 단순히 정확한 것이 아니라

[09:20] - 정확함이라는 것이 모호할 수 있거든요 -

[09:22] 당신이 명시한 것일 수도 있지만,

[09:23] 명세가 충분하지 않아서

[09:25] 실제로는 최고의 인간 프로그래머가

[09:26] 할 수 있는 최선을 다한 것일 수도 있지만

[09:29] 실제로

[09:31] 당신이 마음속으로 생각했던 것과는

[09:33] 다를 수 있습니다.

[09:35] 그래서 그 과정을 훨씬,

[09:37] 훨씬 더 좋게 만드는 것이 정말, 정말 중요할 것 같습니다.

[09:39] 그리고 이것은 저희가

[09:40] 우리도 정말 관심 있는 분야예요.

[09:42] - 그런 방향으로 어떤 초기 아이디어가 있나요?

[09:44] - 회사 내 여러 사람들로부터

[09:45] 몇 가지 아이디어가 떠돌고 있어요.

[09:48] 우리 CEO인 마이클이 정말

[09:51] 좋아하는 아이디어 중 하나는

[09:53] 다른 표현 방식으로

[09:55] 코드베이스를 다루는 것이에요.

[09:56] 의사코드처럼 보일 수도 있고

[09:59] 만약 변경사항을

[10:02] 이렇게 간결한 방식으로 표현할 수 있고

[10:04] 그리고 깔끔하게

[10:05] 매핑되는 보장이 있다면

[10:06] 실제 소프트웨어에서 이루어지는

[10:08] 실제 변경사항으로 말이죠.

[10:10] 그렇게 하면 검증 시간을 엄청나게 단축할 수 있을 거예요.

[10:12] 하지만 그것도 하나의 가능한 방법이죠.

[10:14] 음, 소위 말하는

[10:16] '바이브 코딩'이 잘 통하는 이유는

[10:17] 검증 과정이

[10:19] 정말 쉽기 때문이에요.

[10:21] 그냥

[10:22] 소프트웨어를 가지고 놀아보는 것뿐이잖아요, 맞죠?

[10:24] 변경을 하고 나서 실제로

[10:26] 만든 소프트웨어를 가지고 놀아보는 거죠.

[10:28] 하지만 실제 프로덕션 코드베이스에서는

[10:31] 정말 어려울 것 같고

[10:32] 그 문제를 해결하는 것이 정말 중요해요.

[10:35] - 바이브 코딩을 할 수 있는

[10:37] 독립적인 것과

[10:40] 수백만 줄의 파일을 가진

[10:44] 프로덕션 코드베이스 간의 차이에 대한

[10:46] 좋은 질문이네요.

[10:47] 두 가지의 차이점을

[10:47] 어떻게 보시는지, 그리고 현재 모델로

[10:50] 이런 환경에서 작업하는 면에서

[10:53] 어느 정도 수준에 와 있는지 궁금해요.

[10:54] - 백그라운드 에이전트를 통해

[10:56] 많이 고민해본 부분이에요.

[10:59] 정말 간단하고 당연히 쉬워야 할 것은

[11:01] 이런 모델들로 '여기 테스트가 있는데

[11:05] 현재 테스트가 실패하고 있으니

[11:07] 통과하도록 코드를 고쳐달라'고 하는 거죠.

[11:09] 그럼 어떻게 해야 할까요?

[11:12] 모델이 테스트를 실행할 수 있어야 하고

[11:14] 아주 간단한 저장소라면

[11:17] 매우 간단하죠.

[11:18] 하지만

[11:19] 이런 대규모 엔터프라이즈 코드베이스에서는

[11:21] 의존성을 제대로 설정하는 것이

[11:22] 복잡해서

[11:26] 모델이 테스트를 실행하기 어려워요.

[11:27] 하지만 백그라운드 에이전트를 통해

[11:29] 많이 고민해본 부분은

[11:30] 개발자가 이런 환경을 만드는 과정을

[11:34] 어떻게 간단하게 할 수 있을까 하는 것이에요.

[11:36] 에이전트가 테스트를 실행할 수 있는

[11:40] 그리고 반복 가능하게 만들어서 스냅샷을 찍고

[11:42] 빠르게 업데이트할 수 있게 하는 것이죠.

[11:43] 코드 상태가 바뀔 때 말이에요.

[11:46] 이렇게 하면 백그라운드에서 VM을 실행하고

[11:48] 모델이 실험을 할 수 있게 되죠.

[11:51] 그 중 일부는 통과하고

[11:53] 일부는 실패할 거예요.

[11:55] 그러면 결국

[11:56] 개발자는 성공한 경우만

[11:58] 신경쓰면 되고

[12:00] 거기에는 정말 많은 인프라와

[12:03] 사용자 경험이

[12:05] 제대로 구현되어야 해요.

[12:06] - 음, 그렇군요.

[12:07] - 네. 그리고 다른

[12:09] 근본적인 문제들도 있어요.

[12:10] 한 가지 방법은 모델이 테스트를

[12:14] 통과하도록 하는 거예요, 맞죠?

[12:15] 그런 식으로 어느 정도

[12:17] 정확성을 보장할 수 있어요.

[12:19] 하지만 이런 대규모 코드베이스에서는

[12:21] 종종 다루게 되는 것들이

[12:21] 거의 독립적인 언어처럼 보이는 것들입니다

[12:24] 일부 언어 내에서 이런 종류의 DSL을 가지고 있고

[12:26] 모든 것이 특정한 방식으로 수행되며

[12:27] 수백만 개의 파일에 걸쳐 정말 넓게 퍼져 있습니다

[12:30] 이는 수억 개의 토큰, 아마도 그 이상일 수도 있습니다

[12:34] 저희는 이를 크게 개선하기 위해

[12:35] 여러 가지 작업을 해왔습니다

[12:37] 검색 모델을 훈련시키고

[12:38] 다른 컨텍스트 소스들도 통합하는 것들을 포함해서요

[12:39] 예를 들어, 최근에 만든 변경사항들에는

[12:41] 많은 풍부한 정보가 있다고 생각할 수 있습니다

[12:44] 코드를 편집할 때 그것은

[12:46] 당신이 무엇을 향해 작업하고 있는지를 나타내죠

[12:48] 팀의 다른 사람들이

[12:50] 당신의 코드베이스에서 만든 변경사항들에도

[12:51] 풍부한 정보가 있을 수 있습니다

[12:52] 특히 최근의 것들을 힌트로 사용하는 것이죠

[12:54] 하지만 여전히 이것은

[12:56] 정말 어려운 근본적인 문제라고 생각합니다

[12:58] 모델에게 정말 좋은 검색에 대한 접근을 제공하는 것만으로는

[13:00] 모델이 코드베이스를 정말로 이해하기에는

[13:03] 불충분하다고 느낍니다

[13:05] 이는 저희가 정말로 해결하고 싶어하는

[13:06] 문제라고 생각합니다

[13:08] 음, 아마도 메모리와 긴 컨텍스트의 조합을 통해서

[13:12] 그리고 다른 것들도요

[13:13] 네, 메모리는 사람들이 사용한

[13:14] 흥미로운 접근법 중 하나입니다

[13:15] 모델이 사용자의 사용 패턴으로부터

[13:17] 학습하도록 하는 것이죠

[13:20] 하지만 이것도 작은 성능 향상에 불과하고

[13:21] 대규모 코드베이스에서 뛰어난 성능을 내기 위해

[13:24] 필요한 수준에 비해서는

[13:25] 상당히 원시적인 수준이라고 느낍니다

[13:27] 네, 그리고 대규모 코드베이스에서는

[13:28] 단순히 테스트를 통과시키는 것뿐만 아니라

[13:30] 올바른 방식으로 수행하는 것이 중요합니다

[13:32] 기존 코드를 살펴보고

[13:34] 새로운 코드와 일치하도록 만들고

[13:35] 올바른 구조로 가져오고

[13:38] 모든 가이드라인을 올바르게 사용하는 것이죠

[13:39] 저희는 Cursor 규칙을 통해

[13:40] 다양한 종류의 컨텍스트를 통합하는 등

[13:41] 이런 일들을 실현하기 위해 정말 열심히 노력해왔습니다

[13:43] 예를 들어, 저는 처음부터

[13:45] 깊은 바운스 함수를 작성해서

[13:47] 사용할 수 있고 그러면 테스트는 통과할 겁니다

[13:49] 하지만 그것은 올바른 방법이 아닙니다

[13:51] 디바운스 함수 중 하나를 사용해야 하는데

[13:54] 코드베이스 전체에서 사용되는

[13:56] 디바운스 함수가 3개나 4개 정도 있을 수 있습니다

[13:58] 어떤 것이 올바른 것인지 어떻게 알 수 있을까요?

[13:59] 아마도 누군가가 아는 유일한 이유는

[14:01] Slack에서 누군가에게 메시지를 보내서

[14:03] 이렇게 하는 것이라고 들었기 때문일 겁니다

[14:04] 그래서 극도로 큰 코드베이스에서

[14:06] 이런 문제들을 해결하는 것이

[14:07] 정말, 정말 어려워진다고 생각합니다

[14:09] 흥미로운 점이네요

[14:11] 코드베이스 자체 외부에 존재하는

[14:13] 조직적 지식의 요소도 있고

[14:15] 그것이 때때로 이런 결정들에서

[14:16] 주요한 요인으로 작용하는 것 같습니다

[14:20] 특히 대규모 코드베이스에서 작업할 때 말이죠

[14:21] 네, 그것이 오늘날의 병목점이라고 생각하지는 않지만

[14:23] 만약 모델을 완벽하게 만들어서

[14:25] 코드베이스를 아는 것에 대해

[14:26] 해결한다면 말이죠

[14:30] 네

[14:31] 네

[14:33] 네

[14:34] 네

[14:36] 네

[14:37] 네

[14:40] 네

[14:41] 네

[14:44] 네

[14:45] 네

[14:46] 바로 즉시 5배, 아마 10배 정도의 개선을 얻을 수 있을 것 같아요.

[14:48] 하지만 그것보다 더 나아갈 수는 없어요.

[14:50] 왜냐하면 이제 완전히 병목 지점이 되거든요.

[14:51] 모델이 이런 것들을 얼마나 알고 있는지가 문제인데,

[14:53] 이런 것들은 명시적으로 언급되거나

[14:55] PR이나 실제 코드 상태에서

[14:57] 보여지지 않는 것들이거든요.

[14:59] 맞아요.

[15:01] 그리고 비즈니스 측면에서,

[15:02] 영업 등에서 오는 외부적인 우려들도 있어요.

[15:04] 이런 것들을 Cursor로 가져와야

[15:06] 제대로 작동시킬 수 있어요.

[15:07] 맞죠.

[15:10] 그러면 미래의 Cursor 버전은

[15:11] 훨씬 더 많은 시스템들과

[15:13] 연결되어야 하겠네요.

[15:15] 네, 맞아요.

[15:16] 명확히 하자면, 그런 것들이

[15:17] 다른 것들에 비해 정말 중요해지려면

[15:19] 아직 갈 길이 멀다고 생각해요.

[15:21] 사용자 상호작용과

[15:22] 코드베이스의 세부사항,

[15:25] 그리고 커밋 내역을 활용해서

[15:27] Cursor를 훨씬 더 개선할

[15:28] 여지가 아직 많이 남아있어요.

[15:29] 제가 최근에 웹페이지나 콘텐츠에서

[15:31] 흥미롭게 발견한 것 중 하나는,

[15:32] 사람들이 이제 LLM이 읽고 탐색하기 좋도록

[15:35] 페이지를 최적화하는 방법을

[15:37] 생각하기 시작했다는 거예요.

[15:39] 코드에서도 비슷한 일이 일어날 것 같나요?

[15:42] 코드가 변화할 수 있을까요?

[15:44] 주로 인간 리뷰어와 코드베이스에서 작업하는

[15:47] 인간을 위해 작성하던 것에서

[15:48] 모델을 위해 작성하는 방식으로

[15:49] 바뀔 수 있을까요?

[15:51] 이미 그런 일이 일어나고 있다고 생각해요.

[15:56] API 디자인이 이미 LLM이

[15:58] 더 편하게 사용할 수 있도록 조정되고 있어요.

[16:01] 예를 들어, 내부 버전 번호만

[16:02] 바꾸는 것이 아니라

[16:05] 모델이 새로운 소프트웨어 버전임을

[16:06] 명확히 알 수 있도록 만들어서

[16:08] API가 올바르게 사용되도록 하는 거죠.

[16:10] 일반적인 코드베이스와

[16:13] 내부 라이브러리에서도

[16:16] 마찬가지라고 생각해요.

[16:18] n단계의 상호작용을 거치지 않고

[16:19] 단 두 단계의 상호작용만으로

[16:21] 코드를 구조화하는 방식으로 만들면

[16:24] LLM 모델이 그 코드베이스와

[16:26] 더 잘 작업할 수 있게 되거든요.

[16:29] 맞아요.

[16:30] 하지만 궁극적으로 깨끗한 소프트웨어의 원칙은

[16:32] 사람이 읽든 모델이 읽든

[16:33] 그렇게 다르지 않다고 생각해요.

[16:36] 깨끗한 코드를 작성하려고 할 때는

[16:38] 반복을 피하고,

[16:40] 필요 이상으로 복잡하게 만들지 않으려고 하잖아요.

[16:44] 이것은 모델에게도 사람에게도

[16:46] 똑같이 중요해요.

[16:47] 그리고 코드에 대한 취향과

[16:48] 깔끔한 솔루션이 무엇인지,

[16:52] 필요 이상으로 복잡하지 않은 것이

[16:54] 무엇인지에 대한 감각은

[16:56] 이런 모델들이 더 좋아질수록

[16:59] 더욱 중요해질 것 같아요.

[17:01] 점점 더 많은 코드를

[17:02] 쉽게 작성할 수 있게 될 테니까

[17:05] 더욱더 중요해질 거예요.

[17:06] 취향 있게 구조화하는 것이 말이에요.

[17:09] 취향에 대한 정말 좋은 지적이네요.

[17:10] 취향이라는 건 어떤 사람들은

[17:14] 타고나는 것 같기도 하고요.

[17:17] 다른 사람들보다

[17:18] 더 많은 취향을 가지고 태어나는

[17:20] 사람들이 있는 것 같아요.

[17:21] 하지만 일반적으로 취향이라는 것은 경험을 통해 기르게 되는 것이고

[17:24] 무엇이 효과적인지 배우고 실패를 경험하며

[17:27] 성공도 경험하면서 말이죠.

[17:29] AI가 점점 더 많은 코드를 작성하게 되는 세상에서

[17:33] 우리의 코드를 말이죠.

[17:33] 실제로 일부에서는 강한 반발이 있었습니다.

[17:35] 프로그래머들이 게을러질 것이라고 하거나

[17:38] 주니어 개발자들이 실제로 무엇이 필요한지

[17:41] 배울 기회를 얻지 못할 것이라는

[17:42] 대규모 코드베이스에서 작업하고 이 모든 것들을 하는 것이 어떤 것인지 말이죠.

[17:45] 이런 자동화 또는

[17:47] 이 경우에는 지원과

[17:49] 동시에 소프트웨어 엔지니어가

[17:50] 거쳐야 하는 핵심적인 엔지니어링 스킬을

[17:53] 보존하는 것 사이의 균형을

[17:54] 어떻게 생각하시는지요? 그런 시행착오들 말이죠.

[17:57] 제 생각에는 이런 도구들이 교육적으로도 매우 훌륭하고

[18:01] 훌륭한 프로그래머가 되는 데 도움이 될 수 있습니다.

[18:04] 뭔가 어떻게 작동하는지에 대한 질문이 있거나

[18:05] 어떤 개념을

[18:06] 설명해달라고 하고 싶을 때

[18:09] 이제 그냥

[18:10] Command L을 누르고

[18:11] Claude에게 물어볼 수 있어요. 이게 뭔가요?

[18:13] 어떻게 작동하나요? 설명해줄 수 있나요?

[18:15] 이것이 매우 가치 있다고 생각해요.

[18:17] 실제로 더 많은 코드를 작성하기 쉽게 만들고

[18:20] 더 많은 일을 할 수 있게 하며, 이는 높은 품질과

[18:25] 낮은 품질의 코드가 더 많이 나오는 결과를 낳을 수 있어요.

[18:27] 그것은 사실이지만, 전반적으로는 매우

[18:31] 강력한 도구이며 기준을 높일 것이라고 생각합니다.

[18:34] 품질은 빠른 반복을 통해서

[18:37] 실수를 하고

[18:39] 특정한 것들이 왜 실패하는지 알아내는 것에서 나온다고 생각해요.

[18:40] 그리고 모델들이 이 반복 과정을

[18:42] 크게 가속화하고

[18:43] 실제로 그를 통해 무엇이 효과적이고 무엇이 그렇지 않은지를

[18:46] 더 빠르게 배울 수 있게 해줄 수 있어요.

[18:47] 그래서 장기적으로는

[18:48] 개발을 시작하는 개발자들과

[18:51] 더 크고 더 큰 프로젝트를 작업하고

[18:53] 무엇이 효과적이고

[18:54] 무엇이 그렇지 않은지 알아내는 데

[18:56] 매우 도움이 되는 도구라고 생각합니다.

[18:59] 프로그래밍이 어떻게 발전할지 정말 흥미로울 것 같아요.

[19:01] 여전히 오랫동안 세부사항을 아는

[19:04] 엔지니어들이 필요할 것이라고 생각해요.

[19:07] 깊이 들어갈 수 있는 사람들 말이죠.

[19:09] 이제 프로그래밍을 배우는 사람들 중에서

[19:12] 세부사항은 많이 모르지만

[19:15] 여전히 꽤 효과적일 수 있는 사람들을

[19:17] 얼마나 보게 될지 궁금해요.

[19:19] 오늘날에는 여전히

[19:20] 많은 세부사항을 알아야 한다고 생각해요. 시간이 지나면

[19:22] 저수준 세부사항을 거의 알 필요가 없는

[19:24] 소프트웨어 엔지니어 클래스가

[19:25] 생겨나고 여전히 더 높은 수준에서 작업하며

[19:26] 아마도 좀 더 사고적인 것처럼 보일 것 같아요.

[19:28] 취향이 더 UX 취향에 가까운

[19:30] 그런 것처럼 말이죠.

[19:33] 예를 들어

[19:34] 노션 같은 것을 만들려고 한다면

[19:36] 결국에는

[19:37] 그 전체를

[19:38] 언어 모델에게 맡길 수는 없다고 생각해요.

[19:41] 이런 식으로 설명해야 해요.

[19:42] 내가 이런 타입의

[19:44] 상호작용을 할 때 이것이

[19:46] 이런 특정한 방식으로 나타나기를 기대한다고 말이죠.

[19:47] 아마도 그것을 수행하는

[19:49] 순수한 소프트웨어를 작성하는 세부사항까지는 가지 않아도 되지만

[19:51] 여전히 그런 상호작용들을 설명하고

[19:53] 그 방식을 설명하는 것

[19:54] 이것이 대략적으로 작동하는 방식입니다.

[19:55] 이것도 프로그래밍의 한 형태죠.

[19:56] - 모델 주제로 화제를 조금 바꿔보면,

[19:59] 우리가 최근에,

[20:01] 이 영상이 나올 때쯤이면,

[20:02] Claude Opus 4와

[20:04] Claude Sonnet 4가 세상에 출시될 예정입니다.

[20:06] 새로운 모델들에 대한 여러분의 생각과

[20:09] 그리고 이를 Cursor에

[20:10] 통합하는 방법에 대해 어떻게 생각하고 계신지

[20:12] - 정말로 새로운 모델들을 만족스럽게 사용하고 있습니다.

[20:15] 새로운 Sonnet을 사용해보고 정말 놀랐어요.

[20:18] 3.5가 정말 훌륭한 모델이라고 생각했거든요.

[20:21] 에이전트 코딩에서 더 뛰어났지만

[20:23] 모든 사람들이 이런 단점들이 있다는 것을 알고 있었죠.

[20:26] 조금 지나치게

[20:28] 적극적인 경향이 있었어요. - 많은 일을 하려고 했죠.

[20:30] - 네 그랬어요.

[20:32] 가끔 통과한

[20:32] 테스트를

[20:33] 바꾸려고 하기도 했죠. - 네, 맞아요.

[20:34] - Sonnet 4가 그런 문제들을 효과적으로 해결했다는 것을 발견했습니다.

[20:39] 훨씬 더 나아졌고

[20:40] 그리고 지능도

[20:41] 크게 향상되었습니다.

[20:42] 다른 모델들도 지능 면에서 개선된 것을 보셨을 텐데요.

[20:45] 에이전트 코딩만큼

[20:47] 강력하지는 않을 수 있지만

[20:49] O3가 그 예시죠.

[20:51] 그리고 우리가 발견한 것은

[20:52] 훨씬 저렴한 모델임에도 불구하고

[20:53] 그것과 대등하게 경쟁한다는 것입니다.

[20:55] 그래서 Opus에 대해

[20:56] 매우 기대하고 있습니다.

[20:58] 백그라운드에서 사용할 수 있는

[21:01] 환상적인 에이전트가 될 것이라고 생각해요.

[21:02] - 네, 테스트 작성과 과도한 적극성 문제가

[21:06] 해결되었다는 소식을 들어서

[21:07] 정말 좋네요. 이런 것들이

[21:08] 이번 모델들에서 집중적으로 해결하려고 했던 부분이거든요.

[21:10] 강화학습에서 보상 해킹이라는 개념이 있는데

[21:14] 모델들이 어떤 방법을 찾아서

[21:16] 기본적으로 지름길을 택해

[21:18] 최종 보상에 도달하려고 하는 것이죠.

[21:20] 그것을 줄이기 위해 많은 작업을 했고

[21:22] 새로운 모델들에서

[21:23] 약 80%까지 줄였다고 생각합니다.

[21:25] - 정말 궁금한 것이

[21:26] 3.5 Sonnet이 어떻게 탄생했는지인데요.

[21:29] Anthropic에서 처음으로

[21:30] 정말 좋은 코딩 모델이라는

[21:33] 강한 인상을 받았거든요.

[21:34] - 어떻게 탄생했냐고요?

[21:35] 우리가 훈련시켰습니다.

[21:37] 그냥, 좋았어요.

[21:39] 네, 우리는 한동안 알고 있었던 것 같아요.

[21:43] 아마 회사 창립 때부터

[21:45] 모델을 코딩에 정말 뛰어나게 만들고 싶었어요.

[21:47] 그것이 중요해 보였거든요.

[21:49] 다른 모든 일을 위해서도

[21:50] 특히 더 많은 모델을 만들수록 말이죠.

[21:53] 3.5 Sonnet은,

[21:56] 제 생각에는 3-Opus도

[21:57] 정말 좋은 코딩 모델이었어요.

[21:58] 당시로서는 특히 그랬죠.

[22:00] 하지만 3.5 Sonnet은 처음으로

[22:02] 정말로 강력하고 집중적인 노력을 기울여

[22:04] 모델을 코딩에 뛰어나게 만들자고 했던 것이에요.

[22:06] 단순한 코딩이 아니라

[22:07] 장기적인 관점의 코딩으로

[22:11] 앞서 대화에서 언급하신 것처럼

[22:13] 이런 일들을 해야 하는

[22:14] 다른 파일들을 편집하고

[22:17] 여기서 명령을 받아서

[22:19] 도구를 호출하고 나서

[22:20] 다른 곳에서 변경을 하는 것들 말이죠.

[22:22] 이 모든 것들을

[22:23] 하나로 결합할 수 있었던 첫 번째 모델이었습니다.

[22:25] 정말 잘 나온 것 같고

[22:28] 미래 모델들의 기반을

[22:29] 마련해 준 것 같아요.

[22:30] - 그럼 여러분들은

[22:32] 코드와 다른 영역들에 대해

[22:34] Sonnet이 뛰어나길 원하는 부분을

[22:36] 어떻게 생각하세요? - 네

[22:37] - 그리고 Opus도요.

[22:39] - 코드는 주요 영역 중 하나지만

[22:41] 유일한 영역은 아닙니다.

[22:43] 모델이 코드에서 정말 뛰어나지면

[22:45] 다른 영역으로의 전이 효과가

[22:48] 상당히 좋다고 생각해요.

[22:49] 여러 작업을 추론하고

[22:51] 에이전트 방식으로 작업하는 데

[22:54] 더 나아지거든요. 그리고 이런 효과는

[22:57] 코드가 섞여 있으면서도

[22:58] 다른 곳에서 지식을 검색하거나

[23:01] 연구를 해야 하는

[23:03] 애플리케이션을 다룰 때

[23:05] 정말 유용합니다. 일반적으로 저희는

[23:08] 모델의 한계를 최대한

[23:09] 밀어붙이는 것에 집중하고 있어요.

[23:11] 물론 안전성과 관련된

[23:12] 고려사항들이 있고

[23:13] 모델이 사용자가 원하는 것과

[23:15] 저희가 생각하는 모델의 역할에

[23:18] 부합하도록 하는 것도 중요합니다.

[23:20] 하지만 일반적으로 저희는

[23:23] 이런 모델들이 할 수 있는 것의 한계를

[23:25] 계속 밀어붙이고

[23:27] 전 세계 개발자들에게

[23:29] 모델의 역량을 보여주고 싶어요.

[23:31] 컴퓨터 사용 기능 같은 경우,

[23:33] 10월에 공개했을 때

[23:34] 저희가 정말 앞으로

[23:36] 밀어붙이고 있는

[23:38] 또 다른 방향이었어요.

[23:40] 모델이 주로 인간 인터페이스인

[23:42] 것을 실제로 탐색하는 데

[23:44] 어떻게 뛰어날 수 있는지요.

[23:45] API나 도구 호출 같은

[23:47] 세계가 아니라

[23:48] 말 그대로 인간처럼

[23:50] 이미지를 보고

[23:51] 그 화면에 행동을 취해야 하는 거죠.

[23:53] 이런 모델들의 성격에 대해서도

[23:55] 저희가 생각하는 중요한 부분이 있어요.

[23:57] 현재 Amanda Askell이

[23:59] 이 분야의 주요 연구자 중 한 명인데

[23:59] Claude의 성격을 만드는 일에

[24:01] 정말 많은 생각과 고려를

[24:03] 기울이고 있습니다. Claude가

[24:05] 어떤 느낌이어야 하고 어떻게 들려야 하는지,

[24:08] 그리고 AI가 누군가의 삶에서

[24:09] 정말 중요한 역할을 한다는 것이

[24:12] 무엇을 의미하는지요.

[24:13] 단순한 코딩 에이전트가 아니라

[24:15] 어떤 의미에서는

[24:16] 신뢰할 수 있는 동반자 같은

[24:17] 존재이자

[24:18] 많은 시간을 함께 대화할

[24:20] 대상이거든요. 그래서 이런 점들도

[24:22] 저희가 이런 모델들에 대해 내리는

[24:25] 모든 결정과

[24:26] 훈련 방식에 정말 중요한

[24:28] 요소로 작용합니다.

[24:30] - Anthropic은 전체적으로

[24:33] 소프트웨어 엔지니어링과

[24:35] 연구 측면에서

[24:36] 미래가 어떻게 될지,

[24:38] 이런 모델들이 얼마나

[24:40] 이런 작업들을 보강하고,

[24:42] 대체하고, 많은 부분을 담당할지에 대해

[24:45] 어떻게 생각하나요?

[24:46] - 네, 개인적인 의견을 말씀드리면

[24:48] 저희가 대체하지는 않을 거라고

[24:49] 생각해요. 앞서 얘기했듯이

[24:51] 이제 모델들이 있어서

[24:52] 저는 대학에서 컴퓨터공학을 전공했고

[24:55] 소프트웨어 엔지니어링을 했는데

[24:56] 이제는 모델들이

[24:58] 저보다 더 나은 코드를

[25:00] 생성한다고 느낍니다.

[25:01] 예를 들어 리트코드

[25:03] 문제 같은 것을

[25:04] 푸는 것을 생각해보면

[25:06] 제한된 환경에서

[25:07] 모델이 코드를 작성해야 할 때

[25:09] 저를 이길 것입니다.

[25:11] 하지만 저는 그 어느 때보다도 더 많은 일을 할 수 있다고 느껴요.

[25:13] 무엇이든 프로토타입을 만들 수 있고

[25:15] 데모를 엄청나게

[25:16] 빠르게 만들어서 새로운 컨셉을 보여줄 수 있어요.

[25:19] 제가 해왔던 일을 빼앗아가거나 무시하는 것이 아니라 오히려 매우 힘을 주는 느낌이에요.

[25:23] 제가 갖고 있는 소프트웨어 엔지니어링 지식 덕분에

[25:26] 실제로 훨씬 더 잘 활용할 수 있고

[25:29] 모델을 사용해서

[25:30] 더 멀리 밀어붙일 수 있어요.

[25:32] 코드가 무엇인지 전혀 모르는 상태와는

[25:34] 완전히 다르죠.

[25:35] 그런 점에서

[25:36] 흥미로운 미래 추측에

[25:38] 대해 더 이야기해보고 싶은데

[25:40] 실질적인 질문을

[25:41] 하나 해보겠습니다. 몇 년 후에

[25:44] 이 대화로 돌아와서 어떻게 되었는지 확인해볼 수 있겠네요.

[25:46] 2027년 1월 1일,

[25:49] 지금으로부터 2년도 안 되는 시점인데

[25:51] 코드의 몇 퍼센트가

[25:55] AI로 생성될 것이라고 생각하시나요?

[25:56] 그리고 이어서, 현재 자신을

[25:59] 개발자라고 생각하는 사람들의

[26:01] 일상은 어떻게 될까요?

[26:03] 제가 태어나기 전인

[26:05] 1995년의 변호사에게

[26:08] 미래에 법률 문서의

[26:09] 몇 퍼센트가 워드프로세서로

[26:11] 생성될 것인지 묻는 것과 비슷해요.

[26:16] 답은 100%입니다.

[26:19] 아니면 100%에 가깝죠.

[26:22] AI가 작성되는 거의 모든

[26:24] 코드에 관여할 것이기 때문입니다.

[26:27] 하지만 변호사나 개발자로서

[26:28] 코드가 무엇을 해야 하는지 이해하고

[26:32] 안목을 갖고

[26:34] 소프트웨어로 무엇을 할지

[26:35] 가이드하는 역할은

[26:36] 그 어느 때보다 중요해질 것입니다.

[26:39] 이미 Cursor에서는

[26:43] 90% 이상이지만

[26:44] 그것은 상당 부분이

[26:46] Agent 같은 고수준 기능을

[26:48] 사용하기 때문입니다.

[26:52] 네, Command K 같은 것들 말이죠.

[26:54] 하지만 직접 타이핑할 때도

[26:55] Tab이 타이핑하면서

[26:58] 70%를 해줍니다.

[27:00] 직접 들어가서

[27:02] 수동으로 하는 경우에도

[27:03] Tab이 여전히 대부분의 변경을 해주니까요.

[27:05] 맞아요, 실제로 타이핑하는 글자는 정말 아주

[27:09] 적은 비율이죠.

[27:10] 소프트웨어를 만드는

[27:11] 모든 측면이 어떤 식으로든

[27:14] AI를 사용하도록 바뀔 것 같아요.

[27:17] 기본적으로 소프트웨어를

[27:18] 주문형으로 만드는

[27:21] 세상이 올 것이라고 생각하세요?

[27:22] 그런 세상은 어떤 모습일까요?

[27:23] 조직의 다양한 기능을 담당하는 사람들이

[27:27] 이전에는 소프트웨어를 만들지 않았던

[27:29] 사람들이 소프트웨어를 만드는 것을

[27:31] 보게 될 것입니다.

[27:33] 예를 들어 영업팀 사람들이 자신만의 도구를 만들지 않았던

[27:35] 이전에는 예를 들어 대시보드를 구축하게 될 것입니다.

[27:37] 자신에게 중요한 것들을 추적하는 대시보드 말이죠.

[27:40] 그리고 취향이 어떻게

[27:42] 그 어느 때보다 중요해지는지로 돌아가서,

[27:44] 이제 대시보드를 구축할 수 있지만,

[27:45] 여전히 결정해야 할 것은

[27:47] 대시보드가 보여줄 지표가 무엇인지입니다.

[27:50] 그것을 결정하는 것에서 벗어나게 해주지는 않습니다.

[27:53] 더 많은 사람들이 자신만의 소프트웨어를 구축하는 것을 보게 될 것 같습니다.

[28:00] 하지만 고유한 것을 갖는 것에 병목이 될 것입니다.

[28:03] 소프트웨어로 하고 싶은

[28:05] 기존 요구사항으로는 제대로 충족되지 않는 것 말이죠.

[28:08] - 제가 사람들에게 말하고 싶은 한 가지 예는, 우리 팀에 한 사람이 있는데,

[28:11] 우리 커뮤니케이션 팀의 사람인데

[28:13] 실제로 Claude.ai에 버그 픽스를 배포하고 있습니다.

[28:16] 정말 말도 안 되는 일이죠.

[28:18] 그는 완전히 다른 조직 부서에 있고,

[28:20] 제품 개발은 전혀 건드리지 않는데

[28:21] PR을 가지고 나타나서

[28:23] 스탬프를 요청하면

[28:25] 뭘 하고 있는 거냐고 묻게 되죠.

[28:26] 그러면 그가 Claude 코드나

[28:29] Claude를 사용하는 코딩 도구를 사용해서

[28:31] 기본 모델로

[28:32] 프로덕션 코드베이스의 버그를 수정하고 있다는 거죠.

[28:36] 정말 놀라운 일이라고 생각합니다.

[28:38] 그리고 이것은 일반적인 관점으로 돌아가서,

[28:40] 취향이 있고, 좋은 직관이 있다면

[28:42] 정말 많은 것을 할 수 있게 될 것입니다.

[28:44] 그것이 세상이 계속 진보해 나가는 방식이라고 봅니다.

[28:48] 상황이 변할 것이고

[28:49] 역할들이 5년, 10년 후에는 매우 다르게 보일 것입니다.

[28:51] 하지만 일반적으로

[28:54] 저는 이런 것들로 더 많은 것을 할 수 있다면

[28:55] 그것은 항상 좋은 일이 될 것이라고 생각합니다.

[28:57] - 네, 이것이 취할 수 있는 흥미로운 경로들이 많이 있는 것 같습니다.

[28:59] 하나는 완전히

[29:01] 즉석에서 주문형 소프트웨어인데

[29:02] 제가 어떤 앱의 제 버전을 사용하면서

[29:05] 사용하는 동안

[29:06] 이 상호작용이 별로 마음에 들지 않으면

[29:10] 저를 위해 그냥 바뀌는 것이죠.

[29:12] 그것은 상상할 수 있는

[29:13] 하나의 미친 미래입니다.

[29:15] 적극적으로 하는 것이 아니라

[29:17] 단지 상호작용을 기반으로

[29:19] 소프트웨어, 무엇을 사용하든

[29:21] 당신에게 맞게 변화하는 것이죠.

[29:22] 그것은 멋진 잠재적 미래 경로입니다.

[29:24] 세상의 모든 사람이

[29:26] 원할지는 모르겠지만

[29:28] 자신만의 소프트웨어를 구축하고 싶어하는

[29:30] 사람들의 전체 규모가 그렇게 크지는 않을 수도 있습니다.

[29:33] - 맞습니다.

[29:34] - 하지만

[29:35] 자신의 필요에 맞는

[29:36] 소프트웨어로부터 혜택을 받을 수 있는

[29:37] 사람들은 잠재적으로 전 세계가 될 수 있습니다.

[29:40] - 좋습니다. 마지막으로 한 가지만

[29:41] 이것으로 마무리해 보겠습니다.

[29:43] 이것을 보고 있는 모든 분들을 위해,

[29:45] 재능 있는 엔지니어라면

[29:47] 다음 행보에 대해 고민하고 있거나

[29:50] 업계에 더 참여하고 싶어서

[29:52] 큰 회사로 갈지

[29:54] 아니면 Cursor나 Anthropic 같은

[29:56] 더 빠른 속도의 스타트업에

[29:57] 합류할지 결정하려고 한다면,

[30:00] 그런 상황에 있는 사람에게 뭐라고 말씀하시겠습니까?

[30:02] - 네, 스타트업이 요즘

[30:03] Anthropic이나 Cursor처럼

[30:05] 정말 뛰어난 인재를 확보하는 데

[30:07] 장점이 있다고 생각합니다.

[30:09] 큰 회사에 있을 때는

[30:10] 많은 사람들, 세계의 최고 인재들 중 많은 사람들이

[30:12] 그것을 덜 흥미롭게 여기죠.

[30:14] 물론 어떤 사람들은 그렇게 생각하고,

[30:15] 확실히 대기업도 훌륭한 사람들이 있지만

[30:16] 그런 인재의 밀도는

[30:18] 훨씬 낮은 경향이 있습니다.

[30:20] 스타트업에서는

[30:21] 정말 높은 인재 밀도를 얻을 수 있고

[30:22] 그것이 다른 뛰어난 동료들과

[30:24] 일하는 것을 정말 즐겁게 만듭니다.

[30:26] 이렇게 작은 팀에서

[30:28] 정말 임팩트 있는 일을 할 수 있습니다.

[30:29] 제품을 구축하고

[30:31] 세상이 소프트웨어를 작성하는 방식을

[30:33] 바꾸는 모델을 구축할 수 있습니다.

[30:35] 그리고 당신은 그 일을 하는

[30:37] 수십, 수백,

[30:38] 또는 수천 명 중 한 명이 될 수 있고

[30:40] 그것은 정말 멋진 일입니다.

[30:42] - 네.

[30:43] 정말 좋네요.

[30:44] 감사합니다.

[30:44] 정말 멋진 대화였습니다.

[30:46] - 감사합니다. - 감사합니다.