안녕하세요?00:09

잘 지내시죠? 좋습니다. 제 이름은 Daksh입니다. 저는 Grubtile이라는 회사의 공동 창업자 중 한 명이에요.00:13

Grubtile입니다. 그리고 Grubtile에서는 코드 베이스의 전체 맥락을 이해하고 풀 리퀘스트를 검증하는 AI 에이전트들을 개발하고 있어요.00:18

코드 베이스의 전체 맥락으로요. Grubtile은 풀 리퀘스트가 있을 때마다00:25

에이전트 무리를 두고, 변경된 모든 파일과 관련된 파일을 살펴서00:30

버그가 있는지 확인해요. 그리고 의존성을 설치하는 샌드박스에서 코드를 실행하고00:35

로컬 호스트를 실행하고, 클릭을 통해 오류를 발생시키려 시도하며, 입력을 모의해서 코드가 망가졌는지 확인하는 모든 과정을 거쳐요.00:42

하지만 지금부터는 조금 다른 내용인 완전 자율 코딩 에이전트에 대해 이야기할게요.00:50

그래서 저는 3년 전 AI 코딩을 위해 샌프란시스코로 이사했어요.00:57

그 이유는 2022년에 출시된 GBT 3.5가 프로그래밍에 정말 능숙해 보이는 첫 번째 모델이었기 때문이에요.01:00

당시에는 코드 자동 완성, 탭 자동 완성이 코딩의 주요 패러다임이었어요.01:08

가장 흥미로웠던 것은 커서의 탭 자동 완성 기능이었고, 코 파일럿과 같은 코드 자동 완성이 있었죠.01:13

그게 바로 AI 코딩이 작동하는 방식이었어요.01:18

2024년에 처음으로 멀티 파일 편집 기능이 작동하기 시작했어요.01:22

커서가 이걸 최초로 구현했고, 이후 다른 제품들도 뒤따랐어요. 하지만 이제 AI는 처음으로 여러 파일을 동시에 편집할 수 있게 되었죠.01:27

하지만 2025년에 정말 흥미로운 일이 벌어졌는데, 자율 에이전트가 처음으로 등장했거든요.01:32

작업을 받아서 작업을 수행하고 전체 풀 리퀘스트를 한 번에 생성할 수 있었죠.01:39

그리고 지난 12월, 코딩 에이전트가 완전히 자율적으로 작동하게 되면서 중요한 전환점을 맞았어요.01:44

AI 코딩 분야에 있는 사람들은 알겠지만, 새로운 모델이 출시된 지난 12월은 AI 코딩 역사에서 분수령을 맞은 시점이 되었어요.01:50

이 제품들이 처음으로 프로그래밍 방식을 놓고 진정으로 자율성을 확보했기 때문이에요.01:56

트위터에는 에이전트가 알아서 풀 리퀘스트를 하루에 100개씩 열어버린다는 황당한 이야기들이 많았어요.02:01

가끔씩 에이전트를 다시 실행하려고 폴리파식 수면을 실험하기도 했어요.02:08

에이전트 이전부터 프로그래밍을 해본 사람으로서, 실제 회사들이 이런 방식으로 프로그래밍할 수 있을까 정말 회의적이었어요.02:14

그래서 정말 궁금했어요. 이 풀 리퀘스트가 정말로 좋은 걸까요?02:21

이게 트위터에서 떠드는 이야기일 뿐이고, 독립 개발자들이02:25

아니면 고객이 없는 작은 스타트업에서나 할 수 있는 일일까요? 하지만 실제 고객이 있고02:29

상용 가능한 코드베이스를 가진 곳은 이런 엔드투엔드 코딩 에이전트를 사용할 수 있을까요?02:36

그리고 저희 Greptile에서는 운 좋게도 대규모 회사들과 함께 일하고 있어요.02:42

NVIDIA, Coinbase, Scale, Datadog, American Express와 함께 일하고 있죠.02:46

이러한 코딩 에이전트가 대규모 회사에서도 실제로 사용되고 있는지 확인하게 되어 정말 기대했어요.02:50

그리고 실제 코딩 작업에 얼마나 유용한지도 확인해보고 싶었어요.02:56

그래서 아마추어 데이터 과학자로서 저는 저희 데이터를 분석하기로 결정했어요.03:03

저희는 매달 백만 개 이상의 풀 리퀘스트를 검토하고, 어떤 데이터가 흥미로운지 얻게 돼요.03:06

이 풀 리퀘스트들의 장단점은 무엇인지 파악합니다. 수천, 수천 개의 회사들을 위해 그래요.03:11

대부분 기업이고, 최소한 실제 고객을 가진 진지한 제품을 가진 회사들이에요.03:14

그래서 이 데이터를 분석하면 정말 흥미로운 결과를 얻을 수 있을 거라고 생각했어요.03:19

제가 검토해온 많은 풀 리퀘스트 중에서 실제로 AI가 생성한 것이 어떤 것인지 파악하는 게 놀라울 정도로 어려웠어요.03:23

by AI. It was surprisingly difficult to do this. The first thing that I tried was I started looking at the GitHub author field.03:30

깃허브에는 모든 커밋에 작성자 필드가 있어요.03:36

그래서 작성자를 확인해봤는데, 풀 리퀘스트의 1% 미만이03:39

had Codex or Claude or Cursor as the author. But it wasn't intuitive to me that only about 1% of all code was fully AI-generated.03:44

그 숫자가 훨씬 더 높을 것 같다는 느낌이 들었어요. 그래서 다른 신호를 찾아보기 시작했죠.03:51

다행히도 Claude나 Codex 같은 일부 제품들은 PR 설명란에 푸터를 남겨요.03:56

PR 설명에는 클로드 또는 커서가 공동 작성했다는 내용이 적혀 있었어요.04:01

그래서 어떤 PR이 상당 부분, 아니면 완전히 AI가 생성되었을 가능성이 있는지에 대한 신호와 데이터를 조금 더 얻을 수 있었어요.04:06

세 번째로 살펴본 것은 브랜치 이름 접두사였어요. Codex를 사용하면 Codex가 브랜치를 지정한다는 것을 알 거예요.04:13

브랜치 이름을 쓰거나 PR 설명을 쓸 때 코딩 에이전트를 사용하는 경우, 그렇게 하는 것이 합리적이라고 생각했어요.04:18

PR 설명도 작성하는 식으로 코딩 에이전트를 사용한다면, PR들이 대부분 AI가 생성한 것이라고 가정해도 괜찮다고 생각했어요.04:24

그래서 이제 풀 리퀘스트가 완전히 또는 주로 AI 생성인지 판단할 수 있는 좋은 신호들을 확보하게 되었어요.04:29

그러다 보니, Greptel에서 검토하는 모든 풀 리퀘스트 중 약 1/4이04:36

매달 검토하는 풀 리퀘스트 중 약 4분의 1이 완전히 또는 상당 부분 AI가 생성했어요.04:39

그런 다음 지난 12개월 동안 이 데이터를 되돌아보니, 그 숫자가 정말 빠르게 증가하고 있더라고요.04:46

사실 작년 초에는 생성된 풀 리퀘스트 중 1% 미만이 완전히 AI가 생성했다는 증거를 보여줬어요.04:51

모델 성능이 향상됨에 따라 이 숫자는 매우 빠르게 증가하고 있어요.04:57

흥미로운 점은 이 차트에서 새로운 모델이 출시된 시점을 알 수 없다는 거예요.05:00

진전이 매우 꾸준해 보였어요. 이런 것들이 일반적으로 빠른 속도로 경제에 확산되고 있는 것 같아요.05:05

그래서 다음 질문이 나왔어요. 모두가 자유롭게 코딩하고, 엔드투엔드 에이전트 방식으로 PR을 생성하고 있어요. 사람과 AI의 조합이 아니라 완전히 AI가 하는 거죠.05:13

질문은 이 PR들이 얼마나 쓸모 있느냐예요?05:20

첫 번째 질문은 PR이 좋다는 것은 무엇을 의미하는가였어요. AI가 생성한 PR을 평가하기 전에 답해야 할 아주 중요한 질문 같았어요.05:23

그래서 시도해 볼 수 있는 몇 가지 방법을 사용했어요. 제가 먼저 시도한 것은 되돌림 비율이었어요.05:30

풀 리퀘스트가 되돌려졌다면 아마 상태가 안 좋았을 거예요. 그래서 나쁜 풀 리퀘스트의 척도일 거라고 생각했어요.05:34

그래서 실제로 어떤 풀 리퀘스트들이 되돌려졌는지 추적하기 시작했어요.05:41

GitHub는 편리하게 되돌리기-풀 리퀘스트 번호와 풀 리퀘스트 이름으로 브랜치를 지정해요.05:46

그래서 이러한 것들이 얼마나 자주 되돌려지는지 추적할 수 있었고, 흥미로운 데이터를 발견했어요.05:51

Codex 풀 리퀘스트는 1,000개의 풀 리퀘스트 중 약 1개 정도가 되돌려졌고, Devon은 1,000개의 풀 리퀘스트 중 3과 반 개 정도가 되돌려지길 원했어요.05:56

그는 약 2과 반 개 정도에 있었고, 그래서 사람이나 제이슨트가 수행한 연구에서 풀 리퀘스트가 되돌려지는 비율 간에는 큰 차이가 없어 보였어요.06:03

on people versus agents in my study. Now, I was very skeptical of this.06:09

그리고 제가 생각하기에, 이건 아마도 사람들이 에이전트에게 더 쉽고 간단하며 범위가 잘 정의된 풀 리퀘스트 작업을 시키기 때문일 거예요.06:13

더 복잡한 작업은 사람들이 하고 있었고, 물론 복잡한 작업은 풀 리퀘스트가 더 복잡하고 표면적이 넓기 때문에 되돌려질 가능성이 높았어요.06:20

더 복잡해지고 표면적도 커서 위험 요소도 많아 보였어요. 그래서 저는 평균을 측정하기로 결정했어요.06:25

PR 크기와 되돌림 비율이 양쪽 모두 일치하는지 확인해 보려고 했어요.06:30

정말 흥미로운 데이터를 발견했어요. 사실 인간이 되돌림을 받는 PR 크기와 에이전트가 되돌림을 받는 PR 크기 사이에06:35

거의 상관관계가 없는 것 같아요.06:40

인간이 만든 PR이 에이전트가 만든 PR보다 낫다는 강력한 증거는 아닌 것 같아요.06:44

두 번째로 살펴본 신호는 Greptile의 코멘트였어요. 지금 Greptile은 이 모든 풀 리퀘스트를 검토하고 있어요.06:52

그리고 Greptile은 이 변경 사항 전체에서 P0, P1, P2를 찾아내요.06:57

Greptile이 코드에서 더 많은 버그를 발견한다면 코드가 더 나쁠 가능성이 높다고 생각했어요.07:01

그래서 이 변경 사항 전체에서 P0, P1, P2의 개수를 추적하기 시작했어요.07:07

흥미롭게도 다시 한번 큰 차이가 없었어요. 사실 저희가 테스트한 네 에이전트 중 세 에이전트가07:13

인간보다 P0를 생성하는 비율에서 더 좋은 성능을 냈어요.07:18

P0를 인간보다 적게 생성했고, P1과 P2의 경우도 마찬가지였어요.07:22

이 데이터를 보면, 사람 작성 PR과 에이전트 작성 PR의 품질이 거의 비슷했어요.07:28

그다음 세 번째 데이터를 살펴보기 시작했어요. Reptile를 사용하는 가장 일반적인 방법은07:36

풀 리퀘스트를 검토하고, 일련의 댓글을 받은 다음, 에이전트가 그 댓글을 확인하도록 하는 거예요.07:40

답변하고, 풀 리퀘스트 브랜치에 새로운 커밋을 만드는 거죠. 이게 Reptile를 사용하는 가장 일반적인 방법이에요.07:47

풀 리퀘스트의 품질이 높다면 병합되기 전에 더 적은 반복을 거치리라고 생각하는 건 합리적이에요.07:51

그래서 풀 리퀘스트가 열린 시점부터 병합될 때까지의 반복 횟수와 검토 라운드 수를 추적하기 시작했어요.07:57

역시나 차이가 거의 없었어요. Devon의 PR은 2.1.08:04

Codex PR은 2.45. 병합을 위한 검토 사이클 수에요.08:09

그리고 인간은 중간쯤에 있었어요. 다시 한번 사람 작성과 AI 생성 풀의 통계적 차이가 거의 없거나 전혀 없었어요.08:13

요청이 병합되기까지 얼마나 많은 반복을 거치느냐에 있어서08:19

에이전트가 생성한 PR이 사람이 만든 PR보다 나쁘지 않다는 강력한 증거가 없었기 때문에,08:24

질적인 차이가 있는지 궁금해졌어요. 에이전트가 실패하는 방식과 사람이 실패하는 방식이 달랐을 수도 있잖아요.08:30

그래서 저는 Greptile의 코멘트 내용을 살펴보았어요. 평균적으로 풀 리퀘스트당 약 네 개의 코멘트를 작성해요.08:37

지난 몇 달 동안 저희는 수백만 건의 코멘트 내용으로 구성된 이 코퍼스를 가지고 있었어요.08:42

그래서 저는 특정 구문이나 단어를 찾기 위해 내용을 검색하기 시작했어요. 예를 들어 SQL 인젝션이나 N+1 쿼리 같은 것들이요.08:46

그리고 저는 다양한 에이전트의 Greptile 코멘트에 이 용어들이 얼마나 자주 등장하는지 빈도를 그래프로 나타냈어요.08:53

그래서 실패 패턴을 보여주는 차트를 만들었어요.08:59

이 차트를 해석하려면 전체 차트에서 인간이 해당 유형의 오류를 발생시키는 경향을 1배라고 가정할 수 있어요.09:03

그리고 이 에이전트들이 보이는 실패 유형에 꽤 많은 차이가 있다는 것을 알 수 있잖아요.09:09

예를 들어, Claude는 인간보다 SQL 인젝션 오류를 일으킬 확률이 1.5배 더 높아요.09:16

Devon은 인간보다 오프바이패스 문제를 일으킬 확률이 약 절반 정도 돼요.09:22

이 에이전트들의 성능에 이렇게 큰 차이가 있다는 것이 매우 흥미로웠어요.09:29

그리고 그들의 실패 모드가 인간과 얼마나 달랐는지요.09:33

알고 보니, 제 초기 회의적인 시각과는 달리09:38

종단간 코딩 에이전트의 기업 활용 가능성에 대한 초기 회의감에도 불구하고, 증거는 그들이 여기 있다는 것을 시사하는 것 같아요.09:41

그리고 기업 코딩 환경에 실제로 의미 있는 방식으로 기여할 수 있을 거예요.09:48

그래서 그런 세상에서 코드 리뷰가 어떻게 이루어질지 조금 더 생각하기 시작했어요.09:54

흥미로운 통계 자료가 있어요.09:58

현재 매주 수만 명의 엔지니어가 모든 코드를 검토하기 위해 GrubTile을 사용하고 있어요.10:00

그래서 일반적으로 이 사람들이 작성하는 풀 리퀘스트의 수도 알고 있죠.10:06

평균적인 GrubTile 사용자들은 한 달에 50개의 풀 리퀘스트를 작성합니다.10:11

하루 평균 두 개 정도 되는 거죠. 90번째 백분위수는 한 달에 500개의 풀 리퀘스트를 작성합니다.10:14

평균과 P90의 차이가 엄청난데요. P99는 수천 개의 풀 리퀘스트에 달합니다.10:21

그 자체로는 그렇게 흥미롭지 않은데요. 왜냐하면 마진에 있는 사람들이 새로운 아이디어를 떠올리는 속도로 풀 리퀘스트를 생산하고 있다는 뜻이니까요.10:27

흥미롭기도 하지만, 이 코드를 검증하는 기존 시스템이 있잖아요.10:35

물론 수동 코드 리뷰가 있고, 테스트도 있고, 아마 QA 업체와 협력하고 있을 텐데, 자연스럽게 그 정도까지 확장할 수는 없죠.10:39

그리고 GrubTag에서는 정말 좋은 검증이 어떤 모습일지, 처음부터 원칙적으로 접근하기로 결정했습니다.10:47

QA 자동화나 테스트 자동화, 코드 리뷰 자동화를 목표로 하기보다는 한 발짝 물러서서10:52

말했죠. 기업 환경에서 한 달에 수백 개의 풀 리퀘스트를 병합할 수 있도록 하려면 무엇을 해야 할까요?10:57

코드가 풀 리퀘스트에 표현되고 안전하게 병합 및 배포되기까지 무엇이 필요할까요?11:04

저희는 사실 세 가지만 답하면 된다고 생각했어요. 첫 번째 질문은, 이 변경 사항이 사용자 계약을 위반하나요?11:11

두 번째는 해당 애플리케이션의 사용자 계약과 관계없이 향후 사용자 계약 위반 가능성을 높이는지 여부입니다.11:17

어플리케이션에 따라 사용자 계약을 위반할 가능성을 높이나요? 그리고 세 번째는, 작성자가 설명한 의도를 충족시키나요?11:23

풀 리퀘스트가 작성자가 원하는 작업을 수행하나요?11:28

그래서 저희는 이 문제를 가장 기본적인 수준에서 접근하기 시작했고, 에이전트는 아마도11:31

사용자 계약을 위반할지 버그를 감지할 수 있을 거예요.11:37

코드를 샌드박스에서 실행시키고, 의존성들을 설치하고, 입력을 모의하고, 브라우저 에이전트를 실행하면 아마11:41

발생할 수 있는 대부분의 문제를 발견하고 병합 시 높은 수준의 확신을 얻을 수 있을 거예요.11:47

오늘, Greptile 리뷰의 풀 리퀘스트 중 거의 20%가 사람의 검토나 테스트 없이 병합되는데, 저는 이것이 매우 흥미롭다고 생각합니다.11:53

그 숫자는 저희가 매우 중요하게 생각하며, 고품질 코드를 생산하는 안전장치 내에서 계속해서 높이고 싶어 합니다.12:00

정말 감사합니다. 저는 그럽타일의 공동 창업자 중 한 명인 Daksh입니다.12:10

저희는 부스가 있으니 방문해주세요. 그리고 그럽타일을 사용해보고 싶으시다면 grubtile.com에서 저희를 찾아보실 수 있습니다.12:13

오늘 무료로 사용해보시고 여러분의 피드백을 듣고 싶습니다. 정말 감사합니다.12:19