이벤트는 프론트엔드 시스템에 필수적인 입력이다. 그러나 반응을 아키텍처로 오해하면 복잡성에 매몰된다. 초점을 옮겨 상태에 집중해야 한다.

이벤트는 현대 프론트엔드 시스템에 필수적인 입력이다. 그러나 반응을 아키텍처로 오해하면 소리소문 없이 복잡성이 증식한다. 시간이 지나면서 많은 프론트엔드 아키텍처가 구조의 모델보다는 반응의 사슬을 닮아갔고 그 결과 시스템의 표현력은 높아졌지만 시스템을 추론하기는 점점 더 어려워졌다.

다른 아키텍처 관점이 새롭게 부상하는 중이다. 일부에서 반응의 사슬을 중심으로 시스템을 구성하는 대신 애플리케이션 상태를 시스템의 기본 구조로 다루기 시작했다. 이 모델에서도 이벤트는 여전히 발생한다. 다만 더 이상 아키텍처를 정의하지 않고 상태만 수정한다. UI와 파생된 동작은 이런 관계를 따른다.

상태 우선 프론트엔드 아키텍처로의 이 전환은 갈수록 더 복잡해지는 애플리케이션에 대해 추론하기 위한 더 명확한 방법을 제공한다.

반응이 기본값일 때

프론트엔드 엔지니어링은 이벤트를 기반으로 작동한다. 사용자 상호작용, 네트워크 응답, 타이머, 스트리밍 데이터가 끊임없이 애플리케이션으로 들어오고, 시스템은 이에 응답하도록 설계된다. 이벤트는 피할 수 없다. 이벤트는 외부 세계에서 무엇인가가 변하는 순간을 나타낸다. 당연히 이벤트를 취급하는 방법도 매우 정교해졌다. 스트림을 구성하고 부수적 효과를 조율하고 업데이트를 보내고 점점 더 표현력이 풍부한 반응형 파이프라인을 구축한다. 이런 흐름을 규칙에 입각해 예측 가능한 방식으로 구조화하기 위한 생태계가 만들어져 발전했다.

애플리케이션이 더 동적으로, 더 상태적으로 발전하는 만큼 그 정교함은 당연하면서 필요한 것으로 느껴졌다. 그러나 이 과정에서 우리는 이벤트 처리를 단순한 메커니즘이 아니라 아키텍처 자체로 취급하기 시작했다. 시스템을 주로 이벤트와 반응의 관점에서 생각하기 시작했다. 이 미묘한 변화로 인해 시스템에 대해 추론하는 방식이 바뀌었다. 무엇이 사실인지보다는 시스템이 어떻게 반응하는지에 대한 모델링에 치중하게 됐다.

바로 이 부분에서 복잡성이 조용히 쌓이기 시작했다.

리덕스와 구조화된 변화의 시대

현대 프론트엔드 아키텍처에서 가장 큰 영향을 미친 사건 중 하나는 리덕스(Redux)의 등장이다. 리덕스는 설득력 있는 규칙을 도입했다. 상태는 중앙에 집중돼야 하고 업데이트는 예측 가능해야 하며 변경은 단방향으로 흘러야 한다는 규칙이다. 이에 따라 개발자는 값을 암시적으로 변경하는 대신 명시적인 액션을 디스패치했고 리듀서는 새로운 상태를 결정론적으로 계산했다.

혼돈이었던 곳에 리덕스가 구조를 들고 나타난 것이다. 리덕스는 상태 전환을 명시적이고 추적 가능하게 하는 규칙을 도입했고, 그 결과 디버깅이 더 체계화되고 애플리케이션 동작에 대해 추론하기가 더 쉬워졌다.

더 중요한 점은 리덕스가 프론트엔드 시스템에 대한 특정 사고방식을 정규화했다는 점이다. 중앙화된 저장소, 액션 디스패치, 부수 효과 계층, 명시적인 업데이트 흐름이 아키텍처의 기본값이 됐다. 프레임워크와 라이브러리 전반에 걸쳐 이 모델의 여러 변형이 나타나면서 사용 중인 특정 툴과 관계없이 애플리케이션을 구조화하는 방식에 영향을 미쳤다.

구현이 다르다 해도 기반이 되는 전제는 일관적이다. 아키텍처의 핵심은 이벤트가 시스템을 이동하는 방식을 제어한다는 데 있다는 점이다. 이는 규칙에서 중대한 진전이었다. 그러나 이와 동시에 반응을 중심으로 정신 모델을 구성하는, 사람들의 뿌리깊은 습관을 더 강화하기도 했다.

이벤트는 입력이지만 아키텍처는 구조

이벤트는 방금 무슨 일이 일어났는지, 예를 들어 사용자가 버튼을 클릭하거나 요청이 완료되거나 값이 변경됐음을 알려준다. 아키텍처는 이와 달리 “지금 무엇이 사실인가?”라는 질문에 답한다.

이벤트는 일시적이다. 시간상의 순간들을 설명한다. 아키텍처는 그러한 순간을 넘어 지속되는 관계를 정의한다. 시스템이 이벤트를 중심으로 구성되면 동작은 반응의 사슬로 모델링되는 경우가 많다. 이 디스패치가 저 업데이트를 트리거하고, 그것이 또 다른 재계산을 일으키고, 그 재계산이 다른 곳의 구독자에게 알림을 보내는 식이다.

규모가 작은 시스템에서는 이 사슬을 쉽게 따라갈 수 있지만 규모가 큰 시스템에서는 동작을 이해하기 위해 활동의 타임라인을 재생해야 할 필요성이 커진다. 값이 변경된 이유를 설명하기 위해 디스패치와 효과를 추적한다. 종속성을 이해하기 위해 구독 또는 파생된 선택자를 검색한다. 구조는 존재하지만 흐름 속에 암시적으로 존재하며, 암시적인 아키텍처는 규모가 커질수록 추론하기가 어려워진다.

흐름 중심 사고의 인지적 비용

이벤트 기반 모델은 특히 구조화된 형태일 때 프론트엔드 엔지니어링에 꼭 필요한 엄격함을 제공했다. 이를 통해 팀은 비동기 복잡성을 통제하고 변경 관리를 공식화할 수 있었다.

그러나 표현력이 자동으로 명확성을 만들어내지는 않는다. 흐름 지향적 설계는 애플리케이션이 성장함에 따라 구조적 관계를 보기 어렵게 할 수 있다. 상태 조각 사이의 종속성은 직접 표현되기보다 디스패치 로직에서 유추되는 경우가 많다. 파생된 값은 변환을 통해 계층화될 수 있는데, 이를 위해서는 무엇이 무엇에 의존하는지뿐만 아니라 업데이트가 언제 전파되는지도 파악해야 한다.

따라서 이벤트 기반 모델은 미묘한 인지적 부담을 초래한다. 엔지니어는 관계를 직접 조사하는 것이 아니라 시간 경과에 따른 실행을 시뮬레이션해야 한다. 명확하게 해야 하는 질문(예를 들어 이 값에 의존하는 것은 무엇인가? 이것이 변경되면 무엇이 재계산되는가?)을 위해 시스템 전반의 반응 경로를 추적해야 하는 경우가 많다.

조율이 정교해질수록 아키텍처를 전체적으로 이해하는 데 더 많은 노력을 들여야 한다.

상태 우선 사고로의 전환

현대 프론트엔드 개발 전반에서 비교적 조용한 아키텍처 변화가 일어나고 있다. 직전에 무슨 일이 일어났는가를 중심으로 시스템을 구성하는 대신, 현재 무엇이 사실인가를 중심으로 시스템을 구성하는 경우가 증가하는 중이다.

상태 우선 모델에서 변경은 이벤트가 발생해서 전파되는 것이 아니라 관계가 존재하기 때문에 전파된다. 종속성은 명시적으로 선언된다. 파생된 값은 기반 상태의 직접 함수로 표현된다. 어떤 것이 변경되면 시스템은 그에 의존하는 요소를 결정론적 방식으로 재계산한다. 수동으로 흐름을 연출했기 때문이 아니라 관계를 기술했기 때문이다.

이벤트는 여전히 필수적이다. 애플리케이션을 움직이게 하는 것은 여전히 사용자 상호작용과 네트워크 응답이다. 차이점은 이벤트가 아키텍처 추론의 중추 역할이 아니라 상태를 수정하는 입력이라는 본연의 역할로 돌아간다는 것이다. 엔지니어는 타임라인을 재생하는 대신 관계를 조사하고 흐름을 조율하는 대신 구조를 모델링한다.

이 전환은 반응성을 없애는 것이 아니라 다듬는다.

프론트엔드 아키텍처 기술의 재정의

오랜 기간 동안 프론트엔드를 마스터한다는 것은 이벤트를 정밀하게 조율하는 것을 의미했다. 예를 들어 액션을 깔끔하게 디스패치하고, 부수 효과를 철저히 관리하고, 혼돈을 초래하지 않으면서 비동기 경계를 조정하는 것이다. 이런 기술도 여전히 가치가 있다.

그러나 아키텍처의 성숙을 위해서는 그보다 더 깊은 무엇인가가 필요하다. 바로 상태를 명확하게 모델링하고, 종속성을 명시적으로 정의하고, 기록을 재생하는 대신 구조를 조사함으로써 동작을 이해할 수 있는 시스템을 설계하는 역량이다.

리덕스는 큰 진전이었다. 변경에 규칙을 적용했고 이벤트 흐름을 추적할 수 있도록 했다. 그러나 규칙이 있는 디스패치가 아키텍처의 끝이 아니다. 아키텍처는 관계가 핵심 요소가 되고, 상태, 파생, 종속성이 흐름의 결과가 아니라 가시적이고 의도적일 때 시작된다.

이 변화는 여러 현대 프레임워크 전반에서 이미 나타나고 있다. 앵귤러 시그널(Angular Signals), 세밀한 반응형 모델, 상태 기반 UI 아키텍처 등은 모두 동일한 개념, 즉 이벤트 연출이 아니라 상태의 구조가 시스템 동작을 정의해야 한다는 개념으로 수렴한다.

필자는 새롭게 부상하는 이 모델을 “상태 우선 프론트엔드 아키텍처”라고 부른다. 여기서는 애플리케이션 상태가 주된 진실 공급원이 되고, UI는 이벤트 사슬에 의해 움직이는 것이 아니라 상태로부터 파생된다.

현대 프론트엔드 팀이 생각해야 할 질문은 이제 “이 이벤트에 어떻게 반응할 것인가?”가 아니라, “무엇이 사실인지 모델링하기 위한 가장 단순하고 명확한 방법은 무엇인가?”이다.

반응이 아닌 구조로 시작하게 되면 복잡성은 대체로 줄어든다. 시스템을 더 쉽게 설명하고 테스트하고 발전시킬 수 있게 된다. 이벤트는 여전히 시스템에 들어오지만 더 이상 시스템을 정의하지는 않는다.

이 변화는 철학적인 이야기로 들릴 수 있지만 실제 결과를 가져온다. 구성요소를 설계하는 방식을 바꾸고 상태를 구성하는 방식을 바꾸고 규모에 대해 추론하는 방식을 바꾼다.

이벤트는 필수 불가결하다. 애플리케이션을 앞으로 움직이게 하는 입력이다. 그러나 아키텍처의 핵심은 방금 무슨 일이 일어났는지가 아니라 무엇이 사실로 남아 있는지다.

이벤트는 앞으로도 시스템에 들어오겠지만 아키텍처를 정의해서는 안 된다. 차세대 프론트엔드 시스템은 이벤트를 얼마나 매끄럽게 조율하느냐가 아니라, 상태를 얼마나 명확하게 모델링하느냐에 의해 좌우될 것이다. 앵귤러 시그널과 같은 프레임워크는 이 전환이 이미 시작됐음을 보여주며, UI가 이벤트에 대한 반응이 아닌 상태의 투영으로 취급되는 미래를 가리키고 있다.
dl-itworldkorea@foundryco.com