AI 시대에도 ggplot의 API는 최고의 차트 API라고 봄. “Grammar of Graphics”는 단순한 마케팅 문구가 아니라, 가능한 모든 정성적 그래픽을 표현할 수 있는 문법을 실제로 만들려는 시도였음
그 과정은 https://link.springer.com/book/10.1007/0-387-28695-0에 담겨 있음. 종이와 펜으로 그리던 옛 그래프를 조사하다 이 책을 발견했는데, 호주중앙은행의 1960~1980년대 연차보고서 차트에는 개성이 있었던 반면 2000년대 초에는 밋밋한 Excel 차트로 바뀌었음
ggplot이 옛 차트의 매력을 완전히 재현하지는 못해도 정보 전달 방식은 많이 참고한 듯함. 20.1절에서는 나폴레옹의 러시아 원정을 표현한 Minard 그래프를 재현하며, 비슷한 예는 https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...에서 볼 수 있음
pyplot과 그 위에 구축된 API보다 결과물이 보기 좋고, pyplot은 래스터 기반 렌더링과 텍스트 처리에 제약이 큰 듯함. ggplot은 R 생태계에 있어 소프트웨어 엔지니어에게 덜 알려졌지만, Node.js와 Python 생태계에서도 이 API를 더 많이 참고했으면 함

Wilkinson의 Grammar of Graphics가 ggplot에 영감을 준 것이며, 해당 교재에는 ggplot이 아예 나오지 않음
같은 철학에서 영감을 받아 만든 DSL인 Algraf도 공개했음: https://williamcotton.github.io/algraf/demos. 데모에 Minard 그래프도 포함됨

Flint와 AI에게 Vega-Lite 명세를 직접 생성하게 하는 방식을 모두 써봤는데, Flint가 더 나은 해법은 아니었음
Flint는 미리 정해진 차트 유형을 낮은 수준으로 맞춤화할 때는 괜찮지만, 에이전트나 하위 에이전트가 Vega 명세를 직접 만들면 시계열의 최솟값·최댓값 표시나 특정 사건 날짜의 설명 표식처럼 훨씬 유연하고 품질 높은 시각화가 가능함
다만 Vega-Lite는 명세 검증과 구체적인 지침이 필요하고 버그와 특이 동작을 계속 처리해야 함. 차트 제작을 별도 기술로 구축하지 않고 빠르게 시작하려면 Flint가 더 안정적임

여러 차트 백엔드를 하나의 인터페이스로 다루려는 것 같은데, AI가 Flint를 작성할 수 있다면 곧바로 백엔드 코드를 작성하게 하면 되지 않나 싶음. 백엔드를 교체 가능하게 만들어야 할 이유는 불분명함
다만 LLM을 위한 단순한 API라면 토큰 효율을 높일 수 있다는 장점은 있음

차트 백엔드마다 지원하는 유형이 다름. 프로젝트 예시처럼 ECharts 선버스트와 Vega-Lite의 패싯 막대그래프 사이를 쉽게 전환할 수 있다면 매우 유용함

AI용 DSL은 별로 타당하지 않음. 모델은 기존 그래픽 라이브러리로 학습됐고 이미 이를 꽤 잘 다룸
장기적으로 Flint를 공개한 뒤 연구소들이 이 DSL에 과적합하도록 “그래픽 벤치마크”를 만들 수는 있겠지만, 너무 많은 작업이 필요해 보임

추상화가 어느 수준부터 과해지는 것인지 모르겠음. Plotly나 Plotly Express로 충분하지 않은지, 또 하나의 JSON 명세가 어떻게 새로운 시대를 연다는 것인지 의문임

흥미롭지만 정말 필요한지는 모르겠음. Apache ECharts를 비롯해 성숙한 차트 라이브러리가 이미 많은데, 결국 기존 바퀴를 다시 만드는 과정처럼 보임
새 도구가 출시되고 기능이 계속 덧붙은 뒤, 약간 다른 설계와 문법을 채택한 또 다른 도구가 원래 도구를 대신하는 일이 반복됨
계층형 선버스트에는 ECharts, 통계·분석 추적선에는 Plotly, 통합문서 안에서 편집할 차트에는 Excel처럼 백엔드 고유의 강점을 활용할 수도 있음. 아니면 마음에 드는 차트 라이브러리 하나를 골라 기능을 제대로 익히는 편이, 여러 라이브러리의 사전 설정만 섞고 세부 조정은 하지 않는 것보다 나음