EDCAN
We are Creators
EDCAN
전체 방문자
오늘
어제

블로그 메뉴

  • 홈
  • 태그
  • 방명록
  • 분류 전체보기 (13)
    • 소식 (1)
    • 개발 (7)
    • 디자인 (0)
    • 대회 (0)
    • 교내 행사 (1)

공지사항

  • We are Creators, EDCAN

인기 글

최근 글

최근 댓글

hELLO · Designed By 정상우.
EDCAN

We are Creators

Git 1편: 개발에서 제일 중요한 버전 관리
개발

Git 1편: 개발에서 제일 중요한 버전 관리

2023. 4. 2. 19:07

개요

과거의 컴퓨터는 현재의 슈퍼컴퓨터보다 저장공간도 작으면서 훨씬 더 크고 거대했기 때문에 자료를 담아 가방에 넣을 수 있다는 사실조차 그 당시 사람들에게는 충격이었을 것이다. 시대가 빠르게 편하면서 고작 저장공간이 몇 메가밖에 되지 않았던 플로피디스크가 사라지고, USB가 등장하고, 이제는 인터넷 속도가 매우 빨라지며 클라우드에 대부분의 자료들을 저장하는 시대가 되었다.

 

하지만 개발의 영역에서는 단순하게 "자료를 저장"하는 그 이상의 것이 필요하다. 언제 누가 어떤 파일을 수정했는지도 알아야 하고, 문제가 발생할 경우 원래 상태로 롤백하는 과정도 필요하다. 이런 것을 "버전 관리 시스템" 즉 VCS라고 부른다. 이 글에서는 VCS가 어떻게 바뀌어왔는지, 현재 Git이라는 VCS가 등장하기까지 얼마나 많은 시간이 걸렸으며 사람들이 Git을 사용했어야 하는 이유에 대해 알아본다.


최초의 로컬 VCS

아주 오래전 사람들은 버전을 관리하기 위해 디렉토리 자체를 복사하는 아이디어를 냈다. 여러 디렉토리를 만들어서 시간에 따라 저장하는, 아주 원시적인 방법이다. 예를 들어 project라는 디렉토리를 복사해 project-2023-02-13이라고 새로 만드는 것이다. 나름 효율적인 방법이라고 생각할 수 있지만... 

 

사람은 AI가 아니기 때문에 잘못된 파일을 복사하기 십상이고 실수로 디렉토리를 날려먹기 일쑤다. 이런 이유로 사람들은 새로운 버전 관리 시스템을 찾기 시작했다. 이를 "로컬 VCS"라고 부른다. 말 그대로 로컬에서 버전을 관리하는 것이다. 데이터베이스를 하나 만들고, 각 파일의 버전을 관리하는 방식이다. 아직도 많은 회사에서 사용하고 있기도 하고, 가장 기본적인 파일 관리 시스템이다.


협업을 위한 CVCS

하지만 회사에는 나만 있는 것이 아니다. 다른 팀원들과 함께 프로젝트를 해야 하기 때문에 별도로 버전을 관리하는 서버를 만들고 각각의 클라이언트가 그 서버에서 파일을 받아 작업한 뒤 다시 그 서버로 파일을 보내는 방식이다. 이 방식이 정말 획기적인 시스템이었기 때문에 많은 시간동안 개발자들이 CVCS를 사용했다.

이 방식이 왜 획기적이냐면, 당신이 개발자 김씨와 개발자 박씨를 비롯한 수십명의 개발자들을 담당하는 팀 리더라고 해보자. 당신은 CVCS 서버만 관리하면 각각의 클라이언트가 무엇을 하고 있는지, 어떤 파일을 받았고 언제 수정이 이루어졌는지 알 수 있다.


분산 버전 관리 시스템, DVCS

하지만 판교 데이터 센터 화재에서 알수 있듯이(물론 판교 데이터센터 화재는 서버가 분산처리되지 않아 발생한 참사는 아니었다.) 데이터가 한곳에 있으면 예기치 못한 사고가 일어났을 때 큰 참사가 일어나게 된다. 또 클라이언트와 서버간의 네트워크가 유실되었을 경우 서버로 파일을 보내지 못하는 일도 발생한다. 게다가 오류가 있는 파일이 서버에 올라간다면 모두가 작업을 중단해야 한다.

 

현재의 Git이 채택하고 있는 DVCS는 과연 어떤 것일까? 쉽게 말하자면 중간 단계를 두는 것이다. 파일을 commit하면 먼저 개발자의 로컬에 저장한 후 push를 통해 서버에 올리는 것이다. 개발자 김씨가 모든 버전을 다 날려버려도 박씨의 로컬에서 예전에 존재하던 버전을 받아올 수도 있고, 박씨가 손상시킨 파일을 김씨의 로컬에서도 불러올 수 있는 것이다.


스냅샷 (SnapShot)

스냅샷이란 "특정 시점에서의 파일, 폴더 또는 워크스페이스의 상태"를 말한다. commit을 통해 파일들을 저장했을 때, 모든 폴더 구조와 저장소의 역사, 변경된 파일 등을 의미한다. 이런 방식 덕분에 어떤 파일만 바뀌었는지 알 수 있어 특정 부분만 원격 저장소에 저장할 수 있고 속도가 매우 빨라지게 된다.

 

아래 그림에서 총 바뀐 파일은 A, B, C 3개지만 각 단계에서는 1개의 수정된 파일만 받아오는 것이 그 예시이다.


체크섬 해시 (SnapShot)

체크섬이라는 용어는 검사합이라는 뜻으로, sha1 방식으로 파일 이름, 변경 사항 등을 조합하여 40글자의 해시로 만드는 것이다. 이 체크섬이라는 개념을 우리가 직접적으로 사용하지는 않지만 git에서 매우 중요하니 잘 알아두자. 체크섬은 아래처럼 생겼다.

24b9da6552252987aa493b52f8696cd6d3b00373

이 중에서 앞의 7글자를 잘라 커밋의 고유 번호로 사용한다. 


다음 포스트에서는 Git의 파일 관리 방식과 Git의 여러 상태들을 알아보자.

저작자표시 (새창열림)

'개발' 카테고리의 다른 글

[React.js] React Router 사용법  (0) 2023.12.13
[Python] Pandas에서 데이터 전처리 하기  (0) 2023.12.13
[Python] Pandas 기초 공부해보기  (0) 2023.12.13
EDCAN 10기 부원들을 위한 FireBase Guide 2  (0) 2023.06.12
EDCAN 10기 부원들을 위한 FireBase Guide  (0) 2023.06.06
    '개발' 카테고리의 다른 글
    • [Python] Pandas에서 데이터 전처리 하기
    • [Python] Pandas 기초 공부해보기
    • EDCAN 10기 부원들을 위한 FireBase Guide 2
    • EDCAN 10기 부원들을 위한 FireBase Guide
    EDCAN
    EDCAN
    선린인터넷고등학교 모바일 콘텐츠 동아리, EDCAN의 이야기입니다.

    티스토리툴바