업무 E-Mail로 분석해 보는 나의 개발자 생활 4.5년
칡은 씹으면 씹을수록 단맛이 난다고 한다.
데이터도 이와 별반 다르지 않다. 씹으면 씹을수록 더 그 데이터가 가지는 본연의 의미가 나온다.
그래서 이번에 1년 전에 분석했던 "이메일 데이터 분석"을 다시 맛나게 곱씹어 보았다.
시작하기에 앞서
현재 회사에 2012년 입사하여 5년 차가 되었다. 이를 되돌아 보기에 가장 좋은 데이터는 아마도 E-Mail 일 것이다. 그래서 1년 전에 진행했던 E-Mail 분석을 현재 기준으로 업데이트하고 후속 분석 작업도 진행해 보았다.
이번 E-Mail 데이터 분석은 크게 3가지 측면에서 음미해 보았다.
1. E-Mail을 어떻게 사용하고 있는지를 보기 위한 E-Mail Stat 탐색
2. 지금까지의 주요 이슈를 살펴보는 E-Mail 제목으로 Topic 분석
3. 동료 간의 업무 관계 해석을 위한 E-Mail Network 분석
이 중 가장 재미있던 결과는 Network 분석이다. 1년 전에도 했던 분석이 지금은 왜? 다르게 느껴졌던 것일까? 이제부터 알아보자
참고로 아래 분석을 직접 해보고자 하시는 분은 분석의 전체 과정을 담은 https://github.com/goodvc78/email-data-analysis 저장소의 소스를 다운받아서 진행하시면 됩니다.
나의 outlook에 있는 이메일에서 보낸사람, 받는사람, 보낸시간, 제목의 정보를 file로 다운로드를 하자. Outlook에는 기본적인 내보내기를 제공하는데, 이 내보내기 기능에서는 보낸시간 정보를 내보낼 수가 없기 때문에 어쩔 수 없이 서드 파티 툴 인 Codetwo를 이용하였다. 한번 설치해 놓고 쓰니 편하다.
- Outlook E-Mail에서 시간, 보낸사람, 참조, 받는사람, 제목을 추출한다.
- 추출한 E-Mail 데이터셋을 다양하게 Grouping, Split, Aggregation, Plotting을 용이하게 다양한 필드를 추가한다.
우선 기본 스탯으로 보니
하루에 평균 2.4 건의 메일을 보내고
4.6건 메일을 받고
이메일의 제목은 26글자, 6.4 단어로 썼네요.
* 참조 메일의 비율이 65%!
나의 메일 비율을 보니 특이하게 참조 메일이 65%로 많은 비중을 차지했다.
곰곰이 생각해 보고 내린 해석이
팀 내에 정보 공유가 활발히 이루어 지기 때문에 참조메일이 많은 것이 아닐까? 하고 판단해 본다. 비교 데이터가 없어 객관적으로 확인을 못한 것이 아쉽다.
참고로, 나의 보낸 메일 수신자에 팀이 포함된 경우가 전체 1,891 중 892 건으로 47%에 이른다.
* 업무 연차가 늘수록 메일량도 늘어남.
메일을 어떻게 주고받는지 패턴을 보기 위해 날짜(X축)와 시간(Y축)으로 Plotting을 해보았다.
회사에서 업무를 하고 2년의 시간이 지나면서부터 메일량이 급속도로 증가됨이 보인다. 뭔가 회사에서 제 몫을 하고 있는 듯 보인다.
그리고 2015년부터는 종종 새벽 시간에 메일을 받는 것이 눈에 띈다.
(확인해 보니 대부분 장애 리포팅 메일이다!!)
* 하루에 보내는 메일의 수는 증가하다가 일정 값에 수렴할까?
아래 그래프를 보면 시간이 지날수록 "받은 메일수 >>> 보낸 메일의 수"로 압도했다.
이렇게 받은 메일의 수 대비 보낸 메일 수가 증가 폭이 작은 이유는 두 가지로 보인다.
첫째, 나의 업무 시간은 한정적이기 때문에 하루에 보낼 수 있는 메일을 수도 한정된 듯하다.
둘째. 메일당 수신자의 수가 증가해서 회신 사람이 많이 졌기 때문이다.
아마도 협업 대상자 수가 증가해서 그럴 수 있을듯하다.
참고로, 아래 받은 메일의 평균 수신자수를 보면 2015년에 3.034명으로 크게 증가됨이 눈이 뛴다.
* 하루 중 언제 메일을 주고받을까?
받은 메일을 보면 사람들은 업무를 시작하는 오전 10시 전후에 이메일을 가장 많이 보내는 좌편향(SKEY=0.134) 특성이 있다.
나는 오전/오후 구분하지 않고 대중없이 메일을 보내는듯하다.
E-Mail은 내가 진행한 업무에 대하여 아주 설명력이 높은 데이터이다. 특히 E-Mail 제목은 내가 진행하는 주요 업무를 아주 잘 요약했을 것이라 생각된다.
그래서 E-Mail 제목으로 아래와 같은 Topic 모델링 과정을 TF-IDF로 수행하여 Topic 단어를 추출해 보았다.
생각보다 결과가 잘 나온다
결과를 보면 내가 4.5년 동안 어떤 일을 했지는에 대하여 상당히 잘 해석되는듯하다.
회사에 입사해서
패킷 기반 로그 수집 -> Collector 만들고 -> 대용량 메시지 플랫폼 만들고 -> 연관검색어/자동완성 -> 개인화 추천 ->... -> 최근에는 데이터 분석 작업까지 나의 히스토리에 대한 Topic 단어들이 눈네 쏙쏙 들어온다.
기회가 되면 다른 분들도 이 Python 분석 소스로 전체의 과정을 실행해 보기 권한다!!
참고로 E-Mail을 Topic 분석은 보낸 메일만 사용하였다.
보낸 메일이 내가 직접적으로 관여된 이슈이고 한 일이라는 생각 되었고,
실제 결과를 비교해봐도 보낸 메일만 사용하는 쪽의 결과가 더 좋았다.
그럼 이 Topic 단어의 Score를 기반으로 분기별 중요 메일 3건씩을 찾아내어 보자. 역시 좋은 결과가 나온다!!
이 결과도 나름 의미 있어 보여서, 나중에 주/월 단위로도 한번 추출해 봐야겠다.
이렇게 나의 히스토리를 보고 든 생각이, 팀 1년 회고를 이렇게 E-Mail Topic으로 해 보는 것이 어떤가 하는 생각도 든다. 너무 결과가 적나라하려나???
E-Mail을 가장 큰 목적은 업무 커뮤니케이션이다.
그래서 가장 알고 싶었던 내용이다.
나는 누구와 함께 일하는가?
입사 연차별 네트워크 보기
그래서 입사 연차별 주고받은 이메일 대상자를 기준으로 Graph Network을 만들고 결과를 음미해봤다.
참고로 Network 노드의 색상에서
나(최규민)는 하늘색( O )이고,
나의 팀(기반기술팀)은 빨간색( o )이다
입사 1년 차 : 팀 내에서만 짱박힘!
그냥 팀 내에서 활동하다가 간간히 연구소 사우들과 교류
입사 2년 차 : 협업으로 다른 팀 사우들과 어울리기 시작
그래도 활동 범위가 연구소 위주이고, 한 다리 건너는 사업본부와 관계된 업무가 많아짐.
그런데 빨간색인 팀원이 나 포함 3명!!
입사 3년 차 : 이제는 뭔가 일 좀 하는 듯
팀원(빨간색)이 6명으로 늘어남,
그리고 디렉트로 다른 부서와 커뮤니케이션이 활발해짐
입사 4년 차 : 3년 차와 비슷
팀원(빨강)이 이제 9명이나 됨,
2014년과 유사한 커뮤니케이션 네트워크를 나타냄
입사 5년 차 : 나 홀로 떨어져!
이제는 팀원(빨강)이 최대 13명이나 됨
특이한 것은 나의 커뮤니케이션 네트워크가 타 부서 쪽(사업본부, 경영지원 등)으로 많이 당겨짐.
데이터 분석 업무로 이런 네트워크가 그러 해 진 듯함. ( 매우 인상 깊음 )
팀 일감을 관리하는 Redmine으로 팀원들이 군락을 이룸
나도 어렴풋이 만 느꼈던 업무관계를 잘 해석해줌.
이런 네트워크만 잘 분석해도 프로젝트의 성향, 팀의 성향, 개인의 성향, 관계자자들이 잘 뽑힐 듯 보인다.
나와 많이 협업하는 사람들은?
보낸메일만으로 네트워크를 그려보면 내가 누구와 실제로 일을 많이 하는지 한눈에 볼 수 있다.
내가 생각했던 결과가 잘 나오고 디테일해 보인다.
우리 팀원들은 어떻게 연관되었나?
참조메일만으로 네트워크를 그리면 나와 연관되지 않았던 팀 전체의 커뮤니케이션 네트워크가 그려지는 듯 보인다.
이거 이외에도 팀 내에서의 연관 관계, 팀을 제외한 사업부와의 연관 관계, 팀 레벨 등등 데이터를 쪼개고 합치고 변형하면 다양한 관점의 네트워크 만들 수 있고 우리가 몰랐던 사실을 확인할 수 있었다.
이렇게 데이터 탐색을 맺음 하면서 E-Mail로 무엇을 해석할 수 있을까 물어본다면?
회사 생활하면서 궁금했을 법한 아래 질문에 대하여 객관적인 답을 해 주는 듯하다.
어떤 프로젝트를 참여했고?
프로젝트의 성격/관계는 어떠한지?
누구와 협업이 가장 많은지?
나에게 어떤 이슈가 있었는지?
그리고 나는 지금 어떻게 변화하고 있는지?
마치면서
이번에 E-Mail 데이터 탐색을 다시 하면서 느낀 점은
1년 전 삽질을 하던 나와 지금 삽질을 하는 내가 다르고, (개인적으로 데이터 분석 작업은 끊임없는 삽질이라 생각한다.)
동일한 E-Mail 데이터라도 첫 번째 볼 때와 두 번째로 볼 때는 완전히 다른 느낌이었다.
그래서 하고 싶은 말은
데이터는 지루하지만
곱씹어야 그 맛을 즐길 수 있다.