5. 내가 생각하기에 프론트엔드 엔지니어링이 어려운 이유

• 리액트는 자유도가 높다. best practice 로 삼을만한 구조가 없다. 컴포넌트, 훅을 만들기 쉽다. 그래서 어렵다. 높은 자유도가 주어지면 그만큼 사용자가 생각해야 할 것들이 많다. 그래서 예전에는 atomic design pattern, 요즘은 fsd 가 폴더 구조 방법론으로 등장했지만...글쎄...본질적인 문제를 해결해주지는 못한다.

  • 그래서 어쩌면 앵귤러로 FE 개발을 했으면 오히려 이런 복잡도는 줄였을 것 같다.

• 그런데, 리액트라는 라이브러리가 자유도가 높은건 결국 웹앱의 변동성과 복잡도가 투영된 결과라고 생각도 든다. 그렇다면 결국 도구가 문제인게 아니라 해결해야 할 문제 자체가 복잡한 것.

• 그러면 해결해야 할 문제가 왜 복잡할까? 일단 첫번째로 상태가 큰 몫을 한다. FE 엔지니어링의 핵심은 이 상태를 얼마나 잘,적절히 관리하느냐인 것 같다. 그러면 왜 잘,적절히 관리하는게 어려울까? 전역상태 때문이다. 어떤 데이터가 '전역적'이라는 것은 위험도가 높다. (바닐라 자바스크립트에서 전역 변수는 당연한듯이 지양된다..) 앱 전체에서 컨텍스트를 공유하기 때문이고, 이 때문에 행동범위(인풋,아웃풋 모두..)를 추측하기 어렵기 때문이다.

• 어쨌거나, 웹앱에서 불가피해진 전역상태를 조금 더 쉽게 다루게 하기 위해서 온갖 전역상태 라이브러리들이 나온다. (요즘은 zustand, jotai, valtio 삼파전 인것 같다.ㅎ..) 이 때, 각 전역상태 도구들의 멘탈모델이 나의 소프트웨어에 적절한가를 따져봐야한다. 그냥 무작정 사용성을 기준으로 선택하면 안된다. 리덕스의 보일러플레이트가 방대한 이유로 인해 무조건 리덕스를 지양하자는 의견을 나는 별로 좋아하지 않는다. 보일러플레이트가 방대하다는것은 그만큼 구조가 견고하다는 것이다.

• 그리고 또 왜 어려울까, 두번째로는 아무래도 외부 의존도가 높은 것이 생각난다. 대표적으로는 서버와 디자인이 있다.

• 프론트는 서버 데이터를 받아와서 뿌려줘야한다. 이 때 '받아오는 과정'과 '뿌려주는 과정' 속에서 일어나는 모든 예외처리를 해야한다. 로딩/에러/성공 모두. 이는 횡단관심사로서 잘 분리하면 그만아닌가? 생각할 수도 있겠지만 생각보다 쉽지 않다. 이 분리한 예외처리를 코드의 어느 구간에 넣어야할지를 잘 고려해야한다. 이는 결국 디자인과도 결합된다.

• 외부 의존도 두번째는 디자인이다. 디자인 (UI) 와 프론트엔드 컴포넌트 구조는 강결합되기 쉽다. 아무리 헤드리스, 디자인시스템 등을 잘 구현해도 한계점은 분명히 존재한다. 어쩔수 없이 디자인구조가 프론트엔드 구조를 만들기도 한다.

• 그리고..이 두가지 의존성인 서버 데이터와 디자인 사이에서 균형점을 맞춰야하는게 프론트엔드의 역할이니 당연히 어려울 수 밖에 없다. 특히나 서버와 디자인은 대부분 결합되지 않는다. 그러니 서버 < 프론트 > 디자인과 같은 구조가 생긴다. 즉, 프론트는 서버와 디자인이라는 두 가지 외부 의존성을 번역하고, 엮어야한다.

• 그리고 마지막...실행 환경과 하위호환..ㅠㅠ 엉엉. 웹을 개발하든 웹뷰를 개발하든. 프론트엔드 개발은 실행되는 환경을 탄다. 브라우저 지원범위를 신경써서 코드를 작성하고 폴리필을 적절히 추가해줘야하며, 웹뷰를 띄울 때에는 네이티브별로 다른 동작들을 신경써서 개발해야한다. 근데 이건 해결가능한 문제는 아니다. 그냥 웹의 태생이 그렇다. (그냥 다같이 환경 통일하자!!!!!!!!ㅠ)

여기까지 그냥 프론트 개발하다가 어려워서 든 생각...
그니까 그냥 프론트는 제약과 변동성, 외부의존성을 얼마나 잘 다루느냐다.