7.1 개요와 사용 기준

시간이 붙은 데이터라고 모두 같은 테이블에 저장할 필요는 없습니다. 주기적으로 측정한 온도와 “장치가 재접속했다”는 이벤트는 분석 방법이 다르기 때문입니다. LOG를 선택할 때는 시간 컬럼의 유무보다 한 행이 무엇을 나타내는지부터 생각해 보세요.

LOG 테이블의 특성

애플리케이션 오류, 보안 장비의 차단 기록, 작업 시작·종료 이력처럼 사건을 하나씩 추가하는 데이터에 LOG가 적합합니다. 사용자 컬럼 외에 _arrival_time이 자동으로 생기며, 시간 범위 조건과 메시지 검색을 함께 사용할 수 있습니다.

다음 예제로 이벤트 발생 시각과 입력 시각의 차이를 확인해 보겠습니다.

CREATE LOG TABLE ch7_overview (
    event_time DATETIME,
    device     VARCHAR(32),
    message    VARCHAR(128)
);

INSERT INTO ch7_overview VALUES (
    TO_DATE('2026-01-01 10:00:00', 'YYYY-MM-DD HH24:MI:SS'),
    'DEV-01', 'connection restored'
);

SELECT _arrival_time, event_time, device, message FROM ch7_overview;

DROP TABLE ch7_overview;

한 행이 조회됩니다. event_time은 예제에 넣은 고정 시각이고, _arrival_time은 이번 입력에서 자동으로 정해진 시각입니다. 따라서 실행 날짜가 달라도 event_time은 바뀌지 않습니다. 명시 입력과 보정 규칙은 시간 모델에서 다룹니다.

사용 기준

“지난 한 시간의 오류”, “이 IP 주소가 보낸 요청”, “timeout이 들어간 메시지”를 자주 찾고, 저장한 행을 수정할 필요가 없다면 LOG부터 검토하세요. 지속 입력에는 Append API를, 초기 데이터나 파일 묶음에는 적재 도구를 사용할 수 있습니다.

입력 후 수정할 수 없다는 이유만으로 감사 데이터의 위변조 방지가 보장되지는 않습니다. 삭제 권한, 접근 통제, 보존 정책과 백업은 별도로 설계해야 합니다.

실수하기 쉬운 부분은 재전송입니다. 같은 이벤트를 다시 보내면 또 다른 행으로 저장될 수 있습니다. LOG에는 PRIMARY KEY·UNIQUE 제약이 없으므로 자동 중복 제거를 기대하면 안 됩니다. 원본 이벤트 ID를 보관하고 수집 단계에서 재시도와 중복 처리 정책을 정하세요.

다른 테이블과의 비교

LOG는 일반 UPDATE와 임의 조건 DELETE WHERE를 지원하지 않습니다. 정정 이벤트를 새로 추가하는 설계는 가능하지만, 원본 ID와 정정 사유를 저장하고 조회 시 어떤 정정을 반영할지 애플리케이션에서 정해야 합니다. 수정이 일상적인 업무라면 처음부터 다른 테이블을 사용하는 편이 명확합니다.

설계 기준

분석에 필요한 시간이 발생 시각인지 수집 시각인지 먼저 구분합니다. 이어서 장치·등급·IP처럼 자주 사용하는 조건을 정하세요. 이런 값은 원문에서 매번 잘라내기보다 별도 컬럼으로 두어야 쿼리를 이해하고 관리하기 좋습니다. 보관 기간도 이때 정해 두세요. 입력 경로만 준비하고 삭제를 미루면 디스크 사용량은 계속 증가합니다.

다음 스키마 설계에서는 이 질문을 실제 컬럼으로 옮겨 봅니다. 선택이 애매할 때는 대표 이벤트 몇 건과 자주 사용할 쿼리를 나란히 놓고 비교해 보세요.