소스세이프 사용 시 지켜야 할 것들

Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)

 

시작하기 전에 간단한 질문을 던지도록 하겠습니다.

혹시 소스세이프와 같은 버전 제어(Version Control) 도구를 사용해 본 적이 있으신지요?

사용해보니 어떻든가요?

 

아마도 팀 개발을 해보신 분들이라면 한번쯤은 소스세이프를 사용해본 경험이 있으실 것입니다. 재미난건 이런 도구가 필요하다는 것은 대부분 인식을 하면서도 막상 사용하라면 '귀찮다'라는 생각을 하는 경우가 많습니다. 그런데, '귀찮다'라는 것은 갈구면(?) 해결이 되는 부분인데, '불편하더라'나 '문제가 생기더라'라는 경우도 있습니다.

 

자, 그렇다면 소스세이프와 같은 버전 제어 도구들에 문제가 있는 것일까요? 버전제어 도구들을 만들어내는 회사들은 문제가 많은 도구를 비싼 값에 팔아먹고 있는 것일까요? (음.. 일부 제품은 사실 진짜 그런지도 모릅니다. -_-;;)

 

개발툴도 마찬가지지만, 항상 문제는 도구가 아닌 사람입니다. 아무리 좋은 도구가 있더라도 그것을 어떻게 쓰는가에 따라 결과는 상당한 차이가 납니다. 그러면 소스세이프를 잘 쓰기 위한 방법은 무엇일까요? 소스세이프 사용법을 숙달하면 소스세이프를 잘 쓸 수 있을까요? 소스세이프 사용법을 잘 몰라서 소스세이프를 잘 못쓰는 걸까요?

 

이미 느끼셨겠지만 이 글에서 말하고자 하는 것은 소스세이프를 어떻게 쓰는지.. 즉 사용법에 대해서는 말하고자 하는 것은 아닙니다. 그런 것은 소스세이프 도움말을 찾아보던지, 인터넷 상에서 검색하다 보면 다른 사람들이 친절하게 작성해 놓은 것들이 많이 있을 것입니다.

 

수년간 컨설팅을 해보면서 느낀 점은 다시 한번 문제는 도구가 아닌 사람이라는 것입니다. 소스세이프 사용 문제에 있어서 가장 큰 문제점은 '개발자들이 지켜야 할 약속을 지키지 않는다'라는 점입니다. 무슨 얘기인지 좀 풀어서 설명을 해봐야겠죠? ^^

 

소스세이프를 사용하는 목적과 가장 큰 특징은 뭘까요? 소스 백업? 버전관리? 분기? 병합?

우리가 주목해야 할 가장 큰 특징은 소스세이프와 같은 도구가 '공동 작업(팀 개발)'을 가능하게 해준다는 것입니다. 그렇다면 공동 작업, 아니 공동 생활을 할 때 중요한 것이 뭘까요? 바로 공동체의 약속을 지켜야 하며, 이를 위반해서 남에게 피해를 줘서는 안된다는 것입니다.

 

소스세이프 사용법만 가르쳐 주고 어느날부터 무조건 소스세이프를 쓰라고 강제로 지시했다고 가정해보십시오. 각자 따로 작업하던 개발자들이 소스세이프라는 울타리 안에 들어오면서 서로 간에 접촉(마찰)이 일어나기 시작합니다. 소위 말하는 아노미 현상에 가까운 무질서한 상태가 발생합니다.

말하자면 이 상황은 운전자들에게 차를 운전하는 방법만 가르쳐주고 갑자기 어느날 도로로 내몬 것과 유사합니다. 차선도 없고, 신호등도 없는 곳에 던져놓고, '자~ 달려라!'라고 등을 떠미는 것과 같은 상황이라는 거죠.

가끔 신호등이 고장난 교차로를 보신 적이 있으신지요? 사방에서 뒤엉키고, 빵빵대고 거의 난리부르스가 됩니다. 결국 시간이 지나 어느 누구도 오도가도 못하는 상황이 되어서야 누군가 나서서 정리를 하기 시작합니다. 엄청난 시행착오와 혼란을 겪지 않고서는 이 문제가 해결되기 어렵다는 것이지요.

 

소스세이프를 적용한 경우도 마찬가지입니다. 파일을 체크아웃해버린채 퇴근한 개발자 한명 때문에 전체가 곤란을 겪습니다. 제대로 컴파일되지도 않는 엉터리 코드를 체크인해놓고 가버린 개발자도 있습니다. 엉터리 코드를 최신버전으로 올려놓은 채 체크아웃해버리고 퇴근하는 복합적인 만행도 존재합니다. 새로 공통 모듈을 배포한지가 언제인데, 아직도 옛날 코드를 가지고 작업하는 사람도 있습니다.

 

그래서 결국은 이 아노미 현상을 극복하기 위해서는 소스세이프를 사용 시 기본적으로 지켜야 하는 규칙들을 간단하게 정리해볼 필요가 있다는 생각이 들었습니다. 사실 이 내용 자체는 별 것도 아닌 생각해보면 당연하며, 스스로 이미 알고 있는 내용입니다. 문제는 항상 나는 지키지 않으면서 남은 지키겠지라고 생각하는 것에서 생기는 거겠죠.

사설이 무지하게 길었는데 이제 본격적으로 정리를 해보겠습니다. ^^

 

1. 체크아웃은 가급적 짧게 수행합니다.

파일을 체크아웃해둔채 며칠동안을 보내는 개발자도 있습니다. 기본적으로 자신이 현재 작업하고 있는 상황이 아니면 파일을 체크아웃한 상태로 두지 마십시오.

 

2. 한꺼번에 체크아웃하는 파일의 개수를 최대한 줄이십시오.
여러 파일을 체크아웃하고 있으면 그만큼 다른 사람이 작업하려는 대상과 겹칠 경우가 많아집니다.

 

3. 체크인하기 전에는 반드시 빌드를 수행합니다.

수정한 파일을 체크인하기 전에 반드시 수정된 파일이 포함된 프로젝트를 반드시 빌드해서 오류가 없다는 것을 확인하십시오. 단 한 줄의 에러가 전체 프로젝트의 많은 부분에 영향을 미칠 수 있습니다.

참고로 VSTS(Visual Studio Team System)의 Source Control에서는 체크인 전에 빌드 또는 Code Analysis를 수행하도록 옵션을 설정할 수 있습니다.

 

4. 가급적 자주 빌드를 수행하십시오.

또한 빌드는 자주 수행할수록 에러를 좀 더 빨리 잡아 낼 수 있습니다. 컴파일러는 점점 더 똑똑해지고 있다는 것을 아시죠? ^^

 

5. 솔루션이나 프로젝트 전체를 체크아웃 하는 것은 가급적 금지합니다.
이것은 2번과 연결되는 요소입니다.

물론, 작업을 하다 보면 어쩔 수 없이 솔루션이나 프로젝트 파일을 체크아웃하게 되는 경우가 있습니다. 솔루션에 새로운 프로젝트를 추가하거나 프로젝트에 새로운 파일을 추가하는 경우가 대표적인 예입니다. 이 경우, 최대한 빨리 작업을 마치고 프로젝트를 다시 체크인하기 바랍니다.
예를 들어, Northwind.Biz 프로젝트에 SampleSystem.cs를 추가했다고 가정하겠습니다.
이 때, 우선 Northwind.Biz 프로젝트를 체크인(SampleSystem.cs도 같이 체크인 됨)한 후..
SampleSystem.cs 만을 다시 체크아웃 해오는 것이 바람직합니다.

 

6. 특별한 이유가 있지 않으면, 솔루션을 열 때마다/매일 아침 출근 시에/특정한 지시가 있을 때 최신 버전 가져오기를 수행합니다.

 

7. 특별한 이유가 있지 않으면, 솔루션을 닫을 때/매일 저녁 퇴근 전에 체크아웃 해놓은 상태로 방치해놓은 파일이 있는지 확인합니다.

 

8. 가능하면 체크인 시 Comments를 남겨서 변경사항 History를 써주면 좋습니다.

 

거창했던 서론에 비해 규칙은 이렇게 허무할정도로 간단합니다. 그러나 항상 문제는 이렇게 간단한 규칙도 대다수의 사람들이 잘 지키지 않는다는 것에서 발생합니다.

명심하십시오, 문제는 항상 도구가 아닌 사람이라는 것을...

 

p.s.

소스세이프나 다른 툴을 써보신 분들은..

Multiple Checkout을 쓰면 체크인하지 않은 것 때문에 문제가 생기는 건 막을 수 있지 않냐고 하실 수도 있습니다. 예, 물론 그렇습니다. 그런데 과연 그걸 쓰고 싶으세요? ^^