같은 측정 기록, 다른 시각: UTC와 지역 시각을 구분하는 방법
의료기기 소프트웨어의 화면과 서버 기록을 비교할 때 필요한 UTC 오프셋, 날짜 경계, 시각 필드의 의미를 가상 사례로 설명합니다.
표시된 시각만으로 기록의 선후를 판단할 수 없습니다
측정 화면에는 오전 9시, 서버 기록에는 오전 0시가 표시되어 있어도 두 값이 같은 순간을 나타낼 수 있습니다.
서로 다른 기준으로 표시한 시각을 그대로 비교하면 정상적인 기록을 전송 지연이나 시간 오류로 해석할 수 있습니다.
의료기기 소프트웨어의 데이터 연동을 검토할 때는 먼저 두 필드가 어떤 사건의 시각인지 정하고, 날짜와 UTC 오프셋을 포함해 비교하는 편이 명확합니다.
이 글은 측정 기록의 표시와 교환 형식을 설명합니다.
아래 검토 절차는 MedQraft의 실무 제안이며 특정 제품의 법정 저장 형식을 지정하는 내용은 아닙니다.
UTC 오프셋을 적용하면 같은 순간인지 계산할 수 있습니다
UTC는 시각을 비교할 때 사용하는 공통 기준입니다.
UTC 오프셋은 표시한 지역 시각과 UTC 사이의 차이를 뜻합니다. +09:00이면 지역 시각이 UTC보다 9시간 앞서므로, 해당 시각에서 9시간을 빼면 UTC가 됩니다.
RFC 3339는 인터넷에서 교환하는 타임스탬프의 형식과 이 계산 관계를 설명합니다.[1]
가상 시험 기록 하나를 두 방식으로 표시하면 다음과 같습니다.
| 표시 기준 | 같은 기록의 타임스탬프 |
|---|---|
| UTC보다 9시간 앞선 지역 시각 | 2026-10-04T09:00:00+09:00 |
| UTC | 2026-10-04T00:00:00Z |
두 값의 시간 차이는 9시간이 아니라 0입니다.
지역 시각에서 오프셋을 적용해 같은 기준으로 환산한 결과입니다. Z는 UTC 시각을 나타내는 표기에 쓰입니다.
다만 Z만으로 기록이 생성된 장소나 그 장소의 지역 시간대를 알 수는 없습니다.
이 구분은 RFC 3339를 갱신한 RFC 9557의 설명에도 반영되어 있습니다.[2]
본문의 가상 기록을 시간대별로 표현한 그림입니다.
자정 부근에서는 날짜도 함께 바뀝니다
시간만 환산하고 날짜를 그대로 두면 하루 차이의 오류가 생길 수 있습니다.
같은 가상 시험에서 측정 시각을 지역 시각 10월 4일 00시 30분으로 바꾸면, UTC 값은 전날인 10월 3일 15시 30분이 됩니다.
지역 날짜로 집계한 하루와 UTC 날짜로 집계한 하루는 서로 다른 구간이 될 수 있습니다.
이 차이는 일별 측정 건수나 시험 결과를 모을 때도 영향을 줍니다.
화면의 ‘10월 4일’ 목록과 서버의 ‘10월 4일’ 조회를 대조하려면 두 기능의 하루 시작과 끝이 같은 기준인지 먼저 정해야 합니다.
이 예에서 지역 시각 기준 10월 4일 하루는 UTC로 10월 3일 15시부터 10월 4일 15시 직전까지입니다.
조회 조건을 시작 이상, 다음 날 시작 미만으로 정의하면 경계 시점의 중복 포함을 피하기 쉽습니다.
측정 시각과 수신 시각은 서로 다른 필드입니다
시간대 변환이 맞더라도 다른 사건을 기록한 값끼리는 일치하지 않을 수 있습니다.
예를 들어 장비가 측정값을 만든 순간과 서버가 그 값을 받은 순간은 구분해 읽어야 합니다.
필드명이 모두 ‘시간’이면 시험 담당자는 차이의 의미를 판단하기 어렵습니다.
개발팀과 시험팀이 사용할 필드 정의에는 사건의 의미, 시각의 출처, 교환 형식, 화면 표시 기준을 함께 적는 방식을 제안합니다.
다음 표는 제품에 맞게 조정할 수 있는 자체 예시입니다.
| 필드 | 기록하려는 사건 | 검토할 사항 |
|---|---|---|
| measured_at | 측정값 생성 | 장비가 부여하는지, 측정 시작·종료 중 어느 시점인지 |
| received_at | 서버 수신 | 서버가 부여하는지, 재전송 때 새로 기록하는지 |
| 화면의 측정 시각 | measured_at의 표시 | 적용 시간대, 날짜, 초 이하 자릿수 |
두 장비의 시계가 서로 맞지 않으면 오프셋을 바르게 처리해도 사건의 실제 선후를 정확히 복원하지 못할 수 있습니다.
수신 시각과 측정 시각의 차이를 곧바로 통신 지연으로 해석하려면 시계 동기화와 각 필드의 생성 시점도 검토해야 합니다.
필요한 시계 정확도와 허용 차이는 제품의 용도와 해당 기능에 맞게 정합니다.
두 필드를 같은 시간대로 표시하는 작업과, 두 사건 사이의 차이를 해석하는 작업은 구분합니다.
시험은 같은 기록의 저장·조회·표시를 이어서 확인합니다
시험용 기록에 고유한 식별자를 부여하고 입력 타임스탬프, 서버 조회 값, 화면 표시 값을 나란히 남기면 변환이 일어나는 지점을 찾기 쉽습니다.
같은 순간을 다른 오프셋으로 입력했을 때 비교 결과가 같은지, 자정 전후 기록이 의도한 날짜 목록에 포함되는지를 별도 사례로 구성합니다.
| 자체 시험 예시 | 기대하는 판단 |
|---|---|
| 2026-10-04T09:00:00+09:00와 2026-10-04T00:00:00Z | 동일 시점으로 비교됨 |
| 2026-10-04T00:30:00+09:00 | UTC 환산 결과가 2026-10-03T15:30:00Z임 |
| 오프셋 없는 2026-10-04T09:00:00 | 정해 둔 입력 규칙에 따라 거부하거나 별도로 해석하며, 근거 없이 UTC로 간주하지 않음 |
| 같은 기록을 다른 시간대 설정의 화면에서 조회 | 표시 시각이 바뀌더라도 동일한 사건을 가리킴 |
숫자 오프셋은 그 시점의 차이를 나타냅니다.
일광절약시간제가 적용되는 지역의 ‘매일 오전 9시’처럼 지역 일정 자체가 중요하다면, 현재 오프셋 하나를 고정해 쓰는 방식으로 충분한지 검토해야 합니다.
지역 시간대에는 날짜별 규칙이 포함되며 오프셋과 역할이 다릅니다.[2] 이 글의 고정된 +09:00 예시를 모든 지역의 일정 계산에 그대로 적용해서는 안 됩니다.
기록 검토에 남길 질문
현재 인터페이스에서 ‘측정 시각’이 어느 사건을 가리키는지, 오프셋이 없는 입력을 어떻게 처리하는지, 날짜별 조회에 어떤 시간대를 적용하는지가 분명해야 합니다.
세 가지 중 하나라도 개발·시험·운영 담당자가 다르게 해석한다면 해당 필드 정의를 먼저 맞추는 것이 좋습니다.
이후 자정 경계의 시험 기록 하나를 저장부터 화면까지 추적하면 서로 다른 해석이 실제 결과에 미치는 영향을 확인할 수 있습니다.
출처와 관련 글
확인일: 2026년 10월 4일.
표와 그림은 MedQraft가 만든 가상 사례이며 실제 장비의 측정 데이터가 아닙니다.
- [1] IETF RFC 3339, Date and Time on the Internet: Timestamps, 2002. §4.2 오프셋 계산, §5.6 형식, §5.8 예시.
- [2] IETF RFC 9557, Timestamps with Additional Information, 2024. §1.1 시간대와 오프셋의 정의, §2.2 RFC 3339의 Z 표기 의미 갱신.
- 의료기기 소프트웨어 요구사항과 시험 근거: 시각 처리 규칙을 시험 가능한 요구사항으로 연결할 때 함께 읽을 글입니다.
- 규제 판단을 소프트웨어로 옮기는 방식: 규칙과 데이터의 구조를 다룬 관련 글입니다.