내장 프로토타입 확장이 나쁜 이유는?

Array, String 등 내장 객체의 프로토타입을 확장할 때 발생하는 충돌과 예측 불가능한 동작을 이해합니다

심화 15분 내장 프로토타입 확장 금지 충돌 예측 불가능성

JavaScript의 내장 객체인 Array, String, Object 등의 프로토타입을 확장하는 것은 과거에는 흔한 패턴이었지만, 현대 JavaScript 개발에서는 피해야 할 안티패턴으로 간주됩니다. 내장 프로토타입을 수정하면 전역 네임스페이스를 오염시키고, 다른 라이브러리나 미래의 JavaScript 표준과 충돌할 위험이 있습니다. 특히 for…in 루프에서 예상치 못한 속성이 노출되거나, 여러 라이브러리가 같은 메서드 이름으로 프로토타입을 확장할 때 심각한 버그가 발생할 수 있습니다. 이러한 문제는 디버깅이 매우 어렵고, 애플리케이션의 안정성을 크게 해칠 수 있습니다.

핵심 문제점

  • ⚠️ 전역 오염: 모든 인스턴스에 영향을 미쳐 예측 불가능한 동작 발생
  • 🔄 라이브러리 충돌: 서로 다른 라이브러리가 같은 메서드 이름으로 확장 시 덮어쓰기 발생
  • 📊 열거 문제: for…in 루프에서 확장한 메서드가 의도치 않게 노출됨
  • 🚀 표준 충돌: 미래의 JavaScript 표준이 같은 이름의 메서드를 추가할 경우 호환성 문제 발생
  • 🐛 디버깅 어려움: 전역적으로 영향을 미치기 때문에 버그의 원인을 찾기 어려움

실무에서의 영향

내장 프로토타입 확장은 특히 대규모 프로젝트나 여러 개발자가 협업하는 환경에서 심각한 문제를 일으킵니다. 예를 들어, Array.prototype에 custom 메서드를 추가하면 프로젝트 내 모든 배열이 해당 메서드를 갖게 되어, 다른 개발자가 작성한 코드에 예상치 못한 영향을 미칠 수 있습니다. 또한 외부 라이브러리가 동일한 메서드 이름을 사용할 경우 둘 중 하나가 덮어써지면서 런타임 에러가 발생할 수 있습니다. 과거 MooTools 라이브러리가 Array.prototype.flatten을 확장했다가 나중에 JavaScript 표준에 같은 이름의 메서드가 추가되면서 호환성 문제가 발생한 사례는 이러한 위험성을 잘 보여줍니다. 현대 JavaScript에서는 유틸리티 함수, 클래스 상속, 또는 Symbol을 활용한 안전한 확장 방법을 사용하는 것이 권장됩니다. 이를 통해 코드의 예측 가능성과 유지보수성을 크게 향상시킬 수 있습니다.

핵심 개념

전역 네임스페이스 오염

입문

내장 프로토타입을 확장하면 그 타입의 모든 객체에 영향을 미쳐요. 마치 학교 전체 학생들의 가방에 몰래 물건을 넣는 것과 같아요!

🏫 학교 전체에 영향을 미치는 마법 여러분이 학교에 다닌다고 생각해보세요. 만약 누군가 “모든 학생 가방에 자동으로 새 연필이 들어가는 마법”을 걸었다면 어떨까요? 처음에는 좋아 보일 수 있지만, 이미 연필이 있는 학생들은 혼란스러울 거예요. Array.prototype을 확장하는 것도 이와 같아요. 프로그램의 모든 배열에 새 기능이 추가되는 거죠.

🎯 왜 전역 오염이라고 부르나요? ‘오염’이라는 단어를 쓰는 이유는 원하지 않는 곳까지 영향을 미치기 때문이에요. 마치 물에 잉크 한 방울을 떨어뜨리면 물 전체가 색깔이 변하는 것처럼, 하나의 프로토타입을 바꾸면 그 타입의 모든 객체가 바뀌어요.

🚨 어떤 문제가 생기나요? 여러분이 만든 코드뿐만 아니라 다른 사람이 만든 라이브러리 코드도 영향을 받아요. 만약 다른 개발자가 배열에 “size”라는 기능이 없다고 가정하고 코드를 작성했는데, 여러분이 Array.prototype.size를 추가했다면 그 개발자의 코드가 망가질 수 있어요.

💡 범위를 제한할 수 없나요? 일반 변수처럼 “이 파일에서만 사용”하는 방법이 없어요. 내장 프로토타입은 전역적으로 하나만 존재하기 때문에, 한 번 바꾸면 프로그램 어디서든 영향을 받아요. 이게 바로 가장 큰 문제예요!

중급

내장 프로토타입 확장은 해당 타입의 모든 인스턴스에 전역적으로 영향을 미칩니다. JavaScript에서 Array.prototype, String.prototype 같은 내장 프로토타입은 프로그램 전체에서 단 하나만 존재하는 공유 객체이므로, 이를 수정하면 모든 배열과 문자열이 영향을 받습니다.

전역 오염의 메커니즘 프로토타입 체인 메커니즘에 따라 모든 배열은 Array.prototype을 참조합니다. 따라서 Array.prototype에 메서드를 추가하면 프로그램 내 모든 배열 인스턴스에서 해당 메서드를 사용할 수 있게 됩니다. 이는 스코프 제한이 불가능하며, 모듈 시스템으로도 격리할 수 없습니다.

// 라이브러리 A가 확장
Array.prototype.first = function() {
  return this[0];
};

// 프로그램 전체의 모든 배열에 영향
const arr1 = [1, 2, 3];
const arr2 = ['a', 'b', 'c'];

console.log(arr1.first()); // 1
console.log(arr2.first()); // 'a'

// 다른 모듈이나 라이브러리의 배열도 영향 받음
import thirdPartyLib from 'some-library';
console.log(thirdPartyLib.getData().first()); // 예상치 못한 동작 가능

예측 불가능성 문제 전역 오염의 가장 큰 문제는 코드의 예측 가능성을 해친다는 점입니다. 어떤 파일에서 프로토타입을 확장했는지 추적하기 어렵고, 다른 개발자가 작성한 코드가 갑자기 예상치 못한 동작을 할 수 있습니다.

심화

내장 프로토타입 확장의 전역 오염은 JavaScript의 프로토타입 체인 메커니즘과 단일 전역 실행 컨텍스트(Global Execution Context)의 특성에서 비롯됩니다.

프로토타입 공유 메커니즘의 설계적 한계 ECMAScript 명세 9.1.1절 Ordinary Object Internal Methods에 따르면, [[GetPrototypeOf]] 내부 메서드는 객체의 프로토타입 참조를 반환합니다. 모든 배열 인스턴스는 동일한 Array.prototype 객체를 공유하며, 이는 %Array.prototype% 내부 슬롯(Intrinsic Object)으로 정의됩니다. 이 객체는 Realm(실행 환경) 당 하나만 존재하므로, 수정 시 해당 Realm의 모든 배열에 영향을 미칩니다.

프로토타입 조회 과정:

  1. 배열 인스턴스에서 속성 검색
  2. 없으면 [[GetPrototypeOf]]를 통해 Array.prototype으로 이동
  3. Array.prototype에서 속성 발견 시 반환

이 메커니즘은 메모리 효율성을 위해 설계되었지만, 전역 공유로 인한 부작용도 내포합니다.

Realm 격리의 한계 iframe이나 Web Worker 같은 별도 Realm을 사용하지 않는 한, 모듈 시스템(ES Modules)이나 클로저로도 프로토타입 오염을 격리할 수 없습니다. import/export는 스코프 격리를 제공하지만, 내장 프로토타입은 Realm 레벨에서 공유되기 때문입니다.

엔진 최적화와의 충돌 V8 엔진의 Hidden Class 최적화는 객체의 형태(shape)가 안정적일 때 최고 성능을 발휘합니다. 런타임에 프로토타입을 수정하면 모든 관련 Hidden Class가 무효화(invalidation)되어 성능 저하가 발생합니다. 특히 인라인 캐싱(Inline Caching)이 깨지면서 메서드 호출 성능이 최대 10배까지 느려질 수 있습니다.

라이브러리 간 충돌

입문

여러 라이브러리가 같은 이름으로 기능을 추가하면 나중에 추가된 것이 먼저 추가된 것을 덮어써서 문제가 생겨요!

🎨 같은 색 이름으로 그림 그리기 미술 시간에 친구들이 모두 “빨강”이라는 이름의 물감을 만든다고 상상해보세요. 한 친구는 진한 빨강을 만들고, 다른 친구는 연한 분홍을 만들어요. 그런데 모두 같은 통에 담으면 어떻게 될까요? 마지막에 넣은 색깔만 남고 다른 색은 사라져요. 프로토타입 확장도 이렇게 작동해요!

📚 도서관에서 같은 책 제목 문제 도서관에 같은 제목의 책이 있으면 혼란스러워요. “JavaScript 입문”이라는 책이 10권 있는데 모두 다른 저자가 쓴 거라면? Array.prototype.sum이라는 기능을 라이브러리 A와 B가 각각 다르게 만들면, 둘 중 하나만 살아남고 다른 하나는 사라져요.

🔄 덮어쓰기가 왜 위험한가요? 먼저 추가된 기능에 의존하는 코드가 있을 수 있어요. 라이브러리 A의 sum이 숫자를 더한다고 가정하고 코드를 짰는데, 라이브러리 B의 sum이 문자열을 합친다면 프로그램이 망가져요. 그런데 어떤 라이브러리가 덮어썼는지 알기도 어려워요!

🐛 버그를 찾기 어려운 이유 에러 메시지가 “sum이 없다”고 나오지 않아요. sum은 존재하지만 우리가 예상한 것과 다르게 동작할 뿐이에요. 이런 버그는 발견하기도 어렵고, 원인을 찾기는 더 어려워요.

중급

여러 라이브러리나 코드 모듈이 동일한 내장 프로토타입에 같은 이름의 메서드를 추가하면 충돌이 발생합니다. JavaScript에서는 객체 속성 덮어쓰기가 허용되므로, 나중에 로드된 라이브러리가 이전 라이브러리의 메서드를 완전히 대체하게 됩니다.

충돌 시나리오 대규모 프로젝트에서는 npm 패키지 의존성 트리가 복잡하게 얽혀 있습니다. 두 개의 서로 다른 패키지가 동일한 프로토타입 메서드를 정의하면, 로드 순서에 따라 동작이 달라집니다.

// 라이브러리 A (utility-lib-a.js)
Array.prototype.sum = function() {
  return this.reduce((a, b) => a + b, 0);
};

// 라이브러리 B (utility-lib-b.js)
Array.prototype.sum = function() {
  // 다른 구현: 절댓값의 합
  return this.reduce((a, b) => a + Math.abs(b), 0);
};

// 메인 코드
import 'utility-lib-a';
import 'utility-lib-b'; // 라이브러리 B가 A를 덮어씀

const numbers = [1, -2, 3];
console.log(numbers.sum()); // 6 (1 + 2 + 3)
// 라이브러리 A를 사용하는 코드는 4를 기대했지만 다른 결과 발생
// 기존 메서드 존재 여부 체크 시도
if (!Array.prototype.sum) {
  Array.prototype.sum = function() { /* ... */ };
}
// 문제: 먼저 로드된 라이브러리의 구현을 보존하지만,
// 나중 라이브러리의 기능을 사용하려는 코드는 실패함

운영 환경에서의 위험성 개발 환경에서는 문제가 없다가 프로덕션 빌드에서 의존성 번들링 순서가 바뀌면서 갑자기 충돌이 발생할 수 있습니다. Webpack, Rollup 같은 번들러의 최적화나 code splitting이 로드 순서를 변경할 수 있기 때문입니다.

심화

라이브러리 충돌은 JavaScript의 동적 속성 할당 메커니즘과 모듈 로딩의 비결정성(Non-determinism)에서 비롯됩니다.

속성 덮어쓰기의 명세적 정의 ECMAScript 명세 9.1.9절 [[Set]] 내부 메서드에 따르면, 객체에 속성을 설정할 때 기존 속성이 writable: true이면 값을 덮어씁니다. 내장 프로토타입의 속성은 대부분 writable: true, configurable: true로 정의되어 있어 덮어쓰기가 가능합니다.

// Array.prototype.sum 속성 디스크립터
Object.getOwnPropertyDescriptor(Array.prototype, 'sum');
// { value: function, writable: true, enumerable: false, configurable: true }

모듈 로딩 순서의 불확실성 ES Modules의 로딩 순서는 명세에서 구현 정의(Implementation-defined)로 남겨져 있습니다. 의존성 그래프가 순환 참조를 포함하거나 동적 import()를 사용할 경우, 실행 순서가 예측 불가능해집니다.

역사적 사례: MooTools vs ECMAScript 표준 MooTools 1.x는 Array.prototype.flatten을 독자적으로 구현했습니다. ECMAScript 2019에서 표준 Array.prototype.flat이 추가될 때, MooTools의 flatten과 동작이 달라 호환성 문제가 발생했습니다. TC39는 이를 “smooshgate”라 명명하고, 표준 메서드 이름을 flat으로 변경해야 했습니다.

Symbol을 활용한 충돌 회피 전략 Symbol은 고유하고 열거 불가능한(non-enumerable) 속성 키를 생성하여 충돌을 방지합니다:

const sumSymbol = Symbol('customSum');
Array.prototype[sumSymbol] = function() {
  return this.reduce((a, b) => a + b, 0);
};

// 다른 라이브러리와 절대 충돌하지 않음
[1, 2, 3][sumSymbol](); // 6

그러나 Symbol 확장도 여전히 전역 프로토타입을 수정하므로 권장되지 않으며, 유틸리티 함수 패턴이 더 안전합니다.

열거 속성 노출 문제

입문

프로토타입에 추가한 기능이 for…in 같은 반복문에서 예상치 못하게 나타나서 문제를 일으켜요!

🎒 가방 속 물건 세기 가방 안의 물건을 하나씩 꺼내서 센다고 상상해보세요. 여러분의 물건만 세고 싶은데, 가방 자체에 붙어있는 주머니와 지퍼까지 함께 세어진다면 어떨까요? 실제 물건 개수가 5개인데 10개로 나오는 거예요. for…in 반복문이 프로토타입의 속성까지 세는 것이 바로 이런 상황이에요.

📝 목록 작성의 혼란 학급 학생 명단을 작성한다고 해요. 학생 이름만 적어야 하는데, “출석부”, “의자”, “칠판” 같은 교실 물건 이름까지 목록에 추가된다면? 프로토타입에 추가한 메서드가 for…in에서 나타나는 것이 이런 상황이에요.

🔍 왜 이런 일이 생기나요? for…in 반복문은 객체 자신의 속성뿐만 아니라 프로토타입 체인의 속성까지 모두 확인해요. 그래서 Array.prototype에 추가한 메서드도 배열을 반복할 때 함께 나타나는 거예요.

✅ 해결 방법은 없나요? hasOwnProperty로 체크하면 자기 자신의 속성만 골라낼 수 있어요. 하지만 모든 코드에서 이걸 빠뜨리지 않고 사용해야 한다는 게 문제예요. 한 번이라도 잊어버리면 버그가 생겨요!

중급

프로토타입에 추가한 속성은 기본적으로 열거 가능(enumerable)하므로, for…in 반복문이나 Object.keys() 같은 열거 메서드에서 의도치 않게 노출됩니다. 이는 객체의 속성을 순회하는 코드에서 예상치 못한 동작을 유발합니다.

열거 가능성의 기본값 일반적인 속성 할당(=)으로 추가한 속성은 enumerable: true가 기본값입니다. 반면 내장 메서드들은 enumerable: false로 정의되어 있어 for…in에 나타나지 않습니다.

// 프로토타입 확장
Array.prototype.sum = function() {
  return this.reduce((a, b) => a + b, 0);
};

const arr = [1, 2, 3];
arr.customProp = 'test';

// for...in은 프로토타입 속성까지 순회
for (let key in arr) {
  console.log(key);
  // 출력: 0, 1, 2, customProp, sum
  // sum이 예상치 않게 포함됨
}

// hasOwnProperty로 필터링 필요
for (let key in arr) {
  if (arr.hasOwnProperty(key)) {
    console.log(key); // 0, 1, 2, customProp
  }
}
// defineProperty로 열거 불가능하게 설정
Object.defineProperty(Array.prototype, 'sum', {
  value: function() {
    return this.reduce((a, b) => a + b, 0);
  },
  enumerable: false,  // for...in에서 숨김
  writable: true,
  configurable: true
});

const arr = [1, 2, 3];
for (let key in arr) {
  console.log(key); // 0, 1, 2 (sum은 나타나지 않음)
}

문제의 근본 원인 그러나 enumerable: false를 설정하더라도 프로토타입 확장의 다른 문제들(전역 오염, 충돌)은 여전히 남아있습니다. 따라서 근본적인 해결책은 프로토타입 확장을 피하는 것입니다.

심화

열거 속성 노출은 ECMAScript의 속성 열거 메커니즘과 프로토타입 체인 탐색의 상호작용에서 발생합니다.

속성 열거의 명세적 정의 ECMAScript 명세 13.7.5절 for-in 문에 따르면, for-in은 EnumerateObjectProperties 추상 연산을 호출합니다. 이 연산은 다음 순서로 속성을 수집합니다:

  1. 객체 자신의 열거 가능한 속성
  2. [[GetPrototypeOf]]로 프로토타입 체인 탐색
  3. 각 프로토타입의 열거 가능한 속성 추가
  4. 중복 제거 (같은 키는 한 번만)

Property Descriptor의 enumerable 플래그 속성의 열거 가능성은 Property Descriptor의 enumerable 속성으로 제어됩니다:

// 일반 할당
Array.prototype.method1 = function() {};
// [[Enumerable]]: true (기본값)

// defineProperty 사용
Object.defineProperty(Array.prototype, 'method2', {
  value: function() {},
  enumerable: false  // 명시적으로 false 설정
});
// [[Enumerable]]: false

내장 메서드들은 모두 enumerable: false로 정의되어 있습니다:

Object.getOwnPropertyDescriptor(Array.prototype, 'map');
// { enumerable: false, ... }

성능 영향: 열거 비용 V8 엔진에서 for-in의 성능은 프로토타입 체인 깊이에 비례합니다. 프로토타입에 많은 속성이 추가될수록 열거 비용이 증가합니다.

Hidden Class 기반 최적화: V8은 객체의 속성 구조(shape)를 Hidden Class로 캐싱합니다. 프로토타입 속성이 변경되면 관련된 모든 Hidden Class가 무효화되어 for-in 성능이 저하됩니다.

Object.keys()와 for-in의 차이

  • Object.keys(): 객체 자신의 열거 가능한 속성만 반환 (프로토타입 제외)
  • for-in: 프로토타입 체인의 모든 열거 가능한 속성 포함
Array.prototype.custom = 'test';
const arr = [1, 2];

Object.keys(arr);        // ['0', '1']
for (let k in arr) console.log(k); // 0, 1, custom

이러한 비일관성도 프로토타입 확장을 피해야 하는 이유 중 하나입니다.

미래 표준 충돌 위험

입문

지금 추가한 기능의 이름을 나중에 JavaScript 공식 표준에서 사용하게 되면 큰 문제가 생겨요!

🚀 미래에서 온 충돌 여러분이 “teleport”라는 이름의 마법 주문을 만들었어요. 그런데 1년 뒤 해리포터 공식 책에서 “teleport”라는 완전히 다른 주문이 나온다면? 여러분의 주문을 사용하는 마법사들은 혼란에 빠질 거예요. JavaScript 표준도 계속 새로운 기능을 추가하는데, 우리가 먼저 그 이름을 사용하면 이런 충돌이 생겨요!

📅 시간이 지나면서 생기는 문제 오늘 작성한 코드가 1년, 2년 뒤에도 잘 작동해야 해요. 그런데 프로토타입에 Array.prototype.flatten을 추가했다가, JavaScript가 나중에 공식적으로 Array.prototype.flat을 추가하면서 이름을 바꾸게 된 실제 사례가 있어요. 만약 동작이 달랐다면 모든 코드를 고쳐야 했을 거예요!

🔮 미래를 예측할 수 없어요 어떤 이름이 미래에 표준이 될지 아무도 몰라요. 우리가 “perfect”라고 생각한 이름이 5년 뒤 공식 표준에 추가될 수 있어요. 그때 가서 모든 코드를 수정하는 건 너무 어려워요.

⚡ 업데이트할 수 없게 되는 문제 새 JavaScript 버전으로 업그레이드하고 싶어도 못 하게 돼요. 우리가 추가한 메서드와 새 표준 메서드가 충돌하기 때문이에요. 이러면 최신 기능을 사용할 수 없게 되어서 프로젝트가 낙오되어요.

중급

JavaScript 표준(ECMAScript)은 매년 새로운 기능을 추가합니다. 만약 개발자가 내장 프로토타입에 추가한 메서드 이름이 미래의 표준 메서드 이름과 겹치면, 호환성 문제가 발생합니다. 특히 두 메서드의 시그니처나 동작이 다를 경우 기존 코드가 작동하지 않을 수 있습니다.

표준화 과정의 불확실성 TC39(ECMAScript 표준 위원회)는 새 기능을 제안(proposal)하고 검토하는 과정을 거칩니다. 이 과정에서 메서드 이름이나 동작이 변경될 수 있으며, 몇 년이 걸리기도 합니다. 따라서 현재 안전해 보이는 이름도 미래에 충돌할 수 있습니다.

// 2015년: 개발자가 커스텀 메서드 추가
Array.prototype.flat = function() {
  // 커스텀 구현: 2차원 배열만 평탄화
  return this.reduce((acc, val) => acc.concat(val), []);
};

// 코드 작성
const nested = [[1, 2], [3, 4]];
console.log(nested.flat()); // [1, 2, 3, 4]

// 2019년: ES2019에서 Array.prototype.flat 표준 추가
// 표준 flat은 depth 매개변수 지원
const deepNested = [1, [2, [3, [4]]]];
console.log(deepNested.flat(2)); // [1, 2, 3, [4]]

// 문제: 커스텀 flat이 표준 flat을 덮어씀
// 표준 동작을 기대하는 최신 라이브러리와 충돌
// 표준 메서드 존재 여부 확인 후 폴리필
if (!Array.prototype.includes) {
  Array.prototype.includes = function(element) {
    return this.indexOf(element) !== -1;
  };
}
// 문제: 표준이 추가되면 폴리필이 실행되지 않지만,
// 폴리필을 전제로 작성된 코드가 있을 수 있음

심화

미래 표준 충돌은 ECMAScript 진화 과정의 하위 호환성(Backward Compatibility) 요구사항과 웹 플랫폼의 “Don’t Break the Web” 원칙이 충돌하는 지점입니다.

TC39 제안 프로세스와 이름 충돌 TC39 제안은 Stage 0부터 Stage 4까지 진행됩니다. Stage 3(Candidate)에 도달하면 구현이 시작되지만, 웹 호환성 문제가 발견되면 이름이나 동작이 변경될 수 있습니다.

역사적 사례: Array.prototype.flatten → flat

  • 2018년: Array.prototype.flatten이 Stage 3 제안으로 승인
  • MooTools 라이브러리가 이미 Array.prototype.flatten을 다르게 구현
  • 웹사이트 수백만 개가 MooTools를 사용 중
  • 호환성 문제로 메서드 이름을 flat으로 변경 (Smooshgate 논쟁)

이 사례는 “웹을 망가뜨리지 말라(Don’t Break the Web)” 원칙이 표준화 과정에도 영향을 미침을 보여줍니다.

명세 레벨 호환성 보장 ECMAScript 명세는 Annex B (Additional ECMAScript Features for Web Browsers)를 통해 레거시 웹 호환성을 유지합니다. 그러나 커스텀 프로토타입 확장은 이러한 보장 범위 밖에 있습니다.

Polyfill과의 차이 Polyfill은 표준 메서드를 구현하므로 표준이 추가되면 자동으로 대체됩니다:

// 조건부 폴리필 (표준 준수)
if (typeof Array.prototype.flat !== 'function') {
  Array.prototype.flat = function(depth = 1) {
    // 표준 명세에 따른 정확한 구현
    return depth > 0
      ? this.reduce((acc, val) =>
          acc.concat(Array.isArray(val) ? val.flat(depth - 1) : val), [])
      : this.slice();
  };
}

Polyfill은 표준 동작을 복제하므로, 브라우저가 네이티브 구현을 추가해도 동작이 동일합니다. 반면 커스텀 확장은 표준과 다른 동작을 할 수 있어 위험합니다.

안전한 대안: 유틸리티 함수 패턴

// 프로토타입 확장 대신 네임스페이스 유틸리티 사용
const ArrayUtils = {
  sum(arr) {
    return arr.reduce((a, b) => a + b, 0);
  }
};

// 사용
ArrayUtils.sum([1, 2, 3]); // 6
// 미래 표준과 절대 충돌하지 않음

이 패턴은 전역 오염, 충돌, 열거 문제를 모두 회피하며 트리 쉐이킹(Tree Shaking)도 가능합니다.