Posit가 공개한 'ggsql' 알파 — SQL 문법으로 쓰는 ggplot2

• Posit가 ggsql 알파 버전을 공개함 — 한마디로 "SQL 문법으로 쓰는 ggplot2"
  • R/Python 없이 순수 SQL 쿼리로 그래프를 그리는 도구. Quarto, Jupyter, Positron, VS Code에서 바로 동작
  • VISUALIZE, DRAW, PLACE, SCALE, LABEL 같은 새로운 SQL 절(clause)을 추가한 확장 문법을 쓴다
  • 18년 동안 R 생태계를 지배해온 ggplot2의 "그래픽 문법(Grammar of Graphics)" 철학을 SQL 위에 그대로 이식

어떻게 생겼나

• 산점도 같은 기본 플롯은 VISUALIZE penguins MAPPING x=bill_len, y=bill_dep DRAW point 식으로 선언형으로 쓴다
  • 색상 카테고리 추가는 매핑 한 줄 추가, 추세선 추가는 레이어 한 줄 추가 — 점진적으로 플롯을 키워나가는 ggplot2 스타일 그대로
  • "정해진 플롯 타입"이 없고 모듈형 레이어 조합으로 모든 그림을 만듬 (히스토그램, 박스플롯, 지터, 바이올린 등)
• SQL 파트와 시각화 파트가 한 쿼리에 공존 — VISUALIZE 키워드가 둘을 구분하는 경계선
  • 앞부분은 백엔드가 지원하는 순수 SQL(블로그 예시는 DuckDB 백엔드)
  • 결과 테이블이 그대로 시각화 파이프라인으로 흘러들어감

왜 또 시각화 라이브러리를 만들었나

• SQL 사용자를 위한 시각화 도구가 애매했음 — R/Python으로 내보내거나, 재현성 떨어지는 BI GUI를 쓰거나, 빈약한 인-쿼리 도구를 쓰는 선택지뿐이었다
• SQL의 관계대수 기반 선언형 철학과 Grammar of Graphics의 선언형 철학이 구조적으로 잘 맞아떨어짐
• R/Python 런타임 없이 독립 실행 파일로 동작하게 만들어서 AI 에이전트나 리포팅 도구에 끼워넣기 쉽게 만드는 게 목표
  • 샌드박싱도 쉬워지고 악성 코드 실행 위험도 줄어듬
• LLM이 SQL을 이미 아주 잘 쓰기 때문에, ggsql도 자연어→시각화 파이프라인에 잘 맞는다고 판단 (이미 querychat에서 써먹고 있음)

로드맵

• 알파 단계라서 앞으로 추가할 것들을 밝혔음
  • Rust로 처음부터 다시 짜는 고성능 라이터
  • 테마 인프라, 인터랙티비티, 공간 데이터 지원
  • Posit Workbench/Positron → Connect 엔드투엔드 배포 플로우
  • ggsql 전용 LSP와 코드 포매터
• ggplot2는 버리지 않음 — 성숙/안정 단계로 유지 보수하면서, ggsql에서 얻은 경험을 역으로 ggplot2에 반영하겠다는 입장

---

기술 맥락

Grammar of Graphics가 왜 중요한 아이디어인지부터 짚고 가면 좋아요. 2005년 Leland Wilkinson이 제시한 이 이론은 "데이터 → 미적 속성(aesthetic) 매핑 → 기하 객체(geom) → 스케일 → 좌표계 → 패싯"이라는 모듈로 시각화를 분해해요. 이 조합만 있으면 어떤 플롯도 만들 수 있거든요. ggplot2가 18년간 R 생태계 표준으로 살아남은 이유가 바로 이 "레이어를 쌓아 올리는" 조합성 때문이에요.

Posit가 굳이 SQL을 고른 건 런타임 문제가 제일 크거든요. ggplot2는 R이 있어야 하고 plotnine은 Python이 있어야 해요. AI 에이전트나 리포팅 툴에 끼워넣으려면 인터프리터를 통째로 번들링하거나 원격 실행 환경을 세팅해야 하는데, 이게 샌드박싱이나 배포 면에서 골치 아파요. 단일 실행 파일 하나로 해결되면 배포가 훨씬 단순해지고 보안 표면도 줄어들어요.

쿼리 푸시다운이 진짜 핵심 기술 결정이에요. 대부분의 시각화 도구는 "데이터를 전부 가져와서 → 클라이언트에서 집계 → 그림" 순서로 돌아가는데, 이건 데이터 웨어하우스 시대에 맞지 않아요. ggsql은 레이어마다 필요한 집계(빈 카운트, 사분위수 등)를 SQL로 번역해서 백엔드에서 실행해요. DuckDB, Snowflake, BigQuery 같은 엔진의 벡터화 집계를 그대로 활용할 수 있다는 얘기라서 10억 행 규모에서도 시각화가 가능한 거예요.

LLM 연동 관점에서도 전략적이에요. 요즘 LLM은 자연어→SQL 변환은 꽤 잘해요. 근데 자연어→matplotlib/ggplot2 코드는 여전히 환각이 많거든요. SQL 문법의 확장으로 시각화를 표현하면 LLM이 이미 학습한 SQL 패턴을 그대로 재사용할 수 있어요. Posit의 querychat 데모가 이 방향의 첫 증명이에요.

한 가지 트레이드오프도 있어요. SQL 문법을 확장한다는 건 각 백엔드가 이 확장 절을 파싱하거나, 아니면 ggsql이 앞단에서 파싱해서 표준 SQL로 내려보낸다는 뜻이에요. 후자면 표준 SQL 호환성은 확보되지만 중간 엔진이 하나 더 끼는 구조예요. 알파 단계에서는 DuckDB 백엔드로 검증 중인 것 같고, Rust 기반 라이터 로드맵이 나온 걸 보면 이 파싱 계층을 성능 최적화하려는 의도가 읽혀요.