폭스바겐이 Home Assistant를 막았다 — 'client assertion'이 대체 뭐길래?

무슨 일이 있었냐면요

혹시 Home Assistant라고 들어보셨어요? 집 안의 전등, 보일러, 도어락, CCTV, 그리고 요즘은 전기차까지 하나의 대시보드에서 제어하게 해주는 오픈소스 스마트홈 플랫폼이에요. 특정 회사 앱에 갇히지 않고 내 집의 모든 기기를 내 마음대로 자동화할 수 있다는 게 매력이라, 전 세계 홈 오토메이션 덕후들이 정말 사랑하는 프로젝트거든요.

폭스바겐 차주들도 그동안 homeassistant-volkswagencarnet이라는 커뮤니티 통합(integration)을 써왔어요. 차의 배터리 잔량을 확인하고, 출발 전에 미리 히터를 켜고, 충전 스케줄을 짜는 걸 폭스바겐 공식 앱이 아니라 Home Assistant 안에서 직접 했던 거죠. 그런데 최근 폭스바겐이 로그인 과정을 조용히 바꾸면서 이 통합이 한순간에 먹통이 됐어요. 범인은 바로 “client assertion(클라이언트 어서션)”이라는 인증 방식이었습니다.

client assertion이 대체 뭐냐면요

여기서 잠깐, 로그인이 어떻게 동작하는지부터 풀어볼게요. 요즘 대부분의 서비스는 OAuth라는 표준을 써요. 쉽게 말하면 “내 폭스바겐 계정 비밀번호를 이 앱한테 직접 주지 않고도, 폭스바겐 서버가 발급한 출입증(토큰)을 받아서 앱이 대신 차를 조작하게 하는” 방식이에요.

그런데 이 출입증을 받으려면 앱이 자기가 ‘진짜 정식 앱’이라는 걸 증명해야 해요. 예전 방식은 간단했어요. client_id(앱 이름표)랑 client_secret(앱 비밀번호)을 같이 보내면 됐거든요. 문제는 이 비밀번호가 공식 앱을 뜯어보면 그 안에 들어 있어서, 커뮤니티 개발자들이 그걸 꺼내 쓸 수 있었다는 거예요. 그래서 서드파티 통합이 가능했던 거죠.

client assertion은 여기서 한 단계 더 잠그는 방식이에요. 단순 비밀번호 대신, 앱이 자기만 가진 비밀 키(private key)로 서명한 디지털 증명서(서명된 JWT)를 만들어서 보내야 하거든요. 표준 이름으로는 private_key_jwt라고 불러요. 비유하자면, 예전엔 ‘공용 비밀번호’만 알면 들어갈 수 있던 문에, 이제는 ‘오직 정품 앱만 가진 인감도장으로 찍은 위조 불가능한 서류’를 요구하는 셈이에요. 게다가 이 키를 단말기 보안칩이나 앱 무결성 검증(attestation)과 묶어버리면, 제3자가 흉내 내는 게 사실상 불가능해집니다.

결국 기술적으로 ‘해킹당했다’가 아니라, 폭스바겐이 정식 앱만 통과할 수 있는 관문을 새로 세운 거예요. 커뮤니티 통합 입장에선 비밀번호를 알아도 인감도장이 없으니 문 앞에서 막히는 거죠.

업계에서는 이미 흔한 흐름이에요

사실 이건 폭스바겐만의 일이 아니에요. 자동차 회사들이 자기 API를 점점 걸어 잠그는 큰 흐름의 한 장면이거든요. 테슬라도 예전엔 비공식 API를 사실상 방치했다가 공식 Fleet API로 전환하면서 인증을 강화했고, 여러 제조사가 비슷한 길을 걷고 있어요. 이유는 보통 세 가지로 정리돼요. 보안 책임 문제(서드파티 앱이 사고를 내면 누가 책임지나), 구독형 커넥티드 서비스로 돈을 벌고 싶은 사업적 동기, 그리고 데이터 통제권이죠.

흥미로운 건, 이런 잠금이 ‘보안 강화’라는 명분과 ‘생태계 폐쇄’라는 부작용을 동시에 가진다는 점이에요. 사용자 입장에선 내가 산 내 차인데 내가 고른 도구로 제어하지 못하게 되는 거니까요. 유럽에서 데이터 이동권이나 상호운용성 관련 규제 논의가 계속 나오는 것도 이런 맥락과 맞닿아 있어요.

한국 개발자에게 주는 시사점

OAuth로 외부 서비스에 연동하는 기능을 만들어본 분이라면 이 사건이 남 일처럼 느껴지지 않을 거예요. 우리가 어떤 플랫폼의 비공식 API나 추출한 client_secret에 의존해서 서비스를 만들면, 상대가 인증 방식을 한 번만 바꿔도 우리 서비스 전체가 무너질 수 있다는 교훈이거든요.

반대로 내가 API를 제공하는 쪽이라면 private_key_jwt 같은 client assertion 방식은 꼭 알아둘 가치가 있어요. 단순 client_secret보다 훨씬 안전하고, 금융권이나 의료처럼 보안 등급이 높은 연동(OpenID Connect, FAPI 프로파일)에서 점점 표준이 되고 있거든요. ‘비밀번호를 네트워크로 안 보내고 서명만 보낸다’는 개념 하나만 이해해도 인증 설계 감각이 한 단계 올라갑니다.

마무리

이번 일은 ‘내 기기를 내가 통제할 권리’와 ‘제조사의 보안·사업적 통제’가 부딪치는 전형적인 장면이에요. 기술적으로는 client assertion이라는 더 강한 인증이 어떻게 생태계의 문까지 닫을 수 있는지 잘 보여주고요. 여러분은 어떻게 생각하세요? 보안을 위한 정당한 조치일까요, 아니면 사용자 자유를 막는 과한 빗장일까요?