6장 작업을 검증 가능한 단위로 나눈다

나눈 작업이 다시 만나는 곳을 본다

큰 작업을 여러 실행 주체에게 나누면 각각의 수행은 빨라질 수 있다. 그러나 각 결과를 합쳤을 때 목적에 맞게 작동하는지는 별도의 문제다. 입력과 결과에 대한 가정이 다르거나 같은 자원을 동시에 바꾸면, 작은 작업의 완료가 전체 결과의 완료로 이어지지 않을 수 있다. 리더는 얼마나 많이 나눌지에 더해 어디에서 다시 연결하고 누가 그 연결을 판단할지 정해야 한다.

5장은 개별 작업의 입력·출력·권한·완료 증거·실패 처리를 계약에 연결했다. 이 장은 그 계약을 검증 가능한 결과 단위로 나누는 문제를 다룬다. P04 ‘검증 가능한 작업 단위’는 의존성과 통합 조건을 가진 작은 결과 단위에 검증을 부여하도록 제안한다. 분해의 목표는 실행 주체의 수를 늘리는 데 있지 않다. 실패의 위치와 다음 판단을 구분할 수 있도록 결과를 나누는 데 있다.

P09 ‘실행 주체의 교체’는 계약과 산출물 형식, 기록의 인터페이스를 유지하면서 수행자를 바꾸는 패턴이다. 작은 작업의 기준과 기록이 유지되면 다른 사람이거나 다른 에이전트가 이어받을 조건을 확인하기 쉬워질 수 있다. 그러나 분해만으로 모든 수행자가 같은 능력을 갖게 되지는 않는다. 필요한 맥락과 실행 환경, 최소 수행 능력을 함께 확인해야 한다.

파일보다 확인할 결과를 단위로 삼는다

작업을 파일이나 기술 역할별로 나누는 것이 편할 때가 있다. 하지만 파일 하나를 수정했다는 사실은 사용자가 필요한 결과를 얻었다는 판단과 다를 수 있다. 여러 파일을 바꿔야 하나의 동작을 확인할 수도 있고, 한 파일 안에 서로 다른 위험과 검증 조건이 들어 있을 수도 있다. 이 책은 분해의 기준을 완료를 판단할 수 있는 결과에 먼저 두도록 권한다.

예를 들어 5장의 가상 사내 문의 업무를 확장한다고 하자. 승인된 참고 자료에서 근거를 찾아 답변 초안을 만들고, 근거가 부족하면 보류하며, 허용된 경우에만 최종 답변을 발송하는 흐름이다. 이는 실제 고객 사례가 아니다. 자료를 찾는 부분과 초안을 만드는 부분, 발송하는 부분으로 나눌 수 있지만 각 부분의 완료 조건과 연결 조건이 있어야 한다.

결과 단위의 예	확인할 결과	다음 단위와 연결할 조건
승인된 자료에서 근거를 찾는다	문의에 관련된 근거와 출처를 제시하거나 근거 부족을 표시한다.	사용할 자료의 범위·버전과 근거 부족 상태의 의미
근거에 따른 초안을 만든다	초안과 근거를 연결하고 충돌·미검증 항목을 남긴다.	수용할 초안과 추가 판단이 필요한 상태의 구분
허용된 답변을 발송한다	허용된 대상에 결과를 전달하고 상태를 기록한다.	발송 권한·중복 처리·실패 뒤 다음 행동
전체 문의 흐름을 확인한다	근거 부족과 권한 충돌까지 포함해 전체 결과를 판정한다.	부분 결과의 버전·실제 연계·최종 수용 책임

이 표는 분해의 설명 예시다. 모든 업무를 이 네 단위로 나누라는 제안은 아니다. 작은 흐름 하나를 먼저 끝까지 연결해 보고 확장할 수도 있다. 부분 검증을 위해 대체 자료나 모의 환경을 썼다면 실제 연계에서 무엇이 달라지는지 남긴다. 부분의 확인 범위가 전체의 확인 범위인 것처럼 보고해서는 안 된다.

단위가 작아도 다음 수행에 필요한 결과를 만들지 못하면 인수인계가 늘어날 수 있다. 반대로 너무 큰 단위는 실패 원인과 완료 여부를 판단하기 어렵다. 리더는 부분 결과가 실제로 다음 작업의 입력과 수용 판단에 쓰이는지 확인해야 한다. 작업 개수나 코드 줄 수만으로 적절한 크기를 정하지 않는다.

의존성과 병렬 실행의 조건을 드러낸다

어떤 작업을 함께 수행할지는 먼저 의존 관계를 확인한 뒤 판단한다. 앞선 결과가 확정되어야 시작할 수 있는 작업과 공통 기준 아래 독립적으로 진행할 수 있는 작업을 구분한다. 같은 자료를 읽는다는 사실과 같은 상태를 변경한다는 사실도 다르다. 계약을 읽는 작업은 병렬로 진행할 수 있어도 동일한 결과나 운영 자원을 바꾸는 작업은 충돌할 수 있다.

GitHub의 작업 흐름 문서는 특정 작업이 선행 작업의 성공을 기다리도록 관계를 정의할 수 있으며, 선행 실패나 생략이 후속 실행에 영향을 준다고 설명한다.[S48] 조건에 따른 예외도 문서에 있다. 확인한 것은 제품의 문서상 실행 관계이며 실제 워크플로를 시험한 결과는 아니다.

이 구조에서 이 책이 얻는 해석은 작업의 순서와 실패의 전파를 함께 명시해야 한다는 것이다. 수행 목록만 나열하면 앞선 결과가 없을 때 무엇을 할지 알기 어렵다. 후속 작업을 보류할지, 확인 가능한 부분만 진행할지, 별도 조사로 바꿀지 정한다. 앞선 작업이 끝났다는 표시보다 필요한 결과와 증거가 실제로 준비되었는지 확인해야 한다.

병렬 실행을 허용하려면 결과를 다시 합칠 기준도 필요하다. 같은 대상의 서로 다른 버전을 수정한 결과를 어떤 순서로 적용할지, 한 작업이 공통 계약을 바꾸면 다른 작업을 언제 다시 검증할지 정한다. 파일이 달라도 공유 데이터나 호출 조건을 바꾸면 서로 영향을 줄 수 있다. 반대로 영향이 분리되어 있고 통합 조건을 유지할 수 있다면 동시 실행의 범위를 넓힐 수 있다.

불확실한 설계를 동시에 탐색할 수도 있다. 이때 결과는 함께 배포할 구현이 아니라 비교할 대안일 수 있다. 대안 탐색과 공동 구현을 같은 병렬화로 취급하지 않는다. 리더는 무엇을 비교하고 무엇을 합칠지 먼저 정해 불필요한 중복 구현과 통합을 줄일 수 있는지 평가한다.

진행 중인 작업에는 판정 대기도 포함한다

착수한 작업이 늘면 검증과 통합, 수용의 부담도 늘 수 있다. 이 책은 현재 단계에서 착수했지만 아직 수용하지 않은 작업을 진행 중 작업으로 관리하도록 제안한다. 구현이 끝나 판정을 기다리는 결과와 장애 때문에 멈춘 작업도 포함한다. 구현 수용 뒤의 장기 사용자 관찰은 별도 책임으로 기록해 현재 작업의 대기와 구분할 수 있다.

진행 중 작업량을 제한할 때에는 실행 용량만 보지 않는다. 결과를 검증하고 합치고 판단할 용량을 함께 본다. 결과가 판정 대기열에 쌓이는데 수행자를 더 늘리면 대기와 재작업이 늘어날 수 있다. 반대로 검증 자원이 비어 있고 독립적인 작업이 있다면 실행을 늘려볼 이유가 생긴다. 이 관계는 실제 흐름을 관찰해 조정할 제안이다.

GitHub의 동시 실행 문서는 같은 그룹의 실행을 제한하고 대기·취소의 동작을 설정하는 구조를 설명한다.[S49] 기본 설정에서는 새 대기 작업이 기존 대기 작업을 대체할 수 있다. 따라서 실행을 제한했다는 사실만으로 모든 요청이 보존되고 순서대로 처리된다고 가정해서는 안 된다. 실제 설정과 동작은 별도 확인해야 한다.

이 구조에서 이 책이 얻는 해석은 동시 실행 제한과 업무 접수의 보존 정책을 나누어야 한다는 것이다. 오래된 결과의 재검사를 새 요청으로 대체해도 되는 업무가 있고, 모든 요청을 처리해야 하는 업무도 있다. 제한 때문에 어떤 작업이 기다리고 어떤 작업이 취소되는지, 취소 뒤 누가 다음 판단을 하는지 정한다. 기술적 실행 제한을 업무의 우선순위 정책으로 자동 간주하지 않는다.

적절한 작업량에 보편적인 숫자를 붙이지 않는다. 독립성·검증 부담·변경 영향·복구 비용에 따라 허용 범위를 정하고 판정 대기와 운영 결함을 함께 관찰한다. 일률적인 동시 실행 수가 조직의 처리량을 보장하는 것은 아니다. 17장은 이 효과를 전체 비용과 결과로 측정한다.

통합에도 결과와 책임을 부여한다

5장에서 소개한 Vibe Up의 자원 상한은 동시 작업을 선택할 때도 쓸 수 있다. 검증 대기가 늘어 한도에 닿으면 새 착수를 보류하고, 이미 시작한 결과의 판정·통합을 먼저 처리할지 확인한다. 우선순위를 바꿀 권한자가 중요한 새 요청을 넣기로 했다면 어떤 기존 작업을 보류할지와 그 작업의 결과·미검증 상태를 누가 보존할지 함께 정한다. 사람의 비교·판정 여력이 병렬 후보 수의 제약이라는 제안도 같은 맥락이다.[S72]

이 책은 실행 수의 상한을 검증 능력과 사용자 약속에 맞춰 조정하도록 권한다. 같은 날 착수한 작업 수가 줄어도 수용된 전체 결과가 늘거나 재작업이 줄 수 있다. 반대로 검증 여력이 남는데 지나치게 낮은 상한을 유지하면 전달이 늦어질 수 있다. 상한을 지킨 사실보다 대기·결함·취소 뒤의 인계가 어떻게 달라졌는지 평가한다.

부분 작업이 모두 완료되었어도 통합을 맡길 결과와 책임이 없으면 전체 목적은 남는다. 이 책은 통합 자체를 검증할 결과로 정의하도록 제안한다. 각 결과가 계약의 같은 버전을 사용하는지, 연결된 상태와 권한이 맞는지, 전체 흐름이 실패를 처리할 수 있는지 확인한다. 부분의 완료 선언을 모으는 것만으로 통합을 대신하지 않는다.

가상 문의 업무에서도 검색과 초안 생성이 각각 검사에 통과할 수 있다. 그러나 근거 부족 상태를 초안 생성이 정상 근거로 받아들이면 잘못된 답변이 만들어질 수 있다. 발송 단계가 다른 초안의 수용 기록을 사용하면 권한의 연결도 어긋난다. 통합 검증은 이런 경계에서의 조건을 확인해야 한다. 각 단계가 검사한 가정과 검사하지 않은 조건을 함께 넘기는 이유다.

통합 판단의 책임자는 필요한 자료와 권한을 가져야 한다. 책임만 정하고 각 실행의 증거나 적용 버전을 찾을 수 없다면 재검토가 어렵다. 제품 팀과 공유 기반이 나누어 수행했다면 무엇을 제공하고 누가 최종 결과를 수용할지 9장의 책임 구조와 연결한다. 통합을 전담하는 별도 조직이 항상 필요하다는 뜻은 아니다. 누가 어떤 조건으로 통합을 판단하는지가 필요하다.

통합은 마지막에 한 번만 할 작업이 아닐 수 있다. 계약을 바꾸거나 공유 상태를 수정했을 때 영향을 받는 결과를 다시 연결해 확인할 수 있어야 한다. 작은 결과를 일찍 합쳐 가정의 충돌을 드러내는 방법과, 기준이 안정될 때까지 통합 범위를 제한하는 방법을 비교한다. 적절한 시점은 변경의 비용과 남은 불확실성에 따라 정한다.

실행 주체를 바꿔도 기준과 기록을 이어간다

P09는 같은 계약과 산출물 형식, 기록의 인터페이스를 유지하며 수행자를 교체하도록 제안한다. 분해한 작업에 이 구조가 있으면 중단된 작업을 다른 주체에게 넘길 때 무엇이 완료되었고 무엇이 남았는지 확인할 수 있다. 한 수행자가 가지고 있던 대화의 맥락을 모두 복구해야만 이어갈 수 있는 구조는 교체 비용을 높일 수 있다.

인계에는 현재 결과, 확인한 증거, 적용 기준과 환경, 미검증 항목과 다음 판단을 남긴다. 다음 수행자는 기록과 실제 상태가 맞는지 확인한다. 이미 한 행동을 모르고 다시 수행하면 중복 변경이나 외부 부작용이 생길 수 있다. 필요한 상태를 확인하지 못하면 재시도 전에 해당 책임자의 판단을 받아야 한다. 8장은 이런 중단과 복구를 더 다룬다.

실행 주체가 바뀌면 필요한 정보의 형태와 도구가 달라질 수 있다. 같은 결과 기준을 유지하되 전달 방법을 조정할 수 있어야 한다. 모든 도구를 동일한 기능으로 제한하면 고유한 능력을 활용하지 못할 수 있다. 공통 기준과 활용할 기능의 범위를 구분하고 전환 작업량과 회귀 결함을 함께 평가한다. 작은 단위는 교체의 조건을 드러내는 데 도움이 될 수 있지만 교체가 항상 저렴하다는 증거는 아니다.

분해와 조정의 비용도 평가한다

분해하면 계약과 검증, 인수인계 기록을 여러 곳에 유지하는 비용이 생긴다. 너무 잘게 나누면 각 단위보다 설명과 통합에 더 많은 노력이 들 수 있다. 한 가지 판단을 해야 할 작업을 여러 승인으로 쪼개면 결정 대기가 늘어날 수도 있다. 리더는 작은 작업을 많이 만드는 것보다 실패와 판단의 위치를 명확하게 만드는 데 집중한다.

결과를 나누기 어려운 탐색이나 공유 상태의 변경에는 순차 실행 또는 하나의 단위가 더 적절할 수 있다. 단위를 크게 유지할 때에도 중간에 무엇을 확인하고 어떤 조건에서 멈출지 정할 수 있다. 병렬화하지 않는 결정과 검증을 생략하는 결정을 같은 것으로 취급하지 않는다.

사람과 에이전트 사이의 협의도 모두 없앨 대상은 아니다. 새로운 가정을 발견하고 공통 계약을 정할 때에는 대화가 필요하다. 이미 결정한 내용을 찾지 못해서 반복하는 설명과 새로운 판단을 위한 협의를 구분한다. 14장은 이 비용을, 15장은 실제 의존 관계에 맞춰 권한과 팀 경계를 바꿀 조건을 다룬다.

리더는 분해 전후의 흐름을 비교한다

P04를 평가할 때에는 분해 전후 대기 시간과 통합 실패, 재작업을 비교한다. 결과의 크기와 난도, 검증 범위가 달라졌다면 그 차이를 함께 기록한다. 빠르게 완료한 작은 작업의 수만으로 생산성이 올랐다고 판단하지 않는다. 전체 결과의 수용과 운영 품질을 확인해야 한다.

P09는 전환에 필요한 작업량과 회귀 결함을 관찰한다. 필요한 정보를 다른 실행 주체가 찾을 수 있었는지, 같은 기준으로 수행했는지, 이미 끝난 행동을 다시 했는지 살핀다. 진행 중 작업과 판정 대기가 어디에 쌓이는지도 함께 본다. 이런 항목은 패턴을 평가하기 위한 제안이며 제품 문서가 그 효과를 입증한 것은 아니다.

『More Effective Agile』의 작은 프로젝트·흐름과 대규모 협업이라는 주제에 대한 이 책의 재고찰 질문은 실행이 빨라질 때 어떤 결과를 함께 수행하고 어떤 판단과 통합을 기다리게 할 것인가이다. 연결은 원서 주제 연결의 범위의 공개 목차 범위다.

리더는 독립적으로 확인할 결과를 나누고 그 결과가 다시 연결될 조건을 유지한다. 실행 주체의 수보다 검증과 통합을 통과해 수용된 전체 결과가 중요하다. 다음 장은 그 결과를 어떤 증거와 별도의 판정 경로로 받아들일지 설명한다.

출처와 검토

[S48], [S49], [S72]. 확인 범위와 한계는 출처 대장, 주요 주장의 성격은 자료 확인 범위에 기록한다. 문서의 실행 관계와 동시 실행 제한을 확인했으며 실제 제품 설정·에이전트 병렬 실행·조직의 처리량·패턴 효과·원서 본문 대조는 검증하지 않았다.