semver · JohnTitor · Oct 26, 2025 · Aug 23, 2025 · Aug 23, 2025 · Aug 23, 2025
diff --git a/lang/ko/index.md b/lang/ko/index.md
@@ -12,10 +12,10 @@ language: ko
 버전을 주.부.수 숫자로 하고:
 
 1. 기존 버전과 호환되지 않게 API가 바뀌면 "주(主) 버전"을 올리고,
-1. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 "부(部) 버전"을 올리고,
-1. 기존 버전과 호환되면서 버그를 수정한 것이라면 "수(修) 버전"을 올린다.
+2. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 "부(副) 버전"을 올리고,
+3. 기존 버전과 호환되면서 버그를 수정한 것이라면 "수(修) 버전"을 올린다.
 
-주.부.수 형식에 정식배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다.
+주.부.수 형식에 정식 배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다.
 
 머리말
 ------
@@ -24,7 +24,7 @@ language: ko
 
 의존성이 높은 시스템에서는, 새 패키지 버전을 배포하는 일이 금방 끔찍해지곤 한다. 의존성 명세를 너무 엄격하게 관리하면, 버전에 갇히게 될 위험이 있다(의존하는 모든 패키지의 새 버전을 배포하지 않고는 업그레이드할 수 없게 된다). 의존성을 너무 느슨하게 관리하면, 버전이 엉켜서 괴롭게 될 것이다(지나치게 나중 버전까지 호환될 거라 가정한 경우). 버전에 갇히거나 엉켜서 쉽고 안전하게 프로젝트를 계속 진행할 수 없다면 의존성 지옥에 빠진 것이다.
 
-이 문제의 해결책으로, 버전 번호를 어떻게 정하고 올려야 하는지를 명시하는 규칙과 요구사항을 제안한다. 이 규칙들은 기존 오픈 소스/비공개 소스 소프트웨어에 널리 활용되는 규칙을 바탕으로 했으나, 반드시 따르고자 제약을 받지는 않았다. 이 시스템이 동작하려면, 먼저 공개(public) API를 선언해야 한다. 문서와 소스 코드 자체로 드러낼 수 있다. 어떤 방식이든 API가 명확해야 한다. 한번 공개 API를 정의하고 나면, 버전 번호를 올리는 방식을 통해 API가 어떻게 바뀌는지 표현한다. 버전을 X.Y.Z (주.부.수) 형식으로 정한다. API에 영향이 없는 버그 수정은 수(修)버전을 올리고, API가 호환되면서 바꾸거나 추가하는 경우에는 부(部)버전을 올리고, API가 호환되지 않는 변경이라면 주(主)버전을 올린다.
+이 문제의 해결책으로, 버전 번호를 어떻게 정하고 올려야 하는지를 명시하는 규칙과 요구사항을 제안한다. 이 규칙들은 기존 오픈 소스/비공개 소스 소프트웨어에 널리 활용되는 규칙을 바탕으로 했으나, 반드시 따르고자 제약을 받지는 않았다. 이 시스템이 동작하려면, 먼저 공개(public) API를 선언해야 한다. 문서와 소스 코드 자체로 드러낼 수 있다. 어떤 방식이든 API가 명확해야 한다. 한번 공개 API를 정의하고 나면, 버전 번호를 올리는 방식을 통해 API가 어떻게 바뀌는지 표현한다. 버전을 X.Y.Z (주.부.수) 형식으로 정한다. API에 영향이 없는 버그 수정은 수(修)버전을 올리고, API가 호환되면서 바꾸거나 추가하는 경우에는 부(副)버전을 올리고, API가 호환되지 않는 변경이라면 주(主)버전을 올린다.
 
 이 체계를 "유의적 버전"이라고 부르고자 한다. 이 체계를 따르면, 버전 번호와 그 번호를 바꾸는 방법을 통해 특정 버전에서 다음 버전으로 넘어가면서 코드가 어떻게 바뀌는지를 드러낸다.
 
@@ -35,25 +35,25 @@ language: ko
 
 1. 유의적 버전을 쓰는 소프트웨어는 반드시 공개 API를 선언한다. 이 API는 코드 자체로 선언하거나 문서로 엄격히 명시해야 한다. 어떤 방식으로든, 정확하고 이해하기 쉬워야 한다.
 
-2. 보통 버전 번호는 반드시 X.Y.Z의 형태로 하고, X, Y, Z는 각각 자연수(음이 아닌 정수)이고, 절대로 0이 앞에 붙어서는 안 된다. X는 주(主)버전 번호이고, Y는 부(部)버전 번호이며, Z는 수(修)버전 번호이다. 각각은 반드시 증가하는 수여야 한다. 예: 1.9.0 -> 1.10.0 -> 1.11.0.
+2. 보통 버전 번호는 반드시 X.Y.Z의 형태로 하고, X, Y, Z는 각각 자연수(음이 아닌 정수)이고, 절대로 0이 앞에 붙어서는 안 된다. X는 주(主)버전 번호이고, Y는 부(副)버전 번호이며, Z는 수(修)버전 번호이다. 각각은 반드시 증가하는 수여야 한다. 예: 1.9.0 -> 1.10.0 -> 1.11.0.
 
 3. 특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야 한다. 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.
 
-4. 주버전 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다. 이 공개 API는 안정판으로 보지 않는 게 좋다.
+4. 주버전 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무때나 마음대로 바꿀 수 있다. 이 공개 API는 안정판으로 보지 않는 게 좋다.
 
 5. 1.0.0 버전은 공개 API를 정의한다. 이후의 버전 번호는 이때 배포한 공개 API에서 어떻게 바뀌는지에 따라 올린다.
 
 6. 수버전 Z (x.y.Z `|` x > 0)는 반드시 그전 버전 API와 호환되는 버그 수정의 경우에만 올린다. 버그 수정은 잘못된 내부 기능을 고치는 것이라 정의한다.
 
 7. 공개 API에 기존과 호환되는 새로운 기능을 추가할 때는 반드시 부버전 Y(x.Y.z `|` x > 0)를 올린다. 공개 API의 일부를 앞으로 제거할 것(deprecate)으로 표시한 경우에도 반드시 올리도록 한다. 내부 비공개 코드에 새로운 기능이 대폭 추가되거나 개선사항이 있을 때도 올릴 수 있다. 부버전을 올릴 때 수버전을 올릴 때만큼의 변화를 포함할 수도 있다. 부버전이 올라가면 수버전은 반드시 0에서 다시 시작한다.
 
-8. 공개 API에 기존과 호환되지 않는 변화가 있을 때는 반드시 주버전 X(X.y.z `|` X > 0)를 올린다. 부버전이나 수버전급 변화를 포함할 수 있다. 주버전 번호를 올릴 때는 반드시 부버전과 수버전을 0으로 초기화 한다.
+8. 공개 API에 기존과 호환되지 않는 변화가 있을 때는 반드시 주버전 X(X.y.z `|` X > 0)를 올린다. 부버전이나 수버전급 변화를 포함할 수 있다. 주버전 번호를 올릴 때는 반드시 부버전과 수버전을 0으로 초기화한다.
 
 9. 수버전 바로 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 더해서 정식 배포를 앞둔 (pre-release) 버전을 표기할 수 있다. 식별자는 반드시 아스키(ASCII) 문자, 숫자, 붙임표로만 구성한다[0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 숫자 식별자의 경우 절대 앞에 0을 붙인 숫자로 표기하지 않는다. 정식배포 전 버전은 관련한 보통 버전보다 우선순위가 낮다. 정식배포 전 버전은 아직 불안정하며 연관된 일반 버전에 대해 호환성 요구사항이 충족되지 않을 수도 있다. 예: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
 
 10. 빌드 메타데이터는 수버전이나 정식배포 전 식별자 뒤에 더하기(+) 기호를 붙인 뒤에 마침표로 구분된 식별자를 덧붙여서 표현할 수 있다. 식별자는 반드시 아스키 문자와 숫자와 붙임표로만 구성한다 [0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 빌드 메타데이터는 버전 간의 우선순위를 판단하고자 할 때 반드시 무시해야 한다. 그러므로, 빌드 메타데이터만 다른 두 버전의 우선순위는 같다. 예: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
 
-11. 우선순위는 버전의 순서를 정렬할 때 서로를 어떻게 비교할지를 나타낸다. 우선순위는 반드시 주, 부, 수 버전, 그리고 정식배포 전 버전의 식별자를 나누어 계산하도록 한다 (빌드 메타데이터는 우선순위에 영향을 주지 않는다). 우선순위는 다음의 순서로 차례로 비교하면서, 차이가 나는 부분이 나타나면 결정된다: 주, 부, 수는 숫자로 비교한다. 예: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. 주, 부, 수버전이 같을 경우, 정식배포 전 버전이 표기된 경우의 우선순위가 더 낮다. 예: 1.0.0-alpha < 1.0.0. 주, 부, 수버전이 같은 두 배포 전 버전 간의 우선순위는 반드시 마침표로 구분된 식별자를 각각 차례로 비교하면서 차이점을 찾는다: 숫자로만 구성된 식별자는 수의 크기로 비교하고 알파벳이나 붙임표가 포함된 경우에는 아스키 문자열 정렬을 하도록 한다. 숫자로만 구성된 식별자는 어떤 경우에도 문자와 붙임표가 있는 식별자보다 낮은 우선순위로 여긴다. 앞선 식별자가 모두 같은 배포 전 버전의 경우에는 필드 수가 많은 쪽이 더 높은 우선순위를 가진다. 예: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
+11. 우선순위는 버전의 순서를 정렬할 때 서로를 어떻게 비교할지를 나타낸다. 우선순위는 반드시 주, 부, 수 버전, 그리고 정식 배포 전 버전의 식별자를 나누어 계산하도록 한다 (빌드 메타데이터는 우선순위에 영향을 주지 않는다). 우선순위는 다음의 순서로 차례로 비교하면서, 차이가 나는 부분이 나타나면 결정된다: 주, 부, 수는 숫자로 비교한다. 예: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. 주, 부, 수버전이 같을 경우, 정식 배포 전 버전이 표기된 경우의 우선순위가 더 낮다. 예: 1.0.0-alpha < 1.0.0. 주, 부, 수버전이 같은 두 배포 전 버전 간의 우선순위는 반드시 마침표로 구분된 식별자를 각각 차례로 비교하면서 차이점을 찾는다: 숫자로만 구성된 식별자는 수의 크기로 비교하고 알파벳이나 붙임표가 포함된 경우에는 아스키 문자열 정렬을 하도록 한다. 숫자로만 구성된 식별자는 어떤 경우에도 문자와 붙임표가 있는 식별자보다 낮은 우선순위로 여긴다. 앞선 식별자가 모두 같은 배포 전 버전의 경우에는 필드 수가 많은 쪽이 더 높은 우선순위를 가진다. 예: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
 
 유효한 유의적 버전의 BNF(Backus-Naur Form) 문법
 -----------------------------------------------
@@ -173,15 +173,15 @@ FAQ
 
 ### 유의적 버전의 버전 문자열 길이에 제한이 있나?
 
-없지만, 잘 판단 하자. 예를 들어, 255자 버전 문자열은 아마도 지나치게 긴 것일 것이다. 또, 몇몇 시스템은 문자열 길이에 대해 나름의 제한이 있을 것이다.
+없지만, 잘 판단하자. 예를 들어, 255자 버전 문자열은 아마도 지나치게 긴 것일 것이다. 또, 몇몇 시스템은 문자열 길이에 대해 나름의 제한이 있을 것이다.
 
-### "v1.2.3"은 유의적 버전 인가?
+### "v1.2.3"은 유의적 버전인가?
 
 "v1.2.3"은 유의적 버전이 아니다. 그러나, 버전 숫자를 나타내기 위해 유의적 버전의 접두어로 "v"를 붙이기도 한다. 버전 관리 도구에서 "version"의 축약어로 "v"로 사용하는 것을 흔하게 볼 수 있다. 예: `git tag v1.2.3 -m "Release version 1.2.3"` 에서 "v1.2.3"은 tag name이고 유의적 버전은 "1.2.3" 이다.
 
 ### 유의적 버전을 확인할 수 있는 정규식(RegEx)이 있나?
 
-두가지 방법이 있다. 첫번째는 캡처 그룹 이름 지정 방식의 정규식이다(PCRE [Perl Compatible Regular Expressions, i.e. Perl, PHP and R], Python, Go 지원).
+두 가지 방법이 있다. 첫번째는 캡처 그룹 이름 지정 방식의 정규식이다(PCRE [Perl Compatible Regular Expressions, i.e. Perl, PHP and R], Python, Go 지원).
 
 See: <https://regex101.com/r/Ly7O1x/3/>