본 글은 LLM 평가 방법론이 단발성 SVG 생성 프롬프트에서 장시간·절차적 렌더링 작업으로 이동하는 흐름을 정리한 것입니다. Simon Willison이 2024년 10월 제안한 “펠리컨 SVG 벤치마크”의 배경, Andrej Karpathy가 2026년 8월 X에 공유한 확장 실험, 그리고 이 흐름이 실무 평가 설계에 주는 시사점을 확인합니다.
참고 시점은 2026년 8월 초 기준이며, 실험 대상은 Karpathy 원문에 명시된 Claude Opus 5와 약 1M(100만) 토큰 컨텍스트 예산입니다. 원문 정리는 GeekNews의 관련 스레드에서 확인할 수 있습니다.
1. 펠리컨 SVG 벤치마크의 배경
Simon Willison은 2024년 10월 25일 자신의 블로그에서 “자전거를 탄 펠리컨 SVG를 생성하라”는 프롬프트를 자체 LLM 벤치마크로 제안했습니다. 근거는 두 가지였습니다. 필자가 펠리컨을 좋아하고, 자전거를 탄 펠리컨 SVG는 학습 데이터에 흘러들었을 가능성이 낮다는 것입니다. 근거와 실험 결과는 블로그 원문과 simonw/pelican-bicycle 저장소에서 확인할 수 있습니다.
Willison은 동일 프롬프트를 16개 모델에 실행하고 결과 SVG를 저장소에 정리했습니다. 이후 신규 모델이 출시될 때마다 커뮤니티에서 “그런데 펠리컨은?”이라는 반문이 관행이 됐고, 프론티어 모델 릴리스마다 SVG 결과가 Hacker News 상위 댓글로 오르는 문화적 지표가 되었습니다.
2. Karpathy가 제시한 확장 실험 (2026-08)
Andrej Karpathy는 2026년 8월 2일 X에 올린 게시글에서 “이제 펠리컨 SVG 수준의 단발 프롬프트로 LLM을 테스트하는 영역을 벗어나기 시작했다”고 관측했습니다. 게시글 요지는 GeekNews 정리와 관련 Hacker News 토론에 인용돼 있습니다.
Karpathy 게시글에 따르면 대안 실험은 다음과 같습니다. Claude Opus 5에 J.R.R. Tolkien의 “반지의 제왕” 첫 문단, 1M(약 100만) 토큰 컨텍스트 예산(비용 개요 약 10 USD), Three.js 렌더링이라는 최종 산출물을 지시했습니다. 결과는 약 2시간 동안의 자율 실행 끝에 약 5500줄의 JavaScript 코드가 생성됐고, 프로그램은 절차적으로 씬을 구성해 브라우저에서 렌더링됐습니다.
Karpathy는 결과물 자체는 “조악하다(janky)”고 평가하면서도, 모델이 씬 요소를 배치·연출하고 스토리 흐름에 맞춰 코드를 구조화한다는 점에 주목했습니다. 이는 “한 장의 이미지”가 아니라 “실행 가능한 프로그램으로서의 씬”이라는 산출물 형태 자체가 평가 축을 확장시킨다는 관찰로 이어집니다.
3. pelicanmaxxing — 단발성 벤치마크의 신뢰 저하
단발 SVG 벤치마크의 신뢰도 문제는 별개 논의도 축적돼 있습니다. Dylan Castillo가 2026년 7월 공개한 “Are AI labs pelicanmaxxing?” 분석은 프론티어 랩들이 이 벤치마크에 맞춰 훈련을 최적화했는지를 통계적으로 검증한 시도입니다.
Castillo의 실험 설계는 다음과 같습니다. 동물 8종(펠리컨, 플라밍고, 왜가리, 수달, 라쿤, 영양, 고래, 고양이) × 탈것 6종(자전거, 외발자전거, 스케이트보드, 스쿠터, 비행기, 보트) = 48개 셀 프롬프트를 구성하고, 7개 프론티어 모델에서 총 1,008장의 SVG를 생성한 뒤 LLM judge로 채점했습니다. 결과는 랩별 “펠리컨 편향” 효과가 −0.11 ~ +0.14 judge point 범위이며 통계적 유의성에 도달하지 않았다는 것입니다(Castillo 원문 기준, 최소 p = 0.25).
실무 시사점은 두 가지입니다. 첫째, “의도적 학습 오염”이라는 강한 가설은 아직 데이터로 뒷받침되지 않습니다. 둘째, 그럼에도 유명한 단일 셀 프롬프트로 모델 성능을 비교하는 관행은 위험합니다. Willison도 2026년 7월 후속 링크블로그에서 Castillo의 방법론을 “건강한 패턴”이라고 정리했습니다.
4. 장시간·절차적 평가의 조건
Karpathy가 제시한 형태의 평가를 사내나 팀 단위로 재현하려면 다음 조건을 갖춰야 합니다.
- 충분한 컨텍스트 예산: Karpathy 원문 기준 1M 토큰. 실무에서는 문제 크기에 맞춰 128K~1M 범위 조정.
- 실행 가능한 최종 산출물: Three.js 씬, 컴파일 통과 코드, 통과하는 유닛 테스트, 재생 가능한 오디오 등. 사람이 눈으로 확인할 수 있어야 채점 재현성이 확보됩니다.
- 재현 가능한 채점 기준: 산출물의 필수 요소(예: 씬에 등장해야 할 캐릭터·오브젝트) 리스트를 사전 정의합니다.
- 비용 관측: 1M 토큰 실행은 원문 기준 약 10 USD 규모입니다. 반복 채점 비용을 예산으로 잡아둡니다.
실패 리스크로는 실행 도중 컨텍스트 초과, 코드 실행 시 렌더링 실패, 시간 경계 초과 등이 있습니다. 세 항목은 산출물 채점 이전 단계에서 별도 지표로 남겨두면 이후 비교에 유용합니다.
5. 실무 평가 설계에 적용하기
5-1. 다단계 태스크로 재설계
사내 LLM 도입 검토라면 단일 프롬프트가 아니라 “명세 → 설계 → 구현 → 자체 리뷰”로 이어지는 다단계 태스크를 하나의 평가 단위로 잡습니다. 각 단계 산출물을 로그로 남겨 어느 단계에서 실패했는지 분리 관측할 수 있어야 합니다.
5-2. 사내 도메인 프롬프트로 오염 위험 축소
공개 벤치마크 프롬프트는 학습 데이터로 흘러들 위험이 상존합니다. 사내 도메인 데이터(내부 API 명세, 사내 코딩 규칙, 실서비스 로그 형식 등)를 프롬프트에 주입해 외부 벤치마크와 별개의 축을 만들도록 합니다.
5-3. 정성 관찰과 정량 채점 병행
펠리컨 SVG 벤치마크가 여전히 유용한 이유는 “정성 관찰용 지표”로서의 직관성입니다. 새 모델의 시각·공간 이해를 눈으로 훑는 용도에는 적합합니다. 다만 최종 모델 선택 근거로 사용할 때는 Castillo 방식의 grid 확장이나 Karpathy 방식의 장시간 절차적 산출물을 함께 두어야 합니다.
6. 판단 가이드
- 단발 SVG 벤치마크는 정성 관찰 도구로만 사용합니다. 최종 결정 근거로는 부족합니다.
- 모델을 비교할 때는 grid 확장(Castillo 방식)과 장시간 절차적 산출물(Karpathy 방식)을 함께 관찰합니다.
- 사내 프롬프트에 도메인 데이터를 주입해 외부 벤치마크와 별개의 평가 축을 확보합니다.
- 비용·시간·실패 로그를 산출물 채점과 분리해 별도 지표로 남깁니다.
관련 글
본 벤치마크 확장 논의와 인접한 모델·툴체인 이슈는 다음 글에서 정리한 바 있습니다. 프론티어 모델 라인업의 오픈웨이트 방향성은 Anthropic 오픈웨이트 모델 입장 정리에서 다뤘습니다. 로컬 실험 환경 구성이 필요하다면 OpenClaw 로컬 Gateway 아키텍처 가이드가 참고가 됩니다.
- Anthropic 오픈웨이트 모델 입장 정리 — Amodei 공식 답변 (2026-07)
- OpenClaw 정리 — 로컬 Gateway 개인 AI 어시스턴트 (2026-07)
- Ruff v0.16.0 정리 — 기본 규칙 59→413개 확대 (2026-07)
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요