2019년, 데이터의 디귿도 모르지만 데이터 시각화에 빠져있을때였다. 기회가 돼 인턴 휴가까지 내 T아카데미에서 여는 파이썬 데이터 시각화 강의를 보러갔고, 강사 이수진님이 강추해주셔서 이 책 Fundamentals of Data Visualizations (Claus O. Wilke 클라우스 윌케)를 알게됐다. 한국어로는 '데이터시각화 교과서'로 번역된 만큼 근본이 되는 책이다.
요약
이 책을 공부하는 태도
"figures will typically carry the weight of your arguments" 설득력을 기르기 위해 data viz가 필요하다. 안목을 기르기 위해선 이론과 실습이 꼭 병행되어야 한다. Simple rules/principles를 알아야하고, details that other people don't care about을 hands-on practice로 익혀야한다. 그리고 변화하는 세상에서 배움은 lifelong process임을 잊지 않고, learning mindset을 가져야 한다. 단, open mind, but not empty head! 이 책을 읽으면서도 수동적 배움이 아니라, 스스로에게 질문해보고 내 사전에 맞게 paraphrase하는 것이 중요하다. Develop your OWN eye.
데이터를 바라보는 태도
데이터를 스토리로 바라보자. Type of Message가 Type of Chart를 결정한다. Type of Data가 아니라. 사람답게 생각해보자는 것이다. 사람은 데이터를 보면 먼저 이런식으로 생각한다; how large something is, what makes up its composition, how it relates to something else, and so on. 데이터를 보고 오, 이건 연속적 데이터네? 라인 그래프로 나타내야겠어! 라고 생각하지 않는다는 것이다. 따라서 질문에서 시작하자. 질문 - 차트 타입 - 시각화 (사이드 프로젝트 시 이러한 work flow 적용!).
두 우물 파기
데이터시각화... 데이터시각화를 하고 싶다는 것 자체가 사실 '데이터+시각화', 즉 '정확성+심미성'을 더한 것이니 어느 하나가 덜 중요하다고 할 수 없다. 데이터시각물은 틀려서도(멍청해서도), 못생겨서도 안된다 (적어도 누군가에게 보여줄 것이라면 말이다!). 만약 멍청한데 못생기기까지 하면 wrong AND ugly? 정말 봐줄 수 없다. 심미성을 상대적으로 덜 강조하는 사람도 있고 나도 여태 그렇게 믿어왔지만, 그건 두 우물 파기 전문가가 말하는 hindsight이라는 것을 잊지 말아야한다. 똑똑한데, 잘생기기까지 해야 사람들이 봐준다.
같은 데이터 다른 시각화
데이터 값 하나 하나를 aesthetic과 1:1대응/매핑시키는 것이 데이터 시각화이다. 그 과정은 체계적이고 논리적이어야 한다. 다양한 스케일/변수 (축position, size, color, shape)를 써서 전달력을 높일 수 있다. 데이터타입에 따라 적합한 스케일이, 즉 적합한 시각화/차트 타입이 정해져있긴하다. 하지만 같은 데이터를 굳이 다른 스케일로 시각화해보는 연습을 하면, 어떤 시각화가 효과적인지 hands on 과정으로 배울 수 있을 것이다.
Ugly, Bad, Wrong
저자는 차트를 ugly, bad, wrong으로 나눈다. 틀리고 못생긴 것은 분명히 보인다. 반면 bad는 저자 본인도 분류하기가 애매하다고 했는데 (bad도 나라면 이걸 그냥 wrong으로 분류할 것 같다), 나는 이것을 '불친절하거나 태도가 불량한(속이려 드는) 차트'로 이해하기로 했다. 예쁘장하고 맞는 말을 하긴 하는데... 좀 더 쉽게 말해주면 안되나? 라는 생각이 들게 하는 차트 말이다. 한 마디로 good chart는 솔직한 차트라고 정의했다. 솔직하게 두괄식으로, 보여주려는 것을 확실히 보여주는 것. 그래픽 장치를 잘 이용해 강조할 것은 강조하는 등 (어쩌면 더 예쁘게 하는 것이 good chart로 가는 길...?)
대표적인 데이터 타입
연속 vs 이산
데이터 타입은 연속적인 것과, 이산적/비연속적인 것으로 이분되는데, decimal 단위로 쪼개질 수 있는 것을 연속적 데이터로 분류한다. 0, 1, 2 로 단절되는 데이터를 이산적 데이터로 분류한다. 파이썬에선 기본적으로 모든 데이터를 연속적 데이터로 처리하기 때문에, 때에 따라 데이터를 이산으로 처리해줘야 한다 (판다 함수 중에서 astype? 뭐시기 인듯)
양적 vs 질적
데이터 타입은 numerical/quantitative/양적 vs. categorical(범주)/qualitative/질적 으로도 나뉜다. 카테고리/범주는 factors라고도 보통 표현하며, factors can be ordered and non-ordered. ex. months are ordered factors, which need to be visualized in order.
데이터 유형에 따라 어떤 스케일/aesthetic에 매핑시킬지가 정해진다. 연속적 데이터는 한마디로 slider로, morphing/gradual change가 가능한 그래픽 요소를 쓸 수 있다. 그런데, shape/line type도 서서히 a —> b 변화 (slider morphing)이 가능하지 않나...? 할 수는 있는데 비효율적이어서, 그 차이가 너무 미세해서 연속적 데이터에 쓰기 비적합하다고 생각해서 이렇게 나눈 것 같다.
데이터 시각화를 연마하는 두가지 방법:
(1) from dataframe to aesthetics
(2) from aesthetics to dataframe
다양한 scale에 데이터를 mapping해보는 것이다!
1. from dataframe to aesthetics. 표에 정리되어있는 데이터를 보고, 어떤 식으로 시각화 할지 명시해보고, 또 바꿔보면서 어떤 식으로 다양하게 시각화할 수 있을지 빠르게 스케치하는 연습을 해보자. 기억하자, 모든 것의 시작은 df/테이블이다!
2. from aesthetics to dataframe. 3가지 데이터 tempt, location, month가 다른 스케일로 표현돼 결국 다른 시각화로 탄생했다. 그래프를 보고 역으로 dataframe과 어떤 mapping을 했는지 유추하는 것도 해보자.
그래프 용어들
Title, Legend, Major tick, Minor tick, Major tick label, Grid, Figure, Spines, Line, Markers ..
그 외 몇가지 포인트들
전략적 찌뿌 '이유/명분'
그래프를 찌뿌시켜야 하는 상황이 올텐데 (ex 모바일 환경), 그냥 어쩔 수 없이 찌뿌시키는게 아니라 y축 값을 강조시킬지 x축 값을 강조시킬지에 따라 전략적으로 찌뿌시켜야한다는 디테일에 감탄했다. 뭐든지 생각없이 하면 안되고 다 이유가 있어야만 한다는 것이다.
유닛 통일하기
당연한 말일 수 있지만, unit/단위는 꼭 통일시켜야 한다. 통일된 이상 어떤 유닛이어도 그래프 모양은 같을 수 밖에 없다.
로그 스케일은 점들을 지터해주는 마법
로그 스케일은 그냥 마법이라고 이해하기로 했다. 너무 몰려있는 값들을 적절히 퍼뜨려주는 마법! 잘 안보이는 부분만 확대시켜서 한 그래프에 모든 값들이 보여지게 하는 마법! 로그 스케일을 언제 쓰는가? 데이터 집합에 매우 다른 크기의 숫자가 포함 된 경우 (ex. 재산 그래프: 빌게이츠, 손흥민, BTS와 나). 제곱근 스케일이라는 것도 있는데 지금으로선 tmi로 보이므로 skip.
Polar Coordinate System
Polar Coordinate System (직교좌표계를 극좌표계으로 변환하는 과정)은 periodic data, geospatial data에 적합하다. 우리가 흔히 아는 평면 세계지도/cartesian가 왜 현실을 왜곡하는지 보면 이해하기 쉬울 것.
다음 글
올랖
디자인을 좋아하고 더 잘하고 싶어 공부합니다.
쉬는 시간에는 책이나 영화를 보고 농구 슛 연습을 합니다.
'dataVisualization' 카테고리의 다른 글
책 '모두의 SQL' (0) | 2021.09.25 |
---|---|
viz to dataframe 9월 3째주 (0) | 2021.09.24 |
데이터와 차트 매핑하기 (1): 비교할 때 (0) | 2021.09.17 |
이유있는 데이터 색칠 (0) | 2021.09.16 |
[데이터모델링] PK와 UK의 차이 (Primary Key vs. Unique Key) (0) | 2021.09.12 |
댓글