3줄 요약
- HumanLayer 창업자 Dex Horthy의 에세이다. 사람이 코드를 전혀 읽지 않는 ‘불 끄고 돌아가는 소프트웨어 공장(lights-off factory)‘은 작동하지 않는다는 것이 핵심 주장이다. loop·자동 리뷰·샌드박스 같은 하네스 엔지니어링을 아무리 쌓아도 풀리지 않는다. 이것은 하네스의 문제가 아니라 근본적으로 모델 학습의 문제이기 때문이다.
- 이유는 이렇다. 코딩 모델은 ‘테스트가 통과했는가’ 같은 검증기로 강화학습(RL)되는데, 이 채점표에는 나쁜 설계를 벌하는 항목이 없다. 유지보수성은 몇 초 만에 채점할 빠른 오라클이 없어서 RL이 보상할 수가 없다. 그래서 모델은 벤치마크를 아무리 잘 풀어도 시간이 지날수록 코드베이스 품질을 갉아먹는다.
- 그래서 해법은 ‘다시 불을 켜는 것’이다. 코드를 짜기 전에 제품 → 시스템 아키텍처 → 프로그램 설계 → 수직 슬라이스 네 단계로 사람이 사전 정렬한다. 30분의 계획이 몇 시간의 리뷰를 아낀다. 10~100배가 아니라 2~3배를 안전하게 노리자는 것이 결론이다.
‘불 끄고 돌아가는 공장’의 약속
지금 모두가 AI 코딩을 프로덕션에 밀어 넣는 경쟁을 하고 있고, 지배적 통념은 “루프를 더 많이 짜라"는 것이다. StrongDM은 아무도 코드를 읽지도 쓰지도 않는 ‘어두운 소프트웨어 공장’을 소개했고, OpenAI는 자사의 공장 Symphony와 ‘하네스 엔지니어링’을 이야기했다. 서사는 대략 이렇게 흐른다. 당신이 병목이다 → 모델은 이제 충분히 좋다 → 코드는 공짜다 → 그러니 더 찍어내라.
저자는 이들을 향한 존경을 밝히면서도, 현장의 신호는 다른 쪽을 가리킨다고 말한다. Faros AI의 리포트에 따르면 다들 AI 코딩 도구를 집어 든 이후 PR 병합 전 코드 품질이 크게 떨어졌다. 리뷰 코멘트가 늘고(+25%), 길어지고(+22.7%), 아예 리뷰 없이 머지되는 PR이 늘었다(+31.3%). 그리고 인시던트(PR당 +242.7%)와 개발자당 버그(+54%)가 함께 뛰었다. 저자는 이 데이터가 확증이 아니라 상관 신호임을 분명히 하면서도, “방향은 맞는 느낌"이라고 덧붙인다.
이 흐름을 이해하려면 ‘소프트웨어 공장’의 진화를 봐야 한다. 이 용어는 놀랍게도 1968년 NATO 컨퍼런스까지 거슬러 올라간다. AI 이전인 2022년의 공장은 사람이 무엇을 만들지 정하고, 트래커에 넣고, 누군가 티켓을 잡아 만들고, PR을 올려 사람이 리뷰하고, 배포하고, 모니터링하고, 사용자 피드백이 다시 트래커로 돌아오는 여러 겹의 루프였다. 여기서 팀들이 수십 년 전에 터득한 지혜가 프론트로딩이다. 빌드도 리뷰도 시간이 걸리니, 계획·아키텍처를 앞으로 몰아 함께 정렬해 두면 재작업이 줄고, 잘 정리된 PR은 리뷰가 순식간에 끝난다.
에이전트가 들어오면 그림은 “누군가 만든다 → 에이전트가 만든다"로 바뀐다. Ramp·Stripe·WorkOS·Brex 같은 회사들이 코드의 75%가량을 에이전트로 찍어낸다고 설명해 왔다. 빌드가 몇 분~몇 시간으로 줄면, 이제 리뷰가 병목이 된다. 그래서 리뷰도 자동화하고(스타일·버그·보안), 회귀 테스트도 에이전트에 맡긴다. 그래도 리뷰가 병목이면, 결국 그 거슬리는 리뷰 단계 자체를 지워 버리는 데까지 간다. Dan Shapiro가 이름 붙이고 StrongDM이 구현한 lights-off 공장 — 사람이 더 이상 코드를 읽지 않고, 대신 테스트·샌드박스·모니터링·롤아웃에 투자하는 세계다. 그러면 남는 질문은 하나뿐이다. 얼마나 많이 큐에 밀어 넣을 것인가.
우리도 해봤고, 실패했다
저자의 팀은 2025년 7월에 완전한 lights-off로 갔다. 스펙과 티켓만 읽고 작고 중간 규모 일은 전부 백그라운드 에이전트에게. 몇 달을 진지하게 해 본 사람은 결말을 안다. 에이전트가 아무리 정교한 프롬프트로도 못 푸는, 충분히 고약한 이슈를 반드시 하나 만난다. 깊은 컨텍스트 리서치를 해 주고, 열 가지 방법으로 재현을 시켜도 안 된다. 결국 3개월간 읽지 않던 코드베이스를 직접 파고들어 무엇이 깨졌는지 찾아야 한다.
그동안 사이트는 다운돼 있었고, 사용자는 화가 났고, 저자 본인은 흘려보낸 슬롭 코드를 읽으며 비참했다. 첫 번째는 “속도를 위한 하방 리스크"라며 넘겼지만, 11월쯤 세 번째로 같은 일이 반복되자 처음부터 다시 짜는 게 낫다고 판단했다. 공동창업자가 꼬박 2주 동안 VS Code에서 손으로 패턴을 정리해야 했다.
모델은 시간이 지날수록 코드베이스를 망친다
핵심 명제는 이것이다. 모델에는 결함이 있다. 사람의 상당한 조타 없이는, 시간이 지나며 코드베이스 품질을 유지·개선하지 못한다. 여기서 유지보수성이란, 한 부분을 고치려 할 때 다른 부분이 깨지지 않게 만들기가 얼마나 어려운가를 말한다(Martin Fowler의 shotgun surgery).
“그래도 모델이 그때보다 좋아지지 않았나?” 맞다. 일회성 문제를 풀거나 새 마케팅 사이트를 바이브 코딩하는 능력은 훨씬 좋아졌다. 그러나 시간에 걸쳐 코드베이스 품질을 유지하는 능력은 거의 그대로다. 증명할 수는 없다 — 애초에 모델의 유지보수 능력을 재는 좋은 벤치마크가 없기 때문이다. 저자는 이 대목을 두 번 강조한다. 모델의 코드베이스 유지 능력을 재는 좋은 벤치마크는 존재하지 않는다.
Claude Code는 하네스 안에서 RL했기에 이겼다
왜 이렇게 되는지 이해하려면 첫 위대한 코딩 에이전트로 돌아가야 한다. Claude Code는 1년도 안 돼 매출 런레이트가 ~40억 달러, 지금은 ~90억 달러 수준까지 갔다. 조금 이상한 일이다. aider·cline·codebuff처럼 이미 훌륭한 컨텍스트 엔지니어링을 갖춘 CLI 에이전트들이 먼저 있었고, 도구 세트(read·write·edit·grep·bash)도 비슷했으니까. 다만 그것들은 도구 호출이 가끔 그냥 실패했다 — 같은 편집을 세 번 헛치는 걸 보다가 결국 직접 에디터를 열게 되는 식이다.
2024년 SWE-Agent 논문은 도구의 모양이 작게 바뀌어도(ReadFile 결과에 줄 번호를 넣는다든지, Edit을 find/replace에서 줄 범위 편집으로 바꾼다든지) 에이전트 행동에 큰 차이가 난다는 걸 보였다. 통념으로 받아들여지는 설명은, Claude Code가 이긴 건 배포할 바로 그 도구들과 함께 모델을 하네스 안에서 RL한 첫 사례였기 때문이라는 것이다. 도구 정의를 손보는 것과, 가중치를 소유하고 모델 자체를 그 도구에 맞게 바꾸는 것은 전혀 다른 게임이다. OpenAI 팀의 표현대로, 하네스를 만들어도 가중치를 소유하지 못하고 그 안에서 RL할 수 없다면, 둘 다 소유한 팀에 늘 뒤진다.
나쁜 설계에는 벌점이 없다
코딩 모델을 더 잘 만드는 절차는 이렇다. ① 문제를 푸는 코딩 트레이스를 생성하고 ② 검증기로 채점하고 ③ 좋은 트레이스는 더, 나쁜 트레이스는 덜 나오도록 가중치를 갱신한다. 이걸 수백만 번 반복한다. 문제는 이 ‘채점’이 대개 변덕스러울 만큼 1차원적이라는 데 있다.
예를 들어 SWE-bench Multilingual의 과제는 약 15분짜리로, 보상은 두 조건의 0/1이다. FAIL_TO_PASS(요청받은 걸 고쳤는가)와 PASS_TO_PASS(그 과정에서 다른 걸 깨뜨리지 않았는가). fastlane의 실제 사례에서, zip 액션이 옵션 파라미터에 곧바로 .empty?를 불러 nil일 때 터지는 버그가 있었다. 사람의 수정은 nil을 빈 배열로 기본값 처리하는 두 줄이었다. 채점 과정은 모델이 만든 패치는 남기되, 모델이 손댄 테스트 파일 편집은 버리고(실패하는 테스트를 슬쩍 주석 처리하거나 무력화하는 걸 잡아낸 적이 있어서) 벤치마크의 테스트 패치를 위에 얹어 전체 스위트를 돌린다.
여기서 핵심은, 어떻게 정답에 도달했는지는 상관없다는 것이다. 테스트만 통과하면 이긴다. 그리고 유지보수성을 침식한 것에 대한 벌점은 없다. 그래서 모든 것에 try/catch를 두르고, 타입 시스템의 이점을 통째로 무너뜨리는 게으른 타입 캐스팅을 남발하는 습관이 나온다. 테스트만 통과하니까.
품질 검증은 “테스트 통과"보다 몇 배 어렵다
테스트를 돌리면 몇 초 만에 깔끔한 pass/fail이 나온다. 그래서 RL이 세대마다 수백만 번의 루프를 돌 수 있다. 그러나 나쁜 아키텍처의 비용함수는 몇 주, 몇 달, 때로는 몇 년 단위로 측정된다. 누군가 한 줄만 고치려고 그 파일을 열었다가, 한 줄로 안 되고 열한 곳을 똑같이 고쳐야 하며 세 파일 건너에서 뭐가 조용히 깨질지 모른다는 걸 깨닫는 그 순간에야 비용이 드러난다.
이게 결정적이다. 테스트는 초 단위 피드백을 주지만, 몇 달 뒤의 인시던트를 그것을 유발한 설계 결정으로 역전파(backprop)할 방법이 없다. 게다가 소프트웨어는 문제를 풀어 가며 발견하는 일인데, 대부분의 현대 벤치마크는 문제를 앞에서 통째로 공개한다. 그러니 ‘나중에 바꾸기 쉬운가’를 최적화할 이유 자체가 없다. 나쁜 설계는 오늘의 벤치마크가 평가할 수 없는 바로 그 하나다.
프론티어는 느리게 나아지고 있다
저자의 요점은 “불가능하다"가 아니라 “하이프가 규율을 앞지르고 있다"는 것이다. 방향이 옳다고 보는 시도 몇 가지를 든다.
- SWE-Marathon(Abundant AI): “엑셀의 모든 기능을 통째로 복제하라” 같은 ~400시간짜리 과제에, 단일 pass/fail이 아니라 복합 보상 채널을 붙였다.
- DeepSWE(Datacurve): 실제로는 세상에 만들어진 적 없는 대형 OSS 과제라, 구조적으로 학습 데이터에 이미 들어 있을 수 없다(오염 문제는 풀지만 품질 문제는 아니다).
- Frontier Code(Cognition): 멀티-PR 과제이면서, 품질을 결정론적으로 평가하는 영리한 수를 쓴다. 패치 전 코드에서 실패하지 않는 테스트를 쓰면 벌점을 주고(뮤테이션 테스트의 발상), diff 위에 판사 모델을 돌려 코드 품질 규칙을 심사한다.
그래도 모델이 품질을 판정하는 데는 한계가 있다. 사실 모델이 좋은 코드와 나쁜 코드를 신뢰성 있게 구분할 수 있었다면, 애초에 좋은 쪽을 썼을 것이다. RL에는 빠르고 신뢰할 수 있는 오라클이 필요한데, 유지보수성에는 아직 그런 오라클이 없다. 리뷰 에이전트와 토큰을 더 쓰면 바닥은 올라간다(멍청한 실수를 잡는다). 그러나 천장은 올리지 못한다. 천장은 RL에서 가르친 만큼이고, 좋은 설계는 아직 우리가 모델에게 가르치는 법을 모르는 바로 그것이기 때문이다.
다시 불을 켜다: 네 단계의 사전 정렬
지금으로선 판사는 사람이다. 그래서 코드 리뷰를 다시 제자리에 놓되, AI 이전부터 해 오던 것 — 앞에서 조금 계획해 길고 힘든 리뷰의 확률을 낮추는 것 — 을 네 단계로 되살린다.
- 제품 리뷰. 무엇을·왜 만드는지를 짧은 문서로 못 박는다. 실제 사용자 고통과, 출시 후 성공을 판단할 기준을 사용자 언어로 정한다. 화면은 서술하기보다 거친 HTML로 목업한다. 세 문단이 늘어질 논쟁을 목업 하나가 끝낸다.
- 시스템 아키텍처. 서비스·엔드포인트·스키마·큐·스토어가 어떻게 대화하는지를, 프로그램 세부로 들어가지 않고 정렬한다. 시퀀스 다이어그램·계약 형태·데이터 모델을 시각화한다. 레버리지가 높지만, 좋은 코드를 내기엔 이것만으로 부족하다.
- 프로그램 설계. 저자가 “형편없이 과소평가됐다"고 보는 단계다. 구현 전에 아키텍처보다 한 층 내려가 코드의 모양 — 타입, 메서드 시그니처, 콜스택 — 을 정한다. 제어 흐름 변화엔 콜스택 트리(diff 문법으로), 레이아웃엔 파일 트리 diff, 핵심 함수엔 타입·시그니처를 쓴다. 하나하나가 원래라면 리뷰 중에 암묵적으로, 가장 비싼 시점에 내렸을 결정들이다.
- 수직 슬라이스(tracer bullets). 모델은 DB → 서비스 → API → 프론트로 쌓는 ‘수평 계획’을 좋아하지만, 그러면 진행 중에 결과물을 만져 볼 방법이 없다. 저자는 가운데(예: API 계약 + 목 데이터)에서 시작해 바깥으로 나가며 매 단계 브라우저·curl로 확인·폴리시한다. 100~200줄씩 다시 조타하는 편이, 2천 줄 넘어가서 뭐가 깨졌는지 모르는 것보다 훨씬 싸다.
물론 이 전 과정을 모든 작업에 하지는 않는다. 대략 40%는 원샷 또는 1~2회 가벼운 피드백으로 끝내고, 중간 규모는 제품·시스템 설계를 한 문서에 몰아 단계를 나누지 않으며, 큰 것만 전 단계를 밟는다(제품 단계는 대형 리팩터링처럼 안 맞으면 건너뛴다).
30분의 계획이 몇 시간의 리뷰를 아낀다
당신에게 PR이 너무 많은 게 아니라, 나쁜 PR이 너무 많은 것이다. 20%만 재작업이 필요한 PR도(대개 AI 원샷 PR은 50%에 가깝다) 제출자와 리뷰어 양쪽에 지적·정서적 부담을 준다. 반대로 훌륭한 PR은 리뷰가 즐겁다 — 깔끔하고, 합의된 결정을 따르니까.
저자의 닫는 조언은 **제약의 이론(2026 판)**이다. 모델은 어떤 것엔 능하고 어떤 것엔 서툴다. 그 제약을 인정하고 그 안에서 최적화하라는 것이다.
- 제약을 잘 익히고, 모델과 많이 일하며 직관을 기른다
- 그 제약의 경기장 안에서 시스템을 최적화한다
- 레버리지를 찾는다
- 코드를 읽어라
10~100배 빠르게 가려다 코드 품질이 더는 중요치 않다고 스스로를 설득하느라 바쁠 때, 차라리 제약을 끌어안고 2~3배를 안전하게 갈 수 있다는 것. 그것이 이 글의 결론이다.
가장 눈여겨본 것은
내가 곱씹은 대목은 이 글이 ‘벤치마크를 통과하는 능력’과 ‘오래 살아 있는 코드베이스를 지키는 능력’을 정확히 갈라 놓는 지점이다. 우리는 흔히 모델이 좋아졌다는 말을 뭉뚱그려 쓰지만, 저자는 그 능력이 하나가 아니라고 짚는다. 특히 “유지보수성에는 몇 초 만에 채점할 빠른 오라클이 없어서 RL이 보상할 수 없다"는 통찰이 가장 단단하다. 좋은 설계는 몇 달 뒤에야 비용을 드러내는데, 그 비용을 결정의 순간으로 되돌릴 방법이 없다는 것 — 이건 프롬프트나 하네스로 우회할 수 있는 문제가 아니라 학습 신호의 구조적 한계다.
또 하나 신뢰가 간 것은 저자의 정직함이다. 그는 “나는 이걸 증명할 수 없고, 당신도 못 한다"고 먼저 인정하고, 자신이 경쟁 도구(HumanLayer)를 만드는 사람이라 편향됐을 수 있다는 이해충돌을 글 맨 앞에서 밝힌다. 낙관을 팔기 쉬운 주제에서, 자기 주장의 한계를 스스로 표시하는 태도가 오히려 논지를 믿게 만든다.
이 글은 같은 저자의 12-factor agents 다이제스트와 이어 읽으면 결이 맞는다. 신뢰할 수 있는 에이전트 애플리케이션을 어떻게 짜는가에서 시작해, 이번 글은 그 에이전트로 팀 전체를 자동화하려 할 때 어디서 무너지는지로 한 걸음 더 나아간다.
출처
Dex Horthy (HumanLayer), “Why Software Factories Fail (or: harness engineering is not enough)” 원문: https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md 기반 키노트: “Why Software Factories Fail” — AI Engineer World’s Fair 2026, https://hlyr.dev/wsff-live