Tistory
죽은 프레임워크 이론
새 프레임워크가 기술적으로 우수해도 LLM 학습 데이터 · 시스템 프롬프트 · 개발자 코드 의 피드백 루프가 리액트를 고착화시킨다. '도착과 동시에 사망(dead on arrival)'.
핵심 요약
두 개의 자기강화 루프가 동시에 돈다.
[A] LLM 학습 루프
1. 리액트가 기존 웹을 지배 (12개월 1,300만+ 신규 사이트)
2. LLM 이 기존 웹으로 학습
3. LLM 기본 출력 = 리액트 코드
4. LLM 으로 만드는 신규 사이트 = 리액트
5. 더 많은 리액트 사이트가 다음 학습 데이터
→ 2번으로
[B] 도구 루프
1. 리액트가 개발자 생태계 지배
2. IDE/도구가 리액트 우선 생성
3. 시스템 프롬프트에 리액트 하드코딩
4. 신규 사이트 = 리액트
5. 수요 증가 → 도구의 리액트 편향 강화
→ 1번으로
이 루프를 깨려면 12~18개월의 데이터 지연 + 도구 벤더 설득 + 라이브러리 생태계 구축 + 개발자 관성 극복 이 필요. 그 사이 리액트 생태계는 천만 개 사이트를 더 만든다.
가치 있는 플랫폼 혁신의 판별 기준:
| 유형 | 예시 | 채택 가능성 |
|---|---|---|
| DX Sugar (개발자용) | CSS Nesting, Web Components | 낮음 (Sass/React 가 이미 해결) |
| 사용자 영역 불가능 | View Transitions, WebGPU, WebAuthn/Passkeys | 높음 |
| 라이브러리로 해결 가능 | Carousel, Select | 낮음 (react-multi-carousel 이 이미 있음) |
프레임워크 경쟁 = 기술 비교가 아니라 네트워크 효과의 싸움. 리액트는 이제 '프레임워크' 가 아니라 플랫폼. 경쟁 대상은 Angular/Svelte 가 아니라 LLM 학습 데이터셋에서 차지하는 통계적 우위. 이 관점에서만 Replit/Bolt 가 시스템 프롬프트에 리액트를 하드코딩하는 이유가 이해된다.
신기술 도입 의사결정에서 'LLM 이 생성할 수 있는가' 가 기술 스택 선택의 새 축으로 올라왔다. 이 축을 무시하면:
- 신규 프레임워크 도입 → AI 도구가 코드를 생성하지 못함 → 생산성 역행
- 새 CSS/브라우저 API → 개발자들이 여전히 styled-components/Tailwind 로 회귀
- 새 플랫폼 기능 → 사용자 영역에서 이미 라이브러리로 해결됨
사용자 영역에서 구축 불가능한 것 (View Transitions, WebGPU, WebAuthn) 만 의미 있는 혁신이 된다는 저자의 결론은 강력한 프레임이다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
'LLM 학습 데이터에 없으면 존재하지 않는다'
저자의 실증: Chrome 의 Prompt API 를 사용하는 확장을 Claude 로 만들었을 때 6개월 전 API (self.ai.languageModel) 를 출력. 현재 API 는 LanguageModel.create() 인데 학습 데이터 미포함.
새 기능 출시 ─────────────┐
│ ~6개월
학습 데이터 수집 마감 ───┤
│ 모델 학습/배포
모델이 해당 API 출력 ─────┘
최소 1218개월 지연. Baseline Newly-Available → Widely-Available 까지 추가 30개월. **총 45년**이 정상 채택 사이클.
새 API 가 Baseline 에 도달했으니 '이제 쓸 수 있다' 고 판단. 실제로는 AI 도구가 해당 API 를 생성할 때까지 2년 더 기다려야 개발자들이 자연스럽게 사용.
CSS Nesting 은 Sass 를 대체하지 못한다
브라우저 팀은 '프레임워크 패턴의 플랫폼 내재화' 를 추구하지만, LLM 학습 데이터의 양이 다르다.
| 기술 | 학습 데이터 누적 |
|---|---|
| Sass | 15년+ |
| styled-components | 8년+ |
| CSS Nesting | 1~2년 |
게다가 리액트 개발자는 이미 CSS-in-JS/Tailwind 가 있어 전환 유인이 없다. 새 플랫폼 기능이 라이브러리의 대안일 뿐 사용자 경험을 바꾸지 않으면 채택되지 않는다.
'기술적으로 더 좋으니 쓰겠지' 라는 기대. 기술적 우위는 채택 충분조건이 아니다. 네트워크 효과를 뒤집을 유인 이 필요.
유일하게 채택되는 플랫폼 기능의 공통점
성공 사례의 공통분모: 사용자 영역(userland) 에서 만들 수 없다.
- View Transitions API — JS/CSS 로 다중 페이지 전환 애니메이션 구현 불가
- WebGPU — 새로운 연산 접근, 라이브러리로 대체 불가능
- WebAuthn / Passkeys — 보안 primitive, 정의상 플랫폼 전용
반대로 Carousel 을 native 로 만든다고 해도 이미 react-multi-carousel/Swiper 가 있어 채택 안 됨.
신기술 도입 시 질문: '이건 라이브러리로 구현 불가능한가?' YES 면 배울 가치 있음.
'공식 표준이니 쓰겠다' 는 판단. 라이브러리로 이미 가능한 영역은 관성이 항상 승리.
읽는 순서
- 1이론
저자가 언급한 두 가지 피드백 루프 (A: LLM 학습, B: 도구) 를 다이어그램으로 그려 보고, 각 단계의 지연 시간을 추정한다.
- 2구현
Claude/GPT 에 'Chrome
LanguageModel.create()을 사용한 확장 만들어줘' 를 요청해 실제로 구식 API 가 나오는지 확인. - 3실무
최근 도입을 고민한 기술 3개를 '사용자 영역에서 구현 가능한가?' 질문으로 재평가. 가능하면 기존 라이브러리 우선, 불가능하면 진지 검토.
- 4설명
'Svelte 를 도입해야 하나요?' 질문에 (1) AI 도구 커버리지, (2) 라이브러리 생태계, (3) 유지보수 인력 풀 세 축으로 답하는 연습.
면접 연결 질문
[감점 답변] '성능/DX'. [좋은 답변] (1) LLM 도구가 해당 프레임워크 코드를 생성 가능한가, (2) 라이브러리 생태계 규모와 TS 타입 커버리지, (3) 팀이 유지보수할 수 있는 인력 풀, (4) 사용자 경험이 실질적으로 개선되는가(아니면 DX 만 개선), (5) 3년 후에도 유지될 가능성. 저자의 '도착과 동시에 사망' 이론을 근거로 기술적 우수성만으로는 부족 하다고 설명.
[감점 답변] '지원 브라우저 차이'. [좋은 답변] View Transitions 는 사용자 영역에서 불가능한 다중 페이지 전환 이라 유일한 해결책 — LLM 도구가 생성 못해도 직접 쓸 수밖에 없음. CSS Nesting 은 Sass/styled-components/Tailwind 가 이미 해결, LLM 학습 데이터에 Sass 가 15년+ 누적되어 전환 유인 없음. 사용자 경험 vs 개발자 경험 개선 축이 다르다.
자기 점검
단순 시장 점유율 얘기라는 오해. 학습 데이터·시스템 프롬프트·라이브러리 생태계 세 축이 동시에 강화하는 자기참조 구조가 핵심.