does not provide an export named 오류는 대개 함수가 없어서가 아니라 내보낸 방식과 가져온 방식이 다르기 때문에 발생한다. default export와 named export는 이름이 비슷해도 계약이 다르다.
named export는 중괄호와 이름으로 가져온다
도식에서 named export는 내보낸 이름과 가져오는 이름을 맞추고 중괄호를 사용한다. 두 함수를 내보내는 모듈로 문법을 확인해 보자.
// format.js
export function formatDate(value) {
return new Intl.DateTimeFormat("ko-KR").format(value);
}
// app.js
import { formatDate } from "./format.js";named export는 한 모듈이 여러 기능을 공개할 때 알맞다. 가져오는 쪽이 어떤 기능을 사용하는지 import 문에서 바로 보인다. 이름을 바꾸고 싶다면 import { formatDate as format }처럼 별칭을 명시한다.
default export는 모듈의 대표 값 하나다
// logger.js
export default function log(message) {
console.log(message);
}
// app.js
import log from "./logger.js";default import에는 중괄호를 쓰지 않는다. 가져오는 쪽에서 이름을 바꿀 수 있지만, 너무 자유로우면 검색과 리팩터링 때 같은 대상이 여러 이름으로 보일 수 있다.
모듈 실행 환경에서 import { log } from "./logger.js"로 바꿔 보면 named export를 찾지 못한다는 오류가 난다. 반대로 format.js를 import formatDate from "./format.js"로 가져오면 default export가 없어 실패한다. 오류 문구를 보고 파일 경로뿐 아니라 중괄호와 export 선언을 짝지어 확인하자.
한 모듈의 역할부터 정한다
컴포넌트처럼 대표 대상 하나를 내보내는 파일은 default export가 자연스러울 수 있다. 반면 유틸리티 모듈처럼 여러 기능이 동등하다면 named export가 더 명확하다. 중요한 것은 팀 안에서 규칙을 섞지 않는 것이다.
export *로 많은 모듈을 한곳에 다시 내보내면 import가 짧아지지만, 이름 충돌과 의존성 경로를 숨길 수 있다. 공개 API가 필요한 패키지 경계에서만 신중히 사용하자.
핵심 요약
named export는 import { name }, default export는 import name으로 가져온다. 오류를 만나면 먼저 export 문과 중괄호 유무를 대조하자. 모듈마다 대표 값 하나인지 여러 동등한 기능인지 정하고 일관된 export 규칙을 쓰면 import 오류와 코드 탐색 비용이 줄어든다.
