# 소프트웨어 팩토리가 실패하는 이유 또는: 하네스만으로는 충분하지 않다 업데이트 — 이 글을 바탕으로 한 발표 영상이 유튜브에 공개됐다. [https://www.youtube.com/watch?v=Ib5GBkD555M](https://www.youtube.com/watch?v=Ib5GBkD555M) 시리즈 1부이다. 2부는 여기에서 볼 수 있다. [https://x.com/dexhorthy/status/2081058573556306030](https://x.com/dexhorthy/status/2081058573556306030) 3부는 여기에서 볼 수 있다. [https://x.com/dexhorthy/status/2081797628552270027](https://x.com/dexhorthy/status/2081797628552270027) 이제는 루프를 돌리는 게 대세인가 보다. 모두가 AI 코딩을 프로덕션에 도입하려고 경쟁하고 있다. 루프 엔지니어링(loop engineering)에 관한 이야기도 이미 많이 나왔다. 현재 지배적인 견해는 아마 루프를 더 많이 작성해야 한다는 것이다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080398568976945152) [스트롱DM은 사람은 코드를 읽지도 쓰지도 않는 완전 자동화 소프트웨어 팩토리(lights-off software factory)를 소개했다.](https://factory.strongdm.ai/) 그 주장은 대략 다음과 같다. 1. 병목은 바로 당신이다. 2. 모델은 이미 충분히 뛰어나다. 3. 코드는 공짜다. 4. 더 많이 출시하기만 하면 된다. 오픈AI의 [라이언 로포폴로](https://x.com/_lopopolo)는 [2월에 이 주제를 다룬 글을 썼고](https://openai.com/index/harness-engineering/), [4월에는 오픈AI의 소프트웨어 팩토리인 심포니(Symphony)에 관해 발표했다.](https://www.youtube.com/watch?v=am_oeAoUhew) 이 사람들은 모두 정말 똑똑하다. 나도 이들을 대단히 존경한다. 하지만 가장 냉소적으로 보자면, 이 역시 벤처캐피털 자금을 엉터리 코드 대포에 더 많이 쏟아붓기 위한 또 하나의 핑계라고 할 수 있다. ## 음... 잘 돌아가고는 있다 우리의 친구 [마리오](https://x.com/badlogicgames)는 AI 엔지니어 유럽(AI Engineer Europe) 무대에 올라 [속도를 늦춰 달라고 간청했다.](https://www.youtube.com/watch?v=RjfbvDXpFls) 코딩 에이전트의 실수 때문에 장애가 발생해서는 안 될 회사들에서 실제로 [그런 장애가 발생하고 있기 때문이다.](https://www.ft.com/content/00c282de-ed14-4acd-a948-bc8d6bdb339d) [맷 포콕](https://x.com/mattpocockuk)의 표현대로라면, [코드베이스는 그 어느 때보다 빠르게 무너지고 있다.](https://www.youtube.com/watch?v=3MP8D-mdheA) 스트롱DM의 다크 팩토리(dark factory)가 결국 어떻게 됐는지 보여 주는 확실한 데이터나 조사 결과는 찾지 못했다. [상황 보고서(weather report)](https://factory.strongdm.ai/weather-report)에는 올해 2월부터 6월까지 드문드문 업데이트가 올라와 있다. 수정: [7월 23일 해커 뉴스에서 팀과 나눈 대화가 있다.](https://news.ycombinator.com/item?id=49026625) 조만간 좀 더 공식적인 업데이트가 나올 듯하다. [파로스 AI 연구진](https://www.faros.ai/research/ai-acceleration-whiplash)은 보고서를 발표했다. 우리 모두가 지난 1~2월부터 AI 코딩 도구를 쓰기 시작한 뒤로 풀 리퀘스트 검토의 품질이 크게 떨어졌다는 내용이다. * 댓글은 더 많고 길어졌으며, 검토를 전혀 거치지 않고 병합되는 PR도 아주 많아졌다. * 장애가 크게 늘었다. * 개발자 한 명당 버그 수도 대폭 증가했다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080398814389923840) 이 보고서는 검증 가능한 결정적 증거라기보다 상관관계를 보여 주는 신호에 가깝다. 그렇다. 일부러 그 표현을 골랐다. 클로드식 문체에 관해서는 말도 꺼내지 마라. 이 글의 요점 자체가 엉터리 데이터를 경계하자는 것이기도 하다. 그래도 내가 본 것에 비추어 보면 전체적인 방향은 맞는 듯하다. ## “잘못 잡고 있다”(You're holding it wrong)고? 그렇지 않다 많은 사람이 이것을 실력 문제라고 말할 것이다. 좋은 결과가 나오지 않는다면 당신 탓이라는 이야기다. 하지만 대체 그것을 어떻게 ‘잡고’ 있든, 토큰을 최대한 쏟아붓는 방식(token-maxxing)이 효과가 없다면 실력 문제라는 말을 틀림없이 듣게 된다. 토큰을 더 많이 써야 한다고 한다. 코드를 읽으려 하지 말라고도 한다. 이제 막 이런 단계에 들어섰다면 장담하건대 이것도 과정의 일부다. [지난여름에는 나도 이렇게 생각했다.](https://hlyr.dev/ace) 내 자존심에는 불행한 일이지만, 내가 “더 잘 잡는 법”에 관해 떠들었던 어리석은 이야기 중 일부가 영상으로 남았다. 지금은 유튜브 누적 조회 수가 약 100만 회에 이른다. 자랑하려는 의도는 아니다. 나는 오랫동안 코딩 에이전트를 가장 잘 이용하는 방법을 깊이 파고들었고, 실제로 많은 사람에게 도움이 된 몇 가지를 발견했다는 점을 밝히려는 것뿐이다. * [코딩 에이전트를 위한 고급 컨텍스트 엔지니어링(Advanced Context Engineering for Coding Agents)](https://hlyr.dev/ace) * [감으로 하지 마라 — 복잡한 코드베이스에서 어려운 문제 해결하기(No Vibes Allowed — Solving Hard Problems in Complex Codebases)](https://hlyr.dev/nva) * [RPI에 관해 우리가 완전히 잘못 알았던 것(Everything We Got Wrong About RPI)](https://hlyr.dev/qrspi-mlops) 어쨌든 우리가 온라인에서 억지로 들어야 했던 “토큰을 더 세게 밀어 넣어라”라는 수많은 헛소리의 약속은 간단히 요약할 수 있다. 하네스 엔지니어링(harness engineering)을 충분히 하면 다음 장점을 모두 얻는다는 것이다. * 10~100배 빠른 속도 * 높은 품질 * 모두가 싫어하는 코드 검토라는 일을 아무도 하지 않아도 됨 린터를 더 많이 설정하고 수많은 PR 검토 봇에 “적대적 검토(adversarial review)” 같은 마법의 단어를 뿌리기만 하면 된다. 그러면 아무 사고 없이 소프트웨어가 알아서 즐겁게 만들어진다는 것이다. ## 이것은 실력 문제가 아니다 내가 설득하려는 주장은 이렇다. 근본적으로 모델 학습에서 비롯된 문제는 하네스 엔지니어링이나 루프 극대화(loopsmaxxing)로 아무리 애써도 해결할 수 없다. 이 문제를 제대로 이해하려면 코딩 모델을 실제로 어떻게 학습하고 평가하는지 살펴봐야 했다. [RLVR](https://github.com/opendilab/awesome-RLVR)와 벤치마크 양쪽 모두를 조사했다. 이 글에서는 다음을 다룬다. 1. 소프트웨어 팩토리의 역사는 1968년까지 거슬러 올라간다. 그동안 어떻게 발전했으며 AI는 무엇을 바꿨는가? 2. 모델은 벤치마크에서 만점을 받으면서도 왜 산더미 같은 엉터리 코드를 생성하는가? 새로 나온 ‘최첨단(frontier)’ 벤치마크도 예외는 아니다. 3. 그런데도 코드베이스를 불태우지 않으면서 상당히 빠르게 개발하려면 어떻게 해야 하는가? 하루가 멀다고 등장하는 온갖 스킬 플러그인과 AI 정신착란식 토큰 극대화 조언의 유행을 걷어 내고자 한다. 특정 스킬이나 프레임워크를 언급하지 않고, 일반적으로 어떤 접근법이 효과적인지 이야기하겠다. 영상판: 이 글은 [AI 엔지니어 월드 페어 2026에서 진행한 내 기조연설](https://www.youtube.com/watch?v=Ib5GBkD555M)을 바탕으로 내용을 확장했다. 이 글에 의견을 준 [@addyosmani](https://x.com/addyosmani), [@CyrusNewDay](https://x.com/CyrusNewDay), [@HamelHusain](https://x.com/HamelHusain), [@zeeg](https://x.com/zeeg), [@dillon_mulroy](https://x.com/dillon_mulroy), [@nayshins](https://x.com/nayshins), [@jeffreyhuber](https://x.com/jeffreyhuber)에게 감사한다. ## 잠깐: 바이브 코딩과는 무관한 이야기다 [애디 오스마니](https://x.com/addyosmani/status/2066595308629594363)는 강조할 만한 이 문제를 명쾌하게 정리했다. > 고작 열두 명 정도가 실행해 볼 사이드 프로젝트를 바이브 코딩하는 개발자와, 10년 된 엔터프라이즈 시스템을 다음 분기까지 살려 둬야 하는 팀 사이에는 공통된 제약 조건이라고 부를 만한 것이 거의 없다. 그런데 세간에 떠도는 조언은 대부분 둘 중 한 사람이 다른 사람에게 어떻게 살아야 하는지 훈계하는 내용이다. 바이브 코딩을 좋아한다면 마음껏 계속하라. 나도 여전히 많은 것을 바이브 코딩한다. 다만 프로덕션 소프트웨어도 많이 유지보수한다. 휴먼레이어(HumanLayer)를 통해 수천 명의 엔지니어가 같은 일을 하도록 돕기도 한다. 따라서 이후 내용은 복잡한 코드베이스에서 어려운 문제를 해결하는 사람들을 대상으로 한다. 이 차이를 설명할 때 브라운필드(brownfield)라는 말을 자주 듣는다. 예전에는 보통 10년 된 자바 시스템 같은 것을 뜻했다. 하지만 지금처럼 빠르게 출시하는 시대에는 에이전트가 만든 코드베이스도 불과 3~6개월이면 문제가 생기기 시작하는 듯하다. 개발 속도가 느려지고 새로운 기능을 추가하는 방식도 바꿔야 한다. ## 소프트웨어 팩토리의 간략한 역사 나는 경력 내내 소프트웨어 팩토리를 만들고 연구해 왔다. 하지만 다음 사실은 최근에야 알았다. 이 용어는 무려 [1968년 나토 회의](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF)까지 거슬러 올라간다. ‘소프트웨어 공학(software engineering)’이라는 말을 탄생시킨 바로 그 회의다. 그 이후의 일 가운데 내가 아주 흥미롭게 여기는 것은 하나뿐이다. [미국 국방부가 젠킨스를 더 잘 써야 한다는 식의 내용을 담은 31쪽짜리 PDF를 작성했다.](https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf) ## 2022년의 소프트웨어 팩토리 AI가 등장하기 직전인 2022년을 기준으로 ‘소프트웨어 팩토리(software factory)’의 정의를 구체화해 보자. 일반적인 소프트웨어 팩토리는 다음과 같이 움직였다. * 무엇을 만들지 사람이 결정한다. 엔지니어, PM, 경영진이 비전을 이끈다. * 결정한 내용을 추적 도구에 넣는다. 리니어, 지라 등 무엇이든 좋다. 해야 할 일의 상태를 관리하는 상태 머신이다. * 누군가 티켓을 가져가서 구현한다. 그 과정에서 수동 또는 자동 테스트도 수행할 것이다. * 풀 리퀘스트를 만든다. 자동 검사를 실행하고 사람이 코드를 검토한다. 누군가는 코드를 내려받아 직접 테스트하기도 한다. * 문제가 있는가? ‘누군가가 구현한다’ 단계로 돌아간다. * 프로덕션에 출시한다. 그러면 사용자와 만난다. * 모니터링을 추가한다. 무언가 고장 났을 때 새벽 3시에 엔지니어를 호출하는 일을 중심으로 산업 하나가 통째로 형성돼 있다. * 사용자가 불만을 제기한다. 무언가를 요청하고 버그를 찾아 기능 요청을 등록한다. 그러면 다시 팀으로 돌아가 추적 도구에 추가한다.  0:41 이 과정은 계속 반복된다. 아직 AI 이야기는 꺼내지도 않았는데 그림에는 이미 여러 루프가 존재한다. ## 초기에 정렬하기 팀들은 수십 년 전에 한 가지 사실을 깨달았다. 구현에는 몇 시간 또는 며칠이 걸리며, 검토에도 그만큼 시간이 든다는 것이다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400527242989568) 그래서 계획 수립, 아키텍처 제안, 스프린트 계획 같은 작업을 앞부분에 배치해 팀이 함께 수행한다. 그 결과는 다음과 같다. * 코드를 작성하기 전에 방향을 맞췄으므로 재작업이 줄어든다. * 모든 줄을 검토하는 데 드는 시간이 줄어든다. 길지만 잘 작성된 PR을 읽어 본 적이 있다면, 거의 완벽한 PR을 얼마나 빨리 검토할 수 있는지 알 것이다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400577415331840) 이 문제는 나중에 다시 살펴보겠다. 먼저 에이전트형 코딩(agentic coding)을 도입하면 어떤 일이 생기는지 보자. ## 에이전트형 소프트웨어 팩토리 이제는 너도나도 다음과 같은 회사들이— * [램프](https://infoq.com/news/2026/01/ramp-coding-agent-platform/) * [스트라이프](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents) * [워크OS](https://workos.com/blog/project-horizon) * [브렉스](https://www.latent.space/p/brex) 올해 대부분의 시간을 자사 코드 중 약 75%를 출시하는 에이전트 팩토리를 어떻게 구축했는지 설명하는 데 썼다. 에이전트형 팩토리는 대체로 ‘누군가가 구현한다’를 ‘에이전트가 구현한다’로 바꾼 형태다. 오케스트레이션, 하네스, 샌드박스, 모델, 컴퓨터 사용 같은 요소가 들어간다. 솔직히 나도 이런 이야기를 읽는 데 질렸고 여러분도 마찬가지일 테니 자세히 설명하지 않겠다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400688757276672) 에이전트가 구현하면 다음과 같이 달라진다. * 몇 시간 또는 며칠이 걸리던 구현 시간이 몇 분 또는 몇 시간으로 줄어든다. * 검토에는 여전히 몇 시간 또는 며칠이 걸린다. 사람이 코드를 읽고 변경 사항을 테스트해야 한다. 이제 검토가 병목이 된다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400721930018816) 그러므로 검토도 더 빠르게 만든다. * 에이전트형 코드 검토를 도입해 스타일 문제, 버그, 보안 문제를 잡는다. * 에이전트형 회귀 테스트를 도입한다. 브라우저와 컴퓨터 사용 기능으로 외부에서 시스템을 건드려 보고, 작업이 끝나면 귀여운 영상까지 보내 줄 수도 있다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400759246774272) 이제 검토가 빨라졌다. 하지만 여전히 병목일 가능성이 크다. 그렇다면 루프를 더 만들면 된다. 그다음에는 장애를 팩토리로 보낼 수 있다. 새벽 3시에 누군가를 호출하는 대신, 아침에 일어나 보면 장애를 이미 수정했을지도 모르는 PR이 도착해 있다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400798199230464) 사용자 피드백도 팩토리로 보낼 수 있다. 사람들이 무언가를 요청하면 곧바로 만들어진다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400827475431424) 이 단계에 이르면 업무는 두 가지 질문으로 압축된다. 대기열에 얼마나 많은 일을 넣을 수 있는가? 그리고 결과물을 얼마나 빨리 검토하고 테스트할 수 있는가? [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400857410187264) 이제 완전 자동화 소프트웨어 팩토리로 넘어간다. ## 완전 자동화 소프트웨어 팩토리 [댄 샤피로가 이 용어를 만들었고](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/), [사이먼 윌리슨은 스트롱DM이 이를 구현한 사례를 소개했다.](https://simonwillison.net/2026/Feb/7/software-factory/) 이곳에서는 사람이 더 이상 코드를 읽지 않는다. 아름다운 소프트웨어 팩토리를 바라본다. 그런데 성가신 코드 검토 단계가 모든 것을 망치고 있다. 그래서 이렇게 말한다. “사람이 모든 변경 사항을 읽는 그 작업 말이야? 사양하겠어.” [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400911281819648) 그래서 코드 검토를 없애고 다른 곳에 힘을 쏟는다. * 테스트와 에이전트의 자체 작업 테스트에 투자한다. * 샌드박스와 오케스트레이션에 투자한다. * 자동 검토에 투자한다. * 모니터링에 투자한다. * 배포에 투자한다. * 사용자 피드백 신호를 수집하는 데 투자한다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080400944983117824) 이제 업무는 정말로 한 가지 질문만 남는다. 에이전트에게 얼마나 많은 것을 만들어 달라고 요청할 수 있는가? 우리는 [얼마나 넓은 바다를 끓이려 하는가](https://garryslist.org/posts/boil-the-ocean)? ## 아주 잘되겠군(그렇지 않다) [](https://x.com/dexhorthy/article/2080697380379427275/media/2080406575840399360) 논란이 될 수도 있는 주장을 하나 하겠다. 완전 자동화 팩토리는 작동하지 않는다. 이제 소프트웨어 팩토리가 실패하는 이유를 살펴보자. ## 우리도 해 봤다 2025년 7월, 우리는 완전 자동화 체제로 전환했다. 사양과 티켓만 읽었다. 작거나 중간 규모인 작업은 모두 백그라운드 에이전트에게 맡겼다. 그야말로 전면 도입이었다. 몇 달 동안 이를 진지하게 시도해 봤다면 결말을 이미 알 것이다. 아무리 정교한 프롬프트와 워크플로를 이용해도 에이전트가 해결하지 못할 만큼 까다로운 문제가 적어도 하나는 나타난다. * 컨텍스트를 깊이 이해하는 조사를 수행하고, 모델이 분석할 수 있도록 필요한 부분을 모두 모아 모델의 집중 영역에 넣는다. * 에이전트에게 열 가지 방법으로 문제를 재현하게 한다. 결국 현실을 받아들이고 석 달 동안 읽지 않았던 코드베이스를 직접 파헤쳐야 한다. 무엇이 망가졌는지 알아내야 하기 때문이다. 그사이에는 다음과 같은 일이 벌어진다. * 사이트가 중단된다. * 사용자는 화가 난다. * 나와 비슷한 사람이라면 비참한 기분이 든다. 시스템에 흘려 넣은 엉터리 코드를 모조리 읽어야 하기 때문이다. 처음 이런 일이 생겼을 때는 털어 내고 넘어갔다. 거의 2주 동안 클로드가 만든 스파게티 코드를 헤집었지만 “위험을 감수할 만한 속도였다”고 생각했다. 11월쯤 세 번째로 같은 일이 벌어지자 차라리 처음부터 다시 작성하는 편이 쉽겠다고 판단했다. 공동 창업자는 꼬박 2주 동안 VS 코드에 틀어박혔다. 커서조차 쓰지 않고 모든 패턴을 직접 구현했다. ## 모델은 시간이 흐를수록 코드베이스의 품질을 떨어뜨린다 내가 말하려는 핵심은 이것이다. 모델에는 결함이 있다. 사람이 상당히 적극적으로 방향을 잡아 주지 않으면 시간이 지나도 코드베이스의 품질을 유지하고 개선하지 못한다. 여기서 유지보수성이란 코드베이스의 한 부분을 바꿀 때 다른 부분을 깨뜨리지 않기가 극도로 어려워지는 문제를 말한다. [마틴 파울러가 말한 산탄총 수술(shotgun surgery)](https://refactoring.guru/smells/shotgun-surgery)이다. 유지보수성에 관해서는 더 길게 이야기하지 않겠다. 관련 서적이 많으니 읽어 보면 된다. * [존 오스터하우트의 『소프트웨어 설계의 철학(A Philosophy of Software Design)』](https://web.stanford.edu/~ouster/cgi-bin/aposd.php) * [로버트 C. 마틴의 『클린 코드(Clean Code)』](https://www.oreilly.com/library/view/clean-code-a/9780136083238/) * [마틴 파울러의 『리팩터링(Refactoring)』](https://martinfowler.com/books/refactoring.html) 그렇다면 모델은 왜 소프트웨어의 유지보수성을 다루지 못할까? “하지만 그때보다 모델이 확실히 좋아지지 않았나?” 이쯤 되면 이렇게 말하고 싶을 것이다. “하지만 덱스, 7월 이후 모델이 훨씬 좋아진 건 확실하잖아.” 맞다. 일부 측면에서는 좋아졌다. 다른 측면은 거의 그대로다. * 일회성 문제를 해결하거나 새로운 마케팅 사이트를 바이브 코딩하는 능력은 확실히 훨씬 좋아졌다. * 시간이 지나도 코드베이스의 품질을 개선하는 능력은 내가 보기에는 별로 나아지지 않았다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080401072330588160) 나는 이를 증명할 수 없다. 여러분도 증명할 수 없다. 모델이 코드베이스 품질을 유지하는 능력을 측정할 만한 좋은 벤치마크가 없기 때문이다. 이 분야가 어디로 가고 있는지는 뒤에서 더 설명하겠다. > 코드베이스 품질을 유지하는 모델의 능력을 측정할 만한 좋은 벤치마크는 존재하지 않는다. 하지만 코딩 에이전트를 한동안 써 봤다면 이미 감을 잡았을 것이다. 많은 사람도 정확히 같은 문제를 지적한다. 코딩 에이전트는 시간이 흐를수록 상황을 악화하고 코드베이스를 다루기 어렵게 만드는 경향이 있다. 왜 이런 일이 생기는지 알아보기 위해 최초의 위대한 코딩 에이전트를 살펴보자. ## 클로드 코드가 성공한 이유는 하네스 내부의 강화학습이다 클로드 코드(Claude Code)는 출시 후 1년도 안 돼 매출이 0달러에서 약 40억 달러로, 이제는 약 90억 달러 수준까지 성장했다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080401154996056064) 조금 이상한 일이다. 이미 훌륭한 CLI 에이전트들이 있었기 때문이다. [에이더](https://aider.chat/), [클라인](https://cline.bot/), [코드버프](https://codebuff.com/)는 모두 클로드 코드보다 먼저 나왔다. 모두 훌륭한 컨텍스트 엔지니어링을 내장했고, 클로드 코드의 특징으로 여길 만한 도구도 똑같이 갖췄다. 읽기, 쓰기, 편집, `grep`, `bash` 등이다. 나도 사용해 봤고 좋은 도구들이었다. 하지만 가끔은 도구 사용이 그냥 실패했다. 같은 편집 작업을 세 번 연속으로 허우적거리며 시도하는 모습을 보다 결국 편집기를 다시 열어 직접 처리하곤 했다. [2024년 SWE-Agent 논문](https://arxiv.org/abs/2405.15793)은 도구의 형태를 조금만 바꿔도 눈에 띄는 차이가 생긴다고 설명한다. 예를 들어 `ReadFile` 결과에 줄 번호를 넣거나, `Edit` 도구를 찾기·바꾸기 방식에서 줄 범위 편집 방식으로 바꾸는 것이다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080401202555318272) 그러다 클로드 코드가 출시됐고 성장 곡선은 빠르게 수직으로 치솟았다. 유통력 덕분이라고 대충 넘길 수도 있다. 하지만 일반적으로 받아들여지는 설명은 클로드 코드가 더 뛰어나서 성공했다는 것이다. 그리고 더 뛰어났던 이유는 앤트로픽이 하네스 안에서 모델을 강화학습으로 훈련했기 때문이다. 연구소가 실제로 출시할 도구와 정확히 같은 도구를 대상으로 모델을 훈련한 최초의 사례였다. 그 결과 모델은 에이전트형 루프에서 해당 도구를 호출하는 데 대단히 능숙해졌다. 모델이 가장 좋아하는 형태를 찾을 때까지 도구 정의와 평가 방식을 조금씩 조정하는 것도 한 가지 방법이다. 나도 여러 사용 사례에서 이런 작업에 몇 주를 썼다. 하지만 모델 가중치를 소유하고 특정 도구 모음에 더 능숙하도록 모델 자체를 수정할 수 있다면 이야기가 완전히 달라진다. 오픈AI 팀은 [11월 발표](https://www.youtube.com/watch?v=wVl6ZjELpBk)에서 이를 명확하게 설명했다. 하네스를 만들었지만 가중치를 소유하지 않아 그 안에서 모델을 강화학습할 수 없다면, 하네스와 모델을 모두 소유한 팀보다 언제나 불리하다. ## 60초 만에 이해하는 코딩 에이전트 강화학습 나는 이 주제를 많이 조사했고 중요한 부분을 설명하려고 여러 시각화 자료도 만들었다. 하지만 코덱스 팀의 MTS이자 세그먼트 창업자인 [캘빈 프렌치오언](https://x.com/calvinfo)이 [AI 카운슬](https://www.youtube.com/watch?v=q-ntX4DLW_c)에서 훨씬 깔끔하고 훌륭하게 설명했다. 따라서 그의 슬라이드에서 영감을 얻은 애니메이션을 여기에 싣는다.  0:24 모델의 코딩 능력을 높이려면 다음과 같이 한다. 1. 문제를 해결하는 코딩 에이전트의 실행 궤적(trace)을 생성한다. 예를 들어 “테스트를 수정하라”라는 문제를 준다. 2. 특정 기준인 검증기(verifier)에 따라 실행 궤적에 점수를 매긴다. 3. 좋은 실행 궤적이 나올 가능성은 높이고 나쁜 실행 궤적이 나올 가능성은 낮추도록 모델 가중치를 업데이트한다. 그런 다음 몇 주 또는 몇 달에 걸쳐 이 과정을 수백만 번 반복한다. 그런데 이 과정에서 ‘점수 매기기(scoring)’는 놀라울 정도로 일차원적일 때가 많다. ## 나쁜 설계에는 벌점이 없다 [SWE-bench Multilingual](https://huggingface.co/datasets/SWE-bench/SWE-bench_Multilingual)을 예로 들어 보자. 각 과제는 약 15분이면 끝낼 수 있을 정도로 작다. 레디스, `jq`, 장고 같은 오픈 소스 저장소에서 가져왔다. 보상은 다음 두 기준에 따라 1점 또는 0점이다. * `FAIL_TO_PASS` — 요청받은 문제를 수정했는가? * `PASS_TO_PASS` — 다른 것을 망가뜨리지 않고 수정했는가? 루비 프로젝트 [패스트레인](https://github.com/fastlane/fastlane)에서 가져온 실제 과제 `fastlane__fastlane-19304`를 살펴보자. `zip` 액션은 선택적 매개변수 두 개를 가져온 뒤 즉시 `.empty?`를 호출한다. 따라서 `include`와 `exclude`를 지정하지 않으면 곧바로 실패한다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080404587455131648) 이 이슈를 종료한 인간의 수정 사항은 두 줄뿐이다. `nil`의 기본값을 빈 배열로 바꿨다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080404635223990272) 평가 과정에서 모델은 다음 정보를 받는다. 1. 수정 사항이 반영되기 직전 시점으로 저장소를 체크아웃한 기준 커밋 2. 버그 보고서. 이 사례에서는 `'zip_command': undefined method 'empty?' for nil:NilClass` 에이전트는 이슈를 바탕으로 코드를 작성한다. 정답 패치나 채점기 역할을 하는 테스트 패치는 볼 수 없다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080404688688848896) 그다음에는 다음 절차를 거친다. 1. 에이전트가 만든 패치를 보관한다. 2. 에이전트가 테스트 파일에 적용한 수정 사항은 모두 버린다. 모델이 실패하는 테스트를 몰래 주석 처리하거나 테스트를 무의미하게 만드는 모의 객체를 끼워 넣은 사례가 있었기 때문이다. 3. 그 위에 벤치마크의 테스트 패치를 적용한다. 4. 전체 테스트 모음을 실행한다. 기존 `zip` 테스트인 `PASS_TO_PASS`와 새로운 테스트인 `FAIL_TO_PASS`가 모두 통과하는지 확인한다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080404876673372160) 잠깐 짚고 넘어가자. 벤치마크는 검증기가 아니다. 실제로 둘은 서로 분리해 두어야 한다. 테스트 데이터로 학습해서는 안 된다는 이야기다. 여기서는 주로 ‘코딩 에이전트 실행 궤적의 품질을 판단하는 방식’과 그 한계를 설명하려는 것이다. 모델이 어떻게 정답에 도달했는지는 중요하지 않다. 테스트만 통과하면 성공이다. 하지만 코드베이스의 유지보수성을 훼손해도 벌점은 없다. ## 코드베이스의 유지보수성을 훼손해도 벌점은 없다 그래서 모든 곳을 `try-catch`로 감싼 코드가 나온다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080405222720249856) 품질을 검증하는 일은 “테스트가 통과했는가?”를 확인하는 것보다 몇 자릿수는 더 어렵다. 테스트를 실행하면 몇 초 만에 명확한 성공 또는 실패 결과를 얻는다. 그래서 강화학습은 모델 생성을 최적화하려고 수백만 번의 루프를 돌릴 수 있다. 하지만 나쁜 아키텍처의 비용 함수는 몇 주, 몇 달, 어쩌면 몇 년에 걸쳐 드러난다. 누군가 한 줄을 바꾸려고 파일을 열었다가 한 줄만으로는 수정할 수 없다는 사실을 깨닫는 순간 문제가 나타난다. 누군가가 바이브를 지나치게 강하게 탔기 때문에 같은 내용을 열한 곳에서 고쳐야 하고, 세 파일 너머에서 무언가 조용히 망가지지 않기만을 바라야 한다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080405395470979072) 테스트는 몇 초 만에 피드백을 주지만, 나쁜 아키텍처의 비용 함수는 몇 주, 몇 달, 어쩌면 몇 년에 걸쳐 측정된다. 나쁜 설계는 오늘날의 벤치마크가 평가하지 못하는 한 가지 요소다. 물론 강화학습과 벤치마크가 같지 않다는 것은 나도 안다. 하지만 이 문제가 강화학습에서 해결됐다면 벤치마크 설계에도 어느 정도 반영되기 시작했을 것이다. 어쨌든 나는 현재 벤치마크의 점수가 올랐다는 이유만으로 모델이 갑자기 코드베이스를 엉망으로 만들지 않게 됐다고 믿지 않는다. ## 최첨단 수준은 천천히 나아지고 있다 물론 많은 뛰어난 사람이 이 문제를 연구하고 있다. 내 주장은 해결할 수 없다는 것이 아니다. [과대광고가 규율과 검증보다 앞서 달리고 있다](https://www.youtube.com/watch?v=c35YoMdnI78)는 뜻이다. 내가 보기에 올바른 방향을 향한 몇 가지 시도는 다음과 같다. * [SWE-마라톤(SWE-Marathon)](https://www.swe-marathon.org/) 어번던트 AI(Abundant AI)의 프로젝트다. “엑셀의 모든 기능을 통째로 복제하라”처럼 약 400시간이 걸리는 과제를 제시한다. 하나의 성공·실패 비트 대신 복합적인 보상 채널을 사용한다. * [딥SWE(DeepSWE)](https://deepswe.datacurve.ai/blog/deepswe) 데이터커브(Datacurve)의 프로젝트다. 현실에서는 실제로 구현된 적 없는 오픈 소스 저장소의 대규모 과제를 이용한다. 따라서 구조상 학습 데이터에 이미 들어 있을 수 없다. 데이터 오염 문제는 해결하지만 품질 문제까지 해결하지는 않는다. * [프런티어 코드(Frontier Code)](https://cognition.com/blog/frontier-code) 코그니션(Cognition)의 프로젝트다. 여러 PR에 걸친 과제를 사용한다. 품질을 결정론적으로 평가하는 영리한 방식도 도입했다. 모델이 작성한 테스트가 패치 적용 전 코드에서 실패하지 않으면 벌점을 준다. [변이 테스트(mutation testing)](https://en.wikipedia.org/wiki/Mutation_testing)를 처음 들어 본다면 흥미로운 경험이 기다리고 있을 것이다. 또한 코드 품질 규칙을 확인하도록 판정 모델이 변경 사항을 검토한다. [](https://x.com/dexhorthy/article/2080697380379427275/media/2080405496180416512) 하지만 모델이 품질을 판단하는 방식에는 한계가 있다. 사실 모델이 좋은 코드와 나쁜 코드를 안정적으로 구분할 수 있다면 애초에 좋은 코드를 작성했을 것이라고 생각하기도 어렵지 않다. 강화학습에는 빠르고 신뢰할 수 있는 오라클(oracle)이 필요하다. 하지만 유지보수성을 판정할 수 있는 오라클은 아직 없다. 모델이 좋은 코드와 나쁜 코드를 안정적으로 구분할 수 있다면 애초에 좋은 코드를 작성했을 것이다. 그러나 유지보수성에는 빠른 오라클이 없다. 따라서 강화학습 중에 유지보수성을 기준으로 보상할 수 없다. 물론 검토 에이전트를 늘리고 토큰을 더 쓰면 도움이 된다. 어리석은 실수를 잡아내므로 최저 수준은 높아진다. 그러나 최고 수준은 높이지 못한다. 최고 수준은 강화학습으로 모델에 가르치는 데 성공한 범위로 제한되기 때문이다. 그리고 좋은 설계는 아직 모델에 가르칠 방법을 모르는 요소다. 그러므로 나는 아직 내 코드베이스를 이런 접근법에 걸지 않겠다. 그래도 성공·실패 판정에서 멈추지 않고 유지보수성에 점수를 매기려는 평가 방식은 이것들이 처음이다. 한편 미래의 어떤 모델은 이 문제를 그냥 이해해 버릴지도 모른다. GPT-7이 나올 때까지 무모하게 프롬프트를 날려 보며 결과를 확인하고 싶다면 마음대로 하라. 하지만 ‘쓰라린 교훈(bitter lesson)’이 무엇이든 지금 당장 해결해야 할 문제가 있다. 이제 우리가 그 문제를 어떻게 해결하는지 설명하겠다. ## 다시 불을 켜기 오늘 트위터 아티클에 ‘미디어 제한(media limit)’이 있다는 사실을 알았다. 따라서 나머지 내용은 2부로 넘어간다. 2부: [https://x.com/dexhorthy/status/2081058573556306030](https://x.com/dexhorthy/status/2081058573556306030) 3부: [https://x.com/dexhorthy/status/2081797628552270027](https://x.com/dexhorthy/status/2081797628552270027)