데이터 시각화와 수학적 해석

숫자는 조용하지만, 그래프는 크게 말한다

지난 장에서 우리는 평균, 분산, 표준편차, 상관관계, 가설검정처럼 데이터를 요약하고 판단하는 도구를 배웠다. 그런데 실무에서 데이터는 대부분 숫자 표로 끝나지 않는다. 매출 추이, 가입자 증가, 서버 응답 시간, 전환율, 클릭률, 재방문율, 모델 정확도 같은 값들은 대시보드 위의 그래프로 나타난다.

문제는 그래프가 단순한 장식이 아니라는 데 있다. 같은 데이터라도 어떻게 그리느냐에 따라 "서비스가 폭발적으로 성장 중"처럼 보일 수도 있고, "거의 변화가 없음"처럼 보일 수도 있다. 그래프는 숫자의 의미를 빠르게 전달하지만, 동시에 숫자의 의미를 빠르게 왜곡할 수도 있다.

개발자에게 데이터 시각화가 중요한 이유도 여기에 있다. 프론트엔드 개발자는 차트를 화면에 그린다. 백엔드 개발자는 지표를 집계해 API로 제공한다. 데이터 엔지니어는 원천 데이터를 가공한다. AI 개발자는 모델 성능을 비교한다. 기획자나 PM이 만든 요구사항을 구현하는 과정에서도 개발자는 "이 그래프가 정말 올바른 질문에 답하고 있는가?"를 확인해야 한다.

좋은 시각화는 예쁜 차트가 아니다. 좋은 시각화는 숫자의 의미를 왜곡 없이 전달하는 수학적 커뮤니케이션이다.

먼저 차트가 아니라 질문을 고른다

차트를 고르기 전에 먼저 물어야 할 것이 있다.

"내가 이 데이터에서 알고 싶은 것은 무엇인가?"

이 질문을 건너뛰면 차트 선택은 취향 문제가 된다. 누군가는 선 그래프가 예쁘다고 하고, 누군가는 막대 그래프가 명확하다고 하며, 누군가는 도넛 차트가 대시보드에 어울린다고 말한다. 하지만 시각화에서 차트는 취향보다 목적에 의해 선택되어야 한다.

예를 들어 다음 세 질문은 서로 다르다.

• "시간이 지남에 따라 사용자가 늘고 있는가?"

• "이번 달에 어떤 카테고리의 매출이 가장 큰가?"

• "광고비를 많이 쓸수록 가입자가 늘어나는가?"

첫 번째 질문은 시간에 따른 변화를 묻는다. 두 번째 질문은 항목 간 크기 비교를 묻는다. 세 번째 질문은 두 변수 사이의 관계를 묻는다. 질문이 다르면 적합한 그래프도 달라진다.

개발자가 차트를 구현할 때 흔히 하는 실수는 데이터 배열을 먼저 보고 "이 라이브러리에서 어떤 차트 컴포넌트를 쓸까?"부터 생각하는 것이다. 더 좋은 순서는 반대다. 먼저 질문을 정하고, 그 질문에 맞게 데이터를 집계하고, 그다음에 차트를 고른다.

선 그래프: 시간의 흐름을 읽는 도구

선 그래프는 값이 시간에 따라 어떻게 변하는지 보여 줄 때 강력하다. 일별 방문자 수, 시간대별 요청 수, 월별 매출, 배포 이후 에러율 변화처럼 시간 축이 중요한 데이터에 잘 어울린다.

선 그래프에서 핵심은 점 하나하나가 아니라 흐름이다. 오늘 값이 어제보다 높아졌는지, 일정한 주기가 있는지, 어느 순간부터 추세가 바뀌었는지, 급격한 상승이나 하락이 있는지 보는 데 적합하다.

예를 들어 서버 응답 시간이 다음과 같이 기록되었다고 해 보자.

이 데이터는 표로 봐도 읽을 수 있다. 하지만 선 그래프로 그리면 12시 이후 응답 시간이 갑자기 나빠졌다는 사실이 더 빨리 보인다. 이때 개발자는 점심시간 트래픽 증가, 특정 배치 작업, 외부 API 지연, 캐시 만료 같은 원인을 추적할 수 있다.

다만 선 그래프를 사용할 때 주의할 점이 있다. 선은 점과 점 사이에 연속적인 변화가 있다고 느끼게 만든다. 그래서 순서가 없는 카테고리 데이터에 선 그래프를 쓰면 이상한 의미가 생긴다. 예를 들어 브라우저별 사용자 수를 Chrome, Safari, Edge, Firefox 순서로 놓고 선으로 연결하면, 마치 Chrome에서 Safari로 값이 "흘러가는" 것처럼 보인다. 하지만 브라우저 종류에는 자연스러운 연속성이 없다. 이런 경우에는 막대 그래프가 더 적합하다.

막대 그래프: 항목 간 크기를 비교하는 도구

막대 그래프는 서로 다른 항목의 크기를 비교할 때 좋다. 상품별 판매량, 국가별 접속자 수, 기능별 사용 횟수, 에러 타입별 발생 건수처럼 카테고리 간 차이를 보고 싶을 때 사용한다.

막대 그래프의 장점은 길이 비교가 쉽다는 것이다. 사람은 면적이나 각도보다 길이를 더 안정적으로 비교한다. 그래서 "A가 B보다 얼마나 큰가?"라는 질문에는 막대 그래프가 매우 직관적이다.

예를 들어 오류 로그를 집계했더니 다음과 같다고 하자.

이 경우 막대 그래프는 어떤 문제부터 해결해야 할지 우선순위를 보여 준다. 인증 실패가 압도적으로 많다면, 가장 먼저 인증 로직, 토큰 만료 정책, 로그인 UI, 외부 인증 서버 상태를 확인해야 할 가능성이 높다.

막대 그래프에서 특히 중요한 수학적 규칙이 있다. 일반적으로 막대 그래프의 축은 0에서 시작해야 한다. 막대는 길이로 크기를 표현하기 때문이다. 축을 중간에서 잘라 버리면 실제 차이는 작아도 막대 길이 차이가 과장된다.

예를 들어 A 서비스의 전환율이 48%, B 서비스의 전환율이 52%라고 하자. y축을 0%부터 60%까지 그리면 B가 조금 더 좋은 정도로 보인다. 그런데 y축을 47%부터 53%까지 잘라서 그리면 B가 A보다 압도적으로 좋아 보인다. 숫자 차이는 여전히 4%포인트인데, 시각적 인상은 완전히 달라진다.

여기서 "4%"와 "4%포인트"도 구분해야 한다. 48%에서 52%가 된 것은 4%포인트 증가다. 상대 변화율로는 ((52 - 48) / 48 approx 8.3%) 증가다. 그래프 제목이나 설명에서 이 둘을 섞어 쓰면 해석이 흔들린다.

산점도: 두 변수의 관계를 보는 도구

산점도는 두 숫자형 변수 사이의 관계를 볼 때 사용한다. 각 데이터는 하나의 점이 되고, x축과 y축에 각각 다른 변수를 놓는다.

예를 들어 다음과 같은 질문이 있다.

• "페이지 로딩 시간이 길수록 이탈률이 높아지는가?"

• "광고비를 많이 쓴 캠페인이 더 많은 가입자를 만드는가?"

• "사용자의 방문 횟수와 결제 금액 사이에 관계가 있는가?"

이런 질문에는 산점도가 잘 맞는다. 점들이 오른쪽 위로 올라가는 패턴을 보이면 양의 관계가 있을 수 있다. x가 커질수록 y도 커지는 경향이다. 반대로 오른쪽으로 갈수록 점들이 아래로 내려가면 음의 관계가 있을 수 있다. x가 커질수록 y는 작아지는 경향이다.

하지만 산점도에서 가장 조심해야 할 단어가 있다. 바로 "때문에"다.

산점도에서 두 값이 함께 움직인다고 해서 하나가 다른 하나의 원인이라고 단정할 수는 없다. 방문 횟수가 많은 사용자가 결제 금액도 높다고 해 보자. 그렇다고 방문 횟수를 강제로 늘리면 결제 금액이 반드시 늘어난다고 말할 수는 없다. 충성도가 높은 사용자가 원래 자주 방문하고 많이 결제하는 것일 수도 있다.

이 차이가 앞 장에서 다룬 상관관계와 인과관계의 차이다. 산점도는 관계를 발견하게 해 주지만, 원인을 증명해 주지는 않는다. 원인을 알고 싶다면 실험 설계, A/B 테스트, 통제 변수, 도메인 지식이 함께 필요하다.

스케일은 그래프의 문법이다

그래프에서 축은 단순한 눈금이 아니다. 축은 데이터를 어떤 언어로 말할지 결정하는 문법이다. 같은 데이터라도 선형 스케일로 볼 때와 로그 스케일로 볼 때 메시지가 달라진다.

선형 스케일은 같은 거리마다 같은 차이를 뜻한다. y축에서 10과 20의 차이, 90과 100의 차이는 모두 10이다. 대부분의 일상적인 그래프는 선형 스케일을 사용한다.

로그 스케일은 같은 거리마다 같은 비율을 뜻한다. 10에서 100, 100에서 1,000, 1,000에서 10,000은 모두 10배 증가다. 차이로 보면 각각 90, 900, 9,000이지만, 비율로 보면 모두 같은 변화다.

로그 스케일이 필요한 대표적인 상황은 값의 범위가 너무 넓을 때다. 예를 들어 어떤 API의 요청 수가 서비스별로 다음과 같다고 하자.

선형 스케일로 막대 그래프를 그리면 E가 너무 커서 A, B, C는 거의 바닥에 붙은 작은 선처럼 보일 수 있다. 이때 로그 스케일을 사용하면 작은 서비스와 큰 서비스를 한 화면에서 함께 비교할 수 있다.

그러나 로그 스케일은 조심해서 써야 한다. 로그 스케일은 큰 차이를 시각적으로 압축한다. 그래서 실제로는 100배 차이가 나는데 그래프에서는 적당히 벌어진 것처럼 보일 수 있다. 대시보드 사용자가 로그 스케일에 익숙하지 않다면, 축이나 범례에 반드시 표시해야 한다. 그렇지 않으면 "별 차이 없어 보이는데 왜 장애라고 하지?" 같은 오해가 생긴다.

로그 스케일은 나쁜 도구가 아니다. 비율 중심의 세계를 볼 때 강력한 도구다. 다만 차이를 보고 싶은지, 배수를 보고 싶은지 먼저 정해야 한다.

누적 그래프: 전체와 구성의 흐름을 함께 볼 때

누적 그래프는 여러 항목을 쌓아서 전체 크기와 구성 변화를 동시에 보여 준다. 월별 매출을 상품군별로 쌓거나, 전체 트래픽을 유입 채널별로 나누거나, 에러 발생 건수를 서비스별로 쌓아 볼 때 자주 사용한다.

누적 그래프의 장점은 전체가 커지는지 줄어드는지 한눈에 볼 수 있다는 것이다. 동시에 전체 안에서 어떤 항목이 기여하는지도 대략 파악할 수 있다.

예를 들어 전체 가입자가 증가하고 있는데, 누적 그래프를 보니 대부분의 증가는 광고 유입에서 발생했고 검색 유입은 거의 그대로라고 하자. 그러면 "서비스가 자연스럽게 성장하고 있다"기보다 "광고비 투입으로 성장이 만들어지고 있다"는 해석이 더 가까울 수 있다.

하지만 누적 그래프에도 함정이 있다. 아래쪽에 있는 항목은 기준선이 고정되어 있어 변화가 비교적 잘 보인다. 반면 위쪽에 쌓인 항목은 아래 항목들의 변화 위에 올라가기 때문에 자체 변화가 왜곡되어 보일 수 있다. 위쪽 항목이 실제로 증가한 것인지, 아래 항목이 증가해서 같이 밀려 올라간 것인지 헷갈릴 수 있다.

비율을 보고 싶다면 100% 누적 그래프를 사용할 수 있다. 전체를 항상 100%로 맞추고 구성비만 보여 주는 방식이다. 이 방식은 "전체 안에서 각 항목의 비중이 어떻게 바뀌는가?"를 볼 때 유용하다. 하지만 전체 규모가 커졌는지 줄었는지는 숨겨진다.

예를 들어 모바일 사용자의 비중이 40%에서 60%로 늘었다고 하자. 100% 누적 그래프에서는 모바일이 크게 성장한 것처럼 보인다. 그런데 전체 사용자 수가 100만 명에서 10만 명으로 줄었다면 이야기가 달라진다. 비중은 늘었지만 실제 모바일 사용자 수는 40만 명에서 6만 명으로 줄었을 수 있다.

그래서 누적 그래프를 볼 때는 항상 두 질문을 함께 던져야 한다. 전체 크기는 어떻게 변했는가? 구성비는 어떻게 변했는가?

정규화: 공정한 비교를 위한 출발선 맞추기

정규화는 서로 다른 크기나 단위를 가진 값을 비교하기 위해 기준을 맞추는 작업이다. 데이터 시각화에서는 정규화가 자주 등장한다.

예를 들어 A 기능은 하루 100만 명이 사용하고, B 기능은 하루 1만 명이 사용한다고 하자. 오류 건수만 비교하면 A 기능의 오류가 훨씬 많아 보일 수 있다. 하지만 사용자 수가 다르기 때문에 단순 오류 건수만으로 품질을 비교하면 불공정하다.

이때 오류율을 계산한다.

[ 오류율 = frac{오류 건수}{요청 수} ]

A 기능에서 오류가 1,000건, 요청이 1,000,000건이라면 오류율은 0.1%다. B 기능에서 오류가 200건, 요청이 10,000건이라면 오류율은 2%다. 오류 건수는 A가 많지만, 오류율은 B가 훨씬 높다. 운영자가 먼저 봐야 할 곳은 B일 가능성이 크다.

정규화는 비교를 가능하게 만든다. 사용자 수가 다른 서비스, 노출 수가 다른 광고, 트래픽 규모가 다른 서버, 클래스 분포가 다른 모델 성능을 비교하려면 적절한 기준으로 나누어야 한다.

하지만 정규화도 잘못 쓰면 오해를 만든다. 작은 표본에서 비율은 쉽게 출렁인다. 어떤 버튼의 클릭률이 100%라고 해도, 노출이 1회이고 클릭이 1회였다면 의미는 약하다. 반대로 노출 100만 회에서 클릭률 5%는 훨씬 안정적인 정보다.

그래서 비율 그래프를 보여 줄 때는 가능하면 분모도 함께 확인해야 한다. 전환율, 클릭률, 오류율, 재방문율은 모두 분모가 중요하다. 대시보드에서 비율만 크게 보여 주고 표본 수를 숨기면, 사용자는 작은 숫자에서 나온 우연한 변동을 큰 의미로 착각할 수 있다.

비율과 변화율을 구분해야 성장 착각을 피한다

성장 지표를 볼 때 가장 흔한 착각은 비율과 변화율을 섞는 것이다.

비율은 전체 중 일부가 차지하는 정도다.

[ 비율 = frac{부분}{전체} ]

예를 들어 전체 방문자 10,000명 중 구매자가 300명이면 구매 전환율은 3%다.

변화율은 이전 값에 비해 얼마나 변했는지를 나타낸다.

[ 변화율 = frac{현재값 - 이전값}{이전값} ]

지난달 매출이 1억 원이고 이번 달 매출이 1억 2천만 원이면 변화율은 20%다.

두 개념은 비슷해 보이지만 완전히 다른 질문에 답한다. 비율은 "전체 중 얼마나 되는가?"를 묻고, 변화율은 "이전보다 얼마나 달라졌는가?"를 묻는다.

이 차이를 놓치면 성장 지표에서 착각이 생긴다. 예를 들어 어떤 스타트업의 월간 활성 사용자 수가 다음과 같다고 하자.

사용자 수는 매달 1,000명씩 꾸준히 늘고 있다. 하지만 전월 대비 증가율은 계속 떨어진다. 이 그래프를 증가율만으로 보면 "성장이 둔화되고 있다"고 느낄 수 있다. 사용자 수 그래프만 보면 "꾸준히 성장하고 있다"고 느낄 수 있다. 둘 다 맞는 말이다. 다만 서로 다른 관점이다.

반대로 작은 숫자에서 출발한 변화율은 매우 커 보인다. 사용자가 10명에서 30명이 되면 200% 성장이다. 사용자가 10만 명에서 12만 명이 되면 20% 성장이다. 전자는 비율상 더 커 보이지만, 실제 증가한 사용자는 20명이고 후자는 2만 명이다.

그래서 성장 그래프를 볼 때는 절대값과 변화율을 함께 봐야 한다. "얼마나 커졌는가?"와 "얼마나 빠르게 커졌는가?"는 다른 질문이다.

축 절단은 작은 차이를 큰 사건으로 만든다

그래프가 데이터를 왜곡하는 가장 쉬운 방법은 축을 자르는 것이다. y축을 0에서 시작하지 않고 특정 값부터 시작하면 작은 차이가 크게 보인다.

물론 모든 그래프가 반드시 0에서 시작해야 하는 것은 아니다. 온도 변화, 주가, 응답 시간의 미세한 변동처럼 작은 차이 자체가 중요한 경우에는 축 범위를 좁혀 보는 것이 유용할 수 있다. 문제는 축 절단 사실을 숨기거나, 차이의 크기를 과장하려는 목적으로 사용할 때다.

특히 막대 그래프는 축 절단에 취약하다. 막대의 길이가 값의 크기를 직접 표현하기 때문이다. 선 그래프는 변화 패턴을 보기 위한 경우가 많아서 축을 확대하는 일이 상대적으로 자연스럽지만, 그래도 축 범위는 명확히 표시해야 한다.

개발자가 차트 컴포넌트를 만들 때는 자동 축 설정을 조심해야 한다. 많은 차트 라이브러리는 데이터의 최솟값과 최댓값에 맞춰 y축을 자동으로 잡는다. 이 기능은 편리하지만, 막대 그래프에서 의도치 않은 과장을 만들 수 있다. "자동으로 그렸을 뿐"이라고 해도 사용자는 그래프의 시각적 메시지를 먼저 받아들인다.

대시보드에서는 축 범위도 데이터 정의만큼 중요하다.

이중 축은 관계가 있는 것처럼 보이게 만든다

이중 축 그래프는 하나의 x축에 두 개의 y축을 놓는 방식이다. 예를 들어 왼쪽 y축에는 광고비를, 오른쪽 y축에는 가입자 수를 놓고 두 선을 함께 그릴 수 있다.

이중 축은 한 화면에서 두 지표를 비교할 수 있어 편리하다. 하지만 매우 조심해야 한다. 두 축의 범위를 어떻게 잡느냐에 따라 두 선이 비슷하게 움직이는 것처럼 보이게 만들 수도 있고, 전혀 관계없는 것처럼 보이게 만들 수도 있다.

광고비와 가입자 수가 같은 시기에 증가했다고 해서 광고비가 가입자를 증가시켰다고 바로 말할 수 없다. 더구나 이중 축에서 두 선이 우연히 겹쳐 보이면 사람은 둘 사이에 강한 관계가 있다고 느끼기 쉽다. 축의 스케일을 조금만 바꿔도 그 인상은 달라진다.

이중 축을 써야 한다면 두 지표의 단위, 축 범위, 해석 의도를 분명히 표시해야 한다. 더 안전한 방법은 두 그래프를 위아래로 나란히 배치하고 같은 시간 축을 공유하게 하는 것이다. 그러면 사용자는 시점을 비교할 수 있지만, 두 값이 같은 단위인 것처럼 착각할 가능성은 줄어든다.

선택적 기간 표시는 원하는 결론을 만들 수 있다

데이터 시각화에서 기간 선택은 강력한 메시지 편집 도구다. 같은 지표라도 어느 기간을 보여 주느냐에 따라 완전히 다른 이야기가 된다.

예를 들어 서비스의 일일 활성 사용자가 1년 동안 전체적으로 증가했지만, 최근 2주 동안은 감소했다고 하자. 1년 그래프를 보여 주면 "장기적으로 성장 중"이라는 메시지가 된다. 최근 2주 그래프를 보여 주면 "위험 신호 발생"이라는 메시지가 된다. 둘 다 사실일 수 있다.

문제는 특정 결론을 강화하기 위해 기간을 선택적으로 보여 줄 때 생긴다. 성과를 강조하고 싶으면 최저점 직후부터 현재까지를 보여 주고, 위기를 강조하고 싶으면 최고점 직후부터 현재까지를 보여 줄 수 있다. 데이터는 거짓말하지 않았지만, 그래프는 매우 편향된 이야기를 할 수 있다.

개발자는 기간 필터를 구현할 때 기본값을 신중히 정해야 한다. 최근 7일, 최근 30일, 최근 90일, 연간 추이 중 무엇을 기본으로 보여 줄 것인가? 이 선택은 사용자의 판단에 영향을 준다.

좋은 대시보드는 하나의 기간만 강요하지 않는다. 짧은 기간과 긴 기간을 함께 볼 수 있게 하고, 요일 효과나 계절성을 확인할 수 있도록 돕는다. 쇼핑몰의 주말 매출, 업무용 SaaS의 평일 사용량, 게임의 이벤트 기간 트래픽처럼 많은 지표에는 주기가 있다. 주기를 무시하면 정상적인 반복 패턴을 이상 현상으로 오해할 수 있다.

평균선 하나로는 충분하지 않다

그래프에는 종종 평균선이 함께 표시된다. 평균은 데이터를 빠르게 요약하는 좋은 도구다. 하지만 평균만 보면 분포를 놓친다.

예를 들어 API 응답 시간 평균이 200ms라고 하자. 이 숫자만 보면 꽤 괜찮아 보인다. 그런데 실제 데이터가 대부분 80ms이고 일부 요청이 5초 이상 걸리는 구조라면 이야기가 달라진다. 평균은 괜찮지만 일부 사용자는 매우 나쁜 경험을 하고 있다.

그래서 성능 대시보드에서는 평균뿐 아니라 p95, p99 같은 분위수 지표를 자주 본다. p95 응답 시간이 1초라는 말은 전체 요청 중 95%는 1초 이하로 응답했고, 나머지 5%는 그보다 오래 걸렸다는 뜻이다. 분위수는 극단적인 사용자 경험을 파악하는 데 유용하다.

시각화에서도 마찬가지다. 평균 막대 하나보다 분포를 보여 주는 박스 플롯, 히스토그램, 누적 분포 그래프가 더 많은 정보를 줄 때가 있다. 모든 대시보드가 복잡한 통계 그래프를 써야 하는 것은 아니지만, 평균이 현실을 가릴 수 있다는 감각은 꼭 필요하다.

대시보드 개발자는 지표 정의까지 검증해야 한다

대시보드를 만드는 개발자는 단순히 차트를 그리는 사람이 아니다. 지표가 어떻게 정의되었는지, 어떤 데이터가 포함되었는지, 어떤 집계 방식이 쓰였는지 함께 검증해야 한다.

예를 들어 "일일 활성 사용자"라는 지표가 있다고 하자. 겉보기에는 단순해 보이지만 실제 정의는 여러 가지일 수 있다.

• 앱을 실행한 사용자

• 로그인한 사용자

• 특정 핵심 행동을 수행한 사용자

• 백그라운드 자동 요청을 보낸 사용자

• 중복 기기를 하나로 합친 사용자

정의가 달라지면 그래프도 달라진다. 앱이 자동으로 백그라운드 요청을 보내는데 이를 활성 사용자로 계산하면, 실제 사용자 행동보다 지표가 부풀려질 수 있다. 반대로 로그인하지 않고도 사용하는 기능이 많은 서비스에서 로그인 사용자만 세면 실제 사용량을 과소평가할 수 있다.

차트의 시각적 표현도 지표 정의와 맞아야 한다. 누적 가입자 수를 선 그래프로 보여 주면 대부분 계속 증가한다. 탈퇴자를 빼지 않는 한 누적값은 줄어들지 않기 때문이다. 이 그래프만 보면 서비스가 항상 성장하는 것처럼 보일 수 있다. 하지만 실제 활성 사용자나 재방문율은 감소하고 있을 수 있다.

따라서 대시보드에서 중요한 것은 "무엇을 그릴까?"가 아니라 "이 그래프가 어떤 행동을 유도할 것인가?"이다. 잘못 정의된 지표와 그럴듯한 그래프가 만나면 팀은 잘못된 방향으로 빠르게 움직인다.

그래프를 구현할 때 확인해야 할 것들

실무에서 차트를 만들 때는 다음 질문을 습관처럼 확인하는 것이 좋다.

• 이 그래프가 답하려는 질문은 무엇인가?

• 데이터의 단위와 집계 기준은 명확한가?

• 선 그래프, 막대 그래프, 산점도 중 질문에 맞는 형태를 선택했는가?

• 축의 시작점과 범위가 차이를 과장하거나 축소하지 않는가?

• 로그 스케일, 누적 그래프, 정규화가 사용되었다면 그 이유가 명확한가?

• 비율을 보여 줄 때 분모의 크기도 함께 확인할 수 있는가?

• 변화율과 절대값을 혼동하지 않도록 표현했는가?

• 기간 선택이 특정 결론만 강조하고 있지는 않은가?

• 평균만 보여 주어 중요한 분포나 이상치를 숨기고 있지는 않은가?

• 사용자가 이 그래프를 보고 어떤 의사결정을 하게 될지 예상했는가?

이 질문들은 디자인 감각보다 수학적 감각에 가깝다. 차트의 색상과 애니메이션도 중요하지만, 그보다 먼저 값의 정의, 축의 의미, 비율의 기준, 변화의 해석이 맞아야 한다.

시각화는 숫자와 사람 사이의 인터페이스다

개발자는 사용자 인터페이스를 만든다. 버튼, 폼, 메뉴, 페이지 흐름만 인터페이스가 아니다. 대시보드와 차트도 인터페이스다. 숫자와 사람 사이에 놓인 인터페이스다.

좋은 인터페이스는 사용자가 실수하지 않도록 돕는다. 좋은 데이터 시각화도 마찬가지다. 사용자가 우연한 변동을 추세로 착각하지 않게 하고, 작은 표본에서 나온 비율을 과대평가하지 않게 하며, 축과 스케일 때문에 잘못된 결론을 내리지 않게 해야 한다.

이 장에서 배운 내용은 복잡한 수학 공식이 아니다. 하지만 실무에서는 매우 강력하다. 선 그래프는 시간의 흐름을, 막대 그래프는 항목 간 비교를, 산점도는 변수 사이의 관계를 보여 준다. 로그 스케일은 배수의 세계를 읽게 해 주고, 정규화는 서로 다른 규모를 공정하게 비교하게 해 준다. 비율과 변화율을 구분하면 성장 지표를 더 정확히 해석할 수 있다. 축 절단, 이중 축, 선택적 기간 표시는 그래프의 메시지를 크게 바꿀 수 있다.

결국 데이터 시각화의 핵심은 하나다.

숫자를 보기 좋게 만드는 것이 아니라, 숫자가 말하는 바를 정확히 듣게 만드는 것이다.

다음 장부터는 데이터가 점과 선을 넘어 공간으로 들어간다. 사용자의 취향, 문장의 의미, 이미지의 특징, 상품의 속성을 숫자의 묶음으로 표현하는 세계다. 그 출발점이 바로 벡터와 행렬이다.