개구리 SVG 벤치마크, 평가의 작은 반란

한 문장 프롬프트가 드러낸 모델의 성격

FROGS_는 "Habsburg jaw를 가진 개구리 SVG를 만들어라"라는 한 문장 프롬프트로 여러 모델을 비교하는 개인 벤치마크다. 2026년 8월 기준 사이트는 14개 모델, 42회 실행, 42개의 SVG 결과를 보여준다. Hacker News 토론에서 주목을 받은 이유도 거창한 점수표 때문이 아니라 결과물을 눈으로 비교하기 쉽기 때문이다.

이 실험은 장난처럼 보이지만 AI 평가의 중요한 결핍을 찌른다. 대부분의 벤치마크는 평균 점수와 순위를 준다. 하지만 제품팀이 알고 싶은 것은 "우리 모델이 실패할 때 어떤 식으로 실패하는가"다. Habsburg jaw는 해부학적 특징이고, 개구리는 동물 형태이며, SVG는 구조화된 벡터 출력이다. 모델은 개념 이해, 시각 구성, XML 형태의 문법, 과잉 장식 억제를 동시에 처리해야 한다.

AI 그림 대결, 에이전트 평가가 된 색연필 실험도 같은 흐름을 다뤘다. 작은 시각 과제는 모델의 추론을 한눈에 드러낸다. 점수가 아니라 결과의 모양이 말한다.

SVG는 이미지가 아니라 실행 가능한 약속이다

SVG가 중요한 이유는 단순한 이미지 생성과 다르기 때문이다. W3C SVG 2 문서가 보여주듯 SVG는 좌표, path, style, 텍스트, 뷰박스가 결합된 문서 형식이다. 모델이 SVG를 만든다는 것은 픽셀을 그리는 것이 아니라 브라우저가 해석 가능한 구조를 작성한다는 뜻이다. 따라서 실패도 여러 층으로 나뉜다. 문법은 맞지만 개구리가 아니거나, 개구리는 보이지만 턱 특징이 없거나, 특징은 있지만 불필요한 왕관과 혈통 상징을 덧붙일 수 있다.

이런 과잉해석은 업무용 에이전트에서도 그대로 나타난다. 사용자가 "간단한 차트"를 원했는데 모델이 설명 문구와 색상 장식을 붙이고, "요약"을 원했는데 정치적 해석을 얹는 식이다. Pelicanmaxxing 논쟁, 벤치마크 게임의 해부는 모델이 평가 조건을 어떻게 우회하거나 과적합할 수 있는지 보여줬다. 개구리 벤치마크는 그 반대편에서 작고 반복 가능한 관찰을 제공한다.

작은 벤치마크가 큰 리더보드를 보완한다

큰 리더보드는 여전히 필요하다. HELM처럼 다양한 시나리오를 표준화한 평가는 모델 선택의 기준점을 준다. LMSYS Chatbot Arena처럼 사람 선호 기반 비교도 실제 대화 품질을 보여준다. 그러나 둘 다 제품팀의 특수한 실패를 그대로 잡아주지는 않는다. 특정 도메인의 작은 프롬프트 묶음이 필요한 이유다.

개구리 실험은 "모델 평가를 누구나 만들 수 있다"는 신호이기도 하다. 디자이너는 아이콘 일관성 테스트를 만들 수 있고, 법무팀은 단서 문구 보존 테스트를 만들 수 있으며, 데이터팀은 차트 축과 단위 테스트를 만들 수 있다. Flint, 에이전트 시대 차트 언어의 등장이 차트 스펙 검증을 다뤘다면, SVG 벤치마크는 시각 출력의 미세한 지시 준수를 다룬다.

한국 팀이 가져갈 실무 방식

한국 개발팀이 할 일은 거대한 벤치마크를 새로 만드는 것이 아니다. 자사 제품에서 자주 깨지는 20개 장면을 모아 작고 오래가는 테스트를 만드는 것이다. 예를 들어 쇼핑몰 상세페이지 생성 모델이라면 가격, 할인율, 배송 조건, 금지 표현을 섞은 테스트가 필요하다. 교육 서비스라면 정답 설명보다 오개념을 얼마나 잘 피하는지 봐야 한다. 디자인 도구라면 SVG, CSS, canvas 결과가 실제로 렌더링되는지 자동 확인해야 한다.

중요한 것은 점수를 하나로 합치지 않는 것이다. 문법, 의미, 과잉추론, 안정성을 분리해 기록해야 어느 모델을 어떤 기능에 넣을지 판단할 수 있다. AI 추론 논쟁, 정답보다 이유를 검증해야 한다가 말한 것처럼 설명이 그럴듯하다고 결과가 맞는 것은 아니다. 렌더링되는 개구리는 말보다 정직하다.

자주 묻는 질문

Q1: 이 벤치마크가 과학적으로 엄밀한가요?

A: 표준 논문 벤치마크라기보다 관찰형 테스트에 가깝다. 다만 실패 양상을 빠르게 비교하는 데 가치가 있다.

Q2: 왜 하필 SVG인가요?

A: SVG는 텍스트로 작성되지만 브라우저에서 시각 결과로 검증된다. 코드와 이미지 사이에 있어 에이전트 평가에 적합하다.

Q3: 한 프롬프트만으로 모델을 판단해도 되나요?

A: 아니다. 한 프롬프트는 현미경이다. 전체 성능 판단에는 여러 도메인 테스트와 실제 사용자 로그가 함께 필요하다.

Q4: 제품팀은 어떻게 적용하면 좋나요?

A: 자사 서비스에서 자주 틀리는 복합 지시 20개를 만들고, 모델 교체 때마다 결과물과 실패 유형을 저장하면 된다.

Q5: 과잉해석은 왜 위험한가요?

A: 모델이 요청하지 않은 의미를 덧붙이면 디자인에서는 장식으로 끝나지만, 법률·의료·금융에서는 잘못된 조언이나 책임 문제로 이어질 수 있다.