David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 세계 게임시장 규모
  • 기획참고
  • 벤치마킹
  • 동향
  • 애플리케이션
  • Gartner
  • UX
  • 디자인
  • 반응형웹
  • 유니티
  • 인공지능
  • 디자인참고
  • daumkakao
  • 사물인터넷
  • Curation
  • 모바일
  • 가트너
  • 큐레이션
  • 웨어러블
  • Mreport
  • 2015
  • 분석
  • trend
  • 사이트
  • 트렌드
  • 트랜드
  • 기획
  • UI
  • 다음카카오
  • 2014

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

Planning · PM/서비스 기획

클라우드와 차량 간 통신(V2V), 서비스 기획 관점

2017. 11. 11. 15:41

 

자동차가 점점 스마트폰처럼 연결된다는 이야기가 요즘 자주 들려요.

그 중심에 있는 개념이 클라우드와 차량 간 통신, 줄여서 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

티스토리툴바