네임스페이스와 ESM: 오래된 패턴을 읽는 법

"네임스페이스를 알아야 하는 이유는 새 코드를 거기에 가두기보다, 오래된 코드를 안전하게 건너오기 위해서야."

네임스페이스가 해결하던 문제

namespace Geometry { export class Point {} }는 여러 선언을 하나의 전역 객체 아래 묶어 이름 충돌을 줄여. 표준 모듈 로더가 널리 자리 잡기 전 브라우저 스크립트와 오래된 TypeScript 코드에서 흔했어.

같은 이름의 네임스페이스 선언은 병합될 수 있고, /// <reference path="..."/>와 함께 여러 파일을 묶기도 했지. 이 구조는 빌드 순서와 전역 상태에 의존하기 쉬워 규모가 커질수록 경계 추적이 어려워져.

새 코드에서는 ESM이 기본

ES 모듈은 파일 자체가 범위가 되고 import와 export로 의존 관계를 명시해. 브라우저, Node, 번들러가 공통으로 이해하며 정적 분석과 코드 분할에도 유리해. 그래서 현대 애플리케이션과 라이브러리의 기본 선택은 ESM이야.

그렇다고 타입 선언의 모든 namespace가 낡았다는 뜻은 아니야. 함수나 클래스에 정적 타입 이름을 병합하는 선언 패턴, 전역 라이브러리를 설명하는 .d.ts에서는 여전히 만날 수 있어. 새 실행 구조를 설계하는 선택과 선언 파일을 표현하는 선택을 구분해야 해.

마이그레이션은 경계를 하나씩

전역 네임스페이스를 한 번에 지우기보다 먼저 공개 진입점을 찾고, 내부 의존을 명시적 import로 바꾼 뒤, 소비자를 ESM 경계로 옮겨. 실행 순서에 숨어 있던 초기화가 있다면 별도 함수로 드러내야 해.

ESM의 정적 import와 export는 트리 셰이킹 같은 분석과 코드 분할을 가능하게 해. 네임스페이스는 jQuery나 Lodash처럼 전역으로 배포되던 라이브러리와 오래된 @types 선언에서 여전히 보이지만, 새 실행 코드는 ESM을 기본으로 삼아.

네임스페이스는 역사적 코드와 선언 파일을 읽기 위한 중요한 문법이지만, 새 실행 경계는 대개 ESM으로 세워. 암묵적 전역을 명시적 의존으로 바꾸는 것이 이주의 핵심이야.

Code

Namespace vs ES module — 같은 모양, 다른 메커니즘·typescript

// Legacy: namespace.
namespace MyApp {
  export function init() { /* ... */ }
  export class Config { /* ... */ }

  export namespace Utils {
    export function helper() { /* ... */ }
  }
}

MyApp.init();
MyApp.Utils.helper();

// Modern: ES module.
// init.ts
export function init() { /* ... */ }

// config.ts
export class Config { /* ... */ }

// utils.ts
export function helper() { /* ... */ }

// app.ts
import { init } from './init';
import { Config } from './config';
import { helper } from './utils';

init();
helper();

Exercise

작은 네임스페이스 예제를 ES 모듈로 옮겨. 논리 단위마다 파일을 나누고 이름 있는 내보내기와 공개 진입점을 만든 뒤 사라진 기능이 있는지 적어.

Hint

네임스페이스 안의 각 내보내기는 해당 파일의 내보내기가 돼. 바깥 래퍼는 사라지고 namespace.member 접근은 이름 있는 import로 바뀌어.

네임스페이스가 해결하던 문제

새 코드에서는 ESM이 기본

마이그레이션은 경계를 하나씩

Code

External links

Exercise

Progress

댓글 0