달고나 47. 프로젝트L 회고
Lessons Learned from An Analysis
자세히 적을 순 없지만 최근 사이드 프로젝트로 오랜만에 데이터를 깊게 들려다 봤다. 최종 완결된 건 아니지만 현재 상황으론 더 이상의 진행은 무의미하다. 여전히 깔끔하지 않은 결과에 미련이 남아 뭘 더 하면 좋을지 또는 다른 시야로 볼 수 있는 건 없는지 계속 되뇌지만 뚜렷한 실마리가 없다. 데이터 분석이라는 게 항상 원하는 결과를 얻는 건 아니다. 이런 찜찜/찝찝함도 분석가가 맞닥 뜨려야 하는 과정의 일부다.
세계 정세나 경제에 관심 있다면 작년 연말에 미국 주요 항구에 수많은 화물선들이 접안/하역을 기다리며 무기한 정박하고 있다는 뉴스나 항구 사진을 봤을 거다. 코로나 초기의 치솓은 해고/실업이 백신 접종 이후로 호실업률이 차츰 감소하고 있지만, 트럭 기사들이 오전히 예전 직장으로 돌아오지 않아서 물류 대란이 발생했고, 그와 함께 인플레이션도 심해졌다는 것은 대부분 알 거다. 그냥 뉴스 속 얘긴 줄 알았는데 이 물류 지연 문제를 데이터로 확인하고 해결해야 하는 업무를 얼떨결에 내가 맡았다. 간단히 적자면 2020년도 하반기부터 화물선의 화물을 (예측했던) 정시에 하역하지 못하고 상황이 점점 더 나빠지고 있는데 이를 데이터로 해결할 수 있는가? 에 관한 거다.
개발/분석을 꾸준히 할 게 아니라서 IntelliJ나 PyCharm 등의 유료 IDE를 정식으로 구매, 설치하는 건 낭비라 생각해서, 난생처음 VS Code를 설치하고 몇 달만에 Python과 Jupyter Notebook을 설치했다. 예측대로 순탄하진 않았지만 적당히 분석 환경은 갖췄다. 이직 전에는 HiveQL로 웬만큼 데이터를 1차 가공해서 가져와서, 파이썬으로 알고리즘에 맞게 정제해서 오픈소스를 돌려서 개념만 증명하는 수준이었는데, 이번은 파이썬으로 거의 모든 작업을 진행해야 했다. 구글신의 도움으로 적당한 샘플 코드를 찾아서 내 데이터에 맞게 수정해서 실행하는 걸 반복했다. 첫 사이클에선 -- 전에 HiveQL로 처리하듯이 -- 파이썬으로 1차 가공한 데이터를 엑셀로 불러와서 손으로 그리고 눈으로 데이터를 다시 가공하고 차트를 그리며 감을 잡고, 나중(2차 사이클 후)에는 엑셀로 표현하기 어려운 건 Seaborn 등으로 적당히 시각화했다. 그런 과정을 반복하며 여러 깨달음을 얻었는데, 오늘은 ‘가능하면 상세히 봐라’와 ‘도메인을 모르면 상상한다’라는 것만 다루려 한다.
가능하면 상세히 봐라.
꼼꼼하고 상세하게 데이터를 보는 건 당연한 건데 왜 굳이 적었는가 하면… 문제와 데이터에 관해서 짧은 설명을 들은 후에, 여느 때처럼 엑셀로 샘플 데이터를 열어서 데이터는 어떤 모양새를 갖췄고 어떤 칼럼들이 있고 각 칼럼의 의미는 무엇인지 등 전체를 쭉 훑어봤다. 그러면서 어떤 칼럼을 사용할지 또는 어떻게 변환하거나 연결해서 분석할지를 파악했다. 물론 실 데이터를 받기 전에 어떤 내용으로 분석하면 좋을지를 미리 머릿속에 그려뒀다. 그런 분석 포인트에 맞게 우선 평균값을 구해서 한 사이클을 돌았다. 월별 이동 시간, 경유항의 작업 시간 등 제한된 데이터 내에서 가능한 많은 걸 보려했다. 코로나 전후로 물류 상황이 많이 바뀌었고 최근 그 정도와 편차가가 더 심해졌다는 걸 확인할 수 있었다. 데이터가 완전하지는 않았다 손치더라도 그저 ‘상황이 안 좋다’라는 걸 재확인만 했을 뿐 더 이상의 인사이트를 얻기 어려웠다. 가용 피쳐가 많지는 않지만 노선이나 해운사 등의 가능한 여러 조합으로 데이터를 쪼개고 붙여서 다시 보더라도 큰 차이가 없었다. 분석 코드에 익숙지 않았지만 첫 사이클은 구글링 하며 2~3일 내에 웬만큼 끝냈다.
결과적으론 지금 결론과 크게 다르진 않지만 뭔가 많이 부족하다는 생각에 더 깊이 파고들었다. 처음에는 엑셀에서 재가공하며 차트를 그리며 데이터를 봤기 때문에 좀 복잡하고 거대한 작업은 할 수 없었던 것도 제약이었다. 고민하다가 그냥 평균이 아닌 최소, 최댓값을 뽑아봤는데, 전체 경향은 평균값과 크게 다르지 않지만 뭉뚱그려볼 때와는 다른 게 보이기 시작했다. 물동량의 많은 부분을 차지하는 특정 해운사의 데이터가 다른 해운사들과 많이 차이가 났을 뿐 아니라 유독 편차가 심해서, 그 해운사를 제외하고 다시 데이터를 살폈다. 문제 상황의 심각성이 확연히 줄었지만 여전히 문제는 해결 불가 상태고 다음 액션으로 연결할 만큼의 인사이트를 얻진 못했다. 데이터 별로 전체 분포를 보는 작업으로 2차 사이클을 진행했으나 1차 결론과 크게 달라진 건 없다.
다시 고민에 빠졌다. 약 3년 치 데이터여서 처음엔 그냥 월별로 합쳐서 봤는데, 일별로 데이터를 파이썬에서 다시 그려봤다. 결론은 같지만 뷰가 달라지니 이전에 잡아내지 못한 문제들이 눈에 들어왔다. 이후로 며칠을 더 고민하며 계속 깊이 파고들어 갔지만 큰 진전 없이 이 데이터만으로 예측이나 액션으로 연결될 수 없다는 찜찜한 결론에 이르렀다. 옆의 동료도 다른 관점으로 몇 가지를 더 확인해서 내가 당연하게 생각했던 가정에 문제가 있음을 발견하긴 했지만, 데이터 정합성이 해결되더라도 현재 데이터만으론 물류 문제의 온전한 해결책을 도출하기엔 무리가 있다는 비슷한 결론이 이르렀다.
데이터가 많으면 (랜덤) 샘플링으로 일부 데이터를 확인하거나 평균 등의 대푯값을 보거나 몇몇 큰 그룹으로 묶어서 전체 경향을 보는 건 당연한 접근법이다. 하지만 그런 대푯값이나 경향만으로 데이터를 완벽히 이해했다고 말할 수 없다. 그래서 가능하면 전체 데이터를 현미경으로 보듯이 분자 단위로 쪼개서 볼 필요도 있다. 100만 -- 예를 들어 -- 건의 샘플을 하나씩 끝까지 눈으로 확인하라는 의미는 아니다. 사용자의 이력 로그라면 몇몇 대표/임의 사용자를 선택해서 처음부터 끝까지 어떤 단계를 거치고 어떤 활동을 했는지 쭉 따라가다 보면 데이터를 더 다양하고 깊게 이해할 수 있게 된다. (물론 개인정보에 문제없는 범위 내에서) 어느 시점에 이런 상세 확인을 해야 한다고 말하긴 좀 어렵다. 분석 후반부에 진행해서 이전까지 분석에 문제가 있었다는 걸 발견하면 다시 처음으로 돌아가서 다시 반복해야할 위험이 있으니 전반부에 상세 확인을 하라고 말하고 싶다가도, 전반부에 몇몇의 -- 일반화되지 않은 -- 독특한 특징 때문에 전체 방향을 잘못 잡을 수 있으니 너무 일찍 보지는 말라고 하기도 그렇고… 어쨌든 전체와 부분을 병행하며 함께 보는 습관은 가질 필요가 있고, 여건이 된다면 2명 이상이 서로 다른 관점으로 데이터를 파고 들어가는 것도 좋다.
도메인을 모르면 상상하게 된다.
데이터 분석가의 필요 역량으로 수학/통계 지식, 프로그래밍 기술, 그리고 도메인 (비즈니스 로직) 이해를 흔히 든다. 수학과 프로그래밍은 기초 역량이라면 도메인 지식은 분석을 끝낼 끝판왕이다. 때론 데이터 분석을 통해서 도메인을 더 깊게 이해하기도 하지만, 적절한 도메인 지식이 없으면 분석을 제대로 수행하기 어렵다. 주니어들에게 ‘편견을 갖고 시작해서 편견 없이 끝내라’라는 말을 한 적이 있다. 여기서 (전자) 편견은 ‘도메인 지식’을 의미한다. 데이터가 속한 도메인을 잘 알고 있으면 데이터를 직접 파보기 전에 여러 가설을 쉽게 세울 수 있고 확인해볼 포인트를 쉽게 잡을 수 있다. 가설이 좋으면 데이터로 그 가설들이 맞는지만 확인하면 된다. 데이터가 가설을 지지할 수도, 아닐 수도 있다. 하지만 좋은 가설이 있을 때 분석 결과를 해석하기가 용이하다. (후자) 편견 없이 끝내라는 말은 가령 A라 생각하고 분석했지만 데이터가 B라고 말하면 B를 받아들이라는 거다. 물론 한 번에 OK 할 것이 아니라 분석, 실험을 반복하거나 다른 데이터로 재검증하며 애초의 편견(도메인 아님)에서 자유로워지는 거다. 도메인을 모르니 적당한 가설을 세우지 않고 그럴 것이다라는 가정을 바탕으로 데이터를 보게 된다.
나는 (해상) 물류에 관한 전문가가 아니다. 그렇기 때문에 오히려 선입견 없이 데이터를 분석할 수 있었을지 모르나, 이상한 데이터를 볼 때마다 어떻게 접근하고 해석할지 막막했다. 데이터를 통해서 부산에서 뉴욕까지 25일 전후가 걸리는 걸 확인했지만, 30일 이상 걸리는 데이터도 있었다. 이걸 정상 데이터로 봐야 할지 아니면 아웃라이어나 데이터 오류로 봐야 할지 사전 지식이 없으니 판단하기 어려웠다. 이것보다 더 심한 이상치들도 있었지만 그냥 '잘못된 데이터니 삭제하자'라고 쉽게 결정할 수 없었다. 어떤 항구에선 배가 보통 10일 정도 머물렀는데, 어떤 컨테이너는 한 달이 넘게 그 항구에 머물렀다고 로그에 기록돼있다. 잘못된 데이터일까? 부산에서 유럽으로 가는 화물선이 싱가포르항에 잠시 정박한다고 가정했을 때, 처음에는 싱가포르항에서 일부 화물은 내리고 다른 화물을 실어서 다시 유럽으로 향하는 시나리오를 생각했다. 그런데 같은 화물선에 실린 것으로 보이는 컨테이너의 출도착 시간이 다르다면 뭔가 문제가 있다. 그래서 어떤 화물은 항구에 몇십 일 내려놓았다가 유럽으로 가는 다른 화물선이 와서 그 화물을 다시 싣고 가는 걸 상상했다. 이게 맞는 추론인지 아닌지는 -- 아니며 그냥 데이터 정합성 문제인지 -- 전문가에게 문의해서 답을 얻기 전에는 모른다. 내가 해상 물류에 문외한이기 때문이다. 분야 전문가였다면 이런 이상치를 만났을 때 맞다 틀리다를 바로 판단하거나 왜 이런 현상이 발생했는지 적당한 이유/설명을 떠올릴 텐데, 도메인 지식이 없으니 그저 가정과 상상만 하게 된다. (물론 사전 지식 때문에 데이터에 나타난 중요한 것들을 무시하는 것도 위험하다.)
사전 지식이 잘못된 편견을 주는 것이 아니라면 사전 지식은 풍부할수록 좋다. 데이터 분석가라면 도메인에 대한 너른 습득력이 필요하다. 세상 돌아가는 뉴스를 꾸준히 들어두는 것도 도움된다. 수에즈항의 21년 3월 데이터에 이상치가 많았다. 21년 3월에 수에즈 운하에 사고가 발생했다는 걸 몰랐다면 이 데이터를 어떻게 해석했을까? 도메인과 그 이상의 데이터를 찾아서 결합하는 할 수 있는 것도 분석가의 능력이다. 도메인 지식이 없으면 분석 전에 가설을 세우는 대신 가정을 하게 되고 분석 결과를 해석하지 않고 상상하게 된다.
꼼꼼함과 박식함, 여기에 더해서 한 발짝 더 들어가는 끈기(GRIT)가 분석의 최종 질을 결정한다. 결론은 허무할지 몰라도 과정은 치열해야 한다.
