PIT와 PET로 설계하는 시간 기준 데이터 관리

기록된 시점과 유효한 시점은 다르다

데이터 이력을 다룰 때는 두 가지 시간을 구분해야 한다. 하나는 시스템이 해당 데이터를 언제 기록했는지이고, 다른 하나는 그 데이터가 실제 업무에서 언제 효력을 가지는지다. PIT(Point-In-Time)와 PET(Point-of-Effective-Time)는 이 차이를 모델에 반영하는 방법이다.

PIT는 특정 시점에 데이터베이스가 어떤 상태였는지를 조회하거나 복원하는 관점이다. 시스템 시간, 즉 데이터가 기록된 시간을 기준으로 변경 이력을 따라간다. 장애 복구뿐 아니라 감사와 사고 조사에서도 특정 시점의 상태를 확인하는 데 쓰인다.

PET는 데이터의 업무상 유효 기간을 나타낸다. 시작일(Start Date)과 종료일(End Date)로 데이터가 언제부터 언제까지 적용되는지를 관리하므로, 정책 변경이나 미래 시점의 계획 데이터를 다루기에 적합하다.

시간 축에 따라 달라지는 질문

PIT는 “그때 시스템에는 무엇이 저장돼 있었는가”에 답한다. 로그, 트랜잭션 기록, 스냅샷을 통해 시스템 관리, 감사, 백업 및 복구에 활용한다.

PET가 답하는 질문은 “그 날짜에 이 정보가 실제로 유효했는가”다. 유효 시작일과 종료일을 이용해 비즈니스 규칙 적용, 정책 변경 관리, 미래 데이터 계획을 처리한다.

예를 들어 은행 시스템은 매일 자정 자동 백업을 수행해 장애가 발생했을 때 특정 시점으로 복구할 수 있다. 오전 10시 30분에 발생한 오류 이전의 상태로 복원하는 작업은 PIT의 활용 사례다. 금융 감독 기관이 3개월 전 특정 일자의 거래 내역을 요청했을 때도 당시 데이터 상태를 조회해야 한다.

반대로 통신 요금제는 고객 A가 2023년 1월 1일부터 기본 요금제를 사용하다가 2023년 6월 1일부터 프리미엄 요금제를 적용받았다는 이력을 보관해야 한다. 보험 상품의 약관이 2022년 7월 1일부터 2023년 6월 30일까지 유효하고 이후 새 약관으로 바뀌는 경우도 PET로 관리할 수 있다. 직원 B가 2022년 4월 1일부터 대리, 2023년 4월 1일부터 과장으로 승진한 이력 역시 같은 방식이다.

두 시간 축을 한 모델에 담는 방법

시간 차원 데이터 모델은 유효 기간과 시스템 기록 기간을 별도 필드로 둔다. valid_from, valid_to는 PET를, system_from, system_to는 PIT를 표현한다.

⤢✕

이 구조에서는 한 직원의 직급·급여가 업무상 언제 유효했는지와, 그 정보가 시스템에 언제 등록·변경됐는지를 함께 추적할 수 있다.

시스템 기록 시점을 조회하는 PIT

PIT 구현에서는 변경 이력을 별도 테이블에 남기고, 기존 레코드의 종료 시각과 새 레코드의 시작 시각을 기록한다. 아래 예시는 특정 시스템 시점의 직원 데이터를 조회하는 방식이다.

-- 테이블 생성 (시스템 시간 기록 포함)
CREATE TABLE employee_history (
    employee_id INT,
    name VARCHAR(100),
    position VARCHAR(50),
    salary DECIMAL(10,2),
    system_from TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    system_to TIMESTAMP DEFAULT '9999-12-31 23:59:59'
);

-- 데이터 변경 시 트리거
CREATE TRIGGER employee_update_trigger
BEFORE UPDATE ON employee
FOR EACH ROW
BEGIN
    -- 기존 레코드 종료
    UPDATE employee_history
    SET system_to = CURRENT_TIMESTAMP
    WHERE employee_id = OLD.employee_id AND system_to = '9999-12-31 23:59:59';

    -- 새 레코드 삽입
    INSERT INTO employee_history (employee_id, name, position, salary, system_from)
    VALUES (NEW.employee_id, NEW.name, NEW.position, NEW.salary, CURRENT_TIMESTAMP);
END;

-- 특정 시점의 데이터 조회
SELECT * FROM employee_history
WHERE employee_id = 101
AND '2023-05-15 14:30:00' BETWEEN system_from AND system_to;

업무상 유효 기간을 다루는 PET

PET는 계약, 약관, 요금제처럼 미래 날짜를 포함하는 데이터를 저장할 수 있어야 한다. 유효 기간만으로 특정 업무일의 상태를 조회할 수 있고, 시스템 기록 시각 조건까지 더하면 PIT와 PET를 동시에 적용할 수 있다.

-- 테이블 생성 (비즈니스 유효 기간 포함)
CREATE TABLE employee_contracts (
    employee_id INT,
    position VARCHAR(50),
    salary DECIMAL(10,2),
    valid_from DATE,
    valid_to DATE DEFAULT '9999-12-31',
    system_from TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    system_to TIMESTAMP DEFAULT '9999-12-31 23:59:59'
);

-- 새로운 계약 정보 삽입 (미래 날짜 포함 가능)
INSERT INTO employee_contracts (employee_id, position, salary, valid_from)
VALUES (101, '과장', 5000000, '2023-07-01');

-- 특정 비즈니스 날짜 기준 유효한 데이터 조회
SELECT * FROM employee_contracts
WHERE employee_id = 101
AND '2023-08-15' BETWEEN valid_from AND valid_to;

-- 특정 시점에 시스템에 기록된, 특정 비즈니스 날짜에 유효한 데이터 조회 (PIT + PET)
SELECT * FROM employee_contracts
WHERE employee_id = 101
AND '2023-08-15' BETWEEN valid_from AND valid_to
AND '2023-06-01 00:00:00' BETWEEN system_from AND system_to;

분석과 이력 관리에서의 역할

데이터 웨어하우스와 비즈니스 인텔리전스에서도 두 시간 축은 분명한 역할을 가진다. Slowly Changing Dimension(SCD)에서 Type 2 SCD는 유효 시작일과 종료일을 사용해 PET 형태의 이력을 관리한다. Type 4 SCD는 히스토리 테이블을 별도로 운영해 PIT 관점의 기록을 보관한다.

데이터 마트에서는 특정 시점 기준의 스냅샷을 만들고, 시간 경과에 따른 비즈니스 지표 변화를 분석할 수 있다. 시스템 시간과 비즈니스 시간이 어긋나는 데이터를 탐지하거나 소급 적용된 데이터를 식별하는 일도 시간 정보를 분리해 두었을 때 가능하다.

이력 테이블을 운영할 때 남는 과제

시간 이력을 추가하면 저장해야 할 데이터가 늘어난다. 시간 조건이 복잡해질수록 쿼리 성능도 영향을 받을 수 있으므로, 시간 관련 필드의 인덱스와 복합 인덱스에 시간 필드를 포함할지 검토해야 한다.

트랜잭션 처리 시스템과 분석 시스템을 분리할지, CDC(Change Data Capture) 도구를 어떻게 활용할지도 아키텍처 설계의 일부다. 이력 보존 기간을 정하고 과거 데이터 접근 권한을 제한하는 정책 역시 데이터 거버넌스 범위에서 결정해야 한다.

PIT는 시스템이 기억하는 시간을, PET는 업무가 인정하는 시간을 관리한다. 두 관점을 함께 설계하면 데이터 이력, 감사 요구사항, 복구, 비즈니스 규칙 변경을 하나의 시간 모델 안에서 다룰 수 있다.