[Kotlin 번역] Kotlin evolution principles

실용적인 진화의 원칙

 

프로그래밍 언어의 설계는 돌에 새겨진 것과 같지만, 이 돌은 비교적 부드러워서 어느 정도 노력하면 나중에 다시 형태를 바꿀 수 있습니다.

- Kotlin 디자인 팀

 

Kotlin은 프로그래머를 위한 실용적인 도구로 설계되었습니다. 언어의 발전에 있어, Kotlin의 실용적 성격은 다음 원칙들로 요약될 수 있습니다:

 

1. 언어를 지속적으로 현대적으로 유지하기

2. 사용자와의 지속적인 피드백 루프 유지하기

3. 새로운 버전으로의 업데이트를 사용자에게 쉽고 편리하게 제공하기

 

Kotlin의 발전 방향을 이해하는 데 있어 이 원칙들은 핵심적이며, 이를 더 자세히 설명하면 다음과 같습니다.

 

1. 언어를 현대적으로 유지하기

 

시스템은 시간이 지남에 따라 레거시가 축적됩니다. 한때 최첨단 기술이었던 것이 오늘날에는 완전히 구식이 될 수 있습니다. 우리는 언어를 사용자들의 필요와 기대에 맞게 발전시켜야 하며, 이를 위해 새로운 기능을 추가하는 것뿐만 아니라 더 이상 권장되지 않는 오래된 기능을 점진적으로 제거해야 합니다. 이러한 기능들은 점차 레거시로 간주되며, 더 이상 프로덕션 환경에서 사용되지 않도록 유도해야 합니다.

 

2. 편리한 업데이트 제공하기

 

언어에서 무언가를 제거하는 것과 같은 호환되지 않는 변경 사항은 적절한 준비 없이 진행된다면 버전 간의 전환 과정에서 큰 고통을 초래할 수 있습니다. 우리는 항상 이러한 변경 사항을 사전에 충분히 공지하며, 먼저 해당 기능을 deprecated(사용 중단) 상태로 표시하고, 변경 전에 자동 마이그레이션 도구를 제공합니다. 언어 변경이 실제로 적용될 때쯤에는 이미 대부분의 코드가 업데이트되어 문제가 없도록 하는 것이 목표입니다.

 

3. 피드백 루프 유지하기

 

사용 중단 절차를 거치는 것은 많은 노력이 필요하므로, 미래에 호환되지 않는 변경을 최소화하려고 합니다. 우리의 최선의 판단을 사용하는 것 외에도, 실제 환경에서 직접 시도해 보는 것이 디자인을 검증하는 가장 좋은 방법이라고 믿습니다. 한 가지를 확정 짓기 전에 충분히 실전 테스트를 거치기를 원합니다.

 

이를 위해 Experimental(실험적), Alpha(알파), Beta(베타) 상태로 사전 안정화된 상태의 설계를 언어의 프로덕션 버전에 포함시킬 기회를 최대한 활용합니다. 이러한 기능은 안정적이지 않으며 언제든지 변경될 수 있습니다. 이를 사용하는 사용자들은 미래의 마이그레이션 문제를 기꺼이 수용하겠다는 의사를 명시적으로 밝히고 사용합니다. 이 사용자들이 제공하는 소중한 피드백을 수집해 설계를 반복적으로 개선하고 완성도 높은 결과를 만들어 냅니다.

 

호환되지 않는 변경

 

버전을 업데이트할 때, 이전에 잘 작동하던 코드가 더 이상 작동하지 않게 되는 경우, 이는 언어에서의 호환되지 않는 변경(종종 “브레이킹 변경”이라고도 함)입니다. “더 이상 작동하지 않는다”는 정확히 무엇을 의미하는지는 경우에 따라 논쟁의 여지가 있을 수 있지만, 다음과 같은 경우는 확실히 포함됩니다:

• 컴파일되거나 실행되던 코드가 이제 에러를 발생시키는 경우 (컴파일 시간 또는 링크 시간에). 여기에는 언어 구조를 제거하거나 새로운 제한 사항을 추가하는 것이 포함됩니다.

• 정상적으로 실행되던 코드가 이제 예외를 발생시키는 경우.

 

“회색 영역”에 해당하는 덜 명확한 사례로는 다음이 포함될 수 있습니다:

• 코너 케이스를 다루는 방식이 변경된 경우

• 이전과 다른 유형의 예외를 발생시키는 경우

• 리플렉션을 통해서만 관찰 가능한 동작이 변경된 경우

• 문서화되지 않았거나 정의되지 않은 동작이 수정된 경우

• 바이너리 아티팩트의 이름이 변경된 경우 등

 

이러한 변경 사항은 때로는 마이그레이션 경험에 큰 영향을 미치기도 하고, 때로는 중요하지 않을 수도 있습니다.

 

호환되지 않는 변경 사항이 아닌 것으로 확실히 간주되는 예는 다음과 같습니다:

 

• 새로운 경고를 추가하는 것.

• 새로운 언어 구조를 활성화하거나 기존 구조에 대한 제한을 완화하는 것.

• private/internal API 및 기타 구현 세부 사항을 변경하는 것.

 

호환되지 않는 변경 사항의 관리

 

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

 

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

 

1. 버전 A로 업데이트 (변경 사항이 공지됨)

2. 변경 사항에 대한 경고 확인

3. 도구를 사용해 코드 마이그레이션

4. 버전 B로 업데이트 (변경 사항이 적용됨)

5. 문제 없이 작동 확인

 

실제로는 컴파일 시간에 정확히 감지할 수 없는 변경 사항도 있습니다. 이러한 경우 경고를 제공할 수는 없지만, 최소한 사용자들에게 버전 A 릴리스 노트를 통해 버전 B에서 변경 사항이 발생한다는 점을 알릴 것입니다.

 

컴파일러 버그 처리

 

컴파일러는 복잡한 소프트웨어로, 개발자의 최선의 노력에도 불구하고 버그가 발생할 수 있습니다. 컴파일러 자체가 실패하거나 잘못된 에러를 보고하거나 명백히 실패하는 코드를 생성하는 버그는, 번거롭고 종종 난감하지만, 쉽게 수정할 수 있습니다. 이러한 수정은 호환되지 않는 변경을 구성하지 않기 때문입니다.

 

다른 유형의 버그는 컴파일러가 실패하지 않고 잘못된 코드를 생성하게 만들 수 있습니다. 예를 들어, 소스 코드의 오류를 놓치거나 잘못된 명령어를 생성하는 경우입니다. 이러한 버그의 수정은 기술적으로 호환되지 않는 변경(이전에는 컴파일되던 코드가 이제 더 이상 컴파일되지 않음)을 초래하지만, 이러한 패턴이 사용자 코드에 확산되는 것을 막기 위해 가능한 빨리 수정하려 합니다. 이는 더 적은 사용자가 해당 문제에 직면하게 하므로, 편리한 업데이트 제공하기 원칙을 지지한다고 봅니다. 물론, 이는 릴리스된 버전에서 나타난 지 얼마 되지 않은 버그에만 해당됩니다.

 

의사 결정

 

JetBrains는 Kotlin의 원작자로서 커뮤니티와 Kotlin 재단의 협력을 통해 Kotlin의 발전을 주도하고 있습니다.

 

Kotlin 프로그래밍 언어의 모든 변경 사항은 **수석 언어 설계자(현재 Michail Zarečenskij)**의 감독 아래 이루어집니다. 수석 설계자는 언어 발전과 관련된 모든 사항에 대해 최종 결정 권한을 갖습니다. 또한, 완전히 안정된 컴포넌트에 대한 호환되지 않는 변경 사항은 Kotlin 재단에서 지정한 언어 위원회의 승인을 받아야 합니다(현재 위원은 Jeffrey van Gogh, Werner Dietl, Michail Zarečenskij로 구성).

 

언어 위원회는 어떤 호환되지 않는 변경 사항을 적용할지와 사용자 업데이트를 최대한 원활하게 만들기 위한 구체적인 조치를 최종 결정합니다. 이 과정에서 언어 위원회는 언어 위원회 가이드라인을 준수합니다.

 

언어와 도구 릴리스

 

버전 번호(예: 2.0.0)가 있는 안정 릴리스는 보통 언어 릴리스로 간주되며, 언어에 주요 변경 사항을 가져옵니다. 일반적으로, 언어 릴리스 사이에는 x.x.20 형식으로 번호가 매겨진 도구 릴리스를 발행합니다.

 

도구 릴리스

 

도구 릴리스는 도구의 업데이트(종종 새로운 기능 포함), 성능 향상, 버그 수정을 제공합니다. 이러한 버전 간의 호환성을 유지하려고 노력하기 때문에, 컴파일러의 변경 사항은 주로 최적화와 경고 추가/제거로 제한됩니다. 안정화 이전의 기능들은 언제든지 추가되거나 제거되거나 변경될 수 있습니다.

 

언어 릴리스

 

언어 릴리스는 종종 새로운 기능을 추가하며, 이전에 사용 중단(deprecated)으로 지정된 기능을 제거하거나 변경할 수 있습니다. 사전 안정화(pre-stable) 상태에서 안정화된 상태로 기능이 승격되는 경우도 언어 릴리스에서 이루어집니다.

 

EAP 빌드

 

언어 및 도구 릴리스의 안정 버전을 발행하기 전에, **EAP(Early Access Preview)**라고 불리는 여러 프리뷰 빌드를 제공합니다. 이를 통해 빠른 반복 작업과 커뮤니티 피드백 수집이 가능합니다.

언어 릴리스의 EAP는 종종 안정화된 컴파일러에서 거부될 바이너리를 생성합니다. 이는 바이너리 형식에서 발생할 수 있는 잠재적 버그가 프리뷰 기간을 넘어서지 않도록 보장하기 위한 조치입니다. 그러나 최종 릴리스 후보(Final Release Candidates)에서는 이러한 제한이 적용되지 않는 것이 일반적입니다.

 

사전 안정화 기능

 

위에서 설명한 피드백 루프 원칙에 따라, 우리는 설계를 공개적으로 반복하며, 일부 기능이 사전 안정화 상태에 있는 언어 버전을 릴리스합니다. 이러한 기능은 변경되거나 제거될 수 있으며, 사전 공지 없이도 가능합니다. 우리는 의도치 않게 이러한 기능이 사용되지 않도록 최선을 다합니다. 이러한 기능은 일반적으로 코드나 프로젝트 설정에서 명시적인 선택(opt-in)을 요구합니다.

 

Kotlin 언어 기능 상태

 

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

 

1. 탐색 및 설계(Exploration and design)

 

새로운 기능을 언어에 도입하는 것을 고려 중인 상태입니다. 기존 기능과의 통합, 사용 사례 수집, 잠재적 영향을 평가하며, 이 기능이 해결할 문제와 관련된 피드백을 요청합니다. 가능한 경우, 이러한 문제와 사용 사례가 얼마나 자주 발생하는지에 대한 추정도 포함됩니다. 아이디어는 일반적으로 YouTrack 이슈로 문서화되어 논의가 이어집니다.

 

2. KEEP 논의(KEEP discussion)

 

해당 기능을 언어에 추가해야 한다는 확신이 든 상태입니다. 동기, 사용 사례, 설계 및 기타 중요한 세부 사항을 포함한 문서(KEEP)를 제공하며, 사용자 피드백은 이 문서의 내용을 바탕으로 논의하는 데 중점을 둡니다.

 

3. 프리뷰(In preview)

 

기능 프로토타입이 준비되어 있으며, 특정 컴파일러 옵션을 사용해 활성화할 수 있습니다. 사용자가 해당 기능을 코드베이스에 통합하거나 기존 코드와 상호 작용하는 경험, IDE 지원 문제 등에 대한 피드백을 요청합니다. 피드백에 따라 기능 설계가 크게 변경되거나 완전히 철회될 수 있습니다.

 

4. 안정화(Stable)

 

기능이 Kotlin 언어의 정식 기능이 된 상태입니다. 이 기능의 역호환성이 보장되며, 도구 지원도 제공됩니다.

 

5. 철회(Revoked)

 

제안이 철회되었으며, Kotlin 언어에서 구현되지 않을 것입니다. 프리뷰 상태의 기능도 Kotlin에 적합하지 않다고 판단되면 철회될 수 있습니다.

 

Kotlin 언어 제안 및 상태 전체 목록을 확인할 수 있습니다.

 

다양한 컴포넌트의 상태

 

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

 

라이브러리

 

언어는 생태계 없이는 아무것도 아니기 때문에, 우리는 라이브러리의 원활한 발전을 위해 각별히 주의를 기울입니다.

 

이상적으로는, 새로운 버전의 라이브러리가 이전 버전의 “drop-in replacement”로 사용될 수 있어야 합니다. 즉, 이진 종속성을 업그레이드하더라도 애플리케이션을 다시 컴파일하지 않고도 아무 문제가 없어야 합니다(이는 동적 링크(dynamic linking) 하에서 가능합니다).

 

이 목표를 달성하기 위해 필요한 두 가지 측면

 

1. 컴파일러의 안정성 보장

 

컴파일러는 별도 컴파일(separate compilation)의 제약 조건 아래 응용 프로그램 이진 인터페이스(ABI) 안정성을 보장해야 합니다. 따라서 언어의 모든 변경 사항은 이진 호환성 관점에서 검토됩니다.

 

2. 라이브러리 작성자의 주의

 

라이브러리 작성자는 어떤 변경이 안전한지 신중히 판단해야 합니다. 이를 위해 작성자가 소스 변경이 호환성에 미치는 영향을 이해하고, API와 ABI의 안정성을 유지하기 위한 모범 사례를 따라야 합니다.

 

라이브러리 발전 관점에서 언어 변경을 고려할 때의 가정

 

• 공개/보호(public/protected) 함수와 속성의 반환 타입 명시

 

라이브러리 코드에서는 공개 API에 대해 반환 타입을 명시적으로 지정해야 하며, 타입 추론(type inference)에 의존하지 않아야 합니다. 타입 추론의 미묘한 변화로 인해 반환 타입이 의도치 않게 변경되면 이진 호환성 문제가 발생할 수 있습니다.

 

• 오버로드된 함수 및 속성의 일관성

 

동일한 라이브러리가 제공하는 오버로드된 함수와 속성은 본질적으로 동일한 작업을 수행해야 합니다. 타입 추론의 변화로 호출 지점에서 더 정확한 정적 타입이 알려지면, 오버로드 해석이 달라질 수 있습니다.

 

• @Deprecated와 @RequiresOptIn 주석 사용

 

라이브러리 작성자는 API 표면의 진화를 제어하기 위해 이러한 주석을 사용할 수 있습니다. 특히 @Deprecated(level=HIDDEN) 주석은 API에서 제거된 선언이라도 이진 호환성을 유지할 수 있도록 해줍니다.

 

• 특정 패키지에 대한 관례

- 이름이 “internal”인 패키지는 공개 API로 간주되지 않습니다.

- 이름이 “experimental”인 패키지에 속한 모든 API는 사전 안정화(pre-stable) 상태로 간주되며, 언제든지 변경될 수 있습니다.

 

Kotlin 표준 라이브러리(kotlin-stdlib)의 발전

 

우리는 위에 언급된 원칙에 따라 안정된 플랫폼용 Kotlin 표준 라이브러리를 발전시킵니다. API 계약의 변경은 언어 변경과 동일한 절차를 거쳐 신중히 처리됩니다.

 

컴파일러 옵션

 

컴파일러가 수용하는 명령줄 옵션도 일종의 공개 API로 간주되며, 동일한 기준이 적용됩니다.

 

• 지원되는 옵션

 

“-X” 또는 “-XX” 접두사가 없는 지원 옵션은 언어 릴리스에서만 추가할 수 있으며, 제거 전에 반드시 적절히 사용 중단(deprecation) 절차를 거쳐야 합니다.

 

• 실험적 옵션

 

“-X” 및 “-XX”로 시작하는 옵션은 실험적이므로 언제든지 추가되거나 제거될 수 있습니다.

 

호환성 도구

 

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

 

호환성 옵션

 

• -language-version X.Y 및 -api-version X.Y 옵션을 제공하여 새로운 버전에서 이전 버전의 동작을 에뮬레이트할 수 있습니다.

이를 통해 마이그레이션 시간을 추가로 확보할 수 있으며, 최신 안정 버전에 더해 이전 언어 및 API 버전 세 개를 지원합니다.

• 적극적으로 유지 관리되는 코드베이스는 전체 사용 중단 주기가 완료되기를 기다리지 않고 버그 수정을 즉시 적용받을 수 있습니다.

이를 위해, 현재 이러한 프로젝트는 -progressive 옵션을 활성화하여 도구 릴리스에서도 버그 수정을 사용할 수 있습니다.

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

 

이진 포맷 발전

 

소스는 최악의 경우 수작업으로 수정할 수 있지만, 이진 파일은 마이그레이션이 훨씬 어렵기 때문에 이진의 하위 호환성이 중요합니다. 이진에 대한 비호환 변경은 업데이트를 매우 불편하게 만들 수 있으므로, 소스 언어 구문보다 더 신중하게 도입해야 합니다.

 

안정 버전 컴파일러의 기본 이진 호환성 프로토콜은 다음과 같습니다:

 

1. 모든 이진 파일은 하위 호환성(backwards compatibility)을 유지합니다.

 

즉, 최신 컴파일러는 이전 버전에서 생성된 이진 파일을 읽을 수 있습니다(예: 1.3 컴파일러는 1.0~1.2 이진 파일을 이해할 수 있음).

 

2. 이전 컴파일러는 새로운 기능을 사용하는 이진 파일을 거부합니다.

 

예를 들어, 1.0 컴파일러는 코루틴을 사용하는 이진 파일을 거부합니다.

 

3. 가능하면(보장할 수는 없지만) 이진 포맷은 다음 언어 릴리스와 대부분 전방 호환성(forwards compatibility)*을 유지합니다.

 

예를 들어, 1.9는 2.0에서 생성된 대부분의 이진 파일을 이해할 수 있지만, 2.1은 이해하지 못할 수 있습니다.

 

이 프로토콜은 약간 오래된 컴파일러를 사용하는 경우에도 프로젝트가 종속성 업데이트를 차단당하지 않도록 설계되었습니다.

 

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

 

Kotlin klib 이진 파일

 

Kotlin klib 이진 파일은 Kotlin 1.9.20에서 안정적인 수준(Stable)에 도달했습니다. 하지만 다음과 같은 호환성 세부 사항을 유의해야 합니다:

 

1. 하위 호환성(backwards compatibility):

 

1.9.20 이후의 klib 이진 파일은 하위 호환성을 유지합니다. 예를 들어, 2.0.x 컴파일러는 1.9.2x 컴파일러가 생성한 이진 파일을 읽을 수 있습니다.

 

2. 전방 호환성(forward compatibility):

 

보장되지 않습니다. 예를 들어, 2.0.x 컴파일러는 2.1.x 컴파일러가 생성한 이진 파일을 읽을 수 있을 것으로 보장되지 않습니다.

 

3. Kotlin cinterop klib 이진 파일:

 

여전히 Beta 상태입니다. 현재로서는 Kotlin 버전 간 cinterop klib 이진 파일의 호환성에 대해 구체적인 보장을 제공할 수 없습니다.

 

원문

 

https://kotlinlang.org/docs/kotlin-evolution-principles.html#compiler-options