죽은 프레임워크 이론
AI Focus 블로그 포스트 번역
2025년 10월 12일
이것은 저의 의견이며, 더 많은 개발자들이 LLM과 Framework를 사용하여 웹을 구축할 때 일어날 수 있는 일에 대한 생각입니다.
지난해 10월에 저는 "개발자들이 미래에 Framework를 신경 쓸까?"라는 글을 작성했으며, LLM이 Framework 선택을 추상화할 것이라고 예측했습니다. 저는 틀렸습니다. 적어도 타이밍에 대해서는 틀렸습니다.
현실은 더 흥미롭고 더 영구적입니다: React는 더 이상 다른 Framework들과 경쟁하지 않습니다. React는 플랫폼이 되었습니다. 그리고 오늘날 새로운 Framework, Library 또는 브라우저 기능을 구축하고 있다면, 저희는 React와만 경쟁하는 것이 아니라 LLM 학습 데이터, 시스템 프롬프트, 개발자 출력 사이의 자기 강화 피드백 루프와 경쟁하고 있다는 것을 이해해야 합니다. 이는 React를 대체하는 것을 기능적으로 불가능하게 만듭니다.
Replit, Bolt 및 유사한 도구들이 하고 있는 일을 보면, 저희는 Framework를 추상화하려고 하지 않습니다. 저희는 명시적으로 시스템 프롬프트에 React를 하드코딩합니다. 저희는 그렇게 해야 합니다. 오늘날 개발자를 유치하기 위한 도구를 구축하고 있다면, 저희는 개발자들이 유지할 수 있는 코드를 제공해야 합니다. 그리고 "개발자들이 유지할 수 있는 코드"는 이제 대다수의 웹 개발자에게 "React"를 의미합니다.
그러나 HTTP Archive를 보면, 다른 이야기를 전합니다. React 사용량은 모바일에서 120만 개의 모바일 출처에서 정체되어 있으며, Builtwith에서 보고한 5,500만 개의 출처와 비교됩니다.
데이터 세트 크기는 매우 다릅니다. HTTP Archive는 약 1,200만~1,600만 개의 출처를 살펴보는 반면, Builtwith는 약 4억 1,400만 개의 루트 도메인을 살펴보고 있다고 보고됩니다. 또한 사이트는 어느 정도의 사용량이 있어야 HTTP Archive에 들어가며, Builtwith의 많은 사이트는 주차된 도메인이거나 적극적으로 사용되지 않는 사이트일 수 있습니다.
상위 1백만 개를 보면, 감지 비율이 더 일치합니다: 140k 대 160k입니다.
저희는 상위 1백만 개 사이트의 약 12~18%를 보고 있습니다. 이 모든 숫자를 약간의 회의적 태도로 받아들이세요. 감지가 깨질 수 있고, 데이터 세트 크기가 다르며, 측정되는 것의 정의가 다릅니다. 하지만 추세는 부인할 수 없는 것 같습니다: React의 성장은 계속되는 반면 Angular와 같은 경쟁자들은 안타깝게도 정체되어 있습니다.
그렇다면 React 사이트의 증가를 주도한 것은 무엇일까요? 저의 데이터 해석은 지난 12~18개월 동안 LLM 도구들이 React 코드를 출력하는 것을 선호하고 있음을 시사합니다.
상관관계는 인과관계가 아니며, 토큰이 시스템을 통해 흐를 때 도구 제작자들만 전체 그림을 봅니다. 하지만 타이밍은 놀랍습니다: 대규모 토큰 성장이 대규모 React 배포 성장과 일치합니다.
모델과 도구들은 개발자들이 이미 사용하고 있는 도구들을 선호하고 있으며, 이는 채택의 자기 강화 순환을 주도하고 있습니다. 오늘날 새로운 API나 도구를 출시하고 있다면, 저희는 생태계에 의해 어떻게 채택될 것인지, 그리고 LLM의 학습 코퍼스에 어떻게 들어갈 것인지를 고려해야 합니다.
저희는 여기서 두 가지 피드백 루프가 작동하고 있습니다:
- React가 기존 웹을 지배합니다 (~12개월 동안 1,300만 개 이상의 새로운 사이트)
- LLM이 기존 웹에서 학습합니다
- LLM이 기본적으로 React를 출력합니다
- LLM으로 구축된 새로운 사이트는 React를 사용합니다
- 향후 학습을 위해 더 많은 React 사이트가 존재합니다
- 2단계로 이동합니다
그리고…
- React가 개발자 생태계를 지배합니다
- IDE와 도구들이 개발자들이 선호하는 React를 출력합니다
- 도구들이 LLM에 기본적으로 React를 출력하도록 요청합니다
- 구축된 새로운 사이트는 React를 사용합니다
- React를 출력하도록 도구에 대한 수요를 증가시키기 위해 더 많은 React 사이트가 존재합니다
- 1단계로 이동합니다
저는 실제로 이것이 좋은지 나쁜지 모릅니다. 저희는 웹에 더 많은 사이트를 얻고 있으며 모두 상당히 높은 품질입니다. 하지만 저희가 이해해야 할 새로운 Framework, 도구 및 웹 플랫폼 기능에 대한 장벽을 만듭니다. 특히 다음과 같은 경우:
- Framework가 새로워서 학습 데이터에 없습니다
- 도구 제작자들이 오늘날 개발자들이 알고 있는 것이기 때문에 React를 하드코딩합니다
- 개발자들은 작동하는 것이기 때문에 React 출력을 기대합니다
- 회사들은 개발자들이 유지할 수 없다면 Framework를 사용하지 않습니다
- React는 수천 개의 Library를 가지고 있습니다. 저희는 수십 개를 가지고 있습니다
오늘날 새로운 Framework, Library 또는 브라우저 기능을 출시한다면, 기술적으로 우수하더라도, 저희는 다음을 수행해야 합니다:
- LLM 학습 데이터에 들어가기 (최소 12~18개월 지연)
- 도구 제작자들을 설득하여 시스템 프롬프트 수정 (기존 채택 필요)
- 포괄적인 Library 생태계 구축 (수년의 개발)
- 개발자 관성을 극복하고 개발자들이 이를 요청하도록 하기
1단계를 완료할 때쯤이면, React를 사용하는 생태계는 또 다른 1,000만 개 이상의 사이트를 생성했습니다. 저희는 그 순서를 뒤집을 수 있으며, 개발자 마음 점유율을 얻기 위해 대규모 캠페인을 수행하고, Library 생태계에 대한 유료 통합으로 보충할 수 있습니다. 저희는 Framework 및 Library 작성자들이 시스템 프롬프트에 Framework를 포함하도록 도구 제공자에게 비용을 지불하는 새로운 비즈니스 모델을 볼 수도 있습니다. 하지만 그렇더라도, 저희는 React Library와 LLM 학습 데이터 모두에 뿌리내린 패턴과 싸우고 있습니다.
이것은 React가 최고의 도구이거나 그 모델이 LLM에 좋다는 것에 관한 것이 아닙니다 (저는 거기에 어떤 증거도 보지 못합니다). 이것은 React가 네트워크 효과가 대안을 실행 가능하게 만드는 지점을 지나갔다는 것에 관한 것입니다.
이것이 저에게 와닿은 것은 다음과 같습니다: 지난주 저는 Claude를 사용하여 Chrome의 내장
prompt API를 사용하는 Chrome Extension을 구축했습니다. Claude는 성실하게 전체 Extension을 작성했지만, 6개월 전의 API인 self.ai.languageModel을 사용했습니다. 현재 API는 LanguageModel.create()이지만, 그것은 학습 코퍼스에 없었습니다.기능이 "Baseline newly-available"이 되는 지점에 도달하기 위해 수년의 Interop 작업이 필요할 수 있다는 사실을 추가하면, "Baseline widely-available"에 도달하는 데 또 다른 30개월이 필요합니다. 그 시간까지, 생태계는 앞으로 나아갔으며, 기능은 React Library와 LLM 학습 데이터 모두에 뿌리내린 패턴과 경쟁하고 있습니다.
이것이 새로운 현실입니다: LLM 학습 데이터에 없으면, 존재하지 않습니다. 적어도 12~18개월 동안은 아닙니다. 다음 모델 학습 주기까지는 아닙니다. 충분한 예제가 야생에 존재하여 통계적으로 중요할 때까지는 아닙니다.
이제 이것을 Framework에 적용하세요:
- 웹 플랫폼 API: 학습 차단 전 0~6개월의 실제 사용
- 새로운 Framework: 학습 차단 전 0~6개월의 실제 사용
- React 패턴: 10년 이상의 누적된 예제
오늘날, Framework나 문서가 LLM의 학습 코퍼스에 없다면, 출력되지 않을 것입니다. 개발자가 사용하는 도구의 시스템 프롬프트에 API, Library 또는 Framework가 없다면, 출력에 없을 것입니다. 도구 사용자가 특정 API, Library 또는 Framework를 요청하지 않으면, 출력되지 않을 것입니다. 모델 제공자들은 모델이 특정 스타일, Framework 또는 Library를 선호하도록 기울이고 있습니다.
동일한 역학은 Framework 기능을 대체하도록 설계된 새로운 웹 플랫폼 API에 적용됩니다. 일반적인 패턴을 고려하세요:
- 브라우저 팀이 Framework의 일반적인 패턴을 식별합니다 (예: Sass 대신 CSS Nesting)
- 다년간의 표준화 프로세스가 시작됩니다
- 기능이 브라우저에 배포됩니다
- 개발자들은… Framework 패턴을 계속 사용합니다
왜일까요? 왜냐하면:
- LLM이 이전 패턴을 배웠습니다: Sass는 15년의 예제를 가지고 있습니다. CSS Nesting은 1~2년입니다
- Framework가 이미 작동합니다: React 개발자들은 styled-components, Tailwind, CSS modules를 사용합니다
- 생태계가 구축되었습니다: 수천 개의 React 컴포넌트 Library가 기존 CSS 패턴을 사용합니다
- 전환할 인센티브가 없습니다: 새로운 플랫폼 기능이 사용자를 위해 사이트를 더 좋게 만들지 않습니다
예를 들어:
- 사람들은 Sass를 좋아했지만, 빌드 단계가 필요하므로 저희는 CSS Nesting을 가지고 있습니다. 그러나 전처리기 패턴이 코퍼스에서 더 일반적이고 React 개발자들이 이미 LLM이 출력하는 방법을 알고 있는 CSS-in-JS 솔루션을 가지고 있기 때문에 거의 출력되지 않습니다.
많은 사이트의 작성자로서, 저는 이 기능들을 좋아합니다. CSS Nesting만으로도 저는 CSS를 개인적으로 읽고 유지하기가 더 쉽다고 생각하는 방식으로 구조화할 수 있습니다. 하지만 사이트를 사용하는 사람을 위해 사이트의 경험 품질을 실제로 변경하지는 않습니다. 사이트의 성능을 변경하지 않습니다. 사이트의 접근성을 변경하지 않습니다. 저에게 작성하고 유지하기가 더 쉬울 뿐입니다.
중요한 유일한 새로운 플랫폼 기능은 사용자 공간에서 구축할 수 없는 것들입니다:
- Multi-page view transitions (새로운 네비게이션 기능)
- WebGPU (근본적으로 새로운 컴퓨팅 액세스)
- WebAuthN과 PassKeys (보안 기본 요소)
다른 모든 것은 React Library와 LLM 학습 데이터 모두에 뿌리내린 패턴과 경쟁하고 있습니다.
여기서 고려해야 할 최소 3가지 이해관계자가 있습니다:
- 웹에서 구축하는 "head" 비즈니스 - 상위 1,000개 사이트는 웹의 트래픽과 수익의 대부분을 차지하며, 저희는 상위 1,000개에서 상위 1백만 개까지 상위 1백만 개에서 대규모 기술 변화를 보지 못합니다. 왜냐하면 이들은 확립된 사이트이고 확립된 팀이며 기술 변화는 종종 제품 속도 개선 외에 불명확한 이점으로 어렵기 때문입니다. 저희는 속도를 높이는 데 도움이 되도록 LLM 기반 도구를 사용할 가능성이 높지만, Framework나 Library를 가볍게 전환하지는 않을 것입니다.
- 웹에서 구축하는 "middle" 비즈니스 - 다음 1,000만 개 사이트는 소규모 팀과 개인에 의해 구축되며 LLM을 사용하여 새로운 사이트를 완전히 구축할 가능성이 높으며, 프롬프트하지 않으면 도구가 출력하는 기본값을 사용할 것입니다
- "long tail" - 이들은 Loveable, Replit 또는 채팅 앱에서 직접 사용하는 도구를 사용할 공식 웹 개발자가 아닌 사람들입니다. 저희는 코드를 볼 필요가 없을 수도 있으므로, 이 새로운 API들이 더 나은 사이트를 구축하는 데 어떤 도움이 될까요? 그리고 저희는 플랫폼의 성장을 나타내며 저희는 수백만 명 이상의 사람들이 웹에 배포할 수 있는 기회를 가지고 있습니다
2번과 3번 그룹의 사람들은 웹의 사이트 성장을 주도하고 있으며, 이 도구들로 구축하지 않는 한 Passkeys, WebAuthn, Web Components, CSS Nesting, View Transitions 또는 플랫폼에 추가되는 다른 새로운 기능에 대해 알 가능성이 낮습니다. 저희는 단지 필요한 것을 수행하는 사이트를 만들고 싶습니다.
문제는 웹을 사용하는 일반인들은 도구, Framework 및 Library에 신경 쓰지 않는다는 것입니다. 이것은 웹을 사용하는 일반인을 걱정하게 하지 않습니다. 사람들을 걱정하게 하는 것은 페이지 사용 경험입니다. 충분히 빨리 로드됩니까? 상호작용이 부드럽습니까? 사이트가 실제로 필요한 것을 수행합니까?
오늘날, 저희가 이러한 범주 중 하나에서 개발자를 대상으로 하는 회사라면 (LLM 또는 LLM에서 코드를 출력하는 도구), 기본적으로 React를 출력하지 않는 것은 경쟁자들이 현재 수요를 충족하고 있기 때문에 잠재적 청중을 제한하는 것입니다.
이제 코드 생성 LLM 도구의 현재 작동 모델을 고려하세요. 이는 학습된 생태계를 반영합니다. 이는 새로운 API, Framework 또는 Library가 도구에 의해 출력될 것이라는 측면에서 극복해야 할 큰 장애물이 있다는 것을 의미합니다. 모든 새로운 기능이 학습 코퍼스에 없을 수 있다는 사실과 LLM의 학습 및 확장 출력에 충분히 널리 퍼져 있지 않을 것이라는 사실은 새로운 플랫폼 기능을 구축하는 사람들에게 우려의 대상이어야 합니다.
오늘날의 도구가 주로 React 코드를 출력하는 추세를 보면, 사용자 공간 Library의 포괄적인 생태계는 사용자 정의 선택 상자, 특수 날짜 컴포넌트 및 기타 모든 것에서 거의 모든 것을 수행할 수 있습니다. 저는 새로운 플랫폼 기능이 사용 중인 Library를 대체할 세상을 볼 수 없으며, 저는 새로운 Framework가 단기에서 중기에 React를 대체할 세상을 볼 수 없습니다. 저는 Remix 팀이 Remix 3으로 하고 있는 것을 정말 좋아하며, 저는 어떻게 채택되는지, LLM이 어떻게 이를 선택할 수 있는지를 열심히 지켜볼 것입니다. 이 게시물이 현실 세계에서 어떻게 진행되는지 보기 위해 LLM이 특정 프롬프팅이나 컨텍스트에 문서를 포함하지 않고 Remix 코드를 출력하기 시작하는 데 얼마나 오래 걸리는지 보고 싶습니다.
Framework 작성자들을 위해: 새로운 Framework를 구축하는 것은 LLM이 최소 12~18개월 동안 출력하지 않을 제품을 구축하는 것입니다. Library 생태계가 없고, 개발자들이 모르며, 회사들이 채택하지 않을 것입니다. 저희는 React의 기술적 장점과 경쟁하지 않습니다. 저희는 모든 LLM 학습 코퍼스와 모든 도구 제공자의 선호도에서 React의 통계적 지배력과 경쟁하고 있습니다.
플랫폼 개발자들을 위해: 개발자 경험 기능 (구문 설탕, 편의 API)은 LLM 학습 데이터에서 확립된 React 패턴과 경쟁하고 있습니다. 저희는 규모에 따라 채택되지 않을 것입니다. 사용자 공간에서 구축할 수 없는 근본적인 기능에 집중하세요. 브라우저 개발자들이 오늘날 만들고 있는 기능의 경우, 저희는 개발자가 아닌 사용자에게 가져올 이점을 자세히 살펴봐야 합니다. 그 정도까지, Web Components에서 구문 변경에 이르는 많은 플랫폼 기능은 향후 몇 년 동안 사이트를 구축하는 대다수의 사람들에게 필요하지 않습니다.
도구 제작자들 (예: IDE)을 위해: 기본적으로 React를 출력하지 않으면, 저희는 주소 지정 가능한 시장을 제한하고 있습니다. 저희의 경쟁자들은 현재 수요를 충족하고 있습니다. 저희는 Framework 다양성에 대해 원칙적일 여유가 없습니다.
Dead Framework Theory는 Framework가 죽는 것에 관한 것이 아닙니다. 이것은 React가 플랫폼이 된 세상에서 새로운 Framework가 도착 시 죽는 것에 관한 것입니다 (적어도 사람들이 코드를 유지해야 하는 한).
산업으로서 저희는 절대적으로 혁신하고 새로운 Framework, Library 및 플랫폼 기능을 구축해야 합니다. 저희는 웹을 앞으로 나아가게 하고 경쟁을 만들기 위해 혁신이 필요합니다. 하지만 저희는 작동 중인 역학을 인식하고 저희의 작업을 LLM 학습 코퍼스, 시스템 프롬프트 및 개발자 마음에 넣기 위한 명확한 전략을 가져야 합니다.
산업이 유지 보수성과 개발자 경험에 대한 현재의 초점을 계속하면, 저희는 LLM이 React와 학습 데이터에 뿌리내린 소수의 Library를 사용하여 구축하는 웹의 세상에 끝날 것입니다. Framework 혁신이 정체됩니다. 플랫폼 혁신은 다른 곳에 초점을 맞춥니다. React는 인프라가 됩니다. 보이지 않고 변경할 수 없습니다.
하지만 낙관적인 관점이 있습니다: LLM 사용이 계속 증가하면, 도구 제공자들은 이 동질화된 생태계에서 서로 경쟁해야 합니다. 모두가 기본적으로 React를 출력할 때, 저희는 Framework 선택에 따라 차별화할 수 없습니다. 저희는 출력 품질에 따라 경쟁해야 합니다. 시장 세력은 개발자 경험에서 사용자 경험으로 초점을 이동시킵니다.
어느 시나리오든, 저희는 사용자 결과에 따라 경쟁하기 시작해야 합니다. 저는 Core Web Vitals이 성능을 위해 한 것처럼 품질 결과에 초점을 맞춘 Evals 및 Benchmarks를 보고 싶습니다. 도구들이 사용자를 유치하기 위해 경쟁할 때, 의미 있게 더 나은 경험을 출력하는 도구들이 승리할 것입니다. 이 경쟁 압력은 전체 생태계가 개발자가 아닌 사용자를 위해 최적화하도록 장려할 것입니다.
그리고 저희가 성공한다면? 그러면 장기적으로, Framework는 모델이 개선되어 사람들이 단어만으로 사이트를 조작할 수 있는 지점에 도달할 때 무관해질 것입니다. LLM 제공자들은 자신의 Framework나 튜닝으로 더 나은 결과를 만들 수 있다고 믿습니다 (Ade에게 감사). 배포 기술은 사용자 요구를 충족하는 최적화된 컴파일된 출력이 됩니다. "React"인지 다른 것인지는 더 이상 중요하지 않습니다.
원시적이고 벌거벗은 웹 플랫폼의 경우? 근본적으로 새로운 기능에 집중하세요. 사용자 공간에서 구축할 수 없는 것들, 또는 Library로 달성할 수 없는 명확한 사용자 경험 이점이 있는 것들입니다.
0
78
댓글
?
아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!