[Language] Kotlin

Kotlin란?

---

Kotlin은 JetBrains가 설계한 정적 타입 프로그래밍 언어이다. JVM 위에서 Java와 함께 동작하도록 출발했지만, 현재는 Android, 서버, JavaScript, Native, Wasm까지 바라보는 멀티플랫폼 언어로 확장되어 있다. 핵심 방향은 기존 Java 생태계를 버리지 않으면서도 null 안전성, 타입 추론, 데이터 클래스, 확장 함수, 코루틴 같은 현대적 언어 기능으로 반복 코드를 줄이는 데 있다.

Kotlin을 단순히 “Java보다 짧은 문법”으로만 보면 중요한 장점을 놓치기 쉽다. 실제 현장에서는 기존 JVM 자산을 점진적으로 활용하면서 신규 모듈의 안정성, 비동기 처리, Android 생산성, 공통 비즈니스 로직 공유를 개선하는 선택지로 쓰인다.

Kotlin 공식 로고는 Kotlin 브랜드 자산 번들에 포함된 원본 이미지이다. 본문에서는 Kotlin 언어를 식별하기 위한 시각 자료로 사용한다. 출처: Kotlin brand assets, JetBrains.

Kotlin은 Java 생태계와의 호환성을 유지하면서 더 안전하고 간결한 코드, Android 친화성, 멀티플랫폼 확장을 함께 노리는 언어이다.

등장 배경과 생태계 위치

---

Kotlin은 대규모 JVM 개발에서 반복적으로 마주치는 장황한 문법, null 처리 실수, 불변성과 함수형 스타일의 부족, Android 개발의 생산성 문제를 줄이기 위해 등장했다. Java와 완전히 단절된 새 플랫폼을 만들기보다, Java 라이브러리와 빌드 도구, IDE, 프레임워크를 그대로 활용할 수 있는 방향을 택했다는 점이 중요하다.

이 전략 덕분에 Kotlin은 Spring 기반 서버, Android 앱, Gradle 빌드 스크립트, 데이터 처리 도구, CLI, 멀티플랫폼 라이브러리 등으로 자연스럽게 퍼졌다. 특히 Android에서는 Google의 공식 지원 이후 사실상 주류 언어 중 하나가 되었고, JVM 서버에서는 Java 코드베이스에 일부 모듈부터 점진적으로 도입하는 방식이 흔하다.

Kotlin의 생태계 전략은 “새 런타임으로 갈아타기”가 아니라 “기존 JVM과 Android 자산 위에 더 나은 언어 계층을 얹기”에 가깝다.

핵심 언어 모델

---

Kotlin은 정적 타입 언어이지만 타입 추론을 적극적으로 제공한다. 개발자는 많은 경우 타입을 직접 적지 않아도 컴파일러가 타입을 계산하며, API 경계나 복잡한 제네릭처럼 명시성이 필요한 지점에서는 타입을 드러낼 수 있다. null 안전성도 Kotlin의 핵심이다. nullable 타입과 non-null 타입을 구분하고, 안전 호출, 엘비스 연산자, smart cast 같은 문법을 통해 null 처리를 코드 구조 안으로 끌어들인다.

또한 데이터 클래스, sealed class, 확장 함수, 고차 함수, 람다, delegated property 같은 기능은 도메인 모델과 API 표현력을 높인다. 단, 표현력이 강하다는 것은 팀 규칙이 없을 때 코드 스타일이 쉽게 흩어질 수 있다는 뜻이기도 하다. 실무에서는 확장 함수 남용, 암시적 변환 기대, 과도한 DSL 설계를 조심해야 한다.

Kotlin의 타입 시스템은 짧은 코드 자체보다 null과 상태 모델을 컴파일 시점에 더 명확히 표현하는 데 큰 의미가 있다.

JVM 상호 운용성과 운영 관점

---

Kotlin은 Java 상호 운용성을 매우 중요하게 다룬다. 공식 문서도 Kotlin에서 Java 코드를 자연스럽게 호출할 수 있고, 반대로 Java에서 Kotlin 코드를 사용할 수 있다고 설명한다. 이 특성은 기존 Java 라이브러리, Spring, JPA, Gradle, Maven, JVM 모니터링 도구를 유지하면서 Kotlin을 도입할 수 있게 한다.

하지만 상호 운용성이 곧 모든 경계가 자동으로 안전하다는 뜻은 아니다. Java의 nullability annotation이 부족하면 Kotlin에는 platform type으로 들어오며, 이때 null 안전성의 일부 보장이 약해질 수 있다. Java에서 Kotlin의 default parameter, companion object, suspend function, property accessor를 호출할 때도 API 설계를 신경 써야 한다. 라이브러리나 공용 모듈에서는 Java 호출자를 고려해 `@JvmOverloads`, `@JvmStatic`, 명확한 nullability annotation, 예외 정책을 정리하는 것이 좋다.

Kotlin 도입의 현실적인 성공 여부는 Java와 섞이는 경계에서 null, 예외, 바이너리 호환성, 호출 형태를 얼마나 일관되게 관리하느냐에 달려 있다.

코루틴과 비동기 처리

---

Kotlin의 코루틴은 비동기 코드를 순차 코드처럼 작성하게 해 주는 실행 모델이다. 공식 문서는 코루틴을 suspend 가능한 계산으로 설명하며, 스레드를 계속 점유하지 않고 중단과 재개를 할 수 있다는 점을 강조한다. 서버에서는 I/O 중심 작업을 더 읽기 쉬운 방식으로 표현하고, Android에서는 네트워크와 데이터베이스 작업이 메인 스레드를 막지 않도록 구조화하는 데 많이 쓰인다.

운영 관점에서는 코루틴도 공짜가 아니다. `CoroutineScope`의 생명주기, dispatcher 선택, cancellation 전파, timeout, exception handling이 명확하지 않으면 누수나 조용한 실패가 발생할 수 있다. 특히 Spring, Android lifecycle, Ktor, Reactor 같은 프레임워크와 섞을 때는 어느 계층이 동시성 경계를 책임지는지 정해야 한다.

코루틴은 비동기 처리를 쉽게 보이게 만들지만, 실제 안정성은 scope, cancellation, dispatcher, 예외 전파 규칙을 명시적으로 설계할 때 확보된다.

멀티플랫폼 실행 모델

---

Kotlin Multiplatform은 공통 Kotlin 코드를 여러 플랫폼 타깃으로 컴파일해 공유하는 접근이다. Android Developers와 JetBrains 문서 모두 KMP가 Android, iOS, 데스크톱, 웹, 서버 같은 대상에서 생산 사용 가능한 선택지로 성장했음을 설명한다. 일반적인 전략은 UI 전체를 무조건 공유하기보다 도메인 모델, 네트워크 계층, validation, 비즈니스 규칙, 데이터 변환 로직을 공통화하고, 각 플랫폼의 UI와 OS 기능은 native로 유지하는 방식이다.

이 다이어그램은 공통 Kotlin 코드가 Android/JVM, iOS/Native, JS/Wasm 타깃으로 나뉘는 구조를 정리한 자체 제작 이미지이다. Kotlin 도입을 검토할 때는 언어 문법보다 어떤 코드가 어느 타깃까지 공유될 수 있는지 먼저 나누어 보는 것이 중요하다.

멀티플랫폼의 장점은 중복 구현 감소와 로직 일관성이다. 반면 플랫폼별 API 차이, 빌드 시간, IDE 플러그인 성숙도, iOS 개발자의 Kotlin 이해도, 라이브러리 호환성은 실제 비용으로 남는다. KMP는 “모든 코드를 한 번만 작성한다”는 약속보다 “공유할 가치가 큰 코드를 선별해 중복을 줄인다”는 관점에서 접근할 때 성공 확률이 높다.

Kotlin Multiplatform은 UI를 무리하게 통합하기보다 공통 비즈니스 로직을 공유하고 플랫폼 고유 경험은 유지하는 선택지로 이해하는 것이 현실적이다.

선택 기준과 트레이드오프

---

• 기존 JVM 자산이 많은 팀: Java 라이브러리와 Spring 기반 서버를 유지하면서 새 코드의 안정성과 표현력을 높이기 좋다.
• Android 중심 팀: Kotlin 친화적인 Android API, 코루틴, Jetpack 생태계와 잘 맞는다.
• 모바일 공통 로직이 많은 팀: Android와 iOS가 같은 도메인 규칙을 구현해야 한다면 KMP가 중복을 줄일 수 있다.
• Java 호출자가 많은 공개 라이브러리: Kotlin 문법의 편의보다 Java API 모양, 바이너리 호환성, nullability annotation을 더 엄격히 봐야 한다.
• 런타임과 빌드 안정성이 중요한 조직: Kotlin 컴파일 시간, Gradle 설정 복잡도, 플러그인 버전 호환성, 팀 학습 비용을 미리 측정해야 한다.

Kotlin은 많은 문제를 줄여 주지만, 모든 Java 프로젝트의 자동 해답은 아니다. 간단한 CRUD 서버에서 팀이 Java에 매우 익숙하고 변경 비용을 원하지 않는다면 도입 이득이 작을 수 있다. 반대로 null 안전성, Android 생산성, 공통 모바일 로직, DSL 기반 설정, 비동기 코드 가독성이 중요한 팀에서는 장점이 분명하다.

Kotlin은 언어 자체의 우아함보다 기존 생태계와 팀 역량, 빌드 체인, API 경계까지 함께 검토할 때 좋은 선택이 된다.

사례

---

Android 공식 문서의 Kotlin Multiplatform 안내는 KMP가 Android와 iOS 사이의 비즈니스 로직 공유에 공식적으로 지원되며 production-ready라고 설명한다. 모바일 팀이 동일한 validation, API client, domain model을 두 번 구현하는 비용을 줄이는 사례에 해당한다.

JetBrains의 Kotlin Multiplatform stable 발표는 KMP가 안정화 단계에 들어섰고 production use를 목표로 한다는 점을 정리한다. 이 사례는 Kotlin이 JVM 언어를 넘어 제품 코드 공유 플랫폼으로 확장되는 방향을 보여 준다.

Kotlin 공식 Java interop 문서는 기존 Java 코드를 Kotlin에서 사용할 수 있고 Kotlin 코드도 Java에서 호출할 수 있음을 다룬다. 이는 Spring, JPA, Android legacy module처럼 Java 자산이 큰 조직에서 Kotlin을 한 번에 전환하지 않고 점진적으로 도입할 수 있는 근거가 된다.

참고 자료: Kotlin Documentation - Calling Java from Kotlin, Kotlin Documentation - Coroutines, Kotlin Multiplatform, Android Developers - Kotlin Multiplatform, JetBrains Blog - Kotlin Multiplatform Is Stable and Production-Ready.