Microsoft, AI 에이전트용 시각화 언어 Flint 공개 — 사람이 읽는 차트 명세의 시대

> 원문: https://news.hada.io/topic?id=31287

• --

▲ Microsoft, AI 에이전트용 시각화 언어 Flint 공개 (microsoft.github.io) 3 P by GN⁺ 20시간전 | ★ 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를 구축함 함께 보면 좋은 글 β Microsoft/Data-Formulator - AI로 시각화 생성하기 gitagent - AI 에이전트 정의 및 관리를 위한 Git 기반 표준 Microsoft AI Ignite 이벤트 발표 제품들 요약 [8분] Microsoft Amplifier - 초고속 AI 개발 환경 Microsoft, Bing Image Creator 공개 GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기 댓글과 토론 인증 이메일 클릭후 다시 체크박스를 눌러주세요 ▲ GN⁺ 20시간전 [-] 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/ Flint에서도 접근성 지원 작업이 필요할 것 같고, 이건 접근성 문제를 중앙에서 다루기 좋은 지점임 추적용 이슈를 추가했음: https://github.com/microsoft/flint-chart/issues/48 이게 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 을 한 번에 만들어낼 수 있었던 것 같음 데이터 시각화에 L

• --

왜 Flint가 중요한가

1. 에이전트-인간 협업 시점 — 차트 명세를 사람이 읽고 수정 가능해야 하는데 기존 Vega-Lite는 명세 → 그래프 one-way다. Flint는 명세 단계부터 사람이 개입한다.
2. 저수준 자동화 — 46개 차트 유형 / 83개 갤러리 예제로 에이전트가 "막대그래프 그려줘" 같은 추상 요청을 받아도 의미 타입 + 인코딩을 자동 결정한다.
3. 렌더 백엔드 다중화 — Vega-Lite, ECharts, Chart.js 모두 지원 — 웹/RN/노트북 어디서든 같은 명세로 재현된다.
4. 타입 시스템 + 의미 타입 — 데이터 스키마(문자열/숫자/날짜)와 차트 의미(x/y/색/면)를 분리해서 컴파일 타임에 안전성 검증.

실무 적용

• 데이터 분석 에이전트가 차트를 만들 때 Flint 명세를 출력하면 사람이 review → 수정 → 최종본 확정 가능.
• 기존 Vega-Lite 핸드코드 조직이라면 명세를 모듈화해 차트 라이브러리화 가능.
• React/Flutter/Swift Charts 모두 같은 Flint 명세에서 시작 — 다중 플랫폼 대시보드 정합성 유지.

• --

• 이 글은 AI/ML 자동 발행 파이프라인으로 작성되었습니다 (소스: GeekNews #31287).*

---

📰 원본 출처 · https://news.hada.io/topic?id=31287 (#N=31287)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.