Kotlin 발전 원칙

실용적인 발전 원칙

언어 설계는 돌에 새겨지는 것과 같습니다.

하지만 이 돌은 상당히 부드러워서,

약간의 노력을 기울이면 나중에 다시 모양을 만들 수 있습니다.

Kotlin 디자인 팀

Kotlin은 프로그래머를 위한 실용적인 도구로 설계되었습니다. 언어 발전에 있어서 Kotlin의 실용적인 특성은 다음 원칙들에 의해 구현됩니다.

• 시간이 지나도 언어를 현대적으로 유지합니다.
• 사용자와 지속적인 피드백 루프를 유지합니다.
• 사용자들이 새 버전으로 쉽게 편안하게 업데이트할 수 있도록 합니다.

이러한 원칙들은 Kotlin이 어떻게 발전하고 있는지를 이해하는 데 핵심적이므로, 각 원칙에 대해 자세히 살펴보겠습니다.

언어를 현대적으로 유지하기. 시스템은 시간이 지남에 따라 레거시를 축적한다는 것을 인지하고 있습니다. 한때는 최첨단 기술이었던 것이 오늘날에는 도저히 구식이 될 수 있습니다. 우리는 사용자들의 요구에 부응하고 그들의 기대에 맞춰 언어를 계속 발전시켜야 합니다. 여기에는 새로운 기능을 추가하는 것뿐만 아니라, 더 이상 프로덕션 사용에 권장되지 않고 레거시가 된 오래된 기능들을 단계적으로 제거하는 것도 포함됩니다.

편안한 업데이트. 언어에서 일부 요소를 제거하는 것과 같은 호환되지 않는 변경 사항은 제대로 처리하지 않으면 다음 버전으로의 마이그레이션을 고통스럽게 만들 수 있습니다. 우리는 항상 그러한 변경 사항들을 미리 충분히 공지하고, 해당 요소들을 사용 중단(deprecated)으로 표시하며, 변경이 발생하기 전에 자동화된 마이그레이션 도구를 제공할 것입니다. 언어가 변경될 때쯤이면 전 세계 대부분의 코드가 이미 업데이트되어 새 버전으로 마이그레이션하는 데 문제가 없기를 바랍니다.

피드백 루프. 사용 중단(deprecation) 주기를 거치는 것은 상당한 노력이 필요하므로, 미래에 발생할 호환되지 않는 변경 사항의 수를 최소화하고자 합니다. 최선의 판단을 사용하는 것 외에도, 우리는 실제 환경에서 시도해보는 것이 설계를 검증하는 가장 좋은 방법이라고 믿습니다. 최종 결정(casting things in stone)을 내리기 전에 충분히 검증(battle-tested)되기를 바랍니다. 이것이 우리가 디자인의 초기 버전을 언어의 프로덕션 버전에서 활용하되, 사전 안정(pre-stable) 상태 중 하나인 Experimental, Alpha, 또는 Beta로 제공하는 모든 기회를 활용하는 이유입니다. 이러한 기능들은 안정적이지 않으며 언제든지 변경될 수 있으며, 이를 사용하기로 선택한 사용자들은 미래의 마이그레이션 문제를 기꺼이 다룰 준비가 되어 있음을 명시적으로 나타내는 것입니다. 이 사용자들은 우리가 디자인을 반복하고 견고하게 만드는 데 사용하는 매우 귀중한 피드백을 제공합니다.

호환되지 않는 변경 사항

한 버전에서 다른 버전으로 업데이트할 때, 기존에 작동하던 코드가 더 이상 작동하지 않는 경우, 이는 언어의 호환되지 않는 변경(incompatible change) 입니다(때로는 "파괴적 변경(breaking change)"이라고도 합니다). 어떤 경우에는 "더 이상 작동하지 않는다"는 것이 정확히 무엇을 의미하는지에 대한 논쟁이 있을 수 있지만, 다음은 확실히 포함됩니다.

• 컴파일 및 실행이 잘 되던 코드가 이제 오류(컴파일 또는 링크 시)로 거부됩니다. 여기에는 언어 구성 요소 제거 및 새로운 제한 추가가 포함됩니다.
• 정상적으로 실행되던 코드가 이제 예외를 발생시킵니다.

"회색 영역"에 속하는 덜 명확한 경우에는 예외 처리 방식 변경, 이전과 다른 유형의 예외 발생, 리플렉션을 통해서만 관찰 가능한 동작 변경, 문서화되지 않거나 정의되지 않은 동작 수정, 바이너리 아티팩트 이름 변경 등이 포함됩니다. 때로는 이러한 변경이 중요하고 마이그레이션 경험에 극적으로 영향을 미치기도 하지만, 때로는 미미하기도 합니다.

다음은 확실히 호환되지 않는 변경 사항이 아닌 경우의 몇 가지 예시입니다.

• 새로운 경고 추가.
• 새로운 언어 구성 요소 활성화 또는 기존 구성 요소에 대한 제한 완화.
• private/internal API 및 기타 구현 세부 정보 변경.

'언어를 현대적으로 유지하기'와 '편안한 업데이트' 원칙은 호환되지 않는 변경이 때로는 필요하지만, 신중하게 도입되어야 함을 시사합니다. 우리의 목표는 사용자들이 다가오는 변경 사항을 미리 충분히 인지하여 코드를 편안하게 마이그레이션할 수 있도록 하는 것입니다.

이상적으로는 모든 호환되지 않는 변경 사항이 문제가 있는 코드에서 보고되는 컴파일 시간 경고(일반적으로 사용 중단 경고라고 함)를 통해 발표되고, 자동화된 마이그레이션 지원이 동반되어야 합니다. 따라서 이상적인 마이그레이션 워크플로우는 다음과 같습니다.

• 버전 A로 업데이트 (변경 사항이 발표되는 버전)
  • 다가오는 변경 사항에 대한 경고 확인
  • 도구의 도움을 받아 코드 마이그레이션
• 버전 B로 업데이트 (변경 사항이 실제로 적용되는 버전)
  • 아무런 문제도 발생하지 않음

실제로 일부 변경 사항은 컴파일 시 정확하게 감지할 수 없으므로 경고를 보고할 수 없지만, 최소한 사용자들은 버전 A의 릴리스 노트를 통해 버전 B에서 변경 사항이 발생할 것임을 알 수 있습니다.

컴파일러 버그 처리

컴파일러는 복잡한 소프트웨어이며, 개발자들의 최선의 노력에도 불구하고 버그가 있습니다. 컴파일러 자체가 실패하거나 잘못된 오류를 보고하거나 명백히 실패하는 코드를 생성하는 버그는 성가시고 종종 당황스럽지만, 수정 사항이 호환되지 않는 변경 사항을 구성하지 않기 때문에 쉽게 고칠 수 있습니다. 다른 버그는 컴파일러가 실패하지 않는 잘못된 코드를 생성하게 할 수도 있습니다. 예를 들어, 소스에서 일부 오류를 놓치거나 단순히 잘못된 명령을 생성하는 경우입니다. 이러한 버그에 대한 수정 사항은 기술적으로 호환되지 않는 변경 사항입니다(일부 코드는 이전에는 잘 컴파일되었지만 이제는 그렇지 않게 됩니다). 하지만 우리는 사용자의 코드 전반에 걸쳐 잘못된 코드 패턴이 확산되는 것을 방지하기 위해 가능한 한 빨리 이를 수정하려고 합니다. 우리의 의견으로는 이것이 '편안한 업데이트' 원칙을 지원한다고 생각합니다. 왜냐하면 더 적은 사용자들이 해당 문제를 접할 가능성이 있기 때문입니다. 물론 이는 릴리스된 버전에서 나타난 직후에 발견된 버그에만 해당됩니다.

의사 결정

Kotlin의 원래 제작사인 JetBrains는 커뮤니티의 도움과 Kotlin Foundation과의 협력을 통해 Kotlin의 발전을 이끌고 있습니다.

Kotlin 프로그래밍 언어의 모든 변경 사항은 언어 수석 디자이너 (현재 Michail Zarečenskij)가 감독합니다. 수석 디자이너는 언어 발전과 관련된 모든 사안에 대한 최종 결정권을 가집니다. 또한, 완전히 안정적인 구성 요소에 대한 호환되지 않는 변경 사항은 Kotlin Foundation 산하에 지정된 언어 위원회 (현재 Jeffrey van Gogh, Werner Dietl, Michail Zarečenskij로 구성)의 승인을 받아야 합니다.

언어 위원회는 어떤 호환되지 않는 변경이 이루어질지, 그리고 사용자 업데이트를 가능한 한 원활하게 만들기 위해 어떤 정확한 조치를 취해야 할지에 대한 최종 결정을 내립니다. 이 과정에서 위원회는 일련의 언어 위원회 가이드라인에 의존합니다.

언어 및 도구 릴리스

2.0.0과 같은 버전의 안정적인 릴리스는 일반적으로 언어의 주요 변경 사항을 가져오는 언어 릴리스로 간주됩니다. 일반적으로 언어 릴리스 사이에는 x.x.20으로 번호가 매겨진 도구 릴리스를 게시합니다.

도구 릴리스는 도구 업데이트(종종 기능 포함), 성능 개선 및 버그 수정을 제공합니다. 우리는 이러한 버전들이 서로 호환되도록 노력하고 있으며, 따라서 컴파일러 변경 사항은 대부분 최적화 및 경고 추가/제거에 해당합니다. 사전 안정(pre-stable) 기능은 언제든지 추가, 제거 또는 변경될 수 있습니다.

언어 릴리스는 종종 새로운 기능을 추가하고, 이전에 사용 중단된 기능을 제거하거나 변경할 수 있습니다. 사전 안정에서 안정으로의 기능 졸업(Feature graduation) 또한 언어 릴리스에서 발생합니다.

EAP 빌드

언어 및 도구 릴리스의 안정 버전을 출시하기 전에, 우리는 더 빠르게 반복하고 커뮤니티로부터 피드백을 수집할 수 있도록 EAP("Early Access Preview"의 약자)라고 불리는 여러 프리뷰 빌드를 게시합니다. 언어 릴리스의 EAP는 일반적으로 나중에 안정 컴파일러에 의해 거부될 바이너리를 생성하여, 바이너리 형식의 잠재적인 버그가 프리뷰 기간을 넘어서 지속되지 않도록 합니다. 최종 릴리스 후보(Release Candidates)는 일반적으로 이러한 제한을 가지지 않습니다.

사전 안정(Pre-stable) 기능

위에 설명된 피드백 루프 원칙에 따라, 우리는 개방적으로 디자인을 반복하며 일부 기능이 사전 안정(pre-stable) 상태 중 하나를 가지며 변경될 것으로 예상되는 언어 버전을 릴리스합니다. 이러한 기능은 언제든지 경고 없이 추가, 변경 또는 제거될 수 있습니다. 우리는 의심하지 않는 사용자가 사전 안정 기능을 우연히 사용하지 않도록 최선을 다합니다. 이러한 기능은 일반적으로 코드나 프로젝트 구성에서 명시적인 옵트인(opt-in)이 필요합니다.

Kotlin 언어 기능은 다음 상태 중 하나를 가질 수 있습니다.

• 탐색 및 설계. 우리는 언어에 새로운 기능을 도입하는 것을 고려하고 있습니다. 여기에는 기존 기능과의 통합 방식 논의, 사용 사례 수집, 잠재적 영향 평가 등이 포함됩니다. 우리는 이 기능이 해결할 문제와 다룰 사용 사례에 대한 사용자 피드백이 필요합니다. 가능한 경우, 이러한 사용 사례와 문제가 얼마나 자주 발생하는지 추정하는 것도 도움이 됩니다. 일반적으로 아이디어는 YouTrack 이슈로 문서화되며, 거기서 논의가 계속됩니다.

• KEEP 논의. 우리는 이 기능이 언어에 추가되어야 한다고 상당히 확신하고 있습니다. 우리는 KEEP이라는 문서에 동기, 사용 사례, 설계 및 기타 중요한 세부 사항을 제공하는 것을 목표로 합니다. 우리는 사용자들이 KEEP에 제공된 모든 정보에 대한 논의에 집중해 주기를 기대합니다.

• 프리뷰 중. 기능 프로토타입이 준비되었으며, 기능별 컴파일러 옵션을 사용하여 활성화할 수 있습니다. 우리는 코드베이스에 얼마나 쉽게 통합되는지, 기존 코드와 어떻게 상호 작용하는지, IDE 지원 문제나 제안 사항을 포함하여 기능 사용 경험에 대한 피드백을 찾고 있습니다. 기능의 디자인은 피드백에 따라 크게 변경되거나 완전히 철회될 수 있습니다. 기능이 프리뷰 중일 때, 이는 안정성 수준을 가집니다.

• 안정. 언어 기능은 이제 Kotlin 언어에서 일급 시민입니다. 우리는 해당 기능의 하위 호환성 및 도구 지원을 보장합니다.

• 철회됨. 우리는 제안을 철회했으며, Kotlin 언어에 해당 기능을 구현하지 않을 것입니다. 프리뷰 중인 기능이 Kotlin에 적합하지 않다고 판단되면 철회할 수 있습니다.

Kotlin 언어 제안 및 상태 전체 목록 보기.

다양한 구성 요소의 상태

Kotlin/JVM, JS, Native 컴파일러 및 다양한 라이브러리와 같은 Kotlin의 다양한 구성 요소의 안정성 상태에 대해 자세히 알아보십시오.

라이브러리

언어는 생태계 없이는 아무것도 아니므로, 우리는 라이브러리의 원활한 발전을 가능하게 하는 데 특별한 주의를 기울입니다.

이상적으로는 라이브러리의 새 버전이 이전 버전의 "드롭인 대체(drop-in replacement)"로 사용될 수 있어야 합니다. 이는 바이너리 종속성을 업그레이드할 때, 애플리케이션이 다시 컴파일되지 않더라도(동적 링크 시 가능) 아무것도 깨지지 않아야 함을 의미합니다.

한편으로, 이를 달성하기 위해 컴파일러는 별도 컴파일 제약 조건 하에서 특정 애플리케이션 바이너리 인터페이스(ABI) 안정성 보장을 제공해야 합니다. 이것이 언어의 모든 변경이 바이너리 호환성 관점에서 검토되는 이유입니다.

다른 한편으로, 많은 것이 라이브러리 개발자가 어떤 변경이 안전한지 주의하는지에 달려 있습니다. 따라서 라이브러리 개발자가 소스 변경이 호환성에 어떻게 영향을 미치는지 이해하고 라이브러리의 API와 ABI를 모두 안정적으로 유지하기 위한 특정 모범 사례를 따르는 것이 중요합니다. 다음은 라이브러리 발전 관점에서 언어 변경을 고려할 때 우리가 가정하는 몇 가지 사항입니다.

• 라이브러리 코드는 항상 public/protected 함수 및 프로퍼티의 반환 타입을 명시적으로 지정해야 하며, 따라서 public API에 대한 타입 추론에 의존해서는 안 됩니다. 타입 추론의 미묘한 변경은 의도치 않게 반환 타입을 변경하여 바이너리 호환성 문제를 야기할 수 있습니다.
• 동일한 라이브러리가 제공하는 오버로드된 함수와 프로퍼티는 본질적으로 동일한 작업을 수행해야 합니다. 타입 추론의 변경은 호출 지점에서 더 정확한 정적 타입을 알 수 있게 하여 오버로드 해결의 변경을 초래할 수 있습니다.

라이브러리 개발자는 @Deprecated 및 @RequiresOptIn 어노테이션을 사용하여 API 표면의 발전을 제어할 수 있습니다. @Deprecated(level=HIDDEN)은 API에서 제거된 선언에 대해서도 바이너리 호환성을 유지하는 데 사용될 수 있습니다.

또한, 관례상 "internal"로 명명된 패키지는 공용 API로 간주되지 않습니다. "experimental"로 명명된 패키지에 있는 모든 API는 사전 안정(pre-stable)으로 간주되며 언제든지 변경될 수 있습니다.

우리는 위에서 명시된 원칙에 따라 안정적인 플랫폼을 위한 Kotlin 표준 라이브러리(kotlin-stdlib)를 발전시킵니다. 해당 API의 계약에 대한 변경 사항은 언어 자체의 변경 사항과 동일한 절차를 거칩니다.

컴파일러 옵션

컴파일러가 허용하는 명령줄 옵션 또한 일종의 공용 API이며, 동일한 고려 사항이 적용됩니다. 지원되는 옵션(“-X” 또는 “-XX” 접두사가 없는 옵션)은 언어 릴리스에서만 추가될 수 있으며, 제거되기 전에 적절하게 사용 중단(deprecated)되어야 합니다. “-X” 및 “-XX” 옵션은 실험적이며 언제든지 추가 및 제거될 수 있습니다.

호환성 도구

레거시 기능이 제거되고 버그가 수정됨에 따라 소스 언어가 변경되며, 제대로 마이그레이션되지 않은 오래된 코드는 더 이상 컴파일되지 않을 수 있습니다. 일반적인 사용 중단(deprecation) 주기는 마이그레이션을 위한 충분한 시간을 제공하며, 심지어 기간이 끝나고 변경 사항이 안정 버전에 포함된 후에도 마이그레이션되지 않은 코드를 컴파일할 수 있는 방법이 있습니다.

호환성 옵션

새 버전이 이전 버전의 동작을 에뮬레이트하여 호환성을 유지하도록 -language-version X.Y 및 -api-version X.Y 옵션을 제공합니다. 마이그레이션 시간을 더 드리기 위해, 최신 안정 버전 외에 이전 세 가지 언어 및 API 버전을 지원합니다.

활발히 유지보수되는 코드베이스는 전체 사용 중단(deprecation) 주기가 완료되기를 기다리지 않고 가능한 한 빨리 버그 수정을 받는 것이 좋습니다. 현재 이러한 프로젝트는 -progressive 옵션을 활성화하여 도구 릴리스에서도 이러한 수정 사항을 적용할 수 있습니다.

모든 옵션은 명령줄뿐만 아니라 Gradle 및 Maven에서도 사용할 수 있습니다.

바이너리 형식 발전

최악의 경우 수동으로 수정할 수 있는 소스와 달리, 바이너리는 마이그레이션하기가 훨씬 더 어렵기 때문에 바이너리 하위 호환성이 중요합니다. 바이너리에 대한 호환되지 않는 변경은 업데이트를 매우 불편하게 만들 수 있으므로 소스 언어 구문에서보다 훨씬 더 신중하게 도입되어야 합니다.

완전히 안정적인 컴파일러 버전의 경우, 기본 바이너리 호환성 프로토콜은 다음과 같습니다.

• 모든 바이너리는 하위 호환됩니다. 즉, 최신 컴파일러는 이전 바이너리(예: 1.3은 1.0 ~ 1.2를 이해함)를 읽을 수 있습니다.
• 이전 컴파일러는 새 기능에 의존하는 바이너리(예: 1.0 컴파일러는 코루틴을 사용하는 바이너리를 거부함)를 거부합니다.
• (보장할 수는 없지만) 바이너리 형식은 다음 언어 릴리스와 대부분 상위 호환되지만, 그 이후 릴리스와는 호환되지 않습니다 (새 기능이 사용되지 않는 경우, 예를 들어 1.9는 2.0의 대부분의 바이너리를 이해할 수 있지만 2.1은 이해할 수 없음).

이 프로토콜은 약간 오래된 컴파일러를 사용하더라도 프로젝트가 종속성 업데이트에 막히지 않도록 편안한 업데이트를 위해 설계되었습니다.

모든 대상 플랫폼이 이 수준의 안정성에 도달한 것은 아니지만, Kotlin/JVM은 도달했습니다.

Kotlin klib 바이너리

Kotlin klib 바이너리는 Kotlin 1.9.20에서 안정(Stable) 수준에 도달했습니다. 그러나 유의해야 할 몇 가지 호환성 세부 사항이 있습니다.

• klib 바이너리는 Kotlin 1.9.20부터 하위 호환됩니다. 예를 들어, 2.0.x 컴파일러는 1.9.2x 컴파일러에 의해 생성된 바이너리를 읽을 수 있습니다.
• 상위 호환성은 보장되지 않습니다. 예를 들어, 2.0.x 컴파일러는 2.1.x 컴파일러에 의해 생성된 바이너리를 읽을 수 있음이 보장되지 않습니다.

Kotlin cinterop klib 바이너리는 여전히 베타(Beta) 상태입니다. 현재 cinterop klib 바이너리의 서로 다른 Kotlin 버전 간의 특정 호환성 보장은 제공할 수 없습니다.