최근 AI 에이전트를 활용해 소프트웨어 개발 과정을 자동화하는 '소프트웨어 팩토리' 개념이 다시 주목받고 있습니다. 이는 컨텍스트 수집, 행동, 검증을 반복하는 루프(loop)를 대규모로 운영하는 방식으로, 마치 공장에서 제품을 찍어내듯 소프트웨어를 생산하려는 시도입니다. 하지만 이 과정에서 모든 것을 기계에 맡기는 '다크 팩토리'와 인간의 판단을 유지하는 '밝은 팩토리' 사이의 딜레마가 부상하고 있습니다.
소프트웨어 팩토리는 루프, 하네스(harness), 팩토리의 세 계층으로 구성됩니다. 루프는 에이전트가 작업을 반복하는 최소 단위이며, 하네스는 루프가 안전하게 실행되도록 샌드박스와 도구를 제공합니다. 팩토리는 여러 하네스 기반 루프를 동시에 실행하고 검토 게이트를 거쳐 배포하는 전체 시스템입니다. 코드 생성, 테스트, 스캔은 거의 비용 없이 확장 가능하지만, 인간의 검토와 판단은 확장하기 어렵다는 것이 핵심 문제입니다. 사람이 코드를 읽지 않는 다크 팩토리는 단기적으로 개발 속도를 높이는 것처럼 보이지만, 장기적으로는 '이해 부채(comprehension debt)'를 쌓아 시스템 유지보수에 심각한 문제를 초래할 수 있습니다. 복잡한 시스템에서는 테스트가 통과해도 뒤늦게 버그가 발견되거나, 시스템 전체가 갑자기 붕괴하는 상황이 발생할 수 있습니다.
따라서 잘못된 결정의 비용과 영향 범위가 큰 작업, 예를 들어 인증, 결제, 공개 API와 같은 부분에는 사람의 검토를 유지하는 '밝은 팩토리' 접근 방식이 중요합니다. 엔지니어의 역할은 개별 코드를 직접 작성하는 것에서 벗어나, 에이전트가 수행한 진단, 구현, 테스트의 증거를 검증하고 승인하며 결과에 책임지는 '외부 루프'를 설계하고 지키는 역할로 변화해야 합니다. 즉, AI 에이전트가 대부분의 구현을 담당하더라도, 중요한 설계 및 아키텍처 단계에서는 사람이 사전에 개입하여 계획을 검토하고, 배포 전 최종 검증을 통해 잠재적 문제를 방지하는 것이 필요합니다. 이는 아키텍처 관행을 통해 안전망을 구축하고, 모델 바깥에서 장기적인 유지보수성을 확보하는 길입니다. 모든 루프를 같은 모드로 운영하기보다, 각 루프의 위험도와 중요도에 따라 자동화 수준을 조절하는 것이 핵심 기술이 될 것입니다.