프론트엔드가 더 복잡해지는 것이 아니라 — 경계가 흐려지고 있다

Source: Dev.to

왜 과거 프론트엔드는 복잡하게 느껴졌는가

• 많은 구분된 파트들
• 각 레이어마다 명확한 책임이 있었음
• 경계가 쉽게 식별되었음

현대 프론트엔드에서 바뀐 점

• 시스템 경계가 더 이상 명확하지 않음.
• 이전 아키텍처에서는 다음과 같은 구분이 있었음:
  • UI vs. 로직
  • State vs. 렌더링
  • Client vs. Server
  • Component vs. Service

이러한 구분 덕분에 대규모 시스템을 이해하기 쉬웠다. 이제는 그 경계가 점점 흐려지고 있다.

컴포넌트가 이제 여러 책임을 담당

• 데이터 페칭
• 캐싱 로직
• 비즈니스 규칙
• 사이드 이펙트

UI는 더 이상 단순히 UI가 아니다. 컴포넌트는 이제 프레젠테이션 단위가 아니라 여러 책임을 담은 번들이다.

상태가 이제 많은 영역에 영향을 미침

• 여러 컴포넌트
• 외부 시스템
• 비동기 워크플로우
• 파생 연산

상태가 예측 가능한 경계 안에만 머물지 않는다; 하나의 변화가 원점보다 훨씬 멀리까지 파급될 수 있다.

분산된 로직

로직이 퍼져 있다:

• 컴포넌트
• 훅(Hooks)
• 유틸리티
• 프레임워크 추상화

동작을 이해하려면 여러 정신적 레이어를 오가야 한다. 더 많은 로직이 생겨서가 아니라, 어디에 무엇이 속하는지 알기 어려워졌기 때문에 “집”이 사라진 것이다. 이러한 불확실성은 인지 부하를 만든다.

개발자들은 다음과 같은 질문에 더 많은 시간을 쏟는다:

• 이 로직은 어디에 두어야 할까?
• 왜 이 동작이 여기서 일어나고 있지?
• 이 변화에 무엇이 의존하고 있지?

구조적 vs. 구문적 혼란

옛 시스템

• 컴포넌트가 UI를 담당
• 서비스가 로직을 담당
• 상태는 중앙 집중화
• 책임이 명확히 정의됨

현대 프론트엔드 시스템

• 책임이 겹침
• 경계가 유연함
• 소유권이 공유됨
• 동작이 분산됨

작은 기능조차도 복잡하게 느껴진다. 복잡해서가 아니라, 그 기능이 제한되지 않았기 때문이다.

흐려진 경계의 결과

• 디버깅이 어려워짐
• 리팩토링 위험 증가
• 온보딩 속도 저하
• 정신 모델이 불안정해짐

개발자들은 “이 동작은 실제로 어디에 존재하는가?” 라는 질문에 답하기 힘들어한다.

명확성을 되찾기

우수한 엔지니어들은 구조를 재도입함으로써 보완한다:

• 로직에 대한 명확한 소유권 정의
• 책임을 의도적으로 격리
• 레이어 간 의존성 감소
• 예측 가능한 데이터 흐름 유지
• 아키텍처 일관성 강제

그들은 경계를 정의하는 데 프레임워크에 의존하지 않는다; 경계를 스스로 만들고 있다.

결론

프론트엔드가 더 어려워지는 이유는 코드가 많아졌기 때문이 아니라, 책임에 대한 명확한 경계를 그리기가 점점 어려워지고 있기 때문이다. 그 경계가 없으면, 심지어 단순한 시스템도 복잡하게 느껴진다.