안녕하세요 여러분. 코드 리뷰의 죽음에 대한 세션에 참여해 주셔서 감사합니다. 코드 리뷰의 죽음에 대한 세션을 진행합니다.00:13

스케줄링 결정이 어떻게 내려지는지 아무도 모르겠지만, 스윅스는 두 세션이 연달아 진행되는 것이 재미있을 거라고 생각했나 봐요.00:21

안녕하세요, 저는 로리입니다.00:27

저는 아라이즈 AI의 개발자 관계 이사입니다. 제가 NPM Inc.를 공동 창업했던 때부터 기억하시는 분들도 있을 거예요.00:30

NPM Inc.를 공동 창업했고, 요즘은 AI와 그것을 어떻게 테스트할지에 대해 생각하고 있습니다.00:34

지금 모두가 겪고 있는 문제에 대해 이야기하려고 왔습니다.00:38

AI 에이전트의 부상은 개발자가 코드를 생성하는 속도를 엄청나게 높였지만,00:43

사람이 코드를 검토하는 속도는… 네, 지금 강연을 하고 있습니다.00:50

감사합니다. 좋은 상기시켜 주셨습니다.00:55

사람이 코드를 검토하는 속도는 그대로 유지되었고,01:00

거의 똑같고, 그게 새로운 병목 현상을 만들고 있어요01:03

모두 느끼고 있습니다. 업계의 엔지니어링 팀들이 그걸 느끼고 있죠. 그럼 우리는 뭘 할 수 있을까요?01:07

어떻게 해야 할까요? 몇 가지 옵션이 있는데, 인간 검토를 완전히 건너뛸 수도 있습니다.01:12

몇몇 사람들은 그렇게 시도하고 있어요. 신뢰성 있게 리뷰를 자동화할 수 있을까요?01:16

몇몇 사람들은 그것도 시도하고 있습니다.01:20

오늘 우리가 할 일은 제가 여러분을 위해 살펴볼 내용이 있어요01:23

현재 업계가 실제로 무엇을 하고 있는지 살펴보고, 방을 나설 때 할 수 있는 일을 알아내려고 노력할 겁니다.01:26

자, 두 개의 숫자로 시작해 봅시다. 최근01:33

세 명의 경제학자들이 10만 명이 넘는 Github 개발자를 추적했고, 그들을 매칭했어요.01:37

각자가 언제 AI를 사용하기 시작했는지 보여주는 텔레메트리와 함께 했고, 자율 에이전트를 활성화한 개발자들은01:42

에이전트는 코드 양은 741% 더 많이 작성했지만, 배포된 소프트웨어는 30%밖에 늘지 않았어요.01:49

배포량이 이것이 문제의 규모를 보여주는 거죠. 그들은 거의 8배 더 빠르게 코드를 작성하고 있었는데01:55

빠르게 코딩했지만, 실제로 배포된 소프트웨어는 세분의 일밖에 늘지 않았고, 연구 저자들은 단정적으로 말해요.02:00

리뷰가 병목이라고요. 문제는 프로덕션으로 가는 경로가 아직도 사람을 거쳐야 한다는 거예요.02:06

특히 코드 리뷰와 같은 인간의 단계는 하위 단계를 모두 막아버려요.02:12

코드를 생산하는 것은 갑자기 훨씬 저렴해졌어요. 그것을 믿을 만한지 판단하는 것은 여전히 매우 비싸죠.02:20

특히 블라스트 반경이 있는 민감한 코드를 가지고 있을수록요.02:25

어떻게 하면 두 번째 숫자를 낮춰서 우리가 배포하는 소프트웨어의 양을02:30

코딩할 수 있는 양과 맞춰야 할까요?02:34

먼저 확대해 봐요. 문제가 실제로 존재한다는 것을 분명히 해야 해요.02:38

생성 자체가 더 이상 병목이 아닙니다. 스트라이프는 올해 앤트로픽스의 Fable 출시 자료에서02:42

하루 만에 5천만 라인의 루비 코드를 마이그레이션했다고 보고했습니다.02:47

팀에서 두 달 이상 걸릴 것으로 예상했던 작업입니다.02:52

앤트로픽스의 일부가 된 번(Bun)은 6일 만에 지그(ZIG)에서 러스트로 1백만 라인 이상을 마이그레이션했다고 보고했습니다.02:57

물론 우리 모두 이 방에 있는 사람들도 작은 규모로 느끼고 있습니다.03:04

우리 에이전트가 전체 앱을 생성하고, 그냥 병합 버튼을 누르고03:09

이 코드 차이점을 읽지 않은 것에 대해 죄책감을 느끼고 잘 작동하기를 바라면서03:12

그렇게 계속할 수는 없습니다.03:18

그래서 분명한 답은, 그리고 어떤 사람들이 시도하는 답은 코드 리뷰를 더 많이 하는 것입니다.03:21

이전에 코드를 검토하고 작성하던 사람들을 데리고 그냥03:26

코드 리뷰만 계속 하세요, 이제 이것이 당신의 일입니다라고 말하지만 효과가 없어요03:30

일부로 보면 정말 지루하고 그 사람들은 금방 지쳐버리지만03:35

숫자도 그렇다고 말해요. 이 주제에 대한 가장 좋은 연구는 2년 전에03:40

시스코에서 10개월 동안 2500건의 리뷰를 진행했어요.03:46

320만 라인의 코드를 검토했고, 연구 결과에 따르면 리뷰어들은03:51

한 번 앉아서 400라인 이상을 읽으려고 하면 효과적으로 버그를 찾지 못해요.03:57

그리고 한 시간에 450라인 이상을 검토하려고 하면 효율성이 완전히 떨어져요04:02

계산해 보면04:06

그 속도로 1만 라인의 에이전트 풀 리퀘스트를 검토하려면04:12

실제 사람이 리뷰하는 데 3일에서 4일이 걸릴 거라는 거죠. 그게 바로 하나의 풀입니다.04:16

에이전트 한 개에서 요청하는 1만 라인은04:20

여러분이 많은 작업을 수행하는 에이전트에 대해 기대할 수 있는 코드 양이에요.04:28

개발자는 이제 한 번에 여러 에이전트를 실행할 수 있지만, 그렇게 하는 사람들은 좀 의심스럽다고 생각해요.04:32

그래서 그냥 더 열심히 검토할 수는 없고, 우리 모두가 그걸 느끼고 있어요.04:39

더 열심히 검토하려는 사람들이 지쳐가고 있어요. 그럼 다른 방법은 뭔가요?04:43

일부 사람들은 그냥 코드를 읽는 것을 그만두기로 결정했어요.04:48

전혀 코드를 읽지 않아야 한다고 해요. OpenClaw를 만든 피터 스타인버거가 말하길04:52

더 이상 코딩 에이전트를 프롬프트하지 마세요. 에이전트에게 프롬프트를 보내는 루프를 설계해야 해요.04:57

OpenAI의 창립 엔지니어 중 한 명인 안드레 카파시도 같은 주장을 했어요.05:02

루프에서 자신을 제거해야 한다고 말이죠. 루프에 있는 사람이 시스템을 방해하고 있어서요.05:06

하지만 이것은 트위터에 나오는 과장된 주장 이상의 의미를 갖습니다.05:13

지난 2월, OpenAI는 내부 제품을 구축하는 방법에 대한 보고서를 발표했습니다05:17

그들의 표현에 따르면 수동으로 작성된 코드가 전혀 없다고 했습니다.05:21

완전히 빈 저장소에서 시작해서 에이전트가 모든 것을 작성했습니다.05:25

5개월 후, 약 백만 줄의 코드가 있었습니다05:29

약 1,500개의 풀 리퀘스트가 병합되었고, 이를 위해 세 명의 엔지니어를 사용했습니다.05:32

에이전트가 에이전트를 검토하는 데 필요한 기본적인 구조조차도 에이전트에 의해 작성되었습니다.05:39

그들이 말하기를, 사람은 풀 리퀘스트를 검토할 수 있지만, 반드시 그래야 하는 건 아니라고 했습니다.05:44

거의 모든 리뷰 노력을 에이전트 간에 처리되도록 전환했습니다.05:51

OpenAI 실험에서 흥미로운 점은 그들이 제품이 무엇을 하는지 알려주지 않았다는 것입니다.05:56

그리고 그들은 이것이 우리의 방법이고, 여러분도 이렇게 하세요라고 말하는 오픈 소스 제품을 출시하지 않았어요.06:01

그 전략에 아직 허점이 있다는 것을 보여주네요. 음, 그런데 그래요.06:06

OpenAI에서 할 수 있다고 하면, 아마 할 수 있을 거예요.06:12

OpenAI에서는 그것이 할 수 있는 일 중 하나라고 말해요. 그곳에서의 베팅은 루프 디자인이 검토를 대체한다는 것이죠.06:19

루프가 여러분의 모든 코드를 검토할 만큼 충분히 좋을 수 있는지 여부는 무엇을06:24

루프가 볼 수 있는지에 달려있고, 그것은 엄청난 주의사항이에요.06:31

루프는 정확히 무엇을 볼 수 있으며, 코드 검토를 할 만큼 신뢰할 만한가요?06:34

수년간 업계에서 신뢰성과 품질의 대리 지표는06:40

테스트가 통과했는지였어요. 왜냐하면 그것이 벤치마크가 측정하는 것이었으니까요.06:46

올해 3월에 이전에 들어보셨을 연구 그룹인 Meter가 테스트했어요.06:49

그 지표를 직접 검증하기 위해, 오픈 소스 프로젝트의 네 명의 활동적인 유지보수자를 고용했어요.06:55

Sweebench 테스트에 사용되는 동일한 오픈 소스 프로젝트에서06:59

이미 Sweebench의 검사기를 통과한 PR들을 살펴보게 했어요.07:06

Sweebench는 이 풀 리퀘스트가 병합될 만큼 충분하다고 말했죠.07:13

그리고 오픈 소스 검토자들이 동일한 PR을 살펴보고, 정말로 병합될 만큼 괜찮은지 평가하게 했어요.07:17

결과적으로, 약 절반의 경우에만 병합할 만하다고 판단되었어요.07:22

실패 원인은 정확성이 아니었어요. 당연히 PR들은 모든 테스트를 통과하고 있었으니까요.07:27

문제는 코드 품질이었고, 다른 코드를 조용히 망치는 변경 사항들이었죠.07:32

테스트 스위트 외부의 문제들인데, Meter에서 언급하는 한 가지 주의사항은07:36

피드백을 반복할 기회가 없어서, 당연히 인간 기여자는07:42

PR이 병합되지 않을 것이라고 말받고, 다시 시도할 기회를 얻는다면07:47

다시 한 번 해볼 수 있지만, 그 예외 사항은 사실 관련이 없어요.07:50

우리의 목적과는 거리가 멀기 때문이에요. 왜냐하면 우리는 인간을 루프에서 완전히 제거할 수 있는지 확인해 보려고 하거든요.07:56

Devon 제작사인 Cognition은 유지 관리자의 실제 질문에 기반한 벤치마크를 만들었어요.08:04

병합하시겠습니까? 이걸 프론티어 코드라고 이름 붙이고 6월에 출시했어요.08:09

20명 이상이08:13

유지 관리자들이 자체 저장소에서 150개의 작업을 만들었는데, 각각 40시간 이상의 전문가의08:16

작업이었어요. 프론티어 벤치는 행동 정확성, 회귀, 안전성, 범위,08:21

규율, 테스트 품질 및 유지 관리성을 평가해요. 이것은 인간 리뷰 가이드라인을 기계가08:26

검증할 수 있도록 만들었어요. 그리고 그들이 발견한 것은 Fable 5가 삭제되었다가 다시 포함되기 전에는08:31

풀고 다시 삭제되기 전, 스위벤치 프로에서는 88% 점수를 받았지만08:36

프론티어 코드에서는 29%에 불과했어요. 같은 모델이 같은 작업으로 동일한 표면에서 5108:43

점을 덜 받습니다. 테스트를 통과하는지 여부뿐만 아니라08:48

결과를 실제로 병합할 수 있는지에 대한 질문입니다. 그리고 이건 단순히 하나의 모델이 안 좋은 날을08:54

보인 것이 아니에요. 같은 테스트 세트에서 GPT 5.5는 6% 미만의 점수를 기록했어요.09:00

그래서 현재 가장 강력한 모델들도 신뢰성 있게 사람의 코드 리뷰를 통과하기에는 훨씬 못 미쳐요.09:04

따라서 병합 가능성이 무엇을 의미하는지 누군가가 명확하게 적어야 합니다.09:10

그게 실제로 무슨 뜻인지요. 아직 그렇게 하지 못했다는 것은 분명해요.09:14

그것을 정의하는 순간, 뭔가 일어날 거예요.09:18

AI 분야의 저명한 투자자인 사라 구오는 이에 대해 썼고, 그 문제를 해결하는 것이09:22

진정한 병합 가능성이라는 벤치마크는 코딩 모델 개발의 중요한 전환점이 될 거예요.09:29

그녀가 이 주제에 대해 이야기하는 에세이에서09:35

이것에 대해 그녀는 모델들이 코드를 생성하는 속도가 왜 그렇게 빠른지 분명히 밝혔고09:37

그 이유는 컴파일러가 무료 검증기이기 때문이에요.09:43

테스트 스위트도 무료 검증기고, 저렴하게 검증할 수 있는 것은 계속해서 훈련시켜서09:46

극복할 수 있어요. 그리고 이것이 주요 모델 트레이너들에게 일어난 일이에요.09:53

따라서 병합 가능성 벤치마크를 만들 수 있다면 단순히09:57

측정이 아니라 즉시 최첨단 모델의 학습 신호가 될 거예요.10:04

유지 관리성, 범위 규율, 회귀 안전성을 의미해요.10:07

그렇게 신뢰할 수 있는 테스트를 개발하는 순간, 큰 모델들은 그것으로 훈련될 거예요.10:13

그것들을 기반으로 학습될 거예요. 그리고 오늘 리뷰 기준을 작성하는 사람이 내년에 나올 기본10:17

모델 행동을 결정짓게 될 거예요. 이미 이런 일이 벌어진 적이 있다는 선례도 있고요,10:23

즉, 2024년에 OpenAI는 모델이 작성한 코드의 버그를 잡기 위해 Critic GPT라는 모델을 학습시켰어요.10:29

사람 리뷰어가 혼자서도 모델만으로는 성능이 안 좋았어요.10:34

그래서 OpenAI는 모델을 만들었어요10:40

모델을 검토해서 학습 데이터를 정리하고, 이제 모델에 내장된 학습 신호를 만들었죠.10:43

모델이 거의 즉시 더 좋아졌어요.10:47

하지만 병합 가능성 기준은 아직10:50

미래에 있어요. 사람이 어떤 것을 고려할 때 포괄하는 좋은 기준이 없어요.10:54

병합 가능한지 결정할 때 고려해야 할 모든 것을 판단하게 해드릴게요.11:02

그렇다면 지금 실제로 자동 리뷰를 수행하는 곳은 어디인가요?11:09

한 회사에서는11:13

GitHub입니다. GitHub의 Copilot 리뷰어는 6천만 건의 리뷰를 수행했고, 현재11:15

GitHub 전체 코드 리뷰 중 5분의 1 이상을 차지하고 있어요.11:20

따라서 세계 최대 규모의 코드11:23

호스트에서 머신 리뷰는 주류가 되었고, 이는 단순한 실험이 아니라 대규모 프로덕션이고, 큰11:29

Cursor도 엄청난 양의 코드 리뷰를 하고 있어요.11:34

Cursor는 리뷰어 아키텍처를 공개해서, 그들이 어떻게 하고 있는지 알 수 있어요.11:38

세부 사항은 그 일이 무엇인지 알려주죠.11:42

첫 번째 리뷰어 버전은11:47

리뷰어는 각 변경 사항에 대해 8번의 리뷰 단계를 거친 후, 리뷰 순서를 섞어서11:48

코드 검토를 반복적으로 수행했는데, 그 리뷰 순서가 변경되었기 때문이에요.11:54

리뷰 결과에 영향을 미쳤어요. 그들은 거짓 양성을 걸러내고 있었죠.12:00

자동 리뷰어가 실제로 좋은 코드를 나쁜 것으로 표시하면 무시되기 때문이죠.12:07

좋은 코드라고 판단되면 무시될 가능성이 높아요. 그리고 이것을 하고 있는 곳이 커서뿐만이 아니에요. 관련 연구도 있어요.12:11

북경대학교의 한 팀이 이와 동일한 아이디어를 독립적으로 테스트했어요.12:18

...여러 번 리뷰 단계를 거쳐 합의된 내용을 유지했고, 그 결과 리뷰 품질을 최대12:22

44%까지 향상시켰어요.12:29

이러한 다중 단계 방식은 거짓 양성이 리뷰어의 신뢰도를 떨어뜨리기 때문에 계속해서 재발견되고 있으며, 실제로 효과가 있어요.12:30

그래서 커서는 모델이 변경 사항을 분석하고 도구를 호출하여12:38

그리고 어디를 자세히 살펴봐야 할지 결정하고, 재구축 과정에서 가장 좋았던 점은 모델에게 코드를 더 의심하라고 알려줘야 했다는 거예요.12:45

모델에게 코드에 대해 더 의심하도록 가르쳐야 했어요. 모델은 코드를 보고12:51

라고 말이죠, 음, 괜찮아 보이니 배포하자고. 인간이 그 상황에서 하듯이요.12:56

기본적으로 코드를 의심하지 말고, 뭔가 잘못됐다고 가정하라고 알려줘야 했어요.12:59

그리고 그 문장 어딘가에는 좋은 리뷰가 무엇인지에 대한 이야기가 담겨 있어요.13:06

기본적으로 의심하는 태도가 중요해요.13:10

다음으로 일어나는 일은 리뷰가 수정과 융합되기 시작한다는 거예요.13:15

수정 작업과 합쳐지기 시작했어요. 커서의 리뷰어는 자체 분석 결과를 바탕으로 수정 에이전트를 생성해서13:19

단순히 버그를 지적하는 것이 아니라 패치를 작성해서 변경 사항을 전달하고13:23

승인하는 것은 또 다른 사람이 루프에 있다는 뜻이고,13:29

loop where we don't want humans in the loop. The next thing Cursor wants to do13:34

리뷰어가 자신의 버그 보고서가 실제로 맞는지 확인하기 위해 코드를 실행하는 거예요.13:38

리뷰와 재작업 사이의 경계가 점점 얇아지고 있어요.13:42

그리고 GitHub과 Cursor는 이 게임에 참여하는 유일한 업체가 아니에요.13:48

거기 경쟁이 매우 치열해지고 있고, 관련 분야의 회사들이 정말 많아요.13:52

CodeRabbit은 가장 큰 전문 리뷰어이며, 현재 1300만 건 이상의 풀 리퀘스트를 검토했어요.13:57

Greptile은 전체 저장소의 그래프를 구축하여 리뷰어가 변경 사항이 원격 코드에 어떻게 적용되는지 볼 수 있도록 해요.14:03

Graphite은 개발자가 자신의 제안을 수락하거나 거부하는 것으로부터 평가 세트를 구축해요.14:10

하지만 주목해야 할 점은 그들 모두가 자신의 성공 정의로 동일한 지표를 사용하고 있다는 거예요.14:17

성공, 즉 인간이 제 답변을 수락하는 것인가요?14:24

커서는 이를 해결률이라고 부르며, 52%에서 70% 이상으로 끌어올렸어요.14:28

리뷰어들은 매일 대규모로 인간의 승인 판단을 통해 학습해요.14:35

그들은 인간의 승인에 따른 좋은 결과의 정의를 향해 하니스를 훈련시키고 있어요.14:39

이것은 모델들이 할 일의 미리보기인데, 이 회사들은 이미 출시했어요.14:45

현재 상태는 코드를 자동으로 생성할 수 있고, 코드를 자동으로 검토할 수 있다는 거예요.14:51

하지만 여전히 사람이 리뷰를 검토해야 해요. 그 단계를 완전히 건너뛸 수 있을까요?14:56

사람을 완전히 루프에서 벗어나게 할 수 있을까요? 지금까지 제가 들어본 바로는 두 가지 주요 프로젝트가 시도해 봤어요.15:01

지난 2월, Anthropic의 니콜라스 칼리니가 16개의 에이전트에게 Rust로 C 컴파일러를 처음부터 만들게 했어요.15:09

인간의 개입 없이 약 2,000회의 세션 동안 리눅스 커널을 컴파일할 수 있었어요.15:15

하지만 그 실험을 자세히 읽어보면 인간의 개입이 없었던 것은 사실이에요.15:21

코드가 작성되는 동안 코드를 검토하는 사람이 없었지만, 분명히 사람이 관여했어요.15:27

코드를 검토하고, 코드가 의도한 대로 작동하는지 확인하는 시스템은,15:31

모두 사람이 작성했고, 테스트 하니스와 피드백 시스템 등 모든 것들이었죠.15:36

사람이 작성해야 하는 테스트를 사용한 자동화된 테스트였고, 칼리니 자신의 경고는15:44

테스트가 통과하는 것을 보고 작업이 완료되었다고 가정하기 쉽지만, 실제로 그렇지 않다는 것이었어요.15:50

저도 이미 언급했듯이 또 다른 매우 널리 알려진 실험은15:57

간략하게 지나가듯 말했던 것은 Bun이 전체 런타임을 Zig에서 Rust로 포팅했을 때였는데, 약 백만16:01

라인의 코드를 에이전트들이 6일 동안 작성했어요. 분명히 아무도 그 diff를 읽지 않았겠죠.16:07

그 실험의 관문은 기존 테스트 스위트였어요.16:11

테스트 스위트의 99.8%가 통과했어요. 그래서 테스트는 실제로 의미 있는 작업을 수행했죠.16:15

재미있는 사실은 그 실험에 관해서16:21

에이전트들이 모든 ZIG 코드를 완료했다고 결정한 풀 리퀘스트는16:23

ZIG 코드를 전부 삭제하는 거대한 풀 리퀘스트로 제출되었는데, 다른 로봇이16:29

당신의 코드를 전부 지울 수 없는 AI 쓰레기라고 플래그를 달았어요.16:33

재미있는 일화였지만, 그 실험에는 몇 가지 중요한 주의사항이 있어요.16:37

실험에 대해 자세히 살펴본 사람이 있는데, 코드를 포팅한 결과 13,044개의16:43

비슷한 규모의 서둘러 작성된 인간 코드베이스에서는 약 74개 정도의16:48

안전하지 않은 블록이 세 배나 더 많아요.16:55

안전하지 않은 블록은 작성자가 메모리가 올바르게 처리된다고 주장하는 곳이죠, 증명하는 것이 아니에요.17:02

따라서 테스트 스위트는 공개 인터페이스에서의 동작을 인증할 수 있지만,17:08

인터페이스를 인증할 수 있을 뿐입니다. 테스트 스위트는 13,000개의 단언을 확인하도록 설계되지 않았어요.17:12

확인할 수 없죠. 그래서 인간의 개입은 확실히 배제했지만, 이제는 그들의 Rust 표면에 무엇이 숨어 있는지 알 수 없어요.17:18

결과적으로 그들의 Rust 표면에 뭐가 숨어있는지 알 수 없게 됐죠.17:24

그래서 인간 검토를 건너뛰는 데 드는 비용을 보여주기 때문에 OpenAI로 돌아가서 이 방법을 처음으로 도입했죠.17:28

검토를 삭제한 게 아니라 옮겼어요. Codex는 자체 변경 사항을 검토한 다음 더 많은 에이전트를 호출해서17:34

모든 에이전트 리뷰어가 만족할 때까지 그 검토들을 반복해서 검토하죠.17:42

OpenAI는 Codex가 모든 변경 사항마다 부팅될 수 있도록 만들어서 Codex가 실제로17:46

Codex의 복사본을 실행하고, 그것을 살펴보고, UI를 확인해서 버그가 수정되고 있는지 확인할 수 있도록 했고17:52

전체 로깅 스택을 에이전트에 노출시켰어요. 그리고 그들의 문서에 나오는 한 문장은17:58

Cisco 연구에서 말했듯이 실패할 때마다 해결책은 거의 노력하는 게 아니었다고 정확히 말하고 있어요.18:02

가끔 작동하지 않았어요. 그리고 여러분의 한 주 동안 알 수 있는 세부 사항 중 하나는 이 프로젝트에서 잠시 동안18:08

사람이 직접 AI 쓰레기를 정리하는 데 매주 금요일을 보내야 했어요.18:15

그래서 결국 확장되지 않았고, 그래서 AI 쓰레기를 찾도록 에이전트를 훈련했어요.18:20

AI 쓰레기를 없애세요, 코드 리뷰가 사라지지 않는다는 것이 교훈이에요.18:27

새로운 시스템으로 재구축되었고, 그 시스템은 사람이 만들었어요.18:35

그렇다면 사람을 완전히 건너뛸 수 있나요?18:39

실제로 시도하고 마음을 바꾼 사람이 덱스터 호르티예요.18:44

그는 6개월 동안 사람들에게 코드 리뷰하지 말라고 했어요.18:47

그는 작년에 AIE에서 유명하게 그런 말을 했어요. 코드를 바로 배포하고 에이전트가 알아서 하라고 했죠.18:50

그리고 올해 3월 무대 위에서 그는 그것을 취소했어요.18:56

그는 제가 틀렸다고 말했어요. 제발, 코드를 읽어주세요.18:59

저희는 6개월 정도 코드를 안 읽어보려고 했는데, 좋게 끝나지 않았어요.19:03

시스템의 큰 부분을 제거하고 교체해야 했어요. 이건 벤치마크가 아니에요.19:07

실제 코드로 실제 시스템에서 이 실험을 해보고 발언을 철회한 사람이에요.19:11

OpenAI는 실행했고, 결과를 경험하고 공개적으로 번복했어요.19:19

그래서 제가 이전에 언급했던 Sarah Guo의 보고서에서 왜 그런 일이 발생하는지 설명했어요.19:26

테스트를 통과했다고 해서 변경 사항이 올바른 변경 사항이라고 알려주지는 않아요.19:31

이 모듈이 세 명의 외부 사용자가 있기 때문에 존재한다고 알려주지도 않았어요.19:35

그 모듈이 존재해야 하는 이 크론 작업이 있다는 것을 알려주지도 않았어요. 아무도 작성했다고 인정하지 않을 거예요.19:41

테스트 스위트에서 찾을 수 없는 컨텍스트가 있어요.19:47

지금까지 살펴본 모든 것에서, 인간 검토 단계는 계속되고 있어요.19:53

움직이고 있지만, 예측 가능한 장소에서 살아남고 있습니다.20:00

하나는 정확성을 저렴하게 확인할 수 없는 경우이고, 다른 하나는 폭발 반경이 큰 경우입니다.20:04

보안에 민감한 환경에서는 사람들에게 인간 검토를 없앨 수 있다고 말할 때마다 즉시 거절당합니다.20:11

결과에 이름을 올릴 사람이 있는 곳이라면요. 하지만 인간의 역할이 사라지는 것은 아닙니다.20:18

스택 위로 이동하고 있어요, 어쩌면 여러20:24

스택의 여러 단계로 올라가서 코드를 직접 검사하는 것에서 시스템을 설계하고 조정하는 것으로20:27

코드를 검사하는 시스템을 설계하고, 좋은 결과의 정의를 설계하는데, 그러면 당연히 의문이 생기죠. 누가 그 시스템들을 검토하나요?20:31

리뷰 시스템을 직접 구축했다면, 리뷰어의 메타 리뷰는 어떻게 하나요?20:38

답은 예상하시는 대로, 인간이에요.20:44

앤쓰로픽은 자동화된 보안 검토기를 배포하고, 그 설명서에는 큰 주의사항이 적혀 있는데20:47

이 작업은 프롬프트 주입 공격에 대한 대비가 되어 있지 않으므로 신뢰할 수 있는 PR에만 사용해야 한다는 것이에요.20:52

신뢰할 수 있는 PR을 검토하는 데 사용해야 해요.20:57

앤쓰로픽의 코드 검토기는 자신이 검토하는 것 자체에 의해 그 결과를 번복될 수 있어요.21:00

그리고 그것은 재현된 결과라는 사실이에요.21:07

올해 3월에 진행된 연구에서 취약한 코드가 순수한 커밋 메시지로 위장되어21:09

자율 검토 에이전트를 88%의 시도에서 속였어요.21:14

동일한 시도가 인간 검토자에게 전달되었을 때는 35%의 성공률을 보였어요.21:20

인간을 루프에서 제거하면 검토자를 잃는 것뿐만 아니라 속이기 어려웠던 것을 잃게 돼요.21:26

자동화된 검토는 확신에 찬 잘못된 코드를 쉽게 받아들이고, 확신에 찬 잘못된 코드는 에이전트가 매우 잘 생성하는 코드의 일종이에요.21:33

매우 잘 생성하는 편이에요. 이거 좋고, 준비됐다고 말하죠.21:40

가끔 틀리기도 해요.21:44

또 다른 문제는 이 평가자들을 어떻게 평가할지에 대해 분야 자체가 아직 동의하지 못한다는 거예요.21:49

벤치마크 스캐폴드가 정답을 유출하는 것이 적발되기도 했어요.21:54

연구원들은 품질 검토 방법에 대해 의견이 일치하지 않아서, 결국 당신이21:56

자동화할 수 없고 건너뛸 수도 없는, 프로덕션 환경이 남아요.22:02

코드 병합 전 검토가 모두 머신으로 바뀌면, 코드가 실제로 무엇을 하는지 관찰하는 것이22:07

마지막 리뷰어가 돼요.22:12

코드가 배포되면 테스트 결과는 더 이상 흥미로운 것이 아니고, 트랙터리는22:16

시스템이 실제로 세상과 맞서 실행되었을 때 단계별로 무엇을 했는지에 대한 것예요.22:20

여기 Arize에 대한 홍보는 하지 않겠습니다. 이 컨퍼런스에는 이미 홍보가 충분해요.22:26

컨퍼런스가 많으니까요. 하지만 자동 코드 리뷰를 통해 배포한다면, 프로덕션 환경에서22:29

실제로 어떤 일을 하는지 검토하는 시스템은 필수적이에요.22:35

접근 가능해요.22:39

그래서 모든 증거를 살펴보고, 자동화된 코드 리뷰에 대해 세상이 어떻게 하고 있는지 검토한 결과,22:42

코드 리뷰는 완전히 죽은 것이 아니지만, 엄청나게 변화하고 있다는 결론에 도달했어요.22:47

엔지니어링 시스템으로 재구축되고 있어요.22:53

사람들은 코드 리뷰를 이끄는 엔진으로서 코드를 한 줄씩 읽는 역할에서22:55

줄 단위로 코드를 읽는 엔진에서 조종사 역할로 바뀌고 있는데, 처음에 말씀드린 수치를 고려하면 아마도 적절한 변화일 거예요.23:01

그 시스템의 모든 계층, 벤치마크, 분류기, 채점 기준, 테스트 스위트, 평가 등은 누군가가 결정할 때까지 검토되지 않아요.23:07

그것이 그들의 일입니다. 그리고 앞으로 몇 년간 승리할 팀은 가장 많은 코드를 생성하는 팀이 아니에요.23:14

배포한 것에 대해 왜 신뢰할 수 있는지 증거로 설명할 수 있는 팀일 거예요.23:20

그리고 제가 오늘 바로 실천할 수 있고, 가져갈 수 있는 실용적인 무언가를 드리겠다고 말씀드렸습니다.23:26

그것은 PR 검토를 중단하는 것입니다. 2026년에는 잘못된 추상화 수준이에요.23:32

사람의 판단력은 매우 중요하지만, 현재보다 훨씬 더 확장될 수 있어요.23:38

신뢰할 수 있는 검토 하니스를 구축하는 데 귀중한 시간을 쏟으세요.23:45

좋음의 정의, 회사 컨텍스트, 도메인 지식을 코딩하고, 그런 다음 에이전트가 함께 작업할 수 있도록 설정하세요.23:51

세 배 더 빠르게 진행할 수 있어요.23:59

노력을 검토자, 규칙 및 평가 스택의 상위로 집중한다면24:02

오늘 업계가 무엇을 하고 있는지 살펴보는 것이 앞으로 어떻게 해야 할지 결정하는 데 도움이 되었기를 바랍니다.24:09

무엇을 해야 할지, 다음에 무엇을 기대할 수 있을지 결정하는 데 도움이 되었기를 바랍니다. 그리고 시간 내주셔서 정말 감사합니다.24:15