영업 메일 기한 추출 검수, ‘내일’을 어느 날짜로 저장할까
영업 메일의 ‘내일’과 ‘금요일까지’를 날짜로 저장하기 전 기준 메시지·업무 시간대·날짜와 시각의 구분을 대조합니다. 지연 수신·재처리·영업일의 확정 및 보류 조건을 인수표로 정리합니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
영업 메일 기한은 원문·기준일·시간대를 묶어 검수합니다. 2026-11-06 기준, 해석 근거가 없으면 날짜를 확정하지 않습니다.
어젯밤 작성한 “내일까지 보내주세요”가 오늘 도착했다면 어느 날이 기한일까요? AI가 날짜처럼 보이는 값을 출력해도, 수신일과 작성자가 말한 기준일이 섞이면 후속 업무의 알림이 달라집니다. 인수할 결과물은 추출된 날짜와 그 날짜를 선택한 근거입니다.
이미 확정된 기한의 변경·완료를 관리하려면 영업 메일 후속 업무 큐에서, 새 메일의 수신 여부부터 검수하려면 Gmail 수신 판정에서 확인할 수 있습니다. 이 글은 메일의 시간 표현을 확정하기 전, 기준일과 저장 타입을 정하는 단계에 집중합니다.
메일의 Date와 수신일 중 어느 것을 기준으로 삼나요?#
일괄 선택하지 않습니다. “내일”이 들어 있는 메시지와 표현의 작성 맥락을 확인하고, 합의한 업무 지역·달력 아래 기준일을 정합니다. 수신 시각이나 오늘의 처리 시각으로 원문 기준일을 자동 교체하지 않습니다.
RFC 5322 §3.6.1은 Date를 작성자가 메시지를 완성해 전송 준비가 됐다고 표시한 시각으로 설명합니다. 실제 운송 시각을 뜻하지 않습니다. 2008년 10월 발표 문서를 2026-11-06 확인했으며, 이 헤더가 업무 기한이나 작성자 신원을 인증한다는 의미로 쓰지 않습니다.
Google의 Gmail 메시지 공식 문서는 internalDate를 받은편지함 정렬에 쓰는 내부 시각으로 설명합니다. 일반 SMTP 수신에서는 Google이 처음 수락한 시각이지만, API 이관 메일은 Date를 기준으로 설정할 수 있습니다. 문서 갱신일은 2026-05-06 UTC, 확인일은 2026-11-06입니다. 이 필드의 동작을 다른 메일 서비스의 계약으로 일반화하지 않습니다.
따라서 보관할 값은 메시지의 작성 표기, 공급자가 제공한 수신 관련 시각, 처리 시각으로 나눕니다. 어느 값을 해석 기준으로 썼는지도 남깁니다. 헤더의 UTC 오프셋만 보고 상대가 원하는 업무 지역이나 휴일 달력까지 추정하지 않습니다.
같은 원문을 늦게 읽어도 기한은 같아야 하나요?#
같은 원문과 해석 정책을 다시 처리한다면 기준일도 보존해야 합니다. 원래 의미가 불명확했다면 다시 돌린 뒤에도 미확인으로 남기는 편이 맞습니다. 아래는 실제 고객 메일을 재현하지 않은 설계 예시입니다.
| 합성 입력 | 해석에 필요한 증거 | 저장 후보·판정 | 막아야 할 처리 |
|---|---|---|---|
| A. 11-05 23:50+09:00 작성, 11-06 00:10+09:00 수신. “내일까지” | 2026년, 기준 메시지 확인. 작성 기준일 11-05와 업무 지역 Asia/Seoul을 별도 합의 | 날짜 2026-11-06 후보. 확정 전 담당자 검토 | 수신일의 다음 날인 11-07로 자동 확정 |
| B. A를 11-09에 재처리 | 원래 기준 메시지·11-05 기준일·동일 정책 | A와 같은 날짜 후보 유지 | 처리일 기준 11-10으로 이동 |
| C. “2026-11-06까지” | 날짜만 제시됐고 시각·마감 지역은 미확인 | 날짜를 보존. 정확한 마감 순간과 알림 시각은 별도 확인 | 원문에 없는 자정·23:59를 확정 |
| D. “2026-11-06 17:00+09:00까지” | 현재 요청의 명시적 날짜·시각·오프셋 | 시각 후보 2026-11-06T08:00:00Z, 원문과 오프셋 함께 보존 | 날짜만 남겨 시간 정보 유실 |
| E. “금요일 오후 5시까지” | 어느 주인지·업무 지역 미확인 | 기준 주·지역 확인 대기 | 시스템의 이번 주·기본 지역을 몰래 보충 |
| F. “3영업일 이내” | 기준 사건·휴일 달력·시작일 포함 규칙 미확인 | 영업일 계산 규칙 확인 대기 | 단순히 3일을 더해 확정 |
| G. 과거 인용문에만 옛 기한, 이번 답변에는 기한 없음 | 현재 작성 부분과 인용 출처 구분 | 이번 답변의 새 기한 근거 없음 | 인용된 옛 기한을 새 확정값으로 복사 |
G의 현재 작성 부분을 고르기 전에는 메일 MIME 본문 선택도 확인합니다. 올바른 본문을 골랐더라도 인용된 문장과 현재 요청의 경계는 추가로 검수해야 합니다.
날짜만 있는 기한을 UTC 자정으로 저장해도 되나요?#
날짜와 특정 순간을 구분하는 저장 계약부터 정합니다. “2026-11-06까지”라는 표현에는 시각과 지역이 없습니다. 자정을 덧붙이면 문서에 없던 의미를 시스템이 만든 셈입니다.
RFC 3339 §5.6은 full-date와 오프셋을 포함하는 date-time의 문법을 나눕니다. 2002년 7월 발표 문서를 2026-11-06 확인했습니다. 업무 기한의 마감 규칙은 이 문법이 정하지 않으므로, 날짜만 있는 값의 처리 방식은 조직이 따로 합의해야 합니다.
아래는 날짜 후보를 남기는 자사 설계 예시입니다. 특정 제품의 기본 필드나 표준 스키마가 아닙니다. 메시지 키는 가상 값이며 원문 위치는 권한이 있는 환경에서 확인하도록 연결합니다.
{
"source_message": "sample-a",
"expression": "내일까지",
"anchor_date": "2026-11-05",
"business_zone": "Asia/Seoul",
"due_kind": "date",
"due_date": "2026-11-06",
"due_instant": null,
"decision": "review_required"
}알림은 별도 규칙으로 계산합니다. 조직이 정한 지역과 알림 시각이 확정돼야 예약할 수 있습니다. 날짜를 보존한 상태에서 알림을 계산해야, 저장 편의를 위해 추가한 시각이 고객이 요청한 마감으로 둔갑하지 않습니다.
KST 조직이라도 매번 사람이 확인해야 하나요?#
합의한 규칙과 입력 근거가 충족된 범위는 자동화할 수 있습니다. 모든 업무를 한국 달력으로 해석하기로 했다면 해당 정책과 적용 범위를 명시합니다. 메일 작성자의 기기 시간대가 곧 업무 정책이라는 가정은 피합니다.
검수에서는 A·B처럼 원문을 고정한 뒤 수신일과 재처리일만 바꿉니다. 후보 날짜가 달라지면 해석에 처리 시계가 섞였는지 확인합니다. C와 D는 날짜 타입과 시각 타입이 유지되는지, E와 F는 빈 근거를 보충하지 않고 보류하는지 대조합니다. 모델의 높은 확신도도 빠진 업무 합의를 대신하지 못합니다.
“다음 주”, “금요일”, “3영업일”의 기준은 조직 정책에 따라 달라질 수 있습니다. 기준 사건·주 시작·휴일 달력·기한 포함 여부를 정하지 않았다면 확인 대기로 남깁니다. 기한을 확정한 뒤의 변경 적용과 옛 알림 취소는 후속 업무 큐의 별도 검수 대상입니다.
인수표에는 원문 위치, 기준일 출처, 적용 정책 버전, 기대 후보, 실제 저장값과 보류 이유를 남깁니다. 공급자 이관 방식이나 조직 달력을 바꾸면 같은 표본으로 다시 확인합니다. 이 글은 오래된 메일·시각 사양을 AI 업무 자동화의 인수 조건으로 적용한 설계 제안이며, 새 모델 기능이나 납품 성과를 주장하지 않습니다.
영업 메일 기한 추출 FAQ#
Date 헤더를 읽으면 “내일”을 바로 확정할 수 있나요?
Date는 메시지 작성자가 표시한 전송 준비 시각입니다. 현재 요청이 속한 메시지인지, 기준 날짜와 업무 지역이 합의됐는지 추가로 확인합니다. 헤더만으로 기한의 해석이나 신원 확인을 끝내지 않습니다.
Gmail internalDate는 언제나 실제 수신 시각인가요?
일반 SMTP 수신과 API 이관을 구분해야 합니다. Google 문서는 일반 SMTP 수신에서는 최초 수락 시각을 쓰지만 API 이관에서는 Date 기준 설정이 가능하다고 설명합니다. 이관 시각을 원래 문의 시각이나 업무 기한으로 단정하지 않습니다.
날짜만 있는 기한에는 몇 시 알림을 걸어야 하나요?
조직이 정한 알림 정책을 따로 적용합니다. 원문에 시각이 없으면 특정 마감 순간을 확정하지 않고 날짜 타입을 보존합니다. 알림을 위한 시각과 상대가 요청한 기한을 구분해 보여줍니다.
“3영업일 이내”는 날짜에 3을 더하면 되나요?
기준 사건과 휴일 달력, 시작일을 세는 규칙을 확인해야 합니다. 정보가 없으면 계산을 보류합니다. 자연어 추출에 성공했어도 영업일 계산의 근거까지 확보된 것은 아닙니다.
메일을 재처리했더니 기한이 바뀌면 어떻게 검수하나요?
원문·기준 메시지·기준일·업무 지역·정책 버전을 먼저 대조합니다. 동일 입력과 정책인데 값이 바뀌었다면 처리일을 해석 기준으로 썼는지 확인합니다. 정책이 변경된 경우에는 재해석 사유와 전후 값을 남겨 사람이 적용 범위를 확인합니다.
기한 해석 인수표 협의#
알파카랩스는 AX 서비스에서 업무 진단과 시스템 구축·운영을 연결하는 제공 방식을 설명합니다. 이는 자사 공개 설명이며 이 글의 기한 검수 기능을 이미 납품했다는 주장은 아닙니다. 비식별 메일 표현과 합의한 기준일·업무 달력 규칙을 주시면 확정·보류 조건과 재처리 기대값을 적은 인수표 초안을 협의합니다. 소요 시간은 자료와 범위를 확인한 뒤 정합니다.