Microsoft가 선언적(declarative) 시각화 언어인 Flint를 발표했습니다. 이 언어는 사람이 아닌, 모델 언어(language model)가 그래프의 사양을 작성하도록 설계되었습니다. 프로젝트는 microsoft.github.io/flint-chart/에서 확인할 수 있으며, 모든 노력을 요약하는 문구와 함께 소개됩니다: "A Visualization Language for the AI Era".

기본 아이디어는 간단합니다. 오늘날 AI 비서에게 그래프 생성을 요청하면, 거의 항상 D3.js 코드나 matplotlib을 사용한 Python 코드가 생성되는 경향이 있습니다. 이는 구문 오류에 취약하고 자동으로 검증하기 어려운 명령형(imperative) 코드입니다. Flint는 다른 경로를 제안합니다: 픽셀 하나를 그리기 전에 검증기(validator)가 검토할 수 있는 구조화된 사양으로 그래프를 설명하는 것입니다.

요약 (TL;DR)

• Microsoft가 microsoft.github.io/flint-chart/에 문서화된 선언적 시각화 언어 Flint를 발표했습니다.
• 이 프로젝트는 "A Visualization Language for the AI Era"로 정의되며, 프롬프트(prompt) 흐름, 사양, 렌더링을 위해 고안되었습니다.
• 명령형인 D3.js와 달리, Flint는 그래프를 코드의 단계가 아닌 구조화된 데이터로 설명합니다.
• 이는 이미 Washington 대학교의 Vega-Lite 및 Observable Plot과 같은 선언적 언어들이 점유하고 있는 영역에 추가됩니다.
• 구조화된 사양은 렌더링 전에 스키마(schema)와 비교하여 검증될 수 있으며, 이는 자유 JavaScript가 허용하지 않는 기능입니다.
• 이 사이트는 Microsoft 조직의 GitHub Pages에 호스팅되어 있으며, 개발 중인 오픈 프로젝트의 일반적인 패턴을 따릅니다.
• 데이터 팀에게 있어 이를 채택한다는 것은 AI 에이전트가 그래프 코드를 건드리지 않고도 시각화를 생성하고 수정하도록 하는 것을 의미합니다.

Flint: 마이크로소프트가 발표한 시각화 언어란 무엇인가

선언적 **시각화 언어 (visualization language)**는 컴퓨터에게 그래프를 단계별로 어떻게 그릴지 지시하는 것이 아니라, 데이터와 시각적 속성 사이의 관계가 무엇인지를 알려줍니다.

Flint는 동일한 맥락을 따르지만, 설계 측면에서 다른 뉘앙스를 가집니다. Vega-Lite와 Observable Plot이 시각적 판단력을 가진 사람이 작성하도록 설계된 반면, Flint는 명세(specification)의 주요 작성자가 에이전트(agent) 내의 언어 모델(language model)이 될 것이며, 인간은 결과물을 검토만 할 것이라고 가정합니다.

Flint는 그래프를 그리는 단계가 아닌 데이터로서 기술합니다.

기술적 세부 사항: Flint가 제안하는 선언적 명세(declarative specification)의 구조

Flint의 공식 문서는 microsoft.github.io/flint-chart/에 있으며, 프로젝트의 정확한 구문(syntax)을 확인하기 위한 필수 참조 자료입니다. 확실하게 설명할 수 있는 점은 이러한 유형의 선언적 언어들이 공유하는 일반적인 패턴이며, 이는 Flint가 해결하고자 하는 문제, 즉 데이터, 시각적 마크(visual mark), 인코딩(encoding)을 하나의 코드 블록에 섞지 않고 분리하는 것을 이해하는 데 도움이 됩니다.

이러한 유형의 그래픽 문법이 갖는 전형적인 구조를 보여주는 최소한의 예시는 다음과 같습니다:

{
  "mark": "bar",
  "data": {
...

이 블록 자체는 아무것도 그리지 않습니다. 대신 렌더러(renderer)가 해석할 관계(언어별 막대, 채택률에 따른 높이)를 기술합니다. 에이전트가 동일한 그래프에서 두 개 이상의 변수를 비교해야 할 때 흔히 사용하는 방식인, 색상으로 인코딩된 세 번째 차원을 추가한 더 현실적인 예시는 다음과 같습니다:

{
  "mark": "point",
  "data": { "url": "metricas_equipo.json" },
...

AI 에이전트에게 D3의 JavaScript를 생성하는 것보다 이 형식이 갖는 장점은 두 가지입니다. 첫째, 알려진 스키마(schema)의 필드만 채우면 되기 때문에 유효한 토큰(token) 공간이 훨씬 작습니다. 둘째, 모델이 데이터에 존재하지 않는 필드를 만들어낸 경우, 렌더링하기 전에 검증기(validator)가 명세를 거부할 수 있습니다.

💡 팁: LLM (Large Language Model)에 의해 생성된 명세(specification)를 렌더링하기 전에, 언어 스키마(JSON Schema 또는 그에 상응하는 것)를 통해 검증(validation)한 후 렌더링 엔진으로 전달하세요. 이렇게 하면 오류가 화면에 깨진 그래프로 나타나는 대신 검증 메시지로 격리됩니다.

Flint와 기존 대안들 비교

오늘 바로 이 접근 방식을 테스트하는 방법

이 프로젝트는 GitHub Pages 사이트로 공개되어 있으며, 이는 일반적인 GitHub 관례에 따라 소스 코드가 동일한 조직의 리포지토리(repository)에 존재함을 의미합니다. 이를 탐색하기 위한 첫 번째 단계는 브라우저에서 문서를 여는 것이며, 소스 코드를 확인하고 싶다면 리포지토리를 클론(clone)하세요:

Windows (PowerShell):

git clone https://github.com/microsoft/flint-chart.git
cd flint-chart
start https://microsoft.github.io/flint-chart/

macOS:

git clone https://github.com/microsoft/flint-chart.git
cd flint-chart
open https://microsoft.github.io/flint-chart/

Linux:

git clone https://github.com/microsoft/flint-chart.git
cd flint-chart
xdg-open https://microsoft.github.io/flint-chart/

현재 보고 있는 것이 로컬의 오래된 복사본이 아니라 프로젝트의 활성 버전인지 확인하려면, 클론(cloned)된 저장소의 가장 최근 커밋(git log -1)을 문서 페이지 자체에 표시된 마지막 업데이트 날짜와 비교해 보세요.

📌 참고: organization.github.io/repo-name 패턴을 사용하는 GitHub Pages 기반 사이트들은 거의 항상 해당 조직 내의 동일한 이름의 공개 저장소(public repository)로부터 생성됩니다. 이는 이러한 프로젝트의 소스 코드를 찾는 가장 빠른 방법입니다.

영향 및 분석

Flint는 갑자기 나타난 것이 아닙니다. 이는 더 넓은 패턴의 일부입니다. 즉, 이전에는 인간을 위해 설계되었던 포맷을 에이전트(agent) 내의 언어 모델(LLM)이 생성하도록 설계된 포맷으로 적응시키는 과정입니다. 도구와 에이전트를 연결하기 위한 Model Context Protocol이 존재하는 이유나, 왜 많은 LLM 제공업체들이 자유 형식의 텍스트 대신 구조화된 출력 생성(강제된 JSON Schema)을 밀어붙이는지에 대한 이유도 동일한 논리로 설명됩니다. 오류 공간(error space)을 줄이면 자동화된 시스템이 매 단계마다 인간의 개입 없이도 오류를 감지하고 수정하기가 더 쉬워지기 때문입니다.

솔직히 말해서, 리스크는 파편화(fragmentation)입니다. Vega-Lite와 Observable Plot은 이미 수년간 채택되어 왔고 방대한 문서가 존재하며, 데이터 분석 코드를 실행하는 것을 포함한 많은 AI 어시스턴트들이 이미 기본값으로 생성하는 포맷입니다. Flint가 이러한 사실상의 표준(de facto standard)을 보완하는 대신 경쟁해야 한다는 점은 이 프로젝트의 가장 중요한 미결 과제입니다. 만약 Flint가 여러 포맷 중 하나로 전락한다면, Flint가 해결하고자 했던 문제(LLM을 위한 모호성 감소)가 어떤 언어를 사용할지 선택하는 더 높은 단계에서 다시 반복될 것입니다.

다음 단계

Microsoft가 개발을 주도한다면, 자연어 질문으로부터 어시스턴트가 시각화(visualizations)를 생성해야 하는 구체적인 니즈가 이미 존재하는 자체 에이전트(agents) 도구 및 Power BI나 Fabric 같은 데이터 제품과의 통합을 보는 것이 논리적일 것입니다. 또한 Microsoft뿐만 아니라 다른 LLM 제공업체들이 이 형식을 구조화된 출력(structured output)으로 채택할지 여부도 핵심이 될 것입니다. 이는 Flint가 교차 표준(cross-standard)이 될지, 아니면 내부 도구로 남을지를 결정할 것입니다.

Vega-Lite와 Observable Plot은 이미 Flint가 점유하고자 하는 영역을 지배하고 있습니다.

💭 핵심: AI를 위한 시각화 언어의 진정한 가치는 구문(syntax)에 있는 것이 아니라, 유효하지 않은 명세(specification)가 사용자의 화면에 도달하기 전에 자동 검증기(automatic validator)가 얼마나 쉽게 이를 거부할 수 있느냐에 있습니다.

📖 Telegram 요약: 요약 보기

직접 시도해 보세요: 브라우저에서 microsoft.github.io/flint-chart/를 열고, 첫 번째 명세를 생성하기 전에 공식 문서의 예시를 통해 정확한 구문을 확인해 보세요.

자주 묻는 질문 (FAQ)

Flint란 무엇인가요?

Microsoft에서 발표한 선언적(declarative) 시각화 언어로, microsoft.github.io/flint-chart/에 문서화되어 있으며 언어 모델(language model)이 생성하도록 설계된 형식으로 소개되었습니다.

D3.js와는 무엇이 다른가요?

D3.js는 명령형(imperative)입니다. 즉, 각 요소를 그리는 코드를 직접 작성해야 합니다. Flint는 Vega-Lite와 마찬가지로 그래프를 데이터와 시각적 속성(visual properties) 간의 관계로 기술하며, 실제 그리는 작업은 렌더러(renderer)에 맡깁니다.

Vega-Lite나 Observable Plot을 대체하나요?

그것이 목표라는 증거는 없습니다. 세 가지 모두 유사한 문제를 해결하지만, Flint의 차이점은 형식이 누구를 위해 설계되었느냐에 있습니다. 즉, 사람이 아닌 AI 에이전트를 위해 설계되었습니다.

Flint를 사용하려면 JavaScript를 알아야 하나요?

사양(specification)을 작성하기 위해서라면 아니요. 하지만 프로젝트가 어떻게 구현되어 있느냐에 따라, 웹 페이지에 렌더링하거나 렌더링 엔진을 수정하려면 아마도 JavaScript를 알아야 할 것입니다.

오픈 소스 프로젝트인가요?

Microsoft 조직 산하의 GitHub Pages에 호스팅되어 있으며, 이는 개발 중인 공개 프로젝트의 전형적인 패턴입니다. 라이선스와 저장소(repository)의 정확한 상태는 공식 출처에서 확인하는 것이 좋습니다.

공식 문서는 어디에 있나요?

이 기사의 주요 출처인 microsoft.github.io/flint-chart/에서 확인할 수 있습니다.

참고 문헌

• microsoft.github.io/flint-chart/: Flint 프로젝트 공식 페이지, "A Visualization Language for the AI Era".
• Vega-Lite: 워싱턴 대학교 Interactive Data Lab의 선언적 그래픽 문법 (declarative graphics grammar).
• D3.js: 웹 생태계의 상당 부분에서 여전히 기반이 되고 있는 명령형 시각화 라이브러리 (imperative visualization library).
• Observable Plot: 빠른 데이터 탐색을 위해 D3 위에 구축된 간결한 선언적 계층 (declarative layer).

📱 이 콘텐츠가 마음에 드시나요? 기술, AI, 개발 분야의 가장 중요한 소식을 매일 게시하는 저희 Telegram 채널 @programacion에 참여하세요. 빠른 요약과 매일 새로운 콘텐츠를 제공합니다.