문서 AI의 날짜 정규화: 시간대와 마감 시각을 임의로 채우지 않기

문서에 ‘11월 1일까지’라고만 적혔는데 AI가 2026-11-01T00:00:00Z로 저장했다면, 보기 좋은 표준화가 아니라 원문에 없는 시각과 UTC 기준을 더한 것일 수 있다. 날짜만 있는 값, 시간대가 없는 현지 시각, UTC 오프셋이 있는 시각을 먼저 구별해야 한다. 변환할 근거가 없는 부분은 서버의 기본값으로 채우지 않는다.

이 글은 안내문·예약 정보·업무 문서의 날짜를 추출해 알림이나 기한 판단에 쓰는 담당자를 위한 설명이다. 아래 신청 안내와 예약 시각은 가상이며 실제 제도의 접수 조건이 아니다. 날짜 변환 산술을 로컬에서 대조했지만 운영 DB·예약 서비스·알림 시스템에 적용해 시험하지 않았다.

날짜와 한 순간을 같은 필드로 다루지 않는다

RFC 3339의 형식 정의는 날짜를 나타내는 full-date와 시각·오프셋을 포함한 date-time을 구별한다. 문서의 날짜를 읽었다고 특정 순간까지 확보한 것은 아니다. 아래 표는 이 구분을 업무 추출에 적용한 작성자의 판단표다.

원문 또는 추출값	확인한 정보	바로 하면 안 되는 처리
2026-11-01	달력상의 날짜	자정·업무 종료 시각·UTC를 임의 추가
2026-11-01 09:00	날짜와 시계 시각	근거 없이 서버 시간대로 해석해 UTC 변환
2026-11-01T00:30:00+09:00	날짜·시각·UTC와의 차이	시계 숫자는 그대로 두고 끝에 Z만 붙이기
‘11월 1일까지’	문구에 적힌 월·일과 기한 표현	연도·마감 시각·지역·포함 여부를 모두 확정

연도는 같은 문서의 제목·적용 기간에서 확인될 수 있다. 시간대도 문서가 정한 업무 기준에 있을 수 있다. 그 근거를 연결해 해석하는 것과 컴퓨터의 오늘 날짜·현재 지역을 조용히 대입하는 것은 다르다. 스키마가 문자열을 받는다는 사실만으로 이 판단은 끝나지 않는다.

가상 사례: 날짜뿐인 마감과 변환 가능한 시각

가상의 2026년 교육 안내에 ‘신청은 11월 1일까지’라고만 적혀 있다고 하자. 이 문서만으로는 오전 0시에 끝나는지, 오후 업무 시간에 끝나는지, 그날 전체를 포함하는지 확정할 수 없다. 접수 시스템이나 확인된 안내에 마감 기준이 있다면 그 근거를 연결한다. 자동 접수 여부를 가르는 데 필요한 기준이 없다면 날짜는 보존하고 그 판단을 보류한다.

같은 안내에 ‘2026년 11월 1일 00:30, UTC+09:00’이라고 명시됐다면 상황이 다르다. 이 순간은 UTC로 2026-10-31T15:30:00Z와 같다. 날짜가 전날로 바뀌어도 같은 순간이다. RFC 3339의 오프셋 설명에 따라 현지 시각에서 오프셋을 빼서 대조할 수 있다. 반대로 00:30은 유지한 채 +09:00을 Z로 바꾸면 다른 순간을 만든다.

시간대가 빠진 시각에는 확인할 조건이 남아 있다

‘오전 9시’라는 정보만으로 어느 지역의 순간인지 정할 수는 없다. 조직이 모든 예약에 특정 지역의 시간대를 적용한다고 명시했다면 그 규칙을 사용할 수 있다. 그 규칙도 없다면 문서 작성자나 예약 조건에서 확인해야 한다. 원문에 시간대가 없다는 이유로 UTC라고 선언하지 않는다.

UTC+09:00 같은 오프셋은 해당 시각과 UTC 사이의 차이를 나타낸다. 특정 지역의 향후 규칙까지 담은 이름과는 다르다. 일광절약시간제를 쓰는 지역의 향후 예약처럼 지역 규칙이 필요한 업무라면 해당 날짜와 지역을 지원하는 도구로 해석하고, 시각이 중복되거나 존재하지 않는 경우의 처리 계약도 확인한다. 한국어 문서라는 사실만으로 모든 시각을 한국 기준으로 정하지 않는다.

원문 날짜가 유효한지도 별도로 본다. 존재하지 않는 월·일을 다음 달 날짜로 자동 보정하거나, ‘03/04’를 근거 없이 월/일 순서로 확정하지 않는다. 날짜 형태를 통일하는 일과 모호한 정보를 해석하는 일을 구별하면, AI가 만들어 낸 확실성을 찾기 쉽다.

저장소가 받아 줬다는 사실도 의미 보존의 증거는 아니다

PostgreSQL 18의 timestamp 문서는 timestamp without time zone으로 정해진 값에서 시간대 표기를 무시한다고 설명한다. timestamp with time zone에는 오프셋 없는 입력을 시스템 TimeZone 기준으로 해석하는 동작이 있고, 원래 입력한 시간대는 그대로 보존하지 않는다. 이는 특정 저장소의 실제 계약 사례이며 모든 DB가 같은 방식으로 동작한다는 뜻은 아니다.

따라서 문자열 끝의 오프셋만 확인하지 말고 실제 바인딩 타입, 저장 타입과 다시 읽을 때의 표시 기준을 함께 본다. 날짜 전용 필드는 날짜로 유지하고, 순간을 담는 필드는 확인된 오프셋·지역 규칙으로 변환한다. 원문의 표현을 나중에 검토해야 한다면 필요한 원문 위치와 변환 근거도 연결한다.

작성자는 ‘원문 → 추출한 종류와 값 → 사용한 해석 규칙 → 변환 결과 → 최종 표시’를 대조할 것을 제안한다. 날짜만 있는 사례, 오프셋이 있는 사례, 없는 사례, 자정을 넘는 사례를 따로 검사하면 어느 단계가 정보를 더하거나 버렸는지 볼 수 있다. 이 글의 로컬 산술 확인이 해당 저장소의 실제 쓰기·읽기 검증을 대신하지는 않는다.

값 자체가 비어 있다면 누락과 null을 처리하는 기준으로, 번호가 변형됐다면 식별자의 타입·정밀도 보존으로 나누어 점검한다. 이미 날짜를 정확히 읽었는데 서로 다른 문서의 적용 시점이 충돌하는 문제는 문서의 적용 범위·시행일 판단과 구별한다. 기한의 표현을 정규화했다고 어떤 규정이 적용되는지까지 결정되지는 않는다.

자주 묻는 질문

모든 날짜를 UTC로 바꾸면 일관성이 생기지 않나요?

확인된 순간을 비교하는 데는 유용하다. 그러나 날짜만 있는 값에 UTC 자정을 붙이면 원문에 없던 순간을 만든다. 날짜·현지 시각·순간 중 어떤 종류인지 먼저 정하고 필요한 경우에만 변환한다.

서버가 한국에 있으니 시간대 없는 값도 한국 시각으로 보면 되나요?

서버 위치가 문서의 업무 기준을 정하지는 않는다. 문서나 서비스 계약에서 한국 시각을 명시했는지 확인한다. 서버 설정이 바뀌어도 해석이 유지돼야 하는 업무라면 적용한 기준을 명시적으로 전달한다.

UTC로 바꾼 뒤 날짜가 전날이면 오류인가요?

같은 순간의 시간대 변환이라면 정상일 수 있다. 원문 오프셋과 변환 산술을 확인하고 사용자에게 보여 줄 지역 기준도 맞춘다. 다만 생일·날짜 전용 기한처럼 애초 순간으로 정의하지 않은 값이라면 그 변환 자체가 적절했는지부터 다시 본다.