7장 증거로 완료를 판단한다

완료 보고를 받은 뒤에도 남는 판단

리더가 완료 보고를 받으면 다음 작업을 시작하거나 사용자에게 결과를 약속해야 한다. 이때 보고에 담긴 확신과 조직이 감수할 위험은 같은 것이 아니다. 수행자는 요청한 변경을 만들었다고 생각할 수 있다. 그러나 검사가 중요한 조건을 빠뜨렸거나, 변경을 사용하는 다른 시스템의 사정을 알지 못했다면 수용 판단은 달라져야 한다. 결과를 받아들인다는 것은 수행자의 노력을 인정하는 일에 더해, 그 결과를 다음 업무의 근거로 사용할 책임을 맡는 일이다.

2장은 의도를 지속적인 기준으로 유지하는 문제를 다뤘고, 3장은 방법을 바꿀 권한과 경계를 바꿀 권한을 구분했다. 이 장은 5·6장에서 정한 계약과 결과 단위에 따라 제출한 결과를 무엇으로 수용할지 다룬다. 이 책은 P06 ‘증거 기반 완료’로 결과와 완료 조건을 연결하고, P07 ‘독립된 검증’으로 수행자의 오해를 별도의 판정 경로에서 발견하도록 제안한다. 두 패턴을 적용해도 모든 결함이 사라지는 것은 아니다. 리더의 과제는 수용할 범위, 확인한 조건, 남은 불확실성과 판정 책임을 명시하는 데 있다.

완료 조건마다 증거와 책임을 연결한다

완료 조건은 작업을 맡기기 전에 정하는 것이 원칙이다. 결과를 본 뒤 수행자가 충족하기 쉬운 기준으로 바꾸면 의도와 판정 사이의 연결을 잃을 수 있다. 리더는 어떤 결과가 필요한지 정하고, 그 결과를 확인할 증거와 판정할 주체를 연결한다. 새로운 정보를 발견해 조건을 바꿔야 한다면 변경 이유와 권한을 확인한다. 검사 방법의 개선과 약속한 결과의 축소는 다른 판단이다.

4장에서 소개한 연락처 변경 기능의 완료 조건을 더 살펴보자. 고객이 자신의 연락처를 변경하는 기능을 개선한다고 하자. 이는 설명을 위한 가상 상황이다. 실행자는 화면이 바뀌고 저장 요청이 성공했음을 보여줄 수 있다. 하지만 고객이 다시 접속했을 때 바뀐 정보가 유지되는지, 다른 고객의 정보가 바뀌지 않는지, 변경을 사용하는 후속 업무에 새 정보가 전달되는지도 판단 대상일 수 있다. 이 조건은 업무의 목적과 정책에 따라 정해야 한다. 모든 기능에 같은 검사 목록을 적용하자는 제안은 아니다.

리더가 요구할 것은 검사의 개수보다 각 검사가 어떤 약속을 확인하는지에 대한 연결이다. 확인하기 어려운 조건도 목록에서 지워서는 안 된다. 증거를 아직 얻지 못한 조건은 미검증으로 남기고, 추가 확인을 기다릴지 제한된 범위에서 수용할지 해당 위험의 책임자가 결정한다. 증거 부족과 조건 위반을 구분하면 수행자에게 돌아갈 다음 작업도 분명해진다.

판정할 질문	필요한 증거의 예	리더가 정할 사항
요청한 결과가 존재하는가	결과물과 최종 상태의 확인	수용할 결과의 범위와 기준
정책의 경계를 지켰는가	권한·정보 취급·변경 범위의 확인 기록	해석이 필요한 조건의 책임자
연결된 업무가 계속 작동하는가	관련 소비자와 통합 조건의 확인	검증에 포함할 의존 관계
아직 확인할 수 없는 결과는 무엇인가	미검증 조건과 후속 관찰 계획	수용 제한·관찰 책임·재판정 조건

이 표는 이 책의 판정 설계 제안이다. 증거의 형식과 깊이는 변경의 영향, 복구 가능성, 업무의 반복성에 맞춰 정한다. 작은 변경에도 거대한 검토 문서를 요구하면 기록이 판단을 돕기보다 작업을 지연시킬 수 있다. 짧은 결과 기록으로도 조건과 증거를 다시 확인할 수 있다면 그 범위에서 시작할 수 있다.

수행 기록과 결과 상태를 나누어 본다

Anthropic의 2026년 1월 평가 지침은 수행 기록과 최종 환경 상태를 구분하고 코드·모델·사람의 판정을 조합한다.[S10] 이 자료는 업체의 평가 설계 지침이다. 일반 조직의 생산성 효과를 입증한 연구로 사용하지 않는다.

이 구분에서 이 책이 얻는 해석은 두 종류의 증거가 서로 다른 질문에 답한다는 것이다. 수행 기록은 어떤 행동을 어떤 기준 아래에서 했는지 보여준다. 결과 상태는 그 행동 뒤에 무엇이 실제로 남았는지 보여준다. 허용된 절차를 따랐어도 결과가 없을 수 있고, 결과가 존재해도 금지된 방법을 사용했을 수 있다. 따라서 한쪽의 확인만으로 다른 쪽의 판단을 대신해서는 안 된다.

P06을 적용할 때에는 실행 대상과 증거의 대상을 맞춘다. 이전 버전의 검사 결과를 새 결과의 증거로 사용하거나, 일부 환경에서 얻은 결과를 모든 사용 환경에 적용하면 판정 범위가 실제 확인 범위를 넘어선다. 결과물, 적용한 기준, 확인한 환경과 시점을 함께 남겨야 한다. 실행이 끝난 뒤 결과가 바뀔 수 있는 업무에서는 증거가 유효한 기간도 판단해야 한다.

저자의 「증거로 거르는 팩토리」는 문제의 재현, 수정 전 실패, 실제 동작을 서로 다른 증거로 분류한다.[S42] 이 책은 결함 수정의 완료 조건에도 이 구분을 적용하도록 제안한다. 처음 문제가 존재했는지, 새 검사가 그 문제를 실제로 잡는지, 수정이 사용 환경의 조건을 충족하는지 확인한다. 모든 작업에 같은 세 단계를 요구하는 것은 아니다. 기능 탐색과 기준 변경에는 다른 증거가 필요하며, 확인하지 못한 환경은 판정의 한계로 남긴다.

독립성은 다른 실행자를 배치하는 데서 끝나지 않는다

P07은 수행자의 해석과 다른 경로에서 결과를 확인하도록 제안한다. 독립성은 사람이나 모델의 이름이 다르다는 사실만으로 확보되지 않는다. 수행자와 판정자가 같은 요약만 읽고 같은 예시로 확인한다면, 원래 요구에서 빠진 조건을 함께 놓칠 수 있다. 리더는 판정자가 무엇을 독립적으로 확인할 수 있는지 살펴야 한다.

먼저 기준의 근거를 확인한다. 판정자는 수행자의 완료 보고에 더해 의도 소유자가 정한 요구와 정책에 접근할 수 있어야 한다. 다음으로 검증 자료를 확인한다. 수행자가 선택한 성공 예시 외에 경계 조건과 실패 조건을 검토할 수 있어야 한다. 마지막으로 판정 권한을 확인한다. 결과를 만든 주체가 검사를 고치고 그 변경의 충분성까지 단독으로 수용한다면, 기준을 낮추는 변경을 발견하기 어려울 수 있다. 3장에서 나눈 변경 권한은 이 판정에도 적용된다.

이 구분은 실행자가 검사를 만들면 안 된다는 뜻이 아니다. 실행자가 만든 검사는 빠른 피드백과 결함 발견에 쓸 수 있다. 다만 결과의 영향이 크거나 같은 오해가 반복될 가능성이 높다면, 다른 자료와 관점으로 그 검사가 놓친 조건을 확인할 필요가 있다. 소규모 팀은 모든 변경에 별도 조직을 배치하기 어려울 수 있다. 그 경우에도 중요한 조건에 대한 외부 검토, 별도로 관리하는 확인 자료, 수용 후 표본 점검 중 무엇이 필요한지 결정할 수 있다.

검증 체계 자체도 시험해야 한다. 이 책은 알려진 실패 결과를 판정 경로에 넣어 실제로 거부하는지 확인하도록 제안한다. 정상 결과를 지나치게 거부하는지도 함께 본다. 판정자가 여러 명인데 같은 실패를 놓친다면 숫자를 늘리기 전에 공유한 가정과 자료를 조사한다. P07의 검증 기준은 실패 발견과 오류의 상관관계를 확인하는 것이며, 다른 모델을 추가한 횟수가 아니다.

사람이 판정자로 참여한다는 사실만으로 독립성이 확보되지는 않는다. 이 책은 영향이 큰 결과에서 사람이 AI 제안 전에 주요 실패 조건을 정하고, 제안과 기준이 충돌하는 지점을 확인하도록 제안한다. 추가 검토가 오류 발견에 도움이 되는지와 판단 부담을 함께 평가해야 한다. 사람이 이런 판단을 행사할 권한·능력·동기를 갖도록 하는 업무 설계는 16장에서 다룬다.

공개 변경 기록이 보여주는 검증 범위의 질문

OpenHands의 PR #17660 본문은 일부 기능 변경과 집중 테스트 통과를 보고하면서 배포 패키지의 검증을 주장하지 않는다고 명시한다.[S18] 여기서 읽은 것은 작성자의 보고다. 검사 로그를 대조하거나 제품을 실행한 결과는 아니다.

2026년 10월 6일 병합된 복구 PR #18048은 Enterprise의 대체 경로가 준비되기 전에 기존 VS Code 경로를 제거한 문제를 설명하며, 해당 제거를 되돌린다고 기록한다.[S13] 확인한 것은 공개 설명과 복구의 병합 기록이다. Enterprise 환경의 실제 장애나 피해 규모는 확인하지 않았다.

이 기록에서 이 책이 제기하는 질문은 변경을 수용할 때 검증 범위에 소비자 시스템의 조건이 포함되었는가이다. 일부 검사가 통과했다는 보고가 있어도 그 검사 밖의 사용 경로까지 확인했다는 뜻은 아니다. 다만 이 자료만으로 당시의 모든 승인 과정이나 실패 원인을 재구성할 수는 없다. 이 사례를 AI의 승인 때문에 결함이 생겼다는 증거로 사용하지 않는다. 공개 기록에서 드러난 확인 범위와 소비자 조건 사이의 간격을 검토 대상으로 삼는다.

리더는 변경의 직접 대상 외에 누가 결과를 사용하는지 확인해야 한다. 공유 기반을 바꾸는 작업이라면 그 기반을 사용하는 팀의 수용 조건을 연결한다. 모든 소비자를 매번 전부 시험하기 어렵다면 영향 범위와 대표 조건을 어떻게 골랐는지 남긴다. 검증에서 제외한 사용 조건은 수용 판단의 한계로 표시한다. 9장은 이 조건을 누가 제공하고 유지할지 제품 팀과 팩토리의 책임 구조로 확장한다.

실행 오류와 재현 증거를 구분하는 구현

데모의 수정 증거 판정은 버그로 분류된 팩토리 봇의 변경 제안에 재현 테스트를 요구한다. 수정 전 코드에 새 테스트를 적용해 실제 단언이 실패하고, 수정 후에는 통과해야 한다. 테스트 수집 오류·시간 초과·결과 보고서 누락은 버그 재현 성공으로 인정하지 않는다. 브라우저 전체 동작 검사는 이 판정의 실행 범위 밖이다.[S62]

리더는 검사 통과 여부와 함께 어떤 실패를 증거로 인정했는지 읽을 수 있다. 검사가 시작되지 못한 실패를 재현으로 인정하면 잘못된 수정도 근거를 갖춘 것처럼 보인다. 이 검사의 대상이 아닌 변경은 재현 검사를 하지 않고 통과할 수 있으므로, 통과 표시만으로 모든 결과에 같은 검증이 적용됐다고 해석해서는 안 된다. 원문도 이 장치를 악의적인 코드의 판정 조작까지 막는 보장으로 제시하지 않는다.[S59] 업무에 맞는 검사 범위와 그 밖의 조건을 수용할 책임을 함께 정해야 한다.

구현 수용과 사용자 결과의 확인을 구분한다

결과물의 조건을 충족했다는 판단과 사용자의 문제가 해결되었다는 판단은 다른 시점에 가능할 수 있다. 앞의 가상 상황에서도 연락처가 저장되는지는 구현 단계에서 확인할 수 있지만, 고객이 변경 절차를 이해하고 이후 업무에서 정보를 제대로 사용하는지는 추가 관찰이 필요할 수 있다. 리더는 지금 수용한 약속과 운영에서 확인할 약속을 구분한다.

이 책은 완료라는 한 단어로 그 차이를 숨기지 않도록 권한다. 구현을 수용했다면 확인한 조건을 기록하고, 운영 관찰이 남았다면 담당자와 재검토 시점을 정한다. 관찰에서 기준을 충족하지 못하면 결과 수용을 다시 판단할 경로가 있어야 한다. 후속 관찰을 남기는 것은 모든 결과를 영구적으로 미완료 상태에 두기 위한 장치가 아니다. 현재 판단의 범위와 다음 책임을 구체화하기 위한 장치다.

탐색 작업에서는 처음부터 제품의 성공 조건을 확정하기 어려울 수 있다. 이때 완료 결과는 확인한 가설, 얻은 근거, 남은 불확실성과 다음 결정이 될 수 있다. 기대한 가설이 지지되지 않아도 탐색 계약을 충족할 수 있다. 반대로 학습했다는 선언만 있고 판단을 바꿀 근거가 없다면 탐색 결과의 수용도 어렵다. 검증 가능한 작업 단위를 정하는 6장의 논의는 이러한 결과의 범위를 정하는 데 필요하다.

검증 비용과 판정 오류를 함께 관리한다

검증을 강화하면 확인 자료를 만들고 환경을 유지하며 판정을 기다리는 비용이 생긴다. 독립된 검토를 추가한 뒤 그 대기가 가장 큰 병목이 될 수도 있다. 또한 검사하기 쉬운 항목만 완료 기준에 넣으면 사용자 결과가 빠질 수 있다. 검증의 강도를 높이는 것과 의도에 맞는 판단을 하는 것은 같은 일이 아니다.

리더는 변경의 영향과 불확실성에 따라 판정 경로를 정한다. 반복적이고 되돌리기 쉬운 작업은 정해진 증거로 빠르게 수용할 수 있다. 새로운 사용 조건을 건드리거나 복구가 어려운 변경은 별도 판단이 필요할 수 있다. 같은 경로를 통과한 결과에서도 운영 결함과 판정 번복을 관찰해야 한다. 수용 비율이 높아졌을 때에는 실행이 개선되었는지, 기준이 완화되었는지, 어려운 작업이 평가 대상에서 빠졌는지 구분한다.

필요한 증거를 얻을 수 없는 결과는 성공으로 계산하지 않는다. 검증 장치가 작동하지 않아 판정을 보류한 경우와 결과가 기준을 위반한 경우도 구분한다. 불확실한 판정을 사람에게 전달할 때에는 확인한 조건, 부족한 증거, 결과를 수용하면 감수할 위험과 가능한 다음 행동을 제시한다. 중단과 재시도 및 복구의 구체적인 선택은 8장에서 다룬다.

리더는 판정 체계가 놓친 것을 관찰한다

P06의 유용성은 수용한 결과의 운영 결함과 판정 번복을 추적하며 평가한다. 번복이 생겼다면 결과가 바뀌었는지, 기준이 달라졌는지, 처음의 증거가 부족했는지 구분한다. P07은 알려진 실패를 발견하는지와 판정 경로들이 같은 오류를 반복하는지 확인한다. 검토 시간, 추가 질문, 잘못된 거부와 검증 환경의 유지 비용도 함께 기록한다. 이런 관찰은 두 패턴의 효과를 평가하기 위한 제안이며, 이미 효과가 입증되었다는 주장이 아니다.

실패를 발견했다고 즉시 정책을 바꾸지는 않는다. 의도가 불완전했는지, 정책이 충돌했는지, 계획이 필요한 확인을 빠뜨렸는지, 구현이나 검증이 잘못되었는지 살핀다. 변경안이 같은 실패를 줄이면서 다른 조건을 훼손하지 않는지도 확인해야 한다. 4장은 이 증거를 다음 정책과 계획으로 돌려보내는 루프를, 19장은 개선안의 검증을 구체화한다.

『More Effective Agile』의 품질·완료와 자동 테스트라는 주제에 대한 이 책의 재고찰 질문은 실행 속도가 높아질 때 결과 수용의 기준과 판정 책임을 어떻게 유지할 것인가이다. 이 연결은 기존 공개 목차 대응표에 근거한 주제 연결이며 원서 본문을 대조한 평가가 아니다. 확인 범위는 원서 주제 연결의 범위에 남긴다.

리더가 유지할 책임은 모든 검사를 직접 수행하는 데 있지 않다. 어떤 증거가 어떤 약속을 확인하며, 그 증거가 부족할 때 누가 다음 판단을 할지 정하는 데 있다. 완료 보고는 그 판단을 요청하는 자료가 된다. 조직은 확인한 범위 안에서 결과를 수용하고, 남은 불확실성을 다음 책임으로 연결한다.

출처와 검토

[S10], [S13], [S18], [S42], [S59], [S62]. 확인 범위와 한계는 출처 대장, 주장의 성격과 검토 항목은 자료 확인 범위에 기록한다. 제품 실행·전체 CI 로그·Enterprise 환경·조직 성과와 패턴 효과는 검증하지 않았다.