프런트엔드 프레임워크마다 상태 관리 방식이 제각각이던 시절이 있었다. 그런데 최근 몇 년, 서로 경쟁하던 진영들이 약속이나 한 듯 같은 개념으로 수렴하고 있다. 바로 시그널(Signals)이다. 리액트, 뷰, 스벨트, 솔리드, 앵귤러까지 표현은 조금씩 달라도 밑바탕의 발상은 놀랄 만큼 닮아간다.
시그널은 값이 바뀌면 그 값을 쓰는 곳만 정확히 다시 계산되도록 의존 관계를 자동으로 추적하는 반응성 기본 단위다. 쉽게 말해, "이 값이 바뀌면 화면의 어디를 갱신해야 하는지"를 개발자가 일일이 지정하지 않아도 시스템이 알아서 안다.
경쟁하던 프레임워크들이 반응성의 정답을 같은 곳에서 찾고 있다.
시그널은 "무엇이 무엇에 의존하는가"를 자동으로 추적한다.
전체를 다시 그리고 차이를 비교하던 방식에서, 바뀐 값이 닿는 곳만 정밀하게 갱신하는 방식으로 프런트엔드의 기본기가 이동하고 있다.
자동추적 의존성을 수동 선언 불필요 |
정밀갱신 닿는 노드만 다시 계산 |
수렴 5개 프레임워크 같은 방향 |
3요소 신호·파생·효과 세 축 |
왜 지금 시그널인가
지난 10년의 주류는 이른바 가상 DOM 방식이었다. 상태가 바뀌면 컴포넌트 트리를 다시 그려 새 결과를 만들고, 이전 결과와 비교해 달라진 부분만 실제 DOM에 반영한다. 개발자에게 편한 모델이었다. "상태가 곧 화면"이라는 선언적 사고를 널리 퍼뜨린 공이 크다.
하지만 이 방식에는 태생적 비용이 있다. 어디가 바뀌었는지 알려면 일단 다 그려 보고 비교해야 한다는 점이다. 앱이 커질수록 이 "다 그려 보기"가 부담이 됐고, 개발자는 불필요한 재계산을 막으려 메모이제이션 같은 수동 최적화를 여기저기 붙여야 했다. 나는 이 지점이 늘 찜찜했다. 최적화의 책임이 시스템이 아니라 사람에게 넘어와 있었기 때문이다.
시그널은 방향을 반대로 잡는다. 다 그려 보고 비교하는 게 아니라, 값과 그 값을 읽는 계산 사이의 의존 관계를 처음부터 그래프로 붙들고 있는다. 그래서 값이 바뀌면 비교 없이도 영향받는 곳을 곧바로 안다.
세 가지 구성 요소
표현은 프레임워크마다 달라도 뼈대는 대개 셋으로 정리된다.
- 신호(state) — 값을 담는 그릇. 읽으면 자신을 읽은 계산을 구독자로 기억한다.
- 파생(computed) — 다른 신호로부터 계산되는 값. 원본이 바뀔 때만 다시 계산되고 결과는 캐시된다.
- 효과(effect) — 신호가 바뀔 때 실행되는 부수 작업. 화면 갱신, 로깅, 네트워크 요청 같은 것들이 여기 붙는다.
const count = signal(0);
const doubled = computed(() => count() * 2);
effect(() => console.log(doubled()));
count.set(1); // doubled와 effect만 반응핵심은 파생과 효과가 실행 도중 읽은 신호를 스스로 기억한다는 데 있다. 개발자가 의존성 목록을 손으로 적을 필요가 없다. 이 자동 추적이 시그널의 정체성이자, 수동 최적화의 짐을 덜어 주는 지점이다.
프레임워크들의 수렴
흥미로운 건 서로 다른 출발점에서 같은 결론에 도달했다는 사실이다. 어떤 진영은 처음부터 세밀한 반응성을 내세웠고, 어떤 진영은 컴파일러로 반응성을 코드에 새겨 넣는 길을 택했으며, 또 어떤 진영은 오랜 가상 DOM 모델 위에 시그널 개념을 얹는 절충을 시도한다. 방법은 달라도 "의존성을 자동 추적해 정밀하게 갱신한다"는 목표는 공유한다.
| 항목 | 시그널 | 가상 DOM 재렌더 |
|---|---|---|
| 갱신 범위 | 의존하는 부분만 | 컴포넌트 트리 재계산 |
| 의존성 파악 | 실행 중 자동 추적 | 비교(diff)로 사후 판별 |
| 최적화 책임 | 시스템이 대부분 | 개발자 수동 메모 |
| 멘탈 모델 | 값의 흐름 그래프 | 상태→전체 재그림 |
주의할 점
장점만 있는 건 아니다. 자동 추적은 편하지만, 신호를 읽는 시점이 언제인지에 따라 구독 관계가 미묘하게 달라져 처음엔 직관과 어긋나는 순간이 있다. 비동기 경계를 넘나들 때 추적이 끊기는 상황도 조심해야 한다. 또 세밀한 반응성 그래프가 지나치게 잘게 쪼개지면 관리할 노드가 늘어 오히려 복잡해질 수 있다.
그럼에도 방향은 분명하다. 프런트엔드의 기본기가 "전부 다시 그리고 비교하기"에서 "필요한 곳만 정밀하게 반응하기"로 옮겨가는 중이고, 시그널은 그 흐름을 대표하는 이름이다. 지금 새 코드를 짠다면 어떤 프레임워크를 쓰든 이 개념에 익숙해질 가치가 충분하다.
자주 묻는 질문
시그널을 쓰면 상태 관리 라이브러리가 필요 없어지나요?
전역 상태의 상당 부분을 시그널로 자연스럽게 표현할 수 있어 별도 라이브러리 의존이 줄어드는 경향은 있다. 다만 대규모 앱의 데이터 흐름 규율이나 서버 상태 캐싱 같은 영역은 여전히 전용 도구가 도움이 된다.
가상 DOM은 이제 한물간 기술인가요?
그렇게 단정하긴 이르다. 가상 DOM은 여전히 잘 동작하고 생태계도 방대하다. 다만 세밀한 갱신이 필요한 영역에서 시그널을 함께 도입하는 절충이 늘고 있어, 두 접근이 한동안 공존할 가능성이 크다.
의존성을 자동 추적한다는 게 정확히 무슨 뜻인가요?
파생 값이나 효과가 실행되는 동안 어떤 신호를 읽었는지를 시스템이 기록해 두는 것이다. 그래서 나중에 그 신호가 바뀌면 다시 실행해야 할 대상을 개발자의 선언 없이도 정확히 알 수 있다.
기존 프로젝트에 시그널을 도입할 수 있나요?
사용하는 프레임워크가 시그널 API를 제공한다면 새로 작성하는 상태부터 점진적으로 옮길 수 있다. 성능이 민감한 화면이나 자주 갱신되는 위젯부터 적용해 보는 방식을 권한다.
댓글 0