"이 고객의 대출을 6월에 왜 승인했나"라는 질문에 현재 신용등급만 조회하면 당시 결정을 잘못 설명할 수 있다. 6월에는 등급 A였고 8월에 D로 바뀌었는데 최신 값만 남아 있다면, 에이전트는 오늘의 정보로 과거를 판단하게 된다. 과거 결정을 설명하려면 당시 유효했던 값과 시스템이 그 값을 알게 된 시점을 함께 조회할 수 있어야 한다.
현재 값만 저장하면 과거 상태를 잃는다
온톨로지는 개체 해소, 행동 정의, 시맨틱 레이어를 통해 엔터티와 업무 규칙을 연결한다. 하지만 속성을 현재 값 하나로만 저장하고 새 값으로 덮어쓰면 과거 상태는 남지 않는다.
현재 상태를 보여주는 대시보드에는 단일 값으로 충분할 수 있다. 그러나 과거 결정을 설명하거나 뒤늦게 도착한 정보로 이전 판단을 재검토하려면 시점 질의가 필요하다. 당시 값이 저장돼 있지 않으면 에이전트도 현재 정보만으로 답할 수밖에 없다.
시간은 하나가 아니다: 유효시간과 시스템시간
변경 이력만 쌓아도 이전 값은 볼 수 있다. 하지만 소급 정정이 있는 업무에서는 사실이 현실에서 유효했던 시간과 시스템이 그 사실을 알게 된 시간을 나눠야 한다. 데이터베이스 이론에서는 이를 다음 두 축으로 구분한다.
- 유효시간(valid time): 그 사실이 현실에서 참인 기간. “이 고객은 6/1~7/31에 등급 A였다.”
- 시스템시간(transaction time): 데이터베이스가 그 사실을 알게 된 시점. “우리가 이 등급을 8/15에 기록했다.”
정보가 늦게 도착하거나 과거 시점으로 정정되면 두 시간이 달라진다. 8월에 받은 정정이 5월부터 유효했다면 유효시간은 5월, 시스템이 기록한 시간은 8월이다. 두 축을 함께 저장하는 방식을 이분시간(bitemporal) 모델이라고 한다.
XTDB의 시간 모델은 두 시간축을 함께 관리하는 구현 사례다. 다른 데이터베이스에서도 이력 테이블과 유효 기간을 직접 설계할 수 있다. 제품마다 제공 범위가 다르므로 필요한 조회와 감사 요건을 먼저 정해야 한다.
과거 상태를 저장하지 않았을 때 생기는 문제
현재 상태만 남은 온톨로지에서는 다음 세 가지 문제가 생길 수 있다.
첫째, 당시 결정을 정확히 설명하기 어렵다. 현재 값으로 과거를 평가하면 그때 이용할 수 있었던 정보가 무엇인지 구분되지 않는다.
둘째, 소급 정정과 당시 기록을 함께 보존하기 어렵다. 새 사실로 덮어쓰기만 하면 정정 전 시스템이 어떤 값을 알고 있었는지 잃는다.
셋째, 과거 실행을 재현하기 어렵다. 해당 시점의 데이터와 규칙을 복원할 수 있어야 에이전트의 판단을 다시 확인할 수 있다.
현재 값과 이력을 따로 관리하면 현재 상태를 빠르게 조회하면서 과거 변경도 보존할 수 있다. 모든 속성에 같은 구조를 적용하기보다 과거 판단을 설명하는 데 필요한 값부터 이력을 남긴다.
필요한 시간 정보부터 정한다
작은 팀에서는 다음 세 가지를 먼저 확인할 수 있다.
- 덮어쓰지 말고 버전으로 쌓아라. 핵심 엔티티의 속성은 단일 값 대신 시점이 붙은 이력으로 저장하라. 과거 값을 지운 뒤 정확히 복원하기는 어려우므로 처음부터 변경 이력을 남기는 편이 낫다.
- 정정이 잦은 도메인에선 두 축을 다 남겨라. 금융·의료·공급망처럼 소급 정정이 일상인 곳이라면 유효시간만으론 부족하다. "언제 참이었나"와 "언제 알았나"를 분리해 저장해야 소급 기입과 감사가 동시에 성립한다.
- 시점 조회를 기본 기능으로 제공하라. 에이전트가 "6월 1일 기준 이 고객 상태"를 조회할 수 있어야 과거 결정의 입력을 재현하고 설명할 수 있다.
회사 데이터는 늦게 도착하거나 과거 시점으로 소급해 정정되기도 한다. 현재 상태만 저장하면 에이전트는 당시 알려진 정보와 나중에 확인된 사실을 구분할 수 없다. 유효시간과 시스템시간을 필요한 범위에서 관리하면 과거 결정을 재현하고, 정정된 사실을 반영하면서도 당시 판단 근거를 보존할 수 있다.