이제 토스는 AI '딸깍'으로 만듭니다

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI에게 어드민 화면을 만들어 달라고 요청하는 경험을 실제 서비스로 만들려면, 프롬프트보다 어떤 플랫폼·보안·브라우저 실행 환경이 필요한가?==

• 어드민은 데이터를 다루므로 API·보안·컴플라이언스·마스킹·암호화·감사 로그가 화면 생성보다 먼저 통제되어야 한다.
• 토스는 중앙 플랫폼에서 정책과 API 프록시를 관리하고, AI가 API 스키마와 UI 패턴을 바탕으로 React 화면을 만들게 분리했다.
• 서버 개발 서버와 Sandpack의 한계를 거쳐, 가상 파일 시스템·esbuild-wasm·패키지 조합 해시·S3를 이용한 브라우저 프리뷰 런타임을 직접 만들었다.
• 이 구조는 프리뷰 첫 화면을 47초에서 1.3초로 줄였고, 개인 생산성의 10배를 조직 전체의 속도로 확장하려는 시도다.

영상은 ‘AI가 화면을 몇 분 만에 만들어 준다’는 데모보다, 그 뒤에서 제품 경계와 실행 환경을 설계한 프론트엔드 엔지니어링을 설명한다. 사용자는 자연어로 어드민의 목적을 말하고 필요한 질문에 답하면 되지만, 플랫폼은 API 등록·정책 적용·데이터 보호·패키지 설치·번들링·격리·프리뷰까지 책임져야 한다. 핵심은 AI가 코드를 생성하는 기능이 아니라, 조직이 반복적으로 만드는 어드민을 안전하고 빠르게 만들 수 있도록 반복되는 복잡성을 플랫폼에 흡수하는 데 있다.

---

1. 어드민을 AI로 만든다는 것의 범위

AI 어드민은 프롬프트 하나로 화면을 만드는 기능이 아니라, 데이터 정책과 개발 환경을 제품화하는 작업이다.

1.1. 기존 어드민 개발의 반복 작업

1. 프론트엔드 서비스의 기본 흐름

   1. 프로젝트 스캐폴딩: 먼저 프로젝트의 기본 구조를 만들고 필요한 npm 패키지와 의존성을 추가한다.
   2. 빌드와 인증: 어떤 빌드 도구를 사용할지 정하고 인증을 붙인다.
   3. 코드 작성과 배포: 서버 API를 준비하고 프론트엔드 코드를 작성한 뒤 빌드하고 배포한다.

2. 어드민에 추가되는 요구사항

   1. 보안과 도메인 지식: 일반 화면보다 보안 정책과 데이터를 다루는 도메인 규칙을 더 엄격하게 반영해야 한다.
   2. 운영 데이터 처리: 로그와 감사 증적, 파일 다운로드, 암호화, 개인정보 마스킹과 같은 기능이 필요하다.
   3. 반복되는 구축 과정: 어드민을 하나 만들 때마다 프로젝트·의존성·인증·배포·보안 정책의 과정을 반복한다.

1.2. 개별 화면에서 플랫폼으로

1. 개별 어드민의 한계

   1. 규칙의 누락 위험: 개별 어드민을 각각 만들면 보안 규칙과 도메인 지식이 모든 화면에 일관되게 적용되기 어렵다.
   2. 비즈니스 속도와 FE 리소스의 불일치: 토스처럼 비즈니스가 빠르게 진행되면 이를 통제하는 어드민 수요도 계속 생기지만, 모든 팀에 충분한 프론트엔드 리소스가 있는 것은 아니다.

2. 플랫폼으로 해결할 문제

   1. 반복 복잡성의 중앙화: 매번 반복되는 정책·API·보안·실행 환경을 플랫폼에 넣어 개별 팀이 다시 구현하지 않게 한다.
   2. 사용자 범위 확대: FE 인력이 부족한 팀도 필요한 API와 정책 안에서 어드민을 만들 수 있게 한다.

---

2. 토스 AI 어드민의 사용 경험과 분리된 구조

사용자는 자연어로 목적을 설명하지만, 플랫폼은 정책과 화면 생성을 서로 다른 책임으로 다룬다.

2.1. 자연어에서 실행 가능한 어드민으로

1. 브라우저 안의 생성 경험

   1. 프롬프트 입력: 사용자가 어떤 어드민을 만들지 프롬프트로 입력하면 화면에 생성 중이라는 상태가 나타난다.
   2. 질문과 답변: 에이전트는 사용자의 요구를 그대로 코드로 바꾸기보다 어떤 어드민을 만들 것인지 추가 질문을 한다.

2. 에이전트의 생성 단계

   1. 계획(Planning): 사용자의 답변과 등록된 정책을 바탕으로 무엇을 만들지 계획한다.
   2. 코드 작성(Coding/Writing): 계획에 따라 코드를 작성하고, 브라우저 안에서 결과를 프리뷰로 보여 준다.

3. 정책이 제품에 녹아 있는 방식

   1. API 등록: 어떤 API를 사용할 수 있는지 플랫폼에 먼저 등록한다.
   2. 호출 정책: 생성되는 어드민이 어떤 API를 사용할지 확인하고, 데이터를 어떻게 다뤄야 하는지 정책으로 제한한다.

2.2. 중앙 정책과 화면 생성의 분리

1. 플랫폼이 맡는 영역

   1. API 프록시: 등록된 API를 서버에서 프록시해 호출 경로에 정책을 자동 적용한다.
   2. 보호와 감사: 마스킹·조회 암호화 같은 처리를 자동으로 제공하고, 프록시를 거친 호출 기록과 감사 증적을 남긴다.

2. AI가 맡는 영역

   1. API 스키마 참조: AI는 허용된 API 스키마를 참고해 어떤 데이터를 화면에 보여 줄지 판단한다.
   2. 반복 UI 패턴 생성: React 코드로 테이블·필터·상세 페이지처럼 자주 사용되는 화면 패턴을 조합한다.

3. 이 분리가 필요한 이유

   1. 데이터 규칙의 일관성: 보안과 컴플라이언스는 생성된 코드에 맡기지 않고 중앙 정책으로 강제한다.
   2. 표현의 자동화: 정책 아래에서 데이터가 보여지는 프론트엔드 화면은 AI가 빠르게 생성하도록 한다.

---

3. 실제 도입 규모가 만든 플랫폼 요구

AI 어드민은 실험용 데모가 아니라 반복 생성되는 내부 제품을 감당해야 한다.

3.1. 프로젝트와 페이지 규모

1. 사내 공개 뒤의 누적 규모

   1. 약 440개 프로젝트: 사내에 공개된 뒤 반년 동안 만들어진 프로젝트가 약 440개라고 소개한다.
   2. 약 2,400개 페이지: 프로젝트 안의 페이지는 약 2,400개 규모로 늘어났다.

2. 라이브 사용량

   1. 약 120개 라이브 프로젝트: 440개가 모두 실험에 그친 것은 아니며, 실제 라이브 상태로 운영되는 프로젝트가 약 120개다.
   2. 꾸준한 수요: 토스의 비즈니스가 빠르게 진행되기 때문에 이를 운영하고 통제할 어드민 수요가 계속 발생한다.

3.2. 제품을 두 층으로 나눈 이유

1. 데이터·컴플라이언스 층

   1. 중앙 정책: 데이터를 다루는 방법과 컴플라이언스 컨트롤을 플랫폼의 정책으로 정한다.
   2. 자동 적용: API 프록시·마스킹·암호화·로그 증적을 플랫폼이 공통으로 제공해 어드민마다 다시 구현하지 않게 한다.

2. 화면·프론트엔드 층

   1. API 기반 코드 생성: AI가 API 스키마를 보고 React 화면 코드를 만든다.
   2. 패턴의 재사용: 테이블·필터·상세 화면 등 자주 쓰이는 패턴을 미리 알려 주어 생성 결과가 회사의 사용 방식에 맞게 나온다.

---

4. 브라우저에서 개발 환경을 실행해야 하는 문제

AI가 코드를 만든 뒤 사용자가 즉시 결과를 보려면, 서버의 로컬 개발 환경을 브라우저 안으로 가져와야 한다.

4.1. 첫 번째 시도: 서버 개발 서버와 iframe

1. POC 구성

   1. Next.js 개발 서버: 서버에 Next.js 개발 서버 프로세스를 하나 띄운다.
   2. 사용자 iframe: 사용자의 브라우저가 해당 개발 서버에 iframe으로 연결되어 결과를 보게 한다.

2. 격리 실패

   1. 페이지별 사용 차이: 서로 다른 사용자가 서로 다른 페이지를 만들고 있어도 같은 개발 서버를 공유하게 된다.
   2. 에러 오버레이 전파: 한 페이지에서 에러 오버레이가 발생하면 개발 서버 전체에 전파되어 다른 사용자의 화면까지 영향을 받을 수 있다.

4.2. 두 번째 시도: Sandpack

1. 브라우저 코드 샌드박스

   1. 역할: Sandpack은 브라우저 안에 가상 환경을 만들어 코드를 수정하면 UI에 결과를 바로 반영하는 라이브러리다.
   2. 격리 목적: 서버의 하나의 개발 서버를 공유하는 문제를 줄이기 위해 브라우저별로 나뉜 실험 환경으로 옮기려 했다.

2. 성능과 패키지 문제

   1. 첫 화면까지 47초: 처음 시도했을 때 브라우저 런타임에 진입한 뒤 첫 화면이 보이기까지 약 47초가 걸렸다.
   2. 패키지 다운로드: 런타임에서 패키지를 내려받아야 했고, 퍼블릭 레지스트리에서 패키지를 가져오는 과정이 느렸다.
   3. 사내 패키지 주입: 공개 패키지와 달리 사내 패키지를 브라우저 런타임에 주입하기도 어려웠다.

3. 직접 구현으로 전환

   1. POC를 넘어선 요구: Sandpack은 아이디어를 확인하기에는 충분했지만, 실제 제품의 격리·속도·패키지 요구를 모두 만족시키지 못했다.
   2. 자체 런타임: 발표자는 핵심 실행 환경을 직접 만들기로 결정했다.

---

5. 토스가 직접 만든 브라우저 프리뷰 런타임

자체 런타임은 브라우저의 파일 시스템 부재, 패키지 조합, 번들링, 결과 반영을 각각 해결한다.

5.1. 가상 파일 시스템과 브라우저 번들링

1. 가상 파일 시스템

   1. 브라우저의 제약: 브라우저에는 일반적인 디스크 파일 시스템이 없으므로 파일 경로를 키로 사용하는 가상 파일 시스템을 만들었다.
   2. 레이어 구성: 여러 레이어에 걸쳐 가상 파일을 구성해 사용자가 편집하는 프로젝트 파일을 메모리 안에서 다룬다.

2. esbuild-wasm

   1. 브라우저 실행: esbuild를 WebAssembly 버전으로 만들어 브라우저에서 실행할 수 있게 했다.
   2. 플러그인 연결: 가상 파일 시스템을 플러그인으로 연결하고, esbuild-wasm이 import 구문을 해석할 때 파일을 가상 파일 시스템에서 가져오게 했다.

3. ESM 번들

   1. 번들 생성: 파일과 import 관계를 해석해 브라우저에서 실행할 수 있는 ESM 번들을 만든다.
   2. Node와 비슷한 개발 경험: 브라우저 안에서도 Node 기반 개발 환경처럼 파일을 읽고 의존성을 연결하고 실행하는 경험을 제공한다.

5.2. 동적 패키지 조합을 다루는 방법

1. 고정 패키지의 한계

   1. 초기 구조: 처음에는 정해진 패키지 조합만 사용해 큰 문제가 없었다.
   2. 사용자별 차이: 사용자가 프로젝트마다 다른 패키지를 쓰고 싶어 하면서 중앙에서 하나의 조합으로 관리하기 어려워졌다.

2. 번들을 따로 만들 때의 문제

   1. 싱글톤 파괴: 패키지를 따로 번들링하면 하나의 인스턴스로 유지되어야 하는 패키지 조합에서 싱글톤이 깨질 수 있다.
   2. 조합의 의미 상실: 패키지 하나가 아니라 서로 함께 사용되는 전체 조합을 하나의 의미 단위로 봐야 했다.

3. 패키지 세트 해시

   1. 해시 입력: 패키지 엔트리 목록과 yarn.lock의 해시 같은 정보를 모두 묶어 전체 패키지 세트를 해싱한다.
   2. S3 저장: 해시된 키를 기준으로 해당 패키지 조합을 S3에 업로드한다.
   3. 조합 단위 재사용: 같은 조합을 사용하는 프로젝트는 하나의 의미 단위로 묶인 결과를 재사용할 수 있다.

4. 브라우저에서 패키지 선택

   1. 워크스페이스 구성: 패키지 조합을 만들고 사용하는 흐름에 맞춰 워크스페이스를 만든다.
   2. 설치와 번들링: package.json을 기준으로 Yarn이 의존성을 설치하고, Vite로 번들링한 뒤 import map을 생성한다.
   3. import map 활용: 브라우저는 import map을 보고 어떤 캐시와 패키지 조합을 사용할지 확인한 뒤 esbuild-wasm과 함께 실행한다.

5.3. 결과를 안전하게 화면에 반영하기

1. 두 결과의 결합

   1. 코드와 실행 결과: 브라우저에서 실시간으로 바뀌는 코드와 준비된 패키지 조합을 결합해 실행한다.
   2. 프리뷰 표시: 두 요소가 성공적으로 조합됐을 때 사용자에게 화면을 보여 준다.

2. 트랜잭션 커밋과 같은 반영

   1. 부분 결과 방지: 코드와 패키지 중 하나만 준비된 상태에서 깨진 화면을 보여 주지 않도록 결과 반영을 묶는다.
   2. 속도 개선: Sandpack을 썼을 때 첫 화면까지 47초가 걸리던 것을 직접 만든 런타임에서는 1.3초까지 줄였다.

---

6. 엔지니어가 하는 일은 경계와 조합을 설계하는 일

직접 만든 핵심 코드의 양보다, 제품 요구에 맞는 경계와 이미 검증된 도구의 조합이 더 중요하다는 회고다.

6.1. 변화의 속도를 나누는 인터페이스

1. 경계 설정

   1. 제품 요구에 맞춘 분리: 어떤 부분은 빠르게 변화해야 하고 어떤 부분은 천천히 안정적으로 변화해야 하는지 나눈다.
   2. 인터페이스 설계: 변화 속도가 다른 영역 사이에 인터페이스를 두어 한쪽의 변경이 전체를 흔들지 않게 한다.

2. 안전성과 속도의 동시 확보

   1. 안전한 코드 실행: 코드가 격리된 환경에서 안전하게 실행되도록 구조를 만든다.
   2. 빠른 피드백: 사용자가 AI가 만든 결과를 기다리지 않고 즉시 확인하고 수정할 수 있게 한다.

6.2. 라이브러리를 조합하는 능력

1. 처음부터 모든 것을 만들지 않기

   1. 기존 도구 활용: 발표자가 직접 구현한 부분이 거의 없다고 말할 정도로 이미 널리 사용되는 라이브러리와 도구를 활용했다.
   2. 제품에 맞는 연결: 가상 파일 시스템·esbuild-wasm·패키지 저장소·import map을 제품 요구에 맞는 하나의 시스템으로 연결했다.

2. 엔지니어의 조합 책임

   1. 선택: 각 도구의 장점과 제약을 알고 제품 경계 안에 배치해야 한다.
   2. 운영 가능한 구조: 단순히 데모가 동작하는 조합이 아니라, 속도·격리·캐시·패키지·실패 반영까지 운영할 수 있는 구조여야 한다.

6.3. 개인의 10배를 조직의 배수로

1. 조직 문제의 구조화

   1. 반복 문제를 제품화: 여러 팀이 매번 겪는 어드민 구축 문제를 플랫폼의 정책과 실행 환경으로 구조화한다.
   2. AI 활용 제품: AI를 한 사람의 생산성 도구로만 두지 않고 조직 전체가 반복 사용하는 제품으로 만든다.

2. 10배의 의미

   1. 개인의 10배: 한 명이 AI로 빠르게 화면을 만드는 수준을 넘어선다.
   2. 조직 전체의 효과: 개인의 10배 생산성을 플랫폼으로 공유해 조직 전체가 영향을 받는 구조를 목표로 한다.

---

7. Q&A: 브라우저 파일 시스템은 어디에 저장되는가

마지막 질문은 브라우저 안의 가상 파일 시스템과 실제 코드 저장 위치를 구분한다.

7.1. 메모리 기반 가상 파일 시스템

1. 브라우저 안의 데이터

   1. 디스크에 직접 저장하지 않음: 브라우저에 만든 가상 파일 시스템은 메모리에서만 활용된다.
   2. 런타임 수명: 브라우저 런타임이 종료되면 메모리 안의 가상 파일 시스템은 회수되는 구조다.

2. 실제 코드의 저장

   1. S3 사용: 실제 코드와 사용자의 편집 결과는 S3에 저장된다.
   2. 편집에 따른 업데이트: 사용자의 편집 내용에 따라 S3의 코드가 업데이트되고, 브라우저 런타임은 이를 기반으로 다시 실행한다.

7.2. 전체 설계의 경계

1. 일시적 실행과 지속적 저장의 분리

   1. 가상 파일 시스템: 빠른 프리뷰와 번들링을 위한 임시 실행 상태를 담당한다.
   2. S3: 런타임이 끝나도 남아 있어야 하는 코드와 편집 상태를 담당한다.

2. 제품 관점의 의미

   1. 속도: 메모리 기반 실행으로 브라우저에서 즉시 프리뷰한다.
   2. 지속성: S3 저장으로 사용자의 작업을 보존한다.

---

주요 발언 모음

“AI 시대 어드민은 브라우저 안에서 사용자에게 만들어지는 어드민을 어떻게 보여 줄 것인가의 문제이기도 합니다.”

“어드민은 데이터를 다루기 때문에 보안과 컴플라이언스 규칙을 플랫폼에서 정책으로 정해야 합니다.”

“Sandpack을 사용했을 때 47초가 걸리던 것을 직접 만든 런타임으로 1.3초까지 개선했습니다.”

“엔지니어가 하는 일은 제품 요구에 맞게 경계를 잘 설정하고, 안전하고 빠르게 실행되는 구조를 만드는 일입니다.”

“개인의 10배에서 조직 전체가 영향을 받는 구조를 만들고 싶습니다.”

핵심 데이터 & 수치

• 12분 07초: Toss Challengers의 ‘AI 시대 어드민’ 웨비나 편집 영상 길이다.
• 약 440개: 사내 공개 후 반년 동안 만들어진 프로젝트 수다.
• 약 2,400개: 같은 기간 누적된 페이지 수다.
• 약 120개: 실제 라이브 상태로 운영되는 프로젝트 수다.
• 47초: Sandpack 기반 프리뷰에서 첫 화면이 보이기까지 걸린 시간이다.
• 1.3초: 자체 브라우저 프리뷰 런타임으로 줄인 첫 화면 표시 시간이다.
• 10배: 개인 AI 생산성을 조직 전체의 효과로 확장하려는 비유적 목표다.

결론 및 시사점

1. AI가 어드민 화면을 생성하는 경험은 프롬프트 기능만으로 완성되지 않으며 정책·API·보안·실행 환경이 함께 필요하다.
2. 데이터와 컴플라이언스는 중앙 플랫폼에서 통제하고, 화면 표현과 반복 UI 조합은 AI가 담당하도록 책임을 나누는 것이 핵심이다.
3. AI가 만든 코드를 브라우저에서 즉시 확인하려면 가상 파일 시스템과 번들링·패키지·격리 문제를 해결해야 한다.
4. 서버 개발 서버는 사용자 간 에러 전파가 생길 수 있고, Sandpack은 패키지 다운로드와 47초의 초기 로딩이라는 한계를 보였다.
5. esbuild-wasm과 가상 파일 시스템을 연결하면 브라우저에서도 파일·import·ESM 번들을 실행할 수 있다.
6. 패키지 하나가 아니라 전체 패키지 조합을 해시해 S3에 저장하면 동적 의존성과 싱글톤 문제를 함께 다룰 수 있다.
7. 코드와 패키지 실행 결과를 트랜잭션처럼 함께 반영하면 사용자에게 부분적으로 깨진 프리뷰를 보여 주는 일을 줄일 수 있다.
8. 엔지니어링의 핵심은 모든 것을 새로 만드는 데 있지 않고, 변화 속도가 다른 영역의 경계와 인터페이스를 설계하는 데 있다.
9. 가상 파일 시스템은 메모리에서 빠른 실행을 담당하고, S3는 런타임이 끝나도 남아야 하는 코드를 담당한다.
10. 개인의 AI 활용을 조직의 생산성으로 확장하려면 반복되는 조직 문제를 플랫폼의 정책과 실행 환경으로 구조화해야 한다.

핵심 요약 (40줄)

1. 토스의 AI 어드민은 프롬프트로 화면만 생성하는 기능이 아니라 정책과 개발 환경을 제품화한 플랫폼이다.
2. 일반적인 프론트엔드 서비스는 스캐폴딩·의존성·빌드·인증·배포와 서버 API 준비를 거친다.
3. 어드민은 데이터와 권한을 다루므로 보안·로그·감사 증적·파일·암호화·마스킹이 추가로 필요하다.
4. 개별 어드민마다 규칙을 다시 구현하면 보안과 도메인 지식이 일관되게 적용되기 어렵다.
5. 토스는 반복되는 어드민 구축 복잡성을 중앙 플랫폼으로 흡수하려고 했다.
6. 사용자는 자연어로 만들고 싶은 어드민을 설명하고 에이전트의 질문에 답한다.
7. 에이전트는 답변을 바탕으로 계획을 세우고 코드를 작성해 브라우저 프리뷰를 만든다.
8. 어떤 API를 사용할지와 데이터를 어떻게 다룰지는 플랫폼의 정책으로 통제된다.
9. API 프록시는 서버에서 호출을 중계하며 정책·마스킹·암호화·감사 기록을 자동으로 적용한다.
10. AI는 허용된 API 스키마와 반복 UI 패턴을 참고해 React 화면 코드를 만든다.
11. 사내 공개 후 약 440개 프로젝트와 약 2,400개 페이지가 만들어졌다.
12. 그중 실제 라이브 상태로 운영되는 프로젝트는 약 120개다.
13. 비즈니스가 빠르게 진행될수록 이를 통제할 어드민의 수요도 계속 발생한다.
14. 첫 시도는 서버에 Next.js 개발 서버를 띄우고 사용자 iframe을 연결하는 방식이었다.
15. 하나의 개발 서버에서 한 페이지의 에러 오버레이가 다른 사용자에게 전파되는 격리 문제가 있었다.
16. 두 번째 시도로 브라우저 코드 샌드박스 라이브러리인 Sandpack을 사용했다.
17. Sandpack은 브라우저 런타임에서 패키지를 다운로드하고 사내 패키지를 주입하는 데 한계가 있었다.
18. Sandpack 기반 프리뷰는 첫 화면이 보이기까지 약 47초가 걸렸다.
19. 토스는 격리·속도·패키지 요구를 해결하기 위해 브라우저 프리뷰 런타임을 직접 만들었다.
20. 브라우저에는 일반적인 파일 시스템이 없으므로 파일 경로를 키로 하는 가상 파일 시스템을 구성했다.
21. 가상 파일 시스템은 여러 레이어에서 프로젝트 파일을 메모리로 다룬다.
22. esbuild를 WebAssembly로 실행하는 esbuild-wasm을 브라우저 번들러로 사용했다.
23. 플러그인이 import 구문을 해석하고 가상 파일 시스템에서 파일을 가져오도록 연결했다.
24. 파일과 의존성을 묶어 브라우저에서 실행 가능한 ESM 번들을 만들었다.
25. 사용자가 프로젝트별로 다른 패키지를 선택하면서 전체 조합을 의미 단위로 관리해야 했다.
26. 패키지를 따로 번들링하면 싱글톤으로 유지되어야 할 패키지 인스턴스가 깨질 수 있다.
27. 패키지 엔트리 목록과 yarn.lock 해시를 묶어 패키지 세트 전체를 해싱했다.
28. 해시 키를 기준으로 패키지 조합을 S3에 저장해 재사용할 수 있게 했다.
29. 워크스페이스에서 의존성을 설치하고 Vite로 번들링한 뒤 import map을 생성했다.
30. 브라우저는 import map으로 캐시와 패키지 조합을 선택하고 esbuild-wasm과 함께 실행한다.
31. 코드와 준비된 패키지 조합은 성공적으로 결합된 경우에만 화면에 반영된다.
32. 이 반영 방식은 코드와 실행 결과를 트랜잭션 커밋처럼 묶어 부분 실패를 줄인다.
33. 자체 런타임은 첫 화면 표시 시간을 47초에서 1.3초로 줄였다.
34. 엔지니어는 제품 요구에 맞춰 빠르게 변할 영역과 안정적으로 유지할 영역의 경계를 정한다.
35. 안전한 코드 실행과 빠른 프리뷰를 동시에 제공하려면 영역 사이의 인터페이스가 중요하다.
36. 핵심은 모든 것을 새로 만드는 것이 아니라 검증된 라이브러리와 도구를 제품에 맞게 조합하는 일이다.
37. 개인의 AI 활용을 조직 전체의 생산성으로 확장하려면 반복되는 조직 문제를 플랫폼으로 구조화해야 한다.
38. 브라우저의 가상 파일 시스템은 메모리에서만 동작하고 런타임 종료 시 회수된다.
39. 실제 코드와 사용자 편집 결과는 S3에 저장되어 런타임과 분리된 지속성을 갖는다.
40. AI 어드민의 본질은 딸깍하는 코드 생성보다 정책·실행 환경·경계·조직 확장을 함께 설계하는 데 있다.