이글은 이파피루스 대표이신 모던보이님의 글에 트랙백하기 위해서 씁니다.

이파피루스 대표께서 운영하는 블로그에 “버전관리시스템과 포스트모더니즘”이라는 글이 올라왔습니다. 물론 글의 내용은 본인도 상당히 공감하는 통제와 자유화의 관점에서 느끼는 소견이라 사족을 달고 싶지는 않습니다. (동감한다고 해야 할까요?)

하지만, CVS와 SourceSafe의 비교에서 일반 사용자(버전관리 시스템을 개발하는 사람은 아닌)분들이 조금 헷갈려 하시는 부분이 있어 언급하고자 합니다.

CVS와 SourceSafe로 대표되는 개인용 버전관리시스템의 가장 큰 차이점은 “무결성”을 유지하는 방법입니다. 여기에서 무결성이란, 현재 수정중인 소스를 여러 사람이 한꺼번에 수정 했을때, 혹은 이전 버전을 등록하려고 하는 등의 사용자의 실수를 방지하고, “버전관리 시스템”차원에서 결함이 없을을 보장하는 것 입니다.

크게 두가지 방법이 있습니다. Lock-Modify-Unlock 방식과 Update-Modify-Commit 방식이 있습니다.

이해하기 쉽게 Lock방식은 “내가 수정 하는 동안 다른 사람은 아무도 수정하지 못한다.”입니다. 이 방식으로 사용하는 버전관리 도구는 SourceSafe, PVCS가 대표적입니다만, SourceSafe는 2005 이후로 공식적으로는 Update방식을 지원하는 것으로 되어 있습니다. :)

Update방식은 “수정하기 전에 내 소스를 최신버전으로 맞추고(Update) 수정을 완료 한 다음에 반영(Commit)할 때, 내가 수정하는 동안 다른 사람이 수정 했는지 확인하고 반영한다.”입니다.

여기에서 중요한 점은 수정하기 전에 반드시 Update해서 최신버전으로 맞추어야 잘 작동한다는 것으로, Lock방식에 익숙한 사용자분들이 많이 어려워 하는 부분이기도 합니다. 미리 미리 Update하지 않면 충돌(Conflict)의 원인이 되고, 그 충돌을 해결하는 과정에서 (이게 쓸만하네, 못쓰겠네, 소스를 날려 먹었네, 등등 여러 상황이 연출 됩니다.)

여기에서 일반 사용자분들이 생각하지 못하는 핵심은. “Lock 방식이 우수하거나, Update 방식이 우수한 것이 아니라. 작업영역(소스를 체크아웃 받는 영역)이 공용으로 사용하는 폴더인지, 사용(개인)폴더 인지에 따라 더 적합한 방식이 결정되는 것입니다.”

Update방식은 개인 작업영역을 고려하여 만들어진 방식입니다. (쉽게) 우리나라 전산실에서 주로 하는 형태인 개발용 Unix Server에서 공용ID 하나로 개발하는 환경에서 Update방식을 지원하는 CVS를 사용하는 것은 (않되는 것은 아니겠지만) 상당히 난해 할 수 있습니다.

반면에 Lock방식인 SourceSafe나 PVCS는 몇십 혹은 몇백명의 개발자들이 투입되는 대형 SI프로젝트에서는 병렬개발 혹은 개발 퍼포먼스에 많은 문제가 발생합니다.라이브러리 등에서 대기하거나, Lock잡고 풀어주는것을 잊어 버리거나 Lock을 모니터링 하기 위해서 Scan하는 시간이 너무나 길어지는(가장 일반적인 어려움 입니다.) 현상이 발생 합니다.

여담이지만, SourceSafe나 PVCS는 Desktop용으로 설계된 제품이기 때문에, 일정 규모이상의 사용자가 사용하는 것은 당연히 무리가 있습니다. 10명 정도의 팀이 사용하기에는 비용대비 무난한 솔루션이지만 30명 혹은 100명이 사용한다면 다른 관점에서 접근하는 것이 좋습니다.

결론적으로 CVS방식 혹은 SourceSafe방식. 어떤 방식으로 버전을 관리 할 것인지 결정하는 핵심은 작업영역의 공용/사용 여부와 사용방식의 차이입니다. 어떤 솔루션이 더 우월(우수)해서 그런것은 아닐 것입니다.

그런 관점에서 CVS가 모더니즘적인 느낌이라는것은 저도 100% 공감하는 바입니다. :) (하지만 시대의 흐름에 따라 도구의 기능은 자꾸만 변해하는 것이겠지요. 받아들이고, 만들어 내고…)

우리팀이 만들고 있는 실루엣의 경우에는 1.x 버전에서는 Lock방식으을 지원 했지만, 2.x에서는 Update방식중 일부를 포함해서 함께 지원하고 있습니다. CVS처럼 완전 Auto Merge를 지원하지는 않지만, 개별 소스의 변경 혹은 Merge 필요여부 상태를 알려주고, 사용자가 필터링해서 작업 할 수 있도록 하고 있습니다. 한국 개발자들의 눈높이에 맞춘기능이라고 할까요 :)

객
여기에서 일반 사용자분들이 생각하지 못하는 핵심은. “Lock 방식이 우수하거나, Update 방식이 우수한 것이 아니라. 작업영역(소스를 체크아웃 받는 영역)이 공용으로 사용하는 폴더인지, 사용(개인)폴더 인지에 따라 더 적합한 방식이 결정되는 것입니다.” 라고 하셨는데, 사실 핵심은 주로 다루는 파일이 바이너리인가 텍스트인가 입니다. 주로다루는 파일이 텍스트라면 어떤 경우에든 Update 방식이 적합합니다. Update 방식을 사용할 때 뭔가 문제가 생긴다면 사용방식이 잘못되어 있는 것입니다. 바이너리 파일을 주로 다루는 경우는, 특히 4GL 툴을 사용할 때와 같이 폼 파일과 코드 파일이 동시에 사용되는 경우가 대부분입니다. 이때 폼 디자인의 경우 다른 사람의 작업을 Merge할 방법이 없기 때문에 Lock 방식을 사용할 수 밖에 없습니다. 설사, Lock 방식이 성능상 문제가 있거나 개발자가 많을 때 적합해 보이지 않더라도, 동일 화면을 여러 개발자가 다루어야 하는 경우가 자주 있다면 Lock 방식을 사용해야만 합니다. 아니면 철저하게 개발자별로 담당 화면을 분리하여 Lock이 필요없게 해야만 합니다.

2008.09.17 15:55머샤머샤
//객 네. 바이너리 or 텍스트의 문제도 고려 할 수 있습니다.

좀더 구체적으로는 개발도구가 어떻게 지원하는가? (Form파일을 Text로 지원하는 개발도구도 많이 있습니다.) 여부 인것 같습니다.

지적 감사합니다.

하지만, 제가 중시하는 부분은 “무결성”을 어떻게 유지 할 것인가에 초점을 두고 이야기 하는 부분으로, 개발도구의 특수성은 (잠시)보류 하였습니다.

그것까지 감안하면, 글을 읽으시는 일반사용자 분들에게 너무 많은 케이스를 한꺼번에 열거 하는거라 생각이 됩니다. 감사합니다.

2008.09.17 16:57 신고모던보이
핵심은 “무결성”의 유지 방법이 다르다는 점 맞습니다.

재밌는 점은 제도 또는 룰이 좀 더 자율을 보장하는 경우에도 그다지 큰 혼란이 없다는 점이라 생각합니다. CVS 또는 SVN을 사용해 보면 Conflit를 경험하는 경우가 별로 없다는 것을 경험하실 것입니다.

사실 제가 이 이야기를 꺼낸 것은 사회 현상도 마찬가지라는 점을 들고 싶어서 였습니다.

국가 또는 회사 내에서도 철저한 통제와 관리를 하지 않으면 금방 카오스가 될 것 처럼 모더니스트들은 이야기 하지만, 의외로 자율적인 질서의 힘이 강력하다는 것이지요.

예를 들어 (아직 저희도 시도해 보지 않았지만) 출퇴근 완전 자율화를 한다하더라도 초기의 혼란은 있겠지만, 곧 질서를 찾고 잘 운영될 수 있을 것같다는 생각? ㅎㅎ

브라질의 기업 셈코처럼 기존의 틀을 깨는 회사들이 훌륭한 성과를 내는 것이 좋은 예가 되겠군요.

2008.09.18 15:52머샤머샤
//모던보이 자율적인 질서의 힘이 강력하지만, 개인적인 견해로는 국지적인 조직 및 Scope에서만 그 강력한 힘이 발휘 될 수 있을 것이라 생각됩니다.

인간사회에서 자유라는 이름은 표면적인 측면만 알려져있고 (대부분)일반사회는 보이지않는 통제 혹은 권력이라는 보이지 않는 무엇을 인지하지 못한체 살아가고 있는것이라 생각됩니다.

또 모르지요. “가이아”의 측면에서 보면 인간사회또한 질서정연하게 자율적으로 흘러가고 있는 하나의 “파츠”일 뿐일런지도 말입니다. :)

2008.11.23 21:54 신고mrlatte
우와 실루엣 한번 써봐야겠네요 ^^

Read Count