VCS(Version Control System) 이야기

예전에 그날그날 작업에 대해 note.txt 파일에 변경사항을 적고 소스코드를 압축해서 ftp/smb를 통해 백업서버의 스토리지 지분율을 차지하던 분이 문득 생각이 났다. VCS보다 이 방법이 훨씬 더 좋다는 말을 전해 들었었고, 난 아직도 이 방법의 장점을 하나라도 찾기 위해 노력중이다. 내 개발인생 최고의 궤변 중 손에 꼽힐 정도의 에피소드이다.

로컬 세팅, 중간 파일, 빌드 결과물 등등 까지 압축하진 않았는지 문득 궁금해지지만 이제 확인할 수 없는게 너무 아쉽다.

나는 압축하여 버전관리를 하는 시스템을 SVCS라고 명명했다. Self-VCS(가내수공업 버전관리)라고 주변에 설명하긴 하지만 숨은 본래의 뜻이 있다. tq?

처음 개발을 시작할 때는 VCS로 CVS를, 이후에는 SVN을 사용했다. 회사에 이미 개발 프로세스가 정립되어 있었으므로 별다른 생각을 하지 않고 사용했던 것 같다.

하지만 이걸 사용하면 할 수록, 협업 인원이 많아질수록 불만이 쌓여갔다. 내가 기존의 VCS를 사용하면서 겪었던 큰 불편함은 다음과 같다.

• 원격지에 바로 커밋되므로 서버가 꼭 있어야하며, 서버에 문제 발생시 커밋 불가
• 실수로 커밋을 할 경우 서버에 바로 적용되므로 다른 사람에게 피해를 줄 수 있고 증거인멸이 쉽지 않음

PoC(Proof of Concept)정도의 작업을 위해 항상 서버에 레포지토리를 생성하여 관리하는 것이 항상 귀찮음으로 다가왔었다. 레포지토리를 만드는게 얼마나 귀찮냐 싶겠지만 보통은 관리자에게 레포지토리 생성을 요청했어야 했기에…

또한 커밋 메시지에 오타가 있거나 파일을 잘못 올렸을 경우 롤백하는 과정에 발생되는 히스토리가 마음에 들지 않았다. 이 히스토리를 깨끗하게 정리할 수는 있지만 실수 한번에 치뤄야 하는 작업이 너무 커서 쉽게 할 수 있는 작업은 아니었다.

그리고 시간이 지나 알게 된 것이 DVCS(Distributed-VCS)인 git이다. mercurial이라는 녀석도 있었지만 무슨 이유에서인지 금세 놓게 됐던 것 같다. git은 내가 지금까지 겪었던 문제들에 대한 해결사로 자리매김했지만 이미 SVN으로 구축된 개발 프로세스를 git으로 바꾸는건 쉽지 않았다. ‘이걸로도 지금까지 잘 개발했잖아?’, ‘왜 일을 만드냐?’ 라는 식의 피드백은 내 의지를 꺾이게 할 수 밖에 없었다. 우격다짐으로 개발 프로세스를 바꿀 위치에 있지도 않았기 때문에 git을 알면서도 한동안 SVN을 사용할 수 밖에 없었다.

그 사이에도 git의 인기는 빠르게 증가하고 있었고 다행히 얼마 지나지 않아 실무에서도 git을 쓸 수 있게 되었다. 조금 더 시간이 흘러 GitHub와 GitLab을 알게 되면서 이보다 더 좋은 통합 형상관리 솔루션이 나올까? 라는 생각을 가지게 되었던것 같다.

GitHub는 엔터프라이즈 환경이 아니면 온프레미스를 지원하지 않기 때문에 보안이 중시되는 곳에선 GitLab을 셀프호스팅하여 사용했고 그 이외의 곳에서는 GitHub를 사용하게 되었다. 학습용도나 소규모 프로젝트라면 GitHub의 무료플랜으로도 개발에 전혀 지장이 없으므로 사용해본적이 없다면 꼭 한번 사용해 봤으면 한다.

소프트웨어 개발에 최고의 능력을 발휘하지만 디자인 작업이나, 문서 작업도 커밋 메시지만 잘 적어 놓는다면 diff/merge 기능정도만 포기하고 버전관리가 가능하다. SVCS보단 확실히 낫지 않을까?

하나의 툴, 서비스가 개발 프로세스를 획기적으로 바꾸어 놓는 세상이다. 이것들을 사용하지 않는다고, 예전의 것을 사용한다고 소프트웨어 개발이 불가능한 것도 아니다.

하지만 시대의 변화, 기술의 변화를 배척하고 사는건 자동차, 비행기를 내버려두고 두다리로 걸어서, 헤엄쳐서만 이동하겠다는 것과 무엇이 다르다고 할 수 있을까?