버전(Version)

소프트웨어는 생물체와 같아서 발전하기도 하고, 퇴보하기도 하고 병에 걸리기도 한다.

 

애지중지 키우다 보면, 회사에서 이 소프트웨어를 다른 회사 혹은 개인에게 분양시켜버린다. 이때부터, 나는 불안장애에 걸리게 된다. 솔직히 잘살고 있는지는 궁금하지 않고, 나에게 아무 연락도 없길 바라게 된다. 분양한 건데, 분양받은 사람이 잘 키워야지...

 

그런데 대부분은 연락이 온다. 애가 아파요. 애가 이걸 못해요. 등등

아 글 쓰면서 상상만 해도 가슴 아프다.

 

이때부터 분양 당시 아이의 나이가 중요해진다. 우리는 이 나이를 "버전"이라고 한다.

 

소프트웨어 버전이 중요한 이유

버그는 개발자 모르게 발생했다가도 소프트웨어가 성장하면서 개발자 모르게 사라지기도 한다. (어떤 개발자가 자신이 실수한 거라 아무도 모르게 잠수함 패치를 하는 것 등)

 

버그를 고치는 대략적인 과정은 아래와 같다.

1. 버그를 재현한다.
2. 버그가 발생한 위치를 소스 코드에서 찾는다.
3. 해결한다.

만약 판매한 소프트웨어에 버전이라 것이 없었다면, 개발자 처지에서는 최신 버전에서 버그를 재현하려고 하는데, 버그 재현부터가 안 될 것이다.

버그 재현이 안 되는데 버그를 고치는 것은 어불성설이므로 버그 픽스를 못하게 되고, 소비자에게 신뢰를 잃게 된다.

물론, 단순하게 소비자에게 최신 버전을 설치하게 하면 되겠지만, 만약 소비자가 설치한 버전에서 어떤 기능을 자신들의 것과 연동시켰는데, 최신 버전에서는 호환이 안 된다면 이 방법이 불가능하다.(판매 정책 등 여러 가지로 문제가 생기는 것이 많다.)

 

그러므로, 소프트웨어를 판매할 때는 반드시 버전을 명시해야 한다.

---

 

기본적으로 창조주는 "나"이므로, 버전이 올라가는 방법도 내 마음대로이다. 사람처럼 1년마다 그냥 1씩 올려줘도 되고, 소프트웨어가 격변할 때마다 기념으로 1씩 올려줘도 된다. 버전이 꼭 숫자일 필요도 없다. 그냥 문자 ABC를 붙여줘도 된다. 정말 그냥 내 마음대로다.

 

하지만 그렇다고 버전을 너무 막 붙여버리면 의미가 없다. 이 버전이라는 것이 의미 있게 하기 위한 여러 가지 버전 명명 규칙이 있다.

 

이 포스팅에서는 몇 가지의 버전 명명 규칙에 소개하겠다.

SemVer

SemVer(Semantic Versioning)는 직역하면 의미론적 버전 관리인데, 의역하면 의미 있게 버전 붙이는 규칙 정도이다.

 

SemVer는 아래와 같은 형식을 취한다.

X.Y.Z

 

각각 아래와 같이 부른다.

• X = Major, 주 버전
• Y = Minor, 부 버전
• Z = Patch, 수 버전

각각의 버전은 다음과 같을 때 올라간다.

• X: 이전 버전과 호환이 안 되는 경우
• Y: 기능이 추가되지만, 이전 버전과 호환을 할 수 있는 경우
• Z: 버그를 고치지만, 이전 버전과 호환을 할 수 있는 경우

이도 저도 아닐 때, 그냥 성능을 조금 개선했거나 소스 코드를 리팩토링한 것처럼 외부로 크게 표시가 안 될 때는 아래처럼 라벨을 붙이라고 제안하고 있다.

X.Y.Z-<build 번호>

 

이것 외에 하지 말아야 할 것, 해야 할 것 등의 규칙이 있지만, 이런 것까지 굳이 지킬 필요는 없다.
위에서 설명한 것 정도만 지켜도 이미 의미가 있다.

CalVer

CalVer(Calendar Versioning)은 무척 단순하다. 그냥 배포하는 순간의 시간을 버전으로 표기하면 된다.

 

이를 가장 제대로 보여주는 프로젝트 중 하나는 youtube-dl이다.
이 프로젝트의 태그는 아래와 같다.

2021.06.06
2021.05.16

너무도 직관적이다.

 

CalVer는 이게 전부인 버전 명명 규칙이다.

SemVer vs CalVer

CalVer는 쉽지만, SemVer에 비해서 너무도 의미가 없어 보인다.
그런데 생각해보면 SemVer도 숫자만 보면 아무 의미가 없다.

 

4.19.213
5.4.155
5.10.75

위의 버전은 리눅스 커널의 버전들이다.

버전만 보면 4.19에서 5.4로 변할 때, 호환이 안 되겠구나! 정도
5.4에서 5.10으로 변할 때, 기능이 추가됐지만 호환되겠구나! 정도뿐이다.

 

CalVer에 비해 조금 더 의미가 있긴 하지만, 릴리즈 노트를 읽지 않으면 무슨 변화가 생겼는지 모른다.

 

독자분들이 어떤 버전 명명 규칙을 사용하게 될지는 모르겠지만, 제발 의미 있는 버전 명명 규칙을 사용하게 되길 바란다.

번외) 코드명

버전과 함께 코드명이라는 것을 사용하는 곳도 있다.

 

대표적으로 안드로이드, 오픈스택이 그렇다.

 

안드로이드는 컵케이크부터 젤리빈, 롤리팝, 오레오 등등의 디저트 코드명을 사용했다.
물론, 안드로이드 9(파이)까지만이다.

이후로는 외부에만 공개하지 않는 건지, 정말로 사용 자체를 하지 않는 건지 모르겠지만 숫자로만 표기한다.

 

오픈스택은 코드명이 아니라 시리즈라고 표기하긴 하지만, 일단 비슷하게 A로 시작하는 Austin부터 T로 시작하는 Train까지 꾸준히 코드명을 사용하고 있다. Y는 yoga로 정해졌고, 이후에 Z를 넘어가면 다시 A부터 시작할지 아니면 안드로이드처럼 코드명을 포기할 게 될지 궁금하다.

 

이런 식으로 코드명이 있으면 굉장히 편리하다.
코드명은 또 다른 이름처럼 쓰이므로, 의사소통할 때 정말 좋다.
물론 코드명 짓기 자체가 힘들긴 하겠지만 말이다.

마치며...

뭘까. 원래 이렇게 길게 쓸 생각이 없었는데, 이거에 대해 깊은 빡침이 있었나보다.
내가 다니는 회사에서는 프로그램에 버전이라고 부를 만한 게 없다. 즉, 구분이 안 된다.

 

프로그램 이름이 바닐라라고 하면, 바닐라의 버전을 조금이라도 구분하기 위해서
구바닐라, 뉴바닐라 라고 부른다.

 

근데 웃긴 게, 뉴바닐라가 조금 지나면, 이걸 뉴바닐라라고 부를 수 있나?
또 새로운 바닐라가 나오면 이게 뉴바닐라고, 원래 뉴바닐라는 구바닐라가 되는데, 그럼 원래 구바닐라는 뭐라고 불러야 될까? 구구바닐라라고 불러야되나?

 

제발, 이걸 읽으시는 분들은 이러지 말길, 이렇게 되지 않길 바란다.