코틀린 2.4-RC 핵심 4축, 안드로이드 6년차의 사이드 프로젝트 적용 기록

 

얼마 전 회사 안드로이드 팀 카톡 단톡방에 "Kotlin 2.4 LTS 떴다" 라는 메시지가 올라왔는데요. 열어보니 LTS 가 아니라 stdlib JVM 한정 보안 백포트 정책이더라고요.

 

코틀린(Kotlin) 2.4-RC 변경점 4축, 한 줄로 정리

5/13 에 풀린 2.4.0-RC 릴리즈 노트를 한 줄로 줄이면 "언어·표준 라이브러리·KMP·보안" 4축이 한꺼번에 움직였습니다. 한 줄씩 짚어보면 이렇습니다.

1. 언어: Context Parameters, Explicit Backing Fields, Annotation Use-site Targets 가 Stable 로 올라왔습니다. Hilt 모듈 2개에 Context Parameters 를 PoC 로 끼워봤어요.
2. 표준 라이브러리: UUID API 와 정렬 검증 함수가 정식 안정화 단계로 들어왔습니다.
3. KMP/네이티브: Swift Export 가 이번 RC 에서 또 한 번 개선됐고(아직 Experimental 단계이긴 합니다), Objective-C 호환 코드 한정으로 Swift Package 를 의존성으로 바로 끌어다 쓸 수 있게 됐어요.
4. 보안: JVM kotlin-stdlib 런타임에 한정된 18개월 보안 백포트 정책이 새로 생겼습니다.

각 축이 영향을 주는 지점이 다릅니다. 그래서 회사 프로덕션 4개 모듈은 정식 GA 이후 2.4.10+ 까지 본 뒤 검토하기로 일정을 잡고, 사이드 프로젝트에서만 하나씩 갈아끼워봤어요.

 

stdlib 18개월 보안 백포트, LTS 와는 다른 자리

이름 때문에 처음엔 LTS 인 줄 알았는데, 막상 문서를 읽어보니 LTS 가 아니었습니다. 적용 대상은 JVM kotlin-stdlib 아티팩트 하나, 범위는 CVE 같은 보안 패치 백포트로 한정돼 있어요. 컴파일러·툴링·KMP·네이티브 런타임은 빠지는 것으로 알려져 있습니다.

 

"버전 업데이트를 멈춰도 된다"는 뜻이 절대 아닙니다. 기능 패치도, 일반 버그픽스도 백포트 대상이 아니라서 정기 마이그레이션은 그대로 굴려야 해요.

 

 

저는 4개 모듈 중 결제·인증 2개만 stdlib 버전을 명시적으로 핀했습니다. 나머지 2개는 그래들(Gradle) BOM 으로 받아 자연스럽게 따라가게 두었고요. 2.5 가 나오면 2.4 백포트 기간이 단축될 가능성이 있어서, 분기마다 마이그레이션 검토 일정은 따로 캘린더에 박아뒀어요.

 

자바(Java) 26 지원, 안드로이드 빌드 툴체인은 어디까지

안드로이드 런타임은 이번에도 그대로입니다. 안드로이드 타깃은 여전히 1.8/11/17 이고, R8 이 디슈가링으로 받아주는 구조도 안 바뀌었어요. JDK 26 바이트코드가 단말기 위에서 그대로 도는 게 아닙니다.

 

 

대신 빌드 툴체인을 JDK 26 으로 올리면 컴파일·테스트·정적 분석 단계에서 성능과 보안 패치 효과를 받을 수 있어요. 다만 안드로이드 그래들 플러그인(AGP) 호환성이 1~2분기 뒤에나 안정화될 것으로 보여서, 저는 CI 잡만 JDK 26 으로 굴리고 로컬 안드로이드 스튜디오(Android Studio) 는 17 에 묶어뒀습니다.

 

자바 26 의 HTTP/3 Client 도 욕심나서 만져봤는데요. 안드로이드에서 직접 쓰긴 어려워서 KMP 공유 모듈 중 백엔드 사이드에서만 PoC 로 분리해 돌려봤어요. 자바 26 자체가 비-LTS 이고, 다음 LTS 는 2027년 9월 자바 29 가 예정돼 있어서 프로덕션 빌드 환경 전환은 29 GA 이후로 미루는 게 마음 편합니다.

 

스위프트 익스포트(Swift Export) 개선, KMP iOS 에서 SKIE 뺀 후기

이번 릴리즈에서 KMP 진영이 가장 들썩인 부분이에요. Objective-C 헤더를 거치지 않고 코틀린 코드를 Swift 모듈로 바로 내보내는 길이 한층 다듬어졌고, 무엇보다 kotlinx.coroutines.Flow 가 Swift AsyncSequence 로 직접 매핑돼 for await 구문을 그대로 쓸 수 있게 됐습니다.

 

사이드 프로젝트 iOS 모듈에서 SKIE 의존성을 한 번 빼고 굴려봤더니, Flow 래퍼로 둘러쳐 두던 Swift 쪽 코드가 30줄 정도 줄어들더라고요. for await event in repository.events() 가 별도 래퍼 없이 컴파일됐을 때 솔직히 좀 통쾌했네요.

 

 

다만 제네릭과 Sealed Class 매핑은 여전히 제약이 큽니다. 화면 상태를 sealed class 로 묶어두던 부분은 임시로 enum + 보조 데이터 클래스로 우회했어요. Swift Export 는 아직 Experimental 단계라 프로덕션에 쓰기는 이르고, 회사 iOS 빌드는 SKIE 를 그대로 유지하기로 했습니다.

 

UUID·sorted 안정화, KMP 분기 파일이 통째로 사라진 자리

가장 체감이 빨랐던 건 사실 작은 표준 라이브러리 변화였습니다. 그동안 KMP 모듈에서 UUID 를 쓰려고 expect/actual 로 플랫폼 분기를 떠놓던 케이스가 있었는데요. 이걸 stdlib Uuid.random() 한 줄로 갈아끼우니, 플랫폼 분기 파일 네 개가 통째로 사라졌습니다.

 

정렬 여부를 검증하던 헬퍼 함수도 stdlib 의 정렬 체크 API 한 줄로 압축됐어요. 5줄짜리 확장 함수가 사라지면서 테스트 코드도 같이 짧아졌습니다.

 

 

메타데이터 안에 어노테이션을 기본으로 담아주는 변화도 작지만 큰 지점입니다. DI 프레임워크가 리플렉션으로 어노테이션을 잡아갈 때 R8 keep 룰을 별도로 깔아두던 게 정리될 후보로 보이는데요. 다만 Hilt·Koin 같은 프레임워크가 공식적으로 받아주는 시점을 본 뒤에 룰을 걷어내야 할 것 같습니다. 지금 미리 빼면 릴리즈 빌드에서 NoSuchMethodException 이 터질 여지가 있어서, 저는 keep 룰 폐기 후보 목록에만 적어두고 멈췄어요.

 

마치며

개인적으로 이번 2.4-RC 에서 무게가 가장 실리는 건 Context Parameters 나 Swift Export 같은 큰 카드가 아니었습니다.

 

 

UUID·sorted 같은 작은 표준 라이브러리 안정화 쪽이 사이드 프로젝트 빌드 시간과 KMP 분기 파일 수를 실제로 줄여줬어요. 보안 정책은 이름만 그럴싸하지 LTS 와 같은 자리는 아닙니다. 회사 프로덕션은 2.4.10+ 까지 기다린 뒤 옮기고, 사이드 프로젝트는 RC 단계에서 미리 굴려보는 두 갈래로 갈라둔 게 이번 분기에 제일 잘 한 결정이었네요.