버튼 하나로 돌아본 프론트엔드 20년
버튼 하나로 돌아본 프론트엔드 20년
2008년 무렵 웹 개발을 떠났다가 지금 돌아오면 `
핵심 요약
| 시기 | 해결하려던 문제 | 뒤따른 비용 |
| jQuery와 AJAX | 브라우저 차이를 줄이고 페이지 일부만 바꿨어요 | 데이터와 DOM 상태를 개발자가 직접 맞춰야 했어요 |
| 컴포넌트 프레임워크 | 상태에 따라 화면을 선언적으로 그렸어요 | 런타임과 프레임워크 학습 비용이 커졌어요 |
| 번들러와 고속 툴링 | 모듈, 구형 브라우저 호환, 빌드 속도를 해결했어요 | 설정과 의존성 구조가 복잡해졌어요 |
| 서버 렌더링 | 초기 화면, 검색 노출, 로딩 문제를 줄였어요 | hydration과 서버·클라이언트 경계가 새 과제가 됐어요 |
| 코딩 에이전트 | 다른 분야 개발자도 화면을 빠르게 만들 수 있게 했어요 | 생성된 코드를 판단하려면 앞선 기술 층을 이해해야 해요 |
1. 웹은 문제를 풀 때마다 새로운 층을 쌓았어요
초기 AJAX와 jQuery는 페이지 전체를 다시 읽지 않고 필요한 부분만 바꾸는 경험을 대중화했어요. 브라우저마다 달랐던 DOM API도 한결같이 다룰 수 있었어요. 하지만 값은 자바스크립트 변수에 있고 실제 화면 상태는 DOM에 따로 남았어요. 버튼의 라벨이나 비활성 상태를 바꿀 때 개발자가 두 상태를 직접 맞춰야 했어요. 2
React, Vue, Angular, Svelte 같은 프레임워크는 이 수동 동기화를 줄였어요. 개발자가 데이터에 맞는 화면을 선언하면 프레임워크가 필요한 부분을 갱신해요. 버튼도 이벤트와 상태를 가진 컴포넌트가 됐어요. 최근 도구들이 signal이나 세밀한 의존성 추적을 채택하는 흐름은 화면 전체보다 바뀐 값 주변만 갱신하려는 선택으로 볼 수 있어요.
브라우저용 코드를 만들기 위한 공정이 길어졌어요
자바스크립트에 통일된 모듈 체계가 없던 시기에는 CommonJS와 ES Modules가 함께 쓰였어요. 새 문법을 구형 브라우저에서도 실행하려고 Babel이 필요했고, 여러 파일을 묶으려고 webpack이 자리 잡았어요. 압축, tree-shaking, 코드 분할, 소스 맵까지 빌드 과정에 들어왔어요.
기능이 늘수록 설치 파일과 설정도 불어났어요. 원문은 빈 스타터 프로젝트에서도 약 25만 개 파일이 설치될 수 있다고 짚어요. 이후 esbuild와 SWC가 Go와 Rust로 주요 작업을 다시 구현해 속도를 높였고, Vite는 개발 서버의 대기 시간을 줄였어요. Rolldown, pnpm, Bun도 같은 맥락에서 등장했어요. 개발자는 더 빠른 도구를 얻었지만, 패키지 매니저, 변환기, 번들러의 역할을 구분해야 했어요. 2
서버에서 HTML을 만드는 방식이 다시 중요해졌어요
단일 페이지 앱은 브라우저에서 자바스크립트가 실행된 뒤 화면을 만들어요. 초기 응답에 내용이 적으면 첫 화면이 늦게 보이고 검색 로봇이 읽기 어려울 수 있어요. Next.js, Astro, SvelteKit, Nuxt 같은 메타 프레임워크는 서버나 빌드 시점에 HTML을 만들도록 선택지를 넓혔어요. SSR은 요청마다, SSG는 배포 전에, ISR은 일정 조건에 따라 정적 결과를 갱신해요.
서버가 만든 HTML을 브라우저에서 다시 동작하게 만드는 hydration에는 실행 시간과 전송량이 들어요. Astro의 Islands, Qwik의 Resumability, React Server Components는 브라우저로 보내는 자바스크립트를 줄이거나 실행 시점을 바꾸는 접근이에요. 2008년식 서버 HTML과 닮았지만, 지금은 정적 생성과 부분 상호작용, CDN 배포를 함께 고를 수 있다는 차이가 있어요.
TypeScript와 배포 도구가 기본 작업 방식도 바꿨어요
TypeScript는 큰 코드베이스에서 함수와 데이터 형태를 먼저 확인하게 해요. 리팩터링할 때 영향을 받는 곳을 찾기도 쉬워요. CSS 쪽에서는 Tailwind가 유틸리티 클래스 흐름을 넓혔고, 네이티브 CSS도 변수, nesting, container query를 지원하며 발전했어요. shadcn/ui는 패키지 내부 구현을 감추기보다 컴포넌트 소스를 프로젝트가 직접 소유하는 방식을 보여줘요.
배포는 FTP로 파일을 올리는 작업에서 Git push 중심으로 바뀌었어요. Vercel, Netlify, Cloudflare 같은 서비스는 커밋마다 빌드하고 PR마다 미리보기 주소를 만들어요. 서버리스 함수와 에지 실행 환경도 프론트엔드 저장소 안에서 서버 코드를 다루는 일을 늘렸어요. 화면 개발자가 빌드와 배포, 실행 위치까지 함께 판단하는 경우가 많아진 배경이에요.
AI가 진입 장벽을 낮춰도 기술 층은 사라지지 않아요
v0, Lovable, Bolt는 자연어 설명에서 동작하는 화면을 만들고, Cursor, Claude Code, Copilot은 기존 프로젝트 안에서 코드를 수정해요. 백엔드나 시스템 개발자도 짧은 시간에 프론트엔드 시제품을 만들 수 있어요. 원문 저자도 코딩 에이전트가 엔지니어링 분야 사이의 경계를 흐리는 상황에서 프론트엔드의 변화를 따라잡으려고 이 글을 썼다고 밝혀요. 2
생성 속도와 유지보수 판단은 별개예요. 에이전트가 만든 코드가 왜 hydration 오류를 내는지, 번들 크기가 왜 커졌는지, 서버 컴포넌트와 클라이언트 컴포넌트를 어디서 나눌지는 개발자가 확인해야 해요. 도구가 코드를 대신 입력해도 브라우저, 네트워크, 상태, 접근성에 대한 지식은 리뷰 기준으로 남아요.
왜 중요한가요
프론트엔드 도구를 이름순으로 외우면 변화가 불필요하게 복잡해 보여요. 각 도구가 해결한 문제를 따라가면 선택 기준이 선명해져요. 브라우저 상태 동기화가 문제라면 반응형 UI가 필요하고, 첫 화면과 검색 노출이 문제라면 서버 렌더링을 검토해요. 작은 정적 페이지에 대규모 상태 관리나 무거운 hydration을 먼저 넣을 이유는 적어요. 2
새 프로젝트에서는 익숙한 이름보다 필요한 층을 먼저 고르는 편이 좋아요. HTML과 CSS만으로 충분한 부분, 브라우저 상호작용이 필요한 부분, 서버에서 데이터를 읽어야 하는 부분을 나눠 보세요. 코딩 에이전트를 쓴다면 생성 결과가 추가한 의존성, 클라이언트로 보내는 자바스크립트 양, 키보드 조작과 오류 상태를 함께 확인해야 해요. 지난 20년의 도구는 모두 비용을 줄였지만, 그 비용이 다른 곳으로 옮겨갔는지도 살펴야 해요.
참고 자료
- 당신이 안 보는 사이 프론트엔드에 무슨 일이 있었나 — GeekNews
- The Descent — What Happened to the Frontend While You Weren't Watching — David Poblador i Garcia