이번 포스트는 형상관리에 대해서 적어볼까 합니다.
제 경험과 함께 공부하며 새롭게 알게된 사실도 같이 적습니다.
형상관리
아마 프로그래밍을 배우고 어느정도 익혔을 어렸을때는 정확히 형상관리에 대해 알지 못했습니다.
9년전 3인 프로젝트를 진행해야 했는데, 그 프로젝트의 규모는 생각보다 괜찮은 편이였습니다.
저를 제외한 두 사람은 소스코드 관리에 대해서 고민할 수 밖에 없었고 저는 이러한 개념도 없을 초보 시절이였죠.
전쟁의 서막
그중 한 사람이 SVN에 대해서 얘기하고 제안 했습니다.(아직도 생생하군요.)
나머지 한 사람이 “그럴 필요까지 있는가?”라며 반대했습니다.
결국 SVN을 사용하지 않기로 결정하고 개발에 착수했습니다.
우리는 나름 잘 개발했고 인터페이스도 그럭저럭 괜찮은 편이였습니다. 초반 며칠만 말이죠.
복병을 만나다
프로젝트에서 관리해야 할 파일은 점점 늘어만 갔습니다.
한 폴더 안에는 일련의 클래스와 헤더들(그때는 C++)이 넘쳐나기 시작했고 다른 사람이 개발한 소스코드를 네이트온으로 받아서 병합해야 하는 시간은 날로 늘어만 갔습니다.
소스코드 관리는 점점 힘들어지고 개발해야 하는 기능도 늘어만 갔습니다.
끝내
당시 한명이 짜증을 내면서 이짓을 언제까지 해야하는지 푸념했습니다.
그가 바로 SVN을 반대한 사람이였습니다.
형상관리를 해야하는 이유
앞서 제 이야기에서 형상관리를 해야하는 메세지가 담겨있습니다.
고작 3명으로 진행하는 프로젝트에서도 소스코드 병합과 배포등에 많은 시간을 할애 해야 했죠.
서로 개발하고있는 소스 버전도 달라서 누구에게는 있는 기능이 누구에게는 없어서 혼동이 오는 경우도 많았습니다.
거의 저 일화가 있은 1년정도 후에 공부하면서 SVN을 알게 되었고 제 무지함도 같이 깨닫게 되었습니다.
그 이후로 한참동안 SVN을 사용하면서 잘 개발해 왔습니다.
git이 제 곁에 훌쩍 다가와 있음에도 말이죠.
SVN과 git
SVN과 git은 형상관리를 해준다는 장점과 공통점이 있지만 차이점도 많습니다.
대표적으로 git은 local 기반의 저장소, SVN은 중앙(서버) 저장소를 사용하는 구조입니다.
위의 그림이 시각적으로 명확하게 보여주고있습니다.
이런 특성을 이용해 차이점이자 git의 장점이 또 있는데, 오프라인 작업이 가능하다는 것 입니다.
SVN에서는 코드를 원본에 커밋(푸쉬)할 때 온라인으로 중앙 저장소에 접근 가능해야 합니다.
로컬에서 변화가 있으면 중앙 저장소에 커밋해서 다른사람들이 받을 수 있도록 해야합니다.
이런 차이점은 단순히 인터넷접근이 불가능한 공간에서 작업이 가능하다는 장점만을 말하는 것이 아닙니다.
중앙 저장소의 고장으로 인해 발생할 수 있는 예외나 불편함을 피할 수 있습니다.
git을 사용하면 로컬에 커밋해놓고 중앙 저장소가 정상화 되었거나 복구되었을때 커밋을 푸쉬하면 됩니다.
SVN에서 커밋, 푸쉬의 영역이 모호했다면 git에서는 커밋이 로컬 저장소에 저장, 푸쉬가 중앙 저장소에 반영 정도가 될 것입니다.
브랜치에 관하여
SVN에서는 저장소에 실제 파일들을 저장합니다.
브랜치의 개념은 폴더로 구분 짓습니다.
조금 더 쉽게 풀어쓰자면, 어떤 기능을 개발하기 위해 브랜치로 분리해서 작업하게 되면 시스템에 독립된 폴더가 생성되고 그 공간에서 작업하게 됩니다.
반면 git의 경우 해시로 관리되고 이 해시에 이름을 붙인것입니다.
이 내용은 복잡하므로 간단히 얘기하면 SVN처럼 폴더를 새로 만들어서 복사본을 만드는 것이 아닙니다.
마치 각자 파일들이 바뀌는 것 처럼 동작하게 됩니다.
개발자는 작업중인 공간에서 계속해서 작업하면 됩니다.
개인적으로
브랜치를 나누는 방법에 대해서 주변 사람들과 이야기 하곤 하는데 정답은 없다고 생각합니다.
다만 어느정도의 가이드가 있으면 좋을 큰 틀은 머릿속에 있는데요.
Master 브랜치는 지금 당장 배포할 수 있는 수준의 코드를 관리합니다.
Dev 브랜치를 만들어 다음 버전에 반영될 Feature들이 모일 브랜치로 관리합니다.
나머지는 Feature 단위로 각자 브랜치를 만들어서 개발하고, 개발이 완료되면 Dev에 머지합니다.
반영할 Feature 브랜치들이 모두 머지되면 Dev로 부터 Release 브랜치를 만들어 테스트합니다.
이때 발생된 버그들을 모두 Release 브랜치에서 처리하여 Dev와 Master로 병합하고 배포합니다.
배포가 완료되고 Release, Feature 브랜치들이 필요없다고 판단되는 시점에서 브랜치를 삭제합니다.
Master, Dev는 계속해서 관리하여 개발을 진행합니다.
지금 제가 속한 회사는 Master에 모든 작업을 하고있습니다.
급하게 배포해야할때 굉장히 어려움이 있죠.
제대로 테스트 되지 않은 부분을 배포한다는건 사실 굉장한 스트레스입니다.
이런 불완전한 기능은 아직 크리티컬한 타격을 주지 않았지만, 언젠가는 그 크리티컬함을 넘어 사람의 생명까지 위협할 수 있습니다.
회사, 단체 구성원들이 한데 모여 규칙을 정하고 그 규칙을 잘 지켜나가는 데에서 이러한 오버헤드를 줄일 수 있습니다.
마치며
간단히 SVN과 git을 이야기 하면서 형상관리의 중요성에 대해서도 적어보았습니다.
위에서 설명한 것은 정말 초급 부분만 이야기 한 것으로 git은 ‘git 생태계’라는 말이 있을 정도로 무궁무진합니다.
하나의 예로 GitHub이 있을 수 있죠.
지금은 주제에서 벗어나고 나중에 포스팅할 기회가 있을겁니다.