최고 AI 모델도 차트가 복잡해지면 성능 절반 상실, 새 벤치마크 발표

RealChart2Code 벤치마크는 기존의 단순한 차트 재현 테스트를 넘어, 실제 데이터셋에서 파생된 복잡한 시각화를 AI 모델이 얼마나 정확하게 코드로 재구성할 수 있는지를 평가한다. 차트 이해(chart understanding)는 단순 OCR이 아니라 시각적 요소(축 레이블, 범례, 색상 매핑, 겹쳐진 데이터 포인트)를 해석하고, 이를 matplotlib/plotly/seaborn 같은 라이브러리 코드로 역공학하는 멀티모달 추론을 요구한다. 14개 주요 모델을 평가한 결과 최상위 프로프라이어터리 모델조차 단순 테스트 대비 성능이 약 절반으로 떨어졌는데, 이는 시각적 요소 인식(perception), 데이터 구조 추론(reasoning), 코드 생성(synthesis) 3단계 중 어느 한 단계라도 실패하면 전체 파이프라인이 무너지는 구조적 취약성 때문이다.

개발자 관점에서 이 결과가 시사하는 바는 명확하다. 최근 데이터 분석 자동화, BI 대시보드 생성, Jupyter 노트북 에이전트처럼 "차트 스크린샷 → 코드" 워크플로우에 LLM을 끼워 넣는 사례가 급증했지만, 프로덕션 데이터처럼 범례가 많고 축이 로그 스케일이며 이중 Y축이나 서브플롯이 얽힌 그래프에서는 토이 데모 수준의 정확도가 보장되지 않는다. 특히 금융·헬스케어·제조 도메인처럼 차트 해석 오류가 의사결정에 직접 영향을 주는 분야에서 LLM 단독 출력을 그대로 신뢰하면 잘못된 축 단위, 누락된 카테고리, 뒤바뀐 색상 매핑 같은 미묘한 오류가 그대로 전파될 수 있다.

실무에 적용할 때는 몇 가지 방어적 설계가 필요하다. 첫째, 차트→코드 파이프라인은 단일 LLM 호출이 아니라 "raw data 추출 → 스키마 검증 → 코드 생성 → 실행 결과 재비교"의 다단계 검증 구조로 설계하고, 생성된 코드를 실제로 실행해 원본 이미지와 픽셀·구조 레벨에서 diff를 확인하는 self-consistency 루프를 붙이는 것이 안전하다. 둘째, 가능하다면 스크린샷을 입력으로 받기 전에 원본 CSV/JSON 데이터에 접근할 수 있는 경로를 확보하고, 시각화는 LLM이 템플릿 선택만 하도록 역할을 좁혀야 한다. 셋째, RealChart2Code 같은 도메인 특화 벤치마크 점수를 모델 선정 기준에 포함시키고, MMLU·HumanEval 같은 범용 지표만 보고 멀티모달 차트 작업에 배치하지 않도록 주의할 필요가 있다.