프론트엔드 개발 변천사, 20년 만에 제자리로 돌아온 진짜 이유

"파일 하나 올리면 끝났는데" 요즘 프론트엔드가 낯선 이유

혹시 개발 좀 해봤다는 분들 중에 요즘 프론트엔드는 도대체 왜 이렇게 복잡해졌지 하고 느끼신 적 있으신가요. 2008년만 해도 index.html 파일 하나 만들어서 FTP로 업로드하면 웹사이트가 바로 완성됐습니다. 빌드도 없고 패키지 설치도 없었죠.

그런데 지금은 신입 개발자용 튜토리얼을 펼치면 처음 보는 도구 이름이 열 개 넘게 등장합니다. 최근 개발자 David Poblador가 정리한 글이 이 20년의 변화를 아주 흥미롭게 풀어냈는데, 오늘은 이 내용을 바탕으로 프론트엔드가 왜 이렇게 복잡해졌는지, 그리고 왜 다시 단순해지고 있는지 짚어보려고 합니다.

한 줄 정리하면, 프론트엔드가 복잡해 보이는 이유는 갑자기 어려워진 게 아니라 20년간 문제를 하나씩 해결하며 쌓인 결과물이기 때문입니다.

모든 도구는 상처 위에 생긴 흉터다

이 글의 핵심 문장이 하나 있습니다. 모든 도구는 진짜 문제 위에 생긴 흉터라는 겁니다. 누군가 실제 문제를 겪었고, 그걸 고치려고 도구를 만들었고, 그 도구가 또 다른 문제를 만들면서 다음 도구가 나왔습니다. 무작위로 복잡해진 게 아니라 20년치 합리적인 선택들이 쌓인 결과라는 뜻이죠.

그래서 오늘은 연대기 순서대로, 문제가 생길 때마다 어떤 도구가 왜 등장했는지 따라가 보겠습니다. 저도 이 흐름을 처음 정리해봤을 때 꽤 놀랐어요. 지금의 복잡함은 무작위가 아니라 20년간 문제 해결의 누적된 흔적이었더라구요.

1단계, 2006~2010년, 제이쿼리의 시대

처음 문제는 단순했습니다. 페이지 전체를 새로고침하지 않고 일부만 바꾸고 싶다는 요구였죠. 이걸 위해 등장한 게 제이쿼리입니다. 브라우저마다 다르게 동작하던 DOM 처리 방식을 하나로 통일해줬습니다.

그런데 앱이 복잡해지면서 새로운 문제가 생겼습니다. 데이터가 자바스크립트 변수에도 있고 화면에도 있으니, 가격을 바꾸면 장바구니 합계, 헤더 배지, 결제 버튼을 개발자가 일일이 손으로 다 업데이트해야 했습니다. 하나라도 빠뜨리면 화면이 거짓말을 하는 셈이었죠.

화면과 데이터를 손으로 일일이 맞추는 수작업, 이게 다음 시대를 열게 만든 근본 원인이었습니다.

2단계, 2010~2015년, 프레임워크의 등장

이 수작업 문제를 해결한 게 리액트, 뷰, 앵귤러 같은 프레임워크입니다. 핵심 아이디어는 선언형 UI입니다. 화면을 바꾸는 절차를 일일이 적는 대신, 데이터가 이렇게 생기면 화면은 이런 모습이어야 한다고 선언만 하면 프레임워크가 알아서 처리해주는 방식입니다.

2013년 페이스북에서 나온 리액트가 이 시대를 사실상 평정했습니다. 컴포넌트 단위로 화면을 조립하는 방식과 가상 DOM이 핵심이었죠. 리액트는 SPA을 전제로 하며, 가상 DOM과 고도화된 비교 알고리즘으로 변경된 요소만 선별적으로 갱신해서 대규모 데이터 업데이트가 자주 발생하는 환경에서 최적의 성능을 보여줍니다.

화면과 데이터를 자동으로 맞춰주는 프레임워크가 등장하면서, 개발자는 더 이상 손으로 DOM을 만지지 않게 됐습니다.

3단계, 2012~2018년, 빌드 과정이 왜 필요해졌나

가장 원망받는 단계입니다. 왜 파일을 그냥 못 여는 거야라는 불만이 여기서 나오죠. 이유는 두 가지예요. 자바스크립트에는 원래 파일을 나눠서 관리하는 기능이 없었고, 개발자들은 최신 문법과 JSX를 옛날 브라우저도 이해할 수 있게 변환해야 했습니다.

그래서 바벨 같은 변환 도구와 웹팩 같은 번들러가 등장했습니다. 이 과정에서 코드를 압축하고 안 쓰는 코드를 제거하는 작업까지 함께 이뤄지죠. 그 결과물이 바로 개발자라면 누구나 아는 그 무거운 node_modules 폴더입니다.

파일을 나누고 최신 문법을 옛날 브라우저에서도 돌아가게 만드는 과정에서 빌드 단계가 필수가 됐습니다.

4단계, 2018~2024년, 속도 전쟁

빌드는 됐는데 너무 느렸습니다. 그래서 도구 자체를 자바스크립트가 아니라 Go나 Rust 같은 빠른 언어로 다시 만드는 흐름이 시작됐어요. esbuild, SWC, 그리고 요즘 가장 많이 쓰는 Vite가 이 시기 산물입니다.

2026년 현재 시점에서 보면 이 흐름이 국내 개발 현장에서도 뚜렷합니다. Rspack이나 Vite Rolldown 같은 고성능 툴체인이 등장하며 모듈 페더레이션 기술이 안정화됐고, 서로 다른 저장소에 있는 컴포넌트를 런타임에 불러오는 비용이 획기적으로 낮아졌습니다. 실제로 국내 빅테크 기업들은 결제, 장바구니, 리뷰 같은 영역을 팀별로 나눠 독립적으로 배포하는 마이크로 프론트엔드 구조를 이미 운영 중입니다.

느린 빌드 도구를 Rust와 Go로 다시 짜면서 개발 속도 자체가 수십 배 빨라졌습니다.

5단계, 2014~2026년, 다시 서버로 돌아가다

여기서 재밌는 반전이 나옵니다. 자바스크립트로만 화면을 그리다 보니 새로운 문제가 생겼습니다. 서버는 텅 빈 화면만 보내고 자바스크립트가 다 다운로드될 때까지 사용자는 흰 화면만 보게 됐죠. 검색엔진도 마찬가지로 빈 페이지로 인식했습니다.

해결책은 다시 서버에서 화면을 미리 만들어 보내는 방식, 바로 2008년에 하던 그 방식으로 돌아가는 것이었습니다. 다만 지금은 넥스트js, 아스트로 같은 정교한 도구를 얹었죠. 문제는 서버가 만든 화면이 처음엔 사진처럼 보이기만 하고 버튼이 눌리지 않는다는 점입니다. 이걸 하이드레이션이라고 부르는데, 사실상 같은 요리를 두 번 하는 셈이에요.

빈 화면 문제를 해결하려고 서버 렌더링으로 회귀했지만, 이번엔 하이드레이션이라는 새로운 비용이 생겼습니다.

6단계, 2015~2026년, 타입스크립트와 성숙한 도구들

이 단계는 도입할 가치가 가장 확실한 부분입니다. 타입스크립트는 자바스크립트에 타입 체계를 더해서 코드를 쓸 때 바로 오류를 잡아줍니다. 테일윈드 CSS는 스타일을 마크업 안에 바로 쓰는 방식으로 생산성을 크게 끌어올렸고요.

요즘 국내 현업 분위기도 이 흐름과 정확히 맞닿아 있어요. 2025년 리액트 19의 정식 릴리즈는 프론트엔드 개발의 판도를 클라이언트 중심에서 서버 중심으로 완전히 이동시켰다는 평가가 나오는데, 핵심은 서버 컴포넌트와 Actions입니다. 실무에서는 클라이언트 상태 관리 라이브러리의 역할이 축소되고, 서버에서 미리 렌더링된 HTML을 스트리밍으로 받아오는 패턴이 표준이 되고 있다고 합니다. 토스, 당근마켓 같은 국내 기업들도 이미 서버 컴포넌트를 프로덕션에 도입하고 있고요.

타입스크립트와 성숙한 CSS 도구들은 복잡함 속에서도 실제로 도입할 가치가 확실한 영역입니다.

7~8단계, 배포는 쉬워지고 이제는 AI가 코드를 짠다

배포는 오히려 좋아졌습니다. Git 저장소를 Vercel이나 Netlify에 연결하면 코드를 올릴 때마다 자동으로 배포됩니다. 파일질라에 파일 끌어다 놓던 시절보다 확실히 편해졌죠.

그리고 가장 최근 층은 AI가 코드를 대신 짜주는 시대입니다. v0, Cursor, Claude Code 같은 도구에 원하는 화면을 말로 설명하면 실제 동작하는 프론트엔드 코드가 나옵니다. 이제 개발자는 코드 작성자에서 AI 워크플로우 설계자로 이동하고 있고, 효율성보다 정확한 흐름 관리가 실무 역량의 기준이 되고 있다는 분석도 나옵니다.

배포는 완전히 쉬워졌고, AI 코드 생성은 개발자의 역할을 코드 작성자에서 설계자로 바꾸고 있습니다.

결국 원점, 그런데 왜 다시 돌아왔을까

20년, 수십 미터 분량의 빌드 도구를 파고 내려가 보니 도착한 곳은 결국 지금의 최신 트렌드가 서버에서 HTML을 만들고 자바스크립트는 최소한만 보낸다는, 2008년 파일 하나 올리던 방식과 놀랍도록 닮은 지점이었습니다. 아스트로의 아일랜드, 서버 컴포넌트, htmx 모두 같은 방향을 가리키고 있죠.

이게 시사하는 바는 분명합니다. 처음의 본능이 틀렸던 게 아니라, 현실적인 이유로 멀리 돌아갔다가 다시 그 자리로 돌아온 것뿐입니다.

20년의 여정 끝에 업계는 서버 중심, 가벼운 자바스크립트라는 원래의 본능으로 돌아오고 있습니다.

마무리

프론트엔드 개발이 복잡해 보이는 건 갑자기 그런 게 아니라 20년간 진짜 문제를 하나씩 풀어온 결과입니다. 전체 역사를 다 외울 필요는 없고, 지금 내 서비스에 필요한 20퍼센트만 골라 쓰면 충분해요. 개발 트렌드를 오랜만에 다시 들여다보시는 분이라면, 이 흐름을 알고 나면 훨씬 마음이 편해지실 겁니다. 다음번에 새로운 프론트엔드 도구를 만나면, 이 도구도 결국 누군가의 상처 위에 생긴 흉터겠구나 하고 한번 떠올려보세요.