제씨 블로그

Git hub 블로그를 운영한지 1년이 지난 지금, 장단점을 돌아보고 티스토리까지 운영하게 되는 계기를 함께 서술한다.

•  목차
  • 1. 깃헙블로그 장점
  • 2. 깃헙블로그 단점
  • 3. 티스토리 병행 운영

깃헙블로그 장점

• 마크다운 친숙성
  깃헙 블로그를 운영하는 동안 깃헙의 메커니즘을 많이 익혔다. 더불어서 마크다운 언어를 자유롭게 사용하게 되었는데, 보고서를 만들거나 문서를 정리할 때, 개발 블로그를 만들 때 큰 도움이 됐다.
• 개발친화적 느낌
  사실 깃헙 블로그는 멋지다. 일정 플랫폼을 벗어나서 블로그와 홈페이지를 구성해보고 그것을 유지하는 경험 자체도 근사하다. 그리고 포트폴리오로써 이보다 제시하기 좋은 점은 없다고 본다.

깃헙블로그 단점

• 유지관리가 쉽지 않다
• _VS Code*_를 켜야하고 깃헙으 스테이지에 올리고, 푸시하고 이를 관리하는 과정이 까다롭다. 특히 이미지와 마크다운을 맵핑시키는 부분이 꽤 귀찮아서 글을 자주 쓰지 않게 되는 것 같다.
• 방문자 통계의 어려움
  방문자 통계를 내고 싶었는데, 결과적으로 구글 애널리틱스와 끝내 연결되지 않았다. 이유는 잘 모른다. 시키는대로 했지만, 결과는 나오지 않으니 답답할 수 밖에. 완성되지 않은 상태에서 하나하나 만든 다는 것은 어려움이 따르는 것 같다.
• 결국엔 하나의 스킨테마에 갇힌다
  내가 웹개발자가 아닌 이상, 지금 유지하는 정도 이상의 스킨 수준을 관리하는 것은 불가능하다. 너무 귀찮은 일이 될 것 같다.

티스토리 병행 운영

고민 끝에 두 개의 블로그를 병행운영 하기로 했다. 고로 똑같은 내용의 깃헙 블로그를 발견한다면, 그것은 바로 나이다..

• 티스토리의 마크다운 지원
  티스토리가 마크다운을 지원한다. 내가 모든 깃헙 문서를 마크다운으로 작성하는만큼 이상의 호환성이 높아질 것이라고 생각한다. 물론 이미지를 다시 넣는 작업은 조금 귀찮은 일이 되겠지만, 드는 노력에 비해 티스토리 노출이 상당히 좋은 편
• 가시적인 트래픽
  티스토리는 자체적으로 통계 기능을 지원한다. 1년 넘게 관리를 하지 않았는데도 불구하고 꾸준하게 50 ~ 100명의 트래픽을 유지하고 있다. 즉 내가 좀 더 관심을 갖고 관리를 하면 더 좋은 트래픽을 일으킬 수 있을 것이라 판단했다.

개요

EIS를 기꺼이 만들었으나 사용하지 않는 기업과 그 이유에 대하여 생각해보았습니다.

• 목차
  • 원인
    • 1. 임원들은 경영정보에 생각보다 관심이 없다
    • 2. 데이터가 뻔하다
    • 3. EIS가 업의 핵심이 아니다
  • 해결책
    • 1. 최대한 간단하게
    • 2. 업무와 관련된 데이터만
    • 3. 가급적 만들지 말자..

몇 년간 QlikView / Sense 를 사용해서 여러 기업의 EIS와 대시보드를 구축하고 나서 가장 크게 느낀 점은, 결국 애써서 만들었으나 그 효용이 낮다라는 생각이었습니다. 긴 시간 그 이유를 조금 생각해봤고 아래와 같이 정리해볼 수 있다고 생각합니다.

임원들은 경영정보에 생각보다 관심이 없다

• 내 일이 아닌 것 같아...
  경영데이터가 사람들의 업무에 크리티컬하게 영향을 주지 않습니다. 즉 보면 좋고 안보면 그만인 그래프들에 지나지 않게 됩니다. 그래서 그냥 경영데이터가 보기좋게 제시되어서 보고용으로 적합할 뿐, 그 이상의 역할은 하지 않게 되는 것 같습니다. 실제로 많은 기업에서 사용자는 Open 이후로 천천히 우하향곡선을 그리게 되죠.

데이터가 뻔하다.

• 이미 보고 받고 있는 데이터인데?
  경영데이터는 보통 ERP에서 사용하고 있는 데이터를 집계하여 시각화합니다. 그렇게 때문에 데이터 자체에서 새로울 것은 잘 없겠죠. 다만 비즈니스 로직에 따라서 필요한 지표들이 더 추가되고편리하게 볼 수 있다는 장점이 있을 수 있습니다. 하지만 이러한 편의를 위해서 들여야 하는 노력에 비해, 사용빈도가 현저히 낮습니다.
• 데이터가 변하는 게 없잖아?
  데이터의 집계에는 시간이 걸립니다. 일 단위로 집계되는 데이터를 본다면 실시간을 원하고, 결산을 기준으로 데이터를 본다면 일 데이터를 원하는 사용자도 생깁니다. 이럴 경우 데이터의 신선도에 대한 요구가 지속적으로 발생합니다. 이렇게 신선도를 잃게 되었다고 생각되는 데이터는 지나간 실적에 대한 보고로써의 역할만 맡게 되는 것 같습니다.
• 그래서 원인이 뭐야?
  BI의 딜레마는 낮은 수준으로 데이터를 묶을수록 정보 전달성이 떨어지며, 높은 수준으로 묶을수록 데이터의 원인을 트래킹하기 어렵습니다. 이 중 EIS는 후자에 가깝습니다. 때문에 데이터를 보고 의문이 생겨도 그 하위로 내려가지 못하고, 결국 팀 내의 현업에게 묻게 됩니다. 즉, Drill-Down 되지 않게 되면 이 역시 EIS가 실패하는 원인이 되는 것으로 보입니다.

EIS가 업의 핵심이 아니다.

• 나 진짜 바쁘고, 이것까지 볼 시간이 없다.
  EIS 정보를 모른다고 해서 자신의 업무에 영향을 받지 않습니다. 그렇다면 바쁜 와중에는 굳이 전체 경영정보를 볼 이유가 없겠죠. 자신의 업무로도 이미, 충분히 각자 바쁜 시간을 보내고 있을테니까요. 이건 어떤 EIS를 구축하느냐의 문제도 있지만, EIS가 가진 본질적인 한계처럼 느껴지기도 합니다.
• EIS 없어도 잘 돌아갔어
  사실입니다. 이전에 잘 돌아가던 업무의 패턴이 있고 EIS는 편의 내지는 지원의 개념으로 현업들의 업무에 끼어들 뿐이죠. 거창한 의미를 둘 필요가 없다는 뜻입니다. 그래서 저는 EIS를 힘주어 만들 필요가 없다고 생각한다. 반대로 Micro한 자신의 업무단위까지 관련이 있다면, (예를 들어 생산라인 오류 감지 등) 시키지 않아도 그것을 보게 되지 않을까요?

이런 식으로 EIS는 애써 기업에서 만들지만 쉽게 사장됩니다.그러면 어떻게 반복되는 EIS의 실패를 막을 수 있을까요? 저는 이렇게 생각합니다.

최대한 간단하게

• 핵심지표만 간추리자
  EIS 안에서는 핵심지표만 과감하게 최소한의 노력으로 핵심지표만 간추려야 한다고 봅니다. 굳이 거대하고 무겁게 만들어봐야 사용하지 않을 확률이 놓기 때문이죠. 그래도 임원들이 보기 때문에 대충 만들기 조금 그렇다고 생각하겠지만, 이건 문화를 바꾸는 게 급선무인 것 같습니다. 중요하게 생각하는 분석지표는 수시로 바뀔 수 있으며 더군다나 요즘같이 빠르게 변하는 시대에는 더더욱이나 그렇습니다.
• 필요에 의해 추가하자
  다른 개발이나 프로젝트, 분석도 마찬가지이지만 EIS에서도 똑같이 적용되는 것 같습니다. 가장 작게 필요한 부분만 시작하고, 차후 현업의 필요를 받아들여서 확장해나가는 것이 더욱 중요해보입니다.

업무와 관련된 데이터만

• 업과 직결된 지표들
  그나마 만들어진 EIS에서 사람들이 보는 지표는, 매출액, 영업이익과 같이 본인들의 평가와 직결된 정보들이었습니다. 그런 핵심 정보들과 더불어서 재고관리팀이라면 재고 현황 데이터를, 생산관리팀이라면 생산관리 데이터를 볼 수 있도록 팀마다 화면을 분리해야 합니다.
• 진짜 EIS가 필요한 것인지요..
  EIS가 필요한 것인지 스스로 자문하며 진단할 필요가 있습니다. 예를 들어서 B2B 기업이고 고객사가 한정적이며, 고객사에 대한 정보를 정리하지 않는 기업의 경우, 데이터를 보며 얻을 수 있는 Action이 발생하지 않죠.

가급적 만들지 말자..

• 어차피 쓰지도 않는 거..
  각고의 노력을 다해 만들어봐야 EIS는 높은 확률로 사장됩니다.그래서 그 때 그 때마다 데이터를 다르게 볼 수 있는 보고서와 좀 더 데이터분석에 가까운 플랫폼을 제공해주는 게 더 좋아보입니다.
• 현업에게도 교육이 필요하다.
  데이터를 다루고 그것을 어떻게 가공해야 하는지에 대한 기본적인 지식이 현업에게도 필요합니다. 그들이 유연하게 데이터에 접근하고 데이터를 가공할 수 있을 때 비로소 유연한 데이터 분석과 문화가 형성이 된다고 생각합니다.

한국복지패널 데이터는 한국인의 다양한 삶의 양상을 볼 수 있는 데이터이다.

분석에 앞서 데이터 '무엇을 보고 싶어하는지'를 정의하는 것은 무척 중요한 일이라고 한다. 

목표가 없이 분석을 하는 것은 목표에 도달하지 못하는 분석과 동일하기 때문이다.

반대로 목표가 있으면, 설령 그 목표에 맞는 분석이 실패하더라도 무엇이 잘못되었는지 알 수 있다고 했다.

그래서 이 1000개가 넘는 Column을 가진 데이터의 바다 속에서, 나는 가장 기본적인 결정변수를 잡아보았다.

"소득과 다양한 변수들(성별, 지역, 건강, 직업, 나이 등)은 어떤 관계가 있을까?"

왜 이 질문이 중요한가?

1. 만약 지역별로 소득이 편중되어 있다면, 우리나라의 지역불균형에 대한 이야기를 이어가볼 수 있다. 소득은 분명한 지표가 될 수 있으니까.

2. 성별로 차이가 있다면, 우리는 '유리천장'문제에 대하여 이야기해볼 수 있다. 하지만 이를 위해서는 세부적인 조사가 더 필요하겠다. 예를 들어

 1) 진짜로 성별 차이로 인해서 발생한 임금의 차이인가 - 여자라서 임금을 덜 주는 경우가 있는가?

 2) 그 외에 여성의 반강제적인 사회적 책임(육아나 출산)에 의해, 공백기간을 포함했는가, 또 그로 인한 불이익을 감안했는가?

작은 부분부터 시작해보자

먼저 Rstudio를 켜고 라이브러리를 불러온다.

# 분석패키지 라이브러리

library(dplyr)

library(foreign)

library(ggplot2)

library(readxl)

# 파일 불러오기

raw_welfare <- read.spss(file = "Koweps_hpda12_2017_beta1.sav",

                         to.data.frame = T)

# 원시 데이터 넣기

welfare <- raw_welfare

 * 이작업은 반드시 필요하다. 원시데이터와 분석하는 테이블을 분리하지 않는다면, 나중에 잘못된 변수를 집어넣거나 파일을 날렸을 때 어마어마하게 곤란한 상황이 벌어질 수 도 있다. 또한 매우 귀찮은 상황에 처하기도 한다.(다시 파일을 불러와야 한다던가)

# 변수 이름 조정

welfare <- rename(welfare,

                  sex = h12_g3, #성별

                  birth = h12_g4, #태어난 해

                  education = h12_g6, # 교육수준

                  region = h12_reg7, # 지역코드

                  marriage = h12_g10, # 혼인여부

                  medcal_ins = h12_med10, # 의료보험가입개수

                  income = h12_din, # 가처분 소득

                  code_job = h12_eco9, #직종

                  health = h12_med2)  # 건강상태

welfare <- rename(welfare,

                  income2 = h12_pers_income1, #상용근로자 소득 

                  income3 = h12_cin) # 경상소득 

 * 변수의 이름들을 알아보기 힘들기 때문에 보기 편한 수준으로 조정했다.

 * 추가로 붙인 변수는 가처분소득 이외에 다른 결과를 나타낼 수도 있는 경상소득과 상용근로자 소득을 통해 다양한 분석을 하기 위함이다.

이제 분석을 위한 데이터 준비는 끝났다. 앞으로 하게 될 분석은 전체적으로

1) 데이터 전처리

2) 데이터 분석 / 시각화

두 단계를 반복하며 진행해볼 예정이다.