브라우저 안 빌드·프리뷰 환경: AI가 만든 화면을 바로 띄우기

왜 브라우저 안에 개발 환경이 필요한가

프론트엔드 개발자는 로컬 dev 서버로 프리뷰를 본다. 하지만 비개발자가 프롬프트로 화면을 만드는 제품에서는 AI가 쓴 코드를 사용자 브라우저에서 곧바로 실행해 보여 줘야 한다. 로컬 환경이 없는 사람을 위해 개발 환경을 브라우저 안으로 가져오는 것이다.

사내 어드민이 대표적인 대상이다. 어드민마다 스캐폴딩·의존성·빌드·인증·배포에 더해 보안, 개인정보 마스킹, 조회 기록(감사 로그), 다운로드 파일 암호화를 반복해야 하고, 따로 만들면 이 규칙이 고르게 적용되지 않는다.

해법: 정책은 플랫폼, 화면은 AI

어드민의 일을 두 층으로 나눈다.

층	담당	내용
데이터·컴플라이언스	플랫폼(정책)	쓸 API를 등록하면 서버가 프록시한다. 프록시를 거치므로 마스킹·조회 암호화 같은 정책이 자동 적용되고 호출 기록(증적)이 자동으로 남는다
데이터를 보여 주는 화면	AI(코드 생성)	등록된 API 스키마를 참고해 React 코드를 만든다. 테이블·필터·상세 페이지 같은 자주 쓰는 패턴을 미리 알려 준다

AI가 어떤 코드를 만들든 데이터는 플랫폼의 정책을 통과해야 하므로, 화면 생성의 자유와 보안을 분리할 수 있다. 사내에서 만든 앱을 안전하게 배포하는 다른 방식은 조직 AX의 「바이브 코딩 앱의 사내 배포」, 생성 화면을 디자인 시스템에 맞추는 방법은 디자인 시스템을 아는 화면 생성 에이전트 설계하기에 있다.

프리뷰 런타임 고르기

방식	동작	한계
서버의 dev 서버	서버에 dev 서버 프로세스를 띄우고 사용자의 iframe을 연결	격리가 안 된다. 한 사용자 페이지의 에러 오버레이가 같은 dev 서버를 쓰는 모두에게 번진다
Sandpack	iframe 안에 가상 번들러 환경을 띄워 코드 수정을 바로 반영	런타임에 들어온 뒤에야 패키지를 공개 레지스트리에서 받아 첫 화면이 수십 초까지 늦다. 사내 패키지를 넣기 어렵다
WebContainers(StackBlitz)	브라우저 안에서 Node.js 자체를 돌린다	범용성은 크지만 무겁다
직접 구성	브라우저 빌드 + 미리 준비한 패키지 + 결과 합성	만들고 운영할 몫이 생기지만, 정해진 패턴의 화면이면 첫 화면이 1초대로 줄어든다

직접 구성한 프리뷰 런타임의 구조

flowchart TB
  n1["[편집] AI·사용자가 코드 수정"] --> n2["가상 파일 시스템<br/>(메모리, 경로 → 내용 Map, 레이어별)"]
  n2 -->|"esbuild 플러그인이 import를 해석해 가상 FS에서 파일을 읽는다"| n3["esbuild-wasm<br/>(브라우저에서 번들링)"]
  n3 --> n4["ESM 번들"]
  n4 -->|"bare import('react' 등)는 import map으로 해석"| n5["미리 번들해 객체 스토리지에 올려 둔 패키지 조합<br/>(패키지 조합 해시 = 캐시 키)"]
  n5 --> n6["iframe에 실행 결과 반영<br/>(성공했을 때만 교체: 트랜잭션 커밋처럼)"]

패키지를 하나씩 따로 번들하면 싱글톤이 깨진다. React처럼 인스턴스가 하나여야 하는 패키지가 번들마다 따로 들어가 동작이 어긋난다. 그래서 조합 전체를 한 단위로 다룬다.
패키지 조합 해시(package set hash): 패키지 엔트리 목록과 lockfile 해시를 묶어 하나의 해시로 만든다. 같은 조합이면 같은 키다.
서버에서 그 조합으로 워크스페이스를 만들어 의존성을 설치하고 번들해, import map과 함께 해시 키로 올린다.
브라우저는 import map을 보고 쓸 패키지 조합을 정한 뒤, esbuild-wasm 번들의 bare import를 그 URL로 연결한다. bare specifier를 import map으로 해석하는 원리는 모듈: export와 import에 있다.

4. 결과를 안전하게 합성한다

사용자 코드 번들과 패키지 조합을 합칠 때 빌드가 성공했을 때만 결과를 교체한다. 실패한 중간 상태가 화면에 보이지 않는다.

설계 원칙

새로 구현하기보다 esbuild-wasm, 번들러, import map, 객체 스토리지처럼 검증된 도구를 조합한다.
자주 바뀌는 것(사용자 코드)과 느리게 바뀌는 것(패키지 조합)을 나눠 경계와 캐시 키를 둔다.
격리(사용자별 브라우저 실행), 사전 번들, 성공 시에만 교체로 안전하고 빠르게 실행되게 한다.

정리

비개발자용 AI 화면 생성 제품에는 브라우저 안의 빌드·프리뷰 환경이 필요하다.
데이터 정책은 API 프록시 플랫폼에 두고, AI에는 화면만 맡기면 생성의 자유와 보안을 분리할 수 있다.
서버 dev 서버는 격리가 안 되고, 런타임에 패키지를 받는 방식은 느리다.
가상 FS + esbuild-wasm + 조합 단위로 미리 번들한 패키지 + import map 조합이 가볍고 빠르다.
패키지는 조합 전체를 한 단위(해시)로 다뤄야 싱글톤이 깨지지 않는다.

버그 제보