9장 팩토리의 책임과 경계를 정한다

실행이 빨라져도 책임은 남는다

여러 제품 팀이 같은 실행 환경과 검증 장치를 사용하면 공통 기반을 관리할 책임이 필요해진다. 그러나 공통 기반을 제공하는 팀이 모든 제품의 성공 조건까지 판단할 수 있는 것은 아니다. 검사가 통과했는데 사용자의 문제가 남았을 때 제품 팀은 검증 장치를 탓하고, 기반 운영자는 주어진 검사를 수행했다고 답할 수 있다. 작업이 기술적으로 끝났어도 결과를 다시 판단할 책임이 불분명하면 다음 대응은 멈춘다.

이 책에서 소프트웨어 팩토리는 의도를 정책과 계획, 수행, 검증, 운영 관찰과 개선에 연결하는 생산 체계다. 특정 제품이나 하나의 중앙 조직을 뜻하지 않는다. 제품 팀 안에서 이 체계를 운영할 수도 있고, 여러 팀이 일부 기반을 공유할 수도 있다. 리더는 먼저 어느 기능과 판단을 함께 제공할 이유가 있는지, 제품마다 달라야 하는 기준은 무엇인지 정해야 한다.

4장은 결과를 다음 판단으로 돌려보내는 루프를, 5~8장은 개별 작업의 위임·분해·수용·복구를 다뤘다. 이 장은 그 흐름을 운영할 책임을 제품 팀과 공유 기반에 배치한다. P03 ‘실행 가능한 계약’은 팀 사이에서 맡기는 작업의 조건을 연결한다. P06 ‘증거 기반 완료’는 기반의 실행 완료와 제품 결과의 수용을 구분할 근거를 제공한다. P13 ‘의도부터 결과까지 추적’은 문제가 생겼을 때 어느 기준과 실행을 다시 확인할지 연결한다. 이 책임 구조는 이 책의 설계 제안이며 효과는 실제 업무에서 평가해야 한다.

제품의 판단과 공통 기반의 판단을 구분한다

제품 팀은 누구의 어떤 문제를 해결할지, 어떤 결과를 수용할지에 필요한 업무 지식을 제공한다. 공유 생산 기반의 운영자는 계약에 따라 실행하고 결과를 확인할 환경과 기록을 제공한다. 조직 공통의 정보 취급이나 권한 정책은 해당 위험을 책임지는 주체가 유지한다. 이 역할은 조직의 규모와 업무에 맞춰 배치할 수 있다. 직책을 새로 만들기 전에 어떤 결정이 누구에게 속하는지 식별해야 한다.

다음 표는 역할을 배치할 때 사용할 제안이다. 작은 조직에서는 한 사람이 여러 책임을 맡을 수 있다. 큰 조직에서는 하나의 책임을 여러 팀이 나눠 수행할 수 있다. 어느 경우에도 최종 판단의 책임자와 필요한 정보를 제공할 주체가 드러나야 한다.

판단 대상	제품 팀이 제공할 것	공유 기반이 제공할 것	식별할 판단 책임
작업 접수	목적·산출물·수용 조건·관련 소비자	지원 범위·필요 입력·실행 가능성	사업 우선순위와 접수 여부
정책 적용	제품 특유의 약속과 위험	공통 정책의 적용·충돌 확인	정책 변경과 예외 승인
수행·검증	업무별 평가 자료와 해석 기준	실행 환경·검증 경로·결과 증거	결과 수용과 미검증 조건
배포·운영	사용자 영향과 관찰할 결과	배포 기록·중단·복구 경로	배포 허용과 영향 조정
개선	의도와 결과의 차이	실패 기록·기반 변경의 영향	바꿀 대상과 효과의 판정

공유 기반에 업무별 수용 기준을 모두 맡기면 제품 지식이 없는 곳에 사업 판단이 모일 수 있다. 반대로 제품 팀이 공통 실행 환경까지 각각 유지하면 중복 운영과 서로 다른 기록 형식이 생길 수 있다. 리더는 공유할 때 줄어드는 부담과 새로 생기는 조정 비용을 함께 판단한다. 공유 범위는 중앙화의 정도보다 반복해서 제공할 수 있는 기능과 책임으로 정한다.

저자의 조직 설계 원고는 공통 기반, 현장의 맥락을 연결하는 역할, 제품의 최종 책임을 함께 배치하는 구성을 제안한다.[S39] 이 책에서는 이를 규모에 맞게 선택할 수 있는 구조로 다룬다. 현장의 연결 역할은 공통 기준을 업무에 적용하고 반복 실패를 기반 운영자에게 돌려보낼 수 있다. 별도 직책을 반드시 신설할 필요는 없다. 공유 기반의 품질과 지원에는 기반 운영자의 책임이 남으므로 제품 팀이 모든 원인을 단독으로 책임지는 구조로 해석해서도 안 된다.

하네스가 실행을 지속할 조건을 만든다

1장에서 모델·에이전트·하네스의 역할을 나눴다. 이 장에서 하네스는 에이전트의 실행 루프를 유지하는 기반이다. 현재 목표와 상태를 읽어 모델에 필요한 맥락을 전달하고, 모델이 요청한 도구 호출을 허용된 경로로 실행하며, 결과나 실패를 다음 판단으로 돌려보낸다. 중단과 이관 뒤에도 같은 작업을 다시 식별할 수 있게 기록을 연결한다. 이 책은 이러한 역할을 팩토리의 필수 운영 기반으로 다룬다.

Anthropic은 2025년 장기 실행 실험에서 초기 환경 준비와 이후 세션의 점진적 작업, 다음 수행을 위한 기록을 결합했다.[S08] 2026년의 별도 설계 글은 세션 기록·모델 호출 루프·실행 환경을 분리하는 구조를 설명한다.[S20] 두 자료는 업체가 설명한 설계이며 모든 업무에서의 운영 효과를 입증한 것은 아니다. 하네스의 기능이 하나의 프로그램에 모두 들어 있어야 한다는 뜻으로도 읽지 않는다.

리더는 하네스가 직접 제공할 기능과 외부 기반에 맡길 기능을 구분하되, 그 사이의 책임이 끊기지 않도록 정한다. 다음 표는 이 책이 제안하는 확인 항목이다.

연결할 기능	실행에서 갖출 조건	리더가 확인할 질문
맥락 공급	현재 목적·계약·자료와 접근 범위를 전달한다.	어떤 기준과 자료를 읽었는지 다시 확인할 수 있는가?
도구 실행	허용된 호출을 실행하고 성공·오류·결과 미확인을 구분한다.	실패 표시와 실제 외부 상태가 다를 때 어디로 돌아가는가?
상태와 인계	작업 식별자·진행 상태·완료 증거·남은 판단을 보존한다.	중단 뒤 새 수행자가 이미 한 행동을 반복하지 않고 이어갈 수 있는가?
권한과 자원	허용 행동·비용 상한·정지 조건을 실제 실행에 연결한다.	모델이 계속하자고 해도 경계를 넘는 행동을 막을 수 있는가?
검증 연결	결과의 버전에 맞는 검사와 판정 근거를 수집한다.	검사가 실행되지 않은 상태와 통과를 구분하는가?
관찰과 이관	다음 판단의 책임자에게 상태·증거·선택지를 전달한다.	알림이 도착한 뒤 누가 결정하고 실행이 어떻게 재개되는가?

예를 들어 고객 정보 조회 변경을 맡긴 에이전트의 세션이 끝났다면, 다음 수행은 현재 변경·사용한 기준·검증 결과·미확인 소비자 조건을 찾아야 한다. 하네스는 이 정보를 연결하고 실제 상태를 다시 확인할 경로를 제공한다. 기록이 있다는 사실만으로 외부 행동의 중복이 방지되거나 결과의 수용까지 끝나는 것은 아니다. 재시도와 복구의 조건은 8장, 현재 자료의 갱신 책임은 10장과 연결한다.

하네스에도 운영 책임과 변경 기준을 둔다

하네스 운영자는 실행 기록과 상태 복구, 도구 연결과 장애 대응을 유지한다. 제품 책임자는 필요한 결과와 수용 기준을 제공하고, 정책 책임자는 허용 행동과 예외를 정한다. 하네스가 그 결정을 집행할 수 있게 연결하는 일과 사업적 약속을 결정하는 일을 구분한다. 작은 팀에서는 같은 사람이 맡을 수 있어도 변경 대상과 판단 근거는 나누어 남긴다.

OpenAI의 2026년 공개 사례는 에이전트가 일할 환경과 도구, 확인 가능한 피드백을 설계하는 엔지니어링을 설명한다.[S09] 이 책에서 얻는 해석은 하네스 운영을 최초 설치로 끝내지 말아야 한다는 것이다. 도구나 자료의 경로가 바뀌면 실행과 증거의 연결도 다시 확인해야 한다. 실패가 생겼을 때 모델·하네스·도구·환경 중 어디를 조사할지 알 수 있는 기록이 필요하다.

하네스를 직접 만들지, 기존 실행 도구를 확장할지, 외부 서비스를 이용할지는 같은 기준으로 판단한다. 필요한 권한을 집행할 수 있는지, 기록을 꺼내 재검토할 수 있는지, 중단된 작업을 복구할 수 있는지, 변경을 평가하고 되돌릴 경로가 있는지 살핀다. 도입 비용에 검증·갱신·지원·전환 비용을 더해 비교한다. 핵심 상태를 찾거나 옮길 수 없다면 교체 비용도 커질 수 있다.

모델의 변화로 불필요해진 보완 장치도 생길 수 있다. 4장에서 다룬 가정의 재검토를 하네스 변경에도 적용한다. 장치를 더한 양보다 결과의 수용·예외·복구·전체 비용이 어떻게 달라졌는지 확인하고, 변경된 조합은 11장의 기준으로 다시 평가한다.

계약으로 작업을 받는다

P03은 입력·출력·권한·완료 증거·실패 처리를 실행 계약에 명시하도록 제안한다. 제품 팀과 공유 기반 사이에서도 같은 원리를 적용한다. 계약은 결과를 제출할 형식에 더해, 기반이 맡을 수 있는 범위와 제품 팀이 계속 판단해야 하는 조건을 연결한다. 자세한 구현 방법을 전부 고정하는 문서일 필요는 없다.

예를 들어 여러 제품이 함께 쓰는 고객 정보 조회 기능을 변경한다고 하자. 이는 설명을 위한 가상 상황이다. 제품 팀은 필요한 결과와 사용 조건, 영향을 받는 소비자를 제공한다. 기반은 허용된 환경에서 수행할 수 있는지, 어떤 검증이 가능하며 무엇은 별도 확인이 필요한지 알려준다. 소비자 조건을 제공받지 못했다면 기반이 그 조건까지 확인했다고 보고해서는 안 된다.

입력이 부족한 작업을 일단 접수한 뒤 매 단계마다 질문하면 실행 대기가 늘어날 수 있다. 이 책은 접수 전에 기준의 누락과 정책 충돌, 지원하지 않는 환경을 확인하도록 권한다. 부족한 조건은 제품 팀이나 정책 책임자에게 돌려보내고, 진행할 수 있는 부분과 보류할 부분을 구분한다. 탐색이 필요한 작업은 확인할 가설과 다음 결정을 산출물로 정할 수 있다. 불확실한 작업을 준비된 제품 변경과 같은 계약으로 다루지 않는다.

접수 권한과 우선순위 결정도 구분한다. 기반 운영자는 환경과 용량의 이유로 작업을 보류할 수 있지만, 어느 고객의 요구가 더 중요한지는 별도의 사업 판단일 수 있다. 공유 기반의 대기열에서 우선순위를 바꿀 권한과 그 영향의 책임을 정한다. 긴급 작업이 일반 작업을 계속 밀어내면 실행 능력을 늘리기 전에 우선순위와 예외의 원인을 살펴야 한다.

이름표와 실제 권한을 구분한다

Backstage의 공식 시스템 모델은 소프트웨어 구성요소와 API, 운영 자원을 구분하고 시스템이 외부 소비자에 내부 구현을 감추는 구조를 설명한다.[S21] API는 여기서 소프트웨어 구성요소 사이의 호출·데이터 교환 경계다. 확인한 것은 OSS 프로젝트가 제시하는 모델이며 특정 조직의 운영 결과는 아니다.

별도 형식 문서는 구성요소의 책임자를 표시하는 소유자 정보를 설명하면서, 그 정보를 실행 시스템의 권한 부여에 사용해서는 안 된다고 명시한다.[S22] 이는 해당 필드의 문서상 의미다. 책임자가 기록되었다고 실제 접근 권한이나 승인 경로가 자동으로 설정된다는 뜻은 아니다.

이 문서에서 이 책이 얻는 해석은 세 가지 관계를 따로 확인해야 한다는 것이다. 어떤 결과와 기반이 연결되는가, 누가 그 대상을 유지하는가, 누가 실제로 무엇을 실행하거나 바꿀 수 있는가이다. 책임자를 찾을 수 있는 정보는 문제를 전달하는 데 필요하지만, 그 사람이 해결에 필요한 권한과 자료를 갖추었는지는 별도로 확인해야 한다.

팩토리의 경계를 정할 때에는 공통 기능과 제품 기능의 관계를 드러내되, 관계의 표시를 권한 집행으로 오해하지 않는다. 책임을 맡긴 주체가 어떤 변경을 할 수 있고 어떤 변경을 다른 책임자에게 넘겨야 하는지 정한다. 담당자가 바뀌거나 공통 기반이 교체되어도 이 관계를 다시 찾을 수 있어야 한다. 도구가 보여주는 소유자 이름만으로 책임 설계가 끝났다고 판단할 수는 없다.

저자의 「누가 병합하는가」는 변경을 반영한 주체와 그 변경을 실제로 검토한 증거를 구분해서 살핀다.[S44] 이 책은 같은 관점을 결과 수용 기록에도 적용한다. 반영 권한을 행사한 계정만으로 검토의 범위나 판단의 질을 확정하지 않는다. 누가 어떤 기준을 적용했고 어떤 예외를 허용했는지 확인할 기록이 필요하다. 공개 저장소의 승인·병합 비율은 별도 원천 대조 전에는 이 책의 성과 근거로 가져오지 않는다.

결과를 만드는 단계와 게시하는 단계를 나눈다

데모의 구현 워크플로는 준비·에이전트 수행·게시를 별도 실행 환경으로 나눈다. 수행 환경은 변경을 만들고, 게시 환경은 준비 단계가 남긴 계획과 전달받은 결과를 처리한다. 게시 단계는 게시 권한에 쓰는 자격 증명을 자체 발급받으며 에이전트 작업 트리의 코드를 실행하지 않도록 구성되어 있다.[S64]

결과를 만드는 능력과 공유 영역에 반영할 권한을 같은 주체에 모두 줄 필요는 없다. 다만 실행 환경을 나눈 사실이 사업적 수용 판단이나 완전한 보안 격리를 대신하지 않는다. 데모가 공개한 실행 환경·캐시 등의 제한도 함께 읽어야 한다.[S59] 리더는 단계 사이에서 무엇을 신뢰하고 무엇을 재확인하며 누가 예외를 결정하는지 정한다.

실행 완료와 결과 수용을 연결한다

공유 기반은 실행이 끝났는지와 정해진 검증이 어떤 결과를 냈는지 보고할 수 있다. 제품 결과를 수용할 주체는 그 증거가 업무의 약속을 충분히 확인하는지 판단한다. P06을 적용할 때에는 자동으로 수용할 조건, 사람의 해석이 필요한 조건과 운영 관찰이 남은 조건을 나눈다. 7장에서 정한 판정 경로를 공유 기반과 제품 팀의 책임에 연결한다.

제품 팀이 모든 결과를 처음부터 다시 검증한다면 기반의 증거가 필요한 판단에 연결되지 않았을 수 있다. 반대로 공통 검사 통과만으로 제품 결과를 수용하면 제품 특유의 조건을 놓칠 수 있다. 이 책은 공유 검증의 범위와 제품별 판정의 범위를 계약에 연결하도록 제안한다. 검증 기준을 제공할 책임과 그 기준을 실행할 책임을 구분하되 결과에서 다시 연결한다.

가상 고객 정보 조회 기능에서도 기반은 허용된 접근과 계약에 포함된 결과를 확인할 수 있다. 소비자 시스템의 동작이나 사용자의 실제 경험이 검증 범위 밖이라면 그 확인을 맡을 책임자를 정한다. 중간 결과가 준비되었다는 이유로 전체 변경이 완료되었다고 선언하지 않는다. 기반의 작업 완료와 제품의 결과 수용이 다른 시점에 가능하다면 다음 판단의 책임과 기한을 남긴다.

예외와 복구에도 책임의 경계가 필요하다

GitHub의 배포 환경 문서는 보호 조건을 충족해야 작업이 진행되며, 승인 조건이 있으면 승인 전에는 해당 환경의 비밀 정보에 접근할 수 없다고 설명한다.[S23] 여기서 비밀 정보는 인증에 쓰는 자격 증명 등이다. 확인한 것은 제품의 문서상 구조이며 실제 저장소 설정이나 실행은 시험하지 않았다.

이 구조에서 이 책이 얻는 해석은 실행을 막는 조건과 그 조건을 해제할 권한을 따로 정할 수 있다는 것이다. 다만 승인할 사람이 있다는 사실만으로 그 사람이 적절한 기준과 증거를 갖고 판단한다는 점까지 보장되지는 않는다. 이 책은 예외를 요청할 때 충돌한 조건, 확인한 증거, 허용할 범위와 남은 위험을 연결하도록 권한다. 구체적인 권한 설계와 배포 검증은 12장에서 다룬다.

공유 기반의 장애와 제품 변경의 결함도 대응 책임이 다를 수 있다. 실행 환경이 멈췄다면 기반 운영자가 환경과 기록의 상태를 확인할 수 있어야 한다. 사용자의 결과가 잘못되었다면 제품 팀이 영향과 약속을 판단해야 한다. 여러 제품에 동시에 영향이 생겼다면 누가 공통 중단을 결정하고 누가 각 제품의 복구 순서를 정할지 필요하다. 복구 중에도 피해를 줄이는 권한과 사업적 약속을 바꾸는 권한을 구분한다.

문제가 생긴 뒤 서로의 책임으로 돌려보내는 일을 줄이려면 최초 대응을 맡을 주체와 이관 조건을 정한다. 최초 대응자는 모든 원인을 해결할 필요는 없지만 현재 영향과 부족한 정보, 다음 판단의 담당자를 연결할 책임을 맡는다. 원인이 아직 불분명한 경우에도 대응이 멈추지 않도록 한다. 8장은 중단·재시도·복구의 선택을, 이 장은 그 선택을 판단할 주체를 다룬다.

앞의 가상 조회 기능에서 제품 팀은 출시를 원하지만 기반 운영자는 소비자 검증이 부족하다고 판단하고, 정책 책임자는 정보 접근 범위를 문제 삼을 수 있다. 이때 접수 계약에는 조정 중 허용할 행동부터 정한다. 기반 운영자는 위임받은 중단 권한으로 새 배포를 보류하고, 이미 실행 중인 작업은 정해 둔 영향·복구 기준에 따라 처리한다. 격리된 환경의 추가 검증처럼 기존 권한 안에서 가능한 작업은 계속할 수 있다. 출시 일정이 급하다는 이유만으로 접근 경계나 수용 기준을 해제하지 않는다.

사업 우선순위는 제품의 책임자가, 공통 기반의 실행 가능성은 기반 운영자가, 정책 예외는 해당 정책의 변경 권한자가 판단한다. 이 판단들이 충돌할 때 선택지를 모을 조정 책임자도 계약에 지정한다. 조정 책임자는 출시 범위 축소·추가 확인·일정 변경을 관계자에게 제시하며 자신의 권한 밖의 정책을 대신 승인하지 않는다. 합의하지 못하면 조직에서 지정한 상위 판단 경로로 넘기고, 변경 권한자가 새 범위를 정한 뒤 그 범위에 맞는 증거를 확인한다.

응답 기한과 대체 판단자, 그동안 유지할 제한 상태도 실행 전에 정한다. 기한 안에 답이 없으면 승인으로 간주하지 않고 대체 판단자에게 이관한다. 대체 경로도 작동하지 않으면 최초 대응자가 보류 상태와 남은 위험을 보고하고 새 실행을 시작하지 않는다. 리더는 이관이 반복되는 시간과 보류 중의 사용자 영향을 함께 살펴 조정 경로를 고친다. 이는 책임 충돌을 다루기 위한 이 책의 운영 제안이며 모든 판단을 한 사람에게 모으자는 뜻은 아니다.

책임을 배치한 뒤에는 그 사람이 결과를 거부하거나 중단을 요청하고 수정 판단에 필요한 정보를 얻을 수 있는지 확인한다. 필요한 판단 시간과 지원이 부족하면 책임자라는 표시만으로 실제 대응을 기대하기 어렵다. 16장은 이 구조를 사람이 책임을 행사할 업무와 피드백·학습 조건으로 연결한다.

기록은 다음 판단까지 이어져야 한다

P13은 의도·정책·계획·실행·검증·배포 기록을 식별자로 연결하도록 제안한다. 공유 기반에서도 결과 한 건이 어떤 기준과 환경 아래에서 만들어졌는지 다시 확인할 수 있어야 한다. 제품 팀은 결과의 목적과 수용 조건을, 기반은 실행과 판정 기록을 제공한다. 정책 책임자는 적용한 기준과 예외의 이력을 유지한다.

이 연결을 만들면 특정 실행 주체가 바뀐 뒤에도 과거 결과를 재검토할 근거를 유지할 수 있다. 그러나 기록의 존재가 같은 실행을 완전히 재현한다는 보장은 아니다. 외부 시스템과 자료가 바뀌거나 접근할 수 없는 조건이 있을 수 있다. 재검토 가능한 범위와 다시 실행할 수 없는 부분을 구분한다. 기록에 민감한 정보가 들어간다면 필요한 증거와 보관 범위를 함께 판단해야 한다.

기록을 읽을 책임도 정해야 한다. 사용자 문제가 반복되어도 제품 팀이 증거를 찾을 수 없거나 기반 운영자가 업무의 기준을 확인할 수 없다면 저장된 자료가 많아도 루프는 이어지지 않는다. 실행 한 건을 골라 목적에서 결과와 판정, 배포와 후속 관찰까지 따라가 본다. 그 과정에서 끊긴 연결과 불필요한 정보 요구를 찾아 개선한다. 10장은 이 자료의 출처·갱신·공급 책임을 더 다룬다.

판단할 정보를 보고한다

저자의 「바이브 코딩을 넘어서 소프트웨어 팩토리로」는 변경 목적·검증·남은 위험과 사람이 내릴 결정을 연결한 보고를 제안한다.[S01] 이 책의 P12 ‘결정에 필요한 보고’도 같은 문제에 답한다. 결과 책임자는 모든 실행 로그를 읽는 대신 지금 판단할 대상과 확인한 근거에 접근할 수 있어야 한다. 짧은 보고에서 상세 기록으로 내려갈 경로를 두고, 판단이 필요 없는 상태 알림이 중요한 예외를 밀어내지 않는지 확인한다.

공유 범위를 작게 시작하고 비용을 확인한다

공통 기반은 여러 팀의 반복 부담을 줄일 수 있지만 표준 형식을 유지하고 예외를 처리하는 비용을 만든다. 제품마다 다른 조건을 공통 형식에 억지로 맞추면 중요한 차이가 사라질 수 있다. 변경 하나가 여러 팀의 계약과 검증을 깨뜨리는 위험도 생긴다. 리더는 이용하는 팀의 수보다 공유했을 때 줄어드는 운영 부담과 증가하는 조정 비용을 본다.

처음에는 반복할 이유가 있고 수용 조건을 설명할 수 있는 업무를 선택할 수 있다. 실행 환경이나 기록 형식처럼 함께 유지할 부분부터 공유하고, 제품별 기준과 사업 판단은 해당 지식을 가진 주체에 남긴다. 새로운 제품을 접수할 때 지원 범위를 넓히는 비용과 기존 제품에 미치는 영향을 확인한다. 공통 기반의 변경에도 소비자 조건과 되돌릴 경로가 필요하다.

한 팀 안에서 충분히 운영할 수 있다면 별도의 중앙 조직을 만들 필요는 없을 수 있다. 반대로 여러 팀이 공통 기능을 제각각 유지하고 같은 실패를 반복한다면 공유 책임을 정할 근거가 생긴다. 조직도 변경의 필요성은 실제 대기·중복 유지·책임 공백을 확인한 뒤 판단한다. 15장은 업무 흐름에 맞춰 권한과 팀 경계를 바꾸는 조건을 다룬다.

리더는 경계를 넘는 작업 하나를 확인한다

이 책은 요청부터 운영 관찰까지 이어지는 작업 한 건을 기준으로 책임 구조를 시험하도록 제안한다. 접수 시 기준을 누가 제공했는지, 수행 중 부족한 정보가 어디로 돌아갔는지, 결과를 누가 어떤 증거로 수용했는지 확인한다. 예외와 복구가 있었다면 다음 판단의 담당자와 권한을 찾을 수 있는지 본다. 활동량만으로 팩토리의 효과를 판단하지 않는다.

P03은 같은 기준의 작업을 다른 실행 주체에게 맡길 수 있는지 검토한다. P06은 수용 뒤 운영 결함과 판정 번복을 관찰한다. P13은 실행 한 건을 같은 자료로 재검토할 수 있는지 확인한다. 접수와 판정의 대기, 반복 질문, 계약 유지와 기록 관리의 비용도 함께 살핀다. 이 확인 항목은 효과를 평가하기 위한 제안이며 공개 문서가 그 효과를 입증한 것은 아니다.

『More Effective Agile』의 팀 구성·역할, 대규모 협업과 반복 전달이라는 주제에 대한 이 책의 재고찰 질문은 공유 생산 기반과 제품 팀 사이에서 결과 책임과 판단 권한을 어떻게 연결할 것인가이다. 연결 범위는 원서 주제 연결의 범위의 공개 목차다. 원서 본문을 대조해 세부 주장에 동의하거나 반박한 결과는 아니다.

팩토리의 경계는 어떤 도구를 한곳에 모았는지보다 어떤 판단을 맡기고 어떤 증거를 돌려받는지에서 드러난다. 리더는 제품의 목적과 수용 책임을 유지하면서 반복해서 제공할 수 있는 실행 기반을 정한다. 다음 장은 이 기반과 실행 주체가 필요한 지식을 얻고 그 지식의 유효성을 유지할 책임을 다룬다.

출처와 검토

[S01], [S08], [S09], [S20], [S21], [S22], [S23], [S39], [S44], [S59], [S64]. 확인 범위와 한계는 출처 대장, 주요 주장의 성격은 자료 확인 범위에 기록한다. 공개 문서의 구조를 확인했으며 제품 설치·실행·조직 성과·패턴 효과·원서 본문 대조는 수행하지 않았다.