作者注：이 글에서는 Flint-interactive가 ‘시맨틱 이벤트 + 업데이트 연산’으로 에이전트의 인터랙티브 차트 생성 비용과 오류를 줄이는 방법과 세 가지 도입 경로를 살펴봐요.
데이터 분석이나 보고서용 AI 에이전트를 만들고 있다면 이런 상황을 겪어봤을 거예요. 에이전트가 정적 차트는 금방 만들지만, ‘클릭 필터링’이나 ‘영역 선택 연동’을 추가하려면 여러 번 수정해야 해요. 레이아웃이 어긋나거나 강조 표시가 작동하지 않고, 한 곳을 고치면 다른 곳이 망가져 토큰과 시간을 디버깅에 쏟게 되죠.
마이크로소프트 리서치는 2026년 10월 22일 Flint를 기반으로 구축한 인터랙티브 데이터 시각화 언어 Flint-interactive를 발표했어요. 이 글은 새로운 차트 라이브러리를 추천하려는 게 아니에요. Flint-interactive를 사례로 삼아, 에이전트가 저수준 렌더링 코드를 덜 작성하도록 고수준 출력 명세를 설계하는 방법을 살펴볼게요.
핵심 가치: 에이전트가 인터랙티브 차트를 생성할 때 겪는 비용과 신뢰성 문제를 이해하고, ‘시각화 로직은 컴파일러에 맡기고 인터랙션 로직은 시맨틱 이벤트로 기술한다’는 설계 방식을 익힐 수 있어요. 또 대화 내, 애플리케이션 내, 사용자 정의 인터랙션이라는 세 가지 도입 경로가 각각 어떤 상황에 적합한지도 알아봐요.
에이전트가 Flint-interactive 없이 직접 인터랙션 코드를 작성하면 비용이 높은 이유
에이전트가 인터랙티브 차트 코드를 직접 작성하면 가장 유연해 보입니다. 하지만 연구 블로그에 따르면, 성능이 뛰어난 최신 모델을 사용하더라도 실제 적용 시 두 가지 뚜렷한 병목이 있어요.
첫 번째는 높은 생성 비용입니다. 에이전트가 한 번에 만족스러운 인터랙티브 차트를 완성하는 경우는 드뭅니다. 보통 여러 차례 추론, 코딩, 디버깅을 거치며, 매번 토큰과 시간이 소모돼요. 두 번째는 낮은 신뢰성입니다. 인터랙티브 시각화는 그 자체로 복잡해 표현력이 뛰어난 차트일수록 레이아웃이 어긋나거나 인터랙션이 작동하지 않기 쉽습니다. 수정 과정에서 새로운 문제가 생길 수도 있고요.
그렇다면 차트 라이브러리에 내장된 인터랙션을 그대로 사용하면 어떨까요? 블로그에 따르면 일부 시각화 라이브러리는 내장 인터랙션의 표현력이 부족해 맞춤형 인터랙티브 차트를 만들기 어렵습니다. 결국 필요한 것은 ‘표현력이 뛰어나면서도 충분히 높은 수준의’ 인터랙션 기술 언어예요.
| 방법 | 에이전트가 출력해야 하는 내용 | 주요 문제 | 적합성 |
|---|---|---|---|
| 저수준 렌더링 코드를 직접 작성 | 이벤트 리스너, 히트 테스트, 다시 그리기 로직 | 여러 차례 디버깅이 필요하고 토큰 소모가 크며, 새로운 버그가 생기기 쉬움 | 표현력은 가장 뛰어나지만 안정성이 낮음 |
| 차트 라이브러리의 내장 인터랙션만 사용 | 몇 가지 설정 항목을 켜거나 끔 | 인터랙션 종류가 제한적이고 맞춤 설정이 어려움 | 안정적이지만 표현력이 부족함 |
| Flint-interactive 명세 | 의미 기반 이벤트와 업데이트 작업의 매핑 | 새로운 명세 체계를 배워야 함 | 표현력과 신뢰성을 모두 고려한 방식 |
이처럼 여러 차례 생성이 필요한 작업에서 에이전트의 모델을 자주 바꿔야 한다면, APIYI apiyi.com의 통합 인터페이스로 여러 주요 모델을 사용할 수 있어요. 동일한 호출 코드로 모델별 생성 횟수와 소모량을 비교해, 내 상황에서 ‘저수준 코드를 직접 작성하는 방식’에 얼마나 비용이 드는지 먼저 파악할 수 있습니다.
Flint-interactive 핵심 요점
| 요점 | 설명 | 개발자를 위한 가치 |
|---|---|---|
| 의미 이벤트 | 컴파일러가 클릭, 드래그, 키 입력 등의 원시 트리거를 분석해 어떤 차트 요소와 데이터가 선택됐는지 파악 | 에이전트가 픽셀 좌표와 히트 테스트를 처리할 필요가 없어요 |
| 업데이트 작업 | set-style, set-annotation, set-viewport 등의 고수준 작업으로 화면 변화를 표현 | 렌더러에 종속된 그래픽 마크를 직접 조작할 필요가 없어요 |
| Flint Canvas 상태 머신 | 캔버스에서 발생하는 사용자 상호작용을 추적하고 렌더링 상태를 관리 | 프레임워크가 런타임을 관리해 상태가 꼬일 위험을 줄여요 |
| 조합 가능성 | 이벤트 생성과 시각적 업데이트를 조합해 표, 텍스트, 컴포넌트를 연결 | 데이터 스토리와 연동 대시보드를 만들 수 있어요 |
의미 이벤트: Flint-interactive는 “사용자가 어떤 데이터를 선택했는지”에만 집중해요
의미 이벤트는 Flint-interactive의 핵심 개념이에요. 기존 방식에서는 에이전트가 “마우스가 좌표 (x, y)에서 눌린 뒤 어디까지 드래그됐는지”를 처리하고, 해당 영역에 포함된 데이터 포인트를 직접 계산해야 해요. Flint에서는 컴파일러가 이 단계를 처리하고, “사용자가 이 국가 그룹들을 영역 선택했다”처럼 의미가 담긴 이벤트를 바로 생성해요.
프런트엔드 개발에서 “네이티브 DOM 이벤트”와 “비즈니스 이벤트”의 차이에 비유할 수 있어요. 비즈니스 로직을 작성할 때 mousedown 좌표가 아니라 “사용자가 주문 A를 선택했다”는 사실에 집중하는 것과 같아요. 의미 이벤트는 시각화 영역에 같은 추상화를 적용하며, 컴파일러가 그 정확성을 보장해요.
업데이트 작업: Flint-interactive는 명령형 다시 그리기 대신 선언적으로 결과를 표현해요
의미 이벤트를 받은 뒤 상호작용 로직이 답해야 할 질문은 하나예요. 화면이 어떻게 바뀌어야 하는가죠. 블로그에서 소개한 업데이트 작업에는 set style로 데이터를 강조하고, set annotation으로 특정 지점에 레이블을 추가하고, set viewport로 뷰를 이동하거나 확대·축소하는 작업이 있어요.
이는 SQL과 직접 작성한 반복문의 관계와 비슷해요. SQL에서는 “원하는 결과”를 설명하면 데이터베이스가 실행 방법을 결정해요. Flint에서도 “어떤 데이터를 강조할지” 설명하면 컴파일러가 히트 테스트와 저수준 시각적 업데이트를 포함한 구체적인 캔버스 변화로 변환해요.
상태 머신: Flint Canvas가 상호작용 런타임을 관리해요
Flint Canvas는 기본적으로 상태 머신이에요. 캔버스에서 발생하는 사용자 상호작용을 계속 추적하고 렌더링 상태를 관리해요. 따라서 에이전트는 “현재 무엇이 선택됐는지, 이전 강조 표시가 해제됐는지”처럼 오류가 생기기 쉬운 중간 상태를 직접 유지할 필요가 없어요.
위 그림은 블로그의 핵심 역할 분담을 보여줘요. 시각화 로직은 컴파일러가 관리하고, 상호작용 로직은 사용자가 의미 수준에서 설명해요. 에이전트는 중간에서 “어떤 이벤트를 어떤 업데이트에 대응할지”만 매핑하고, 오류가 발생하기 쉬운 양쪽 처리 과정은 프레임워크에 맡겨요.
Flint-interactive에서 얻을 수 있는 범용 원칙: 에이전트의 고수준 출력 명세 설계하기
Flint-interactive 사례에서 주목할 만한 것은 그 바탕에 있는 엔지니어링 판단이에요. 에이전트에게 가장 실수하기 쉬운 계층을 출력하도록 하지 마세요. 저수준 렌더링 코드는 의존 관계가 복잡하고 피드백을 받기까지 오래 걸려요. 에이전트가 이 계층에서 시행착오를 반복하면 비용도 그만큼 커져요.
다르게 보면, Flint는 열린 형태의 프로그래밍 문제를 “제한된 어휘 안에서 매핑하는” 문제로 좁혔어요. 에이전트의 출력 범위가 줄고 구조가 일정해지면서 검증도 쉬워졌죠. 이 접근법은 워크플로 오케스트레이션, 폼 생성, 보고서 레이아웃 같은 분야에도 적용할 수 있어요.
| 판단 기준 | 에이전트가 출력하기에 적합 | 컴파일러나 런타임이 처리하기에 적합 |
|---|---|---|
| 비즈니스 의도를 표현하는가 | 예: “국가를 선택하면 같은 그룹을 강조” | 아니요: 픽셀 좌표 변환 |
| 많은 암묵적 상태에 의존하는가 | 의존성이 적고, 한 번의 매핑으로 설명 가능 | 의존성이 많고, 지속적인 추적이 필요 |
| 오류가 발생하면 원인을 찾기 쉬운가 | 명세 구조가 명확해 검증하기 쉬움 | 렌더링 세부 사항이 흩어져 있어 원인 파악이 어려움 |
| 재사용할 수 있는가 | linked-brush 같은 프리셋으로 만들어 활용 가능 | 범용 인프라로 한 번 구현 |
자체 에이전트의 출력 형식을 설계할 때 이 표를 기준으로 하나씩 확인해 보세요. 어떤 계층이 ‘의도를 표현하고, 상태 의존성이 적으며, 검증하기 쉽다’는 조건을 모두 만족한다면 에이전트에 맡기기 적합해요. 반대로 그렇지 않다면 결정론적인 코드나 컴파일러가 처리하도록 하는 편이 좋아요.
다만 연구 블로그에는 토큰 소비 감소나 성공률 향상에 관한 정량적 데이터가 제시되어 있지 않아요. 따라서 이 설계 원칙의 효과를 그대로 받아들이기보다, 직접 수행하는 작업에서 테스트해 검증하는 것이 좋아요.
Flint-interactive 빠른 시작: 3가지 연동 방법
블로그에서는 차트 사용자, 애플리케이션 개발자, 인터랙션 디자이너를 위한 세 가지 사용 방법을 소개해요. 가장 간단한 방법부터 차례로 살펴볼게요.
| 연동 방법 | 대상 사용자 | agent 또는 애플리케이션의 출력물 | 대표적인 활용 사례 |
|---|---|---|---|
| 대화에서 사용하기(Flint-MCP + MCP Apps) | 차트 사용자 | Flint 차트 명세 + interaction_spec |
채팅에서 데이터를 탐색하고 선택한 내용을 후속 질문에 활용 |
| 애플리케이션에 통합하기(Flint Interactive Canvas) | 애플리케이션 개발자 | 시맨틱 이벤트 처리 함수 + Canvas에 전달할 업데이트 작업 | 대시보드, 데이터 스토리, 차트와 표 연동 |
| 인터랙션 사용자 지정하기(프로그래밍 API) | 인터랙션 디자이너 | 트리거(trigger) + 사용자 지정 handle 함수 | DimpVis처럼 기본 설정을 넘어서는 맞춤형 인터랙션 |
경로 1: 대화에서 Flint-interactive 사용하기(MCP)
가장 간단한 방법이에요. Flint-MCP와 MCP Apps를 통해 채팅이나 캔버스 환경에서 Flint Interactive를 직접 사용할 수 있어요. 구체적인 설정은 공식 MCP 설정 가이드를 따르면 됩니다. 연동 후의 흐름은 다음과 같아요.
- 공식 MCP 설정 가이드에 따라 Flint-MCP를 MCP Apps를 지원하는 채팅 또는 캔버스 환경에 연동해요.
- agent에게 어떤 차트를 그리고 어떤 인터랙션을 원하는지 알려줘요. 예를 들어 “영역 선택을 지원하고 같은 그룹의 국가를 연동해 강조해 줘”라고 요청할 수 있어요.
- agent가 Flint 차트 명세와 함께
interaction_spec을 생성하고, 대화에 인터랙티브 차트를 표시해요. - 차트에서 항목을 선택하면 선택한 내용을 이후 대화의 컨텍스트로 전달할 수 있어요.
4단계가 특히 유용해요. 사용자가 이상 데이터 구간을 선택한 뒤 “이 점들은 왜 값이 높은 거야?”라고 바로 물으면, agent는 모호한 텍스트 설명 대신 구조화된 선택 결과를 받아요.
방법 2: 애플리케이션에 Flint-interactive Canvas 통합하기
자체 대시보드나 데이터 스토리에 활용하려면 Flint Interactive Canvas를 선택할 수 있어요. 데이터는 양방향으로 흐르며, 다음과 같이 나눠서 이해하면 됩니다.
- 차트 → 애플리케이션: Flint Canvas가 의미 이벤트를 발생시키면 애플리케이션이 이벤트 핸들러로 이를 받아 테이블을 필터링하거나, 다른 차트를 업데이트하거나, 애플리케이션 상태를 변경해요.
- 애플리케이션 → 차트: 애플리케이션의 컴포넌트에서 차트를 제어하려면 Flint Canvas에 업데이트 작업을 보내면 돼요.
블로그의 예제에서는 차트와 테이블이 양방향으로 연동돼요. 테이블의 행을 클릭하면 차트의 해당 점이 강조되고, 반대로 차트에서 점을 클릭해도 테이블이 연동돼요. 보고서 제품에서 차트와 데이터를 연결하는 경험의 기초가 되는 기능이죠. 또한 interaction-author 스킬을 코딩 에이전트와 공유하면 애플리케이션에 인터랙션 프리셋을 추가하는 데 도움을 받을 수 있다고 해요.
방법 3: 프로그래밍 API로 Flint-interactive 사용자 지정 인터랙션 만들기
프리셋 인터랙션(예: linked-brush 연동 영역 선택)만으로 부족하다면, 프로그래밍 API에서 트리거와 사용자 지정 handle 함수를 정의해 의미 이벤트를 일련의 사용자 지정 차트 업데이트에 연결할 수 있어요.
블로그의 예제에서는 특정 국가를 클릭하면 해당 국가가 강조되고 이름이 라벨로 표시돼요. 이 핸들러는 set-style과 set-annotation 두 작업을 조합하며, 렌더러에 종속된 그래픽 마크를 직접 조작할 필요가 없어요. 더 복잡한 DimpVis 예제에서는 시간 경로를 따라 점을 드래그하면서 모든 도시의 기온과 강수량이 어떻게 변하는지 살펴볼 수 있어요.
🚀 시작 가이드: 먼저 방법 1을 사용해 대화에서 데이터가 인터랙션에 적합한지 확인한 뒤, 방법 2나 방법 3을 적용할지 결정해 보세요. 에이전트를 구동하는 모델은 APIYI apiyi.com을 통해 통합 접근할 수 있어요. 같은 코드에서 주요 모델을 바꿔 가며 어느 모델이 유효한
interaction_spec을 더 안정적으로 생성하는지 확인해 보세요.
에이전트가 생성한 Flint-interactive 명세의 신뢰성 평가하기
블로그에서는 어떤 모델이나 에이전트가 Flint 명세를 더 잘 생성하는지 설명하지 않아요. 따라서 실제 서비스에 적용하기 전에 간단한 평가 절차를 마련하는 것이 좋아요. 다음 지표를 살펴보세요.
| 평가 지표 | 확인 방법 | 설명 |
|---|---|---|
| 첫 시도 사용 가능률 | 첫 생성 결과가 올바르게 렌더링되고 상호작용하는 비율 측정 | 생성 비용을 직접적으로 보여줘요 |
| 평균 수정 횟수 | 첫 생성부터 사용 가능한 결과를 얻기까지의 대화 횟수 기록 | 토큰과 시간 소모에 해당해요 |
| 상호작용 의도 충족도 | 동작이 요구사항과 일치하는지 사람이 직접 확인 | 명세가 유효하다고 해서 의도까지 맞는 것은 아니에요 |
| 회귀 안정성 | 한 상호작용을 수정한 뒤에도 다른 상호작용이 정상 동작하는지 확인 | 블로그에서 언급한 신뢰성 문제와 관련 있어요 |
고정된 상호작용 요구사항을 테스트 세트로 준비하고, 같은 프롬프트로 ‘렌더링 코드를 직접 작성하는 방식’과 ‘Flint 명세를 출력하는 방식’을 각각 실행해 보세요. APIYI 같은 멀티 모델 통합 인터페이스를 이용하면 하나의 스크립트에서 여러 모델을 비교할 수 있어, 각 업체의 SDK를 따로 연동하는 수고를 덜 수 있어요.
자주 묻는 질문 FAQ
Q1: Flint-interactive란 무엇인가요?
Flint-interactive는 Microsoft Research가 Flint를 기반으로 선보인 인터랙티브 데이터 시각화 언어예요. 컴파일러가 사용자 인터랙션을 의미 이벤트로 변환하고, 고수준 업데이트 작업으로 차트를 수정해요. 사용자와 에이전트는 간결한 명세로 클릭, 필터링, 확대·축소, 강조, 차트 간 연동 등을 표현할 수 있어요.
Q2: 에이전트가 차트 인터랙션 코드를 직접 작성하는 것과 Flint-interactive는 어떻게 다른가요?
코드를 직접 작성하면 에이전트가 이벤트, 히트 테스트, 다시 그리기를 모두 처리해야 해요. 표현력은 높지만 여러 차례 디버깅하는 데 드는 비용이 크고 오류도 생기기 쉬워요. Flint-interactive는 시각적 로직을 컴파일러에 맡기므로, 에이전트는 “어떤 의미 이벤트에 어떤 업데이트를 적용할지”만 설명하면 돼요. 출력도 짧고 구조를 검증하기도 쉬워요.
Q3: Flint-interactive는 언제 발표됐나요?
Microsoft Research 블로그는 2026년 10월 22일에 이 연구를 발표했어요. 오픈소스 라이선스, 성숙도, 프로덕션 환경에서의 사용 가능성은 참고 자료에 명확히 나와 있지 않아요. 정식 프로젝트에 적용하기 전에 공식 저장소의 최신 정보를 확인하는 것이 좋아요.
Q4: Flint-interactive는 어떤 활용 사례에 가장 적합한가요?
– **대화형 데이터 분석**: 채팅 중 데이터 포인트를 영역으로 선택하고, 선택 결과를 후속 질문에 활용해요.
– **보고서와 대시보드**: 여러 차트를 연동하고, 차트를 클릭해 상세 표를 필터링해요.
– **데이터 스토리**: 데이터 저널리즘의 인터랙티브 스토리텔링처럼 차트와 본문 단락을 양방향으로 강조해요.
Q5: Flint-interactive를 사용하는 에이전트를 구축할 때 모델 호출은 어떻게 준비하나요?
Flint는 “무엇을 출력할지”를 해결하지만, 모델은 별도로 연동해야 해요. APIYI apiyi.com을 통해 여러 주요 모델에 접속하고, 통일된 인터페이스로 동일한 인터랙션 요구사항을 테스트하는 방법이 간편해요. 각 모델이 생성한 명세의 첫 시도 사용 가능률과 수정 횟수를 비교한 뒤 프로덕션 환경에 사용할 모델을 결정하면 돼요.
Q6: 제품 책임자는 Flint-interactive 도입 여부를 어떻게 판단하면 좋을까요?
먼저 두 가지를 확인해 보세요. 사용자가 차트를 탐색할 필요가 있는지, 그리고 현재 에이전트가 생성한 인터랙티브 차트를 재작업하는 비율이 높은지예요. 둘 다 그렇다면 경로 1로 소규모 검증을 해볼 만해요. 테스트 단계에서는 APIYI 플랫폼으로 모델을 빠르게 전환해 검증 비용을 낮출 수 있어요.
Q7: Flint-interactive의 알려진 한계나 확인이 필요한 사항은 무엇인가요?
– **정량적 데이터 부족**: 블로그에 토큰 절감량이나 성공률 향상에 관한 구체적인 수치가 공개되지 않았어요.
– **모델별 적합성 미확인**: 어떤 모델이 Flint 명세를 가장 잘 생성하는지 설명하지 않았어요.
– **제한된 인터랙션 어휘**: 프리셋에 없는 인터랙션은 프로그래밍 API로 직접 구현해야 해요. 공식 측은 어휘를 확장할 수 있도록 GitHub에 새 프리셋을 제출하도록 권장해요.
Flint-interactive 핵심 요약 Key Takeaways
- 비용의 원인: 에이전트가 인터랙션 코드를 직접 작성하면 여러 차례 디버깅해야 해 토큰 소모가 크고, 수정 과정에서 새로운 버그가 생기기 쉬워요.
- 시맨틱 이벤트: 컴파일러가 클릭, 드래그 같은 원시 동작을 ‘어떤 데이터가 선택됐는지’로 변환해요.
- 업데이트 연산: set-style, set-annotation, set-viewport로 화면 변화를 선언하며, 저수준 렌더링은 직접 다루지 않아요.
- 역할 분리: 시각화 로직은 컴파일러에 맡기고, 인터랙션 로직은 시맨틱 계층에서 기술하며, Canvas 상태 머신이 런타임을 관리해요.
- 세 가지 접근 방식: 대화에서는 MCP, 애플리케이션에서는 Canvas, 맞춤형 인터랙션에는 프로그래밍 API를 사용해요.
- 다른 분야에도 적용할 원칙: 에이전트에 고수준 출력 명세를 제공하고, 오류가 가장 발생하기 쉬운 계층은 결정론적 시스템에 맡겨요.
- 실제 검증: APIYI의 통합 인터페이스로 여러 모델을 비교해 명세 생성의 안정성을 테스트해요.
정리
Flint-interactive의 시맨틱 이벤트 접근 방식은 세 가지로 요약할 수 있어요.
- 정확한 문제 진단: 인터랙티브 차트를 생성하기 어려운 이유는 모델 성능이 부족해서가 아니라, 표현력이 있으면서도 충분히 고수준인 인터랙션 언어가 없기 때문이에요.
- 명확한 역할 분담: 컴파일러는 이벤트 해석과 화면 업데이트를 담당하고, 에이전트는 ‘이벤트 → 업데이트’ 매핑만 기술해요.
- 단계별 통합 방식: 대화에서 시험해 보는 것부터 애플리케이션 통합, 맞춤형 인터랙션 구현까지 필요에 따라 단계적으로 진행할 수 있어요.
보고서나 데이터 분석 에이전트를 개발하는 팀이라면, 당장 Flint를 사용하지 않더라도 이러한 설계 원칙을 참고해 자체 에이전트의 출력 형식을 다시 살펴볼 수 있어요.
직접 검증할 때는 APIYI apiyi.com을 통해 여러 주요 모델에 일괄적으로 접근하고, 동일한 인터랙션 요구사항으로 생성 결과를 비교해 보세요. 비즈니스에 적합한 모델과 명세 조합을 더 빠르게 찾을 수 있어요.
📚 참고 자료
- Microsoft Research Blog – Flint-interactive: Flint-interactive 공식 연구 블로그
- 링크:
microsoft.com/en-us/research/blog/flint-interactive-a-language-for-creating-interactive-data-visualizations - 설명: 시맨틱 이벤트, 업데이트 작업, Canvas 상태 머신과 MCP, Canvas, 프로그래밍 API의 세 가지 사용 방식을 소개해요. MCP 설정 가이드, 인터랙티브 예제 모음, 프로그래밍 API 링크도 제공해요.
작성자: APIYI 기술팀
기술 교류: APIYI apiyi.com에서 에이전트와 다중 모델 연동 경험을 나눠보세요. 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
