읽기와 쓰기 사이에는 문턱이 하나 있다

한 줄 요약

조사는 틀려도 다시 하면 되지만 UPDATE 는 다시 할 수 없고, 그래서 쓰기 앞에는 조사에 없던 네 가지가 붙는다 — 범위 산정, 되돌릴 길, 시험 실행, 중단 기준.

왜 이게 필요했나

FDE 가 고객 환경에서 하는 일의 대부분은 읽기입니다. 로그를 읽고, 테이블을 조회하고, 코드를 따라가고, 그 결과를 문서로 옮깁니다. 이 구간에서 틀린 판단의 비용은 시간입니다. 가설이 어긋나면 지우고 다시 세우면 되고, 잘못 센 숫자는 다시 세면 됩니다.

그런데 어느 시점에 반드시 이 문장이 옵니다. "그럼 그거 좀 고쳐 주실 수 있나요."

여기서부터 성질이 완전히 바뀝니다. 틀린 조회는 다시 하면 되지만 틀린 UPDATE 는 다시 할 수 없습니다. 되돌릴 수단을 미리 만들어 두지 않았다면, 그 순간 우리가 한 일은 조사가 아니라 사고입니다.

그리고 문제가 하나 더 있습니다. 요청은 조건이 아니라 문장으로 옵니다. "오래 멈춰 있는 결제 건 정리해 주세요" 라는 문장을 WHERE status='pending' 으로 옮기는 순간, 요청한 사람이 머릿속에 그린 범위와 실제로 바뀌는 범위가 갈라집니다. 갈라진 폭만큼이 사고이고, 그 폭은 세어 보기 전에는 요청한 쪽도 받은 쪽도 모릅니다.

어떻게 동작하나

쓰기 앞에 붙는 네 가지 장치는 전부 이 갈라짐을 좁히거나, 좁히지 못했을 때를 대비합니다.

하나, 범위 산정. 두 숫자를 나란히 놓습니다 — 요청 문장을 그대로 옮겼을 때 바뀌는 행 수와, 조건을 좁혔을 때 바뀌는 행 수. 이 두 숫자의 차이가 이 변경의 위험입니다. 45건과 20건이라면 25건이 위험이고, 그 25건이 왜 제외되는지를 한 줄씩 적을 수 있어야 조건이 완성된 것입니다.

둘, 되돌릴 길. 백업은 두 종류를 남기는데 쓰임이 다릅니다.

파일 사본   전부 잘못됐을 때 통째로 되돌린다.            단점 — 그 사이에 들어온 남의 변경까지 함께 되돌아간다.행 스냅샷   바꿀 행의 변경 전 값을 id 와 함께 남긴다.            id 를 열쇠로 그 행만 되돌릴 수 있고, 무엇이 어떻게 바뀌었는지 설명할 수 있다.

파일 사본만 있으면 되돌릴 수는 있어도 설명할 수 없고, 행 스냅샷만 있으면 스키마가 바뀌는 변경을 되돌릴 수 없습니다. 그래서 둘 다 남깁니다.

셋, 시험 실행. 트랜잭션을 열고 실제 UPDATE 를 친 다음 커밋하지 않고 되돌립니다. SELECT COUNT(*) 로 미리 세는 것과 결과가 같아 보이지만 성질이 다릅니다. 세는 조건과 바꾸는 조건이 문자 그대로 같기 때문입니다. 두 문장을 따로 쓰면 그 사이에 오타가 숨고, 오타는 언제나 두 문장 중 실행되는 쪽에 있습니다.

넷, 중단 기준. 어떤 결과를 보면 멈출지를 실행 전에 정합니다. 이건 다음 모듈에서 따로 다룹니다.

그리고 적용이 끝난 뒤의 검증에는 절반이 더 있습니다. 대조군 — 바뀌지 말아야 할 것이 그대로인지 세는 일입니다. 바뀌어야 할 것만 세는 검증은 조건이 넓어 옆을 함께 건드린 사고에서도 멀쩡히 통과합니다.

현장에서 만나는 모습

첫째, 확인할 수 없는 것은 바꾸지 않습니다. 고객 테이블에 없는 customer_id 를 가진 주문처럼, 조건은 만족하지만 누구의 것인지 알 수 없는 행이 실제 데이터에는 거의 항상 섞여 있습니다. 오래됐다는 이유만으로 함께 취소하면 나중에 그 한 건을 설명할 수 없습니다. 제외하고, 제외한 사실과 이유를 계획서에 적고, 고객사에 물어보는 것이 정답입니다. 제외는 일을 덜 한 것이 아니라 판단을 기록한 것입니다.

둘째, 없던 값을 새로 만드는 변경은 조용히 퍼집니다. status 에 지금까지 없던 cancelled 를 넣으면, 그 값을 모르는 집계 쿼리와 대시보드는 그 행들을 조용히 빼고 셉니다. 에러가 나지 않으니 아무도 모르고, 한 달 뒤 정산이 맞지 않는 것으로 드러납니다. 그래서 새 값을 도입하는 변경은 데이터 변경이면서 동시에 통보해야 하는 변경입니다.

셋째, 실행 기록은 실행한 사람이 아니라 두 시간 뒤에 이 표를 이상하게 여길 다른 사람을 위한 것입니다. 언제, 무엇을, 몇 건, 무엇으로 되돌리는지가 한자리에 없으면 그 사람은 우리를 찾아내는 데 시간을 씁니다.

다음 실습에서 할 것

고객사가 "pending 인 주문을 전부 cancelled 로 바꿔 주세요" 라고 요청한 상황을 처음부터 끝까지 밟습니다. 요청대로 옮기면 45건이 바뀌는데 실제로 바꿔야 할 것은 20건입니다. 그 25건의 차이를 찾아내고, 되돌릴 길을 만들고, 사본에서 되돌리기를 시연한 뒤, 본 적용과 대조군 검증까지 끝냅니다.