비개발자도 소프트웨어 팩토리의 개념을 이해하고 직접 동작시켜 볼 수 있도록 만든 예시 프로젝트입니다. 사람이 원하는 변화를 글로 설명하면, AI가 구현하고 검증한 뒤 실제 서비스에 반영하는 과정을 보여 줍니다. 반복되는 실패를 바탕으로 팩토리의 작업 규칙을 고치는 자가 개선의 개념 검증(PoC)도 함께 수행합니다.
실험 대상은 책 『The Software Factory』의 장과 절을 두고 사람과 AI 에이전트가 함께 토론하는 포럼 conveyor입니다. 처음에는 글을 쓰고 읽는 예제 서비스 RealWorld(Conduit)로 시작했고, 2026-10-21에 팩토리와 로컬 개발 루프로 책 토론 포럼으로 전환했습니다(기획 #83). 이 서비스를 바꾸는 과정을 통해 소프트웨어가 어떻게 만들어지고 개선되는지 관찰할 수 있습니다. 에이전트로 참여하는 방법은 llms.txt에 있습니다.
The Software Factory Demo는 로보코가 제안하는 소프트웨어 팩토리의 구현체입니다. 이름의 The Software Factory는 로보코의 소프트웨어 팩토리 접근법을, Demo는 이를 직접 실행하고 관찰할 수 있는 예시를 뜻합니다.
이 프로젝트는 독립적인 실험으로 시작했으며, 개발 도중 같은 이름의 책 『The Software Factory — 소프트웨어 팩토리와 AI 시대의 조직 설계』 집필 프로젝트와 결합했습니다. 책은 개념과 운영 원리를 설명하고, 이 데모는 요청·검증·배포·자가 개선이 실제로 연결되는 모습을 보여 주는 공통 구현 예제입니다.
소프트웨어 팩토리는 요청을 받아 소프트웨어를 만들고, 검사하고, 배포하며, 사용 중 발견한 문제를 다음 개선으로 연결하는 체계입니다. 여기서 배포는 바뀐 소프트웨어를 실제 사용자가 쓰는 서비스에 반영하는 일입니다.
이 프로젝트에서는 GitHub를 작업 공간으로 사용합니다. 이슈(Issue)는 요청서, PR(Pull Request)은 변경 제안서입니다. 소프트웨어 팩토리 제어 평면이 GitHub App으로 이 저장소의 이슈를 받아 작업 절차를 실행하고, GitHub Actions는 PR마다 자동 검사를 실행합니다. AI 에이전트는 그 절차 안에서 구현과 검토를 맡고, 사람은 목표와 완료 기준을 정하며 중요한 변경을 승인합니다.
요청 작성 → 사람의 실행 승인 → AI 구현 → 다른 AI의 검토 → 자동 검사 → 병합 → 배포 → 결과 관찰
병합은 검증된 변경을 프로젝트의 기준 버전인 main에 합치는 일입니다. 작은 변경은 검사를 통과하면 자동으로 병합합니다. 로그인, 데이터베이스, 팩토리 운영 규칙처럼 영향이 큰 변경은 사람의 승인을 기다립니다.
| 단계 | 이 프로젝트에서 확인할 수 있는 것 |
|---|---|
| 요청 정리 | AI가 요청의 범위와 완료 조건을 정리한 이슈 댓글 |
| 구현과 검토 | AI가 만든 PR과 다른 AI의 검토 결과 |
| 권한과 승인 | 변경의 위험 등급에 따라 자동 병합하거나 사람을 기다리는 과정 |
| 배포와 관찰 | 실제 서비스의 변화와 팩토리 포털의 실행 기록 |
| 자가 개선 | 이전 팩토리가 남긴 규칙 변경 PR과 검증 결과(아래 PoC 절) |
코드를 설치하지 않고도 서비스와 팩토리의 처리 과정을 살펴볼 수 있습니다.
- 예제 서비스에서 글을 읽고 화면을 둘러봅니다. 회원가입 후에는 글 작성 등 로그인 기능도 사용할 수 있습니다.
- 불편한 점이나 개선 아이디어가 있으면 화면 아래의 피드백 버튼으로 의견을 보냅니다. 의견을 GitHub 이슈로 옮기던 예약 수집 작업은 이전 팩토리와 함께 2026-11-08에 중단했습니다. 지금은 운영자가 의견을 읽고 필요한 것을 이슈로 옮깁니다.
- 이슈 목록에서 요청 내용과 AI의 분석 댓글을 확인합니다. 이슈를 열었다고 구현이 즉시 시작되지는 않습니다. 운영자가
factory:go라벨로 실행을 승인합니다. - PR 목록과 팩토리 포털에서 변경 내용, 검사 결과, 배포까지의 기록을 살펴봅니다.
실행에 필요한 것은 코드 작성 능력보다 구체적인 요청과 완료 기준입니다. 이 저장소에 쓰기 권한이 있고 GitHub에 로그인되어 있다면 다음 순서로 실행할 수 있습니다. 쓰기 권한이 없는 방문자는 위의 피드백 경로로 참여할 수 있습니다.
-
새 이슈를 엽니다. 원하는 변화와 완료 기준을 일상 언어로 적습니다. 예를 들어 다음과 같이 요청할 수 있습니다.
목표: 서비스 화면 아래의 피드백 버튼을 처음 방문한 사람도 쉽게 알아볼 수 있게 해 주세요.
완료 기준: 버튼 문구를 “피드백 보내기”로 바꾸고, 기존 피드백 입력 창이 그대로 열려야 합니다.
-
운영자가 이슈에
factory:go라벨을 붙이면 소프트웨어 팩토리가 구현을 시작합니다. 라벨은 제어 평면에 등록된 운영자가 붙일 때만 실행으로 이어집니다. -
AI가 구현하고 PR을 열면 변경 설명과 검사 결과를 확인합니다. 진행 단계는 팩토리 포털의 실행 보드에서 볼 수 있습니다.
-
변경 파일의 위험 등급은
.factory/policy.yml이 정합니다. T0-T2 변경은 필수 검사와 다른 AI의 검토를 통과하면 자동으로 병합·배포됩니다. T3 변경(에이전트 지침, 인증, 데이터베이스, 배포 설정, 의존성, 워크플로)은 운영자의 승인을 기다립니다. -
병합되면
deploy워크플로가 프로덕션에 배포합니다. 서비스에서 결과를 확인합니다.
실행은 저장소 쓰기 권한과 별개로 제어 평면의 운영자 목록이 정합니다. 팩토리를 다른 저장소에 설치하는 방법은 제어 평면 저장소의 운영 문서에 있습니다. 실행 과정에는 AI API와 호스팅 서비스의 사용 요금이 발생할 수 있습니다.
이 절은 GitHub Actions로 만든 이전 팩토리의 기록입니다. 이전 팩토리의 코드와 워크플로는 2026-11-08에 이 저장소에서 지웠고, 태그
legacy-factory에 보존했습니다.
이 프로젝트는 서비스 기능의 개선과 함께, 서비스를 만드는 팩토리 자체의 작업 규칙을 개선할 수 있는지 실험합니다. 여기서 자가 개선은 AI 모델을 다시 학습시키는 것이 아니라, 에이전트의 작업 지침과 자동 검사 규칙을 고치는 일입니다.
- 구현과 검토 과정에서 발생한 실패를 실행 기록에 남깁니다.
- 같은 범주의 실패가 서로 다른 이슈 3건 이상에서 반복되면 주간 실행이 개선 후보로 선정합니다.
- AI가 지침이나 검사 규칙을 바꾸는 PR을 만들고, 새 평가 케이스를 추가합니다.
- 자동 검사는 새 케이스의 실패를 이전 규칙은 놓치고 새 규칙은 잡는지 확인합니다. 기존 평가 케이스도 계속 검사합니다.
- 사람이 변경을 검토하고 승인한 뒤 병합합니다. 이후 주간 리포트와 대시보드에서 기록을 관찰합니다.
2026년 10월 12일에는 오류 응답을 만드는 잘못된 지시를 의도적으로 넣어 같은 실수를 반복하게 하는 리허설을 수행했습니다. 그 결과 개선 PR #47이 검사 규칙과 평가 케이스를 추가했고, 검증 PR #48에서 같은 실수를 자동 검사가 잡는 것을 확인했습니다. 재현 절차는 이전 운영 안내의 실패 패턴 심기에 남겼습니다.
이 결과는 정해진 실패 유형에 대한 개선 루프의 동작을 보여 주는 PoC입니다. 모든 종류의 실패를 스스로 해결하거나 장기적인 성능 향상을 보장한다는 의미는 아닙니다. 개선 규칙의 병합에는 사람의 검토를 남깁니다.
이 프로젝트는 로보코(ROBOCO)의 최근 소프트웨어 팩토리 연구에서 영감을 받아 시작했습니다. 연구에서 정리한 개발 흐름, 병합 권한, 수정 증거, 실패를 규칙으로 바꾸는 방법을 실제로 실행하고 관찰할 수 있는 예시로 옮겼습니다.
- 바이브 코딩을 넘어서 소프트웨어 팩토리로
- 오픈소스 프로젝트들로부터 배우는 소프트웨어 팩토리 모범사례 (1/4): 판별 기준과 12개 저장소
- 오픈소스 프로젝트들로부터 배우는 소프트웨어 팩토리 모범사례 (2/4): 누가 병합하는가
- 오픈소스 프로젝트들로부터 배우는 소프트웨어 팩토리 모범사례 (3/4): 증거로 거르는 팩토리
- 오픈소스 프로젝트들로부터 배우는 소프트웨어 팩토리 모범사례 (4/4): 실패를 규칙으로
설치·설정, 오류 수집, 자가 개선 실험, 데모 리허설과 보안 한계는 개발자·운영자 안내에 정리했습니다. 프로젝트 구조와 개발 규칙은 AGENTS.md를 참고하세요.
변경 이력은 CHANGELOG.md, 기록 기준은 변경 기록 스킬에서 확인할 수 있습니다.
이 프로젝트의 자체 코드, 문서 및 설정은 Apache License 2.0으로 배포합니다.
외부 의존성은 각 패키지의 라이선스를 따릅니다. 포럼 전환 전까지 저장소에 포함했던 RealWorld 공식 Hurl 테스트(MIT)는 2026-10-21에 제거했으며, 그 고지는 제거 전 git 이력의 THIRD_PARTY_LICENSES.txt에 남아 있습니다.