차량 상태 동기화: Push, WebSocket과 Polling을 함께 쓰는 이유

모바일 앱2026년 8월 14일글: 홍서진, Duolabs9분 읽기2023 automotive blog connected-car model-openai-gpt-5 portfolio realtime-sync technical-note websocket

커넥티드 카 앱의 차량 상태는 한 번 조회하고 끝나는 데이터가 아닙니다. 도어, 공조, 충전과 차량 온라인 상태는 앱 밖에서도 계속 바뀝니다. 사용자가 원격 명령을 실행하는 동안에도 이전 상태 이벤트와 새로운 조회 응답이 다른 순서로 도착할 수 있습니다.

실시간 화면을 안정적으로 만들려면 Push, WebSocket과 Polling 중 하나를 고르는 것보다 각 수단의 역할을 분리해야 합니다. 이벤트는 변화를 알려 주고, 상태 조회는 현재 값을 확인하며, 로컬 캐시는 화면의 연속성을 유지합니다.

명령 결과와 차량 상태는 다른 데이터입니다

도어 잠금 명령이 성공했다는 응답과 현재 도어 상태가 잠김이라는 정보는 같지 않습니다. 명령 결과는 특정 요청의 처리 결과이고, 차량 상태는 특정 시점에 관측된 값입니다.

명령 결과
commandId = 81
status = SUCCEEDED

차량 상태
doorLock = LOCKED
observedAt = ...

명령 성공만 보고 화면의 차량 상태를 영구적으로 바꾸면 이후 상태 조회와 충돌할 수 있습니다. 성공 응답 뒤 최신 차량 상태를 확인하거나, 해당 명령 이후에 관측된 상태 이벤트를 기다려 최종 화면을 갱신하는 편이 안전합니다.

앱은 두 데이터를 별도 모델로 관리하고 화면에서만 조합해야 합니다. 그래야 명령은 성공했지만 상태 확인이 늦는 상황을 완료, 확인 중처럼 구분할 수 있습니다.

Push는 변경 신호로 사용합니다

Push 알림은 앱이 백그라운드이거나 실시간 연결이 없는 상태에서도 차량 이벤트를 전달할 수 있습니다. 하지만 도착 시간과 순서가 항상 보장되는 상태 스트림은 아닙니다.

알림 본문에 포함된 상태를 그대로 최종값으로 저장하기보다, 어떤 차량의 어떤 영역이 변경됐는지 알려 주는 무효화 신호로 사용할 수 있습니다. 앱이 활성 상태라면 관련 상태를 서버에서 다시 조회합니다.

Push 수신
  ↓
차량 상태 캐시를 갱신 필요로 표시
  ↓
앱 활성화 또는 화면 진입
  ↓
최신 상태 조회

사용자에게 즉시 보여 줄 메시지가 필요하다면 Push의 표시 내용과 내부 동기화 정보를 분리합니다. 민감한 차량 상태를 잠금 화면 알림에 과도하게 노출하지 않도록 주의해야 합니다.

WebSocket은 화면이 열려 있을 때 빠른 변화를 전달합니다

앱이 포그라운드에 있고 차량 제어 화면을 보고 있다면 WebSocket으로 상태 변경 이벤트를 받을 수 있습니다. 폴링 간격을 기다리지 않고 명령 진행 상태와 차량 이벤트를 갱신할 수 있다는 장점이 있습니다.

연결되었다는 사실만으로 이벤트가 모두 도착했다고 가정해서는 안 됩니다. Wi-Fi와 셀룰러 전환, 앱 백그라운드 이동과 서버 재시작으로 연결이 끊길 수 있습니다. 재연결 직전의 이벤트가 누락될 가능성도 있습니다.

WebSocket 이벤트에는 순서 번호나 버전, 발생 시각과 관측 시각을 포함하는 편이 좋습니다. 앱은 마지막으로 반영한 버전을 저장하고, 재연결할 때 그 이후 이벤트를 요청하거나 최신 상태 전체를 다시 조회합니다.

Polling은 실시간 연결의 보정 장치입니다

Polling은 단순하지만 항상 느린 방식은 아닙니다. 화면 진입, 사용자의 새로고침, 명령 완료 직후와 재연결 시점에 사용하면 실시간 이벤트가 놓친 상태를 보정할 수 있습니다.

고정된 짧은 간격으로 모든 차량 상태를 계속 조회하면 서버와 차량 통신 경로에 불필요한 부하가 생깁니다. 상태의 성격에 따라 갱신 주기를 나누는 편이 좋습니다.

명령 진행 상태는 완료될 때까지 비교적 자주 확인합니다.
차량의 일반 상태는 화면이 보일 때 주기적으로 확인합니다.
앱이 백그라운드라면 주기 조회를 중단하고 Push를 기다립니다.
차량이 오프라인이면 간격을 늘리고 마지막 정상 상태를 유지합니다.

재시도에는 상한과 지수 백오프를 적용합니다. 사용자가 화면을 떠난 뒤에도 타이머가 남지 않도록 구독과 폴링의 생명 주기를 같은 소유자가 관리해야 합니다.

상태에는 값과 기준 시점이 함께 있어야 합니다

LOCKED라는 값만으로는 새로운 정보인지 판단할 수 없습니다. 각 상태에는 서버 버전, 차량에서 관측한 시각과 서버가 수신한 시각 중 가능한 기준을 함께 저장해야 합니다.

vehicleId
stateVersion
observedAt
receivedAt
source
payload

늦게 도착한 이벤트의 버전이 현재 캐시보다 낮다면 적용하지 않습니다. 여러 상태 영역이 독립적으로 갱신된다면 차량 전체에 하나의 버전을 쓰는 대신 도어, 공조와 충전처럼 영역별 버전을 둘 수 있습니다.

시각만으로 순서를 판단할 때는 차량과 서버의 시계 차이를 고려해야 합니다. 가능하면 서버가 부여한 단조 증가 버전이나 이벤트 순서를 우선하고, 시각은 사용자 표시와 진단 정보로 사용합니다.

부분 상태와 전체 상태를 구분합니다

WebSocket이나 Push 이벤트는 바뀐 필드만 전달할 수 있습니다. 이를 전체 상태처럼 저장하면 이벤트에 없던 값이 사라질 수 있습니다.

부분 이벤트는 기존 캐시에 병합하고, 전체 조회 응답은 기준 버전에 맞춰 캐시를 교체합니다. 병합할 때는 필드별 버전이나 이벤트 버전을 확인해야 합니다.

기존 상태
doorLock = UNLOCKED
climate = OFF

부분 이벤트
doorLock = LOCKED

병합 결과
doorLock = LOCKED
climate = OFF

알 수 없음과 꺼짐도 분리해야 합니다. 조회하지 못한 공조 상태를 OFF로 표시하면 실제 차량 상태와 다른 정보를 만들 수 있습니다. 값이 없거나 오래됐다면 확인할 수 없음과 마지막 확인 시각을 보여 주는 편이 정확합니다.

차량 온라인 상태는 마지막 통신 시각으로 판단합니다

WebSocket이 연결돼 있다고 차량까지 온라인인 것은 아닙니다. 앱은 서버와 연결돼 있어도 차량 통신 장치는 절전 또는 통신 불가 상태일 수 있습니다.

차량 온라인 여부는 차량에서 전달된 Heartbeat, 마지막 상태 보고와 통신 정책을 기준으로 계산해야 합니다. 일정 시간이 지났다고 즉시 오프라인으로 바꾸기보다 상태의 신뢰 구간을 둘 수 있습니다.

ONLINE       최근 통신 확인
STALE        갱신 기준을 넘겼지만 단절은 확정하지 못함
OFFLINE      통신 계층에서 단절 확인
UNKNOWN      판단할 정보가 없음

마지막으로 확인된 상태를 보여 줄 때는 현재 상태처럼 표현하지 않고 확인 시각을 함께 표시합니다. 사용자는 차량이 오프라인이어도 마지막 도어 상태를 참고할 수 있지만, 최신 정보라고 오해해서는 안 됩니다.

네트워크 전환 뒤에는 기준 상태부터 복구합니다

실시간 연결이 끊어지면 앱이 놓친 이벤트의 범위를 정확히 알기 어렵습니다. 재연결 직후에는 로컬 캐시를 그대로 최신 상태로 간주하지 않고 다음 순서로 복구할 수 있습니다.

서버 연결과 사용자 권한을 다시 확인합니다.
진행 중인 원격 명령을 조회합니다.
차량 상태의 최신 버전을 가져옵니다.
실시간 이벤트 구독을 시작합니다.
조회와 구독 사이의 버전 공백을 확인합니다.

구독을 먼저 시작한 뒤 전체 상태를 조회하는 방법도 있습니다. 이 경우 조회 중 도착한 이벤트를 버퍼링하고 버전 순서에 맞춰 적용해야 합니다. 어느 순서를 선택하든 조회와 구독 사이의 빈 구간을 처리하는 규칙이 필요합니다.

화면은 낙관적 상태와 확인된 상태를 구분합니다

사용자가 도어 잠금 버튼을 누른 직후 화면을 잠김으로 바꾸면 반응은 빠르게 느껴집니다. 하지만 차량 명령이 실패하면 다시 원래 상태로 되돌려야 하고, 그 사이 사용자는 실제 상태를 오해할 수 있습니다.

차량 제어에서는 버튼의 진행 상태를 즉시 바꾸되 차량 상태는 확인 전까지 별도로 표시하는 방식이 안전합니다.

도어 상태: 잠금 해제
명령 상태: 잠그는 중

차량의 최신 상태가 확인되면 도어 상태를 갱신하고 명령 진행 표시를 끝냅니다. 실패하거나 만료됐다면 기존 차량 상태를 유지하면서 실패 원인을 설명합니다.

실시간성보다 상태의 출처를 명확히 합니다

Push는 백그라운드에서 변화를 알리고, WebSocket은 열린 화면에 이벤트를 빠르게 전달하며, Polling은 기준 상태를 다시 확인합니다. 어느 하나도 단독으로 모든 모바일 환경을 처리하기는 어렵습니다.

안정적인 동기화의 기준은 가장 빨리 도착한 값을 쓰는 것이 아닙니다. 차량 상태와 명령 결과를 분리하고, 버전과 관측 시각을 비교하며, 재연결할 때 기준 상태를 복구해야 합니다. 화면에는 현재 값뿐 아니라 그 값이 언제 어디서 확인됐는지도 함께 전달해야 합니다.