원문: https://github.com/facebook/astryx/wiki/Chart-System-Architecture · 번역 기준: 2026-09-03
Astryx에서 데이터 시각화를 어떻게 생각하는지에 대한 문서입니다 — 차트가 해결하는 문제, 아키텍처가 강제하는 정확성 보장, 그리고 개발자에게 맡겨진 디자인 선택.
일반적인 Astryx 컨벤션은 API Conventions와 Astryx Philosophy를 보세요.
차트는 거짓말을 합니다. 보통은 고의가 아닙니다 — 하지만 대부분의 차트 라이브러리의 기본 동작은 자신도 모르는 사이에 오해를 부르는 시각화를 만들기 쉽게 되어 있습니다.
흔한 실패 양상:
겹쳐진 데이터셋이 서로 다른 scale을 사용합니다. 같은 차트 위의 두 라인이 비교 가능해 보이지만 실제로는 서로 다른 y-domain을 통해 매핑되어 있습니다. 시각적 관계가 임의적입니다. 차트 컴포넌트들이 각자 독립적으로 자기 범위를 계산할 때 일어납니다.
축과 mark가 어긋납니다. y축은 0–100이라고 말하는데, bar 컴포넌트가 자기 데이터 부분집합에서 domain을 다시 계산했기 때문에 실제 bar는 다른 범위로 매핑되어 있습니다. Grid 라인도 일치하지 않습니다.
스트리밍 데이터가 요동칩니다(jitter). 실시간 차트가 매 프레임마다 자동 스케일링을 하므로 축이 끊임없이 널뜁니다. 차트 맨 위에 있던 값이 새 포인트가 domain을 늘렸다는 이유로 갑자기 중간에 와 있습니다.
조용한 데이터 축소(data reduction)가 outlier를 숨깁니다. 큰 데이터셋은 렌더링을 위해 downsample되는데, 순진한 접근(매 N번째 포인트 건너뛰기)은 애초에 차트를 보는 이유였던 스파이크를 떨어뜨립니다.
색이 데이터를 인코딩하지만 사람을 배제합니다. 지각적으로 순서화되지 않은 sequential 팔레트는 크기에 대해 오해를 부릅니다. 색맹 안전(colorblind-safe)하지 않은 categorical 팔레트는 남성 사용자의 8%를 배제합니다.
이것들은 edge case가 아닙니다. 대부분의 차트 접근법의 기본 동작이며, 알아채기 어렵고 그대로 행동에 옮기기 쉬운 방식으로 미묘하게 잘못된 차트를 만들어 냅니다.
이 문제들 중 일부는 객관적인 답이 있습니다 — 축이 데이터와 일치하지 않는 차트는 틀린 것입니다, 그것으로 끝입니다. 다른 것들은 맥락에 따라 정답이 달라지는 판단의 문제입니다.
우리는 이를 두 tier로 나눕니다.
이것들은 문서가 아니라 아키텍처로 enforcement됩니다. Mark 컴포넌트는 물리적으로 형제들과 다른 scale로 렌더링할 수 없습니다. 사용 가능한 유일한 scale이 context 안의 그것뿐이기 때문입니다.
| 보장 | 메커니즘 |
|---|---|
| 모든 mark는 하나의 좌표 공간을 공유 | React context 안의 단일 yScale/xScale. 컴포넌트는 그것을 읽습니다. 자기 것을 만드는 컴포넌트는 없습니다. |
| 축이 데이터와 일치 | 축은 mark와 같은 context scale에서 읽습니다. 어긋날 수가 없습니다. |
| 겹쳐진 데이터셋은 비교 가능 | 같은 scale, 같은 픽셀 매핑. 시리즈 A의 값 50에 있는 포인트와 시리즈 B의 값 50에 있는 포인트는 같은 y-픽셀에 놓입니다. |
| SVG와 WebGL이 일치 | 둘 다 context의 yScale(value)를 호출합니다. 렌더링 백엔드는 세부사항이지 좌표계가 아닙니다. |
| Domain은 확장될 뿐, 절대 잘리지 않음 | yDomain은 하한(floor)을 설정합니다. 이를 초과하는 데이터는 범위를 넓힙니다 — 아무것도 조용히 잘려 나가지 않습니다. |
| 스트리밍은 차트의 scale을 사용 | ChartStreamGL은 자체 내부 매핑이 아니라 context의 yScale을 읽습니다. |