서울의 도로교통 패턴 #2

실행 결과 4797번의 응답을 받아내는 데는 역시 5분 이상이 걸렸다. 실행마다 request 완료에 걸리는 시간도 상이하고 성공적으로 속도값을 알려오는 링크의 개수도 서로 달라 똑부러지게 말할 수는 없지만, 내 랩탑으로는 대략 10분 정도가 걸렸다. 200(OK)을 돌려주지 못하고 에러를 토하는 링크는 매번 60-120개 정도였다. 비율로는 전체의 2% 안팎이어서 지도에 큰 구멍은 나지 않을 것 같다. 혹시 반복적으로 에러를 토하는 죽은 링크가 있는지 확인해보고 싶었지만, 그러려면 10분짜리 request를 일정한 시간 간격으로 적어도 3번 이상 실행해야 하는, TOPIS가 해야 할 것 같은 일을 대신 하는 것만 같은 느낌에 그만두었다.

더구나 막상 데이터를 굴려보고 나니, 실시간 속도 데이터는 이상적으로 보아도 ‘그 순간(정확히는 5분간)’의 상황일 뿐, 내가 보려는 패턴이라는 ‘일정한 현상’을 말해주지는 않는다는 생각이 들었다. 지금 이 데이터와 더 이상 씨름할 필요는 별로 없어 보인다. 앞서 말했듯 TOPIS는 2014년 이후 링크별 매시간 평균속도를 가공 산출해 제공해주고 있는데, 아쉬운대로 이 데이터를 이용해 보다 중장기적이고 일정한 패턴을 뽑아낼 수 있겠다는 생각이 들었다.

평균속도에 근거해서 더 움직이기 전에 평균속도에 대한 이야기를 잠시 하려 한다.

초등학생 시절 한동안 내 머리를 혼란스럽게 했던 산수 문제가 있다.

A씨는 옆 도시로 가는 120km 거리의 도로를 40km/h의 속도로 운전했다. 그리고 돌아올 때는 같은 도로를 60km/h로 운전했다. 이때 A씨의 평균 주행속도는 얼마인가?

이 문제의 답이 왜 50km/h가 아닌 48km/h인지를 놓고 오랜 기간 힘들어했던 그때의 추억 때문인지, 나는 평균속도를 조화평균이 아닌 산술평균으로 구하는 것을 보면 신경이 곤두선다. 2개 이상의 속도의 평균값은 (총 이동거리)/(총 소요시간)이며, 이 원칙은 동일한 도로구간을 통과한 차량들의 평균속도를 구할 때도 마찬가지로 적용된다. 현재 어떤 링크에서의 프로브별 평균속도는 해당 링크의 길이를 통과(정확히는 전후 노드의 일정 반경의 진출입)에 걸린 시간으로 나누어 구하고 있으므로, 산수상 옳은 평균속도는 그 값들을 가지고 다음의 식으로 쉽게 구할 수 있다:

(평균속도) = (프로브의 수) × (링크의 길이) / (프로브별 링크 통과시간의 합)

같은 구간을 서로 다른 속도로 움직인 두 물체의 평균속도를 산술평균과 조화평균으로 구했을 때의 차이는 가령 다음과 같다.*

굳이 산수 이야기를 꺼낸 이유는, TOPIS가 링크별 평균속도를 산술평균이 아닌 조화평균으로 구하는지 확인할 수 없었기 때문이다. 그리고 도로교통공단의 UTIS 관련 보고서에 복수의 속도를 산술평균하여 평균속도를 구한다는 내용이 있는 것을 볼 때, 그리고 모든 자료에서 그냥 ‘평균’이라고만 적어둔 것을 볼 때 산술평균을 쓰지 않았나 하는 의구심이 들었기 때문이다. 교통공학계에서는 너무나 당연한 내용이라 생략한 것일까? 그렇더라도 비전공자를 위해서 이에 대한 명확한 언급이 필요하지 않을까 싶다.

산수 차원을 떠나서도 평균속도라는 값에는 고민이 필요해 보인다. 어떤 도로에서 수많은 자동차들이 달리고 있을 때 그 도로의 평균속도란 무엇을 의미하는가? 내 생각에 공식적 발표의 목적으로 산출되는 어떤 도로구간의 특정 시점의 평균속도란, 불특정한 운전자가 그 시점 그 도로구간을 일반적인 운전 매너로 무사 통과할 때 낼 수 있는 속도다. 그리고 그 속도는 차간거리를 지키며 앞뒤 차량과 같은 속도로 달릴 때의 속도일 것이다. 가령 갑자기 끼어드는 앞차 때문에 급정거했다던가 소위 ‘칼질’을 하며 달린 프로브가 있었다면 그 속도를 평균속도 산출에 반영하는 것은 합리적이지 않다. 현재 프로브가 전부 택시이기 때문에 더더욱 이런 지적을 하게 된다. 김은정 외(2015)에 따르면 속도 산출에 이용되는 원시데이터 중 빈 택시(공차)가 차지하는 비율이 40%로 나오는데, 승객을 실은 택시와 승객을 찾는 택시가 움직이는 패턴이 사뭇 다르다는 것은 주지의 사실이다. 그 두 집단간의 차이를 평균이라는 과정으로 뭉뚱거리는 것은 좀 편의주의적으로 보인다. 만약 샘플의 개수가 충분하다면, 평균값보다는 최빈값(mode)을 도로구간의 평균속도로 보는 것이 합리적이지 않은가 하는 생각이 든다. 물론 그 ‘충분’이란 얼만큼인지, 서울에서의 일반적인 운전 매너가 무엇인지 등에 대해서는 논쟁의 여지가 크다. 한편 GPS 오류나 시간간격, 샘플의 수처럼 더 큰 오차를 만들 수 있는 다른 요소를 생각하면 애초에 합리적 접근이란 무엇인지 머릿속이 하얘지기도 한다.

비전공자 주제에 이렇게(까지?) 따져보는 이유는, 애초에 교통공학 관련 연구에 동원되는 각종 알고리즘의 복잡성이 비전공자를 질리게 할 만큼 높기 때문이다. 그런데 그렇게 복잡한 수식을 콤보로 동원하면서 정작 이런 것들을 고려하지 않는다면 그건 육상경기장의 결승선은 레이저로 그으면서 출발선은 돌로 긋는 것과 무엇이 다를까.

아무튼 내가 여기서 어찌할 수 없는 이런 점들을 생각하며, 이야기를 다시 작업으로 돌려서..

실시간 속도 데이터와 잠시 작별하기 전에, 몇 개 시점에서 수집된 데이터를 지도 위에 뿌려보았다. 이 과정에는 QGIS를 사용하였다. 속도 데이터를 입힐 표준링크의 벡터 레이어는 다시 data.seoul을 벗어나 국토교통부가 운영하는 표준노드링크 웹사이트 자료실에서 구할 수 있다. 이 자료는 현재 국토지리정보원 표준의 하나인 중부원점 좌표계(EPSG:5186)로 저장되어 있어 WGS84 기반 projection에 아무런 문제 없이 내려앉는다. 보다 자세한 이야기는 그림을 보면서 하기로 한다.

2017년 11월 14일 저녁 8시 14분 기준 서울 도로 소통 상황

2017년 11월 19일 오전 4시 54분 기준 서울 도로 소통 상황

모든 시각화 작업이 그렇지만 도로 속도를 지도화할 때 가장 중요하고 고민되는 이슈는 범례의 설정이다. 다시 말해 속도구간을 어떻게 나누어 어떤 색상으로 표현하는 것이 수치의 적절한 시각화인지를 결정하는 것이 관건이다. 위의 두 지도에서 보는 것과 같이 주중 저녁시간과 주말 새벽 시간의 소통상황은 판이하다. 이렇게 다양한 상황에서 색상의 스펙트럼이 구간의 차이를 과장하거나 반대로 변별력이 떨어지는 현상을 최소화하는 색 배분, 스타일링이 필요하다. 그러나 동시에, 스타일에 치중하다가는 현실 속 정보의 의미를 최대한 전달해야 하는 주제도의 본령을 저버릴 수 있음에 유의해야 한다.

속도구간의 합리적 구분 근거가 있을지 살펴보니, 마침 서울시와 국토교통부에서 관련 사항에 대해 나름의 고민을 한 흔적을 찾을 수 있었다. 기존 시내도로 정체구간 범위가 10km/h 이하였는데 시민이 체감하는 소통상황과 격차가 크다는 민원이 많았는지, 국토교통부와 가이드라인을 만들어 2016년 8월부터 TOPIS 등에서 표출 범위를 상향조정했다는 내용이다.

별다른 기준을 찾기 어려운 가운데 이 가이드라인은 어느 정도 합의 단계에 오른 기준이라 판단된다. 그래서 저속구간에 대해서는 이 구분 기준을 인용하기로 했다. 그런데 25km/h 이상 속도구간을 세분화할 좋은 기준을 찾기가 어려웠다. 다만 2017년 6월부터 서울 내 도시고속도로를 제외한 모든 도로 제한속도가 60km/h로 바뀐 사실이 있었다. 그래서 60km/h에서 한 번 끊어준 다음, 비례상 40km/h에서 다시 끊어두고 분포 양상을 보기로 했다. 내부순환로나 강변북로 같은 도시고속도로구간은 대체로 제한속도 80km/h을 가지고 있지만, 일단은 일반도로와 구분하지 않고 보기로 했다.

두 지도에 나타난 링크의 속도 분포를 D3.js를 이용해 히스토그램으로 만들어 보았다. 일단 적어도 이들 사례에서 직관적으로 보기에는 속도구간의 설정에 큰 무리는 없는 것 같다. 그렇지만 통계분석을 통해 어떤 수치적 근거가 나오거나, 아예 정성적으로 도시 주행속도가 가지는 사회적 의미를 도출할 수 있다면 구간 설정을 바꿀 여지는 있다.

2017년 11월 14일 저녁 8시 14분 (좌) / 11월 19일 오전 4시 54분 (우) 링크별 속도 분포

* 평균 내기에 대한 보다 근본적인 이야기는 이 포스트를 비롯한 여러 글에서 음미해볼 수 있다.