커넥티드 카 원격 명령: 요청부터 차량 응답까지의 상태 관리

커넥티드 카 앱에서 도어 잠금이나 공조 시작 버튼을 누르면 요청은 여러 시스템을 통과합니다. 앱이 서버 요청에 성공했다고 차량 기능까지 실행된 것은 아닙니다. 명령이 차량에 도착하고 제어 장치가 결과를 반환해야 비로소 실행 여부를 판단할 수 있습니다.

원격 제어를 안정적으로 보여 주려면 하나의 API 응답보다 명령의 전체 수명 주기를 관리해야 합니다. 앱, 서버와 차량이 서로 다른 시점에 온라인이 될 수 있기 때문입니다.

원격 명령은 긴 비동기 작업입니다

일반적인 원격 명령 경로는 다음처럼 나눌 수 있습니다.

모바일 앱
  ↓ 명령 요청
서비스 API
  ↓ 인증과 권한 확인
명령 처리 계층
  ↓ 차량 통신 경로
차량 통신 장치
  ↓ 제어 요청
차량 기능
  ↑ 실행 결과

앱과 API 사이의 HTTP 연결은 앞부분만 담당합니다. API가 200 또는 202를 반환해도 차량이 지하 주차장에 있거나 절전 상태라면 실제 실행은 늦어질 수 있습니다.

따라서 최초 응답에는 완료 여부 대신 명령 ID와 접수 상태를 반환하는 편이 자연스럽습니다. 앱은 이 ID로 이후 상태를 조회하거나 서버가 보내는 변경 이벤트와 연결합니다.

명령 상태를 한 단어로 줄이지 않습니다

화면에서 진행 중 하나만 사용하더라도 내부 상태는 더 구체적이어야 합니다.

CREATED
  ↓
ACCEPTED
  ↓
DELIVERED
  ↓
EXECUTING
  ↓
SUCCEEDED

정상 흐름 밖에는 REJECTED, FAILED, EXPIRED, CANCELED 같은 종료 상태가 필요합니다. 차량에 전달되기 전에 거절된 명령과 차량에서 실행하다 실패한 명령은 재시도 가능 여부가 다릅니다.

상태 전이는 앞쪽으로 되돌아가지 않도록 관리해야 합니다. 네트워크 지연으로 DELIVERED 이벤트가 SUCCEEDED 뒤에 도착해도 완료 화면을 다시 진행 중으로 바꾸면 안 됩니다. 상태 순서와 이벤트 버전을 함께 확인하는 이유입니다.

명령 ID와 멱등성 키는 역할이 다릅니다

명령 ID는 생성된 작업을 추적하는 식별자입니다. 멱등성 키는 사용자의 같은 동작이 여러 번 도착해도 명령을 하나만 만들기 위한 값입니다.

사용자가 버튼을 두 번 누르거나, 모바일 네트워크가 끊겨 앱이 같은 요청을 다시 전송할 수 있습니다. 서버가 매번 새 명령을 만들면 잠금과 잠금 해제가 예상하지 못한 순서로 실행될 수 있습니다.

앱은 한 번의 사용자 의도에 멱등성 키를 만들고 재시도할 때 같은 값을 사용합니다. 서버는 계정, 차량, 명령 종류와 키를 기준으로 기존 결과를 반환합니다. 새로운 사용자 동작에는 새로운 키가 필요합니다.

같은 사용자 동작의 네트워크 재시도
  같은 멱등성 키 → 기존 명령 반환

사용자가 다시 누른 별도 동작
  새로운 멱등성 키 → 새 명령 생성

키의 보관 기간은 차량이 늦게 응답할 수 있는 시간보다 짧아서는 안 됩니다. 그렇다고 영구 보관할 필요는 없습니다. 명령 만료 정책과 함께 관리하면 됩니다.

타임아웃은 실패가 아니라 관측 종료일 수 있습니다

앱이 기다리는 시간, 서버가 차량 응답을 기다리는 시간과 명령 자체의 유효 시간은 서로 다릅니다. 이 세 시간을 하나의 타임아웃 값으로 처리하면 늦게 도착한 성공 응답을 잘못된 실패로 표시할 수 있습니다.

• 앱 대기 시간: 현재 화면에서 실시간으로 기다릴 시간
• 전송 대기 시간: 차량 통신 경로에서 전달을 시도할 시간
• 명령 유효 시간: 차량이 명령을 실행해도 되는 마지막 시각

앱 대기 시간이 끝나도 명령은 서버에서 계속 진행될 수 있습니다. 이 경우 실패보다 응답 지연으로 표시하고 명령 ID를 저장해야 합니다. 앱이 다시 열리면 서버에서 최종 상태를 확인합니다.

명령 유효 시간이 지난 뒤 차량이 온라인으로 돌아왔다면 실행해서는 안 됩니다. 오래된 공조 시작이나 도어 제어가 뒤늦게 수행될 수 있기 때문입니다. 서버와 차량 양쪽에서 만료 시각을 검증하는 편이 안전합니다.

재시도 주체를 하나로 정합니다

모바일 앱, API 게이트웨이, 명령 처리 계층과 차량 통신 계층이 모두 독립적으로 재시도하면 실제 전송 횟수를 예측하기 어렵습니다. 명령 생성 재시도와 동일 명령 전달 재시도를 구분해야 합니다.

앱은 같은 멱등성 키로 접수 여부만 확인합니다. 서버의 명령 처리 계층은 동일한 명령 ID를 유지한 채 차량 전달을 재시도합니다. 차량은 이미 처리한 명령 ID를 기억하고 중복 실행을 막습니다.

재시도 간격은 즉시 반복하기보다 점차 늘리고 전체 만료 시간을 넘지 않아야 합니다. 인증 실패, 권한 없음과 지원하지 않는 명령은 기다려도 해결되지 않으므로 재시도 대상에서 제외합니다.

한 차량의 충돌하는 명령을 직렬화합니다

동일한 차량에 잠금과 잠금 해제, 공조 시작과 종료가 거의 동시에 도착할 수 있습니다. 네트워크 도착 순서만으로 실행하면 사용자가 마지막으로 선택한 상태와 결과가 달라질 수 있습니다.

차량별 명령 큐를 사용하거나 기능 그룹별로 동시에 실행할 수 있는 명령을 정의해야 합니다. 새 명령이 이전 명령을 취소할 수 있는지, 반드시 순서대로 실행해야 하는지도 명확해야 합니다.

예를 들어 같은 도어 상태를 요구하는 중복 명령은 하나로 합칠 수 있습니다. 반대 상태를 요구하는 명령은 기존 명령이 차량에 전달됐는지에 따라 취소하거나 뒤에 배치해야 합니다. 이 판단은 앱 화면이 아니라 서버의 일관된 정책에서 수행하는 편이 좋습니다.

성공 응답 뒤에도 차량 상태를 확인합니다

명령 성공은 제어 장치가 요청을 처리했다는 뜻일 수 있습니다. 사용자가 보고 싶은 것은 실제 도어가 잠겼는지, 공조가 켜졌는지와 같은 차량 상태입니다.

서버는 명령 결과와 차량 상태 이벤트를 구분해 저장해야 합니다. 명령이 성공한 뒤 최신 상태를 조회하거나 후속 상태 이벤트가 도착했을 때 화면을 갱신합니다.

CommandResult: SUCCEEDED
VehicleState: doorLock = LOCKED

두 정보가 일치하지 않으면 성공으로 단정하기보다 상태 확인 중으로 둘 수 있습니다. 센서 조건이나 차량 내부 정책 때문에 명령 접수와 실제 상태 반영 사이에 차이가 생길 수 있습니다.

앱을 다시 열어도 진행 상태가 이어져야 합니다

원격 명령 중에 앱이 백그라운드로 가거나 종료될 수 있습니다. 진행 상태를 화면 메모리에만 두면 사용자가 돌아왔을 때 명령이 사라지고 같은 버튼을 다시 누르게 됩니다.

앱에는 최소한 차량 식별자, 명령 ID, 멱등성 키, 요청 시각과 마지막으로 확인한 상태를 저장합니다. 재실행 시 종료되지 않은 명령을 서버에서 조회하고 현재 상태와 합칩니다.

Push 알림은 완료를 알려 주는 수단으로 사용할 수 있지만 유일한 근거로 삼아서는 안 됩니다. 알림이 늦거나 도착하지 않을 수 있으므로 화면 진입 시 서버 상태를 다시 확인해야 합니다.

보안 검증은 명령 생성과 실행 시점에 필요합니다

원격 제어는 조회 API보다 강한 권한을 사용합니다. 서버는 사용자 인증뿐 아니라 해당 차량과 기능에 대한 권한, 명령의 유효 시간과 재전송 여부를 검증해야 합니다.

차량 통신 경로에서도 명령 출처와 무결성을 확인하고 오래된 요청을 거부해야 합니다. 로그에는 명령 ID, 상태 전이와 오류 원인을 남기되 인증 토큰과 민감한 차량 정보를 기록하지 않습니다.

사용자 인증이 명령 대기 중에 만료될 수 있다는 점도 고려해야 합니다. 이미 승인된 명령을 계속 실행할지 취소할지는 명령 종류와 정책으로 정하고, 결과 조회 권한은 현재 세션에서 다시 검사해야 합니다.

API 응답과 차량 결과를 분리합니다

커넥티드 카 원격 제어는 짧은 HTTP 요청으로 시작하지만 긴 비동기 작업으로 끝납니다. 명령 ID, 멱등성 키, 만료 시각과 상태 전이를 중심으로 설계하면 네트워크 재시도와 앱 재실행에도 같은 작업을 이어서 추적할 수 있습니다.

가장 중요한 구분은 접수와 실행입니다. 앱이 요청을 보냈다는 사실, 서버가 명령을 받아들였다는 사실과 차량이 실제로 상태를 바꿨다는 사실을 각각 표현해야 원격 제어 결과를 정확하게 보여 줄 수 있습니다.