서울시 공공자전거 따릉이: 11. epilogue

지난번 O-D 지도를 만든 업보로, 2017년 전체 데이터도 마찬가지 방식으로 지도에 펴보지 않을 수 없게 되었다.

사실 ‘마찬가지 방식’은 될 수 없다. 선의 개수가 31.2만 개에서 415.6만 개로 13배 이상 늘어났기 때문이다. 아래에서 보겠지만, 30만 개까지는 봐줄 만하다 쳐도 400만 개의 선을 종이 한 장 위에 그리면 어떻게 그리든 복잡해 보인다. 즉 이해 가능한 그림을 그리려면 우선 데이터를 어떤 식으로든 쪼개어야 한다.

나누어 그려야 하다는 것은 그만큼 해야 하는 설명의 양도 늘어난다는 뜻이 된다. 그런데 막상 적다 보니 할 이야기가 한도 끝도 없이 많다. 실은 그동안 내 글 자체가 그랬다.. 보이려던 건 그림 몇 장인데 결과적으로는 글 쓰는 데 너무 많은 에너지를 소모하게 된다. 당초 취지에 맞지 않거니와 지겹기도 해서, 글자 수를 최대한 줄이고 그림에 집중하려고 한다.

이런 다짐을 하는 또다른 이유는, 자꾸 데이터 자체가 안고 있는 문제들의 지적으로 이야기가 채워지기 때문이다. 그 문제들은 제공 데이터 포맷의 일관성 부족부터 데이터의 신뢰도를 근본적으로 의심케 하는 오류까지 다양한 지점에 포진해 있다.

물론 비관적으로 보자면, 세상에 내가 만든 것 말고 모든 데이터는 다 불편하고 의심스럽다. 그래서 이런저런 경우에 데이다 보면 나중에는 어떤 데이터셋이든 어느 정도 각오하고 열어보는 태도를 갖게 된다. 그런데 data.seoul 내지 공공데이터를 제공하는 공공기관 대부분은, 약간은 악의를 품고 있는 것이 아닌가 싶을 만큼 데이터를 다루기 귀찮게 만들어 놓는 경우*가 많다. 그리고 정합성이 확보되지 않는 경우 즉 앞뒤 아귀가 안 맞는 경우가 종종 발견되는데, 그에 대한 합리적 이유는 찾기 어렵다. 담당자의 머릿속에만 저장되어 있거나, 이전까지 누구도 틀렸다는 사실을 몰라 이유란 걸 따져본 적이 없기 때문에.

사실 이번 글도, 데이터 신뢰도를 의심케 하는 상황을 어떻게 이해해야 할지 이리저리 살펴보고 고민하느라 시간을 다 보냈다. 대표적으로, 기록된 주행거리가 시점과 종점 대여소 사이의 직선거리보다 짧은 경우가 너무 많이 나왔다. 예를 들어 이런 대여이력이 있다.

'SPB-01761','2017-06-25 01:46:15','1119. 염창동 한마음아파트앞(염창동 빛나는 음악학원앞)',6,
'2017-06-25 01:49:02','1639. 희성오피앙’,7,2,700

강서구 염창동 한마음아파트앞 대여소 1119번에서 출발해 노원구 상계동의 희성오피앙 대여소 1639번까지 2분간 700m 주행했다는 기록이다. 뭔가 이상하다. 강서구에서 노원구까지 주행했다는 것만 보면 한번 놀라고 말 뿐이지만. 어째서 주행거리 700m, 주행시간 2분인가? 실제 대여소 1119번과 1639번 사이의 직선거리는 21,675.1m이나 되는데 말이다. 

지도에 선으로 표현할 수 있는 2017년 데이터 4,155,681건 중 440,446건(10.6%)이 이렇게 대여소간 직선거리보다 주행거리가 더 짧은 기록이다. ET가 따릉이 단골이라고 해도 불가능한 기록이 10.6% 포함되어 있는 것이다. 이걸 어떻게 받아들여야 좋을까.. 대여소 정보를 의심해야 할까, 주행거리 기록을 의심해야 할까? 그럼 다른 항목은 의심하지 않아도 좋을까?

여기에 생각이 미치면 이 작업 자체의 의미마저 의심스러워져 버린다. 더이상 작업을 진행할 동력이 사라지는 것이다.. 틀린 데이터인 줄 알면서 뭣하러 분석하는가? 일단 이번 글로 따릉이 데이터에 대한 이야기를 중단하는 것은 이런 맥락에서다.

아무튼, 본론으로 돌아와서. 일단 앞서와 동일한 방식으로 지도에 선을 뿌려 보았다. 2017년 기록은 총 4,974,843건인데, 이 중 이동거리가 0m인 기록, 시점과 종점이 동일한 기록 등**을 제외하고 지도 위에 선으로 표현할 수 있는 기록은 4,155,681건이다.

2017년 따릉이 주행이력의 시점-종점 연결.

앞서의 시각화에 비해 붉은색이 두드러지는 것은, 앞서 글의 scatterplot에서 확인하듯 겨울철 기록에 비해 장거리 주행이 많아졌기 때문이다. 어쨌든 보다시피 이제 색깔로 구별해 보기에 400만 개 선은 너무 많다. 거리 구간별로 쪼개어 볼 필요가 있다.

아무래도 우선 단거리 주행에 주목하게 된다. 일상적 필요에 따른 주행일 가능성이 높고 레저 목적의 주행일 가능성은 낮다고 볼 수 있기 때문이다. 또한 단거리 이용이 빈번한 구간은 지리적으로 자전거 이용이 편리한 환경이거나 절대적으로 수요가 많은 지역에 속해 있다고 볼 수 있다.

도시에서 어느 정도의 자전거 주행거리를 ‘단거리’로 볼 것인지에 대해서는 여러 정의가 있을 수 있고 체계적인 분석이 필요하다. 다만 여기서는 간단하게 ‘10분 이하로 주행하는 경우’를 단거리 주행이라고 치자. 사람마다 속도가 다르고 지역마다 지리적 저항이 다르지만, 어떻든 대여소 가서 자전거 빌리고 반납하는 수고를 감안할 때 10분 이하 주행이라면 확실히 ‘단거리’라 볼 만하니까.

주행거리 기록을 신뢰할 수 없는데 주행시간 기록을 신뢰할 수 있는지 모르겠지만, 지금으로서는 활용할 수밖에 없다. 2017년 유효 데이터에서 10분 이하의 주행기록은 32.2%인 1,555,115건이다. 지도 위에 뿌려 보면 다음과 같다.

2017년 따릉이 주행이력 중 10분 이하 주행기록의 시점-종점 연결. 참고사항으로 지적도상 ‘산림’ 지역(녹색 부분)을 포함하였다.

서울 전체로 보면 역시 몇 개 클러스터가 보인다. 그리고 가까운 구간임에도 선이 아예 없는 경우가 있다. 그냥 오갈 일이 없어서라고 볼 수만은 없는 구간도 있을 것이다. 구 단위로 확대해서 현재의 자전거 인프라와 함께 살펴본다면 어떤 구간에 자전거 이동성 장애요인이 있는지, 개선이 가능하다면 우선적으로 어디에 자원을 배분해야 하는지 힌트를 얻을 수 있을 것이다.

참고로, 기록 자체의 오류가 아니어도 아래 scatterplot에서 보듯 일반적인 10분간의 주행이라고 보기 어려운 outlier는 상당수 존재한다. 다만 위 시각화에서는 선이 적어도 2개 이상 겹치지 않으면, 즉 반복된 주행이력이 아니면 드러나지 않으므로 커다란 패턴은 실제를 반영한다고 볼 수 있다. (여기에 올리는 모든 그림은 클릭하여 원래 크기로 보지 않으면 디테일이 안 보인다.)

2017년 주행이력 중 주행시간 60분 이하의 주행시간-주행거리 scatterplot. 특히 10분 이하의 기록 중 기이한 사례가 자주 보인다. 10분도 안 돼 5km 이상을 주행한 기록이 많은데, 이들은 평균속도 30km/h 이상이었다는 말이다.

재미삼아 장거리 이력도 분리해서 보았다. 임의로 ‘시간 관계 없이 20km 이상 주행거리 기록’을 장거리 주행으로 정의하였다. 해당되는 데이터는 총 26,444건이다.

2017년 따릉이 주행이력 중 주행거리 20km 이상의 시점-종점 연결.

시점과 종점만 있는 이 데이터의 한계상, 장거리 주행 패턴은 낙서에 가깝다. 여의도와 뚝섬, 잠실지역이 장거리 주행의 허브로서의 기능을 수행한다는 점, 역시 홍제천, 도림천, 중랑천 등 주요 지천이 장거리 주행의 파이프라인으로 보인다는 점 정도가 눈에 띈다.

지금까지 data.seoul에 공개된 따릉이 데이터는 많은 것들이 생략되었음에도 많은 잠재력을 가진 것으로 보인다. 그러나 데이터의 형식의 문제, 자전거도로 등 함께 살펴보아야 할 연관 데이터의 부실함, 그리고 이 모든 문제를 덮어버리는 근본적 신뢰도의 문제 등이 해결되어야 할 것이다. 이렇게 제공해주니 감지덕지 아니냐고 하기엔 이 데이터를 들여다보는 사람이 너무 많아졌고, 따릉이의 흥행을 보건대 앞으로 더 많아질 것 같다.

*

가령 이런 식이다. 2017년 1분기까지 제공되는 csv의 열은 아래와 같이 11개로 이루어져 있다.

자전거번호,대여일시,대여소번호,대여소명,거치대번호,반납일시,반납대여소번호,반납대여소명,반납 거치대번호,이용시간(분),이용거리(M)
SPB-00230,2017-01-01 0:00,419, 홈플러스 앞,5,2017-01-01 0:21,914, 새절역 2번출구,18,20,3340

그런데 2017년 2분기부터는 이렇게 바뀐다.

'자전거번호','대여일시','대여대여소','대여거치대','반납일시','반납대여소','반납거치대','이용시간(분)','이용거리(M)'
'SPB-03053','2017-11-01 00:14:14',"'2359. 국립국악중,고교 정문 맞은편'",1,'2017-11-01 00:25:31','2360. 도곡1동 주민센터 교차로’,4,10,2470

형식이 바뀌었으니 뭔가 보다 개선되었을 것으로 기대하게 되지만 실상은 그저 개악이다.

첫째로 대여소번호와 대여소명이 합쳐졌다. 사람 읽으라고 만드는 스무 줄 hwp 문서라면 몰라도, 코딩으로 처리해야만 하는 수십만 줄짜리 csv에서 왜 숫자(integer)와 글자(string)를 붙여놓는지 아무리 생각해도 모르겠다. 대여소번호와 대여소이름은 type 때문이 아니라도 엄연히 별개의 정보다. 나처럼 대여소번호를 대여소 좌표값과 join해서 공간 데이터로 변환해야 하는 사람들은 '259. 대방역6번출구’에서 ‘259’를 분리해내 별도의 열로 만드는 코드를 적어넣어야 한다. 코드 한 줄로 해결되는 일이기는 하지만, 애초 DB에 별개의 테이블에 존재했을 ‘259’와 ‘대방역6번출구’를 굳이 합쳐서 올리는 합리적 이유를 찾기 어렵다. 

따옴표를 일관성 없게 넣는 것도 그렇다. 예시와 같이 따옴표가 없는 값, 홑따옴표(‘)를 넣은 값, 겹따옴표(“)를 넣은 값이 함께 존재한다. 일차적인 이유는 있어 보인다. column 구분기호가 쉼표(,)인데 대여소 이름에 쉼표가 들어가는 경우가 있어 겹따옴표가 필요해진 것이다. 그러나, 시중의 소프트웨어는 물론이고 파이썬의 (위대한) 라이브러리 pandas도 모든 값(cell)이 같은 형식으로 분리되어 있을 것으로 기대하고 읽어들이기 때문에, 이렇게 따옴표가 여러 가지 형식인 경우에는 불러온 다음 핸들링을 한 번 더 해야 한다. 물론 이것도 코드 한두 줄로 해결할 수는 있다. 그런데 왜 굳이 이런 꼴을 만들어놓아서 모든 사용자들이 교정 코드를 입력하게 하고 전력을 더 소모하게 만드는지 모르겠다.

**

가령 기록 가운데는 일반 대여소가 아닌 것으로 보이는, 그래서 고유번호도 좌표도 알 수 없는 '상암센터 정비실', ‘위트콤', ‘중랑센터', ‘위트콤공장' 등을 시/종점으로 하는 기록이 포함되어 있다. 2017년에 177건이 이런 기록이다. 

이용 패턴을 보건대 서비스 관계자의 이용 기록이 아닐까 추측된다. 물론 이런 이용도 기록에 포함될 수는 있다. 다만 데이터 모든 행이 일관된 형식을 띠고 있을 것으로 기대하고 핸들링하는 입장에서는, 500만 행 가운데 0.0036% 때문에 또 몇 줄 예외 처리 코드를 적어넣게 만드는 부분이기 때문에 귀찮아진다.