8장 예외와 복구를 설계한다

멈출 이유와 다시 시작할 조건을 정한다

자동 실행의 범위를 넓히면 실패한 뒤의 행동도 위임해야 한다. 결과가 나오지 않았을 때 다시 실행할지, 이미 바뀐 상태를 확인할지, 이전 상태로 돌아갈지 판단이 필요하다. 성공할 때의 경로만 정하면 실패의 순간에 수행자가 임의로 반복하거나 사람이 모든 다음 단계를 다시 지시해야 할 수 있다. 리더는 실행을 계속할 조건과 멈춰야 할 조건을 함께 정해야 한다.

5장은 실행 계약에 실패 처리를 연결했고, 6장은 부분 결과와 통합 조건을 나눴다. 7장은 확인한 증거와 결과 수용의 범위를 구분했다. 이 장은 실패하거나 판정할 수 없을 때의 다음 행동을 다룬다. 중단은 더 이상의 영향을 제한하는 판단이고, 재시도는 같은 의도를 다시 수행하는 행동이며, 복구는 필요한 상태와 업무 흐름을 회복하는 작업이다. 이 구분은 이 책의 운영 설계 제안이다.

P10 ‘범위가 정해진 자율성’은 실행 권한과 정지 조건, 예외 경로를 정한다. P11 ‘예외를 통한 개입’은 정상 결과를 정해진 검증으로 처리하고 정책 충돌과 불확실성, 큰 영향에 판단을 배치한다. P15 ‘검증을 거치는 개선’은 실패 뒤 변경안의 효과를 같은 기준으로 확인한다. 실패를 처리하는 권한, 지금 결과를 수용하는 판단, 다음 실행을 개선하는 판단을 구분하면서 연결한다.

오류와 결과 미확인, 기준 충돌을 나눈다

실패라는 한 단어로 다른 상태를 묶으면 다음 행동을 잘못 선택할 수 있다. 실행이 시작되지 않았는지, 일부 행동은 끝났는지, 결과는 있지만 증거를 얻지 못했는지 구분해야 한다. 기준에 맞지 않는 결과와 기준 자체가 충돌하는 상황도 다른 판단을 요구한다. 이 책은 확인한 상태와 아직 모르는 상태를 나누어 보고하도록 권한다.

예를 들어 사내 문의에 대한 답변을 허용된 대상에게 발송했지만 발송 도구의 응답을 받지 못했다고 하자. 이는 5·6장에서 사용한 가상 업무의 연장이며 실제 사건이 아니다. 답변이 전달되지 않았을 수도 있고, 전달되었지만 확인 응답만 누락되었을 수도 있다. 같은 답변을 곧바로 다시 보내면 중복 전달이 생길 수 있다. 성공 표시가 없다는 이유만으로 실행이 없었다고 가정해서는 안 된다.

확인할 상태	먼저 물을 질문	연결할 다음 판단
실행 전 오류	필요한 자료·권한·환경이 준비되었는가	부족한 조건을 보완할지 실행을 보류할지
일시적인 실행 오류	같은 요청을 반복해도 추가 영향이 없는가	허용 범위의 재시도와 중단 조건
결과 미확인	어떤 행동이 끝났으며 실제 상태를 확인할 수 있는가	상태 조사·재검증·별도 판단
일부 결과만 완료	완료한 부분과 남은 부분의 관계는 무엇인가	유지할 결과와 복구할 범위
정책·수용 기준 충돌	어떤 약속과 권한이 서로 맞지 않는가	기준 책임자의 범위·예외·중단 판단

이 표는 상태를 조사하기 위한 제안이다. 표에 분류했다는 사실만으로 다음 행동이 안전해지지는 않는다. 필요한 증거가 없다면 모르는 상태를 그대로 남기고 확인할 책임과 허용할 행동을 정한다. 결과가 없다는 판단과 결과를 확인하지 못했다는 판단을 구분하는 것이 재시도와 복구의 출발점이다.

같은 요청을 다시 해도 되는지 확인한다

Amazon Builders’ Library의 설명은 재시도가 일시적 실패에 도움이 될 수 있지만, 과부하를 키우거나 이미 발생한 부작용을 반복할 수 있다고 지적한다.[S50] 확인한 것은 작성자의 설계 설명이며 이 책에서 서비스를 실행하거나 효과를 재현한 결과는 아니다.

이 설명에서 이 책이 얻는 해석은 재시도의 근거를 실패 표시만으로 정하지 말아야 한다는 것이다. 같은 입력과 목적을 유지할 수 있는지, 이미 발생한 행동을 확인할 수 있는지, 반복이 더 큰 영향을 만들지 않는지 살핀다. 필요한 조건이 달라졌다면 같은 요청의 재시도가 아니라 새로운 계획이나 기준 판단일 수 있다.

별도의 Builders’ Library 글은 같은 요청을 반복해도 추가 부작용이 생기지 않도록 하는 멱등성과 요청 식별의 계약을 설명한다.[S51] 멱등성은 여기서 같은 의도의 반복이 별도의 효과를 더 만들지 않도록 하는 성질이다. 적용 범위와 요청을 식별하는 조건이 필요하며, 모든 외부 행동이 이 성질을 갖는다고 가정하지 않는다.

가상 발송 업무에서 같은 발송 의도를 식별하고 실제 상태를 확인할 수 있다면 중복 행동을 줄일 방법을 검토할 수 있다. 하지만 수행자를 바꿀 때 요청 식별이 사라지거나 내용이 바뀌었는데 같은 요청으로 취급하면 판단이 어긋날 수 있다. 재시도의 계약에는 대상과 의도, 적용 기준과 상태를 연결한다. 형식상 같은 식별자가 있다는 사실과 중복 효과를 막는 장치가 실제로 작동한다는 사실은 별도로 확인해야 한다.

읽기 중심 작업에도 반복의 비용과 한계가 있다. 새 자료가 들어오면 같은 요청의 결과가 달라질 수 있다. 반복해서 얻은 결과를 어느 시점의 기준으로 판단할지 정해야 한다. 행동의 부작용이 작다는 이유만으로 무제한 반복을 허용하지 않는다.

재시도에는 비용과 종료 조건을 붙인다

Vibe Up은 수렴하지 않는 작업을 요청과 가정의 재검토로 돌려보내는 운영 장치를 제안한다.[S72] 이 책에서는 이를 재시도 원인을 구분하는 데 활용한다. 일시적인 실행 환경의 오류라면 허용한 반복이 도움이 될 수 있지만, 수행자가 상충하는 요구를 번갈아 충족한다면 필요한 것은 같은 작업의 재실행보다 무엇을 우선할지 정하는 판단일 수 있다.

그 판단으로 돌아갈 때에는 확인한 결과, 충돌한 조건, 이미 시험한 대안과 남은 선택을 넘긴다. 의도 소유자나 정책 책임자가 조건을 정리한 뒤 계획과 증거의 적용 범위를 다시 확인한다. 원문의 일정·횟수는 모든 업무에 적용할 임계값으로 삼지 않는다. 반환 경로가 책임을 떠넘기는 절차가 되지 않도록 9장의 조정 책임과 연결한다.

재시도를 맡길 때에는 허용할 시간과 자원, 중단할 상태를 정한다. 같은 실패가 반복되거나 필요한 상태를 확인하지 못하면 다음 판단으로 돌아갈 수 있어야 한다. 시도 횟수만 남기고 어떤 조건이 달라졌는지 기록하지 않으면 반복의 의미를 평가하기 어렵다. 여러 작업이 함께 실패했을 때에는 공통 기반의 문제인지 개별 작업의 문제인지도 살핀다.

실행 주체마다 독립적으로 반복하면 전체 부담을 알아보기 어려울 수 있다. 이 책은 한 작업의 재시도와 연결된 작업들의 반복을 함께 관찰하도록 제안한다. 누가 반복을 결정하고 다른 작업을 보류할지 정한다. 같은 장애에 요청을 계속 쌓기보다 확인할 상태와 회복할 자원을 구분해야 한다.

기다리는 것도 운영의 선택이다. 일시적인 조건 변화가 해소될 때까지 대기할 수 있지만, 사용자가 결과를 기다리는 비용과 그동안의 상태를 함께 관리해야 한다. 너무 이르게 멈추면 가능한 결과를 놓칠 수 있고, 너무 늦게 멈추면 비용과 영향을 키울 수 있다. 허용 범위는 작업의 가치와 영향, 복구 가능성을 근거로 정하고 실제 결과를 보며 고친다.

종료 조건을 충족하면 이미 시작한 행동도 확인해야 한다. 중단 요청을 냈다고 외부 시스템의 실행까지 즉시 멈췄다는 뜻은 아니다. 아직 진행되는 부분과 완료된 부분을 기록하고, 다음 수행자가 같은 행동을 다시 시작하지 않도록 연결한다. 6장의 진행 중 작업과 인계 기록은 이 상태를 관리하는 데 필요하다.

복구는 무조건 이전 상태로 돌아가는 일이 아니다

실행 전의 상태를 되살리는 방법은 복구의 한 선택이다. 그러나 외부에 전달한 답변이나 이미 사용된 결과는 과거의 행동을 없었던 일로 만들기 어려울 수 있다. 되돌릴 수 있는 변경과 후속 조치로 영향을 줄여야 하는 변경을 구분한다. 이 책은 복구의 목표를 상태와 사용자 약속의 관점에서 정하도록 제안한다.

가상 문의 업무에서 초안만 저장했다면 초안을 수정하거나 폐기할 수 있다. 이미 잘못된 답변이 전달되었다면 현재 상태를 확인하고 정정과 후속 안내를 판단할 수 있다. 이것은 같은 권한이나 같은 비용의 작업이 아니다. 무엇을 회복할지와 누구에게 새로 약속할지를 해당 책임자가 결정해야 한다.

부분 결과를 모두 되돌리는 것이 적절하지 않을 수도 있다. 확인한 근거와 올바른 중간 결과는 유지하고 잘못된 부분만 다시 처리할 수 있다. 그 경우 부분 결과가 어떤 버전과 조건에 의존하는지 확인한다. 복구한 부분이 다른 결과의 가정을 바꾸면 통합을 다시 검증해야 한다. 작은 결과를 나누는 것과 복구 범위를 자동으로 알 수 있다는 주장은 구분한다.

복구 행동 자체도 실패할 수 있다. 복구할 권한과 자료가 없거나 새로운 영향이 생기면 그 상태를 기록하고 판단 경로로 넘긴다. 복구 명령을 내린 사실과 목표한 상태가 회복되었다는 증거를 분리한다. 7장의 증거 기반 완료는 복구 결과의 수용에도 적용된다.

사람에게 돌아올 예외를 결정과 연결한다

P11은 정상 결과를 정해진 검증으로 처리하고 정책 충돌과 불확실성, 큰 영향에 사람이 개입하도록 제안한다. 알려진 일시적 오류를 허용 범위에서 처리할 수 있다면 매번 새로운 승인을 요청할 필요는 없을 수 있다. 반대로 결과가 무엇인지 알 수 없거나 허용한 경계 밖의 행동이 필요하다면 별도의 판단을 요청해야 한다. 실패라는 이름만으로 모든 사건을 같은 알림으로 보내지 않는다.

판단 요청에는 현재 의도와 적용 기준, 확인한 상태와 증거, 아직 모르는 것, 이미 한 행동과 가능한 다음 선택을 연결한다. 계속할지, 범위를 줄일지, 복구할지, 종료할지에 따라 감수할 위험이 달라진다. 책임자가 원래 기록으로 내려가 확인할 수 있어야 한다. 로그를 많이 전달하는 것보다 어떤 결정을 요청하는지 드러내는 것이 중요하다.

예외에는 판단할 주체와 기다릴 조건도 필요하다. 책임자가 응답하지 않을 때 계속 실행해도 되는지, 보류할지, 다른 책임자에게 넘길지 정한다. 안전하게 멈출 수 있는 범위를 먼저 확인하고 필요한 긴급 대응 권한을 구분한다. 응답이 없다는 사실을 경계를 넘을 허락으로 해석하지 않는다.

예외를 허용할 때에는 대상과 기간, 종료 조건과 남은 위험을 남긴다. 한 번의 허용이 같은 종류의 모든 작업에 적용되거나 이후의 권한으로 남지 않도록 한다. 반복되는 예외는 정책이 현실과 어긋났는지, 계획과 수행 능력이 부족한지 검토할 자료가 된다. 승인 횟수만으로 어느 쪽이 잘못됐는지 단정하지 않는다.

멈춘 범위와 재개할 범위를 구분하는 구현

데모의 실패율 차단기는 정한 관찰 창과 표본 조건에서 구현·수정 실행의 실패 비율을 판단해 새 작업 시작을 일시 중지한다. 별도의 명령 처리 코드는 저장소 쓰기 권한과 현재 상태를 확인한 뒤 관련 실행 취소와 사람에게의 이관을 처리한다.[S63] 무엇을 중단하고 어떤 판단은 계속할지 구분한 예다.

차단기 해제, 취소된 작업의 재시도, 이미 반영한 외부 효과의 복구는 서로 다르다. 데모의 임계값을 그대로 옮기기 전에 실패 영향과 표본의 의미를 판단해야 한다. 오래 대기한 작업이 자동으로 복구되는지도 별도 질문이다. 데모 문서는 준비 단계 실패 뒤 사람이 상태를 정리해야 하는 경우를 남겨 두고 있다.[S59] 리더는 예외 경로가 작동하지 않는 경우까지 운영 책임에 포함해야 한다.

복구 뒤에는 다시 시작할 기준을 확인한다

복구된 상태에서 재개할 때에는 무엇이 보존되었고 무엇이 달라졌는지 확인한다. 원래 입력과 계약이 여전히 유효한지, 앞선 완료 증거를 계속 쓸 수 있는지, 결과를 수용할 조건이 바뀌었는지 판단한다. 새 환경이나 다른 수행자가 이어받으면 기록과 실제 상태가 일치하는지도 확인해야 한다.

재개 가능한 부분과 추가 판단이 필요한 부분을 나누면 전체 작업을 처음부터 반복하는 부담을 줄일 수 있는지 평가할 수 있다. 그러나 과거 검증을 재사용하는 이유와 범위를 설명해야 한다. 이미 확인한 단계라는 이유만으로 새로운 조건에서의 확인을 생략하지 않는다. 다시 시작하는 결정에는 적용할 기준과 허용 권한이 연결되어야 한다.

리더는 복구에 성공했다는 보고와 업무의 목적을 달성했다는 판단도 구분한다. 서비스의 실행 상태는 회복되었지만 사용자에게 할 약속이나 자료의 정확성이 남을 수 있다. 남은 관찰과 결과 수용의 책임을 이어간다. 9장은 제품 팀과 공유 기반이 이 책임을 나누는 구조를 다룬다.

실패를 기준 변경의 근거로 바로 사용하지 않는다

재시도와 복구의 기록은 다음 실행을 개선할 자료가 된다. 그러나 같은 실패를 줄였다는 이유로 수용 기준을 낮추거나 권한을 넓힌 결과까지 개선으로 계산해서는 안 된다. P15는 실패를 원인별로 분류하고 변경안을 고정된 회귀 과제로 확인한 뒤 허용 범위에서 반영하도록 제안한다.

실행 오류와 판단 기준의 누락, 정책 충돌과 검증 장치의 문제를 구분한다. 실제 상태를 확인하지 못했다면 관측과 기록을 보완할 이유가 있을 수 있다. 중복 행동이 생겼다면 요청 식별과 반복의 권한을 조사한다. 사람에게 같은 질문이 반복되면 계약과 예외 경로에 빠진 판단이 있는지 살핀다. 하나의 원인으로 모든 실패를 설명하지 않는다.

개선 전후에 같은 조건의 실패를 다시 확인하고 정상 결과를 지나치게 보류하지 않는지도 본다. 변경한 규칙과 장치의 이유, 적용할 작업과 확인할 효과를 연결한다. 4장은 이 자료를 다음 정책과 계획으로 돌려보내는 루프를, 19장은 개선안을 검증하는 운영을 더 다룬다.

리더는 복구 속도와 남은 영향을 함께 본다

P10은 허용 범위 밖 행동과 정지 조건의 작동을 확인한다. 중단 뒤 남은 실행과 권한, 재개할 때 적용한 기준을 살핀다. P11은 예외 처리 시간과 놓친 사건, 불필요한 알림을 함께 본다. 같은 문제를 반복해서 사람에게 보내는지와 중요한 판단이 묻혔는지도 확인한다.

P15는 변경 전후를 같은 기준으로 비교하고 정책 이력을 검토한다. 재시도 비용, 중복 행동과 복구 실패, 판정 대기와 사용자가 감수한 영향을 함께 기록한다. 빨리 다시 실행했다는 사실만으로 안전한 복구나 생산성 향상을 주장하지 않는다. 실제 결과와 전체 비용으로 운영을 평가해야 한다.

『More Effective Agile』의 복잡성·불확실성과 프로세스 개선이라는 주제에 대한 이 책의 재고찰 질문은 실패한 실행을 어떤 조건에서 반복하고 어떤 책임으로 멈추며 결과를 다시 판단할 것인가이다. 연결은 원서 주제 연결의 범위의 공개 목차 범위다.

실패를 처리하는 경로를 설계하면 위임의 범위를 더 분명하게 설명할 수 있다. 리더는 자동 처리할 상태와 새로운 판단이 필요한 상태를 나누고, 멈춘 뒤에도 무엇을 확인하고 회복할 책임이 남는지 연결한다. 다음 장은 이 흐름을 제품 팀과 공유 생산 기반의 책임 구조로 옮긴다.

출처와 검토

[S50], [S51], [S59], [S63], [S72]. 확인 범위와 한계는 출처 대장, 주요 주장의 성격은 자료 확인 범위에 기록한다. 공급자의 기술 설계 설명을 조직의 운영 효과로 일반화하지 않았다. 실제 API 실행·중복 방지·부하·복구 효과·원서 본문 대조는 검증하지 않았다.