커넥터만 꽂으면 충전이 끝난다 — 바로차징을 만든 이야기

표준은 ‘커넥터만 꽂으면 인증·결제가 끝난다’고 약속합니다. 하지만 도로 위의 차들은 그 약속을 저마다 다르게 지킵니다. 이 글은 ISO 15118이라는 표준과, 그것을 다 따르지 못하는 현실의 차량들 사이를 메워 ‘진짜로 되는’ 바로차징을 만든 이야기입니다.

ISO 15118과 Plug & Charge — 표준이 그린 그림

기존 충전에서 ‘인증’은 회원카드를 태깅하거나 앱에서 시작 버튼을 누르는 일이었습니다. 바로차징(Plug & Charge, PnC)은 이 과정을 통째로 없앱니다. 사용자는 커넥터를 꽂기만 하고, 나머지는 차와 충전기, 서버가 알아서 끝냅니다.

이걸 가능하게 하는 국제 표준이 ISO 15118입니다. 차량 안의 통신 제어기(EVCC)와 충전기 쪽 제어기(SECC)가 커넥터의 전력선(PLC)으로 대화하고, 세션을 여는 SessionSetup 단계에서 차량이 자기 식별자인 EVCC ID를 넘깁니다. 다만 표준이 ‘권장하는’ 신원 인증은 여기서 한 걸음 더 나아갑니다 — 차량이 계약 인증서(contract certificate)를 PKI 체계 위에서 제시해 자기 신원을 암호학적으로 증명하는 방식입니다. 즉 EVCC ID는 ‘누구인지’를 가리키는 식별자일 뿐, 그 자체가 보안 자격증명은 아닙니다.

문제는 이 PKI 인증서 생태계 — 인증서 발급·신뢰 체계와 차량·인프라의 광범위한 지원 — 가 아직 대중화되지 않았다는 데 있습니다. 그래서 현실에서는 EVCC ID를 식별자로 삼아 자동 인증하는 ‘오토차징’ 방식이 과도기 표준처럼 쓰입니다. 바로차징도 지금은 이 EVCC-ID 기반 오토차징으로 동작하되, ISO 15118 인증서 처리 경로도 함께 갖춰 PKI 기반 인증이 무르익는 시점을 대비했습니다. 그리고 ‘식별자 기반’이라는 과도기의 빈틈은, 뒤에서 이야기할 보완 장치(암호화된 차량 데이터 연동 · 이상 탐지 · 폴백)로 메웁니다.

ISO 15118 Plug & Charge의 표준 흐름. 차량(EVCC)과 충전기(SECC)가 전력선으로 대화하고 SessionSetup에서 EVCC ID가 넘어온다. 표준은 그 위에 계약 인증서(PKI) 기반 신원 인증을 권장하지만, 대중화 전이라 현재는 식별자 기반 오토차징으로 동작한다.

현실의 벽 — 모든 차가 표준을 똑같이 말하지 않는다

여기까지는 표준 문서의 이야기입니다. 그런데 표준 문서와 도로 위의 실제 차량은 다른 세계였습니다. 바로차징을 프로덕션 품질로 만드는 데 가장 큰 난이도는 프로토콜 구현 자체가 아니라, ‘세상의 차들이 이 표준을 제각각으로 따른다’는 사실에 있었습니다. 어긋남은 크게 세 갈래였습니다.

• ISO 15118 자체 미지원. 구형 차량은 아예 EVCC ID를 내보내지 않습니다. 표준 이전 세대에는 ‘꽂으면 인증’의 전제 자체가 없습니다.
• 국내 데이터 연동 규격(K-VAS) 미지원. 국내 충전 생태계의 차량 데이터 연동 규격을 따르지 않는 차량이 존재합니다.
• 지원해도 구현이 제각각. 표준을 지원한다는 차들 사이에서도 버전, 주고받는 필드, 인증서 처리 방식이 미묘하게 다릅니다. “표준을 지원한다”가 “우리 기대대로 동작한다”를 보장하지 않았습니다.

표준을 코드로 옮기는 일과, 도로 위의 온갖 차를 실제로 인증시키는 일은 전혀 다른 난이도였습니다.

그래서 — 직접 붙여보고, 표로 만들었다

표준 문서만 읽어서는 알 수 없는 영역이라, 방법은 하나였습니다. 수많은 실차를 직접 충전기에 붙여 인증을 돌려보고, 통신 로그를 열어 차종별로 어디서 어긋나는지 확인하며 동작을 검증했습니다. 그렇게 쌓인 결과를 차종별 호환성 표로 정리했습니다.

이 표는 내부 문서로만 남지 않습니다. 고객이 ‘충전소에 가기 전에 내 차가 바로차징이 되는지’를 미리 알 수 있도록, 그대로 앱의 지원 차종 안내로 투명하게 노출됩니다.

그리고 — 안 되는 차도 충전은 끊기지 않게

검증만으로는 부족합니다. 바로차징이 불가능하거나 불완전한 차를 만났을 때 그냥 실패하면 사용자는 충전을 못 합니다. 그래서 충전기·차량의 능력을 판별해, PnC가 안 되면 회원카드·원격 인증으로 매끄럽게 되돌리는 폴백 체계를 세웠습니다. 구현 세부는 접어두더라도 원칙은 분명합니다 — 되는 차는 자동으로, 안 되는 차도 충전 자체는 항상 가능하게. 충전기 쪽 지원 여부 역시 펌웨어 단위의 ‘능력’으로 관리해, 이 판별의 일부로 삼았습니다.

차량마다 다른 표준 지원·구현을 능력 판별로 갈라준다. 표준의 약속과 현실의 차량 사이를 폴백으로 메워, 어떤 차든 충전이 끊기지 않게 했다.

이 지원 여부는 앱 곳곳의 바로차징 뱃지로도 노출됩니다 — 충전소·충전기가 바로차징을 지원하는지, 내 차가 지원 차종인지를 사용자가 한눈에 확인할 수 있게 했습니다.

편의 뒤의 보안 — FDS라는 방어·학습 체계

바로차징의 본질은 ‘사용자 개입 제거’입니다. 그런데 개입이 사라진 만큼 부정 사용의 표면도 새로 생깁니다. 식별자가 복제되거나 공유되면, 한 시점의 검증만으로는 걸러내기 어렵습니다. 예컨대 한 도시에서 충전이 끝난 직후 수백 km 떨어진 곳에서 같은 식별자로 인증 요청이 온다면, 그것은 물리적으로 불가능한 이동입니다.

1장에서 말했듯 EVCC ID 기반 오토차징은 편리하지만 ‘식별자’에 기댑니다. PKI 인증서가 아직 채우지 못하는 그 신뢰의 빈틈을 운영 단에서 메우는 것이 FDS(이상 거래 탐지)입니다. 우리는 편의만 만든 게 아니라, 그 편의를 노린 부정 사용을 막는 방어 체계를 처음부터 하나의 개념으로 설계했습니다. 뼈대는 이렇습니다.

• 2단계 검증. 인증 시점과 충전 종료 시점, 두 번에 걸쳐 각각 검증합니다.
• 물리적 이동 불가능성. 같은 식별자의 연속 충전 사이의 거리·시간으로 도달 가능성을 따져, 불가능하면 차단합니다.
• 이력 대비 학습형 이상 탐지. 사용자의 과거 충전·결제 패턴과 비교해, 평소와 다른 미세한 변화를 잡아냅니다.
• 리스크 스코어와 차등 대응. 신호를 하나의 점수로 합산해 정상은 승인, 의심은 모니터링·알림, 부정은 즉시 차단으로 대응 수위를 나눕니다.

정직하게 말하면, 이 방어 체계가 코드로 전부 구현된 것은 아닙니다. 하지만 흩어진 규칙의 나열이 아니라 FDS라는 하나의 학습형 방어 구조로 설계했고, 이 구조를 특허로 출원해 두었습니다. 그 토대는 이미 프로덕션에 있습니다 — 성공이든 실패든 모든 인증 신호를 사유까지 담아 이벤트로 흘려보내는 파이프라인입니다. 확정된 판정 결과가 다시 모델과 임계값을 갱신하는 학습 루프로, 시간이 갈수록 더 정확해지도록 방향을 잡았습니다. 다만 구체적인 탐지 규칙과 임계값은 그 자체가 회피의 실마리가 될 수 있어, 이 글에서는 의도적으로 공개하지 않습니다.

FDS의 얼개(개념도). 인증·종료 두 시점의 신호를 리스크로 합산해 대응 수위를 나누고, 판정 결과가 모델·임계값을 갱신하는 학습 루프로 이어진다. 세부 판별 규칙은 악용 방지를 위해 공개하지 않았다.

마치며 — 일하는 방식

바로차징 하나에 국제 표준, 충전기 프로토콜, 관제 서버, 백엔드 도메인, 모바일 앱이 한 흐름으로 엮였습니다. 기능 자체보다, 그 사이사이의 판단을 공유하고 싶었습니다.

• 표준이 약속한 편리함과 현실의 차량 사이 간극은 실차 테스트로 메운다.
• 되는 차는 자동으로, 안 되는 차도 폴백으로 충전이 끊기지 않게.
• 편의를 만들 때, 그것을 지킬 방어 체계까지 함께 설계한다.

표준을 ‘문서 그대로’ 구현하는 것과, 세상의 온갖 차에서 ‘진짜로 되는’ 제품으로 만드는 것은 다른 일이었습니다. 그 간극을 메우는 데 든 수많은 실차 테스트와 설계 판단이, 우리가 일하는 방식이라고 생각합니다.

그리고 이 모든 건 한 사람의 일이 아니었습니다. 무엇을 풀지 정의하고 편의를 지킬 이상 탐지(FDS) 방어 체계를 설계한 일(Young), 표준을 실제 장비 위에서 ‘되게’ 만든 하드웨어 설계(Jimi), 서버와 앱을 관통하는 소프트웨어 구현(Jay), 그 결과를 앱의 차량별 지원 화이트리스트로 붙여 안정화한 손길(Teddy·Ollie), 그리고 그 화이트리스트를 차량 하나하나 검증해 채운 QA(Eddy)까지 — 여기 다 적지 못한 여러 동료의 기여가 더해져 지금의 바로차징이 됐습니다.