프론트엔드 기술은 왜 이렇게 복잡해졌는가
웹은 1989년 CERN의 팀 버너스리가 연구 문서를 링크로 잇기 위해 만든 공유 시스템으로 출발했습니다. 1991년 HTML, URL, HTTP 세 가지가 등장했을 때 웹페이지는 링크 달린 텍스트가 전부였습니다. 꾸미고 싶다는 요구에 1996년 CSS가 구조와 표현을 분리했고, 반응하는 화면을 위해 1995년 자바스크립트가 단 10일 만에 만들어졌습니다.
코드가 폭발하자 2006년 jQuery가 브라우저마다 달랐던 DOM 조작을 통일했고, 그것으로도 부족해지자 2013년 페이스북이 '데이터가 바뀌면 화면은 알아서 바뀐다'는 철학의 React를 내놓았습니다. 부품을 가져다 쓰려고 npm이 생겼고, 브라우저가 못 읽는 최신 문법을 옮기고 흩어진 파일을 묶으려고 트랜스파일링·번들링·트리셰이킹 같은 빌드 과정이 생겼습니다. 모든 기술이 앞 기술이 만든 문제의 답입니다.
개념을 알면 AI에게 내리는 지시가 어떻게 달라지는가
package.json이 왜 생기는지 묻는 사람과 '부품 목록이 기록되는 파일이구나'라고 이해하는 사람은 같은 도구를 써도 다른 결과를 냅니다. 전자의 지시는 '버튼 예쁘게 만들어 줘'에 머물고, 후자는 '이 데이터가 바뀌면 저 화면도 같이 바뀌게 해 줘', 곧 상태 관리를 요구하는 수준까지 올라갑니다.
장바구니에 담은 상품이 페이지를 옮겨도 남아 있어야 한다는 요구가 곧 상태(state)이고, 카드 틀 하나를 만들어 1,000번 찍어내는 것이 컴포넌트입니다. 이 개념이 머리에 있으면 AI가 짠 코드가 어디서 꼬였는지도 짚어낼 수 있습니다.
SPA로 갔다가 왜 SSR로 돌아왔는가
앱처럼 깜빡임 없이 화면이 전환되기를 바라는 요구에서 HTML 파일 하나로 자바스크립트가 화면을 갈아 끼우는 SPA가 나왔습니다. 그런데 검색 엔진 크롤러는 자바스크립트가 실행되기 전의 빈 껍데기만 보고 떠나고, 초기 로딩은 눈에 띄게 느려졌습니다.
그래서 서버가 완성된 HTML을 먼저 내려주는 SSR이 다시 주목받았습니다. 정적인 HTML에 자바스크립트를 주입해 살려내는 하이드레이션, 페이지마다 두 방식을 섞는 Next.js식 하이브리드가 지금의 표준입니다. 카카오톡에 URL을 붙였을 때 뜨는 미리보기도 SSR 환경이라야 제대로 동작합니다. 기술은 항상 트레이드오프이고, 문제를 풀면 새 문제가 생기는 방식으로 진화합니다.
비개발자 바이브 코더는 무엇부터 배워야 하는가
문법 암기가 아니라 이 진화의 지도가 먼저입니다. 지도가 있으면 npm install이 앱스토어에서 부품을 받아 조립하는 과정이라는 것, 내가 쓴 코드와 실제 배포되는 코드가 빌드를 거쳐 달라진다는 것이 자연스럽게 이해됩니다. SH Consulting이 바이브 코딩 교육에서 도구 사용법보다 기술의 역사를 먼저 꺼내는 이유도 여기에 있습니다. 개념을 모르면 AI에게 시킬 수 있는 일의 수준이 거기서 멈춥니다.