본문 바로가기
코딩해보니/Git

[Git_01] 버전(Version)?

by 위시랜 2022. 11. 2.

버전(version) 이란?
버전(version) 이란?

Git(깃)은 버전 관리 프로그램입니다.
너무나 당연한 이야기지만,

버전 관리 프로그램은 버전 관리 시스템(VCS = Version Control System)을

구성하는데 필수적인 소프트웨어입니다.

1. 버전(Version) 이란?

버전 관리~, 버전 관리~ 하는데,

도대체 버전이 무엇인지 부터 살펴보겠습니다.
인터넷에서 '버전'이라고 검색하면 사전적 의미로 다음과 같습니다.

 

버전 (Version)
[명사]
1. 어떤 소프트웨어가 몇 번 개정되었는지를 나타내는 번호. 보통 소프트웨어가 처음 출시될 때 버전이 1.0이고, 추후 기존의 기능이 보완되거나 새로운 기능이 추가될 때 버전을 올린다.

2. 한 소프트웨어를 서로 다른 시스템 환경에서 사용할 수 있도록 각각 제작된 프로그램을 이르는 말. 예를 들어, 어떤 게임용 소프트웨어는 도스 버전과 윈도 버전이 있다.

사전적 의미로 두 가지를 얘기하고 있습니다만,

지금부터 얘기하고자 하는 것은 첫 번째 의미에 해당합니다.

모든 프로그램(소프트웨어)들은 버전을 가지고 있습니다.
예를 들어, 크롬 브라우저를 사용한다면

이 브라우저에도 현재 사용하고 있는 크롬 브라우저의 버전이 있습니다.

 

확인해 볼까요?

다음 크롬 브라우저 화면과 같이

주소 입력 창 맨 오른쪽에 위치한 점 세 개로 표시되고 있는 곳을 클릭하면

펼쳐지는 메뉴들 중에 아래쪽에 [도움말]이 보입니다.

 

크롬(Chrome) 브라우저 - 버전 정보 확인하기
크롬(Chrome) 브라우저 - 버전 정보 확인하기

[도움말] 메뉴에 마우스를 가져가면 또 다른 추가 메뉴들이 펼쳐지는데요.

여기서 [Chrome 정보]라는 메뉴를 확인할 수 있고 클릭해 보면 됩니다.

또는, 다음과 같이 바로 주소 입력창에 “chrome://settings/help”라고 입력해도 됩니다.

크롬(Chrome) 브라우저 - 도움말 바로가기
크롬(Chrome) 브라우저 - 도움말 바로가기

그러면 다음과 같은 화면을 확인할 수 있습니다.

크롬(Chrome) 브라우저 - 버전 정보 확인하기
크롬(Chrome) 브라우저 - 버전 정보 확인하기

가운데에 보면 “Chrome이 최신 버전입니다.”라는 메시지가 보입니다.
그리고 바로 아래 “버전 105.0.5195.102(공식 빌드) (64비트)”라고 버전을 표시하고 있습니다.

이렇게 모든 프로그램(소트프웨어)은 현재 버전을 확인할 수 있습니다.
모바일 앱도 마찬가지입니다.
앱들도 구글 플레이나 앱스토어에서 업데이트를 받게 되는데,

이러한 버전 정보로 관리되어지고 표시되고 있습니다.


2. 버전 표기 방법

버전은 보통 세자리로 표시하고 점(.)을 사용해 자리를 구분합니다.
위에서 살펴본 크롬 브라우저의 버전을 다시 한번 보겠습니다.

크롬(Chrome) 브라우저 버전 표기
크롬(Chrome) 브라우저 버전 표기


첫 번째 자리는 0으로 시작하면 아직 정식 버전이 아니라 초기 개발 버전임을 의미합니다.
보통 정식 버전은 첫자리가 1로 시작합니다. 첫자리는 메이저(major) 번호라고 합니다.

메이저 번호는 완전히 새롭게 변화를 주는 경우에 변경을 하게 됩니다.

완전히 새롭게 변화를 주기 때문에 이전 버전(하위 버전)과 호환이 안 되는 경우가 많습니다.

두번째 자리는 메이저 버전에서 기능을 추가하거나 변경 사항이 있을 때 바꾸는 게 보통입니다.
두 번째 자리를 마이너(minor) 번호라고 합니다

세번째 자리는 버그 수정이나 아주 소소한 변화가 있을 때 바꾸게 됩니다. 패치(patch) 번호라고 합니다.

세 번째 뒤에 alpha, beta, release 등을 함께 붙여 사용하기도 합니다.
가령, 1.0.0-alpha, 1.0.0-beta, 1.0.0-release 와 같은 식입니다.

alpha는 내부 테스트 버전,

beta는 개발단에서 개발이 완료되면 유저들에게 일부 배포를 해서 사용할 수 있도록 해서 추가 문제가 없는지 확인하는 단계를 가집니다.

그럼 1.0.0-beta 버전에서 버그를 수정해 패치했다고 하면 버전이 어떻게 될 수 있을까요?
1.0.1-beta와 같이 패치 번호를 올려서 추가 배포하게 됩니다.

메이저, 마이너, 패치의 세 자리 표기는 SemVer 방식이라고 해서

Semantic Versioning의 약자로써 버전을 관리하는 형식 중 하나로

많은 소프트웨어가 이러한 형식을 따르지만 이것도 꼭 모두 그런 것은 아닙니다.

이 외에 버전을 나타내기 위해 사용하는 용어로 RC, GA, CBT, OBT 가 있습니다.

RC는 Release Candidate의 줄임말로 beta 버전과 같은 의미로 안정적인 동작을 보장하지 않는 버전으로 이해하면 되겠습니다. Candidate는 후보자, 지원자라는 뜻으로 Release(릴리즈) 될 후보 버전이라는 의미가 되겠습니다.

1.0.0-rc1 , 1.1.0-rc2 이런 식으로 표기하는 경우입니다.

GA는 General Avaliability의 줄임말로 정식 릴리즈 버전을 의미하며 안정된 버전을 나타냅니다.

CBT, OBT는 버전이라기 보다는 베타 버전의 제품을 어떻게 테스트하느냐에 대한 구분이라고 할 수 있습니다. CBT는 Close Beta Testing, OBT는 Open Beta Testing의 줄임말인 것처렴 CBT는 제한된 인원, 허가된 인원에 대해서만 베타 버전으로 테스트를 하는 것이며, OBT는 테스트 인원을 더 늘려서 모든 이용자들이 베타 버전을 사용할 수 있도록 하는 것입니다.

버전에 대해 한번 정리해 봤습니다.

버전을 표기하는 방법까지 알아 봤습니다만,

버전은 사용자(유저)들이 확인 가능한 정보이지만,

서비스 또는 프로그램을 제작하는 입장에서는 버전별로 코드를 관리하고 있습니다.


3. 버전(Version) 관리의 필요성

혼자 개발 공부를 하는 경우가 아니라, 상용 소프트웨어를 개발한다면,

다시 말해 유저(사용자)가 이용하는 제품으로써

소프트웨어를 개발하는 경우라면 반드시 버전은 관리되어야 합니다.

과거 버전 관리 시스템이 없거나, 사용을 하지 않았더라도 나름 버전 관리를 하고 있었습니다.
서버의 설정 파일을 변경할 때도 이름을 바꿔서 복사본을 만들어 두고, 변경할 작업을 했던 기억이 납니다.

프로그램 소스를 변경할 때도 마찬가지였습니다.

심지어 주기적으로 폴더 단위로 이름을 달리해서 백업을 해 두어 가면서 작업했습니다.

지금 생각하면 정말 무식하게 했었다는 생각이 듭니다. ㅎㅎ

하지만 이 또한 나름의 "버전 관리"였던 것입니다.

여러분 대부분은 다른 사람들이 개발했던 소스를 분석해 가면서 개발하게 됩니다.
왜냐면, 회사에 개발자로 취업을 한다면

이미 서비스되고 있는 소스를 수정/보완하는 것부터 시작하게 되는데

이것은 이미 만들어져 있는 프로그램 소스를 열어서 수정하게 됩니다.

그런데, 처음부터 최근 코드까지 작성했던 개발자가 회사에 아직도 남아 있는 경우는 드뭅니다.
그래서 어떤 식으로 개발을 했고 주의해야 할 부분들은 무엇인지 전혀 알 수가 없습니다.

즉, 히스토리를 알 수가 없으므로 난감한 경우가 종종 있습니다.

이럴 때 언제 누가 무엇을 수정했는지 알 수 있다면 많은 도움이 됩니다.

주석이라도 꼼꼼이 잘 작성되어 있다거나 문서화되어 있어도 다행입니다. 하지만 이런 경우는 잘 없습니다.
이럴 경우 버전 관리가 되어 있다면, 차근차근 히스토리를 따라가 볼 수 있습니다.

하지만 솔직히 버전 관리가 되어 있다고 해서

이렇게 히스토리를 따라가 보면서 살펴볼 여유는 실무에선 여의치 않는 게 사실입니다. ㅠ.ㅠ

가장 버전 관리가 필요한 이유는 다음의 경우라 생각됩니다.

기능을 하나 추가해서 적용을 했는데 알 수 없는 버그가 발견되어 빠르게 수정을 해야 하는데,

원인을 파악하고 수정/적용까지 시간이 다소 걸린다면

빠르게 이전에 문제없던 상태로 일단 적용해두는 것이 필요합니다.

이전으로 빠르게 돌리려면 이전 버전의 소스가 필요합니다.

이럴 경우를 대비해서 필자는 과거에

무식하게 다른 이름으로 디렉토리 전체를 백업을 해 두고 새로운 작업을 시작했습니다.

또, 같은 프로그램을 여러 사람이 함께 개발해야 하는 경우라면

각자 수정했던 부분을 합쳐야 할 때도 사람이 일일이 합친다면 파일이 한두 개가 아니기에 막막하게 됩니다.

Git 협업 플로우
Git 협업 플로우


그래서 과거엔 이럴 경우를 대비해서 같은 파일을 동시에 수정하는 일은 없도록 규칙을 정하곤 했습니다.
버전 관리 시스템을 이용하면 손쉽게 이러한 협업을 이뤄낼 수 있습니다.

버전을 관리해야 하는 이유는 작든 크든 아주 많습니다.


그럼 버전을 누가 어떻게 관리할 것인가?

당연히 사람이 전부 관리한다면 불가능하거나 많은 노력이 필요할 것입니다.
그래서 우리는 버전을 관리하는 시스템을 만들 필요가 있고 그 시스템의 핵심 소프트웨어를 알아 가고자 합니다.

그 소프트웨어 중 하나가 Git(깃) 입니다.

 

 

 

[전자책]Basic Git - 예스24

SVN을 사용할 때도 그랬지만, 버전 관리 시스템을 사용하면서 충분히 알지 못한 상태에서 당장 필요한 기능만을 익혀서 사용하는 경우가 대부분이었습니다. 어떻게 동작하는 지에 대한 이해는

www.yes24.com

 

댓글