Home

오늘의 기억

[Webpack] 사내 webpack 도입기 (1) - Legacy와 삽질


2015년 10월, 첫 회사에 입사 후 한 프로젝트의 유지보수 업무를 맡게 되었다. 그 프로젝트는 Java 기반의 JSP(Spring) + jQuery + 자체 JS 라이브러리로 구성된 웹 어플리케이션 이였다.

대학 시절 Java만 주도적으로 공부했고, 오로지 Java로만 프로젝트를 진행했던 나에게 JavaScript는 교육을 들은 적도, 공부한 적도 없었던 낯선 프로그래밍 언어였다. 그래서 그때부터 JavaScript 를 집중적으로 공부했으며 그것을 토대로 업무를 진행했다.

그러나 한 3개월정도 시간이 흘러 이런식으로 계속 개발하는건 몹시 비효율적이라는걸 깨닫게 되었다. 당시 여러가지 문제점이 있었지만, 그 중 하나는 JavaScript 소스 코드의 분산 이였다.

좀 더 자세하게 설명하자면 다음과 같다.

JavaScript 소스 코드 Import

해당 프로젝트에서는 View 단을 Tiles를 이용해 여러 JSP를 병합하여 관리했다. 그런데 JS 파일을 Import 하는 <script> 태그가 각종 JSP 에서 중구난방으로 사용되었던것이다.

따라서 특정 페이지가 있으면 그 페이지에서 사용하는 JS 파일을 찾는것 조차 쉽지 않았으며, 버그가 발견되면 그 페이지에서 사용하고있는 JS 파일을 찾는게 디버깅 1단계가 되어버렸다.

여기서 끝이 아니였다. JavaScript 소스가 JSP에 Inline으로 삽입된 경우도 존재했다. 이러니..디버깅이 쉬울리가

JavaScript 소스 코드의 충돌

Javascript 의 변수 선언은 함수 내에서 선언된 로컬 변수가 아니라면 전부 전역 변수로 선언된다. 현재 페이지에서 Import 된 JS 파일 조차 모르는데, 다른 JS 파일에서 사용되고 있는 전역 변수를 알 수 있을까? 답은 몹시 어렵다.

그럼 분명 현재 사용 중인 전역 변수인데, 다른 JS 파일에서 동일한 이름으로 사용한 경우.. 진짜 찾기 힘든 버그가 발생된다. (이런 문제 때문에 몇시간을 날린 적도..)

이런 상황을 대비해 JS 파일을 즉시 실행 함수로 감싸서 개발이 된 부분도 있었지만 반드시 전역 변수가 사용되어야 하는 경우가 많아 잘 지켜지지 않았다.

하나만 있어도 문제, 너무 많아도 문제

하나만 있어도 문제, 너무 많아도 문제.. 바로 JS 파일을 말하는 것이다.

한 번은 분리되어 있던 JavaScript 소스 코드를 하나의 JS 파일로 합친적이 있었다. 그랬더니 결과적으로 하나의 JS 파일이 2,000줄이 넘어가는 상황이 발생했다..맙소사..

다른 방법도 시도했다. JavaScript 모듈화랍시고 JS 파일을 쪼갤 수 있는건 전부 분리시켰다. 물론 디버깅은 전보다 편리해졌다. 그러나 마냥 좋은건 아니였다.

먼저 분리된 JS 파일끼리 데이터를 교환해야하는 경우가 많이 발생했다. 그럼 어쩔 수 없이 전역 변수를 사용해야했으며, 그만큼 관리도 힘들었다.

또한 분리 된 JS 파일을 각각 Import 하는 것도 일이였다. 그만큼 브라우저에서 Request 가 많이 발생되어 로딩 속도가 느려졌으며, 앞서 말한 JS 파일끼리 데이터를 교환해야하는 경우가 있으면 JS 파일의 Import 순서 또한 일정하게 맞춰야했다. 그러지 않으면 선언되지 않은 전역 변수를 사용할때 not defined 같은 에러가 발생되기 때문이다.


이러한 문제 때문에 여러가지 다양한 방법을 검색하고 시도를 해봤다.

JavaScript 소스 코드를 이용해 다른 JS 파일을 Import 하는 것도 시도해보고, 아무튼 이상한 방법을 많이 시도해봤지만 전부 다 실패로 돌아갔다.

당시 검색 결과 webpack 에 대해서도 많이 나오긴 했지만 ‘이런건 Node.js 환경에서만 가능한거 아닌가?’ 라는 의구심이 있어서 매번 지나치다가 어느날 문득 webpack 에 대해서 그냥 한 번 따라해보고 공부해 본 결과

답은 webpack 이였구나! 라고 깨닫게 되었다.


같이 보기

20180702 Charyum.Park