Software factory 논쟁, harness보다 review 병목이 먼저인 이유

AI coding agent를 production에 넣는 팀이 늘면서 “software factory”라는 말이 다시 뜨고 있다. HumanLayer의 글은 그 흐름을 정면으로 겨냥한다. 더 많은 loop, 더 많은 harness, 더 많은 자동 review를 붙이면 사람이 코드를 읽지 않아도 되는가. HN 댓글은 이 질문을 꽤 집요하게 파고들었다.

글의 출발점은 요즘 널리 퍼진 서사다. 모델은 충분히 좋아졌고, 코드는 싸졌고, 사람은 병목이니 더 많이 shipping하면 된다는 주장이다. StrongDM의 lights-off software factory, OpenAI의 harness engineering, 여러 회사의 agent factory 사례가 배경으로 언급된다. 하지만 저자는 build 시간이 minutes/hours로 줄어도 review는 여전히 hours/days라는 점을 짚는다.

흥미로운 대목은 “skill issue” 반박이다. agent 결과가 나쁘면 prompt를 더 잘 쓰거나 token을 더 쓰라는 조언이 반복되지만, 글은 그 한계가 개인 사용법보다 모델 학습과 평가 구조에 있다고 본다. 복잡한 brownfield codebase에서는 agent가 만든 코드가 몇 달 쌓인 뒤 문제가 터지고, 그때는 사람이 이미 읽지 않던 코드로 돌아가야 한다는 설명이다.

저자는 software factory 자체를 부정하지 않는다. 오히려 planning과 architecture alignment를 앞에 두면 review 비용이 줄어든다는 오래된 교훈을 다시 꺼낸다. agent가 구현 속도를 높일수록, 무엇을 만들지 정하고 어떤 품질 기준으로 볼지 정하는 앞단 작업이 더 중요해진다는 뜻이다.

커뮤니티 반응도 “agent를 쓰지 말자”보다 “review를 없앨 수 있다는 말이 너무 빠르다”에 가까웠다. 자동화의 가치는 인정하지만, lights-off factory가 복잡한 제품 운영에서 어떤 실패 모드를 만들지 아직 충분히 공개된 데이터가 부족하다는 시각이다.

HN discussion / source