👋 들어가며
안녕하세요! ✋
사이드 프로젝트 동아리 DDD에서 Android 개발자로 활동하고 있는 오세민입니다.
이번 글에서는 개발을 하다 보면 한 번쯤은 꼭 마주치게 되는 주제,
시간과 날짜를 다루는 라이브러리에 대해 이야기해보려고 해요.
특히,
- Joda-Time
- java.time
- kotlinx-datetime
이 세 가지를 중심으로
“왜 이렇게 나뉘어 있을까?”라는 질문에서 시작해 보려고 합니다.
⏰ 시작은 항상 이 의문에서 합니다
Joda-Time은 꽤 범용적인 시간 라이브러리예요.
실제로 오래전부터 많은 프로젝트에서 사용됐고, 지금도 레거시 코드에서는 자주 보입니다.
그런데 Java에는 또 java.time이 있고,
Kotlin에는 kotlinx-datetime이라는 라이브러리가 따로 있어요.
그러다 보면 자연스럽게 이런 생각이 들어요.
Joda-Time으로도 충분히 잘 되는데
왜 Java와 Kotlin은 굳이 시간 라이브러리를 다시 만든 걸까요?
이 글은 이 질문에서 출발해요.
“뭘 써야 할까?”보다는
“왜 이렇게 나뉘게 되었을까?”를 먼저 정리해보려 해요.
🕰️ Joda-Time은 왜 그렇게 많이 쓰였을까요
Java 8 이전을 떠올려보면,
시간을 다루는 기본 API가 썩 친절하지 않았어요.
- java.util.Date는 이름과 다르게 날짜/시간 개념이 섞여 있고
- Calendar는 mutable하고 사용하기도 불편했어요
이런 상황에서 등장한 게 Joda-Time이에요.
- 불변 객체
- 날짜, 시간, 기간 개념의 명확한 분리
- 타임존을 고려한 설계
그래서 한동안은 “Java에서 시간 다루려면 Joda-Time”이라는 말이 거의 정설처럼 쓰였어요.
🧭 그래서 Joda-Time의 현재 위치는요
여기서 흥미로운 사실 하나가 있어요.
Joda-Time의 핵심 개발자와 java.time(JSR-310)의 설계자가 동일 인물이라는 점이에요.
Joda-Time을 만들었던 Stephen Colebourne이
Java 8의 시간 API 설계에도 직접 참여했고,
그 결과물이 바로 java.time이에요.
그래서 구조를 보면 익숙한 이유도 여기에 있어요.
Joda-Time에서 검증된 개념과 설계를 그대로 가져와
Java 공식 표준으로 정리한 게 java.time이기 때문이에요.
이 개발자는 공식 문서와 여러 글에서 분명하게 이야기해요.
Joda-Time은 유지보수 모드이며, 새 코드에서는 java.time을 사용하라
그래서 지금 시점에서 Joda-Time은 이렇게 보는 게 자연스러워요.
- 기존 레거시 유지보수 → 괜찮아요
- 새 프로젝트 설계 → 굳이 선택할 이유는 없어요
문제가 있어서 밀려난 게 아니라,
자신의 설계가 표준으로 흡수되면서 역할을 마무리한 라이브러리에 더 가까워요.
Joda-Time이 실패해서 사라진 게 아니라,
성공했기 때문에 java.time으로 이어졌다고 보는 게 맞아요.
🧩 Kotlin에서는 왜 또 다른 선택지가 있을까요
여기서 kotlinx-datetime이 등장해요.
이 라이브러리는 Java의 시간 API를 대체하려는 목적이 아니에요.
핵심은 딱 하나예요.
Kotlin Multiplatform에서 공통으로 사용할 수 있는 시간 API
그래서 몇 가지 차이가 있어요.
- JVM, Android, iOS, JS에서 공통 사용
- Instant, LocalDate 같은 개념은 유지
- 타임존은 TimeZone을 명시적으로 함께 사용
val instant = Clock.System.now()
val local = instant.toLocalDateTime(TimeZone.of("Asia/Seoul"))Java의 ZonedDateTime을 그대로 쓰지 않은 이유도 멀티플랫폼 환경을 고려한 선택이에요.
🗂️ 개념으로 보면 라이브러리는 덜 헷갈려요
시간 라이브러리가 어려운 이유는 문법보다 개념이 섞이기 때문이에요.
| 개념 | 의미 |
| Instant | 절대적인 시점 |
| LocalDate | 날짜 |
| LocalTime | 시간 |
| ZonedDateTime | 날짜 + 시간 + 타임존 |
| Duration | 시간의 양 |
이 개념은
Joda-Time, java.time, kotlinx-datetime 모두 거의 동일해요.
차이는 “어디에서 쓰느냐”에 더 가까워요.
📱 Android에서는 이렇게 선택해요
minSdk 26 이상
java.time을 그대로 사용하면 돼요.
추가 고민은 거의 없어요.
minSdk 26 미만
이 경우에도 방법은 명확해요.
Core Library Desugaring을 활성화해서
java.time을 백포트해서 사용하는 방식이 가장 안정적이에요.
android {
compileOptions {
coreLibraryDesugaringEnabled true
}
}
dependencies {
coreLibraryDesugaring(
"com.android.tools:desugar_jdk_libs:..."
)
}
실무에서 가장 많이 쓰이는 방식이에요.
🌍 Kotlin Multiplatform이라면 선택이 달라져요
공용 모듈에서는 kotlinx-datetime이 현실적인 선택이에요.
그리고 시간 계산은
kotlin.time.Duration이 정말 잘 만들어져 있어요.
5.hours + 30.minutes읽는 순간 바로 이해된다는 점에서
이건 꽤 큰 장점이에요.
🧠 시간 라이브러리에서 가장 중요한 원칙
라이브러리 선택보다 더 중요한 건 이 원칙이에요.
저장과 전송은 항상 Instant로 해요
사람에게 보여줄 때만 날짜와 타임존을 입혀요
이 기준을 지키면
- 서버와 클라이언트 간 시간 차이
- 타임존 문제
- DST(일광절약시간) 이슈
대부분을 자연스럽게 피할 수 있어요.
✅ 정리해보면 이렇습니다
- Joda-Time은 한 시대를 잘 마무리한 라이브러리예요
- java.time은 그 설계를 공식 표준으로 만든 결과예요
- kotlinx-datetime은 멀티플랫폼을 위한 현실적인 선택이에요
무엇을 쓰느냐보다 왜 이런 타입과 라이브러리가 존재하는지 이해하는 게 더 중요해요.
시간은 조용히 쌓이고, 문제가 생기면 고치기 어렵거든요.
긴 글 읽어주셔서 감사합니다.
🔗 레퍼런스
이 글을 정리하면서 실제로 참고한 자료들이에요.
https://www.joda.org/joda-time/
https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html
https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.time/
'Android' 카테고리의 다른 글
| [Android] java.io.stream에 대한 고찰 (0) | 2026.03.15 |
|---|