프론트엔드를 하다보면 많이들 물어보는 (저 역시 지금도 고민을 하고 있는) 질문들을 꼽아보자면 "컴포넌트 추상화 구조는 어떻게 하면 좋나요?", "뷰 로직과 비니지스 로직은 어떻게 분리를 해서 정리

프론트엔드를 하다보면 많이들 물어보는 (저 역시 지금도 고민을 하고 있는) 질문들을 꼽아보자면 "컴포넌트 추상화 구조는 어떻게 하면 좋나요?", "뷰 로직과 비니지스 로직은 어떻게 분리를 해서 정리하나요?", "어떤 구조가 좋은 구조인가요?" 등이 있습니다. 질문들의 형태는 다르지만 결국 좋은 아키텍쳐가 무엇인가에 대한 질문이라고 생각을 합니다. 처음에는 그냥 기능 구현을 하면 되지만 프로젝트의 크기가 커지다 보면 이거 제대로 정리해두지 않고서는 정말 안될 것 같은 순간들을 맞이하게 됩니다. 점점 디버깅이 힘들어지고 그냥 만들면 쉬울 요구사항도 기존 코드에 확장을 하는 것이 쉽지 않다는 것을 느끼게 됩니다. 많은 프론트엔드 개발자들이 이러한 문제에 부딫히면서 기존의 구조에서 조금씩 더 나은 아키텍쳐의 형태를 만들고 라이브러리나 프레임워크의 형태를 제안하게 되면서 짧은 시간안에 새로운 아키텍쳐들과 방법들이 꾸준히 탄생했습니다. 특정 벤더가 존재하지 않는 웹이라는 특성과 요구사항의 변화와 빠른 대응이 중요한 프론트엔드라는 직군의 특성이 만나면서 웹 프론트엔드는 더 나은 선택지로의 트렌드 변화가 참 빠른 곳이 되었습니다. 이번 글이 얼마만큼 빨리 낡아질지는 모르나 지금 현재 프론트엔드 아키텍쳐의 가장 최근의 트렌드에 대해서 한번 이야기 해볼까 합니다. 프론트엔드 트렌드 변천사 1. HTML, CSS, JS의 탄생 - 관심의 분리와 느슨한 결합 2. jQuery까지의 시대 - 일단 DOM을 쉽게 쓰자. 3. HTML + JS를 합치는게 더 낫던데? MVC 컴포넌트 방식의 탄생 4. 선언적으로 만들자. 데이터 바인딩 + 템플릿 = MVVM 웹 프레임워크 춘추전국시대 5. 컴포넌트간 데이터 교환이 너무 복잡해요. Container - Presenter 방식 6. Props Drill 문제 어떻게 할거임? - FLUX와 Redux 7. 너무 복잡한데? - hooks와 context, Recoil, Zustand, jotai 8. 어차피 대부분 서버 api를 관리 하려고 쓰는 거 아님? React Query, SWR, Redux Query