코드 슬롭(Code Slop)과의 싸움: 소프트웨어 팩토리의 현실

원문 제목: [한영자막] 코드 슬롭(Code Slop)과의 싸움: 소프트웨어 팩토리의 현실을 짚어봅니다 - Dex Horthy
URL: https://www.youtube.com/watch?v=XejHwIKi5qg
Video ID: XejHwIKi5qg
날짜: 2026-10-14
발행일: 2026-10-14
채널: Tech Bridge
발표자: Dex Horthy, HumanLayer CEO·공동 창업자

---

📌 핵심 질문 / 코드 슬롭과 소프트웨어 팩토리의 핵심 논점

==AI 에이전트가 코드를 빠르게 만들어도, 사람의 이해와 피드백 없이 방치하면 장기적으로 코드베이스의 유지보수성과 아키텍처 품질을 보전할 수 없다.== 따라서 목표는 사람을 완전히 제거한 ‘무인 공장(Lights-off Factory)’이 아니라, 사전 계획·가시적 협업·실행 검증·운영 피드백을 에이전트와 결합한 소프트웨어 팩토리다.

• 모델은 단기 과제 해결과 테스트 통과에는 강하지만, 비용이 수개월·수년에 걸쳐 드러나는 유지보수성을 빠르게 판정하지 못한다.
• 점진적으로 기능이 추가되는 실제 개발을 모사한 SlopCodeBench에서 GPT-5.5의 점수는 14.8%에 그쳐, ‘코딩이 해결됐다’는 포화된 벤치마크의 인상을 반박한다.
• 20~30분의 계획, 브라우저·curl·영상 등을 통한 실행 검증, 사용자·인시던트 피드백, 세션 학습을 공장에 넣어야 처리량과 품질을 함께 높일 수 있다.

핵심은 에이전트를 더 자율적으로 만드는 데만 있지 않다. 무엇을 만들지 함께 정하고, 모델이 만든 결과를 빠르게 관찰하고, 실제 사용자와 운영 환경의 역압력(backpressure)을 전달하고, 누적된 세션 경험을 다음 작업에 반영하는 구조가 필요하다.

1. AI 코딩 열풍과 ‘코드 슬롭’ 문제의 출발점

AI가 생산성을 높이는 순간에도 코드 이해와 품질 책임을 포기할 수 없다는 문제의식에서 논의가 시작된다.

1.1. 청중의 현실과 HumanLayer의 역할

1. AI가 작성하는 코드의 비중

   1. 청중에게 코드의 100%를 AI로 작성하는 사람이 있는지 묻자 일부가 손을 들었다.
   2. AI가 만든 코드를 거의 전부 읽으려고 노력하는 사람도 다시 확인했으며, 적어도 생성 속도만큼 검토가 따라가야 한다는 분위기를 만들었다.

2. Dex Horthy와 HumanLayer

   1. Dex Horthy는 HumanLayer의 CEO이자 공동 창업자이며, 코딩 에이전트와 에이전틱 AI에 관한 콘텐츠를 꾸준히 만들어 왔다.
   2. HumanLayer는 여러 사람이 함께 쓰는 멀티플레이어 코딩 에이전트 워크스페이스를 만들고, 누구나 에이전틱 코딩을 잘할 수 있게 하는 것을 목표로 한다.
   3. 제품의 초점은 작은 티켓을 PR로 바꾸는 자동화보다 수백 명의 엔지니어와 수백 개의 저장소가 있는 복잡한 코드베이스에서 어려운 문제를 팀이 함께 푸는 방식이다.
   4. 티켓→PR 또는 Slack 메시지→PR 파이프라인은 만들 수 있지만, 큰 문제에서 엔지니어와 팀이 의미 있게 협업하는 것이 더 어려운 영역으로 제시된다.

1.2. 유행과 품질 지표 사이의 간극

1. 루프와 에이전트 자율성에 대한 과열

   1. 인터넷에는 FOMO와 과장이 많으며, 한때는 프롬프트조차 그만두고 ‘루프(Loops)’만 만들자는 유행이 있었다.
   2. AI 코딩을 무조건 확대하는 담론과 달리 실제 팀의 코드 리뷰와 운영 품질 지표를 함께 봐야 한다.

2. 품질 악화 신호

   1. 2026년 1월경 많은 사람이 Opus 4.5를 충분히 좋은 모델로 받아들인 뒤 나온 보고서에서는 코드 리뷰 품질이 떨어졌다고 지적했다.
   2. 리뷰를 건너뛰는 PR이 늘고, PR의 설명과 코멘트는 길어졌으며, PR당 인시던트와 개발자당 버그가 증가했다.
   3. 이를 단순한 개인의 실력 문제라고 볼 수 있는지 묻자 소수만 손을 들었고, Dex는 데이터가 개인의 skill issue라는 설명과 다르게 말한다고 주장했다.

2. 소프트웨어 팩토리의 역사와 에이전트 도입

소프트웨어 팩토리는 AI가 갑자기 만든 개념이 아니라 수십 년 동안 발전한 개발·검증·배포·운영의 흐름이며, AI는 그 안의 일부 단계를 바꾼다.

2.1. 1968년부터 이어진 소프트웨어 팩토리

1. 개념의 기원

   1. 소프트웨어 팩토리라는 발상은 1968년부터 존재했다.
   2. 같은 해에 ‘소프트웨어 공학(software engineering)’이라는 표현도 등장했으므로, 현재의 AI 공장 담론은 완전히 새로운 발명이라기보다 기존 공학적 생산 체계의 연장선이다.

2. 2022년형 표준 흐름

   1. 팀에는 엔지니어, 제품 관리자, 비전을 이끄는 GM이나 CEO가 있고, 만들 일을 정해 Linear·Jira·Beads 같은 트래커에 넣는다.
   2. 누군가 목록에서 일을 꺼내 구현하고 단위 테스트·통합 테스트를 수행한 뒤 브라우저에서 직접 확인하거나 curl로 요청을 보내 수동 테스트를 한다.
   3. 구현자는 PR을 만들고, 수백 개의 CI 검사와 보안 스캔이 실행되며, 필요하면 사람이 내려받아 직접 테스트하고 코드 리뷰를 한다.
   4. 문제가 있으면 작업자에게 되돌리고, 준비가 끝나면 feature flag·점진적 롤아웃·카나리 시스템을 이용해 프로덕션에 안전하게 배포한다.
   5. 사용자는 기능을 요청하고, 불만을 제기하고, 고장 난 부분을 알려준다. 이 피드백은 다시 팀과 작업 큐로 돌아간다.
   6. 모니터링 시스템은 장애가 발생하면 새벽 3시에 엔지니어를 호출한다. 호출당하는 것은 괴롭지만, 사이트가 내려간 순간 복구할 수 있다는 점에서는 공장의 중요한 기능이다.

2.2. 에이전틱 소프트웨어 팩토리의 변화

1. 빌더의 교체

   1. 기존 공장의 구조 대부분은 남아 있고, 사람이 맡던 ‘구현’ 단계가 에이전트로 바뀐다.
   2. 에이전트는 일을 수분에서 수시간 만에 끝낼 수 있지만, 리뷰·검증·승인·배포에 걸리는 시간은 여전히 수시간에서 수일이다.

2. 검토 단계의 에이전트화

   1. 에이전틱 코드 리뷰와 에이전틱 회귀 테스트를 도입하면 작은 실수는 더 빨리 잡을 수 있다.
   2. 그래도 결과를 이해하고 장기적 구조를 판단하는 리뷰는 병목으로 남을 수 있다.

3. ‘무인 공장’의 한계와 코드 품질의 시간축

생성 단계만 빨라진 상태에서 리뷰를 없애면, 단기 처리량은 올라가도 장기 유지보수 비용이 누적된다.

3.1. Lights-off Factory가 약속하는 것

1. 사람을 검토 루프에서 제거하려는 유혹

   1. 반복적인 코드 리뷰에 지친 팀은 시니어 엔지니어가 리뷰를 싫어하고 번아웃을 겪는다는 이유로 검토 자체를 없애고 싶어 한다.
   2. 나머지 테스트·스캔·자동화에 충분히 투자하면 사람 없이 코드가 통과하는 무인 공장이 가능해 보인다.

2. 핵심 반론

   1. 감독받지 않는 모델은 시간이 지나도 코드베이스의 품질을 유지하거나 개선하지 못한다.
   2. 모델은 현재의 문제를 해결하는 데 매우 좋아졌지만, 코드베이스 전체의 품질을 높이는 작업에는 같은 수준으로 강해지지 않았다.
   3. 모델에게 ‘품질을 개선하라’고 지시하려면 무엇을 어떻게 고쳐야 하는지 사람이 이미 코드베이스를 이해하고 있어야 한다. 그 순간 공장은 다시 감독 상태가 된다.

3.2. 유지보수성에는 빠른 오라클이 없다

1. 강화학습이 선호하는 빠른 정답

   1. 현재의 벤치마크와 보상 체계는 테스트를 통과하게 만드는 행동을 보상하기 쉽다.
   2. 테스트를 통과했지만 아키텍처가 나쁘거나 중복·복잡성이 쌓이는 문제는 단기 점수에 잘 드러나지 않는다.

2. 늦게 드러나는 비용

   1. 나쁜 아키텍처의 대가는 수개월 또는 수년에 걸쳐 측정된다.
   2. 유지보수 가능한지 즉시 판별해 주는 오라클(verifier)은 없다.
   3. 코드가 추해졌다는 사실은 누군가 두 달 뒤 새벽 3시에 장애 호출을 받고, 왜 이런 코드가 코드베이스에 들어왔는지 추적할 때 비로소 드러난다.

3.3. SlopCodeBench가 드러낸 장기 과제의 현실

1. 실제 개발을 닮은 평가 방식

   1. 미국 위스콘신대학교의 한 연구실에서 발표한 SlopCodeBench는 문제 전체를 처음부터 공개하지 않는다.
   2. 모델에 과제를 조금씩 공개하고, 코드를 쓰게 한 뒤 다음 기능을 추가하고, 다시 다음 기능을 추가하게 한다.
   3. 한 번 설계해 배포하고 영원히 건드리지 않는 소프트웨어가 아니라 계속 기능을 추가하고 진화시키는 실제 개발의 모습을 모사한다.

2. 점수와 포화된 벤치마크의 대비

   1. SlopCodeBench가 공개될 당시 최고 수준 모델로 소개된 GPT-5.5의 점수는 14.8%였다.
   2. 따라서 터미널 벤치마크에서 95%를 얻고 ‘코딩이 해결됐다’고 말하는 것과 달리, 장기적인 코드 품질을 측정하는 과제는 아직 포화되지 않았다.
   3. 후속 모델인 Astra와 Sol X I는 GPT-5.5보다 약 1~1.5%포인트 높은 수준으로 언급됐지만, 개선 속도는 ‘모든 문제가 해결됐다’는 주장만큼 빠르지 않다.

3. 연구·업계 사례가 보여주는 누적 슬롭

   1. Anthropic도 시간이 지나며 지저분한 코드가 쌓여 보안 문제가 생긴 일을 회고했다.
   2. 예전에는 “코드가 슬롭이지만 GPT-7의 문제”라고 미룰 수 있다고 농담했지만, GPT-6 시대에도 추상화와 중앙화 같은 구조적 작업은 여전히 어렵다.
   3. 모델이 비디오게임·컴퓨터 사용·Blender 데모 같은 임의의 과제에서 나아지는 것과, 실제 코딩 워크플로에서 좋은 추상화와 중앙화를 수행하는 것은 별개의 문제다.

3.4. Steve Yegge 사례와 태도의 전환

1. 과거의 ‘코드를 읽지 말라’는 주장

   1. Steve Yegge는 Gas Town을 만들었고, Gas Town은 다시 다른 Gas Town을 만드는 데 유용하다는 농담의 대상이 됐다.
   2. 그는 약 1년 동안 인터넷에서 코드를 계속 읽으려 하면 뒤처질 것이라고 주장했다.

2. 최근의 수정된 결론

   1. 최근에는 모델을 주의 깊게 살피지 않으면 슬롭 코드를 쓰고, 모델 스스로도 디버깅할 수 없는 복잡한 것을 만들게 된다고 말했다.
   2. 이는 모델이 만든 코드를 사람의 주의와 검토에서 완전히 분리할 수 없다는 Dex의 핵심 주장과 맞닿는다.

4. 12-Factor Factory: 사람과 에이전트가 함께 품질을 만드는 방법

‘12-Factor Factory’라는 이름은 12개를 모두 채운 공식 목록이라기보다, 기존 소프트웨어 공학의 원칙을 에이전트 시대에 맞게 재구성한 실천 묶음으로 제시된다.

4.1. 만들기 전에 계획하라

1. 짧은 사전 계획의 경제성

   1. 구현 전에 20~30분을 들여 팀이 아키텍처와 작업 분해를 논의하면 리뷰 단계에서 수시간을 아낄 수 있다.
   2. 팀은 AI 이전에도 작업이 수시간 또는 수일 걸리고 리뷰도 수시간 또는 수일 걸리면, 먼저 모여 설계와 범위를 맞췄다.
   3. 목적은 구현 뒤 대규모 재작업이 발생할 가능성을 줄이고 리뷰 단계의 예상 고통(expected pain)을 없애는 것이다.

2. 과소 계획과 과잉 계획 사이

   1. 두 문장짜리 YOLO 프롬프트로 시작하면 나중에 다시 프롬프트를 작성하고 구조를 고칠 확률이 약 50%라고 설명한다.
   2. 5시간 동안 상세 명세를 작성하면 마지막에는 약간의 다듬기만 필요할 확률이 약 90%가 되고, 에이전트가 만든 구조 때문에 전면 재작업할 가능성은 크게 줄어든다.
   3. 코드를 20시간 직접 작성하면 에이전트가 만든 결과를 다시 고쳐야 할 가능성은 없지만, 사람이 만든 코드도 버그가 있을 수 있으므로 테스트와 리뷰는 여전히 필요하다.
   4. 계획 중 버튼 색상처럼 나중에 쉽게 바꿀 수 있는 사소한 사항을 에이전트와 논쟁할 필요는 없다. 바꾸기 어렵고 영향이 큰 결정에 계획 시간을 배분해야 한다.

4.2. 텍스트 벽 대신 시각적으로 정렬하라

1. Show Me 방식

   1. 에이전트의 긴 설명 문단을 끝없이 읽기보다, 모델이 정보를 시각적인 산출물로 보여주게 해야 한다.
   2. HumanLayer가 공개한 ‘show me’ 스킬에는 이 방식의 예시가 들어 있으며, 공개 저장소에서 사용할 수 있고 약 2만 회 설치된 것으로 소개된다.

2. 작업 구조를 먼저 보이기

   1. 스택을 어떤 순서로 나눌지, PR을 어떤 단위로 쪼갤지, 변경을 어떤 순서로 진행할지 모델에게 보여 달라고 한다.
   2. 계획·구조·차이를 시각적으로 맞추면 사람이 벽처럼 긴 에이전트 산문을 읽어야 하는 부담이 줄고, 구현 전에 방향을 바로잡을 수 있다.

4.3. 에이전트에 실행과 역압력을 제공하라

1. 직접 확인 가능한 환경

   1. 에이전트에게 브라우저를 주고 앱을 실행하게 한다.
   2. curl 요청, 자동·수동 테스트, 실행 영상 녹화 등 결과를 실제로 검증할 도구를 제공한다.
   3. 모델이 ‘코드가 그럴듯해 보인다’고 끝내지 않고 실행 결과를 보고 다시 고치도록 하는 것이 역압력(backpressure)이다.

2. TypeScript 안티 슬롭 규칙

   1. TypeScript를 쓰는 팀이라면 Dylan Mulroy가 정리한 저장소를 참고할 수 있다.
   2. 저장소에는 에이전트가 TypeScript 코드베이스에 남기는 안티패턴을 모은 약 100개의 안티 슬롭 규칙이 있다.
   3. SlopCodeBench 논문에 담긴 규칙과 사례도 팀의 검사 규칙으로 가져와 자동화할 수 있다.

4.4. 사용자와 운영 피드백을 공장 안으로 넣어라

1. 지원 티켓을 단순 티켓으로 변환하지 않기

   1. 지원 티켓을 사람이 읽고 Jira 티켓으로 옮기는 중간 단계를 반복하기보다, 지원 티켓과 에이전트가 만든 PR을 함께 확인한다.
   2. 사용자 표현과 코드 변경을 직접 연결하면 요구사항의 맥락이 손실되지 않고 처리량이 높아진다.

2. 인시던트 대응을 PR로 연결하기

   1. 새벽 3시의 pager alert가 발생하면, 경보와 함께 에이전트가 장애를 고칠 것이라고 판단한 PR을 제시하게 한다.
   2. 그 PR의 절반만 바로 머지할 수 있어도 처리량에는 큰 차이가 난다.
   3. 엔지니어가 깨어나서 PR을 확인하고 머지한 뒤 다시 잠드는 흐름은, 장애 대응의 첫 작업을 자동화하는 현실적인 방식이다.

4.5. 모델이 여러 대안을 실험하게 하라

1. 기능 플래그 기반 실험

   1. 에이전트에 feature flag 도구를 주면 하나의 기능에 대해 세 가지 버전을 만들어 비교하게 할 수 있다.
   2. 하나를 미리 정답으로 고르는 대신 실제 사용자에게 여러 변형을 노출하고 결과를 측정한다.

2. UI에는 사용자 자체가 검증기

   1. 모델은 아름다운 UI를 만들 수 있어도 사람처럼 화면을 보고 사용성을 판단하지는 못한다.
   2. 세 가지 UI를 사용자에게 보여주고 사람들이 어느 버전을 더 쉽게 이해하고 사용할 수 있는지 측정하면, 모델에 UI 작업의 역압력을 전달할 수 있다.

4.6. 루프를 순방향 압력과 역방향 피드백으로 분해하라

1. 새 일을 시작시키는 순방향 압력

   1. 루프는 신비한 마법이라기보다 어떤 조건이 새 작업을 발생시키는지 정하는 구조다.
   2. 일정(schedule), 자동화(automation), 웹훅(webhook) 등이 작업을 시작시키는 트리거가 된다.

2. 작업 중 결과를 개선하는 역방향 피드백

   1. 에이전트가 사람에게 매번 돌아오지 않아도 결과를 조금씩 개선하도록 실행 결과·테스트·사용자 반응을 피드백으로 제공한다.
   2. 이 과정을 통해 에이전트가 목표를 향해 언덕을 올라가는(hill-climb) 것처럼 점진적으로 결과를 개선할 수 있다.

3. 시간에 따른 복리 효과

   1. 팀의 과거 세션과 작업 기록을 분석해 무엇에서 막혔는지 파악한다.
   2. 반복되는 해결법을 스킬·메모리·규칙으로 추출해 다음 세션에 반영하면 경험이 누적된다.
   3. 이 누적 학습은 단순히 더 많은 에이전트를 띄우는 것보다 공장의 장기 생산성을 높이는 핵심이다.

5. AI 시대의 소프트웨어 포지와 SDLC 재설계

에이전트가 코드를 쓰는 것만으로는 새 공장이 완성되지 않으며, 실행 인프라부터 협업·통제·기록까지 네 개의 계층이 필요하다.

5.1. 세션과 계획이 새로운 협업 기록이 된다

1. Git 이전과 이후

   1. 과거에는 Git 패치를 이메일 리스트로 주고받았고, Linus Torvalds는 여전히 Linux 커널을 위해 비슷한 방식을 사용한다.
   2. 대부분의 팀은 GitHub를 사용하면서 프로토콜은 분산돼 있어도 변경 협업을 중앙화된 장소에서 처리하게 됐다.

2. AI 네이티브 협업의 문제

   1. 사람이 에이전트와 나눈 세션이나 계획을 복사해 Slack·Teams에 붙여 넣고, 동료가 다시 자기 에이전트에 붙여 넣어 답을 얻은 뒤, 그 답을 다시 복사해 돌아오는 흐름이 생긴다.
   2. 이 왕복은 한 번으로 끝나면 좋지만, 현재는 여러 차례 반복되기도 한다.
   3. 세션 trace, 아키텍처 문서, 계획, 프롬프트가 하나의 중앙 시스템에 남아야 새로운 SDLC의 기록과 협업 기반이 된다.

5.2. 네 개의 계층

1. Compute layer

   1. Kubernetes 클러스터의 여분 pod에서 에이전트를 실행하거나 Daytona·E2B 같은 컴퓨트 환경을 구매할 수 있다.
   2. 핵심은 에이전트가 안정적으로 실행될 자원과 격리 환경을 확보하는 것이다.

2. Development environment layer

   1. 언어와 런타임을 설치하고, preview environment를 제공해야 한다.
   2. 에이전트가 작업을 테스트하려면 VPC 내부 서비스 연결이 필요한지까지 개발 환경에서 해결해야 한다.

3. Harness layer

   1. 에이전트가 도구를 호출하고 테스트하고 결과를 반복해 개선하는 하네스는 구매하거나 직접 만들 수 있다.
   2. 이 계층은 모델 자체와 실행 환경 사이에서 작업 방식과 피드백을 조정한다.

4. Control plane layer

   1. 어떤 작업을 어디로 보낼지(dispatch), 세션과 계획에서 어떻게 협업할지 결정하는 계층이다.
   2. 에이전트의 실행만큼이나 사람과 에이전트의 공동 작업을 관리하는 통제면이 중요하다.

5.3. HumanLayer의 협업 워크스페이스

1. 공유 세션과 공동 프롬프트

   1. HumanLayer는 팀원이 무엇을 작업하는지 한눈에 보고, 동료의 세션에 들어가고, 자신의 세션에 다른 사람을 초대할 수 있는 공유 워크스페이스를 지향한다.
   2. 세션은 클라우드에서만 실행되는 것이 아니라 개인 노트북의 Cloud Code 세션에도 동료를 불러올 수 있다.
   3. Google Docs와 Notion을 연상시키는 아티팩트 협업 기능이 세션 화면에 들어간다.

2. PR 이전의 실시간 코드 리뷰

   1. 어디에서 실행되는 에이전트든 코드 작성 중 diff를 클라우드로 스트리밍한다.
   2. 따라서 PR이 생성될 때까지 기다리지 않고 변경 중인 코드 자체를 리뷰할 수 있다.
   3. HumanLayer는 이 구조를 약 1년 동안 대부분 공개하지 않은 채 구축해 왔으며, 컨트롤 플레인과 자체 하네스 일부를 오픈소스로 공개할 계획을 밝혔다.

3. 공개 자료와 후속 탐색

   1. Dex는 관련 자료를 시대별·연대기순으로 정리한 humanlayer.dev/resources를 안내했다.
   2. HumanLayer의 더 깊은 구조는 발표 후 복도에서 직접 논의할 수 있다고 했으며, 참석자에게 자료를 확인하고 이메일로 연락하라고 초대했다.

주요 발언 모음

“감독받지 않는 모델은 시간이 지나도 코드베이스의 품질을 개선하거나 유지하지 못한다.”

“유지보수성에는 빠른 오라클이 없다.”

“계획은 예상되는 고통을 없애는 일이다.”

“에이전트에게 역압력을 줘라. 브라우저를 주고, 앱을 실행하게 하고, curl을 쓰게 하고, 영상을 녹화하게 하라.”

“루프는 순방향 압력과 역방향 압력의 결합이다.”

“모델에 주의를 기울이지 않으면 슬롭 코드를 쓰고, 모델 스스로도 디버깅할 수 없는 복잡한 것을 만들게 된다.”

핵심 데이터 & 수치

• 1968년: 소프트웨어 팩토리 개념과 ‘소프트웨어 공학’이라는 표현이 등장한 시점으로 언급됐다.
• 1월 이후: Opus 4.5를 충분히 좋은 모델로 받아들인 뒤 코드 리뷰 품질 저하와 인시던트·버그 증가 신호가 나타났다는 보고가 소개됐다.
• 20~30분: 구현 전 계획에 투자하면 리뷰에서 수시간을 절약할 수 있는 권장 시간이다.
• 50%: 두 문장짜리 YOLO 프롬프트로 시작했을 때 나중에 추가 프롬프트와 재작업이 필요할 가능성의 예시다.
• 약 90%: 5시간짜리 상세 명세 뒤에는 전면 재작업보다 마지막 다듬기만 필요할 가능성의 예시다.
• 약 100개: Dylan Mulroy의 TypeScript 안티 슬롭 규칙 수로 소개됐다.
• 약 2만 회: 공개된 ‘show me’ 스킬의 설치 수로 소개됐다.
• 14.8%: SlopCodeBench에서 공개 당시 최고 모델로 소개된 GPT-5.5의 점수다.
• 약 1~1.5%포인트: 후속 모델인 Astra와 Sol X I가 GPT-5.5보다 높다고 언급된 차이다.
• 수개월~수년: 나쁜 아키텍처와 유지보수성 저하의 비용이 드러나는 시간축이다.
• 약 1년: HumanLayer가 공유 세션·실시간 diff 리뷰 구조를 대부분 비공개로 구축해 온 기간이다.

핵심 요약 (20줄)

1. AI가 코드를 만드는 속도와 사람이 코드의 장기 품질을 이해하는 속도 사이에는 큰 격차가 있다.
2. 소프트웨어 팩토리는 1968년부터 이어진 개발·검증·배포·운영 체계이며 AI는 그 일부인 구현 단계를 바꾼다.
3. 2022년형 공장은 트래커의 작업을 구현하고 테스트·CI·보안 스캔·사람 리뷰를 거쳐 안전하게 배포했다.
4. 에이전틱 공장은 구현을 수분 또는 수시간으로 줄이지만 리뷰와 승인에 걸리는 시간은 여전히 수시간 또는 수일이다.
5. 모든 검토를 제거한 Lights-off Factory는 단기 처리량을 높여도 코드베이스 품질을 보장하지 못한다.
6. 감독받지 않는 모델은 개별 문제를 풀 수 있지만 시간이 지나며 아키텍처와 유지보수성을 개선하지 못한다.
7. 나쁜 아키텍처의 비용은 수개월 또는 수년에 걸쳐 나타나므로 빠른 보상 함수가 이를 제대로 측정하기 어렵다.
8. SlopCodeBench는 기능을 조금씩 추가하는 실제 개발을 모사해 장기 코드 품질을 평가한다.
9. GPT-5.5의 SlopCodeBench 점수 14.8%는 포화된 터미널 벤치마크만으로 코딩이 해결됐다고 말하기 어렵다는 근거다.
10. Anthropic의 보안 문제 회고와 Steve Yegge의 태도 변화는 누적되는 코드 슬롭의 위험을 보여준다.
11. 모델에게 품질 개선을 맡기려면 사람이 코드베이스를 이해하고 무엇을 고칠지 지정해야 하므로 완전한 무인 상태가 아니다.
12. 구현 전 20~30분의 팀 계획은 리뷰 단계의 재작업과 예상 고통을 줄이는 가장 값싼 투자다.
13. 계획은 모든 세부사항을 고정하는 일이 아니라 영향이 크고 바꾸기 어려운 결정을 먼저 정렬하는 일이다.
14. Show Me 방식은 긴 에이전트 산문 대신 구조·작업 분해·PR 순서를 시각적으로 보여주게 한다.
15. 브라우저·curl·실행 영상과 TypeScript 안티 슬롭 규칙은 에이전트에 실행 결과라는 역압력을 제공한다.
16. 지원 티켓과 인시던트 경보를 에이전트 PR로 직접 연결하면 사람이 중간 티켓을 옮기는 시간을 줄일 수 있다.
17. feature flag로 여러 UI를 실험하면 실제 사용자가 모델 결과를 검증하는 피드백 루프가 만들어진다.
18. 루프는 일정·자동화·웹훅으로 일을 시작하는 순방향 압력과 실행 결과로 개선하는 역방향 압력의 결합이다.
19. 세션 trace·계획·프롬프트·아키텍처 문서를 중앙 기록으로 모아야 팀의 에이전트 경험이 복리처럼 누적된다.
20. 차세대 공장은 컴퓨트·개발 환경·하네스·컨트롤 플레인의 네 계층과 사람의 지속적인 판단을 함께 갖춰야 한다.

결론 및 시사점

1. 생성 속도보다 품질의 시간축을 측정한다: 테스트 통과율이나 짧은 작업의 성공률만 보지 말고, 기능이 추가된 뒤 구조가 유지되는지, 인시던트와 재작업이 줄어드는지 추적해야 한다.
2. 리뷰를 없애기보다 리뷰를 앞당기고 가볍게 만든다: 구현 전에 아키텍처를 정렬하고, 모델이 계획과 diff를 시각적으로 보여주게 하며, PR 이전부터 협업하면 사람의 판단을 더 중요한 결정에 집중할 수 있다.
3. 실행 환경을 모델의 품질 장치로 사용한다: 브라우저·런타임·내부 서비스·feature flag·카나리·실제 사용자 반응을 연결해 모델이 결과를 관찰하고 수정하게 해야 한다.
4. 운영과 사용자 피드백을 개발 입력으로 바꾼다: 지원 티켓과 pager alert를 에이전트가 분석하고 수정 PR을 제안하게 하면 공장이 실제 문제를 중심으로 순환한다.
5. 팀의 세션을 조직 자산으로 축적한다: 반복되는 실패와 해결책을 스킬·메모리·규칙으로 남겨 다음 세션에 공급할 때 에이전트의 자율성은 품질 감독과 양립할 수 있다.
6. 네 계층을 통합한 협업 구조를 만든다: 컴퓨트, 개발 환경, 하네스, 컨트롤 플레인을 따로 최적화하는 데 그치지 말고 세션·계획·diff를 공유하는 시스템으로 묶어야 한다.

참고 링크

• 발표 자료 모음: https://humanlayer.dev/resources
• HumanLayer: https://www.humanlayer.dev/
• 12-Factor Agents: https://github.com/humanlayer/12-factor-agents
• SlopCodeBench 논문: https://arxiv.org/abs/2603.24755
• SlopCodeBench 리더보드: https://snorkel.ai/leaderboard/slopcode-bench/
• Agentic AI Foundation: https://aaif.io/