자바스크립트 Date의 시대가 끝났다: 우리가 Temporal을 기다려온 이유

 

자바스크립트 생태계에서 수십 년간 괴롭혔던 Date 객체를 뒤로하고

새로운 표준 API인 'Temporal'이 마침내 들어왔다.

 

자바스크립트 개발자라면 알고 있는 'Date'의 유산
자바스크립트의 창시자 브렌던 아이크(Brendan Eich)는
언어 설계 초기, 당시 대세였던 자바(Java)의 Date 설계를 그대로 가져왔다.

하지만 자바스크립트의 유연하고 동적인 특성과
자바의 정적인 설계 방식은 태생부터 부조화를 이루었다.

타임존 계산 오류, 비직관적인 월(Month) 인덱스 등 수많은 버그의 온상이 되었고,
이를 해결하기 위해 Moment.js나 Day.js 같은 외부 라이브러리에 의존하며 기술 부채를 쌓아왔다.

 

가변성(Mutability)과의 작별: 이제는 '불변성'의 시대
기존 Date 객체의 가장 치명적인 결함은 바로 '가변성'이다.
setFullYear() 같은 메서드를 호출하면 원본 객체 자체가 수정되어 버린다.
이는 의도치 않은 데이터 오염을 발생시키고 코드의 예측 가능성을 심각하게 떨어뜨린다.

 

 

 

 

 

 

 

반면, Temporal은 철저히 불변성(Immutability)을 지킨다.
add() 메서드 등을 사용해 시간을 조작하면 원본은 그대로 유지되고
계산된 결과가 담긴 새로운 객체가 반환된다.

이는 현대 상태 관리 패턴과 완벽히 부합하며,
버그 없는 안정적인 코드를 작성할 수 있게 해준다.

 

 

 

 

 

서머타임과 타임존: 더 이상 수동 계산은 없다

글로벌 서비스를 운영할 때 가장 골치 아픈 것이 서머타임(DST)과 타임존 처리이다.

Temporal은 상황에 맞는 명확한 객체 구분을 제공한다.

 

 

Temporal.Instant	1970년 1월 1일 UTC 기준의 절대적 시점(타임스탬프)을 기록 기존 new Date().getTime()의 표준적 대체재이다.
Temporal.ZonedDateTime	타임존과 서머타임 정보가 포함된 객체 예를 들어 서머타임 경계에서 12시 30분에 1시간을 더했을 때, 엔진이 자동으로 시계 바늘이 한 시간 점프하는 것을 인지하여 2시 30분이라는 정확한 결과를 반환함.
Temporal.PlainDate	타임존 계산이 필요 없는 순수한 날짜(생일, 기념일 등)를 다룰 때 적합함. 서버와 클라이언트 간의 시차 때문에 생일이 하루 밀리는 등 고질적인 문제를 원천 봉쇄할 수 있음

 

 

시간의 '범위'를 다루는 Duration 객체를 새롭게 도입

 

"130시간 20분은 총 몇 초인가?"와 같은
복잡한 시간 단위 변환과 계산을 단 몇 줄의 코드로 명쾌하게 해결할 수 있다.

또한, 글로벌 표준답게 히브리 달력 등 다양한 달력 체계 옵션을 제공하며,
inLeapYear 프로퍼티를 통해 해당 연도가 윤년인지 여부를
즉시 확인할 수 있는 등 실무에서 유용한 세부 기능을 대거 포함하고 있다.

 

 

 

 

 

 

결론: Stage 4 도달, 이제는 건너갈 준비를 할 때

 

Temporal은 현재 자바스크립트 표준 제정의 최종 단계인
스테이지 4(Stage 4)에 도달했다.

이는 모든 사양 확정이 완료되었음을 의미하며,
내년쯤이면 대다수의 모던 브라우저에서
폴리필(Polyfill) 없이 네이티브로 사용할 수 있게 될 전망이다.

기존 Date보다 압도적으로 강력하고 예측 가능한 Temporal로의 전환은 이제 선택이 아닌 필수이다.
표준 API의 도입은 곧 기술 부채 해결과 코드 품질 향상으로 이어질 것이다.

프로젝트에서 가장 먼저 교체하고 싶은 'Date' 로직은 무엇인가?