혹은: 하네스만으로는 부족하다
업데이트 - 이 글의 발표 영상이 유튜브에 공개되었습니다: https://www.youtube.com/watch?v=Ib5GBkD555M
이제 루프를 돌아볼까
우리 모두는 AI 코딩을 실제 운영 환경에 도입하기 위해 경쟁하고 있습니다. 루프 엔지니어링에 대해 많은 이야기가 오갔고, 대체적인 통념은 우리가 더 많은 루프를 작성해야 한다는 것입니다.
StrongDM은 자신들의 무인 소프트웨어 팩토리에 대해 글을 썼습니다. 사람이 코드를 읽지도, 작성하지도 않는 곳이죠.
이야기의 흐름은 대략 이렇습니다:
- 당신이 병목이다.
- 모델은 충분히 좋다.
- 코드는 공짜다.
- 그냥 더 많이 배포하라.
OpenAI의 Ryan Lopopolo는 2월에 이 주제에 대해 글을 썼고, 4월에 강연을 통해 OpenAI의 소프트웨어 팩토리인 Symphony에 대해 이야기했습니다.
이 사람들은 모두 정말 똑똑하고, 저도 그들을 존경합니다. 하지만 가장 냉소적인 해석은, 이것이 그저 또 다른 벤처 캐피탈 돈을 쓰레기 대포에 퍼붓기 위한 구실에 불과하다고 보는 것입니다.
음... 좀 심각하네요
우리의 친구 Mario는 AI Engineer Europe 컨퍼런스에 나와서 우리에게 속도를 늦춰달라고 간청했습니다. 왜냐하면 코딩 에이전트 사고로 인한 장애가 발생해서는 안 될 회사들이, 글쎄... 코딩 에이전트 사고로 인한 장애를 겪고 있기 때문입니다.
Matt Pocock의 말처럼, 코드베이스가 그 어느 때보다 빠르게 무너지고 있습니다.
StrongDM의 그 무인 공장이 어떻게 돌아갔는지에 대한 명확한 데이터나 결과를 아직 찾지 못했습니다. 날씨 보고서에는 올해 2월부터 6월까지 몇 가지 드문 업데이트만 있습니다. 수정 - 7월 23일 해커 뉴스에 팀과의 대화가 있습니다 - 곧 더 공식적인 업데이트가 나올 것 같습니다!
Faros AI의 사람들은 보고서를 발표했습니다: 우리2 모두가 지난 1월과 2월에 이 AI 코딩 도구들을 사용하기 시작한 이후로, 풀 리퀘스트 리뷰 품질이 크게 떨어졌습니다.
- 더 많은 댓글, 더 긴 댓글, 그리고 리뷰 없이 병합되는 수많은 PR.
- 장애가 크게 증가했습니다.
- 개발자당 버그가 크게 증가했습니다.
이 보고서는 검증된 확실한 증거라기보다는 상관관계 신호에 가깝습니다 (네, 의도적으로 그 단어를 선택했습니다, Claude의 산문체에 대해 말하게 하지 마세요). 그리고 이 글의 핵심은 형편없는 데이터를 조심하라는 것이지만, 제가 본 것에 비추어 볼 때 대략적으로 타당하다고 느껴집니다.
"당신이 잘못 잡고 있는 겁니다" (아닙니다)
많은 사람들이 이것은 기술 부족 문제라고 말할 것입니다. 좋은 결과를 얻지 못하는 것은 당신 잘못이라는 거죠.
하지만 어떻게 잡고 있든, 저는 당신이 이런 말을 듣고 있다고 장담합니다: 토큰을 극대화하는 방식이 통하지 않는다면, 그것은 기술 부족 문제라고. 더 많은 토큰을 써야 한다고. 코드 읽기를 포기하라고. 그리고 만약 이제 막 그 단계에 도달했다면, 그것은 발전 과정의 일부라고 약속할게요. 저도 지난 여름에 이렇게 생각했습니다.
안타깝게도 제 자존심 상, "더 잘 잡는 방법"에 대해 제가 했던 멍청한 발언들이 녹화되어 지금 유튜브에서 약 100만 회의 조회수를 기록하고 있습니다. 자랑하려는 것이 아닙니다. 이것을 공유하는 이유는 제가 코딩 에이전트를 가장 잘 활용하는 방법에 대해 오랫동안 깊이 파고들었고, 많은 다른 사람들이 진정으로 유용하다고 생각하는 몇 가지를 발견했음을 알리기 위해서입니다.
어쨌든, 우리가 참아내야 했던 이 모든 온라인 "그냥 토큰을 더 써라"는 잡담의 약속은 간결하게 말하면: 충분한 하네스 엔지니어링을 통해, 우리는 두 마리 토끼를 모두 잡을 수 있다는 것입니다:
- 10배에서 100배 더 빠르고,
- 높은 품질,
- 그리고 아무도 우리 모두가 싫어하는 코드 리뷰를 할 필요가 없습니다.
우리가 해야 할 일은 더 많은 린터를 구성하고 "적대적 리뷰"와 같은 마법의 단어를 충분한 PR 리뷰 봇에 뿌리는 것뿐입니다. 그러면 우리의 소프트웨어는 장애 없이 스스로 행복하게 구축될 것입니다.
이것은 기술 부족 문제가 아닙니다
제가 여러분을 설득하려는 것은, 아무리 많은 하네스 엔지니어링이나 루프 극대화로도 근본적으로 모델 훈련 문제인 것을 해결할 수 없다는 것입니다.
이를 이해하기 위해, 저는 코딩 모델이 실제로 어떻게 훈련되고 평가되는지 파헤쳐야 했습니다. RLVR과 벤치마크 측면 모두에서 말이죠.
이 글에서 다룰 내용은 다음과 같습니다:
- 소프트웨어 팩토리는 1968년으로 거슬러 올라갑니다. 어떻게 발전해 왔으며, AI가 어떻게 변화시켰는지
- 모델이 벤치마크(심지어 새로운 "프론티어" 벤치마크)에서 만점을 받음에도 불구하고 왜 엄청난 양의 쓰레기를 생성할 수 있는지
- 그럼에도 불구하고, 코드베이스에 불을 지르지 않고도 꽤 빠르게 움직일 수 있는 방법
저는 매일 새로 등장하는 스킬 플러그인과 AI 정신병-토큰극대화 조언 전염병에 대한 과대광고를 뚫고, 특정 스킬이나 프레임워크를 언급하지 않고 작동하는 유형의 것들에 대해 일반적인 용어로 이야기하려고 합니다.
비디오 버전: 이 글은 AI Engineer World's Fair 2026에서의 제 기조 연설을 기반으로 (그리고 확장하여) 작성되었습니다.
이 글에 대한 피드백을 주신 @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, @jeffreyhuber 님께 감사드립니다.
참고: 이것은 바이브 코딩과 아무 관련이 없습니다
Addy Osmani는 강조할 가치가 있는 이 문제를 정리했습니다:
열두 명 정도만 사용할 사이드 프로젝트를 바이브 코딩하는 개발자와, 10년 된 엔터프라이즈 시스템을 다음 분기까지 유지보수해야 하는 팀은, 이름을 붙일 가치가 있는 거의 공통된 제약 조건을 공유하지 않습니다. 그리고 유통되고 있는 조언의 대부분은 실제로 두 사람 중 한 명이 다른 사람에게 어떻게 살아야 하는지 말하는 것입니다.
바이브 코딩을 좋아한다면, 계속 바이브 하세요. 저도 여전히 많은 것을 바이브 코딩합니다. 하지만 저는 또한 많은 프로덕션 소프트웨어를 유지보수하고 (그리고 HumanLayer를 통해 수천 명의 다른 엔지니어들이 그렇게 하도록 돕습니다), 따라서 나머지 부분은 복잡한 코드베이스에서 어려운 문제를 해결하는 사람들을 위한 것입니다.
저는 이 분할에 대해 브라운필드라는 단어를 많이 듣습니다. 역사적으로 이것은 10년 된 Java 무언가를 의미했지만, 우리가 지금 배포할 수 있는 속도로 볼 때, 에이전트가 구축한 코드베이스는 아마 3~6개월 후에 문제가 생기기 시작하는 것 같습니다. 속도가 느려지기 시작하고, 새로운 것을 추가하는 접근 방식을 바꿔야 합니다.
소프트웨어 팩토리의 간략한 역사
저는 평생 소프트웨어 팩토리를 구축하고 연구해 왔지만, 이 용어가 1968년 NATO 컨퍼런스까지 거슬러 올라간다는 것을 최근에야 알게 되었습니다. 바로 그 컨퍼런스에서 "소프트웨어 엔지니어링"이라는 용어가 나왔습니다.
그 이후로 제가 매우 흥미롭게 생각하는 유일한 다른 부분은 미국 국방부가 31페이지 분량의 PDF를 작성하여 DoD가 Jenkins를 더 잘 사용해야 한다거나 뭐 그런 내용을 작성했다는 것입니다.
2022년의 소프트웨어 팩토리
AI 직전인 2022년을 기준으로 "소프트웨어 팩토리"의 정의를 내려봅시다. 일반적인 소프트웨어 팩토리에서는:
- 사람들이 무엇을 만들지 결정합니다 -- 비전을 주도하는 엔지니어, PM, 리더십
- 트래커에 들어갑니다 -- Linear, Jira 등: 수행해야 할 작업의 상태 머신
- 누군가 티켓을 가져가서 빌드합니다 -- 아마도 그 과정에서 수동/자동 테스트를 수행할 것입니다
- 풀 리퀘스트 -- 자동 검사, 사람이 코드 리뷰, 누군가 테스트를 위해 내려받을 수도 있습니다
- 문제가 있나요? "누군가가 빌드" 단계로 다시 루프
- 프로덕션에 배포 -- 그리고 사용자와 접촉합니다
- 모니터링 추가 -- 문제가 생겼을 때 오전 3시에 엔지니어를 호출하는 산업 전체가 있습니다
- 사용자가 불평합니다 -- 기능을 요청하고, 버그를 찾고, 기능 요청을 제출합니다 → 다시 팀으로 돌아가 트래커에 추가
그리고 계속됩니다. 아직 AI를 만나지도 않았는데도, 이 그림에는 이미 여러 개의 루프가 있습니다.
정렬을 사전에 처리하기
수십 년 전에 팀들이 알아낸 것이 있습니다: 빌드하는 데는 몇 시간 또는 며칠이 걸리고, 리뷰도 마찬가지입니다.
그래서 우리는 작업을 사전에 처리합니다 -- 계획, 아키텍처 제안, 스프린트 계획을 팀 전체가 함께 합니다. 즉:
- 재작업이 줄어듭니다, 코드를 작성하기 전에 정렬했기 때문입니다
- 모든 줄을 리뷰하는 시간이 줄어듭니다, 길지만 잘 작성된 PR을 읽어본 적이 있다면, 거의 완벽에 가까울 때 리뷰가 얼마나 빨리 진행되는지 알 것입니다
이것에 대해서는 나중에 다시 다루겠습니다. 에이전틱 코딩이 도입되면 어떤 일이 발생하는지 살펴보겠습니다.
에이전틱 소프트웨어 팩토리
이제 모든 회사와 그들의 모회사들이 --
올해 대부분의 시간을 자신들이 약 75%의 코드를 배송하는 에이전트 팩토리를 구축한 방법을 설명하는 데 보냈습니다.
에이전틱 팩토리는 대부분 "누군가가 빌드" → "에이전트가 빌드" 를 바꾸는 것과 같습니다. 여기에는 오케스트레이션, 하네스, 샌드박스, 모델, 컴퓨터 사용 등과 같은 것들이 있습니다. 저는 그 세부 사항에 대해 깊이 들어가지 않겠습니다. 솔직히 말해서 읽는 것도 지겹고, 여러분도 마찬가지일 것이라고 확신하기 때문입니다.
에이전트가 무언가를 빌드할 때:
- 빌드 시간이 몇 시간 또는 며칠에서 몇 분 또는 몇 시간으로 단축됩니다.
- 리뷰는 여전히 몇 시간 또는 며칠이 걸립니다. 사람이 여전히 코드를 읽고 변경 사항을 테스트해야 합니다. 따라서 리뷰가 이제 병목이 됩니다.
그래서 리뷰 속도도 높입니다:
- 에이전틱 코드 리뷰를 통해 스타일, 버그, 보안을 잡아냅니다.
- 에이전틱 회귀 테스트를 통해 브라우저와 컴퓨터 사용으로 외부에서 찔러보고 완료되면 귀여운 작은 비디오를 보내줄 수도 있습니다.
리뷰가 더 빨라졌지만, 여전히 병목일 가능성이 높습니다. 하지만 더 많은 루프를 만들 수 있습니다.
다음으로 장애를 팩토리로 라우팅할 수 있습니다. 오전 3시에 누군가를 호출하는 대신, 이미 수정되었을 수도 있는 PR과 함께 일어납니다.
또한 사용자 피드백을 팩토리로 라우팅할 수 있습니다. 사람들이 무언가를 요청하면, 그것이 구축됩니다.
이 시점에서 작업은 두 가지 질문으로 귀결됩니다: 얼마나 많은 것을 큐에 넣을 수 있는지, 그리고 나오는 것을 얼마나 빨리 리뷰하고 테스트할 수 있는지입니다.
이것이 우리를 무인 소프트웨어 팩토리로 이끕니다.
무인 소프트웨어 팩토리
Dan Shapiro가 이 용어를 만들었고 Simon Willison이 StrongDM의 구현에 대해 글을 썼습니다. 우리는 더 이상 코드를 읽지 않습니다.
아름다운 소프트웨어 팩토리를 바라봅니다. 그 성가신 작은 코드 리뷰 단계 때문에 망가졌고, 당신은 이렇게 말합니다: 있잖아, 사람이 모든 변경 사항을 읽는 그거? 사양이야.
그래서 그것을 버리고, 노력을 다른 곳에 투자합니다:
- 테스트에 투자하고 에이전트가 자신의 작업을 테스트하도록 합니다
- 샌드박스와 오케스트레이션에 투자합니다
- 자동 리뷰에 투자합니다
- 모니터링에 투자합니다
- 롤아웃에 투자합니다
- 사용자로부터 피드백 신호를 수집하는 데 투자합니다
이제 작업은 정말로 하나의 질문입니다: 에이전트에게 얼마나 많은 것을 요청할 수 있을까요? 바다를 얼마나 끓이고 싶을까요?
이것은 잘 될 것입니다 (아닙니다)
저는 잠재적으로 논란의 여지가 있는 주장을 하나 해보려고 합니다: 무인 팩토리는 작동하지 않습니다.
소프트웨어 팩토리가 실패하는 이유에 대해 알아보겠습니다.
우리는 이것을 시도했습니다
2025년 7월, 우리는 완전 무인 운영을 시작했습니다. 명세서와 티켓만 읽고, 모든 소규모/중간 규모 작업에 백그라운드 에이전트를 사용하는 방식이었습니다.
이것을 몇 달 동안 진지하게 시도해 보셨다면, 결과가 어떻게 끝나는지 이미 아실 것입니다. 에이전트가 해결할 수 없는, 최소한 하나의 까다로운 문제를 발견하게 됩니다. 가장 진보된 프롬프트와 워크플로우를 사용해도 말이죠.
- 심층적인 컨텍스트 인식 연구를 수행하여, 모델이 분석할 수 있도록 올바른 모든 부분을 스마트 존으로 수집합니다
- 에이전트가 10가지 다른 방법으로 재현을 시도하게 합니다
결국에는 세 달 전에 읽기를 중단한 코드베이스로 직접 들어가서 무엇이 고장났는지 파악해야 합니다.
그리고 그 동안:
- 사이트가 다운되었습니다.
- 사용자들이 화가 났습니다.
- 그리고 저는, 여러분이 저와 조금이라도 비슷하다면, 시스템에 들어오도록 놔둔 모든 쓰레기 코드를 읽으면서 비참했습니다.
이런 일이 처음 발생했을 때, 저는 털어냈습니다. Claude의 스파게티 코드를 거의 2주 동안 파헤치는 데 시간을 보냈음에도 불구하고, "하방 위험은 속도만큼 가치가 있었다"고 생각했습니다. 11월에 세 번째 정도 발생했을 때, 우리는 처음부터 다시 작성하는 것이 더 쉬울 것이라고 결정했고, 공동 창업자는 무려 2주 동안 VS Code (Cursor조차 사용하지 않고)에서 모든 패턴을 손으로 직접 구현했습니다.
모델은 시간이 지남에 따라 코드베이스 품질을 저하시킵니다
제가 말하고자 하는 것은 이것입니다: 모델에는 단점이 있습니다. 모델은 시간이 지남에 따라 코드베이스 품질을 유지하고 개선할 수 없습니다. 상당한 양의 인간의 개입 없이는 말이죠.4
제가 유지보수성이라고 말할 때, 코드베이스의 한 부분을 변경하는 것이 다른 부분을 망가뜨리지 않고는 정말, 정말 어려워지는 특정 상황을 의미합니다. 이것이 Martin Fowler의 샷건 수술입니다.
유지보수성에 대해 더 이상 많이 말하지는 않겠습니다. 이에 대해 읽을 수 있는 책들이 많이 있습니다:
그렇다면, 왜 모델은 소프트웨어 유지보수성을 수행할 수 없을까요?
"하지만 분명히 모델은 그 이후로 훨씬 더 좋아졌을 거야"
이쯤에서 당신은 이렇게 말하고 싶을지도 모릅니다: 하지만 Dex, 분명히 모델은 7월 이후로 훨씬 더 좋아졌을 거야
어떤 면에서는 그렇습니다. 다른 면에서는 거의 비슷합니다.
- 일회성 문제를 해결하거나, 새로운 마케팅 사이트를 바이브 코딩하는 것? 네. 훨씬 더 좋아졌습니다.
- 시간이 지남에 따라 코드베이스 품질을 개선하는 것? 제가 알기로는, 별로 좋아지지 않았습니다.
저는 이것을 증명할 수 없습니다. 당신도 증명할 수 없습니다. 모델의 코드베이스 품질 유지 능력에 대한 좋은 벤치마크는 없습니다. (이것이 어디로 가고 있는지에 대해서는 나중에 더 자세히 다루겠습니다.)
모델의 코드베이스 품질 유지 능력에 대한 좋은 벤치마크는 없습니다
하지만 당신이 코딩 에이전트와 함께 일한 지 꽤 되었다면 -- 그리고 많은 사람들이 정확히 이것에 대해 글을 올리고 있습니다 -- 아마 이미 느낌이 있을 것입니다: 에이전트는 시간이 지남에 따라 상황을 더 악화시키는 경향이 있고, 코드베이스에서 작업하기를 더 어렵게 만듭니다.
그래서 왜 이런 일이 발생하는지 알아내기 위해, 저는 첫 번째 위대한 코딩 에이전트로 시야를 넓히고 싶습니다.
Claude Code가 승리한 이유: 하네스 내부의 강화 학습
Claude Code는 1년도 안 되어 매출이 거의 $4B에서 약 $9B로 성장했습니다.
이것은 약간 황당한데, 이미 훌륭한 CLI 에이전트가 있었기 때문입니다. aider, cline, codebuff -- 모두 Claude Code보다 먼저 나왔고, 모두 진정으로 훌륭한 컨텍스트 엔지니어링이 내장되어 있었으며, Claude Code의 특징으로 생각할 수 있는 것과 동일한 도구 세트를 가지고 있었습니다: 읽기, 쓰기, 편집, grep, bash. 저는 그것들을 사용했습니다. 좋았습니다. 하지만 도구 사용이... 가끔 실패했습니다. 같은 편집을 세 번 시도하는 모습을 지켜보고 에디터를 다시 열어 직접 해야 했습니다.
2024년의 SWE-Agent 논문은 도구 모양의 작은 변화가 눈에 띄는 차이를 만든다고 설명합니다. 예를 들어, ReadFile 결과에 줄 번호를 포함하거나, 편집 도구를 찾기/바꾸기에서 줄 범위 편집으로 변경하는 것 등이 있습니다.
그런 다음 Claude Code가 출시되었고 매우 빠르게 수직 상승했습니다. 이것을 유통 채널의 힘으로 치부할 수 있지만, 정설로 받아들여지는 설명은 Claude Code가 더 나았기 때문에 승리했고, 더 나은 이유는 Anthropic이 하네스 내부에서 모델을 RL(강화 학습)했기 때문이라는 것입니다. 이것은 실험실이 모델을 출시할 정확한 도구에 대해 처음으로 훈련시킨 사례였습니다. 그리고 그 도구들을 에이전틱 루프에서 호출하는 데 정말, 정말 능숙해졌습니다.
도구 정의와 평가를 조정하여 모델이 가장 선호하는 형태를 찾는 것은 한 가지 일입니다. 저는 다양한 사용 사례를 위해 이것을 하는 데 몇 주를 소비했습니다. 가중치를 소유하고 특정 도구 세트에 더 능숙하도록 모델 자체를 수정할 수 있는 것은 완전히 다른 게임입니다.
OpenAI 팀은 11월에 강연에서 이것을 꽤 잘 설명했습니다: 하네스를 구축하지만 가중치를 소유하지 않고 그 안에서 모델을 RL할 수 없다면, 둘 다 소유한 팀에게 항상 불리할 것입니다.
60초 만에 알아보는 코딩 에이전트 RL
저는 이 주제에 대해 많은 연구를 수행하고 중요한 부분을 설명하기 위해 많은 시각 자료를 만들었지만, Calvin French-Owen (codex 팀의 MTS, Segment의 창업자)이 AI Council에서 한 강연이 훨씬 더 잘하고 깔끔하게 설명했기 때문에, 그의 슬라이드에서 영감을 받은 이 애니메이션을 여기에 올리겠습니다:
코딩에 더 나은 모델을 만들기 위해서는 다음을 수행할 것입니다:
- 문제를 해결하기 위해 (예: 내 테스트 수정) 몇 가지 코딩 에이전트 트레이스를 생성합니다
- 일부 기준(검증기)에 따라 트레이스에 점수를 매깁니다
- 좋은 트레이스의 가능성은 높이고, 나쁜 트레이스의 가능성은 낮추도록 모델 가중치를 업데이트합니다
그리고 몇 주 또는 몇 달에 걸쳐 수백만 번 이것을 수행합니다.
그러나 이러한 것들의 "점수 매기기" 부분은 변덕스럽게 1차원적인 경향이 있습니다.
나쁜 설계에 대한 패널티는 없습니다
SWE-bench Multilingual을 예로 들어보겠습니다. 작업은 작습니다. 각각 약 15분 정도의 작업량이며, Redis, jq, Django와 같은 오픈 소스 저장소에서 추출되었습니다. 보상은 다음을 기반으로 1 또는 0입니다:
- FAIL_TO_PASS - 요청받은 것을 수정했습니까?
- PASS_TO_PASS - 다른 것을 망가뜨리지 않고 수정했습니까?
다음은 실제 예시입니다. Ruby 프로젝트인 fastlane의 fastlane__fastlane-19304입니다. zip 액션은 두 개의 선택적 매개변수를 가져와서 바로 .empty?를 호출하므로, include와 exclude를 생략하는 순간 오류가 발생합니다:
이 특정 이슈를 해결한 인간의 수정은 두 줄입니다 (nil을 빈 배열로 기본 설정):
평가 중에 모델은
- 기본 커밋에서 시작합니다. 수정이 적용되기 직전 시점의 저장소입니다.
- 버그 보고서 - 이 경우 'zip_command': undefined method 'empty?' for nil:NilClass
에이전트는 이슈를 기반으로 코드를 작성합니다. 채점 기준이 되는 황금 패치나 테스트 패치는 보지 않습니다:
그런 다음:
- 생성된 패치는 유지하고,
- 테스트 파일에 대한 편집 내용은 모두 폐기합니다 (모델이 조용히 실패하는 테스트를 주석 처리하거나 테스트를 무용지물로 만드는 목업을 삽입하는 것을 발견했습니다)
- 벤치마크의 테스트 패치를 그 위에 적용하고,
- 전체 스위트를 실행합니다: 기존 zip 테스트(PASS_TO_PASS)와 새 테스트(FAIL_TO_PASS)를 실행하여 둘 다 통과하는지 확인합니다
참고 - 벤치마크는 검증기가 아닙니다. 실제로는 서로 분리되어야 합니다 (테스트 세트로 훈련하지 마세요, 어쩌고 저쩌고). 저는 주로 "코딩 에이전트 트레이스의 품질을 판단하는 것"과 그 한계의 형태를 전달하려는 의미입니다.
모델이 올바른 답에 어떻게 도달했는지는 중요하지 않습니다. 테스트가 통과하면 승리하지만, 코드베이스 유지보수성을 훼손하는 것에 대한 패널티는 없습니다.
코드베이스 유지보수성을 훼손하는 것에 대한 패널티는 없습니다.
그래서 모든 것에 try-catch를 붙이는 결과가 나옵니다:
품질 검증은 "테스트 통과 여부"보다 몇 배는 더 어렵습니다
테스트를 실행하면 깔끔한 합격 또는 불합격이 ~초 만에 나옵니다. 이것이 RL이 각 모델 세대를 최적화하기 위해 수백만 개의 루프를 실행할 수 있는 이유입니다.
하지만 나쁜 아키텍처의 비용 함수는 몇 주, 몇 달, 심지어 몇 년 단위로 측정됩니다. 이것은 누군가가 한 줄 변경을 위해 그 파일을 열었을 때, 한 줄로 변경할 수 없다는 것을 깨닫는 첫 번째 순간에 발생합니다. 누군가가 이것을 너무 열심히 바이브해서, 이제 열한 곳에서 동일한 편집을 해야 하고, 세 개의 파일을 넘어 조용히 아무것도 망가뜨리지 않기를 바라는 상황을 말합니다.
테스트는 몇 초 안에 피드백을 주지만, 나쁜 아키텍처의 비용 함수는 몇 주, 몇 달, 심지어 몇 년 단위로 측정됩니다
나쁜 설계는 오늘날의 벤치마크가 평가할 수 없는 유일한 것입니다. 그리고 저도 압니다, RL != 벤치마크라는 것을. 하지만 이것이 RL에서 해결되었다면, 우리의 벤치마크 설계 방식에도 나타나기 시작할 것이라고 확신합니다.
어쨌든, 저는 오늘날의 벤치마크에 대한 어떤 개선도 모델이 갑자기 코드베이스를 엉망으로 만들지 않는 데 능숙해졌다는 지표로 개인적으로 신뢰하지 않습니다.
프론티어는 천천히 나아지고 있습니다
물론 많은 똑똑한 사람들이 이 문제를 해결하기 위해 노력하고 있습니다. 제 요점은 이것이 불가능하다는 것이 아니라, 과대광고가 규율을 앞지르고 있다는 것입니다.
올바른 방향으로 가고 있다고 생각되는 몇 가지 노력은 다음과 같습니다:
- SWE-Marathon (Abundant AI): "Excel의 모든 기능을 복제하라"와 같은 ~400시간 작업 -- 단일 합격/불합격 비트 대신 복합 보상 채널 사용
- DeepSWE (Datacurve): 실제 세계에서 구축된 적이 없는 OSS 저장소의 대규모 작업. 따라서 구조상 훈련 세트에 이미 존재할 수 없습니다 (오염 문제는 해결하지만 품질 문제는 해결하지 못함)
- Frontier Code (Cognition): 다중 PR 작업, 그리고 결정론적으로 품질을 평가하는 영리한 방법 -- 패치 전 코드에서 실패하지 않는 테스트를 작성하는 모델에 패널티를 부과합니다 (돌연변이 테스트에 대해 들어본 적이 없다면 재미있는 시간을 보낼 것입니다5). 또한 diff에 대해 코드 품질 규칙을 확인하는 심판 모델을 실행합니다.
하지만 심판 모델이 품질을 판단하는 데는 한계가 있습니다.
사실, 모델이 좋은 코드와 나쁜 코드를 확실히 구분할 수 있다면 처음부터 좋은 버전을 작성했을 거라고 상상하는 것은 어렵지 않습니다. RL 은 빠르고 신뢰할 수 있는 오라클이 필요하지만, 유지보수성에 대해서는 아직 그런 오라클이 없습니다.
모델이 좋은 코드와 나쁜 코드를 확실히 구분할 수 있다면 처음부터 좋은 버전을 작성했을 테지만, 유지보수성에는 빠른 오라클이 없기 때문에 RL 중에 이에 대해 보상할 수 없습니다.
물론, 더 많은 리뷰 에이전트와 더 많은 토큰은 도움이 됩니다. 바닥을 높여서 기본적인 실수를 잡아주니까요.
하지만 천장을 움직이지는 못합니다. 천장은 RL 에서 모델에게 가르친 것에 의해 결정되기 때문이며, 좋은 디자인은 아직 가르치는 방법을 모르는 영역이기 때문입니다.
그래서 저는 여전히 이 중 어떤 것에도 제 코드베이스를 걸지 않을 것입니다. 하지만 이것들은 통과/실패에서 멈추지 않고 유지보수성을 평가하려는 첫 번째 평가 도구들입니다.
참고 미래의 모델이 이것을 이해해서 우리가 멈출 수 있을지도 모릅니다. GPT-7 이 출시될 때까지 프롬프트를 마구 던져보고 싶다면, 마음대로 하세요. 하지만 bitter lesson 은 잠시 접어두고, 지금 우리에게는 해결해야 할 문제가 있으며, 저는 그 해결 방법을 설명하려고 합니다.
다시 불을 켜며
오늘 알게 된 사실인데, Twitter Articles 에는 "미디어 제한"이 있어서 나머지 내용은 2부 포스트로 이어집니다. 계속 지켜봐 주세요.
