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

이 말은 아무리 강조해도 지나치지 않음. “에이전트에 좋다”는 건 결국 자기 설명적이고, 조작감이 명확하며, 안전한 기본값과 간결하거나 제어 가능한 출력, 프로그래밍 가능한 인터페이스를 갖췄다는 뜻이고, 이런 특성은 사람에게도 도움이 됨

이게 말 그대로 MCP 서버를 통해 AI 에이전트가 접근하도록 만든 것 아닌가 싶음. 그렇다면 마케팅에서 AI 에이전트를 강조하는 건 꽤 중요해 보임

이렇게 요약하는 게 맞아 보임. 화려한 설명은 결국 “데이터를 보고 차트가 어떻게 보여야 할지 알아서 정한다”는 말을 길게 한 것 같음
페이지에서도 “스케일, 축, 간격, 레이아웃 같은 장황한 저수준 매개변수를 요구하는 대신, Flint 컴파일러가 데이터, 의미 타입, 차트 타입, 인코딩에서 최적화된 차트 설정을 도출한다”고 설명함

에이전트가 생성하기도 쉽지만, 사람도 특히 UI가 있으면 편집하기 쉬운 형태임

패키지를 보면 기존 차트 라이브러리 위에 구축된 형태임

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

Claude가 PPT 덱을 직접 XML로 만들지 않고 Python 코드를 작성해서 생성하는 걸 처음 봤을 때 꽤 “아하” 하는 순간이었음. 많은 작업이 이런 경로로 갈 것 같고, 장기적으로는 약간 제한적이고 해킹처럼 느껴지지만 당분간은 100% 맞는 접근으로 보임

이 아이디어에 완전히 동의함. 지난 한 달간 한 에이전트 코딩 작업은 모두 중간 표현을 통해 진행했고, 반복도 주로 그 계층에서 했음. 이 방식으로 결정적인 코드 출력에 꽤 가까이 갈 수 있다는 게 놀라움

잘 설계된 중간 계층은 AI와 독립적으로 검증과 제어를 가능하게 함. 이러면 인간과 AI의 상호작용이 위임에서 협업으로 바뀜

맞음. 에이전트 시스템은 처음부터 이런 패턴이었음. 느슨하게 생성하고, 입력이 검증될 때까지 구멍에 맞는 모양과 크기가 나올 때까지 계속 재시도하는 방식임

예전에는 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을 쓰는 게 꽤 일반적임. 서로 다른 렌더링 맥락으로 쉽게 옮길 수 있기 때문임

아쉽지만 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를 직접 생성하게 하면 안정성, 표현력, 비용 시간과 토큰을 동시에 달성하기 어렵고, 그래서 일부 결정을 컴파일러로 옮겨 생성 비용을 줄이면서 표현력을 유지하는 절충으로 이 언어를 설계했음