같은 질문에 답이 둘인 이유

한 줄 요약

보험 데이터에는 시간 축이 둘이다 — 언제의 상태인가(기준일)와 언제 알게 된 사실로 계산했는가(인지일). 둘 중 하나만 적은 리포트는 다음 달에 재현되지 않는다.

왜 이게 필요했나

6월 마감 리포트에 "실효 계약 10건" 이라고 적어 보냈습니다. 8월에 감사 대응으로 같은 질의를 다시 돌렸더니 7건이 나왔습니다. 질의는 파일로 저장해 뒀고 한 글자도 안 고쳤습니다. 기준일도 그대로 2026-06-30 입니다.

이 자리에서 할 수 있는 말이 없습니다. 감사팀에게는 "숫자가 왜 바뀌었는지 모르겠습니다" 로 들리고, 그 다음 질문은 반드시 "그럼 6월에 보낸 숫자는 뭐였습니까" 입니다.

원인은 데이터 오염도 버그도 아닙니다. 보험은 과거를 고쳐 쓰는 일이 잦기 때문입니다.

어떻게 동작하나

과거를 고쳐 쓰는 경로가 여럿 있습니다.

수납 누락 정정   창구에서 받은 보험료가 원장에 안 실렸다가 민원 뒤 소급 입력계약 정정        가입 나이·직업·피보험자 정보를 잘못 받아 소급해서 바로잡음소급 담보        특약 개시일을 계약일로 되돌려 그 사이 사고까지 보장심사 번복        부지급했던 건이 이의에서 뒤집혀 지급으로 정정

전부 오늘 입력되지만 효력은 과거에 붙습니다. 그래서 "2026-06-30 기준" 이라는 말만으로는 답이 하나로 정해지지 않습니다. 하나가 더 필요합니다.

기준일(as-of date)      어느 날의 상태를 묻는가인지일(known-as-of)     언제까지 알게 된 사실로 계산하는가

7월 5일에 들어온 소급 정정은 6월 30일 상태를 바꿉니다. 6월 30일에 계산했을 때는 없던 사실이고, 8월 31일에 계산하면 있는 사실입니다. 기준일은 같은데 답이 다릅니다. 이렇게 시간 축을 둘 두는 설계를 이중 시간(bitemporal) 이라고 부릅니다.

그러면 무엇이 옳은 답인가. 둘 다 옳습니다. 다만 쓰임이 다릅니다.

그때 조회한 값   그날 보낸 리포트가 왜 그 숫자였는지 설명할 때지금 조회한 값   지금 무엇을 해야 하는지 정할 때

감사는 앞의 것을 묻고 운영은 뒤의 것을 씁니다. 둘을 구분하지 못하면 감사에서 설명을 못 하고, 구분만 하고 남겨 두지 않으면 설명할 근거가 없습니다.

그래서 마감 리포트는 질의가 아니라 결과를 저장합니다. 질의만 저장하면 다음에 돌릴 때 다른 답이 나오고, 그 차이가 정정 때문인지 사고 때문인지 구분할 방법이 없습니다. 기준일과 인지일을 함께 적은 스냅샷을 남기면 "그때는 이렇게 나왔다" 가 증명 가능한 사실이 됩니다.

한 가지 더. 정정 이력을 지우면 안 됩니다. 값을 덮어쓰고 옛 값을 버리는 설계는 그 순간 "그때 조회한 값" 을 영영 복원할 수 없게 만듭니다. 옛 값과 정정 시각을 남겨 두는 표 하나가 나중에 몇 달치 분쟁을 줄입니다.

현장에서 만나는 모습

첫째, 월말 대사가 매달 어긋나는 고객사에는 대개 이 문제가 깔려 있습니다. 회계는 마감 시점에 굳힌 숫자를 쓰고 원장 조회는 현재 값을 쓰는데, 그 사이에 소급 정정이 들어옵니다. 두 숫자가 다른 것은 버그가 아니라 설계이고, 고쳐야 할 것은 숫자가 아니라 "어느 시점 기준인지" 를 적지 않은 리포트입니다.

둘째, "왜 어제랑 숫자가 달라요" 라는 신고를 받으면 먼저 정정 이력을 봅니다. 데이터 건수를 다시 세거나 조인을 의심하는 것은 그 다음입니다. 순서를 바꾸면 반나절이 날아갑니다.

셋째, 리포트에 기준일만 적고 인지일을 안 적는 습관은 아무 문제 없어 보이다가 감사 때 한 번 크게 터집니다. 평소에는 아무도 안 묻기 때문에 잘못됐다는 신호가 오지 않습니다.

다음 실습에서 할 것

같은 질의를 기준일 두 개로 돌려 실효 건수가 7건에서 12건으로 늘어나는 것을 재현합니다. 그 다음 기준일을 고정한 채 인지일만 바꿔 같은 2026-06-30 의 답이 10건과 7건으로 갈리는 것을 봅니다. 차이 3건이 사고가 아니라 7월 5일에 들어온 수납 정정 때문임을 계약 번호까지 짚어 증명하고, 마지막에 재현되는 스냅샷 테이블을 만듭니다.