"4베드 듀플렉스에 차고 하나, 앞마당엔 야자수." 이 한 문장이 몇 초 뒤 브라우저 안에서 걸어 다닐 수 있는 3D 주택이 된다면? dev.to에 공개된 Forge3D Spaces 사례는 단순한 사이드 프로젝트 소개를 넘어, LLM과 WebGPU를 결합한 AI-First 프론트엔드 설계의 교과서적 패턴을 담고 있다. 그리고 그 설계 선택 하나하나가 프론트엔드 개발자에게 꽤 많은 것을 이야기해준다.
핵심 이슈: LLM에게 기하학을 맡기지 않는다
가장 직관적인 접근은 "LLM에게 3D 씬을 직접 생성하게 하면 되지 않나?"일 것이다. 하지만 이 방법은 빠르게 무너진다. 모델은 공간적 일관성에 취약하다—벽이 만나지 않고, 방이 겹치고, 문이 공중에 뜬다. Forge3D가 선택한 해법은 명확하다. LLM은 절대 기하학을 직접 건드리지 않는다. 대신 구조화된 프로그램을 내뱉고, 결정론적 솔버가 그것을 실제 건물로 변환한다.
파이프라인은 세 단계다. 첫째, 자연어 문장이 JSON Schema 기반의 엄격한 구조화 호출을 통해 방 프로그램(룸 타입, 목표 면적, 인접 관계, 층수)으로 변환된다. OpenRouter의 json_schema 응답 포맷을 활용해 모든 필드를 필수로 강제한다. 둘째, 반도체 설계에서 차용한 슬라이싱 트리 솔버가 직사각형을 재귀적으로 분할해 방 배치를 확정한다—결과는 겹침도 빈틈도 없는 정확한 좌표값이다. 셋째, 이 풀린 플랜에서 벽·개구부·지붕·가구가 규칙 기반으로 생성된다.
맥락 해석: "하나의 모델, 여러 뷰"가 만드는 설계 일관성
이 파이프라인에서 진짜 통찰은 렌더링 아키텍처에 있다. 플랜이 단일 데이터 구조로 존재하기 때문에 2D 도면, 3D 모델, 입면도, 수량 산출서가 모두 같은 소스의 뷰(view)다. 벽 하나를 드래그하면 모든 것이 함께 움직인다. "싱크를 맞출 것이 없다—처음부터 하나이기 때문에." 이 말이 단순해 보이지만, 상태 관리의 난제를 근본적으로 회피하는 설계 원칙이다.
AI 편집 레이어도 같은 철학을 따른다. "소파를 현관 앞에서 치워줘"라고 입력하면 LLM이 메쉬를 직접 움직이는 게 아니다. 클라이언트가 씬 요약(노드 ID + 위치)을 전송하고, 모델은 add_item, move_node, delete_node 같은 연산 목록을 반환한다. 클라이언트가 각 연산을 실제 씬 그래프에 대해 검증한 뒤, 전체 배치를 단일 Zustand 스토어 트랜잭션으로 적용한다. 다섯 개 연산이 하나의 Ctrl+Z가 되는 이유다. 알 수 없는 ID는 던지지 않고 스킵-후-보고—부분 유효한 플랜도 깨끗하게 착지한다.
렌더링 레이어: WebGPU의 현실과 폴백 설계
React Three Fiber 위에 WebGPURenderer를 올린 뷰포트 선택도 흥미롭다. WebGPU가 브라우저 점유율 75%에 달한다고 하지만, "사용 가능"과 "실제 세션에서 살아남기"는 다른 문제다. requestAdapter()는 성공했는데 renderer.init()이 특정 드라이버·OS 조합에서 터지고, Instagram/Facebook 인앱 브라우저는 지원하지도 않는 기능을 지원한다고 거짓말하고, 모바일 Safari는 탭 전환 시 GPU 디바이스를 날린다.
해법은 init 프로미스를 캔버스 단위로 캐싱하고, init이 reject될 때 WebGL로 조용히 폴백하는 것. "해피 패스가 실패한다고 가정하면 대부분은 실패하지 않는다." 이 한 문장이 프로덕션 WebGPU 전략의 전부다.
CSG(구성 솔리드 기하학) 처리도 마찬가지다. 문이 달린 벽은 단순히 "박스 빼기 박스"로 사전 계산할 수 없다—개구부가 실시간으로 이동하고 크기가 변한다. three-mesh-bvh로 바운딩 볼륨 계층을 구축해 불리언 연산을 가속하고, 노드별 브러시 기하학을 캐싱해 변경된 것만 재평가하는 방식으로 "데모 씬 세 개"와 "실제 프로젝트 사십 개" 사이의 성능 절벽을 넘었다.
시사점: RSC·Next.js 워크플로우와 닿는 설계 패턴
Forge3D의 파이프라인은 프론트엔드 개발자에게 복수의 레이어에서 읽힌다. 가장 직접적인 시사점은 LLM 응답을 타입-안전한 JSON으로 파싱하고 렌더링 레이어와 연결하는 패턴이다. Zod 스키마로 씬 그래프 노드를 검증하고, 구조화된 출력을 단일 스토어 트랜잭션으로 적용하는 흐름은 Next.js Server Actions에서 구조화된 응답을 받아 클라이언트 상태를 업데이트하는 패턴과 본질적으로 같다.
"AI에게 무엇을 맡기고 무엇은 맡기지 않을지"의 경계 설정도 핵심이다. 자연어 해석과 의도 파악은 LLM이 잘한다. 공간적 일관성과 수치 계산은 결정론적 솔버가 잘한다. 두 영역을 섞지 않고 명확히 분리한 것이 이 아키텍처의 강점이다. 전체 건물 요청이 감지되면 LLM 연산 40번 대신 파라메트릭 생성기에 위임하는 선택도 같은 맥락—"솔버가 훨씬 잘하는 일을 LLM에게 시키지 않는다."
전망: 자연어 → 구조화 출력 → 결정론적 렌더링이라는 템플릿
건축 CAD는 하나의 예시일 뿐이다. 자연어 → 구조화 스펙 → 결정론적 실행이라는 이 세 단계 패턴은 데이터 시각화, 인터랙티브 UI 생성, 게임 레벨 설계 등 "공간적·구조적 일관성이 중요한 모든 도메인"으로 확장된다. LLM의 창의적 해석 능력과 솔버의 수학적 엄밀성을 레이어로 분리하되, 단일 데이터 모델로 묶는 것이 핵심이다.
프론트엔드 개발자 입장에서 가장 실용적인 질문은 이것이다. 지금 만들고 있는 AI 기능에서 LLM이 실제로 잘하는 부분과 결정론적 코드가 훨씬 잘하는 부분을 구분하고 있는가? 그 경계를 명확히 설계한 팀이 "AI가 이상한 걸 만들었다"는 디버깅 지옥에서 먼저 벗어난다.