Signal이 대체 뭐길래? 프론트엔드를 뒤흔드는 Push-Pull 반응형 알고리즘 파헤치기

요즘 프론트엔드에서 자꾸 들리는 'Signal'

혹시 최근에 프론트엔드 관련 글을 읽다가 "Signal"이라는 단어를 자주 마주치지 않으셨나요? Angular, Solid.js, Preact, 심지어 Vue까지—요즘 거의 모든 프론트엔드 프레임워크가 Signal을 도입하거나 Signal 기반으로 재설계하고 있거든요. 그런데 막상 "Signal이 뭔데?"라고 물으면 명쾌하게 답하기 어려운 분들이 많을 거예요. 오늘은 Signal의 핵심인 Push-Pull 기반 알고리즘이 어떻게 동작하는지, 기존 방식과 뭐가 다른지를 최대한 쉽게 풀어볼게요.

먼저, 반응형(Reactivity)이 뭔지부터

반응형이란 쉽게 말해서 "데이터가 바뀌면 화면도 알아서 바뀌는 것"이에요. 엑셀을 떠올려 보세요. A1 셀에 숫자를 넣고, B1 셀에 =A1*2라는 수식을 넣으면, A1 값을 바꿀 때마다 B1이 자동으로 업데이트되잖아요. 웹 프론트엔드에서도 똑같은 걸 하고 싶은 거예요. 사용자 이름이 바뀌면 화면에 표시된 이름도 자동으로 바뀌어야 하니까요.

기존에 React는 이걸 Virtual DOM 비교(diffing) 방식으로 해결했어요. 상태가 바뀌면 컴포넌트 전체를 다시 렌더링하고, 이전 결과와 새 결과를 비교해서 달라진 부분만 실제 DOM에 반영하는 거죠. 이 방식은 직관적이지만, 바뀌지 않은 부분까지 매번 다시 계산한다는 비효율이 있어요.

Signal의 핵심: Push도 아니고 Pull도 아닌, Push-Pull

반응형 시스템을 설계하는 방법은 크게 두 가지가 있어요.

Push 방식은 데이터가 바뀌는 순간 즉시 모든 의존 대상에게 새 값을 밀어넣는 거예요. 카카오톡 알림처럼, 메시지가 오면 바로 푸시 알림이 뜨는 것과 비슷해요. 장점은 항상 최신 상태를 유지한다는 건데, 단점은 중간 단계가 많으면 불필요한 계산이 연쇄적으로 발생할 수 있다는 거예요. 예를 들어 A → B → C → D로 이어지는 의존 체인에서, A가 바뀌면 B, C, D가 순서대로 전부 다시 계산되는데, 최종적으로 D만 화면에 보여준다면 B와 C의 계산은 낭비인 거죠.

Pull 방식은 반대로, 값이 필요한 시점에 가서 가져오는 거예요. 냉장고에서 음료를 꺼내 마시는 것처럼, 목마를 때 직접 가서 확인하는 방식이에요. 불필요한 계산은 줄어들지만, 값이 바뀌었는지 아닌지를 매번 확인해야 하는 오버헤드가 생겨요.

Signal이 채택한 Push-Pull 방식은 이 둘의 장점을 합친 거예요. 작동 원리를 단계별로 설명하면 이래요. 먼저 소스 데이터가 바뀌면 "나 바뀌었어!"라는 알림(notification)만 Push해요. 실제 새 값을 계산하지는 않아요. 그냥 "더러워졌다(dirty)"는 표시만 전파하는 거죠. 그다음, 실제로 그 값을 읽으려는 곳(예: 화면을 그리는 코드)에서 필요한 시점에 Pull해서 값을 계산해요. 이렇게 하면 중간 단계의 불필요한 계산을 건너뛸 수 있고, 동시에 값이 바뀌었다는 사실은 즉시 알 수 있어요.

그래프로 이해하는 Signal

Signal 시스템은 내부적으로 방향 비순환 그래프(DAG)를 구성해요. 이게 뭐냐면, 데이터 간의 의존 관계를 그래프로 표현한 건데요. 예를 들어볼게요.

firstName과 lastName이라는 두 개의 Signal이 있고, fullName은 이 둘을 합친 Computed Signal이고, 화면에 표시하는 Effect가 fullName을 구독하고 있다면, 이런 그래프가 만들어져요: firstName → fullName → 화면 렌더링, lastName → fullName → 화면 렌더링.

firstName이 바뀌면, Signal 시스템은 이 그래프를 따라 "dirty" 플래그만 전파해요. 그리고 다음 렌더링 사이클에서 화면을 그릴 때, fullName의 값을 Pull 방식으로 요청하면 그제야 새 값을 계산하는 거죠. 만약 firstName이 짧은 시간 안에 여러 번 바뀌더라도, 실제 계산은 마지막에 한 번만 일어나요. 이게 바로 Push-Pull의 힘이에요.

기존 방식과 뭐가 다른가요?

React의 useState + Virtual DOM 방식과 비교하면 차이가 확연해요. React는 상태가 바뀌면 해당 컴포넌트와 하위 컴포넌트를 통째로 다시 실행하거든요. useMemo나 React.memo로 최적화할 수 있지만, 이건 개발자가 직접 "여기는 다시 계산하지 마"라고 명시해야 하는 거라 번거롭죠.

Signal은 이런 수동 최적화가 필요 없어요. 의존 관계를 시스템이 자동으로 추적하니까, 정확히 바뀐 부분만 알아서 업데이트돼요. 이걸 세밀한 반응성(fine-grained reactivity)이라고 부르는데, Solid.js가 이 방식의 선두주자예요.

Vue의 ref와 computed도 사실 Signal과 거의 같은 개념이에요. Vue 3의 반응형 시스템이 이미 Push-Pull 하이브리드 방식으로 동작하고 있었거든요. Angular도 v16부터 Signal을 도입했고, Svelte 5의 Runes도 컴파일 타임 Signal이라고 볼 수 있어요.

한국 개발자에게 이게 왜 중요한가요?

솔직히 지금 당장 프로덕션 코드를 Signal로 바꿔야 하는 건 아니에요. 하지만 프론트엔드 생태계 전체가 Signal 방향으로 수렴하고 있다는 흐름은 알아두는 게 좋아요. React도 이런 흐름을 의식해서 React Compiler를 만들고 있고, 내부적으로 세밀한 반응성에 가까운 최적화를 자동으로 해주려 하고 있거든요.

지금 할 수 있는 건 이런 거예요. Solid.js나 Angular Signal로 간단한 사이드 프로젝트를 만들어보면서 감을 잡는 거죠. Vue를 쓰고 계신 분들은 이미 Signal과 비슷한 모델 위에서 작업하고 있으니, 원리를 이해하면 computed나 watch를 더 효과적으로 쓸 수 있어요.