Derma:code Chart Library

구현에 바로 들어가기 이전에, 가장 유연한 D3로 먼저 만들어 봤습니다. 육각 레이더·게이지·스코어 세 차트를 D3+SVG와 Canvas 두 방식으로 구현해 결과와 구현 비용을 비교했습니다.

사용자가 보는 결과와 렌더링 속도는 거의 차이가 없었습니다. 대신 구현 비용은 달랐습니다. DOM 노드는 65개 대 1개, 번들은 +42KB 대 0, 같은 효과를 구현하는 코드는 Canvas가 49~82% 적었습니다.

D3 방식에서는 요소마다 transition을 따로 제어해야 했고, DOM을 직접 조작하는 방식도 React의 렌더링 구조와 맞지 않았습니다.

DERMA:CODE에 화면이 늘어날 때마다 차트를 새로 스타일링했습니다. 같은 지표를 그려도 화면마다 색과 간격이 달랐고, 수정할 때 여러 화면을 함께 손봐야 했습니다.

차트를 공용 라이브러리로 묶기로 했고, 먼저 어떤 렌더링 방식을 표준으로 삼을지 결정해야 했습니다.

주장하지 않고 쟀습니다. 같은 차트를 Canvas·SVG·Recharts 세 방식으로 구현한 벤치마크 앱을 만들고, 차트 1개·5개·30개를 일반 환경과 CPU 4배 스로틀링 환경에서 비교했습니다.

CPU 4배 스로틀링에서 차트 30개는 Canvas 76fps, SVG 36fps, Recharts 11fps였고, 클릭 반응 시간은 일반 환경에서도 Canvas 7.1ms, SVG 14.66ms였습니다. DOM 노드 수도 60개 / 1,320개 / 1,830개로 차이가 났습니다.

현재 실제 화면의 차트 수만 보면 SVG도 충분했습니다. 다만 공용 라이브러리의 기준을 정할 때는 현재 화면뿐 아니라 애니메이션·인터랙션을 하나의 렌더링 방식으로 통제할 수 있는지, 차트 수가 늘어날 때의 비용까지 함께 고려했습니다.

그 결과 Canvas를 공통 렌더링 방식으로 정하고, 차트별 구현은 하나의 라이브러리 안에서 통일했습니다.

스토리북에서는 정상적으로 표시되었지만, 실제 사용 프로젝트인 DERMA:CODE에 설치하자 클릭 범위가 어긋나고, 레이블이 겹치고, 레이아웃이 틀어졌습니다.

테스트에도 어려움이 있었습니다. jsdom에는 Canvas 구현이 없어 getContext('2d')가 null을 반환했고, isPointInPath() 같은 Canvas API의 동작까지 그대로 검증하기는 어려웠습니다.

초기에는 가짜 context를 만들어 어떤 API가 어떤 인자로 호출됐는지 검증했습니다. 하지만 클릭 판정처럼 Canvas의 실제 기하 연산에 의존하는 로직까지 목킹으로 재현하는 데는 한계가 있었습니다. 목 파일을 더 정교하게 만드는 대신, Canvas에 의존하는 로직 자체를 줄이기로 했습니다.

히트 판정 로직을 Canvas에서 분리해 순수 함수로 추출했습니다. 좌표와 도형 정보만 받아 안팎을 판정하도록 만들어 Canvas 없이도 테스트할 수 있게 했습니다. 나머지 렌더링은 Vitest와 Canvas 2D mock으로 검증했습니다.

팀이 실제로 사용할 수 있는 경로를 설치·버전·문서·검수 네 가지로 나눠 만들었습니다.

pnpm 모노레포로 라이브러리·데모·벤치마크를 분리하고, tsup으로 CJS와 ESM을 함께 배포하면서 타입 선언도 자동 생성했습니다. 태그를 푸시하면 GitHub Packages에 배포되도록 구성했습니다.

색·타이포그래피·간격·투명도·선 굵기는 디자인 토큰으로 정의하고, 4종 프리셋과 인스턴스별 override를 지원하도록 만들었습니다.

Storybook에는 각 차트와 상태를 등록해 디자이너가 코드 없이 결과를 확인할 수 있도록 했습니다.