저장된 필드의 의미를 바꾸면

배치가 매일 집계를 계산해 저장하고 화면은 그 값을 읽어 차트를 그린다. 올라온 변경을 검토하다 집계 필드의 계산이 건수에서 금액으로 바뀌는 한 줄에서 멈췄다.

Open Table of contents

최근 몇 달만 재집계하는 배치

이 배치는 전체를 매일 다시 만들지 않고 최근 몇 개월만 재집계한다. 전량을 매일 돌리면 시간이 감당되지 않기 때문이다.

그러면 재집계 구간은 금액이 되고 그 이전 구간은 건수로 남는다. 화면은 전체를 새 의미로 해석하므로 축이 뒤섞인 차트가 그려진다.

여기가 이 변경의 위험한 부분이었다. 타입이 같고 필드 이름도 같고 조회도 성공하므로 어디서도 오류가 나지 않는다.

건수 수십과 금액 수백만이 같은 축에 놓이면 과거 구간이 바닥에 붙는다. 옛날에는 매출이 없었던 것처럼 보이는 차트가 조용히 만들어진다.

이것을 어떻게 다뤄야 하는지 정리하면서 성격을 다시 잡았다. 저장된 집계의 필드 의미를 바꾸는 것은 코드 배포가 아니라 스키마 마이그레이션이다.

컬럼 타입을 바꿀 때 기존 데이터를 어떻게 할지 정하는 것과 같은 일이다. 저장된 값이 있고 그 해석이 바뀐다는 구조가 동일하기 때문이다.

첫째는 전량 재집계로 과거까지 새 의미로 다시 만드는 것이다. 시간이 걸리지만 이후 해석이 하나로 통일된다.

둘째는 새 필드명을 쓰고 기존 필드를 그대로 두는 것이다. 화면은 새 필드를 읽고 없으면 옛 필드로 물러나므로 과거 구간도 무언가는 보인다.

셋째는 혼재를 받아들이고 화면에 그 사실을 표시하는 것이다. 셋 중 하나를 배포 전에 고르지 않으면 표시 없는 셋째가 되는데 그것은 그냥 틀린 차트다.

전량 재집계로 가되 배포와 같은 단계에 두지 않았다. 재집계는 몇 시간이 걸리고 도중에 실패할 수 있어서 배포 안에 넣으면 되돌리는 판단이 애매해진다.

새 필드명으로 코드를 먼저 내보내고 화면은 옛 필드로 물러나게 둔 뒤 재집계를 따로 돌렸다. 완료를 확인하고 나서 물러나는 경로를 지웠으므로 각 단계가 독립적으로 되돌아간다.

의미를 바꾼 것이 의도인지도 원저자에게 물었다. 의도였고 화면도 같이 바뀌어 있었으며 과거 데이터 문제만 못 본 것이었는데 바꾼 사람이 못 본 것과 안 바꾼 것은 물어봐야 갈린다.