TOAST UI

지난 해 많은 개발자 도구들이 출시되었다. 그리고 그 개발자 도구들은 지난 몇 년 동안 webpack, Babel, Rollup, Parcel, create-react-app을 포함하는 프론트엔드 개발을 지배해 온 도구의 뒤를 따른다.

자바스크립트에서 다양한 종류의 에셋을 import 하는 방법을 알아보자.

최신 자바스크립트로 작성된 의존성 모듈과 결과물 중심으로 성능을 개선한다.

자바스크립트 코드 베이스가 다소 복잡하더라도, 배포(production) 모드와 개발(development) 모드의 코드를 다르게 번들링하고 실행할 수 있다. 배포 모드와 개발 모드의 코드를 다르게 번들링하고 실행시키는 것은 매우 강력한 기능이다. React의 개발 모드는 버그로 이어질만한 많은 부분을 미리 경고해주는 검증 코드가 포함되어 있다. 하지만, 이런 코드는 번들 크기를 증가시키고 앱 속도를 느리게 할 수 있다.

필자는 TOAST UI의 라이브러리 중 하나를 개발하고 있고 그동안 쌓은 경험과 노하우를 대방출하고자 한다. 이 글은 UI 라이브러리를 만드는데, 라이브러리의 목표와 기능, 사용한 기술 스택 그리고 웹팩 설정까지 바로 적용할 수 있는 실용적인 내용으로 구성하였다. UI 라이브러리를 만드는 방법과 노하우 A to Z를 알고 싶다면 노트북을 준비하고 차근차근 따라해보자.

필자는 Stanley Black & Decker의 Industry 4.0 팀에서 일하고 있다. 최근 우리 팀은 세계적인 Stanley의 제조 공장을 위해 앱 스토어와 같은 것을 만들었다.

자바스크립트 개발을 하다 보면 다양한 모듈 정의 방법을 마주치게 된다. ES 모듈, CommonJS 모듈, AMD 모듈 등 자바스크립트에는 다양한 모듈 시스템이 공존하는데, 각 모듈은 모두 다른 방식으로 모듈을 정의하며 객체를 내보내고 가져오도록 설계되어있다. 그러나 React, Vue 등의 프레임워크로 애플리케이션을 개발해 본 독자라면, 모듈을 가져올 때 이러한 다양한 모듈 포멧을 신경쓰면서 사용해 본 기억이 없을 것이다. 그동안 번들러를 사용해서 ES6 환경으로 개발을 할 때 CommonJS 모듈을 ES6의 'import' 문법으로 가져오더라도 에러가 발생하지 않는 게 의심스럽지는 않았는가? ES 모듈의 'import ~ from ~;' 문법을 통해서 가져와도 잘 동작하니까 "그냥" 사용하지는 않았는가? 이제 슬슬 마음속에 "번들러나 타입스크립트 컴파일러 안에서 도대체 무슨 일이 일어나고 있는 걸까?"라는 질문이 떠오르길 바란다. 그렇다면 이 글을 통해 ES 모듈에만 있는 방법인 default import(이하 기본값 가져오기)를 이용해서 다른 방식의 모듈을 가져와 사용할 수 있는 이유, 그리고 번들러와 트랜스파일러 그리고 타입스크립트는 어떤 방법으로 서로 다른 모듈끼리 가져오기를 지원하는지 알아보도록 하자.

오늘날 웹 애플리케이션들은 굉장히 크고, 대부분 자바스크립트로 만들어진 것이다. 2018년 중순, HTTP Archive가 보여준 모바일 장치에서 자바스크립트의 평균 전송 크기는 약 350 KB 이다.

최근에 새로운 프로젝트를 진행하게 되면서 기존에 간만 살짝 보고 있던 뷰(Vue, 이하 뷰)를 본격적으로 도입하게 되었다. 사실 팀에서는 리액트를 선호하고 있었으나 회사 내부에서 뷰의 사용이 빠른 속도로 증가하고 있었고 그에 따라 팀내에서도 뷰에 대한 전문성이 필요하게 되었다. 뷰와 리액트는 서로 영향을 주고받고 발전해나가는 도구들이라 비슷한 부분이 많아 큰 어려움 없이 적응할 수 있었다. 새로운 프로젝트에서는 뷰를 사용하는것 뿐 아니라 다른 개발 환경도 요즘 것들로 업그레이드 해봤다. 웹팩 4 사용하고 테스트 러너도 기존에 팀 내에서 표준처럼 사용하던 카르마(Karma)에서 요즘(이미) 잘나가는 제스트(Jest)로 새롭게 시도해봤다.

기존의 프론트엔드 자바스크립트는 특별히 모듈화나 디펜던시관리에 대한 방법이 없어 필요한 자바스크립트 파일을 정해진 순서에 맞게 직접 스크립트 태그로 로드하고 각각 약속된 네임스페이스에 담아 공유했었다. 이런 방식은 프로젝트가 커질수록 그리고 참여 개발자가 많을수록 문제를 일으켰다.