온톨로지 시점 조회: 적용일과 기록일이 다른 데이터를 검수하는 법

2026년 10월 기준, 과거를 묻는 AI는 업무 적용일과 시스템이 알게 된 시점을 나눠야 합니다. 변경 이력이 없으면 당시 조회 근거를 복원할 수 없습니다.

지난달 조직도를 다시 조회했는데 지난달에 받은 답과 다릅니다. 데이터가 틀렸다고 단정하기 전에 질문을 나눠야 합니다. 지금 정정된 정보로 지난달의 소속을 묻는 것인지, 지난달 당시 알려져 있던 소속을 묻는 것인지에 따라 답이 달라질 수 있기 때문입니다.

ERP의 조직·거래처·계약 관계를 온톨로지와 AI에 연결하는 담당자라면 이 구분을 검수 조건에 넣을 수 있습니다. 이 글은 과거 관계를 읽는 제안 설계입니다. 아래 직원·조직·날짜는 모두 설명용 가상 자료이며 실제 고객의 인사 기록이 아닙니다.

같은 10월 3일의 소속인데 왜 답이 달라지나요?#

업무에서 유효한 시점과 그 사실이 기록된 시점이 다르기 때문입니다. 가상 직원 E의 소속이 10월 1일부터 나팀으로 바뀌었지만, 원천 시스템에는 10월 5일에 소급 등록됐다고 해보겠습니다. 정정 전 기록에는 가팀 소속과 종료일 미정이 남아 있었고, AI에도 그 정정 전 버전이 전달돼 있었다고 가정합니다.

정정된 원천 버전은 AI 조회 저장소에 10월 7일에 도착합니다. 예시의 업무 적용은 2026년 10월 1일 0시부터이며, 나머지 조회·등록·수신 시점은 해당 날짜의 한국시간 정오로 가정합니다. 목표 날짜는 모든 행에서 10월 3일로 같습니다. 이 표에서는 수신한 버전이 같은 시점에 조회·검색에도 반영되는 것으로 가정합니다.

표는 위 가정이 모두 충족될 때의 기대값입니다. 가팀이라는 당시 기록을 나팀으로 덮어쓰기만 하면 정정된 업무 관계는 조회할 수 있어도, 당시 시스템이 무엇을 알고 있었는지는 구별하기 어렵습니다. 반대로 정정 전 기록만 고집하면 현재 정정된 과거 관계를 놓칩니다.

적용일·기록일·수신일은 각각 어디에 쓰나요?#

적용일은 업무 관계를 고르고, 기록일은 특정 시스템의 지식 상태를 고릅니다. AI에 복제하는 구조라면 수신 시점도 따로 남겨야 합니다. 이름이 같은 변경일 필드 하나에 이 역할을 모두 맡기지 마세요.

수신됐어도 색인 반영 전이라면 검색에서는 이전 버전이 보일 수 있습니다. 이때 수신 시각만으로 AI가 읽을 수 있던 자료를 단정하지 않습니다. 원천에서 삭제되거나 관계가 끊긴 변경도 전파 이력에 남아야 합니다. 근거 연결 방식은 AI 답변 출처 추적과 함께 검토할 수 있습니다.

시점 조회 요청에는 무엇을 명시해야 하나요?#

대상 개체와 관계, 업무 기준 시점, 지식 기준 시점, 기준 시스템을 함께 지정합니다. 예를 들어 “원천 시스템에 10월 6일까지 기록된 정보로, 10월 3일 직원 E의 소속을 알려달라”는 요청입니다. 당시 AI가 받은 답의 근거를 찾는 요청이라면 기준 시스템도 AI 조회 저장소로 바뀝니다.

구현에서는 업무 기간과 기록 기간을 분리하고 원천 버전을 연결하는 방식을 검토할 수 있습니다. 결과에는 소속만 반환하지 않고 적용한 두 기준 시점·기준 시스템·원천 버전·누락 여부를 붙입니다. 기준이 불명확한 질문은 기본값을 조용히 채우기보다 사용자가 선택한 조회 모드를 보여주는 편이 검수하기 쉽습니다.

Microsoft의 SQL Server temporal tables 공식 문서는 현재 테이블과 이력 테이블로 시스템 버전을 관리하는 방식을 설명합니다. 엔진이 관리하는 시스템 기간의 시각은 트랜잭션 시작의 UTC 값입니다. 이를 사용자가 입력한 업무 적용일이나 커밋 완료 시각으로 해석하면 안 됩니다. 업무 적용 기간은 별도로 설계해야 합니다.

PostgreSQL 18의 range types 공식 문서는 날짜·시각의 범위와 경계 포함 여부, 겹침을 다룹니다. 이 글에서는 적용 시작을 포함하고 종료를 제외하는 구간을 설계 예시로 사용합니다. 모든 시스템에 강제되는 규칙은 아닙니다. 두 문서의 확인일은 2026년 10월 23일이며, 이력 조회 자체를 새로 등장한 기술로 소개하는 것은 아닙니다.

같은 개체의 같은 단일 소속 관계에 기간이 겹치거나 비어 있다면, 모델이 임의로 하나를 고르지 않게 해야 합니다. 겸직처럼 복수 소속이 허용되는 관계는 별도 규칙을 둡니다. 스키마 구조를 바꾸고 복원하는 문제는 온톨로지 스키마 버전 관리의 범위이며, 여기서는 정해진 구조 안에서 읽을 관계의 시점을 정합니다.

어떤 표본을 통과해야 시점 조회를 인수할 수 있나요?#

소급 정정 전후와 기간 경계, 이력 누락, 전파 지연을 나눠 검수합니다. 각 표본에 입력 시점과 기대 관계, 근거 버전을 먼저 적으세요. 모델이 자연스러운 문장으로 답했는지가 아니라 지정한 기준으로 관계를 골랐는지를 확인합니다.

표는 2026년 10월 기준의 제안 검수안입니다. 현재 값만 저장된 원천에서 당시 값을 추정해 정답으로 채우면 이 검수의 목적이 사라집니다. 정정된 과거와 당시 지식이 우연히 같은 표본만 쓰지 말고, 둘이 달라지는 표본을 포함해야 합니다.

이력을 남기면 과거 AI 답변도 그대로 재현되나요?#

데이터 이력만으로 동일한 AI 문장까지 재현되지는 않습니다. 당시 검색 대상과 권한, 모델·프롬프트·도구 설정이 달랐을 수 있습니다. 먼저 당시 답변의 조회 근거를 복원할지, 실행 전체를 추적할지 목표를 나눠야 합니다. 기록이 없으면 미확인이라고 남깁니다.

모든 데이터에 복잡한 이력 모델을 붙일 필요도 없습니다. 현재 상태만 설명하는 업무라면 최신성·출처·권한 검수부터 시작할 수 있습니다. 과거 기준의 관계가 판단을 바꾸는 업무부터 적용 기간과 정정 이력을 남기세요. 계약 단가를 전표에 고정하고 나중에 정산하는 흐름은 구매 단가 적용일과 정산 설계에서 별도로 다룹니다.

과거 관계는 현재의 조회 권한을 우회하는 통로가 아닙니다. 보존·삭제 정책과 현재 요청자의 권한을 먼저 적용하고, 당시 권한을 감사할 목적의 조회는 별도 허용 범위를 정합니다. 캐시도 업무 시점·지식 시점·원천 버전·권한 범위를 구별하지 못하면 다른 기준의 답을 재사용할 수 있습니다.

알파카랩스와는 어떤 구축 범위를 확인하나요?#

알파카랩스는 공개 온톨로지 서비스에서 업무 개념과 관계, 원천 매핑, 출처·권한·검수, AI 연동과 운영 인수 범위를 함께 설계한다고 안내합니다. Ontokit 소개도 원천 시스템을 유지하며 개체·관계와 근거를 연결하는 방식을 설명합니다. 이는 자사 제공 범위에 관한 안내입니다.

이 글의 시점 조회가 Ontokit의 기본 제공 기능이거나 이미 수행한 고객 성과라는 뜻은 아닙니다. 실제 범위는 과거 기준으로 답해야 할 질문, 남아 있는 원천 이력, AI 수신 구조, 권한과 검수 표본을 확인한 뒤 정합니다. 비교표는 바로 참고할 수 있으며 별도 구축 산출물·비용·일정은 원천 확인 후 협의합니다.

온톨로지 시점 조회에서 자주 묻는 질문#

업무 적용일과 시스템 기록일은 어떻게 다른가요?

업무 적용일은 소속이나 계약 조건이 실제 업무에서 유효해지는 시점입니다. 기록일은 특정 시스템이 그 사실을 저장한 시점입니다. 소급 정정이 있으면 두 시점이 달라집니다. 과거 상태를 묻는 요청에는 어느 시스템의 기록을 기준으로 삼는지도 지정해야 합니다.

SQL Server temporal table이면 업무 적용일도 자동 관리되나요?

시스템 버전 관리의 기간과 업무 적용 기간은 구별해야 합니다. SQL Server의 시스템 기간은 엔진이 관리하며 트랜잭션 시작 시각의 UTC 값을 사용합니다. 업무 적용일이 과거이거나 미래라면 별도 업무 필드와 조회 조건을 설계해야 합니다.

원천 시스템의 이력만 있으면 당시 AI 답변을 재현할 수 있나요?

원천 이력만으로는 부족합니다. AI가 당시 수신한 버전과 검색 대상, 권한, 모델·프롬프트·도구 설정 등이 달랐을 수 있습니다. 당시 조회 근거의 복원과 동일한 문장의 재생성은 별도 목표이며, 남지 않은 기록은 미확인으로 처리합니다.

최신 데이터만 쓰는 AI에도 시점 조회가 필요한가요?

현재 상태만 설명하고 과거 결정을 재검토하지 않는다면 복잡한 시점 조회가 필요하지 않을 수 있습니다. 소급 정정이나 늦은 수신으로 답이 바뀌는 업무인지 먼저 확인하고, 필요한 관계와 기간부터 이력을 남깁니다.

과거에 접근할 수 있었던 자료는 지금도 조회해도 되나요?

과거 관계를 조회한다는 이유로 현재 권한을 우회하면 안 됩니다. 현재 조회자의 권한과 보존·삭제 정책을 먼저 적용합니다. 당시 권한 상태를 감사할 목적이라면 별도 권한과 목적 범위를 정해야 합니다.