참고

• 글이 두서가 없습니다^^.. (개선해볼게요!)
• 학습했던 내용, 파생된 궁금증, 개인적인 생각 등이 본문 사이사이에 끼어있습니다.
• 그래서 잘못된 정보가 많을 수 있습니다..!😥
• 글 내용이나 제 생각이 잘못됐다면 댓글 남겨주세요. 같이 이야기해보고 싶습니다.
• 저작권 확인을 하고 사용하지만, 혹시나 사용한 자료의 저작권 문제가 있다면 댓글 남겨주세요. 바로 조치하겠습니다!

시작하며

오랜만에 팀을 이루어 개발을 하게 되었다. 평소처럼 브랜치 전략을 구상하고, 약속했던 흐름대로 소스코드를 합치기도 PR을 보내기도 했다. 하지만 얼마 지나지 않아 rebase and merge하는 부분에서 문제가 발생했다. 하지만 진짜 문제는 여태 git을 제대로 학습하지 않았던 나 자신으로부터 시작됐다. 팀원분께서 해당 이슈에 대한 의견을 제시했지만 동의하거나 반대하는 의견이 입 밖으로 나오지 않았던 것이다. 당시 팀원분의 해결 방안을 전혀 이해하지 못했으며, 방법대로 진행했을 때 어떤 결과가 나타날지 전혀 예상이 안 됐기 때문이다. 팀원분께 깃 공부 열심히 하겠다고 파워당당하게 말씀을 드렸고 12월쯤에서야 공부하기로 마음먹었던 학습을 땡기기로 결정했다.

앞으로 개인적으로나 팀 활동을 하면서 프로젝트 관리가 필요한 상황은 점점 더 많아질 것이다. 회사에 취직하게 된다면 그 중요성은 더 커질 것이며, 심지어 이슈가 발생했을 때 빠르게 이유를 파악하고 유연하게 대처할 수 있어야 할 것이다. 이번 학습의 목표는 아래와 같다.

1. CLI 환경에서의 명령어 사용을 통해 git을 다룰 수 있도록 한다.
2. git이 동작하는 원리를 이해하고 설명할 수 있도록 한다.

참고자료는 매 포스팅 하단에 작성할 것이지만, 베이스는 git-scm에서 제공하는 progit 교재를 통해 학습한다.

키워드

• 버전 관리
• 버전 관리 시스템 (VSC, Version Control System)
• 로컬 버전 관리 시스템 (Local VSC)
• 중앙집중식 버전 관리 시스템 (CVCS, Centralized VSC)
• 분산 버전 관리 시스템 (DVCS, Distributed VSC)

버전 관리 시스템

버전 관리란?

문서작업을 한다고 가정한다.
[고객의 이름, 연락처, 지역, 최근 방문일]의 데이터를 보관하라는 요구사항이 있었고, 이를 위해 스프레드 시트 편집기를 열고 데이터를 작성하고 저장한다.

며칠 뒤, 개인정보 보관법 변경으로 인해 고객의 연락처를 앞으로 보관하면 안된다는 명령이 떨어졌다. 그로 인해, 문서의 연락처 열 자체를 삭제하기로 결정했다. 아래처럼 문서를 편집하고 저장한다.

며칠 뒤, 해당 법이 3년 뒤부터 시행된다는 이야기를 전해 들었다. 다시 고객들의 연락처가 필요해진 상황이라서 해당 문서를 복원하려고 한다.

그런데, 이전 문서에 대한 정보는 어디에 있을까?
별도로 문서의 내용이 변경될 때마다 사본을 만들어두지 않았다면 과거의 작업 내용은 복원이 불가능하다.

왼쪽 사진은 사본을 만들어두지 않아 이전의 기록들을 찾아볼 수 없는 상황이다.
반면, 오른쪽 사진처럼 사본을 만들어뒀다면 과거의 기록들을 찾아보면서 이전에 사용했던 문서를 마치 지금 작업하던 것처럼 이어서 작업할 수 있다. 또한, 각 사본의 이름을 설정하는 등의 규칙으로 언제 변경된 문서인지 표기해두면 더 관리가 용이할 것이다.

여기서의 사본을 버전이라고 한다. 버전들을 관리하는 것을 통해 원하는 버전으로 작업 환경을 변경할 수 있으며, 원하는 시점의 작업 데이터를 다시 가져올 수도 있다.

왜 필요한가?

위의 상황은 스프레드 시트를 활용한 문서의 버전을 예시로 들었지만, 실제로 거의 대부분의 컴퓨터 파일들은 시간순서에 따른 변화를 기억해야 할 필요가 있다. 개발자라면 소스 코드 및 개발 문서를 시간순에 따라 버전 관리를 해둘 수 있다. 디자이너라면 디자인 설계서 및 도안 등을 관리할 수 있다. 그리고 이러한 버전관리의 개념은 매우 중요하다.

버전 관리 시스템의 이점은 이전 버전의 상태를 기억하는 것으로부터 파생된다. 버전에 따라 수정 내용을 비교해 볼 수도 있고, 실수로 파일을 훼손시켰다고 하더라도 쉽게 복구할 수 있다.

만약, 혼자서 작업하는 것이 아니라 팀 단위로 여러 명이 작업한다면 이러한 시스템을 통해 더 생산성 있는 관리를 할 수 있다. 예를 들어, 어떤 범위의 작업을 누가 했는지 알 수 있을 것이다. 어떤 오류가 발생했다면 누가 잘못을 했었는지 추적을 하는 것도 가능하다.

이러한 여러 이유들로 버전 관리가 필요하게 되며, 이러한 이점에 보다 가깝게 접근할 수 있는 체계가 연구되어왔다. 이를 버전 관리 시스템(Version Constrol System, VCS)이라고 한다.

버전 관리 시스템의 장점은 아래와 같다.

• 원하는 버전 상태로 자유롭게 움직일 수 있다.
• 작업물의 변경 이력을 관리할 수 있다.
• 버전에 따라 수정 내용을 비교할 수 있다.
• 누가 문제를 일으켰는지 추적이 가능하다.
• 파일을 잃어버리거나 잘못 고쳤을 경우에도 쉽게 복구가 가능하다.
• 예상하지 못한 문제가 발생 시 빠르게 대처 가능하다.

버전 관리 시스템

버전 관리 시스템의 핵심 모티브는 당연 버전을 작업 순서대로 기억하고 이를 활용하는 것이다. 이러한 목적을 효과적으로 표현하기 위해 다양한 시스템이 형성되었다. 그리고, 이러한 시스템을 적절하게 사용하도록 돕는 여러 소프트웨어 도구들이 만들어졌다. 버전 관리를 대표하는 시스템들의 아이디어를 정리해보았다.

로컬 버전 관리 시스템

문서 작업을 했던 가정으로 돌아가 본다. 버전관리를 위해서 나름의 규칙을 정해놓고 사본을 만들어뒀다. 하지만, 해당 사본을 보관하던 디렉토리 자체를 실수로 삭제했다면 또다시 복원할 수 없는 문제가 발생한다.

로컬 버전 관리 시스템은 이를 작은 데이터베이스에 저장하기로 했다. 해당 데이터베이스는 말 그대로 로컬환경인 내 자신의 컴퓨터 내부에 존재한다. 다만 저장하는 방식이 독특하다. 변경을 원하는 파일 전체를 저장하는 것이 아닌, 마지막 버전으로부터 변경된 사항들만 차곡차곡 저장한다. 해당 변경사항을 patch라고 부른다. 변경사항만 가지고 있기 때문에 하나의 patch만을 가지고서는 올바른 버전을 불러올 수 없다.

특정 버전으로 돌아가고 싶다면, 로컬 VCS는 처음부터 patch를 순서대로 불러와서 합친다. 그리고 사용자는 합쳐진 문서를 이용하여 작업을 진행할 수 있다.

물론 여기에도 앞선 상황과 동일한 문제가 존재한다. 데이터베이스가 로컬에 있기 때문에, 만약 로컬 내부 데이터베이스에 문제가 생긴다면 관리하고 있던 버전에도 문제가 생길 수 있다는 것이다. 또한, 로컬 환경이기 때문에 협업을 고려했을 경우 효율적으로 사용할 수 없는 시스템이다.

위의 문제들을 요약하면 아래와 같다.

• 로컬 데이터베이스에 문제가 발생할 경우 버전 관리 내역의 유지보수가 힘들어진다.
• 협업을 위해서 해당 방식을 이용할 수 없다.

중앙집중식 버전 관리 시스템 (CVCS)

기존 로컬 버전 관리 시스템에서 제기된 문제를 해결하기 위해서는 데이터의 보관/유지 안정성에 집중할 수 있는 별도의 데이터베이스가 필요하며, 해당 데이터베이스를 여러 사람끼리 공유할 수 있으면 보완될 것으로 보인다.

위의 사진처럼 모두가 공유할 수 있는 서버에 데이터베이스를 설치하면 버전 공유가 가능하다. 또한, 서버는 오로지 데이터베이스 관리의 임무만 가지고 있기 때문에 보다 더 안전하게 버전관리가 가능하다. 이 방식이 중앙집중식 버전 관리 시스템이다.(Centralized VCS, CVCS)

중앙집중식 버전 관리 시스템의 장점은 아래와 같다.

• 여러 사람들 간의 문서, 문서 버전의 공유가 가능하다.
• 중앙 데이터베이스를 하나만 관리하면 되므로 관리가 편하고 생산성이 향상된다.

하지만 중앙 서버 하나만을 관리하기 때문에 문제가 발생하기도 한다. 만약 서버에서의 문제가 발생하여 접속 불능상태가 된 경우, 프로젝트의 현시점을 기록/저장(commit)하는 작업조차 불가능하게 된다. 마찬가지로 협업을 진행하던 다른 동료들의 작업을 받아올 방법도 없기 때문에 작업 진행에 큰 문제가 발생한다. 또한, 서버내의 데이터베이스 관리가 잘 되어야겠지만 혹시 하나 서버의 데이터베이스 일부가 변형된다면 이전의 버전들이 무의미해질 수 있다. (심지어 버전기록이 삭제된다면..?!)

분산 버전 관리 시스템

중앙집중식 버전 관리 시스템에서는 서버의 버전관리에 문제가 생겼을 경우, 복원이 사실상 불가능하다. 왜 그럴까? 그 이유는 서버가 모든 변경 과정의 보관을 독점하고 있기 때문이다.

로컬의 컴퓨터는 서버에서 특정 버전의 파일을 가져와서 작업을 진행하고 있을 것이다. 다른 버전 상태에서의 스냅샷은 서버를 믿고 서버에 보관했기 때문에 로컬에는 버전과 관련된 그 어떠한 정보도 가지지 않는다. 따라서, 서버의 버전 기록들이 의도치 않게 변형된다면 이를 돌이킬 방법이 없다. 물론, 모든 버전의 스냅샷을 로컬 어딘가에 보관했다면 복원이 가능하다. 하지만, 중앙집중식 버전 관리 시스템을 사용한다면 애초에 그랬을 가능성이 매우 적었을 것이며 그럴 필요도 없었을 것이다. 왜냐하면, 로컬에 버전을 백업해놓는 방식은 로컬 버전 관리 시스템을 사용하는 방식보다 더 번거로울 것이며, 중앙집중식 버전 관리 시스템을 사용하는 목적을 포기하는 것과 같다고 생각했기 때문이다.

이를 해결하기 위해 분산 버전 관리 시스템(DVSC, Distributed VSC)이 도입되었다. 분산 버전 관리 시스템은 서버에서 로컬로 특정 시점의 상태를 가져오지 않는다. 대신, 버전 관리되고 있던 저장소를 그대로 가져온다. 위의 그림을 보면 이해가 가능하다.

기존의 중앙집중식 버전 관리 시스템은 서버에서 파일의 버전을 확인하고, 원하는 버전의 파일을 가져온 뒤 로컬에서 작업을 진행했다. 그런데, 분산 버전 관리 시스템에서는 서버가 가지고 있는 버전 변경 이력들을 로컬로 전부 가지고 오는 것을 확인할 수 있다. 또한, 가져온 버전들 중에서 내가 원하는 시점의 파일을 가지고 작업하는 그림으로 이해할 수 있다.

이렇게 되면, 서버의 버전 관리 책임이 약간은 줄어든다. 서버에서 문제가 발생해서 데이터 유실이 있더라도 여러 사용자들이 로컬로 가져온 데이터베이스를 이용하여 복원할 수 있다. 또한, 버전들이 로컬에 존재하기 때문에 자신의 로컬에서 버전관리를 할 수 있다는 장점이 있다. 이전에는 버전관리를 위해서 무조건 서버를 거쳐야 했다. 따라서, 서버가 먹통이 되더라도 로컬에서 추가적인 버전관리를 하면 되기 때문에 무리가 덜하다. 심지어 인터넷이 안 되는 기차나 비행기 안에서도 작업 후 새로운 버전을 등록할 수 있게 된다는 이점이 있다.

분산 버전 관리 시스템의 이점은 아래와 같다.

• 중앙 서버에 접속 문제가 발생해도 로컬에서 관리가 가능하다.
• 중앙 서버의 데이터가 변형/유실되어도 로컬의 히스토리를 이용해 복원이 가능하다.
• 특정 버전의 파일만 가져오는 것이 아니기 때문에, 로컬 환경에서 안전하게 여러 가지 실험 및 테스트를 하는 것도 편하다.
• 로컬에서 버전 관리가 이루어지기 때문에 속도가 빠르다.
• 인터넷이 동작하지 않는 환경에서도 버전 관리가 가능하다.

다만, 사용하기에 어렵다는 단점이 있어서 공부를 많이 해야 한다. 모르고 사용하면 여러 환경들이 꼬이게 되고 동기화 문제도 쉽게 발생한다. 대부분 개발자들이 사용하는 Git 역시 이에 속한다.

마치며

해당 개념을 이전에도 여러 번 학습했었지만, 역시나 대부분의 내용을 잊어버렸음을 이번에 공부하면서 다시 알게 되었다. 그리고 왜 분산 버전 관리 시스템이 도입됐어야 했는지도 학습정리를 꼼꼼하게 하면서 더 깊이 있게 생각해 볼 수 있었던 것 같다.

해당 글에서는 파일 하나를 예로 들었지만, 실제로는 이를 확장한 개념으로 디렉토리 내의 파일들 전부를 관리할 수도 있다. 더 나아가서 프로젝트에 사용되는 모든 디렉토리를 관리하는 것도 가능하다 (참고로 디렉토리도 파일이다). 앞으로는 이러한 가정으로 git에 대한 이야기를 정리할 생각이다.

참고자료

학습

• git-scm
• Introduction to Git and Types of Version Control Systems
• What do you know about Version Control System
• git snapshot
• 버전 관리 시스템

이미지 소스

문제 있을 시 연락주시면 삭제하겠습니다.

• git 버전관리와 관련된 이미지들