프론트엔드는 원래 이렇게 복잡했어야 할까? - 본질적 복잡성과 우연한 복잡성의 경계

"간단한 웹 페이지 하나 만드는데 왜 이렇게 복잡해진 거야?"

혹시 여러분도 프론트엔드 개발을 시작하면서 이런 생각 해보신 적 있나요? 간단한 버튼 하나 만드는데 React, Next.js, TypeScript, Tailwind, shadcn, TanStack Query, Zustand, ESLint, Prettier, Vite, pnpm... 뭐 이렇게 많이 써야 하는 걸까 싶은 그 순간이요. binaryigor이라는 개발자가 "현대 프론트엔드 복잡성: 본질적인가, 우연적인가?"라는 글로 이 질문을 정면으로 파헤쳤어요.

여기서 나오는 본질적 복잡성(essential complexity)과 우연한 복잡성(accidental complexity)이라는 용어가 핵심이에요. 이게 뭐냐면, 소프트웨어 거장 프레드 브룩스가 "은총알은 없다"라는 유명한 에세이에서 제시한 개념이에요. 본질적 복잡성은 문제 자체에 내재된 피할 수 없는 복잡성이고요, 우연한 복잡성은 우리가 선택한 도구나 방식 때문에 생긴, 없애려면 없앨 수 있는 복잡성을 말해요. 예를 들어 "사용자가 여러 기기에서 동시에 같은 문서를 편집할 수 있어야 한다"는 요구사항은 본질적으로 복잡해요. 하지만 "이 간단한 폼 하나 때문에 빌드 시간이 3분"이라면 그건 우연한 복잡성일 가능성이 높죠.

우리가 짊어지고 있는 레이어들

저자는 현대 프론트엔드가 얼마나 많은 레이어로 쌓여 있는지를 하나씩 짚어요. 먼저 언어 레이어에서는 TypeScript가 JavaScript 위에 타입 시스템을 얹어요. 그리고 이걸 브라우저가 이해할 수 있는 JS로 다시 변환하는 트랜스파일러가 필요하죠. 그 다음엔 번들링 레이어예요. 수백 개의 파일을 하나로 묶어주는 Webpack, Vite, Turbopack 같은 도구들이 여기 속해요. 왜 묶냐고요? 브라우저가 파일을 하나씩 요청하면 느리니까 미리 합쳐두는 거예요.

그 위에 프레임워크 레이어가 있어요. React, Vue, Svelte 같은 친구들이죠. 여기서 또 "그냥 React"로는 부족하다며 Next.js, Remix, Nuxt 같은 메타 프레임워크가 얹혀요. 서버 사이드 렌더링, 파일 기반 라우팅, 이미지 최적화 같은 걸 해주거든요. 그리고 상태 관리 레이어(Redux, Zustand, Jotai), 데이터 페칭 레이어(TanStack Query, SWR), 스타일링 레이어(CSS Modules, Tailwind, styled-components), 폼 레이어(React Hook Form), 검증 레이어(Zod, Yup)가 줄줄이 붙어요.

간단한 투두 앱을 만들어도 package.json에 의존성이 50~100개는 기본이에요. node_modules 폴더는 몇 백 MB를 쉽게 넘기고요. 저자는 이 중 상당 부분이 우연한 복잡성이라고 주장해요. 진짜로 그 문제 때문에 필요한 게 아니라, 생태계의 관성과 "다들 이렇게 하니까"라는 분위기 때문에 쓰고 있다는 거예요.

그러면 어떻게 해야 할까

저자가 제시하는 대안은 "덜 쓰기(do less)"예요. 모든 프로젝트가 Netflix나 Facebook 규모일 필요는 없잖아요? 간단한 사내 도구나 블로그, 랜딩 페이지 같은 건 순수 HTML에 살짝 JavaScript만 얹어도 충분해요. 최근 HTMX나 Alpine.js 같은 하이퍼미디어 기반 접근법이 주목받는 것도 이런 맥락이에요. 서버에서 HTML을 그냥 내려주고 필요한 부분만 갈아끼우는 방식인데, 브라우저가 원래부터 잘하던 걸 다시 써먹자는 철학이거든요.

또 하나의 흐름은 번들러를 쓰지 않는 개발이에요. 브라우저가 이제 ES Modules를 네이티브로 지원하니까, 빌드 없이 바로 import를 써도 돌아가요. Vite도 개발 모드에서는 이 방식을 활용하죠. 그리고 Deno나 Bun 같은 새로운 런타임은 TypeScript를 별도 트랜스파일 없이 바로 실행할 수 있게 해줘요.

업계 맥락: 반동의 물결이 오고 있어요

이런 비판은 사실 dpc만의 목소리가 아니에요. DHH(Ruby on Rails 창시자)는 "No build" 운동을 펼치면서 Rails에서 Webpack을 걷어냈고요, Svelte 창시자 Rich Harris도 "프레임워크는 사라져야 한다"며 컴파일 타임에 다 처리하는 방향으로 설계했어요. Astro 같은 프레임워크는 "기본은 정적 HTML, JS는 꼭 필요한 섬(island)에만"이라는 철학으로 인기를 끌고 있고요.

반대로 React는 Server Components를 도입하면서 오히려 복잡도를 다른 방향으로 움직이고 있어요. 서버와 클라이언트의 경계가 흐려지면서 새로운 개념을 또 배워야 하는 상황이죠. 이게 본질적 복잡성을 해결한 건지, 아니면 우연한 복잡성을 하나 더 쌓은 건지에 대해서는 여전히 논쟁 중이에요.

한국 개발자에게 주는 시사점

한국 기업의 프론트엔드 환경은 대부분 React + Next.js가 표준으로 자리 잡았어요. 그래서 신입 개발자 교육도 자연스럽게 이 스택 중심으로 이뤄지죠. 그런데 프로젝트의 요구사항을 먼저 보지 않고 도구부터 정하는 습관은 조심할 필요가 있어요. "회사 소개 페이지"를 만드는데 SSR, ISR, RSC를 다 쓸 필요가 있을까요? 오히려 정적 HTML 하나가 더 빠르고 관리하기 쉬울 수 있어요.

실무에서는 복잡성의 예산(complexity budget)이라는 개념을 적용해볼 만해요. 이 프로젝트가 감당할 수 있는 복잡도는 얼마까지인지 미리 정하고, 새 라이브러리를 추가할 때마다 "정말 필요한가?"를 묻는 거죠. 특히 소규모 팀이라면 이게 생산성을 크게 좌우해요.