Microsoft, AI 에이전트용 시각화 언어 Flint 공개

 (microsoft.github.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Flint는 AI 에이전트가 사람이 편집할 수 있는 짧은 명세로 표현력 있는 차트를 만들도록 돕는 시각화 중간 언어임
  • 컴파일러가 데이터와 의미 타입, 차트 유형, 인코딩을 해석해 스케일·축·간격·레이아웃 같은 저수준 설정을 자동으로 채움
  • 46개 차트 유형과 83개 갤러리 예제를 제공하며, Vega-Lite, ECharts, Chart.js 렌더링을 지원함
  • TypeScript / JavaScript 환경에서는 npm으로 설치할 수 있고, 에이전트 워크플로에서는 MCP 서버를 사용할 수 있음
  • 백엔드별 API 차이를 통합 인터페이스 뒤에 숨겨, 같은 명세에서 렌더러 전환이나 차트 설계 변경을 더 쉽게 처리함

Flint가 해결하려는 문제

  • Flint는 Microsoft Research 프로젝트로, AI 에이전트가 간단하고 사람이 편집 가능한 차트 명세에서 차트를 생성하도록 설계된 시각화 중간 언어임
  • 명세는 데이터, 의미 타입, 차트 명세로 구성됨
    • 예시 명세는 period를 YearMonth, totalUsers를 Quantity, gameType과 region을 Category로 지정함
    • Line Chart에서 region을 column, period를 x, totalUsers를 y, gameType을 color에 바인딩해 지역별 월간 활성 사용자 라인 차트를 만듦
  • npm으로 TypeScript / JavaScript 환경에 설치할 수 있음
  • 에이전트 워크플로에서는 MCP 서버를 사용할 수 있음
  • gallery에서 46개 차트 유형과 83개 예제를 볼 수 있음

명세를 차트로 바꾸는 방식

  • Flint는 압축된 명세에서 시작해 Vega-Lite 같은 백엔드 네이티브 명세를 생성하고, 필요한 저수준 세부 설정을 채워 차트를 렌더링함
  • 의미 타입은 데이터 필드의 의미를 표현함
    • 예시는 Rank, YearMonth, Delta, Temperature 같은 타입을 포함함
    • Flint는 이를 바탕으로 파싱, 스케일, 축, 포매팅, 색상 체계 같은 차트 설정을 추론함
    • 순 신규 사용자를 게임과 월별로 보여주는 히트맵에서는 시간 값 파서, 축 포매팅, 발산 색상 체계와 중간점을 의미 타입 기반으로 결정함
  • 자동 레이아웃 최적화는 탄력적 레이아웃 모델과 banking 원칙을 기반으로 함
    • 컴파일러가 크기, 간격, 배치를 동적으로 관리해 차트가 캔버스에 맞도록 조정함
    • 그룹 막대 차트 수가 늘어나면 캔버스를 늘리고 band width를 줄여 조밀한 버전도 캔버스에 맞춤
  • 차트 설계 변경은 차트 유형 전환과 시각 인코딩 재바인딩으로 처리할 수 있음
    • 2000년 미국 인구조사의 성별·연령별 인구 분포 faceted bar chart를 pyramid chart로 바꿀 때, 사용자는 차트 유형만 바꾸고 나머지는 컴파일러가 처리함

렌더링 백엔드와 사용 가능 상태

  • Flint는 Vega-Lite, ECharts, Chart.js 전반에서 46개 차트 유형을 지원함
    • 서로 다른 API와 프로그래밍 모델을 통합 인터페이스 뒤에 숨김
    • Vega-Lite에 네이티브 sunburst가 없을 때 ECharts로 전환할 수 있음
    • 지역 × gameType × game 계층 구조 시각화에는 그룹 막대 차트보다 sunburst chart가 더 나은 대안으로 제시됨
  • Flint는 오픈소스이며 바로 사용할 수 있음
  • 시작 지점으로 GitHub와 갤러리 예제가 제공됨
  • Microsoft Research가 IDEAS Lab 및 Renmin University of China와 협력해 Flint를 구축함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “AI 에이전트용”이라는 마케팅이 왜 필요한지는 알겠지만, 결국 차트를 표현하기 쉬운 언어라는 점만으로도 충분히 인상적이고 유용함

    • 이 말은 아무리 강조해도 지나치지 않음. “에이전트에 좋다”는 건 결국 자기 설명적이고, 조작감이 명확하며, 안전한 기본값과 간결하거나 제어 가능한 출력, 프로그래밍 가능한 인터페이스를 갖췄다는 뜻이고, 이런 특성은 사람에게도 도움이 됨
    • 이게 말 그대로 MCP 서버를 통해 AI 에이전트가 접근하도록 만든 것 아닌가 싶음. 그렇다면 마케팅에서 AI 에이전트를 강조하는 건 꽤 중요해 보임
    • 이렇게 요약하는 게 맞아 보임. 화려한 설명은 결국 “데이터를 보고 차트가 어떻게 보여야 할지 알아서 정한다”는 말을 길게 한 것 같음
      페이지에서도 “스케일, 축, 간격, 레이아웃 같은 장황한 저수준 매개변수를 요구하는 대신, Flint 컴파일러가 데이터, 의미 타입, 차트 타입, 인코딩에서 최적화된 차트 설정을 도출한다”고 설명함
    • 에이전트가 생성하기도 쉽지만, 사람도 특히 UI가 있으면 편집하기 쉬운 형태임
    • 패키지를 보면 기존 차트 라이브러리 위에 구축된 형태임

  • 에이전트 시스템에서 새 패턴이 나타나고 있고, 이 프로젝트가 좋은 예시임
    LLM이 생성해서 넘기는 어떤 중간 표현(IR) 을 두고, 그 위에 컴파일러나 코드 생성기 같은 결정적 계층을 얹는 방식임. 가까운 미래에 이런 구조를 더 자주 보게 될 것 같음

    • Claude가 PPT 덱을 직접 XML로 만들지 않고 Python 코드를 작성해서 생성하는 걸 처음 봤을 때 꽤 “아하” 하는 순간이었음. 많은 작업이 이런 경로로 갈 것 같고, 장기적으로는 약간 제한적이고 해킹처럼 느껴지지만 당분간은 100% 맞는 접근으로 보임
    • 이 아이디어에 완전히 동의함. 지난 한 달간 한 에이전트 코딩 작업은 모두 중간 표현을 통해 진행했고, 반복도 주로 그 계층에서 했음. 이 방식으로 결정적인 코드 출력에 꽤 가까이 갈 수 있다는 게 놀라움
    • 잘 설계된 중간 계층은 AI와 독립적으로 검증과 제어를 가능하게 함. 이러면 인간과 AI의 상호작용이 위임에서 협업으로 바뀜
    • 맞음. 에이전트 시스템은 처음부터 이런 패턴이었음. 느슨하게 생성하고, 입력이 검증될 때까지 구멍에 맞는 모양과 크기가 나올 때까지 계속 재시도하는 방식임
    • 프로그래밍은 그 어느 때보다 살아 있음

  • 페이지에는 없지만, 데이터 시각화를 만들 때 접근성을 설계 단계에서 반영하는 게 정말 중요함
    이 팟캐스트에는 관련 짧은 인터뷰가 잘 정리되어 있음: https://open.spotify.com/episode/18dHTAxCCeIaLOTch6tRld
    인터뷰 대상은 이 분야에서 꽤 유명해 보이는 Frank Elavsky이고, 접근성 감사용 휴리스틱, 원칙, 가이드라인을 담은 Chartability 프로젝트도 만들었음: https://chartability.github.io/POUR-CAF/

  • 이게 Vega 자체보다 어떻게 더 낫거나 다른지 구체적인 설명이 있는지 궁금함: https://vega.github.io/vega/docs/specification/
    Vega는 이미 시각화를 위한 표현력 있는 DSL이고, LLM 학습 데이터에도 꽤 널리 포함되어 있을 것 같음

    • 예전에는 Vega가 사람에게는 고수준 언어였지만, 지금은 AI 에이전트에게는 오히려 조금 저수준일 수 있음. 에이전트가 보기 좋은 차트를 만들려면 저수준 매개변수를 많이 써야 하고, 그 결과 안정적으로 작성하기 어려워짐
      Flint는 더 높은 수준의 추상화라 명세가 훨씬 짧고 단순하며, 컴파일러가 저수준 결정을 도출해서 보기 좋은 차트를 만들도록 함. 즉 예전에는 긴 프로그램이 필요했던 좋은 차트를 에이전트가 짧은 프로그램으로 만들 수 있게 해줌
    • 나도 Vega-Lite와 비교하면 어떤지 궁금했음. Vega-Lite도 비교적 고수준이고 선언적이며, 문법도 Flint와 비슷해 보임

  • “단순한 차트 명세는 안정적일 수 있지만 시스템 기본값에 의존해 생성 차트 품질이 낮고, 복잡한 명세는 보기 좋은 차트를 만들 수 있지만 장황해서 에이전트가 안정적으로 다루기 어렵다”는 주장에 크게 공감되지는 않음
    분석 에이전트를 만드는 소수의 작업 경험으로는, LLM이 Python과 R로 시각화를 꽤 잘 만든다는 점이 인상적이었음. 작은 공개 가중치 모델도 마찬가지였고, 모호한 부분을 조금 반복해서 다듬으면 단점이 사라지는 경우가 많았음. 이 주장을 뒷받침하거나 문제가 생기는 지점을 보여주는 연구 흐름이 있는지 궁금함

    • 더 단순한 명세는 더 단순한 에이전트가 사용할 수 있음. 아마 여기서의 용도는 하나의 큰 모델이 시각화를 하나씩 만드는 대신, 작고 저렴한 에이전트가 병렬로 쓰는 쪽일 수 있음
      개인적으로 Claude와 ChatGPT는 ggplot 모델을 잘 생성하지만, 커스터마이징이 많아지면 조금 복잡해짐
    • 표현력뿐 아니라 안정성과 상호작용성도 고려하고 있음. 전문가가 아닌 사용자를 대상으로 하거나 작은 모델을 쓸 때는, 표현력이 좋으면서도 단순한 명세가 도움이 됨

  • “스케일, 축, 간격, 레이아웃 같은 장황한 저수준 매개변수”라는 설명은 Microsoft가 서로 다른 두 가지를 섞고 있는 것 같음
    LLM은 코드가 저수준이고 장황한지 자체를 크게 신경 쓰지 않고, 어셈블리나 SPIR-V도 잘 읽을 수 있음. 진짜 문제는 시각적 구성임. LLM은 사람과 다르게 “보기” 때문에 시각 비교를 통한 공간 구성 이해가 자연스럽지 않고, 우회하려면 코드 형태의 시각화처럼 LLM이 추론하고 이해하기 쉬운 표현을 제공해야 함. 즉 깊게 중첩되어 있거나 숨은 상태를 추론해야 하는 구조가 아니면 됨
    또 Flint가 JSON에서 문자열 키 중심으로 타입을 다루는 결정에는 동의하기 어려움. 실제 명세를 보면 그냥 사람이 쓰기 좋은 TypeScript 라이브러리로 만들 수도 있었고, 그 편이 훨씬 나았을 것 같음. 나중에 소스를 실제로 보니 문서만 보고 가정한 목업보다 훨씬 완성도 있고 정교했지만, “문자열 키 JSON 대 진짜 제네릭 작성 표면”이라는 핵심 불만은 여전히 남음

    • chartType 부분은 템플릿이 더 확장 가능해야 해서 그리 우아하지 않다고 봄. 이 부분은 수정이 필요함
      다른 부분은 시각화나 다이어그램 라이브러리에서 JSON을 쓰는 게 꽤 일반적임. 서로 다른 렌더링 맥락으로 쉽게 옮길 수 있기 때문임
    • JSON이 최적의 명세 언어는 아니라는 데 동의하지만, 각 프로젝트가 저마다의 명세를 새로 쓰기 시작하는 것보다 나은지는 생각해볼 문제임
      관련 글: https://www.openui.com/blog/stop-making-ai-write-json
    • 아쉽지만 LLM에서 데이터나 코드를 넣고 빼는 가장 안정적인 방법으로는 JSON에 묶여 있는 것 같음. 더 나쁜 YAML일 수도 있었음
      LLM 예측 가능성을 높이는 커스텀 DSL에는 관심이 있고, Microsoft 같은 공룡도 이걸 이해한 듯해 반가움. https://slangify.org/examples의 Contacts 예시는 VCARD와 JCARD를 왕복 변환하면서 직접 DSL을 쉽게 만드는 방식임

  • “좋은 컴파일러가 처리해야 할 시각적 결정을 명시적으로 하게 만든다”는 설명을 보면, Graphviz가 같은 이유로 있는 것 아닌가 싶음
    선언 언어로 JSON을 쓰는 걸 보니, LLM이 JSON을 잘 다루는 건 인정해도 사람이 소비하기 좋은 문법은 아님

    • 사실 시각화에서 사람이 쓰는 공통 언어로서 JSON은 꽤 오래전부터 있었음. 선언형 문법의 장점은 사용자가 UI에서 드래그 앤드 드롭이나 클릭으로 명세를 효과적으로 조작할 수 있다는 점임
      Flint는 에이전트가 스케일, 축, 0 기준, 단계 크기 같은 저수준 매개변수를 건너뛰도록 의도적으로 설계했음. 이런 요소는 보기 좋은 차트에 매우 중요하고, 컴파일러가 동적으로 최적화함. 그래서 AI 에이전트가 더 쉽게 다룰 수 있음
    • 맞음. 솔직히 이건 출시하자마자 막힌 느낌이고, 기존에 있던 것보다 딱히 낫지 않음

  • 의미 타입을 추가 포맷 요소로 쓰는 건 매우 유용함. 많은 포맷 상용구를 간결하게 인코딩해주기 때문임
    Flint 타입 레지스트리를 공유하거나 확장 가능하게 만들 계획이 있는지 궁금함. 아예 데이터 속성 자체로 두지 않는 이유도 궁금함. Vega-Lite 위에서 더 높은 수준의 연결형 차트를 만들 때 거의 같은 명세에 도달했음

  • 이 프로젝트의 요점을 잘 모르겠음. GPT-3.5 시절부터 LLM은 matplotlib을 한 번에 만들어낼 수 있었던 것 같음
    데이터 시각화에 LLM을 많이 써봤지만 별문제를 겪지 않았음. 에이전트가 시각화 생성에서 구체적으로 어디서 어려움을 겪고, Flint가 그걸 어떻게 해결하는지 사례가 궁금함

    • 여기에는 약간의 마지막 20% 문제가 있음. 채팅창에서 GPT와 대화하며 계속 방향을 잡아주면, 파워 유저에게는 대체로 괜찮음
      하지만 최종 사용자를 위한 도구에 넣으면 보기 좋은 차트 생성 성공률 80%가 큰 문제가 되기 시작함. 데이터 분석 시스템을 만들 때 이런 일을 겪었음. matplotlib이나 Vega-Lite를 직접 생성하게 하면 안정성, 표현력, 비용 시간과 토큰을 동시에 달성하기 어렵고, 그래서 일부 결정을 컴파일러로 옮겨 생성 비용을 줄이면서 표현력을 유지하는 절충으로 이 언어를 설계했음

  • 프로젝트 페이지: https://microsoft.github.io/flint-chart/
    MCP 설정: https://microsoft.github.io/flint-chart/#/mcp

답변달기