아래는 자바에 비해 코틀린의 실질적인 단점만 뽑아봤습니다. (현업 개발자들이 실제로 불편해하거나 피로감을 느끼는 부분 위주로, 2025년 기준으로 정리)
| 순위 | 카테고리 | 자바에 비한 코틀린 단점 (현업 체감 순) | 체감 강도 |
|---|---|---|---|
| 1 | 컴파일 속도 | 여전히 Java보다 느림. 특히 대규모 프로젝트에서 인크리멘탈 빌드가 느껴질 정도로 차이 남 (K2 컴파일러로 많이 개선됐지만 완벽히 따라잡진 못함) | ★★★★★ |
| 2 | 에러 메시지 가독성 | 컴파일 에러 메시지가 Java보다 훨씬 길고 복잡함. 타입 추론 때문에 “Type inference failed” 같은 추상적 에러 자주 발생 → 디버깅 피로도 ↑ | ★★★★★ |
| 3 | 학습 곡선 (초기) | Null 안전, 코루틴, Flow, sealed class 등 새로운 개념이 많아서 Java 개발자가 처음 배울 때 “이게 뭐야?” 하며 헤매는 기간 길음 | ★★★★☆ |
| 4 | IDE 의존도 높음 | IntelliJ IDEA 없으면 코틀린 개발이 고통 수준 (Android Studio는 괜찮지만, VS Code나 Eclipse 지원은 여전히 제한적) | ★★★★☆ |
| 5 | 런타임 오버헤드 (미세) | 코루틴, 확장 함수, 인라인 클래스 등 언어 기능 때문에 아주 미세하게 바이트코드가 커지거나 런타임 비용 발생 (대부분 무시 가능하지만 극한 최적화 시 체감) | ★★★☆☆ |
| 6 | 라이브러리 생태계 격차 | Java가 20년 넘게 쌓아온 마이너 라이브러리는 아직 Kotlin-native 버전이 없거나 문서가 부족한 경우 많음 (대부분 호환되지만) | ★★★☆☆ |
| 7 | 스택트레이스 가독성 | 예외 발생 시 스택트레이스가 Java보다 길고 복잡함 (인라인 함수, 확장 함수 때문에 실제 호출 지점 찾기 어려움) | ★★★☆☆ |
| 8 | @JvmStatic / @JvmField 등 어노테이션 강요 | Java와 혼용할 때 호환성을 위해 번거로운 어노테이션 자주 붙여야 함 (특히 companion object나 data class 사용 시) | ★★★☆☆ |
| 9 | implicit parameter (context receiver) 등 실험적 기능 | 최신 기능(예: Kotlin 2.0 context receiver)이 아직 안정화되지 않아 프로덕션에서 쓰기 꺼려짐 | ★★☆☆☆ |
| 10 | 채용 시장 (일부 지역) | 한국/일부 국가에서는 여전히 “Java 경력 5년 이상” 요구사항이 많아서 코틀린만 아는 신입이 불리할 수 있음 | ★★☆☆☆ |
현업 개발자들 실제 불평
- “빌드 한 번 돌리는데 10초 더 걸리니 하루에 30번 빌드하면 5분 날아감… 짜증”
- “에러 메시지 20줄 나오는데 어디가 문제인지 모르겠음. Java 때는 한 줄로 딱 나왔는데”
- “IntelliJ 안 쓰면 자동 완성도 제대로 안 되고 리팩토링도 힘듦”
- “Java 라이브러리 문서 보면서 @JvmOverloads 붙여가며 호환 맞추는 게 은근 귀찮음”
결론
장점이 압도적이긴 하지만, 대규모 레거시 프로젝트 유지보수나 극한 성능 최적화가 필요한 경우에는 여전히 Java를 선호하는 팀도 있습니다.
하지만 신규 프로젝트라면 단점에도 불구하고 거의 대부분 코틀린을 선택하는 게 현실이에요.
답글 남기기