번들링(Bundling)이란?

번들링(Bundling)

프로그래밍을 하다보면 자주 마주치는 단어 중에 번들링이란 단어가 있습니다. 번들이라는 것은 묶는다는 뜻으로 뭔가를 묶는 작업이라는 걸 이름에서 유추할 수가 있죠. 그렇다면 이게 당연히 파일을 묶는 것일테고 어째서 파일을 묶는 작업이 필요한걸까 생각해 볼 수 있습니다.

 

정확하게 번들링이란 모듈들의 의존성 관계를 파악하여 그룹화시켜주는 작업을 뜻합니다. 모듈(module)이란 분리된 파일입니다. 즉, 분리된 녀석들을 하나로 합쳐주는 구나 라고 이해할 수 있습니다.

 

그렇다면 애초부터 왜 멀쩡한 파일을 모듈로 분리했던 걸까요? 그건 작업의 효율성을 위해서입니다. 스크립트의 크기가 점점 커지고 복잡해지면서 단순히 하나의 파일이나 클래스로만 관리하기에는 그 복잡성이 프로그래머가 감당할 수준이 아니게된거죠. 그렇기 때문에 머리, 가슴, 팔, 다리를 따로 떼어서 모듈로서 작업을 할 필요가 생긴겁니다.

 

그렇다면 당연히 머리, 가슴, 팔, 다리 같은 각각의 모듈들은 그거 하나만으로 존재하는 독립적인 존재가 아닐겁니다. 머리가 하나만 있다면 그냥 시체겠죠. 다른 모듈들과의 연계성을 당연히 띄어야 해요. 그래서 모듈 내부에는 import로 외부모듈의 기능을 가져오고 export로 외부 모듈에서의 접근을 허용하여 모듈의 기능을 내보냅니다.

 

어? 그러면 그냥 모듈끼리 import하고 export하면 되지 번들링이 필요해? 라는 의문에는 이렇게 대답할 수 있습니다.

 - 하나. 여러 개의 파일을 브라우저에서 로딩한다면 네트워크가 그만큼 소모되어 속도가 저하될 수 있습니다.

 - 둘. 모듈 간의 변수 충돌 등의 위험성이 존재합니다. 

 

이렇게 각각의 분리된 자바스크립트(꼭 자바스크립트에 한정되지는 않습니다)를 모아서 묶어주는 작업을 하는 게 번들링입니다. 그렇다면 이러한 번들링 작업을 하는 도구는 어떤게 있을까요?

 

번들링 도구들은 RequireJS, Browserify, Rollup, Parcel 등이 있습니다. 하지만 가장 많이 쓰이는 건 역시 Webpack입니다. 번들링 도구라고해서 하는 작업은 다 비슷할 텐데 왜 Webpack이 인기를 끄는 걸까요? 그건 웹팩의 우수한 성능 때문입니다.

 

모듈화 작업을 하는 방식에는 CommonJS, AMD, UMD, ES6 모듈 등같은 모듈 명세들이 다양하게 존재합니다. 웹팩은 이 모두를 지원해주죠. 그리고 파일 분할 기능이 있어서 원하는 코드만 따로 분리해서 압축하는 것도 가능합니다. 뿐만 아니라 CSS 로더의 기능과 리액트의 JSX 변환 작업도 해주기 때문에 모던 자바스크립트 개발을 할 때 상당히 유용합니다. 

 

이런 장점 때문에 크고 복잡하며 다양한 리소스들이 존재하는 프로젝트에는 웹 팩을 사용하는 것이 좋습니다.

반면 Grunt와 Gulp는 의존성에 대한 개념이 없으며 오로지 리소스들에 대한 툴로 사용됩니다.

그리고 Brwosify는 웹팩과 비슷한 도구지만 속도면에서는 웹팩보다 조금 떨어집니다.

 

Browserify

제가 현재 참고하는 깃허브 링크가 Browserify를 사용하고 있기 때문에 여기에 대해서 좀 더 깊게 파보려고 합니다.

사실 웹팩의 등장으로 이 도구에 대한 지분은 상당히 줄었다고 봐야죠. 이 도구는 CommonJS를 사용합니다. 

 

CommonJS란?
자바스크립트의 모듈화를 위한 움직임은 예전의 최대 이슈거리였습니다. 그때 CommonJS는 자바스크립트를 범용적으로 사용하기 위한 모듈의 명세를 만듭니다. 모듈을 어떻게 정의하고 사용할 것인지를 제안한거죠. 제안한 내용은 다음과 같습니다.

스코프(Scope) : 모든 모듈은 자신만의 독립적인 실행 영역이 있어야한다.
정의(Definition) : 모듈 정의는 exports 객체를 이용한다
사용(Usage) : 모듈 사용은 require 함수를 이용한다.

여기에 의하면 exports는 단순히 모듈의 기능을 내보내는 게 아닌 모듈을 정의하는 개념인 셈이죠. 다른 모듈은 require를 이용하여 그걸 받아와 사용하는 겁니다.

그런데 문제는 스코프입니다. 모듈만의 독립적인 실행 영역이 있어야하기 때문에 모듈의 지역변수와 전역변수를 구분지을 필요가 생깁니다.

자바스크립트가 서버사이드에서 동작한다면 파일마다 독립적인 파일 스코프를 가지기에 상대적으로 작성이 쉽습니다. 전역 변수가 겹치지 않기 때문이죠. 다만 이런 경우에서는 서버사이드에서 필요한 모듈을 전부 로드하고 처리해야하기 때문에 로딩에 시간이 조금 걸릴 수 있습니다.

그렇다고 자바스크립트를 서버사이드가 아니라 클라이언트 브라우저에서 동작시킨다면 또 문제가 생깁니다. 왜냐하면 브라우저에서 동작할 때는 파일의 독립적인 스포크가 없기 때문입니다. 그래서 서로 모듈을 불러온다면 전역변수가 겹치는 일도 발생할 수 있습니다.

이런 문제를 해결하기 위해 CommonJS는 서버 모듈을 비동기적으로 클라이언트 브라우저에 전송할 수 있는 모듈 전송 포맷을 추가로 정의했습니다. 여기에 대해서는 나중에 필요할 때 언급하도록 하죠!

 

참고로 nodejs도 동일하게 commonJS 모듈 방식을 사용합니다. 

npm install -g brwoserify

설치는 위와 같이 진행하도록 합니다.

browserify <소스 이름> -o <결과물 이름>

사용 방법은 간단합니다. 위와 같이 번들링할 소스와 번들링 후의 작업 결과물의 이름을 설정해주기만하면 됩니다. 이때 번들링할 타겟의 require을 따라서 의존성을 모두 찾아내 번들링을 진행하기 때문에 소스는 당연히 최상의 루트 파일이 되어야 합니다.

 

오늘은 이렇게 아~주 간단하게 번들링에 대하여 알아보았습니다.

그럼 이만🖐🖐🖐🖐

 

 

 

참고

JavaScript 표준을 위한 움직임: CommonJS와 AMD (naver.com)

[ModuleBundler][Browserify]js를 하나의 파일로 묶기, browserify설치 및 사용법 :: Kamang's IT Blog (tistory.com)