본문으로 건너뛰기

Kotlin 진화 원칙

실용적인 진화 원칙​

노트

언어 디자인은 돌에 새겨져 있지만,

이 돌은 비교적 부드럽고,

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

Kotlin Design Team

Kotlin은 프로그래머를 위한 실용적인 도구로 설계되었습니다. 언어 진화에 있어서, 그 실용적인 본질은 다음 원칙에 의해 포착됩니다.

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

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

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

편안한 업데이트. 언어에서 항목을 제거하는 것과 같은 호환되지 않는 변경 사항은 적절한 주의 없이 수행될 경우 한 버전에서 다음 버전으로의 고통스러운 마이그레이션으로 이어질 수 있습니다. 우리는 항상 이러한 변경 사항을 미리 발표하고, 변경 사항이 발생하기 전에 항목을 더 이상 사용되지 않는 것으로 표시하고 자동화된 마이그레이션 도구를 제공할 것입니다. 언어가 변경될 때까지 우리는 전 세계 코드의 대부분이 이미 업데이트되어 새 버전으로 마이그레이션하는 데 문제가 없기를 바랍니다.

피드백 루프. 더 이상 사용되지 않는 주기를 거치는 데는 상당한 노력이 필요하므로 앞으로 만들 호환되지 않는 변경 사항의 수를 최소화하려고 합니다. 최선의 판단을 사용하는 것 외에도, 실제로 시험해 보는 것이 디자인을 검증하는 가장 좋은 방법이라고 생각합니다. 돌에 새기기 전에 실전에서 검증되기를 바랍니다. 이것이 우리가 디자인의 초기 버전을 언어의 프로덕션 버전에서 사용할 수 있도록 모든 기회를 활용하는 이유이지만, Experimental, Alpha 또는 Beta와 같은 pre-stable 상태 중 하나입니다. 이러한 기능은 안정적이지 않으며 언제든지 변경될 수 있으며, 이를 사용하기로 선택한 사용자는 향후 마이그레이션 문제를 처리할 준비가 되었음을 명시적으로 나타내기 위해 그렇게 합니다. 이러한 사용자는 우리가 디자인을 반복하고 견고하게 만드는 데 수집하는 귀중한 피드백을 제공합니다.

호환되지 않는 변경 사항​

한 버전에서 다른 버전으로 업데이트할 때, 이전에는 작동했던 일부 코드가 더 이상 작동하지 않는다면, 이는 언어의 호환되지 않는 변경 사항 입니다(때로는 "호환성이 깨지는 변경 사항"이라고도 함). 어떤 경우에는 "더 이상 작동하지 않는다"는 것이 정확히 무엇을 의미하는지에 대한 논쟁이 있을 수 있지만, 다음 사항이 확실히 포함됩니다.

  • 이전에 컴파일되고 잘 실행되던 코드가 이제 오류와 함께 거부됩니다(컴파일 또는 링크 시간). 여기에는 언어 구문을 제거하고 새로운 제한 사항을 추가하는 것이 포함됩니다.
  • 정상적으로 실행되던 코드가 이제 예외를 발생시킵니다.

"회색 영역"에 속하는 덜 명확한 경우는 코너 케이스를 다르게 처리하거나, 이전과는 다른 유형의 예외를 발생시키거나, 리플렉션을 통해서만 관찰할 수 있는 동작을 변경하거나, 문서화되지 않았거나 정의되지 않은 동작을 수정하거나, 바이너리 아티팩트의 이름을 바꾸는 것 등이 있습니다. 때로는 이러한 변경 사항이 매우 중요하고 마이그레이션 경험에 큰 영향을 미치기도 하고, 때로는 미미하기도 합니다.

호환되지 않는 변경 사항이 아닌 것의 몇 가지 예는 다음과 같습니다.

  • 새로운 경고를 추가합니다.
  • 새로운 언어 구문을 활성화하거나 기존 구문에 대한 제한을 완화합니다.
  • private/internal API 및 기타 구현 세부 정보를 변경합니다.

언어의 현대성을 유지하고 편안한 업데이트를 제공한다는 원칙은 호환되지 않는 변경 사항이 때로는 필요하지만 주의해서 도입해야 함을 시사합니다. 우리의 목표는 사용자가 코드를 편안하게 마이그레이션할 수 있도록 예정된 변경 사항을 미리 알리는 것입니다.

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

  • 버전 A로 업데이트합니다(변경 사항이 발표된 버전).
    • 예정된 변경 사항에 대한 경고를 확인합니다.
    • 도움말 도구를 사용하여 코드를 마이그레이션합니다.
  • 버전 B로 업데이트합니다(변경 사항이 발생한 버전).
    • 아무런 문제가 없습니다.

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

컴파일러 버그 처리​

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

의사 결정​

Kotlin의 최초 제작자인 JetBrains는 커뮤니티의 도움과 Kotlin Foundation과의 협력을 통해 진행 상황을 주도하고 있습니다.

Kotlin 프로그래밍 언어에 대한 모든 변경 사항은 Lead Language Designer(현재 Michail Zarečenskij)가 감독합니다. Lead Designer는 언어 진화와 관련된 모든 문제에 대해 최종 결정권을 가집니다. 또한 완전히 안정적인 구성 요소에 대한 호환되지 않는 변경 사항은 Kotlin Foundation에 따라 지정된 Language Committee(현재 Jeffrey van Gogh, Werner Dietl 및 Michail Zarečenskij로 구성됨)의 승인을 받아야 합니다.

Language Committee는 어떤 호환되지 않는 변경 사항을 만들지, 그리고 사용자 업데이트를 최대한 원활하게 만들기 위해 어떤 정확한 조치를 취해야 하는지에 대해 최종 결정을 내립니다. 그렇게 할 때, Language committee guidelines를 기반으로 합니다.

언어 및 툴링 릴리스​

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

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

언어 릴리스는 종종 새로운 기능을 추가하고 이전에 더 이상 사용되지 않는 기능을 제거하거나 변경할 수 있습니다. 사전 안정화에서 안정화로의 기능 졸업도 언어 릴리스에서 발생합니다.

EAP 빌드​

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

사전 안정화 기능​

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

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

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

  • KEEP 토론. 우리는 해당 기능이 언어에 추가되어야 한다고 확신합니다. _KEEP_이라는 문서에서 동기, 사용 사례, 디자인 및 기타 중요한 세부 정보를 제공하는 것을 목표로 합니다. 사용자의 피드백이 KEEP에서 제공하는 모든 정보를 논의하는 데 집중되기를 기대합니다.

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

  • 안정적. 언어 기능은 이제 Kotlin 언어에서 일류 시민입니다. 우리는 이전 버전과의 호환성을 보장하고 툴링 지원을 제공할 것입니다.

  • 취소됨. 우리는 제안을 취소했으며 Kotlin 언어에서 해당 기능을 구현하지 않을 것입니다. Kotlin에 적합하지 않은 경우 _프리뷰 중_인 기능을 취소할 수 있습니다.

Kotlin 언어 제안 및 해당 상태의 전체 목록을 참조하십시오.

다양한 구성 요소의 상태​

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

라이브러리​

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

이상적으로 라이브러리의 새 버전은 이전 버전에 대한 "드롭인 대체"로 사용할 수 있습니다. 즉, 애플리케이션이 다시 컴파일되지 않더라도(동적 링킹 하에서 가능) 바이너리 종속성을 업그레이드하면 아무것도 깨지지 않아야 합니다.

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

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

  • 라이브러리 코드는 항상 public/protected 함수 및 속성의 반환 유형을 명시적으로 지정해야 합니다. 따라서 public API에 대한 유형 추론에 의존하지 마십시오. 유형 추론의 미묘한 변경으로 인해 반환 유형이 부주의하게 변경되어 바이너리 호환성 문제가 발생할 수 있습니다.
  • 동일한 라이브러리에서 제공하는 오버로드된 함수 및 속성은 기본적으로 동일한 작업을 수행해야 합니다. 유형 추론의 변경으로 인해 호출 사이트에서 더 정확한 정적 유형을 알 수 있게 되어 오버로드 해결에 변경이 발생할 수 있습니다.

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

또한 규칙에 따라 "internal"이라는 이름의 패키지는 공용 API로 간주되지 않습니다. "experimental"이라는 이름의 패키지에 있는 모든 API는 사전 안정화된 것으로 간주되며 언제든지 변경될 수 있습니다.

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

컴파일러 옵션​

컴파일러에서 허용하는 명령줄 옵션도 일종의 공용 API이며 동일한 고려 사항이 적용됩니다. 지원되는 옵션("-X" 또는 "-XX" 접두사가 없는 옵션)은 언어 릴리스에서만 추가할 수 있으며 제거하기 전에 적절하게 더 이상 사용되지 않는 것으로 표시해야 합니다. "-X" 및 "-XX" 옵션은 실험적이며 언제든지 추가 및 제거할 수 있습니다.

호환성 도구​

레거시 기능이 제거되고 버그가 수정됨에 따라 소스 언어가 변경되고 제대로 마이그레이션되지 않은 이전 코드는 더 이상 컴파일되지 않을 수 있습니다. 일반적인 더 이상 사용되지 않는 주기는 마이그레이션을 위한 편안한 기간을 허용하며 종료되고 변경 사항이 안정적인 버전으로 제공되더라도 마이그레이션되지 않은 코드를 컴파일하는 방법이 여전히 있습니다.

호환성 옵션​

호환성을 위해 새 버전이 이전 버전의 동작을 에뮬레이트하도록 하는 -language-version X.Y 및 -api-version X.Y 옵션을 제공합니다. 마이그레이션 시간을 더 많이 제공하기 위해 최신 안정 버전 외에 이전 3개의 언어 및 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에서 안정 수준에 도달했습니다. 그러나 몇 가지 호환성 세부 정보를 염두에 두어야 합니다.

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

Kotlin cinterop klib 바이너리는 여전히 베타 상태입니다. 현재 cinterop klib 바이너리에 대한 다양한 Kotlin 버전 간의 특정 호환성 보장을 제공할 수 없습니다.