The Software Factory 0.1 프리뷰
1장 코드 생성에서 의도 실현으로
더 빨리 만든 뒤에도 남는 문제
섹션 제목: “더 빨리 만든 뒤에도 남는 문제”리더가 AI 도입을 검토할 때 가장 먼저 보는 것은 작업 속도일 수 있다. 코드와 문서가 빨리 만들어지고 변경이 더 자주 제출된다. 그러나 그 활동이 사용자의 문제를 해결했는지, 품질과 운영 부담을 함께 유지했는지는 다른 질문이다. 생성한 결과를 확인하고 합치고 판단하는 시간이 늘었다면 고객이 결과를 얻는 시간은 줄지 않을 수 있다. 자동화할 활동과 개선할 조직의 결과를 구분해야 한다.
이 책은 코드 생성에서 의도 실현으로 평가의 대상을 넓힐 것을 제안한다. 의도는 달성할 결과와 그 이유, 지켜야 할 경계와 성공을 판단할 기준이다. 리더는 무엇을 만들 수 있는지에 더해 무엇을 만들 가치가 있고 어떤 조건에서 결과를 받아들일지 정한다. 생성 속도는 이 목적을 실현하는 과정의 한 요소다.
소프트웨어 팩토리는 무엇을 운영하는가
섹션 제목: “소프트웨어 팩토리는 무엇을 운영하는가”이 책에서 소프트웨어 팩토리는 사람과 에이전트의 소프트웨어 작업을 요청의 접수부터 구현·검증·반영·운영 관찰과 개선까지 연결하는 생산 체계다. 실행할 환경과 도구뿐 아니라 일을 맡길 조건, 결과를 받아들일 증거, 실패와 예외를 판단할 권한을 함께 갖춘다.
리더가 설계할 것은 그 흐름의 연결이다. 구현이 빨라져도 검증이 결과를 따라가지 못하거나 배포 뒤 문제를 받아줄 책임자가 없다면 전체 생산 체계는 제 역할을 하지 못한다. 이 책은 접수·수행·판정·운영의 각 경계에서 무엇을 제공하고 누가 다음 결정을 내릴지 설명한다.
팩토리는 제품 팀 안에서 운영할 수도 있고 여러 팀이 일부 기반을 공유할 수도 있다. 특정 모델이나 제품, 중앙 조직 하나를 필수 조건으로 정하지 않는다. 사람과 에이전트에 수행을 맡기고 결과를 증거로 확인한다. 사업적 약속과 위험을 판단하고 새로운 권한을 허용하는 책임은 사람에게 남는다.
모델·에이전트·하네스가 함께 일한다
섹션 제목: “모델·에이전트·하네스가 함께 일한다”이 책에서 다루는 AI 기반 소프트웨어 팩토리는 모델·에이전트·하네스를 필수 구성으로 본다. 이는 세 개의 독립 제품을 구매해야 한다는 뜻이 아니라, 생산 체계 안에서 갖추어야 할 역할을 구분한 것이다. 에이전트는 모델과 하네스, 도구를 결합해 목표를 수행하는 실행 주체다.
| 구성 | 맡는 역할 | 리더가 확인할 것 |
|---|---|---|
| 모델 | 주어진 맥락에서 내용을 해석하고 다음 행동이나 결과를 생성한다. | 맡길 업무에 필요한 능력·비용·한계 |
| 에이전트 | 목표와 역할에 따라 도구를 사용하고 결과를 확인하며 작업을 이어간다. | 맡긴 결과·협력 범위·완료와 이관 조건 |
| 하네스 | 모델에 맥락을 제공하고 도구 호출·결과 전달·상태 기록·다음 실행을 연결한다. | 실행의 경계·지속성·검증 연결·중단과 재개 |
모델의 응답을 실제 행동과 다음 판단으로 이어주는 장치가 있어야 반복 수행을 맡길 수 있다. 여기서 하네스는 에이전트가 일할 수 있게 하는 실행 기반이다. 자료가 없어도 계속 진행하거나 도구 오류를 성공으로 넘기고 이전 작업을 잃어버리는 실행이라면 모델의 능력만으로 운영의 신뢰를 설명하기 어렵다.
세 역할은 한 도구 안에 묶여 있을 수도 있고 여러 서비스에 나뉠 수도 있다. 리더는 구성요소의 이름보다 실제로 어떤 조건을 누가 집행하고 실패 뒤 무엇을 이어받을 수 있는지 확인한다. 9장은 하네스를 포함한 팩토리의 책임 구조를, 11장은 이 조합의 능력을 평가하는 방법을 다룬다.
구현 예제에서 판단의 연결을 읽는다
섹션 제목: “구현 예제에서 판단의 연결을 읽는다”이 책은 공통 구현 예제로 로보코의 The Software Factory Demo를 사용한다. 글을 작성하고 읽는 예제 서비스를 대상으로 요청·구현·검토·검사·병합·배포를 연결한 공개 프로젝트다.[S59] 뒤의 장은 이 흐름에서 요청의 충분성, 수정 증거, 사람에게 돌아오는 판단, 실패 뒤의 기준 변경을 각각 살펴본다.
파일이 존재하는 사실, 코드가 정한 조건, 공개 실행 기록에서 확인한 결과를 구분해 읽는다. 이 책에서 서비스를 직접 실행하거나 조직 생산성을 측정한 것은 아니다. 다른 조직은 자신의 사용자 결과와 권한·복구 조건에 맞는지 판단해야 한다. 장별 원문 위치와 확인 범위는 구현 사례 지도에 모았다.
결과 단위를 먼저 선택한다
섹션 제목: “결과 단위를 먼저 선택한다”자동화의 출발점은 도구를 많이 배포하는 일이 아니라 관찰할 결과를 선택하는 일이다. 예를 들어 사내 문의의 답변 초안 업무를 생각해 보자. 초안이 빨리 나오는 것만 측정하면 근거가 없거나 오래된 내용을 담은 답변도 성과가 될 수 있다. 정확한 근거를 찾고 필요한 판단을 남겨 문의 처리에 쓰이는 결과를 확인해야 한다.
리더는 사용자 결과, 품질의 경계, 전체 비용과 남은 인간 판단을 함께 정한다. 업무마다 확인 가능한 시점도 다르다. 구현 직후의 검사와 실제 사용에서의 결과를 구분해 누가 언제 다시 볼지 연결한다. 확인할 수 없는 효과는 기대나 가설로 남기고 이미 달성한 성과로 보고하지 않는다.
| 선택할 대상 | 리더가 정할 것 | 관찰할 것 |
|---|---|---|
| 업무 결과 | 누구의 어떤 문제를 해결하는가 | 수용한 결과와 실제 사용 |
| 허용 경계 | 무엇을 위임하고 무엇을 보존하는가 | 권한 밖 행동·예외·복구 |
| 판정 | 어떤 증거로 누가 받아들이는가 | 누락·오류·판정 번복 |
| 투자 | 어떤 역량과 기반을 개선하는가 | 전체 비용·대기·재작업 |
이 표는 이 책의 도입 판단 기준이다. 모든 업무에 같은 지표를 적용하는 제안은 아니다. 결과의 성격과 실패 영향에 맞춰 기준을 정하고, 측정하기 쉬운 활동이 목적을 대신하지 않는지 살핀다.
모델 의존을 줄이려면 운영 조건이 필요하다
섹션 제목: “모델 의존을 줄이려면 운영 조건이 필요하다”좋은 모델은 수행할 수 있는 업무와 비용, 속도에 영향을 준다. 팩토리를 구축해도 그 차이가 사라지지는 않는다. 이 책이 지향하는 것은 특정 모델이 바뀌어도 목적과 수용 기준을 유지하고 품질 변동을 발견할 수 있는 체계다. 최소 수행 능력과 작업 환경의 적합성을 확인해야 그 위임이 가능하다.
P01 ‘의도의 명시화’는 기준과 책임을 드러낸다. 실행 주체를 선별하고 필요한 맥락을 공급하며, 결과를 별도 기준으로 판정하고 실패를 복구할 수 있어야 그 기준이 실제로 유지된다. 규칙을 많이 적거나 모든 결과에 사람의 승인을 붙이는 것만으로 이를 대신할 수는 없다.
완전 자동화도 대상 범위 안에서 설명해야 한다. 어떤 입력을 받고 어떤 결과를 만들며 어떤 예외에서 멈추는지 정한다. 정상 수행을 자동화했어도 기준을 바꾸고 새로운 위험을 감수할 책임은 남을 수 있다. 범위의 자동화 목표와 모든 상황의 성공 보장을 구분한다.
사람의 판단과 조직의 흐름을 함께 설계한다
섹션 제목: “사람의 판단과 조직의 흐름을 함께 설계한다”수행이 빨라져도 승인과 인계, 재설명에 시간이 걸릴 수 있다. 커뮤니케이션 비용은 메시지의 개수보다 필요한 판단과 맥락을 전달하는 부담으로 본다. 이미 정한 기준을 다시 찾는 비용과 새로운 문제를 발견할 협의를 구분해야 한다. 전자를 줄이면서 후자의 통로를 유지하는 것이 과제다.
조직 개편은 그 병목을 확인한 뒤 판단한다. 정보 접근과 권한을 정리하는 것으로 해결할 수 있다면 팀 경계를 바꾸지 않아도 된다. 반대로 결과 책임과 결정 권한이 계속 분리되어 대기와 책임 공백을 만든다면 경계의 재설계를 검토할 근거가 생긴다. 조직도 변경 자체를 자동화의 성과로 보지 않는다.
사람에게도 목적과 결과에 기여할 역할이 필요하다. 기준을 선택하고 잘못된 결과를 거부하며 실패를 개선할 실제 권한과 역량을 연결한다. 16장은 오너십·인지적 참여·책임 행동을 나누어 이 업무 설계를 다룬다. 자동화를 줄인 양으로 사람의 역할이 보존되었다고 판단하지 않는다.
작은 실행 루프에서 가설을 검토한다
섹션 제목: “작은 실행 루프에서 가설을 검토한다”P15 ‘검증을 거치는 개선’은 실패를 분류하고 변경안을 같은 기준으로 확인하도록 제안한다. 처음에는 목적과 결과를 설명할 수 있고 영향과 복구 범위를 제한할 업무를 고른다. 필요한 질문과 개입, 판정 대기와 결과의 품질을 살펴보고 다음에 바꿀 조건을 정한다. 도구 사용률만으로 확대를 결정하지 않는다.
이 책의 패턴은 이미 효과가 입증된 보편 법칙이 아니다. 적용 맥락과 상충하는 요구, 해결 구조와 비용, 실패 조건과 검증 방법을 함께 읽어야 한다. 공개 자료의 관찰과 업체의 보고, 저자의 해석과 제안을 구분하며 자신의 업무에서 가설을 시험한다.
리더는 자동화로 무엇을 해결하려는지 선택하고 그 결과를 판단할 기준을 유지한다. 다음 장은 의도를 일회성 요청에 머물게 하지 않고 이후의 수행과 수용, 개선에서도 접근할 수 있는 기준으로 만드는 방법을 다룬다.
출처와 검토
섹션 제목: “출처와 검토”[S59]. 확인 범위와 한계는 출처 대장, 주장 유형은 자료 확인 범위에 기록한다. 이 장의 적용 방법은 저자 제안이며 실제 조직의 인과 효과·패턴 효과·원서 본문 대조·편집 확정은 완료하지 않았다.
원서 주제의 기존 연결: 원서 주제 연결의 범위.
이 장의 판단을 정리하셨나요?
추천 경로에서 다음