(번역) 죽은 프레임워크 이론 (dead framework theory)

 

 

원문: https://aifoc.us/dead-framework-theory

 

이는 점점 더 많은 개발자들이 LLM과 프레임워크를 사용하여 웹을 구축함에 따라 발생할 수 있는 일에 대한 제 의견이자 고찰입니다.

 

작년 10월, 저는 "개발자들은 미래에 프레임워크에 관심을 가질까요?"라는 글을 쓰면서 LLM이 프레임워크 선택을 추상화할 것이라고 예측했습니다만 제 예측은 틀렸습니다. 적어도 타임라인에 대해서는 말이죠.

 

현실은 더욱 흥미로우며 또한 더욱 영속적입니다. 이제 리액트는 다른 프레임워크들과 경쟁하지 않습니다. 리액트는 플랫폼이 되었습니다. 그리고 오늘날 새로운 프레임워크, 라이브러리 또는 브라우저 기능을 구축하고 있다면, 단지 리액트와 경쟁하는 것뿐만 아니라 LLM 학습 데이터, 시스템 프롬프트, 그리고 개발자 생성 코드 사이의 자기 강화 피드백 루프(self-reinforcing feedback loop)에 맞서 경쟁하고 있다는 사실을 이해해야 합니다. 이 루프는 리액트를 대체하는 것을 기능적으로 불가능하게 만듭니다.

 

Replit, Bolt 그리고 이와 유사한 도구들이 무엇을 하고 있는지 살펴보면, 이들은 프레임워크를 추상화하려고 시도하는 것이 아닙니다. 오히려 시스템 프롬프트에 리액트를 명시적으로 하드코딩하고 있습니다. 그들은 그렇게 해야만 합니다. 오늘날 개발자들의 흥미를 끌기 위한 도구를 구축하고 있다면, 그들이 유지보수할 수 있는 코드를 제공해야 합니다. 그리고 이제 "개발자들이 유지보수할 수 있는 코드"는 대다수의 웹 개발자에게는 "리액트"를 의미합니다.

 

builtwith.com에 따르면, 지난 12개월 동안 상위 1백만 개 사이트 외에도 리액트로 배포된 사이트가 1,300만 개 이상 있었습니다. 다음 곡선들을 보십시오.

 

리액트 사용량 변화

 

지난 12개월 간 리액트 사용량 변화

 

하지만, HTTP Archive를 보면 얘기가 다릅니다. Builtwith에서 보고된 5,500만 개의 Origin과는 달리, 모바일에서의 리액트 사용량은 120만 개의 모바일 Origin에서 정체(stalled)되었습니다.

 

HTTP Archive. 지난 6개월 간 리액트 사용량 변화

 

데이터셋 크기는 매우 다릅니다. HTTP Archive는 약 1,200만~1,600만 개의 Origin을 조사하는 반면, Builtwith는 약 4억 1,400만 개의 Root Domain을 조사하는 것으로 알려져 있습니다. 또한 HTTP Archive에 등록되는 사이트는 일정 수준의 사용량이 있어야 하는 반면, Builtwith의 많은 사이트들은 파킹 도메인이거나 활발하게 사용되지 않은 사이트일 수 있습니다.

 

상위 100만 개 사이트를 살펴보면 탐지율은 더 비슷합니다. 14만 개 대 16만 개입니다.

 

HTTP Archive. 상위 100만 개 사이트의 리액트 사용량 변화

 

Builtwith. 상위 100만 개 사이트의 리액트 사용량 변화

 

우리는 상위 100만 개 사이트 중 약 12%에서 18% 정도의 점유율을 보고 있습니다. 이러한 수치들은 다소 걸러서 받아들여야 합니다. 탐지 방식에 오류가 있을 수 있고, 데이터셋의 크기가 다르며, 측정 대상의 정의 또한 다를 수 있기 때문입니다. 하지만 다음의 추세는 부인할 수 없을 것 같습니다. 경쟁자인 Angular와 같은 프레임워크가 정체하고 있는 동안에도 리액트의 성장은 지속되고 있습니다.

 

그렇다면 리액트 사이트의 이러한 증가세를 견인한 것은 무엇일까요? 제가 이 데이터를 읽기로는, 지난 12~18개월 동안의 LLM 도구들이 리액트 코드를 생성하는 것을 선호하고 있기 때문이라고 생각합니다.

 

OpenRouter의 토큰 증가량을 보십시오. 프로그래밍 도구들은 단 하나의 게이트웨이를 통해서도 하루에 수십억 개의 토큰을 소모하고 있습니다. 그 곡선은 유사해 보입니다.

 

OpenRouter 토큰 사용량 변화

 

상관관계가 인과관계는 아니며, 토큰이 시스템을 통해 흘러가는 전체적인 그림은 오직 해당 도구 제작자들만이 볼 수 있습니다. 하지만 이 시점은 매우 절묘합니다. 대규모 토큰 증가가 리액트 배포의 대규모 증가와 동시적으로 발생하고 있습니다.

 

모델과 도구들은 개발자들이 이미 사용하고 있는 도구들을 선호하고 있으며, 이는 자기 강화적인 채택 주기(self-reinforcing cycle of adoption)를 이끌고 있습니다. 오늘날 새로운 API나 도구를 출시한다면, 이것이 생태계에 어떻게 채택될지, 그리고 LLM의 학습 데이터셋(Corpus)에 어떻게 포함되도록 할 것인지를 고려해야 합니다.

 

역주: '학습 데이터셋(Corpus)'는 기계 학습 모델이 학습하는 데 사용되는 대규모 텍스트 데이터 집합을 의미합니다. 이러한 데이터셋는 모델이 언어 패턴, 문법, 어휘 등을 이해하고 생성하는 능력을 향상하는 데 사용됩니다.

 

여기에는 두 가지 피드백 루프가 작용하고 있습니다.

 

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

 

그리고...

 

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

저는 실제로 이것이 나쁜지 혹은 좋은지 판단할 수 없습니다. 우리는 웹에서 더 많은 사이트를 얻고 있으며, 그 사이트들은 모두 꽤 높은 품질을 가지고 있습니다. 하지만 이 현상은 우리가 이해할 필요가 있는 새로운 프레임워크와 도구들, 그리고 웹 플랫폼 기능에 대한 장벽을 만듭니다. 특히 다음과 같은 상황일 때 말입니다.

 

1. 당신의 프레임워크가 신규 프레임워크라서 학습 데이터에 포함되어 있지 않은 경우
2. 개발자들이 오늘날 알고 있는 것이 리액트이기 때문에 도구 제작자들이 리액트를 하드코딩하는 경우
3. 항상 그래왔던 대로 리액트 코드가 생성될 것이라고 개발자들이 기대하는 경우
4. 회사의 개발자들이 당신의 프레임워크를 유지보수할 수 있는 여력이 없어서 이를 사용하지 않을 경우
5. 리액트는 수천 개의 라이브러리를 가지고 있지만 당신은 수십 개만 가지고 있는 경우

 

오늘날 당신이 새로운 프레임워크, 라이브러리 또는 브라우저 기능을 출시한다면, 그것이 기술적으로 우수하더라도 다음을 수행해야 합니다.

 

• LLM 학습 데이터에 진입해야 합니다. (최소 12~18개월의 지연이 발생합니다.)
• 도구 제작자들에게 시스템 프롬프트를 수정하도록 설득해야 합니다. (이는 채택이 필요합니다.)
• 포괄적인 라이브러리 생태계를 구축해야 합니다. (수년간의 개발이 필요합니다.)
• 개발자들의 관성을 극복하고, 그들이 스스로 그것을 요구하도록 만들어야 합니다.

 

여러분이 1단계를 완료할 때쯤이면, 리액트를 사용하는 생태계는 이미 1,000만 개 이상의 사이트를 추가로 생성했을 것입니다. 여러분은 그 순서를 뒤집어서 개발자들의 인식 점유율을 얻기 위한 대규모 캠페인을 진행하고, 라이브러리 생태계에 유료로 통합하는 방식으로 보충할 수도 있습니다. 심지어 프레임워크 및 라이브러리 제작자들이 도구 제공자에게 시스템 프롬프트에 자신들의 프레임워크를 포함하도록 비용을 지불하는 새로운 비즈니스 모델도 보게 될지 모릅니다. 하지만 그때조차도, 여러분은 리액트 라이브러리들과 LLM 학습 데이터 모두에 깊이 뿌리내린 패턴과 싸우고 있는 것입니다.

 

이것은 리액트가 최고의 도구라거나, 리액트의 모델이 LLM들에게 좋다는 이야기가 아닙니다 (저는 그럴 만한 근거를 전혀 발견하지 못했습니다). 이는 네트워크 효과(network effects)가 대안을 존속시키기 어렵게 만드는 지점을 리액트가 이미 넘어섰다는 이야기입니다.

 

저에게 이 상황을 명확히 각인시켜 준 사례가 있습니다. 지난주, 저는 Chrome의 내장 Prompt API를 사용하여 Chrome Extension을 구축하기 위해 Claude를 사용했습니다. Claude는 전체 Extension 코드를 충실히 작성했지만, 6개월 전 API였던 self.ai.languageModel을 사용했습니다. 현재 API는 LanguageModel.create()이지만, 이는 아직 학습 데이터셋에 포함되지 않았던 것입니다.

 

여기에 상호 운용성 작업에 수년이 걸려서야 비로소 기능이 "Baseline Newly-Available (새로 사용 가능한 기준선)" 상태에 도달하고, 그 후 다시 30개월이 지나야 "Baseline Widely-Available (광범위하게 사용 가능한 기준선)" 상태에 도달한다는 사실까지 더해 보십시오. 그때쯤이면, 생태계는 이미 앞으로 나아갔고, 해당 기능은 리액트 라이브러리와 LLM 학습 데이터 모두에 뿌리내린 패턴과 경쟁하게 됩니다.

 

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

 

이제 이것을 프레임워크들에게 적용해 봅시다.

 

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

 

오늘날, 여러분의 프레임워크나 문서가 LLM의 학습 데이터셋에 없다면, 그것은 출력되지 않을 것입니다. 개발자가 사용하는 도구의 시스템 프롬프트에 여러분의 API, 라이브러리 또는 프레임워크가 없다면, 그것은 출력되지 않습니다. 그리고 도구 사용자가 특정 API, 라이브러리 또는 프레임워크를 요청하지 않는다면, 그것 역시 출력되지 않을 것입니다. 모델 제공자들은 모델이 특정 스타일, 프레임워크 또는 라이브러리를 선호하도록 편향시키고 있습니다.

 

동일한 역학 관계가 프레임워크 기능들을 대체하도록 설계된 새로운 웹 플랫폼 API에도 적용됩니다. 일반적인 패턴을 생각해 보세요.

 

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

 

왜 그럴까요? 그 이유는 다음과 같습니다.

 

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

 

예를 들어 보겠습니다.

 

• 사람들은 Sass를 매우 좋아했지만, 빌드 단계가 필요했기 때문에 CSS Nesting이 등장했습니다. 하지만 이는 거의 출력되지 않습니다. 그 이유는 전처리 패턴이 데이터셋에서 더 흔하게 나타나기 때문이며, 리액트 개발자들이 이미 LLM이 출력할 줄 아는 CSS-in-JS 솔루션을 가지고 있기 때문입니다.
• 캐러셀은 구축하기 어렵기 때문에, 플랫폼의 기본 기능으로 만들어야 한다는 의견이 있을 수 있습니다. 하지만 이미 LLM 학습 데이터에 존재하는 훌륭한 캐러셀을 만들어내는 라이브러리는 수없이 많습니다.

 

많은 사이트의 저자로서, 저는 이러한 기능들을 좋아합니다. CSS 중첩만 하더라도 제가 개인적으로 더 읽고 유지보수하기 쉽다고 생각하는 방식으로 CSS 구조를 잡을 수 있게 해 줍니다. 하지만 이는 제 사이트를 사용하는 사람의 사이트 경험 품질 자체를 실제로 바꾸지는 않습니다. 사이트의 성능을 바꾸지 않으며, 제 사이트의 접근성을 바꾸지도 않습니다. 단지 제가 작성하고 유지보수하기 더 쉽게 만들 뿐입니다.

중요한 새로운 플랫폼 기능은 다음과 같이 사용자 영역에서 구축될 수 없는 것들뿐입니다.

 

• 다중 페이지 view transitions (새로운 탐색 기능)
• WebGPU (근본적으로 새로운 연산 접근)
• WebAuthN과 PassKeys (보안 기본 요소)

 

다른 모든 것들은 리액트 라이브러리와 LLM 학습 데이터 모두에 깊이 뿌리내린 패턴들과 경쟁하고 있습니다.

여기서 고려해야 할 최소 세 가지의 구성요소가 있습니다.

 

1. 웹 구축의 핵심(head) 비즈니스 - 웹에서 트래픽과 수익의 가장 큰 몫을 차지하는 상위 1,000개 사이트 그룹입니다. 상위 1,000개에서 100만 개 사이의 사이트에서는 대규모 기술 변화를 찾아보기 어렵습니다. 이들은 이미 자리 잡은 사이트와 안정된 팀을 보유하고 있으며, 기술을 전환하는 것은 어렵고 잠재적인 제품 속도 향상 외에는 명확하지 않은 이점이 많기 때문입니다. 이들은 속도를 높이기 위해 LLM 기반의 도구를 사용할 가능성이 높지만, 프레임워크나 라이브러리를 쉽게 전환하지는 않을 것입니다.
2. 웹 구축의 중간(middle) 비즈니스 - 다음 1,000만 개의 사이트 그룹은 소규모 팀과 개인에 의해 구축되고 있으며, 이들은 LLM을 사용하여 새로운 사이트를 완전히 구축할 가능성이 높습니다. 그리고 별도로 프롬프트를 지정하지 않은 한, 도구가 출력하는 기본값을 사용할 것입니다.
3. 긴 꼬리(long tail) - 이들은 정규 웹 개발자가 아니며, Loveable, Replit 또는 심지어 채팅 앱에서 직접 도구를 사용할 사람들입니다. 이들은 코드를 들여다볼 필요가 전혀 없을 수도 있습니다. 그렇다면 이러한 새로운 API들 중 어떤 것이 이들이 더 나은 사이트를 구축하는 데 도움이 될까요? 이들은 플랫폼의 성장을 대변하며, 수백만 명의 사람들이 웹에 배포할 수 있는 기회를 제공합니다.

 

2번과 3번 그룹의 사람들은 웹사이트의 성장을 주도하는 주역이지만, 이들은 Passkeys, WebAuthn, Web Components, CSS Nesting, View Transitions 등 플랫폼에 추가되는 다른 새로운 기능들에 대해 알지 못하는 도구들을 사용하여 사이트를 구축할 가능성이 높습니다. 이들은 단지 자신들이 원하는 기능을 수행하는 사이트가 생성되기를 원할 뿐입니다.

 

중요한 점은 웹을 사용하는 일반 사용자들은 도구에 관심이 없다는 것입니다. 프레임워크와 라이브러리는 웹을 사용하는 일반 사용자에게는 전혀 중요하지 않은 문제입니다. 사람들이 관심을 갖는 것은 페이지가 충분히 빠르게 로드되는가? 상호작용이 부드러운가? 사이트가 실제로 내가 필요로 하는 기능을 수행하는가? 와 같은 페이지를 사용하는 경험입니다.

 

오늘날, 만약 여러분이 이 범주들(LLM 또는 LLM으로부터 코드를 출력하는 도구) 중 어느 하나에 속한 개발자를 대상으로 하는 회사라면, 기본적으로 리액트 코드를 생성하지 않은 것은 잠재적인 고객을 제한하는 행위입니다. 왜냐하면 경쟁사들은 현재의 수요를 충족시키고 있기 때문입니다.

 

이제 코드 생성 LLM 도구의 현재 작동 모델을 고려해 보십시오. 이 모델은 학습된 생태계를 반영합니다. 이는 새로운 API, 프레임워크 또는 라이브러리가 도구에 의해 출력될 수 있도록 하는 데 있어 큰 장벽을 넘어야 함을 의미합니다. 어떤 새로운 기능이라도 학습 데이터셋에 포함되지 않을 수 있고, 그 사용 패턴과 관용구가 모델 학습과 나아가 LLM의 출력에 각인될 만큼 충분히 널리 퍼지지 않을 수 있다는 사실은 새로운 플랫폼 기능을 구축하는 사람들에게 우려 사항이 되어야 합니다.

 

오늘날 도구들이 주로 리액트 코드를 출력하는 추세를 살펴보면, 사용자 영역 라이브러리의 포괄적인 생태계는 커스텀 Select Box부터 특화된 날짜 컴포넌트 및 그 외의 모든 것을 거의 다 처리할 수 있습니다. 저는 새로운 플랫폼 기능이 현재 사용 중인 라이브러리를 대체하거나, 새로운 프레임워크가 단기에서 중기적으로 리액트를 대체하는 세상을 상상할 수 없습니다. 저는 Remix 팀이 Remix 3로 추진하는 일들을 정말 좋아하며, 이것이 어떻게 채택되고 LLM들이 어떻게 이 프레임워크를 받아들일지 주의 깊게 지켜보며 이 글의 예측이 현실에서 어떻게 전개될지 보고 싶습니다. LLM들이 특정 프롬프트나 문서를 맥락에 포함시키지 않고도 Remix 코드를 출력하기 시작하는 데 얼마나 오랜 시간이 걸릴지 보고 싶습니다.

 

프레임워크 제작자들에게: 새로운 프레임워크를 구축하는 것은 LLM들이 최소 12~18개월 동안 제공하지 않을 제품을 만드는 것이며, 이는 곧 라이브러리 생태계가 없고 개발자들이 알지 못하며, 기업들이 채택하지 않을 제품을 만드는 것입니다. 여러분은 리액트의 기술적 장점과 경쟁하는 것이 아닙니다. 여러분은 모든 LLM 학습 데이터셋에서 리액트가 차지하는 통계적 우위와 도구 제공업체 고객들의 선호도와 경쟁하고 있는 것입니다.

 

플랫폼 개발자들에게: 개발자 경험을 위한 기능들(예: Syntactic Sugar, 편의 API)은 LLM 학습 데이터에 이미 확립된 리액트 패턴과 경쟁하고 있으며 이것들은 대부분 채택되지 않을 것입니다. 사용자 영역에서 구축될 수 없는 근본적인 기능에 집중해야 합니다. 오늘날 브라우저 개발자들이 만들고 있는 기능들의 경우, 우리는 개발자가 아닌 사용자에게 가져다줄 이점을 면밀히 검토해야 합니다. 그러한 관점에서, 웹 컴포넌트에서부터 구문적 변화에 이르기까지 많은 플랫폼 기능들은 향후 몇 년 동안 사이트를 구축할 대다수의 사람들에게는 전혀 필요하지 않을 것입니다.

 

도구 제작자들에게 (예: IDE): 기본적으로 리액트 코드를 생성하지 않는다면, 여러분의 가용 시장은 제한됩니다. 당신의 경쟁자들은 현재의 시장의 수요를 충족시키고 있습니다. 당신은 프레임워크 다양성에 대해 원칙을 고수할 여유가 없습니다.

죽은 프레임워크 이론은 프레임워크가 사라지는 것에 관한 것이 아닙니다. 리액트가 플랫폼이 된 세상에서 적어도 사람들이 코드를 유지보수해야 하는 한, 새로운 프레임워크가 도착과 동시에 죽어 있는(dead on arrival) 상태라는 의미입니다.

 

역주: 'dead on arrival'은 '도착 시 이미 사망'이라는 뜻으로, 기술 분야에서는 제품이 배달되거나 설치되자마자 불량으로 판명된 상태를 의미합니다. 해당 글에서는 새로운 프레임워크가 출시되자마자 시장에서 성공하지 못하는 상황을 비유적으로 표현하고 있습니다.

 

업계로서 우리는 새로운 프레임워크, 라이브러리 및 플랫폼 기능을 반드시 혁신하고 구축해야 합니다. 웹을 발전시키고 경쟁을 창출하기 위해서는 혁신이 필요합니다. 하지만 우리는 작용하고 있는 역학 관계를 인식해야 하며, 우리의 결과물을 LLM 학습 데이터셋, 시스템 프롬프트, 그리고 개발자들의 마음에 심기 위한 명확한 전략을 가져야 합니다.

 

만약 업계가 유지보수성과 개발자 경험에 현재와 같은 초점을 맞춘다면, 결국 LLM들이 리액트와 학습 데이터에 깊이 뿌리내린 소수의 라이브러리를 사용하여 웹을 구축하는 세상에 이르게 될 것입니다. 프레임워크 혁신은 정체되고, 플랫폼 혁신은 다른 곳에 초점을 맞추게 됩니다. 리액트는 보이지 않으며 변경 불가능한 존재인 인프라가 될 것입니다.

 

하지만 여기에 낙관적인 견해가 있습니다. 만약 LLM 사용이 계속 증가한다면, 도구 벤더사들은 이러한 동질화된 생태계 내에서 서로 경쟁해야 할 것입니다. 모두가 기본적으로 리액트 코드를 생산할 때, 프레임워크 선택에 있어서는 차별점을 가져갈 수 없습니다. 여러분은 코드 생성 품질로 경쟁해야 합니다. 시장의 힘은 개발자 경험에서 사용자 경험으로 초점을 옮기고 있습니다.

 

두 가지 시나리오 중 어느 쪽이든, 우리는 사용자 결과물을 두고 경쟁하기 시작해야 합니다. 저는 Core Web Vitals가 성능에 대해 그랬던 것처럼, 품질 결과물에 초점을 맞춘 평가와 벤치마크가 등장하기를 정말로 바랍니다. 도구들이 사용자를 유치하기 위해 경쟁할 때, 의미 있게 더 나은 경험을 제공하는 도구가 승리할 것입니다. 이러한 경쟁 압박은 전체 생태계가 개발자가 아닌 사용자를 위해 최적화하도록 장려할 것입니다.

 

그리고 만약 우리가 성공한다면 어떨까요? 그렇다면 장기적으로, 사람들이 단어만으로 사이트를 조작할 수 있을 정도로 모델이 개선되고, LLM 제공업체들이 자신들의 자체 프레임워크나 튜닝을 통해 더 나은 결과물을 만들 수 있다고 믿게 되면서 프레임워크는 무의미해질 것입니다. (Ade에게 감사를 표합니다.) 전달 기술은 사용자 요구를 충족시키는 최적화된 컴파일된 출력이 됩니다. 그것이 "리액트"든 다른 무엇이든 상관없어지는 것입니다.

 

원시적이고 순수한 웹 플랫폼은 어떨까요? 근본적으로 새로운 기능, 즉 사용자 영역에서 구축할 수 없는 기능이나 라이브러리로는 달성할 수 없는 명확한 사용자 경험에 집중해야 합니다.

 

 

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!