애플리케이션에서의 시계 동기화 — 본질, 프로토콜 및 구현

시계 동기화란?

시계 동기화(Clock Sync)는 장치의 내부 시계를 기준 UTC 시간(협정 세계시)에 맞추는 메커니즘입니다. 동기화가 없으면 모바일 장치의 수정 발진기가 점차 표류합니다. 온도와 부품 품질에 따라 하루에 1~10초의 표류가 발생합니다. 동기화는 인터넷의 NTP 서버, GPS 위성 또는 셀 타워와 같은 외부 소스에서 정확한 시간을 얻어 이 표류를 보상합니다. 이상적으로 장치는 1초 이내의 정확도를 유지하기 위해 4~6시간마다 동기화해야 합니다.

하드웨어 및 소프트웨어 시계

모바일 장치에는 두 가지 유형의 시계가 있습니다. 하드웨어(RTC, 실시간 시계)는 별도의 배터리 백업이 있어 장치가 꺼져도 계속 작동하며, 소프트웨어(시스템 시간)는 운영 체제에서 관리합니다. 부팅 시 시스템 시간은 RTC에서 초기화된 다음 클록 생성기 인터럽트를 통해 유지됩니다. NTP 동기화는 시스템 시간을 수정하고 경우에 따라 RTC에도 보정을 기록합니다. Android에서는 하드웨어 RTC에 대한 액세스가 제한되어 있어 루트 액세스 없이는 앱이 수정할 수 없습니다.

모바일 앱에서 시간 동기화가 필요한 이유

모바일 애플리케이션 작동의 많은 측면이 정확한 시스템 시간에 크게 의존합니다. SSL 인증서에는 유효 기간이 있습니다. 장치 시간이 인증서 발급일보다 빠르거나 만료일보다 늦게 설정된 경우 HTTPS 연결이 차단됩니다. OAuth 토큰 및 JWT 인증은 만료 확인을 위해 타임스탬프를 사용합니다. 비동기화는 잘못된 권한 부여 실패로 이어집니다. 푸시 알림은 시간에 따라 예약되며 시계가 표류하면 사용자가 잘못된 시간에 알림을 받거나 전혀 받지 못합니다.

비동기화의 결과

애플리케이션 보안도 잘못된 시간으로 인해 영향을 받습니다. 시간 기반 암호화(시간 기반 OTP), 잘못된 타임스탬프의 이벤트 로그, 서버 측의 잘못된 속도 제한(서버가 “미래” 요청을 차단) 등이 있습니다. OWASP Mobile Top 10(2024)에 따르면 시스템 시간에 대한 불신은 불충분한 플랫폼 보안 범주에 속합니다. 개발자는 클라이언트 시계에만 의존하지 않고 항상 서버에서 시간을 확인하는 것이 좋습니다. 차이가 임계값(5초 권장)을 초과하면 애플리케이션은 동기화가 될 때까지 중요 작업을 차단해야 합니다.

동기화 프로토콜: NTP와 SNTP

시계 동기화의 주요 프로토콜은 NTP와 그 단순화된 버전 SNTP입니다. NTP(RFC 5905)는 서버 필터링, 표류 분석 및 PLL 보정을 갖춘 완전한 프로토콜입니다. 서버 및 네트워크 장비에서 사용됩니다. SNTP(RFC 4330)는 지속적인 동기화가 필요하지 않은 클라이언트 장치용 경량 버전입니다. SNTP 클라이언트는 요청을 보내고 응답을 받은 후 기록 분석 없이 시간을 설정합니다. 모바일 장치에서는 특히 SNTP가 사용됩니다. Android의 내장 Google Time Service(GTS)는 time.google.com 서버와 SNTP를 통해 동기화됩니다.

추가 동기화 방법

NTP/SNTP 외에도 모바일 장치의 시간 동기화는 GPS 수신기(이상적인 조건에서 최대 10ns 정확도) 및 셀룰러 네트워크(NITZ — 네트워크 식별 및 시간대를 통해)를 통해 가능합니다. GPS는 최대 정확도를 제공하지만 야외에서만 작동하고 많은 전력을 소비합니다. NITZ는 네트워크 등록 시 이동통신사에서 자동으로 제공되지만 모든 통신사가 지원하는 것은 아닙니다. Android는 모든 방법을 조합하여 사용합니다. 우선적으로 GTS(SNTP), 백업으로 NITZ, 높은 정확도가 필요한 애플리케이션에는 GPS를 사용합니다.

분산 시스템의 동기화 문제

서버와 클라이언트가 다른 장치에 있는 분산 시스템에서 시계 동기화는 근본적인 제한에 직면합니다. 네트워크 지연으로 인해 클라이언트의 정확한 시간을 명확하게 결정할 수 없습니다. 패킷에 200ms가 걸린 경우 요청 시와 응답 시의 서버 시간이 이미 다릅니다. NTP는 RTT 측정 및 통계 처리를 통해 이 문제를 해결하지만 분산 트랜잭션(예: 은행 송금)에는 충분하지 않으며 논리 시계(Lamport 타임스탬프) 또는 벡터 시계가 사용됩니다.

물리적 시계 대 논리적 시계

물리적 시계(벽시계)는 NTP를 통해 동기화되는 실제 UTC 시간입니다. 논리적 시계는 시스템 내 이벤트의 순서 번호로, 물리적 시간에 묶이지 않습니다. 분산 시스템에서는 이벤트 순서 지정을 위해 벡터 시계가 자주 사용됩니다. 각 노드는 모든 클러스터 노드에 대한 카운터 벡터를 저장합니다. 모바일 애플리케이션의 경우 1~5초 정확도의 물리적 동기화로 충분합니다. 이는 OAuth, SSL 및 푸시 알림의 올바른 작동을 보장합니다. 엄격한 이벤트 순서 지정이 필요한 경우(예: 실시간 채팅) 서버 수준에서 논리적 동기화가 추가됩니다.

Android에서 Clock Sync 구현

Android 애플리케이션에서 시계 동기화를 구현하는 방법은 여러 가지가 있습니다. 가장 간단한 방법은 REST API를 통해 서버 시간을 가져오는 것입니다. 서버는 응답 본문 또는 HTTP Date 헤더에 Unix 타임스탬프를 반환합니다. 이 방법은 추가 라이브러리가 필요 없으며 시간이 서버와 일치함을 보장합니다. 두 번째 방법은 SNTP 클라이언트를 사용하여 NTP 서버에 직접 쿼리하는 것입니다. 세 번째는 장치가 인터넷에 연결된 경우 시스템 시간을 자동으로 동기화하는 Android Google Time Service에 의존하는 것입니다.

Android 접근 방식 비교

인증 및 금융 거래가 포함된 Android 애플리케이션에서는 결합된 접근 방식이 권장됩니다. 각 API 요청마다 서버 시간과 System.currentTimeMillis()의 차이가 저장됩니다. 이 차이는 시스템 시계가 동기화되었는지 여부에 관계없이 클라이언트의 모든 시간 계산에 적용됩니다. 이 접근 방식을 클록 스큐 보정(clock skew correction)이라고 하며 서버와의 마지막 알려진 차이를 저장하는 클래스를 통해 구현됩니다. 또한 WorkManager를 통해 4~6시간마다 백그라운드 NTP 동기화를 실행할 수 있습니다.

// 클록 스큐 보정
class ClockSyncManager {
    private var serverTimeDiff: Long = 0 // serverTime - deviceTime (ms)

    fun updateServerTime(serverTimestampMs: Long) {
        serverTimeDiff = serverTimestampMs - System.currentTimeMillis()
    }

    fun getCorrectedTime(): Long {
        return System.currentTimeMillis() + serverTimeDiff
    }

    fun isSyncValid(maxDiffMs: Long = 5000): Boolean {
        return Math.abs(serverTimeDiff) < maxDiffMs
    }
}

WorkManager를 통한 백그라운드 동기화

Android에서 정기적인 백그라운드 시간 동기화를 위해 PeriodicWorkRequest와 함께 WorkManager를 사용합니다. 동기화 작업은 SNTP 요청 또는 REST API 호출을 수행하고 서버 시간을 가져와 ClockSyncManager를 업데이트합니다. PeriodicWorkRequest의 최소 간격은 15분이지만 시간 동기화에는 4~6시간이면 충분합니다. 동기화 시 네트워크 상태를 고려하고 로밍 중 불필요한 요청을 방지하기 위해 NetworkType.CONNECTED를 사용합니다. 동기화에 실패하면 이전 보정을 저장합니다. 점차 정확도가 감소하지만 유효합니다.

장치의 자동 시간 동기화

최신 모바일 장치는 내장 서비스를 통해 자동으로 시간을 동기화합니다. Android에서는 Google Play Services의 일부인 Google Time Service(GTS)입니다. iOS에서는 운영 체제에 내장된 NTP 클라이언트입니다. 이러한 서비스는 애플리케이션과 독립적으로 작동하며 추가 구성이 필요하지 않습니다. 사용자는 설정에서 자동 동기화를 비활성화할 수 있으며, 이는 애플리케이션에 위험을 초래합니다. 바로 이때 개발자가 자체 동기화를 구현해야 합니다. Settings.Global.getInt(AUTO_TIME)를 통해 자동 동기화 상태를 확인하고 비활성화된 경우 사용자에게 경고하는 것이 좋습니다.

개발자를 위한 권장 사항

자동 동기화에만 의존하는 것은 위험합니다. 사용자가 비활성화하거나 인터넷이 없는 지역에 있을 수 있습니다. 최선의 방법은 각 API 요청마다 서버에서 시간을 가져오고 SharedPreferences 또는 DataStore에 비동기화를 저장하는 것입니다. 중요 작업(결제, 인증, 문서 서명)의 경우 실행 전에 항상 isSyncValid()를 확인합니다. 비동기화가 임계값을 초과하면 사용자에게 자동 동기화를 활성화하거나 동기화를 기다리도록 제안하는 화면을 표시합니다. 게임 및 엔터테인먼트 앱의 경우 시작 시 서버에서 시간을 가져와 한 시간에 한 번 업데이트하는 것으로 충분합니다.