Forge 이야기: 웹사이트 제작 방식을 바꾼 결정론적 AI 컴파일러

모든 AI 웹사이트 빌더는 똑같은 방식으로 작동해요. 프롬프트를 입력하면 LLM이 HTML을 쓰고, 결과물은 LLM이 주는 대로 받아요. 어떤 때는 좋고, 어떤 때는 별로예요. "생성"을 다시 누르면 완전히 다른 결과가 나와요. 레이아웃도, 색상도, 품질도 달라요. 결과물은 근본적으로 예측할 수 없어요.

저희도 그 방식으로 서비스를 시작했어요. 잘 작동했고 사람들이 그걸로 실제 웹사이트를 만들었어요. 하지만 수천 개의 사이트가 생성되는 걸 지켜보면서 하나의 패턴이 보였어요. LLM이 토큰의 대부분을 자기가 결정하지 말았어야 할 것들을 새로 만드는 데 쓰고 있었어요. 내비게이션 시스템, 색상 대비, 모바일 분기점, 앵커 링크, 글꼴 로딩, 문의 양식 마크업 같은 것들이에요.

생성할 때마다 정답이 있는 문제를 두고 새로 주사위를 굴리는 셈이었어요.

Forge는 이런 관찰에서 나온 저희의 답이에요. 조금씩 개선한 것이 아니라 AI가 웹사이트를 만드는 방식 자체를 근본적으로 바꾼 아키텍처예요.

AI에게 HTML을 직접 쓰게 하는 방식의 문제

LLM에게 "이발소 웹사이트를 만들어 줘"라고 요청하면 수천 가지 결정을 동시에 내려야 해요. 어떤 섹션을 넣을지, 어떤 순서로 둘지, 내비게이션은 어떻게 생겼는지, 어떤 색상을 쓸지, 모바일 레이아웃은 어떻게 처리할지, 글꼴은 어떻게 불러올지, 앵커 링크는 어떻게 연결할지, HTML을 의미에 맞게 어떻게 구조화할지, 명암 대비는 어떻게 다룰지, 영업시간은 어떻게 표시할지, 전화번호를 어떻게 클릭할 수 있는 링크로 만들지 같은 것들이에요.

그중 일부는 창의적인 결정이에요. 어떤 섹션을 넣을지, 이발소에 어울리는 색상 팔레트는 무엇인지, 전체적인 분위기는 어때야 하는지 같은 것들이에요.

대부분은 엔지니어링 결정이에요. 내비게이션은 실제 앵커로 스크롤되어야 하고, 명암 대비는 최소 4.5:1이어야 하고, 전화번호는 E.164 형식이어야 하고, 글꼴은 preconnect와 함께 Google Fonts에서 불러와야 하고, 모바일 레이아웃은 480px 아래에서 세로로 쌓여야 해요.

LLM에게 둘 다 맡기면 창의적인 결정은 좋지만 엔지니어링 결정은 들쭉날쭉해요. 어떤 결과물은 명암 대비가 완벽하고 어떤 결과물은 그렇지 않아요. 앵커 링크가 잘 작동하는 결과물도 있고, 존재하지 않는 섹션을 가리키는 죽은 href가 있는 결과물도 있어요. 글꼴을 제대로 불러오는 경우도 있고, 끝내 해석되지 않는 font-face를 인라인으로 넣는 경우도 있어요.

Forge의 핵심 통찰은 이거예요. 창의적인 결정과 엔지니어링 결정을 분리하는 것. 창의성은 AI가 맡고, 정확성은 컴파일러가 맡는다.

2단계 아키텍처

Forge는 웹사이트 생성을 뚜렷하게 구분되는 두 단계로 나눠요.

1단계: AI가 무엇을 만들지 결정해요(SiteSpec)

AI는 HTML을 직접 쓰는 대신 구조화된 명세, 즉 우리가 SiteSpec이라고 부르는 JSON 문서를 만들어요. SiteSpec은 사이트에 어떤 섹션이 있어야 하는지, 각 섹션에 어떤 콘텐츠가 들어가는지, 색상 팔레트와 타이포그래피는 어때야 하는지, 내비게이션은 어떻게 생겼는지, 전체 디자인 처리는 어떤지를 설명해요.

AI는 모든 창의적인 결정을 내려요. 어둡고 고급스러운 미학일까요, 밝고 에디토리얼한 느낌일까요? 히어로에 Bebas Neue 같은 좁은 제목 글꼴을 쓸까요, Cormorant Garamond 같은 우아한 세리프체를 쓸까요? 섹션에 갤러리, 통계 밴드, FAQ, 팀 그리드 중 무엇을 넣을까요?

하지만 AI는 그걸 어떻게 렌더링할지는 결정하지 않아요. HTML이나 CSS는 단 한 줄도 쓰지 않아요. 의도를 설명할 뿐이에요.

2단계: 컴파일러가 매번 완벽하게 렌더링해요

SiteSpec은 결정론적 컴파일러로 전달돼요. 명세와 플레이북을 받아 독립적으로 작동하는 실서비스 수준의 HTML을 출력하는 순수 함수예요. 같은 입력은 언제나 같은 출력을 만들어요.

컴파일러는 모든 엔지니어링 결정을 책임져요.

• 내비게이션 앵커 — 모든 내비게이션 링크는 실제 섹션을 가리켜요. 죽은 앵커는 불가능해요. 컴파일러가 모든 #href를 실제 섹션 ID와 대조해 맞춰요.
• 대비 안전성 — 배경 위 텍스트의 명암 대비를 확인하고 WCAG AA(4.5:1)를 충족하도록 맞춰요. 팔레트는 AI가 고르고, 읽기 쉬움은 컴파일러가 보장해요.
• 배경 번갈아 적용 — 인접한 두 섹션이 같은 배경 색조를 공유하지 않아요. 컴파일러가 기본 배경과 보조 배경을 자동으로 번갈아 적용해 시각적인 리듬을 만들어요.
• 연락처 정규화 — 전화번호는 tel: 링크를 위해 E.164 형식으로 맞추고, WhatsApp 채널은 자동으로 감지하고, 영업시간과 주소는 깔끔하게 정리해요. 모든 연락처 정보가 실제로 클릭할 수 있는 링크로 작동해요.
• 글꼴 로딩 — Google Fonts를 preconnect와 display-swap으로 불러와요. 깨진 font-face도, 레이아웃 흔들림도 없어요.
• 반응형 레이아웃 — 모든 블록이 모바일, 태블릿, 데스크톱 분기점에서 올바르게 렌더링돼요. 분기점은 AI가 고르지 않고 컴파일러가 강제해요.
• 푸터와 내비게이션 합성 — AI가 푸터나 내비게이션을 빼먹으면 (토큰을 아끼려고 그럴 때가 있어요) 컴파일러가 존재하는 섹션을 바탕으로 만들어 줘요. 최종 결과물에서는 빠지는 것이 없어요.

이것이 중요한 이유: 속도와 결정론

속도

AI가 HTML이 아니라 구조화된 데이터를 만들기 때문에 출력 크기가 크게 줄어요. 한 페이지 전체의 HTML을 생성하려면 LLM 출력이 15,000~25,000 토큰 필요해요. 같은 사이트의 SiteSpec은 4,000~6,000 토큰이 필요하니 3~4배 줄어요. 그 덕분에 생성이 더 빨라지고(사이트 전체가 90초 이내) 비용도 낮아져요.

결정론

컴파일러는 순수 함수예요. 같은 SiteSpec이 주어지면 언제나 같은 HTML을 만들어요. 그 의미는 이래요.

• 수정이 안전해요. 비주얼 에디터에서 섹션 제목을 바꾸면 그 섹션만 바뀌어요. 컴파일러가 명세를 다시 렌더링하고 사이트의 나머지는 그대로예요. 연쇄적인 부작용이 없어요.
• 품질이 보장돼요. 대비, 앵커, 연락처 형식, 글꼴 로딩 등 모든 것이 가끔이 아니라 생성할 때마다 정확해요.
• 테스트가 가능해요. 결정론적 엔진은 체계적으로 평가할 수 있어요. 저희는 생성 결과 전반에서 색상 대비, 앵커 무결성, 블록 다양성, 디자인 편차를 자동으로 검사해요.

제한된 창의성

직관과 반대되는 통찰이 있어요. 제약은 AI를 덜 창의적으로 만드는 게 아니라 더 창의적으로 만들어요. LLM이 반복되는 HTML과 CSS를 쓰는 일에서 벗어나면 섹션 선택, 콘텐츠 전략, 디자인 처리, 색채 이론처럼 정말 중요한 결정에 토큰 예산 전부를 쓸 수 있어요. 엔지니어링 결과물을 따로 맡기 때문에 창의적인 결과물이 더 좋아져요.

플레이북 시스템

컴파일러는 어떤 블록이 어떻게 렌더링되는지를 코드에 고정해 두지 않아요. 대신 플레이북(Playbook)을 받아요. 블록 라이브러리(각 섹션 유형이 HTML/CSS로 렌더링되는 방식), 디자인 결정 시스템(팔레트와 타이포그래피가 정해지는 방식), 기본 스타일시트를 정의하는 모듈이에요.

플레이북을 바꾸면 같은 SiteSpec이 완전히 다른 시각 언어로 렌더링돼요. 엔진은 그대로이고 블록만 바뀌어요. 이 점이 Forge를 확장할 수 있게 해 줘요. 새로운 섹션 유형, 새로운 디자인 처리, 새로운 렌더링 방식을 컴파일러의 핵심을 건드리지 않고 추가할 수 있어요.

현재 사이트 생성기 플레이북에는 26가지가 넘는 블록 유형이 있어요. 히어로 섹션과 서비스 목록부터 통계 밴드, 갤러리, FAQ, 팀 그리드, 마퀴, 예약 행동 유도 버튼까지 다양해요. AI가 업종과 콘텐츠에 따라 이 라이브러리에서 고르고, 컴파일러가 픽셀 단위로 정확하게 렌더링해요.

Forge가 탄생한 과정

Forge는 거창한 계획에서 시작하지 않았어요. 프로토타입에서 시작했어요. 손으로 쓴 JSON 명세를 받아 HTML로 렌더링하는 compile.mjs 파일 하나였어요. 질문은 간단했어요. 블록은 우리가 정의하고 AI는 콘텐츠만 채우게 하면 LLM이 직접 쓴 HTML보다 결과가 나을까요?

나았어요. 극적으로 좋았어요. 프로토타입은 완벽한 명암 대비, 작동하는 내비게이션, 올바른 글꼴 로딩, 일관된 다크/골드 미학을 갖춘 이발소 사이트를 렌더링했어요. 그것도 같은 내용의 HTML보다 훨씬 작은 JSON 명세만으로요.

거기서부터 아키텍처가 모양을 갖췄어요.

1. 프로토타입은 타입이 있는 프레임워크 독립 엔진이 되었어요. React, Next.js, SiteDrop 내부에 의존하지 않고 어떤 JavaScript 런타임에서도 가져다 쓸 수 있어요.
2. 코드에 고정된 블록 렌더러는 교체할 수 있는 플레이북 시스템이 되었어요. 각 플레이북이 자체 블록, 디자인 토큰, CSS를 정의해요.
3. LLM 연동은 HTML을 직접 출력하는 방식에서 구조화된 도구 사용 방식으로 바뀌었어요(SiteSpec 스키마가 곧 도구 스키마예요. 모델이 무엇을 만들어야 하는지 가르치면서 출력 형태를 제한해요).
4. 스스로를 설명하는 스키마가 기존의 시스템 프롬프트를 대체했어요. 스키마 설명이 각 필드의 의미를 AI에게 가르쳐 주므로 "문법"은 몇 줄이면 돼요.
5. 품질 게이트, 즉 대비 검사, 앵커 대조, 배경 번갈아 적용, 연락처 정규화가 컴파일러에 내장되어 선택적인 후처리가 아니라 생성할 때마다 실행돼요.

결과는 제공업체에 구애받지 않고(Claude, GPT, Gemini, DeepSeek, xAI 등 구조화된 출력을 지원하는 모든 모델과 작동해요), 프레임워크에 의존하지 않고(독립 패키지로 분리할 수 있어요), 결정론적인(같은 명세는 언제나 같은 HTML) 엔진이에요.

사용자에게 어떤 의미일까요?

SiteDrop 사용자라면 사이트를 생성할 때 Forge가 이미 작동하고 있어요. 다르게 해야 할 일은 아무것도 없어요. 결과물의 품질, 속도, 일관성이 좋아졌어요.

• 더 빠른 생성 — AI 출력이 3~4배 작아서 사이트가 90초 이내에 생성돼요.
• 일관된 품질 — 생성할 때마다 올바른 명암 대비, 작동하는 내비게이션, 알맞은 글꼴 로딩, 정리된 연락처 정보를 갖춰요.
• 더 다양한 디자인 — AI가 26가지 이상의 블록 유형, 4가지 이상의 디자인 원형, 다양한 타이포그래피 조합 중에서 골라요. 이발소는 어둡고 좁은 글꼴의 미학을, 치과는 깔끔한 에디토리얼 느낌을, 파인 다이닝 레스토랑은 고급스러운 세리프 처리를 받아요.
• 더 안전한 수정 — 비주얼 에디터가 SiteSpec을 수정하고 컴파일러를 통해 다시 렌더링하기 때문에 변경 사항을 예측할 수 있고 부작용이 없어요.

Forge의 다음 단계

컴파일러 아키텍처는 저희가 만드는 모든 것의 토대예요. 엔진이 명세 기반이라서 새로운 기능은 모두 새로운 블록 유형, 새로운 플레이북, 새로운 디자인 토큰이에요. 생성 파이프라인을 다시 쓰는 일이 아니에요. 이것이 분리의 힘이에요. AI는 결정을 더 잘하게 되고, 컴파일러는 렌더링을 더 잘하게 되고, 둘은 서로 독립적으로 발전해요.

저희는 이 2단계 패턴, 즉 의도는 AI가, 실행은 컴파일러가 맡는 방식이 앞으로 웹 애플리케이션을 만드는 방법이라고 믿어요. 한 페이지짜리 웹사이트뿐 아니라 여러 페이지로 된 애플리케이션, 대시보드, 인터랙티브 경험도요. AI는 무엇이 존재해야 하는지 설명하고, 컴파일러는 그것이 작동하도록 보장해요.