문제는 데이터를 수집한다는 사실이 아니다
커넥티드카 플랫폼을 기획하다 보면 어느 시점에 이런 질문이 나온다. "우리가 수집하는 데이터를 사용자에게 어디까지 보여줘야 하는가?" 많은 팀이 이 질문을 법무팀에 넘기고 개인정보처리방침 문서를 업데이트하는 것으로 마무리한다. 그 결과 제품에는 실질적인 동의 체계가 없고, 사용자는 차량 앱이 무엇을 어디로 보내는지 전혀 모른 채 서비스를 이용한다.
노스이스턴대학교 연구팀이 21개 차량과 30개 동반 앱을 실측한 결과, 테스트한 차량 19대가 제3자 도메인으로 트래픽을 전송했고, 앱 7개는 민감한 식별자를 외부 트래커에 보냈다. 앱 5개는 VIN(차량 고유 식별번호)과 개인정보를 함께 전송했다. 이 수치가 중요한 이유는 특정 제조사의 실패를 보여서가 아니라, 업계 전반적으로 데이터 흐름의 투명성 설계가 요구사항 단계에서 체계적으로 다뤄지지 않고 있음을 시사하기 때문이다.
수집 자체가 문제가 아니다. 수집 항목이 사용자에게 보이지 않고, 제3자로 흘러가는 경로가 설계 단계에서 통제되지 않은 채 배포된다는 것이 문제다.
요구사항 단계에서 데이터 흐름 목록을 먼저 만들어야 하는 이유
대부분의 팀은 기능을 먼저 설계하고 데이터 처리 정책을 나중에 붙인다. 커넥티드카 환경에서 이 순서는 거꾸로다.
차량과 앱은 동시에 다른 채널로 데이터를 전송한다. 차량은 Wi-Fi와 셀룰러를 통해 1차 서버와 제3자 서버로 트래픽을 보내고, 동반 앱은 별도 경로로 광고 SDK와 분석 도구에 데이터를 전달한다. 두 채널이 각각 독립적으로 동작하기 때문에, 기능 단위로 개인정보 영향을 평가하면 전체 흐름이 보이지 않는다.
요구사항 단계에서 만들어야 할 첫 번째 산출물은 **데이터 흐름 목록(Data Flow Inventory)**이다. 형식은 간단할수록 좋다. 다음 네 열로 시작하면 충분하다.
- 어떤 데이터인가 (위치, VIN, 운전 패턴, 탑승자 수 등)
- 어느 시점에 수집되는가 (시동 ON, 주행 중, 앱 실행 시, 상시)
- 어디로 전송되는가 (1차 서버, 제3자 분석 도구, 광고 파트너)
- 사용자가 이 흐름을 인지하고 있는가
네 번째 열이 비어 있는 항목이 많을수록, 그곳이 설계 위험 구간이다.
동의 체계를 설계할 때 피해야 하는 두 가지 함정
동의 체계를 설계할 때 팀이 흔히 빠지는 함정이 둘 있다.
첫 번째는 옵트아웃 중심 설계다. "원하지 않으면 해제하세요" 방식은 사용자 대부분이 기본값을 그대로 두기 때문에 실질적인 동의로 보기 어렵다. 규제 당국도 같은 시각으로 본다. 데이터 흐름 목록에서 광고·제3자 판매 목적으로 쓰이는 항목은 옵트인(명시적 동의)을 기본으로 설계해야 한다. 서비스 기능에 필요한 데이터와 수익화에 사용되는 데이터를 구분하지 않으면, 나중에 어느 쪽도 제대로 설명하기 어려워진다.
두 번째는 동의를 일회성 이벤트로 처리하는 것이다. 차량 소프트웨어가 업데이트되거나 제3자 파트너십이 변경될 때마다 데이터 흐름이 달라질 수 있다. 사용자가 최초 가입 시 동의한 내용이 이후 실제 수집 범위와 달라졌다면, 그 간격이 법적 리스크로 전환된다. 동의는 버전 관리가 필요한 요소다. 어느 시점의 동의가 어떤 데이터 흐름에 적용되는지 추적할 수 있어야 한다.
제3자 공유 정책, 어디서 선을 그어야 하는가
제3자 공유 정책은 "공유하느냐, 안 하느냐"의 문제가 아니라 "어떤 조건으로, 어떤 목적에 한정해서" 공유하느냐의 문제다. 비즈니스 현실을 무시하고 전면 차단을 선택하면 데이터 기반 서비스 기능 자체가 흔들리고, 반대로 무분별하게 허용하면 브랜드 신뢰를 잃는다.
실무적으로 판단 기준이 되는 구분은 세 층위다.
1층위. 서비스 기능에 필수적인 전송 내비게이션 서비스, OTA 업데이트, 긴급구조 연계처럼 기능이 작동하려면 외부 전송이 불가피한 경우다. 이 범주는 투명하게 고지하면 충분하다. 사용자가 이 전송을 차단하면 서비스가 제한된다는 사실도 함께 명시한다.
2층위. 파트너 서비스 개선을 위한 전송 보험사 연계, 충전 네트워크, 딜러 서비스 이력 공유가 여기에 해당한다. 사용자에게 개별 파트너와의 공유를 켜고 끌 수 있는 선택지를 줘야 한다. 이 구간에서 VIN과 위치 정보가 결합되면 재식별 위험이 높아지므로, 전송 전 익명화 수준을 요구사항으로 명시해야 한다.
3층위. 광고·데이터 판매 목적의 전송 이 범주는 사용자 동의 없이 기본 활성화하면 규제 리스크와 신뢰 손상이 동시에 발생한다. 명시적 동의를 받더라도 전송 대상 회사 목록, 데이터 종류, 보유 기간을 구체적으로 공개할 수 있어야 한다. "제휴사와 공유할 수 있습니다" 수준의 표현은 사용자 입장에서도, 규제 당국 입장에서도 공개로 인정받기 어렵다.
구현 순서: 요구사항에서 검증까지 단계별 산출물
아래 순서는 커넥티드카 플랫폼 PM이 요구사항 단계부터 실제 운영까지 챙겨야 하는 흐름이다. 각 단계에서 무엇을 확인해야 하는지를 중심으로 정리했다.
1단계: 데이터 인벤토리 작성 (요구사항) 차량, 앱, 백엔드 세 채널 각각에서 수집·전송되는 항목을 목록화한다. 이 시점에 '왜 수집하는가'를 함께 기록해 두지 않으면 이후 정책 문서와 실제 동작이 어긋날 가능성이 높다. 산출물: 채널별 데이터 흐름 목록, 각 항목의 수집 목적 분류.
2단계: 동의 분기 설계 (설계) 데이터 흐름 목록을 기반으로 필수/선택/금지 항목을 구분한다. 선택 항목은 사용자가 기능별로 제어할 수 있는 UI 흐름을 설계한다. 동의 이력을 서버에서 버전 단위로 관리하는 구조도 이 단계에서 결정해야 한다. 산출물: 동의 분기 플로우차트, 동의 이력 저장 스키마.
3단계: 제3자 계약 조건 검토 (설계-개발 사이) SDK, 광고 파트너, 분석 도구 계약서에서 해당 업체가 수신 데이터를 재판매하거나 다른 목적으로 사용할 수 있는지 확인한다. 계약서에 명시가 없으면 없다고 가정하면 안 된다. 데이터 처리 위탁 계약(DPA)에서 재공유 금지 조건을 명문화한다. 산출물: 제3자 데이터 처리 조건 체크리스트.
4단계: 네트워크 트래픽 검증 (QA) 앱과 차량이 실제로 어떤 도메인에 트래픽을 보내는지 테스트 환경에서 확인한다. 설계 단계에서 정의한 데이터 흐름 목록과 실제 트래픽 목적지가 일치하는지 비교한다. 불일치 항목이 발견되면 개발 단계로 되돌려 원인을 추적한다. 산출물: 트래픽 목적지 대조 보고서.
5단계: 사용자 공개 문서 검수 (출시 전) 개인정보처리방침, 앱 내 설정 화면, 차량 디스플레이의 공개 내용이 실제 데이터 흐름과 일치하는지 검수한다. 법무 검토 후 수정된 내용이 제품 UI에 반영되었는지 확인하는 단계도 여기에 포함한다. 산출물: 문서-제품 일치 여부 체크리스트.
6단계: 정기 감사 체계 수립 (운영) 소프트웨어 업데이트마다 새로운 SDK나 외부 도메인이 추가될 수 있다. 반기마다 데이터 흐름 목록을 재검토하고, 신규 제3자 파트너가 추가될 때마다 3단계 프로세스를 반복하는 체계를 내부 운영 절차로 등록한다.
규제와 브랜드, 어느 쪽이 더 빠르게 손해로 이어지는가
규제 리스크는 발생까지 시간이 걸린다. 반면 미디어와 커뮤니티를 통한 브랜드 손상은 훨씬 빠르다. 보험사와 데이터 공유 계약을 맺었다는 사실이 외부에 알려지는 순간, 사용자 반응은 법적 판결보다 먼저 온다.
두 리스크를 따로 관리하면 대응 속도가 늦어진다. 투명성 설계를 규제 대응 작업이 아니라 제품 신뢰 구조의 일부로 보는 팀이, 위기가 왔을 때 더 빠르게 대응할 수 있다. 사용자에게 명확하게 공개된 정책은 변호하기도 쉽다.
PM 입장에서 보면, 요구사항 단계에서 데이터 흐름을 정리하고 동의 체계를 설계하는 일은 '개인정보보호 작업'이 아니다. 나중에 설명해야 할 때 말문이 막히지 않기 위한 사전 작업이다.
커넥티드카가 주행 중 어떤 도메인과 통신하는지 사용자가 묻는다면, 지금 그 답을 팀 내에서 빠르게 꺼낼 수 있는지 확인해 보는 것이 시작점이다.
