-->

🎧 이 글을 오디오북으로 듣기
AI 로컬 합성 오디오북 (Qwen3-TTS)

이 글을 누가 읽으면 좋은가

이 글은 AI 코딩 도구로 실제 제품 화면을 만드는 프런트엔드 개발자와 디자인 엔지니어, 그리고 코딩 에이전트를 팀의 워크플로에 배선하려는 플랫폼 엔지니어를 위해 씁니다. “AI가 그럴듯한 랜딩 페이지 목업을 뽑는다”는 이야기는 이미 흔합니다. 여기서 다루려는 질문은 한 단계 더 들어갑니다. 스크롤에 반응하는 3D 씬이나 셰이더 기반 배경처럼, 손으로 짜면 며칠 걸리는 인터랙션을 모델이 어디까지 실제로 만들어 내는가, 그리고 그 결과물을 프로덕션 파이프라인에 어떻게 얹을 것인가입니다. 결정을 앞둔 분이라면, 이 글은 과장 없이 현재 가능한 것과 아직 사람이 붙어야 하는 것을 구분해 드리는 데 목적이 있습니다.

빛과 유리 표면이 겹치며 깊이감을 만드는 추상적인 3D 인터랙션의 이미지

개요

프런트엔드에서 AI 생성물의 벽은 오랫동안 “정적”이었습니다. 버튼과 카드가 가지런히 놓인 페이지는 잘 나오지만, 스크롤 위치에 따라 카메라가 움직이는 3D 씬이나 마우스를 따라 굴절되는 유리 재질처럼 상태와 시간이 얽힌 인터랙션은 모델이 자주 무너졌습니다. 코드가 컴파일은 되는데 화면에서는 아무 일도 일어나지 않거나, 프레임이 뚝뚝 끊기는 식이었습니다.

2026년 중반 들어 이 벽이 눈에 띄게 낮아졌습니다. 그 중심에 Anthropic의 Claude Fable 5가 있습니다. 개발자 Viktor Oddy는 “Claude Fable 5 Just Changed Web Design Forever!”라는 제목의 공개 가이드에서, 단일 프롬프트로 3D이면서 인터랙티브하고 애니메이션이 붙은 웹사이트를 만들어 내는 과정을 처음부터 끝까지 녹화해 공유했습니다. 이후 커뮤니티에서는 Fable 5로 만든 UI 실험을 모은 오픈소스 갤러리까지 등장했습니다. 이 글은 그 흐름을 따라가며, 무엇이 실제로 달라졌고 이것이 ThakiCloud처럼 에이전트를 인프라로 다루는 회사에 어떤 의미인지 정리합니다.

위 영상은 Viktor Oddy가 Fable 5로 3D 인터랙티브 웹을 만드는 과정을 녹화한 가이드입니다.

Fable 5는 무엇이 다른가

Fable 5는 Anthropic이 공개한 Claude 계열 모델로, 특히 프런트엔드 엔지니어링과 여러 단계에 걸친 에이전트형 작업에서 강점을 보입니다. 여기서 “여러 단계”라는 표현이 중요합니다. 인터랙티브 웹 하나를 만드는 일은 사실 여러 작업의 묶음입니다. 레이아웃을 잡고, 3D 지오메트리를 정의하고, 스크롤 이벤트와 씬을 연결하고, 셰이더를 붙이고, 파일을 구조화하고, 성능을 다듬는 과정이 이어집니다. 기존 모델이 이 중 한두 단계를 처리하고 나머지를 사람에게 넘겼다면, Fable 5는 이 사슬을 더 길게 스스로 이어 갑니다.

구체적으로 공개 사례에서 반복적으로 확인되는 특징은 다음과 같습니다. 첫째, 스크롤로 제어되는 애니메이션을 코드로 구현합니다. 스크롤 진행도를 씬의 카메라나 요소 상태에 매핑하는, 손으로 짜면 상태 관리가 까다로운 부분을 모델이 직접 배선합니다. 둘째, Three.js 같은 3D 라이브러리와 GLSL 셰이더를 조합해 굴절, 노이즈, 파티클 같은 시각 효과를 만듭니다. 셋째, 스크린샷을 입력으로 받아 기존 사이트의 레이아웃과 인터랙션을 개선한 리디자인을 제안합니다. 넷째, 프로젝트 파일 구조와 애셋을 스스로 정리하며 단일 프롬프트에서 실행 가능한 결과물까지 밀고 갑니다.

이 능력들의 공통점은 “정적 마크업 생성”이 아니라 “상태와 시간이 얽힌 코드의 생성”이라는 점입니다. 바로 이 지점이 그동안 AI 프런트엔드의 약한 고리였고, Fable 5가 눈에 띄게 밀어 올린 부분입니다.

인터랙티브 웹 디자인, 어떻게 만드는가

공개된 가이드와 갤러리의 결과물을 역으로 추적하면, 실전 워크플로는 대체로 아래 흐름을 따릅니다. 한 번에 완벽한 결과를 기대하기보다, 모델이 잘하는 단계를 큰 덩어리로 맡기고 사람이 검수하며 좁혀 가는 구조입니다.

flowchart TB
    A["의도 프롬프트<br/>(무드·레퍼런스·스택 명시)"] --> B["초안 생성<br/>레이아웃 + 3D 씬 골격"]
    B --> C["인터랙션 배선<br/>스크롤 진행도 → 씬 상태"]
    C --> D["시각 효과<br/>GLSL 셰이더 · Three.js 재질"]
    D --> E["사람 검수<br/>성능 · 접근성 · 브랜드"]
    E -->|"수정 지시"| C
    E -->|"통과"| F["빌드 · 배포<br/>React · Tailwind · Three.js"]

핵심은 첫 프롬프트에 “무엇을 원하는가”를 충분히 구체적으로 담는 것입니다. 원하는 무드, 참고 사이트, 사용할 스택(예: React, Tailwind, Three.js)을 명시하면 모델의 초안 품질이 크게 달라집니다. 스크린샷을 함께 주면 리디자인 정확도가 올라갑니다. 초안이 나온 뒤에는 “스크롤 하단에서 카메라가 더 천천히 움직이게” 같은 인터랙션 단위의 수정 지시가 잘 먹힙니다. 즉, 프롬프트 한 방으로 끝내는 것이 아니라, 큰 골격은 모델에게 맡기고 인터랙션의 결을 사람이 조율하는 방식입니다.

주의할 점도 분명합니다. 화려한 셰이더와 3D는 모바일 성능과 접근성에서 대가를 치릅니다. 모델이 뽑은 결과가 데스크톱에서 근사해도, 저사양 기기나 스크린 리더 사용자를 위한 대응은 여전히 사람의 몫입니다. 이 검수 단계를 워크플로에 명시적으로 넣지 않으면, “예쁘지만 실전에 못 쓰는” 결과물이 쌓이기 쉽습니다.

실제 사례와 오픈소스 갤러리

이 흐름이 개인의 자랑이 아니라는 근거는 공개 자료에 있습니다. 앞서 언급한 Viktor Oddy의 가이드는 과정 전체를 녹화로 남겼고, 커뮤니티에서는 Fable 5로 만든 UI 실험을 모은 오픈소스 갤러리 pulkitxm/claude-directory가 공개되어 있습니다. 이 저장소는 랜딩 페이지, 히어로 섹션, GLSL 셰이더, 디자인 시스템, 애니메이션, 3D를 React, Tailwind, Three.js 위에서 구현한 예제를 모아 둔 곳으로, 결과물을 직접 열어 코드까지 확인할 수 있습니다. 개별 실험을 브라우저에서 바로 볼 수 있으므로, “정말 되는가”를 스크린샷이 아니라 실행으로 검증할 수 있다는 점이 중요합니다.

또 다른 사례로는 Fable 5와 Higgsfield MCP를 조합해 시네마틱 스크롤 웹사이트를 만든 공개 기록도 있습니다. 여기서 눈여겨볼 부분은 모델이 단독으로 모든 것을 하는 것이 아니라, MCP 커넥터를 통해 외부 도구(여기서는 비주얼 애셋 생성)와 연결되어 하나의 결과물로 합쳐진다는 점입니다. 인터랙티브 웹 생성이 단일 모델의 재주가 아니라, 모델과 도구가 물려 돌아가는 파이프라인의 산물로 진화하고 있다는 신호입니다.

정리하면 지금 시점에서 확인 가능한 사실은 다음과 같습니다. 첫째, 단일 프롬프트에서 3D 인터랙티브 웹의 실행 가능한 초안이 나옵니다. 둘째, 그 결과가 공개 저장소에서 코드째 검증됩니다. 셋째, MCP 같은 도구 연결로 애셋 생성까지 파이프라인에 통합됩니다. 다만 이 사례들에서 정량적인 성능 벤치마크(프레임률, 번들 크기, 접근성 점수)는 표준화되어 공개된 것이 없으므로, 품질 판단은 여전히 각자의 검수 기준에 달려 있다는 점은 [추정]이 아니라 사실로 받아들이는 편이 안전합니다.

ThakiCloud 제품 적용 시사점

이 흐름은 ThakiCloud가 만드는 Paxis의 방향과 정확히 맞물립니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 스킬(Skills)·도구(Tools)·정책(Policies)·감사 로그(Audit Logs)를 일급 리소스로 다룹니다. Fable 5가 보여 준 것은 코딩 에이전트가 단발 응답기를 넘어 여러 단계를 스스로 이어 가는 생성 주체가 되었다는 사실입니다. 이런 에이전트를 제품 워크플로에 얹으려면, “무엇을 생성하느냐”만큼이나 “어디서 어떤 권한으로 실행되고 무엇이 기록되느냐”가 중요해집니다.

Paxis 관점에서 위 워크플로를 다시 보면 각 단계가 제어 평면의 리소스로 환원됩니다. 인터랙티브 웹 생성 같은 반복 작업은 하나의 스킬로 등록되어 960여 개 스킬 풀에서 BM25로 선택되고, 실제 코드 생성과 빌드는 격리된 샌드박스에서 실행됩니다. Higgsfield MCP 사례처럼 외부 도구가 필요하면 MCP 커넥터가 OAuth 재연결까지 자동으로 처리합니다. 생성물이 프로덕션에 닿기 전에는 정책 게이트가 검수 규칙을 강제하고, 모든 행동은 감사 로그에 남습니다. 즉 “AI가 화면을 잘 만든다”는 개별 재주를, 팀이 신뢰하고 감사할 수 있는 반복 가능한 파이프라인으로 승격시키는 것이 제어 평면이 하는 일입니다.

인프라 층에서도 함의가 있습니다. 3D와 셰이더가 붙은 프런트엔드는 생성 단계에서 무거운 렌더링과 반복 빌드를 요구합니다. ThakiCloud의 ai-platform은 K8s와 Kueue 기반으로 이런 버스트성 작업을 격리된 테넌트 안에서 스케줄링하고, 필요할 때만 자원을 붙였다 떼는 방식으로 비용을 관리합니다. 온프레미스와 소버린 환경에서 자체 호스팅으로 이 파이프라인을 돌릴 수 있다는 점은, 코드와 디자인 애셋을 외부로 내보내기 어려운 고객에게 특히 의미가 있습니다. 저비용의 안정적인 생성·빌드 인프라(ai-platform)가 있어야, 그 위에서 에이전트 경제성(Paxis)이 성립합니다.

한계 및 반론

낙관만 정리하면 균형이 무너집니다. 몇 가지 반대편을 분명히 해 둡니다.

첫째, 생성된 인터랙션 코드의 유지보수성은 여전히 불확실합니다. 한 프롬프트에서 나온 3D 씬은 인상적이지만, 몇 달 뒤 다른 사람이 그 상태 관리 로직을 이해하고 수정할 수 있는가는 다른 문제입니다. 화려함과 유지보수성은 자주 상충합니다.

둘째, 성능과 접근성은 자동으로 따라오지 않습니다. 앞서 강조했듯 모바일 프레임률, 번들 크기, 스크린 리더 대응은 모델이 기본으로 챙겨 주는 영역이 아니며, 이를 검수 게이트로 명시하지 않으면 기술 부채로 남습니다.

셋째, 결과물의 독창성 문제입니다. 비슷한 프롬프트가 비슷한 3D 히어로 섹션을 양산하면, 모든 사이트가 같은 무드로 수렴하는 “AI 미학의 획일화”가 생길 수 있습니다. 도구가 강력할수록, 무엇을 만들지에 대한 사람의 판단이 오히려 더 중요해집니다.

넷째, 공개 사례에 표준화된 정량 지표가 없다는 점은 신중함을 요구합니다. “차원이 다르다”는 인상적인 증언은 많지만, 재현 가능한 벤치마크로 검증된 것은 아직 부족합니다. 실전 도입 전에는 자신의 스택과 기준으로 직접 재현해 보는 단계를 권합니다.

결론적으로 Fable 5는 인터랙티브 웹 생성의 문턱을 실질적으로 낮췄습니다. 다만 그 결과를 신뢰할 수 있는 제품으로 만드는 일은, 여전히 검수와 정책과 인프라의 문제입니다. 그리고 그 마지막 구간을 어떻게 시스템으로 닫느냐가, 도구를 쓰는 팀과 제품을 만드는 팀을 가릅니다.

관련 슬라이드

본문 내용을 NotebookLM(architectural_mono 스타일)으로 요약한 슬라이드입니다.

fable5-interactive-web-design 슬라이드 1

fable5-interactive-web-design 슬라이드 2

fable5-interactive-web-design 슬라이드 3

fable5-interactive-web-design 슬라이드 4

출처

참고