펠리컨 테스트를 넘어: LLM 평가는 이제 작은 세계를 만든다

LLM을 평가할 때 한동안 재미있는 기준 중 하나는 “자전거를 탄 펠리컨 SVG를 그려보라”였습니다. 그런데 GeekNews의 “Karpathy의 펠리컨” 요약 ↗은 이 기준이 이제 다음 단계로 넘어가고 있음을 보여줍니다. Andrej Karpathy는 단일 SVG 대신, 긴 토큰 예산을 주고 문학의 첫 문단을 3D 장면으로 구현하게 했습니다.

먼저 결론부터 말하면, 이 실험의 핵심은 “모델이 예쁜 3D 영상을 만들었다”가 아닙니다. LLM 평가의 단위가 정적인 산출물 하나에서, 코드, 장면, 애니메이션, 검증 루프가 엮인 작은 세계로 커지고 있다는 점이 중요합니다.

The Decoder가 링크한 Karpathy 실험 영상 ↗에서 추출한 한 장면입니다. 모델은 Tolkien의 첫 문단을 바탕으로 Bag End 주변의 3D 장면, 저폴리곤 자산, 움직임, 내레이션 타이밍을 절차적으로 구성했습니다.

이 글에서 다루는 내용:

• 펠리컨 SVG 테스트가 왜 좋은 “작은 평가”였는지
• Karpathy의 실험이 평가 단위를 어떻게 키웠는지
• 장시간 생성 결과를 검증하기 위해 무엇이 더 필요해지는지

펠리컨 테스트가 보여준 것

simonw/pelican-bicycle 저장소 ↗는 “Generate an SVG of a pelican riding a bicycle”이라는 단일 프롬프트로 여러 모델의 결과를 모아둔 벤치마크입니다. 프롬프트가 일부러 우스꽝스럽기 때문에, 모델이 학습 데이터에 있던 이미지를 그대로 재현하기보다 구조적 조합 능력을 보여줘야 합니다.

이 테스트가 좋았던 이유는 단순합니다. 결과가 SVG라서 사람이 바로 열어볼 수 있고, 펠리컨과 자전거라는 두 객체의 관계가 눈에 띄며, 실패도 꽤 선명합니다. 자전거가 없거나, 펠리컨이 얹혀 있지 않거나, SVG가 깨지면 바로 보입니다.

하지만 단일 SVG는 여전히 짧은 작업입니다. 정적인 결과 하나를 보면 모델의 공간 감각과 지시 이행 능력은 어느 정도 볼 수 있지만, 긴 작업을 유지하는 능력, 여러 자산을 일관되게 배치하는 능력, 시간에 따라 움직이는 장면을 완성하는 능력은 보기 어렵습니다.

평가 단위가 작은 세계로 커진다

Karpathy의 X 포스트 검색 스니펫 ↗과 The Decoder 기사 ↗에 따르면, 그는 Claude Opus 5에 The Lord of the Rings 첫 문단과 100만 토큰 예산, 약 10달러 수준의 비용 한도를 주고 Three.js 렌더링을 요청했습니다. 결과적으로 모델은 약 2시간 동안 5,500줄가량의 코드를 작성해 3D 장면을 만들었습니다.

여기서 흥미로운 점은 결과물이 “이미지”가 아니라 “실행 가능한 코드”라는 점입니다. 모델은 폴리곤 자산을 만들고, 좌표계 안에 배치하고, 장면 전환과 애니메이션을 연결해야 합니다. 단일 SVG보다 훨씬 긴 의존성 그래프를 다루는 셈입니다.

flowchart TD
    A[문학 첫 문단]
    B[장면 해석]
    C[3D 자산 생성]
    D[좌표 배치]
    E[애니메이션 구성]
    F[브라우저 렌더링]
    G[스크린샷 확인]

    A --> B --> C --> D --> E --> F --> G
    G -->|문제 발견| B

이 흐름은 제가 앞서 다룬 Grues in Comic 글과도 닮았습니다. Grues 사례가 오래된 게임을 임포터, IR, 엔진, 렌더러로 나누는 문제였다면, Karpathy의 실험은 짧은 텍스트를 장면, 자산, 카메라, 애니메이션으로 확장하는 문제입니다.

장시간 작업의 병목은 검증입니다

GeekNews 요약 ↗은 이 실험의 한계를 “비디오를 효율적으로 인식하거나 생성한 게임을 직접 플레이하며 검증하기 어렵다”는 점으로 정리합니다. The Decoder 기사 ↗도 모델이 자기 비디오 출력을 직접 보지 못해 스크린샷에 의존했고, 그 과정에서 오류가 남았다고 설명합니다.

이 지점이 중요합니다. 모델이 5,500줄을 쓸 수 있다는 사실보다, 그 5,500줄이 실제로 장면 의도를 만족하는지 평가하는 방법이 더 어려워집니다. 정적인 SVG는 한눈에 실패가 보이지만, 90초짜리 3D 장면은 시간, 카메라, 오브젝트 상호작용, 내레이션 싱크까지 봐야 합니다.

벤치마크가 아니라 하네스가 필요해진다

단일 결과물 평가에서는 좋은 프롬프트 하나와 사람의 눈이 꽤 잘 작동합니다. 하지만 작은 세계를 만들기 시작하면, 평가도 구조화되어야 합니다. 장면이 로드되는지, 특정 시점에 필요한 오브젝트가 있는지, 카메라가 대상과 너무 멀지 않은지, 애니메이션이 멈추지 않는지 같은 체크가 필요합니다.

이 관점은 GAN에서 빌려온 하네스 설계에서 다룬 generator-evaluator 루프와 직접 이어집니다. 생성자는 세계를 만들고, 평가자는 브라우저나 렌더러를 통해 실제 결과를 관찰해야 합니다. 모델이 좋아질수록 “프롬프트 하나로 끝”이 아니라, 더 큰 산출물을 다룰 하네스가 필요해집니다.

개발자에게 남는 질문

Karpathy의 실험은 아직 정량 벤치마크라기보다 vibe check에 가깝습니다. The Decoder도 이것이 hard benchmark는 아니라고 표현합니다. 그래도 방향성은 분명합니다. 모델 평가는 “이 프롬프트에 답을 잘했나”에서 “긴 시간 동안 작동하는 환경을 만들고, 스스로 또는 외부 도구로 확인할 수 있나”로 이동하고 있습니다.

이 변화는 개발자에게도 꽤 실용적인 질문을 던집니다. 다음에 에이전트에게 큰 작업을 맡길 때, 우리는 결과 파일만 받을 것인지, 아니면 실행 가능한 장면과 검증 절차까지 함께 받을 것인지 정해야 합니다.

저는 후자가 앞으로 더 중요해진다고 봅니다. AI가 코드를 길게 쓸수록, 개발자의 역할은 타이핑이 아니라 경계 설정, 관찰 지점 설계, 실패 기준 정의 쪽으로 이동합니다. AI 엔지니어링의 5계층에서 말한 것처럼, 모델 위에 어떤 시스템을 얹느냐가 결과 품질을 가르게 됩니다.

마무리

“자전거를 탄 펠리컨”은 좋은 시대의 좋은 테스트였습니다. 짧고, 이상하고, 실패가 잘 보였기 때문입니다. 하지만 모델이 더 긴 작업을 견디기 시작하면, 평가도 더 긴 시간축과 더 복잡한 산출물을 다뤄야 합니다.

Karpathy의 Lord of the Rings 실험은 완성도 높은 제품이라기보다 다음 질문을 던지는 신호입니다. 모델이 작은 세계를 만들 수 있다면, 우리는 그 세계가 제대로 작동하는지 어떻게 평가할 것인가. 앞으로의 AI 개발은 이 질문에 답하는 하네스 설계에 점점 더 가까워질 것입니다.

관련 내부 포스트:

• Grues in Comic: AI 에이전트가 클래식 게임을 다시 엮는 법 — 게임 구현에서 구조와 검증 기준이 왜 중요한지 다룬 사례
• GAN에서 빌려온 하네스 설계 — 장시간 생성 작업에서 generator-evaluator 루프가 필요한 이유
• From Code to System: 2026년 AI 엔지니어링의 5계층 — 모델, 하네스, 평가를 시스템으로 보는 큰 그림

참고 자료

• GeekNews: Karpathy의 펠리컨 ↗ — 한국어 요약과 핵심 논점
• Karpathy의 X 포스트 ↗ — 원문 실험 포스트
• The Decoder: Unicorn, pelican, Middle-earth ↗ — 실험 설명과 영상 링크
• simonw/pelican-bicycle ↗ — pelican-on-a-bicycle SVG 벤치마크 저장소