Posts [프론트엔드 개발환경의 이해와 실습] 프론트엔드 개발환경의 이해: NPM
Post
Cancel

[프론트엔드 개발환경의 이해와 실습] 프론트엔드 개발환경의 이해: NPM

몇 년 전부터 프론트엔드 개발자 채용 공고에 Node.js 기술이 우대 사항 항목으로로 추가 되었다. Node.js는 백엔드를 구현하는 기술이라고 생각했다면 이 채용 항목이 의문이었을지 모르겠다. 웹 어플리케이션 개발에 직접적으로 사용하는 것은 아니지만 개발 환경을 이해하고 구성하는데 Node.js를 모르면 언젠가는 한계에 부딪히게 될 것이다.

프론트엔드 개발에 Node.js가 필요한 이유

1) 최신 스펙으로 개발할 수 있다.

자바스크립트 스펙은 빠르게 발전하고 있는데 이에 비해 브라우저의 지원 속도는 항상 뒤쳐진다. 아무리 편리한 스펙이 나오더라도 이것을 브라우저에서 작동하도록 구현해주는 징검다리 역할(바벨, 웹팩, npm)이 필요하다.

마찬가지로, Typescript, Sass 같은 고수준 프로그래밍 언어를 사용하려면 전용 트랜스파일러(프론트엔드에 이해가 부족한 사람들은 컴파일러라고 이해하면 쉽다)가 필요한데 이것 역시 Node.js 환경이 뒷받침 되어야 한다.

2) 빌드 자동화

과거처럼 코딩 결과물을 브라우저에 바로 올리는 경우는 흔치 않다. 파일을 압축하고, 코드를 난독화하고, 폴리필을 추가하는 등 개발 이외의 작업을 거친후 배포한다. Node.js는 이러한 일련의 빌드 과정을 이해하는데 적지 않은 역할을 하며, 라이브러리의 의존성을 해결하고, 각종 테스트를 자동화하는데도 사용된다.

3) 개발 환경 커스터마이징

React의 CRA, Vuejs의 vue-cli를 사용하면 손쉽게 개발환경을 갖출 수 있다. 그러나 이렇게 손쉽게 구축한 개발환경을 그대로 사용할 수는 없을 것이다. 커스터마이징이 필요하게 될텐데 이때 Node.js 에 대한 지식이 필요하다.

(일반적인 실무 애플리케이션은 CRA로 구축하는게 거의 없다. 거의 직접 초기 세팅을 일일히 하는 경우가 대부분일 것이다.)

이러한 이유들로 인해 Node.js는 프론트엔드 개발에서 필수 기술로 자리매김하고 있다.

1) IIFE 방식의 모듈

이러한 문제를 예방하기 위해 스코프를 사용한다. 함수 스코프를 만들어 외부에서 안으로 접근하지 못하도록 공간을 격리하는 것이다. 스코프 안에서는 자신만의 이름 공간이 존재하므로 스코프 외부와 이름 충돌을 막을 수 있다.

  • math.js
1
2
3
4
5
6
7
8
var math = math || {} // math 네임스페이스

;(function () {
  function sum(a, b) {
    return a + b
  }
  math.sum = sum // 네이스페이스에 추가
})()

같은 코드를 즉시실행함수로 감쌌기 때문에 다른 파일에서 이 안으로 접근할 수가 없다. 심지어 같은 파일일지라도 말이다. 자바스크립트 함수 스코프의 특징이다. ‘sum’이란 이름은 즉시실행함수 안에 감추어졌기 때문에 외부에서는 같은 이름을 사용해도 괜찮다. 전역에 등록한 ‘math’라는 이름 공간만 잘 활용하면 된다.

2) 다양한 모듈 스펙

이러한 방식으로 자바스크립트 모듈을 구현하는 대표적인 명세가 AMD와 CoomonJS다.

ComonJS

자바스크립트를 사용하는 모든 환경에서 모듈을 하는 것이 목표이다. exports 키워드로 모듈을 만들고 require() 함수로 불러 들이는 방식이다. 대푲거으로 서버 사이드 플랫폼인 Node.js에서 이를 활용한다.

  • math.js
1
exports function sum(a, b) { return a + b; }
  • app.js
1
2
const math = require("./math.js")
math.sum(1, 2) // 3

AMD

AMD(Asynchronous Module Definition)는 비동기로 로딩되는 환경에서 모듈을 사용하는 것이 목표다. 주로 브라우져 환경이다.

UMD

UMD(Universal Module Definition) 는 AMD기반으로 CommonJS 방식까지 지원하는 통합 형태다.

이렇게 각 커뮤니티에서 각자의 스펙을 제안하다가 ES2015에서 표준 모듈 시스템을 내 놓았다. 지금은 바벨과 웹팩을 이용해 모듈 시스템을 사용하는 것이 일반적이다. ES2015 모듈 시스템의 모습을 살펴보자.

  • math.js
1
2
3
export function sum(a, b) {
  return a + b
}
  • app.js
1
2
import * as math from "./math.js"
math.sum(1, 2) // 3

export 구문으로 모듈을 만들고 import 구문으로 가져올 수 있다.

3) 브라우져의 모듈 지원

안타깝게도 모든 브라우져에서 모듈 시스템을 지원하지는 않는다. 인터넷 익스플로러를 포함한 몇 몇 브라우져에서는 여전히 모듈을 사용하지 못한다.

가장 많이 사용하는 크롬 브라우져만 잠시 살펴보자. (버전 61부터 모듈시스템을 지원 한다)

  • index.html
1
<script type="module" src="app.js"></script>

<script> 태그로 로딩할 때 type="text/javascript" 대신 type="module"을 사용한다. app.js는 모듈을 사용할 수 있다.

그러나 분명 그 당시에 누군가는 브라우져에 무관하게 모듈을 사용하고 싶은 욕구가 있었을 것이다. 이러한 욕구를 해결하기 위해 웹팩이 등장하게 되었다.

출처

This post is licensed under CC BY 4.0 by the author.

[프론트엔드 개발환경의 이해와 실습] 웹팩이 필요한 이유와 기본 동작

[프론트엔드 개발환경의 이해와 실습] 엔트리/아웃풋 실습