SCM 일별 집계 검수: 시간대와 마감 경계

SCM 일별 집계는 기준 시각·시간대·마감 경계를 고정해 검수합니다. 2026-11-01 기준, 오프셋 없는 값은 합의 없이 변환하지 않습니다.

같은 주문이 채널에서는 전날, 통합 화면에서는 오늘로 보이는 상황을 가정해 보겠습니다. 시간을 UTC로 저장했더라도 어느 하루에 넣을지는 업무 규칙에 달려 있습니다. 이 글은 실제 고객 장애 사례가 아닌 설계 예시로, 일별 집계의 포함 구간을 확인하는 인수표를 제안합니다.

같은 하루를 비교하려면 무엇부터 정해야 하나요?#

기준 사건·업무 시간대·시작과 종료 경계를 한 묶음으로 정합니다. 주문 생성 시각과 출고 완료 시각은 서로 다른 지표를 만듭니다. 수신 시각이나 화면 조회 시각을 대신 넣으면 지연 수신 때문에 날짜가 바뀔 수 있습니다.

먼저 원천 필드가 주문 발생 시각인지, 주문일이라는 날짜 값인지 확인하세요. 다음으로 업무 책임자가 사용할 지역과 마감 시각을 정합니다. 그 정의를 고정한 뒤 집계와 상세 목록의 읽기 범위를 확인하는 절차는 SCM 조회 일관성 검수에서 이어집니다.

원천의 시각과 날짜를 어떻게 구별하나요?#

오프셋이 있는 시각, 지역만 약속된 현지 시각, 날짜 전용 값을 구별해 읽습니다. 오프셋은 특정 시각에서 UTC와의 차이를 나타냅니다. 지역의 시간대는 날짜에 따라 달라지는 규칙까지 다룰 수 있습니다.

PostgreSQL 18의 날짜·시간 타입 공식 문서에 따르면 timestamp without time zone으로 결정된 값은 입력의 시간대 표시를 무시합니다. timestamptz는 시각을 UTC로 저장하지만 원래 시간대를 보존하지 않으며, 출력은 세션 시간대의 영향을 받습니다. 고정 18 문서의 게시일은 미표기이며 2026-11-01 확인했습니다. 이 설명은 해당 DB의 의미에 한정합니다.

따라서 원문 값·원천 필드 의미·적용한 지역·정규화한 시각·업무일을 대조할 수 있어야 합니다. 증거의 보관 범위와 접근 권한은 별도로 정하고, 개인정보가 든 전체 응답을 검수표에 복제하지 않습니다.

마감 경계에 걸린 주문은 어느 날에 넣나요?#

시작을 포함하고 종료를 제외하는 구간으로 경계 표본을 대조합니다. 아래에서는 2026-11-01 업무일을 Asia/Seoul의 04:00부터 다음날 04:00 직전까지로 정했습니다. 04시는 설명을 위한 가상 정책이며 고객의 운영 조건이나 업계 표준이 아닙니다.

이 예시의 UTC 구간은 2026-10-31 19:00 이상, 2026-11-01 19:00 미만입니다. 끝 시각을 양쪽 업무일에서 모두 포함하면 동일 주문을 겹쳐 넣게 됩니다. 초 단위 표본은 경계를 보여 주기 위한 것이며 실제 원천 정밀도에서도 바로 전·경계 값·바로 다음을 검사하세요.

마지막 표본은 한국시간이라는 계약이 확인되면 시작 경계로 판정할 수 있습니다. 같은 문자열을 일단 서버 기본 시간대로 읽고 나중에 화면만 한국시간으로 바꾸는 처리는 이 확인을 대신하지 못합니다.

개발사에 어떤 인수표와 조회 조건을 전달하나요?#

표본 식별자별로 원천 해석·포함 판정·화면 표기를 함께 받습니다. 시각을 비교할 수 있다는 판정과 업무일이 맞다는 판정을 나눠야 원인을 좁힐 수 있습니다. 정상값과 보류값 모두 기대 동작을 적으세요.

다음 SQL은 occurred_at이 timestamptz인 가상 조회 사본의 읽기 조건입니다. PostgreSQL 18의 AT TIME ZONE 공식 정의를 바탕으로 경계의 지역을 명시했습니다. 문서 게시일은 미표기이며 2026-11-01 확인했습니다. 이 글에서 SQL 엔진으로 실행한 결과는 아니므로 실제 타입·드라이버·세션 설정에서 별도 검수해야 합니다.

SELECT event_id, occurred_at
FROM event_snapshot
WHERE occurred_at >= (
  timestamp '2026-11-01 04:00:00'
  AT TIME ZONE 'Asia/Seoul'
)
AND occurred_at < (
  timestamp '2026-11-02 04:00:00'
  AT TIME ZONE 'Asia/Seoul'
);

하루의 시작과 다음날의 시작을 각각 지역 규칙으로 구합니다. 서버의 날짜 문자열을 잘라 비교하거나 세션 기본값에 맡기는 대신, 실제로 선택된 식별자 집합이 인수표와 같은지 확인하세요.

한국시간으로 통일해도 남는 실패 조건은 무엇인가요?#

해외 업무일은 해당 지역의 규칙을 확인해야 합니다. IETF가 2024년 4월 발표한 RFC 9557의 시간대·오프셋 정의는 둘을 구별하고, 지역 시각이 서머타임 변경 등으로 존재하지 않거나 중복될 수 있음을 설명합니다. 2026-11-01 확인했습니다. 고정 오프셋으로 하루를 더하는 방식은 지역의 다음 업무일 계산을 대신할 수 없습니다. 새벽 경계가 모호한 지역의 거부·선택 규칙도 합의하세요.

날짜가 맞아도 주문일·출고일·정산일은 서로 다른 기준입니다. 늦게 도착한 사건을 확정값에 반영할 권한과 정정 이력이 없으면 시간 변환을 고쳐도 운영 인수는 끝나지 않습니다. 과거에 유효했던 상태를 조회하는 문제는 업무 시점과 시스템 이력 검수로 구분해 확인하세요.

알파카랩스는 공개 SCM 운영대시보드 개발 서비스에서 원천별 지표·기준일·갱신 시각과 표본 대사 조건을 협의한다고 설명합니다. 자사 제공 범위에 관한 자기표기이며 이 글의 시간대 정책을 고객 시스템에 구현했다는 실적은 아닙니다. 기존 보고서 설정으로 해결되는지도 먼저 비교하고, 원장 수정·정산 확정은 별도 범위로 정합니다. 공개 페이지는 2026-11-01 확인했습니다.

SCM 일별 집계 검수 FAQ#

업무일 경계 인수표를 먼저 채우세요#

비식별 원천 값과 기준 사건, 업무 시간대, 시작·종료 경계, 미확인 값의 처리 방식을 적으세요. 경계 전후의 기대 판정과 실제 식별자 목록을 대조하면 개발 범위와 남은 확인 항목을 정리할 수 있습니다. 자료 확인과 상담에 필요한 시간은 원천 계약의 준비 정도에 따라 협의합니다.