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

사람이 코드를 읽고 쓰지 않는 무인(lights-off) 소프트웨어 팩토리는 생성 속도를 높이지만, 장기 유지보수성을 판단할 인간까지 제거해 복잡한 프로덕션 코드베이스에서 작동하기 어려움 코딩 모델의 강화학습은 테스트 통과처럼 빠르고 명확한 보상을 최적화하며, 수개월 뒤 드러나는 나쁜 설계 비용에는 벌점을 주지 못함 SWE-bench 계열은 버그 수정과 기존 테스트 보존을 평가하지만, 무분별한 try/catch·타입 캐스트·shotgun surgery처럼 코드 품질을 서서히 악화시키는 변경은 걸러내지 못함 현재는 인간이 코드 리뷰를 맡고 제품 요구사항·시스템 아키텍처·프로그램 설계·수직 슬라이스를 구현 전에 검토해야 재작업과 대규모 AI 생성 코드 리뷰를 줄일 수 있음 모델의 제약을 인정하면 무리한 10~100배 자동화 대신 인간 수준에 가까운 품질을 유지하면서 2~3배 빠르게 개발할 수 있으며, 핵심 판단과 코드 읽기는 아직 외주화할 수 없음 루프 중심 소프트웨어 팩토리의 약속과 현실 AI 코딩의 프로덕션 도입 경쟁에서 하네스와 에이전트 루프를 늘리면 된다는 인식이 확산됨 StrongDM의 무인 소프트웨어 팩토리는 인간이 코드를 읽거나 쓰지 않는 방식을 내세움 OpenAI의 Symphony도 하네스 엔지니어링을 기반으로 한 소프트웨어 팩토리 사례임 이 접근은 사람이 병목이고 모델은 충분히 좋으며, 코드 생성 비용이 사실상 낮으므로 더 많이 출시하면 된다는 전제를 둠 목표는 10~100배 속도, 높은 품질, 인간 코드 리뷰 제거를 동시에 달성하는 것임 린터를 더 구성하고 PR 리뷰 봇에 적대적 검토를 지시하면 소프트웨어를 스스로 안전하게 만들 수 있다고 봄 실제 현장에서는 코딩 에이전트의 실수로 장애가 발생하고, 코드베이스가 빠르게 무너진다는 사례가 나타남 Faros AI 보고서는 AI 코딩 도구 도입 이후 다음 변화를 관찰함 리뷰 댓글 수와 길이는 늘었지만, 리뷰 없이 병합되는 PR도 많아짐 인시던트와 개발자당 버그가 증가함 다만 검증된 인과관계가 아니라 상관관계 신호에 가까움 StrongDM의 결과를 보여주는 확정적 데이터는 찾기 어려우며, 2월부터 6월 사이 공개된 업데이트도 드문 편임 복잡한 코드베이스는 바이브 코딩과 다른 문제 소수만 사용하는 사이드 프로젝트와 10년 된 엔터프라이즈 시스템을 유지하는 팀은 공유하는 제약이 거의 없음 바이브 코딩 자체가 아니라 복잡한 코드베이스의 어려운 문제와 프로덕션 ...