미래를 위한 코딩 패널

VVercel
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00(신나는 음악) - AI 코딩의 미래 패널에 오신 걸 환영합니다.
00:00:04검은 옷을 입으셔야 한다는 메모를 읽어주셔서 감사합니다.
00:00:07(웃음) 좋아요, 간단한 소개를 하고 싶어요.
00:00:12여러분 각각을 다르게 알고 있지만, 청중분들은 잘 모를 수도 있겠죠.
00:00:17Matan, 먼저 말씀해 주시겠어요?
00:00:19Factory의 AI 코딩 분야에서의 입장은 무엇인가요?
00:00:26- 네, Factory에서 우리의 미션은 소프트웨어 엔지니어링에 자율성을 가져오는 것입니다.
00:00:32더 구체적으로 말하자면,
00:00:33우리는 '드로이드'라고 불리는 엔드-투-엔드 소프트웨어 개발 에이전트를 만들었습니다.
00:00:38이들은 단순히 코딩 자체에만 집중하지 않고, 진정한 엔드-투-엔드 소프트웨어 개발 생명주기 전체를 다룹니다.
00:00:43문서화,
00:00:44테스트,
00:00:44리뷰 같은 모든 지루한 부분들을 담당하니까 당신은 코딩처럼 더 재미있는 부분에만 집중할 수 있어요.
00:00:52그리고 코딩 중에 하기 싫은 부분이 있으면 드로이드가 그것도 할 수 있죠.
00:00:56그래서 우리가 하는 일은 드로이드를 만드는 거고,
00:00:58드로이드를 만드는 거예요.
00:00:59OpenAI는 당연히 소개가 필요하겠지만,
00:01:02코덱스 팀에서의 당신의 역할은,
00:01:04코덱스 비디오에서 당신이 나타난 걸 봤거든요.
00:01:08그래서 당신이 그 작업을 하고 있다는 걸 알았어요.
00:01:10요즘 코덱스가 많이 확장되었는데, 어떻게 생각하고 계세요?
00:01:14- 네, 올해 초 우리는 첫 번째 코딩 에이전트를 출시했습니다.
00:01:19저는 코덱스 CLI를 작업했고, 우리의 추론 모델의 힘을 사람들의 컴퓨터에 가져왔습니다.
00:01:26그 다음에 코덱스 클라우드를 출시했는데, 이것으로 클라우드에서 작업을 분배하고 위임할 수 있게 되었죠.
00:01:31그리고 지난 몇 개월 동안, 우리는 이 경험들을 통합해 왔습니다.
00:01:34그래서 가능한 한 원활하게 작동하도록요.
00:01:36우리의 많은 초점은 기본 요소와 원시적 요소들을 얼마나 유용하게 만들 수 있는가에 있습니다.
00:01:41우리는 방금 개발자 행사에서 코덱스 SDK를 출시했어요.
00:01:43우리가 보고 있는 주요 방향 중 하나는 코딩이나 코드 실행 에이전트를 단순히 코딩을 위해서만 사용하는 것이 아니라,
00:01:49일반적인 목적의 작업을 위해서도 사용하는 것입니다.
00:01:52그래서 올해 초에 제가 작업했던 에이전트인 Try를 불문하고,
00:01:56실제로 백그라운드에서 코드를 실행하여 일부 작업을 완료하지만,
00:01:59우리 개발자들이 추론 모델뿐만 아니라 샌드박싱 등 코덱스에 구축한 다른 모든 원시적 요소 위에 구축할 수 있도록 시작하고 있습니다.
00:02:07- 좋네요.
00:02:09V0?
00:02:10- V0의 목표는 개발자들이 미리보기 중심의 에이전트식 프로그래밍을 하도록 하는 것입니다.
00:02:16그래서 현재 웹 앱을 만들 때,
00:02:18아마도 에이전트가 열려 있고,
00:02:19IDE가 열려 있고,
00:02:20어떤 종류의 코드가 있고,
00:02:22그리고 당신이 실제로 만드는 것의 미리보기가 있을 거예요.
00:02:25보통 개발 서버를 실행하고 있어요.
00:02:26V0를 사용하면,
00:02:27우리의 목표는 단지 에이전트를 실행하고 실행 중인 앱에 직접 프롬프트를 할 수 있도록 하는 것입니다.
00:02:32그리고 우리는 DX의 미래가 그렇게 될 것이라고 생각해요.
00:02:35- 좋아요.
00:02:36그리고 모두가 코딩 에이전트에 접근할 수 있는 서로 다른 방식을 가지고 있어요.
00:02:40그래서 우리가 시작하고 싶은 것 중 하나는 로컬 대 클라우드가 얼마나 중요한가입니다.
00:02:45당신은 로컬에서 시작해서 클라우드로 갔고,
00:02:47클라우드에서 시작해서 로컬로 갔고,
00:02:48지금은 클라우드만 하고 있어요.
00:02:50비율이 어떻게 되나요?
00:02:52결국 모두가 합쳐질 건가요?
00:02:55- 네, 제가 먼저 말씀드릴 수 있을 것 같아요.
00:02:58결국 이 에이전트들의 핵심은 가능한 한 도움이 되고,
00:03:02당신이 함께 일할 수 있는 인간과 매우 유사한 특성을 가지고 있다는 거예요.
00:03:08그리고 당신은 로컬 인간과 원격 인간을 가지지 않고 있고 그들이 뭔가 이상하게,
00:03:12이건 이 환경에서만 작동하고,
00:03:13그건 저 환경에서만 작동하는 것처럼 말이죠.
00:03:16일반적으로,
00:03:16인간은 회의에서 그들과 함께 있고 아이디어를 떠올릴 때나,
00:03:20컴퓨터 옆에 나란히 앉아 있을 때나 도움이 될 수 있습니다.
00:03:24그래서 궁극적으로 이들은 같아져야 하지만,
00:03:27단기적으로는,
00:03:28우리가 보고 있는 것은 원격은 일반적으로 당신이 안정적으로 위임할 수 있다는 더 확신하는 더 작은 작업에 더 유용한 경향이 있다는 것입니다.
00:03:39반면 로컬은 당신이 에이전트에 조금 더 가까워지고 싶을 때,
00:03:43어쩌면 어떤 더 큰 작업이나 더 복잡한 작업인데 당신이 적극적으로 모니터링할 거라는 거죠.
00:03:49그리고 당신은 그것이 로컬이기를 원해요.
00:03:51그래서 뭔가 잘못되면,
00:03:52당신은 그 분기를 다시 끌어내릴 필요가 없고 대신 당신은 그곳에 있어서 그것을 안내할 수 있어요..
00:03:57- 네, 어쩌면 제가 욕심이 많아서일 수도 있지만, 둘 다 원해요.
00:04:00그리고 Matan의 관점으로 양식을 갖는 것,
00:04:05저는 제 동료들과 협력하는 주요 형태가 무엇인지 생각하고 싶어요.
00:04:11그것이 종종 화이트보드 세션 같은 것으로 시작되고, 어쩌면 우리는 그냥 방에서 뭔가를 하고 있어요.
00:04:17우리가 만들고 있을 때,
00:04:19좋은 예는 agents.md였는데,
00:04:21이것은 다양한 코딩 에이전트 전반에 걸쳐 일반적이려고 의도된 우리의 커스텀 지침입니다.
00:04:26그것이 시작된 방식은 Romain과 제가 방에 있어서 이 아이디어를 떠올렸어요.
00:04:31그 다음에 우리는 그냥 화이트보드를 시작했고 사진을 찍었고 코덱스 CLI를 로컬로 킥오프했고,
00:04:36마치 작업할 수 있는 Next.js 앱에서의 워크숍처럼,
00:04:39점심 먹으러 갔다가 돌아왔어요.
00:04:41그것은 핵심 구조의 좋은 양을 가지고 있었어요.
00:04:44그리고 그곳에서, 우리는 조금 더 가깝게 반복할 수 있었어요.
00:04:46그래서 그런 종류의 페어링과 종류의 브레인스토밍 스타일 경험을 가지고 있는 것.
00:04:49그리고 그 다음 당신이 위임하는 작업 종류에 대한 두 번째 포인트에,
00:04:53역사적으로 더 작은,
00:04:54금전적으로 범위가 지정된 작업인데,
00:04:56당신이 산출물이 무엇인지 매우 명확한 경우,
00:04:58종류는 당신이 '불과 잊어버림'을 하고 있다면 올바른 양식입니다.
00:05:02하지만 저는 우리가 GBD5 코덱스를 약 2개월 전에 출시한 것으로 시작하는 것을 보고 있습니다.
00:05:08그리고 주요 차이점 중 하나는 실제로 더 오래 실행되고,
00:05:11더 복잡하고,
00:05:11더 모호한 작업을 할 수 있다는 거예요.
00:05:13당신이 끝에서 원하는 것에 대해 명확한 한..
00:05:16그래서 그것은 몇 시간 동안 작동할 수 있어요.
00:05:18모델이 능력이 증가함에 따라 그 전환이 더 많은 종류의 사용 케이스를 활성화하기 시작할 것이라고 생각해요.
00:05:24- 네.
00:05:24네, 에이전트가 작동하게 하는 세 가지 부분이 있다고 생각해요.
00:05:27실제 에이전트 루프가 있고,
00:05:29그것이 만드는 도구 호출이 있고,
00:05:31그 다음 도구 호출이 작용해야 하는 리소스가 있어요.
00:05:34클라우드 또는 로컬에서 먼저 가는 것은 이러한 리소스가 어디에 있는지를 기반으로 합니다.
00:05:37로컬 파일 시스템에서 작업하려고 한다면, 이것들이 당신이 접근해야 할 리소스들입니다.
00:05:41에이전트 루프가 로컬에서 실행되어야 한다는 것이 완벽하게 말이 됩니다.
00:05:44일반적으로 클라우드에 존재하는 리소스에 접근하고 있다면 GitHub에서 직접 끌어오거나 어떤 종류의 제3자 저장소에서,
00:05:50그러면 당신의 에이전트가 클라우드에서 시작하는 것이 말이 됩니다.
00:05:54궁극적으로, 이러한 리소스는 두 장소에 모두 존재해요.
00:05:57모든 개발자는 에이전트가 로컬 파일 시스템과 GitHub에서 호스팅될 수 있는 개방형 PR 모두에서 작동할 수 있기를 기대합니다.
00:06:04그래서 당신이 시작하는 곳은 중요하지 않아요.
00:06:07모두가 같은 장소에 수렴하고 있습니다.
00:06:08당신의 에이전트 루프가 어디서나 실행될 수 있어야 하고,
00:06:11당신의 도구 호출이 클라우드에서 로컬로 또는 로컬 백업에서 클라우드로 스트리밍될 수 있어야 해요..
00:06:16그리고 그 다음 그것은 모두 당신이 실제로 작용하고 싶어 하는 리소스들이 위치하는 곳에 달려 있어요.
00:06:20- 네, 좋네요.
00:06:22좋아요, 우리는 무대 뒤에서 이야기하고 있었고 자극적인 질문 같은 것들을 던지고 있었어요.
00:06:27그래서 저는 이 질문을 정말 좋아했고 제 생각엔 아주 시의적절해요.
00:06:31당신들은 생업으로 쓰레기를 생성하나요?
00:06:33그래서 우리가 아마도 과대광고 거품 속에 있을 위험에 처해 있는지
00:06:40이것이 AGI로 향하는 지속 가능한 경로라고 믿는?
00:06:44- 음,
00:06:45시작하려면,
00:06:46한 사람의 쓰레기는 다른 사람의 보물이라고 말할 수 있지,
00:06:49어느 정도까지는 그럴 수도 있어.
00:06:52예를 들어, 당신이 가지고 있다고 하죠, 모르겠지만, 전혀 문서가 없었던 저장소가 있었다고 하죠.
00:07:00당신은 우리가 이야기한 많은 도구들을 사용해서 가서 이 저장소에 대한 문서를 생성할 수 있어요.
00:07:08자, 그것이 가장 세밀하게 만들어진 문서일 건가요?
00:07:13아니, 하지만 그것이 가치를 제공하고 있나요?
00:07:16네,
00:07:16제 생각엔 그렇다는 것은,
00:07:18문서가 없는 아주 오래된 레거시 코드베이스를 뒤져야 하는 것이 약간 엉성하게 만들어진 문서를 살펴보는 것보다 훨씬 더 어렵다는 거거든요.
00:07:26그래서 나는 중요한 것은 이러한 도구들을 활용할 수 있는 곳을 파악하는 것이고,
00:07:32그것이 얼마나 쓰레기인지는,
00:07:33나는 또한 당신이 제공하는 지침의 정도에 달려 있다고 생각합니다.
00:07:38그래서 당신이 그냥 '이렇게 하는 앱을 만들어줘'라고 하면,
00:07:41당신은 아마도 어떤 일반적인 쓰레기 앱을 얻을 거고,
00:07:43-- 보라색이어요.
00:07:44- 네, 파란색, 보라색처럼 페이드, 네.
00:07:48반면에 당신이 당신이 원하는 것을 정확히 매우 체계적이라면,
00:07:52당신은 실제로 테스트를 실행할 수 있는 도구들을 제공했고 당신이 요청하는 능력들의 일부를 검증했어요.
00:07:58나는 그것이 유사한 정도로 훨씬 더 구조화되었다고 생각해요.
00:08:01당신이, 당신이 알았다면, 당신의 팀에 주니어 엔지니어를 고용하고 그냥 '이거 가서 해'라고 말했다면..
00:08:08그들은 아마도 중간 정도의 결과를 낼 거예요. 왜냐하면 그들이 갈 다른 명시는 없거든요.
00:08:14그리고 당신이 실제로 원하는 것이 정말 불명확하거든요.
00:08:19- 제 생각엔 핵심 단어는 활용이예요.
00:08:21AI 코딩 에이전트가 당신이 할 수 있도록 해주는 것은 당신이 혼자서 할 수 있는 것보다 10배 더 많이 하는 거고,
00:08:26꽤 높은 수준으로 말이죠.
00:08:27그래서 당신이 기술 수준을 에이전트가 얼마나 유용한지 또는 그것이 얼마나 가능성이 있는지에 대해 그린다면,
00:08:32당신이 알아 당신은 아마도 기술이 없다면 꽤 낮은 수준을 가지고 있을 거예요.
00:08:36당신은 아직도 꽤 높은 바닥을 가지고 있어요.
00:08:38에이전트들은 기본적으로 상당히 좋아요.
00:08:39당신이 개발에 대해 아무것도 몰라도, 에이전트는 당신이 가능한 것보다 훨씬 더 많이 할 거예요.
00:08:44하지만 당신이 더 높고 높은 기술 수준에 도달할 때,
00:08:46시니어,
00:08:47프린시팔,
00:08:47뛰어난 엔지니어들은 실제로 에이전트를 다르게 사용합니다.
00:08:50그들은 이미 할 수 있던 것들을 수준 올리는 데 사용하고 있어요.
00:08:53당신이 알다, 프린시팔 엔지니어는 수동으로 하루에 5,000줄의 코드를 쓸 수 있어요.
00:08:57에이전트를 사용하면, 그들은 하루에 50,000줄의 코드를 쓸 수 있어요.
00:09:00그리고 그것은 정말 당신이 거기에 집어넣는 입력과 지식의 품질 수준에서 작동합니다.
00:09:04그래서 나는 우리가,
00:09:06당신이 알아,
00:09:06더 나은 에이전트를 만들어서 시간이 지남에 따라 천천히 바닥을 올리고 있다고 생각해요.
00:09:11하지만 나는 그것이 활용의 한 형태라고 생각해요.
00:09:14그것은 이미 할 수 있던 것들을 가속화하는 방법이고, 더 빠르게 해요.
00:09:18그리고 기술이 없는 사람들을 위해,
00:09:19당신이 알아,
00:09:20그것은 실제로 정말 그것을 할 수 있는 바닥을 올릴 수 있어요.
00:09:23- 절대적으로, 그리고 이 두 포인트에 추가하려면, 저는 그들이 도구이고 수공예의 증폭기라고 생각해요.
00:09:29당신이 그것을 가지고 있으면, 당신은 더 많이 할 수 있어요.
00:09:31당신이 없으면, 그것은 그냥 더 어려워. 하지만 그것은 바닥을 올려요.
00:09:34저는 그것이 정말 언급할 가치가 있다고 생각해요.
00:09:36저는 첫 프로토타입을 만들려고 하는 사람들을 위해, 그들은 아이디어를 반복하려고 하고 있어요.
00:09:42앞의 예가 언급한 그 예..
00:09:44그것은 내가 콘텐츠 중심의 사이트처럼 좀 그런 프론트엔드를 만들 수 없었다는 게 아니야.
00:09:49나는 그냥 시간이 없었어..
00:09:51그리고 화이트보드에 그리고,
00:09:52이야기하고,
00:09:53대화를 나누고,
00:09:53그 다음 에이전트에 킥오프하는 것이 더 재미있었어요.
00:09:57하지만 저는 흥미로운 예 중 하나는 우리가 훨씬 더 초기 버전의 코덱스를 만들고 있었을 때 생각해요.
00:10:02일 년 이상 전..
00:10:03그리고 우리는 두 가지 다른 원형들 앞에 두고 있었어요.
00:10:07그들이 많은 제품 엔지니어링을 하는 사람들인데 로컬을 사용하는 데 익숙한 사람들,
00:10:13내부 루프 스타일 도구들인데 그들은 그냥 채팅하고 어쩌면 반복하는 데 익숙한..
00:10:19그리고 완전히 다른 양식은 우리가 추론 팀의 사람들과 이야기할 때인데 그들은 아마도 5분 동안 앉아서 작업을 정의하고 에이전트가 떠나갈 에세이 길이,
00:10:28단어 문제 같은 거를 가지고 있고,
00:10:30그리고 나서 그것은 1시간 동안 작동할 거예요.
00:10:33그리고 그것은 효과적으로 01 또는 그 이전 버전 같은 거였어요.
00:10:37그리고 흥미로운 부분은 그냥 사람들이 에이전트에 작업을 주는 방법이 그들이 필요하다고 생각하는 것에 대한 그들의 이해를 기반으로 완전히 달랐다는 거였어요.
00:10:48그래서 저는 정말 특수성에 고정하고,
00:10:50당신이 산출물이 되고 싶은 것에 대해 정말 명확하게 하는 것에 생각합니다.
00:10:55그리고 저는 더 광범위한 항목이 있다고 생각해요.
00:10:58그것은 에이전트의 빌더인 우리와 모델을 훈련하는 사람들 모두에 대한 책임인데,
00:11:02정말 그 바닥을 올리고 높은 수공예,
00:11:05높은 취향이 있는 사람들을 위한 천장이 그들이 맞다고 생각하는 방식으로 행사할 수 있도록 보장하려면..
00:11:11- 나는 실제로 당신이 언급한 무언가가 이 아이디어를 떠올렸어요.
00:11:16그래서 우리의 목표 청중은 엔터프라이즈예요.
00:11:19그리고 우리가 반복해서 보기 시작한 것은 에이전트 네이티브 개발의 채택 측면에서 매우 흥미로운 이중 양식이 있다는 거예요.
00:11:28특히, 일반적으로 초기 경력 개발자들은 에이전트 네이티브 방식으로 만들기 시작하려는 데 더 열려 있습니다.
00:11:35하지만 그들은 엔지니어링 팀을 관리한 경험이 없어요..
00:11:39그래서 그들은 어쩌면 위임하는 데 매우 익숙하지 않을 수도 있어요. 그것이 매우 잘 작동하는 방식으로.
00:11:44한편, 더 경험 많은 엔지니어들은 많은 경험이 있어요. 그들을 위임하는 데.
00:11:47그들은 알아요. 만약 내가 이 정확한 것들을 명시하지 않으면, 완료되지 않을 거야.
00:11:51그래서 그들은 정말 그 문단을 써내는 데 좋아요.
00:11:54하지만 그들은 꽤 완고하고 그들은 실제로 그들이 만드는 방식을 바꾸고 싶지 않아요.
00:11:59당신은 그들의 손이 차가울 때까지 Emacs를 그들로부터 빼앗을 거야..
00:12:03그래서 거기에 흥미로운 균형이 있어요.
00:12:05- 그렇게 말하니 재미네요.
00:12:06엔터프라이즈에서 우리가 본 비슷한 것은 시니어 엔지니어, 더 높은 곳에 있는 사람들은 티켓을 쓸 거예요.
00:12:12그래서 그들은 실제로 해야 할 일의 모든 명세를 써내는 일을 할 거예요.
00:12:16그들은 그것을 주니어 엔지니어에게 실제로 실행하도록 넘길 거예요.
00:12:18주니어 엔지니어는 그 아주 잘 쓰여진 티켓을 가져다가 에이전트에 줄 거예요. 맞죠?
00:12:21그래서 당신은 그냥 주니어 엔지니어가 실제로 에이전트 작업을 할 거라는 아이디어를 중재하고 있어요.
00:12:26왜냐하면 그들이 그것을 하는 데 더 편하거든요..
00:12:28하지만 시니어 엔지니어가 명세를 쓰는 데 정말 좋은 사람인데,
00:12:32우리가 만들어야 할 건축 결정이 무엇인지 이해하는 데 매우 좋고 그것을 어떤 종류의 티켓에 넣어요.
00:12:37- 네,
00:12:38모르시는 분들을 위해,
00:12:39Matan과 일반적으로 Factory는 에이전트 네이티브 개발 시대에 대해 쓰고 있고 옹호하고 있어요.
00:12:44그래서 당신은 그들의 웹사이트에서 더 읽을 수 있어요.
00:12:45나는 당신들을 위해 바닥을 올리는 것이 좋은 일이라고 생각해. 좋은 용어 그것이 하나를 발급하고 싶어요.
00:12:54저는 실제로 다른 사람들이 바닥을 낮춘다고도 말한다고 생각해요. 같은 의미도.
00:12:57기본적으로 그냥 기술 수준처럼 그리고 그들이 할 수 있는 것처럼 그리고 그냥 더 많은 리소스를 제공해요.
00:13:05나는 또한 다른 것을 생각해요. 일반적으로 많은 사람들이 모델 계층을 생각하고 있다는 거예요. 맞죠?
00:13:13명백하게 당신들은 당신의 자신의 모델을 소유하고, 당신들 두 명은 그렇지 않아요.
00:13:18그리고 나는 가치에서 지금 뜨거운 화제라고 생각해요.
00:13:22Airbnb의 Brian Chesky는 가치의 대부분이 Quinn에 있다고 말했어요, 명백하게.
00:13:28오픈 모델이 얼마나 중요한지, 당신들을 위해 그리고 당신도 끼어들 수 있어요.
00:13:33하지만 오픈 모델이 당신들 두 명의 전략으로 얼마나 중요합니까??
00:13:37- 나는 당신이 먼저 말해주길 궁금해.
00:13:38- 네.
00:13:38음, 오픈 모델을 좋아해요.
00:13:42제 생각엔 중요한 것 중 하나는,
00:13:44그래서 모델에 대해 이야기할 수 있다는 것,
00:13:46나는 생각해요 개방성은 정말 지속 가능한 개발 생명주기에 핵심이에요.
00:13:50코덱스 CLI를 사용해서,
00:13:52우리는 그것을 처음부터 개방 소스로 제공했고 우선순위의 일부는 오픈 모델이 내려올 것임을 이해하는 것이었어요..
00:13:58우리는 우리의 추론 모델을 사용하는 방법을 할 수 있는 한 최대한 문서화할 수 있도록 보장하고 싶었어요.
00:14:03우리는 많은 혼동을 봤어요. 도구의 종류가 뭔지, 환경이 뭐여야 하는지, 리소스.
00:14:08그래서 우리는 그것이 가능한 한 명확한지 보장하고 싶었어요.
00:14:10그리고 그 다음 오픈 모델로도 잘 작동하는지 보장하고 싶었어요..
00:14:12그래서 나는 정말 많은 사용 사례가 있다고 생각해요.
00:14:17특히 내장된 사용 사례로 들어갈 때나 데이터가 경계를 떠나고 싶지 않은 경우..
00:14:23정말 많은 좋은 이유가 있어요. 당신이 그것을 하고 싶은 이유.
00:14:26그리고 나서 나는 클라우드 호스팅 모델의 이점이라고 생각해요, 그리고 그것은 많은 오픈 모델로 보는 거예요.
00:14:33그들은 결국 장치에서 실행되지 않아요.
00:14:35하지만 그들은 어쨌든 클라우드 호스팅 되어요.
00:14:38아마도 효율성을 위해,
00:14:39아마도 비용을 위해,
00:14:40거기는 여전히 많은 가치가 있어요 그냥 순수 지능에서 훨씬 더 큰 모델을 사용하는 것..
00:14:46그리고 그것이 사람들이 O3에서 GBD5로 그리고 GBD5 코덱스로 정말 끌려가는 이유예요.
00:14:52거기는 여전히 많은 가치가 있어요.
00:14:53지금 우리는 그 초과 공급이 여전히 종류가 해결되는 것을 봅니다.
00:14:58여기서 몇 달마다 새로운, 매우 작은, 매우 인상적인 모델이 있어요..
00:15:04그리고 나는 그것이 신기하다고 생각해요.
00:15:05만약 우리가 그 해의 시작에서 고려한다면, 우리는 O3 미니를 최전선 같은 것으로 가지고 있었어요.
00:15:09그리고 우리가 지금 있는 곳..
00:15:10그래서, 네, 나는 오픈 모델에서 엄청난 가치가 있다고 생각해요.
00:15:14하지만 여전히,
00:15:15나는 개인적으로 사용 관점에서,
00:15:17클라우드 호스팅 것들을 사용하는 것에서 더 많은 가치가 있어요..
00:15:21- 네, 나는 좀 끼어들겠어요.
00:15:23포드는 실제로 개인 정보 보호, 보안, 에이전트 견고함을 많이 생각해요.
00:15:27그래서 당신이 그와 마주치면, 그에 대해 더 이야기해요.
00:15:30하지만 당신들 두 명을 위해,
00:15:32어쩌면 당신이 시작하기를 원하는 것이,
00:15:34실제로,
00:15:35당신의 각각의 앱에서 생성된 오픈 모델 토큰 백분율의 대략적인 값은 무엇일까요?
00:15:39그리고 그것이 올라갈 건가요 아니면 내려갈 건가요?
00:15:42- 그래서 나는 추측해요. 그래서 어쩌면 시작하려면, 당신이 말한 것이 정말 흥미롭다고 생각해요.
00:15:47그래서 몇 주 전에,
00:15:48우리가 우리의 factory CLI 도구를 출시했을 때,
00:15:50사람들은 정말 관심이 있었어요.
00:15:52왜냐하면 우리는 또한 Terminal Bench라고 불리는 벤치마크에서 우리의 점수와 함께 출시했거든요..
00:15:57그리고 첫 번째 요청 중 하나는 할 수 있냐는 거였어요. 당신 가이들은 오픈 소스 모델을 시험에 사용합니까?
00:16:02왜냐하면 우리의 드로이드 에이전트는 완벽하게 모델 불가지론적이거든요.
00:16:04그래서 즉시 사람들은 오픈 소스 모델을 던져라고 말했고 그것이 어떻게 하는지 보여줘.
00:16:09그리고 나는 뭔가가 특히 놀라웠다고 생각해요. 오픈 소스 모델들, 특히 GLM은 정말 정말 좋았어요.
00:16:17그들은 명백하게 최전선 모델보다 덜 성능 좋았어요. 하지만 엄청 큰 마진은 아니었어요.
00:16:24나는 그래서 한 가지 주목할 만한 것이었어요.
00:16:27우리가 오픈 소스 모델을 벤치마킹했을 때,
00:16:29맨 위의 일곱 개 중,
00:16:30하나는 당신이 정말 이 사람에 의해 미국에서 만들어졌다는 거였어요.
00:16:34나는 그것이 그런 종류의 수치라고 생각해요..
00:16:37최전선 모델의 경우 같은 것, 그것은 미국 전체에 걸쳐요.
00:16:43하지만 그 다음에 오픈 소스로 나갈 때, 우리는 정말 공을 놓치고 있어요.
00:16:47그래서 나는 그것이 한 가지 주목할 만한 일이라고 생각해요 그리고 나는 뭔가를 생각해요,
00:16:51적어도 내가 그것을 봤을 때,
00:16:53정말 그 측면에서 소집 명령이 있어야 한다고 생각했어요.
00:16:56왜냐하면 우리가 오픈 소스 모델을 위한 지원을 출시한 이후,
00:17:01오픈 소스 모델을 사용하고 있는 사람들의 백분율은 드라마틱하게 올라왔거든요.
00:17:08부분적으로 비용 때문에 그리고 당신이 알다, 그것은 당신을 허용해요.
00:17:11그래서 말해 봐요,
00:17:12문서 예제에서,
00:17:13어쩌면 당신은 문서를 생성하고 싶지만,
00:17:15당신은 그것이 어떻게 되길 원하지 않아,
00:17:17당신이 알다,
00:17:17아주 높은 추론 위에,
00:17:19최대처럼,
00:17:19당신 천 달러 비용을 들고 싶지만,
00:17:21당신은 그냥 그런 초기 첫 번째 통과를 원해요..
00:17:24그리고 또한 사람들은 조금 더 많은 통제를 갖고 싶어요.
00:17:28그리고 나는 그들이 이들 오픈 소스 모델의 일부로 그 통제의 많은 것을 얻는다고 느껴요.
00:17:34둘 다 통제하고 비용하고 그냥 그런 관찰 가능성 그것이 실제로 일어나고 있는 것..
00:17:39그래서 나는 수요가 내가 일 년 전에 기대하지 않던 지점까지 성장했다고 생각해요.
00:17:43나는 일 년 전에 나는 오픈 소스 모델에 대해 지금보다 덜 강세였다고 생각해요. 오픈 가중치, 하지만 네.
00:17:49- 네,
00:17:50나는 우리가 우리의 전체 에이전트 파이프라인에서 오픈 소스와 폐쇄 소스 모델 둘 다 사용한다고 생각해요.
00:17:55그리고 나는 그들이 LLM 호출을 위한 두 가지 다른 사용 사례가 있다고 우리가 생각하는 방식은.
00:17:58하나는 당신이 최첨단 추론을 원한다는 거예요.
00:18:01그것은 정말 정말 개방형 질문이예요.
00:18:02당신은 실제로 답이 뭔지 모르죠.
00:18:04목표는 그런, 목표 함수가 슈퍼 잘 정의되지 않은 것.
00:18:07그 경우에, 폐쇄 소스 모델은 추론과 지능을 올 때 여전히 최첨단이예요.
00:18:13우리는 거의 배타적으로 폐쇄 소스 모델을 이러한 종류의 사용 사례에 사용해요.
00:18:16두 번째 사용 사례가 있어요 우리가 더 틈새 작업을 가진 훨씬 더 명확한 목표 함수.
00:18:22이러한 경우에서, 우리는 거의 항상 오픈 소스 모델을 미세조정하려고 노력해요.
00:18:26우리는 어쩌면 추론 능력 측면에서 20% 타격을 가할 수 있다는 것에 괜찮아요.
00:18:31그래서 우리는 실제로 매우 구체적인 사용 사례를 미세조정할 수 있어요..
00:18:35그리고 우리는 오픈소스 모델들이 매우 빠르게 따라잡고 있다는 걸 발견했어요.
00:18:391년 반 전만 해도 v0의 파이프라인에 오픈소스 모델을 사용하는 것은 생각할 수 없었어요.
00:18:45지금은 파이프라인의 모든 부분에서 오픈소스 모델을 도입할 수 있을까 생각해봐요.
00:18:49지금 사용 중인 폐쇄형 최첨단 프론티어 모델을 오픈소스 모델의 파인튠으로 대체할 수 있을까 하는 거죠.
00:18:57그리고 Qwen, QEMI-K2 같은 모델들로 엄청난 성공을 거뒀어요.
00:19:02네, 이건 제가 본 가장 큰 변화 중 하나라고 생각해요.
00:19:06올해 초에 BrainTrust의 Ankur와 팟캐스트를 했는데,
00:19:10그때 오픈소스 모델 사용률이 BrainTrust에서 보기에 대략 5% 정도고 계속 떨어지고 있다고 했거든요..
00:19:17지금은 합리적으로 10에서 20% 범위로 올라갈 거라고 생각해요.
00:19:22흥미로운 건 폐쇄형 모델들도 소형 모델 개발에 더 많이 투자하고 있다는 거예요.
00:19:29Haiku, GPT-4 Mini, Gemini Flash 같은 것들 말이에요.
00:19:33이런 소형 모델 카테고리가 오픈소스와 가장 경쟁하는 분야라고 생각해요..
00:19:38소형 모델 클래스가 오픈소스 모델의 파인튠과 경쟁하는 상황이죠.
00:19:42그리고 어떤 사용 사례는 프론티어 모델을 쓰는 것 자체가 과한 경우도 있어요.
00:19:48과하다면 당연히 더 빠르고 저렴한 걸 쓰도록 유도될 수밖에 없죠..
00:19:53그런 사용 비율의 변화는 오픈소스 모델이 임계점을 넘는 순간이 있거든요.
00:20:01대부분의 작업에는 충분하고, 몇몇 틈새 작업에만 추가 성능이 필요한 거죠..
00:20:10일부 오픈소스 모델로 정말 그 수준에 도달하고 있다고 생각해요.
00:20:13그래서 앞으로 사용량이 더 늘어날 거라고 예상합니다..
00:20:16네, 정말 고무적이네요.
00:20:18남은 시간에 마지막 질문으로 이걸 여쭤보고 싶은데요.
00:20:21현재 당신의 에이전트가 못 하는데 내년에는 할 수 있기를 원하는 것 중에 뭐가 있을까요??
00:20:27제가 먼저 말할까요?
00:20:31네.
00:20:32지난 1년간 o1이 나온 때, 정확히 1년 조금 넘게 되는데, o1 프리뷰부터 지금까지 본 것들이 있어요.
00:20:43초반 체크포인트를 사용했을 때 o1은 4o 대비 낫긴 했지만 여전히 많이 부족했어요..
00:20:51당시 보안팀에 있었는데, 그 모델에 위임할 수 없는 작업들이 정말 많았어요.
00:21:00반면 지금은 2-3문장 정도에 핵심 포인트 몇 개,
00:21:05그리고 '아마 여기서 막힐 거 같은데'라고 구체적으로 알려주면,
00:21:1130분에서 1시간 후에 끝나요.
00:21:147-8시간, 거의 하루 종일 돌리는 경우도 봤어요. 저는 회의가 많아서 그렇게 긴 집중 시간이 없거든요.
00:21:26하지만 그건 엔지니어링의 절반일 뿐이에요.
00:21:30한쪽은 코딩이고, 다른 쪽은 아키텍처 설계, 트러블슈팅, 디버깅이죠.
00:21:34다른 절반은 문서 작성이고, 시스템을 이해하고, 사람들을 설득하는 거예요.
00:21:39그래서 우리가 보게 될 것은 이런 슈퍼 협력자가 될 거라고 생각해요.
00:21:46코덱이나 다른 인터페이스를 통해 제공하고 싶은 것은 이상적인 협력자죠..
00:21:53가장 먼저 찾는 사람,
00:21:55함께 아이디어를 토론하고 싶은 그 좋은 동료 같은 거,
00:21:58적어도 Claude를 통해 제공하고 싶은 게 그거예요.
00:22:02우리는 두 가지 전선에서 급속한 진전을 봤어요.
00:22:07첫 번째는 에이전트가 합리적으로 수행할 수 있고 제대로 된 결과를 얻을 수 있는 단계가 몇 개냐는 거예요.
00:22:14작년에는 1단계, 최대 3단계 정도였어요.
00:22:1790% 이상의 성공률로 안정적인 결과를 원하면 보통 1-3단계 에이전트 스텝을 실행했어요.
00:22:22지금은 대부분의 도구가 5-20단계를 실행하고도 90% 이상의 성공률로 꽤 좋은 결과를 얻어요.
00:22:29내년에는 100+,
00:22:30200+ 같은 수준으로 엄청 많은 단계를 한 번에 실행하고,
00:22:34여러 시간 동안 장시간 실행하는 작업도 자신 있게 유용한 결과를 얻을 수 있을 거라고 생각해요.
00:22:40두 번째는 소비할 수 있는 리소스에 관한 것이에요.
00:22:421년 전에는 프롬프트에 넣는 것만 가능했어요.
00:22:47지금은 MCP를 통해 외부 연결을 구성하거나 애플리케이션에서 직접 API 호출을 만들 수 있어요.
00:22:55지식이 있으면 설정을 구성할 수 있는 거죠.
00:22:58내년부터는 그냥 자동으로 될 거라고 생각해요.
00:23:00그냥 작동할 거예요.
00:23:02목표는 에이전트에게 어떤 컨텍스트를 줘야 하는지 알 필요가 없다는 거예요.
00:23:06에이전트가 직접 나가서 필요한 컨텍스트 소스를 찾을 거예요.
00:23:09이미 지금도 시작되고 있지만, 아직 정말 신뢰할 만하고 유용한지는 확신이 안 서요.
00:23:16내년쯤이면 그게 기본 모드가 될 거라고 생각해요.
00:23:18네, 저도 동의합니다.
00:23:19에이전트는 기본적으로 모든 걸 할 수 있어요.
00:23:23하지만 그걸 얼마나 신뢰할 만하고 주도적으로 하는지가 바뀔 슬라이더라고 생각해요..
00:23:29그런데 그 슬라이더는 사용자에게도 달려 있어요.
00:23:31만약 에이전트 수준에 맞추려고 행동을 바꾸지 않는 사용자라면 신뢰성과 주도성이 낮을 수 있어요.
00:23:38반면 환경을 제대로 설정하면 더 신뢰할 만하고 더 주도적으로 일할 수 있어요.
00:23:45네, 정말 좋은 말씀입니다.
00:23:46시간이 다 되었네요.
00:23:48제 분야는 컴퓨터 비전이에요.
00:23:49모두 Atlas를 써 보세요.
00:23:51더 많은 컴퓨터 비전 사용 사례를 시도해 보세요. 그리고 시간을 내주셔서 정말 감사해요.
00:23:55감사합니다.
00:23:56(관객 박수) (신나는 음악)

Key Takeaway

AI 코딩 에이전트는 개발자의 생산성을 획기적으로 향상시키고 있으며, 오픈소스와 폐쇄형 모델의 하이브리드 활용과 함께 더욱 자율적이고 신뢰할 수 있는 협력자로 진화하고 있다.

Highlights

AI 코딩 에이전트는 문서화, 테스트, 리뷰 등 반복적인 작업을 자동화하여 개발자가 더 창의적인 작업에 집중할 수 있게 함

로컬과 클라우드 환경의 선택은 작업의 특성과 리소스 위치에 따라 달라지며, 궁극적으로 두 환경이 통합될 것으로 예상됨

오픈소스 모델의 성능이 빠르게 향상되고 있으며, 비용과 제어 측면에서 폐쇄형 모델을 대체할 가능성이 높아지고 있음

에이전트 네이티브 개발에서 경력 초반 개발자와 경험 많은 개발자의 사용 패턴이 상반되는 흥미로운 양극화 현상이 나타남

AI 생성 콘텐츠의 품질은 입력된 지침의 구체성과 명확성에 크게 좌우되며, 저품질 산출물보다 부분적으로 생성된 콘텐츠가 가치 있음

올해의 주요 성과는 에이전트가 실행 가능한 단계 수가 1-3단계에서 5-20단계로 증가했으며, 내년에는 100단계 이상을 안정적으로 수행할 수 있을 것으로 예상됨

미래의 에이전트는 사용자가 수동으로 컨텍스트를 제공하지 않아도 필요한 정보를 자동으로 찾아 더 자율적으로 작동할 것으로 기대됨

Timeline

패널 소개 및 각 회사의 AI 코딩 관점

패널에 참석한 전문가들이 자신들의 조직에서 AI 코딩 에이전트 개발에 대한 관점을 소개한다. Factory의 Matan은 드로이드라는 엔드-투-엔드 소프트웨어 개발 에이전트를 만들었으며, 이는 단순 코딩을 넘어 문서화, 테스트, 리뷰 같은 전체 개발 생명주기를 다룬다고 설명한다. OpenAI의 대표자는 올해 초 첫 코딩 에이전트를 출시했으며, 코덱스 CLI, 클라우드, 그리고 최근 SDK를 통해 점진적으로 기능을 확장해왔다고 언급한다. 이러한 도구들은 개발자들이 코딩 및 코드 실행 에이전트를 일반적인 목적의 작업에도 활용할 수 있도록 설계되었다.

V0 소개 및 미리보기 중심의 에이전트식 프로그래밍

V0는 미리보기 중심의 에이전트식 프로그래밍을 목표로 하는 도구로 소개된다. 기존에는 웹 앱 개발 시 에이전트, IDE, 코드, 미리보기를 모두 열어놓고 개발 서버를 실행하는 방식이었다면, V0를 사용하면 에이전트를 실행하고 직접 실행 중인 앱에 프롬프트를 입력할 수 있다. 패널 참석자는 이러한 방식이 개발자 경험(DX)의 미래가 될 것이라고 확신하고 있으며, 이는 개발 프로세스의 효율성을 크게 향상시킬 수 있다는 점을 강조한다.

로컬 vs 클라우드: 어느 것이 더 적합한가?

패널 토론에서 로컬과 클라우드 환경의 선택에 대해 깊이 있게 논의한다. Factory의 대표자는 에이전트의 핵심이 인간처럼 도움이 되는 특성에 있으며, 로컬 인간과 원격 인간을 구분하지 않듯이 에이전트도 환경에 따라 다르게 작동해서는 안 된다고 주장한다. 단기적으로는 원격이 안정적으로 위임 가능한 작은 작업에 더 유용하고, 로컬은 에이전트를 더 가깝게 모니터링하면서 큰 또는 복잡한 작업을 수행할 때 적합하다고 설명한다. OpenAI의 대표자는 리소스 위치에 따라 선택이 결정되어야 하며, 궁극적으로 에이전트가 로컬 파일 시스템과 GitHub 모두에서 작동할 수 있어야 한다고 강조한다.

에이전트 네이티브 개발의 협업 방식과 실제 사용 사례

Factory의 대표자는 agents.md라는 커스텀 지침 개발 사례를 소개하면서, 화이트보드 세션에서 아이디어를 떠올린 후 코덱스 CLI를 로컬로 실행하여 근본적인 구조를 빠르게 구축하고 점진적으로 정제하는 과정을 설명한다. 또한 작은 범위의 명확한 산출물을 가진 작업은 '불과 잊어버림' 방식에 적합하지만, GBD5 코덱스 출시 이후로는 더 길게 실행되고 복잡하며 모호한 작업도 수행 가능해졌다고 언급한다. 모델의 능력이 증가함에 따라 더 많은 종류의 사용 사례가 활성화될 것으로 전망하고 있으며, 이는 개발 프로세스의 새로운 패러다임을 제시한다.

AI 생성 콘텐츠의 품질 논쟁: 쓰레기인가 보물인가?

패널에서 AI가 저품질 콘텐츠를 생성하는지에 대한 질문이 제기된다. Factory의 대표자는 한 사람의 쓰레기가 다른 사람의 보물일 수 있다고 언급하면서, 문서가 없던 저장소에 대해 에이전트로 자동 생성한 문서가 완벽하지는 않지만 가치를 제공한다고 설명한다. 중요한 것은 이러한 도구를 어디에 활용할지 파악하는 것이며, 제공하는 지침의 정도에 따라 결과의 품질이 크게 달라진다는 점을 강조한다. OpenAI의 대표자는 구체적이고 체계적인 요구사항을 제공하고 테스트를 실행할 수 있는 도구를 제공하면, 에이전트의 결과가 주니어 엔지니어의 중간 정도 성과와 유사할 정도로 구조화될 수 있다고 언급한다.

기술 수준별 에이전트 활용 방식의 차이

패널에서 AI 코딩 에이전트의 활용이 개발자의 기술 수준에 따라 어떻게 달라지는지를 분석한다. 기술이 없는 사람도 에이전트를 사용하면 상당히 높은 수준의 결과를 얻을 수 있으며, 이를 '바닥을 올린다'고 표현한다. 반면 시니어, 프린시팔, 뛰어난 엔지니어들은 에이전트를 다르게 활용하여 이미 할 수 있던 것들의 수준을 높이고 있다. 프린시팔 엔지니어가 수동으로 하루 5,000줄의 코드를 작성한다면, 에이전트 사용 시 하루 50,000줄의 코드를 작성할 수 있을 정도로 생산성이 향상되며, 이는 입력된 지침과 지식의 품질에 따라 결정된다고 강조한다.

엔터프라이즈 환경에서의 이중 양극화 현상

Factory의 대표자는 엔터프라이즈 환경에서 에이전트 네이티브 개발 채택에 있어 흥미로운 이중 양극화를 언급한다. 초기 경력 개발자들은 에이전트 네이티브 방식으로 만들기를 더 열려 있지만, 위임 경험이 부족하여 제대로 된 작업 위임 방식을 모를 수 있다. 반면 경험 많은 엔지니어들은 위임 경험이 풍부하고 정확한 명세 작성에 능숙하지만, 기존 방식의 변화를 거부하려는 성향이 있다. 실제 기업 환경에서는 시니어 엔지니어가 상세한 티켓을 작성하고, 주니어 엔지니어가 그것을 에이전트에 위임하는 구조로 작동하고 있으며, 이는 역할 분담의 새로운 모델을 제시한다.

오픈소스 모델의 급속한 성장과 실제 채택률 변화

패널 참석자들은 오픈소스 모델의 성능과 채택률 변화에 대해 논의한다. OpenAI의 대표자는 코덱스 CLI 출시 시 오픈소스 모델을 테스트할 수 있는 기능을 추가했으며, GLM 같은 오픈소스 모델의 성능이 생각보다 좋다고 놀라워했다고 설명한다. Factory의 대표자는 오픈소스 모델 지원을 출시한 이후 사용률이 극적으로 상승했으며, 이는 비용 절감뿐만 아니라 제어, 보안, 관찰 가능성 측면에서의 이점 때문이라고 분석한다. 일 년 전만 해도 오픈소스 모델 사용률이 약 5%였다면, 현재는 10-20% 범위로 증가했으며, 소형 모델 카테고리에서 오픈소스와 폐쇄형 소형 모델들이 경쟁하고 있는 상황이다.

폐쇄형과 오픈소스 모델의 하이브리드 활용 전략

OpenAI의 대표자는 전체 에이전트 파이프라인에서 폐쇄형과 오픈소스 모델을 모두 활용하는 전략을 설명한다. 최첨단 추론이 필요한 개방형 질문에는 폐쇄형 모델을 사용하고, 명확한 목표 함수를 가진 틈새 작업에는 오픈소스 모델을 미세조정하여 사용한다고 말한다. 추론 능력 측면에서 20% 정도 손실을 감수할 수 있다면 오픈소스 모델을 매우 구체적인 사용 사례에 맞게 조정할 수 있으며, 이를 통해 비용 효율성을 높일 수 있다. 1년 반 전에는 V0 파이프라인에서 오픈소스 모델을 사용하는 것이 불가능했지만, 지금은 Qwen, QEMI-K2 같은 모델로 파이프라인의 대부분을 대체할 수 있을 정도로 발전했다고 강조한다.

내년의 에이전트 발전 방향: 장시간 실행과 자동 컨텍스트 수집

패널은 내년에 에이전트가 달성할 수 있을 것으로 예상되는 두 가지 주요 진전을 논의한다. 첫째는 에이전트가 실행할 수 있는 단계 수의 급증으로, 작년 1-3단계에서 올해 5-20단계로 증가했으며, 내년에는 100단계 이상을 안정적으로 수행하면서 여러 시간 동안 실행할 수 있을 것으로 예상한다. 둘째는 리소스 소비 방식의 변화로, 현재는 사용자가 프롬프트에 컨텍스트를 포함시켜야 하지만, 내년에는 에이전트가 필요한 컨텍스트를 자동으로 찾아 수집할 수 있을 것으로 기대한다. 패널의 마지막 논의에서는 에이전트의 신뢰성과 자율성이 사용자의 환경 설정과 에이전트 수준에 맞춘 행동 변화에 달려 있다는 점을 강조하며, 이는 기술과 사용자 적응의 상호작용을 의미한다.

Community Posts

View all posts