Intro
VCS에 대해 글을 써 볼까 말까 참 많이 고민을 했다만....그래도 쓰긴 써야겠단 생각이 들었다. Git 명령어를 쓸 줄 아는 건 맞지만, 실무를 겪기 전 까지 Git을 제대로 썼다고는 떳떳하게 말 하기 힘들었다.
많은 팀에서는 Git을 사용한다. 아니 사실상 표준처럼 굳어진 것 같다. SVN을 쓰는 팀을 여태까진 본 적이 없다. 그 만큼 Git이 가지는 영향력이 크기도 하고, 한번 배우는 게 쉽지 않을 순 있어도 배워 두면 강력한 무기로 사용 할 수 있으니까.
VCS : Version Control System
영어 그대로 버전을 관리하는 소프트웨어를 의미한다. SVN(SubVision), Git 이 대표적이다.
거의 90퍼센트 이상의 회사에서는 Git을 사용한다. 포스팅에서는 Git을 위주로 다루도록 하겠다.
VCS를 쓰는 이유?
소프트웨어의 유지 보수성은 정말 중요하다. 코드를 깔끔하게 짜든, 변수 명을 예쁘게 짓든, SOLID 법칙을 지키든 그렇게 하는 데 이유는 다 코드의 유지 보수성 때문이다.
유지 보수성이 높은 코드는 곧 오랜 기간 유지될 수 있고, 많은 사람들이 코드를 보고 쉽게 이해 할 수 있게 된다. 즉 서비스의 생명에 큰 영향을 끼친다.
특히 협업을 하게 된다면 이런 것들이 중요해진다.
개발 업무 중 소통을 하는 건 정말 쉬운 일이 아니다. 각자 자신만의 생각이 있고, 그 생각을 코드로 어떻게 표현하느냐의 답은 사람마다 조금 씩 다르다. 그리고 각자가 맡은 파트도 조금 씩 다르다. 모든 사람들이 다른 모듈들을 개발하니까 각자 잘 하면 될거 아닌가? 라고 생각 할 수도 있지만, 막상 합치려고 보면 여러모로 문제가 생긴다.
그러므로 현재 프로젝트에 코드가 어떻게 변경되고 있는 지, 누가 변경했는 지 추적 할 수단이 필요하다. 또한 문제가 생기면 변경 시킬 수도 있어야 한다. 많은 사람들이 병렬적으로 코드를 수정하고 합치는 과정에서 생길 수 있는 문제를 중재할 수 있어야 한다. 이 모든걸 사람이 하기에는 힘이 드는 법.
그러므로 VCS의 도움을 받는다. 에자일 한 프로그램 개발 프로세스를 위해서라도 VCS의 역할은 매우 큰 편이다.
Git
필자는 전역 이후 Github 플랫폼을 처음 다뤄보았다. 물론 그 당시에는 Github라는 플랫폼이 와 닿을 정도로 써 먹어 본 적은 없다. 기껏해봐야 학부 2학년 겨우 하고있는 사람이었으니까.
기본적인 명령어들을 약간이나마 이해 한 이후로 조금씩 Github를 써 먹기 시작했고 현재는 Git Model을 도입하여 크고 작은 프로젝트에 활용 해 보고 있는 상황이다.
Git은 정말 많은 사람들이 활용하고 있는 VCS다. SVN을 사용하는 곳이 없는 것은 아니나, Git의 분산 처리 기능(SVN은 반드시 서버를 한 대 두어야 하지만, Git은 그럴 필요가 없다.) 과 코드 충돌 방지를 위한 여러 안전장치 덕분에 Git 유저들이 현재는 거의 대부분이라고 할 수 있다.
특히 분산처리가 가능하다는 장점 덕분에 Github, Gitlab, Bitbucket과 같은 서비스가 등장했다.
명령어들에 대한 설명은 따로 하지는 않겠다.
Git Branching Model
그냥 Git을 쓰기만 해서는 체계적으로 개발을 진행하기 어렵다.
Github든 뭐든 처음에 쓸 때는 branch를 팀원들 이름으로 분리하여 작업 했던 기억이 난다.
각자가 맡은 부분을 개발해서 Master에 조금 씩 반영 해 나가는 것. 사실 그것만으로도 소규모 팀에서는 나름대로 체계적인 개발 방법이라 할 수도 있겠지만...몇 가지 문제가 있었다.
바로 Master에 반영하다보니 가끔씩 치명적인 에러가 생겼을 때 롤백하는 게 너무나 어려웠다.
실무를 뛰면서 이 부분에 대해서 완전히 새로운 경험을 해 보았다. 바로 Git Branching Model을 직접 써 본 것.
Master branch 그 자체는 최대한 안정적인 버전을 유지하도록 하는 데 목적이 있다.
Master 뿐 만 아니라 Dev, Release, Hotfix, feature 등 브랜치들을 목적에 따라 분리하는 모델을 의미한다.
Dev는 개발 상황에서 현재 반영되어있는 브랜치, Release는 알파라고 생각하면 된다. Hotfix는 Master에서 급하게 변경해야 하는 에러 사항을 처리하는 브랜치, feature는 기능 추가와 관련 된 branch다.
각 팀원들은 feature 를 통해 각자가 맡은 이슈를 처리하고 정기 배포 시 Dev branch 에 해당 feature가 완료되었을 경우 반영한다.
그 후 Dev에서 어느정도 테스트를 마친 후 알파 테스트를 위해 Release 브랜치에 Dev를 반영 후 최종적으로 릴리즈 할 수 있을 때 Master 브랜치에 반영한다.
Outro
간단하게 VCS, Git에 대해 알아보았다.
명령어야 사실 금방 적응하는데 Git을 통해 어떤 체계로 일을 하느냐? 에 익숙해지는 게 더 중요하다고 생각한다.
다음 포스팅의 주제는 대망의 DB다. OS 만큼이나 장기 시리즈가 될 것으로 예상된다....
Reference
