소프트웨어 팩토리

소프트웨어 팩토리는 코딩 에이전트에게 작업 하나가 아니라 큰 목표 하나를 주는 개발 방식이다. 하네스로 감싼 여러 루프가 작업 큐에서 일을 꺼내 처리하고, 리뷰를 통과한 결과만 배포로 넘긴다. 사람은 코드를 직접 쓰기보다 목표와 규칙을 정하고 이 '공장'을 설계·운영한다.

1968년에 나온 생각을 에이전트가 되살렸다

이 용어는 1968년 Bob Bemer의 논문까지 거슬러 올라간다. 소프트웨어도 공장에서 부품을 찍어내듯 반복 가능한 공정으로 만들자는 생각이었지만, 아이디어는 찍어낼 수 없어서 대체로 실패했다. 지금은 에이전트가 코드베이스를 읽고, 파일을 고치고, 테스트를 돌리고, 실패 원인을 찾아 스스로 수정할 수 있게 되면서 이 생각이 다시 나왔다.

루프 하나는 이렇게 돈다

가장 단순한 구현은 프로젝트 목표를 주고 하네스가 계속 진행하도록 두는 것이다. 이슈 트래커의 프로젝트 하나를 루프 하나에 연결하는 식이다.

공장 전체: 큐에서 리뷰 게이트까지

루프 여러 개를 모으면 공장이 된다. 일은 작업 큐로 들어오고, 루프들이 그 일을 처리하고, 리뷰 게이트를 지나야 운영 환경으로 나간다. 계획, 구현, 운영, 피드백으로 이어지는 기존 개발 주기와 같은 흐름인데, 단계 사이의 넘김을 개발자가 일일이 챙기지 않아도 된다. 운영에서 생긴 장애나 고객 피드백이 다음 작업으로 다시 들어온다는 점도 같다. 구조만 보면 상태 머신과 액터 모델을 새로 포장한 것에 가깝다.

도입할 때 주의할 점

가장 흔한 함정은 프로젝트의 목표와 맥락을 사람 머릿속에만 두는 것이다. 에이전트에게 작업만 넘기고 목표는 주지 않으면, 방향이 맞는지나 빠진 작업이 있는지 스스로 판단할 수 없다. 프로젝트 설명을 최신으로 유지하는 것이 곧 공장을 돌리는 일이다. 디자인 패턴의 팩토리 메서드와는 이름만 같고 전혀 다른 개념이다.

이슈 트래커와 리뷰 흐름에 루프를 붙여 쓴다

가장 흔한 방식은 코딩 에이전트를 이미 쓰고 있는 이슈 트래커와 PR 리뷰 흐름에 연결하는 것이다. 목표가 분명하고 테스트로 결과를 확인할 수 있는 작업일수록 공장에 맡기기 좋고, 사람은 리뷰 게이트와 프로젝트 설명 관리에 집중한다.