웹사이트 한 페이지를 여는 과정을 상상해 볼게요. 보통은 이런 흐름이죠. 브라우저가 서버에 요청을 보내고, 서버는 미리 만들어둔 HTML 파일을 찾거나 템플릿에 데이터를 채워 HTML을 조립한 뒤, 그걸 그대로 돌려줍니다. 수십 년 동안 웹의 작동 방식은 대체로 이 구조였어요. 그런데 flipbook.page라는 실험적인 사이트는 여기서 한 발짝 더 나갑니다. 서버의 템플릿 대신, 거대 언어 모델(LLM)이 HTML을 실시간으로 생성해서 스트리밍해주는 거예요. 말 그대로 "모델에서 웹사이트가 흘러나온다"는 표현이 어울리는 구조입니다.
기술적으로 어떻게 돌아가나
이게 뭐냐면, 사용자가 페이지를 요청하는 순간 서버가 미리 준비해둔 HTML을 가져오는 게 아니라, LLM에게 "이런 페이지를 만들어줘"라는 프롬프트를 던지고, 모델이 토큰 단위로 HTML을 뱉어내면 그걸 브라우저에 곧바로 흘려보내는 방식이에요. 일반적인 ChatGPT 답변이 한 글자씩 타이핑되듯 나타나는 것과 같은 원리인데, 그 결과물이 실행 가능한 웹페이지라는 점이 다릅니다.
좀 더 깊이 들어가 볼까요. 브라우저는 원래 HTML을 순차적으로 파싱할 수 있게 설계돼 있어요. <head>가 먼저 도착하면 스타일시트나 스크립트 링크를 미리 내려받기 시작하고, <body> 앞부분이 오면 이미 렌더링을 시작합니다. 그래서 LLM이 토큰을 순서대로 내뱉어도, 브라우저는 그걸 HTTP 스트리밍으로 받아 차례대로 해석해 화면을 그려나갈 수 있는 거죠. Transfer-Encoding: chunked라는 오래된 HTTP 기술과 모델의 스트리밍 API가 만나 이런 실험이 가능해졌습니다.
한 번 새로고침할 때마다 전혀 다른 페이지가 나온다는 점도 재미있어요. 모델의 샘플링(sampling) 특성상 온도(temperature) 값이나 랜덤 시드에 따라 같은 프롬프트라도 결과가 달라지거든요. 콘텐츠, 색상, 레이아웃이 매번 미묘하게 바뀌는 "살아 있는 웹사이트"가 되는 셈입니다.
이게 그냥 장난감일까, 다음 패러다임의 신호일까
당장은 실험·데모 성격이 강합니다. 토큰당 비용, 지연시간(latency), 캐시, SEO, 접근성 등 실제 프로덕션에 쓰기엔 걸림돌이 많거든요. LLM 호출 한 번이 수백 밀리초에서 수 초까지 걸리다 보니, 모든 요청마다 모델을 돌리면 기존 정적/서버렌더링 방식과 비용 차이가 어마어마합니다.
그럼에도 주목할 만한 이유가 있어요. Generative UI라는 흐름이 최근 1~2년 사이에 빠르게 성장하고 있거든요. Vercel의 v0, Bolt.new 같은 AI 웹 빌더, Cursor의 인라인 생성, 그리고 Claude Artifacts나 ChatGPT Canvas 같은 기능도 결국 "사용자 요청에 따라 UI를 동적으로 생성한다"는 같은 방향을 가리키고 있어요. flipbook.page는 이 흐름을 극단까지 밀어붙여서 "그럼 아예 매 요청마다 모델이 HTML을 새로 짜면 어떻게 되지?"를 실험한 프로젝트로 읽힙니다.
비교해보면 재미있어요. 기존 SSR(Server-Side Rendering)은 템플릿 + 데이터 = HTML이고, ISR(Incremental Static Regeneration)은 미리 만들어둔 HTML을 가끔 재생성이라면, 이 방식은 프롬프트 + 모델 = HTML입니다. 생성 주체가 개발자가 쓴 코드에서 모델로 옮겨간 거죠.
한국 개발자에게 주는 시사점
실무에 바로 적용할 기술은 아닙니다. 하지만 이 실험이 던지는 질문은 꽤 묵직해요. 예를 들어 마케팅 랜딩 페이지처럼 개인화가 중요하고 트래픽이 제한적인 영역이라면, 전체 HTML을 모델이 생성하는 방식이 말이 안 되는 걸까요? 내부 관리자 도구처럼 UI가 자주 바뀌는 화면은요? 실제로 Vercel AI SDK의 streamUI, OpenAI의 구조화된 출력(Structured Outputs), Next.js의 React Server Components가 결합되면 부분적 Generative UI는 이미 구현 가능한 단계에 와 있습니다.
국내 서비스 중에서도 챗봇 답변 안에 차트나 카드가 동적으로 렌더링되는 사례가 늘고 있어요. 토스의 AI 상담, 네이버 하이퍼클로바X의 앱 빌더 기능 같은 것도 큰 틀에서 같은 방향입니다. 지금 당장 flipbook.page 같은 극단적 구조를 쓰진 않겠지만, "UI 생성 파이프라인에 LLM을 어디까지 끼워 넣을 수 있나"를 미리 고민해두면 다음 몇 년간 분명 써먹을 일이 생길 겁니다.
마무리
한 줄 요약하면, flipbook.page는 "웹페이지가 파일이 아니라 모델의 출력일 수 있다"는 생각을 실제로 보여준 도발적인 실험이에요. 여러분이 만드는 서비스에서 "이 화면, 매번 똑같이 만들지 말고 상황에 맞게 달라져도 되겠는데?" 싶은 부분은 어디인가요?
🔗 출처: Hacker News
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공
