The Software Factory 0.1 프리뷰
서문 · 소프트웨어를 생산하는 조직
왜 The Software Factory인가
섹션 제목: “왜 The Software Factory인가”소프트웨어 개발과 운영을 완전히 자동화하는 체계를 소프트웨어 팩토리라고 할 때, 이 책은 그 가운데 로보코가 제안하는 방식을 다룬다. 제목을 『소프트웨어 팩토리』가 아니라 『더 소프트웨어 팩토리(The Software Factory)』로 정한 이유다. 제목의 The에는 개발·검증·운영을 연결하는 로보코의 구체적인 접근을 담았다.
이 책의 주제는 소프트웨어 팩토리를 만들고 운영하는 조직의 판단이다. 좋은 모델은 중요하다. 그러나 모델이 바뀔 때마다 개발 방식의 신뢰성이 흔들린다면 우리는 그 능력을 충분히 시스템으로 바꾸지 못한 것이다. 모델이 가진 능력을 활용하면서도 목적과 품질 기준을 지속적으로 유지할 방법이 필요하다.
사람에게 일을 맡길 때도 같은 질문을 한다. 무엇을 달성해야 하는가. 어떤 제약을 지켜야 하는가. 결과를 무엇으로 판단할 것인가. 말로 지시할 수 있는 업무라면 자동화의 후보가 될 수 있다. 다만 사람이 말 사이에서 이해하는 관행과 예외를 드러내고 실제 행동 및 검증으로 연결하는 작업이 뒤따라야 한다.
이 책에서 의도는 개발을 시작하는 순간의 요청이 아니다. 의도는 목적과 기대 결과와 제약 및 성공 기준을 포함하며 개발 이후에도 결과를 판단하는 기준으로 남는다. 정책은 그 의도를 지키기 위한 경계를 정한다. 실행계획은 정책 아래에서 수행할 작업과 확인 절차를 정한다. 수행 결과를 관찰하면 실행이 잘못되었는지, 계획이 부족했는지, 정책이 목적에 맞지 않았는지 질문할 수 있다.
완전한 자동화는 이 책이 지향하는 방향이다. 그 방향으로 가는 동안 자동화의 범위는 실제 수행 증거에 따라 넓힌다. 목적을 바꾸는 판단과 기존 정책을 수행하는 판단을 구분하고, 실패한 작업이 어떻게 멈추고 복구되는지도 설계한다. 자동화의 진척은 사람이 입력한 프롬프트 수보다 사람이 개입해야 하는 이유를 얼마나 명시적인 절차로 바꾸었는지에서 확인할 수 있다.
이 책에서 소프트웨어 팩토리는 사람과 에이전트가 수행하는 소프트웨어 작업을 요청의 접수부터 구현·검증·배포·운영 관찰과 개선까지 연결하는 생산 체계다. 어떤 일을 맡기고 어떤 증거로 받아들이며 실패 뒤 누가 판단할지를 정한다. 사람이 모든 작업의 다음 단계를 지시하지 않아도 진행되는 구조를 만들며, 필요한 판단은 근거와 함께 사람에게 전달한다. 코드 생성이 빨라질수록 검증과 병합 및 예외 처리의 처리량이 중요해진다.
이 책이 다루는 AI 기반 팩토리에는 모델의 수행 능력, 목표를 맡아 행동하는 에이전트, 그 실행을 이어주는 하네스가 함께 필요하다. 하네스는 필요한 맥락과 도구, 상태·권한·검증의 경로를 연결한다. 리더는 이 조합을 실제 업무에 맞게 갖추고 운영할 책임을 정해야 한다.
이 변화는 실행 주체를 선별하는 방식에도 영향을 준다. 실제 업무를 수행할 수 있는 모델과 에이전트의 조합을 평가하고 비용과 실패 유형을 관찰해야 한다. 사람에게는 고객을 이해하고 목적을 판단하며 실행 체계를 설계하는 역량이 요구된다. 좋은 실행자를 고르는 일과 좋은 시스템을 만드는 일이 함께 중요해진다.
조직의 구조도 같은 관점에서 살핀다. 구현이 빨라도 설명과 인계 및 승인 대기가 길면 고객이 결과를 받는 시간은 줄지 않는다. 우리는 커뮤니케이션 비용을 메시지 개수로만 보지 않는다. 필요한 맥락을 전달하는 시간, 판단을 기다리는 시간, 오해를 수정하는 시간을 함께 본다. 실제 병목에 맞춰 역할과 권한 및 팀 경계를 바꿀 수 있어야 한다.
설명 가능성은 실행의 근거를 다시 확인할 수 있다는 의미로 사용한다. 어떤 의도와 정책 아래 작업했고 어떤 증거로 결과를 받아들였는지 남긴다. 독자는 이 책의 패턴과 사례를 이용해 자신의 업무에서 작은 실행 루프를 만들고 그 효과를 평가할 수 있을 것이다.
이 책은 소프트웨어 조직의 리더를 위해 쓴다. 설치와 설정의 상세 절차보다 지속적인 원리와 판단에 집중하며, 공개된 오픈소스 자료와 AI 업체의 설명에서 확인한 관찰을 사용한다. 관찰한 사실과 사례 주체의 주장, 그로부터의 해석과 이 책의 제안을 구분한다.
구현을 따라 읽는 공통 예제
섹션 제목: “구현을 따라 읽는 공통 예제”로보코가 제안하는 소프트웨어 팩토리의 구현체인 The Software Factory Demo가 공개되어 있다.[S59] 이 책은 직관적인 이해를 돕기 위해 이 데모를 책 전체의 공통 예시로 활용한다. 요청이 작업으로 정리되고 에이전트가 수행하며, 검증·반영·실패 처리와 개선으로 이어지는 구조를 관련 장에서 함께 살펴본다.
독자는 원칙을 읽은 뒤 데모에서 그 판단이 어디에 연결되는지 확인할 수 있다. 문서와 코드에서 확인한 구조, 공개 실행 기록에서 관찰한 결과의 범위를 각 장에 밝히며 자신의 업무에 적용할 조건을 판단하도록 돕는다.
기획의 기준과 생각의 출발점
섹션 제목: “기획의 기준과 생각의 출발점”이 책의 독자와 다룰 문제를 정할 때 가장 직접적인 기준으로 삼은 책은 스티브 매코널의 『More Effective Agile: A Roadmap for Software Leaders』, 한국어판 『애자일 조직은 이렇게 일합니다』다.[S06] 소프트웨어 조직의 리더가 팀·작업·품질·투자·조직 운영을 판단한다는 독자 관점을 이 책의 기획에 반영했다.[S05][S12] 그 문제들을 AI와 에이전트가 수행에 참여하는 조건에서 다시 묻되, 목차와 논증은 이 책의 의도·실행·검증·책임 문제에 맞춰 구성했다. 원서와의 구체적인 연결은 공개 목차와 일부 공개 미리보기의 확인 범위에 근거한다.
문제의식의 직접적인 출발점은 로보코에 쓴 「바이브 코딩을 넘어서 소프트웨어 팩토리로」와 「오픈소스 프로젝트들로부터 배우는 소프트웨어 팩토리 모범사례」 연재다.[S01][S02] 여기에 저자의 앞선 작업인 Intent Engineering, Vibe Adoption Framework(VAF), VDLC, Vibe Up을 관련 장의 논의로 연결했다.[S69][S70][S71][S72] 이 자료들은 각각 작성 당시의 질문과 맥락을 갖는다. 뒤의 장에서는 당시 제안과 이 책에서 발전시킨 해석을 구분해 설명한다.
의도 관리에 관한 선행 논의로 Richard Stockley와 J-Tech Japan의 Intent-Driven Development도 참고했다.[S03][S04]
작업에 쓸 자원의 상한을 생각할 때에는 Ryan Singer의 『Shape Up』에서 다루는 시간 상한과 추정의 구분, 그리고 이를 재해석한 Vibe Up을 참고했다.[S75][S72] 성과 측정에서는 로보코의 비공식 DORA AI Guide를 원 자료를 찾아가는 안내로 활용하고, DORA의 측정 글을 별도로 확인했다.[S73][S74] 각 방법의 원래 적용 맥락과 이 책의 제안을 구분했다.
실행과 검증의 구조를 구체화할 때에는 OpenAI와 Anthropic의 공개 엔지니어링 글·평가 지침, 공개 오픈소스의 문서와 변경 기록을 참고했다.[S09][S10] 이 사례들은 문서·코드·실행 기록에서 실제로 확인한 범위에 맞춰 설명한다.
웹 독서판의 구성에서는 『Shape Up』의 온라인판을 참고했다. 부·장·절의 목차와 장별 페이지로 읽는 방식을 벤치마크하고, 이 책의 독자에게 맞게 목적별 추천 경로와 이어 읽기를 더했다.[S76] 본문 논증의 참고 자료와 독서 경험의 참고 대상을 구분해 밝힌다.
이 책을 읽는 순서와 자료의 범위
섹션 제목: “이 책을 읽는 순서와 자료의 범위”1부는 무엇을 지키고 누가 기준을 바꿀지 정한다. 2부는 이를 개별 작업의 계약·분해·수용·복구에 적용한다. 3부는 그 흐름을 유지할 생산 기반과 지식·능력·권한을 배치한다. 4부는 사람의 역량과 조직의 판단·학습 조건을 다룬다. 5부는 결과를 측정하고 도입·개선·확대를 결정한다. 뒤의 장은 앞의 원칙을 새 판단에 적용하므로 필요한 기준 장으로 돌아가 읽을 수 있다.
이 책의 패턴과 업무 설계는 적용 조건 아래에서 평가할 제안이다. 공개 문서의 설명, 코드가 정한 조건, 실행 기록의 결과, 조직의 운영 효과는 서로 다른 근거로 다룬다. 별도 확인이 없는 효과를 입증된 성과로 읽지 않는다. 각 장은 판단에 중요한 자료의 시점과 확인 한계를 밝히고 출처와 주장 메모로 연결한다.
『More Effective Agile』과의 연결은 공개 목차를 기준으로 이 책이 다시 묻는 조직 문제다. 원서 본문 전체를 대조한 세부 논증의 요약·동의·반박이 아니다. 판본과 확인 범위는 원서 주제 연결의 범위에 남긴다.
사내 문의의 근거 검색·초안·발송, 고객 정보의 조회·변경은 설명을 위한 가상 업무다. 같은 예시를 이어 쓰더라도 조회 권한과 정보 변경 권한, 초안 수용과 외부 발송은 각각 판단한다. 구현 예제의 원문과 확인 범위는 각 장의 출처에서 찾아볼 수 있다.
독자의 의견을 기다린다
섹션 제목: “독자의 의견을 기다린다”읽으며 발견한 오탈자, 설명이 부족한 부분, 다른 관점은 책의 GitHub 이슈에 남겨 주시기 바란다. 장·절이나 페이지 주소와 읽은 판본을 함께 알려주면 검토에 도움이 된다.
핵심 정의와 방향은 저자의 집필 제안이다. 위 자료의 원문과 확인 범위는 출처 대장에 기록한다. 기획의 기준, 선행 논의, 사례와 웹 구성의 참고 역할을 구분했다.