소프트웨어 버전관리, 시맨틱 버저닝(Semantic Versioning) 규칙을 쉽게 정리합니다.
1.0, 1.1, 2.0… 버전, 어떻게 올려야 할까?
프로그램을 개발하다 보면 버전을 어떻게 매겨야 할지 고민이 됩니다. 보통 1.0으로 시작했다가 별 기준 없이 1.1, 1.2를 붙이거나 갑자기 2.0으로 올리곤 하죠. 저 역시 같은 고민을 하다가, 널리 쓰이는 명확한 규칙을 알게 되어 정리합니다.
이 글에서는 가장 보편적인 버전 규칙인 시맨틱 버저닝(Semantic Versioning)을 중심으로, 각 숫자의 의미와 실제로 언제 올려야 하는지를 예시와 함께 살펴보겠습니다.
목차
시맨틱 버저닝이란
시맨틱 버저닝은 버전 숫자에 '의미(semantic)'를 부여하는 규칙입니다. 버전을 세 자리 숫자로 나누고, 각 자리가 어떤 변경을 의미하는지 약속해 둡니다.
1.1.1
MAJOR.MINOR.PATCH
각 자리의 의미는 다음과 같습니다.
- MAJOR(메이저) – 기존 버전과 호환되지 않는 변경(API 변경 등)이 생겼을 때 올립니다.
- MINOR(마이너) – 기존과 호환되면서 새로운 기능을 추가했을 때 올립니다.
- PATCH(패치) – 기존과 호환되며 버그를 수정했을 때 올립니다.
규칙이 하나 더 있습니다. 상위 자리를 올리면 하위 자리는 0으로 초기화합니다. 예를 들어 마이너를 올리면 패치는 0이 됩니다.
실제로 언제 올릴까 (예시)
| 변경 내용 | 버전 변화 |
|---|---|
| 단순 버그 수정 | 1.2.3 → 1.2.4 |
| 호환되는 기능 추가 | 1.2.3 → 1.3.0 |
| 호환 깨지는 변경 | 2.0.0 |
0.x.x와 사전 배포 버전
메이저 버전이 0인 0.x.x는 '아직 초기 개발 단계로, 언제든 변경될 수 있다'는 의미입니다. 안정화되어 정식 출시 준비가 되면 1.0.0으로 올립니다.
정식 출시 전 단계는 버전 뒤에 라벨을 붙여 표시합니다. 흔히 쓰이는 순서는 다음과 같습니다.
- alpha – 내부 테스트 단계 (예:
1.0.0-alpha) - beta – 외부 사용자 테스트 단계 (예:
1.0.0-beta.1) - rc (Release Candidate) – 정식 출시 직전 후보 (예:
1.0.0-rc.1)
버전 이름(코드네임)
숫자 버전과 별개로, 일부 소프트웨어는 개발 단계에 별도의 '코드네임'을 붙이기도 합니다. 보통 프로젝트의 정체성을 담거나 외부에 정보가 노출되지 않도록 하기 위해서입니다.
예를 들어 삼성 갤럭시 폴드의 개발 코드명은 '위너(Winner)'였고, 과거 안드로이드는 컵케이크·아이스크림 샌드위치·킷캣처럼 디저트 이름을 버전 코드네임으로 사용했습니다. 우분투 리눅스도 'Focal Fossa'처럼 형용사+동물 조합의 코드네임을 씁니다.
마무리
시맨틱 버저닝을 정리해 봤습니다. 핵심은 'MAJOR는 호환 깨짐, MINOR는 기능 추가, PATCH는 버그 수정'이라는 세 가지 약속입니다. 이 규칙만 지켜도 사용자와 협업자가 버전 번호만 보고 변경의 성격을 짐작할 수 있어, 협업과 배포가 한결 명확해집니다.
여러분은 버전을 어떻게 관리하시나요? 나만의 방법이 있다면 댓글로 공유해 주세요!