1.버전 관리 시스템

1-1.버전 관리의 필요성

컴퓨터로 하는 모든 작업의 결과물은 파일의 형태로 저장된다. 프로젝트를 진행함에 따라 소스나 문서는 계속 바뀌기 마련인데 일을 하다 보면 이전 문서를 참고해야 하는 경우가 있다. 내용을 계속 추가만 하는게 아니라 삭제할 경우도 있어 현재 문서만으로는 처음 내용을 정확히 알 수 없다. 즉, 문서의 이력 관리가 필요하다.

또 저장 장치를 신뢰할 수 없고 컴퓨터도 언제 고장날지 알 수 없으니 주기적으로 분리된 장소에 백업해 두어야 한다. 귀찮고 번거롭지만 백업은 지적 작업물을 지키기 위한 필수 조치이다. 이력관리와 백업을 위해 중간 중간에 사본을 떠 둔다. 용량 절약과 관리 편의를 위해 압축해 두기도 하고 파일명에 주요 변경 사항을 요약해 둔다.

이때 저장할 때마다 버전이 바뀐다. 여기서 버전(Version)이라는 용어는 이전 상태와 구분할 수 있는 관리 번호라고 생각하면 된다. 내용을 편집했건 작성자가 바뀌었건 저장한 날이 다르건 사소한 변화라도 발생하면 버전이 바뀌는 것이다. 위 예에서 초안, 수정본, 3월 24일 등으로 붙여 놓은 것이 바로 버전이다.

윈도우7, 윈도우10 처럼 운영제제에 붙이는 숫자나 갤럭시 24, 갤럭시 25처럼 제품에 붙이는 발표년도도 버전의 한 예이다. 문서 관리의 버전도 같은 용어이되 훨씬 더 잘게 나누어 사소한 변화에 대해서도 일일이 버전을 붙인다. 버전은 프로젝트 진행 시점의 스냅샷이며 내부적인 관리 번호이다.

이런 식으로 파일을 복사해 두는 작업은 상식적이고 쉽다. 누구든 이런 식으로 파일을 관리해 본 경험이 있을 것이다. 직관적이고 단순하지만 원시적인 방법인만큼 불편하고 단점도 많다.

▶ 항상 전체를 복사해 두므로 용량이 크다.

▶ 모든 변경사항을 다 저장하지는 않고 백업 중간 시점의 기록은 없다.

▶ 메모한 것만 보고 이전 내역을 정확히 찾아 비교하기 어렵다.

▶ 이전 내역에 원하는 부분을 찾아 가져오는 것도 만만치 않은 작업이다.

▶ 아무리 백업을 잘 해 놔도 백업 자체를 잃어 버리면 대책이 없다.

모든게 수동이다 보니 비효율적이다. 이런 작업을 자동화하여 한번의 명령으로 최소한의 변경 내역만 알아서 저장해 주는 것이 버전 관리 시스템(VCS, Version Control System)이다. 모든 변경 내역을 최소한의 용량으로 저장해 주고 이전 버전과의 비교도 일목요연하게 보여주며 원격지의 저장소에 안전하게 보관해 주기도 한다.

더 전문적인 용어로 형상관리(Configuration Management) 시스템이라고도 부르는데 파일 뿐만 아니라 개발 환경이나 빌드 구조, 배포방법, 문서까지 포괄한다. 버전 관리를 포함하는 더 넓은 개념이며 프로젝트를 수행하는데 필요한 모든 정보를 체계적으로 관리하는 시스템이다.

1-2.제품들

버전을 관리할 정도라면 최근의 대형 프로젝트에나 해당될 거 같지만 예상외로 역사가 오래 되었다. 1970년대에 본격적인 소프트웨어 개발이 태동할 때부터 팀 작업을 위해 적극적으로 도입했다. 세대를 거치며 점점 대형화, 지능화되면서 효율성과 안정성을 개선해 왔다.

집에서 혼자 취미로 하는 프로젝트라면 몰라도 회사에서 팀으로 작업하는 프로젝트는 다 버전 관리 시스템을 사용하고 있다. 즉, 취업해서 같이 일하려면 지금은 꼭 알아야 하는 필수 과목이다. 여러 제품이 많이 발표되어 있는데 어떤 식으로 발전해 왔는지 대충 이름만 봐 두자.

▶ CVS(Concurrent Versions System) : 1990년에 발표한 버전 관리 시스템의 태고적 제품이며 버전 관리의 기본 구조를 완성했다. 지금은 많이 쓰지 않지만 이후 제품에 많은 영향을 미쳤다. VCS의 원조가 바로 CVS이다.

▶ SVN(Subversion) : CVS를 기반으로 필수 기능을 추가한 업그레이드 버전이다. 커밋을 원자적으로 처리하여 일관성을 유지하며 디렉토리도 버전을 관리하고 브랜치 기능을 개선했다. 요즘도 간단한 용도로 사용하는 곳이 많다.

▶ Perforce : 거대 기업에서 주로 사용하는 엔터프라이즈급의 고가 시스템이며 병합 기능이 우수하다. 삼성전자에서 이 시스템을 사용한다.

초기의 버전 관리 시스템은 서버에 모든 파일을 저장하는 중압집중형이다. 서버가 막강한 통제를 하므로 일관된 관리가 가능하다는 이점이 있지만 서버에 문제가 생기면 골치아파진다. 이런 일이 발생하지 않도록 치밀하게 관리하지만 잠시라도 서버나 네트워크에 장애가 발생하면 프로젝트 진행이 멈춰 버리니 치명적이다.

이런 고질적인 문제를 해결하기 위해 이후의 시스템은 분산형을 도입했다. 서버에 모든 것을 의존하지 않고 로컬에 각각의 사본을 유지함으로써 일정 시간 동안은 프로젝트를 계속 진행할 수 있다. 서버에 장애가 발생하더라도 로컬에서 사본으로 먼저 작업해 두고 서버 정상화 후 동기화하는 식이다.

분산형 버전 관리 시스템의 대표 선수가 바로 git이다. 서버없이 로컬에서도 프로젝트를 진행할 수 있어 유연성이 뛰어나며 클라우드 플랫폼과의 연동도 잘 되어 있어 대규모의 인원이 참여하는 협업도 가능하다. 그 외에 git과 유사하나 더 간편한 Mercurial이 있고 소규모에 적합한 Fossil도 많이 사용한다.

1-3.git의 역사

오픈소스 운영체제인 리눅스의 규모는 어마어마하며 참여자도 많아 소스 관리가 필수적이다. 당시의 SVN으로는 속도나 안정성을 확보하기 어려워 초기에 리눅스는 BitKeeper라는 상용 프로그램으로 버전을 관리했다. 성능적으로는 충분했으나 오픈소스를 만드는데 상용 프로그램을 사용하는 것은 어울리지 않는다는 지적이 있었다.

BitKeeper 제작사는 리눅스를 만들어 낼 정도의 개발자라면 리버스 엔지니어링으로 똑같은걸 만들어낼 위험이 있다고 판단하여 일부 핵심 개발자의 접근을 제한하는 조취를 취했다. 이에 격분한 리누스 토발즈가 그럴거면 우리가 만들어 쓴다 하고 2주만에 번개같이 만들어 낸게 바로 git이다.

리눅스 창시자가 만들었다는 유명세에 힘입어 급속히 전파되었다. 수많은 개발자가 벌떼같이 달려들어 광속으로 기능을 늘리더니 기존 제품을 모두 능가하는 압도적인 위치에 올라서 버렸다. BitKeeper는 반성문 제출하고 심지어 무료로 제공하겠다고 나왔지만 이미 늦었다. 파워 개발자 한명의 파워를 실감할 수 있는 상징적인 사건이다.

처음 발표한 2005년 이후 git은 버전관리의 대명사가 되었으며 구글, 트위터 등의 대기업도 git을 사용하기 시작했다. 심지어 오픈소스에 적대적이었던 마이크로소프트조차 git을 사용하며 비주얼 스튜디오에도 연동 기능을 넣었다. 지금은 대표적인 저장소인 github도 사 버렸으며 윈도우도 git으로 관리한다.

이전의 버전 관리 시스템은 서버를 중심으로 한 중앙 집중적인 관리를 하는데 비해 git은 로컬 저장소를 따로 유지하는 분산형이라는 면에서 독특하다. 각 개발자의 컴퓨터에 전체 소스를 받아 놓고 개발한 후 서버의 소스와 합치는 방식이다. 분산형은 중앙 집중식에 비해 여러 가지 장점이 있다.

▶ 서버가 일일이 개입하지 않아도 되므로 속도가 빠르고 서버의 부담이 덜하다.

▶ 서버가 다운되어도 로컬에서 얼마간은 오프라인 작업이 가능하다.

▶ 로컬에서 서버로 올리기 전의 상태를 면밀히 점검할 수 있다.

그러나 한 단계를 더 거침으로 인해 복잡도가 증가하는 단점이 있다. 소스가 양쪽에 있어 동기화하는 작업 단계가 복잡하고 특정 명령의 효과를 정확히 알려면 경험히 쌓여야 하니 초보자의 접근성이 떨어진다. 또 저장소 하나가 프로젝트 하나인 구조여서 일부만 가져와 작업할 수 없고 항상 전체를 다 받아와야 작업을 할 수 있다.

git은 버전관리툴로도 유명하지만 오픈소스를 배포하는 수단으로서도 중요한 역할을 담당하고 있다. 예전에는 오픈소스를 압축 파일로 묶어 배포했지만 요즘은 git에 등록해 두고 누구나 참고할 수 있도록 공개한다. 그래서 git을 모르면 오픈소스를 활용하기 어렵고 오픈소스 개발에 참여하는건 더 어렵다.

git의 이름이 의미하는 바는 공식적으로 알려져 있지 않다. 어떤 문장의 줄임말일 듯 하고 g는 아마도 GNU가 아닐까 추측되지만 제작자가 정확히 밝히지 않았으니 알 수 없다. 발음이 애매한데 공식 발음은 [git]으로 되어 있다. 한글로 읽거나 표기할 때도 '깃'이라고 쓰며 '기트'나 '짓'이라고 하지는 않는다.

1-4.깃 서비스

git은 버전을 관리하는 방법을 정의하는 시스템일 뿐이며 그 자체가 소스를 저장해 주지는 않는다. 버전별 소스를 안전하게 저장하려면 물리적인 저장 장치가 있어야 하고 여러 사람이 동시에 읽고 쓰려면 고속 네트워크도 구축해 놓아야 한다.

실제 소스를 관리하는 주체는 깃 서비스이다. 대용량의 저장 장치와 고속의 네트워크 연결이 필요하므로 상당한 자본이 소요된다. 개인 사용자는 무료로 쓸 수 있지만 기업은 일정한 비용을 내야 쓸 수 있다. 여러 업체에서 깃 서비스를 제공하는데 다음 3가지가 제일 유명하고 많이 쓴다.

▶ github : 대표적인 깃 서비스이며 오픈소스의 성지이다. 무료 사용자는 프로젝트를 의무적으로 공개해야 했으나 현재는 3인 이하의 소규모는 비공개로 사용할 수 있다.

▶ Bitbucket : 비공개 프로젝트를 생성할 수 있다. 이슈 관리 시스템인 Jira와의 연동이 쉽다. 구글의 크로미움(CEF) 같은 대형 오픈소스가 여기에 있다.

▶ gitlab : 규모에 상관없이 비공개 프로젝트를 생성할 수 있다. 서비스 자체도 오픈소스이며 NASA 프로젝트를 여기서 관리한다.

git과 github를 잘 구분하자. git은 소스 관리 시스템이며 실체가 없는 무료 소프트웨어일 뿐이다. 반면 github는 소스를 저장하는 물리적인 저장장치와 네트워크를 제공하는 서비스이며 돈 내고 쓰는 것이다. 개인이 리눅스 환경에 깃 서버를 설치하여 직접 운영할 수도 있지만 관리가 쉽지 않다.

서버가 제공하는 깃 서비스를 제대로 활용하려면 로컬에서 동작하는 깃 클라이언트가 필요하다. 서버에 저장된 버전을 다운로드받고 로컬에서 작업한 후 다시 업로드하는 등의 동작을 한다. 이것도 여러 가지 제품이 있다.

▶ CLI : 깃 자체가 제공하는 공식 클라이언트이다. 명령행 방식이라 불편하지만 깃 설치 후 바로 쓸 수 있어 간편하고 모든 기능을 제공한다는 점에서 강력하다.

▶ github Desktop : 깃허브가 제공하는 공식적인 클라이언트로 GUI인만큼 쓰기 편하고 직관적이며 깃허브와의 연동성이 좋다.

▶ 토터스 깃 : 윈도우 탐색기의 팝업 메뉴를 통해 소스를 관리할 수 있다는 면에서 편의성이 높다. 그러나 윈도우 한정이라는 면에서 제약이 있다.

▶ 소스 트리 : 기능이 많고 편리하지만 사용법은 복잡한 편이다. 깃허브는 물론 비트버킷과도 연동성이 좋다.

이상은 다 무료로 쓸 수 있는 클라이언트이며 상용으로는 GitKraken, SmartGit 등의 고기능성 제품도 있다. 그래픽 환경의 클라이언트는 보기 좋고 쓰기도 편하지만 내부에서 어떤 처리가 일어나는지 직관적으로 알기 어렵다.

처음에는 좀 불편해도 CLI 환경에서 명령어를 두들겨 가며 배우는 것이 느려도 확실한 방법이다. 실무에서는 더 효율적인 툴을 쓰더라도 일단은 깃이 어떤 방식으로 동작하는지 이해하는 것이 중요하므로 배울 때는 무조건 CLI로 시작하는 것이 바람직하다.

1-5.설치

깃은 오픈소스이며 누구나 무료로 받아 사용할 수 있다. 다음 사이트에서 맥, 윈도우, 리눅스용을 모두 제공한다. 여기서는 윈도우 64비트 버전을 기준으로 하되 다른 환경에서도 큰 차이없이 쓸 수 있다.

https://git-scm.com

버전은 수시로 바뀌는데 24년 11월 최신 버전은 2.47.0이다. 업데이트가 꽤 자주 있는데 만약 이전 버전이 설치되어 있다면 해제 후 맞는 버전으로 재설치하자. 크게 바뀌는 부분은 없으며 하향 호환성은 웬만하면 유지한다.

설치 과정은 깃 동작 환경을 설정하는 질문의 연속이다. 아직 의미를 잘 모르니 웬만하면 디폴트를 받아들이되 일부 옵션은 꼭 바꿔야 하는 것도 있어 무조건 Next를 눌러서는 안된다. 설치할 폴더와 구성요소는 무난하게 설정되어 있다. 시작 메뉴의 옵션은 Git으로 받아들인다.

다음은 기본 편집기를 묻는데 디폴트는 vim으로 설정되어 있다. vim은 익숙해지면 강력한 편집기이나 현대적인 GUI 환경에는 어울리지 않는다. 역사적인 이유로 vim을 디폴트로 제시하지만 웬만하면 그래픽 편집기를 선택하라고 되어 있다. Notepad++이나 VSCode 등이 무난하나 설치해 놓지 않았다면 제일 아래쪽에 있는 메모장을 선택하자.

여기서 선택한 기본 편집기는 커밋 메시지를 수정하거나 소스의 현재 상태를 보여줄 때 자동으로 열어줄 편집기일 뿐 개발에 쓰는 것은 아니다. 비주얼 스튜디오나 이클립스로 개발하고 있다면 소스 편집은 당연히 통합 개발 환경 내의 편집기를 사용한다.

다음은 초기 브랜치의 이름을 선택한다. 브랜치는 프로젝트의 흐름을 뜻하는 용어이되 최초 루트에서 시작하여 기능의 변화가 있을 때마다 브랜치를 분리하여 병렬 개발할 때 쓰는 개념이다. 상세한 의미는 다음에 배우되 일단 루트 브랜치의 이름을 선택해야 한다. 첫 브랜치의 이름이 왜 중요한지는 역사적인 설명이 필요하다.

git의 예전 버전에서는 첫 브랜치의 이름이 master였으며 master로부터 세부 브랜치를 분기해 나가는 식이었다. 그런데 master의 반대말은 slave이고 이는 주인/노예 식으로 주종관계를 상징하는 인종차벽적인 용어라는 면에서 부적절하다는 지적이 있었다. 그래서 지금은 main으로 이름을 바꿀 것을 권장한다.

프로젝트의 분기는 기능적 차이이지 예속 관계가 아니므로 꼭 틀린 지적은 아니다. 그러나 어차피 구분을 위한 용어일 뿐인데 여기서 인종차별을 떠올리는 것은 너무 예민한 반응이기도 하다. 디폴트는 여전히 master로 되어 있는데 아직도 이 용어를 쓰는 프로젝트가 많기 때문이다.

여기서는 두 번째 옵션을 선택하여 권장한대로 main으로 바꾸자. 이름을 바꾸는 것은 많은 혼란을 야기하지만 2020년부터이니 이제 바꿀 때도 되었고 gitlab, bitbucket 등도 모두 main으로 바꾸는 추세여서 따르는게 좋다. 첫 브랜치의 이름이 맞지 않으면 귀찮은 일이 발생하므로 두 번째 옵션을 선택하자.

이후 명령행에서의 경로 처리, 보안 서버 접속 방법, 텍스트 파일의 줄 끝 처리, 터미널 에뮬레이터의 종류 등을 계속 질문하는데 모두 디폴트를 받아들이자. 어떤 옵션을 선택하는가에 따라 미세한 변화는 있지만 처음 설치하는 단계에서 이걸 다 결정하기는 어렵다. 차후 필요할 때 옵션을 변경하는 것이 좋다. 모든 옵션을 다 선택하면 설치를 진행하고 완료 후 다음 대화상자가 나타난다.

Finish 버튼을 누르면 설치가 완료되며 이후 git을 사용할 수 있다. 설치용량은 400M로 GUI가 없는 것 치고는 굉장히 크다. 원래 git이 리눅스에서 개발된 시스템이고 실행도 리눅스 기반이기 때문이다. 윈도우에서 실행하려면 리눅스 환경을 그대로 구현해야 하는데 이게 MinGW(Minimalist GNU for Windows)이다. 쉽게 말해 윈도우 안에 리눅스 개발 및 실행 환경을 하나 더 깔아 놓은 셈이며 그러다 보니 용량이 작지 않다.

1-6.실행

시작 메뉴에 깃 프로그램이 등록되어 있으며 여러 가지 실행 방법을 제공한다. 제일 위에 있는 Git Bash가 무난하다. 리눅스 터미널을 그대로 에뮬레이션하는 환경이며 리눅스를 쓰듯이 명령행에서 깃을 사용한다.

Git CMD는 윈도우의 명령행이되 깃을 위한 환경 변수가 설정되어 있다. 리눅스 명령 대신 윈도우 명령(정확하게는 도스 명령)을 쓸 수 있어 친숙하다. 예를 들어 파일 목록을 볼 때 ls 대신 dir 명령을 사용하고 삭제할 때 rm 대신 del 명령을 쓰면 된다. 쉘 관련 명령 외에 깃 명령어는 별반 차이가 없다.

옵션은 시스템 메뉴의 Options... 명령으로 조정한다. 디폴트도 무난하지만 기본 글꼴이 9pt로 작은 편이다. 고해상도 모니터에서는 눈이 아플 지경이므로 12pt나 14pt 정도로 넉넉하게 키워서 쓰는게 좋다. Looks 탭에서 색상을 변경할 수 있는데 디폴트인 검정 바탕에 흰색도 편안하게 볼만하다. 취향에 따라 옵션을 적당히 조정하자.

프롬프트에는 현재 로그인한 사용자와 시스템 명칭이 보이며 홈 디렉토리에 있다는 ~ 표시가 되어 있다. 아래줄의 $는 명령 입력 대기상태라는 뜻이며 이 기호 다음에 명령을 내린다. 간단한 명령 몇 개를 내려 보자. 이 강좌에서는 사용자가 직접 입력하는 명령은 파란색으로 표시한다.

soen@SoenDesk MINGW64 ~

$ git --version

git version 2.47.0.windows.1

soen@SoenDesk MINGW64 ~

$ pwd

/c/Users/soen

깃 버전과 현재 디렉토리를 조사하여 출력했다. git은 깃 실행을 위한 명령이라는 뜻이며 모든 깃 명령은 git 다음에 온다. 옵션을 지정할 때는 - 기호를 앞에 쓰는데 -m, -p 처럼 한 글자 옵션은 -를 하나만 쓰고 두 글자 이상은 가독성을 위해 --를 두 개 쓴다. 그래서 -version이 아니라 --version이다. POSIX의 관례이며 git은 이를 따른다.

pwd는 현재 디렉토리를 확인하는 쉘 명령이다. 깃 명령이 아니므로 git으로 시작하지 않는다. git이 실행되는 환경은 리눅스이므로 리눅스 스크립트에 대해서도 기본 학습이 되어 있어야 한다. cd, mkdir, ls, rm 정도는 알아야 하는데 이 정도는 리눅스 강좌만 대충 읽어 봐도 알 수 있다. 자신 없으면 파일 관리를 탐색기에서 하면 되느 너무 걱정하지 말자.

종료할 때는 exit 명령을 사용하거나 타이틀바의 X 버튼을 눌러 창을 닫아 버리면 된다. 작업중이 아닌 한 군말없이 조용히 사라진다.

1-7.사용자 등록

깃은 여러 사람이 참여하여 공동 개발할 수 있는 협업 시스템이다. 팀 내의 동료 뿐만 아니라 전세계의 개발자들과 협업할 수도 있다. 소스를 수정하여 업로드할 때마다 깃은 누가 언제 어떤 변경을 가했는지 모두 기록한다. 따라서 개발에 참여하는 모든 사람은 자신의 신분을 명확히 밝혀야 한다.

깃 설치 직후에 가장 먼저 해야 할 작업이 나를 정의하는 것이다. 등록해야 할 정보는 이름과 이메일주소이다. 이름을 개발자 식별자로 사용하는데 동명이인이 있을 수 있으므로 이메일 주소도 같이 밝힌다. 사용자를 등록할 때는 git config 명령을 사용한다.

git config --global user.name 사용자명

git config --global user.email 이메일주소

--global 옵션은 참여하는 모든 프로젝트에 이 정보를 전역적으로 쓰겠다는 뜻이다. 대개의 경우 이름이 바뀌지 않지만 참여하는 프로젝트에 따라 다른 이름을 쓸 수도 있는데 이때는 각 프로젝트마다 이름을 따로 등록하면 된다. 예를 들어 회사 프로젝트에서는 kimpro ID를 쓰고 취미로 하는 게임 개발 프로젝트에서는 nalari ID를 쓰기도 한다.

국제화 시대에 맞게 이름은 가급적 영문으로 된 ID를 쓰는 것이 바람직하다. user.name 설정에 사용자명, user.email 설정에 메일 주소를 지정한다. 명령행에서 다음 두 명령을 실행하여 사용자를 등록한다. 물론 그대로 따라하면 안되고 여러분의 이름과 이메일 주소로 등록해야 한다. 남의 숙제를 베끼더라도 학번이랑 이름은 바꿔야 하는 것과 같은 이치이다.

soen@SoenDesk MINGW64 ~

$ git config --global user.name soen

soen@SoenDesk MINGW64 ~

$ git config --global user.email soenmaster@naver.com

사용자를 등록한다고 해서 딱히 바뀌는 것은 없다. 이 정보는 기록만 해 두었다가 차후 프로젝트를 수정하여 업로드할 때 사용한다. --list 옵션으로 현재 설정을 확인해 보자.

soen@SoenDesk MINGW64 ~

$ git config --list

diff.astextplain.textconv=astextplain

filter.lfs.clean=git-lfs clean -- %f

filter.lfs.smudge=git-lfs smudge -- %f

filter.lfs.process=git-lfs filter-process

filter.lfs.required=true

http.sslbackend=openssl

http.sslcainfo=C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt

core.autocrlf=true

core.fscache=true

core.symlinks=false

core.editor=notepad

pull.rebase=false

credential.helper=manager

credential.https://dev.azure.com.usehttppath=true

init.defaultbranch=main

user.name=soen

user.email=soenmaster@naver.com

기본 편집기가 메모장으로 지정되어 있고 첫 브랜치명은 main으로 되어 있다. 제일 아래쪽에는 이름과 이메일이 등록되어 있다. 특정 설정만 보려면 git config user.name식으로 설정의 이름을 지정한다.