Claude Code Opus 5로 three.js 랜딩 페이지 만들기: 2026년 실전 로드맵 6단계

Claude Code에서 Opus 5를 지정하고 브라우저 확인 루프를 붙이면 three.js 3D 랜딩 페이지를 혼자서도 완성까지 밀고 갈 수 있습니다.

"저 같은 비개발자가 셰이더까지 손대야 하는 거 아니에요?" 이 질문, 정말 자주 받습니다. 저도 처음엔 똑같이 걱정했어요. 이 글에서는 실제 공개된 프롬프트와 검증 수치를 근거로, Claude Code와 Opus 5를 활용한 AI 코딩으로 three.js 랜딩 페이지를 만드는 순서와 함정을 정리했습니다.

왜 지금 가능해졌나: 모델과 도구가 만나는 지점

3D 웹은 원래 진입장벽이 셋이었죠. 수학(행렬·카메라), 셰이더(GPU 언어), 성능 튜닝입니다. 이 세 가지가 한꺼번에 낮아진 이유는 모델 하나 때문이 아니라 모델과 도구가 결합했기 때문이에요.

모델 축: Claude Code 공식 문서는 복잡한 에이전트형 코딩과 엔터프라이즈 작업에는 Opus 5로 시작하라고 권합니다. Opus 5와 Sonnet 5에서는 작업 강도를 정하는 effort 값이 기본 high라, 별도 설정 없이도 여러 파일을 읽고 검증까지 밀고 나가는 쪽으로 동작해요.
도구 축: 브라우저를 붙여주면 결과물을 스스로 스크린샷으로 확인합니다. 공식 문서는 프론트엔드 작업에 Claude Code Chrome 확장을 권장하고, 별도로 Chrome DevTools MCP 서버(chrome-devtools-mcp)를 붙이면 성능 트레이스와 콘솔 로그까지 직접 확인해요.
분업 축: Anthropic이 약 400,000건의 인터랙티브 세션(약 235,000명)을 분석한 자료에 따르면, 사람은 계획 결정의 약 70%를 하지만 실행 결정은 약 20%만 합니다. 무엇을 만들지는 사람이 정하고, 어떻게 만들지는 에이전트가 정하는 구도죠. 인터랙티브 웹 랜딩 작업도 같은 분업이 자연스럽습니다.

실전 사례 해부: MengTo의 kage

이 주제에서 가장 값어치 있는 자료는 결과물과 빌드 프롬프트가 함께 공개된 1차 사례, kage입니다. DesignCode 창업자 Meng To가 Claude Code로 만든 three.js 사이트를 2026-08-08 오픈소스로 공개했고, 2026-08-15 gh api 실측 기준 977 stars / 183 forks를 기록했습니다.

실전 사례 해부: MengTo의 kage

이미지 출처: github.com

항목	값
저장소	`github.com/MengTo/kage`
공개일	2026-08-08 (2026-08-15 실측 977 stars / 183 forks)
정체	교토 산사의 밤길을 5개 챕터로 걷는 인터랙티브 스크롤 3D 사이트
구성	HTML 100%, `index.html` 단일 파일 238KB
사용 three.js	r149 vendored (저장소에 직접 포함)
빌드	빌드 스텝 0, 패키지 매니저 0, 런타임 네트워크 의존성 0
총 용량	three.js+코드 합쳐 1MB 미만, 고화질 PNG 포함 3MB
라이브 사이트	`mengto.github.io/kage`

절차적 생성(사원·토리이·랜턴·달·지형·비·낙엽·안개·포스트프로세싱)은 코드가 만들고, 시네마틱 장면 플레이트와 전경 컷아웃은 GPT Image 2로 생성한 뒤 3D 씬 위에 HTML 레이어로 합성했어요. 화려한 결과물인데 기술 스택은 오히려 단순하네요. 프레임워크도, 빌드 도구도, 최신 렌더러도 안 씁니다. 복잡도를 낮춰야 AI가 끝까지 밀고 갈 수 있다는 신호로 읽는 게 맞을 겁니다.

라이선스: kage는 재사용 허가가 없는 저장소입니다. 977 stars를 받은 공개 저장소여도 재사용·재배포 허가는 부여되지 않았어요(vendored된 three.js 런타임만 MIT 고지 유지). 공개가 곧 자유 사용은 아니거든요. 이 글이 참고하는 건 코드가 아니라 방법론입니다. 프롬프트 구조, 금지 목록, 자가 검증 지시, 단일 파일과 버전 고정이라는 설계 판단을 참고하고, 상업적 랜딩에 쓸 거라면 코드는 직접 작성하세요.

PROMPT.md 4블록: 프롬프트가 아니라 사양서

공개된 빌드 프롬프트(PROMPT.md, 2,642바이트)는 네 덩어리로 나뉩니다. "멋지게 만들어줘"가 아니라 사양서에 가까워요.

Experience(경험): 고정된 풀뷰포트 캔버스를 환경 레이어로 깔고, 스크롤이 하나의 연속된 카메라 패스를 구동하게 합니다. 팔레트는 near-black / blue-charcoal / warm amber / bone white / vermilion으로 고정했어요.
Layout(레이아웃): hero → temple threshold → still gardens → sacred craft chapters → afterlight closing → manifesto footer 순서를 못 박습니다.
Motion(모션): 헤딩은 단어 단위로 리빌하고, reduced-motion에서도 읽기 경험을 전부 보존하라고 명시합니다.
Interaction and quality(인터랙션·품질): 커스텀 커서는 fine pointer에서만, 시맨틱 랜드마크와 모바일 내비를 넣고, 상대 경로를 쓰라고 지시합니다.

이 프롬프트에서 눈여겨봐야 할 두 문장이 있어요. 첫째, 금지 목록으로 AI 슬롭을 앞에서 차단합니다.

"Avoid frameworks, build tooling, analytics, trackers, remote fonts, placeholder imagery, generic glassmorphism, excessive glow, and decorative motion without narrative purpose."

생성 모델이 기본값으로 쏟아내는 뻔한 글래스모피즘·과한 글로우·서사 없는 장식용 모션을 이름으로 지목해 미리 막은 거죠. 둘째, 자가 검증 루프를 프롬프트 안에 직접 명령으로 내장했습니다.

"Verify at desktop and approximately 390 × 844, check all assets for 404s, parse every inline script, inspect the browser console, and test one complete scroll/navigation interaction before shipping."

데스크톱과 약 390×844에서 확인하고, 모든 에셋의 404를 점검하고, 인라인 스크립트를 전부 파싱하고, 브라우저 콘솔을 확인하고, 스크롤 인터랙션을 한 번 완주한 뒤 출고하라는 조건이에요. "원샷으로 완성됐다"는 주장이 X에서 자주 나오지만, 저자 본인은 토큰과 프롬프트가 많이 들었다고 밝혔습니다. 브라우저를 직접 열어 확인하고 반복한 결과라는 뜻이죠.

기획부터 배포까지, 실전 워크플로우 6단계

Claude Code 공식 베스트 프랙티스(조사 → 계획 → 구현, 증거 요구)에 3D 특유의 단계를 얹은 순서입니다.

단계	할 일
1. 프로젝트 규칙 파일	`CLAUDE.md`에 목표 프레임률, 지원 최저 사양, 렌더러 선택(WebGL/WebGPU), 에셋 용량 상한을 적어둡니다
2. 레퍼런스 + plan mode	벤치마킹할 사이트 스크린샷을 붙이고, `@`로 파일을 참조하고, plan mode로 탐색과 실행을 분리합니다
3. 씬 뼈대부터	Scene, Camera, Renderer 삼각형을 먼저 세우고, GLTF 모델과 포스트프로세싱은 뼈대가 도는 걸 확인한 다음 얹습니다
4. 브라우저 스크린샷 루프	Claude Code Chrome 확장 또는 Chrome DevTools MCP로 이동·스크린샷·콘솔 확인·수정·재확인을 반복합니다
5. 성능 수치화	`performance_start_trace`로 트레이스를 뜨고 `performance_analyze_insight("LCPBreakdown")`으로 Core Web Vitals을 확인합니다
6. 접근성 폴백 + 배포	`prefers-reduced-motion` 처리를 넣고 배포합니다

4단계가 이 워크플로우의 핵심이에요. Chrome DevTools MCP는 이렇게 붙입니다.

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

--isolated=true(임시 프로필), --viewport=1920x1080, 기본 도구만 노출하는 --slim 옵션이 있고, 설정 후에는 Claude Code를 재시작해야 로드됩니다. 모델은 세 가지 방법으로 지정할 수 있어요.

# 그 세션 한 번만
claude --model claude-opus-5

# 대화 중 즉시 전환 (Claude Code 안에서 입력)
/model

# 영구 기본값
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5

3D 씬 설계처럼 무거운 계획은 Opus가, 반복 수정처럼 가벼운 실행은 Sonnet이 맡는 /model opusplan 조합도 랜딩 작업엔 합이 좋습니다. 모델을 바꿔도 대화가 지워지지 않아 이어받기가 자연스럽거든요.

검증 수치로 보는 three.js와 브라우저 지원

항목	값	신뢰도
three.js 현행 릴리스	r185 (2026-07-01 발행)	검증됨
npm 패키지 버전	0.185.1	검증됨
직전 릴리스	r184 (2026-04-16)	검증됨
kage가 고정한 버전	r149 (2023-01-26 릴리스)	검증됨
전체 임포트 크기	약 155KB gzip	Tier 3, 참고치
트리셰이킹 후	약 100~130KB gzip	Tier 3, 참고치

검증 수치로 보는 three.js와 브라우저 지원

이미지 출처: github.com

번들 크기 두 줄은 공식 포럼 사용자 보고 기반이라 참고치로만 쓰세요. 단정적인 수치가 필요하면 실제 프로젝트에서 빌드 후 직접 측정하는 편이 안전합니다.

WebGPU는 Chrome, Edge, Firefox, Safari에서 공식 지원되지만 플랫폼 조건이 붙어요.

브라우저	지원 상황
Chrome / Edge	Chrome 113부터, Android는 Chrome 121 + Android 12 이상 + Qualcomm·ARM GPU 조건
Firefox	Windows는 Firefox 141부터, macOS Tahoe 26 ARM64는 Firefox 145부터
Safari	macOS Tahoe 26, iOS 26, iPadOS 26, visionOS 26

접근성 기준은 WCAG 성공 기준 2.3.3(Animation from Interactions)입니다. WebGL 씬은 CSS가 아니라 코드로 그리므로 자바스크립트용 기법인 SCR40을 적용합니다.

const query = window.matchMedia("(prefers-reduced-motion: no-preference)");

function applyMotionPreference() {
  const motionAllowed = query.matches;
  camera.autoRotate = motionAllowed;
  parallaxLayer.enabled = motionAllowed;
}

applyMotionPreference();
query.addEventListener("change", applyMotionPreference);

값이 reduce이지 none이 아니라는 점이 중요해요. 전부 없애라는 뜻이 아니라, 자동 회전과 카메라 드리프트를 멈추고 정지 프레임 하나를 렌더하는 정도의 절충이 실무적입니다.

초보가 흔히 밟는 함정 7가지

"최신 버전"에 집착한다. kage는 r185가 아니라 r149를 저장소에 직접 넣어 씁니다. 버전이 고정돼 있으면 AI가 만든 코드가 나중에 깨지지 않고, CDN도 빌드도 필요 없어 정적 호스팅만으로 끝나요. AI에게 시킬 때는 "최신을 쓰라"보다 "이 버전으로 고정하라"가 안전합니다.
번들 크기를 트리셰이킹으로만 해결하려 한다. 전용 도구 벤치마크에서도 도구 제작자 본인이 "50~200kB 차이는 작은 편이니 대부분은 신경 쓸 것 없다"고 적어뒀어요. 더 큰 이득은 로더·컨트롤·포스트프로세싱 같은 애드온을 지연 로딩하는 데서 나옵니다.
WebGPU면 무조건 빠를 거라고 생각한다. 공식 포럼에는 같은 씬에서 WebGL이 WebGPU보다 2~4배 높은 FPS를 냈다는 보고가 있습니다. 정하기 전에 본인 워크로드로 직접 재보세요.
모바일과 저사양을 나중에 생각한다. 안드로이드는 Chrome 121 이상 + Android 12 이상 + Qualcomm·ARM GPU 조건이 붙어요. 처음부터 정적 히어로 이미지 같은 폴백 경로를 계획에 넣어야 합니다.
prefers-reduced-motion을 빼먹는다. 스크롤 연동 3D는 전정기관 자극의 교과서적 사례라 WCAG 2.3.3에 걸립니다. SCR40 패턴을 기본으로 넣으세요.
무한 수정 루프에 빠져 비용이 샌다. 3D의 문제가 아니라 에이전트 운용의 문제예요. 통과/실패가 명확한 검사(스크린샷 비교, 프레임률 목표치, 번들 크기 상한)를 미리 정해두는 게 실질적인 방어입니다.
공개된 사례 코드를 그대로 가져다 쓴다. kage는 라이선스가 없어요. 977 stars를 받았어도 재사용·재배포 허가는 없다는 걸 꼭 기억하세요.

커뮤니티 온도차: X의 열광과 HN의 냉정

X와 Hacker News의 정서는 정반대로 갈립니다. 2026-07-25 X에서는 Opus 5로 three.js 게임을 "원샷"으로 만들었다는 게시물이 조회 487만 회를 찍으며 3D 원샷 붐이 일었어요. 하지만 이 주장은 본인 홍보성이고 반론도 함께 달려 있어, "그렇게 만들었다는 주장이 나온다" 정도로만 받아들이는 게 맞습니다.

반면 Hacker News에서는 2026-08-14 "Why does Opus 5 feel worse to work with?"가 861 points·778 comments로 상위에 올랐어요. 댓글 정서는 혼재이면서도 부정 쪽이 두껍고, 반복해서 나온 실무 조언은 "설계와 표준은 사람이 100% 잡고 거기로 몰아가야지, 안 그러면 복잡도가 계속 쌓여 무슨 일이 벌어지는지 모르게 된다"였습니다. 같은 날 "Maximizing the value of your Claude Code sessions"는 211 points를 받았는데, 지배적 불만은 비용이었어요. 예상치 못한 캐시 재기록으로 세션 비용이 정기적으로 100달러를 넘는다는 보고가 올라왔습니다.

두 축은 모순이 아니에요. 되기는 되는데 공짜는 아니라는 뜻이죠. kage 저자 본인도 토큰과 프롬프트가 많이 들었다고 밝혔습니다. (참고로 Reddit 쪽 반응은 이번 조사에서 접근이 막혀 확인하지 못했습니다.)

마무리

Claude Code와 Opus 5로 three.js 랜딩 페이지를 만드는 길은 이제 추측이 아니라 공개된 사례로 검증됐어요. 모델 지정 방법, 브라우저 확인 루프, kage의 PROMPT.md 구조까지 근거가 다 있습니다. 다음으로 해볼 만한 건 본인 프로젝트의 CLAUDE.md에 프레임률·에셋 용량 상한 같은 판정 기준부터 적어보는 거예요. 그게 함정 6번을 피하는 가장 확실한 출발점입니다.

자주 묻는 질문 (FAQ)

Q: Opus 5로 작업하면 비용이 많이 드나요?

Hacker News에서 가장 크게 터진 불만이 바로 이 지점입니다. 예상치 못한 캐시 재기록으로 세션 비용이 정기적으로 100달러를 넘는다는 보고가 있었어요. 통과/실패가 명확한 검사 기준을 미리 정해두면 무한 수정 루프로 인한 비용 낭비를 줄일 수 있습니다.

Q: 정말 프롬프트 한 번으로 완성되나요?

X에서는 "원샷"으로 3D 게임을 만들었다는 주장이 큰 도달을 기록했지만, 검증할 수 있는 근거는 없습니다. kage 저자 본인은 토큰과 프롬프트가 많이 들었다고 밝혔어요. 원샷보다는 반복 검증 루프가 실제 작업 모습에 가깝습니다.

Q: kage 코드를 그대로 가져다 써도 되나요?

안 됩니다. kage는 라이선스가 없는 저장소라 977 stars를 받았어도 재사용·재배포 허가는 부여되지 않았어요(vendored된 three.js 런타임만 MIT 고지 유지). 참고할 것은 코드가 아니라 프롬프트 구조와 설계 판단이고, 결과물은 직접 만들어야 합니다.

Claude Code Opus 5로 three.js 랜딩 페이지 만들기: 2026년 실전 로드맵 6단계