선 하나 긋는 데 50시간? 차트 라이브러리 없이 직접 만들어 본 개발자의 기록

그래프 라이브러리 하나 쓰면 끝나는 거 아니야?

웹에서 데이터를 시각화할 일이 생기면 우리는 보통 별생각 없이 Chart.js나 D3, Recharts 같은 라이브러리를 끌어옵니다. npm install 한 줄이면 예쁜 라인 차트가 뚝딱 나오니까요. 그런데 Doug MacDowell이라는 개발자가 "그래, 간단한 라인 그래프 하나쯤은 직접 그려보자" 하고 시작한 작업이, 무려 50시간이 걸렸다는 이야기를 풀어냈어요. 단순한 자랑 글이 아니라, 우리가 평소에 너무 당연하게 여기던 라이브러리 뒤에 얼마나 많은 디테일이 숨어 있는지를 보여주는 기록입니다.

그가 만들고 싶었던 건 거창한 게 아니었어요. X축에 시간, Y축에 값, 그리고 그걸 잇는 선 하나. 그런데 이걸 "제대로" 만들려고 하는 순간, 끝이 안 보이는 토끼굴이 펼쳐졌다고 합니다.

라인 하나에 숨어 있는 50시간의 디테일

먼저 가장 기본적인 문제부터 시작합니다. 눈금(tick)을 어디에 찍을 것인가. 값이 0부터 1000까지면 100 단위로 찍으면 되겠죠. 그런데 0부터 1037까지라면요? 100 단위로 찍으면 마지막 눈금이 1000이 되고 그래프 영역 위로 데이터가 삐죽 튀어나옵니다. 그렇다고 1037을 그대로 표시하면 보기 흉하고요. "사람이 보기 좋은 숫자"로 반올림하는 알고리즘, 이게 뭐냐면 데이터 범위를 보고 1, 2, 5, 10 같은 깔끔한 간격을 자동으로 골라주는 로직인데, 이걸 직접 구현하면 의외로 까다롭습니다. D3의 nice() 함수가 왜 존재하는지 그제야 이해된다고 해요.

다음은 레이블이 겹치는 문제예요. 데이터 포인트가 빽빽하면 X축 날짜 레이블이 서로 겹쳐서 읽을 수가 없거든요. 그럼 어떤 레이블은 숨기고 어떤 건 보여줄지, 화면 폭에 따라 동적으로 계산해야 합니다. 화면을 줄였다 늘렸다 할 때마다 레이블이 우아하게 사라지고 나타나야 하고요.

그리고 마우스 호버. 점 위에 마우스를 올리면 툴팁이 떠야 하는데, 정확히 어느 점에 가장 가까운지 빠르게 찾아야 합니다. 점이 수천 개면 매번 거리 계산을 다 돌릴 수 없어서 이진 탐색이나 공간 분할 같은 기법을 써야 하죠. 거기에 모바일 터치까지 고려하면 또 다른 세계가 열립니다.

축 단위가 시간일 때는 더 복잡해져요. "오늘"인지 "어제"인지, 같은 달인지 같은 해인지에 따라 표시 형식이 달라야 하고, 타임존도 신경 써야 하죠. 누락된 데이터가 있을 때 선을 끊을지 이어 그릴지도 결정해야 하고요. 결국 50시간이라는 시간은 "라인 하나"가 아니라 "라이브러리가 우리 대신 해주던 수많은 결정" 을 직접 마주한 시간이었던 거예요.

그럼에도 직접 만들어 본 가치

비슷한 회고는 의외로 많아요. Mike Bostock(D3 만든 사람)은 "좋은 시각화 도구는 사용자가 보지 않는 곳에서 100가지 결정을 내려준다"고 말한 적이 있고, Observable Plot이나 Vega-Lite 같은 고수준 도구들이 등장한 이유도 결국 "이 결정들을 매번 하기 싫다"는 욕구에서 출발했습니다. 반면 Apache ECharts나 Highcharts처럼 옵션이 수백 개인 라이브러리들이 왜 그렇게 무겁고 복잡한지도, 직접 만들어 보면 비로소 이해가 가죠.

흥미로운 건, 최근에는 Visx(Airbnb)나 Nivo 같은 "중간 추상화" 라이브러리들이 인기를 끌고 있다는 점이에요. 완전한 차트 컴포넌트도 아니고, D3처럼 너무 저수준도 아닌, 축이나 스케일 같은 부품만 제공하는 도구들이죠. 직접 만들어 본 사람만이 이런 도구의 가치를 제대로 알아볼 수 있습니다.

한국 개발자에게 주는 메시지

실무에서 "바퀴를 재발명하지 마라"는 격언은 거의 진리처럼 통합니다. 그래서 차트가 필요하면 Chart.js, 폼이 필요하면 React Hook Form, 상태 관리는 Zustand, 이런 식으로 조합해서 빠르게 만들죠. 이게 잘못된 건 아니에요. 비즈니스 가치를 빠르게 만드는 게 우선이니까요.

다만 가끔은 이미 있는 도구를 한 번쯤 직접 만들어 보는 시간이 개발자로서의 깊이를 만들어 줍니다. 50시간을 들여 라인 그래프를 만들어 본 사람은, 다음에 Chart.js를 쓸 때 옵션 하나하나의 의미를 정확히 알게 되거든요. 디자이너가 "여기 눈금이 좀 이상해요"라고 했을 때 즉시 원인을 짚을 수 있고, 라이브러리가 안 되는 걸 요구받았을 때 "이건 이런 이유로 어렵습니다"라고 설명할 수도 있죠.

사이드 프로젝트로 차트, 라우터, 상태 관리, 폼 검증 같은 "이미 잘 만들어진 것"을 직접 만들어 보세요. 회사 일에 바로 쓰진 못해도, 코드 리뷰의 깊이가 달라집니다.

마무리

라이브러리가 우리에게 주는 건 "기능"이 아니라 "수많은 결정"입니다. 그 결정을 직접 마주해 본 사람이 결국 더 나은 사용자가 되더라고요.

여러분은 최근에 "이미 있는 걸 굳이 직접 만들어 본" 경험이 있나요? 그 경험에서 가장 크게 배운 건 무엇이었나요?