Kotlin 진화 원칙

실용적인 진화의 원칙

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

이 돌은 꽤 부드럽고,

약간의 노력을 들여 나중에 다시 모양을 바꿀 수 있습니다.

Kotlin 디자인 팀

Kotlin은 프로그래머를 위한 실용적인 도구가 되도록 설계되었습니다. 언어의 진화에 있어서, 이러한 실용적인 본질은 다음과 같은 원칙에 담겨 있습니다:

• 시간이 흘러도 언어를 현대적으로 유지합니다.
• 사용자와의 지속적인 피드백 루프를 유지합니다.
• 새 버전으로 업데이트하는 과정을 사용자에게 쉽고 편안하게 만듭니다.

이것이 Kotlin이 앞으로 나아가는 방식을 이해하는 핵심이므로, 이 원칙들을 더 자세히 살펴보겠습니다.

언어를 현대적으로 유지하기. 시스템에는 시간이 흐르면서 레거시(legacy)가 쌓인다는 점을 잘 알고 있습니다. 한때 최첨단 기술이었던 것이 오늘날에는 절망적일 정도로 구식이 될 수 있습니다. 우리는 언어를 사용자의 요구에 맞게 적절히 유지하고 사용자의 기대에 부응하도록 진화시켜야 합니다. 여기에는 새로운 기능을 추가하는 것뿐만 아니라, 더 이상 프로덕션 용도로 권장되지 않고 레거시가 된 오래된 기능들을 단계적으로 제거하는 것도 포함됩니다.

편안한 업데이트. 기능을 제거하는 것과 같은 호환되지 않는 변경 사항은 적절한 주의 없이 수행될 경우 한 버전에서 다음 버전으로 넘어가는 마이그레이션 과정을 고통스럽게 만들 수 있습니다. 우리는 항상 이러한 변경 사항을 충분히 미리 공지하고, 지원 중단 예정(deprecated)으로 표시하며, 변경이 일어나기 전에 자동 마이그레이션 도구를 제공할 것입니다. 언어가 변경될 즈음에는 전 세계 코드의 대부분이 이미 업데이트되어 새 버전으로 마이그레이션하는 데 문제가 없기를 바랍니다.

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

호환되지 않는 변경 사항

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

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

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

호환되지 않는 변경 사항이 아닌 확실한 예는 다음과 같습니다:

• 새로운 경고(warning) 추가.
• 새로운 언어 구조 활성화 또는 기존 구조의 제한 완화.
• private/internal API 및 기타 구현 세부 사항 변경.

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

이상적으로는 모든 호환되지 않는 변경 사항이 문제가 되는 코드에서 보고되는 컴파일 시점 경고(흔히 _지원 중단 경고(deprecation warning)_라고 함)를 통해 공지되어야 하며, 자동 마이그레이션 도구가 동반되어야 합니다. 따라서 이상적인 마이그레이션 워크플로우는 다음과 같습니다:

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

실제로는 일부 변경 사항을 컴파일 시점에 정확하게 감지할 수 없어 경고를 보고할 수 없는 경우도 있지만, 최소한 버전 A의 릴리스 노트를 통해 버전 B에서 변경이 예정되어 있음을 사용자에게 알릴 것입니다.

컴파일러 버그 처리하기

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

의사 결정

Kotlin의 최초 제작자인 JetBrains는 커뮤니티의 도움과 Kotlin 재단(Kotlin Foundation)과의 협력을 통해 발전을 이끌어가고 있습니다.

Kotlin 프로그래밍 언어의 모든 변경 사항은 언어 설계 리드(Lead Language Designer)(현재 Michail Zarečenskij)가 감독합니다. 설계 리드는 언어 진화와 관련된 모든 사항에 대해 최종 결정권을 가집니다. 또한, 완전히 안정된 컴포넌트에 대한 호환되지 않는 변경 사항은 Kotlin 재단 산하의 언어 위원회(Language Committee)(현재 Jeffrey van Gogh, Werner Dietl, Michail Zarečenskij로 구성)의 승인을 받아야 합니다.

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

언어 및 도구 릴리스

2.0.0과 같은 버전을 가진 안정화 릴리스는 대개 언어의 주요 변경 사항을 가져오는 _언어 릴리스(language releases)_로 간주됩니다. 보통 언어 릴리스 사이에는 x.x.20으로 번호가 매겨진 _도구 릴리스(tooling releases)_를 게시합니다.

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

언어 릴리스는 종종 새로운 기능을 추가하며, 이전에 지원 중단된 기능을 제거하거나 변경할 수 있습니다. 안정화 전 단계에서 안정 단계로의 기능 전환(graduation)도 언어 릴리스에서 발생합니다.

EAP 빌드

언어 및 도구의 안정화 버전을 릴리스하기 전에, 우리는 EAP("Early Access Preview")라고 불리는 여러 프리뷰 빌드를 게시하여 더 빠르게 반복 개선하고 커뮤니티로부터 피드백을 수집합니다. 언어 릴리스의 EAP는 대개 나중에 안정화 컴파일러에서 거부될 바이너리를 생성합니다. 이는 바이너리 형식의 잠재적인 버그가 프리뷰 기간 이후까지 살아남지 않도록 하기 위함입니다. 최종 릴리스 후보(Release Candidates)는 보통 이러한 제한이 없습니다. 자세한 내용은 Kotlin Early Access Preview 참여하기를 참조하세요.

안정화 전 기능 (Pre-stable features)

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

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

• 탐색 및 설계 (Exploration and design). 언어에 새로운 기능을 도입하는 것을 고려 중입니다. 여기에는 기존 기능과의 통합 방식 논의, 유스케이스 수집, 잠재적 영향 평가 등이 포함됩니다. 이 기능이 해결할 문제와 유스케이스에 대한 사용자의 피드백이 필요합니다. 가능하다면 이러한 유스케이스와 문제가 얼마나 자주 발생하는지 추정하는 것도 도움이 됩니다. 일반적으로 아이디어는 YouTrack 이슈로 기록되어 논의가 이어집니다.

• KEEP 토론 (KEEP discussion). 기능이 언어에 추가되어야 한다는 점이 상당히 확실합니다. 우리는 _KEEP_이라고 불리는 문서에 동기, 유스케이스, 디자인 및 기타 중요한 세부 사항을 제공하는 것을 목표로 합니다. 사용자들이 KEEP에 제공된 모든 정보를 논의하는 데 집중하여 피드백을 주기를 기대합니다.

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

• 안정 (Stable). 해당 언어 기능은 이제 Kotlin 언어의 정식 구성 요소(first-class citizen)입니다. 우리는 하위 호환성과 도구 지원 제공을 보장합니다.

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

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

다양한 컴포넌트의 상태

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

라이브러리

언어는 생태계 없이는 아무것도 아니기에, 우리는 원활한 라이브러리 진화가 가능하도록 각별한 주의를 기울입니다.

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

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

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

• 라이브러리 코드는 항상 public/protected 함수 및 프로퍼티의 반환 타입을 명시적으로 지정해야 하며, public API에 대해 타입 추론에 의존해서는 안 됩니다. 타입 추론의 미세한 변화로 인해 반환 타입이 의도치 않게 변경되어 바이너리 호환성 문제가 발생할 수 있습니다.
• 동일한 라이브러리에서 제공하는 오버로드된 함수와 프로퍼티는 본질적으로 동일한 작업을 수행해야 합니다. 타입 추론의 변화로 인해 호출 지점에서 더 정밀한 정적 타입을 알게 되어 오버로드 해소(resolution) 결과가 바뀔 수 있습니다.

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

또한 관례적으로 "internal"이라는 이름의 패키지는 public API로 간주되지 않습니다. "experimental"이라는 이름의 패키지에 있는 모든 API는 안정화 전 단계로 간주되며 언제든지 변경될 수 있습니다.

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

컴파일러 옵션

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

호환성 도구

레거시 기능이 제거되고 버그가 수정됨에 따라 소스 언어가 변경되며, 적절히 마이그레이션되지 않은 오래된 코드는 더 이상 컴파일되지 않을 수 있습니다. 일반적인 지원 중단 사이클은 마이그레이션을 위한 충분한 시간을 제공하며, 설령 그 기간이 지나고 변경 사항이 안정화 버전에 포함되더라도 마이그레이션되지 않은 코드를 컴파일할 방법은 여전히 존재합니다.

호환성 옵션

우리는 새로운 Kotlin 버전이 호환성을 목적으로 이전 버전의 동작을 에뮬레이트하도록 하는 호환성 옵션을 제공합니다:

• -language-version X.Y - Kotlin 언어 버전 X.Y에 대한 호환성 모드로, 이후에 나온 모든 언어 기능에 대해 오류를 보고합니다.
• -api-version X.Y - Kotlin API 버전 X.Y에 대한 호환성 모드로, Kotlin 표준 라이브러리의 최신 API(컴파일러가 생성한 코드 포함)를 사용하는 모든 코드에 대해 오류를 보고합니다.

마이그레이션 시간을 더 드리기 위해, 최신 안정화 버전 외에도 최소 3개 이전 언어 및 API 버전에 대한 개발을 지원합니다.

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

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

바이너리 형식의 진화

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

컴파일러의 완전한 안정화 버전에 대한 기본 바이너리 호환성 프로토콜은 다음과 같습니다:

• 모든 바이너리는 하위 호환(backwards compatible)됩니다. 즉, 최신 컴파일러는 이전 바이너리를 읽을 수 있습니다(예: 1.3은 1.0부터 1.2까지를 이해합니다).
• 이전 컴파일러는 새로운 기능에 의존하는 바이너리를 거부합니다(예: 1.0 컴파일러는 코루틴을 사용하는 바이너리를 거부합니다).
• 가급적(보장할 수는 없지만) 바이너리 형식은 다음 언어 릴리스까지는 대부분 상위 호환(forwards compatible)되지만, 그 이후 버전과는 호환되지 않습니다 (새로운 기능이 사용되지 않은 경우, 예를 들어 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 버전 간의 구체적인 호환성 보장을 제공할 수 없습니다.