Microsoft, AI 에이전트를 위한 시각화 언어 Flint 공개

TL;DR Highlight

Microsoft가 LLM/AI 에이전트가 차트를 쉽게 생성할 수 있도록 설계된 고수준 시각화 DSL(도메인 특화 언어) Flint를 오픈소스로 공개했다. 에이전트가 복잡한 시각적 세부사항 대신 의미론적 명세만 다루면 되도록 추상화 계층을 제공하는 게 핵심이다.

Who Should Read

LLM 기반 데이터 분석 에이전트나 AI 어시스턴트에 차트 생성 기능을 붙이고 싶은 백엔드/풀스택 개발자. 특히 AI가 생성하는 시각화 결과물의 품질이 들쭉날쭉해서 고민인 팀에게 유용하다.

Core Mechanics

Flint는 AI 에이전트가 차트를 생성할 때 scales, axes, spacing, layout 같은 저수준 시각적 파라미터를 일일이 지정하지 않아도 되도록, 고수준 의미론적 명세(semantic specification)만 작성하면 나머지를 자동으로 처리해주는 시각화 언어다.
기존 차트 생성 방식의 딜레마가 있다. 단순한 차트 스펙은 LLM이 안정적으로 생성하지만 시스템 기본값에 의존해 품질이 낮고, 세부사항이 가득한 복잡한 스펙은 품질은 좋지만 LLM이 신뢰성 있게 생성하기 어렵다. Flint는 이 간극을 좁히는 것을 목표로 한다.
Flint의 핵심 설계 철학은 '시각화 과정을 마지막 단계로 분리'하는 것이다. AI는 고수준 의미론적 명세만 다루고, 실제 레이아웃 최적화와 시각적 결정은 Flint 컴파일러/엔진이 처리하는 구조다.
데이터 필드에 'Category', 'YearMonth', 'Profit' 같은 semantic type을 붙이고, chartType과 encodings(x, y, color, size 등)를 지정하는 방식으로 스펙을 작성한다. JSON 형식이며 MCP(Model Context Protocol) 연동 설정도 공식 문서에서 제공한다.
오픈소스로 공개되었으며, 프로젝트 페이지(https://microsoft.github.io/flint-chart/)와 MCP 연동 가이드(https://microsoft.github.io/flint-chart/#/mcp)가 함께 제공된다.
에이전트 시스템에서 나타나는 패턴, 즉 'LLM이 중간 표현(IR, Intermediate Representation)을 생성하고 → 결정론적 컴파일러/생성기가 실제 결과물을 만드는' 구조의 좋은 사례로 커뮤니티에서 주목받고 있다.

Evidence

Flint의 필요성 자체에 의문을 제기하는 댓글이 있었다. 'GPT 3.5 시절부터 LLM이 matplotlib을 one-shot으로 잘 써왔고, 데이터 시각화에 실제 문제를 경험한 적이 없다. 에이전트가 시각화를 못 만드는 구체적인 상황이 뭔지 모르겠다'는 의견이었다. 실제로 소규모 분석 에이전트를 만들어보고 있는 다른 댓글 작성자도 LLM(작은 오픈소스 모델 포함)이 Python/R 시각화를 꽤 잘 한다고 공유했다.
JSON 기반의 'stringly typed' 설계를 비판하는 의견이 있었다. TypeScript 라이브러리로 만들었다면 타입 안전성과 개발자 경험이 훨씬 좋았을 것이라며 구체적인 TypeScript 타입 코드까지 작성해 대안을 제시했다. 다만 해당 댓글 작성자는 나중에 실제 소스코드를 보니 자신의 가정보다 훨씬 완성도 있다고 인정하며 일부 수정했다.
Vega(데이터 시각화를 위한 기존 DSL)와의 차별점이 불분명하다는 지적이 있었다. Vega도 이미 표현력 있는 DSL이고 LLM 학습 데이터에 충분히 포함되어 있을 텐데, Flint가 구체적으로 어떤 점에서 더 나은지 설명이 부족하다는 의견이었다.
Flint와 독립적으로 비슷한 아이디어를 이미 구현했다는 경험담이 공유됐다. 로컬 AI 에이전트를 만드는 과정에서 JSON 'Lego 블록' 형태로 차트를 포함한 리포트를 생성하고, 생성 후 검증 및 재시도 단계를 붙이는 방식을 썼더니 일관성 있는 출력 레이어가 만들어졌다고 했다.
'LLM이 verbose한 저수준 코드를 못 다루는 게 문제가 아니다'라는 예리한 반론도 있었다. LLM은 Assembly나 SPIR-V도 읽을 수 있다. 진짜 문제는 LLM이 시각적 공간 구성(spatial composition)을 인간처럼 시각적으로 비교할 수 없다는 것이고, 그래서 깊은 중첩 구조나 숨겨진 상태 없이 LLM이 추론하기 쉬운 코드 형태의 시각화 표현이 필요하다는 분석이었다.

How to Apply

AI 에이전트에 데이터 시각화 기능을 붙이려는 경우, Flint의 MCP 연동 가이드(https://microsoft.github.io/flint-chart/#/mcp)를 참고해 에이전트가 Flint 스펙을 생성하고 렌더링 엔진에 넘기는 파이프라인을 구성하면, 에이전트가 복잡한 시각적 세부사항을 직접 다루지 않아도 품질 있는 차트를 얻을 수 있다.
AI 에이전트가 matplotlib이나 D3.js 코드를 직접 생성하도록 했더니 결과물 품질이 들쭉날쭉하다면, Flint처럼 '에이전트는 고수준 의미론적 명세(어떤 필드가 무슨 의미인지, 어떤 차트 타입인지)만 생성하고, 실제 렌더링 파라미터는 별도 엔진이 결정하는' 아키텍처로 분리하는 방식을 검토해볼 수 있다.
LLM 에이전트 시스템을 설계할 때 Flint 사례처럼 'LLM이 중간 표현(IR)을 생성 → 결정론적 컴파일러/렌더러가 최종 결과물 생성'하는 패턴을 활용하면, 에이전트 출력의 일관성과 신뢰성을 높일 수 있다. 이 패턴은 차트 외에도 문서 생성, UI 컴포넌트 생성 등 다양한 도메인에 적용 가능하다.

Code Example

snippet

// Flint 스펙 예시 (JSON 형식)
{
  "data": { /* 실제 데이터 */ },
  "semantic_types": {
    "game": "Category",
    "period": "YearMonth",
    "newUsers": "Profit"
  },
  "chart_spec": {
    "chartType": "Heatmap",
    "encodings": {
      "x": "period",
      "y": "game",
      "color": "newUsers"
    },
    "chartProperties": {
      "colorScheme": "redblue"
    }
  }
}

// 댓글에서 제안된 TypeScript 타입 대안
type SemanticType = "Category" | "YearMonth" | "Profit";
type ChartType = "Heatmap" | "BarChart" | "LineChart" | "ScatterPlot";

interface ChartSpec {
  chartType: ChartType;
  encodings: { x: string; y: string; color?: string; size?: string; tooltip?: string; };
  chartProperties: { colorScheme: string; [key: string]: unknown; };
}

interface ChartConfig<TData = Record<string, unknown>> {
  data: TData;
  semantic_types: Record<string, SemanticType>;
  chart_spec: ChartSpec;
}

Terminology

DSLDomain-Specific Language의 약자. 특정 목적에만 집중해서 설계된 미니 언어. 예를 들어 SQL은 데이터 조회 전용 DSL이고, Flint는 차트 명세 전용 DSL이다.

IRIntermediate Representation(중간 표현)의 약자. 컴파일러에서 원본 코드와 최종 결과물 사이의 중간 단계 표현. 여기서는 LLM이 생성한 Flint JSON 스펙이 IR 역할을 한다.

semantic type데이터 필드가 '어떤 의미를 가진 값인지'를 나타내는 타입. 예를 들어 'period' 필드가 단순한 문자열이 아니라 '연월(YearMonth)' 데이터임을 명시하면, 렌더러가 그에 맞는 시각적 처리를 자동으로 해준다.

MCPModel Context Protocol의 약자. AI 에이전트가 외부 도구나 서비스를 호출할 때 쓰는 표준 프로토콜. Flint가 MCP를 지원한다는 건 Claude나 다른 MCP 호환 에이전트에서 바로 Flint를 도구로 쓸 수 있다는 의미다.

stringly typed타입 시스템 없이 모든 값을 문자열로 표현하는 방식을 비꼬는 표현. JSON에서 'chartType: "Heatmap"' 같이 문자열로 열거형을 표현하면, 오타가 나도 컴파일 타임에 잡을 수 없다.

layout optimization engine차트의 실제 배치(여백, 축 위치, 레이블 크기 등)를 자동으로 계산해주는 엔진. Flint에서 개발자가 이런 세부사항을 직접 지정하지 않아도 되는 이유가 이 엔진 덕분이다.