같은 프롬프트 한 장, Claude Sonnet 5.5 vs GPT Sol 6.1 — 3D 웹사이트 누가 더 잘 만들까
똑같은 싱글 프롬프트로 Claude Sonnet 5.5와 GPT Sol 6.1에게 어워즈급 3D 스크롤 웹사이트를 한 번씩 만들게 했습니다. 두 작품을 직접 체험하고, 챕터별 품평과 점수표로 비교합니다.

읽기 전에 핵심만
- 비주얼 완성도와 브랜드 해석은 Claude Sonnet 5.5가 앞섰습니다.
- 장애 복구, 접근성, 가벼움은 GPT Sol 6.1이 더 탄탄했습니다.
- 한 번의 실행 결과이므로 두 원본을 직접 체험하고 판단해 보세요.
최신 AI 모델이 나올 때마다 "코딩 벤치마크 몇 점"이라는 숫자가 먼저 돌아다닙니다. 그런데 숫자만으로는 그 모델이 만든 화면이 실제로 멋진지는 알 수 없습니다. 그래서 포에모라는 직접 시험해 봤습니다. 똑같은 프롬프트 한 장을 Claude Sonnet 5.5와 GPT Sol 6.1(OpenAI GPT 계열의 Sol 트랙)에 각각 한 번씩 넣고, 둘이 만든 웹사이트를 나란히 놓고 뜯어봤습니다.
두 작품은 아래 링크에서 직접 스크롤해 볼 수 있습니다. 모델이 뱉은 파일을 한 글자도 고치지 않고 그대로 올렸습니다.
시험 조건: 프롬프트 한 장, 딱 한 번
과제는 가상의 향수 브랜드 "AURORA VOID"의 티저 사이트입니다. 우주 관측소와 향수를 섞은 콘셉트로, 아래 조건을 HTML 파일 하나에 모두 담아야 합니다.
- Three.js 최신 버전의 WebGPU 렌더러를 쓰고, 안 되면 WebGL2로 자동 전환
- 스크롤에 따라 카메라가 6개 챕터를 지나가는 3D 여정 (INTRO → DIVE → TUNNEL → REVERSAL → REVEAL → OUTRO)
- 4장 REVERSAL에서 세계가 180도 뒤집히고 시간이 거꾸로 흐르는 연출
- 외부 음원 없이 코드로 합성한 사운드. 스크롤 속도에 따라 필터가 열리고 닫힘
- 모바일·저사양 자동 대응, 모션 줄이기 설정 대응, 콘솔 오류 0개
외부 이미지·3D 모델·오디오 파일은 전부 금지했습니다. 화면에 보이는 모든 것은 코드로 만들어야 합니다. 두 모델 모두 추론 강도는 high로 맞췄고, 각각 한 번만 실행했습니다. 다시 돌리면 결과가 달라질 수 있으니, 이 글은 "한 판 승부"의 기록으로 읽어 주세요. 프롬프트 전문은 글 아래쪽에 공개합니다.
| 항목 | Claude Sonnet 5.5 | GPT Sol 6.1 |
|---|---|---|
| 파일 크기 | 59.6KB · 1,149줄 | 47.8KB · 436줄 |
| 글꼴 | Instrument Serif + Martian Mono | Cormorant Garamond + Space Grotesk |
| 네온 색 | 전기 시안 → 반전 후 주홍 | 시안 → 반전 후 분홍·갈색 |
| 은하 파티클(PC 기준) | 60,000개 | 32,000개 |
| 콘솔 앱 오류(우리 시험 환경) | 0건 | 0건 |
첫인상: 둘 다 "돌아간다", 그다음이 갈린다
먼저 기본기부터 말하면, 둘 다 합격입니다. 두 파일 모두 한 번에 열렸고, 로딩 카운터 → 소리 선택 → 6챕터 스크롤 → 마지막 버튼까지 끊김 없이 이어졌습니다. 우리 시험 환경에서 두 작품 모두 앱이 낸 콘솔 오류는 0건이었습니다.
차이는 "무엇을 보여 주느냐"에서 벌어졌습니다. 표지 이미지가 3장 TUNNEL 장면입니다. Sonnet은 육각형 링 140개 사이로 파편 360개를 흩뿌리고, 스크롤을 빨리 할수록 화면 가장자리가 빨강·초록·파랑으로 찢어지는 색수차를 강하게 걸었습니다. 속도감이 눈으로 느껴집니다. Sol은 원형 링 240개로 깔끔한 터널을 만들었는데, 링 너머로 다음 장의 오브제가 미리 비쳐 보이는 구성이 영리합니다. 다만 화면의 변화 폭은 Sonnet 쪽이 확실히 큽니다.
챕터별 품평

1장 INTRO. Sonnet은 거대한 나선 은하 한가운데 노이즈 구체를 띄우고, 그 아래 "AURORA / VOID"를 큰 세리프로 깔았습니다. 잡지 표지 같은 구도입니다. Sol은 은하 대신 거친 표면의 구체를 정면에 크게 두고 제목을 글자 단위로 올렸습니다. 좀 더 미니멀합니다.
2장 DIVE. 구체를 뚫고 들어가는 장면입니다. Sonnet은 구체 안쪽에 들어가면 노이즈가 등고선처럼 흐르는 화면으로 바뀌어서 "표면을 뚫었다"는 감각이 분명합니다. Sol은 구체를 바깥에서 보는 시간이 길어 관통의 순간이 약합니다.
3장 TUNNEL. 위에서 말한 대로 Sonnet의 속도감이 압도적입니다. Sol은 정돈되어 있지만 링 모양이 한 가지라 단조롭습니다.
4장 REVERSAL. 이 프롬프트의 핵심 장면입니다. 둘 다 카메라를 180도 굴리고, 색을 반전하고, 시간의 부호를 뒤집고, 흰 섬광과 슬로모션을 넣었습니다. 요구사항은 둘 다 빠짐없이 챙겼습니다. 연출의 설계는 다릅니다. Sonnet은 터널 끝의 빛나는 특이점 주위를 머리핀처럼 돌아 나와, 지나온 터널을 거꾸로 되짚어 후퇴합니다. 화면 구석의 수치(Z 좌표, 시간 방향 T)가 +1.00에서 −1.00으로 넘어가는 디테일까지 넣었습니다. Sol은 터널 끝에서 몸을 돌려 뒤를 바라보며 물러나는 방식이라 더 단순하지만 흐름이 매끄럽습니다.
5장 REVEAL. 이번 대결에서 가장 차이가 큰 장면입니다. Sonnet의 유리 매듭은 빨강·초록·파랑 빛이 각각 다른 각도로 굴절되도록 계산해서, 무지개빛이 도는 진짜 크리스털처럼 보입니다. 이번 대결에서 가장 아름다운 한 컷입니다. Sol의 매듭도 유리 질감을 흉내 냈지만, 반전된 분홍·갈색 링 터널 한가운데 놓여 오브제와 배경이 섞여 버립니다.
6장 OUTRO. 프롬프트는 "카메라가 서서히 멀어지며 버튼으로 마무리"였습니다. Sonnet은 실제로 은하 밖까지 빠져나오고, 마그네틱 원형 버튼 "Enter the Void"를 누르면 처음으로 날아 돌아갑니다. Sol은 터널 안에 머문 채 끝나서 "Stay unfound." 문구와 버튼이 링 무늬에 묻혀 잘 안 읽혔습니다. 대신 Sol의 버튼은 "You have arrived"라는 마무리 창을 띄워 여정의 끝을 따로 매듭짓습니다.
보이지 않는 곳: 카피, 사운드, 그리고 엔지니어링
카피와 브랜드 해석은 Sonnet이 한 수 위입니다. Sonnet은 향수의 향 구조(탑 노트 → 하트 노트 → 베이스 노트)를 챕터에 겹쳤습니다. DIVE는 "Top note · Ozone, cold iron", TUNNEL은 "Heart note", REVEAL은 "Base note"입니다. 향수 브랜드라는 설정을 실제 이야기 구조로 바꾼 것입니다. Sol의 문구("Beyond the visible.", "Even time can turn.")는 분위기는 좋지만 어느 브랜드에 붙여도 되는 일반론에 가깝습니다.
사운드는 둘 다 코드로 전부 합성했고, 설계는 Sonnet이 더 촘촘합니다. 이 부분은 코드를 읽고 평가했고, 귀로 비교 청취한 결과는 아닙니다. 둘 다 스크롤 속도에 따라 필터를 지수 곡선으로 여는 핵심 요구를 지켰습니다. Sonnet은 반전 순간에 역재생 잔향, 테이프가 멈추듯 음이 떨어지는 효과, 0.4초의 정적 뒤 서브 베이스 쿵, 아르페지오 방향 반전까지 네 가지를 모두 따로 구현했습니다. 음이 찢어지지 않게 막는 압축기와 리미터도 두 겹으로 걸었습니다. Sol은 같은 효과를 더 간결하게 처리했고, 리미터 없이 압축기 하나만 썼습니다.
엔지니어링의 견고함은 Sol이 확실히 앞섭니다. 이 부분은 장애를 일부러 일으켜 본 것이 아니라 코드를 읽고 판단했습니다. 그래픽 장치가 끊기면 Sonnet은 정지 화면으로 넘어가지만, Sol은 WebGL2로 다시 살려서 여정을 이어 갑니다. 뒤로 가기로 페이지가 복원되는 경우도 Sol만 따로 처리했습니다. 로딩 화면의 키보드 포커스 가두기, 스크린리더용 진행률 표시, 카메라 동선 계산을 따로 떼어 시험할 수 있게 만든 구조도 코드에 들어 있습니다. 운영할 사이트라면 이런 부분이 나중에 장애를 막습니다.
가벼움도 Sol의 강점입니다. 같은 소프트웨어 렌더 환경(WebGPU)에서 로딩 완료까지 Sol은 약 3초, Sonnet은 약 25초가 걸렸습니다. 한 번 잰 값이고, 은하 파티클도 60,000개 대 32,000개로 부하가 달랐습니다. GPU 없는 서버의 극단적인 조건이라 실제 PC 체감과는 다르지만, Sonnet 쪽이 훨씬 무거운 장면을 그린다는 방향은 분명합니다. 반대로 Sol은 제목 등장 애니메이션을 프레임 속도에 묶어 두어서, 느린 기기에서는 제목이 늦게 떠오릅니다.
점수표와 결론
10점 만점, 심사자 주관 점수입니다. 평가 항목은 두 결과물을 본 뒤에 심사자가 정했습니다.
| 평가 항목 | Sonnet 5.5 | Sol 6.1 |
|---|---|---|
| 비주얼 완성도 | 9 | 7 |
| 반전 연출 | 8 | 7 |
| 타이포·카피·브랜드 해석 | 9 | 7 |
| 텍스트 가독성 | 8 | 5 |
| 사운드 설계(코드 기준) | 9 | 7 |
| 장애 대응·접근성 | 7 | 9 |
| 가벼움·로딩 | 6 | 9 |
| 합계 | 56 | 51 |
"웹사이트 디자인 능력"을 묻는 이번 시험의 승자는 Claude Sonnet 5.5입니다. 같은 요구사항을 받고도 장면마다 볼거리를 한 겹씩 더 얹었고, 향수라는 설정을 이야기 구조로 바꾸는 기획력까지 보여 줬습니다. GPT Sol 6.1은 "사고 나지 않는 사이트"를 만드는 쪽으로 더 신경을 썼습니다. 장애 복구와 접근성, 가벼움은 Sol이 낫습니다.
이번 과제 기준으로 실무에 옮기면 이렇게 정리됩니다. 이번 과제처럼 브랜드 첫인상이 승부인 티저 페이지라면 Sonnet의 결과물이 출발점으로 좋습니다. 오래 운영할 서비스 화면이라면 Sol의 방어적인 구조를 참고할 만합니다. 어느 쪽이든 모델의 결과물은 출발점일 뿐이고, 실제 기기와 브라우저에서 사람이 확인하며 다듬는 과정이 남습니다. 그 과정이 필요하다면 포에모라의 홈페이지·웹 제작을 참고해 주세요.
이 비교의 한계
공정하게 읽으실 수 있도록 한계를 적어 둡니다.
- 한 번씩만 실행했습니다. 같은 프롬프트라도 다시 돌리면 결과가 달라집니다. 모델의 평균 실력이 아니라 이번 한 판의 결과입니다.
- 스크린샷은 GPU가 없는 서버에서 찍었습니다. 소프트웨어 렌더라 실제 PC보다 거칠고 느립니다. 이 환경의 WebGPU에서는 두 작품 모두 3D 화면이 하얗게 나와서, 비교 캡처는 WebGL2 모드와 모바일 폭(768px)으로 통일했습니다. 흰 화면은 두 작품 공통이었고 작품의 결함이 아닌 환경의 한계로 판단했습니다.
- 장면 평은 코드 정독과 자동화 브라우저 캡처를 바탕으로 했습니다. 사운드와 장애 복구·접근성 항목은 실제로 들어 보거나 장애를 일으켜 본 것이 아니라 코드를 읽고 평가했습니다. 실제 휴대폰과 느린 기기에서도 시험하지 않았습니다.
- 사용자 입력은 같았지만 실행 환경까지 같지는 않습니다. 두 모델이 돌아간 앱의 시스템 지침과 도구 조건이 같다고 보장할 수 없습니다. 구독 요금 안에서 실행해서 호출 비용은 따로 재지 않았습니다.
- 심사는 Anthropic의 Claude Opus 5.5가 했습니다. Sonnet과 같은 회사 모델이라 편향이 있을 수 있고, 모델 이름을 가린 채 평가하지도 않았습니다. 그래서 두 작품 원본을 그대로 공개합니다. 직접 스크롤해 보고 판단해 주세요.
프롬프트 전문
직접 다른 모델로 재현해 보고 싶은 분을 위해 원문을 공개합니다.
너는 시니어 크리에이티브 디벨로퍼야. 아래 스펙대로 "어워즈급 몰입형 3D 스크롤 웹사이트"를 단일 index.html 파일 하나로 완성해줘. 설명이나 질문 없이 바로 완성된 코드만 작성하고, 끝까지 실행 가능한 상태여야 해.
## 컨셉
가상의 브랜드 "AURORA VOID"(우주 관측소 × 향수 브랜드 같은 하이엔드 실험적 프로젝트)의 티저 사이트.
톤: 어두운 시네마틱, 네온 액센트 하나(전기 시안 또는 자홍 중 택1), 큼직한 에디토리얼 타이포.
실존 브랜드/IP/로고 사용 금지. 외부 이미지·모델·오디오 파일과 외부 API 호출 없이 전부 프로시저럴(코드 생성)로 만들 것.
## 기술 스택 (엄수)
- 단일 HTML 파일. importmap으로 Three.js 최신 안정 버전을 버전 고정하여 CDN 로드. 'three/webgpu'와 'three/tsl' 엔트리를 사용.
- 그 외 허용 라이브러리: GSAP + ScrollTrigger, Lenis. 이외 금지.
- 폰트는 Google Fonts 1~2종만.
## 렌더러: WebGPU 우선 + WebGL2 폴백
- navigator.gpu 확인 후 WebGPU 사용, 실패하면 WebGL2 백엔드로 자동 폴백. 동일한 씬·셰이더 코드가 두 백엔드에서 모두 동작해야 함.
- URL 파라미터 ?renderer=webgl 로 폴백 강제, ?renderer=webgpu 로 WebGPU 강제 가능하게.
- 화면 좌하단 HUD에 현재 백엔드(WebGPU / WebGL2), FPS, 파티클 수 표시. ?debug=1 일 때만 표시.
- WebGL2도 불가하면 정적 폴백 화면(CSS 그라디언트 + 안내 문구)으로 처리.
## 셰이더 & 후처리 (TSL 기반)
- 모든 3D 오브젝트는 procedural geometry + TSL NodeMaterial로 제작. 최소 3종의 서로 다른 커스텀 셰이더:
(a) 노이즈 구체: vertex displacement + fresnel
(b) 터널 링/프리즘: 속도 반응형 emissive
(c) 메인 오브제: 프로시저럴 크리스탈/토러스 노트, 유리 질감 굴절 근사 셰이더
- 파티클 은하는 GPU 구동(Instancing 또는 Points + TSL 위치/색 계산). CPU 루프로 매 프레임 갱신 금지.
- 후처리는 three/webgpu의 PostProcessing + TSL 노드로: bloom + chromatic aberration(RGB shift) + film grain + vignette. 색상 인버트 강도(uInvert)와 CA 강도(uCA)는 uniform으로 노출해 스크롤/챕터에서 제어.
## 핵심 연출: 스크롤 기반 카메라 시퀀스 (6챕터, 약 600vh)
카메라는 CatmullRomCurve3 경로를 따라 이동하며 스크롤 진행도(0~1)에 완전히 동기화된다(스크럽 + 관성 lerp).
1. INTRO – 로딩 카운터(0→100%) 후 타이틀이 글자 단위로 등장, 카메라는 거대한 파티클 은하 바깥에서 천천히 접근.
2. DIVE – 카메라가 노이즈 구체 속으로 관통. FOV 변화로 속도감.
3. TUNNEL – 수백 개의 링/프리즘 터널을 고속 통과. 스크롤 속도에 비례해 CA 강도 상승.
4. REVERSAL(핵심) – 정점에서 진행 방향이 반전된다: 카메라가 180° 롤하며 월드가 뒤집히고, 지나온 터널을 역방향으로 되돌아 바라보며 후퇴한다. 시간감도 반전(파티클/링 회전 방향 반대, 팔레트 인버트, uTime 부호 반전). 반전 순간에 짧은 화이트 플래시 + 슬로모션 임팩트 프레임.
5. REVEAL – 반전된 세계에서 메인 오브제가 마우스 방향으로 기울며 반응.
6. OUTRO – 카메라가 서서히 멀어지며 CTA("Enter the Void" 마그네틱 호버 버튼)로 마무리.
## 사운드: 100% 프로시저럴 Web Audio (외부 파일/API 금지)
- 브라우저 오토플레이 정책 준수: 사용자 제스처(로딩 후 "Enter with sound / without sound" 선택 버튼) 이후에만 AudioContext 시작. 기본값은 음소거, 토글 UI 제공.
- 사운드 구성: 서브 베이스 드론(디튠된 오실레이터 2~3개) + 노이즈 기반 공기감 레이어 + 코드 패드. 전부 코드로 합성.
- 스크롤 속도 → 오디오 매핑 (핵심):
· 스크롤 속도(스무딩된 값)에 따라 로우패스 필터 컷오프를 지수 곡선으로 스윕 (정지 시 어둡게 → 고속 시 밝게 열림), Q값도 함께 상승
· 속도에 비례해 드론 피치/디튠 미세 상승, 노이즈 레이어 게인 증가
· 파라미터는 setTargetAtTime으로 스무딩해 클릭 노이즈 방지
- 챕터별 사운드 변화: TUNNEL에서 상승하는 라이저, INTRO/OUTRO에서 리버브 테일 증가(코드로 생성한 임펄스 응답 ConvolverNode).
- REVERSAL 사운드: 시간 반전 연출과 동기화 — (1) 코드로 생성한 임펄스 응답을 역재생한 리버스 리버브, (2) 테이프 스톱 같은 피치 다운 스윕, (3) 임팩트 순간의 서브 부머 + 짧은 무음 구간, (4) 이후 LFO/아르페지오 방향 반전.
- 마스터에 컴프레서/리미터를 두고 클리핑 방지. 탭 비활성화 시 suspend, 복귀 시 resume.
- 모션 토글(prefers-reduced-motion 또는 사용자 토글)이 켜지면 스윕 폭과 임팩트 사운드를 완화.
## 인터랙션 & UI
- 커스텀 커서(mix-blend-mode), 마우스 패럴랙스(카메라 미세 흔들림), 스크롤 진행 인디케이터, 챕터 번호 HUD.
- 챕터 텍스트 오버레이는 HTML로 구현, 스크롤에 맞춰 마스크/스태거 리빌.
- 네비게이션은 로고 + 사운드 토글 + 모션 토글만.
## 품질 기준 (반드시 충족)
- 데스크톱 60fps 지향, devicePixelRatio는 min(dpr, 2).
- 화면 폭 768px 이하 또는 저성능 감지(프레임타임 기반 동적 품질 조정 포함) 시 파티클 수·후처리 자동 축소.
- prefers-reduced-motion 대응: 카메라 이동 단순화, 플래시/글리치 제거.
- resize, visibilitychange, 렌더러 초기화 실패, 디바이스 로스트 처리.
- 역스크롤/빠른 왕복 스크롤에서도 카메라와 오디오가 튀지 않을 것.
- 콘솔 에러/경고 0개(두 백엔드 모두). 리소스 dispose 처리로 메모리 누수 방지.
- 코드는 섹션별 주석 + 상단 CONFIG 객체(색상, 파티클 수, 챕터 타이밍, 오디오 매핑 범위)로 조정 가능하게.
## 출력 형식
index.html 전체 코드를 코드 블록 하나로만 출력하고, 그 뒤에 "구현한 핵심 기법 5줄 요약"과 "알려진 한계 2줄"만 덧붙여.두 원본 파일은 수정 없이 그대로 올렸습니다. 파일 지문(SHA-256 앞 12자리)은 Sonnet 52dffeb649fa, Sol 3c99bd2a2f59입니다. AI로 만든 결과물을 실제 사이트로 다듬는 일이 필요하다면 포에모라에 문의해 주세요.
자주 묻는 질문
두 작품은 어디서 직접 볼 수 있나요?
본문 상단의 두 링크에서 모델이 만든 원본 HTML을 그대로 열어 볼 수 있습니다. PC의 최신 Chrome이나 Edge를 권하며, 주소 끝에 ?debug=1을 붙이면 렌더러 종류와 프레임 수가 표시됩니다.
한 번만 실행한 결과로 어느 모델이 낫다고 말할 수 있나요?
아닙니다. 같은 프롬프트도 실행할 때마다 결과가 달라집니다. 이 글은 두 모델의 평균 실력이 아니라 같은 조건에서 치른 한 번의 결과를 기록한 것입니다.
심사가 공정한가요?
심사는 Anthropic의 Claude Opus 5.5가 코드 정독과 브라우저 캡처를 근거로 했습니다. Sonnet과 같은 회사 모델이라 편향 가능성이 있어, 두 원본을 수정 없이 공개하고 판단 근거를 항목별로 적었습니다.
스크린샷이 실제 화면과 다른 이유는 무엇인가요?
캡처는 GPU가 없는 서버의 소프트웨어 렌더로 찍었습니다. 그래서 실제 PC보다 거칠고, 두 작품 모두 WebGL2 모드와 768px 폭으로 통일했습니다. 실제 모습은 링크에서 확인해 주세요.
이 결과물을 실제 브랜드 사이트로 쓸 수 있나요?
출발점으로는 충분하지만 그대로 운영하기에는 실제 기기에서의 성능 확인, 저사양 기기 대응, 접근성 검수가 더 필요합니다. 모델의 결과물을 사람이 실제 브라우저와 기기에서 확인하며 다듬는 과정을 권합니다.


