웹팩은 왜 필요할까
단일 페이지 애플리케이션과 웹팩의 관계
불과 20년 전 인터넷에는 웹 사이트에 자바스크립트가 많이 사용될 일이 적었습니다. 자바스크립트를 HTML에 효과를 더해주는 정도로 사용하는 일이 많았습니다.
축구팀 아약스 아니고 비동기적 자바스크립트와 XML역사의 분기점은 2006년 구글에서 만든 ajax라 말할 수 있습니다. ajax는 페이지를 전환하지 않고도 사용자의 인터렉션에 따라 데이터를 처리할 수 있게 해 줬는데, 이를 바탕으로 제작된 게 구글 맵(https://www.google.com/maps)입니다. 구글의 혁명적인 발전을 따라 웹 페이지에서 참조되는 자바스크립트 코드도 증가하기 시작했습니다.
웹 개발자에게 날개를 달아준 Nodejs2009년 두 번째 역사적인 순간이 찾아옵니다. 바로 Node.js의 탄생입니다. 웹 개발자가 수 없이 사용하는 노드와 npm 그리고 그 아래에 딸린 수많은 라이브러리들과 서비스는 이 시점을 기준으로 폭발적으로 증가합니다. Node.js를 기준으로 자바스크립트는 웹에서 강력한 지위를 얻었을 뿐 아니라 타 플랫폼까지 넘볼 수 있게 됐습니다. 이는 Node.js가 JavaScript runtime built on Chrome's V8JavaScript engine 이기 때문인데 쉽게 이야기하면 자바스크립트만을 사용해 윈도우 앱, 모바일 앱, 그 밖의 어떤 앱도 구축할 수 있게 됐다고 보시면 됩니다.
그렇습니다. 대(大) 자바스크립트의 시대의 도래입니다.
웹팩을 이야기하는데 왜 웹 개발의 역사를 이야기하는지 궁금하실 수 있습니다. 이제부터 웹팩의 중요성을 이야기하겠습니다.
대 자바스크립트의 시대는 필연적으로 많은 '자바스크립트 파일의 참조'를 야기시켰습니다. C++이나 JAVA에서 사용되는 모듈 시스템이 자바스크립트에 적극적으로 사용되기 시작했고, 이 과정에서 모듈을 참조하고, 최적화하고, 압축하고, 배포하는 최적화된 도구가 필요했습니다. 눈치채셨겠지만 이 도구가 바로 웹팩입니다.
웹팩은 수많은 자바스크립트 파일에서 발생하는 참조를 반영해 배포에 최적화된 상태로 코드를 압축하고, 묶어줍니다. 그럼 이렇게 물어보시는 분들이 있을 수 있습니다.
웹팩으로 꼭 묶지 않아도 작은 서비스는 배포해도 되지 않을까요?
초창기에 웹은 페이지에 따라 HTML 파일을 새로 그리는 방식이었습니다. 원시적인 DOM 컨트롤이라 할 수 있습니다. 반면 지금은 어떤가요? 작은 프로젝트를 만들 때도 리액트와 뷰 등을 사용해 만듭니다. HTML 파일을 직접 하나하나 작성하는 것보다 훨씬 더 생산성이 나오기 때문입니다.
리액트나 뷰에선 가상 DOM을 사용합니다. 가상 DOM이란 타깃 엘리먼트에 동적으로 DOM을 생성하고, 페이지 변화나 상태 변화에 따라 최소한의 부분만 DOM을 수정할 수 있습니다. 결과적으로 전체 페이지를 렌더 하지 않고, 일부분만 변경함으로써 자원을 아낄 뿐만 아니라 애플리케이션처럼 동작할 수 있게 합니다. 더 쉽게 말하면 페이지를 전환할 때도 화면이 다 바뀔 필요 없이 변화가 가능해집니다.
이와 같은 방식을 SPA, 단일 페이지 애플리케이션(Single Page Application)이라 부릅니다. SPA로 제작된 웹사이트는 당연하겠지만 가상 DOM이 변화하면서 페이지를 그리기 때문에 하나의 페이지에서 어마어마하게 많은 자바스크립트 파일을 참조하게 됩니다.
바꿔 말하면 우리가 리액트나 뷰를 사용해 웹앱을 개발할 때 웹팩을 사용하지 않는다는 건 현명한 방법이 아닙니다. 특히나 리액트와 뷰 모두 프로젝트 생성을 할 때 웹팩 설정까지 모두 마친 상태로 프로젝트를 만들 수 있기 때문에(create-react-app, vue-cli) 웹팩을 굳이 뺄 이유도 없습니다.
원래 어떤 개념을 알기 위해선 그전의 배경을 잘 알아야 기억이 더 오래 남는다고 합니다. 이런 이유에서 웹팩이 나오게 된 배경과 SPA에서 웹팩이 핵심적인 역할을 하는지 살펴봤습니다. 혹시라도 웹 개발의 역사와 구조에 대해서 궁금하시다면 아래의 글을 읽어보시는 걸 추천드립니다.
