최근 서점에 갔다가 놀라게 된 일이 있었다. 직업이 직업인지라 컴퓨터 관련 서적들을 습관처럼 훑어 보게 되는데, 버전 관리 시스템(이하 SCM)에 대한 책들이 꽤 많이 나와 있는 것이다.


놀란 이유는 두 가지다. 하나는 왜 SCM 사용법이 책으로 나와야 하는 것이고, 다른 하나는 왜 요즘에 저런 책이 나오는가 하는 것이다. 아, 그랬던 것이다. 책을 몇 권 뒤져보니 지금까지도 버전 관리 없이 살아온 개발팀이 많았던 것이다.


여기서, 버전 관리의 중요성을 논하고 싶지는 않다. 그 보다는 널리 사용되는 두 종류의 SCM, 마이크로소프트 SourceSafe와 오픈 소스 프로젝트인 CVS에 대한 담론을 해보려고 한다.


SourceSafe(이하 SS)는 어떤 파일에 대해 작업을 하기 위해 체크아웃이라는 절차가 필요하다. 체크아웃을 통해 내가 이 파일을 수정할 예정이니 다른 사람들은 손대지 말라는 선언을 하는 것이다. 수정이 끝나면 체크인을 해서 중앙 저장소에 기록을 하게 되고, 이제 모든 사람들이 이 수정을 자신의 로컬로 가져올 수 있게 된다.


이 방식의 가장 큰 특징은 하나의 파일을 동시에 한 사람만 수정할 수 있다는 것이다. 즉 main.c 파일을 김군이 수정하고 있으면, 이양은 김군이 수정을 마칠 때까지 수정할 수 없다는 것이다. 여러 사람이 작업할 때, 생길 수 있는 충돌을 원천 봉쇄하는 것이다.


CVS는 훨씬 자유롭다. 아무 파일이나 마음 내키는 대로 수정하면 된다. 그리고 수정이 끝나면 커밋(SS의 체크인과 비슷한 개념)을 하면 된다. 그러면 동시에 여러 사람이 같은 파일을 수정하고 커밋하면 어떻게 되냐고? 이런 상황을 충돌이라고 하는데 그런 경우는 동시에 일어난 수정들을 손으로 해결 하거나, 자동에 맡기면 된다.


위의 두 방식은 예전부터 격렬한 논쟁 거리가 되어 왔었지만, 이 이야기를 또 들고 나온 것은 저 물건들의 정치적, 사회적 특성에 대해 재미있는 것을 발견 했기 때문이다.


SourceSafe의 방식은 안전하다. 절대 혼란이 발생할 수가 없다. 어떠한 작업을 하기 위해서는 SCM이라는 중앙 기관의 허락을 받아야 하고, 이 허락 없이는 작업이 불가능 하기 때문이다. 그야 말로 계몽주의의 전형이다. 누가 어떤 파일을 사용하는지 중앙에서 통제한다. 사회의 혼란을 막기 위해서 모든 것을 통제 하는 시스템. 형식의 아름다움이 느껴지지 않는가?


하지만, CVS는 이 형식을 깨버린다. 작업을 하기 전에 중앙의 승인을 받아야 하는 절차를 무시한다. 그저 아무 때나 작업을 하면 된다. 작업을 하기 위한 중앙 저장소의 허락이 필요 없다. 작업이 끝나면 커밋 만 하면 되는 것이다. 더 이상 관리의 주체는 SCM이 아니라, 개인이 된 것이다. 오바를 해 보자면, 개인과 사회의 해방을 이룩한 것이다.

종종 충돌 과 혼란도 일어난다. 하지만, 구조나 형식을 통해서 이 문제를 해결하지는 않는다. 자유와 해방을 위해서 이러한 혼란을 감수한다.


사회, 문화, 예술에 이어 엔지니어링 세계에서도 포스트모더니티가 나타나고 있다.

(이 글은 2006/04/25일 네이버 블로그에 올렸던 글입니다.)

트랙백 주소 :: http://www.epapyrus.com/blog/jeong/trackback/29

  1. Subject: 버전관리 - 작업영역에 대한 오해

    Tracked from 머샤의 인생과 웃기는 고양이 2008/09/17 11:41  삭제

    이글은 이파피루스 대표이신 모던보이님의 글에 트랙백하기 위해서 씁니다. 이파피루스 대표께서 운영하는 블로그에 "버전관리시스템과 포스트모더니즘"이라는 글이 올라왔습니다. 물론 글의 내용은 본인도 상당히 공감하는 통제와 자유화의 관점에서 느끼는 소견이라 사족을 달고 싶지는 않습니다. (동감한다고 해야 할까요?) 하지만, CVS와 SourceSafe의 비교에서 일반 사용자(버전관리 시스템을 개발하는 사람은 아닌)분들이 조금 헷갈려 하시는 부분이 있어 언급..

댓글을 달아 주세요

  1. clue 2008/09/17 04:29  댓글주소  수정/삭제  댓글쓰기

    CVS가 sourcesafe보다 훨씬 먼저 만들어진 소프트웨어죠. sourcesafe는 그래도 90년대일 텐데.

  2. youlsa 2008/09/17 14:01  댓글주소  수정/삭제  댓글쓰기

    CVS를 거쳐 SVN을 쓰고 있는데요, 별로 생각해보지 않은 내용을 지적하셨네요. 그러고 보니 또 그렇다는 생각이 듭니다. 통제의 틀을 다소 넓힌거라고 볼수도 있겠고요.

  3. clue 2008/09/17 15:39  댓글주소  수정/삭제  댓글쓰기

    sourcesafe가 사용하고 있는 lock-modify-unlock 모델은 CVS 전부터 RCS, SCCS 따위시절부터 오랫동안 쓰던 방식입니다. CVS나 SVN은 이런 전통과는 다르게 working copy를 만들어 merge하는 모델을 택했고 매뉴얼을 보면 lock을 하는 것에 대해 문제점과 불필요함을 논하는 부분이 있죠. sourcesafe는 더 나중에 만들어졌음에도 불구하고 lock을 하는 모델을 택했구요.

  4. 모던보이 2008/09/17 16:47  댓글주소  수정/삭제  댓글쓰기

    CVS와 SourceSafe의 앞뒤는 논점은 아닙니다. Clue님이 말씀하신것 처럼 lock-modify-unlock 모델이 더 오래 됬고, 모던 하다는 이야기 이지요. ㅎㅎ

늘 부족하다고 생각하고 있습니다만, 우리 회사의 개발 환경을 소개해 보겠습니다.
더 좋은 방법이라던지 새로운 방법을 제안해 주시면 PDF-Pro 한 카피를 정성스럽게 포장해서 보내드리겠습니다. ^_^

1. 소스 콘트롤 서버

이파피루스는 SVN을 사용하고 있습니다. 초창기에는 CVS를 사용했습니다만, 소스들의 무결성(integrity; 무결성이라는 말이 적당한지 잘 모르겠네요 ㅎㅎ)을 위해 Atomic check-in이 가능한 Subversion으로 이주한지 2년 정도 되었습니다. 로깅을 잘하자고 늘 강조하고 있지만 늘 부족한듯이 느껴집니다.

사용자 삽입 이미지


2. 버그 트랙킹 시스템

버그질라를 사용하고 있습니다. 버그질라를 외부에 오픈하는 것이 어떻겠느냐고 프로그래머들을 설득하고 있지만, 아직은 반대가 많네요. (자신이 없냐고 놀리고는 합니다. ㅎㅎ) 버그가 고쳐지면 SVN과 연계해서 어떤 버그를 고치기 위해 어떤 패치가 일어났는지를 알 수 있습니다.
아래 스크린샷을 보면 오늘 날짜로 142개의 버그/이슈가 살아있는 것을 알 수 있습니다. (내부에서 관리하는 버그 개수로 이 정도는 많지는 않다고 우기면 믿어주시려는지 ㅎㅎ)
사용자 삽입 이미지

3. 데일리 빌드 서버

사내의 모든 프로젝트들을 소스 컨트롤에서 받아와, 빌드하는 서버입니다. NT 기반에서 돌아가고 있으며 파이썬으로 작성된 스크립트입니다. 빌드 시간이 만만치 않기 때문에 새벽시간과 점심시간에 한번씩 수행됩니다. 빌드에러는 로그로만 남겨지는데, 빌드 에러 발생시 이메일 등으로 통지하는 기능을 만들려고 마음먹은지 1년쯤 되었습니다. ㅎㅎ

4. 회귀 테스트 (Regression test) 서버

데일리 빌드 서버와 같은 하드웨어입니다. 역시 NT 기반이며 펄로 만들어진 스크립트입니다. PDF 렌더링 엔진에만 적용되고 있으며, 대량의 PDF 문서를 열고, 렌더링 해서 전날 까지의 작업과 달라진 점이 있는지를 (잘 나오던 글자가 사라진다던가와 같은) 체크해서 리포트로 만들어 줍니다. 새벽 3시에 시작하면 5시경에 끝이 납니다.

5. 테스트용 워크스테이션

코어가 4개로 사내에서 제일 짱짱한 시스템입니다. 가상 머신을 동시에 4개 까지 돌릴수 있으며, 모든 테스트는 가상 머신 위에서 진행합니다. 저희 제품이 동작할 수 있는 모든 환경을 가상 이미지로 만들어 놓고, 신제품 출시 또는 패치 출시 전에 테스트를 진행합니다.

6. 위키

여러가지 잡다한 내용들을 위키에 등록해 놓고 사용합니다. 예를 들자면, 복합기 드라이버 설치법이 헛갈릴 때도 사용하고, tar 압축 해제하는 법이 갑자기 생각이 나지 않을 때, 회의록 작성 양식이 필요할 때 등 여러가지로 사용하고 있습니다.

7. 문서 관리 서버

Alfresco를 문서 관리 서버로 사용합니다. 개발부 뿐만 아니라 전 부서가 함께 사용하고 있으며, 여러가지 개발 관련 문서들을 저장합니다. 특히 자동 버전 관리 기능이 좋습니다.

8. 파일 서버

2테라 NAS를 사용합니다. 특별히 사용 용도는 없습니다만, 늘 용량이 부족한 것으로 봐서 동영상이 가득찬 것이 아닌가 의심을 하고 있습니다. ㅎㅎ

9. 백업

시대에 뒤떨어져 보이기는 하지만, 테이프 백업을 합니다. 테이프 5개를 돌려가며 매일 백업을 하고 있으며, 주 단위 백업과 월 단위 백업 테이프는 회사 바깥의 안전한 곳에서 장기간 보존을 합니다.

트랙백 주소 :: http://www.epapyrus.com/blog/jeong/trackback/19

댓글을 달아 주세요

  1. 김재훈 2008/08/02 17:35  댓글주소  수정/삭제  댓글쓰기

    KLDP에서 글을 보다 여기까지 왔습니다. 좋은 정보 얻고 갑니다. 오픈소스에 관심을 가진지 얼마되지 않지만 수혜자의 역할에서 벗어나 기여자로서 역할을 어떻게 하면 좋을까 고민하고 있습니다. 한번 시간이 되시면 만나뵈면 좋겠습니다. 저는 www.polypix.com을 98년부터 운영하고 있습니다. jaison63@naver.com

  2. Kenny 2008/08/03 19:42  댓글주소  수정/삭제  댓글쓰기

    와.. 꽤 정리가 잘 되어 있네요..
    음.. VCS 관련으로 개인적인 추천을 하자면...

    1. Branch 활용에 대한 언급이 없으시네요... 활발하게 이용하고 계신가요? 저희 회사에서는.. 수정사항이 생길때 Branch를 이용하고는 있습니다면... 아무래도 Subversion의 Branch 기능은 좀 불편한 부분이 있어서.. 개인적으로 Git - Subversion 연동을 통해 로컬 Branch를 활용하고 있습니다. 배워야 한다는 단점만 제외하면... 아직까지는 제일 편한 방법이네요.

    2. http://www.infoq.com/articles/agile-version-control 글을 꼭 한번 봐 주시기 바랍니다. VCS 활용을 극대화 하려면.. 아무래도 VCS "이용"에 대한 전략이 필요하다는 생각을 오랜기간 하고 있었는데... 상당히 정리를 잘 해 놨더라고요.

  3. 모던보이 2008/08/03 19:52  댓글주소  수정/삭제  댓글쓰기

    1. Branch를 쓰고 있습니다만, 사내에 불편해 하는 프로그래머들이 많더군요. 한번도 다른 대안에 대해 생각해 본 적이 없는데, Git + Subversion 검토해봐야 겠네요. 감사합니다.

    2. 정리가 잘 되있네요. 좋은 자료 감사합니다.

    메일로 주소 알려 주시면 PDF-Pro 4 한개 보내드리겠습니다. ㅎㅎ
    jeong@pdfpro.co.kr

  4. LispHacker 2008/08/06 21:31  댓글주소  수정/삭제  댓글쓰기

    vcs 는 어떤 것이든 유사한 문제가 있는 것이 대부분입니다(변경을 관리할 때 공통적으로 생길 수 밖에 없는 근본적인 문제들). cvs 10년 이상 사용하다가 약 3개월 전부터 mercurial 사용하고 있는데, 공통된 문제점도 있고, 더 나은 점도 있더군요. 하나 이상의 vcs를 사용하는 것은 그리 좋은 아이디어는 아닌 것 같습니다. (참고로 저와 동료들은 꼭 필요한 변경은 주저않고 수행하지만, 그렇지 않은 경우 최대한 보수적 관점을 유지합니다. 즉, 뭔가 해결할 수 없는 문제가 없는 한 절대 툴을 바꾸지 않습니다. 반면 개발 프로세스는 쉽게 바꿉니다)

    tracking system을 오픈하는 것도 그리 좋은 생각은 아닌 것 같습니다. 물론, 이메일로 버그보고를 받으면 ts에서 id부여후 답장을 자동으로 보내는 등의 자동화 정도는 괜찮을 듯 합니다. jira 쓰고 있는데, 기본적 기능만 사용하므로 별 어려움 없이 씁니다.

    빌드와 테스트는 거의 동시에 일어나야 하지 않나 생각합니다. 즉, 개별 작업의 change set이 vcs의 메인라인에 커밋되기 전에 머지후 빌드 및 테스트가 돌아간 후 메인라인에 커밋되는 프로세스라면 데일리 빌드는 큰 의미가 없어집니다. 물론 이렇게 되려면 각 개발자가 언제든 돌려볼 수 있는 테스트 케이스가 있어야 합니다(개별 코드라인 전략은 위의 링크에 이미 있는 것과 유사하면 되겠죠. 제 기억이 맞다면, mercurial로 바꾸면서 동료가 알려준 perforce ppt(pdf?) 파일 내용과 유사하네요. tofu scale 만 기억나네요)

    저는 개인용 위키도 사용합니다. http://www.tiddlywiki.com/ USB 메모리 스틱에 truecrypt로 무장한 위키 갖고 다니면서 잡동사니 들을 기록합니다.

    개발툴이 양이면, 프로세스가 음인데, 프로세스에 대한 언급은 없어서 약간 아쉽네요. (적고나서 보니 거의 '프로세스' 이야기가 되버렸네요)

    건승하시길...

  5. youlsa 2008/09/17 14:11  댓글주소  수정/삭제  댓글쓰기

    남의 개발환경을 훔쳐보는 기분이네요. 저 있는 곳과 거의 비슷한 환경이네요. 다만 저희는 문서 관리도 SVN을 쓰고 있습니다. 복잡한 툴 배우게 하기가 쉽지 않아서요... alfresco는 처음 봤는데 한번 검토해봐야겠습니다.

    좋은 글 감사합니다.

최근 서점에 갔다가 놀라게 된 일이 있었다. 직업이 직업인지라 컴퓨터 관련 서적들을 습관처럼 훑어 보게 되는데, 버전 관리 시스템(이하 SCM)에 대한 책들이 꽤 많이 나와 있는 것이다.


놀란 이유는 두 가지다. 하나는 왜 SCM 사용법이 책으로 나와야 하는 것이고, 다른 하나는 왜 요즘에 저런 책이 나오는가 하는 것이다. 아, 그랬던 것이다. 책을 몇 권 뒤져보니 지금까지도 버전 관리 없이 살아온 개발팀이 많았던 것이다.


여기서, 버전 관리의 중요성을 논하고 싶지는 않다. 그 보다는 널리 사용되는 두 종류의 SCM, 마이크로소프트 SourceSafe와 오픈 소스 프로젝트인 CVS에 대한 담론을 해보려고 한다.


SourceSafe(이하 SS)는 어떤 파일에 대해 작업을 하기 위해 체크아웃이라는 절차가 필요하다. 체크아웃을 통해 내가 이 파일을 수정할 예정이니 다른 사람들은 손대지 말라는 선언을 하는 것이다. 수정이 끝나면 체크인을 해서 중앙 저장소에 기록을 하게 되고, 이제 모든 사람들이 이 수정을 자신의 로컬로 가져올 수 있게 된다.


이 방식의 가장 큰 특징은 하나의 파일을 동시에 한 사람만 수정할 수 있다는 것이다. 즉 main.c 파일을 김군이 수정하고 있으면, 이양은 김군이 수정을 마칠 때까지 수정할 수 없다는 것이다. 여러 사람이 작업할 때, 생길 수 있는 충돌을 원천 봉쇄하는 것이다.


CVS는 훨씬 자유롭다. 아무 파일이나 마음 내키는 대로 수정하면 된다. 그리고 수정이 끝나면 커밋(SS의 체크인과 비슷한 개념)을 하면 된다. 그러면 동시에 여러 사람이 같은 파일을 수정하고 커밋하면 어떻게 되냐고? 이런 상황을 충돌이라고 하는데 그런 경우는 동시에 일어난 수정들을 손으로 해결 하거나, 자동에 맡기면 된다.


위의 두 방식은 예전부터 격렬한 논쟁 거리가 되어 왔었지만, 이 이야기를 또 들고 나온 것은 저 물건들의 정치적, 사회적 특성에 대해 재미있는 것을 발견 했기 때문이다.


SourceSafe의 방식은 안전하다. 절대 혼란이 발생할 수가 없다. 어떠한 작업을 하기 위해서는 SCM이라는 중앙 기관의 허락을 받아야 하고, 이 허락 없이는 작업이 불가능 하기 때문이다. 그야 말로 계몽주의의 전형이다. 누가 어떤 파일을 사용하는지 중앙에서 통제한다. 사회의 혼란을 막기 위해서 모든 것을 통제 하는 시스템. 형식의 아름다움이 느껴지지 않는가?


하지만, CVS는 이 형식을 깨버린다. 작업을 하기 전에 중앙의 승인을 받아야 하는 절차를 무시한다. 그저 아무 때나 작업을 하면 된다. 작업을 하기 위한 중앙 저장소의 허락이 필요 없다. 작업이 끝나면 커밋 만 하면 되는 것이다. 더 이상 관리의 주체는 SCM이 아니라, 개인이 된 것이다. 오바를 해 보자면, 개인과 사회의 해방을 이룩한 것이다.

종종 충돌 과 혼란도 일어난다. 하지만, 구조나 형식을 통해서 이 문제를 해결하지는 않는다. 자유와 해방을 위해서 이러한 혼란을 감수한다.


사회, 문화, 예술에 이어 엔지니어링 세계에서도 포스트모더니티가 나타나고 있다.

트랙백 주소 :: http://www.epapyrus.com/blog/jeong/trackback/6

댓글을 달아 주세요