[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]
- 감사합니다.
- 감사합니다.