프레임워크는 부패하지만, 플랫폼은 그렇지 않습니다.

자신의 package.json을 바라보며 고민에 빠진 모든 이들을 위한 결정 메모.

SPA 프레임워크를 떠나려는 대부분의 논거는 업그레이드 트레드밀(upgrade treadmill) — 즉, 메이저 버전 마이그레이션, 의존성 변화(dependency churn), 빌드 도구 교체라는 끝없는 순환에 집중되어 있습니다. 그 논거는 실재하지만 불완전하며, 그 자체만으로는 결정적이지 않았습니다. 모든 프레임워크를 사용하는 곳들은 이미 그 트레드밀과 함께 살아가는 법을 배웠기 때문입니다. 하지만 서로 결합하여 시너지를 내는 네 가지 기둥에 기반한 더 강력한 논거가 존재합니다.

첫째, 총 소유 비용 (Total Cost of Ownership, TCO): 웹 플랫폼 위의 바닐라 자바스크립트(vanilla JavaScript)는 거의 평탄한 감가상각 곡선에 의해 지배되는 독특한 TCO 특성을 가집니다. 플랫폼을 대상으로 작성된 코드는 부패하지 않는데, 그 이유는 기반(substrate)이 변하지 않기 때문입니다. 장기적인 관점에서 이 단일 특성은 프레임워크가 제공하는 거의 모든 기능별 생산성 논거보다 더 큰 비중을 차지합니다.

둘째, 노동 시장: 바닐라 자바스크립트(vanilla JavaScript)로 작업할 수 있는 인력 풀은 프론트엔드 시장 내의 틈새 시장이 아닙니다. 그것은 프론트엔드 시장 전체이자, 백엔드 시장의 대부분이기도 합니다. 모든 프레임워크 개발자는 근본적으로 자바스크립트(JavaScript) 개발자입니다. 그 역은 성립하지 않습니다. 만약 특정 프레임워크를 기준으로 채용한다면, 당신은 주류를 채용하고 있다고 스스로를 설득하면서 실제로는 그 하위 집합(subset)에서 채용하고 있는 것입니다.

셋째, AI 레버리지 (AI leverage): 엔지니어들은 이제 AI의 도움을 받아 점점 더 많은 비중의 코드를 생성하고 있으며, 그 도움의 경제성은 대상에 따라 극명하게 갈립니다. 웹 플랫폼은 작고 안정적이며 철저하게 문서화된 지식 체계인 반면, 프레임워크 생태계는 학습 데이터가 끊임없이 노후화되는 크고 빠르게 변이하는 체계입니다. AI 코딩 도구는 전자의 경우에 측정 가능한 수준으로 더 신뢰할 수 있습니다. AI 보조 개발이 지배적인 생산 방식이 됨에 따라, AI가 가장 잘 다루는 기반이 더 저렴한 기반이 될 것이며, 프레임워크가 움직이는 동안 플랫폼이 정지해 있는 매년 그 격차는 더욱 벌어질 것입니다.

넷째, **아키텍처 (architecture)**입니다: Web Components로 포팅하는 것은 동일한 설계를 다른 구문으로 단순히 옮겨 적는(transliteration) 작업이 아닙니다. 플랫폼은 진정으로 다른 아키텍처, 즉 중앙에서 조정되는 트리(tree) 구조가 아닌 자율적이고 메시지 전달(message-passing)을 수행하는 컴포넌트 구조를 지향합니다. 그리고 이 아키텍처는 광범위한 애플리케이션 계층에 주로 유리한 독자적인 경제적 결과를 초래하며, 이는 우연히 발견하기보다는 의도적으로 채택해야 하는 부분입니다.

미리 권고 사항을 말씀드리자면: 만약 귀하의 애플리케이션이 적절한 사분면에 속한다면 — 즉, 협업형 캔버스(collaborative-canvas)보다는 수명이 길고 안정화되어 있으며 폼(forms)과 뷰(views) 중심이라면 — 스트랭글러 패턴 (strangler pattern)을 통해 점진적으로 마이그레이션하고, 빅뱅 방식의 재작성 (big-bang rewrite)은 거부하십시오. 이 포스트의 나머지 부분에서는 각 기둥(pillar)과 그 이면에 있는 논거, 그리고 이 논증 전체가 뒤집히는 조건들에 대해 전개할 것입니다.

2. 원칙 (Tenets)

기둥들을 살펴보기 전에, 그것들이 기반하고 있는 원칙들을 살펴보겠습니다. 만약 아래의 결론에 동의하지 않는다면, 그 이견은 아마도 이 원칙들 중 하나에 대한 것일 것이며, 바로 그 지점이 생산적인 논쟁이 일어날 수 있는 곳입니다.

1. 다음 분기의 개발 비용이 아니라, 애플리케이션의 전체 수명 동안의 총 소유 비용 (TCO)을 최적화하십시오. 기반 기술의 가치 하락률 (depreciation rate)은 도입 첫날의 사용성 (ergonomics)보다 더 중요합니다.
2. 노동력 풀 (labor pools)을 측정할 때 기술의 명칭이 아니라 기술의 하한선 (skill floor)을 기준으로 하십시오. 관련 질문은 "React 개발자가 몇 명인가"가 아니라 "얼마나 많은 사람이 한 달 안에 이 코드베이스에서 생산성을 낼 수 있는가"입니다.
3. 코드의 비용은 점점 더 코드를 작성하는 AI를 감독하는 비용이 되어가고 있습니다. 기질 (substrates)은 기계가 해당 환경에서 코드를 얼마나 잘 생성, 검증 및 유지 관리할 수 있는지에 따라 부분적으로 선택되어야 합니다.
4. 아키텍처는 경제적 대상입니다. 결합 구조 (coupling structure)가 변경 비용을 결정합니다. 구조를 라이브러리의 렌더 모델 (render model)로부터 물려받지 말고, 직접 선택하십시오.
5. 양방향 문 (two-way doors)을 선호하십시오. 마이그레이션 계획은 이미 비용을 지불한 상태에서도 진행 도중에 일시 중지할 수 있어야 합니다.

3. 첫 번째 기둥: 플랫폼 네이티브 코드의 TCO 곡선

대부분의 소프트웨어 비용 모델은 구축 비용(construction cost)에 집착하며 유지보수 기간(maintenance tail)을 단순히 승수(multiplier)로 취급합니다. 수명이 긴 애플리케이션의 경우, 이는 앞뒤가 바뀐 생각입니다. 유지보수 기간이야말로 본체(the animal)이기 때문입니다. 업계 경험에 따르면 평생 유지보수 비용은 초기 개발 비용의 몇 배에 달하며, 그 유지보수의 '구성(composition)'이 바로 기질(substrates)을 구분 짓는 요소입니다.

프레임워크 코드는 세 가지 유지보수 구성 요소를 수반합니다: (a) 여러분이 선택하여 수행하는 변경 사항 — 기능 추가, 버그 수정; (b) 기질이 여러분에게 강요하는 변경 사항 — 버전 마이그레이션 (version migrations), 지원 중단 (deprecations), 의존성 보안 변동 (dependency security churn), 툴체인 교체 (toolchain turnover); 그리고 (c) 기반 시설의 부채가 자산의 가치를 초과할 때 발생하는 결국 피할 수 없는 전체 재작성 (full rewrite)입니다. 플랫폼 네이티브 (Platform-native) 코드는 오직 (a)만을 수반합니다. 구성 요소 (b)는 0에 수렴하는데, 브라우저는 DOM에 파괴적 변경 사항 (breaking changes)을 배포하지 않기 때문입니다. 플랫폼의 하위 호환성 (backwards-compatibility) 기록은 수십 년에 걸쳐 있으며, 2026년에 Custom Elements와 CSS 커스텀 속성 (CSS custom properties)을 대상으로 작성된 코드는 2040년에도 수정 없이 실행될 것입니다. 구성 요소 (c) — 일정은 잡혀 있지만 날짜는 정해지지 않은 재작성 — 은 완전히 제거됩니다. 이는 정직한 장기 모델에서 가장 큰 단일 항목입니다. 다시 말해, 애플리케이션 전체 비용에 더해, 아무도 기억하지 못하는 10년 치의 미세한 결정들을 다시 찾아내야 하는 행동 고고학 (behavioral archaeology) 비용이 추가되는 것입니다.

그 결과로 나타나는 그림은 두 개의 감가상각 곡선입니다. 프레임워크 코드는 차량처럼 감가상각됩니다. 손을 대지 않더라도 생태계의 표류 (ecosystem drift)를 통해 지속적으로 가치를 잃으며, 단순히 기능을 유지하기 위해서만 주기적인 자본 투입 (메이저 버전 마이그레이션)이 필요합니다. 플랫폼 코드는 건물이 있는 토지처럼 감가상각됩니다. 건물 — 즉 여러분의 기능 — 은 여러분이 얼마나 자주 변경하느냐에 비례하여 유지보수가 필요하지만, 땅은 움직이지 않습니다. 4년의 관점에서는 두 곡선이 거의 분리되지 않으며, 프레임워크의 초기 사용성 (day-one ergonomics)이 승리합니다. 하지만 10년의 관점에서는 평탄한 곡선이 결정적으로 우세하며, 프레임워크에 관대한 가정을 하더라도 8년이 되기 훨씬 전에 교차점이 발생합니다.

바닐라(vanilla) 측면에서 고려해야 할 정직한 비용이 하나 있습니다. 플랫폼에는 내장된 반응성 모델 (reactivity model)이 없기 때문에, 사소하지 않은 모든 앱은 표준을 추적하는 얇은 레이어 — 수백 줄의 시그널 (signals) 또는 Lit과 같은 마이크로 라이브러리 (micro-library) — 를 포함하게 됩니다. 이는 여러분이 직접 책임져야 하는 유지보수 부채입니다. 하지만 이는 범위가 제한적이고 검사 가능하며, 그 아래에서 움직이지 않는 기질 (substrate) 위에 놓여 있습니다. 이는 분기별 출시 주기에 따라 수십만 줄의 코드가 변하는 프레임워크와는 근본적으로 다른 위험 범주 (risk class) 입니다.

4. 두 번째 기둥: 인력 풀은 더 작아지는 것이 아니라 더 커집니다

전통적인 반론은 다음과 같습니다: "시장은 React 개발자로 가득 차 있습니다. 바닐라와 웹 컴포넌트 (Web Components)는 틈새 시장이며, 이는 채용 깔때기를 좁히는 결과를 초래할 것입니다." 이는 실제 시장 구조를 거꾸로 해석한 것입니다.

모든 프레임워크 개발자는 자바스크립트 (JavaScript)를 작성합니다. 프레임워크는 그들이 이미 알고 있는 언어 위의 방언 (dialect)이며, DOM은 그들의 프레임워크가 궁극적으로 구동하는 기계입니다. 따라서 바닐라 코드베이스는 모든 프레임워크 커뮤니티 — React, Vue, Angular, Svelte — 의 합집합뿐만 아니라, 자바스크립트는 알지만 특정 프론트엔드 프레임워크를 전문적으로 다루지는 않는 상당수의 풀스택 및 백엔드 엔지니어들에게도 최소한 읽힐 수 있습니다. 반면 프레임워크 코드베이스는 특정 계층에게만 읽힙니다. 기업이 특정 주요 버전의 특정 프레임워크에 대한 깊은 경험을 요구하는 직무를 게시할 때, 시장을 두 번 필터링하게 됩니다. 한 번은 방언에 의해, 또 한 번은 방언의 연식 (dialect vintage)에 의해 필터링됩니다. 원칙 2는 기술적 최저선 (skill floor)을 기준으로 측정하라고 말합니다. 잘 구조화된 바닐라 코드베이스에서 한 달 안에 생산성을 낼 수 있는 엔지니어의 수는, 단일 프레임워크 코드베이스에서 생산성을 낼 수 있는 엔지니어의 수보다 엄격한 상위 집합 (superset) — 그것도 몇 배나 더 큰 규모 — 입니다.

2차적 효과(second-order effects) 또한 모두 같은 방향을 가리킵니다. 온보딩 (Onboarding) 기간이 단축됩니다. 프레임워크 특유의 방언(dialect)도, 맞춤형 상태 관리 관용구(state-management idiom)도, 습득해야 할 빌드 파이프라인의 구전 지식(folklore)도 없기 때문입니다. 학습해야 할 범위는 플랫폼 그 자체 — 즉, 모든 후보자가 커리어 내내 몸담아 온 것 — 와 여러분의 도메인뿐입니다. **기술 지속성 (Skill durability)**이 향상됩니다. 엔지니어가 바닐라 코드베이스(vanilla codebase)를 유지 관리하며 배우는 것들(DOM, 이벤트, 캡슐화, 플랫폼의 실제 계약)은 프레임워크의 시장 점유율과 함께 만료되는 것이 아니라, 커리어 전반에 걸쳐 가치가 상승합니다. 이는 부수적으로, 프레임워크의 유행 변화로 인해 피로감을 느꼈던 유능한 시니어 후보자들에게 해당 직무를 제안하기 더 쉽게 만들어 줍니다. **핵심 인력 리스크 (Key-person risk)**는 감소합니다. 유행이 변함에 따라 프레임워크 인재 풀이 얇아져서, 노후화된 스택을 유지하기 위해 희소성과 싸우며 높은 비용을 지불해야 하는 상황 — 즉, 10년의 유예 기간을 두고 다가오는 COBOL의 역학 관계 — 에 더 이상 노출되지 않습니다.

솔직한 반론도 있습니다. Shadow DOM의 세부 사항 — 슬롯 구성(slot composition), 이벤트 리타겟팅(event retargeting), ElementInternals — 에 대한 평균적인 숙련도는 주류 프레임워크의 관용구에 대한 평균 숙련도보다 확실히 낮습니다. 하지만 이를 채용 파이프라인의 구조적 확대와 대조하여, 엔지니어당 분기 단위가 아닌 주 단위의 교육 비용으로 산정해 보십시오. 이는 기꺼이 감수할 만한 가치가 있는 거래입니다.

5. 세 번째 기둥: AI 레버리지 — 작고 고정된 코퍼스(Corpus)의 승리

이제 코드의 점점 더 많은 부분이 AI의 도움으로 생성되고 있으며, 그 비중은 계속 높아지고 있습니다. 이는 "개발자 생산성"의 의미를 변화시킵니다. 제약 조건은 점점 더 인간이 코드를 얼마나 빨리 쓰느냐가 아니라, 모델이 얼마나 신뢰성 있게 생성하느냐와 인간이 얼마나 저렴하게 이를 검증하느냐로 옮겨가고 있습니다. 기저 구조(Substrate)의 선택에는 이제 AI 측면의 영향(원칙 3)이 포함되어 있으며, 세 가지 구조적 이유로 인해 이 영향은 플랫폼에 유리하게 작용합니다.

지식의 본체(body of knowledge)가 작습니다. 웹 플랫폼의 API 표면(API surface) — DOM, 이벤트(events), 커스텀 엘리먼트(Custom Elements), fetch, 현대적 CSS — 은 압축적이며 철저하게 명세(specification)되어 있습니다. 프레임워크 생태계는 이 표면에 프레임워크 자체의 거대한 API, 상태 관리(state-management) 위성 라이브러리들, 메타 프레임워크(meta-framework) 컨벤션, 그리고 현재 사용되는 주요 버전의 관용구(idioms)가 더해진 형태입니다. 프레임워크 코드를 생성하도록 요청받은 모델은 훨씬 더 큰 규모의 패턴 공간을 탐색해야 하며, 그중 상당수는 명세가 아닌 컨벤션에 기반하고 있어 그럴듯해 보이는 조합이 미묘하게 틀릴 수 있습니다.

코퍼스(Corpus)가 안정적입니다. 모델은 과거의 코드로 학습됩니다. 빠르게 변화하는 프레임워크의 경우, 그 역사는 폐기된 패턴들의 퇴적물과 같습니다. 학습 데이터는 어제의 관용구들이 지배하고 있으며, 모델은 두 단계 전 메이저 버전에서 제거된 API를 자신 있게 내뱉거나, 구식 패러다임을 신식 패러다임과 혼합하거나, 그사이 이름이 바뀐 패키지를 임포트(import)합니다. 프레임워크 코드에 AI 어시스턴트를 사용하는 사람이라면 누구나 이러한 실패 모드(failure mode)를 인지하고 있습니다. 이는 생성 속도를 검토 부담으로 변질시킵니다. 플랫폼 API는 이런 문제가 없습니다. 2016년의 올바른 패턴이 2026년에도 여전히 올바른 패턴이기 때문입니다. 학습 분포(training distribution)와 배포 현실(deployment reality)이 일치합니다. 이는 영구적인 구조적 이점으로 보입니다. 프레임워크가 움직이는 동안 플랫폼이 정지해 있음으로써 이 격차는 매년 벌어지며, 모델이 아무리 개선되더라도 이 격차를 완전히 메울 수는 없습니다. 왜냐하면 노후화(staleness)의 원인은 모델이 아니라 데이터에 있기 때문입니다.

검증 비용이 더 저렴합니다. AI가 생성한 바닐라(vanilla) 코드는 공개된 명세에 따라 확인 가능하며 디버거(debugger)에서 직접 관찰할 수 있습니다. 코드와 그 효과 사이에 리콘실러(reconciler)가 존재하지 않습니다. 반면 AI가 생성한 프레임워크 코드는 프레임워크의 시맨틱(semantics) — 훅(hooks)의 규칙, 반응성(reactivity) 주의사항, 하이드레이션(hydration) 제약 조건 — 에 대해서도 추가로 검증되어야 합니다. 이는 모델이 가장 자주 위반하고 검토자가 가장 늦게 잡아내는, 바로 그러한 비지역적(non-local)이고 컨벤션으로 인코딩된 정확성 조건들입니다.

경제적 관점에서의 해석은 다음과 같습니다. 만약 플랫폼 타겟에서 AI 보조가 '첫 시도에 정확한(correct-on-first-pass)' 코드를 유의미하게 더 자주 생성한다면 — 그리고 팀들의 일상적인 경험이 이를 뒷받침한다면 — AI 도입이 심화됨에 따라 플랫폼에서의 기능별 생산 비용은 프레임워크보다 더 빠르게 하락합니다. 프레임워크의 전통적인 장점은 인간을 위한 개발자 인체공학(developer ergonomics)이었습니다. 하지만 기계가 초안을 작성하는 체제에서는 '기계를 위한 인체공학(ergonomics-for-machines)'이 지표가 되며, 이는 정반대의 방향을 가리킵니다. 이 이점은 대칭적이기도 합니다. 프레임워크 방언(dialect)이 없는 더 작고 안정적인 코드베이스는 AI 도구가 '읽기'에 더 쉬우며, 이는 AI 보조를 통한 유지보수, 마이그레이션(migration), 온보딩(onboarding) 비용 또한 더 저렴하게 만듭니다.

6. 네 번째 기둥: 그것은 다른 아키텍처이며, 그것이 핵심입니다

프레임워크 기반의 SPA(Single Page Application)는 그 컴포넌트 구문이 무엇이든 간에, 아키텍처적으로 '중앙 집중식으로 조정되는(centrally coordinated)' 시스템입니다. 즉, 단일 리컨실러(reconciler)가 트리를 소유하고, 상태 변경(state changes)은 글로벌 스케줄러(global scheduler)를 통해 흐르며, 컴포넌트는 타인의 런 루프(run loop) 내부에서 실행되는 함수입니다. 이는 일관성(coherence)을 얻는 대신 결합(coupling)이라는 비용을 치르게 합니다. 모든 컴포넌트는 조정자(coordinator)의 시맨틱(semantics)에 결합되어 있으며, 이것이 바로 프레임워크 마이그레이션이 부분적이 아닌 전체적으로 이루어지는 정확한 이유입니다. 하나의 뇌가 몸 전체를 제어하고 있을 때는 신체의 한 부분씩만 따로 움직일 수 없습니다.