우선 SemVer이 무엇인가?
SemVer 풀어 쓰면 Semantic Version 는 언뜻 보기엔 낮선 단어처럼 느껴질 수 있지만, 사실 우리는 모두 SemVer이 뭔지 알고 있다. 비단 개발자 뿐만 아니라 개발과는 거리가 먼 일반인들도 충분히 많이 봤을 법한 내용이다.
보통 우리는 버전을 얘기할 때,
이번 프로그램 업데이트의 버전은 "2.5.43" 입니다.
라고 하는 경우가 많은데, 이 때 "2.5.43" 이 바로 SemVer이 되시겠다.
이를 하나 하나 보자면,
{메이저 버전} . {마이너 버전} . {패치 버전}
라고 구분 짓을 수 있다. 지금부터 하나씩 훑어보자.
1. 메이저 버전 (Major Version)
{메이저버전} . {마이너버전} . {패치버전}
메이저 버전은 뭔가 큰 변화가 있을 만한 업데이트에 올리게 된다. 라고 하지만 뭔가 판단 기준이 안서는 기분이다. 변화가 큰 지 안 큰지는 사람마다 다 다르게 생각할 거 아닌가?
사실 이것보다 메이저 버전을 나누는 가장 좋은 아이디어가 있다. 바로 "하위호환"이다. 하위호환은 프로젝트를 유지보수할 때 가장 신경써야 할 부분 중 하나이다. 우리는 어느 상황에도 최대한 하위호환을 유지토록 해야할 의무가 있다.
예를 들어 API를 개발할 때 조차도 지금 작성되어 있는 API를 버리면 안된다. 응답/요청 구조 혹은 URL 조차도 바뀌면 안된다. 클라이언트는 API가 업데이트가 되었는 지 안 되었는지는 신경 쓸 필요가 없다. API는 말그대로 Interface이기 때문에 안의 비즈니스 로직이 어떻게 돌아가든, 클라이언트에게 보여주는 면은 항상 똑같아야 한다.
하지만 정 하위호환을 못 지킬 때가 분명히 찾아올 것이다. 우리는 이런 것을 큰 변화라고 생각할 수 있다. 이러한 변화가 생기는 이유는 비단 대단한 기능의 추가에 경우만 있는 것은 아니다. 생각지도 못하게 백엔드에서 사용하는 자료구조가 바뀌는 것 만으로 Interface가 깨지는 경우도 분명 있다. 이런 경우에는 메이저버전을 올리는 것을 고려해보자.
당연하지만 마이너버전의 변경사항을 포함한다.
2. 마이너 버전 (Minor Version)
{메이저버전} . {마이너버전} . {패치버전}
마이너 버전은 메이저 버전과 달리 하위호환이 가능한 변화가 있을 경우 버전을 올리게 된다. 마이너버전의 중요한 역할은 "기능 추가" 를 대표한다는 것이다. 마이너 버전을 올리는 경우에는 적어도 하나의 기능 추가가 있어야 한다. 그리고 아주 조그만한 기능의 추가라도 마이너버전으로 올려야 된다는 것을 명심하자.
당연하지만 패치버전의 변경사항을 포함한다.
3. 패치 버전 (Minor Version)
{메이저버전} . {마이너버전} . {패치버전}
패치 버전의 가장 중요한 역할은 "버그 수정" 을 대표한다는 것이다. 다른 역할은 기능추가 없는 변경사항이 있다. 중요한 것은 "기능추가가 없다" 라는 것이다. 괜히 기능추가를 생각해놓고 패치 버전을 올리는 불상사를 저지르지 말자.
SemVer을 지키는 것은 하나의 약속이다.
위의 내용을 정리하자면
- 메이저 버전: 큰 변화가 있을 업데이트
- 마이너 버전: 작은 변화가 있을 업데이트
- 패치 버전: 버그 수정 및 코드 개선
으로 생각할 수 있다.
최대한 이 방식대로 SemVer을 올려주기를 권고하는 데, 왜냐하면 우리는 모두 이 방식으로 올리기로 약속했기 때문이다. 우리는 혼자만 일하는 것이 아니다. 다른 사람들과 일한다.
마이너 수준의 패치를 하는 동료는 분명히 하위호환이 될 것이라 생각하고 패치할 것이다. 하지만 그 패치가 메이저 수준의 변화가 있다고 한다면? 패치는 정상적으로 실행되지 않을 것이다. 이것은 단순히 패치 실패에 대한 얘기가 아니다. 서로간의 믿음과 신뢰가 깨지는 지름길이다.
이미 내보낸 버전은 절대로 절대로 고치지 말자.
버전이 무엇이라고 생각하는가? 버전은 프로젝트를 현재상태를 유니크하게 찍은 스냅샷의 "키"이다. 즉, 어떠한 버전은 유니크한 상태를 대표할 수 있어야 한다.
만약 다른 상태들이 하나의 키로 표현된다면? 그것은 재앙이라고 할 수 있다. 분명히 같은 버전인데 허떤 프로그램은 버그가 발생하고, 어떤 프로그램은 버그가 발생하지 않는다면? 우리는 굉장히 많은 시간을 불필요한 디버깅 시간으로 낭비하게 될 것이다.
버전은 또한 롤백을 위한 근거가 된다. 어떤 프로그램을 업데이트했더니 버그가 발생해 다시 이전 버전으로 돌아가고 싶다고 할 때, 이전 버전의 내용은 업데이트하기 전의 버전의 내용과 동일해야 한다. 이것이 보장되지 않는 한, 그 프로그램은 절대로 신뢰할 수 없을 것이다.
버전이 올라가면 이전 버전은 끝나버리는 걸까?
일반적으론 버전이 올라가면 그 이전 버전은 지원을 중단하는 것이 일반적이긴 하다. 하지만 항상 뜻대로 되는 것은 없다. 버전이 올라가도 이전 버전의 대한 유지보수 지원이 있어야 할 수도 있다. 이것은 각 업무의 성격에 따라 다를 것이다.
내가 업무할 때도 이런 경우가 상당히 많은데, 나는 이런 경우를 자연스럽게 풀기 위해 프로젝트의 버전관리에 있어 Gitflow를 적당히 변경하여 대처했다. 이에 관한 내용은 추후에 설명할 시간이 있으면 좋겠다.
