JavaScript Signals 완전 정복: 모든 프레임워크가 Signals로 몰리는 이유 (그리고 React의 선택)

요즘 프론트엔드 생태계에서 뭔가 심상치 않은 일이 벌어지고 있어요. Angular가 Signals를 정식 도입했고, Svelte는 기존 반응형 시스템을 통째로 갈아엎고 Runes를 만들었고, Solid.js는 처음부터 Signals 위에 설계됐죠. Vue의 Composition API? 사실 내부적으로는 Signal이나 다름없었고요. Qwik, Preact, 심지어 Ember까지 전부 같은 방향으로 수렴하고 있어요.

그런데 시장 점유율 1위인 React만 정반대 길을 가고 있거든요. Signals를 안 쓰고, 컴파일러로 성능 문제를 해결하겠다는 거예요.

여기에 TC39 Signals 제안까지 표준화 과정을 밟고 있어요. 이게 통과되면 Signals는 프레임워크 기능이 아니라 Promise나 Array처럼 JavaScript 언어 자체의 기능이 되는 거예요.

Virtual DOM이 등장한 지 10년이 넘었는데, 그 이후로 프론트엔드 아키텍처 최대의 전환점이에요. 실제로 무슨 일이 벌어지고 있는지, 왜 중요한지, 지금 쓰는 코드에 어떤 영향이 있는지 하나씩 까보겠습니다.

---

Signal이 정확히 뭔가요?

프레임워크별 API를 다 걷어내고 본질만 보면, Signal은 놀라울 정도로 단순해요: 값이 바뀌면 의존하는 곳에 자동으로 알려주는 반응형 값 박스.

쉽게 말하면, 의존성 추적이 자동으로 되는 Observable 변수예요. 어떤 계산 안에서 Signal을 읽으면 런타임이 의존 관계를 기억하고, Signal 값이 바뀌면 실제로 그 값에 의존하는 계산만 다시 실행되는 구조죠.

// 반응형 값 생성
const count = signal(0);

// 파생 상태 — 의존성 자동 추적
const doubled = computed(() => count.value * 2);

// 사이드 이펙트 — 의존하는 값이 바뀔 때만 재실행
effect(() => {
  console.log(`Count: ${count.value}, doubled: ${doubled.value}`);
});

// count에 의존하는 것들만 재실행
count.value = 5;
// 콘솔: "Count: 5, doubled: 10"

의존성 배열 없음. 수동 구독 관리 없음. 디핑 알고리즘도 없음. 런타임이 누가 누구에 의존하는지를 실행 시점에 관찰해서 알아내니까요.

세 가지 핵심 프리미티브

어떤 프레임워크든 Signals 구현은 세 가지 프리미티브로 이루어져 있어요:

1. Signal (상태) — 하나의 값을 담는 반응형 컨테이너.

const name = signal("Alice");
console.log(name.value); // "Alice"
name.value = "Bob";      // 의존하는 곳에 알림

2. Computed (파생 상태) — 하나 이상의 Signal에서 파생된 값이에요. Lazy하게 동작하니까, 읽힐 때만, 그것도 의존성이 실제로 바뀌었을 때만 재계산하죠.

const firstName = signal("Alice");
const lastName = signal("Smith");

const fullName = computed(() => `${firstName.value} ${lastName.value}`);
// fullName은 읽힐 때 + 의존성이 바뀌었을 때만 재계산

3. Effect (사이드 이펙트) — 추적된 의존성이 바뀔 때 실행되는 함수. DOM 업데이트, 네트워크 요청, 로깅 등을 여기서 해요.

effect(() => {
  document.title = fullName.value; // fullName이 바뀔 때만 재실행
});

이 세 가지가 전부예요. 이제 속을 까봅시다.

---

Signals는 내부적으로 어떻게 동작할까요?

Signals의 진짜 핵심은 API가 아니라 자동 의존성 추적이에요. 원리를 제대로 이해하려면 직접 만들어보는 게 빠르죠. 아주 간단한 Signals 런타임을 처음부터 구현해 봅시다.

의존성 그래프

Signals 런타임의 내부에는 방향성 비순환 그래프(DAG)가 있어요:

┌─────────┐     ┌─────────┐
│ signal A │────▶│computed C│────▶ effect E
└─────────┘     └─────────┘
┌─────────┐        ▲
│ signal B │────────┘
└─────────┘

Signal A가 바뀌면 런타임이 그래프를 따라가면서 Computed C와 Effect E만 재실행해요. Signal B의 다른 의존자들은 건드리지도 않아요.

50줄로 구현하는 Signals

실제로 동작하는 Signals를 ~50줄 JavaScript로 만들 수 있어요:

let currentObserver = null;

function signal(initialValue) {
  let value = initialValue;
  const subscribers = new Set();

  return {
    get value() {
      // 추적: 누군가 관찰 중이면 이 signal을 등록
      if (currentObserver) {
        subscribers.add(currentObserver);
      }
      return value;
    },
    set value(newValue) {
      if (newValue === value) return; // 같으면 스킵
      value = newValue;
      // 알림: 모든 구독자 재실행
      for (const subscriber of subscribers) {
        subscriber();
      }
    }
  };
}

function computed(fn) {
  let cachedValue;
  let dirty = true;

  const computation = () => { dirty = true; };

  return {
    get value() {
      if (dirty) {
        const prevObserver = currentObserver;
        currentObserver = computation;
        cachedValue = fn();
        currentObserver = prevObserver;
        dirty = false;
      }
      return cachedValue;
    }
  };
}

function effect(fn) {
  const execute = () => {
    const prevObserver = currentObserver;
    currentObserver = execute;
    fn();
    currentObserver = prevObserver;
  };
  execute(); // 즉시 실행해서 의존성 수립
}

핵심 기법은 글로벌 옵저버 스택 (currentObserver)이에요. Computed나 Effect가 실행될 때 자신을 현재 옵저버로 설정해요. 실행 중에 읽히는 Signal은 자동으로 옵저버를 구독자 목록에 추가해요. 그래서 의존성을 수동으로 선언할 필요가 전혀 없는 거예요.

프로덕션 수준의 최적화

물론 프로덕션 구현체는 여기서 훨씬 더 나가요. 몇 가지 핵심 최적화가 들어가거든요:

1. Push-Pull 평가 — Signal이 바뀌면 하위 Computed를 "dirty"로 표시만 하고(push), 실제로 값이 읽힐 때만 재계산(pull)하는 방식이에요. 큰 그래프에서 불필요한 연산을 완전히 없앨 수 있죠.

2. Glitch-Free 실행 — Signal A와 B가 같은 마이크로태스크에서 둘 다 바뀌면, 둘에 의존하는 Computed가 한 번만 실행돼야 해요. 위상 정렬이나 배칭으로 일관성을 보장해요.

const a = signal(1);
const b = signal(2);
const sum = computed(() => a.value + b.value);

batch(() => {
  a.value = 10;
  b.value = 20;
});
// sum은 (10, 20)으로 딱 한 번만 실행

3. 자동 정리 — Effect가 재실행되면 이전 의존성 구독이 자동으로 해제되고 새로 수립돼요. 메모리 누수 방지.

4. 동일값 체크 — 새 값이 이전 값과 같으면(Object.is 기본) 알림 자체를 스킵해서 불필요한 하위 업데이트를 막아요.

---

TC39 Signals 제안: 언어 표준이 되는 Signals

가장 흥미로운 건 프레임워크 안에서 벌어지는 일이 아니라 언어 수준에서 벌어지는 일이에요. TC39 Signals 제안은 반응형 프리미티브를 JavaScript 표준에 넣으려 하고 있어요.

왜 표준화가 필요할까요?

모든 프레임워크가 자체 Signals 구현을 갖고 있어요. Angular Signals랑 Solid의 createSignal은 서로 호환이 안 돼요. Preact Signals로 만든 날짜 선택기 라이브러리를 Vue 앱에서 쓰려면 래퍼가 필요해요.

TC39 제안은 모든 프레임워크가 위에 쌓을 수 있는 표준 Signal API로 이 문제를 해결해요:

// TC39 제안 API (Stage 1, 변경 가능)
const counter = new Signal.State(0);
const isEven = new Signal.Computed(() => (counter.get() & 1) === 0);

// 프레임워크들은 자체적으로 편리한 API를 감싸지만
// 내부 반응형 그래프는 공유됨

제안이 제공하는 것

제안은 렌더링이 아니라 반응형 그래프 알고리즘에 집중해요:

• Signal.State — 읽기/쓰기 가능한 반응형 값
• Signal.Computed — 파생된 반응형 값 (lazy, 캐시)
• Signal.subtle.Watcher — 프레임워크 통합을 위한 로우레벨 API

중요한 점: 제안에 effect()는 포함되지 않아요. DOM 업데이트, 렌더 스케줄링, 변경 배칭은 프레임워크마다 다르니까요. 표준은 반응형 그래프 프리미티브만 제공해요.

상호운용성의 미래

이런 미래를 상상해 보세요:

• 차트 라이브러리가 Signal.State를 내부적으로 사용
• Angular 앱에서 Angular Signals(Signal.State 기반)로 그 라이브러리를 사용
• 동료는 같은 라이브러리를 Solid 앱에서 사용
• 반응형 그래프가 공유되니까 자연스럽게 연동

프레임워크에 상관없이 모든 반응형 상태가 호환되는 세상. 이게 TC39 표준화가 꿈꾸는 미래예요.

---

프레임워크별 Signals 현황

Angular Signals (v17+)

RxJS와 Zone.js, 변경 감지로 유명하던 Angular가 Signals를 도입한 건 정말 큰 사건이었어요:

import { signal, computed, effect } from '@angular/core';

@Component({
  template: `
    <h1>{{ fullName() }}</h1>
    <button (click)="updateName()">이름 변경</button>
  `
})
export class UserComponent {
  firstName = signal('Alice');
  lastName = signal('Smith');

  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);

  logger = effect(() => {
    console.log(`이름 변경됨: ${this.fullName()}`);
  });

  updateName() {
    this.firstName.set('Bob');
  }
}

핵심 변화가 뭐냐면, Angular가 이제 변경 감지에 Zone.js 없이도 되거든요. 모든 이벤트마다 전체 컴포넌트 트리를 dirty-checking 하는 대신, 바뀐 Signal에 바인딩된 특정 DOM 노드만 업데이트하는 거죠. 실제 벤치마크에서 렌더링 속도 30-50% 향상을 보이고 있어요.

Solid.js — 처음부터 Signals

Solid.js는 Signals가 프로덕션급 UI 프레임워크를 구동할 수 있다는 걸 증명한 프레임워크예요:

import { createSignal, createMemo, createEffect } from "solid-js";

function Counter() {
  const [count, setCount] = createSignal(0);
  const doubled = createMemo(() => count() * 2);

  createEffect(() => {
    console.log(`Count: ${count()}, Doubled: ${doubled()}`);
  });

  return (
    <button onClick={() => setCount(c => c + 1)}>
      {count()} × 2 = {doubled()}
    </button>
  );
}

React와 결정적 차이: Solid는 컴포넌트를 다시 실행하지 않아요. Counter 함수는 딱 한 번만 실행돼요. JSX는 특정 Signal을 구독하는 세밀한 DOM 업데이트 명령으로 컴파일돼요. count가 바뀌면 count()와 doubled()를 표시하는 텍스트 노드만 업데이트되고, 컴포넌트 함수 자체는 절대 다시 실행 안 돼요.

Virtual DOM 디핑도 없고, 리렌더링도 없고, 메모이제이션이 필요한 적도 없어요.

Svelte Runes (v5)

Svelte 5는 기존 $: 레이블 기반 반응성을 Runes로 완전히 교체했어요. 본질적으로 컴파일 타임 Signals예요:

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);

  $effect(() => {
    console.log(`Count: ${count}, Doubled: ${doubled}`);
  });
</script>

<button onclick={() => count++}>
  {count} × 2 = {doubled}
</button>

Runes의 우아한 점은 일반 변수처럼 보인다는 거예요. 컴파일러가 $state, $derived, $effect를 내부 Signal 프리미티브로 변환하지만, 개발자 경험은 그냥 평범한 JavaScript를 쓰는 느낌이에요.

Vue Composition API

Vue는 사실 Composition API(Vue 3)부터, 내부적으로는 Vue 2의 Object.defineProperty부터 Signal 같은 반응형 시스템을 써왔어요:

<script setup>
import { ref, computed, watchEffect } from 'vue';

const count = ref(0);
const doubled = computed(() => count.value * 2);

watchEffect(() => {
  console.log(`Count: ${count.value}, Doubled: ${doubled.value}`);
});
</script>

<template>
  <button @click="count++">
    {{ count }} × 2 = {{ doubled }}
  </button>
</template>

Vue의 ref가 Signal이고, computed가 Computed고, watchEffect가 Effect예요. 이름만 다르지 내부 반응형 그래프는 구조적으로 동일해요. Vue가 Signals 유행 전부터 Signals를 하고 있었던 거예요.

Preact Signals

Preact는 좀 다른 방식으로 접근했어요. Virtual DOM에 통합되는 별도 라이브러리로 Signals를 추가한 거죠:

import { signal, computed } from "@preact/signals";

const count = signal(0);
const doubled = computed(() => count.value * 2);

function Counter() {
  return (
    <button onClick={() => count.value++}>
      {count} × 2 = {doubled}
    </button>
  );
}

Preact Signals의 특별한 점: JSX에 Signal을 직접 전달할 수 있어요 ({count.value} 대신 {count}). Preact가 DOM 수준에서 직접 구독해서 해당 노드에 한해 Virtual DOM 디핑을 완전히 건너뛰어요. React 같은 컴포넌트 모델을 유지하면서 Solid에 가까운 성능을 내는 거예요.

---

React의 다른 선택: Hooks + 컴파일러 vs. Signals

여기서부터 논쟁이 뜨거워지는데요. 모든 주요 프레임워크가 Signals로 수렴하는데, React만 안 하거든요. 왜 그런지 까보면 근본적인 철학 차이가 드러나요.

React 팀의 Signals 반대 논리

1. 하향식 데이터 흐름 — React는 컴포넌트가 props와 state의 함수라는 설계 철학 위에 있어요. setState 호출 → 컴포넌트 재실행 → React가 결과를 비교. Signals는 DOM 노드를 직접 업데이트하니까 이 모델을 깨뜨리는 거예요.

2. 디버그 편의성 — React 모델에서는 아무 컴포넌트에 브레이크포인트를 걸면 매 상태 변경마다 전체 렌더를 볼 수 있어요. Signals는 세밀하게 업데이트되니까 "렌더 사이클"이라는 개념이 없어요. React 팀은 이게 디버깅을 어렵게 한다고 주장해요.

3. 컴파일러 베팅 — React의 입장은 컴파일러가 프로그래밍 모델을 바꾸지 않고도 Signal 수준의 성능을 달성할 수 있다는 거예요.

반론들

근데 반론도 만만치 않죠:

1. 근본적인 오버헤드 — 완벽한 메모이제이션을 해도 React는 여전히 컴포넌트 함수를 재실행하고 Virtual DOM 트리를 디핑해야 해요. Signals는 이 두 단계를 통째로 건너뛰죠. 컴파일러로는 깨뜨릴 수 없는 성능 천장이 있는 거예요.

React (컴파일러 적용 후):
  상태 변경 → 컴포넌트 함수 재실행 → vDOM 디핑 → DOM 패치

Signals:
  상태 변경 → DOM 직접 패치

// "재실행 + 디핑" 단계는 아무리 최적화해도 비용이 0이 아님

2. 런타임 비용 — React Compiler의 메모이제이션은 런타임 오버헤드(캐시 조회, 매 메모이제이션 값마다의 동일성 체크)를 추가해요. Signals는 값이 실제로 바뀔 때만 작업해요.

3. "React의 규칙" — 컴파일러는 코드가 "React의 규칙"(순수 컴포넌트, 렌더 중 뮤테이션 금지, 올바른 Hook 순서)을 따라야 해요. 위반하면 성능 문제가 아니라 정확성 버그가 조용히 생겨요. Signals에는 이런 제약이 없어요.

4. 생태계 파편화 — TC39가 Signals를 표준화하면 React 빼고 모든 프레임워크가 공통 반응형 프리미티브를 공유하게 돼요. React 컴포넌트만 외톨이가 되는 거예요.

성능 비교

실제 벤치마크를 한번 봐요. js-framework-benchmark(프레임워크 성능 표준화 스트레스 테스트)의 공개 결과를 기반으로 한 10,000행 테이블 대략적인 수치예요:

작업	React 19 + Compiler	Solid.js (Signals)	Angular (Signals)	Svelte 5 (Runes)
10k 행 생성	~420ms	~190ms	~230ms	~200ms
10행마다 업데이트	~80ms	~18ms	~25ms	~20ms
행 2개 스왑	~45ms	~12ms	~15ms	~14ms
행 선택	~8ms	~2ms	~3ms	~2ms
행 삭제	~38ms	~6ms	~9ms	~7ms
메모리 (생성 후)	~9 MB	~4 MB	~4.5 MB	~3.5 MB

참고: 이 수치는 공개된 벤치마크 트렌드를 기반으로 한 근사값이에요. 실제 수치는 하드웨어, 브라우저, 프레임워크 버전에 따라 달라요. 최신 결과는 js-framework-benchmark에서 확인하세요.

패턴이 극명해요: Signals 기반 프레임워크가 React 컴파일러 최적화 대비 대부분의 작업에서 대략 2~4배 빨라요. 메모리 차이는 더 극적인데, Signals는 Virtual DOM 트리를 유지할 필요가 없어서 그래요.

---

실전: 지금 내 스택에 Signals 도입하기

지금 당장 Signals를 도입하고 싶다면, 현재 쓰는 프레임워크에 따라 실용적인 경로가 있어요.

Angular를 쓰고 있다면

이미 거기 있어요. Angular 17+ Signals는 프로덕션 레디예요. RxJS 중심 패턴에서 마이그레이션을 시작하세요:

// Before: RxJS Observables
@Component({...})
export class UserComponent implements OnInit, OnDestroy {
  user$!: Observable<User>;
  private destroy$ = new Subject<void>();

  ngOnInit() {
    this.user$ = this.userService.getUser().pipe(
      takeUntil(this.destroy$)
    );
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

// After: Angular Signals + resource API
@Component({...})
export class UserComponent {
  userId = input.required<string>();
  user = resource({
    request: () => this.userId(),
    loader: ({ request: id }) => this.userService.getUser(id)
  });
}

구독 관리도 필요 없고, takeUntil 패턴도 없고, OnDestroy 정리도 없어요.

React를 쓰고 있다면 (Preact Signals 활용)

React에서도 @preact/signals-react를 통해 Signals를 쓸 수 있어요:

import { signal, computed } from "@preact/signals-react";

const count = signal(0);
const doubled = computed(() => count.value * 2);

function Counter() {
  return (
    <div>
      <p>{count.value} × 2 = {doubled.value}</p>
      <button onClick={() => count.value++}>증가</button>
    </div>
  );
}

주의: 서드파티 통합이라 React 렌더 사이클에 훅으로 연결해서 동작하는 방식이에요. 네이티브 Signals처럼 vDOM을 완전히 바이패스하진 못하지만, useMemo/useCallback 수동으로 일일이 쓰는 고통에서는 벗어날 수 있죠.

새 프로젝트를 시작한다면

2026년에 프레임워크를 새로 고르는데 성능이 중요하다면:

1. Solid.js — 최고 성능, 최소 번들 크기, 가장 "순수한" Signals 경험
2. Svelte 5 — 최고의 개발자 경험 (Runes가 일반 JS처럼 보임), 우수한 성능
3. Angular — 대규모 엔터프라이즈 팀에 최적 (TypeScript 네이티브, 종합 툴체인)
4. Vue — 성능과 생태계 성숙도의 균형

---

실전 예제: 반응형 폼 밸리데이션

Signals가 실제로 어떻게 동작하는지 실용적인 예제를 만들어 봅시다.

Vanilla Signals (TC39 제안 스타일)

const email = new Signal.State("");
const password = new Signal.State("");

const emailError = new Signal.Computed(() => {
  const value = email.get();
  if (!value) return "이메일을 입력해주세요";
  if (!value.includes("@")) return "이메일 형식이 올바르지 않아요";
  return null;
});

const passwordStrength = new Signal.Computed(() => {
  const value = password.get();
  if (value.length === 0) return "empty";
  if (value.length < 8) return "weak";
  if (/(?=.*[A-Z])(?=.*[0-9])(?=.*[!@#$%])/.test(value)) return "strong";
  return "medium";
});

const isFormValid = new Signal.Computed(() => {
  return emailError.get() === null
    && passwordStrength.get() !== "weak"
    && passwordStrength.get() !== "empty";
});

// 이 파생 그래프가 자동으로 업데이트돼요:
// email 변경 → emailError 재계산 → isFormValid 재계산
// password 변경 → passwordStrength 재계산 → isFormValid 재계산
// 수동 의존성 연결 불필요

Solid.js 구현

import { createSignal, createMemo, Show } from "solid-js";

function SignupForm() {
  const [email, setEmail] = createSignal("");
  const [password, setPassword] = createSignal("");

  const emailError = createMemo(() => {
    const value = email();
    if (!value) return "이메일을 입력해주세요";
    if (!value.includes("@")) return "이메일 형식이 올바르지 않아요";
    return null;
  });

  const passwordStrength = createMemo(() => {
    const value = password();
    if (value.length === 0) return "empty";
    if (value.length < 8) return "weak";
    if (/(?=.*[A-Z])(?=.*[0-9])(?=.*[!@#$%])/.test(value)) return "strong";
    return "medium";
  });

  const isValid = createMemo(() =>
    emailError() === null && !["weak", "empty"].includes(passwordStrength())
  );

  return (
    <form>
      <input
        type="email"
        value={email()}
        onInput={(e) => setEmail(e.target.value)}
        classList={{ error: !!emailError() }}
      />
      <Show when={emailError()}>
        <span class="error">{emailError()}</span>
      </Show>

      <input
        type="password"
        value={password()}
        onInput={(e) => setPassword(e.target.value)}
      />
      <div class={`strength-${passwordStrength()}`}>
        강도: {passwordStrength()}
      </div>

      <button disabled={!isValid()}>가입하기</button>
    </form>
  );
}

사용자가 이메일 필드에 타이핑하면:

1. email Signal만 변경
2. emailError만 재계산 (passwordStrength는 안 함)
3. isValid만 재계산
4. emailError()와 isValid()에 바인딩된 DOM 노드만 업데이트

비밀번호 입력, 강도 표시기, 기타 모든 DOM 노드는 전혀 건드리지 않아요. React였다면 컴포넌트 함수 전체가 재실행되고, 모든 JSX 표현식이 재평가되고, React가 전체 Virtual DOM 서브트리를 디핑했을 거예요.

---

프론트엔드가 향하는 방향

Signals로의 수렴은 우연이 아니에요. 여러 힘이 동시에 작용하고 있거든요:

1. Virtual DOM의 성능 한계

Virtual DOM 디핑은 2013년에는 천재적인 아이디어였죠. 그때는 JavaScript 엔진이 느렸고 DOM 조작이 비쌌으니까요. 근데 2026년 기준으로 JavaScript 엔진은 엄청나게 빨라졌고, 오히려 "가상 트리 생성 → 디핑 → 패치"의 오버헤드가 DOM 자체보다 병목이 되는 상황이에요.

Signals는 중간 단계를 없애요. 상태 변경 → DOM 업데이트. 디핑 단계 없음.

2. Islands 아키텍처의 부상

Astro, Qwik, 심지어 Next.js(RSC)까지 정적 HTML 바다 속 인터랙티브 "섬" 모델로 이동하고 있어요. Signals는 각 Island가 페이지의 나머지에 영향 없이 자체 로컬 반응형 그래프를 가질 수 있어서 딱 맞아요.

3. TC39의 엔드게임

Signal.State와 Signal.Computed가 JavaScript 표준이 되면:

• 그 위에 만들어진 모든 프레임워크가 자동으로 상호운용
• 브라우저 엔진이 네이티브 수준에서 반응형 그래프를 최적화 가능
• 서드파티 라이브러리(날짜 선택기, 폼 라이브러리, 상태 관리)가 범용 반응형 프리미티브를 사용

상태 관리의 "프레임워크 종속" 시대가 끝나는 거예요.

---

정리하면

프론트엔드 세계에 리액티비티 혁명이 진행 중이에요. Signals는 React가 대중화한 Virtual DOM 디핑 방식보다 근본적으로 더 효율적인 UI 상태 관리 모델이라는 걸 증명했어요.

React를 제외한 모든 주요 프레임워크가 Signals를 도입했어요. TC39 제안은 JavaScript 자체에 표준화하려 하고 있어요. Angular는 마이그레이션 후 30-50% 렌더링 개선을 봤고, Solid.js는 표준 벤치마크에서 React 대비 2-4배 성능을 보여줘요.

React의 컴파일러 베팅은 과감하고 격차를 줄일 수도 있지만, 컴포넌트 재실행과 Virtual DOM 디핑의 근본적 오버헤드를 없앨 수는 없어요. React가 결국 Signals를 도입하든, 컴파일러 접근이 우월하다는 걸 증명하든, 이 경쟁이 전체 생태계를 더 좋게 만들고 있어요.

어떤 프레임워크를 쓰고 있든 Signals를 이해하는 건 이제 선택이 아니라 필수예요. 반응형 그래프가 프론트엔드 상태 관리의 미래이고, 이미 여기 와 있어요.