코틀린(Kotlin)이란? 자바부터 스프링·Ktor·멀티플랫폼까지 활용 범위 총정리 (2026)

 

코틀린(Kotlin)은 안드로이드뿐 아니라 JVM 백엔드, iOS, 데스크톱까지 아우르는 범용 프로그래밍 언어입니다. 코틀린이 무엇인지부터 스프링 부트·Ktor·코틀린 멀티플랫폼(KMP)까지, 2026년 기준 코틀린 프레임워크와 활용 범위를 입문자 눈높이로 정리했습니다.

 

 

"코틀린은 안드로이드 만들 때 쓰는 거 아니에요?"
"자바 할 줄 알면 코틀린도 금방 배우나요?"
"백엔드도 코틀린으로 짤 수 있어요?"
"코틀린 배우면 결국 어디까지 만들 수 있는 건데요?"

 

 

개발 커뮤니티에서 코틀린 얘기가 나오면 빠지지 않고 따라붙는 질문들입니다. 대부분은 "코틀린 = 안드로이드 언어"라는 인상에서 출발하죠. 틀린 말은 아니지만, 지금의 코틀린을 그 한 줄로 설명하기엔 많이 모자랍니다. 안드로이드는 코틀린이 유명해진 계기였을 뿐, 실제로는 서버 백엔드, iOS 앱, 데스크톱 프로그램, 심지어 웹 프런트까지 넘나드는 언어로 자랐습니다.

이 글은 코틀린을 한 번도 안 써본 분도 따라올 수 있게 "코틀린이 대체 뭔지"부터 짚고, 그다음에 코틀린이 실제로 활약하는 무대들을 프레임워크 단위로 하나씩 살펴봅니다. 자바를 알고 계시면 더 빠르게 이해되겠지만, 몰라도 큰 틀을 잡는 데는 무리가 없도록 풀어 썼습니다.

참고로 글 안의 버전·현황 정보는 2026년 6월 기준입니다. 코틀린은 6개월 주기로 큰 버전이 나오는 언어라, 시간이 지나면 세부 상황은 달라질 수 있다는 점 감안하고 봐주세요.

📋 목차

1. 코틀린, 한 문장으로 말하면
2. 코틀린은 어떻게 여기까지 왔나 (간단 연표)
3. 코틀린의 핵심 특징 네 가지
4. 자바 vs 코틀린, 무엇이 다른가
5. 코틀린이 실행되는 네 개의 무대
6. 활용 ① 안드로이드 앱 개발
7. 활용 ② 서버·백엔드 개발
8. 백엔드 양대 프레임워크: 스프링 부트 vs Ktor
9. 활용 ③ 코틀린 멀티플랫폼(KMP)
10. 활용 ④ Compose Multiplatform, UI까지 공유하기
11. 활용 ⑤ 웹·데이터·스크립팅
12. 그래서 코틀린, 어디에 쓰면 좋을까
13. 코틀린 입문자가 자주 묻는 질문 (FAQ)
14. 마무리
15. 한눈에 보는 코틀린 용어집

1. 코틀린, 한 문장으로 말하면

코틀린은 IntelliJ IDEA를 만든 회사 JetBrains가 개발한 프로그래밍 언어입니다. 정적 타입 언어이고, 기본적으로 자바 가상 머신(JVM) 위에서 돕니다. 그래서 자바와 100% 호환됩니다. 기존 자바 코드를 그대로 가져다 쓸 수 있고, 반대로 코틀린으로 짠 코드를 자바에서 부를 수도 있어요.

핵심은 "자바를 대체하려는 언어"가 아니라 "자바의 불편한 점을 덜어내고 더 안전하게 쓰자"는 방향으로 설계됐다는 점입니다. 같은 일을 하는 코드를 더 짧고 읽기 좋게 쓸 수 있고, 자바에서 골치 아팠던 NullPointerException 같은 문제를 언어 차원에서 막아줍니다.

 

📌 정적 타입이 뭔가요?

변수의 타입(정수인지 문자열인지 등)을 컴파일 시점에 미리 검사하는 방식입니다.

실행하기 전에 타입 오류를 잡아줘서, 큰 프로젝트일수록 버그를 일찍 발견하는 데 유리합니다.

자바, C#이 대표적인 정적 타입 언어이고, 파이썬·자바스크립트는 반대인 동적 타입입니다.

 

2. 코틀린은 어떻게 여기까지 왔나 (간단 연표)

코틀린의 위상을 이해하려면 짧은 역사를 훑는 게 빠릅니다. 안드로이드 언어로 시작한 게 아니라는 점이 의외일 수 있어요.

시기	사건
2011년	JetBrains가 코틀린 프로젝트 공개
2016년	정식 버전 1.0 출시
2017년	구글이 안드로이드 공식 지원 언어로 채택
2019년	구글, 안드로이드 개발에 "코틀린 우선(Kotlin-first)" 선언
2024년	버전 2.0과 함께 새 K2 컴파일러 정식 안정화
2026년	버전 2.4.0 출시 (6개월 주기 언어 릴리스 정착)

2024년 출시된 2.0은 코틀린 입장에서 큰 분기점이었습니다. 컴파일러를 새로 갈아엎은 'K2'가 정식으로 들어왔거든요. K2는 JVM뿐 아니라 네이티브, 웹어셈블리(Wasm), 자바스크립트까지 모든 타깃에서 안정 단계로 자리 잡았고, 컴파일 속도도 눈에 띄게 빨라졌습니다. JetBrains가 공개한 측정에서는 일부 프로젝트의 클린 빌드 시간이 절반 가까이 줄기도 했습니다.

3. 코틀린의 핵심 특징 네 가지

왜 자바를 두고 코틀린을 쓰는지, 자주 꼽히는 강점부터 보겠습니다.

 

널 안정성(Null Safety) — 코틀린은 "이 변수에 null이 들어올 수 있는가"를 타입에 표시하도록 강제합니다. null 가능성이 있으면 ?를 붙여야 하고, 그렇지 않은 변수에는 애초에 null을 넣을 수 없어요. 자바 개발자라면 한 번쯤 겪었을 NullPointerException을 컴파일 단계에서 상당 부분 차단합니다.

var name: String = "코틀린"   // null 불가
var nick: String? = null      // null 허용 (? 표시)
println(nick?.length)         // null이면 그냥 null 반환, 터지지 않음

 

간결한 문법 — 같은 동작을 자바보다 훨씬 짧게 씁니다. 대표적인 게 데이터 클래스예요. 자바라면 수십 줄이 필요한 getter/setter, equals, toString을 한 줄로 끝냅니다.

data class User(val id: Long, val name: String)
// 이 한 줄이 equals, hashCode, toString, copy까지 만들어 줍니다

 

코루틴(Coroutine) — 비동기 처리를 동기 코드처럼 읽기 쉽게 쓰게 해주는 기능입니다. 콜백이 콜백을 부르는 이른바 '콜백 지옥' 없이, 수많은 동시 작업을 가볍게 다룰 수 있습니다. 네트워크 요청이나 DB 조회처럼 기다리는 작업이 많은 서버·앱에서 특히 빛을 봅니다.

 

자바와의 완전한 호환 — 이게 사실 코틀린 확산의 일등 공신입니다. 기존 자바 프로젝트에 코틀린 파일을 한 개씩 섞어 넣을 수 있어요. 전부 다시 짤 필요 없이, 새 기능부터 코틀린으로 쓰는 식의 점진적 전환이 가능합니다.

 

 

💡 호환성이 왜 중요할까

새 언어가 아무리 좋아도 기존 코드와 못 섞이면 도입 장벽이 큽니다.

코틀린은 자바 라이브러리와 프레임워크를 그대로 쓸 수 있어서,

기업 입장에서 "있는 거 버리고 갈아타는" 부담 없이 받아들일 수 있었습니다.

 

4. 자바 vs 코틀린, 무엇이 다른가

둘은 경쟁 관계라기보다 한 식구에 가깝지만, 입문자가 감을 잡기 좋게 비교해 보겠습니다.

항목	자바	코틀린
널 처리	런타임에 NPE 발생 위험	타입에 null 여부 명시, 컴파일 단계 차단
코드 길이	보일러플레이트 많음	간결, 데이터 클래스 등으로 대폭 축소
비동기	스레드·CompletableFuture 등	코루틴으로 가볍게 처리
실행 환경	주로 JVM	JVM 외에 네이티브·JS·Wasm도
학습 곡선	기초 문법 단순	자바 경험자는 빠름, 기능은 더 풍부
생태계	20년 넘게 축적된 방대한 자료	자바 자산 그대로 활용 가능

표를 보면 코틀린이 자바를 밀어내는 그림이라기보다, 자바가 깔아놓은 토대 위에서 더 편하게 일하게 해주는 쪽이라는 게 보입니다. 그래서 신규 자바 진영 프로젝트가 코틀린으로 시작하는 경우가 꾸준히 늘었습니다.

5. 코틀린이 실행되는 네 개의 무대

코틀린의 활용 범위가 넓은 근본 이유는 '실행 타깃'이 여러 개라는 데 있습니다. 같은 코틀린 코드를 어디로 컴파일하느냐에 따라 도는 환경이 달라집니다.

- Kotlin/JVM — 가장 기본. 자바 가상 머신 위에서 돌며 안드로이드 앱과 서버 백엔드가 여기 속합니다.

- Kotlin/Native — JVM 없이 기계어로 직접 컴파일. iOS나 임베디드처럼 JVM이 없는 환경을 노립니다.

- Kotlin/JS — 자바스크립트로 변환해 웹 브라우저에서 실행.

- Kotlin/Wasm — 웹어셈블리로 컴파일해 브라우저에서 더 빠르게 돌리는 비교적 새로운 타깃.

이 네 갈래 덕분에 "코틀린 하나로 모바일·서버·웹을 다 건드린다"는 말이 가능해집니다. 뒤에서 볼 멀티플랫폼도 결국 이 구조 위에 서 있습니다.

6. 활용 ① 안드로이드 앱 개발

가장 널리 알려진 영역입니다. 2019년 구글이 안드로이드 개발에서 코틀린을 우선한다고 못 박은 이후, 신규 안드로이드 프로젝트의 기본값은 사실상 코틀린이 됐습니다. 공식 문서, 샘플 코드, 안드로이드 스튜디오의 기능 지원이 전부 코틀린 중심으로 돌아갑니다.

UI 쪽에서는 Jetpack Compose라는 선언형 UI 도구가 표준으로 자리 잡았습니다. XML로 화면을 짜던 옛 방식 대신, 코틀린 코드로 직접 UI를 기술하는 방식이죠. 코루틴과 결합해 화면 상태 관리도 한결 깔끔해졌습니다.

 

 

📌 안드로이드 입문이라면
지금 안드로이드를 처음 배운다면 자바보다 코틀린 + Jetpack Compose 조합으로 시작하는 편이 자료도 많고 미래 대응에도 유리합니다.

다만 유지보수로 들어가는 기존 앱은 여전히 자바 코드가 많으니, 자바를 아예 모르고 가긴 어렵습니다.

 

7. 활용 ② 서버·백엔드 개발

의외로 강력한 영역이 백엔드입니다. 코틀린이 JVM 위에서 돌기 때문에, 자바 진영의 검증된 서버 생태계를 거의 그대로 쓸 수 있습니다. 거기에 코틀린의 간결함과 코루틴 기반 비동기 처리가 더해지니, 동시 접속이 많은 API 서버나 마이크로서비스에서 매력이 큽니다.

대표 프레임워크를 정리하면 이렇습니다.

- 스프링 부트(Spring Boot) — 자바 진영의 사실상 표준. 스프링 부트 3부터 코틀린을 1급으로 지원해, 코루틴 컨트롤러와 코틀린 DSL 설정을 자연스럽게 쓸 수 있습니다.

- Ktor — JetBrains가 코틀린을 위해 처음부터 새로 만든 경량 프레임워크. 코루틴이 부가 기능이 아니라 뼈대입니다. 마이크로서비스·API에 잘 맞습니다.

- Micronaut / Quarkus — 빠른 시작 속도와 적은 메모리를 노린 클라우드·서버리스 지향 프레임워크. 코틀린을 지원합니다.

- Koin — 코틀린용 경량 의존성 주입(DI) 라이브러리. 스프링의 무거운 DI 대신 가볍게 쓰고 싶을 때 자주 짝지어집니다.

8. 백엔드 양대 프레임워크: 스프링 부트 vs Ktor

백엔드를 코틀린으로 한다면 결국 마주치는 갈림길이 스프링 부트와 Ktor입니다. 성격이 꽤 다릅니다.

항목	스프링 부트	Ktor
성격	기능이 다 갖춰진 종합 프레임워크	필요한 것만 끼우는 경량 프레임워크
출신	자바 기반, 코틀린도 1급 지원	JetBrains가 코틀린 전용으로 제작
생태계	보안·데이터·클라우드 등 방대	상대적으로 작지만 충분히 실무 가능
시작 속도·메모리	무거운 편	가볍고 빠른 콜드 스타트
잘 맞는 곳	대규모 엔터프라이즈, 팀 합류 빠름	컨테이너·마이크로서비스, 코틀린 우선 팀

거칠게 요약하면, 자료가 풍부하고 자바 개발자가 바로 합류하기 좋은 쪽은 스프링 부트, 가볍고 코틀린답게 짜고 싶은 쪽은 Ktor입니다. 자료 검색과 채용 풀을 생각하면 국내 실무에서는 아직 스프링 진영이 두텁습니다. 새 프로젝트의 성격에 따라 고르면 됩니다.

9. 활용 ③ 코틀린 멀티플랫폼(KMP)

여기서부터가 코틀린이 "안드로이드 언어"라는 인상을 확실히 벗는 지점입니다. 코틀린 멀티플랫폼(Kotlin Multiplatform, 줄여서 KMP)은 하나의 코틀린 코드로 안드로이드와 iOS, 데스크톱, 서버까지 공통 로직을 공유하는 기술입니다.

전형적인 방식은 이렇습니다. 네트워크 통신, 데이터 모델, 입력값 검증, 비즈니스 규칙처럼 화면과 상관없는 핵심 로직을 공통 모듈에 한 번만 작성합니다. 그리고 화면(UI)이나 결제·생체인증 같은 플랫폼 고유 기능만 각 플랫폼에서 따로 구현하는 식이죠. 같은 규칙을 안드로이드와 iOS에 두 번 짜다가 생기는 미묘한 동작 차이를 줄일 수 있습니다.

2026년 기준 KMP는 안정 단계이고, 구글도 안드로이드와 iOS 사이의 비즈니스 로직 공유 용도로 KMP를 공식 지원합니다. Room, DataStore 같은 안드로이드 표준 라이브러리들이 멀티플랫폼을 지원하면서, 익숙한 API를 공통 코드에서 쓸 수 있게 됐습니다.

 

 

💡 KMP의 현실적 접근법
전체를 한 번에 공유하기보다, 보통은 로직부터 점진적으로 공유하는 방식을 권합니다.

네트워크·데이터 계층을 먼저 공통화하고, UI는 일단 각 플랫폼 네이티브로 두는 식입니다.

검증을 거치며 공유 범위를 차차 넓혀가는 거죠.

 

10. 활용 ④ Compose Multiplatform, UI까지 공유하기

KMP가 로직 공유라면, Compose Multiplatform(CMP)은 화면(UI)까지 공유하려는 도구입니다. 안드로이드의 Jetpack Compose를 다른 플랫폼으로 확장한 것으로, 같은 코틀린 UI 코드를 안드로이드·iOS·데스크톱에서 함께 씁니다.

2026년 기준 Compose Multiplatform은 안드로이드, iOS, 데스크톱에서 안정(stable) 단계입니다. iOS용도 2025년에 정식 안정화돼, 스크롤감이나 텍스트 선택 같은 세부 경험이 네이티브에 상당히 가까워졌습니다. 웹 타깃은 아직 베타라 초기 도입자용에 가깝습니다.

방식이 독특한데, 안드로이드 UI를 iOS 컴포넌트로 '번역'하는 게 아니라 자체 렌더링 엔진으로 화면을 직접 그립니다. 그래서 두 플랫폼에서 버튼 모양이 미묘하게 다른 문제가 줄어드는 대신, Kotlin/Native 런타임이 들어가 앱 용량이 다소 늘어나는 식의 트레이드오프가 있습니다.

11. 활용 ⑤ 웹·데이터·스크립팅

덜 알려졌지만 코틀린이 발을 걸치고 있는 영역이 더 있습니다.

- 웹 프런트(Kotlin/JS, Kotlin/Wasm) — 코틀린 코드를 자바스크립트나 웹어셈블리로 변환해 브라우저에서 돌립니다. 앞서 본 Compose Multiplatform의 웹 타깃도 여기에 기댑니다.

- 데이터·스크립팅 — 간단한 자동화 스크립트나 데이터 처리에도 쓸 수 있습니다. 자바의 무거운 절차 없이 가볍게 돌리는 용도죠.

- 서버리스·클라우드 — 시작 속도가 중요한 환경에서 Ktor나 GraalVM 네이티브 이미지와 결합해 가벼운 함수형 서비스를 만들기도 합니다.

다만 솔직히 말하면 웹 프런트나 데이터 영역은 자바스크립트·파이썬 같은 기존 강자가 워낙 두터워서, 코틀린이 주류라고 하긴 어렵습니다. "가능하다"와 "주로 쓴다"는 다르니, 이 영역은 선택지 정도로 보는 게 맞습니다.

12. 그래서 코틀린, 어디에 쓰면 좋을까

활용 범위가 넓다고 해서 전부 코틀린으로 가야 한다는 뜻은 아닙니다. 현실적으로 정리하면 이렇습니다.

상황	코틀린의 위치
안드로이드 앱	사실상 표준. 새로 시작한다면 1순위
JVM 백엔드	자바 대안으로 충분히 강력. 스프링/Ktor 선택
안드로이드+iOS 동시	KMP로 로직 공유 검토할 만함
웹 프런트 단독	가능하나 주류 아님. 신중히
데이터·AI	파이썬 생태계가 압도적, 굳이 권하기 어려움

요점은 코틀린의 본거지가 JVM(안드로이드+백엔드)이고, 그 위에서 멀티플랫폼으로 영역을 넓혀가는 언어라는 겁니다. 자바를 다뤄봤거나 안드로이드를 하려는 사람에게는 거의 필수에 가깝고, 그 바깥 영역은 "할 수는 있다" 정도로 받아들이면 기대치가 어긋나지 않습니다.

13. 코틀린 입문자가 자주 묻는 질문 (FAQ)

코틀린은 자바를 완전히 대체하나요?

대체라기보다 공존에 가깝습니다. 코틀린은 자바 가상 머신 위에서 돌고 자바 코드와 100% 섞어 쓸 수 있어서, 기존 자바 자산을 버릴 필요가 없습니다. 안드로이드 신규 개발에선 코틀린이 우선이지만, 백엔드나 레거시 시스템에는 자바가 여전히 광범위하게 살아 있습니다.

코틀린을 배우려면 자바를 먼저 알아야 하나요?

꼭 필수는 아닙니다. 코틀린 자체는 자바 없이도 입문할 수 있게 설계돼 있어요. 다만 실무에선 자바로 짜인 라이브러리나 기존 코드를 마주칠 일이 많아, 자바를 어느 정도 읽을 줄 알면 훨씬 수월합니다.

코틀린으로 iOS 앱도 만들 수 있나요?

가능합니다. 코틀린 멀티플랫폼(KMP)으로 안드로이드와 iOS의 공통 로직을 공유할 수 있고, Compose Multiplatform을 쓰면 화면(UI)까지 함께 만들 수 있습니다. 2026년 기준 iOS용도 안정 단계지만, 결제·생체인증 같은 일부 기능은 여전히 플랫폼별 네이티브 코드가 필요합니다.

코틀린 백엔드는 스프링 부트와 Ktor 중 무엇으로 시작하면 좋나요?

자료가 풍부하고 채용 시장이 두터운 쪽을 원하면 스프링 부트, 가볍고 코틀린답게 짜고 싶으면 Ktor입니다. 입문자나 국내 취업을 염두에 둔다면 스프링 부트 쪽이 무난하고, 마이크로서비스나 컨테이너 환경의 경량 서비스라면 Ktor가 잘 맞습니다.

코틀린은 입문자가 배우기 어렵나요?

기초 문법은 무난한 편이지만, 코루틴이나 널 안정성 같은 코틀린 특유의 개념은 처음엔 낯설 수 있습니다. 다행히 공식 문서와 한글 자료가 잘 갖춰져 있어, 천천히 익히면 큰 진입 장벽은 아닙니다.

14. 마무리

코틀린을 "안드로이드 언어"로만 알고 있었다면, 적어도 그 틀은 깨졌을 거라 생각합니다. JVM 백엔드, iOS, 데스크톱까지 하나의 언어로 넘나드는 흐름은 다른 언어가 쉽게 따라 하기 어려운 코틀린만의 그림이에요.

물론 모든 곳에서 1등인 언어는 없습니다. 웹이나 데이터 영역에선 여전히 다른 언어가 우위고, 코틀린이 만능 해결책처럼 포장되는 건 경계할 일입니다. 그래도 자바 자산을 그대로 안고 가면서 더 안전하고 간결하게 쓰고 싶다면, 그리고 안드로이드나 멀티플랫폼을 노린다면 코틀린은 지금 시점에서 충분히 배워둘 가치가 있는 언어입니다.

버전과 생태계는 계속 움직이는 중이라, 입문하실 거면 공식 문서(kotlinlang.org)에서 최신 상황을 한 번 확인하고 시작하시길 권합니다.

한눈에 보는 코틀린 용어집

본문에 나온 용어 중 처음 보면 헷갈릴 만한 것들을 모아 정리했습니다.

반응형

용어	쉽게 풀면
JVM (자바 가상 머신)	자바·코틀린 코드를 실제 컴퓨터에서 돌게 해주는 실행 환경. OS가 달라도 같은 코드가 돌아가게 해줍니다.
컴파일 / 컴파일러	사람이 쓴 코드를 컴퓨터가 실행할 수 있는 형태로 번역하는 과정(컴파일)과 그 번역기(컴파일러).
정적 타입	변수의 자료형을 실행 전(컴파일 시점)에 미리 검사하는 방식. 타입 실수를 일찍 잡아줍니다.
런타임	프로그램이 실제로 실행되고 있는 동안의 시점. "런타임 오류"는 돌리던 중에 터지는 오류를 뜻합니다.
널 안정성 (Null Safety)	값이 비어 있을(null) 가능성을 언어가 미리 관리해, 빈 값을 잘못 건드려 생기는 오류를 막는 기능.
NullPointerException (NPE)	비어 있는(null) 값을 실수로 사용하려다 프로그램이 멈추는 대표적인 오류. 자바 개발자의 단골 골칫거리.
보일러플레이트	기능과 상관없이 형식상 반복해서 써야 하는 군더더기 코드. 코틀린은 이걸 많이 줄여줍니다.
데이터 클래스	데이터를 담는 용도의 클래스를 한 줄로 정의하면, 비교·출력·복사 기능을 코틀린이 자동으로 만들어 주는 문법.
비동기 / 코루틴	기다리는 작업(네트워크·DB 등)을 멈춰 서지 않고 처리하는 방식이 '비동기'. 코틀린은 '코루틴'으로 이를 쉽게 쓰게 해줍니다.
프레임워크	앱·서버를 만들 때 뼈대와 공통 기능을 미리 제공해 주는 도구 묶음. 스프링 부트, Ktor 등이 해당합니다.
API	프로그램끼리 정해진 방식으로 데이터를 주고받게 해주는 약속. 서버가 외부에 기능을 열어주는 창구로 자주 쓰입니다.
의존성 주입 (DI)	어떤 객체가 필요로 하는 부품을 직접 만들지 않고 밖에서 넣어주는 설계 방식. 코드 결합을 느슨하게 해줍니다.
마이크로서비스	큰 시스템을 작고 독립적인 여러 서비스로 잘게 쪼개 만드는 아키텍처 방식.
콜드 스타트	서버나 함수가 처음 켜질 때 준비를 마치고 응답하기까지 걸리는 시간. 짧을수록 클라우드 비용·반응성에 유리합니다.
선언형 UI / Jetpack Compose	"화면이 이렇게 생겨야 한다"고 코드로 기술하면 알아서 그려주는 방식이 선언형 UI. 안드로이드의 대표 도구가 Jetpack Compose입니다.
네이티브 / Kotlin/Native	JVM을 거치지 않고 기계어로 직접 실행되는 형태. iOS처럼 JVM이 없는 환경을 겨냥합니다.
웹어셈블리 (Wasm)	브라우저에서 자바스크립트보다 빠르게 돌리기 위한 저수준 실행 형식. 코틀린도 이 타깃을 지원합니다.
K2 컴파일러	코틀린 2.0부터 기본이 된 새 컴파일러. 빌드 속도가 빨라지고 여러 플랫폼을 통합해 다룹니다.
KMP (코틀린 멀티플랫폼)	하나의 코틀린 코드를 안드로이드·iOS·데스크톱·서버에서 함께 쓰도록 공유하는 기술.