Kotlin Multi-platform

개요

코틀린 공식 홈페이지를 보면 코틀린에 대한 세부 설명 중 멀티 플랫폼 항목이 가장 상단에 위치하는 것을 볼 수 있다. 그만큼 jetbrains 사에서도 코틀린이 가지는 가치 중 멀티 플랫폼을 중요하게 생각함을 알 수 있다.
이번 글에서는 코틀린이 가지는 특징 중 멀티 플랫폼에 대한 내용을 다룬다.
 

코틀린 멀티 플랫폼?

“The Kotlin Multiplatform technology is designed to simplify the development of cross-platform projects.” ”It reduces time spent writing and maintaining the same code for different platforms while retaining the flexibility and benefits of native programming.”

Kotlin Multiplatform | Kotlin

코틀린으로 작성된 코드를 모든 클라이언트에 일괄적으로 반영 가능하도록 멀티 플랫폼으로 구현이 가능하다. 예를 들어 넷플릭스는 수 백가지의 클라이언트와 매핑 되는 앱을 개발해야 한다. 가령 스위치, IOS, LG TV, 플레이 스테이션 등의 이기종 환경이 있을 것이다. 이때 각 기종 별로 개발을 하는 것이 아니라 각 기기들이 가져야할 공통 영역을 코틀린 멀티 플랫폼으로 구현할 수 있다.

 

GitHub - Shabinder/SpotiFlyer: Kotlin Multiplatform Music Downloader, Supports Spotify /   Gaana / Youtube Music / Jio Saavn / S

GitHub - joreilly/PeopleInSpace: Kotlin Multiplatform project with SwiftUI, Jetpack Compose, Compose for Wear, Compose for Deskt

위와 같이 여러 기종에서 동작하는 데모 프로젝트들은 아래 사이트에서 더 찾아볼 수 있다.
 
 

Kotlin Multiplatform samples | Kotlin Multiplatform Development

 
 

멀티 플랫폼에서 동작하는 원리

그럼 어떻게 코틀린은 멀티 플랫폼에서 동작할 수 있을까?
 

https://medium.com/nybles/breaking-the-boundaries-of-platform-specific-development-with-kotlin-multiplatform-be1280509003

 
코어 라이브러리, 기본 tool들은 Common kotlin에 포함시킨다. 이렇게 코틀린으로 작성된 Common kotlin은 모든 플랫폼에서 동작한다. 코틀린 멀티 플랫폼 라이브러리를 사용해 개발자는 공통 코드와 플랫폼 종속적인 코드에서 멀티 플랫폼 로직을 재사용 할 수 있다. 공통 코드는 HTTP, 직렬화, 코루틴 관리와 같은 일반적인 작업을 처리하는 라이브러리에 의존할 수 있다.
 

https://medium.com/nybles/breaking-the-boundaries-of-platform-specific-development-with-kotlin-multiplatform-be1280509003

 
코틀린의 플랫폼별 버전에는 코틀린 언어에 대한 확장과 플랫폼별 라이브러리가 포함되어 있다.
 
예를 들어 kotlin.collections.List를 멀티 플랫폼 측면에서 다시 보자.
코틀린의 컬렉션 라이브러리는 각 다른 환경들의 연결 다리 역할을 한다. 예를 들어 Java의 ArrayList를 사용하는 순간 특정 환경에 종속돼 버린다. 많은 사람들이 kotlin.collections.List와 java.lang.List가 같다고 생각하지만, 멀티 플랫폼의 브라우저에서는 JS의 List가 사용되고 iOS에서는 Array가 사용된다.

따라서 코틀린은 JVM과 같지 않다. 단지 자바를 차용한 언어로써 코틀린이라 생각하는 것이 옳다.

 

서버 환경에서의 멀티 플랫폼

위에서 설명한 내용을 읽다보면 사실 백엔드 개발자에게는 큰 이점이 아니라는 생각이 들 수도 있겠다. 하지만 코틀린의 멀티 플랫폼은 백엔드 개발자에게도 적지 않은 이점을 주는데 이를 중점으로 살펴보겠다.
참고로 아래 설명하는 내용은 아직 과도기에 있기 때문에 현재(2023년 10월) 기준으로 실사용에는 한계가 있다는 것을 이해하며 읽는 것이 좋다.
코틀린 멀티 플랫폼은 백엔드 개발자에게는 아래의 이점을 준다.

• Kotlin Native
• WASM

 

Kotlin Native

Kotlin Native | Kotlin

 
Kotlin/Native는 코틀린 코드를 가상 머신 없이 실행할 수 있는 네이티브 바이너리로 컴파일하는 기술이다.
Kotlin/Native에는 코틀린 컴파일러용 LLVM 기반 백엔드와 코틀린 표준 라이브러리의 기본 구현이 포함되어 있다. 즉, 기존 코틀린보다 높은 성능을 가진다.
iOS나 임베디드 기기와 같이 가상 머신이 바람직하지 않거나 가능하지 않은 플랫폼이 있는데 이런 기기들에서도 컴파일을 허용하도록 설계되어 있다. 이런 환경에 있는 기기들은 아래 플랫폼들이 있는데 모두 Kotlin/Native가 지원하는 플랫폼이다.

• mac OS
• iOS, tvOS, watchOS
• 리눅스
• 윈도우(MinGW)
• 안드로이드 NDK

지원 대상의 전체 목록은 아래 링크에서 확인 가능
Kotlin/Native support

 
이미 많은 라이브러리들이 코틀린에서 사용 가능하다.

• https://github.com/cashapp/sqldelight
• Ktor
• KotlinIO
• etc..

즉, DB연동, 프레임워크, IO까지 순수 코틀린으로 가능해졌다. 따라서 코틀린을 활용하면 서버 개발에서도 고성능 서버 개발이 가능하다. (아직까지 시기 상조이긴 하지만..)
 

WASM (WebAssembly)

“만약 WASM+WASI가 2008년에도 존재했다면, Docker를 만들 필요가 없었다. 서버에서의 WebAssembly는 컴퓨팅의 미래다."

 
Docker의 공동 창업자인 Solomon Hykes는 위와 같이 말했다.
 
 

W3C도 2019년 공식 w3c 표준으로 WASM을 추가했다. 그만큼 wasm에 대한 관심이 높아지고 있음을 알 수 있다.
 

WASM 이란

WebAssembly는 최신 웹 브라우저에서 실행할 수 있는 새로운 유형의 코드이며, 새로운 기능과 성능 면에서 큰 이점을 제공한다.
웹 브라우저는 어느 기기나 기본적으로 탑재가 가능하며, 바이너리 파일을 만들면 어느 기기나 호환이 가능하다. 이런 이점을 활용하여 네이티브 앱을 웹에 탑재해 배포할 수 있다.

아래는 WASM의 대표적인 활용 사례이다.

• dosbox
• unity on web
• Cloudflare Workers

 

클라우드 네이티브에서 WASM

WASM은 클라우드 네이티브 환경에서 더욱 큰 가치를 가진다.

컨테이너는 애플리케이션에서 클라우드에 자체 런타임을 쉽게 가져올 수 있게 해주고 다른 애플리케이션으로부터 효과적으로 격리해주지만, 안전한 애플리케이션 샌드박스에서 원하는 모든 것을 제공하지는 않는다. 즉, 컨테이너 애플리케이션은 여전히 호스트 리소스에 엑세스할 수 있다. 이런 이유에서 클라우드 환경에서 WASM이 더 중요해지고 있다.
 
WASM은 다음과 같은 장점을 가진다.
 
첫째, 컨테이너 대비 작고 빠르며 네이티브에 가까운 속도로 애플리케이션을 실행할 수 있다.
둘째, 기기에 종속되지 않는다.
 

엘라스틱 서치의 이미지를 보면 OS/ARCH 마다 다른 이미지를 사용해야 함을 알 수 있다.
WASM은 크로스 플랫폼이기 때문에 원하는 어떤 언어로든 작성할 수 있는 프레임워크를 제공한다. 때문에 러스트, C/C++, Golang, Kotlin 등 다양한 언어로 작성된 구성요소가 서로 통신할 수 있다. 또 서버 측 시스템(e.g.데이터베이스 등)이 해당 모듈을 어떻게 생성했는지 신경 쓰지 않고도 다른 언어의 구성 요소를 내장할 수 있는 기능을 제공한다.
WASM은 가상화 되어 있고, WASM 런타임을 지원하는 모든 환경에서 작동할 수 있기 때문에 클라우드에 적합하다. 따라서 복잡해질 수 있는 클라우드 환경을 단순화할 수 있다.
안정성 측면에서도 장점을 가진다. WASM은 외부 리소스에 대한 엑세스를 명시적으로 활성화해야 하기 때문에 샌드박스에서 더 안정성을 가진다.
 

참고 영상

 
 

참고 문서

WebAssembly on the server-side

[번역] 웹어셈블리에 주목하라