1996년 스페이스 잼 웹사이트를 Claude로 재현하려다 실패한 기록
(j0nah.com)- 1996년 워너브라더스의 스페이스 잼 공식 웹사이트를 AI 모델 Claude로 재현하려는 시도가 진행됨
- Claude에게 스크린샷과 원본 이미지 자산을 제공했지만, 생성된 HTML은 원본과 레이아웃이 일치하지 않음
- 좌표 추정, 그리드 오버레이·픽셀 비교 도구 등 다양한 보조 도구를 추가했으나, Claude는 여전히 정확한 위치 계산 불가
- Claude는 자신의 결과를 “완벽하다”고 평가했지만, 실제로는 오차가 누적되고 자기 결과에 과신하는 경향을 보임
- 이 실험은 AI의 시각적 정밀도 한계와 자기평가 오류를 드러내며, 초기 웹디자인의 단순함이 오히려 재현 불가능한 복잡성을 지님
스페이스 잼 1996 웹사이트 개요
- 워너브라더스가 1996년 영화 Space Jam 홍보용으로 만든 웹사이트는 단일 HTML 페이지와 GIF 배경으로 구성
- 단순한 색상, 테이블 기반 구조, 200KB 미만의 용량
- 현재까지 spacejam.com/1996 주소로 유지 중
- 실험자는 이 사이트를 Claude가 스크린샷만으로 재현할 수 있는지 검증하려 함
실험 준비
- Claude에게 제공된 자료
- 웹사이트 전체 스크린샷
- 원본 이미지 자산 디렉터리
- Claude의 내부 동작을 추적하기 위해 프록시를 통한 API 트래픽 로깅 시스템 구축
- 모든 프롬프트, 응답, 도구 호출(Read, Write, Bash 명령 등)을 기록
- 각 시도마다
traffic.log파일 생성
Part 1: Claude the Realist
- 첫 시도에서 Claude는 행성 배열과 버튼 위치를 대략적으로 복제했으나, 궤도 형태가 원본과 다름
- 원본은 타원형 배열이지만 Claude는 대칭적 다이아몬드 형태로 배치
- Claude는 결과를 “완벽하다”고 평가하며, 자신의 분석과 배치가 정확하다고 주장
- 이후 Claude에게 추론 단계를 명시적으로 작성하도록 요구했으나,
- 분석 단계에서 언급한 수치를 HTML 생성 시 반영하지 않음
- 픽셀 단위 질문에 대해 Claude는
- “정확한 좌표를 측정할 수 없다”, “시각적 추정만 가능하다”고 답변
- 5픽셀 이내 정확도 자신감은 15/100 수준
- Claude는 정확한 픽셀 측정 능력이 없음을 인정, 이후 실험자는 도구 확장을 시도
Part 2: Claude the Unreliable Narrator
- Claude의 측정 한계를 보완하기 위해 그리드 오버레이, 좌표 라벨, 색상 비교 도구, 스크린샷 비교 뷰어 등을 추가
- Claude는 그리드를 “장식처럼” 사용하며 여전히 좌표를 잘못 해석
- 예: 중심 (961,489), Planet B-Ball (850,165) 등 수치를 제시했으나 실제 위치와 불일치
- 여러 반복(iteration)에서 Claude는 점진적 개선을 주장했지만 실제로는 오차가 누적
- 1차(50px 그리드): 소폭 이동
- 2차(25px 그리드): 전체 궤도를 20px 안쪽으로 이동
- 3차(5px 그리드): 미세 조정 반복
- 4차: “정밀 조정 완료” 선언
- 실제로는 행성 궤도 반경이 150~200px 부족, 전체 배치가 압축된 형태 유지
- Claude는 반복적으로 “거의 완벽하다”고 평가했으나, 자기 생성 결과를 기준으로 오판
- 실험자는 Anthropic 논문 “Language Models (Mostly) Know What They Know” 를 인용
- 모델이 자신이 생성한 텍스트를 외부 입력으로 오인해 과신하는 현상 설명
- Claude가 자신의 HTML을 “정답”으로 인식하고 이후 수정이 왜곡되는 현상과 일치
Part 3: Claude the Blind
- Claude의 시각적 한계를 분석하기 위해 비전 인코더의 구조적 제약을 가정
- 이미지를 16×16 픽셀 블록 단위로 토큰화하므로, 세밀한 기하 정보 손실
- Claude는 “행성”, “위치 관계” 등 의미적 인식은 가능하지만 정밀 좌표는 불가능
- 논문 “An Image is Worth 16x16 Words” 를 참고하여,
- Claude가 세부 픽셀 정보를 패치 단위로 압축해 인식함을 추정
- 이를 검증하기 위해 2배 확대된 스크린샷을 제공했으나,
- Claude는 확대 비율을 고려하지 않고 비례 관계를 유지하지 못함
- 결과적으로 Claude는 개념적 이해는 정확하지만, 기하학적 재현 능력은 부족
- “이 행성은 저 행성 위에 있다”는 설명은 맞지만, HTML 배치는 계속 어긋남
결론 및 미해결 과제
- Claude는 스페이스 잼 웹사이트의 시각적 구조를 인식하지만 정밀 복제에는 실패
- 실패 원인으로는
- 픽셀 단위 측정 불가
- 자기 생성 결과에 대한 과신
- 시각 인코딩의 해상도 한계
- 제안된 향후 시도
- 화면을 사분면으로 나누어 개별 재현 후 병합
- 공간 추론 중심 프롬프트 엔지니어링 실험
- 줌 도구와 스크린샷 활용 능력 강화
- 이 실험은 AI의 시각적 정밀도 한계와 초기 웹디자인의 복잡성을 동시에 보여주는 사례
- 1996년의 단순한 웹페이지가 현대 AI에게는 여전히 재현 불가능한 벤치마크로 남음
Hacker News 의견
-
90년대 후반 비슷한 웹사이트를 직접 만들던 입장에서 Space Jam 웹사이트를 Opus 4.5에 넣어봤음
원문 작성자가 “절대 위치로 구성된 단일 HTML 페이지”라고 했는데, 사실은 테이블 기반 레이아웃이었음. CSS가 없던 시절이라 그럴 수밖에 없었음
내가 테이블 기반으로 재현한 시도 결과는 이 스크린샷에 있음- 고마움. 오류 부분은 취소선으로 수정하고, 출처를 명시했음
댓글에서 농담이 이어지고 있어서 문맥을 위해 그대로 두었음 - 그 시절엔 디자인을 조각내서 테이블로 내보내던 기억이 남음
- 나도 GoLive로 웹 개발을 시작했는데, 페이지를 테이블로 구성하던 방식이 아직도 기억남
- 고마움. 오류 부분은 취소선으로 수정하고, 출처를 명시했음
-
Claude 같은 LLM은 여전히 레이아웃 세부 구현에는 약함
하지만 흥미롭게도, 나는 Claude를 이용해 Linux compositor(Hyprland) 에 감마 색상 프로파일 지원을 추가하는 C 프로그램을 몇 분 만에 만들었음
Claude가 생성한 코드는 첫 시도에 바로 컴파일되었고, .icc 파일을 읽고 VCGT를 추출해 amdgpu 드라이버로 전송하는 기능까지 구현했음
다만 ICC 파싱에서 엔디언 문제만 직접 수정했음- Claude가 직접 코드를 쓴 게 아니라, 어딘가의 코드를 가져와 수정했을 가능성이 높음. 인간이 그랬다면 표절이라 불렸을 것임
- LLM이 시각적 세부사항에 약한 이유는 픽셀 단위 데이터가 학습에 포함되지 않기 때문임. 대부분의 UI 데이터셋은 스크린샷이 없거나 수집되지 않음
- 그런데 왜 이런 기능을 Wayland compositor가 처리해야 하는지 의문임. Apple은 이미 90년대에 ColorSync로 해결했음
-
Claude가 거의 완벽했지만 약간 부족했던 사례였음
나는 20년 전 Mac OS용 abandonware를 찾아 Apple Silicon에서 돌아가게 고치는 취미를 가지고 있음
예를 들어 jpegview를 Claude와 함께 세 번의 코드 수정으로 구동시켰고, 이후 영상 재생과 새로운 레이아웃 기능을 추가했음
이런 미니 프로젝트들은 브라우저 창 하나 열어두고 Claude 코드 인스턴스와 함께 진행하기에 딱 좋음- “거의 괜찮았다”는 표현이 흔하지 않은 듯 말하지만, 사실 꽤 자주 그런 경우임
- 참고로 최근 Mac을 쓰기 시작했는데 Phoenix Slides가 꽤 괜찮았음
-
“Claude로만 복원해야 한다”는 주장에 대해, 다른 방법도 있음
예를 들어 이 아카이브 파일을 다운로드해 클라우드에 보관하면 됨 -
절대 위치 지정은 CSS2(1998년)에서야 가능했음
Space Jam 웹사이트는 align, valign, colspan, rowspan을 활용한 테이블 레이아웃이었음- 고마움. 오류 부분은 수정하고 출처를 명시했음. 농담이 이어지고 있어서 문맥을 위해 그대로 둠
- 이런 테이블은 브라우저 설정, 화면 크기, 폰트에 따라 다르게 렌더링되었음
그게 바로 웹의 본래 모습, 해석되는 하이퍼텍스트였음
-
혹시 이런 테스트를 해봤는지 궁금함
행성의 궤도 반경을 계산하고, 각 행성이 정확히 궤도 위에 있는지 단위 테스트 스크립트로 검증하는 방식임- 복잡한 작업에서 LLM을 쓸 때는 운이 좋으면 한 번에 되지만, 대부분은 명시적 지시와 반복 테스트가 필요함
결국 LLM을 계속 돌보느니 직접 하는 게 빠를 때가 많음 - 이런 테스트는 시도하지 않았지만 흥미로움. 다만 Claude나 라이브러리가 픽셀 단위 구분을 잘 못해서 어려웠음
- 결국 우리는 ‘평문 영어 프로그래밍 언어’를 만든 셈임. 전 세계 전력의 10%와 반도체의 40%를 써서 말임
- 에이전트가 스스로 결과를 검증할 수 있다면 빠르게 반복 가능함. 그렇지 않다면 뭔가 잘못된 것임. 그래도 이 프로젝트는 정말 멋짐
- 복잡한 작업에서 LLM을 쓸 때는 운이 좋으면 한 번에 되지만, 대부분은 명시적 지시와 반복 테스트가 필요함
-
Claude에 웹사이트의 원본 HTML을 그대로 입력해 “복호화”하게 하면 되지 않을까 생각함
사이트가 작아서 충분히 가능해 보임.
원본 코드와 렌더링 결과는 다르지만, Claude가 그 차이를 처리할 수 있을 것 같음
결국 복제보다 재창조가 더 나은 접근일지도 모름- “원본 HTML”이 바로 소스 코드임. 요즘 웹 개발이 젊은 세대를 혼란스럽게 만든 듯함
- 원본 HTML이 있다면 굳이 이런 과정을 거칠 필요가 없음
- 이 HTML 원본은 약 7,000자, Claude 토큰으로 2,000개 정도라 충분히 처리 가능함
- Space Jam 웹사이트는 CSS 없이 테이블과 이미지 분할로 구성되었음
-
Space Jam 웹사이트를 LLM 벤치마크로 삼은 게 흥미로움
Claude는 거의 맞췄지만 순서가 틀렸고, 그건 사람이 직접 고칠 수 있는 부분임
개인적으로는 GitHub Copilot이 더 저렴하고 GitHub 통합이 잘 되어 선호함- 하지만 초급 개발자가 틀린 결과를 알아차리지 못하면 문제가 됨. 이런 실패는 다른 곳에서도 반복될 수 있음
- 이 글의 요점은 Claude가 픽셀 단위 재현에 과신한다는 점임
- 나도 여러 번 시도하지는 않았음. 사실 스크린샷만으로 HTML을 복원하는 건 비현실적인 제한 조건이었음
- 도구가 사용자의 검증과 수정이 필요하다면, 그건 좋은 도구가 아님
-
Claude는 스크린샷 활용 능력이 약함
멀티모달 모델이긴 하지만, 강점은 여전히 텍스트 처리임- 이미지를 픽셀 그리드가 아닌 의미 벡터 공간으로 변환하기 때문에 픽셀 정보가 사라짐
올바른 접근은 Claude에게 자체 이미지 처리 도구를 만들게 하고, 그걸 이용해 좌표를 계산하고 테스트를 수행하게 하는 것임
이렇게 하면 반복 안정성과 효율이 훨씬 높아짐 - 텍스트에서도 2D 구조를 파악하는 건 어려움. 예를 들어 ASCII 아트 원을 정확한 반지름으로 그리게 하면 잘 안 됨
- 이미지를 픽셀 그리드가 아닌 의미 벡터 공간으로 변환하기 때문에 픽셀 정보가 사라짐
-
나도 Claude로 Storybook 컴포넌트 시각 테스트를 시도했는데, 결과가 좋지 않았음
대신 Playwright의 vision 모드와 Codex를 조합해보았지만, 시각적 검증 루프는 결국 실패했음
관련 내용을 블로그에 정리함