Skip to content
Published on

Microsoft Flint 읽기 — 에이전트가 차트를 그리게 만드는 시각화 언어

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
공유하기
Authors

들어가며 — 무엇을 위한 시각화 언어인가

"에이전트를 위한 시각화 언어"라는 문구는 두 가지로 읽힙니다. 하나는 에이전트의 추론이나 실행 궤적을 그림으로 들여다보는 도구, 다른 하나는 에이전트가 스스로 그림(차트)을 그려내게 돕는 도구입니다. Microsoft가 2026년 7월 8일 공개한 Flint 는 후자입니다 — 저도 처음엔 전자로 착각했고, 제목이 그렇게 읽히도록 되어 있으니 먼저 못박아 둡니다. Flint는 에이전트를 시각화하지 않습니다. 에이전트가 데이터로부터 차트를 만들게 합니다.

문제의식은 단순합니다. 보기 좋은 차트를 만들려면 스케일, 축, 눈금, 색, 간격, 레이아웃 같은 낮은 수준의 설정을 잔뜩 적어야 하고, Microsoft Research 블로그의 표현으로 그런 명세는 "장황하고, 깨지기 쉽고, 오류가 잦다(verbose, fragile, and error-prone)"는 것입니다. 사람도 힘든 이 작업을 LLM 에이전트에게 시키면 더 자주 틀립니다. Flint는 Microsoft Research가 중국 인민대학 IDEAS Lab과 함께 만든 오픈소스(MIT)로, github.com/microsoft/flint-chart에 공개돼 있습니다.

Flint이 실제로 하는 일 — 컴파일러가 낮은 수준을 대신 정한다

핵심 발상은 "에이전트에게 완성된 차트 코드를 뱉게 하지 말고, 의도만 적게 하라"입니다. 입력은 세 조각입니다 — 데이터, 각 필드가 무엇을 뜻하는지 알려주는 시맨틱 타입, 그리고 필드를 축·색 같은 시각 채널에 붙이는 인코딩. 나머지 낮은 수준의 결정은 컴파일러가 데이터와 이 힌트로부터 유도합니다.

// Flint 입력 명세 (산점도 예시)
{
  data: { values: myData },
  semantic_types: { weight: 'Quantity', mpg: 'Quantity', origin: 'Country' },
  chart_spec: {
    chartType: 'Scatter Plot',
    encodings: { x: { field: 'weight' }, y: { field: 'mpg' }, color: { field: 'origin' } },
    baseSize: { width: 400, height: 300 },
  },
}

여기서 origin 을 Country 로 선언하면 컴파일러는 그것이 범주형 지리 값임을 알고 적절한 색 팔레트와 범례를 고릅니다. Flint는 이런 시맨틱 타입을 Rank, Temperature, Price, Country 등 70종 이상 갖고 있습니다. 여기에 적응형 레이아웃 이 더해져, 범주 수나 밀도가 바뀌어도 크기·간격·라벨·배치를 스스로 조정해 읽히게 만듭니다 — 사람이 일일이 손보지 않아도 됩니다.

블로그의 히트맵 예시를 기준으로, 이 간결한 명세에서 컴파일러가 대신 채우는 것은 구체적으로 다음과 같습니다.

  • 축과 스케일 — 데이터 범위에 맞춘 눈금·기준선과 날짜/시간 파싱
  • 서식 — 숫자와 축 라벨 포맷
  • 색 — 시맨틱 타입에 맞는 색 스케일과 범례 구성
  • 배치 — 셀 크기, 간격, 전체 레이아웃

복합 차트일수록 이 위임이 크게 남습니다. 워터폴이나 선버스트처럼 순수 Vega-Lite 로는 100줄을 훌쩍 넘기는 종류가 특히 그렇습니다.

간결한 Flint 명세           컴파일러                     백엔드 네이티브 출력
(데이터 + 시맨틱 타입    →   (스케일·축·서식·색·      →    Vega-Lite / ECharts / Chart.js
 + 인코딩)                   레이아웃을 유도)              명세 + 렌더된 차트

이식성도 설계의 핵심입니다. 같은 Flint 명세 하나가 Vega-Lite, Apache ECharts, Chart.js 세 백엔드로 각각 컴파일됩니다 — 라이브러리는 assembleVegaLite(input), assembleECharts(input), assembleChartjs(input) 세 함수가 동일한 ChartAssemblyInput 을 받는 구조입니다. 30종 이상의 차트 타입을 지원하고, flint-chart-mcp 서버를 통해 에이전트가 대화나 코딩 환경 안에서 차트를 만들고 검증하고 렌더할 수 있습니다(데이터를 인라인으로 넣거나 로컬 파일을 읽고, PNG/SVG로 뽑거나 대화형 미리보기를 엽니다). 설치는 npm install flint-chart 와 npx -y flint-chart-mcp 이고, Python 패키지는 예정이라고 밝힙니다.

왜 이게 필요했나 — 신뢰성이라는 진짜 표적

Flint의 진짜 표적은 "더 예쁜 차트"가 아니라 신뢰성 입니다. Flint 팀은 Hacker News 토론에서 이렇게 정리했습니다 — Vega-Lite 같은 문법은 사람에게는 고수준 언어였지만 "에이전트에게는 너무 저수준일 수 있다(too low-level for AI agents)". 시맨틱 타입은 낮은 수준의 시각화 파라미터 전체보다 모델이 추론하기 쉽고, 그래서 완전한 Vega-Lite 명세를 통째로 생성하게 하는 것보다 실패가 적다는 것이 요지입니다. 팀은 실사용 관점의 문제도 짚습니다 — 최종 사용자에게 서비스할 때 "차트가 잘 나오는 성공률 80%는 큰 문제가 될 수 있다(an 80% success rate ... can become a big issue)".

숫자는 어떨까요. Microsoft의 자체 비교에서 Flint는 직접 Vega-Lite를 생성하는 방식(DirectVL)을 세 모델 모두에서 근소하게 앞섰습니다 — GPT-5.1은 16.27 대 15.91, GPT-5-mini는 16.16 대 15.60, GPT-4.1은 15.91 대 15.34. 정직하게 말하면 격차는 크지 않고(모두 0.6점 미만), 제가 읽은 자료는 이 점수의 척도가 무엇인지 명확히 밝히지 않습니다. 그러니 이 표는 "Flint가 압도한다"가 아니라 "일관되게, 그러나 조금 낫다"로 읽는 게 정직합니다. 더 무게 있는 근거는 정량 지표가 아니라, Flint가 이미 Microsoft Research의 AI 데이터 분석 도구 Data Formulator 를 구동하는 데 실제로 쓰이고 있다는 사실입니다.

마치며 — 과잉설계인가, 실용적 신뢰성 계층인가

회의론부터 정직하게 옮깁니다. HN에는 "GPT-3.5 때부터 LLM이 matplotlib를 원샷으로 잘 만들었고 별문제 없었다"는 반론이 있었습니다. 또 다른 시각화 실무자는 "ggplot이나 Observable Plot이면 줄 수가 Flint와 비슷하다"고 지적했습니다 — 즉 줄 수 이득은 주로 장황한 Vega-Lite 대비, 특히 100줄을 넘기는 워터폴·선버스트 같은 복합 차트에서 두드러진다는 뜻입니다. LLM이 JSON을 생성할 때 키를 빠뜨리거나 타입을 틀린다는 우려, 설정 언어가 결국 프로그래밍 언어로 비대해진다는 오래된 함정도 지적됐습니다. 모두 타당합니다.

그럼에도 저는 코어 발상이 설득력 있다고 봅니다. 요점은 "예쁜 차트"가 아니라 검증 가능하고 사람이 고칠 수 있는 중간 표현 입니다. 에이전트가 최종 산출물이 아니라 구조화된 명세를 내놓으면, AI와 무관하게 그 명세를 검사·수정·재사용할 수 있습니다 — HN의 한 표현처럼 상호작용이 "위임에서 협업으로" 바뀝니다. 시맨틱 타입이 영리한 지점도 여기입니다. 모델에게 픽셀 계산을 시키는 대신 "이 열은 가격이다" 정도의 의미만 추론하게 하고, 서식 보일러플레이트는 컴파일러에 맡깁니다.

그래서 제 판정은 이분법이 아닙니다. 차트를 무인으로 대량 생성하는 제품(대시보드, 리포트 자동화, 데이터 어시스턴트)이라면 Flint는 신뢰성·일관성 계층으로 값어치가 있고, 멀티 백엔드와 사람이 편집 가능한 명세가 덤으로 따라옵니다. 반대로 일회성 차트 하나가 필요할 뿐이라면 matplotlib 원샷으로 충분하고, Flint는 과한 도구입니다. 벤치마크 격차가 작다는 사실이 이 결론을 강화합니다 — Flint의 근거는 "전엔 못 하던 걸 한다"가 아니라 "같은 걸 더 자주 옳게 한다"이고, 그 가치는 자기 워크로드에서 실패율을 직접 재봐야 확인됩니다.

참고 자료

Discuss on Twitter • View on GitHub