[EXT-027][실무] 지원되는 달력과 시간대 목록 만들기
페이지 정보

본문
[이번 수업]
Intl.supportedValuesOf()로 현재 실행 환경이 지원하는 달력·통화·시간대 값을 확인합니다. 런타임 기능과 서비스 허용 목록을 구분합니다.
[선수지식]
JavaScript 배열과 Set, Intl의 로케일 개념을 알면 됩니다. 런타임(runtime)은 JavaScript 코드를 실제로 실행하는 브라우저나 Node.js 환경입니다.
[학습목표]
1. supportedValuesOf()가 받는 키와 반환값을 설명할 수 있습니다.
2. 런타임 지원 목록과 업무 허용 목록의 교집합을 만들 수 있습니다.
3. 국제화 데이터가 바뀌어도 깨지지 않는 검증 흐름을 설계할 수 있습니다.
[핵심개념]
Intl.supportedValuesOf(key)는 현재 구현이 지원하는 국제화 식별자를 배열로 돌려줍니다. ECMA-402 2025의 키는 calendar, collation, currency, numberingSystem, timeZone, unit 여섯 가지입니다. 다른 키를 넣으면 RangeError가 발생합니다. 반환값은 표준 형태이며 중복 없이 코드 단위 사전순으로 정렬됩니다.
이 목록은 런타임 능력을 보여 줄 뿐 서비스 정책을 정하지 않습니다. currency에 있다고 현재 유통 중인 통화이거나 결제를 허용한다는 뜻은 아닙니다. timeZone 목록은 IANA 시간대 데이터베이스를 바탕으로 하며 구현과 데이터 버전이 바뀌면 항목도 달라질 수 있습니다. 별칭처럼 formatter가 받아들이지만 열거 목록에는 없는 값도 있을 수 있습니다. 따라서 목록 전체를 영구 저장하거나 항목 수를 테스트 정답으로 고정하지 않습니다.
화면 선택지는 먼저 제품이 지원할 값을 정한 뒤 런타임 목록과 교집합을 만듭니다. 서버에서도 같은 업무 허용 목록으로 다시 검증해야 합니다. 통화·달력 이름은 Intl.DisplayNames로 만들고 시간대 이름은 따로 관리합니다.
[따라하기]
supported-values.js 파일에 아래 코드를 저장합니다.
```javascript
const keys = ['calendar', 'currency', 'timeZone', 'unit'];
for (const key of keys) {
console.log(`${key}: ${Intl.supportedValuesOf(key).length > 0}`);
}
const supportedZones = new Set(Intl.supportedValuesOf('timeZone'));
const businessZones = ['Asia/Seoul', 'Asia/Tokyo', 'Mars/Base'];
const choices = businessZones.filter(zone => supportedZones.has(zone));
console.log(choices.join(', '));
try {
Intl.supportedValuesOf('locale');
} catch (error) {
console.log(error.name);
}
```
`node supported-values.js`를 실행합니다. 확인한 예상 결과는 네 키가 모두 `true`, 다음 줄이 `Asia/Seoul, Asia/Tokyo`, 마지막 줄이 `RangeError`입니다. 존재하지 않는 Mars/Base는 교집합에서 빠집니다. Windows PowerShell·명령 프롬프트, macOS 터미널, Linux 셸에서 명령은 같습니다. 런타임에 따라 지원 목록이 다를 수 있으므로 값의 전체 개수는 비교하지 않습니다.
[흔한 실수]
지원 목록을 결제 통화나 예약 지역의 허용 목록으로 그대로 쓰면 업무상 막아야 할 값까지 통과할 수 있습니다. 반대로 목록을 한 번 복사해 코드에 고정하면 시간대 데이터가 갱신될 때 낡습니다. currency 코드를 사용자 언어 이름이라고 생각하거나 timeZone 식별자를 화면 문구로 그대로 노출하지 마세요. `locale`처럼 허용되지 않은 키를 넘기면 빈 배열이 아니라 RangeError가 납니다. 값 하나의 유효성을 확인하려고 매 요청마다 큰 배열을 다시 만들지 말고, 프로세스 안에서 안전하게 재사용할 수 있습니다.
[보안 주의]
클라이언트 선택 목록은 편의 기능일 뿐 신뢰 경계가 아닙니다. 서버에서 입력 형식, 런타임 지원 여부, 서비스 허용 목록을 모두 확인합니다. 통화는 결제 제공 범위, 시간대는 서비스 지역 정책처럼 별도 규칙을 적용하세요. 알 수 없는 키는 거부하고 오류 메시지에 내부 설정 전체를 노출하지 않습니다. 아주 큰 선택 목록을 그대로 DOM에 만들지 말고 검색이나 구간 렌더링을 사용합니다. 실습은 본인 소유의 로컬 환경에서만 진행합니다.
[직접 해볼 과제]
calendar와 numberingSystem 목록에서 앞의 다섯 항목만 출력하세요. 이어서 서비스 허용 통화 `KRW`, `JPY`, `USD`와 런타임 currency 목록의 교집합을 만들고, 허용되지 않은 `ABC`가 빠지는지 확인하는 테스트를 작성하세요.
[확인문제]
1. supportedValuesOf()의 결과를 서비스 허용 목록으로 바로 사용하면 안 되는 이유는 무엇인가요?
2. 지원 항목의 전체 개수를 테스트에 고정하면 왜 깨질 수 있나요?
3. 허용되지 않은 key를 넘기면 어떤 오류가 발생하나요?
[다음 학습]
다음에는 정규 표현식의 Unicode 속성 이스케이프로 문자 범주를 확인하고, 글자 범위를 직접 나열하지 않는 입력 검증을 배웁니다.
[공식 참고 자료]
ECMA-402 supportedValuesOf(): https://tc39.es/ecma402/2025/#sec-intl.supportedvaluesof
ECMA-402 시간대 데이터: https://tc39.es/ecma402/2025/#sec-use-of-the-iana-time-zone-database
IANA 시간대 데이터베이스: https://www.iana.org/time-zones
Unicode LDML: https://www.unicode.org/reports/tr35/
Intl.supportedValuesOf()로 현재 실행 환경이 지원하는 달력·통화·시간대 값을 확인합니다. 런타임 기능과 서비스 허용 목록을 구분합니다.
[선수지식]
JavaScript 배열과 Set, Intl의 로케일 개념을 알면 됩니다. 런타임(runtime)은 JavaScript 코드를 실제로 실행하는 브라우저나 Node.js 환경입니다.
[학습목표]
1. supportedValuesOf()가 받는 키와 반환값을 설명할 수 있습니다.
2. 런타임 지원 목록과 업무 허용 목록의 교집합을 만들 수 있습니다.
3. 국제화 데이터가 바뀌어도 깨지지 않는 검증 흐름을 설계할 수 있습니다.
[핵심개념]
Intl.supportedValuesOf(key)는 현재 구현이 지원하는 국제화 식별자를 배열로 돌려줍니다. ECMA-402 2025의 키는 calendar, collation, currency, numberingSystem, timeZone, unit 여섯 가지입니다. 다른 키를 넣으면 RangeError가 발생합니다. 반환값은 표준 형태이며 중복 없이 코드 단위 사전순으로 정렬됩니다.
이 목록은 런타임 능력을 보여 줄 뿐 서비스 정책을 정하지 않습니다. currency에 있다고 현재 유통 중인 통화이거나 결제를 허용한다는 뜻은 아닙니다. timeZone 목록은 IANA 시간대 데이터베이스를 바탕으로 하며 구현과 데이터 버전이 바뀌면 항목도 달라질 수 있습니다. 별칭처럼 formatter가 받아들이지만 열거 목록에는 없는 값도 있을 수 있습니다. 따라서 목록 전체를 영구 저장하거나 항목 수를 테스트 정답으로 고정하지 않습니다.
화면 선택지는 먼저 제품이 지원할 값을 정한 뒤 런타임 목록과 교집합을 만듭니다. 서버에서도 같은 업무 허용 목록으로 다시 검증해야 합니다. 통화·달력 이름은 Intl.DisplayNames로 만들고 시간대 이름은 따로 관리합니다.
[따라하기]
supported-values.js 파일에 아래 코드를 저장합니다.
```javascript
const keys = ['calendar', 'currency', 'timeZone', 'unit'];
for (const key of keys) {
console.log(`${key}: ${Intl.supportedValuesOf(key).length > 0}`);
}
const supportedZones = new Set(Intl.supportedValuesOf('timeZone'));
const businessZones = ['Asia/Seoul', 'Asia/Tokyo', 'Mars/Base'];
const choices = businessZones.filter(zone => supportedZones.has(zone));
console.log(choices.join(', '));
try {
Intl.supportedValuesOf('locale');
} catch (error) {
console.log(error.name);
}
```
`node supported-values.js`를 실행합니다. 확인한 예상 결과는 네 키가 모두 `true`, 다음 줄이 `Asia/Seoul, Asia/Tokyo`, 마지막 줄이 `RangeError`입니다. 존재하지 않는 Mars/Base는 교집합에서 빠집니다. Windows PowerShell·명령 프롬프트, macOS 터미널, Linux 셸에서 명령은 같습니다. 런타임에 따라 지원 목록이 다를 수 있으므로 값의 전체 개수는 비교하지 않습니다.
[흔한 실수]
지원 목록을 결제 통화나 예약 지역의 허용 목록으로 그대로 쓰면 업무상 막아야 할 값까지 통과할 수 있습니다. 반대로 목록을 한 번 복사해 코드에 고정하면 시간대 데이터가 갱신될 때 낡습니다. currency 코드를 사용자 언어 이름이라고 생각하거나 timeZone 식별자를 화면 문구로 그대로 노출하지 마세요. `locale`처럼 허용되지 않은 키를 넘기면 빈 배열이 아니라 RangeError가 납니다. 값 하나의 유효성을 확인하려고 매 요청마다 큰 배열을 다시 만들지 말고, 프로세스 안에서 안전하게 재사용할 수 있습니다.
[보안 주의]
클라이언트 선택 목록은 편의 기능일 뿐 신뢰 경계가 아닙니다. 서버에서 입력 형식, 런타임 지원 여부, 서비스 허용 목록을 모두 확인합니다. 통화는 결제 제공 범위, 시간대는 서비스 지역 정책처럼 별도 규칙을 적용하세요. 알 수 없는 키는 거부하고 오류 메시지에 내부 설정 전체를 노출하지 않습니다. 아주 큰 선택 목록을 그대로 DOM에 만들지 말고 검색이나 구간 렌더링을 사용합니다. 실습은 본인 소유의 로컬 환경에서만 진행합니다.
[직접 해볼 과제]
calendar와 numberingSystem 목록에서 앞의 다섯 항목만 출력하세요. 이어서 서비스 허용 통화 `KRW`, `JPY`, `USD`와 런타임 currency 목록의 교집합을 만들고, 허용되지 않은 `ABC`가 빠지는지 확인하는 테스트를 작성하세요.
[확인문제]
1. supportedValuesOf()의 결과를 서비스 허용 목록으로 바로 사용하면 안 되는 이유는 무엇인가요?
2. 지원 항목의 전체 개수를 테스트에 고정하면 왜 깨질 수 있나요?
3. 허용되지 않은 key를 넘기면 어떤 오류가 발생하나요?
[다음 학습]
다음에는 정규 표현식의 Unicode 속성 이스케이프로 문자 범주를 확인하고, 글자 범위를 직접 나열하지 않는 입력 검증을 배웁니다.
[공식 참고 자료]
ECMA-402 supportedValuesOf(): https://tc39.es/ecma402/2025/#sec-intl.supportedvaluesof
ECMA-402 시간대 데이터: https://tc39.es/ecma402/2025/#sec-use-of-the-iana-time-zone-database
IANA 시간대 데이터베이스: https://www.iana.org/time-zones
Unicode LDML: https://www.unicode.org/reports/tr35/
- 이전글[EXT-028][실무] 여러 언어의 글자 범주를 정규식으로 검사하기 26.09.08
- 다음글[EXT-026][실무] 이모지와 한글을 사용자 눈에 맞게 나누기 26.09.08
댓글목록
등록된 댓글이 없습니다.
