Karpathy 펠리컨의 은퇴: LLM 벤치마크가 반지의 제왕으로 넘어간 진짜 이유

자전거 탄 펠리컨을 SVG로 그리게 하던 시대가 저물고, 이제는 LLM에게 반지의 제왕을 통째로 3D 세계로 렌더링시키는 시대가 열렸습니다. 그 전환점과 아직 남은 결정적 한계를 함께 짚어봅니다.

Karpathy 펠리컨 시험이 끝났다는데, 뭐가 달라진 걸까요?

몇 달 전만 해도 새 LLM이 나오면 사람들이 제일 먼저 시키던 게 있었어요. “자전거 탄 펠리컨을 SVG로 그려봐.” 코드만으로 그림을 그리게 하는 이 단순한 과제가 의외로 모델의 공간 감각을 잘 드러냈거든요. 그런데 최근 업계에서 이 펠리컨 벤치마크가 “이제 포화됐다”는 이야기가 돌기 시작했습니다.

발단은 Andrej Karpathy가 공유한 실험이었어요. Opus 5에게 반지의 제왕 첫 문단과 100만 토큰 예산을 주고 Three.js로 렌더링하라고 시켰더니, 약 2시간 동안 5,500줄의 코드를 스스로 짜서 하나의 움직이는 세계를 만들어냈거든요. 결과물은 어설펐지만, 평가의 무대가 '단일 이미지'에서 '장시간 세계 생성'으로 넘어갔다는 신호였어요. 오늘은 이 실험의 숫자와 논쟁을 실무자 관점에서 뜯어보겠습니다.

⚡ 이 글의 핵심만 먼저 보기 (Key Takeaways)

벤치마크 전환: '자전거 탄 펠리컨 SVG' 단일 결과물 평가가 포화되고, 세계·게임을 절차적으로 구현하는 장시간 과제로 이동했습니다.
핵심 실험: Opus 5에 반지의 제왕 첫 문단 + 100만 토큰을 주자 약 2시간 동안 5,500줄 Three.js 코드를 작성했습니다.
비용의 파괴력: 사람이 시간 대비 가치가 낮아 안 하던 초맞춤형 콘텐츠를 약 10달러에 주문형으로 만들 수 있게 됐습니다.
결정적 한계: LLM은 영상을 효율적으로 인식하지 못하고 자기 게임을 직접 플레이해 검증하지 못해, 느린 스크린샷에 의존하다 실수를 남겼습니다.
뜨거운 논쟁: “결국 three.js 코딩 실력일 뿐”이라는 회의론과 “공간 추론·직관 물리를 요구하는 진짜 평가”라는 옹호가 팽팽합니다.
바로 해볼 것: Claude Code로 Three.js/ogl.js 씬을 생성하고 브라우저에서 로딩·렌더링을 직접 측정하는 실전 루프를 돌려볼 수 있습니다.

1. 펠리컨 벤치마크는 원래 무엇이었나

'자전거 탄 펠리컨' 과제는 사실 굉장히 영리한 시험이었어요. 모델에게 이미지 생성기를 주는 게 아니라, SVG 코드만으로 펠리컨과 자전거를 그리게 하는 거였거든요. 그러려면 “자전거 프레임이 어떻게 생겼는지”, “펠리컨이 어디에 앉는지” 같은 걸 좌표와 도형으로 풀어내야 했죠.

① Why SVG — 왜 하필 벡터 코드였나

SVG는 픽셀이 아니라 좌표와 곡선의 나열이에요. 그래서 결과물이 그럴듯하려면 모델이 사물의 구조를 '머릿속'에서 이해하고 있어야 합니다. 1년 전엔 대부분의 모델이 이걸 어려워했고, 그래서 잘 그리면 좋은 모델이라는 신호가 됐어요.

② Saturation — 이제는 다들 잘해서 시시해졌다

문제는 이 과제가 너무 유명해지고 모델들이 다 잘하게 되면서 변별력을 잃었다는 겁니다. 실무자들 사이에서도 “여전히 자전거 조향 부분은 제대로 이해 못 하는 것 같은데”라는 반응이 나오긴 했지만, 대체로 “이제 흥미가 떨어졌다”는 쪽이었어요. 벤치마크가 포화되면 새로운 과제가 필요합니다.

💡 이렇게 쓰세요:
새 모델을 빠르게 감별하고 싶다면 '정답이 학습 분포 안에 없는' 과제를 던지세요. 유명 벤치마크는 이미 학습됐을 가능성이 큽니다. 대신 여러분 업무의 실제 산출물(사내 문서 포맷, 특정 라이브러리 코드)을 만들게 해서 초기 성능이 형편없는지부터 확인하는 게 변별력이 높아요.

2. 100만 토큰으로 만든 반지의 제왕 세계

Karpathy가 던진 새 과제는 스케일이 완전히 달랐어요. Opus 5에게 반지의 제왕 첫 문단을 주고, 100만 토큰 예산 안에서 Three.js로 그 장면을 렌더링하라고 시킨 거예요. 단일 이미지가 아니라 '움직이는 세계'를요.

1) The numbers — 2시간, 5,500줄, 그리고 10달러

Opus 5는 약 2시간 동안 5,500줄의 코드를 작성했어요. 폴리곤 자산을 절차적으로 만들고, 그걸 3차원 좌표에 배치한 다음, 이야기 전개에 맞춰 애니메이션으로 연결했죠. 결과는 매끄럽지 않았지만 실제로 작동하는 결과물이었습니다. 그리고 이 전체 비용이 약 10달러였어요.

항목	펠리컨 SVG	반지의 제왕 세계
산출물	정적 벡터 이미지 1장	움직이는 3D 씬(Three.js)
작업 시간	수 초	약 2시간
코드량	수십 줄	약 5,500줄
요구 능력	구조 이해	공간 추론 + 직관 물리 + 장시간 계획
비용	거의 0	약 10달러

2) On-demand worlds — 초맞춤형 콘텐츠의 경제학

여기서 진짜 핵심이 있어요. 사람이 직접 만들기엔 시간 대비 가치가 안 나와서 아무도 시도하지 않던 초맞춤형 콘텐츠를, 이제 10달러와 LLM의 인내력으로 주문형 제작할 수 있다는 겁니다. 상상한 세계에 플레이어를 관찰자 NPC나 등장인물로 넣는 식으로 확장하면, Karpathy 표현으로 'X를 소재로 한 일회성 GTA'를 만드는 개념이 되는 거죠.

3. 왜 이게 좋은 새 벤치마크인가

좋은 평가 과제의 조건은 의외로 명확해요. 초기 성능이 형편없고, 개선 여지가 커야 합니다. 다들 만점 받는 시험은 변별력이 없으니까요. 이 과제는 바로 그 조건을 노리고 의도적으로 어렵게 설계됐어요.

① Spatial reasoning — 문학 한 문단을 3D로 바꾸는 능력

추상적이고 모호한 문학 문단 하나를 3D 애니메이션으로 옮기려면 뭐가 필요할까요? 공간 관계, 직관적 물리, 일상 사물에 대한 막대한 암묵지, 그리고 3D 변환과 컴퓨터 그래픽 수학까지요. 저도 처음엔 '코드 좀 잘 짜는 거 아냐?' 싶었는데, 문단을 씬으로 번역하는 과정 자체가 물리 세계 이해를 요구한다는 점이 흥미로웠어요.

② Out-of-distribution — 학습 분포 밖을 노린 설계

이 과제가 영리한 건 기존 영상 생성 파이프라인을 쓰지 못하게 막았다는 점이에요. 공간 추론과 제1원리로 애니메이션을 구성해야만 하죠. 1년 전 대부분의 모델에게 SVG 생성이 '분포 밖 과제'였던 것과 똑같은 구도예요. 그래서 지금 결과물이 형편없다는 사실이 오히려 벤치마크로서는 장점입니다.

💡 이렇게 쓰세요:
모델 성능을 정성적으로 추적하고 싶다면, 같은 프롬프트(예: 특정 문단의 3D 씬 생성)를 고정해두고 버전이 올라갈 때마다 결과물을 비교 보관하세요. 점수가 아니라 '눈으로 보이는 완성도 곡선'이 향후 발전을 가늠하는 실용적 지표가 됩니다.

4. 치명적 약점: LLM은 자기 결과를 못 본다

이 실험에서 가장 중요한 교훈은 사실 실패 지점에 있어요. 세계와 게임은 LLM이 자기 결과물을 직접 검증하기 어려운 영역이거든요. 이게 왜 중요하냐면, 검증 못 하는 작업은 완성도를 스스로 끌어올릴 수 없기 때문이에요.

1) No video perception — 영상을 효율적으로 못 본다

LLM은 비디오를 효율적이고 자연스럽게 인식하지 못합니다. 자기가 만든 게임을 직접 플레이하면서 “아, 여기 캐릭터가 벽을 뚫네” 하고 확인하는 게 안 되는 거죠. Opus 5는 여러 시점의 스크린샷을 느리고 수고스럽게 하나씩 확인해야 했고, 그 과정에서 몇 차례 실수해 어설픈 부분을 다수 남겼어요.

[사람의 검증 루프]        [LLM의 검증 루프]
만든다 -> 플레이한다        만든다 -> 스크린샷 요청
  ^         |               ^         |
고친다  <- 문제를 본다       고친다  <- 정적 이미지 몇 장만
(실시간, 연속)             (느림, 불연속, 놓침 많음)

② The bottleneck — 멀티모달 인식이 병목이다

결국 장시간 생성 작업의 완성도를 높이는 열쇠는 코드 생성 능력이 아니라 멀티모달 인식과 게임 플레이 능력이라는 결론이 나와요. 만들 줄은 아는데 잘 만들었는지 볼 줄을 모르는 상태인 거죠. 이 병목이 풀려야 '어설픈 세계'가 '쓸 만한 세계'가 됩니다.

5. 결국 three.js 실력 아니냐 논쟁

이 실험을 두고 실무자들 사이에서 뜨거운 논쟁이 붙었어요. 저도 양쪽 다 일리가 있다고 봐서 정리해봤습니다.

1) 회의론 — 트위터용 화려한 데모일 뿐

비판 쪽 논리는 이래요. Anthropic 모델은 three.js 코드 생성에 특별히 잘 훈련된 것으로 보인다는 거예요. 그러면 이 과제는 'three.js를 짤 수 있는가' 외에는 별 지표가 안 된다는 거죠. 영상과 3D 애니메이션이 소셜 미디어에서 제일 잘 먹히니까, 진짜 평가라기보다 트위터 관심용 소재에 가깝다는 뼈아픈 지적도 있었어요.

2) 옹호론 — 문단을 씬으로 옮기는 건 코딩이 아니다

반대쪽은 이렇게 반박합니다. 모호한 문학 문단을 3D로 바꾸는 데 필요한 공간 관계와 직관 물리, 암묵지를 '단순 three.js 코딩 능력'으로 환원하는 건 터무니없다는 거예요. 실제로 이 발상을 응용해 영화 장면(Back to the Future의 DeLorean, Apocalypto의 창던지기 시퀀스)을 3D로 만든 사례들도 커뮤니티에 올라왔는데, 정밀도는 낮아도 물리가 제법 그럴듯했다는 후기가 있었어요.

3) 냉정한 중간 지점 — 진짜 평가는 따로 있다

가장 현실적인 의견은 이거였어요. 진짜 평가는 실제 워크로드로 모델별 비용·품질·속도를 측정하는 것이지, 트위터에 올릴 화려한 영상이 아니라는 거죠. 데이터베이스 백엔드나 금융·물류 시스템처럼 경제적 가치가 큰 지루한 영역에서의 성능이 결국 중요하다는 균형 잡힌 시각이 인상적이었습니다.

6. 지금 당장 따라 할 수 있는 실전 활용

이 실험은 구경만 할 게 아니라 직접 재현해볼 수 있어요. 필요한 건 Claude 계정과 브라우저 하나뿐입니다.

① Claude Code로 씬 생성하기

Claude Code에서 Opus 5나 Sonnet 5를 붙이고, “이 문단을 Three.js 씬으로 렌더링해줘”라고 요청해보세요. 핵심은 결과를 브라우저에서 직접 확인하며 반복하는 거예요. 사람이 검증 루프를 대신 돌려주면 LLM의 '눈 없음' 문제가 상당 부분 해소됩니다.

② three.js에서 ogl.js로 최적화하기

커뮤니티에서는 생성한 게임을 three.js에서 ogl.js로 옮겨 페이지 용량을 약 600KB에서 50KB로 줄이고, 4G 모바일 로딩을 수 초에서 약 0.5초로 단축한 실전 사례가 화제였어요. Claude 모델이 WebGL과 렌더링 속도를 이해하고 있어서, 브라우저 내장 도구로 변경 효과를 직접 측정하며 최적화할 수 있었다고 합니다.

💡 이렇게 쓰세요:
문서 대표 이미지나 랜딩 페이지 히어로 영역을 정적 PNG 대신 가벼운 3D 애니메이션으로 바꿔보세요. ① 원하는 장면을 문장으로 설명 → ② Claude Code로 Three.js 씬 생성 → ③ 브라우저에서 확인·수정 → ④ ogl.js로 경량화. Karpathy의 실험처럼 '주문형 초맞춤 콘텐츠'를 저비용으로 만드는 실전 워크플로입니다.

Karpathy의 사상적 배경이 궁금하다면 Andrej Karpathy AI 사상 5가지: Software 2.0·Vibe Coding 실전 완벽 정리도 함께 보시면 이 실험이 왜 나왔는지 맥락이 잡힙니다.

새 LLM이 나올 때마다 어떻게 평가할지 고민하는 ML 엔지니어·연구자
Three.js·WebGL로 인터랙티브 콘텐츠를 만드는 프론트엔드·크리에이티브 개발자
LLM으로 '주문형 콘텐츠' 제품을 기획 중인 스타트업 창업자·PM
AI 벤치마크의 한계와 방향을 이해하고 싶은 AI 프로덕트 담당자
멀티모달·에이전트 검증 문제에 관심 있는 연구 지향 개발자
화려한 데모와 진짜 실력을 구분하고 싶은 기술 의사결정자

8. 자주 묻는 질문 (FAQ)

Q. 펠리컨 벤치마크는 이제 완전히 쓸모없어졌나요?

A. 그렇지 않아요. 커뮤니티에서도 “펠리컨 시험만으로도 여전히 모델을 잘 평가할 수 있다”는 의견이 많았습니다. 다만 대부분의 모델이 잘하게 되면서 변별력이 떨어졌을 뿐이에요. 여전히 자전거 조향 구조 같은 세부에서 약점이 드러나기 때문에 빠른 감별용으로는 유효합니다.

Q. 정말 10달러로 이런 3D 세계를 만들 수 있나요?

A. 네, 다만 '완성도 높은' 결과를 기대하면 안 됩니다. Karpathy의 결과물도 공중에 뜬 창문이나 어설픈 모델링이 많았어요. 10달러의 가치는 완성도가 아니라 '사람이 안 하던 초맞춤 작업을 자동으로 시도해준다'는 데 있어요. 사람의 검토·수정이 붙어야 쓸 만해집니다.

Q. 이 실험이 Anthropic 모델에만 유리한 것 아닌가요?

A. 그 지적은 타당합니다. Anthropic 모델이 three.js 생성에 특히 강하다는 관찰이 있었으니까요. 그래서 공정한 평가라면 다른 모델과 동일 프롬프트로 비교하거나, three.js가 아닌 다른 렌더링 방식도 함께 시켜봐야 합니다. 단일 데모를 모델 우열의 결론으로 삼는 건 위험해요.

✍️ 글을 마치며

Karpathy 펠리컨의 은퇴가 시사하는 건 단순해요. 모델이 좋아지면 벤치마크도 진화해야 하고, 이제 그 무대가 '단일 이미지'에서 '장시간 세계 생성'으로 넘어갔다는 거죠. 동시에 이 실험은 LLM이 자기 결과를 못 본다는 검증의 벽도 선명하게 드러냈습니다.

저는 Claude Code로 짧은 문단 하나를 Three.js 씬으로 렌더링하고, 브라우저에서 검증 루프를 직접 돌려보는 걸 가장 먼저 해볼 것 같아요. LLM에게 부족한 '눈'을 제가 대신 채워주면 완성도가 얼마나 올라가는지 확인해보고 싶거든요.

여러분은 어떤 부분이 가장 인상적이셨나요? 댓글로 자유롭게 의견 남겨주세요! 😊