Microsoft Flint, AI가 만든 차트를 사람이 검증할 수 있게 하는 중간 언어

원문 링크: WordPress 원문

언어 선택 / Choose a language

KO · 한국어EN · English

AI에게 “이 데이터로 막대그래프 그려줘”라고 하면 그림 한 장이 뚝 나옵니다. 편리하지만 문제가 하나 있습니다. AI가 왜 그 축을 그렇게 잡았는지, 왜 그 색을 골랐는지, 기준선을 어디에 뒀는지가 그림 안에 숨어 버린다는 점입니다. 완성된 이미지에는 판단의 근거가 남지 않기 때문에, 결과물만 보고 “이게 맞나?”를 사람이 판단하기가 의외로 어렵습니다.

Microsoft Research가 공개한 Flint는 바로 이 틈을 메우려는 오픈소스 연구 프로젝트입니다. Flint는 그림을 바로 그리지 않고, 그림을 그리기 전 단계에 “이 차트는 이런 의도로 이렇게 만들 것”이라는 짧은 명세(spec)를 먼저 남깁니다. 사람이 그 명세를 읽고 고친 다음, 실제 렌더링 도구로 컴파일하는 방식입니다. 요리에 비유하면, AI가 완성된 요리 접시를 던져 주는 대신 레시피 카드를 먼저 건네주고, 사람이 간을 확인한 뒤 조리에 들어가는 구조라고 보면 됩니다.

Flint가 정확히 무엇인가: 그림이 아니라 ‘중간 언어’

Flint의 핵심 정체성은 **시각화 중간 언어(visualization intermediate language)**라는 점입니다. 프로그래밍에서 소스 코드가 곧바로 기계어가 되지 않고 중간 표현을 거치듯, Flint는 자연어 요청과 최종 차트 사이에 사람이 읽을 수 있는 명세 계층을 하나 끼워 넣습니다.

이 구분이 중요합니다. Flint는 “오류 없는 차트 생성기”가 아닙니다. AI가 만든 시각화 의도를 명세라는 형태로 붙잡아 두어, 사람이 검토하고 수정할 수 있게 만드는 것이 목표입니다. 다시 말해 Flint가 파는 가치는 ‘완벽한 그림’이 아니라 ‘검증 가능성’입니다.

왜 이 구조가 검증에 유리할까요. 완성된 이미지는 픽셀 덩어리라서, 잘못된 부분을 발견해도 이미지 자체를 고칠 방법이 없습니다. 처음부터 다시 생성을 요청하고, 새 결과가 또 맞는지 다시 눈으로 확인하는 반복에 빠지기 쉽습니다. 반면 명세는 텍스트입니다. “기준선이 0이 아니네” 싶으면 해당 줄만 고치면 되고, 고친 내용이 그대로 기록으로 남습니다. 검토와 수정의 단위가 ‘그림 전체’에서 ‘명세의 한 줄’로 줄어드는 것이 이 방식의 핵심 이점입니다.

명세는 사람이 눈으로 읽고 손으로 고칠 수 있을 만큼 간결하게 설계되어 있습니다. 어떤 데이터를 어떤 축에 매핑하고, 어떤 척도(scale)를 쓰고, 색과 배치를 어떻게 할지를 명시적으로 적어 두기 때문에, 결과 그림만 보고 추측할 필요가 줄어듭니다.

공식 원문·검증된 수치만으로 재구성한 보조 시각자료입니다. 이미지를 누르면 핵심 공식 출처가 열립니다.

의미 유형(semantic types): 차트가 스스로 문맥을 갖게 하는 장치

Flint에서 주목할 개념이 **의미 유형(semantic types)**입니다. Microsoft Research의 설명에 따르면, 이 의미 유형이 파싱(parsing), 척도(scale), 기준선(baseline), 서식(formatting), 색상(color), 배치(layout)를 안내하는 역할을 할 수 있습니다.

무슨 뜻일까요. 예를 들어 어떤 값이 ‘비율’인지 ‘절댓값’인지, ‘시간’인지 ‘범주’인지를 명세가 알고 있으면, 축의 기준선을 0에 둘지 말지, 숫자를 퍼센트로 표기할지, 색을 순서가 있는 팔레트로 쓸지 등을 더 합리적으로 정할 수 있습니다. 시각화에서 흔한 실수 상당수가 바로 이 지점에서 나옵니다. 절댓값 막대그래프의 기준선을 0이 아닌 곳에 두어 차이를 과장하거나, 순서가 있는 데이터에 순서 없는 색을 입혀 읽기 어렵게 만드는 식입니다.

즉 의미 유형은 “이 숫자가 어떤 성격의 데이터인가”라는 문맥을 명세 안에 담아 두는 장치입니다. 사람 입장에서는 이 정보 덕분에 “왜 이렇게 그렸는지”를 그림이 아니라 명세에서 직접 확인할 수 있고, 잘못 지정됐다면 유형 하나만 바꿔서 관련 설정이 함께 따라오게 할 수 있습니다. 다만 이것이 실제로 얼마나 효과적인지는 별개의 문제이며, 여기서 소개한 내용은 Microsoft Research가 제시한 설계 의도입니다.

하나의 명세, 여러 렌더러: 백엔드 분리 구조

Flint의 또 다른 특징은 명세와 렌더링을 분리한다는 점입니다. 프로젝트 페이지에 따르면 Flint는 Vega-Lite, ECharts, Chart.js 세 가지 백엔드로 컴파일됩니다.

이 구조의 장점은 직관적입니다. 같은 차트 명세를 한 번 작성해 두면, 웹 대시보드에는 ECharts로, 논문·리포트에는 Vega-Lite로, 가벼운 페이지에는 Chart.js로 각각 내보낼 수 있습니다. 도구마다 처음부터 다시 만들 필요가 없어집니다.

또한 명세가 특정 라이브러리에 묶이지 않으므로, 시각화 ‘의도’와 실제 ‘구현 도구’를 따로 관리할 수 있습니다. 조직이 나중에 렌더링 라이브러리를 바꾸더라도, 검증을 거친 명세 자산은 그대로 재사용할 수 있는 셈입니다. 검토 역시 렌더러별 코드가 아니라 명세 한 곳에서 하면 되므로, 확인해야 할 지점이 줄어듭니다.

항목 프로젝트 페이지가 밝힌 내용

지원 차트 유형 46종

제공 예제 83개

지원 백엔드 Vega-Lite, ECharts, Chart.js

의미 유형의 역할 파싱·척도·기준선·서식·색상·배치 안내

공개 형태 오픈소스 (flint-chart, flint-chart-mcp)

46종 차트와 83개 예제: 커버리지의 의미

프로젝트 페이지는 Flint가 46종의 차트 유형을 다루며 83개의 예제를 제공한다고 밝히고 있습니다. 이 숫자는 Flint가 실험적 장난감이 아니라 어느 정도 폭넓은 시각화 요구를 염두에 두고 설계됐음을 보여 줍니다.

다만 이 숫자를 ‘모든 차트를 완벽히 지원한다’로 읽는 것은 과잉 해석입니다. 46종·83개는 프로젝트가 현재 문서화해 둔 범위이며, 커버리지의 폭을 나타내는 지표일 뿐 품질 보증이나 완전성 선언은 아닙니다. 자신이 자주 쓰는 차트 유형이 목록에 있는지, 있다면 예제가 실제 용도와 비슷한지는 각자 확인해야 할 몫입니다.

예제가 함께 제공된다는 점은 실무자에게 실용적입니다. 명세를 처음부터 쓰기보다, 비슷한 예제를 골라 데이터와 의미 유형만 바꾸는 식으로 접근할 수 있기 때문입니다. 새 언어를 배울 때 문법서보다 예문이 빠른 것과 같은 이치입니다.

LLM 심판 점수는 어떻게 읽어야 하나

Microsoft Research의 연구 블로그는 테스트한 모델들에 대해 **LLM을 심판으로 사용한 평가 점수(LLM-judge scores)**를 보고합니다. 즉 사람이 아니라 대형 언어 모델이 결과물을 채점하는 방식의 평가입니다.

이 점수를 다룰 때는 두 가지를 지켜야 합니다. 첫째, 모든 평가 수치는 Microsoft Research가 특정 조건에서 측정한 결과로 귀속해서 읽어야 합니다. 둘째, 그 수치를 일반적인 상황 전반으로 확대 해석해서는 안 됩니다. 테스트한 모델과 설정에서 나온 값이지, 모든 모델이나 모든 데이터에서 재현된다는 뜻이 아닙니다.

LLM 심판 평가는 빠르고 확장성이 있다는 장점이 있지만, 심판 역시 모델이라는 한계를 함께 안습니다. 채점 기준을 어떻게 주느냐, 어떤 모델을 심판으로 쓰느냐에 따라 점수가 달라질 수 있다는 뜻입니다. 그래서 이 점수는 “이 방향이 유망하다”는 신호로 읽는 편이 안전하며, 절대적 성능 보증으로 받아들일 근거는 아닙니다.

오픈소스 구성: flint-chart와 flint-chart-mcp

Flint는 오픈소스로 공개돼 있으며, 저장소에는 flint-chart와 flint-chart-mcp 두 축이 포함됩니다. 앞의 것은 Flint 언어와 컴파일 기능의 본체이고, 뒤의 것은 MCP(Model Context Protocol) 연동을 위한 구성 요소입니다.

여기서 분명히 해 둘 경계가 있습니다. Flint가 오픈소스로 나왔다는 사실이 곧 Power BI 같은 상용 제품에 통합됐다는 뜻은 아닙니다. 또한 Flint는 무오류(zero-error) 출력을 보장하지 않습니다. 이 두 가지는 프로젝트가 주장하지 않은 내용이므로, 소개나 인용 시 섞어 넣지 않도록 주의해야 합니다. 이 프로젝트의 전제 자체가 “AI 출력에는 오류가 있을 수 있으니 사람이 확인할 수 있는 지점을 만들자”이기 때문에, 무오류 보장과는 오히려 반대 방향의 접근입니다.

MCP 구성 요소가 있다는 것은 AI 에이전트나 도구가 Flint를 프로토콜을 통해 호출하는 시나리오를 염두에 두었음을 시사합니다. 다만 이는 공개된 구성 요소의 존재에 대한 서술이며, 특정 제품과의 연동을 확정하는 진술은 아닙니다.

독자를 위한 확인 체크리스트

Flint 같은 접근을 살펴보거나, AI가 만든 차트를 일상적으로 다루는 독자라면 다음을 점검해 볼 수 있습니다.

• 의도가 어디에 기록되는가 : 지금 쓰는 도구는 완성 이미지만 주는가, 아니면 사람이 읽을 수 있는 명세를 남기는가.

• 수정의 단위 : 잘못된 부분을 발견했을 때 전체를 다시 생성해야 하는가, 해당 설정만 고칠 수 있는가.

• 기준선과 척도 : 축의 시작점, 척도 종류, 단위 표기가 데이터의 성격과 맞는가. 명세가 있다면 이 항목들이 명시돼 있는지 확인합니다.

• 커버리지 확인 : 자신이 필요로 하는 차트 유형과 백엔드가 문서화된 범위 안에 있는가.

• 평가 수치의 출처 : 어떤 도구든 성능 수치를 볼 때, 누가 어떤 조건에서 측정했는지를 먼저 확인하고 그 범위 밖으로 일반화하지 않습니다.

이 체크리스트는 특정 도구를 쓰라는 권고가 아니라, AI 생성 시각화를 검토할 때 공통으로 유용한 질문들입니다.

무엇이 사실이고 무엇이 아직 열린 문제인가

정리하면, 확인된 사실은 다음과 같습니다. Microsoft Research가 Flint를 시각화 중간 언어로 소개했고, 프로젝트 페이지가 46종 차트·83개 예제·세 가지 백엔드를 명시하며, 의미 유형이 파싱부터 배치까지를 안내할 수 있다는 설계가 제시됐고, 연구 블로그가 LLM 심판 점수를 보고했으며, flint-chart와 flint-chart-mcp가 오픈소스로 공개됐다는 점입니다.

연구소의 주장은 의미 유형의 효용과 평가 점수 부분입니다. 특히 평가 수치는 Microsoft Research의 조건부 측정치로 귀속해야 합니다. 해석의 영역은 “이런 방식이 사람의 검증 가능성을 높인다”는 기대이며, 이는 합리적 방향성이지 검증된 결론은 아닙니다.

아직 열린 조건도 있습니다. 실제 현장에서 Flint 명세가 얼마나 편하게 편집되는지, 다양한 모델과 데이터에서 품질이 어떻게 나오는지는 앞으로의 사용과 후속 연구를 통해 확인될 문제입니다. 이 글은 특정 도구의 채택을 권하거나 성능을 보증하지 않으며, 공개된 연구 프로젝트의 개념과 경계를 설명하기 위한 교육용 정보입니다.

참고자료

• Flint: A visualization language for the AI era — Microsoft Research 블로그

• Flint 프로젝트 페이지

• flint-chart GitHub 저장소