태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Search results for 'svn'

빈 줄도 지워서는 안된다.

2015.04.13 14:25 by 전규현


잠시 후 Google blogger로 이동됩니다.






SVN 쓸까? Git 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 중요한 것은 SVN이나 Git 상관없이 어떻게 하면 여러 개발자들과 협업이 되도록 코딩을 하느냐다.


많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다. 또는 여러 명이 개발을 하더라도 자신의 소스코드가 정해져 있어서 혼자 개발하는 경우가 많다. 이러다 보니 협업을 위한 개발에는 별로 관심이 없다. 하지만 협업은 혼자서 때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다. 방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.


혼자서 개발을 하더라도 수많은 브랜치가 발생할 있고 한두 명끼리는 그럭저럭 개발을 하더라도 개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.


그럼 어떻게 코딩을 하는 것이 좋을까?


첫째, 줄도 고쳐서는 된다.


내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다. 설사 혼자서 고치는 소스코드라고 하더라도 습관이 된다. 협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 


뿐만 아니다. Indentation 맞지 않는다고 고치는 것도 좋지 않다. 괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다. 무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.


둘째, 파일 이름을 바꾸지 말아야 한다.


처음에 대충 파일을 만들다 보면 파일이름이 마음에 드는 경우가 있다. 그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을 피할 길을 없다. 처음에 정해야 한다. 


셋째, 함수 이름과 정의를 바꾸지 않아야 한다.


대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다. 그리고 대충 만들고 나중에 수정하는 것은 비용이 많이 든다. 아주 작은 시스템만 경험해 개발자는 이런 방법이 빠르다고 주장할지 몰라도 시스템에 개발자가 수십 명이라면 얘기가 달라진다. 대충하고 바꾸는 습관이 들어서는 안된다.


넷째, 소스코드를 재배치하지 말아야 한다.


파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge 어려워진다. 처음에 생각해서 정하고 나중에는 고치지 말아야 한다. 여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.


이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.


외에도 변수를 어떻게 선언하느냐는  협업을 위한 수많은 코딩 노하우들이 있다. 항상 개발은 혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.

물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 

필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.





저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 GIT, merge, svn

  1. Blog Icon

    비밀댓글입니다

  2. Blog Icon
    저는 조금 반대입니다.

    저는 조금 반대인게 변경해야 하는 내용이 규격화된 내용과 맞지 않는 형식이라면 고치는게 맞다고 생각합니다.
    머지를 하는게 처음엔 힘들수 있지만 일정한 표준화가 되고 난 다음부터는 그렇게 힘들지 않습니다.
    일단 제 경험상으론 그렇네요.

  3. Blog Icon
    나그네

    이럴때 필요한게 리팩토링 이지요...

    프로젝트 중간 팀원들과 리팩토링을 하여 정보를 공유하는게 좋을듯합니다..

    빈줄도 지워서는 안된다는 좀 심한듯..

왜 하나만 써야 하는가?

2011.08.13 11:32 by 전규현


잠시 후 Google blogger로 이동됩니다.





이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 2008년에 작성한 소프트웨어 회사의 개발 역량 평가 표에는 20점 중 2점을 차지하고 있다.

2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표 

종종 "여러개를 쓰면 어떤가?"하는 궁금증이 있어서 그 이유를 설명하고자 하다.

 소스코드관리시스템을 여러개 쓰고 있다면?
 
회사가 아무리 크더라도 소스코드관리시스템은 하나만 쓰는 것이 좋다. 한 종류의 시스템을 여러개 설치에서 쓰는 것도 좋지 않다. 또한 특별한 이슈가 없는 경우라면 하나의 Repository에 소스코드를 관리하는 것이 좋다.

여러 시스템을 쓰는 경우는 대부분 팀마다 각자 취향에 따라서 VSS도 쓰고 SVN도 쓰고 Git도 쓰는 경우이다. 이러한 경우 각자 핑계들이 있다. Visual Studio에 최적화된 VSS를 써야 한다는 둥, 오픈소스를 이용하기 때문에 Git가 좋다는 둥의 주장을 하다가 각 팀에서 알아서 쓰기로 결정을 종종 하게 된다.

팀마다 다른 시스템을 쓰게 되면 여러가지 문제가 발생한다.

첫째, 공통 모듈 관리가 전혀 안되서 공통 모듈을 서로 복사해서 쓰기도 하고 비슷한 모듈을 따로 개발하기도 한다. 공통모듈이 없는 SW회사는 거의 없다. 관리를 안할 뿐이다. 이것이 얼마나 큰 문제가 되냐고 생각하는 사람들도 있다. 하지만 제품이 많아지고 고객이 많아지면 이렇게 복사된 공통모듈로 개발은 엉망진창이 된다. 유지보수 비용이 몇배로 들게 된다. 

둘째, 개발자는 각 팀마다 스위치가 자유로워야 하는데 서로 다른 시스템을 배우기 위해서 시간이 들어간다. 기본 기능은 배우는데 얼마 안걸리지만 완전히 손에 익어서 능수능란하게 쓰기에는 시간이 걸리는데 괜히 쓰지않아도 될 시간이 들게 된다.

그외에 전사적으로 관리가 잘 안되서 백업도 비용이 더 많이 들고 여러가지 문제가 발생한다. 주먹구구 식으로 작은 규모로 대충 개발할 때 문제가 눈에 안 띨분이지 나중에 댓가를 치르게 된다.  나중에 문제가 발생한 후에 통합은 거의 불가능하다 처음부터 하나를 써야 한다.

 버그관리시스템을 여러개 쓰고 있다면?
 
버그관리시스템은 개발자들만 쓰는 것이 아니다. CEO를 비롯해서 전직원 모두가 쓰는 시스템이다.
그런데 각 팀마다 서로 다른 시스템을 쓰고 있는 경우라면 십중팔구 개발자나 QA팀만 쓰고 있는 경우이다. 전사적으로 통일된 결정이 없었고 회사의 지원이 없어서 개발자들이 팀내에서 알아서 결정해서 쓰는 경우가 많다. 이는 반쪽만 사용하고 있는 경우이다.

버그관리시스템은 개발을 포함해서 회사의 거의 모든 이슈가 관리되는 곳이다. 기껏해야 회계나 HR이슈들이 빠질 뿐이다. 그런데 팀마다 다른 시스템을 쓰고 있다면 이슈가 통합되서 관리도 안되고 통계도 안나오고 개발팀 바깥의 부서에서는 여러 시스템을 모두 써야 하는 불편함도 있다.

또한 여러 시스템을 다 배워야 하기 때문에 이만저만 불편한 것이 아니다. 이또한 나중에 통합은 어려우므로 처음에 하나로 잘 결정해야 한다.

 SVN과 Git를 같이 쓰는 경우는?
 
종종 SVN을 쓰면서도 출장을 자주 나가서 출장지에서 직접 개발을 해야 하는 경우들도 있다. 이런 경우 SVN과 Git를 연동해서 쓰면 유용하다.

SVN만 사용하면 출장을 나가서 1주일동안 여러가지 기능과 버그를 수정했을 경우 복귀후 Commit을 하게 되면 그동안 수정한 내용이 한번에 커밋이 되서 관리가 어려워진다.

이때 SVN Repository를 Git에 담아서 출장을 가서 개발할 때마다 여러번 Commit을 하면 복귀후 SVN과 다시 통합을 하면 그 History가 고스란히 합쳐진다.

이런 경우 처럼 Git를 보조적으로 쓰는 것도 좋다.

 다른 시스템은 쓸 필요가 없나?
 
나는 보통의 SW회사에서 소스코드관리시스템과 버그관리시스템 2개면 충분하다고 주장한다. 사실 왠만큼 회사가 커지기 전까지는 이 두가지면 충분하다. 

결재가 필요하기 때문에 전자결재를 위한 그룹웨어를 도입하고 싶어하기도 한다. 하지만 소프트웨어 회사에서 그룹웨어는 그렇게 효율적이지 않다. 전자결재는 SW개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.

그 외에 작업관리, 고객요청관리, 테스트 관리등 여러가지 관리의 필요성을 느끼게 된다. 
일단 이 두개만 가지고 쓸 수 있는 한 최대한 써보기를 권한다. 그러면 의외로 거의 모든 것을 다 커버하게 된다는 것을 알게 될 것이다.

그후에 회사의 규모가 정말로 커져서 인원이 몇백명이 되고 좀더 관리를 잘 하고 싶으면 테스트관리나 서비스데스크등 개발자들에게는 부담이 안되지만 관리에 도움이 되는 시스템을 우선적으로 도입하면 좋다.

 결론
 
나중에 통합은 어렵다. 이미 여러개의 시스템을 쓰고 있다면 합칠 수 있다면 지금이라도 합치는 것이 좋다. 나중에는 늦는다.

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by
 
nerovivo
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템 GIT, svn, 기반시스템

  1. SVN+Git이 가장 궁금하네요. 어떤식으로 구성을 하는건가요?

  2. 안녕하세요. 구차니님
    평소에는 SVN을 쓰다가 출장을 갈 때만 git-svn을 이용해서 clone을 만들어 가는 겁니다. 출장시에는 Git를 쓰는 겁니다. 나중에 SVN과 통합할때는 dcommit 명령을 이용하면 그동안 바뀐 SVN와 merge가 되면서 통합니다. 몇가지 명령어만 알면 시행 가능합니다. ^^

  3. 좋은 글 감사합니다.
    주제와는 별도로 프로젝트 기획/정보 공유를 위해 위키를 사용하는 것에 대해서 이야기를 듣고 싶습니다.
    문서들의 버전 관리/동기화 문제 때문에 위키가 정말 적절한 솔루션이라고 생각하는 데, 막상 사용하려고 하면 프로그래머가 아닌 분은 많이 불편해 하시더군요.
    무엇보다 워드나 파워포인트와는 다르게 문서에서 이미지를 그릴 수 없고, 이미지 첨부도 불편한 점이 원인인 것 같습니다.
    업무에 위키 도입에 성공/실패한 사례가 있다면 정말 큰 도움이 될 것 같습니다.

  4. 안녕하세요.송재학님

    위키의 위상은 소스코드관리리스템이나 버그관리시스템에 비하면 5%도 안됩니다. 위키가 왠지 멋져 보이고 장점도 많지만, 쉽게 정착이 안된다는 단점이 있습니다.

    또, 프로젝트의 주요문서 (Baseline에 들어가는 문서)를 위키에 저장하게 되면 상당히 불편합니다. 특히 인쇄를 해서 검토를 할 때 불편합니다. 따라서 워드로 만들어서 SVN 등에 보관하는 것이 좋습니다. 제가 쓴 "소프트웨어 개발의 모든 것"을 보면 어떤 문서를 어디에 보관해야 하는지 자세히 설명이 되어 있습니다.

    그렇다고 하더라도 위키는 여전히 매력적인 물건입니다. 위키는 도입 실폐사례가 많지만, 대기업중 하나인 H사는 Jira, SVN과 같이 Wiki를 도입하여 정보 공유에 활발하게 쓰고 있습니다.

    Wiki의 정착이 어려운 이유는 Wiki를 잘 쓰려면 시간적인 여유도 있어야 하고 각자 능동적이어야 하는데 매일 일에 치이는 회사에서는 금방 흐지부지 되더군요.

    신중하게 생각해보세요.

  5. Blog Icon
    술푼사슴

    늘 좋은글 감사히 읽고 있습니다.

    위키에 대해서는 저는 약간 생각이 다릅니다.

    프로젝트 특성상 주요문서는 협업을 통해 검토 & 변경이 이뤄지고 변경 이력관리가 되어야 합니다.

    워드등으로 만들 경우 이를 변경하고 배포하는게 그리 효율적이지 않고 많은 비용이 드는것 같습니다.(MS Office 기반의 협업도구도 있다고는 들었습니다.)

    또 "요구사항 변경 회의(회의록)"->"요구사항 스펙 수정(변경된 스펙문서)"등 업무로 인한 산출물이 서로 연관이 있을 경우 문서간의 link를 걸어주면 왜 이게 변경이 되었고 변경원인은 무엇인지 손쉽게 관리가 가능합니다.
    (wiki의 문서간 link 기능은 정보를 통합하고 관리하는데 최적의 도구라 생각합니다.)

    현재 사내에서 위키를 문서 작성 플랫폼 및 협업 및 소통의 도구로 잘 활용하고 있습니다.(이메일을 보낼일이 있다면 내용을 위키에 작성후 링크만 이메일로 보냅니다..)

    그간 사내에 위키를 정착하려고 많이 노력을 했었는데 참여도가 저조하고 힘들어 했던 이유중의 하나는 일반적인 wiki 시스템이 사용자 편의성이 떨어진다는 점도 컸던 것 같습니다.

    저도 docuwiki, mediawiki, twiki 등을 써보았지만 괜찮은 WYSIWYG 에디터가 제공되지 않아서 전용 문법을 익히는 부담때문에 사내 적용이 힘들었는데 wiki system 을 바꾸고 예전보다 활용도가 더 많아진 것 같습니다.

  6. Blog Icon
    송재학

    좀 더 고민을 해봐야겠군요.
    일단은 프로젝트에 직접적으로 도입하기 보다는, 지식을 공유하는 용도로 써볼까합니다.
    프로젝트에 도입하는 건 다들 위키에 익숙해지고, 만족스러워한다면 다시 한 번 고려해봐야겠습니다.
    친절한 답변 감사합니다.

맥에서 Subversion 사용하기

2010.04.20 15:09 by 전규현


잠시 후 Google blogger로 이동됩니다.




 
최근에 맥북을 구매해서 아이폰 개발 작업을 하고 있는데 맥에서 Subversion을 사용하는 환경이 그리 좋지 않다는 것을 알게 되었습니다. 그래서 맥에서 Subversion을 제대로 활용하기 위한 글을 적어보려고 합니다.

Subversion 자체에 대해서는 블로그의 다른 글들을 보시기 바랍니다.

일단 Xcode에는 기본적인 Subversion연동 기능이 포함되어 있습니다. 그런데 막상 써보면 기존에 TortoiseSVN의 뛰어난 기능과 성능에 익숙한 사람들은 불만스럽기 짝이 없습니다. 그래서 맥에서 Subversion을 쓰기 위한 방법을 비교해보도록 하겠습니다. 

  • Xcode 기본 기능 
  • 유/무료 맥용 SVN Client 사용 - Syncro, Diffly
  • 터미널
  • 가상머신 + TortoiseSVN 
Subversion 서버는 이미 구축되어 있다고 가정합니다. Subversion서버가 아직 구축되지 않았다면 제 을 참조하여 Subversion을 구축하시기 바랍니다. 또는 Google Code를 이용하는 방법도 있습니다. Google Code를 이용하면 소스코드가 공개가 되니 소스코드를 공개해도 되는 경우라면 Google Code를 이용하면 편리할 것입니다.

 Xcode의 기본 기능 사용

사실 Xcode의 기본 Subversion연동 기능은 그렇게 편리하지 않습니다. 그래도 사용법에 대해서 잠시 알아보죠.


우선 Xcode의 Preferences의 SCM항목에서 이미 구축된 Repository를 등록해야 합니다. 그래야 Xcode에서 해당 Repository와 Xcode 프로젝트를 연결 할 수 있습니다.

그리고 Xcode>SCM>Repositories에서 해당 Repository의 디렉터리를 만들어야 합니다. 

위 그림과 같이 branches, tags, trunk로 나누면 됩니다. 디렉터리를 어떻게 나누냐 하는 이슈는 전략이 필요한 항목이므로 신중하게 판단해야 합니다.

소스코드를 서버에 등록하기 전에 먼저 설정할 것이 있습니다. Subversion에 등록되면 안되는 파일을 설정해야 합니다. ~/.subversion/config파일을 열면 global-ignores 항목이 있습니다. 여기에 등록되면 안되는 파일의 패턴을 적어주면 됩니다. 저는 일단 build 디렉터리만 등록되지 않도록 했습니다. 그외에도 빌드시 생기는 임시 파일들이 있거나 하면 그 패턴을 등록해서 Subversion에 등록되지 않도록 해야 합니다.

 

그리고 Import 메뉴를 이용해서 Mac에 저장되어 있는 소스코드를 모두 Subversion 서버에 등록합니다. 
이제 서버의 소스코드를 내려 받아야 하는데, 기존에 소스코드가 있던 디렉터리에는 내려 받을 수 없으니 소스코드의 디렉터리를 임시로 바꿔놓고 Check out을 통해서 소스코드를 내려받습니다. 소스코드를 내려 받았다고 해서 Xcode와 바로 연결되지는 않습니다. Xcode연동 기능을 사용하지 않을 거라면 여기까지만 하면 되지만 Xcode와 연동해서 사용하려고 하면 Xcode Project와 Subversion repository를 연결해 줘야 합니다.

Xcode에서 Check out하여 내려 받은 프로젝트를 Open하고 Project info를 보면 우상단에 "Configure Roots & SCM..."이 있습니다.


그 버틑을 클릭하면 이미 등록한 리파지토리중에서 본 프로젝트와 연결한 리파지토리를 선택하도록 되어 있습니다. 간단하게 고르면 됩니다.


그리고 Groups & Files에서 마우스 오른쪽 버튼을 눌러서 SCM을 선택하면 SCM과 연동 상태를 확인할 수 있습니다.

이제 Xcode의 SCM 메뉴를 통해서 소스코드를 관리할 수 있게 됩니다.
기본적으로 소스코드를 Check out하고 Commit하고 Tag, brach까지 이 기능을 이용해서 할 수 있도록 되어 있습니다. 하지만 제가 간략하게 본 바로는 Conflict를 해결하고 Merge를 하는 등의 협업이 필요한 작업은 지원이안되는 것 같더군요. 혹시 제가 모르는 방법이 있다면 알려주세요. 
그래서 이럴 때는 다른 솔루션들을 추가로 사용해야 하겠더군요.

 맥용 SVN Client 사용

Syncro, Diffly등 몇몇 유/무료 SVN Client가 있습니다. 하지만 이 부분은 제가 Evaluation을 해보지 않았습니다. 추후 써보게 되면 내용을 보강하도록 하지요.

 터미널 사용

Command line에서 SVN을 사용할 수 있다면 Windows, Linux, Mac 어느 OS에서든지 동일하게 SVN을 사용할 수 있습니다. SVN의 모든 기능은 Command line에서 사용할 수 있도록 되어 있습니다. 단지 Merge등의 몇몇기능이 GUI환경에서 더 편한 것 뿐입니다. Mac에서도 Command line 명령어를 이용하여 SVN을 사용할 수 있습니다.


 가상머신 + TortoiseSVN 사용

마지막으로 제가 최종적으로 선택한 방법은 TortoiseSVN을 이용하는 방법입니다.
Windows에서 TortoiseSVN을 오랫동안 사용한 개발자라면 그 편리함을 잊지 못할 겁니다.
저는 Parallels Desktop에 Windows7을 설치한 다음에 TortoiseSVN을 사용하고 있습니다.
Mac의 모든 디렉터리가 Windows에서 접근 가능하니 Windows에서 사용하는 것과 거의 동일하게 TortoiseSVN을 사용할 수 있습니다. 이렇게 하여 Windows에서 사용하던 Merge tool도 그대로 쓸 수 있게 되었습니다.
Windows에서 TortoiseSVN을 사용할 경우는 Mac에서 SVN을 설정하는 것과 별도로 Windows에서 SVN을 설정해줘야 합니다. C:\Users\{사용자ID}\AppData\Roaming\Subversion\config 파일을 열어서 아까와 같이 global-ignores를 설정하면 됩니다.



저는 기본적인 SVN Commit기능만 쓸때는 Xcode기본 기능을 사용하고 브랜치, 태그, 머지 기능을 사용할 때는 Tortoise SVN을 사용하고 있습니다. 또한 개발자가 여러명이라면 그냥 TortoiseSVN을 사용하는 것도 좋을 것 같습니다.

이상으로 Mac에서 Subversion을 사용하는 방법을 알아봤습니다. Subversion을 제대로 사용하는 방법은 완전히 별개 이슈이니 제 책과 블로그의 다른 글들을 참고하세요.

수정하거나 덧붙일 내용이 있으면 댓글 남겨 주세요.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by silent (e)



저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 Diffly, MAC, SCM, subversion, svn, Syncro, TortoiseSVN, xcode, 맥북

  1. Blog Icon
    별의파편

    맥에서도 tortoise 클론이 있습니다. finder에 연동되는 플러그인인데요.
    http://scplugin.tigris.org 에서 찾으시면 됩니다.

    저는 주로 zigversion 사용하는데 non-commercial은 무료신청할 수 있습니다. 가끔 회사에 놋북 갖고 가서 쓰기도 합니다만....ㅡ.ㅡ;;;

  2. 좋은 정보 감사합니다. 한번 Evaluation 해보도록 하죠.

  3. Blog Icon
    안관수

    scplugin으로 시도해보려고 했는데, 가상머신을 이용할수도 있겠네용
    좋은정보 감사합니다.

소스코드는 어디 있나요?

2010.03.29 15:33 by 전규현


잠시 후 Google blogger로 이동됩니다.





나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다.

"소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다.

그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다.
대부분 아래와 같은 답변들이 돌아옵니다.
  • 내 PC에 소스코드가 저장되어 있습니다. 
  • 아직 정리가 안되서 소스코드관리시스템에 등록하지 않았습니다.
  • 빌드는 IDE(Eclipse 등)에서 해야 합니다.
  • 빌드하기 위해서는 이런 저런 라이브러를 알아서 직접 설치해야 합니다.
  • 아참, 설정을 이렇게 바꿔야 하는데 깜빡했습니다.
  • 지금 내가 소스코드를 고치고 있어서 공유가 어렵습니다.
이런 얘기가 진행되는 동안에 일은 정상적으로 진행이 되지 못하고 여러 번 만나서 대화로 소스코드 공유 문제를 해결해나가야 합니다. 

혼자서 또는 개발자들끼리 익숙해져서 나름대로 방식으로 소스코드를 관리하면서 스스로 아무 문제가 없다고 생각하고 있는 개발자들은 냄비 안에서 물이 점점 뜨거워져서 죽는 개구리처럼 소스코드관리 문제가 점점 커져서 문제가 얼마나 심각한지 인식하고 있지 못하고 있는 겁니다. 이는 기본 중에 기본으로 자꾸 소스코드 관리 문제를 가지고 얘기를 하면 민망하고 한심하기도 합니다.

소스코드를 꽉 쥐고 요청하는 사람들에게 '모이'주듯이 하나씩 던져 주는 개발자들은 이로 인해서 얼마나 많은 자신의 시간을 낭비하고 있고 정작 자신이 제대로 개발할 시간은 모자라고 회사에도 손해를 끼치며 자신의 발전도 가로막는다는 것을 알아야 합니다.

정상적인 경우는 다음과 같습니다.

개발자가 1명이든 100명이든 1000명이든 상관없이 모든 소스코드는 당연히 소스코드관리시스템에 등록이 되어 있어야 합니다.
구차하게 이거 저거 물어보지 않아도 소스코드가 저장된 경로만 알면 누가나 소스코드를 Check out해서 클릭 몇 번이면 Build Script를 찾아내서 즉시 빌드를 할 수 있어야 합니다. 당연히 컴파일러 등의 빌드 환경은 설치가 되어 있어야죠.
여러명이 동시에 소스코드를 마구 고쳐도 전혀 걱정할 필요가 없어야 합니다.

이때 구차하게 이거 저거 물어 봐야 빌드가 되고 IDE를 실행 해야 하고, 빌드 중간에 명령어를 입력해야 하는 등의 바로 알기 어려운 행위들을 해야 하면 안됩니다.

이 정도는 되어 있어야 Daily Build가 가능해지고 프로젝트 내내 소스코드 관리 비용을 최소화 할 수 있습니다.
이 정도는 되어 있어야 엄청 복잡한 소스코드 상황을 깔끔하게 관리할 수 있습니다.
이 정도는 되어 있어야 내가 휴가를 가도 아무나 빌드를 할 수 있습니다.
이 정도는 되어 있어야 개발자들이 빌드를 하지 않고 빌드 담당자에게 빌드를 맡길 수 있습니다.
이 정도는 되어 있어야 누구와도 심지어는 외부인과도 협업을 할 때 말 한마디면 소스코드 공유 준비는 끝납니다.
이 정도는 되어 있어야 개발자는 진짜 개발에 집중할 수 있습니다.

이게 뭐 큰 일이냐라고 생각할지 모르지만 이렇게 생각하는 개발자는 위에서 얘기한 기초 중의 기초가 안되어 있다고 생각하면 됩니다.

소스코드 관리는 워낙 기초이기 때문에 누구나 제대로 방법만 익히면 제대로 수행하는데 오래 걸릴 일도 아닙니다. 똑똑한 개발자라면 일주일이면 방법을 다 터득합니다. 분석, 설계 작업이 방법을 제대로 익히고도 제대로 하는데 수년이 걸리는 것과는 안전히 딴판입니다. 그럼에도 아직도 많은 개발자들이 소스코드 관리를 제대로 하고 있지 못하거나 제대로 하려고 흉내는 내는데 엉뚱한 곳에서 헤매는 경우가 많습니다. 원리는 매우 간단한데 말입니다.

소프트웨어 개발이라는 것이 협업이라는 것을 깨달으면 됩니다. 혼자서 개발하더라도 협업과 똑같습니다. 그렇게 해야 더 혼자 개발하더라도 더 빨리 개발할 수 있고 여럿이 개발할 때는 더욱 더 중요합니다.

소스코드관리시스템을 쓰기는 하는데 어중간하게 흉내만 내고 있다고 생각한다면 한번 확실하게 제대로 배워 놓을 필요가 있습니다. 그렇지 않으면 평생 기초 중에 기초에 문제거리를 안고 가는 겁니다.  

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by marsi

저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 subversion, svn, 소스코드, 소스코드관리

  1. 당연한 얘기를 글로써 상기 시킨다는 현실이 참 슬프네요
    저도 한번은 그렇게 큰 사이트가 아닌데 소스만 400MB
    짜리를 본적이 있었습니다. portal1,portal2,real-portal.....
    같은 디렉토리가 여러개 있는데 마치 닭 갈비집 이름 처럼
    "원조집","진짜원조집","진짜진짜원조집" 같은 느낌이였습니다.
    시스템은 점점더 고도화되고 복잡한 기술을 사용하는데
    개발 환경과 현실은 너무 구닥다리를 따르고 있습니다.

  2. Beyond J2EE님 안녕하세요.

    정말 적절한 비유입니다.
    이런 소스코드는 감당하지도 못합니다. 소스코드관리시스템의 브랜치와 머지 기능을 충분히 활용하고 개발 프로세스 상에서 이를 잘 통제하면 부처님 손바닥안의 소스코드죠.

    언제 다 같이 모아 놓고 세미나를 한번 하고 싶은 마음은 굴뚝 같은데 여유가 안생기네요. - -;

  3. Blog Icon
    옥수석

    항상 좋은 글 감사합니다^^ 개발자로써 구구절절 옳은 말씀만 올려주시지만 현실과의 괴리감이 드는 건 어쩔수가 없네요. 형상관리를 하고 있지만 어느 순간에서부턴가 각 개발자끼리 마치 개별 브랜치를 가진 듯이 다른 방향으로 진행되고 있는 상황을 자주 접하게 됩니다. 물론 상황에 따라 머징이 되긴 하지만 주기적으로 이루어지는 머징도 아니고 필요에 따라, 상황에 따라 이루어지다보니 커뮤니케이션이 소홀해 지는 경우 각자의 프로젝트는 결국 다른 산으로 가고 있더군요.
    다시 한번 좋은 글로 일깨워주심에 감사드립니다~^^

  4. 안녕하세요. 옥수석님

    당연한 기초가 현실과 괴리가 있는 현실이 안타깝습니다. 대학생들을 갈쳐도 몇주면 익숙해지는 것을 십수년 경력의 개발자들도 제대로 하지 못하는 것이 현실이기는 하죠.

    브랜치와 머지는 보통 개발자가 마음대로 하면 안됩니다. 이에 대한 회사의 정책이 있고 개발자는 이를 따라야죠. 일반적으로 브랜치는 승인하에서 합니다. 머지계획도 미리 작성해야 하고요. 번거로우라고 이렇게 하는 것이 아니고 이렇게 하는 것이 가장 효율적이기 때문입니다.

    또 머지는 3-way머지를 해야 합니다. 보통 2-way머지툴을 가지고 머지를 하는데 이는 수십배 더 시간이 많이 들고 잘못 머지가 될 가능성도 대단히 높습니다.

    이렇게 해 놓고 개발자들이 계획에 따라서 자유롭게 개발하는 것이 좋지, 대충 해놓고 뭔가 고칠려고 할 때마다 소스코드 공유/통합을 신경써야 한다면 프로젝트 기간 내내 소스관리 비용이 몇백배로 더 많이 들게 됩니다.

    산으로 가고 있다면 다시 땅으로 끌어 내려야 겠네요. ^^ 필요하면 제가 세미나 등을 통해서 개발자와 경영진들을 설득시키고 교육도 시켜주곤 합니다.

  5. Blog Icon

    비밀댓글입니다

  6. Repository를 어떻게 나누고 각 Repository안의 프로젝트 별 디렉터리를 어떻게 구성하는지는 회사마다 다릅니다.
    일단 revision number는 신경쓰지 않는 것이 좋습니다. revision number에 의미를 부여해서 사용하면 나중에 문제가 발생합니다.
    Repository구분은 각 프로젝트가 단 0.1%라도 서로 연관성이 있는지를 봐야 합니다. 공유되는 소스코드가 있는지? 나중에 쓰고 버릴 소스코드인지? 백업은 공통으로 해야 하는지? 이렇게 생각을 해보고 연관이 있으면 한 Repository에 넣는 것이 좋습니다.
    Repository안의 디렉터리 구조는 각 프로젝트가 완전히 자동으로 Build가 가능하도록 구성을 해야 하는데 공통모듈이 잘 관리되고 있는 회사가 아니라면 이 말이 무슨 뜻인지 잘 모를겁니다. 하지만 공통모듈이 있다면 디렉터리를 어떻게 구성하냐에 따라서 빌드가 달라집니다.

    이렇게 여러가지를 고려하여 처음부터 잘 정해 놓고 시작해야지 나중에 바꾸려고 하면 큰 문제입니다.

    리파지터리 주소는 프로젝트 check out할 때 처음에 한번만 입력하면 되는 것이기 때문에 기억하는 것은 문제가 알될 것 같습니다.

  7. 늘 잘 안되는 것들이 포스팅이 되어서 마음이 아팠었는데

    오늘 포스팅에 대해서는 자신감이 생기네요..
    svn을 사용하고 있고 capistrano를 통해서 각 환경(개발, 백업, 리얼)으로 소스를 deploy 할수 있고 이슈트래킹의 부가기능에 svn history를 연결해놔서 누가 언제 어떻게 고쳤는지 웹상으로 확인할수 있습니다. ^^ 이정도면 자신감을 가져도 괜찮겠죠?

  8. 안녕하세요. zeous님
    일단 SVN과 이슈트래킹(아마 Trac)을 연동해서 잘 쓰고 계시나보네요. 평균 이상은 되시네요. ^^
    항상 안되는 것만 있으면 빵점이게요? 그럴리가 있겠습니까? 항상 포스트를 보면서 조금씩 고쳐나가자는 의미입니다.
    SVN을 잘 쓰시는 것 같기는 한데 Branch, Merge는 어떻게 하는지 궁금하네요. 사실 SVN의 핵심은 Merge거든요. 나중에 Git나 Mercurial들의 분산소스코드관리시스템을 쓰더라도 Merge를 제대로 하지 못하면 반쪽짜리가 됩니다. 그래서 3-Way Merge를 능수능란하게 다룰 수 있어야 합니다. 어떠신가요?

  9. branch를 전혀 쓰지 않는 것은 아닙니다.
    이번에도 새로운 프로젝트를 시작하는데 기존 소스의 서비스도 유지하면서 거기에서 파생되어서 추가적인 작업을 하고 완성후에 합치기 위해서 branch를 생성해서 작업을 하고 있습니다만은

    branch를 생성하고 나서 마지막에 합칠때 실수하지 않을까 (자동으로 하게 되면 가끔 한쪽을 날려먹는 경우가 있어서 안볼수는 없더라구요)
    챙겨야 할것들이 있기에 이왕이면 안만들어졌으면 하는 바램은 있습니다 ^^

  10. SVN을 쓰는 곳, 다수가 해당 소스를 Root에 그냥 올려버리는 곳을 많이 봤습니다.
    Branch나 Tags, Merge와 같은 기능은 꺼버리고 사용하는 것과 마찬가지 인데도 불구하고 말입니다.
    초반엔 인식을 심어주려고 교육도 해보고 노력했으나..역시나 이쪽 부분엔 관심 없어 하더군요.

    무술고수가 항상 강조하는 기본기 "정권찌르기"를 거스르고 현란한 기술만 쓰고자 하는 사람들의 심리때문일까요? 아니면 남들이 모르니 나도 몰라도 된다..라는 심리때문일까요

    가장 기본이 되는 소스코드 관리 정말 중요하죠~ 말이 필요없다고 생각합니다.
    하나를 보면 열을 안다고.. 이런 기본을 중요시하는 기본기가 탄탄한 조직은 정말 안정적인 조직이라고 생각합니다. ( 비단 소스코드관리뿐만이 아닌...:)

  11. moova님 안녕하세요.
    제가 좀 바빴네요. - -;
    소스코드시스템을 쓰는 이유가 소스코드를 잃어버릴까봐 백업용도로만 쓰는 곳이 의외로 많습니다.
    빠뀌지 않는 이유는
    1. 막연히 새로운 것을 배우는 것이 귀찮아서
    2. 나아진 다는 확신이 없어서
    3. 현재 방법에 익숙해져서
    4. 가르쳐 주는 사람에 대한 믿음이 부족해서
    5. 소스코드를 감추려고
    등등 다양합니다.
    산넘어 산입니다.
    그래서 카리스마 있는 사람의 도움을 받아서 설득을 하면서 강제화하는 것이 가장 좋은 방법입니다.

  12. 어느분이 지적하신대로 저 역시 Branch, Tags, Merge 기능을 사용해보질 못했네요 -_-;

  13. 현재 SVN의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜치 요구는 항상 생깁니다.

VSS, CVS, SVN 비교

2009.01.08 12:22 by 전규현


잠시 후 Google blogger로 이동됩니다.



Google Trend에서 세가지 SCM(Software Configuration Management)의 경향을 살펴봤습니다. (아래 그림 참조)

CVS가 여전히 압도적인 우위를 점하고 있고, 상대적으로 SVN은 꾸준히 성장을 하고 있습니다. 물론 Google Trend가 실제 제품의 점유율을 보여주지는 않지만 그만큼 사람들의 관심사는 엿볼 수 있을 것 같습니다.
CVS의 감소는 SVN으로 대체되고 있는 듯 보입니다.
하지만 이렇게 더딘 이유는 CVS도 충분히 좋은 SCM이고 더 좋은 SCM이 나왔다고 함부로 바꿀 수 있는 것이 아니기 때문입니다.
물론 새로 시작하는 회사가 있다면 SVN을 쓰면 좋겠지만, 기존에 수년가 CVS를 쓰던 회사가 치명적인 문제도 없는데 SVN을 그냥 바꿀 필요는 없겠지요.

(3가지를 비교한 그래프입니다. SVN의 성장이 눈이 띕니다. 아래 Comment의 권남님이 제시한 그래프를 보면 SVN의 비율이 훨씬 더 높아지네요. 그리고 미국과 인도에서의 CVS 검색 비중이 아주 높고 나머지 나라에서는 SVN이 더 높은 나라가 많네요.)

(VSS는 점차 감소 추세입니다.)

(CVS는 약간의 감소추세이나 급격하지는 않네요)

(SVN의 성장 추세는 괄목할 만하네요)


제가 가장 오랫동안 사용한 SCM은 VSS입니다. 제가 사용한 VSS는 v6.0이었습니다.
물론 유료지요. 하지만 제가 종종 겪었던 가장 큰 문제는 깨지는 저장소였습니다. CS구조가 아닌 NFS 방식으로 파일을 공유하기 때문에 그런 문제가 있었던 것으로 생각합니다. 물론 VSS 2005에서 안정성(stability)를 향상하고 HTTP를 지원한다고 하지만 그 당시는 제가 SVN을 사용하고 있을 때라서 VSS가 얼마나 좋아졌는지 모릅니다. 혹시 최신 VSS를 쓰고 계신 분은 평가를 올려주시면 좋겠습니다.

하지만, 안정성이 가장 중요한 요소 중 하나인 SCM에서 자주 깨지는 저장소는 신뢰를 잃기에 충분했습니다. 
매일 백업을 받고 있었으므로 몇 시간 분량의 손실만 있을 뿐 복구는 할 수 있었지만, 개발 시간을 낭비하게 만드는 것은 아주 짜증나는 일이었습니다.

그리고 허약한 Branch기능은 부족한 기능 중에 하나였습니다.

그 뒤에 CVS를 거쳐서 SVN을 사용하게 되었는데, 제가 써본 SCM 중에서 최고는 SVN입니다.

VSS < CVS < SVN 이라고 생각합니다.

SVN은 일단 무료이며, 그 오랫동안 사용하면서 저장소는 단 한번도 깨진 적이 없습니다.
그리고 빠릅니다. 아무리 큰 디렉터리를 태깅하거나 브랜치를 해도 시간은 몇 십초 안 걸립니다.
CVS에서 엄청나게 큰 디렉터리 태깅하면서 기다려보신 분은 아실 겁니다.
그렇게 빠른 이유는 SVN은 기존의 SCM의 파일 시스템과 완전히 다른 방식을 사용하고 있기 때문입니다. 기존의 대부분의 SCM들이 RCS(Revision Control System)에서 기초한 파일시스템을 사용하는데 반해서 SVN의 파일시스템은 기존의 단점을 없애고 새로 만들었습니다. 즉 각 Revision의 Diff만 저장하는 방식입니다.
따라서 태그나 브랜치를 만들 때는 Diff가 없으므로 순식간에 이루어집니다.

그리고 SVN의 VSS와 비교한 장점 중의 하나가 협업이 훨씬 쉬워졌다는 겁니다.
SVN도 Lock기능이 있지만, 이걸 사용하지 않고도 협업에 문제가 없습니다. 왜냐하면 하나의 파일을 동시에 수정할 경우에는 Merge를 해주기 때문입니다. 이때 사용하는 3way Merge에 대해서는 제가 올린 글이 있으니 참조하세요.

기존에 VSS를 사용할 때는 물론 Multi-lock 기능이 있기는 하지만, 며칠씩 Lock을 걸어 놓고 풀지 않는 사람 때문에 보통 귀찮은 게 아니었습니다. SVN을 사용하면서 이런 문제는 싹 사라졌습니다.

VSS를 사용하면서는 IDE와 통합되는 기능이 왠지 멋져 보이고 매우 편리하다고 생각했었는데, SVN과 TortoiseSVN을 IDE와 별도로 쓰면서 불편하게 생각되어 본 적이 별로 없었습니다. SVN도 IDE와 통합해주는 Plug-in들이 있지만 이는 취향에 따라서 선택하면 되고 꼭 써야 하는 필수요소는 아닙니다.

결국 SVN의 빠른 속도, 안전한 저장소, 뛰어는 브랜치 기능, 머지기능 등은 저와 저희 팀이 즐겁게, 제대로 일하는데 많은 도움을 주었습니다.

누군가 새로 SCM을 사용하려고 한다면 SVN을 추천합니다.
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 cvs, svn, VSS

  1. Blog Icon
    권남

    비교가 완벽하지는 않은 것 같습니다. svn은 svn말고 subversion으로 검색하는 비율도 높기 때문입니다.
    http://google.com/trends?q=cvs%2Csvn|subversion%2Cvss|sourcesafe|visualsourcesafe%2Cgit%2Cmercurial&ctab=0&geo=all&date=all&sort=0
    이게 더 정확한 결과 일듯 합니다.
    그리고, 저도 SVN이 더 좋습니다. 가장 좋은 점은 파일별이아닌 각 커밋별로 리비전을 관리한다는 점입니다. 불필요한 Tag를 생성할 필요를 줄여주죠.
    예전엔 eclipse용 클라이언트가 너무 후져서 거부감이 들었는데, 요즘엔 Eclipse용 클라이언트도 많이 안정화가 돼서 별다른 불편도 없네요.

  2. 권남님 안녕하세요.
    그렇게 하니 SVN의 비율이 더 높은 수치로 나오는 군요. 감사합니다.

  3. Blog Icon
    mixed

    git이나 mercurial 등의 분산형 소스코드 관리시스템의 비교는 한번 안하시나요^^;;
    잼있게 구독하고 있습니다.^^

  4. mixed님 안녕하세요.
    나중에 한번 기회가 되면 할려고 생각은 하고 있습니다. 지금 준비 중인 이슈가 많이 있어서 추후 올려보도록 하겠습니다.

  5. 재미있는 비교네요 ㅎㅎ
    다만 한가지, CVS가 압도적으로 많은건 CVS가 아직 많이 사용되기 때문이기도 하지만
    미국에 전국 대형 약국 체인중에 CVS가 있는것도 한 몫 하는것 같습니다 (이미 아실지도 모르겠지만요)
    그래서 위의 비교에서는 CVS가 실제 이상으로 많은 점유율을 차지하는것 같습니다.
    아무튼 저는 CVS밖에 안써봐서 잘 모르겠지만, 요즘 정말 SVN이 잘 나가는것 같습니다 ㅎㅎ

  6. fancyydk님 안녕하세요.
    찾아보니 www.cvs.com이 약국체인이네요. 몰랐었습니다. 그래도 여전히 CVS를 많이 쓰고 있겠죠?

  7. Blog Icon
    allting

    좋은 글 잘 보고있습니다^^

  8. allting 님 안녕하세요.
    항상 관심 가져 주셔서 감사합니다. 좋은 S/W를 개발하고 계시더군요. 앞으로도 자주 의견 주고 받고 싶습니다.

  9. 오래된 글에 리플 남기게 되네요 ㅎㅎ
    음.. 개인적으로는 SVN은 사용하고 회사에서는 CVS를 사용하지만, 관리자 측면과, 사용자 측면은 반비례 하는 편이라서 어느편이 좋다라고 하긴 애매한 감이 있습니다.

    사용자 측면에서는 속도라던가 여러모로 편리한 SVN에 손을 들에 주게 되지만,
    svn:// 방식으로 사용시에는 비밀번호가 평문으로 저장된다던가, 로그가 남지 않는다던가 하는 아쉬운 점이 있습니다.(물론 fake-security일지두 모르지만요) 그래서 대부분이 http+svn://을 사용하는 경향이 있는것 같습니다.

    아무튼 svn+ssh:// 든 svn:// 이든 svn+http 만큼의 사용자 편의는 제공하지 않는다는 점과, repository 기본 골격 구조등의 차이로 인한 관리의 어려움은 (tag / branch 디렉토리) cvs에 손을 들어주고 싶습니다.

    아마 이러한 관리상의 아쉬움을 svn이 보완한다면 svn이 완전한 대세가 되겠지만,
    사용상의 편함만으로 cvs를 버리고 svn으로 가기에는 조금 아쉬움이 있습니다.

  10. 안녕하세요. 구차니님
    SVN과 CVS, VSS를 모두 오랫동안 써온 저는 SVN에 가장 높은 점수를 줍니다. 외형적인 기능 면으로는 크게 차이가 없어보이지만 보이지 않는 부분에서 많은 차이가 납니다. SVN의 아키텍처가 가장 훌륭하죠. 그래서 속도도 빠릅니다. tag, branch가 디렉터리로 관리되는 것이 좀 어려울 수 있지만, 이것도 익숙해지면, CVS보다 더 편리하더군요. 좋은 의견 감사합니다.

  11. Blog Icon

    tfs가 최고죠-_-;;; 자바 닷넷 해보면서 tfs만큼 편한 것은 없습니다..;; 유료에 설치가 꽤 까다운 편이지만요..그담은 당연 svn입니다만..그러고 보면 ms가 툴하나는 참 잘만드는 것 같습니다..ㅎㅎ

  12. 안녕하세요.
    TFS(Team Foundation Server)는 국내 레퍼런스가 100개 미만으로 알고 있는데, 사용하고 계신가보네요.
    언제 TFS와 SVN도 비교를 해서 올려보는 것이 좋겠네요. 사실 TFS는 Rational 솔루션들이 너무 무겁다면 가볍게 나온 솔루션이지만 이것 역시 엄청나게 무겁고 개발자에게 부담을 주는 것은 마찬 가지입니다. 기능면으로 비교하면 SVN에 있는 기능은 다 있고, 여타 다른 기능들과 많이 연동이 되어 있는 종합 선물세트죠.
    한방에 해결하고 싶은 분들은 쓰면 좋을 것 같습니다. 하지만 각각의 시스템중에서 가장 좋은 것들을 골라서 서로 느슨하게 연동하고 가볍게 쓰고 싶은 분들은 다른 선택을 하시는 것이 좋겠네요.

소스코드관리시스템을 몇개 사용하고 있나요?

2008.11.07 15:04 by 전규현


잠시 후 Google blogger로 이동됩니다.






소프트웨어 개발 컨설팅을 하다보면 여러가지 경우를 보지만 그중의 한 예를 소개할까 합니다.

국내의 굴지의 금융회사 중의 한 사례입니다.
회사 내에서 각 팀별로 소스코드관리시스템을 여러 개를 사용하고 있더군요.
A팀 Windows 플랫폼의 Application를 개발하니까 Microsoft Visual SourceSafe를 사용하고
B팀 Web 서비스를 개발하고 있었는데, CVS를 사용하더군요.
그리고 C팀은 Unix에서 개발을 하는데, 아무런 소스코드관리시스템을 사용하고 있지 않았고,
D팀은 별로 잘 알려져 있지 않은 외국의 상용 제품의 한글화된 버전을 사용하고 있었습니다.

한 회사에 총 4가지 유 형의 소스코드 관리가 존재하는 겁니다.




이런 상황에서는 다음과 같은 부작용이 생깁니다.
  • 개발자들이 다른 부서로 이동할 때 쓸데 없는 학습 비용이 들어 갑니다.
  • 중복된 시스템 및 관리 비용이 들어갑니다. 소스코드관리시스템은 비용이 많이 들어가는 시스템입니다. 
  • 각 부서간의 정보의 공유가 어렵게 됩니다.

이런 일들이 발생하는 이유는 다음과 같습니다.
  • 회사에서 기술적인 결정을 컨트롤하는 상위 조직이 없어 개발자들의 입맛에 따라 각각 다른 시스템을 쓰게 된 경우
  • 회사를 인수하면서 기존의 시스템을 그대로 사용하고 통합을 시도하지 않은 경우

소스코드관리시스템은 한 회사에 딱 하나만 설치하는 것이 좋습니다. 세계 각지에 떨어져서 개발을 하더라도 하나의 소스코드관리시스템을 사용해야 합니다.

만약 이미 여러가지 소스코드관리시스템을 사용하고 있다면 비용을 지불하고라도 통일을 하는 것이 좋습니다.
이러한 통일 작업은 기계적으로 할 수도 없는 어려운 작업이 됩니다. 
하지만 늦어질 수록 더 많은 비용을 치르게 됩니다.

저작자 표시
신고

전규현 기반시스템/소스코드관리 cvs, svn, VSS

  1. 안녕하세요. 댓글 남기신 거 보고 따라왔습니다. S/W 개발 consulting 쪽 일하시나 보네요. 종종 들르겠습니다. 트랙백 남기고 갑니다.

  2. 김윤수님 안녕하세요.
    김윤수님 블로그에 가보니 소프트웨어 개발에 대한 많은 애정을 가지고 계신 것을 느끼겠더군요.
    앞으로 많은 왕래 기대하겠습니다.
    감사합니다.

  3. 그렇죠~ 소스관리는 무척 중요합니다.

    개인적으로는 무료 공개프로젝트 SVN 을 좋아합니다.

  4. kyuseo님 반갑습니다.
    저도 아주 오래전부터 RCS, VSS, CVS, SVN 다 써봤지만, SVN을 선택해서 쓰고 계시다면 가장 좋은 선택을 하신 것이라고 말씀드리고 싶습니다.
    앞으로 소스코드 관리에 대해서는 심도있게 많은 내용을 다루려고 계획하고 있습니다. 많은 관심 부탁합니다.
    감사합니다.

  5. 저희 회사는 소스세이프를 사용하고 있는데, 이게 여러모로 호환되는 제품이 많더라구요.. ^^;
    그러나, 몇몇 코드가 꼬이는 문제점이 있다고 해서 가끔 당혹스러울때가 많더라구요..
    회사에서 만들어지는 개발 프로그램은 자꾸 늘어나고, 소스 관리는 점점 어려워지고.. ㅠㅠ
    앞으로 다루시는 심도있는 내용에 관심이 막 생기는데요~ +_+

    기대하고 있겠습니다.. ㅎㅎㅎㅎ

  6. kkommy 님 소스세이프는 비추천입니다.
    나도 오랫동안 소스세이프를 써왔고, 여러소스관리시스템을 써왔지만, 소스세이프만큼은 비추천입니다.
    새로 바꾸실 계획이 있다면 Subversion을 추천합니다.
    후회없는 선택이 될 겁니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바