소프트웨어 팩토리가 실패하는 이유: 하네스 엔지니어링만으로는 부족하다

소프트웨어 팩토리가 인간의 코드 검토를 제거하면 실패하는 이유: 모델이 코드베이스 품질을 유지할 수 없기 때문

라이트 오프(lights‑off) 소프트웨어 팩토리—인간이 코드를 읽거나 쓰지 않는 방식—는 실제로 작동하지 않습니다. 2025년 7월에 완전한 라이트 오프 방식을 시도한 후, 저자의 팀은 서비스 중단, 사용자 불만, 그리고 에이전트가 도입한 엉터리 코드(slop code)를 파헤쳐야 했습니다. 더 많은 루프, 더 나은 하네스, 더 많은 토큰이 속도와 품질을 모두 제공할 것이라는 약속은 근본적인 한계를 무시합니다: 오늘날의 모델은 작업이 테스트를 통과하는지 여부에 대해서만 훈련되고 평가되며, 결과 코드가 시간이 지나도 유지보수 가능한지에 대해서는 평가되지 않습니다.

현재의 훈련과 벤치마크는 유지보수성이 아닌 작업 완료에 보상을 줍니다

모델 훈련은 단순한 통과/실패 검증기(예: SWE‑bench Multilingual)로 점수를 매기는 강화 학습을 사용합니다. 잘못된 설계에 대한 패널티가 없기 때문에, 모델은 모든 곳에 try‑catch 블록을 추가하거나 타입 시스템을 약화시키는 게으른 타입 캐스팅을 사용하는 법을 배웁니다. 잘못된 아키텍처의 비용은 몇 주, 몇 달, 혹은 몇 년 후에 나타나기 때문에, 강화 학습 중에 유지보수성을 보상할 빠른 오라클은 존재하지 않습니다. 결과적으로, 최첨단 벤치마크에서 뛰어난 성능을 보이는 모델도 시간이 지나면서 코드베이스를 악화시켜, 단순한 변경에도 여러 곳을 수정해야 하고 숨은 위험이 증가하게 만듭니다.

새로운 벤치마크는 유지보수성을 평가하려 하지만 여전히 한계가 있습니다

SWE‑Marathon(길고 복합적인 작업에 대한 보상), DeepSWE(훈련 데이터에 없는 대규모 오픈소스 작업), Frontier Code(돌연변이 테스트와 판정 모델을 사용한 다중 PR 작업)와 같은 노력은 단순한 통과/실패를 넘어선 품질을 측정하려 합니다. 그러나 좋은 코드와 나쁜 코드를 확실히 구분할 수 있는 모델은 애초에 좋은 버전을 작성했을 가능성이 높으며, 유지보수성을 위한 빠르고 신뢰할 수 있는 오라클은 아직 존재하지 않습니다. 이러한 벤치마크는 유망하지만, 장기적인 코드 건강에 대한 신뢰할 만한 신호를 아직 제공하지는 못합니다.

인간 검토를 전면에 배치하고 레버리지를 높이면 결과가 개선됩니다

조명을 다시 켜는 것—인간 검토를 루프에 포함하는 것—과 전면 부하 정렬(front‑loaded alignment)을 결합하면 재작업이 줄고 검토가 빨라집니다. 권장되는 프로세스는 네 단계로 구성됩니다: 제품 검토(문제와 성공 기준을 정의하는 짧은 문서), 시스템 아키텍처(서비스, 엔드포인트, 스키마, 큐, 저장소 시각화), 프로그램 설계(유형, 메서드 시그니처, 호출 트리, 의사코드의 파일 트리 diff), 그리고 수직 슬라이스(엔드‑투‑엔드 트레이서를 조기에 구축하고 반복적으로 개선). 이 과정에서 약 30분을 투자하면 저자의 경험상 검토 시간을 몇 시간에서 몇 분으로 줄일 수 있습니다.

커뮤니티의 통찰은 인간의 판단, 거버넌스, 모듈식 설계의 필요성을 강화합니다

댓글 작성자들은 몇 가지 실용적인 점을 강조했습니다:

거버넌스와 문화는 모델의 raw 능력보다 더 중요합니다. 신중한 하네스와 인간‑인‑더‑루프, 보안, 규율이 성공적인 다크 팩토리를 가능하게 합니다.
풀 리퀘스트의 사용자 경험은 좋지 않습니다. Linear의 PR 검토 기능처럼 변경 사항을 주제별로 그룹화하고 주석을 추가하는 도구는 인지 부하를 줄여줍니다.
AI는 의도를 만들어낼 수 없습니다. 비전과 가드레일은 인간이 제공해야 합니다.
모듈식 아키텍처를 먼저 구축하면 에이전트가 유지보수성이 낮은 격리된 모듈에서 작업할 수 있습니다.
토큰 보조금이 raw 모델 품질보다 초기 채택을 더 이끌었을 수 있습니다.
하네스 자체를 최적화하는 것—대표적인 repo 수준 데이터셋으로 에이전트 품질을 평가하는 것—은 프론티어 모델의 돌파구를 기다리지 않고도 효과를 높일 수 있습니다.
에이전트는 코드베이스에서 보는 패턴을 따라 하는 경향이 있으므로, 명확하고 일관된 패턴을 확립하면 유용한 코드를 생성하는 데 도움이 됩니다.
복잡한 코드베이스에서는 에이전트가 상태 변수를 반복적으로 추가할 수 있습니다. 이를 합 타입(sum type)으로 리팩터링하거나 공식 모델(예: Quint)을 사용하면 명확성을 회복할 수 있습니다.
1년 이상 된 코드베이스는 백엔드와 프론트엔드를 모두 갖추고 있어도 인간의 명시적인 방향 전환이 여전히 필요합니다. 모델은 인간을 대신해 코드를 이해할 수 없습니다.

모델의 한계 안에서 최적화하라: 이해와 품질을 위해 인간을 루프에 유지하라

핵심 제약은 모델이 격리된 작업에 대한 코드 생성에는 강하지만, 시간이 지나면서 코드베이스 구조를 보존하거나 개선하는 데는 약하다는 것입니다. 점점 더 많은 토큰을 쫓기보다 팀은 이러한 한계를 받아들이고, 더 나은 계획과 점진적 검토를 통해 레버리지를 찾고, 의도 이해, 아키텍처 영향 평가, 유지보수성 보장에 인간을 책임지게 해야 합니다. 이 접근 방식은 라이트 오프 팩토리가 초래하는 중단과 기술 부채를 피하면서 현실적인 2~3배 속도 향상과 안정적인 품질을 제공합니다.