Kotlin 진화 원칙
실용적 진화의 원칙
NOTE
언어 설계는 돌에 새겨져 있지만,
이 돌은 상당히 부드러워서,
약간의 노력을 통해 나중에 다시 다듬을 수 있습니다.
Kotlin 디자인 팀
Kotlin은 프로그래머를 위한 실용적인 도구로 설계되었습니다. 언어 진화에 있어서 Kotlin의 실용적인 특성은 다음 원칙들에 잘 나타나 있습니다.
시간이 지남에 따라 언어를 현대적으로 유지합니다.
사용자와 지속적인 피드백 루프를 유지합니다.
사용자에게 새 버전으로의 업데이트를 쉽고 편안하게 만듭니다.
이것이 Kotlin이 어떻게 발전하고 있는지 이해하는 데 중요하므로, 이 원칙들을 자세히 살펴보겠습니다.
언어를 현대적으로 유지하기. 우리는 시스템이 시간이 지남에 따라 레거시를 축적한다는 것을 인식합니다. 한때 최첨단 기술이었던 것이 오늘날에는 절망적으로 구식이 될 수 있습니다. 우리는 사용자들의 요구에 부합하고 그들의 기대에 발맞추어 언어를 발전시켜야 합니다. 여기에는 새로운 기능을 추가하는 것뿐만 아니라, 더 이상 프로덕션 사용에 권장되지 않고 레거시가 된 오래된 기능들을 단계적으로 폐기하는 것도 포함됩니다.
편안한 업데이트. 언어에서 항목을 제거하는 것과 같은 호환되지 않는 변경은 적절한 주의 없이 수행될 경우 한 버전에서 다음 버전으로의 고통스러운 마이그레이션으로 이어질 수 있습니다. 우리는 항상 그러한 변경 사항을 미리 충분히 발표하고, 항목을 deprecated(사용 중단 예정)로 표시하며, 변경이 발생하기 전에 자동 마이그레이션 도구를 제공할 것입니다. 언어가 변경될 때쯤에는 전 세계 대부분의 코드가 이미 업데이트되어 새 버전으로 마이그레이션하는 데 문제가 없기를 바랍니다.
피드백 루프. 사용 중단 주기(deprecation cycles)를 거치는 것은 상당한 노력을 필요로 하므로, 우리는 미래에 만들 호환되지 않는 변경의 수를 최소화하고자 합니다. 우리의 최선의 판단 외에도, 실제 환경에서 시도해 보는 것이 디자인을 검증하는 가장 좋은 방법이라고 믿습니다. 최종 결정하기 전에 실전에서 검증되기를 원합니다. 이것이 바로 우리가 디자인의 초기 버전을 언어의 프로덕션 버전에서 제공하되, 사전 안정(pre-stable) 상태 중 하나인 Experimental, Alpha, 또는 Beta로 제공하는 모든 기회를 활용하는 이유입니다. 이러한 기능들은 안정적이지 않으며 언제든지 변경될 수 있습니다. 이 기능을 사용하기로 선택하는 사용자들은 향후 마이그레이션 문제에 대처할 준비가 되어 있음을 명시적으로 나타내기 위해 그렇게 합니다. 이 사용자들은 우리가 디자인을 반복하고 견고하게 만드는 데 필요한 귀중한 피드백을 제공합니다.
호환되지 않는 변경
한 버전에서 다른 버전으로 업데이트할 때, 이전에 작동하던 일부 코드가 더 이상 작동하지 않는다면, 이는 언어의 호환되지 않는 변경(때로는 "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) 기능은 언제든지 추가, 제거 또는 변경될 수 있습니다.
언어 릴리스는 종종 새로운 기능을 추가하고 이전에 사용 중단된 기능을 제거하거나 변경할 수 있습니다. 사전 안정(pre-stable) 기능이 안정(stable) 단계로 승격되는 것도 언어 릴리스에서 발생합니다.
EAP 빌드
언어 및 도구 릴리스의 안정적인 버전을 출시하기 전에, 우리는 더 빠르게 반복하고 커뮤니티로부터 피드백을 수집할 수 있도록 EAP ("Early Access Preview")라고 불리는 여러 미리 보기 빌드를 게시합니다. 언어 릴리스의 EAP는 일반적으로 안정적인 컴파일러에 의해 나중에 거부될 바이너리를 생성합니다. 이는 바이너리 형식의 가능한 버그가 미리 보기 기간을 넘어서 존재하지 않도록 보장하기 위함입니다. 최종 릴리스 후보(Release Candidates)는 일반적으로 이러한 제한을 가지지 않습니다.
사전 안정(pre-stable) 기능
위에 설명된 피드백 루프 원칙에 따라, 우리는 공개적으로 디자인을 반복하고 일부 기능이 사전 안정(pre-stable) 상태 중 하나를 가지며 _변경될 예정_인 언어 버전을 출시합니다. 이러한 기능은 언제든지 예고 없이 추가, 변경 또는 제거될 수 있습니다. 우리는 의도치 않은 사용자가 사전 안정 기능을 실수로 사용하지 않도록 최선을 다합니다. 이러한 기능은 일반적으로 코드나 프로젝트 구성에서 명시적인 옵트인(opt-in)이 필요합니다.
Kotlin 언어 기능은 다음 상태 중 하나를 가질 수 있습니다.
탐색 및 설계. 우리는 언어에 새로운 기능을 도입하는 것을 고려하고 있습니다.
여기에는 기존 기능과의 통합 방법 논의, 사용 사례 수집, 잠재적 영향 평가가 포함됩니다.
이 기능이 해결할 문제와 다룰 사용 사례에 대한 사용자 피드백이 필요합니다.
가능할 때마다 이러한 사용 사례와 문제가 얼마나 자주 발생하는지 추정하는 것도 도움이 될 것입니다.
일반적으로 아이디어는 YouTrack 이슈로 문서화되며, 그곳에서 논의가 계속됩니다.
KEEP 논의. 우리는 이 기능이 언어에 추가되어야 한다고 상당히 확신하고 있습니다.
우리는 _KEEP_이라는 문서에 동기, 사용 사례, 디자인 및 기타 중요한 세부 사항을 제공하는 것을 목표로 합니다.
우리는 사용자들이 KEEP에 제공된 모든 정보를 논의하는 데 초점을 맞춰 피드백을 제공하기를 기대합니다.
미리 보기 중. 기능 프로토타입이 준비되었으며, 기능별 컴파일러 옵션을 사용하여 활성화할 수 있습니다.
우리는 기능이 코드베이스에 얼마나 쉽게 통합되는지, 기존 코드와 어떻게 상호 작용하는지, 그리고 IDE 지원 문제 또는 제안을 포함하여 기능 사용 경험에 대한 피드백을 구합니다.
기능의 디자인은 크게 변경될 수 있으며, 피드백에 따라 완전히 철회될 수도 있습니다. 기능이 _미리 보기 중_일 때, 안정성 수준을 가집니다.
안정. 이 언어 기능은 이제 Kotlin 언어에서 일급 시민입니다.
우리는 그것의 하위 호환성을 보장하며 도구 지원을 제공할 것입니다.
철회됨. 우리는 제안을 철회했으며 Kotlin 언어에서 이 기능을 구현하지 않을 것입니다.
미리 보기 중인 기능이 Kotlin에 적합하지 않다고 판단되면 철회할 수 있습니다.
다른 구성 요소의 상태
Kotlin/JVM, JS, Native 컴파일러 및 다양한 라이브러리와 같은 Kotlin의 다른 구성 요소의 안정성 상태에 대해 자세히 알아보세요.
라이브러리
언어는 그 생태계 없이는 아무것도 아니므로, 우리는 원활한 라이브러리 진화를 가능하게 하는 데 특별한 주의를 기울입니다.
이상적으로는 새 버전의 라이브러리가 이전 버전의 "드롭인 대체(drop-in replacement)"로 사용될 수 있습니다. 이는 애플리케이션이 다시 컴파일되지 않더라도 (동적 링크 시 가능함) 바이너리 종속성을 업그레이드하는 것이 아무것도 깨뜨리지 않아야 함을 의미합니다.
한편으로, 이를 달성하기 위해 컴파일러는 분리 컴파일(separate compilation) 제약 하에 특정 애플리케이션 바이너리 인터페이스(ABI) 안정성 보장을 제공해야 합니다. 이것이 바로 언어의 모든 변경이 바이너리 호환성 관점에서 검토되는 이유입니다.
다른 한편으로는, 많은 부분이 라이브러리 작성자가 어떤 변경이 안전한지 신중하게 결정하는 데 달려 있습니다. 따라서 라이브러리 작성자가 소스 변경이 호환성에 어떻게 영향을 미치는지 이해하고, 라이브러리의 API와 ABI를 모두 안정적으로 유지하기 위해 특정 모범 사례를 따르는 것이 중요합니다. 다음은 라이브러리 진화 관점에서 언어 변경을 고려할 때 우리가 가정하는 몇 가지 사항입니다.
라이브러리 코드는 항상 public/protected 함수 및 속성의 반환 타입을 명시적으로 지정해야 하며, 따라서 public API에 대해 타입 추론에 의존해서는 안 됩니다.
타입 추론의 미묘한 변경은 의도치 않게 반환 타입을 변경하여 바이너리 호환성 문제를 야기할 수 있습니다.
동일한 라이브러리에서 제공하는 오버로드된 함수와 속성은 본질적으로 동일한 작업을 수행해야 합니다.
타입 추론의 변경은 호출 사이트에서 더 정확한 정적 타입을 알게 하여 오버로드 해결(overload resolution)에 변경을 초래할 수 있습니다.
라이브러리 작성자는 API 표면의 진화를 제어하기 위해 @Deprecated 및 @RequiresOptIn 어노테이션을 사용할 수 있습니다. @Deprecated(level=HIDDEN)는 API에서 제거된 선언에 대해서도 바이너리 호환성을 유지하는 데 사용될 수 있습니다.
또한, 관례적으로 "internal"이라는 이름의 패키지는 public API로 간주되지 않습니다. "experimental"이라는 이름의 패키지에 있는 모든 API는 사전 안정(pre-stable)으로 간주되며 언제든지 변경될 수 있습니다.
우리는 위에 명시된 원칙에 따라 안정적인 플랫폼을 위한 Kotlin 표준 라이브러리(kotlin-stdlib)를 발전시킵니다. API 계약에 대한 변경 사항은 언어 자체의 변경 사항과 동일한 절차를 거칩니다.
컴파일러 옵션
컴파일러가 허용하는 명령줄 옵션도 일종의 public API이며, 동일한 고려 사항이 적용됩니다. 지원되는 옵션(-X 또는 -XX 접두사가 없는 옵션)은 언어 릴리스에서만 추가될 수 있으며, 제거하기 전에 적절히 사용 중단되어야 합니다. "-X" 및 "-XX" 옵션은 실험적이며 언제든지 추가 및 제거될 수 있습니다.
호환성 도구
레거시 기능이 제거되고 버그가 수정됨에 따라 소스 언어가 변경되며, 제대로 마이그레이션되지 않은 오래된 코드는 더 이상 컴파일되지 않을 수 있습니다. 정상적인 사용 중단 주기(deprecation cycle)는 마이그레이션을 위한 충분한 시간을 제공하며, 이 주기가 끝나고 변경 사항이 안정적인 버전으로 출시된 후에도 마이그레이션되지 않은 코드를 컴파일할 방법이 여전히 존재합니다.
호환성 옵션
우리는 호환성을 위해 새 버전이 이전 버전의 동작을 에뮬레이트하도록 하는 -language-version X.Y 및 -api-version X.Y 옵션을 제공합니다. 마이그레이션 시간을 더 드리기 위해, 우리는 최신 안정 버전 외에 이전 세 가지 언어 및 API 버전을 지원합니다.
활발하게 유지 관리되는 코드베이스는 전체 사용 중단 주기가 완료될 때까지 기다리지 않고 가능한 한 빨리 버그 수정을 받는 이점을 누릴 수 있습니다. 현재 이러한 프로젝트는 -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 버전 간의 특정 호환성 보장을 제공할 수 없습니다.