직전 기간 매출을 같은 쿼리로 다시 셌더니 정의가 갈릴 자리가 없어졌습니다

프랜차이즈 ERP 의 매장별 매출 목록 화면에 '평균매출초과'라는 열이 있었습니다. 조회된 매장들의 평균 매출을 기준으로 이 매장이 그보다 위인지 아래인지를 보여주는 값입니다. 숫자는 정확했고 계산도 틀린 적이 없었습니다.

그런데 이 열을 보고 무엇을 하겠느냐고 물으면 답이 나오지 않았습니다. 이번에 그 열을 지우고 '매출 변동' 한 열로 바꿨는데, 실제로 어려웠던 곳은 변동률을 어떻게 계산하느냐가 아니었습니다. 비교되는 두 숫자가 같은 정의를 갖게 만드는 일이었습니다.

평균보다 높다는 값이 행동을 만들지 못했습니다

매장은 규모도 상권도 업태도 제각각입니다. 그래서 평균 대비 위치를 알아도 어디를 들여다봐야 하는지가 나오지 않습니다. 큰 매장은 늘 위에 있고 작은 매장은 늘 아래에 있습니다. 매일 열어도 같은 줄이 같은 자리에 섭니다.

고객이 실제로 원한 것은 매장끼리의 비교가 아니라 같은 매장의 시간 비교였습니다. 지난 기간보다 빠진 곳이 어디냐는 질문입니다. 객단가 열도 같은 이유로 안 보게 돼서 함께 걷어냈습니다. 목록 화면과 엑셀과 정렬에서 두 열을 모두 빼고 그 자리에 매출 변동 한 열을 넣었습니다.

덧붙이면 평균 대비 비교 자체가 쓸모없는 지표는 아닙니다. 같은 평수, 같은 업태처럼 크기가 고른 집단에서는 평균 대비가 바로 이상치를 집어냅니다. 여기서 안 통한 이유는 지표가 나빠서가 아니라 모집단이 고르지 않아서입니다.

직전 기간 값을 어디서 가져올 것인가

비교 대상을 시간으로 바꾸자마자 갈림길이 하나 나왔습니다. 직전 기간 매출을 어디서 가져올 것인가입니다. 세 가지를 놓고 봤습니다.

첫째 줄이 위험한 이유는 성능이 아니라 두 숫자의 정의가 조용히 갈린다는 데 있습니다. 지금 목록 쿼리에는 제외 매장 규칙, 매출로 인정하는 행의 조건, 브랜드·지역 필터가 이미 얹혀 있습니다. 전용 쿼리를 새로 짜면 그 규칙들을 옮겨 적어야 하고, 나중에 목록 쪽 규칙이 하나 바뀌면 비교 쪽은 따라오지 않습니다. 그때부터 한 화면의 두 숫자는 서로 다른 세계의 값이 됩니다.

셋째 줄은 처음엔 매력적으로 보였습니다. 다만 조회 화면의 필터 조합(브랜드·지역·제외 매장)을 미리 계산해 둔 집계가 알 수 없습니다. 필터가 걸린 순간 첫째 줄과 같은 문제로 돌아옵니다.

같은 쿼리를 기간만 바꿔 한 번 더 부릅니다

둘째 줄로 갔습니다. 목록을 만드는 그 쿼리에 기간 파라미터만 바꿔 한 번 더 호출해서 직전 기간 매출을 얻습니다. 직전 기간 전용 집계는 만들지 않았습니다. 필터가 하나 추가되거나 제외 규칙이 바뀌면 양쪽이 같이 바뀝니다. 치르는 비용은 조회당 쿼리 한 번입니다.

질문을 바꾼 셈입니다. 직전 값을 어떻게 잘 계산할까가 아니라, 두 값이 같은 함수에서 나오게 하려면 무엇을 안 만들어야 하나로 옮겼습니다. 새로 만들지 않는 쪽이 유지해야 할 약속을 하나 줄입니다.

남은 결정은 전부 창을 어디서 자르나로 모였습니다

출처를 하나로 묶고 나니 남은 판단이 한 곳으로 모였습니다. 비교 창을 어떻게 잡느냐입니다. 규칙은 조회 구간 바로 앞의 같은 일수입니다. 조회 구간의 끝을 어제로 잘라 길이를 세고, 그 길이만큼 앞으로 물린 구간을 비교 창으로 잡습니다.

오늘을 일수에서 빼는 이유는 취향이 아닙니다. 판매 데이터가 하루 늦게 들어오기 때문입니다. 오늘을 창에 넣으면 오늘치가 비어 있는 채로 분자에 들어가서 변동률이 늘 마이너스 쪽으로 기웁니다. 관측 지연이 있는 데이터는 이렇게 집계 창의 경계에서 티가 납니다.

이 규칙을 설명 문단으로 적는 대신 예시 셋을 테스트로 고정했습니다.

하루 조회 — 비교 창은 바로 전날 하루

한 달 조회 — 비교 창은 그 앞의 같은 일수

석 달짜리 긴 구간 — 같은 규칙으로 그 앞의 같은 일수

둘째 항목이 이 테스트를 박아둔 이유입니다. 한 달을 조회했을 때 '그 앞 같은 일수'와 '전달 전체'는 서로 다른 구간인데, 글로만 적어두면 다음 사람이 거의 반드시 전달 전체로 읽습니다. 경계 규칙은 문장이 아니라 입력과 기대 출력 쌍으로 적는 편이 정확합니다.

그리고 지금 이 변동률이 어느 구간과 견준 값인지를 검색줄에 글자로 띄웠습니다. 화면 어딘가의 설명 문서가 아니라 숫자 바로 옆에 있어야 사람이 읽습니다.

계산할 수 없는 자리는 빈 칸으로 둡니다

직전 기간 매출이 0이거나 그 사이 폐점한 매장은 변동률을 계산하지 않고 빈 칸으로 뒀습니다. 0으로 나눌 수 없어서만은 아닙니다. 없는 값을 억지로 숫자로 메우면 그 행이 정렬과 필터에서 앞자리를 차지합니다.

직전 기간 매출이 0인 매장에 변동률을 매기면 신규 개점 매장이 전부 무한대 증가로 목록 맨 위에 섭니다. 많이 변한 매장을 보자는 원래 목적에 정확히 반대로 작동하는 화면이 됩니다. 폐점 매장도 같습니다.

반대로 눈에 띄어야 하는 자리에는 표시를 넣었습니다. 변동 폭이 증가·감소 양쪽으로 ±20% 이상이면 매장명을 강조하고, 그것만 남기는 필터를 붙였습니다. 필터 상태는 주소에 실어서 링크로 공유되게 했고, 엑셀도 걸러진 매장만 내려갑니다. 화면에서 걸러 놓고 받은 파일에는 전량이 들어 있으면 그 파일을 다시 걸러야 합니다.

같은 쿼리를 썼으니 맞을 것이라는 말은 검증이 아닙니다

출처를 하나로 묶었다고 해서 검증을 건너뛸 이유는 없습니다. 값을 옆에서 다시 세는 방식으로 봤습니다. 한 구간을 조회해 화면이 돌려준 직전 기간 매출을, 그 구간을 직접 조회해서 얻은 매출과 대조했습니다. 목록 전량이 일치했습니다. 변동률도 두 값에서 다시 계산해 불일치가 몇 건인지 셌고 0이었습니다.

구조가 옳다는 확신과 값이 맞다는 확인은 다른 일입니다. 구조는 앞으로 갈리지 않게 막아주고, 대조는 지금 갈려 있지 않은지를 봅니다.

비교 지표를 붙이기 전에 보는 것

분자와 분모가 같은 코드 경로에서 나오는가 — 다른 경로면 그 화면은 언젠가 거짓말을 합니다

무엇과 비교하는가 — 크기가 다른 개체가 섞인 목록에서 모집단 평균은 순위를 고정시켜 정보가 되지 않습니다

데이터가 언제 도착하는가 — 지연이 있으면 마지막 하루가 지표 전체를 끌어내립니다

창을 자르는 규칙이 테스트로 적혀 있는가 — 문장으로 적힌 경계는 다르게 읽힙니다

계산할 수 없는 자리를 0이나 100%로 메우고 있지 않은가 — 빈 칸이 맞습니다

이 선택이 늘 맞는 것은 아닙니다

같은 쿼리를 두 번 부르는 비용이 감당되지 않는 크기가 있습니다. 목록 쿼리 자체가 무거우면 조회 시간이 그대로 두 배가 됩니다. 그때는 전용 집계가 맞고, 대신 두 경로의 정의가 갈리지 않는지를 대조 테스트로 계속 붙들어야 합니다. 정의 일치 문제가 사라지는 것이 아니라 사람이 지키는 쪽으로 옮겨갈 뿐입니다.

직전 같은 일수가 늘 옳은 비교 창인 것도 아닙니다. 명절이나 프로모션처럼 해마다 날짜가 움직이는 기간은 바로 앞 구간보다 작년 같은 행사 기간과 견주는 편이 맞습니다. 이 화면은 일상 모니터링용이라 직전 기간을 골랐고, 기간을 직접 지정해 견주는 요구는 다른 화면이 받습니다.

요일 구성이 다르면 같은 일수라도 공정하지 않습니다. 주말이 하나 더 들어간 구간과 견주면 변동률에 요일 효과가 섞입니다. 주 단위로 창을 잡거나 요일 보정을 넣는 선택지가 있었고, 이 화면은 단순함을 골랐습니다.

규칙의 예외는 규칙이 적힌 곳 옆에 적었습니다

곁다리로 한 가지를 더 정했습니다. 이 화면은 진입하자마자 기본 기간으로 최초 1회 자동 조회하게 했습니다. 변동률은 기준 구간이 있어야 의미가 생기는 값이라, 빈 화면에서 조회 버튼을 누르게 하면 무엇과 견주는 숫자인지 모르는 채로 첫 화면을 만나게 됩니다.

문제는 이 프로젝트에 '진입 시 자동 조회하지 않는다'는 규칙이 이미 있다는 점이었습니다. 그래서 예외를 커밋 메시지나 별도 문서가 아니라 그 규칙이 적힌 저장소 루트의 에이전트 규칙 파일에 같이 적었습니다. 다른 곳에 적힌 예외는 다음 사람이 규칙 위반으로 보고 되돌립니다.

비교 지표를 붙일 일이 생기면 계산식보다 먼저 보게 되는 것이 하나 생겼습니다. 이 화면에 나란히 선 두 숫자가 같은 곳에서 나왔는지입니다. 같은 곳에서 나오게 만드는 가장 싼 방법은 대개 새로 만들지 않는 것입니다.