죽은 프레임워크 이론: React의 플랫폼화와 LLM의 자기 강화 피드백 루프

TL;DR

죽은 프레임워크 이론(Dead Framework Theory)은 Google의 Paul Kinlan이 제시한 개념으로, LLM(대형 언어 모델)과 AI 코딩 도구의 등장으로 인해 새로운 웹 프레임워크가 출시 순간부터 사실상 경쟁력을 잃는 현상을 설명합니다. React는 더 이상 다른 프레임워크와 경쟁하지 않으며, LLM 학습 데이터 → 코드 생성 → 웹 배포 → 다시 학습 데이터로 이어지는 자기 강화 피드백 루프를 통해 사실상의 웹 플랫폼이 되었습니다. 이로 인해 새로운 프레임워크가 채택되려면 최소 12~18개월간 LLM 학습 데이터에 충분히 포함되어야 하는데, 이 기간 동안 React 생태계는 이미 1,000만 개 이상의 추가 사이트를 생성하게 됩니다.

---

본문

React의 플랫폼화: 경쟁에서 표준으로

과거 웹 개발 생태계에서 React는 Angular, Vue.js, Svelte 등 다른 프레임워크들과의 직접적인 경쟁 관계에 있었습니다. 하지만 지난 1218개월간 상황은 근본적으로 변했습니다. 2024년 통계에 따르면 개발자의 42%가 React를 사용하고 있으며, 상위 1백만 개 사이트 중 약 1218%가 React로 구축되어 있습니다. 더 주목할 점은 매달 1,300만 개 이상의 새로운 사이트가 React로 배포되고 있다는 것입니다.

이러한 채택률은 단순한 기술적 우수성 때문만은 아닙니다. React는 이제 사실상의 웹 플랫폼이 되었습니다. 개발자들이 React를 선택하는 이유는 광범위한 생태계, 안정적인 유지보수, 그리고 무엇보다 이제는 LLM 기반 코딩 도구들이 기본적으로 React를 출력하기 때문입니다.

Why it matters: React의 플랫폼화는 단순한 점유율 증가를 의미하지 않습니다. 이는 새로운 기술이 채택되는 방식 자체를 근본적으로 변화시켰습니다. 더 이상 기술적 우수성만으로는 충분하지 않으며, AI 도구의 기본값이 무엇인지가 생존을 결정합니다.

LLM의 자기 강화 피드백 루프

죽은 프레임워크 이론의 핵심은 두 개의 상호작용하는 자기 강화 피드백 루프에 있습니다:

첫 번째 루프: 웹 데이터 → LLM 학습 → 코드 생성 → 웹 배포

1. React가 기존 웹을 지배합니다 (월 1,300만 개 이상의 신규 사이트)
2. LLM들은 기존 웹을 기반으로 학습합니다
3. LLM들은 기본적으로 React 코드를 생성합니다
4. LLM으로 구축된 새로운 사이트들은 React를 사용합니다
5. 미래의 학습을 위해 더 많은 React 사이트가 존재하게 됩니다
6. 2단계로 돌아갑니다

두 번째 루프: 개발자 선호도 → 도구 기본값 → 채택 증가 → 더 많은 수요

1. React가 개발자 생태계를 지배합니다
2. IDE와 도구(Replit, Bolt, GitHub Copilot 등)는 개발자들이 선호하는 React를 우선적으로 생성합니다
3. 도구들은 LLM들에게 기본적으로 React 코드를 생성하도록 요청합니다
4. 구축되는 새로운 사이트들은 React를 사용합니다
5. React 사이트가 더 많이 존재하게 되어, 도구들이 React 코드를 생성하도록 하는 수요가 증가합니다
6. 1단계로 돌아갑니다

이 두 루프는 서로를 강화하며, OpenRouter의 토큰 증가량과 React 배포 수의 증가 곡선이 거의 일치한다는 점이 이를 입증합니다. 단순한 상관관계이지만, 시간적 연관성이 매우 주목할 만합니다.

Why it matters: 이 피드백 루프는 순환적이며 자기 강화적입니다. 시간이 지날수록 대체 기술의 채택 난이도는 지수적으로 증가합니다. 기존에는 기술적으로 뛰어난 새 프레임워크가 시장을 빼앗을 수 있었지만, 이제는 불가능해졌습니다.

LLM 학습 데이터 부재 = 존재하지 않는 기술

현재의 LLM 학습은 매우 특정한 시점(cut-off date)을 기준으로 수행됩니다. 이는 새로운 기술이 제아무리 뛰어나더라도 학습 데이터에 충분히 포함될 때까지 실질적으로 존재하지 않는 것과 같다는 의미입니다.

구체적인 사례가 있습니다. Paul Kinlan이 최근 Chrome의 새로운 LanguageModel.create() API를 사용하여 Claude로 Chrome Extension을 구축하려고 했을 때, Claude는 6개월 전에 이미 폐기된 self.ai.languageModel API를 사용한 코드를 작성했습니다. 최신 API는 아직 학습 데이터셋에 포함되지 않았기 때문입니다.

타임라인을 고려하면 상황은 더욱 심각합니다:

• 새로운 프레임워크: 학습 마감 이전에 0~6개월의 실제 사용 기간
• 새로운 웹 플랫폼 API: 학습 마감 이전에 0~6개월의 실제 사용 기간
• React 패턴: 10년 이상의 축적된 예시

새로운 웹 표준이 브라우저에 배포되려면 수년간의 표준화 과정이 필요합니다. 하지만 배포된 후에도 개발자들이 이를 실제로 사용하려면 최소 12~18개월의 추가 시간이 필요합니다. 이 기간 동안 React 생태계에는 1,000만 개 이상의 새로운 사이트가 추가됩니다.

Why it matters: 기술의 가치는 더 이상 기술적 특성에 의해서만 결정되지 않습니다. LLM 학습 데이터에 포함되지 않으면 존재하지 않는 것이나 마찬가지이며, 개발자가 명시적으로 요청하지 않는 한 출력되지 않습니다.

새로운 프레임워크가 직면한 불가능한 과제

새로운 프레임워크나 라이브러리를 출시하려면 기술적 우수성만으로는 부족합니다. 다음 모든 과제를 동시에 해결해야 합니다:

1. LLM 학습 데이터 진입 (최소 12~18개월 지연)
2. 도구 제작자의 시스템 프롬프트 수정 설득 (채택 필요)
3. 포괄적인 라이브러리 생태계 구축 (수년간의 개발)
4. 개발자들의 관성 극복 (개발자들이 스스로 요청하도록 만들기)

더 심각한 점은 이 모든 과제를 해결하는 동안 React 생태계는 계속 성장한다는 것입니다. Replit, Bolt 등의 AI 코딩 도구들은 명시적으로 시스템 프롬프트에 React를 하드코딩하고 있습니다. 개발자들이 유지보수할 수 있는 코드를 생성하려면 React를 출력해야 하기 때문입니다.

React의 생태계 규모를 고려하면 더욱 절망적입니다. React에는 수천 개의 라이브러리가 존재하지만, 새로운 프레임워크는 대부분 수십 개 수준입니다. 이는 개발자들의 생산성에 직접적인 영향을 미칩니다.

Why it matters: 기술적 우수성이 뛰어나도, 네트워크 효과 앞에서는 무력합니다. React는 이미 네트워크 효과가 압도적인 지점을 통과했으며, 이제 경쟁자들이 이를 역전시키기는 사실상 불가능합니다.

웹 플랫폼 기능도 피하지 못하는 문제

흥미롭게도, 이 문제는 새로운 프레임워크뿐 아니라 새로운 웹 플랫폼 기능에도 동일하게 적용됩니다.

브라우저 팀이 프레임워크에서 흔히 사용되는 패턴을 발견하고 웹 표준으로 제안하는 과정을 생각해봅시다:

1. 브라우저 팀은 프레임워크에서 흔히 사용되는 패턴을 식별합니다 (예: Sass 대신 CSS Nesting)
2. 수년에 걸친 표준화 프로세스가 시작됩니다
3. 해당 기능이 브라우저에 배포됩니다
4. 개발자들은... 계속해서 프레임워크의 패턴을 사용합니다

예를 들어, CSS Nesting은 브라우저에 추가되었지만 LLM들은 여전히 15년 축적된 Sass 및 CSS-in-JS 패턴을 선호합니다. 왜일까요?

• LLM은 오래된 패턴을 학습했습니다 (Sass는 15년, CSS Nesting은 1~2년)
• 프레임워크가 이미 작동하고 있습니다 (React 개발자들은 styled-components, Tailwind, CSS modules를 사용)
• 생태계가 이미 구축되어 있습니다 (수천 개의 React 컴포넌트 라이브러리가 기존 CSS 패턴 사용)
• 전환할 동기가 없습니다 (새로운 플랫폼 기능이 사용자 경험을 개선하지 않음)

이는 오직 사용자 영역에서 구축될 수 없는 근본적인 기능 (다중 페이지 View Transitions, WebGPU, WebAuthN 등)만이 채택될 수 있음을 의미합니다.

Why it matters: 웹 표준화 기구의 혁신도 LLM의 피드백 루프 앞에서는 제한됩니다. 웹 플랫폼의 진화는 이제 LLM의 선호도에 의해 형태가 결정됩니다.

웹 개발의 삼층 구조와 LLM의 영향

웹을 구축하는 개발자 커뮤니티는 세 가지 계층으로 나뉩니다:

1. 웹 구축의 핵심(Head) 비즈니스
상위 1,000개 사이트 그룹으로, 트래픽과 수익의 가장 큰 몫을 차지합니다. 이들은 기존 기술 스택이 안정적이므로 쉽게 변경하지 않습니다.

2. 웹 구축의 중간(Middle) 비즈니스
다음 1,000만 개의 사이트로, 소규모 팀과 개인이 구축합니다. 이들은 LLM 도구를 사용하여 새로운 사이트를 완전히 구축할 가능성이 높으며, 별도 지정이 없으면 도구의 기본값을 사용합니다.

3. 긴 꼬리(Long Tail)
정규 웹 개발자가 아닌 일반인들이 Loveable, Replit, 또는 채팅 앱에서 직접 도구를 사용하는 계층입니다. 이들은 코드를 들여다볼 필요가 없을 수도 있습니다.

중요한 통찰: 2번과 3번 그룹의 사람들이 웹사이트의 성장을 주도합니다. 이들은 새로운 플랫폼 기능(Passkeys, WebAuthN, Web Components, CSS Nesting, View Transitions)에 대해 알지 못하는 도구를 사용합니다. 결과적으로 이들이 구축하는 사이트는 LLM이 출력하는 기본값인 React 생태계의 패턴만을 반영합니다.

Why it matters: 웹의 미래를 구축하는 대다수 개발자들은 이미 LLM 도구의 기본값에 의해 기술 선택이 결정됩니다. 개발자의 의지나 선택이 아닌, AI 도구의 시스템 프롬프트가 웹의 방향을 결정하는 시대가 되었습니다.

개발자 도구 제작자들의 딜레마

Replit, Bolt, GitHub Copilot 등의 도구 제작자들은 심각한 딜레마에 처해 있습니다.

기본적으로 React 코드를 생성하지 않는다면:

• 가용 시장이 제한됩니다
• 경쟁사들은 현재의 시장 수요를 충족시키고 있습니다
• 프레임워크 다양성에 원칙을 고수할 여유가 없습니다

결과적으로 이들은 모두 시스템 프롬프트에 React를 하드코딩하는 선택을 하게 됩니다. 이는 개별 도구 제작자의 선택이 아니라, 시장 논리가 강제하는 필연적 결과입니다.

Why it matters: 도구 제작자도 이 순환고리를 깨기 못합니다. 개별적으로는 올바른 선택처럼 보이지만, 집단적으로는 기술 다양성을 심각하게 손상시킵니다.

결론

죽은 프레임워크 이론은 단순한 기술 분석이 아니라, AI 시대의 기술 진화 방식 변화에 대한 경고입니다.

React는 더 이상 다른 프레임워크보다 "더 나은" 기술이 아닙니다. React는 LLM 학습 데이터 → 코드 생성 도구 → 웹 배포 → 다시 학습 데이터라는 자기 강화 루프를 통해 사실상의 웹 플랫폼이 되었습니다. 새로운 프레임워크가 경쟁하는 대상은 React의 기술적 특성이 아니라, 모든 LLM 학습 데이터셋에 깊이 뿌리내린 통계적 우위입니다.

새로운 프레임워크 제작자들에게 메시지는 명확합니다: 기술적 우수성만으로는 충분하지 않습니다. LLM 학습 데이터에 진입하고, 도구 제공자를 설득하고, 포괄적인 생태계를 구축해야 합니다. 하지만 이 모든 과정에 최소 12~18개월이 소요되는 동안, React 생태계는 1,000만 개 이상의 추가 사이트를 생성할 것입니다.

웹 플랫폼 개발자들에게도 교훈이 있습니다: 개발자 경험(syntactic sugar, 편의 API)을 위한 기능들은 LLM 학습 데이터에 이미 확립된 React 패턴과 경쟁하게 되며, 대부분 채택되지 않을 것입니다. 오직 사용자 영역에서 구축될 수 없는 근본적인 기능에 집중해야 합니다.

우리가 직면한 현실은 이것입니다: LLM 학습 데이터에 없다면, 그것은 존재하지 않는 것입니다. 최소 12~18개월 동안, 다음 모델 학습 주기가 도래하기 전까지는, 그리고 통계적으로 의미 있을 만큼 충분한 예시가 현실에 존재하기 전까지는 말입니다.

---

References

• (번역) 죽은 프레임워크 이론 (dead framework theory), 2025-12-08
• Dead Framework Theory, 2024-10-01
• Why React JS Leads Web & Mobile Dev in 2025, 2025-08-05
• TypeScript's rise, React's AI advantage, 2024-12-31