News

Kotlin의 미래에 대한 10가지 질문과 답변

Read this post in other languages:
English, Français

이 글에서는 앞으로의 Kotlin에 대해 가장 많은 투표를 받은 10가지 질문에 대해 답변합니다. 여러분도 댓글이나 Reddit(아래 링크)에서 대화에 참여할 수 있습니다.

얼마 전, 1.5.0 릴리즈 이벤트의 일환으로 Reddit에서 Kotlin 팀 AMA(Ask Me Anything, 무엇이든 물어보세요)을 진행했습니다. 저희는 수백 개의 질문을 받았으며, 여기에 대한 답을 하고 대화에 참여하며 매우 즐거웠습니다.

Reddit에서 받은 질문을 통해, 우리는 이 대화를 더 널리 공유하는게 중요하다고 느꼈습니다. 답변은 Kotlin 커뮤니티의 모두에게 훌륭한 지식의 원천입니다. 질문을 해 주신 모든 분과 세심하게 그 질문에 대해 모두 답을 해 준 팀에게 감사를 전합니다.

우리는 최근 릴리즈에 관한 질문 뿐 아니라 몇 가지 기술적인 질문을 받았습니다. 그러나 추천을 많이 받고 사실 우리 관심을 가장 끌었던 것은 Kotlin의 미래에 대한 질문이었습니다.

질문

질문 #1
몇 년 전, 가장 원하는 기능에 투표하는 개발자 설문이 있었습니다. 앞으로 비슷한 것이 있을까요? 

“설문에 참여할 수 있습니다. 기능 설명과 Svetlana Isakova와 Roman Elizarov가 진행했던 웨비나 관련 내용은 이 블로그 글에 있습니다. 현재는 이 설문 조사의 다음 버전을 준비하고 있습니다. 많은 관심 부탁드립니다!”
Reddit 스레드

질문 #2 
중 장기적으로 5년 정도를 가정하여, Java의 변화 속도가 빨라진다면, Java와 Kotlin의 상호 호환성을 유지하는데 어떤 문제를 예상하나요? 예를 들어 Kotlin과 통합하기 매우 어려운, Java 언어나 JVM 바이트코드 구조를 변경하는 프로젝트가 현재 있을까요? 

“우리는 JVM 설계 과정을 밀접하게 따라가고 있습니다. 개발 중이거나, 심지어 꽤 먼 미래에 계획 된 어떤 JVM 기능도 문제가 되지 않았습니다. ”
Reddit 스레드

질문 #3 
예전에 질문한 것인데, 패턴 매칭에 대한 현재 생각은 무엇인가요?
 

“우리는 여전히 관심을 가지고 지켜보고 있지만, Kotlin when 표현식에서 할 수 있는 가장 중요한 단기적인 개선 사항은 가드에 대한 지원을 추가하는 것입니다. https://youtrack.jetbrains.com/issue/KT-13626”을 보세요. 
Reddit 스레드

질문 #4 
Kotlin이 KMM용 Object-C 대신 Swift로 컴파일 할 수 있는 방법이 있을까요? 

“Kotlin은 실제로 iOS용 Objective-C를 컴파일하지 않습니다.

대신 코어에서 Kotlin/Native로 Kotlin을(LLVM의 도움을 받아) 직접 네이티브 코드로 컴파일합니다.

또한 Objective-C 및 Swift에서 컴파일된 Kotlin 코드에 액세스할 수 있도록 브리지를 생성합니다. Kotlin 클래스 Foo의 경우 컴파일러는 추가적으로 “어댑터”를 생성하며, 이를 Objective-C와 Swift가 Objective-C 클래스로 인식합니다. 이 어댑터는 모든 것을 원래 Kotlin 클래스에게 위임합니다.

Kotlin/Native 컴파일러가 Kotlin API에 대한 Objective-C 표현을 추가하는 것과 비슷합니다. 문제는 사실, Kotlin에 Swift 표현을 추가할 방법이 있냐는 거겠죠? 우리는 정답을 계속 살펴보고 있습니다. 
자세한 내용은 Reddit에서 확인해 주세요.

질문 #5
Intellij [IntelliJ IDEA]에서 서식 지정 기능을 별도의 도구로 분리할 계획이 있나요? 

“우리는 서식 지정 규칙 검사기 작업을 거의 다했습니다. 이 검사기는 CI에서 실행 할 수 있을 겁니다. Qodana를 기반으로 하며 IntelliJ IDEA에 있는 Kotlin에 대한 검사를 실행합니다.

현재

  • 이 검사는 .idea 폴더에 저장된 IntelliJ IDEA 서식 지정 설정을 매우 깊이 의존합니다.
  • 아직까지는 유용하지 않습니다. 단지 서식 지정이 잘못되었다고 알려줍니다.

우리는 이 두가지 문제를 해결해 Qodana에 검사를 추가하길 희망합니다.” 
자세한 내용은 Reddit에서 확인해 주세요

질문 #6 
이전에 컴파일 속도가 Kotlin 팀의 최우선 순위이지만, 여러 릴리즈를 통해 다년간의 노력이 필요할거라고 발표한 것으로 알고 있습니다. 어떻게 상황이 진행되고 있는지 알려주시겠어요?

컴파일 성능에 대한 작업은 두 부분으로 나누어집니다.

  1. 기존 컴파일러 보다 더 나은 성능을 얻는 것이 주목표인 새 컴파일러 프론트엔드를 작성하기.
  2. 새 컴파일러 백엔드(백엔드 IR)를 출시하고, 중요 버그를 잡고 최적화하기.

JVM/IR 백엔드는 Kotlin 1.5에서 출시되었습니다. JVM 팀은 이제 앞으로 성능에 중심을 둘 것입니다.

한편, 새 프론트엔드는 활발히 개발중이며 올해 가을에 초기 버전을 출시하려고 합니다. 새 컴파일러 프론트엔드는 주요 성능 향상을 제공할 것입니다. 지금 현재 프론트엔드보다 4배 빠르며, 전체 컴파일 파이프라인 (프론트엔드+백엔드)의 속도보다는 효과적으로 두배정도 빠릅니다.

그리고 Kotlin IDE 플러그인이 분석을 위해 컴파일러 플러그인을 사용하기 때문에 FIR에 기반한 새 플러그인이 IDE 환경에서도 성능을 향상시킬 것 입니다. 
Reddit 스레드

질문 #7 
Kotlin DI[Dependency Injection, 종속성 삽입] 솔루션을 기본적으로 제공할 계획이 있나요?
 

“DI[Dependency Injection, 종속성 삽입]는 언어 또는 표준 라이브로리로 통합되기에는 너무 많은 경쟁 요구사항을 만들기 때문에 별도의 라이브러리로 더 잘 작동한다고 생각합니다.”
레딧에서 자세한 내용을 읽기

질문 #8 
Kotlin과 TypeScript의 크로스 컴파일러에 대한 아이디어는 어떻게 생각하나요? Kotlin과 Java를 함께 컴파일할 수 있는 방법처럼요.

우리는 JavaScript, TypeScript와 원활한 상호작용이 좋다는 것에는 확실히 동의하지만 아래와 같은 문제가 있습니다.

  • Kotlin과 TypeScript/JavaScript의 타입 시스템과 의미적인 비호환성.
  • 매우 빨리 진화되는 TypeScript.
  • 실행 환경으로서 JavaScript VM을 대상으로하고 TypeScript로 작성된 TypeScript 컴파일러, Kotlin과 Java로 작성되고 JVM을 대상 실행 환경으로 하는 Kotlin 컴파일러를 어떻게든 양방향(!)으로 통합해야 함. 또는, 자체 TypeScript 컴파일러 프론트엔드🙂를 만들고 지원해야 할 수도 있음
    (Java의 경우에는 훨씬 간단하여, IntelliJ의 Java 컴파일러 프론트엔드를 재사용 할 수 있음.)

그래서, 우리는 지금 분리된 다단계 상호운용성에 집중하고 있습니다. TypeScript 선언을 Kotlin 선언으로 변환하여 소비하고 (d.ts) Kotlin으로부터 TypeScript 선언을 생성합니다. (d.ts)
Kotlin으로부터 TypeScript 선언을 생성(d.ts)하는 것은 새 JS IR 컴파일러 백엔드를 사용할 때 가능합니다.

누가 알겠어요? 언젠가 매끄럽게 될 수도 있을겁니다.

자세한 내용을 Reddit서 읽기

질문 #9
Kotlin과 Spring에 대한 다음 단계는 무엇인가요? 특히 서버 측 Kotlin에서요. 

Spring Boot 2.5가 Kotlin 1.5를 기준으로 출시되었습니다. 코루틴 1.5와 직렬화 1.2 라이브러리로 업그레이드하였습니다.

다음 단계는 https://github.com/spring-projects-experimental/spring-native/을 통해 훌륭한 Kotlin/JVM/Native(Kotlin/JVM을 GraalVM 네이티브 이미지를 이용해 네이티브로 사용) 지원을 제공하고, (예를 들어 Kotlin/JS 프론트엔드를 이용하여) 멀티플랫폼 개발을 강화하고, Spring Boot 문서를 Kotlin으로 번역하고(Kotlin 팀의 기여를 통해), 재귀적인 제네릭 타입(WebTestClient 처럼)의 일부 타입 추론의 버그 때문에 Kotlin에서 현재 손상된 API를 사용가능하게 하는 것입니다.

장기적으로 제가 좋아하는 주제는 Kotlin 리플렉션을 AOT(Ahead of time)로 적용해 Spring 프레임 워크에서 실시간 kotlin-reflect를 제거하는 것과, https://github.com/spring-projects-experimental/spring-fu를 성숙시켜 더 DSL스럽게 Spring Boot를 구성하는 것입니다.

비록 Spring 기반의 구현은 아니지만 RSocket 프로토콜(GRPC의 많은 용례에 대해 https://rsocket.io/는 대안이 될 수 있습니다)의 Kotlin 멀티플랫폼 구현인 https://github.com/rsocket/rsocket-kotlin을 도우려고 합니다.
Reddit에서 자세한 내용 읽기

질문 #10 메타 프로그래밍 기능을 제공할 계획이 있다고 알고 있는데, 이 주제에 대한 새로운 소식이 있나요?

“두 프론트에 대해 메타 프로그래밍을 작업중입니다.

  • 컴파일러 플러그인 – 이 부분에서 많은 커뮤니티 업데이트가 있는 것을 보아왔습니다. 예를 들어 https://bnorm.medium.com/writing-your-second-kotlin-compiler-plugin-part-1-project-setup-7b05c7d93f6c와 같은, Brian Norman의 시리즈를 살펴보세요. 앞으로 이런 플러그인에 대한 안정적인 컴파일러 API를 제공할 계획입니다.
  • 더 나은 인라인과 상수 표현식 평가. 이 부분에 대해 관심을 갖고 지켜봐 주세요. 올해 이 연구의 개발 테스트 버전을 보여줄 수 있을 것입니다.
    Reddit 스레드

Kotlin과 미래에 관한 유용한 추가 리소스

향후에도 알림을 받고 싶으시다면, Twitter, 블로그 업데이트, YouTube 채널을 구독해 주세요. Kotlin의 새로운 기능을 위한 투표를 시작할 예정입니다. 향후에 저희가 어떤 기능에 우선 순위를 두어야할지 여러 분의 의견을 들려주세요.

이 블로그 게시물을 한국어로 번역 해 주신 Kotlin 커뮤니티의 김용욱 님에게 특별한 감사를 드립니다.

게시물 원문 작성자

Jessie Cho

Alina Dolgikh

Discover more