멈추는 결정은 실행 전에만 싸다

한 줄 요약

이상 신호를 보고 멈출지 말지는 실행 중에 정할 수 없다 — 그때는 이미 들인 시간과 절반 바뀐 상태가 계속하는 쪽으로 밀기 때문에, 멈출 자리는 실행 전에 종이에 적어 두어야 한다.

왜 미리 정해야 하나

변경을 절반쯤 적용한 상태에서 대조군 숫자가 계획과 다르게 나왔다고 해 봅시다. 지금 필요한 판단은 "멈출 것인가" 하나뿐인데, 그 판단을 내리는 사람의 조건이 30분 전과 완전히 다릅니다.

이미 두 시간을 썼고, 고객사 담당자가 화면 옆에 앉아 있고, 데이터는 절반만 바뀐 상태입니다. 이 상태에서 사람은 거의 언제나 계속하는 쪽으로 기웁니다. "여기까지 왔으니 끝내고 보자", "지금 멈추면 상태가 더 이상해진다". 두 문장 다 그 순간에는 합리적으로 들리고, 나중에 사고 보고서에서 다시 읽으면 둘 다 변명입니다.

그래서 멈출 자리는 아직 아무것도 바꾸지 않았을 때, 즉 멈추는 데 아무 비용도 들지 않을 때 정해 둡니다. 실행 중의 나는 그 문장을 다시 쓰는 사람이 아니라 그 문장을 지키는 사람입니다.

어떻게 동작하나

쓸 수 있는 중단 기준에는 세 가지가 다 들어 있어야 합니다.

관측할 수 있는 지표   무엇을 보고 판단하는가. 느낌이 아니라 세어지는 것.넘으면 안 되는 값     그 지표가 얼마가 되면 이상인가. 부등호와 숫자로.그때 할 행동          멈추고 무엇을 하는가. 되돌린다 / 보류하고 보고한다.

셋 중 하나만 빠져도 실행 중에 해석의 여지가 생기고, 해석의 여지는 언제나 계속하는 쪽으로 쓰입니다. "이상하면 멈춘다" 는 중단 기준이 아니라 각오입니다.

부분 적용 상태가 가장 위험합니다. 변경 전 상태와 변경 후 상태는 둘 다 설명할 수 있지만, 절반만 바뀐 상태는 아무 문서에도 없습니다. 그래서 멈춘다는 것은 "그 자리에 선다" 가 아니라 대개 "되돌린다" 입니다. 되돌릴 수 없어서 그 자리에 서야 한다면, 그 사실 자체를 즉시 알리는 것까지가 중단 행동입니다.

시간도 기준입니다. 변경 창이 60분이라면 적용은 60분에 끝나는 것이 아니라, 되돌리는 데 걸리는 시간과 되돌린 뒤 확인할 시간을 빼고 끝나야 합니다. 되돌릴 시간이 없는 상태로 창을 넘기면, 그 뒤로는 중단 기준이 있어도 실행할 수단이 없습니다.

그리고 가장 좋은 방법은 되돌릴 수 없는 변경을 만들지 않는 것입니다. 삭제 대신 삭제 표시를 남기고 유예 기간 뒤에 지우면, 되돌릴 수 없는 한 번이 되돌릴 수 있는 두 번으로 쪼개집니다. 열을 지우는 대신 쓰기를 먼저 멈추고 한 주기를 지켜보는 것도 같은 방식입니다. 이렇게 쪼갤 수 있는지를 먼저 묻는 것이, 중단 기준을 잘 쓰는 것보다 앞섭니다.

현장에서 만나는 모습

실행 직전에 요청자가 조건을 한 군데만 바꿔 달라고 하는 일이 자주 있습니다. "아, 그 주문은 빼 주세요" 한마디면 되는 것처럼 들리지만, 조건이 바뀌면 범위 산정도 시험 실행도 백업도 전부 다른 조건 위에서 한 것이 됩니다. 옳은 대응은 그 한 군데를 반영하고 앞 단계를 다시 밟는 것이고, 시간이 없다면 원래 조건으로 실행한 뒤 차이분을 별도 변경으로 다루는 것입니다. 그 자리에서 조건만 고쳐 실행하는 것이 가장 흔한 사고 경로입니다.

또 하나, 중단을 실제로 실행한 뒤에는 멈췄다는 사실 자체가 보고 대상입니다. 되돌렸으니 아무 일도 없었다고 넘어가면, 고객사는 나중에 로그에서 그 흔적을 발견하고 우리가 숨겼다고 읽습니다. 멈춘 이유와 되돌린 범위, 그리고 다시 시도할 조건을 그날 안에 적어 보내는 것까지가 한 사이클입니다.

다음 실습에서 할 것

요청서가 120건이라고 한 변경의 실제 대상이 480건인 현장을 받습니다.
중단 기준을 종이에 적는 데서 끝내지 않고 코드가 집행하게 만듭니다.

채점기가 여러분의 스크립트를 세 가지 요청으로 직접 돌리고 실행 전후의
데이터를 대조합니다. 범위 기준에 걸려야 하는 요청, 도중에 불변식이 깨져
되돌려야 하는 요청, 그리고 통과해야 하는 요청입니다.

마지막이 중요합니다 — 막기만 하고 일이 안 되면 그것도 실패입니다.