프론트엔드 개발 수준은 과거와는 비교할 수 없이 높아졌다. 현대적인 프레임워크는 빠른 렌더링 파이프라인, 컴포넌트 합성, 강력한 툴, 그리고 정교한 애플리케이션을 쉽게 구축할 수 있게 해주는 라이브러리 생태계를 제공한다.

그러나 정작 팀은 정확히 그 반대로, 더 어려워진 상황을 경험하는 경우가 많다. 애플리케이션을 추론하기가 점점 더 어려워지고 여러 기능이 예상치 못한 방식으로 상호작용한다. 단순한 변경이 시스템에서 관련 없는 부분들에 영향을 미친다. 디버깅은 애플리케이션 전반에 걸친 보이지 않는 종속성을 쫓는 과정이 된다.

툴은 개선됐지만 복잡성은 그대로인 것이다.

끝나지 않는 프론트엔드 복잡성

사람들은 프론트엔드 복잡성의 원인으로 오랫동안 프레임워크 자체를 탓했다. 툴은 각 세대를 거듭하며 이전 세대의 한계를 해결하겠다고 약속했다. 서버 렌더링 페이지에서 클라이언트 측 프레임워크로 전환되면서 아키텍처 측면에서 많은 실험이 이뤄졌고, 그 후 가상 DOM 엔진과 반응형 라이브러리, 그리고 점점 더 정교해지는 컴포넌트 시스템이 등장했다.

더 나은 프레임워크가 나오면 대규모 프론트엔드 애플리케이션의 복잡성이 해결될 것이라는 기대가 있었지만, 실제로 펼쳐진 양상은 달랐다.

현대 프레임워크는 원래 해결을 목표로 삼았던 문제를 대부분 해결했다. 렌더링 성능은 비약적으로 향상됐고 컴포넌트 아키텍처는 예측 가능해졌다. 툴과 개발자 경험도 성숙해졌다. 그런데 프론트엔드 시스템의 복잡성은 계속 더 높아졌다.

프론트엔드의 역할이 조용히, 예전보다 훨씬 더 확장됐다는 점도 그 이유 중 하나다.

프론트엔드 개발은 더 이상 단순히 HTML, 자바스크립트, 프레임워크에 관한 것이 아니다. 현대의 프론트엔드 엔지니어는 전체 시스템이 어떻게 설계되고 운영되는지 이해해야 하며, 분산 API, CI/CD 파이프라인, 컨테이너화된 배포, 설계 시스템, 그리고 복잡한 빌드 인프라를 다룬다. 또한 데이터 흐름, 캐싱 전략, 그리고 대규모 클라이언트 측 시스템의 발전 방향에 대한 아키텍처 결정을 내린다.

여러 측면에서 과거 여러 스택 계층에 속했던 다양한 책임을 프론트엔드가 흡수했다고 할 수 있다.

이 같은 전환을 두고 ‘프론트엔드가 풀스택이 되고 있는 중’이라고 표현하기 쉽지만, 이와 같은 설명도 여전히 실제 변화의 규모를 제대로 반영하지 못한다. 현대의 프론트엔드 작업은 풀스택을 여러 번 곱한 것처럼 느껴지는 경우가 많다. 엔지니어는 애플리케이션 아키텍처, CI/CD 파이프라인, 컨테이너화된 배포, 설계 시스템, 분산 데이터 흐름에 대해 생각해야 하며, 이 모두를 사용자와 접하는 시스템 계층을 구축하는 것과 동시에 해야 한다.

한때 프레젠테이션 계층이었던 것이 차츰 브라우저 내에서 실행되는 전체 애플리케이션 플랫폼으로 바뀌었다.

보이지 않는 복잡성

이 복잡성의 대부분은 개발 초기에는 보이지 않는다. 컴포넌트 수가 많지 않은 소규모 애플리케이션은 단순하고 상태 흐름은 관리 가능해 보이며 데이터 종속성도 명확해 보인다.

그러나 시스템이 성장하면서 숨은 복잡성이 누적되기 시작한다.

사용자 상호작용이 네트워크 요청을 트리거한다. 응답이 상태의 여러 단편을 업데이트한다. 파생된 값들이 다시 계산되고 UI 컴포넌트가 다시 렌더링된다. 백그라운드 동기화는 캐시된 데이터를 업데이트한다. 다른 기능이 동일한 상태를 구독하고 자체적인 업데이트를 트리거한다.

각 개별 단계는 합리적으로 보일 수 있다. 그러나 이러한 개별 단계가 모이면서 종속성은 거미줄처럼 얽히고 점점 더 이해하기 어려워진다.

최근 필자는 이벤트 기반 프론트엔드 시스템(가시적인 구조를 통해 표현되기보다는 동작이 일련의 반응 사슬을 타고 확산) 맥락에서 이와 동일한 패턴을 살펴봤다.

문제는 이러한 상호작용이 존재한다는 사실이 아니다. 현대 애플리케이션은 결국 이러한 상호작용을 조율해야 한다. 문제는 이를 시스템 설계와 관련된 고려 사항이 아닌 구현상의 세부 사항으로 취급하는 우리의 아키텍처 사고방식에 있다.

스택 위로 이동하는 복잡성

소프트웨어 진화의 대표적인 패턴 중 하나는 복잡성이 사라지는 경우가 거의 없다는 점이다. 위치만 바뀔 뿐이다.

프레임워크로 렌더링이 단순화되자 복잡성은 애플리케이션 로직으로 옮겨갔다. 컴포넌트 아키텍처로 모듈성을 개선되자 복잡성은 상태 조율로 이동했다. 애플리케이션이 더 동적으로 변하자 복잡성은 데이터 동기화와 파생 상태로 이동했다.

현재 프론트엔드 아키텍처에서는 렌더링 기법보다는 애플리케이션 상태 조각들 사이의 관계 관리가 더 큰 비중을 차지한다. 포착하기 어렵지만 중대한 변화다.

우리는 여전히 프레임워크나 컴포넌트 패턴, 라우팅 전략이 프론트엔드 아키텍처의 주 요소인 것처럼 이야기한다. 현실적으로 이러한 의사결정은 이제 시스템의 작은 한 부분일 뿐이다. 진짜 아키텍처는 상태의 구조, 그리고 시간 경과에 따른 상태의 변화를 규정하는 규칙 안에 존재한다.

이 변화가 가리키는 방향은 상태 우선 프론트엔드 아키텍처다. 애플리케이션 상태가 시스템의 주 구조가 되고, UI는 그 상태의 투영이다.

아키텍처적 과제의 등장

현대 프론트엔드 개발의 핵심적인 아키텍처 과제는 더 이상 UI를 효율적으로 렌더링하는 것이 아니라, 성장하는 대규모 시스템을 이해 가능한 상태로 유지할 수 있도록 애플리케이션 상태를 모델링하는 것이다.

상태 관계가 불분명하면 복잡성은 빠르게 증폭된다. 기능들은 숨겨진 종속성을 통해 상호작용하기 시작하고 데이터 흐름은 예측 불가능해지고 엔지니어들은 새로운 기능을 구축하기보다 동작을 추적하는 데 더 많은 시간을 소비한다.

그러나 상태 관계가 명확하면 이 복잡성의 대부분은 관리 가능한 수준이 된다.

바로 이 같은 이유로, 현재 가장 중요한 프론트엔드 혁신 중 상당수가 상태 모델링을 중심으로 이뤄지고 있다. 반응형 프리미티브, 선언적 데이터 종속성, 또는 파생된 상태 시스템 등 업계는 애플리케이션 상태의 형태가 애플리케이션 자체의 구조를 정의하는 개념으로 서서히 수렴하고 있다.

현재 프론트엔드 사고방식에 대한 비판

이러한 진전에도 불구하고 프론트엔드 생태계의 많은 부분은 여전히 핵심을 벗어난 문제에 집중하고 있다.

많은 논의가 렌더링 성능, 컴포넌트 구문 또는 프레임워크 비교를 중심으로 한다. 이러한 논쟁도 쓸모가 있긴 하겠지만 대규모 시스템의 유지보수를 어렵게 만드는 문제를 해결하는 경우는 거의 없다.

여전히 프론트엔드에 대한 대화의 너무 많은 부분이 UI를 얼마나 빨리 렌더링할 것인지에만 집중하면서 정작 우리가 시스템을 이해하고 있는지 여부는 무시하고 있다.

대규모 프론트엔드 실패의 원인은 대부분 잘못된 프레임워크 선택이 아니라 상태 관계가 불분명하고 책임 정의가 미흡하고 애플리케이션 로직이 상호 단절된 수많은 코드베이스 조각에 걸쳐 있는 시스템에 있다.

다시 말해 아키텍처의 실패다. 프론트엔드 개발의 중점을 프레임워크의 선택에 둘 경우 시스템이 성장하더라도 이해 가능한 상태를 유지하도록 설계해야 한다는 더 깊은 과제가 묻히게 된다.

프론트엔드 아키텍처는 어떻게 진화할까

필자는 향후 10년 동안 프론트엔드 아키텍처가 명시적인 상태 모델링을 중심으로 전개될 것이라고 생각한다.

팀은 애플리케이션을 산발적인 이벤트와 비동기 업데이트에 반응하는 컴포넌트의 집합으로 구축하기보다는, 애플리케이션 상태와 이러한 상태들 사이의 관계에 대한 더 명확한 표현을 중심으로 시스템을 구축하기 시작할 것이다.

UI는 애플리케이션 로직이 조율되는 곳이 아닌 상태가 투영되는 곳이 된다.

이 같은 초점의 변화는 엔지니어에게 기대하는 역할도 변화시킨다. 엔지니어는 동작을 조율하는 역할에서 벗어나 시스템 자체의 구조와 의도를 정의하는 역할로 옮겨간다.

이미 생태계 전반에 나타나고 있는 패턴에서 변화를 볼 수 있다. 반응형 프리미티브, 파생 상태 모델, 신호 기반 아키텍처는 모두 동일한 방향, 즉 상태 관계가 명시적이고 관찰 가능한 시스템을 가리킨다.

프론트엔드 시스템이 계속 확장됨에 따라 이 접근 방식은 단순히 최적화 수준이 아닌 필수 요소가 될 가능성이 높다. 상태를 명시적으로 모델링하지 못하면 결국 선택한 프레임워크나 툴에 관계없이 시스템을 유지 관리하기가 점점 더 어렵게 될 것이다.

프론트엔드 아키텍처의 미래

프론트엔드 복잡성의 숨은 비용은 렌더링 속도나 번들 크기로 측정되지 않는다. 그 비용은 시스템 동작을 이해하는 데 필요한 인지 부하의 형태로 나타난다. 애플리케이션에서 데이터가 어떻게 이동하는지 엔지니어가 쉽게 추론할 수 없으면 개발 속도는 느려진다. 버그는 격리하기 더 어려워지고, 기능 구현은 더 위험해진다.

이 복잡성을 줄이기 위해서는 관점의 전환이 필요하다. 프론트엔드 아키텍처는 프레임워크를 넘어 시스템 설계에 집중해야 한다. 가장 중요한 의사결정은 더 이상 어느 라이브러리가 UI를 가장 빨리 렌더링하느냐가 아니라, 애플리케이션 상태를 어떻게 구조화할 것인지, 그 상태가 어떻게 발전하는지, 그리고 시스템을 구축하는 엔지니어에게 그 관계의 가시성이 어떻게 유지되느냐에 관한 의사결정이다.

애플리케이션의 규모와 역량이 계속 성장함에 따라 상태 모델링으로의 전환은 프론트엔드 아키텍처의 다음 단계를 정의하게 된다. 프론트엔드의 미래는 더 강력한 렌더링 엔진이 아니라 복잡성을 이해할 수 있는 상태 구조를 갖춘 시스템을 설계하는 데 있다.
dl-itworldkorea@foundryco.com