LabHub

블로그

모던 Kotlin 2026 완벽 가이드 - Kotlin 2.1 · Compose Multiplatform · Ktor · Exposed · KSP · Arrow 심층 분석

2026-05-16 · 27 분 읽기 · #kotlin#kotlin-2#compose-multiplatform#ktor#exposed#ksp#arrow-kt#coroutines#android

한국어English日本語

프롤로그 — Kotlin은 다언어 런타임 시대의 표준이 되었다

2026년 봄, Kotlin은 더 이상 "Android 언어"가 아니다. 서버는 Ktor 3와 Spring Boot 3.4 Kotlin DSL이 양분하고, 모바일은 Compose Multiplatform 1.7이 iOS·Android·Desktop·Web을 한 코드베이스로 빌드하며, 웹은 Kotlin/Wasm GC가 React 컴포넌트를 그릴 수 있는 단계에 들어섰다. JetBrains가 K2 컴파일러를 Kotlin 2.0(2024년 5월)에서 GA로 올린 뒤, 2.1과 2.2로 이어지면서 컴파일 속도는 평균 2배 빨라졌고, 컴파일러 플러그인은 KSP 2로 일원화되었다.

이 글은 2026년의 Kotlin 스택을 처음부터 끝까지 — 언어·동시성·KMP·UI·서버·DB·DI·테스트·웹·커뮤니티까지 — 한 호흡으로 정리한다. 코드는 다 돌아가는 코드를 인용하고, 라이브러리 버전은 2026년 5월 기준 최신을 따른다.

기억할 한 줄: Kotlin은 이제 "JVM의 더 나은 언어"가 아니라, "멀티런타임 시대의 멀티플랫폼 언어"다.

1장 · Kotlin 2.1과 2.2 — K2 컴파일러가 바꾼 것

먼저 언어 자체부터. Kotlin 2.0(2024년 5월)의 핵심은 K2 컴파일러 GA였다. K2는 기존 컴파일러를 처음부터 다시 짠 것으로, 프론트엔드(파서·타입 체커)와 백엔드(IR 생성)를 모듈화했다. 이로 인해:

Kotlin 2.1(2024년 11월)에서 추가된 안정화 항목:

Kotlin 2.2(2025년 6월)는 컨텍스트 매개변수(context parameters)를 stable로 올리고, expect/actual 선언의 표현력을 늘렸다. 컨텍스트 매개변수는 이전의 context receivers를 대체하는 더 명확한 구문이다.

context(logger: Logger)
fun process(input: String) {
  logger.info("processing: $input")
}

// 호출부
with(myLogger) {
  process("hello")
}

2.2의 또 다른 변화: expect/actual의 간소화. 이제 단순한 typealias만으로 actual 선언을 끝낼 수 있고, 동일 시그니처에서는 보일러플레이트가 거의 사라진다.

2장 · Coroutines 1.10 — 구조화된 동시성의 완성

코루틴(kotlinx.coroutines)은 Kotlin의 비동기 표준이다. 2026년의 1.10 릴리스 기준으로 정리한다.

핵심 원칙 — 구조화된 동시성(Structured Concurrency): 모든 코루틴은 부모 CoroutineScope 안에서 산다. 부모가 취소되면 자식도 취소되고, 자식이 실패하면 부모도 실패한다(SupervisorJob은 예외).

import kotlinx.coroutines.*

suspend fun fetchUserData(): UserData = coroutineScope {
  val profile = async { fetchProfile() }
  val orders = async { fetchOrders() }
  val recs = async { fetchRecommendations() }
  UserData(profile.await(), orders.await(), recs.await())
}

coroutineScope는 셋 중 하나라도 실패하면 나머지를 취소하고 예외를 던진다. 이게 구조화된 동시성의 본질이다.

디스패처 선택:

1.10의 새 기능: CoroutineStart.UNDISPATCHED_PROCESSING, 더 정밀한 cancellation propagation, 그리고 Channel.consumeEach의 deprecation.

기억할 한 줄: 코루틴은 가벼운 스레드가 아니라, 가벼운 함수 호출이다.

3장 · Flow · StateFlow · SharedFlow — 반응형의 새 표준

Kotlin의 반응형 API는 RxJava를 대체했다. 셋의 차이부터.

타입콜드/핫용도
Flow콜드일회성 비동기 스트림, 매번 새 emitter
StateFlow핫항상 마지막 값을 가짐, UI 상태
SharedFlow핫다중 구독자 이벤트 브로드캐스트

Flow 예시 — combine·flowOn·stateIn:

val searchQuery: StateFlow<String> = ...
val filters: StateFlow<Filters> = ...

val results: StateFlow<List<Item>> = combine(searchQuery, filters) { q, f ->
  q to f
}
  .debounce(300)
  .mapLatest { (q, f) -> repository.search(q, f) }
  .flowOn(Dispatchers.IO)
  .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), emptyList())

여기서 flowOn은 업스트림의 디스패처를 바꾼다(다운스트림은 컬렉터의 컨텍스트). stateIn은 콜드 Flow를 핫 StateFlow로 변환하면서 5초 stop timeout을 둔다 — 화면 회전 같은 짧은 구독 끊김에서도 검색을 다시 트리거하지 않는다.

mapLatest vs flatMapLatest: 새 값이 들어오면 진행 중인 작업을 취소한다. 검색 자동완성처럼 "마지막만 중요한" 케이스에 쓴다.

SharedFlow 예시 — 이벤트 버스:

private val _events = MutableSharedFlow<UiEvent>(extraBufferCapacity = 1)
val events: SharedFlow<UiEvent> = _events.asSharedFlow()

fun trigger(e: UiEvent) {
  _events.tryEmit(e)
}

4장 · Kotlin Multiplatform — KMP가 안정 단계에 들어선 이유

KMP는 Kotlin 1.9.20(2023년 11월)에서 stable 선언되었다. 2026년 현재 채택 사례:

KMP의 구조는 단순하다: 공용 소스셋(commonMain)에는 플랫폼 무관 코드를, 플랫폼 소스셋(androidMain, iosMain, jvmMain, jsMain)에는 플랫폼별 구현을 둔다.

// commonMain
expect fun platformName(): String

// androidMain
actual fun platformName(): String = "Android ${Build.VERSION.SDK_INT}"

// iosMain
actual fun platformName(): String = "iOS ${UIDevice.currentDevice.systemVersion}"

Kotlin 2.2는 expect/actual을 더 간결하게 했다. 단순 typealias로 끝낼 수 있는 케이스가 늘었고, default implementation을 expect 쪽에 둘 수 있다.

무엇을 공유하나:

무엇을 공유하지 않나: UI는 선택. Compose Multiplatform을 쓰면 공유, SwiftUI를 쓰면 분리.

5장 · Compose Multiplatform 1.7 — iOS Stable의 의미

JetBrains의 Compose Multiplatform(CMP)은 2024년 5월 1.6.10에서 iOS를 beta로 올렸고, 2024년 11월 1.7에서 iOS stable을 선언했다. 2026년 5월 현재 안정 버전은 1.7.x 계열이다.

CMP는 Android의 Jetpack Compose UI 툴킷을 Skia 기반으로 모든 플랫폼에 가져온다:

iOS 인터롭: CMP의 컴포저블을 SwiftUI 안에 넣거나, SwiftUI 뷰를 CMP 안에 넣을 수 있다(UIKitView·UIViewController 래퍼).

@Composable
fun App() {
  MaterialTheme {
    Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {
      Text("Hello from CMP 1.7", style = MaterialTheme.typography.headlineMedium)
      // iOS·Android·Desktop·Web 모두에서 같은 코드로 동작
    }
  }
}

Navigation 2: 2026년 현재 dev 단계. KMP-native Navigation API로, Type-safe routing과 deep link를 공통 코드에서 정의한다.

6장 · Jetpack Compose 1.7 — Strong Skipping과 성능

Android의 Jetpack Compose는 1.7(2024년 9월)에서 strong skipping을 기본으로 켰다. 이전에는 @Stable 어노테이션이 붙은 타입만 자동으로 재구성(recomposition)에서 스킵되었지만, strong skipping에서는 lambda를 포함한 모든 함수가 기본적으로 스킵된다.

@Composable
fun UserCard(user: User, onClick: () -> Unit) {
  // strong skipping 덕에 user가 같으면 onClick이 매번 새 람다여도
  // 이 함수는 재구성되지 않는다.
  Card(onClick = onClick) {
    Text(user.name)
  }
}

Lazy 레이아웃 개선: LazyColumn·LazyRow·LazyGrid가 prefetch와 sticky header에서 더 빠르다.

Compose Compiler 통합: Kotlin 2.0부터 Compose Compiler는 Kotlin 본체에 통합되어 버전 매칭 고민이 사라졌다.

기본 성능 패턴:

기억할 한 줄: Compose는 "선언적"이지만, 그 선언이 매 프레임 다시 실행된다 — 그래서 스킵이 곧 성능이다.

7장 · Ktor 3.0 — 서버 사이드의 표준

JetBrains가 만든 Ktor는 3.0(2024년 10월)에서 JVM뿐 아니라 Native·JS도 서버로를 표준으로 올렸다. Spring Boot에 비해 작고, 가볍고, 코루틴 네이티브다.

import io.ktor.server.application.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*
import io.ktor.server.routing.*
import io.ktor.server.response.*

fun main() {
  embeddedServer(Netty, port = 8080) {
    routing {
      get("/") {
        call.respondText("Hello Ktor 3.0")
      }
      get("/users/{id}") {
        val id = call.parameters["id"]
        call.respondText("user: $id")
      }
    }
  }.start(wait = true)
}

3.0의 새 기능:

install(SSE)

routing {
  sse("/stream") {
    repeat(10) { i ->
      send(ServerSentEvent("tick: $i"))
      delay(1000)
    }
  }
}

Native 빌드: kotlin-multiplatform + ktor-server-cio로 Linux/macOS 단일 바이너리를 만들 수 있다 — Lambda·Cloud Run의 cold start가 훨씬 짧다.

8장 · Exposed 0.56 — Kotlin ORM의 표준

JetBrains의 Exposed는 0.56(2025년)에서 코루틴 통합과 R2DBC 지원을 안정화했다. 두 가지 API를 제공한다:

DSL API — SQL을 그대로 옮긴 듯한 빌더:

object Users : IntIdTable() {
  val name = varchar("name", 50)
  val email = varchar("email", 100).uniqueIndex()
  val createdAt = datetime("created_at").defaultExpression(CurrentDateTime)
}

transaction {
  Users.insert {
    it[name] = "Alice"
    it[email] = "alice@example.com"
  }

  Users.selectAll()
    .where { Users.name like "A%" }
    .map { it[Users.name] }
}

DAO API — 엔티티 객체 매핑:

class User(id: EntityID<Int>) : IntEntity(id) {
  companion object : IntEntityClass<User>(Users)
  var name by Users.name
  var email by Users.email
}

transaction {
  val alice = User.new {
    name = "Alice"
    email = "alice@example.com"
  }
}

대안: Komapper(컴파일 타임 코드 생성으로 더 빠름), Ktorm(가벼운 DSL), JOOQ(엔터프라이즈 표준이지만 Kotlin friendly).

9장 · KSP 2.x — KAPT는 죽었다

KSP(Kotlin Symbol Processing)는 KAPT를 대체하는 컴파일러 플러그인 프레임워크다. KAPT는 Java annotation processing API를 흉내내려고 Java stub을 만들었기 때문에 느렸다. KSP는 Kotlin 컴파일러의 IR을 직접 읽어 약 2배 빠르다.

KSP 2.x(2024년 GA)는 K2 컴파일러 위에서 동작한다. 거의 모든 주요 annotation processor가 KSP로 이전했다:

// build.gradle.kts
plugins {
  id("com.google.devtools.ksp") version "2.1.0-1.0.29"
}

dependencies {
  ksp("androidx.room:room-compiler:2.7.0")
}

KAPT 사용 프로젝트는 마이그레이션을 권장 — 빌드 시간이 즉시 절반으로 준다.

10장 · Arrow 2.0 — Typed Errors와 Raise DSL

Arrow는 Kotlin의 functional programming 라이브러리다. 2.0(2024년 1월)에서 Raise DSL을 stable로 올리면서 typed errors의 새 패러다임을 제시했다.

기존의 Either<Failure, Success> 사용은 모나드 콤프리헨션이나 flatMap 체이닝이 필요했다:

// Arrow 1.x 스타일
fun process(input: String): Either<Error, Result> = either {
  val parsed = parse(input).bind()
  val validated = validate(parsed).bind()
  compute(validated).bind()
}

Arrow 2.0의 Raise는 같은 의미를 함수 컨텍스트로 표현한다:

context(raise: Raise<Error>)
fun parse(input: String): Parsed = ...

context(raise: Raise<Error>)
fun process(input: String): Result {
  val parsed = parse(input)        // bind 불필요
  val validated = validate(parsed)
  return compute(validated)
}

// 호출부 — 한 곳에서 잡는다
val result: Either<Error, Result> = either {
  process(userInput)
}

Raise의 장점:

Arrow 2는 또한 optics(deep immutable updates)와 typed fp utilities(traverse·sequence·zip)를 함께 제공한다.

11장 · kotlinx.serialization 1.7 — JSON·Protobuf·CBOR 통합

JetBrains의 직렬화 라이브러리는 1.7(2024년)에서 컴파일 타임 코드 생성과 멀티플랫폼을 한꺼번에 처리한다. 리플렉션이 없어 Kotlin/Native와 Wasm에서도 동작한다.

import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(val id: Int, val name: String, val email: String)

val user = User(1, "Alice", "alice@example.com")
val jsonStr = Json.encodeToString(user)
val parsed = Json.decodeFromString<User>(jsonStr)

1.7의 핵심: JSON 외에 Protobuf·CBOR·HOCON 포맷 추가, Json.encodeToStream (스트리밍 API), 그리고 polymorphic serialization 개선.

@Serializable
sealed interface ApiResponse {
  @Serializable @SerialName("success") data class Ok(val data: User) : ApiResponse
  @Serializable @SerialName("error") data class Err(val code: Int, val message: String) : ApiResponse
}

val response: ApiResponse = Json.decodeFromString<ApiResponse>(jsonStr)

Ktor·Retrofit·OkHttp 모두 kotlinx.serialization 컨버터를 기본 지원한다.

12장 · 의존성 주입 — kotlin-inject · Koin 4 · Anvil

JVM의 Dagger 2는 여전히 표준이지만, Kotlin/KMP 환경에서는 대안이 늘었다.

kotlin-inject (KSP 기반, KMP 지원):

@Inject class UserService(private val repo: UserRepository)

@Component abstract class AppComponent {
  abstract val userService: UserService
}

Koin 4 (런타임 DSL, 가장 쉬움):

val appModule = module {
  single<UserRepository> { UserRepositoryImpl(get()) }
  factory { UserService(get()) }
}

startKoin { modules(appModule) }

Dagger Anvil (Square): Dagger 위에 Kotlin DSL을 얹어 보일러플레이트를 줄였다. 2.5에서 KSP를 지원한다.

선택 기준:

13장 · Kotlin/Native와 iOS 인터롭

Kotlin/Native는 LLVM 기반 백엔드로, JVM 없이 머신 코드로 컴파일한다. iOS·macOS·Linux·Windows·Wasm을 타깃으로 한다.

iOS 인터롭: Objective-C·Swift와 양방향이다. Swift 5.10부터는 swift-export 기능(아직 experimental)이 더 자연스러운 Swift API를 생성한다.

// Kotlin
class Greeter {
  fun greet(name: String): String = "Hello, $name"
}

// Swift에서 사용
let greeter = Greeter()
let msg = greeter.greet(name: "Alice")

메모리 모델: Kotlin/Native는 2022년에 새 메모리 모델로 전환했다. 이전의 "freeze" 제약이 사라져 멀티스레드 코드를 JVM과 동일하게 짤 수 있다. 코루틴은 기본적으로 thread-safe하게 동작한다.

제약:

14장 · Android 16 — SDK 35·Predictive Back·Material 3 Expressive

2026년 5월 현재, Android 15(API 35)는 안정, Android 16은 dev preview다. Kotlin 개발자가 알아야 할 핵심:

SDK 35 (Android 15):

Material 3 Expressive (Android 16 preview):

개발 환경:

15장 · 서버 사이드 — Spring Boot · Micronaut · Helidon Nima

JVM 서버에서 Kotlin은 1급 시민이다. 2026년 기준 주요 프레임워크:

Spring Boot 3.4 (2024년 11월): Kotlin DSL 지원, Virtual Threads(Loom) 통합, GraalVM Native Image 안정.

@SpringBootApplication
class Application

@RestController
class UserController(private val userService: UserService) {
  @GetMapping("/users/{id}")
  fun get(@PathVariable id: Long): User = userService.findById(id)
}

fun main(args: Array<String>) {
  runApplication<Application>(*args)
}

Micronaut 4.7: AOT 컴파일 + Kotlin Symbol Processing. cold start가 Spring Boot보다 5배 짧다.

Helidon Nima (Oracle): Virtual Threads 위에 동기 코드 스타일로 짜는 서버. Kotlin coroutines과의 시너지는 직접 wrapper가 필요하지만, "동기처럼 짜고 비동기처럼 도는" 그림이 매력적이다.

선택 기준:

16장 · Gradle Kotlin DSL — 빌드 설정도 Kotlin

build.gradle.kts는 이제 사실상 표준이다. Groovy DSL과 비교해:

plugins {
  kotlin("jvm") version "2.1.0"
  kotlin("plugin.serialization") version "2.1.0"
  id("com.google.devtools.ksp") version "2.1.0-1.0.29"
}

dependencies {
  implementation("io.ktor:ktor-server-core:3.0.0")
  implementation("io.ktor:ktor-server-netty:3.0.0")
  implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.10.0")
  implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0")

  testImplementation(kotlin("test"))
  testImplementation("io.kotest:kotest-runner-junit5:5.9.0")
}

tasks.test {
  useJUnitPlatform()
}

Version catalog(libs.versions.toml) 권장 — 의존성 버전을 한 곳에서 관리하고, 모듈 간 일관성을 강제한다.

Configuration cache: Gradle 8.x부터 기본. 첫 실행 후 후속 실행은 task graph를 재사용해 30~70% 빠르다.

17장 · Testing — JUnit 5 · Kotest · MockK · Turbine

Kotlin 테스트 스택은 2026년에 다음 조합이 표준이다.

JUnit 5 + kotlin.test: 가장 흔한 기본. @Test, @BeforeEach, @DisplayName을 그대로 쓴다.

Kotest 5.9: BDD 스타일 + property-based testing.

class UserSpec : StringSpec({
  "should return name in uppercase" {
    User("alice").nameUpper() shouldBe "ALICE"
  }

  "all positive numbers double" {
    checkAll<Int> { n ->
      if (n > 0) (n * 2) shouldBeGreaterThan n
    }
  }
})

MockK 1.13: Mockito와 비슷하지만 Kotlin native. coEvery로 코루틴을 자연스럽게 mock한다.

val repo = mockk<UserRepository>()
coEvery { repo.findById(1) } returns User(1, "Alice")

val service = UserService(repo)
runTest {
  service.getName(1) shouldBe "Alice"
}

Turbine (Cash App): Flow 테스트의 표준.

runTest {
  myFlow.test {
    awaitItem() shouldBe "first"
    awaitItem() shouldBe "second"
    awaitComplete()
  }
}

18장 · KMP 라이브러리 생태계 — Datetime · IO · Crypto

KMP가 stable이 된 뒤 JetBrains가 표준 라이브러리를 정리하기 시작했다.

import kotlinx.datetime.*

val now: Instant = Clock.System.now()
val zoned = now.toLocalDateTime(TimeZone.of("Asia/Seoul"))
val plus3h = now.plus(3.hours)

19장 · Kotlin/Wasm — 웹의 새 가능성

Kotlin 1.9.20부터 Kotlin/Wasm 타깃이 추가되었다. 2024년 Wasm GC 표준이 Chrome·Firefox에서 stable이 되면서, Kotlin은 JS 변환 없이 Wasm 바이너리를 만들 수 있다.

왜 중요한가: Kotlin/JS는 출력 크기가 크고 인터롭 표면이 넓었다. Wasm GC는 JVM·V8과 같은 가비지 컬렉터를 브라우저 안에 가지므로, Kotlin·Compose의 객체 모델이 변환 없이 동작한다.

상태(2026년 5월): Kotlin/Wasm은 alpha이지만, Compose Multiplatform for Web은 이 백엔드 위에서 stable에 가까워졌다. JetBrains의 라이브 데모(Compose Image Viewer)가 그 증거다.

KVision, Kobweb: Kotlin/Wasm·JS로 만드는 풀스택 웹 프레임워크. Kobweb은 Compose 기반이고, KVision은 React-like 컴포넌트 모델이다.

// Compose for Web (Wasm GC)
@Composable
fun App() {
  var count by remember { mutableStateOf(0) }
  Column {
    Text("Count: $count")
    Button(onClick = { count++ }) { Text("Increment") }
  }
}

20장 · 한국 Kotlin 커뮤니티 — Kotlin Seoul과 Kotlin Days Korea

서울 기반의 Kotlin 커뮤니티는 활발하다:

학습 자료: JetBrains Academy 한국어, "Kotlin in Action" 2판 한글판, "Kotlin Coroutines: Deep Dive" 번역본.

기업 채용 시장에서 Kotlin은 Android 외에 서버(Ktor·Spring Boot Kotlin)·핀테크(KMP)에서 빠르게 늘고 있다. 2026년 기준 Naver·Kakao·Toss·Coupang이 Kotlin 서버를 운영한다.

21장 · 일본 Kotlin 커뮤니티 — Kotlin Fest와 DroidKaigi

도쿄도 활발하다:

기업에서는 Cyberagent, DeNA, Mercari, Yahoo! Japan, LINE 등이 Kotlin·KMP를 프로덕션에서 쓴다. Mercari의 KMP 도입 케이스(2022년)는 KotlinConf에서 발표되었다.

학습 자료: "Kotlin인 액션" 일본어판, Wantedly·Mercari 엔지니어링 블로그의 Kotlin 시리즈, DroidKaigi 영상 아카이브.

22장 · 2026년 Kotlin 채택 매트릭스 — 어디서 무엇을 쓸 것인가

마지막으로 정리. "무엇을 만들 때 무엇을 쓰나"의 단순 매트릭스.

만드는 것권장 스택
Android only 앱Kotlin 2.x + Jetpack Compose 1.7 + Hilt/Koin + Room + Coroutines/Flow
iOS + Android (UI 분리)KMP commonMain (Ktor Client + Serialization + SQLDelight) + 각자 SwiftUI/Compose
iOS + Android + DesktopCompose Multiplatform 1.7 + KMP commonMain
서버 마이크로서비스Ktor 3 또는 Spring Boot 3.4 Kotlin
데이터 인텐시브 서버Spring Boot + Exposed/JOOQ + Coroutines
Native CLIKotlin/Native + ktor-client + clikt
풀스택 웹Kobweb (Compose for Web) 또는 KVision
Annotation processor 사용KSP 2.x (KAPT는 피할 것)
FP 스타일 도메인 모델Arrow 2 (Raise + Optics)

기억할 한 줄: Kotlin은 도구가 아니라 생태계가 되었다. 무엇을 만들든 — 그 자리에 맞는 Kotlin 도구가 이미 있다.

에필로그 — 멀티플랫폼이 진짜로 일하는 시대

2026년의 Kotlin은 "JVM 위의 더 나은 Java"라는 첫 번째 정체성을 넘어선 지 오래다. K2 컴파일러 GA로 컴파일 속도가 풀렸고, Compose Multiplatform 1.7이 iOS를 stable로 올렸으며, Wasm GC가 웹의 마지막 퍼즐을 채웠다. KSP 2와 Arrow 2가 컴파일러 확장과 typed FP의 표준이 되었고, Ktor 3가 서버 사이드에 자리잡았다.

Kotlin을 처음 만지는 사람에게는 — Coroutines와 Flow부터 익히는 게 가장 빠른 길이다. Android만 한다면 거기서 Compose로, 서버를 한다면 Ktor로, 멀티플랫폼을 본다면 KMP 라이브러리(kotlinx-*)부터.

마지막 한 줄: "한 번 짜서 모든 플랫폼에서 돈다"는 약속은 종종 거짓이었지만 — 2026년의 KMP에서는 그게 비즈니스 로직 한정으로는 거의 사실이다.

참고 자료

  1. Kotlin Blog — Kotlin 2.0 Released
  2. Kotlin Blog — Kotlin 2.1.0 Released
  3. Kotlin Blog — Kotlin 2.2.0 Released
  4. Kotlin Multiplatform Stable Announcement
  5. Compose Multiplatform 1.7 — iOS Stable
  6. Jetpack Compose 1.7 Release Notes
  7. Kotlin Coroutines Documentation
  8. Ktor 3.0 Release
  9. Exposed — Kotlin SQL Framework
  10. KSP 2 Documentation
  11. Arrow 2.0 — Typed Errors
  12. kotlinx.serialization Guide
  13. kotlin-inject
  14. Koin 4 Documentation
  15. Spring Boot 3.4 Release Notes
  16. Kotlin Multiplatform Libraries List
  17. Kotlin/Wasm Documentation
  18. SQLDelight 2.x
  19. Kotest Documentation
  20. Turbine — Flow Testing
  21. Android 15 Behavior Changes
  22. Material 3 Expressive — Android Developers

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다