[EXT-007][중급] 버전 번호와 의존성 범위 안전하게 읽기
페이지 정보
본문
[이번 수업]
다른 라이브러리를 가져다 쓰면 버전 번호 하나가 동작과 보안을 함께 좌우합니다. 시맨틱 버전(Semantic Versioning, 의미에 따라 숫자를 올리는 규칙)의 MAJOR.MINOR.PATCH를 읽고, 허용 범위와 잠금 파일의 역할을 구분합니다. 예제는 설치 없이 가짜 버전 목록만 다룹니다.
[선수지식]
파일을 만들고 터미널에서 Python을 실행할 수 있으면 됩니다. 튜플은 여러 값을 순서대로 묶은 자료형입니다.
[학습목표]
1. 1.4.2의 세 숫자가 바뀌는 의미를 설명한다.
2. 선언 파일의 범위와 잠금 파일의 확정 결과를 구분한다.
3. 업데이트 후보를 정책에 따라 비교하고 검증한다.
[핵심개념]
SemVer 2.0.0에서 MAJOR는 호환되지 않는 공개 API 변경, MINOR는 하위 호환 기능 추가, PATCH는 하위 호환 오류 수정 때 증가합니다. 2.1.3이라면 2가 MAJOR, 1이 MINOR, 3이 PATCH입니다. 2.0.0은 1.x 사용 코드의 동작을 보장하지 않습니다. 1.0.0-alpha 같은 사전 공개 버전은 정식 버전보다 우선순위가 낮고, +build.5 같은 빌드 메타데이터는 우선순위 비교에서 무시됩니다.
^1.4.2, ~=1.4 같은 범위 문법은 SemVer 자체 규칙이 아닙니다. 패키지 생태계가 별도로 정의하므로 다른 도구의 기호를 그대로 옮기면 안 됩니다. 특히 0.y.z는 공개 API가 불안정할 수 있어 같은 주 버전만으로 호환을 단정하면 위험합니다.
의존성 선언 파일은 허용할 버전 조건을 기록합니다. 잠금 파일(lock file, 실제 선택된 버전과 의존 관계를 고정한 기록)은 설치 결과의 재현을 돕습니다. 넓은 범위만 믿으면 예상 밖 업데이트가 들어올 수 있고, 잠금을 오래 유지하면 보안 수정도 놓칠 수 있습니다. 잠금 파일을 저장소에 두고 계획된 갱신·변경 기록 검토·테스트를 함께 수행합니다.
[따라하기]
아래를 version_check.py로 저장합니다. 학습용 함수는 숫자 세 덩어리인 정식 버전만 처리합니다. 운영에서는 패키지 관리자의 공식 비교 기능을 사용하세요.
```python
def parse_stable(version):
parts = version.split(".")
if len(parts) != 3 or not all(part.isdigit() for part in parts):
raise ValueError(f"안정 버전 형식이 아닙니다: {version}")
return tuple(map(int, parts))
current = parse_stable("1.4.2")
candidates = ["1.4.3", "1.8.0", "2.0.0"]
compatible = [
version for version in candidates
if current <= parse_stable(version) < (current[0] + 1, 0, 0)
]
print("현재:", ".".join(map(str, current)))
print("같은 주 버전 후보:", ", ".join(compatible))
print("선택:", max(compatible, key=parse_stable))
```
macOS/Linux는 `python3 version_check.py`, Windows는 `py version_check.py`를 실행합니다. 예상 결과입니다.
```text
현재: 1.4.2
같은 주 버전 후보: 1.4.3, 1.8.0
선택: 1.8.0
```
같은 MAJOR만 허용한 것은 예제의 정책이며 모든 범위 기호와 같은 뜻이 아닙니다. 실제 작업에서는 선언 파일과 잠금 파일의 변경을 함께 비교하고 테스트합니다.
[흔한 실수]
`1.10.0`을 문자열로 비교하면 `1.9.0`보다 작다고 잘못 판단할 수 있으므로 숫자 덩어리로 나눕니다. 범위 기호를 공통 문법으로 생각하거나, 잠금 파일 충돌을 지운 뒤 바뀐 간접 의존성을 확인하지 않는 것도 실수입니다. 버전이 올랐다는 사실만으로 더 안전하거나 호환된다고 단정하지 마세요.
[보안 주의]
본인 소유의 로컬·격리 환경에서만 연습하세요. 실제 설치는 신뢰하는 공식 레지스트리와 출처를 확인하고 잠금 파일의 무결성 정보를 제거하지 않습니다. 보안 권고와 변경 기록을 읽고 테스트 후 배포하며, 취약 버전을 방치하지 않도록 정기 갱신합니다. 이름이 비슷한 패키지는 설치 전 정확한 이름과 관리 주체를 확인하세요.
[직접 해볼 과제]
후보에 1.5.0과 2.0.1을 추가해 출력 변화를 확인하세요. 1.4처럼 세 덩어리가 아닌 입력이 ValueError가 되는지 검사하고, 0.4.2에서 단순한 같은-MAJOR 정책이 부족한 이유를 두 문장으로 적으세요.
[확인문제]
1. 3.2.5에서 하위 호환 오류 수정은 어느 숫자를 올립니까?
2. 의존성 선언 파일과 잠금 파일은 각각 무엇을 기록합니까?
3. ^ 기호를 모든 패키지 도구에서 같은 뜻으로 해석하면 안 되는 이유는 무엇입니까?
[다음 학습]
다음에는 요청을 재시도해도 결과가 중복되지 않게 만드는 멱등성 키와 재시도 정책을 배웁니다.
[공식 참고 자료]
- Semantic Versioning 2.0.0: https://semver.org/spec/v2.0.0.html
- npm package.json 의존성 명세: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#dependencies
- npm package-lock.json 명세: https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json
- Python Packaging 버전 지정자 명세: https://packaging.python.org/en/latest/specifications/version-specifiers/
- PEP 751 잠금 파일 형식: https://peps.python.org/pep-0751/
다른 라이브러리를 가져다 쓰면 버전 번호 하나가 동작과 보안을 함께 좌우합니다. 시맨틱 버전(Semantic Versioning, 의미에 따라 숫자를 올리는 규칙)의 MAJOR.MINOR.PATCH를 읽고, 허용 범위와 잠금 파일의 역할을 구분합니다. 예제는 설치 없이 가짜 버전 목록만 다룹니다.
[선수지식]
파일을 만들고 터미널에서 Python을 실행할 수 있으면 됩니다. 튜플은 여러 값을 순서대로 묶은 자료형입니다.
[학습목표]
1. 1.4.2의 세 숫자가 바뀌는 의미를 설명한다.
2. 선언 파일의 범위와 잠금 파일의 확정 결과를 구분한다.
3. 업데이트 후보를 정책에 따라 비교하고 검증한다.
[핵심개념]
SemVer 2.0.0에서 MAJOR는 호환되지 않는 공개 API 변경, MINOR는 하위 호환 기능 추가, PATCH는 하위 호환 오류 수정 때 증가합니다. 2.1.3이라면 2가 MAJOR, 1이 MINOR, 3이 PATCH입니다. 2.0.0은 1.x 사용 코드의 동작을 보장하지 않습니다. 1.0.0-alpha 같은 사전 공개 버전은 정식 버전보다 우선순위가 낮고, +build.5 같은 빌드 메타데이터는 우선순위 비교에서 무시됩니다.
^1.4.2, ~=1.4 같은 범위 문법은 SemVer 자체 규칙이 아닙니다. 패키지 생태계가 별도로 정의하므로 다른 도구의 기호를 그대로 옮기면 안 됩니다. 특히 0.y.z는 공개 API가 불안정할 수 있어 같은 주 버전만으로 호환을 단정하면 위험합니다.
의존성 선언 파일은 허용할 버전 조건을 기록합니다. 잠금 파일(lock file, 실제 선택된 버전과 의존 관계를 고정한 기록)은 설치 결과의 재현을 돕습니다. 넓은 범위만 믿으면 예상 밖 업데이트가 들어올 수 있고, 잠금을 오래 유지하면 보안 수정도 놓칠 수 있습니다. 잠금 파일을 저장소에 두고 계획된 갱신·변경 기록 검토·테스트를 함께 수행합니다.
[따라하기]
아래를 version_check.py로 저장합니다. 학습용 함수는 숫자 세 덩어리인 정식 버전만 처리합니다. 운영에서는 패키지 관리자의 공식 비교 기능을 사용하세요.
```python
def parse_stable(version):
parts = version.split(".")
if len(parts) != 3 or not all(part.isdigit() for part in parts):
raise ValueError(f"안정 버전 형식이 아닙니다: {version}")
return tuple(map(int, parts))
current = parse_stable("1.4.2")
candidates = ["1.4.3", "1.8.0", "2.0.0"]
compatible = [
version for version in candidates
if current <= parse_stable(version) < (current[0] + 1, 0, 0)
]
print("현재:", ".".join(map(str, current)))
print("같은 주 버전 후보:", ", ".join(compatible))
print("선택:", max(compatible, key=parse_stable))
```
macOS/Linux는 `python3 version_check.py`, Windows는 `py version_check.py`를 실행합니다. 예상 결과입니다.
```text
현재: 1.4.2
같은 주 버전 후보: 1.4.3, 1.8.0
선택: 1.8.0
```
같은 MAJOR만 허용한 것은 예제의 정책이며 모든 범위 기호와 같은 뜻이 아닙니다. 실제 작업에서는 선언 파일과 잠금 파일의 변경을 함께 비교하고 테스트합니다.
[흔한 실수]
`1.10.0`을 문자열로 비교하면 `1.9.0`보다 작다고 잘못 판단할 수 있으므로 숫자 덩어리로 나눕니다. 범위 기호를 공통 문법으로 생각하거나, 잠금 파일 충돌을 지운 뒤 바뀐 간접 의존성을 확인하지 않는 것도 실수입니다. 버전이 올랐다는 사실만으로 더 안전하거나 호환된다고 단정하지 마세요.
[보안 주의]
본인 소유의 로컬·격리 환경에서만 연습하세요. 실제 설치는 신뢰하는 공식 레지스트리와 출처를 확인하고 잠금 파일의 무결성 정보를 제거하지 않습니다. 보안 권고와 변경 기록을 읽고 테스트 후 배포하며, 취약 버전을 방치하지 않도록 정기 갱신합니다. 이름이 비슷한 패키지는 설치 전 정확한 이름과 관리 주체를 확인하세요.
[직접 해볼 과제]
후보에 1.5.0과 2.0.1을 추가해 출력 변화를 확인하세요. 1.4처럼 세 덩어리가 아닌 입력이 ValueError가 되는지 검사하고, 0.4.2에서 단순한 같은-MAJOR 정책이 부족한 이유를 두 문장으로 적으세요.
[확인문제]
1. 3.2.5에서 하위 호환 오류 수정은 어느 숫자를 올립니까?
2. 의존성 선언 파일과 잠금 파일은 각각 무엇을 기록합니까?
3. ^ 기호를 모든 패키지 도구에서 같은 뜻으로 해석하면 안 되는 이유는 무엇입니까?
[다음 학습]
다음에는 요청을 재시도해도 결과가 중복되지 않게 만드는 멱등성 키와 재시도 정책을 배웁니다.
[공식 참고 자료]
- Semantic Versioning 2.0.0: https://semver.org/spec/v2.0.0.html
- npm package.json 의존성 명세: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#dependencies
- npm package-lock.json 명세: https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json
- Python Packaging 버전 지정자 명세: https://packaging.python.org/en/latest/specifications/version-specifiers/
- PEP 751 잠금 파일 형식: https://peps.python.org/pep-0751/
- 이전글[EXT-008][중급] UUID로 겹치기 어려운 식별자 만들기 26.09.07
- 다음글[EXT-006][기초] SHA-256으로 파일이 같은지 확인하기 26.09.07
댓글목록
등록된 댓글이 없습니다.