차트를 그리는 사람이 아니라

이 저장소에서 d3 를 찾으면 한 줄이 나온다.

think/branch-strategy.mdx:241
> 다이어그램은 인라인 SVG다. mermaid는 d3와 dagre를 포함해 gzip 500KB가 넘고,

쓰지 않기로 한 이유로만 등장한다. 코드에는 import 가 없다.

그런데 내가 가고 싶은 방향을 정리한 리포트는 권장 스택을 이렇게 적는다 — TypeScript/React → SVG → D3.js → 데이터 변환/SQL → 시각화 이론 → 접근성/성능. D3 가 한가운데 있다.

방향은 주장이다. 이 사이트의 규칙은 주장에 증거를 붙이는 것이므로, 그 스택을 한 칸씩 세어 봤다.

세어 본 결과

SVG 9편. 이 사이트의 도식은 전부 손으로 쓴 인라인 SVG 다. 라이브러리가 없다. currentColor 와 var(--accent) 를 쓰기 때문에 명암 반전을 자동으로 따라가고, 하나가 수백 바이트다.

데이터 2편. make/work-calendar 는 node:sqlite 로 실제 데이터를 재서 "업무 관리 도구"라고 생각한 것이 사실은 배포 관리 도구였다는 걸 발견했다 — 배포 18건 대 업무 11건. think/statistics-notation 은 분포와 표기다.

접근성·성능 3편. think/why-contrast-came-first 의 대비 계약은 pnpm check:contrast 가 실제 비율을 측정해 어긋나면 빌드를 실패시킨다. make/personal-interface 는 JS 예산이 게이트로 묶여 있다.

D3 0편. 그리고 리포트가 요구하는 산출물 셋 — analytical dashboard, 지도/시계열/네트워크 중 하나, 재사용 chart system — 도 전부 0 이다.

세지 못한 칸

시각화 이론 을 0 이라고 적지 않고 "셀 수 없음"으로 뒀다. 정직하려면 그래야 했다.

도식 9개를 그리면서 매번 뭘 어떻게 보여줄지 골랐다. 예를 들어 방금 쓴 think/the-screen-said-it-was-fine 의 도식은 두 상자를 일부러 똑같이 그린다. 화면에서 구별되지 않는다는 것이 그 글의 논지이므로, 도식이 그 구별 안 됨을 재현해야 했다. 차이는 오른쪽 — 나가는 쿼리 — 에서만 액센트로 갈린다.

그건 visual encoding 을 고른 것이다. 다만 이론으로 고른 게 아니라 글의 논지에서 역산했다. 정규화·색 척도·오해를 부르는 축 같은 것을 배운 적이 없고, 그래서 내가 고른 것이 맞았는지 판정할 기준이 나한테 없다.

증거가 0 인 것과 판정 기준이 없는 것은 다르다. 전자는 쓰면 되고 후자는 먼저 배워야 한다.

가장 아픈 칸은 D3 가 아니다

리포트 §2 는 채용에서 실제로 확인되는 역량에 접근성, 키보드 탐색, 색상 안전성 을 넣는다.

이 사이트에 시각화라고 부를 만한 것이 하나 있다. TRACE 의 WebGL 필드다. 막대 하나가 기록 하나이고 높이가 분량, 가로축이 시간순이다.

그리고 docs/PRODUCTION.md 가 스스로 이렇게 적어 뒀다.

- Keyboard access to the WebGL field. The list is the accessible path;
  roving tabindex over the bars is worth doing and is not done.

내가 가장 많이 쓴 주제에서, 내가 가진 유일한 시각화가 떨어진다. 대비 계약을 게이트로 못박고 타깃 크기를 WCAG 기준까지 올려 놓고, 정작 막대는 키보드로 짚을 수 없다. 목록이라는 대체 경로가 있어서 접근 불가는 아니지만, "시각화에 키보드로 접근할 수 있는가"라는 질문에 이 사이트의 답은 아니오다.

D3 0 편은 안 해서 없는 것이다. 이건 해 놓고 빠뜨린 것이라 성질이 다르다.

거절했던 이유가 여기서도 유효한가

think/branch-strategy 에서 mermaid 를 버린 판단은 이랬다 — 다이어그램 하나 그리자고 gzip 500KB 를 로드할 수는 없다. 그 글의 라우트 예산에서 JS 여유가 12KB 였다.

그 판단은 지금도 맞다. 그리고 D3 를 안 쓸 이유로는 옮겨지지 않는다.

차이는 차트가 무엇이냐다. 이 사이트에서 도식은 글을 돕는 삽화다. 삽화 하나에 라이브러리를 붙이면 본문보다 무거워진다. 반대로 analytical dashboard 에서는 차트가 제품 그 자체다. 예산의 분모가 다르다.

같은 저울에 다른 것을 올려 놓고 같은 답이 나오길 기대한 셈이다. 무게를 기준으로 삼은 건 맞았고, 그 기준을 다른 문제에 그대로 들고 간 것이 틀렸다.

그래서 이건 지킬 규칙이 아니라 다시 볼 결정이다. 다만 손으로 SVG 를 9번 써 본 것이 손해는 아니다. scale 과 axis 와 join 이 무엇을 대신해 주는지 알려면, 그것 없이 좌표를 직접 계산해 본 쪽이 빠르다.

이미 하고 있었던 것 하나

리포트의 마지막 문장은 이렇다.

목표는 차트를 그리는 사람이 아니라 데이터 의미를 이해하고, 적절한 시각적 표현을 선택하며, 고성능 인터랙티브 데이터 제품으로 구현하는 사람이다.

가운데 항목 — 적절한 시각적 표현을 선택하는 것 — 은 이 사이트가 이미 하고 있었다. 다만 차트로 한 적이 없을 뿐이다.

이 사이트의 인장이 그렇다. lib/sigil.ts 는 저장소의 커밋 기록을 좌표로 접는다. 칸 하나가 커밋 하나, 깊이가 그 커밋이 직접 바꾼 줄 수, 링 밖으로 튀어나온 표시가 저장소가 스스로 선언한 페이즈다. 64칸 × 3링.

그건 데이터를 시각으로 인코딩한 것이다. 차트라고 부르지 않았을 뿐이다. 그리고 그 마크는 아무도 다른 사람의 사이트에 붙일 수 없다 — 데이터가 다르기 때문이다. 시각화가 장식과 갈리는 지점이 정확히 거기다.

리포트에 대해 내가 확인하지 못한 것

이 글의 근거 절반은 내가 센 것이고, 나머지 절반은 리포트가 든 것이다. 둘을 같은 무게로 쓰면 안 된다.

리포트는 2026년 채용 사례로 MIT Senseable City Seoul 의 Data Visualization Specialist / Creative Coder, Adobe 의 UI Data Visualization Engineer, Netflix 의 Data Visualization Engineer 5, Planet 의 Data Visualization Engineer 를 든다. 나는 그 공고들을 직접 열어 보지 않았다. 직책명이 실재한다는 근거로 인용하되, 각 공고의 요구사항을 내가 검증했다고 적지 않는다.

이 사이트가 자기 숫자에 게이트를 붙이는 이유가 이것이다. 확인한 것과 전해 들은 것을 구별하지 않으면, 읽는 사람이 어느 쪽을 믿어야 할지 알 수 없다.

다음 여섯 달에 대해

리포트에는 6개월 로드맵이 있고, 그대로 옮겨 적지 않겠다. 그건 리포트의 것이고 여기 다시 쓰면 두 벌이 된다.

대신 위에서 센 것이 순서를 바꾼다.

• 1개월차(시각화 기초)를 건너뛰지 않는다. 도식 9개는 매체를 아는 증거지 이론을 아는 증거가 아니다. "셀 수 없음"이 그 뜻이다
• 키보드 접근을 먼저 갚는다. 이미 가진 시각화 하나가 이미 적어 둔 기준에 떨어져 있다. 새 프로젝트 셋을 시작하기 전에 갚는 게 순서다
• D3 는 삽화가 아니라 제품에서 처음 쓴다. 이 사이트의 도식에 D3 를 넣으면 거절했던 판단이 다시 옳아진다

그리고 이 글 자체가 /practice 의 미증명 칸과 같은 것이다. 그 페이지는 이력서가 주장하지만 이 사이트가 증명하지 못한 다섯 개를 미증명이라고 표시한다. 이 글은 같은 일을 과거가 아니라 방향에 했다.

증명되지 않은 칸이 부끄러운 게 아니다. 증명되지 않았다는 걸 적지 않는 게 부끄러운 것이다.