소프트웨어 팩토리, 빛과 어둠

소프트웨어 팩토리는 컨텍스트 수집·행동·검증을 반복하는 루프를 하네스로 감싸 대규모로 운영하며, 인간이 판단하는 밝은 팩토리와 코드 검토까지 기계에 맡기는 다크 팩토리로 나뉨 코드 생성·테스트·스캔은 거의 비용 없이 확장되지만 인간의 검토와 판단은 확장하기 어려워, 생성량보다 결과를 저렴하고 신뢰성 있게 검증하는 속도가 병목이 됨 사람이 코드를 읽지 않으면 코드 규모와 인간의 이해 사이에 이해 부채(comprehension debt) 가 쌓이며, 테스트가 계속 통과해도 장기간 운영한 복잡한 시스템에서는 유지보수 문제가 뒤늦게 나타날 수 있음 완전 자동화는 즉각적이고 드리프트하지 않으며 조작하기 어려운 판정 기준을 갖춘 짧은 루프에만 허용하고, 인증·결제·공개 API처럼 잘못된 결정의 비용과 영향 범위가 큰 작업에는 사람의 검토를 유지해야 함 엔지니어의 역할은 개별 변경을 직접 작성하는 데서 외부 루프를 설계하고 지키는 일로 이동하며, 에이전트가 수행한 진단·구현·테스트의 증거를 검증하고 승인과 결과에 책임져야 함 루프에서 소프트웨어 팩토리까지 소프트웨어를 반복 가능하고 계측 가능한 생산 공정으로 만들려는 발상은 Bob Bemer가 1968년 발표한 「The economics of program production」까지 거슬러 올라감 아이디어를 자동차 부품처럼 찍어내기 어려웠기 때문에 지난 반세기 동안 이러한 시도는 대체로 기대에 미치지 못함 최근 2년간의 변화는 오래된 소프트웨어 팩토리 구상을 다시 검토할 만큼 컸지만, 과거의 함정이 새로운 기회처럼 포장될 수 있음 전체 체계는 루프·하네스·팩토리라는 세 계층으로 구성됨 루프는 하나의 에이전트가 컨텍스트를 모으고 행동한 뒤 결과를 확인하며, 종료 조건을 충족할 때까지 반복하는 최소 작업 단위임 루프 엔지니어링은 사람이 매번 프롬프트를 입력하는 대신 에이전트에 프롬프트를 제공하는 작은 시스템을 설계하는 방식임 하네스는 루프가 실행되는 샌드박스, 사용할 수 있는 도구, 실행 사이에 유지되는 메모리, 완료 여부를 판단하는 게이트를 포함함 하네스 없는 모델은 끝없이 반복할 수 있으므로, 하네스가 루프를 유용하고 안전하게 만듦 소프트웨어 팩토리는 작업 큐에서 항목을 받아 여러 하네스 기반 루프를 동시에 실행하고, 검토 게이트를 거쳐 프로덕션으로 내보내는 구조임 더 큰 단일 에이전트가 아니라 루프로 구성된 조직도에 가까움 엔지니어의 작업 단위도 개별 코드 변경에서 루프, ...