Claude Code로 차트 라이브러리 선택하기: Recharts, Chart.js, D3

먼저 제품 리스크를 정리하기

Claude Code로 차트 라이브러리 선택하기: Recharts, Chart.js, D3의 목적은 화면을 화려하게 만드는 것이 아니라, 전환율, 읽기 쉬움, 모바일 레이아웃, 접근성을 깨지 않으면서 개선하는 것입니다. Claude Code는 빠르게 코드를 만들 수 있지만, 실제 운영에서는 빈 상태, 로딩, 오류, 키보드 포커스, 긴 텍스트, 광고 영역, CTA 위치가 더 중요합니다. 초보자일수록 “동작하는 순간”을 완성으로 착각하기 쉽지만, 실무에서는 빈 데이터, 모바일 폭, 접근성, 기존 CSS와의 충돌까지 확인해야 비로소 공개할 수 있습니다.

함께 볼 글은 claude code dashboard development, claude code data visualization, claude code accessibility 입니다. 공식 자료는 Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2 를 참고하세요. Claude Code에게는 목표, 수정 범위, use case, pitfall, 검증 방법을 명확히 전달해야 생성되는 diff의 품질이 안정됩니다.

Claude Code에 주는 프롬프트

가장 작은 안전한 변경으로 구현해 주세요.
기존 컴포넌트 구조, 디자인 토큰, 라우팅을 유지해 주세요.
use case, pitfall, 접근성, 모바일 표시, 실패 상태를 함께 확인해 주세요.
복사해서 실행 가능한 코드와 review checklist를 함께 반환해 주세요.

이 프롬프트의 목적은 Claude Code에게 “완성된 UI”가 아니라 “깨지기 어려운 변경 과정”을 만들게 하는 것입니다. 특히 기존 사이트에서는 화려한 개선보다, 이탈을 늘리지 않고 문의나 구매 동선을 방해하지 않는 것이 중요합니다.

Use case checklist

랜딩 페이지와 글 페이지: 다음 행동을 자연스럽게 보이게 하되 본문과 CTA를 가리지 않습니다.
SaaS 대시보드: 로딩, 빈 데이터, 오류, 성공 상태가 즉시 이해되어야 합니다.
결제, 가입, 상담 흐름: 시각 효과가 주요 버튼보다 강하면 안 됩니다.
팀 리뷰: Claude Code가 코드와 검증 항목을 함께 남겨야 리뷰 시간이 줄어듭니다.

구현 코드

npm i recharts chart.js react-chartjs-2 d3
npm i -D @types/d3

"use client";

import {
  CartesianGrid,
  Line,
  LineChart,
  ResponsiveContainer,
  Tooltip,
  XAxis,
  YAxis,
} from "recharts";

type Point = {
  date: string;
  revenue: number | null;
  orders: number;
};

const money = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
  maximumFractionDigits: 0,
});

function normalize(points: Point[]) {
  return points
    .filter((point) => Number.isFinite(Date.parse(point.date)))
    .sort((a, b) => Date.parse(a.date) - Date.parse(b.date))
    .map((point) => ({
      ...point,
      label: new Intl.DateTimeFormat("en-US", { month: "short", day: "numeric" }).format(
        new Date(point.date),
      ),
      revenue: point.revenue ?? 0,
      orders: Number.isFinite(point.orders) ? point.orders : 0,
    }));
}

export function RevenueChart({ data }: { data: Point[] }) {
  const rows = normalize(data);

  if (rows.length === 0) {
    return <p role="status">No chart data yet. Check the date range or filters.</p>;
  }

  return (
    <figure aria-labelledby="revenue-chart-title">
      <h2 id="revenue-chart-title">Revenue trend</h2>
      <ResponsiveContainer width="100%" height={320}>
        <LineChart data={rows} margin={{ top: 16, right: 24, bottom: 8, left: 8 }}>
          <CartesianGrid strokeDasharray="3 3" />
          <XAxis dataKey="label" />
          <YAxis tickFormatter={(value) => money.format(Number(value))} />
          <Tooltip formatter={(value) => money.format(Number(value))} />
          <Line type="monotone" dataKey="revenue" stroke="#2563eb" strokeWidth={3} dot={false} />
        </LineChart>
      </ResponsiveContainer>
      <figcaption>Data is sorted by date and null revenue is rendered as zero.</figcaption>
    </figure>
  );
}

라이브러리 선택법: Recharts, Chart.js, D3

차트 라이브러리는 “인기 있으니까”로 고르면 후회합니다. 실무에서는 표시하려는 그래프 종류, 팀의 숙련도, 디자인 자유도, 번들 크기 중 무엇을 우선할지로 결정합니다. Claude Code에게 선정을 맡길 때도 이 세 가지를 후보로 주고 “왜 그것을 선택했는지” 설명하게 하면, 나중에 판단의 근거가 남습니다.

라이브러리	적합한 상황	주의점
Recharts	React에서 KPI 카드나 매출 추이 같은 정석 그래프를 빠르게 출력	복잡한 독자 표현이나 수천 점 렌더링은 약함
Chart.js	React 이외 페이지에서도 사용하고 Canvas로 가볍게 그림	DOM 요소가 아니므로 접근성은 별도로 보완
D3	독자적인 데이터 시각화를 세밀하게 작성	학습 비용이 높고 구현량과 리뷰량이 늘어남

첫 판단은 단순합니다. React 대시보드에서 꺾은선, 막대, 원형 같은 정석 그래프만 출력한다면 Recharts로 충분합니다. React 이외 페이지나 점이 수천 개 이상인 무거운 그래프는 Chart.js의 Canvas 렌더링이 더 안정적입니다. 움직임이 있는 독자 표현이나 보고서 같은 정교한 도면이 필요할 때만 D3를 검토합니다. 고민될 때는 먼저 Recharts로 동작하는 것을 만들고, 표현이 부족해지면 갈아타는 편이 되돌아가는 작업이 적습니다.

작은 대시보드에서 시험했을 때도 처음부터 D3에 손을 대 구현이 불어나면서 리뷰가 따라가지 못했습니다. 정석 그래프는 Recharts, 특수한 한 장만 D3로 역할을 나누는 편이 전체 유지보수가 훨씬 수월합니다. Claude Code에게는 “이 그래프는 Recharts로, 여기만 D3로”처럼 범위를 지정해 부탁하면 불필요하게 고기능 라이브러리가 추가되는 일을 막을 수 있습니다.

빈 데이터, 로딩 중, 오류를 반드시 준비하기

그래프에서 가장 사고가 많은 곳은 데이터가 아직 없을 때의 표시입니다. API가 빈 배열을 반환했거나, 집계가 0건이거나, 가져오기에 실패한 상태를 고려하지 않고 만들면 축만 있는 그래프, 새하얀 영역, 최악의 경우 멈춰버린 화면을 독자에게 보여주게 됩니다. 위 구현 예에서 rows.length === 0일 때 메시지를 반환하는 것은 이 사고를 막기 위해서입니다.

실무에서는 최소한 다음 4가지 상태를 준비합니다. 로딩 중에는 그래프와 같은 높이의 플레이스홀더를 두어 레이아웃이 튀지 않게 합니다. 빈 데이터는 “아직 데이터가 없습니다”처럼 이유나 다음 동작을 제시합니다. 오류는 원인과 재시도 버튼을 표시합니다. 그리고 정상일 때만 그래프 본체를 그립니다.

상태	표시	흔한 실패
로딩 중	같은 높이의 스켈레톤	스피너만 있어 높이가 바뀌고 화면이 튐
빈 데이터	이유와 다음 동작	축만 있는 그래프를 보여줌
오류	원인과 재시도	예외로 페이지 전체가 멈춤
정상	그래프 본체	0건과 정상을 구분하지 않음

Claude Code에 의뢰할 때는 “정상 흐름뿐 아니라 빈/로딩/오류 표시도 함께 만들어 줘”라고 먼저 전달합니다. 이를 말하지 않으면 AI는 성공 경로만 구현하기 쉽고, 운영 데이터에서 반드시 막힙니다. 그래프는 겉보기가 화려한 만큼 깨졌을 때의 인상도 강하게 남으므로, 상태 처리에 들이는 노력은 투자만큼의 가치가 있습니다.

Pitfall checklist

스크린샷만 보고 판단하면 실제 전환 흐름을 놓칩니다.
색상이나 움직임만으로 의미를 전달하면 접근성이 떨어집니다.
모바일 375px 폭을 보지 않으면 가로 스크롤이 생길 수 있습니다.
빈 데이터, 긴 라벨, 느린 네트워크, 새로고침을 확인하지 않으면 운영 중 오류가 납니다.
Claude Code가 무관한 파일까지 고치면 diff가 커져 리뷰가 어려워집니다.

검증 방법

구현 후에는 Claude Code에게 review 전용 요청을 다시 보냅니다. 변경 파일, 위험, 브라우저 확인, 수동 확인을 나누어 받습니다. 그 다음 모바일 폭에서 overflow, 코드 블록, CTA, 포커스 표시, 보조 텍스트를 확인합니다.

수익화 관점

이 주제는 광고, 상품 카드, 상담 링크, 가격표, 리드 폼 같은 매출 표면과 연결됩니다. 팀의 실제 저장소에 적용하고 싶다면 Claude Code 교육과 상담 페이지에서 반복 가능한 도입 흐름을 설계할 수 있습니다.

추가 리뷰 관점

변경 전후 스크린샷을 비교하고 CTA, 광고, 본문, 폼, 코드 블록을 확인합니다.
Claude Code에게 삭제 가능한 코드, 프로젝트와 맞지 않는 이름, 위험한 가정을 물어봅니다.
배포 전 모바일, 데스크톱, 키보드 조작, 느린 네트워크, 빈 데이터, 새로고침을 확인합니다.

실전 검증 메모

구현, review, 모바일 확인을 분리해서 테스트했습니다. 한 번에 크게 바꾸는 방식보다 diff가 작고, 접근성 및 레이아웃 문제를 배포 전에 잡기 쉬웠습니다. Claude Code에게 한 번에 전부 맡기지 않고 구현, 리뷰, 수정의 3단계로 나누는 편이 차분히 검증하기 좋았습니다.