자동차가 점점 스마트폰처럼 연결된다는 이야기가 요즘 자주 들려요.
그 중심에 있는 개념이 클라우드와 차량 간 통신, 줄여서 V2V입니다.
저는 자동차 전문가가 아니라 서비스 기획자라서, 기술을 깊이 파고들기보다 "이게 서비스가 된다면 어떤 모양일까"를 중심으로 정리해 보려고 해요.
잘못 이해한 부분이 있을 수 있어서, 기술 사양에 해당하는 내용은 일반적인 개념 수준으로만 적습니다.
V2V는 자동차끼리 서로의 위치나 속도 같은 정보를 주고받는 것을 뜻해요.
옆 차나 앞 차가 무엇을 하는지 운전자가 눈으로 보기 전에 차가 먼저 알 수 있다는 아이디어입니다.
비슷한 말로 차량과 도로 시설이 정보를 주고받는 것, 차량과 주변 모든 것이 이어지는 것을 가리키는 표현도 있어요.
여기에 클라우드가 더해지면 차 한 대가 아니라 수많은 차의 정보가 한곳에 모일 수 있습니다.
차량끼리 직접 주고받는 정보는 빠르고 가까운 범위에 쓰이고, 클라우드에 모인 정보는 넓은 범위의 패턴을 읽는 데 쓰인다고 이해하면 쉬워요.
비유하자면 V2V는 옆 사람에게 바로 외치는 것이고, 클라우드는 관제실에서 전체 상황을 보는 것과 비슷합니다.
실제로 상용화된 것이 아니라 상상해 본 시나리오라는 점을 먼저 밝힙니다.
첫 번째는 급제동 알림이에요.
앞서가는 차가 갑자기 멈췄을 때, 뒤따르는 차가 그 사실을 운전자가 직접 보기 전에 먼저 알 수 있게 해 주는 방식입니다.
바로 앞 차에 시야가 가려서 더 먼 앞의 상황을 못 보는 경우가 많으니까요.
두 번째는 노면 상태 공유입니다.
가정해 보면, 어느 구간에서 많은 차가 미끄러짐을 감지했다면 그 정보가 클라우드에 모여서 뒤따라오는 차에게 "이 구간은 노면이 미끄러워요"라고 알려 줄 수 있어요.
세 번째는 정체 구간 우회입니다.
지금의 내비게이션도 비슷한 일을 하지만, 차량이 직접 보내는 정보가 많아지면 더 촘촘해질 수 있다고 봅니다.
네 번째는 사고 후 대응이에요.
사고가 났을 때 주변 차량에게 알리고, 필요하면 도움을 요청하는 흐름입니다.
이런 시나리오를 적을 때 저는 "누구에게, 언제, 무엇을 알려 주나"를 반드시 한 줄로 쓰려고 합니다.
알림이 너무 많으면 운전자가 오히려 방해받기 때문에, 알려 주지 않는 기준도 함께 적어 두어야 해요.
서비스로 만들려면 누가 비용을 내는지도 생각해 봐야 해요.
운전자가 직접 구독료를 낼 수도 있고, 차를 만드는 쪽이 기본 기능으로 넣어 차의 가치를 높일 수도 있겠죠.
도로를 관리하는 기관이나 보험과 연결하는 방식도 상상해 볼 수 있지만, 모두 가능성을 적어 본 것일 뿐 실제 구조는 확인이 필요합니다.
가장 먼저 부딪히는 한계는 보급률이에요.
V2V는 주변 차들도 같은 기능을 갖고 있어야 효과가 있어서, 처음에는 쓸 수 있는 상대가 거의 없습니다.
메신저가 친구가 많아야 쓸모 있는 것과 같은 구조라고 생각해요.
그래서 초기 서비스는 차량 장비 없이도 가능한 형태, 예를 들어 스마트폰 앱으로 정보를 모으는 방식을 먼저 고민해 볼 만합니다.
두 번째는 지연과 신뢰성이에요.
안전과 관련된 알림은 늦으면 의미가 없고, 틀린 알림은 신뢰를 한꺼번에 잃게 합니다.
통신이 끊기는 구간에서도 서비스가 어떻게 동작하는지 미리 정해 두어야 해요.
세 번째는 규칙과 표준입니다.
어떤 방식으로 주고받을지, 어떤 정보를 다룰 수 있는지는 나라와 업계마다 다를 수 있어서 확인이 필요해요.
네 번째는 개인정보입니다.
차의 위치와 이동 경로는 곧 사람의 생활을 보여 줍니다.
정보를 모을 때 개인을 식별하지 않게 처리할 수 있는지, 사용자에게 어떻게 알리고 동의를 받을지 일찍 정해야 해요.
마지막으로 책임 소재가 있습니다.
알림을 믿고 운전했는데 사고가 났다면 누구의 책임인지는 법과 제도의 문제라서 기획자가 단정하기 어렵고, 전문가의 확인이 필요합니다.
가정해 보겠습니다.
비 오는 날 특정 도로에서 미끄러짐이 자주 생긴다는 점에 착안해 "빗길 위험 구간 알림" 서비스를 기획한다고 해요.
처음 버전은 이렇게 단순하게 시작할 수 있습니다.
- 운전자가 앱을 켜 두면, 급제동이 많았던 지점을 서버에 모은다
- 비슷한 지점에서 급제동이 반복되면 위험 구간으로 표시한다
- 다른 운전자가 그 구간에 접근하면 한 번만 짧게 알려 준다
숫자도 가정해 봅니다.
같은 지점에서 열 대가 한 시간 안에 급제동을 했다면 위험 구간 후보로 올린다는 식으로 기준을 둘 수 있어요.
이 숫자는 설명을 위한 것이고, 실제로는 도로와 날씨에 따라 다시 정해야 합니다.
이 단계에서는 차량 간 직접 통신이 필요 없고, 클라우드와 앱만으로도 V2V가 하려는 일의 일부를 체험해 볼 수 있어요.
나중에 차량이 직접 정보를 보내는 환경이 늘어나면 같은 구조에 데이터 입구만 추가하면 됩니다.
차량 통신은 기술이 먼저 가고 서비스가 뒤따르는 분야라서, 기획자가 할 일은 "가능한 것"보다 "사람이 믿고 쓸 만한 것"을 고르는 일이라고 생각해요.
특히 안전과 연결된 서비스일수록 알림을 많이 주는 것보다 정확히 주는 것이 더 중요합니다.
앞으로 차량이 더 똑똑해질수록 운전자와 차가 역할을 어떻게 나눌지가 큰 주제가 될 것 같아요.
남는 질문도 있습니다.
충분한 보급률이 생기기 전까지는 어떤 서비스로 사용자를 모을 수 있을까요.
그리고 개인정보를 보호하면서 쓸모 있는 정보만 모으는 선은 어디일까요.
이 부분은 제가 더 공부하면서 정리해 보겠습니다.
'Planning · PM > 서비스 기획' 카테고리의 다른 글
| Kakao TOROS (0) | 2017.12.10 |
|---|---|
| 유튜브의 티켓 판매 서비스 (0) | 2017.11.20 |
| 해시태그 기반 검색의 구조와 활용 (0) | 2015.07.02 |
| 2015 Great Calendar App Service (0) | 2015.06.03 |
| Bucket List Creation Websites & Apps (0) | 2015.01.21 |