곧 출시될 8월의 컴포즈 Bill of Materials의 일환으로 젯팩 컴포즈 1.5를 출시한다. 젯팩 컴포즈는 플레이 스토어, 드롭박스, 에어비앤비와 같은 앱에서 사용되는 안드로이드의 현대적이고 네이티브한 UI 툴이다. 이번 업데이트에는 주로 성능 개선에 중점을 두었으며, 2022년 10월 업데이트부터 시작한 모디파이어 리팩토링이 이번 업데이트에 적용됐다.

2021년 컴포즈 1.0에서는 올바른 표준 api 구축하여 안정적인 기반을 제공하는데 중점을 두었다. 구글은 더 강한 양질의 api를 필요로 했으며, 사용이 쉽고 안정적이어서 개발자들이 프로덕션 환경에서 사용할 수 있도록 했다. 지속적인 api 개선에서 성능 향상은 최우선이며, 이번 업데이트에서는 많은 성능 개선 사항이 도입됐다.

모디파이어 성능

상술한 바와 같이 이번 업데이트에서 대규모 성능 개선이 이루어졌는데 컴포지션(앱 ui를 설정하고 컴포저블을 실행하여 재생성하는 일련의 과정) 시간이 최대 80% 단축됐다. 이는 컴포즈 첫 출시에 표준 api가 올바르게 구축되어 나타난 결과이며, 컴포즈로 작성된 앱 대부분이 이러한 이점을 누릴 수 있다.

구글에서는 성능 회귀를 모니터링하고, 성능 향상 투자에 이용되는 벤치마크 스위트를 보유 중이다. 초기 1.0 배포 이후에는 무엇을 개선할 수 있는가에 중점을 두었고, 벤치마크를 예상보다 더 많은 시간을 투자해 모디파이어를 구체화하고 있음을 알 수 있었다. 모디파이어는 컴포즈 트리 대부분을 차지하며, 이로 인해 컴포즈의 컴포지션 시간에서 가장 많은 부분을 차지하게 됐다. 더 효율적인 디자인으로 모디파이어를 리팩토링한 작업은 2022년 10월에 출시됐다.

2022년 10월 업데이트에서는 최하위 모듈인 컴포즈 ui에서 신규 api 출시와 성능 개선이 이루어졌다. 모디파이어는 서로 빌드되기에 다음 배포(2023년 3월)애서는 컴포즈 파운데이션에서 최하위 모디파이어의 마이그레이션을 시작했다. 해당 작업에는 graphicsLayer, 최하위 포커스 모디파이어, padding과 offset이 포함되어 있다. 이러한 최하위 모디파이어들은 Clickable과 같은 많은 모디파이어들에 의해 사용되며, Text와 같이 프레임워크 컴포저블에서도 사용된다. 2023년 3월 업데이트에서 모디파이어를 이전하면 이러한 컴포넌트에 성능 개선이 이루어질 수 있지만, 실제로 큰 효과를 볼 수 있는 것은 고수준의 모디파이어들과 컴포저블 자체를 신규 모디파이어 시스템으로 이전할 때이다.

이번 업데이트에서는 Clickable 모디파이어를 신규 모디파이어 시스템으로 마이그레이션하기 시작하여 컴포지션 시간이 최대 80% 단축됐다. 특히 버튼과 같이 클릭 가능한 요소를 포함하는 지연 목록(lazy list)에서 유용하다. Clickable에서 사용되는 Modifier.indication은 아직 마이그레이션 단계에 있으며, 향후 업데이트에 추가적인 개선이 있을 것으로 예상된다.

이 작업의 일환으로 원래 리팩토링에서 다루지 않은 composed 모디파이어에 대한 사용 사례를 확인하고, CompositionLocal 인스턴스를 사용하는 Modifier.Node를 생성하기 위한 신규 api를 추가했다.

현재 자신의 모디파이어를 신규 Modifier.Node api로 마이그레이션 절차에 관한 문서는 미작성 상태이며, 마이그레이션을 하려면 샘플 코드를 참고하길 바란다.

변경 사항에 대한 자세한 내용은 Android Dev Summit '22의 Compose Modifiers deep dive를 확인하실 바란다.

메모리

이번 업데이트에는 메모리 사용에 대한 여러 개선 사항이 포함되어 있다. 다양한 컴포즈 api 간에 발생하는 할당을 조사하여 많은 영역, 특히 그래픽 스택과 벡터 리소스를 불러올 때 총 할당량을 감소시켰다. 이는 컴포즈의 메모리 풋프린트를 줄일 뿐만 아니라, 메모리 할당 시간을 줄이고 가비지 수집을 감소시켜 성능이 직접적으로 향상됐다.

또한, ComposeView를 사용할 때 발생하는 메모리 누수에 대해 개선을 진행했다. 이로 인해 모든 앱은 긍정적인 영향을 받을 것이며, 특히 멀티 액티비티 아키텍처나 대량의 view/compose 상호 운용을 사용하는 앱에 큰 이점으로 다가올 것이다.

Text

BasicText는 모디파이어 작업을 지원하는 신규 렌더링 시스템으로 이동됐으며, 이로 인해 초기 컴포지션 시간이 평균적으로 22% 감소했으며, 텍스트가 포함된 복잡한 레이아웃의 한 벤치마크에서는 최대 70%까지 감소되었다.

다음을 포함한 여러 텍스트 관련 api가 안정화됐다.

• TextMeasurer와 그에 관한 api
• LineHeightStyle.Alignment (topRatio)
• Brush
• DrawStyle
• TextMotion
• DrawScope.drawText
• Paragraph.paint (brush, drawStyle, blendMode)
• MultiParagraph.paint (brush, drawStyle, blendMode)
• PlatformTextInput

핵심 기능에 대한 개선 및 수정

이번 업데이트에는 상술한 기능 외에도 핵심 api의 신규 기능과 개선점도 존재한다.

• LazyStaggeredGrid 안정화
• toComposePaint를 대체하는 asComposePaint api가 추가됐으며, 리턴된 객체는 원본 android.graphics.Paint를 래핑하기 위해 사용된다.
• SubcomposeLayout에 선행 검사를 지원하는 IntermediateMeasurePolicy 추가
• 소프트 키보드가 나타나기 전에 키 이벤트를 가로채는 onInterceptKeyBeforeSoftKeyboard 모디파이어 추가

원문

• What’s new in the Jetpack Compose August ’23 release

코틀린 1.9.0 릴리즈가 올해 7월 6일에 출시되으며 JVM용 K2 컴파일러 또한 베타 버전이 되었다. 아래는 코틀린 1.9.0의 주 특성이다.

• 코틀린 K2 컴파일러 업데이트
• 열거형 클래스의 value 기능에 대한 안정적인 대체
• 개방형 범위 ..< 연산자 안정화
• regex 캡쳐 그룹을 이름으로 가져오는 신규 공통 함수
• 상위 디렉토리 생성을 위한 새 경로 유틸리티
• 코틀린 다중 플랫폼에서 gradle 환경 설정 캐시 미리보기
• 코틀린 다중 플랫폼에서 Android Target 지원 변경
• Kotlin/Native에서 사용자 지정 메모리 할당자 미리보기
• Kotlin/Native의 라이브러리 연결
• Kotlin/Wasm size 관련 최적화

지원 IDE

코틀린 1.9.0을 지원하는 IDE는 아래와 같다.

또한, 코틀린 1.9.0은 추후에 출시될 IntelliJ IDEA 2023.2에도 지원될 것이다.

코틀린 아티팩트와 종속성을 다운로드하려면 Maven Central Repository를 사용하도록 Gradle 설정을 필수로 구성해야 한다.

코틀린 K2 컴파일러 업데이트

K2 컴파일러는 Kotlin/Native 및 다중 플랫폼 프로젝트에 대한 기본적인 지원이 있다.

K2 컴파일러와 kapt 컴파일러 플러그인의 호환성

k2 컴파일러와 kapt 플러그인을 같은 프로젝트에서 사용할 수 있지만, 몇 가지 제한 사항이 존재한다. languageVersion을 2.0으로 설정했음에도 kapt 컴파일러는 구식 컴파일러를 사용한다.

languageVersion이 2.0으로 설정된 프로젝트에서 kapt 컴파일러 플러그인을 실행하면 kapt는 자동으로 1.9로 전환되고 특정 버전 호환성 검사를 비활성화한다. 이 동작은 아래의 명령 인수를 포함하는 것과 같다.

• -Xskip-metadata-version-check
• -Xskip-prerelease-check
• -Xallow-unstable-dependencies

이러한 검사는 kapt 작업에만 사용이 불가능하다. 타 컴파일 작업은 k2 컴파일을 계속 사용할 것이다.

프로젝트에서 K2 컴파일러 사용

코틀린 1.9.0부터 2.0까지 kotlin.experimental.tryK2=true gradle 속성으로 k2 컴파일러를 테스트할 수 있다. 혹은 아래의 명령어를 실행해 테스트할 수 있다.

$ ./gradlew assemble -Pkotlin.experimental.tryK2=true

해당 gradle 속성은 자동으로 언어 버전으로 2.0으로 설정하고, 현재 컴파일러와 비교하여 k2 컴파일러를 사용해 컴파일한 코틀린 태스크의 수로 빌드 리포트를 업데이트한다.

##### 'kotlin.experimental.tryK2' results (Kotlin/Native not checked) #####
:lib:compileKotlin: 2.0 language version
:app:compileKotlin: 2.0 language version
##### 100% (2/2) tasks have been compiled with Kotlin 2.0 #####

Gradle build 리포트

gradle build 리포트는 코드 컴파일에 현재 컴파일러의 사용 여부와 k2 컴파일러의 사용 여부가 표시된다. 코틀린 1.9.0에서는 해당 정보를 gradle 빌드 스캔에서 확인할 수 있다.

프로젝트에서 사용된 코틀린 버전 또한 빌드 리포트에서 찾을 수 있다.

Task info:
  Kotlin language version: 1.9

현재 K2 컴파일러 제한 사항

gradle 프로젝트에서 k2를 활성화하면 아래와 같은 경우, gradle 버전 8.3 미만을 사용하는 프로젝트에 영향을 미칠 수 있는 몇 가지 제한 사항이 존재한다.

• buildSrc에서 소스 코드 컴파일
• gradle 플러그인 컴파일이 포함된 빌드
• gradle 버전 8.3 미만을 사용하는 프로젝트에서 타 gradle 플러그인을 컴파일
• gradle 플러그인 종속성 빌드

위에서 언급한 문제 중 하나가 발생했을 경우, 다음 단계를 수행하여 해결할 수 있다.

• buildSrc, 모든 gradle 플러그인 및 해당 종속성에 대한 언어 버전을 설정

  kotlin {
    compilerOptions {
        languageVersion.set(org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9)
        apiVersion.set(org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9)
    }
  }

• 프로젝트의 gradle 버전을 8.3으로 업데이트

언어

코틀린 1.9.0에서는 상술한 새로운 기능에 대한 안정화를 진행하고 있다.

열거형 클래스의 value 기능 대체

코틀린 1.8.20에서 열거형 클래스에 대한 entries 프로퍼티는 실험 기능으로 도입됐다. entries 프로퍼티는 합성 value() 함수를 안정적으로 대체한다.(value() 함수는 지원되지만 공식 문서에서는 entries 프로퍼티 사용을 권장)

enum class Color(val colorName: String, val rgb: String) {
    RED("Red", "#FF0000"),
    ORANGE("Orange", "#FF7F00"),
    YELLOW("Yellow", "#FFFF00")
}

fun findByRgb(rgb: String): Color? = Color.entries.find { it.rgb == rgb }

열거형 클래스의 entries 프로퍼티에 대한 내용은 What's new in Kotlin 1.8.20을 참고하길 바란다.

데이터 클래스와의 데이터 객체 대칭

코틀린 1.8.20에 도입된 데이터 객체선언은 안정화가 되었다. 여기에는 데이터 클래스와의 대칭을 위해 추가된 함수인 toString(), equals(), hashCode() 함수가 포함된다.

해당 기능은 데이터 객체 선언과 함께 편리하게 사용할 수 있기에 sealed 계층(sealed 클래스나 sealed 인터페이스 계층)에 특히 유용하다. 아래의 예제에서 EndOfFile을 일반 개체 대신 데이터 개체로 선언하면 재정의할 필요 없이 toString() 함수를 자동으로 포함한다. 이는 함께 제공되는 데이터 클래스 정의와 대칭을 유지한다.

sealed interface ReadResult
data class Number(val number: Int) : ReadResult
data class Text(val text: String) : ReadResult
data object EndOfFile : ReadResult

fun main() {
    println(Number(7)) // Number(number=7)
    println(EndOfFile) // EndOfFile
}

자세한 내용은 What's new in Kotlin 1.8.20을 참고하길 바란다.

인라인 value 클래스에 본문이 있는 보조 생성자 지원

코틀린 1.9.0부터 인라인 value 클래스에 본문이 있는 보조 생성자를 사용할 수 있다.

@JvmInline
value class Person(private val fullName: String) {
    // 코틀린 1.4.30부터 허용
    init {
        check(fullName.isNotBlank()) {
            "Full name shouldn't be empty"
        }
    }
    // 코틀린 1.9.0부터 기본적으로 허용
    constructor(name: String, lastName: String) : this("$name $lastName") {
        check(lastName.isNotBlank()) {
            "Last name shouldn't be empty"
        }
    }
}

이전에 코틀린은 인라인 클래스에서 공개 기본 생성자만 허용했다. 결과적으로 기본 값을 캡슐화하거나 일부 제한된 값을 나타내는 인라인 클래스를 만드는 것은 불가능했다. 코틀린이 개발되며 이러한 문제가 수정되었다. 코틀린 1.4.30에서는 init 블록에 대한 제한이 해제되었고 코틀린 1.8.20에서는 본문이 있는 보조 생성자의 미리보기가 제공되었다. 이제 기본적으로 사용할 수 있게 됐다. 이 페이지에서 코틀린 인라인 클래스의 개발 과정에 대한 내용이 기술되어 있다.

Kotlin/JVM

코틀린 1.9.0부터 컴파일러는 jvm 20에 해당하는 바이트코드 버전으로 클래스를 생성할 수 있다. 또한 JvmDefault 어노테이션 및 레거시 -Xjvm-default 모드는 더 이상 사용되지 않는다.

코틀린 1.5부터 JvmDefault 어노테이션은 사용되지 않으며 -Xjvm-default 모드(all 및 all-compatibility)를 우선하는 방식으로 대체되었다. 코틀린 1.4에 도입된 JvmDefaultWithoutCompatibility와 코틀린 1.6에 도입된 JvmDefaultWithCompatibility와 함께, 이러한 모듈들은 DefaultImpls 클래스의 생성에 대한 포괄적인 제어를 제공하며, 이전 코틀린 코드와의 원활한 호환성을 보장한다.

결과적으로 코틀린 1.9.0에서는 JvmDefault 어노테이션이 지원되지 않기 때문에 사용 시, 오류가 발생하며, 추후 코틀린에서 제거될 예정이다.

Kotlin/Native

코틀린 1.9.0 릴리즈는 Kotlin/Native 메모리 관리자에게 견고성과 성능 향상을 위한 추가적인 개선점을 제공한다.

사용자 지정 메모리 할당기 미리보기

코틀린 1.9.0은 사용자 지정 메모리 할당기에 대한 미리보기를 제공한다. 해당 할당 시스템은 Kotlin/Native 메모리 관리자의 런타임 성능을 향상시킨다.

현재 kotlin/native의 객체 할당 시스템은 효율적인 Garbage Collection(이하 gc)을 위한 기능이 없는 범용 할당기를 사용한다. 이를 보완하기 위해 gc가 할당된 모든 객체를 단일 목록으로 병합하기 전에 스레드-로컬의 링크드 리스트를 유지한다. 해당 접근 방식에는 아래와 같은 성능 저하가 있다.

1. 스위핑 순서는 메모리 로컬리티가 부족하고, 대부분의 경우 메모리 액세스 패턴이 분산되며 이는 잠재적인 성능 문제로 직결된다.
2. 링크드 리스트에는 각 개체에 대한 추가 메모리가 필요하며 특히 작은 개체를 많이 처리할 때 메모리 사용량이 증가한다.
3. 할당된 개체의 단일 리스트는 스윕을 병렬화하기 어렵게 만든다. 이로 인해 뮤테이터 스레드가 gc 스레드보다 빠르게 개체를 할당할 때 메모리 사용 문제가 발생할 수 있다.

이러한 문제를 해결하기 위해 코틀린 1.9.0에서 사용자 지정 할당기 미리보기를 도입한다. 시스템 메모리를 페이지로 분할하여 순차적으로 독립적인 스위핑이 가능하다. 각 할당은 페이지 내 블록이 되고, 페이지는 블록의 크기를 추적한다. 서로 다른 페이지 유형은 다양한 할당 크기에 최적화되어 있으며 메모리 블록들의 연속적인 배열은 할당된 모든 블록들을 통해 효율적인 반복을 보장한다.

스레드가 메모리를 할당할 때 할당 크기에 따라 적합한 페이지를 검색한다. 스레드는 다양한 크기 범주에 대한 페이지 집합을 유지한다. 일반적으로 현재 페이지는 주어진 크기에 대한 할당을 수용할 수 있다. 그렇지 않으면 스레드는 공유 할당 공간에서 다른 페이지를 요청하게 되고, 해당 페이지는 이미 사용 중이거나 스위핑이 필요할 수 있으며, 먼저 생성되어야 할 수도 있다.

새로운 할당기는 복수의 할당 공간을 동시에 가질 수 있게 해주는데, 코틀린팀은 성능 향상을 위한 다양한 페이지 레이아웃을 실험적으로 사용할 수 있게 해준다.

새 할당기 설계에 대한 내용은 이 문서를 참조하면 된다.

-Xallocator=custom을 추가하면 사용할 수 있다.

kotlin {
    macosX64("native") {
        binaries.executable()

        compilations.configureEach {
            compilerOptions.configure {
                freeCompilerArgs.add("-Xallocator=custom")
            }
        }
    }
}

메인 스레드의 Objective-C 혹는 Swift 객체 할당 해제 hook

코틀린 1.9.0부터 objective-C 혹은 Swift 객체 할당 해제 hook는 객체가 코틀린에게 전달되면 메인 스레드에서 호출된다. kotlin/native 메모리 관리자가 이전에 objective-c 객체에 대한 참조를 처리하는 방식에 의해 메모리 누수 문제가 발생할 수 있었다. 새로운 동작은 메모리 관리자의 견고성을 향상시킬 수 있다.

예를 들어 인수로 전달되거나 함수에 의해 리턴되거나 컬렉션에서 검색될 때 코틀린 코드에서 참조되는 objective-c 객체를 생각해보면 코틀린은 objective-c 객체에 대한 참조를 보유하는 자체 객체를 생성한다. 코틀린 객체가 할당이 해제되면 kotlin/native 런타임은 objc_release 함수를 호출하여 objective-c 참조를 해제한다.

이전에는 kotlin/native 메모리 관리자가 objc_release를 special gc 스레드에서 실행했으며 그것이 마지막 개체의 참조라면 개체의 할당이 해제된다. objective-c 객체에 objective-c의 delloc 메소드나 swift의 deinit 블록과 같은 사용자 지정 할당 해제 hook가 있고 이러한 hook가 특정 스레드에서 호출된다면 문제가 발생할 수 있다.

일반적으로 메인 스레드의 객체 hook가 거기서 호출된다고 가정하기 때문에 kotlin/native 런타임은 메인 스레드에서도 objc_release를 호출한다. objective-c 객체가 메인 스레드의 코틀린에 전달되어 코틀린 peer 객체가 생성된 경우에 대해 설명한다. 일반 UI 애플리케이션의 경우, 메인 디스패치 대기열이 처리되는 경우에만 동작한다. 메인 큐가 아니거나 메인 스레드 이외에 타 스레드로 코틀린에 넘겨받았을 경우, 이전과 동일하게 special gc 스레드에서 objc_release가 호출된다.

비활성화

문제가 발생했을 경우, 아래의 옵션을 사용해 gradle.properties에서 해당 동작을 비활성화할 수 있다.

kotlin.native.binary.objcDisposeOnMain=false

Kotlin/Native에서 상수 값에 액세스할 때 객체 초기화하지 않음

코틀린 1.9.0부터 kotlin/native 백엔드 const val 필드에 액세스할 때 객체를 초기화하지 않는다.

object MyObject {
    init {
        println("side effect!")
    }

    const val y = 1
}

fun main() {
    println(MyObject.y) // 처음에는 초기화 없음
    val x = MyObject    // 초기화
    println(x.y)
}

이 동작은 kotlin/jvm에 통합되어 구현은 자바와 일관하고 있어, 이 경우에는 객체 초기화가 진행되지 않는다. 이 변경으로 kotlin/native 프로젝트의 성능 향상도 기대해 볼 수 있다.

Kotlin/Native에서 iOS 시뮬레이터 테스트를 위한 독립 실행형 모드 구성 기능

기본적으로 kotlin/native iOS 시뮬레이터 테스트를 실행하는 경우 --standalone 플래그를 사용하여 수동 시뮬레이터 부팅 및 종료를 방지한다. 1.9.0에서는 독립 실행형 속성을 사용하여 gradle 작업에서 해당 플래그의 사용 여부를 설정할 수 있다. 기본적으로 --standalone 플래그가 사용되므로 독립 실행형 모드는 활성화된다.

아래의 코드는 build.gradle.kts에서 독립 실행형 모드를 비활성화하는 코드이다.

tasks.withType<org.jetbrains.kotlin.gradle.targets.native.tasks.KotlinNativeSimulatorTest>().configureEach {
    standalone.set(false)
}

독립 실행형 모드를 사용하지 않도록 설정한 경우, 시뮬레이터를 수동으로 부팅해야 한다. cli에서 시뮬레이터를 부팅하려면 아래의 명령어를 사용하면 된다.

$ /usr/bin/xcrun simctl boot <DeviceId>

Kotlin/Native 라이브러리의 연결

코틀린 1.9.0부터 kotlin/native 컴파일러는 코틀린 라이브러리와 링크 문제를 kotlin/jvm과 동일하게 처리하게 된다. 어느 서드파티 코틀린 라이브러리 작성자가 타 서드파티 코틀린 라이브러리에서 사용하는 실험적 API에 호환되지 않은 변경을 가하는 경우, 이러한 문제에 직면하게 된다.

타사 코틀린 라이브러리 간의 링크 문제가 발생하더라도 컴파일 도중 빌드가 실패할 일은 없다. 대신, jvm의 경우와 같이 이러한 에러는 런타임에서만 발생한다.

kotlin/native 컴파일러는 라이브러리 링크 문제를 감지하면 경고를 보고한다. 예를 들어 컴파일 로그에서 아래와 같은 경고를 발견했다고 했을 때

No function found for symbol 'org.samples/MyRemovedClass.doSomething|3657632771909858561[0]'

Can not get instance of singleton 'MyEnumClass.REMOVED_ENTRY': No enum entry found for symbol 'org.samples/MyEnumClass.REMOVED_ENTRY|null[0]'

Function 'getMyRemovedClass' can not be called: Function uses unlinked class symbol 'org.samples/MyRemovedClass|null[0]'

프로젝트에서 아래의 동작을 추가로 구성하거나 비활성화할 수 있다.

• 컴파일 로그에서 위와 같은 경고를 표시하지 않으려면 -Xpartial-linkage-loglevel=INFO 컴파일 옵션을 설정하면 된다. 해당 옵션은 경고 심각도를 info 레벨로 낮추어 표시한다.

• 컴파일 옵션을 -Xpartial-linkage-loglevel=ERROR로 설정하여 보고된 경고 심각도를 에러 레벨로 올려서 표시한다. 이 경우에는 컴파일이 실패하고 컴파일 로그에 모든 오류가 표시된다. 해당 옵션을 사용하면 링크 문제를 더 상세히 확인할 수 있다.

• 해당 기능으로 예기치 않은 문제가 발생하면 -Xpartial-linkage=disable 컴파일 옵션을 사용해 해당 기능을 해제할 수 있다.

  // gradle 빌드 파일을 통해 컴파일 옵션을 지정하는 예제
  kotlin {
    macosX64("native") {
        binaries.executable()
  
        compilations.configureEach {
            compilerOptions.configure {
  
                // 경고 레벨을 info로 낮춤
                freeCompilerArgs.add("-Xpartial-linkage-loglevel=INFO")
  
                // 경고 레벨을 error로 높임
                freeCompilerArgs.add("-Xpartial-linkage-loglevel=ERROR")
  
                // 기능 비활성화
                freeCompilerArgs.add("-Xpartial-linkage=disable")
            }
        }
    }
  }

C언어 상호 운용의 묵시적 정수 변환을 위한 컴파일 옵션

kotlin/native의 안정화를 진행하면서, 묵시적 정수 변환이 가능한 c언어 상호운용 컴파일 옵션을 도입했다. 이전에는 묵시적인 정수 변환을 사용하기 위해 컴파일 옵션을 구성하지 않아도 됐으나 신중히 검토한 결과, 해당 기능에 대한 개선의 여지가 보였고 최고품질의 API를 구현하기 위해 의도치 않은 사용을 방지하기 위해 해당 컴파일 옵션을 도입했다.

아래의 코드에서는 묵시적 정수 변환으로 인해 options의 타입이 UInt이지만 0은 부호가 있는 정수(signed)임에도 options = 0이 할당되었다.

val today = NSDate()
val tomorrow = NSCalendar.currentCalendar.dateByAddingUnit(
    unit = NSCalendarUnitDay,
    value = 1,
    toDate = today,
    options = 0
)

네이티브 interop 라이브러리에서 묵시적 변환을 사용하려면 -XXLanguage:+ImplicitSignedToUnsignedIntegerConversion 컴파일 옵션을 사용해야 한다. 이는 아래의 코드와 같이 build.gradle.kts에서 구성할 수 있다.

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinNativeCompile>().configureEach {
    compilerOptions.freeCompilerArgs.addAll(
        "-XXLanguage:+ImplicitSignedToUnsignedIntegerConversion"
    )
}

Kotlin 멀티플랫폼

코틀린 1.9.0에서는 코틀린 멀티플랫폼의 DX(개발자 경험)의 향상을 위해 아래와 같은 업데이트가 진행됐다.

안드로이드를 대상으로 한 지원 변경

구글의 안드로이드팀이 코틀린 멀티 플랫폼에서 안드로이드를 지원하는 자체 gradle 플러그인을 제공할 예정이다. 또한, 새로운 솔루션에 대한 가능성을 열기 위해 1.9.0 버전에서 현재 코틀린 dsl의 android 블록의 이름을 변경한다. 빌드 스크립트에서의 android 블록을 androidTarget으로 변경해야 한다. 이는 추후에 출시될 구글 dsl의 android 이름을 확보하기 위한 일시적인 변경이다.

구글 플러그인은 다중 플랫폼 프로젝트에서 안드로이드를 사용할 때 권장되는 방안이다. 준비되면 필요한 마이그레이션 지침을 제공하여 이전과 동일하게 android 이름을 사용할 수 있게 될 것이다.

신규 안드로이드 소스 세트 레이아웃이 기본적으로 활성화

코틀린 1.9.0부터 신규 안드로이드 소스 세트 레이아웃이 기본 설정으로 적용된다. 이전의 디렉토리 네이밍 스키마가 혼동스러웠던 것을 대체했으며, 신규 레이아웃은 아래와 같은 이점을 제공한다.

1. 유형의 의미론 단순화 - 신규 안드로이드 소스 세트 레이아웃은 타 소스 세트 유형을 정확하고 일관되게 구분이 가능하도록 명명 규칙을 제공한다.
2. 소스 디렉토리 레이아웃 개선 - 신규 레이아웃을 통해 SourceDirectories 배열이 보다 일관적이게 구성되어 코드를 조직화하고 소스 파일를 쉽게 찾을 수 있다.
3. 명확해진 gradle 네이밍 스키마 - 이제 KotlinSourceSets와 AndroidSourceSets에서 더 일관되고 예측 가능한 스키마를 사용한다.

신규 레이아웃은 android gradle 7.0 이상과 Android Studio 2022.3 이상의 버전의 환경에서 사용할 수 있다. build.gradle(.kts)에서 필요한 변경 사항을 반영하려면 마이그레이션 가이드를 참고하길 바란다.

Gradle 환경 설정 캐시 미리보기

코틀린 1.9.0은 멀티플랫폼 라이브러리에서 gradle 환경 설정 캐시를 지원한다. 라이브러리 개발자는 이미 빌드 성능의 향상으로 이점을 누릴 수 있다.

gradle 환경 설정 캐시는 환경 설정 단계의 결과를 후속 빌드에 재사용하여 빌드 프로세스의 속도를 향상시킨다. 해당 기능은 gradle 8.1 이후에 안정화었으며 이를 활용하려면 gradle 문서의 지침을 참고하길 바란다.

Kotlin/Wasm

코틀린팀은 신규 kotlin/wasm을 대상으로 실험을 하고 있다. 이 릴리즈에서 성능과 용량 관련 최적화와 자바스크립트 상호 운용성이 업데이트됐다.

용량 관련 최적화

코틀린 1.9.0에서 웹 어셈블리 프로젝트 용량이 개선되었다. 위의 그래프는 1.8.20에서 작성된 Hello World 프로젝트와 1.9.0에서 작성된 Hello World 프로젝트의 용량을 나타내며, 코드의 용량이 1.8.20에 비해 1/10 수준으로 감소한 것을 확인할 수 있다. 이러한 용량 최적화로 코틀린 코드로 wsam 플랫폼에서 더 효율적인 리소스 활용과 향상된 성능이라는 결과를 가져오게 된다.

자바스크립트 상호 운용성 업데이트

이번 업데이트에서는 kotlin/wasm의 코틀린과 자바스크립트 간 상호 운용성이 포함된다. kotlin/wasm은 실험적인 기능이기에 상호 운용성에 대한 일부 제한 사항이 적용된다.

동적 타입 제한

코틀린 1.9.0부터 더 이상 kotlin/wasm에서 동적 타입을 지원하지 않는다. 이제 이러한 동적 타입은 새로운 범용 JsAny 타입으로 대체되어 js 상호 운용성을 용이하게 한다.

자세한 내용은 이 문서을 참고하길 바란다.

비외부형 타입의 제한

kotlin/wasm은 자바스크립트와 값을 교환할 때 특정 코틀린 정적 타입에 대한 변환을 지원한다. 이러한 지원되는 타입은 다음과 같다.

• 기본형 타입: 즉 부호가 있는 숫자나 Boolean, Char 등
• String
• 함수 타입

기타 타입들은 변환 없이 불분명한 참조로 전달되어 자바스크립트와 코틀린의 하위 타입 사이에서 불일치가 발생했다. 이를 해결하기 위해 코틀린은 자바스크립트 상호 운용성이 잘 지원되는 타입으로 제한된다. 코틀린 1.9.0부터는 kotlin.wasm 자바스크립트 상호 운영성에서 오직 external, primitive, string과 함수 타입만을 지원한다. 더불어, kotlin/wasm 객체에 대한 핸들을 자바스크립트 상호 운용성에 사용하기 위해 별도의 명시적 타입인 JsReference가 도입됐다.

자세한 내용은 kotlin/wasm과 자바스크립트 간의 상호 운용성 문서를 참고하길 바란다.

Kotlin Playground의 Kotlin/Wasm

코틀린 플레이그라운드는 kotlin/wasm 대상을 지원한다. kotlin/wasm을 대상으로 하는 코틀린 코드의 작성, 실행 및 공유가 가능하다. 이곳에서 확인이 가능하다.

kotlin/wasm을 활성하기 위해서는 브라우저에서 실험 기능을 활성화해야 한다. 이러한 기능을 활성화하는 방법은 이 문서에 나와있다.

Kotlin/JS

이번 kotlin/js 업데이트에는 gradle 플러그인의 지원 중단과 es6에 대한 실험적 지원을 포함한다.

Kotlin/JS Gradle 플러그인 지원 중단

코틀린 1.9.0부터 kotlin-js gradle 플러그인 지원이 중단되었다. 대신 js()와 함께 kotlin-multiplatform 플러그인을 사용하는 것을 권장한다.

kotlin/js gradle 플러그인은 kotlin-multiplatform 플러그인을 그대로 복제해서 본질적으로 동일하다. 이러한 중복으로 인해 코틀린팀의 혼란과 유지보수 부담이 증가됐다.

마이그레이션 지침은 코틀린 멀티플랫폼 호환성 가이드를 참고하길 바란다.

외부 열거형 지원 중단

코틀린 1.9.0에서는 코틀린 외부에 존재할 수 없는 entries와 같은 정적 열거형 멤버와 관련된 문제로 인해 외부 열거형을 사용하지 않는 것을 권장한다. 대신 외부 sealed class를 객체 하위 클래스와 같이 사용하는 것을 권장한다.

// 이전
external enum class ExternalEnum { A, B }

// 이후
external sealed class ExternalEnum {
    object A: ExternalEnum
    object B: ExternalEnum
}

객체 하위 클래스가 있는 외부 sealed class로 전환하면 기본 메소드와 관련된 문제를 피하면서 외부 열거형과 유사한 기능을 제공할 수 있다.

상술한 바와 같이 코틀린 1.9.0부터 외부 열거형 사용은 권장되지 않으며, 호환성과 향후 유지보수를 위해 외부 sealed class 구현하도록 코드를 업데이트하는 것이 좋다.

ES6 클래스 및 모듈에 대한 실험적 지원

이번 장에서는 업데이트에서는 es6 모듈과 es6 클래스 생성에 대한 실험적 지원에 대해 소개한다.

• 모듈은 코드베이스를 단순화하고 용이한 유지보수가 가능토록 한다.
• 클래스를 사용하여 oop 원리를 통합하여 깔끔하고 직관적인 코드를 만들 수 있다.

이러한 기능을 사용하기 위해서는 아래와 같이 build.gradle.kts를 구성해주어야 한다.

kotlin {
    js(IR) {
            useEsModules() // es6 모듈 활성화
            browser()
        }
    }

// es6 클래스 생성 사용
tasks.withType<KotlinJsCompile>().configureEach {
    kotlinOptions {
        useEsClasses = true
    }
}

자세한 내용은 ecma 스크립트 2015(es6) 문서를 참고하길 바란다.

JS 프로덕션 배포의 기본 경로 변경

코틀린 1.9.0 이전 버전에서는 배포 대상이 되는 디렉토리가 build/distributions였다. 그러나 이는 gradle 아카이브의 일반적인 디렉토리이기에 이 문제를 해결하기 위해 코틀린 1.9.0의 기본 배포 디렉토리를 build/dist/<targetName>/<binaryName>으로 변경했다.

예를 들어 productionExecutable는 원래 build/distributions 디렉토리에 존재했으나 build/dist/js/productionExecutable 디렉토리로 변경됐다.

만약, 빌드 결과를 사용하는 파이프라인(pipeline)이 이미 구축되어 있다면 해당 디렉토리를 업데이트를 필수적으로 해주어야 한다.

stdlib-js에서 org.w3c 임포팅 제거

코틀린 1.9.0 이후로 stdlib-js는 더 이상 org.w3c 임포팅을 사용하지 않는다. 다만, 해당 임포팅들은 별도의 gradle 종속성으로 이관됐다. 코틀린 멀티플랫폼 gradle 플러그인을 build.gradle.kts에 추가하면 표준 라이브러리와 같이 임포팅은 프로젝트에 자동으로 포함된다.

필요한 조정은 자동으로 처리되기 때문에 수동 작업이나 마이그레이션은 하지 않아도 된다.

Gradle

코틀린 1.9.0은 신규 gradle 컴파일러 옵션을 제공한다.

Classpath 속성 제거

코틀린 1.7.0에서 KotlinCompile의 classpath에 대한 지원 중단에 대해 언급한 바가 있다. 지원 중단 수준은 1.8.0에서 ERROR로 상향 조정되었고, 이번 업데이트에서 classpath 속성을 제거했다. 이제 컴파일에 필요한 라이브러리 목록은 libraries에 입력해야 한다.

신규 컴파일러 옵션

코틀린 gradle 플러그인은 opt-ins와 컴파일러 프로그레시브 모드를 위한 신규 속성을 제공한다.

• optIn 속성을 사용해 optIn.set(listOf(a, b, c))와 같은 문자열 목록의 전달이 가능하다.
• progressiveMode.set(true)로 프로그레시브 모드를 활성화할 수 있다.

Kotlin/JVM을 위한 프로젝트 레벨의 컴파일러 옵션

코틀린 1.9.0부터 코틀린 kotlin 환경 설정 블록 내에서 compilerOptions 블록을 사용할 수 있다.

kotlin {
    compilerOptions {
        jvmTarget.set(JVM.Target_11)
    }
}

compilerOptions 블록은 컴파일러 옵션을 구성하는 것을 간편화를 돕는다. 그러나 몇 가지 주의 사항이 있다.

• 해당 설정은 프로젝트 구성에서만 동작한다.
• 안드로이드 블록의 경우 해당 블록은 아래와 같은 개체를 구성한다.

  android {
    kotlinOptions {}
  }

• android.kotlinOptions와 kotlin.compilerOptions 환경 설정 블록은 서로 덮어쓴다. 최종적으로 빌드 파일에서 두 설정 중 가장 마지막으로 설정된 블록이 적용(빌드 시, 빌드 파일을 순차적으로 읽어들이기 때문)된다.
• moduleName이 프로젝트 레벨에서 설정된 경우 컴파일러로 전달할 때 값이 변경될 가능성이 있다. 메인 컴파일은 예외이지만, 테스트 소스와 같이 다른 유형의 경우에는 코틀린 gradle 플러그인에 의해 _test 접미사가 붙는다.
• tasks.withType<KotlinJvmCompile>().configureEach {}(혹은 tasks.named<KotlinJvmCompile>("compileKotlin") {}) 내부의 구성은 kotlin.compilerOptions와 ndroid.kotlinOptions를 모두 덮어쓴다.

Kotlin/Native 모듈명을 위한 컴파일러 옵션

kotlin/native 모듈명 컴파일러 옵션을 코틀린 gradle 플러그인에서 쉽게 사용할 수 있다.

해당 옵션은 컴파일 모듈명을 지정하며 objective-c로 내보낼 때 선언에 이름 접두사를 추가하는데 사용할 수도 있다.

gradle 빌드 파일의 compilerOptions 블록에서 모듈명을 직접 설정할 수 있다.

tasks.named<org.jetbrains.kotlin.gradle.tasks.KotlinNativeCompile>("compileKotlinLinuxX64") {
    compilerOptions {
        moduleName.set("my-module-name")
    }
}

코틀린 공식 라이브러리를 위한 별도의 컴파일러 플러그인

코틀린 1.9.0에 공식 라이브러리를 위한 별도의 컴파일러 플러그인을 도입했다. 이전에는 컴파일러 플러그인이 해당 gradle 플러그인에 내장되어 있어, 컴파일러 플러그인이 gradle 빌드의 코틀린 런타임 버전보다 높은 코틀린 버전으로 컴파일된 경우에 호환성 문제가 발생할 수 있었다.

이제 컴파일러 플러그인이 별도의 종속성으로 추가되므로 더 이상 구 버전의 gradle과의 호환성 문제에 부딪힐 일은 없을 것이다. 새로운 접근법의 다른 장점은 새로운 컴파일러 플러그인을 바젤과 같이 타 빌드 시스템과 함께 사용이 가능하다는 점이다.

아래는 maven central에 게시 중인 신규 컴파일러 플러그인이다.

• kotlin-atomicfu-compiler-plugin
• kotlin-allopen-compiler-plugin
• kotlin-lombok-compiler-plugin
• kotlin-noarg-compiler-plugin
• kotlin-sam-with-receiver-compiler-plugin
• kotlinx-serialization-compiler-plugin

각 플러그인은 -embeddable 버전이 있다. 예를 들어, kotlin-allopen-compiler-plugin-embeddable은 kotlin-compiler-embeddable 아티팩트와 함께 동작하도록 설계됐다. 이것이 스크립트 아티팩트의 기본 옵션이다.

gradle은 이러한 플러그인들을 컴파일러 인자로 추가하여 기존 프로젝트를 수정할 필요가 없다.

지원되는 최소 버전

코틀린 1.9.0부터 지원되는 최소 안드로이드 gradle 플러그인의 버전은 4.2.2이다.

코틀린 gradle 플러그인과 gradle 버전의 호환성에 관래서는 이 문서를 참고하길 바란다.

kapt는 gradle에서 eager task 미생성

1.9.0 이전에는 kapt 컴파일러 플러그인이 코틀린 컴파일 작업의 구성된 인스턴스를 요청하여 eager task(즉시 생성되는 작업)을 생성했다. 이러한 동작은 1.9.0에 수정되었으며 build.gradle.kts에 기본 환경 설정을 사용하는 경우 설정은 해당 변경 사항의 영향을 받지 않는다.

사용자 지정 환경 설정을 사용하면 설정에 악영향을 미친다. 예를 들어 gradle의 tasks api를 사용해 KotlinJvmCompile 작업을 수정한 경우 빌드 스크립트에서 KaptGenerateStubs 작업 또한 유사하게 수정해야 한다.

예를 들어 스크립트에 KotlinJvmCompile 작업에 대해 아래와 같은 설정이 있는 경우

tasks.named<KotlinJvmCompile>("compileKotlin") {
    // 사용자 지정 설정
}

이 경우 KaptGenerateStubs 작업의 일부로, 동일한 수정이 포함되도록 해야 한다.

tasks.named<KaptGenerateStubs>("kaptGenerateStubs") {
    // 사용자 지정 설정
}

자세한 내용은 YouTrack ticket을 참고하길 바란다.

JVM 대상 검증 모드의 프로그래밍 방식 구성

코틀린 1.9.0 이전에는 자바와 코틀린 간의 jvm 대상 비호환성 탐지를 조정하는 방법은 프로젝트의 루트 디렉토리의 gradle.properties에서 kotlin.jvm.target.validation.mode=ERROR를 설정하는 방법 1가지 밖에 없었다.

1.9.0에서는 build.gradle.kts에서 task 레벨에서도 설정이 가능하다.

tasks.named<org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile>("compileKotlin") {
    jvmTargetValidationMode.set(org.jetbrains.kotlin.gradle.dsl.jvm.JvmTargetValidationMode.WARNING)
}

표준 라이브러리

코틀린 1.9.0에서는 표준 라이브러리에 대한 몇 가지 큰 개선 사항이 있다.

개방형 범위 ..< 연산자 안정화

개방형 범위 연산자인 ..<는 코틀린 1.7.20에 처음 도입되어 1.8.0에 안정화가 되었다. 1.9.0에서는 개방형 범위를 다루는 표준 라이브러리 api도 안정화됐다.

..< 연산자는 개방 범위가 선언된 경우 이해가 쉬워진다. 오히려 until 중위 함수를 사용하면 상한값이 포함된 것으로 오해하는 실수를 쉽게 범할 수 있다.

아래는 until 함수를 사용한 예시이다.

fun main() {
    for (number in 2 until 10) {
        if (number % 2 == 0) {
            print("$number ")
        }
    }
    // 2 4 6 8
}

그리고 아래는 ..< 연산자를 사용한 예시이다.

fun main() {
    for (number in 2..<10) {
        if (number % 2 == 0) {
            print("$number ")
        }
    }
    // 2 4 6 8
}

인텔리제이 2023.1.1부터는 ..< 연산자의 사용 가능한 경우를 강조하는 새로운 코드 검사 기능이 제공되며 해당 연산자로 수행 가능한 작업에 대한 내용은 What's new in Kotlin 1.7.20를 참고하길 바란다.

시간 API 안정화

1.3.50부터 신규 시간 특정 api에 대해 미리 소개한 바가 있다. 해당 api의 지속 시간 부분은 1.6.0에서 안정화됐고, 1.9.0에서 남은 시간을 측정하는 api도 안정화됐다.

구 api에서는 measureTimeMillis 함수와 measureNanoTime 함수가 제공되고 있었다만, 이것들은 직관적인 사용이 가능한 것이 아니다. 둘 다 다른 단위의 시간을 측정하는 것은 틀림없지만, measureTimeMillisis가 시간을 측정하기 위해 wall clock(실제 시간을 측정하는 시계를 뜻하며, 현재 시간을 알아내거나 경과 시간을 측정하는데 사용되는 시계가 이에 해당)을 사용해 시간을 측정하고, measureNanoTime은 단조 시간 소스를 사용(사실 둘 다 명확하지 않다고 한다)한다. 신규 시간 api는 상술한 문제와 기타 문제를 해결하여 api를 좀 더 용이하게 사용할 수 있게 한다.\

신규 시간 api를 사용하면 좀 더 쉽게 아래의 동작을 수행할 수 있다.

• 원하는 시간 단위로 단조 시간 소스를 사용하여 코드 실행에 소요된 시간을 측정
• 특정 시점 표시
• 두 시점을 서로 비교하여 차이점 탐색
• 특정 시점 이후 경과된 시간 확인
• 현재 시간이 특정 시점을 지났는지 확인

코드 실행 시간 측정

코드 블록의 실행 시간을 측정하려면 measureTime 인라인 함수를 사용하면 된다.

코드 블록의 실행 시간을 측정하고 코드 블록의 결과를 리턴하려면 measureTimedValue 인라인 함수를 사용하면 된다.

기본적으로 두 함수 모두 단조 시간 소스를 사용한다. 실경과 시간 소스를 사용하고자 해도 가능하다. 예를 들어, 안드로이드에서는 기본 시간 소스인 System.nanoTime()이 단말기가 활성화된 시간 동안에만 계산을 한다. 디바이스가 deep sleep 모드에 들어가면 시간 계산이 중단되기 때문에 디바이스가 절전된 상태에서도 시간을 계산하려면 SystemClock.elapsedRealtimeNanos()를 사용하면 된다.

object RealtimeMonotonicTimeSource : AbstractLongTimeSource(DurationUnit.NANOSECONDS) {
    override fun read(): Long = SystemClock.elapsedRealtimeNanos()
}

시간 차의 측정 및 표시

특정 시점을 표시하려면 TimeSource 인터페이스와 markNow() 함수를 사용하여 TimeMark를 생성하면 된다. 동일한 시간 소스에서 TimeMark 사이의 차이를 측정하려면 뺄셈 연산자-를 사용하면 된다.

import kotlin.time.*

fun main() {
    val timeSource = TimeSource.Monotonic
    val mark1 = timeSource.markNow()
    Thread.sleep(500) // 0.5초 대기
    val mark2 = timeSource.markNow()

    repeat(4) { n ->
        val mark3 = timeSource.markNow()
        val elapsed1 = mark3 - mark1
        val elapsed2 = mark3 - mark2

        println("Measurement 1.${n + 1}: elapsed1=$elapsed1, elapsed2=$elapsed2, diff=${elapsed1 - elapsed2}")
    }
    // 시간 표시를 서로 비교하는 것도 가능하다.
    println(mark2 > mark1) // mark2가 mark2보다 늦게 캡쳐됐기 때문에 true가 출력된다.
}

특정 시점이 지났는지 혹은 시간이 초과됐는지 확인하려면 hasPassNow() 및 hasNotPassNow() 확장 함수를 사용하면 된다.

import kotlin.time.*
import kotlin.time.Duration.Companion.seconds

fun main() {
    val timeSource = TimeSource.Monotonic
    val mark1 = timeSource.markNow()
    val fiveSeconds: Duration = 5.seconds
    val mark2 = mark1 + fiveSeconds

    // 아직 5초가 지나지 않은 시점
    println(mark2.hasPassedNow())
    // false

    // 6초 대기
    Thread.sleep(6_000)
    println(mark2.hasPassedNow())
    // true
}

Kotlin/Native 표준 라이브러리 안정화

kotlin/native를 위한 표준 라이브러리가 지속적으로 업데이트됨에 따라 표준 라이브러리가 적절한 조건을 만족하는지 검토가 필요하다고 판단되어 기존의 공개 서명(라이브러리나 API의 외부에서 접근 가능한 함수, 클래스, 인터페이스 등의 구성 요소)을 주의깊게 검토했다. 각 서명에 대해 아래와 같은 사항을 고려했다.

• 고유한 목적을 가진다.
• 타 코틀린 api와 일관성이 있다.
• jvm에 대응하는 기능과 유사하게 동작한다.
• 추후 대비가 가능하다.

이러한 사항을 바탕으로 아래와 같은 결정을 내렸다.

• 안정화
• 실험적 기능
• private으로 표시
• 동작 수정
• 다른 위치로 이관
• 지원 중단
• 사용 중단

기존이 서명이 다음과 같은 경우

• 타 패키지로 이동되었다면, 해당 서명은 기존 패키지에는 여전히 존재하지만 WARNING 레벨로 격하된다. 인텔리제이에서 코드 검사 시 자동으로 대체하는 것이 좋다.
• 사용 중단된 경우 deprecation 레벨은 WARNING이 된다.
• 사용 중단으로 표시되면 당장 사용은 가능하지만, 추후 교체된다.

여기에 검토 결과 전부는 아니지만, 몇 가지 강조점이 있다.

• atomics api 안정화
• kotlinx.cinterop의 실험적 지정했으며 해당 패키지의 사용을 위해 다른 opt-in이 필요하다.
• Worker 클래스 및 관련 api의 사용 중단
• BitSet 클래스 사용 중단
• kotlin.native.internal 패키지의 모든 public api를 private로 전환하거나 타 패키지로 이관

묵시적 C 언어 호환성의 안정성 보증

양질의 api 유지하기 위해 kotlinx.cinterop을 실험적인 상태로 유지하기로 결정했다. kotlinx.cinterop의 검증은 철저히 진행됐지만, 아직 완벽하지 않은 부분이 남아있기 때문이다. 해당 api에 대해 아직은 프로젝트에서 사용하는 특정 부분에 한하여 사용하는 것을 권장한다. 이렇게 하면 api를 안정화하는 과정에서의 마이그레이션 작업이 더 용이해질 것이다.

C 스타일의 포인터와 외부 api를 사용하려면 @OptIn(ExperimentalForeignApi)으로 opt-in해야 하며, 그렇지 않으면 코드는 컴파일되지 않는다.

objective-c/swift 상호 운용성을 다루는 kotlinx.cinterop의 나머지 부분을 사용하려면 @OptIn(BetaInteropApi)에서 선택해야 한다. opt-in 없이 해당 api를 사용하려면 코드가 컴파일은 되지만 컴파일러가 해당 동작에 대해 명확한 설명과 함께 경고를 생성한다.

해당 어노테이션에 대한 자세한 정보는 Annotations.kt의 소스 코드를 참고하길 바란다.

또한, 이번 검토에 대한 모든 변경 내용에 대한 자세한 내용은 YouTrack 티켓을 참고하길 바란다.

@Volatile 어노테이션 안정화

var 속성에 @Volatile 어노테이션을 사용하면 백킹 필드가 표시되므로 필드에 대한 읽기/쓰기는 원자적인 상태가 되며 쓰기는 항상 다른 스레드에서 볼 수 있도록 처리된다.

1.8.20 이전에는 kotlin.jvm.Volatile 어노테이션을 공통 표준 라이브러리에서만 사용할 수 있었다. 다만, 해당 어노테이션은 jvm에서만 유효하고, 타 플랫폼에서 사용하면 무시되어 오류가 발생했다.

1.8.20에서는 실험적인 공통 어노테이션인 kotlin.concurrent.Volatile을 도입했다. 해당 어노테이션은 jvm과 kotlin/native에서 미리 확인이 가능하다.

1.9.0에서는 kotlin.concurrent.Volatile가 안정화됐다. 멀티플랫폼 프로젝트에서 kotlin.jvm.Volatile을 사용 중이라면, kotlin.concurrent.Volatile로 마이그레이션하는 것을 권장한다.

Regex 캡쳐 그룹을 이름으로 가져오는 신규 공통 함수

1.9.0 이전에는 각 플랫폼 별로 정규 표현식 매치에서 정규 표현식 캡쳐 그룹을 얻기 위한 고유 확장 함수는 있었으나, 공통 함수는 존재하지 않았다. 1.8.0 이전에는 공통 함수를 가질 수 없었는데 이는 표준 라이브러리가 아직 jvm 1.6과 1.7을 지원했기 때문이다.

1.8.0부터 표준 라이브러리는 jvm 1.8로 컴파일 됐으며, 1.9.0에서는 정규 표현식 매치의 그룹 이름을 사용해 해당 그룹의 내용을 검색하는데 사용하는 표준 함수 groups가 추가됐다. groups는 특정 캡쳐 그룹에 속하는 정규 표현식 매치 결과에 접근하고자 할 때 유용하게 사용할 수 있다.

아래는 세 캡쳐 그룹(도시, 주, 지역 코드)을 포함하는 정규식의 예제이다. 해당 그룹 이름을 사용하여 일치하는 값에 액세스할 수 있다.

fun main() {
    val regex = """\b(?<city>[A-Za-z\s]+),\s(?<state>[A-Z]{2}):\s(?<areaCode>[0-9]{3})\b""".toRegex()
    val input = "Coordinates: Austin, TX: 123"

    val match = regex.find(input)!!
    println(match.groups["city"]?.value)
    // Austin
    println(match.groups["state"]?.value)
    // TX
    println(match.groups["areaCode"]?.value)
    // 123
}

상위 디렉토리 생성을 위한 새 경로 유틸리티

코틀린 1.9.0에는 신규 createParentDirectories() 확장 함수가 추가됐다. 해당 함수를 사용하여 필요한 모든 상위 디렉토리에서 파일을 생성할 수 있다. createParentDirectories()에 파일 경로를 제공하면 해당 경로에 상위 디렉토리의 존재 여부를 확인하고 이미 존재할 경우에는 아무 동작도 하지 않지만, 그렇지 않으면 자동으로 생성한다.

createParentDirectories()는 파일을 복사할 때 유용하게 사용할 수 있다. 아래와 같이 copyToRecursively() 함수와 같이 사용 가능하다.

sourcePath.copyToRecursively(
   destinationPath.createParentDirectories(),
   followLinks = false
)

16진수의 포맷 및 파싱이 가능한 신규 HexFormat 클래스

신규 HexFormat 클래스와 관련 확장 함수들은 현재 실험적 기능으로, 사용하기 위해서는 @OptIn(ExperimentalStdlibApi::class) 어노테이션을 사용하거나 컴파일 인자로 -opt-in=kotlin.ExperimentalStdlibApi를 사용해야 한다.

1.9.0에서는 HexFormat 클래스와 관련된 확장 함수가 실험적 기능으로 제공된다. 해당 기능은 숫자 값과 16진수 문자열 간의 변환을 한다. 구체적으로, 확장 함수를 사용하여 16진수 문자열과 ByteArray 혹은 타 숫자 타입(Int, Short, Long) 간의 변환이 가능하다.

예를 들어 아래와 같이 사용할 수 있다.

println(93.toHexString()) // "0000005d"

HexFormat 클래스에는 HexFormat{} 빌더로 구성 가능한 서식 옵션이 포함되어 있다.

ByteArray와 함께 작업하려는 경우 아래와 같은 옵션이 존재하며, 이는 속성으로 구성이 가능하다.

아래와 같이 사용할 수 있다.

val macAddress = "001b638445e6".hexToByteArray()

// HexFormat{} 빌더를 사용해 16진수 문자열을 콜론으로 구분
println(macAddress.toHexString(HexFormat { bytes.byteSeparator = ":" }))
// "00:1b:63:84:45:e6"

// HexFormat{} 빌더로 아래의 작업을 수행
// * 16진수 문자열을 대문자로 변환
// * 바이트를 쌍으로 그룹화
// * 점으로 구분
val threeGroupFormat = HexFormat { upperCase = true; bytes.bytesPerGroup = 2; bytes.groupSeparator = "." }

println(macAddress.toHexString(threeGroupFormat))
// "001B.6384.45E6"

숫자형 타입을 다루는 경우, 아래와 같은 옵션들이 존재하며 이들은 속성을 통해 구성 가능하다.

아래와 같이 사용 가능하다.

// HexFormat{} 빌더를 사용해 접두사가 "0x"인 16진수 구문을 해석
println("0x3a".hexToInt(HexFormat { number.prefix = "0x" })) // "58"

문서 업데이트

코틀린 문서에 몇 가지 큰 수정이 있었다.

• 코틀린 투어 - 이론과 실습을 겸비한 장으로 코틀린 언어의 기초를 배울 수 있다.
• 안드로이드 소스 세트 레이아웃 - 신규 안드로이드 소스 세트 레이아웃에 대해 알아보자.
• 코틀린 멀티플랫폼 호환성 가이드 - 코틀린 멀티플랫폼으로 프로젝트를 개발하는 동안 직면할 수 있는 호환되지 않는 변경 사항 가이드
• 코틀린 Wasm - 코틀린 wasm에 대해 알아보고 코틀린 멀티플랫폼 프로젝트에서 사용 가능한 방법을 알아보자.
• 코틀린 Wasm 프로젝트에 코틀린 라이브러리 의존성 추가 - 코틀린 wasm에서 지원되는 코틀린 라이브러리에 대해 알아보자.

코틀린 1.9.0 설치

버전 확인

인텔리제이 2022.3.3 및 2023.1.1에서는 코틀린 플러그인을 자동으로 1.9.0으로 업데이트하는 것을 제안한다. 2023.2에서는 코틀린 1.9.0 플러그인이 자동으로 포함될 예정이다.

안드로이드 스튜디오 Giraffe(223)와 Hedgehog(231)은 곧 출시될 릴리즈에서 코틀린 1.9.0을 지원한다.

신규 command-line 컴파일러는 github release에서 다운로드할 수 있다.

Gradle 설정 구성

코틀린 아티팩트와 종속성을 다운로드하려면 setting.gradle(.kts)를 업데이트하여 maven central 저장소를 사용해야 한다.

pluginManagement {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
}

저장소가 지정되지 않은 경우 gradle은 현재 서비스 종료 상태인 jcenter 저장소를 사용하게 되고, 이는 코틀린 아티팩트에 관련하여 문제를 일으킬 수 있다.

코틀린 1.9.0 호환성 가이드

코틀린 1.9.0은 기능 업데이트이기 때문에, 이전 버전으로 작성된 코드와 호환되지 않을 수 있다. 코틀린 1.9.0에 대한 자세한 변경 사항은 코틀린 1.9.0 호환성 가이드에서 확인 가능하다.

원문

• What's new in Kotlin 1.9.0

AWS CLI는 CLI Shell 명령어를 사용하여 AWS 서비스를 관리할 수 있는 오픈소스 도구이다. AWS CLI를 통해 터미널에서 브라우저로 AWS 콘솔에서 작업하는 것과 동일하게 기능을 구현할 수 있다.
또한, AWS CLI를 다루는 것이 능숙해진다면 AWS 서비스의 Public API에 엑세스가 가능하며 리소스를 관리하거나 기능을 구현하는 Shell Script를 작성하여 작업을 자동화할 수 있다.

AWS CLI의 명령 구조는 아래와 같다.

$ aws <command> <subcommand> <옵션이나 파라미터>

CLI에서 도움말 설명서를 보려면 아래의 명령어 중 하나를 입력하면 된다.
각각 AWS CLI, AWS CLI 명령어, AWS CLI 하위 명령어에 대한 도움말 설명서이다.

$ aws help
$ aws <command> help
$ aws <command> <subcommand> help

명령어에 대한 디버깅을 하고 싶으면 명령어를 아래와 같은 형식으로 작성한다.

$ aws --debug <command> <subcommand> <옵션이나 파라미터>

AWS IAM 계정 만들기

이 장에서는 AWS CLI를 다루기 위해 필요한 IAM 계정 생성에 대한 내용을 다룬다. IAM 계정과 엑세스 키를 가지고 있다면 이 장은 건너뛰어도 된다.

AWS 콘솔에서 IAM 서비스에 들어간다. 위의 그림과 같이 IAM 대시보드에서 좌측의 메뉴에서 사용자로 이동한다.

사용자 메뉴로 이동해주었다면 사용자 추가를 눌러 IAM 계정을 추가해주어야 한다. root 계정일 경우, 사용자 추가를 할 수 있지만 root 계정 이외에 IAM 계정으로 로그인하고 있다면 사용자 추가 권한이 없다면 이 작업을 할 수 없다는 것을 알아두어야 한다.

사용자 추가를 눌렀을 때 총 5단계를 거쳐야 사용자가 추가되는데 우선 1번째 단계이다. 사용자의 이름과 AWS 엑세스 유형을 선택하는 단계인데 여기서 그림 2와 같이 프로그래밍 방식 엑세스를 반드시 선택해주어야 한다. 이것을 선택해주어야 후에 엑세스 키가 발급되고 이를 통해 AWS CLI로 작업이 가능하다. 선택해주었다면 다음 단계로 넘어간다.

2단계는 권한 설정이다. 현재 생성 중인 계정이 AWS 내에서 어떤 서비스에 접근이 가능하며 얼만큼의 제어가 가능한지 지정해주는 단계이다. 필자는 Admin 권한을 넣어주었으나 원한다면 따로 권한 설정을 하는 것도 좋다.

사용자의 태그를 지정하는 단계이다. 현재는 크게 중요한 부분은 아니기 때문에 설정하지 않고 다음으로 넘어가도 된다.

생성 직전 검토 단계이다. 1~3단계까지 설정한 것을 검토하는데 이때 AWS 엑세스 유형에 프로그래밍 방식 엑세스가 반드시 있어야 한다. 그렇지 않다면 1단계로 돌아가 프로그래밍 방식 엑세스에 체크해주어야 한다.

이제 마지막 단계이다. .csv 다운로드를 눌러 .csv 파일을 다운받는다. 이 파일에 AWS CLI나 AWS SDK로 AWS 서비스에 접근할 수 있는 엑세스 키가 있기 때문에 반드시 다운받아야 한다.

다운받은 .csv 파일을 열면 그림 8과 같이 사용자 이름, 엑세스 키 ID, 비밀 엑세스 키 등이 적혀있다. 이 파일에서 필요한 것은 엑세스 키 ID와 비밀 엑세스 키이다. 또한 이러한 엑세스 정보는 보안과 직결되므로 외부에 노출되지 않도록 개인이 잘 보관해야 한다.

AWS CLI 설치

Windows에 설치

OS는 Windows 10으로 하여 작업했으니 Windows 11과는 다소 차이가 있을 수 있다. 우선 이 페이지에서 AWS CLI2 설치파일을 다운받는다.

설치가 완료되었다면 정상적으로 설치되었는지 확인하기 위해 Command Prompt나 Power Shell 등 CLI를 열어 AWS CLI의 버전을 확인한다. 정상적으로 설치가 되었다면 위의 그림과 같이 버전에 관한 정보를 확인할 수 있다.

> aws --version

AWS CLI를 사용하기 위해 명령어 aws configure를 입력하여 엑세스 키의 ID와 비밀 엑세스 키를 붙여넣고 작업할 리전과 출력 형식을 입력해준다. 출력 형식은 json, table, text, yaml, yaml-stream이 있다. 그 후, 아래의 명령어로 AWS CLI로 현재 계정에서 EC2로 접근 가능한 리전을 확인한다. 명령어가 위의 그림과 같이 결과를 잘 뱉으면 현재 계정으로 AWS CLI를 사용할 수 있다는 의미이다.

> aws ec2 describe-regions

설정을 변경하고 싶다면 명령어 aws configure 명령어를 입력하여 설정을 변경하거나 위의 그림과 같이 홈 디렉토리에 있는 .aws 디렉토리에서 config 파일과 credentials 파일을 수정해서 설정을 변경할 수 있다. 이렇게 Windows 환경에서 AWS CLI를 사용할 준비가 끝났다.

Linux에 설치

아래의 명령어로 AWS CLI 압축 파일을 다운받는다. 그 후, 압축 해제 명령어를 통해 다운받은 압축 파일의 압축을 해제한다. 압축 해제 명령어가 없다면 설치를 받아야 한다.

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip

아래의 명령어를 통해 설치 프로그램을 실행하는 동시에 권한을 부여한다. 그럼 기본적으로 설치는 /usr/local/aws-cli에 되며 /usr/local/bin에 심볼 링크가 생성된다. 설치 프로그램을 실행 후, 실행한 디렉토리를 -i 옵션으로 복사할 디렉토리와 -b 옵션으로 심볼릭 링크로 연결해준다. 다음 명령어는 AWS CLI를 업데이트하는 명령어인데, 기존 심볼 링크 및 설치 관리자 정보를 추가하여 --update 파라미터를 포함한 install 명령을 구성한다. 마지막으로 AWS CLI 버전을 확인했을 때 위의 그림와 같이 버전 정보가 확인된다면 정상적인 설치가 완료된 것이다.

$ sudo ./aws/install
$ sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
$ ls -l /usr/local/bin/aws
$ aws --version

엑세스 정보 설정은 Windows와 마찬가지로 aws configure 명령어로 진행한다. 엑세스 정보 설정 이후, 아래의 명령어로 EC2에 접근 가능한 리전을 확인한다. 결과가 잘 나오면 AWS CLI를 정상적으로 사용할 수 있다.

$ aws ec2 describe-regions

macOS에 설치

macOS는 homebrew를 사용하면 명령어로 프로그램을 간단히 설치할 수 있다. homebrew에서 AWS CLI를 설치하는 명령어는 아래와 같다.

$ brew install awscli

설치 후, 경로와 버전을 확인하면 위의 그림과 같은 결과가 나오는 것을 확인할 수 있다. 엑세스 정보 설정은 aws configure 명령어를 통해 설정하면 된다.

그 외에 AWS CLI를 다루는 방법

이번 항목에서는 위에서 소개했던 방식 이외에 AWS CLI를 다루는 방식들을 소개한다.

CloudShell

CloudShell은 웹브라우저로 AWS 콘솔에 접근하여 직접 사용할 수 있다. CloudShell은 AWS CLI2가 세팅되어 있는 상태라 별 다른 설정 없이 AWS CLI를 다룰 수 있으며 Python과 Node 런타임, Bash, PowerShell, git, ECS CLI, jq, npm, pip 등이 포함되어 있으며 향후 더 많은 기능이 제공될 예정이다. CloudShell을 지원하는 리전은 이 페이지에서 확인하면 된다.

이 외에 CloudShell에 대해서는 아래와 같이 간단히 정리해두었다.

스토리지: $HOME에 저장된 파일은 Cloud Shell 호출 간에도 유지되지만 그 이외에 설치한 SW는 유지되지 않으며 용량은 리전당 1GB로 제한된다.

요금: 리전 당 최대 10개의 Shell을 동시에 사용했을 때 무료로 사용이 가능하며 Cloud Shell에서 AWS CLI로 작업을 하여도 Cloud Shell은 과금이 되지 않는다.

시간 초과 및 지속성: 20분 동안 사용하지 않으면 세션이 만료된다.

네트워크 엑세스: 세션은 인터넷 아웃바운드 연결을 생성이 가능하지만, 인바운드 연결은 불가능하며 세션은 private VPC 서브넷 내의 리소스에 접근할 수 없지만 이 기능은 단기 로드맵에 존재한다.

Cloud Shell을 사용하는 방법은 매우 간단하다. AWS 콘솔에 접속해서 Cloud Shell을 지원하는 리전에서 위의 그림와 같이 우측 상단 Cloud Shell 아이콘을 클릭하면 된다.

Cloud Shell는 AWS CLI가 기본으로 깔려있기 때문에 따로 세팅해줄 것은 거의 없다고 보면 된다.

AWS Shell

AWS Shell은 AWS CLI 셸 프로그램으로 AWS CLI를 사용하는 사용자에게 도움되는 자동 완성, OS Shell 명령 실행, 실행한 명령의 결과를 text 편집기로 내보내기 등 편리한 기능이 탑재되어 있다. AWS CLI만을 사용하면 간혹 옵션명이 헷갈리거나 기억나지 않는 경우가 있는데 AWS Shell을 사용하면 이러한 경우를 대폭 줄일 수 있다.

AWS Shell을 설치하기 위해서는 python과 pip가 필요한데 pip가 없는 사람은 설치를 해준다. python이 없으면 마찬가지로 python을 설치해준다. 이미 설치되어 있는 사람들은 이곳을 무시하고 다음으로 넘어가면 된다.

$ sudo apt install python3-pip -y

pip를 통해 AWS Shell을 설치해준다.

$ sudo pip install aws-shell

설치가 완료되면 AWS Shell을 실행시켜준다. 실행하는 명령어는 aws-shell이다. 보통 터미널에서 AWS CLI를 사용하면 앞에 무조건 aws를 붙여야 하는데 AWS Shell에서는 앞에 aws를 붙일 필요가 없다. 즉 AWS Shell에서는 명령어를 작성할 때 맨앞의 접두사인 aws를 빼고 <command> <subcommand> <옵션이나 파라미터>와 같이 명령어를 작성할 수 있다. 또한 자동 완성 기능 또한 편리하기에 유용하다. 필자는 명령어가 정상적으로 동작하는지 확인하기 위해 명령어 하나를 실행시켜 보았다.

명령어는 잘 동작한다. 필자는 이미 계정 정보를 설정해두어서 잘 동작하는 것이다.

계정 정보의 설정을 하지 않고 AWS Shell만 설치한 사람은 위의 그림과 같이 AWS Shell 내에서 명령어 configure를 통해 설정이 가능하다. AWS Shell에서 나가려면 F10을 누르면 나갈 수 있다.

참고자료

• AWS docs - Installing or updating the latest version of the AWS CLI
• AWS docs - What is AWS CloudShell?
• Github Repo - aws-shell