자바스크립트 스코프 호이스팅은 망가졌습니다

두 가지 방식 비교:

// 함수 래퍼 방식 (전통적)
let modules = {
  'index.js': (require, exports) => {
    let { add } = require('math.js');
    console.log(add(2, 3));
  },
  'math.js': (require, exports) => {
    exports.add = (a, b) => a + b;
  },
};

// 스코프 호이스팅 (Rollup 이후)
function add(a, b) { return a + b; }
console.log(add(2, 3));

호이스팅은 함수 래퍼·require/exports 오버헤드를 없애지만, 대신 모듈 경계를 잃는다.

원래 entry-a 실행 순서가 shared1 → a1 → shared2 → a2 인데, 공유 번들로 추출 + 호이스팅 후엔 shared1 → shared2 → a1 → a2 가 된다. 부작용을 가진 모듈에서 "수입 순서대로 부작용이 실행된다"는 자바스크립트 모듈의 약속이 깨지는 셈.

// 원본
import * as foo from './foo';
foo.bar(); // this === foo (모듈 객체)

// 호이스팅 후
bar(); // this === undefined (strict)

네임스페이스 객체를 거치지 않고 직접 호출되어 this 가 사라진다. re-export 가 섞이면 더 복잡 — this 는 "함수가 선언된 모듈"이 아니라 "가져온 모듈"이어야 한다.

공유 모듈만 함수로 감싸 호출 순서를 명시화:

// shared.bundle.js
export default {
  shared1: () => console.log('shared1'),
  shared2: () => console.log('shared2'),
};

// entry-a.bundle.js
import modules from 'shared.bundle.js';
modules.shared1();
console.log('a1');
modules.shared2();
console.log('a2');

이게 본질적으로 Parcel 의 동작 방식이며, webpack 의 ModuleConcatenationPlugin 은 "같은 번들 안에서만" 부분 호이스팅을 시도한다.

호이스팅은 트리 셰이킹 의 전제조건이라는 통념도 정확하지 않다. 번들러가 자체 정보를 가지면 함수로 감싸진 모듈에서도 트리 셰이킹이 가능. 또한 "함수 래퍼의 런타임 비용" 은 2016년 Nolan Lawson 측정 이후 V8 발전으로 격차가 줄었다 — 게다가 lazy 평가가 "한 번에 평가"보다 빠를 수도 있다.

[감점 답변] "같은 거다". [좋은 답변] 다른 최적화다. 트리 셰이킹은 "안 쓰는 export 제거"(빌드 타임 정적 분석), 호이스팅은 "모듈을 같은 스코프로 인라인"(런타임/번들 크기 최적화). 호이스팅이 트리 셰이킹을 더 쉽게 만들어 준 건 사실이지만 필수 조건은 아니다 — 번들러가 정보를 직접 수집하면 함수 래퍼 모듈에서도 가능.

[감점 답변] "순서가 바뀐다" 한 줄. [좋은 답변] (1) 부작용 순서 변경 — shared1 → a1 → shared2 → a2 가 shared1 → shared2 → a1 → a2 가 된다(폴리필·로깅 깨짐). (2) this 바인딩 손실 — import * as foo 후 foo.bar() 가 그냥 bar() 가 되어 this === undefined. 두 사례를 코드 스니펫으로 즉시 보일 수 있어야 한다.

[감점 답변] "webpack 방식이 더 빠르다". [좋은 답변] webpack 은 같은 번들 내 모듈을 부분 호이스팅하다가 부작용·동적 import·side effects 등이 보이면 bailout. Parcel 은 기본 함수 래퍼로 정확성을 우선하고 가능한 곳만 호이스팅. "속도 vs 정확성"의 다른 디폴트라는 관점이 답.