태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

빈 줄도 지워서는 안된다.

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
    나그네

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

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

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

소스코드가 없어졌다.

2013.09.04 19:58 by 전규현


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





필자는 소스코드가 없어진 Software 회사를 여러번 보았다. 물론 회사의 전체 소스코드가 없어진 것은 아니다. 일부 소스코드가 없어져서 낭패를 보는 경우는 매우 흔하다. 소스코드는 어떻게 없어지게 될까? 물론 아래 모든 경우는 전사적인 소스코드 관리 및 백업을 받지 않은 경우에서 발생한다.


1. 하드디스크가 망가졌다.


하드디스크는 그렇게 믿을 만한 미디어가 아니다. 어느날 갑자기 망가져 버릴 수도 있고 복구가 안되는 경우도 종종 있다. 10년간 잘 돌던 하드디스크가 PC를 옮겼더니 갑자기 먹통이 되는 경우도 있다. 이런 경우 백업이 없다면 소스코드를 잃어버리는 것이다. 각 개발자의 PC에 사본이라도 있다면 History는 없어져도 최신 소스코드는 건질 수 있지만 그렇지 않아서 소스코드르 잃어버리는 경우를 종종 보았다.


2. 외주를 주고 소스코드를 받지 않은 경우


이 경우도 의외로 많다. 개념이 없이 소스코드를 받지 않은 경우도 있고, 계약상 소스코드는 제공하지 않는 경우도 있다. 두경우 문제가 되기는 마찬가지다. 개발툴을 업그레이드하려면 소스코드가 필요한데 그럴때 외주사가 망해 버리면 영영 발목이 잡혀버린다. 이럴 때는 소프트웨어진흥원에 소스코드 에스크로를 하면 회사가 망했을 때 소스코드를 가져올 수 있다. 외주사가 망해서 소스코드가 없어지는 경우은 의외로 흔하다.


3. 개발자가 소스코드를 관리하다가 퇴사를 한 경우


회사의 중요 제품이라면 소스코드를 잃어버리는 일이 흔하지 않지만 오래된 제품이나 툴등의 소스코드라면 개발자가 대충 소스코드를 보관하고 있다가 퇴사를 해버려서 언제 어떻게 잃어버렸는지도 모르게 소스코드가 없어지는 일이 발생한다. 수년 후 나중에 소스코드가 필요할 때 없어졌다는 사실을 알게 된다.


4. 회사의 소스코드관리시스템(SCM)을 백업받지 않은 경우


소스코드관리시스템을 도입하고 백업을 받지 않는 회사는 엄청나게 많다. 놀랄 일이다. Git등의 분산SCM을 쓴다면 어딘가에 백업이 있지만 SVN을 쓰다가 서버가 날아가면 간신히 부분적인 최신 소스코드만 건지게 된다. History가 사라진 최신소스코드는 그 가치가 몇분의 일로 줄어든다. 물론 많은 회사가 소스코드관리를 제대로 하지 않아서 History가 거의 가치없는 경우가 많다. 하지만 소스코드관리를 제대로 한 경우라면 History는 꼭 필요하다. SCM의 백업은 선택이 아닌 필수다.


이를 방지하는 방법은 전사적으로 소스코드관리를 철저히 하는 것이다. 하나의 통일된 소스코드관리시스템을 사용해야 한다. 회사 몰래 개발자가 숨겨 놓은 소스코드가 존재하면 안된다. 아무리 그렇게 관리를 해도 개발자들이 개인적으로 가지고 있는 소스코드가 존재할 수 있다. 스크립트라고 등록하지 않고, Install shield 프로젝트는 등록하지 않기도 한다. 이런 문제가 발생하는 또다른 이유는 개발자가 개발자PC에서 빌드를 하기 때문이다. 빌드를 빌드 전용서버에서 빌드 담당자가 하게 될 경우 숨어 있는 소스코드를 모두 끄집어 낼 수 있다. 빌드 전용서버는 오로진 SCM에서 소스코드를 가져다가 빌드를 하기 때문에 개발자PC에 숨겨진 소스코드가 있다면 빌드가 되지 않게 된다. 개발자를 못 믿어서가 아니고 빌드는 개발자PC에서 하면 안되는 것이다.


그리고 백업을 제대로 받아야 한다. 백업은 제3의 장소에 보관해서 회사가 완전히 불타 없어져도 소스코드를 바로 복구할 수 있어야 한다는 생각으로 백업을 해야 한다.


이런 환경을 구축하는 것은 비용이 더 많이 드는 일이 아니다. 제대로 관리를 하지 않고 소스코드를 엉망으로 관리하면서 오는 비효율과 비용 및 손실과 비교하면 훨씬 이익이다.


image by Daniel Dreier




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

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

  1. 지금 모처에서 뭔가 외주로 책을 써주는데 관공서들도 기록을 최근(그나마 기록물에 대한 인식이 생긴 금세기) 것만 가지고 있더군요.
    뭐 행정서류는 일정기간이 지나면 파기하지만 역사기록물에 해당하는 것들도..
    아니 아예 기록을 보존한다는 생각이 없..
    저건 소프트업계의 부주의가 아니라 사회 전반적인 문제 같습니다.

SVN보다 Git가 더 좋을까?

2011.10.25 04:56 by 전규현


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





요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.
  1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
  2. Github를 써야 한다면 Git를 써라.
  3. 그외에는 모두 SVN을 써라.
기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 
CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 

일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.
  • Folder공유 타입 - RCS, SCCS
  • Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
  • 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs
폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.
C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.
또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.
  • Offline에서 자주 개발을 해야 할 때
  • Git 기반의 Open source를 이용한 개발을 해야 할 때
  • Git 기반의 Open source 프로젝트에 참여할 때
  • Github을 써야 할 때
이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.
SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다.

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.

SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

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

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

  1. 헐.....
    마지막 문장에서... 좌절했습니다.
    :(

    열심히 보고는 있지만 (항상 좋은 글 감사합니다.)... 설명해줘라? 조언??
    -_-;;

    그냥 개발자 안할래요 :( ...

    -마음가는 길은 곧은 길-

  2. 안녕하세요. trueonot님

    개발자가 아니라면 굳이 신경쓰지 않으셔도 됩니다. ^^

  3. 최근 고민 중의 하나 였는데, 애정남처럼 깔끔히 정리를 해주시네요.^^
    저는 Git에 해당되지 않아서 SVN에 더 많은 애정을 줘야 겠습니다.

  4. 제이즈님 안녕하세요.

    SVN이냐 Git보다 어떻게 쓰느냐가 더 중요합니다.
    제가 본 90% 이상의 회사들이 SVN을 쓰던 Git를 쓰던 엉터리로 쓰면서 제 기능의 5%도 활용 못하고 있습니다.
    그만큼 제대로 쓰기는 어렵습니다.

  5. Blog Icon
    멤피스

    mercurial은 왜 버리시나요 -_-;;;
    mercurial도 쓰기 편한데.
    구글링을 해보면 git vs. mercurial에 대한 비교 논쟁은 쓸데없는 일이라고 하네요. 그냥 닥치고(?) 하나 골라서 열심히 쓰라고.

    http://gitvsmercurial.com/ 대문에 적힌 글입니다. 좀 과격하지만 맞는 말인 듯하네요. :-)

    "Who the FUCK cares?

    Use what YOU like, not what someone on the internet tells you to."

  6. 멤피스님 안녕하세요.

    mercurial도 좋은 툴임에 틀림없습니다. Git가 사용률이 더 높으므로 대표로 말씀드립니다. mercurial이 편하면 mercurial 쓰시면 됩니다. ^^

  7. Blog Icon
    yducy

    좋은 글이네요.
    Git은 막강한 만큼 배우는데 비용이 많이 들더라구요.
    Android 같이 방대한 코드를 모듈화해서 관리할 때도 Git이 좋은 것 같습니다.
    Repo라는 툴이 있으니까요..

  8. yducy님 감사합니다.

  9. Blog Icon
    나지오

    git이 배우기 어려운건 기능이 많기 때문입니다. svn처럼만 사용한다면 그리 어렵지 않습니다. 중앙 저장소 두고 중앙 관리자 두고 pull, push(svn의 update, commit) 위주로 사용하는 거지요. 그쵸, 브랜칭, 병합 등으로 가면 헷갈리지요. 그건 개념이 달라서 어렵죠. svn은 중앙집중 관리, git은 분산 개발이 모토입니다.
    근데 git이냐 svn이냐의 선택 기준은 더 있습니다. svn은 느립니다. 특히 http에 태운 svn은 이제 2011년에 보니 문제가 심각하구나 생각이 듭니다.(아직 1.7의 http 성능 향상은 써보지 않았습니다만.)
    svn은 자체 권한 관리, http 연동, ldap 연동이 가능합니다. 그런데 git은 ssh에만 태울 수 있어서 ssh를 통해 사용자 인증을 처리해야 합니다. ldap 연동이 필요하면 ssh를 구성해야 하는 거죠.

  10. 안녕하세요. 나지오님

    SVN의 속도는 Git와 비교하여 가끔 이슈를 제기합니다. Git는 repository가 개인장비에 있으므로 전광석화같은 속도를 자랑하죠. ^^ 하지만 push, pull 때는 만만치 않죠. 게다가 clone을 만들 때는 많이 기다려야죠.

    SVN은 기존의 어떠한 SCM보다 빠릅니다. diff만 왔가 갔다 하므로 네트워크 상에서 속도가 빠르죠. 실제로 수백명의 개발자가 동시에 사용을 해도 성능이 문제가 되지는 않습니다.
    단 처음에 대량으로 check out을 받을 때는 좀 기다려야죠.

    SVN과 Git는 1:1로 성능 비교를 하기에는 성격이 너무 다릅니다. ^^ 둘다 좋습니다.

  11. Blog Icon
    나지오

    블로그를 안해서 모르는데 티스토리는 원래 댓글 줄바꿈을 없애나요? 댓글에 메일 주소 쓰는 거두 없구. 댓글 달리면 어떻게 알쥐...

  12. Blog Icon
    슬픈멍멍

    결론의 그외의 상황이라면 SVN을 써라보단,,개인적으론 가능하다면 Git을 써라가 낳을것같습니다.
    Git이 GUI툴의 지원이 상대적으로 부족해보이는 면이 있긴합니다.(주관적입니다)
    하지만 로컬에서의 브랜치작업은 SVN의 상대적인 직관적 사용법과 Git의 상대적인 난해함을 모두 커버하고도 남을 만큼 강력하더군요. SVN으로 브랜치생성해서 작업을 어쩌다 한번 하는 개발자는 공감하기어려울 수도 있으나 브랜치작업이 많은경우 Git은 너무나 편리합니다.

  13. 안녕하세요. 슬픈멍멍님 ^^

    제 결론은 SVN입니다. 엄마가 좋아? 아빠가 좋아? 토론은 하루 종일 할 수도 있죠. ㅎㅎ
    SVN은 브랜치, 머지에 있어서 부족함이 없습니다. Git가 브랜치,머지가 직관적이고 쉽지만 SVN은 강력하죠. SVN의 브랜치, 머지가 좀 어렵다면 Git는 기능적으로 풍부하고 다양하지만 경험이 부족하면 어렵습니다.설명이 복잡하지만, 이게 제 결론입니다.

  14. Blog Icon
    슬픈멍멍

    Git vs SVN은 주관적인것이기도 하지만 CVS 에서 SVN으로 거의 넘어오는 것을 보면,
    언젠가는 SVN같은 중앙 저장소 방식에서 Git,Mercurial 같은 분산 버전관리시스템으로 넘어가지 않을까 추측해봅니다 ㅎㅎ

    그러나 사실 Git 이냐 SVN 보다는 어떤 형상관리툴이라도 사용한다는게 중요한것 같습니다.

    글 잘보고 갑니다. 좋은 글 많이 부타드립니다 ^^

  15. SVN을 쓰던 Git를 쓰던 거의 대부분의 회사들은 제대로 사용을 못하고 있는 것이 현실이죠.

    누가 인기를 더 끌지는 저도 궁금하네요. ^^

  16. git는 소스 한번 받아 볼때 외에는 직접 사용해 본적이 없어서 잘 모르겠고
    cvs보다는 확실히 svn이 편하지만 서버구성하기가 조금 짜증이 나더라구요

    개인적으로는 svn을 사용하고 회사규모에서 사용해야 한다면 그냥 따르는것이 좋다고 봅니다 ㅋㅋ

  17. 구차니님 안녕하세요.

    SVN 서버 구성은 회사에서 딱 한명만 잘 알면 되잖아요. ^^ 나머지 사람들은 감사하게 그냥 잘 쓰면 되겠죠.

  18. 이번 글은 너무 명확해서 참 좋으네요.

  19. 김재호님 반갑습니다. ^^

  20. 네이버에서 SVN과 GIT에 대해 검색하다가 읽게 되었습니다. 전 SVN을 잘 쓰고 있거든요. GIT가 분산저장이라는건 알겠는데 도저히 감이 안 잡히네요.

    프로젝트관리툴로는 그동안 TRAC을 써오다가 Redmine을 쓰고 있는데 GIT에 적합한 프로젝트관리툴이 뭐가 있는지도 궁금합니다.

    여튼 잘 읽고 갑니다. 아직은 SVN에 익숙해서 그런지 계속 쓰게 되네요. GIT도 차차 공부해봐야겠습니다. ㅎㅎ

  21. 안녕하세요. 동범님

    Git는 서버자체를 각 PC에 두고 서로 복제하고 Merge하는 개념입니다. ^^ SVN을 잘 쓰시면 그냥 쓰시면 됩니다.

    Trac, Redmine 등은 프로젝트관리툴이라기보다는 이슈관리시스템입니다.

    대부분의 유명한 이슈관리시스템은 거의 Git, SVN 등과 연동이 잘 됩니다.

    굳이 필요하지 않은데 Git를 쓰려고 노력할 필요는 없고, 알아봐 놓는 것은 좋을 것 같습니다.

  22. Blog Icon
    탐구생활

    좋은 글 감사합니다. 제 생각으로는 GIT은 기존 제품을 혁신하는 제품이기 보다는 오프라인에서도 사용 가능한 틈새 시장용 버전컨트롤시스템인듯합니다. GIT의 유행은 제품 자체보다 제작자(리누스 토발즈)의 네임 밸류가 큰 역할을 한거 같습니다.

  23. 안녕하세요. 탐구생활님

    Git는 결코 무시할 수 없는 시스템입니다. 많은 Opensource 프로젝트가 Git를 통해서 개발하고 있고 이들 Opensource를 이용하려면 Git를 쓰는 것이 매우 유용합니다. 회사나 프로젝트의 성격에 따라서 무엇을 쓸지 정해야 하지만 Git도 중요한 고려 사항 중 하나임은 틀림없습니다.

    문제는 무슨 툴을 쓰느냐가 아니고 어떻게 사용하냐 입니다. 뭘써도 제대로 써야 하는데 제대로 쓰는 회사는 5%도 안됩니다. 잘 쓰는 것이 중요합니다.

  24. 2011년/12년/13년에 걸쳐 국내 모바일 3사 중 한곳을 Plastic SCM 이라고 하는 상용 분산 VCS 시스템을 구축 및 지원 하고 있는데요. Git / Perforce / CC 의 장점이 혼재 되어 있는 도구 입니다. 15명 까지는 무료이고 국내 개발자 커뮤니티에게 무상 라이선스도 있으니 한번 자료를 보시는 것도 괜찮을 듯 합니다.
    개인적으로는 단순히 분산 리파지토리를 벗어나서 보다 진 일보된 협업 환경에서의 SCM Activity 가 늘어날 것으로 보고 있습니다. 아울러 리파지토리의 형태도 NoSQL 이나 Hadoop 혹은 Object DB 등으로 진화 해야만 Andorid 기반의 Local 빌드/릴리즈 환경을 가지고 갈 수 있습니다 대부분의 회사에서는 Git 에서 받아서 자체 SCM 창고에 가지고 갑니다.

  25. 와 제가 생각하는것과 비슷하네요.
    git와 svn를 써본봐로는 기본 기능만 쓰고 소규모에서는 svn이 속편하더군요.

  26. Git(정확히 말하면 GitHub)를 조금 사용해 본 결과 너무나 난해합니다. 좋은 점은 저장소가 로컬로 분산되어 있어서 개발이 빠르다는 점, Git과 Hub가 만나서 SNS 적인 통계를 제공한다는 점, 장점인지 단점인지는 모르겠으나, 모든 개발을 branch로 따고 재빠르게 작업해서 다시 merge한다는 점(이 방법은 분산 저장소 개념에 맞는 개발 방법이더군요. 공식 홈페이지에서 추천하는...)
    사실 저에게 가장 어려운 점은 저장소가 분산되고 머지되는 형태로 인해서 반드시 필요해지는 "전략"입니다. 네명이 단일 프로젝트를 관리한다고 했을 때 어떻게 branch하고 merge하는지, 분명히 정하고 넘어가야 합니다. 이게 어려워요 -_-; 사용법만 익힌다고 해결되는게 아닙니다.
    반면 SVN은 상당히 직관적이어서 commit할 때 어떻게 묶고, 이슈번호과 어떻게 연결시키느냐 정도만 정하면 무리없이 진행이 가능하고요.
    일단 git 사용은 일시중지 상태입니다. 물론 다른 프로젝트에 파생되고, 혼자 개발하는 것이라면 당연히 GitHub의 손을 들어주겠습니다. ^^

  27. 전적으로 동의합니다. 이런 상황은 흔히 벌어집니다.
    특별히 분산 개발환경이 아니라면 SVN으로 거의 커버가 됩니다. Git로도 SVN과 유사하게 쓸수는 있지만 그렇게 하려면 그냥 SVN을 쓰면 되겠죠.
    물론 Git는 훌륭하지만 사용법이 복잡하고 제대로 쓰려면 많은 것이 바뀌어야 합니다. 개발하는 방식도 좀 바뀌어야 합니다.
    현재 상황에 가장 알맞는 툴을 선택해서 사용하시는 것이 좋겠습니다.

  28. 다수의 사람들이 같은 코드를 건드릴 여지가 충분하고 새 피쳐 개발하면서 기존 릴리즈 관리하면서 난리부루스를 치게 되면 항상 SVN 이용할때 따라 오는 게 막판 merge시 tree conflict입니다. 간단하게 해결되는 것도 있겠습니다만... 파일명 바뀌고 위치 바뀌고 몇벙 이래저래 옮겨진 워킹브랜치를 머지하는 날에는 그야말로 지옥문이 열리는 걸 경험하실 수 있을겁니다.

    Git을 쓰는 이유? 물론 로컬 repository가 있어서 내가 새로 브랜치를 따든 커밋을 하든 준비가 되었다고 생각할때까지는 다른 작업자들에게 양향을 미치지 않고 작업할 수 있다는 장점도 있습니다만... 그 모든 것의 정점에 있는 기능은 아무래도 "Git을 사용하면 머지시 tree conflict걱정할 필요는 없다" 라는 게 아닐까요? 이거야말로 궁극적으로 팀이 Git을 사용해야 하는 이유라고 할 수 있겠지요.

    아직까지 SVN을 쓰면서 한번도 tree conflict를 본 적이 없거나 그게 뭔지도 모르겠다고 하시는 분이 계시다면... 뭔가 SVN을 잘못 쓰고 있는게 아닌지 한번쯤 고민해 보는 것도 좋을 것 같습니다.

    Git의 브랜칭 전략이라고 하면 http://nvie.com/posts/a-successful-git-branching-model/ 이걸 한번 보시는 게 좋을 것 같습니다. 아마도 이게 best practice가 아닐까 싶네요.

  29. Git을 사용하면 tree conflict가 발생하지 않는다는 말씀은 이해하기가 힘드네요. 머지할 때 충돌이 나는 것이 툴로 해결될 것 같지가 않는데... 혹시 경험이 있으시다면 이 부분 설명 부탁드려요.

    그리고, 현대 개발이라는 것이 이슈트래킹과 연동을 해야하는 이슈가 있는데요 Git이 이런 운영쪽과 협업에 걸림돌이 되지는 않나요?

    베스트케이스로 보내주신 블로그는 그야말로 예술적으로 쓰는군요!!!

  30. 좋은 의견 감사합니다. 메아리바람님의 질문이 있어서 몇가지 덧붙입니다.

    Git는 SVN보다 몇몇 진화된 기능이 포함되어 있습니다. SVN에서는 파일 이름을 바꾸거나 이동을 하면 추적이 안되는데 Git는 추적이 가능합니다. 따라서 Tree conflict가 줄어드는 효과가 있을 수 있습니다. 물론 SVN의 장점도 있습니다. SVN은 여러 프로젝트를 하나의 Repository에 관리하면서 공통모듈을 관리하고 부분적인 Branch를 효과적으로 사용할 수 있습니다. SVN 개발자 브랜치를 이용하면 독자적으로 개발을 해서 merge를 할 수는 있습니다.

    근본적으로 SVN을 쓰던, Git을 쓰던 Conflict를 최소화하는 개발 문화가 되어야 합니다. 구현 시작 전에 소스코드 디렉터리 구조를 미리 확정하고 파일이름도 결정해야 합니다. 또한 Public function들고 미리 정해서 컴포넌트간에 독립적으로 개발이 가능하도록 정합니다. 하나의 소스코드 파일은 나혼자만 수정한다는 생각은 버리고 동시에 수정해서 Conflict이 최소화되는 방법으로 코딩을 하는 것이 좋습니다. 여러가지 방법이 있습니다. 그리고 개발자는 프로젝트 도중에 피치못할 상황이 아니라면 파일의 Rename이나 Move는 지양해야 합니다.

    그리고 Git던 SVN이던 Merge 전략은 잘 세워서 사용해야 합니다.

    이런 환경이 아니라면 Conflict 외에도 여러가지 문제가 발생합니다. Git에서는 이런 문제를 일부 해결했습니다. Git이던 SVN이던 회사의 환경에 맞게 선택을 하는 것이 좋을 것 같습니다.

    그리고 둘다 이슈트레킹시스템과는 연동이 잘 됩니다. ^^

  31. Blog Icon
    g

    물론 Assembly를 가지고 하던 것은 C++로 거의 다 된다.
    또한 Assembly에서 안되는 것도 C++에서 되는 것도 많다.

    그러면 C++이 Assembly보다 좋은 것인가?

    Assembly에서 제공하지 않지만 C++에서 제공하는 기능이 꼭 필요한 경우라면 C++를 사용할 수도 있다.
    - C++, C로 짜여진 수많은 라이브러리를 사용해야 할 때
    - 템플릿과 constexpr를 활용한 메타프로그래밍을 할 때
    - 다형성, 상속, 캡슐화 등을 빨리빨리 구현해야 할 때
    - RAII를 활용해야 할 때

    이런 경우가 아니라면 Assembly를 쓰는 것도 좋다. Assembly가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 Assembly의 막강한 제어능력을 극히 일부만 활용하고 있어서 그럴 수 있다.

  32. Blog Icon
    h

    git과 svn을 asm과 C++로 연결하셨는데요, 둘이 고수준과 저수준의 차이가 나나요. 둘은 목표가 다르고 그 정도의 수준 차이도 나지 않습니다.

    논점을 제대로 집어내지 못한 오도는 쉽게 당신의 논점이 정당하다는 느낌을 주게 할 수는 있을지라도, 그 서술이 옳은 것이란 걸 증명해주진 못합니다.
    이런 게 바로 '허수아비 공격의 오류'죠. 쉬운 주장을 때리시느라 즐거우시긴 하셨겠지만 이제는 현실을 볼 때입니다.

  33. Blog Icon
    운영까지 고려하면

    동시 다발적으로 패치팀이 꾸려지고 각 팀에 대한 브렌치와 머지를 통해 프로덕트 버저닝이 필수인 운영환경에서는 git이 svn보다 이점이 많습니다.

  34. Blog Icon
    기다리는

    Git 기반의 Open source를 이용한 개발을 해야 할 때
    Git 기반의 Open source 프로젝트에 참여할 때
    이거 아니면 깃 쓸 이유 전혀 전혀 전혀 전혀 없습니다

    솔직히 유행 따라 쓰는거지

    svn이 얼마나 좋은 툴인데 svn기능은 다 알고 그러시는건지??


이 소스는 건들지마

2011.10.09 16:07 by 전규현


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





소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.

  • 이 소스코드는 건들지만 이번주 금요일에 릴리즈할 건데 지금 테스트 중이라서 건들면 헷갈리니까 잠시 건들지 말아줘
  • 소스코드를 수정해서 등록하는데 Conflict가 났다. 원래 수정자를 찾아 같이 모여서 소스코드를 머지했다.
  • 같은 소스코드를 서로 같이 동시에 수정하면 문제가 많으니 각 모듈마다 담당자를 따로 정해서 소스코드가 충돌하는 경우를 원천 봉쇄했다. 그래서 서로 다른 사람들의 소스코드를 잘 모른다.
  • 하나의 소스코드를 가지고 오늘은 내가 내일은 다른 사람이 수정할 수 있도록 서로 일정을 조정했다.
  • v1.0 출시 후 v1.0 유지보수와 v1.5로 업그레이드 하는 프로젝트가 동시에 진행하는데 서로 소스코드가 섞여서 소스코드 관리를 잘해야 한다.
  • 위 경우 소스코드 충돌 때문에 소스코드 브랜치를 만들어서 따로 6개월간 개발을 했는데 나중에 v1.0의 수정본을 v1.5에 합치는데 워낙 많이 바뀌어서 거의 한달이나 걸렸다. 그 한달동안에 v1.0 소스코드는 또 많이 바뀌어서 Merge하고 테스트하는데 시간이 또 많이 걸렸다. 

위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.

기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다. 

그것은 바로 "Baseline"과 "3-way merge"이다.
이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.

  • 언제 릴리즈하는지는 상관없이 언제든지 소스코드를 수정할 수 있다. 
  • 소스코드 Conflict가 일어나도 원래 수정자가 없이도 쉽게 Merge할 수 있다.
  • 소스코드에서 여러 컴포넌트를 개발했던 원래 개발자는 있지만 서로 상대방의 컴포넌트를 수정할 수 있고 동시에 수정을 해서 충돌이 가끔 일어나지만 문제 없이 Merge가 된다.
  • 소스코드를 누가 언제 수정하는지 전혀 신경 쓰지 않고 서로 동시에 수정을 할 수 있다.
  • 유지보수 프로젝트와 업그레이드 프로젝트가 동시에 진행을 해도 Merge는 불과 몇시간이 걸리지 않고 대부분 자동으로 해결된다.

Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.

아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.

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

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

  1. Blog Icon
    자바지기

    좋은 글 잘 읽었습니다. 버전 관리 시스템 기능을 최대한 활용해 문제를 해결할 수 있다는 것에 일정 부분 공감하지만 버전 관리 시스템 사용만으로는 한계가 있다고 생각합니다.

    브랜치가 생성되는 순간 이를 테스트할 수 있는 개발 환경을 쉽게 구축할 수 있는 환경이 되어야 하고, 소스 코드 머지가 subverion은 다소 문제가 되는 부분이 있어 다른 형태의 버전 관리 시스템을 사용해 보는 것도 고려해볼 필요가 있다고 생각합니다.

    그러나 다른 무엇보다 각 기능들을 어떻게 관리하느냐가 가장 중요하지 않나 생각합니다. 기능들을 잘게 나누어서 우선순위를 선정해 개발하는 방식이 갖추어져 있어야 이 모든 과정이 가능할 겁니다. 이 부분을 모두 갖춘 상태에서도 브랜치를 나누고 소스 코드를 잘 관리하는 방법은 상당히 어려운 작업이라고 생각합니다. 한, 두 달의 시간이 아닌 1,2년의 시간을 투자했을 때 진정 우리가 원하는 형태의 소스 코드 관리가 가능해지지 않을까 하는 생각이 드네요.

  2. 안녕하세요. 자비지기님
    SVN은 Merge에 있어서 정말 강한 툴이지요. ^^
    하지만 제대로 쓰려면 그 컨셉을 정말 잘 알아야 합니다.

    형상관리도 중요하고 스펙의 범위 관리도 중요하지요. 뭐하나 소홀히 얘기하기는 어렵겠네요.

  3. Git이 SVN보다는 몇가지 나은 점이 있고, 또한 3-way merge를 해서 아무런 문제 없이 머지가 되었다고 해도 그건 단지 텍스트상의 머지이기 때문에 실제로 '언제든지 소스코드를 수정할 수 있다' 가 만족되려면 상당한 수준의 테스트 케이스가 준비되어야 하고 또한 QA들의 도움이 필요한게 사실이지요.

    또한 이미 릴리즈된 버전에 픽스된 라이브 버그 픽스들을 적절히 트렁크로 가져와서 머지하는 것도 중요합니다. 안 그러면 매 버전마다 개발자들이 regression bug때문에 생고생을 하는 경우도 종종 -_-;;

  4. 안녕하세요. 우울한딱따구리님
    Git을 쓰려면 조금더 역량이 필요한 것은 사실이지요. ^^
    언제한번 SVN과 Git를 비교해보도록 하겠습니다.

소스코드 Conflict

2011.02.18 22:16 by 전규현


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






소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.
하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.

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

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

전규현 기반시스템/소스코드관리 Conflict

  1. 음.. 위와 같은 충돌은
    소스코드 법칙을 세우고 서로 맞추는게 오히려 더 맞지 않을까 생각이 됩니다.

    탭간격이라던가 괄호의 규칙 이런걸 정하면 이런 소모적인 충돌은 줄어들테니 말이죠.
    그리고 추가적으로 자주 커밋하고 받으면 이런 문제가 발생할 소지가 줄어 들겠죠 ㅎ

  2. 구차니님 안녕하세요.
    코딩 컨벤션을 지키는 것은 아주 기본적이고 당연한 것이고 위 내용은 그보다 한단계 높은 수준의 습관입니다. ^^

  3. 자주 소스코드를 update하는 습관이 일단 중요한 것 같아요.
    그리고 이유 없이(없다기 보단 그냥 미관상이겠죠..) 소스코드의 줄을 맞추거나 라인을 이동하는거 정말 공감합니다..;;ㅎ

  4. 안녕하세요. 피스티스님
    맞습니다. 팀의 규모가 매우 커지고 프로젝트가 복잡해지면 update를 하는데도 나름 계획이 필요합니다. 파일이 너무 자주 바뀌기 때문에 적절한 시점에 update를 하지 않으면 상당히 복잡해집니다.

  5. Blog Icon
    줄맞추기

    좋은 글 잘 보고 있습니다.

    개발하는 시간보다 소스코드의 줄맞추는데 시간을 더 많이 소비하는 경향이 있는 일인입니다.
    줄이 안 맞는 코드는 가독성이 많이 떨어지던데..
    이런 경우는 제가 문제가 있는 건가요?

소스코드관리시스템 사용도 2차 조사 결과

2010.12.03 13:26 by 전규현


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





2009년 2월에 이와 동일한 조사를 한 적이 있었습니다.
2009/02/22 - [기반시스템/소스코드관리] - 소스코드 관리 방법 조사 결과

그때도 약 20일간 조사를 했었고, 이번에도 마찬가지로 20일간 조사를 했습니다. 
2009년에는 109명이 참여를 했는데 이번에는 370명이 넘는 인원이 참여를 해서 더 정확한 결과가 나왔을 것으로 기대합니다.


이번 설문의 핵심은 소스코드관리시스템을 사용하는지? 사용하지 않는지? 또, 사용한다면 어떤 시스템을 사용하고 있는지를 알아내는 것이었습니다.

2009년초와 비교를 해보면 꽤 많은 변화가 있었음을 알 수 있습니다.
가장 큰 변화를 요약하면 다음과 같습니다.
  • 소스코드관리시스템 사용률의 향상
  • CVS, VSS의 몰락
  • Git의 약진
  • Subversion(SVN)의 꾸준한 증가
그럼 조사 결과를 살펴 보도록 하겠습니다.

소스코드관리시스템을 사용하고 있는 그룹에서만 통계를 내보면 여전히 Subversion이 압도적인 1위를 차지하고 있고, CVS와 VSS의 사용률이 많이 떨어지면서 Git가 크게 치고 나온 것을 알 수 있습니다. Mercurial의 가세까지 보면 분산소스코드관리시스템에 대한 관심이 많이 높아졌음을 알 수 있습니다.
또한 더 다양한 소스코드관리시스템의 사용을 시도해보고 있는 것이 눈에 띕니다.


소스코드관리시스템을 사용하는 비율도 많이 높아졌습니다. 그동안 책이나 블로그를 통해서 소스코드관리시스템을 사용하지 않고 소프트웨어를 개발하는 것은 기적에 가깝다고 하였는데, 이는 긍정적인 신호로 생각됩니다.
물론 소스코드관리시스템을 사용하고 있는 83%에서도 제대로 사용하고 있는 비율은 극히 낮습니다. 그래도 사용하기 시작한 것만 해도 큰 의미라고 생각됩니다.


많은 발전이 있었음에도 여전히 소스코드관리시스템을 사용하지 않는 개발자나 회사가 많이 있고 그 속에서의 비율은 큰 차이가 없어 보입니다.
소스코드관리시스템을 100%의 개발자들이 사용하고, 또한 제대로 사용할 수 있는 날까지 계속 노력을 합시다. 


저는 수많은 회사에서 소프트웨어 공학/경영 컨설팅을 진행하면서 소스코드관리시스템이 개발 문화를 긍정적으로 상당히 많이 바꾸는 것을 보아 왔습니다. 소스코드관리시스템 없이 소프트웨어를 개발한다는 것은 남들은 총들고 전쟁할 때 돌멩이 들고 싸우겠다는 것과 같습니다. 일단 무기가 있어야 싸움을 시작할 수 있을 것 아닙니까?
그리고 나서야 기술이나 전략이 의미가 있어집니다. 돌멩이 들고 싸우면서 전략을 논할 수는 없습니다.
물론 이와 같이 꼭 필요한 무기들은 몇가지 있습니다. 이런한 것들이 기본은 되어야 글로벌 소프트웨어 회사들과 경쟁이란 것을 생각해 볼 수 있습니다. 그렇다고 물론 경쟁이 된다는 것이 아닙니다. 이제 시작할 수 있다는 것 뿐입니다. 

그리고 나면 진짜 개발 실력, 전략, 마케팅이 필요한 때입니다. 하지만 국내 대부분의 소프트웨어 회사들은 아직 글로벌 경쟁은 생각하지도 못할 수준인데 단순히 요소기술만 가지고 경쟁을 할 수 있다고 착각하는 경우가 많습니다.

이번 조사 결과를 보면서 점점 긍정적인 신호들을 느낍니다. 앞으로 좀 더 깊은 내용들도 풀어 나가도 될 것 같습니다.

조사에 협조해주신 모든 분들께 감사드립니다.

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

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

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

  1. 전규현님 덕분에 개발에있어 다른 시각으로 접근하는 시야를 갖게되었습니다 감사합니다.
    svn사용이익숙해지면 Git도 한번 사용해봐야겠네요

  2. 오산돌구님 안녕하세요.
    그렇게 생각해주시니 고맙습니다. 개발자분들이 좀더 좋은 환경에서 일하게 되는 것이 제 바람입니다.

  3. 안녕하세요. rss추가 해놓고 맨날 눈팅 하던중 주옥 같은 글을 발견 하였네요.

    감사합니다. ^^

  4. 안녕하세요. 이승철님
    반갑습니다.

  5. 음.. 문득 다른분들은 svn 서버를 어떻게 구성해서 사용하는지가 궁금해지네요
    http / https / svn / svn+ssh 이런 여러가지 설정방법이 있다 보니 말이죠 ^^;

  6. 안녕하세요. 구차니님
    SVN 서버를 구성하는 방법은 간단하기도 하지만, 제대로 하려면 매우 복잡합니다.

    1. 말씀하신 것과 같이 Protocol을 정해야 합니다.
    2. Repository를 어떻게 나눌 것인지 정해야 합니다.
    3. Repository 내의 디렉터리를 어떻게 구축해야 하는지 정해야 합니다.
    4. 각 Repository내의 디렉터리에서 권한을 어떻게 부여해야 할지 정해야 합니다.

    이 중에서 가장 어려운 것이 2,3번입니다. 특히 3번은 잘못 구축하는 경우가 태반이고, 한번 잘못 구축하면 다시 복구하는 것은 대단히 어렵습니다.
    디렉터리의 구조는 빌드 스크립트와 연관이 있어서 다시 고치는데는 대단히 노력과 비용이 듭니다.
    디렉터리 구조는 회사마다 다르며 잘못 구축하면 비효율성이 계속되며 비용을 지불해야 합니다.
    제대로 디렉터리를 구축하려면 SVN의 사용방법도 제대로 알아야 하고 회사의 미래 개발 전략도 어느정도 이해를 해야 가능합니다.

    이중에서 1번인 프로토콜은 꽤 쉬운 편입니다. 왜냐하면 나중에 요구사항이 바뀌면 바꾸기가 쉽기 때문입니다.
    SVN은 기본적으로 자체서버에서 svn://을 지원합니다. 그리고 웹서버와 연동해서 http:// https://를 지원합니다.
    그리고 ssh에 svn을 얹어서 쓸 수도 있습니다.

    웹브라우저로 보기도 원하는지? 철저한 보안을 원하는지? 편리하고 간단하게 쓰고 싶은지? 속도가 매우 중요한지?에 따라서 정하면 됩니다.

  7. Blog Icon
    csj

    저도 개인 피씨에 보관하던 사람이었죠 ㅎㅎ
    블로그 글 덕분에 버전 시스템을 알게 되었고, 설치하여 프로젝트에 많은 도움이 되고 있습니다.

    하지만, 스포츠에 비유한다면, 이제 겨우 기초 체력을 갖추기 시작한 거라 해야 할까요
    진짜 경쟁은 지금부터겠죠
    여하튼 앞으로도 좋은 글 많이 부탁 드립니다.

  8. 안녕하세요. csj님
    맞습니다. 기본적인 시스템을 갖추지 않고 개발을 하는 것은 사냥을 맨몸으로 하는 것과 같습니다. 창이나 활, 총을 갖춰야죠.
    이제 무기는 생겼습니다. 무기를 갖추는 것은 시간이 얼마 안걸립니다. 하지만 무기를 잘 쓰는데는 시간이 좀 걸립니다.
    또한 사냥을 더 잘하려면 무기를 잘 쓰는 방법 뿐만 아니라 자연을 이해야 하고 동물의 습성등 다른 기술들도 필요하고 팀웍도 필요합니다.

    이제 기초를 갖추신 겁니다. 비록 요소기술이 뛰어나다고 해도 소프트웨어 공학에서 다루는 프로세스, 툴, 분석, 리뷰, 설계 등의 실력을 갖추지 않으면 소프트웨어를 개발하기가 점점 어려워 집니다.

    앞으로 좋은 정보를 많이 공유하도록 하죠.

  9. 전규현님 안녕하세요. 이번주에 git에 대해서 팀내 발표를 하게 되었습니다.
    제가 어떻게 하는지에 따라서 팀내 적용을 할지 말지 정하는 상황입니다.
    현재 팀내 분위기는 git을 사용하기 위해 배우는 비용과 git 사용함으로써 생기는 이득을 따져서 적용해보자~ 하는분위기입니다.

    근데 한가지 문제점은 제가 git이나 svn을 사용하는데 저 혼자만 사용해서 여럿이 사용할때의 이점을 제대로 깨닫지 못한 상태입니다. 그저이론적으로만 알고있죠. . .

    사용하면서 어떤 예로 이득을 보는지 알고싶습니다. 아직 처음 단계라 경험이 부족해이런 질문 드린거 죄송합니다;;

  10. 오산돌구님 안녕하세요.
    제가 쓴 "소프트웨어 개발의 모든 것"의 개정판에 중앙집중식SCM과 분산SCM의 비교가 있으니 참조하시면 좋을 것 같습니다.
    특별히 분산 관리의 목적이 아니라면 SVN이 더 관리하기 편합니다.
    서로 연동도 되니 필요에 따라서 연동해서 사용하는 방법도 있습니다.

2차 소스코드관리시스템 사용도 조사 Poll

2010.11.14 17:05 by 전규현


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







약 2년전쯤 제 블로그에서 어떤 소스코드관리시스템을 사용하고 있는지 조사를 한 적이 있습니다. 

시간도 꽤 흘러서 그동안 어떤한 변화가 있었는지 알고 싶어집니다. 특히 그동안 소스코드관리시스템을 사용하는 비율이 어느정도 높아졌는지가 가장 궁금하더군요. 또한 최근에 분산소스코드관리시스템에 대한 관심의 증가가 실제로 사용도에 영향을 주는지도 궁금합니다.

설문은 간단하게 사용하시는 소스코드관리시스템을 체크하면 됩니다. 만약에 보기에 없다면 Other 항목에 직접 적어 넣으시면 됩니다.

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

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

  1. Blog Icon
    csj

    오 서브버전이 인기가 좋군요~

    확실히 구축해 두니 편하내요 ㅎㅎ

  2. 그렇군요.
    지금까지도 최고의 SCM으로 생각됩니다.

  3. 프로젝트를 진행하다가 문서화에 대해 검색을하다가 블로그를 오게되었습니다.
    전에 말씀해주신 조언들 항상 간직하며 개발하려고 노력하고있습니다.
    날씨가 많이 쌀쌀해졌네요. 감기조심하세요~

  4. 오산돌구님 반갑습니다.
    오산돌구님도 건강하세요.

  5. 으헝헝 저 중에서 사용해본건 2개뿐이고(cvs/svn) 들어보지도 못한게 절반이라니
    전 무능력한 개발자인가봐요 ㅠ.ㅠ

  6. 구차니님 안녕하세요.
    ㅎㅎ 하나만 제대로 써도 충분합니다. 기본 원리는 다 같거든요.
    여러개를 써봤어어도 엉터리로 써보는 것이 더 문제죠.

  7. 조사하다보면 신기한게, 아직까지 SCM을 안쓰는 곳도 꽤 많다라는 겁니다.

    특히, 전문 소프트웨어 개발쪽이 아닌 중소기업과 정부기관 쪽은 이런식으로

    SCM을 쓰기보다는 그냥 개인 백업을 우선시 하더군요.

    몇년치 CD로 보관하시는 분들도 쿨럭...

  8. 2년전과 비교하여 통계를 다시 내보려고 합니다.

  9. Blog Icon
    안효봉

    저희도 SubVersion을 사용합니다.

    저희는 외부업체가 개발을 하는경우도 있고 내부에서도 자체개발을 하는 경우가 있는데

    소스관리가 안되어 있던차에 SubVersion을 알게되어 구축해볼겸 해서 테스트서버에 구축을 해두었습니다.

    아직까지 정책적으로 잡혀있는 것은 아니라서 내부에서 소스 백업용도 정도로만 사용하고 있는데

    시간내서 브랜치나 머지등의 기능등의 기능을 익힐 정도 되면 정책적으로 사용하게 할 계획은 있습니다.

    다만 제가 기능을 익히고 해야 되는데 개발에 밀려서 시간이....

    SubVersion을 사용하긴 하지만 제대로 사용하는 것은 아니네요

  10. Subversion을 제대로 쓰는 것만 해도 보통일이 아닙니다.
    브랜치와 머지가 책에 나온 것을 읽기만 해서는 익히는 것이 거의 불가능 할 정도입니다.
    제가 쓴 책과 블로그에 가이드가 나오니 참고하세요.

  11. 소스 컨트롤을 제대로 사용하느냐가 문제라면 할 말이 없습니다만, 소스 컨트롤을 제대로 사용하고 계신 분들, 그 중에서도 svn 과 같이 오래된 소스컨트롤 시스템을 사용하시는 분들에게 mercurial 과 같은 분산 소스 컨트롤을 접해 보시길 추천해 봅니다. (svn 의 투표율이 높은 것은 대부분 보다 효과적인 도구를 찾는데 수동적이시기 때문이라고 생각합니다.)

    참고: bitbucket.org 에 가시면 무료 호스팅(private 프로젝트도 가능!) 가능합니다. tortoise svn 쓰셨다면 tortoise hg 를 사용해 보세요. 이미 대부분의 오픈소스 프로젝트가 svn 에서 mercurial 로 이동중입니다.

  12. Google Code(Hosting Service)에서도 SVN과 더불어 Mercurial을 기본으로 제공하고 있죠. 최근 분산 소스코드관리에 대한 관심이 많이 높아졌습니다. 모두 훌륭한 툴임에는 의심이 없습니다.
    조만간에 중앙집중식 소스코드관리시스템과 분산 소스코드관리시스템을 비교하는 글을 올려보도록 하겠습니다. :)

마이크로소프트, 구글의 소스코드 트리의 비밀?

2010.06.08 11:02 by 전규현


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






오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요.

책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다.

질문은 다음과 같습니다.
나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다. 그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다.

사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이해하고 경험이 있다면 질문에 해당하는 내용이 책에 포함 되어 있다는 것을 알 수 있을 겁니다. 

결론부터 먼저 말씀드리자면 최종 결과물인 "소스코드 트리"만 보면 배우기 어렵다는 겁니다. 잘 작성된 SRS를 몇개 보고 SRS를 제대로 작성하는 법을 배우기 어려운 것과 비슷합니다. 따라서 소스코드 트리를 보는 것이 큰 도움이 안된다는 것을 말씀드립니다. 하나의 사례를 보는 것에 족할 겁니다. 자칫 그 방법이 가장 좋은 방법인 줄로 착각을 하게 되면 시각이 굳어져서 손해를 볼 수도 있습니다.

좀더 쉽게 설명하면 타이거우즈(요즘 조금 부진하지만)가 골프치는 모습을 보고 골프를 배우기는 어렵고, 김연아가 스케이트 타는 것을 보고 따라하기 어렵다는 겁니다. 어떻게 해서 이러한 결과물이 나오는지 그 과정과 훈련 방법을 알아야 하겠지요. 

그런 과정에 관련된 내용이 책에서 상당히 많이 언급하려고 노력했습니다.

그 과정이라는 것도 각자의 수준에 따라서 보이는 것이 다릅니다. 수준을 1~10정도로 정의할 때 수준이 '1'인 사람은 아무리 설명해도 '2'나 '3'의 내용만 이해가 가능합니다. 수준이 '5'인 사람은 '6'이나 '7'정도가 이해할 수 있습니다. 그래서 올바른 방법으로 꾸준히 차근차근 훈련(경험)을 해 나가야 성장합니다. 

그외의 끝내주는 방법은 없습니다.

위 질문의 요지를 보면 다음과 같습니다.
  1. 모듈을 어떤식으로 분리하는지?
  2. 소스트리를 어떻게 구성하는지?
  3. 중복되는 소스코드를 어떻게 제거하는지?
  4. 공통모듈은 어떻게 공유하는지?
  5. 코멘트는 어떤 규칙으로 작성하는지?
결론부터 말씀드리면 다음과 같습니다.

 구체적인 방법은 회사마다 다르지만 원리는 똑같다.

이것을 모두 이해하려면 1~10 정도의 수준에서 '7'~'8' 이상은 되어서 합니다. 그렇지 않고 아직 소스코드관리시스템의 일부기능만 간신히 쓰고 있고 SRS도 아직 제대로 작성하지 않고 있고 리뷰도 하지 않고 있다면 수천명의 개발자들이 어떻게 뒤죽박죽 되지 않고 소프트웨어를 개발할 수 있는지 이해가 가지 않을 겁니다.

그게 소프트웨어 공학입니다. 어떠한 상황에서도 가장 짧은 시간에 적은 비용으로 소프트웨어를 개발하기 위한 실전적인 방법으로 진화를 해온 것입니다.

조금더 구체적으로 들어가보도록 하겠습니다. 모든 사람들이 이해를 하고 동의할 것으로 생각하지 않습니다. 왜냐하면 각자의 경험과 수준이 있기 때문에 보이는 것이 다르기 때문입니다. 

1. 모듈은 어떤 식으로 분리를 하는지?
천차만별이지만 원리는 있습니다. 책에서도 원리에 대해서 설명하기 위해서 노력을 했습니다. 
책이 있으니 한번 더 보시면 되겠지만 한번더 설명을 하면 "컴포넌트"와 "인터페이스"를 어떻게 나누느냐가 핵심인데, 어떤 툴이나 방법을 쓰냐는 중요하지 않습니다. 생각하는 방법도 서로 다르지만 대체로 설계단계에서 개발자들끼리 서로 모여서 종이나 칠판에 "컴포넌트"와 "인터페이스"를 그려가며 가장 깨끗하게 나오는 구조를 그려갑니다. 문제가 있으면 다시 지우고 그리고를 여러번 반복합니다.
이때 SRS가 없다면 모든 기능을 다 고려할 수 없기 때문에 제대로 아키텍쳐를 작성할 수 없습니다. SRS가 그냥 있기만 한다고 되는 것도 아니고 제대로 작성이 되어야죠. 아키텍쳐에는 회사의 미래전략도 모두 포함되기 때문에 단순히 기능만 다 있다고 되는 것도 아닙니다. SRS이슈로 넘어가면 또 하루 종일 설명을 해야 합니다.
아키텍쳐에 많은 영향을 미치는 사람들은 주로 선임 개발자들이고 개발팀 규모가 엄청나게 크면 한사람이 전체 모든 컴포넌트와 인터페이스를 분리할 수 없기 때문에 수직적으로 나뉘게 됩니다. 개발자들은 서로 여러 설계 리뷰에 참석을 하게 되고 리뷰자들은 서로 중첩이 됩니다. 선임개발자들은 최상위 아키텍쳐 리뷰에 참석도 하고 자신이 맡은 컴포넌트의 아키텍쳐 회의를 주도하고 여기에는 하위 개발자들도 참석을 합니다.
아키텍쳐 리뷰도 실제로 여러번 해보지 않으면 책을 아무리 봐도 어떻게 진행하는지 알기 어렵습니다.

2. 소스트리를 어떻게 구성하는지?
이 부분이야 말로 회사마다 천차만별입니다. 회사마다 제품의 특성이 다르고 프로세스가 다르기 때문에 같을 수가 없습니다. 소스트리를 구성할 때 고려해야 할 것들은 정말로 많고, 그 회사의 경험이 많은 고참 개발자가 아니면 좋은 결정을 할 수가 없습니다. 
소스트리는 한번 제대로 구성을 해놓으면 10년이상 지속될 수 있는 것이기 때문에 상당히 신중해야 합니다.
제품의 성격, 각 제품간의 관계, 사용하는 개발언어, 공통모듈 현황, 미래의 개발계획, 빌드 프로세스, 테스트 프로세스 등이 모두 고려되어야 합니다.
일반적으로 한번에 제대로된 소스트리를 만드는 것은 거의 불가능에 가깝습니다. 대부분은 몇년 해보다가 뒤엎는 경우를 수차례 반복합니다. 
그렇다고 Google이나 Microsoft의 소스트리를 흉내낸다고 제대로 되지는 않습니다. 아마 100% 실패할 것입니다.

3. 중복되는 소스코드를 어떻게 제거하는지?
완벽한 제거란 있을 수 없습니다. 최소화 하는 것이지요. 이것을 이해하려면 SRS, Architecture Design, Peer Review를 모두 잘 이해하고 있어야 하는데 쉽지 않습니다.
우리나라와 같이 각 개발자들이 모두 슈퍼맨에 되어서 알아서 개발하는 구조에서는 해결이 불가능한 이슈입니다.
책에서도 꽤 설명을 하고 있지만 다시 설명을 해보겠습니다. Peer Review를 한다고 가정을 하고 SRS, Architecture, Source Code 모두를 Review한다고 가정을 해보죠. 일단 Review를 충분히 한다는 것이 중요합니다. 개발자들은 이미 상당히 많은 내용을 서로 공유하고 있습니다. 보통 개발하는 시간의 20%는 Review를 위해 사용한다고 합니다. 그리고 고참이 될 수록 더 많은 시간을 Review에 할애 합니다. 
대부분은 개발할 시간도 없는데 언제 Review를 할 시간이 있냐고 합니다. 또한 "SRS는 언제 쓰고 있느냐, 빨리 개발해야지"라고 주장합니다. 그러면 "SRS쓰고 Review할 시간은 없어도, 개발하고 고치고, 개발하고 또 고치고 할 시간은 있느냐?"라고 반문을 하죠.
Review를 적절하게 하는 것이 개발을 가장 빨리 하는 방법이기 때문에 소프트웨어공학에서 주장하는 것이지요.
이런 리뷰를 거친 설계과정에서 중복되는 모듈은 컴포넌트로 빠지고 코딩과정에서도 서로 중첩된 리뷰를 하기 때문에 중복된 코드가 발생할 가능성도 적어지고 있다고 하더라도 쉽게 발견되고 공통 모듈화 할 수 있습니다.

4.공통모듈은 어떻게 공유하는지?
이또한 회사마다 다릅니다. 하지만 공통모듈이 없는 회사를 본적이 있습니다. 아니 많습니다. 각 개발자들이 다 알아서 개발을 하고 있어서 어디에 중복된 모듈이 있는지 알지도 못합니다.
공통모듈은 분석, 설계 과정을 통해서 잘 분리가 되어야 하고 당연히 이를 담당한 개발자나 개발팀이 별도로 존재합니다. 공통모듈이 이를 사용하는 개발자나 개발팀에서 잘 사용할 수 있도록 적절한 프로세스를 갖추고 있어야 합니다. 공통모듈은 소스코드 수준에서 공유하는 회사도 있고, Static library 또는 Dynamic library형태로 공유하기도 합니다. 그에 따른 적절한 공통모듈 Release프로세스를 가지고 있어야 하며 절적한 스케쥴도 유지를 해야 합니다.
회사의 공통모듈은 한개가 아닙니다. 수십개, 수백개가 될 수도 있습니다.
컴포넌트간의 공통모듈이 있고, 제품간의 공통모듈이 있고, 회사 전체 공통모듈이 있을 수 있습니다. 공통모듈은 소스코드가 될 수도 있고, Text파일일 수도 있고, 이미지파일일 수도 있습니다.
이런 공톰모듈을 적절하게 잘 사용할 수 있는 소스트리 구성이 중요합니다. 따라서 최고의 고참이 아니면 소스트리 구성이 어렵습니다.

5.코멘트는 어떤 규칙으로 작성하는지?
이부분도 회사마다 다르지만 규칙은 있다는 겁니다. 
아무것도 제대로 갖춰지지 않은 회사에서 코멘트는 정말 중요합니다. 달랑 소스코드 하나 있는 것이기 때문에 코멘트가 없으면 소스코드를 파악하기 정말 어렵습니다. 특히 해당 개발자가 퇴사를 하고나면 정말로 난감합니다.
하지만 제대로 된 소프트웨어 회사에서는 모든 것이 서로 얽혀 있고 정보들이 서로 중첩되어 있어서 코멘트만이 유일한 정보는 아닙니다. 모든 소스코드의 History는 소스코드관리시스템에 등록이 되어 있어서 Blame을 해보면 누가 언제 등록을 한 소스코드이고 해당하는 Message와 관련된 Issue의 번호를 가져올 수 잇습니다. 그리고 왠만한 소스코드는 서로 중복되어서 리뷰가 되었고, 소스코드관리시스템에 누가 리뷰를 했는지 기록이 되어 있습니다. 
즉, SRS - Architecture - SCCM - Issue Track - Source Code - Brain(뇌, 리뷰) 들이 서로 관련이 있고 얽혀 있어서 코멘트에 목숨거는 상황은 아니게 됩니다.
그래도 코멘트는 작성을 하고 규칙은 각 회사마다 별도로 가지고 있어야 합니다. 
우리나라 같은 경우 영어로 작성을 해야 하는지 한글로 작성을 해야 하는지 정해야 하고, 파일주석, 함수주석, 라인 주석에 대한 규칙을 정해야 하고, 내용, 형식에 대해서도 정의를 해야 합니다.
하지만 너무 복잡한 규칙과 지키기 어려운 엄격한 규칙은 없느니만 못하기 때문에 적절히 규칙을 정해야 합니다.

 결론 
 
위의 모든 것을 한꺼번에 할 수는 없습니다. 회사의 규모에 따라서 3~5년 이상 걸릴 것들도 있습니다. 결코 계단 10개를 한걸음에 뛰어오를 수는 없습니다. 용어만 알고 있거나 한번씩 경험해 봤다고 아는 척해서도 안됩니다. 회사 전체가 같이 움직일 수 있어야 합니다. 현실은 많은 의욕이 넘치는 개발자들이 머리속의 지식과 이상은 level 10인데 실제 실력과 경험은 level 2에서 헤매고 있는 겁니다. 그래도 다른 개발자들보다 용어도 많이 알고 말싸움에서 이기고 잘 안되는 것은 다른 사람들 탓을 하곤 합니다. 이것이 제가 여러 현장에서 겪는 현실입니다.
차근 차근 노력해 가는 것이 올바른 방법이고 전문가의 도움을 통해서 제대로 된 길로 가장 빠르게 가는 것이 유일한 방법입니다.

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


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

전규현 기반시스템/소스코드관리 SRS, 소스코드관리시스템, 소스코드트리, 소스트리, 피어리뷰

  1. 주석처리에 대해서 말이 많이 오가는데
    음.. 확실히 소스에 넣으면 코딩시에 지저분 해지는거 같고
    그렇다고 해서 별도의 문서로 하기에는 관리가 쉽지가 않은거 같더라구요.


    오늘도 좋은 글 감사합니다 ^^

  2. 구차니님 안녕하세요.
    누구는 "소스코드를 주석처럼 자세히 작성해라", "주석은 필요없다.", "있다" 말들이 많지만, 어느것도 정답이 아닙니다. 회사에 알맞게 규칙을 스스로 정하면 됩니다. 그리고 따라야지요.

  3. Blog Icon
    galsys

    규칙을 정한데로 따른다라. 그렇군요.

  4. 은총알은 없다이군요.
    그럼에도 불구하고 계속 은총알을 찾아 해메게 되네요.

    마지막 코멘팅에 대한 질문은 소스코드 코멘트는 아니고 형상관리툴에 체크인할 때 코멘팅 규칙을 여쭤본 것이었습니다. 저는 귀찮아서 코멘트를 종종 빼먹고 체크인하는데, 책에서 이 때의 코멘팅 규칙을 가지고 있어야 한다고 했던 것 같아서요. 혹시 그게 소스코드 코멘트 규칙이었던가요? 집에 가서 책을 다시 뒤져봐야겠어요^^;
    다시 읽어보니 제가 질문을 아주 애매하게 드렸네요.

    좋은 글 잘 읽어보았습니다.
    감사합니다.

  5. 제가 달 곳은 아닌듯 하지만 주제넘게 리플을 달아봅니다.

    개인적으로 doxygen 등의 comment documenting application의 문법대로 생성해주는 것이 가장 무난하지 않을까 생각을 해봅니다. 프로그램 작동원리와 같은 세부 주석은 headrer 파일쪽으로 몰아주는 식으로 말이죠.

    라고는 하지만.. 저도 생각만 해봤지 직접 실행을 안해봐서 잘 모르겠어요 ㅠ.ㅠ

  6. Commit할 때 코멘트는 "Commit message"라고 통일해서 부르면 됩니다. 정확한 용어를 사용하는 것도 자신의 내보이는 중요한 요소가 됩니다. ^^

    Commit Message에서 빠지지 않고 꼭 입력하기를 권장하는 2가지가 있습니다.
    바로 BugID(Issue ID)와 Reviewer입니다.

    BugID가 꼭 포함되는 이유는 버그관리시스템에 등록되지 않은 변경은 없다는 전제하에 작업을 해야 하기 때문에 물론 알파 이전에는 예외이지만, 이후에는 소스코드 한줄을 수정해도 버그관리시스템에 등록을 해야 합니다. 그래서 엑셀에 버그를 관리하는 회사에서는 불가능한 것이지요.

    그리고 누가 리뷰를 했는지 꼭 적게 합니다. 이는 Peer Desk Check을 한다는 전제하에 시행할 수 있습니다. Peer Desk Check은 Commit전에 간단히 동료와 리뷰를 하는 것으로 가장 효과적인 방법중 하나입니다. 이를 도와주는 툴도 있기는 하지만 툴 없이도 할 수 있습니다. Review를 하지 않았으면, None이라고 적고 소스코드를 책임지면 됩니다. 추후 여기서 버그가 나오면 진짜 민망해집니다.

    그리고는 간단한 Message를 포함하면 됩니다. 이미 버그관리시스템에 많은 정보가 있으므로 간단히 적으면 됩니다.

    Commit Message는 절대로 빼먹으면 안됩니다. 버그 등록하지 않고 마음대로 고치면 안됩니다. 이러한 작은 것들이 큰 차이로 나타나게 됩니다.

    나중에는 여기에 관련된 Post로 해야 겠네요.

    감사합니다.

  7. 안녕하세요, '소프트웨어 개발의 모든 것'을 구입하여 읽는 도중에 책에서 언급한 commit시의 로그
    메시지 표준이라는게 어떤식으로 쓰는 것인지 궁금하여 블로그에 들르게 되어 있는데 위 댓글에
    언급이 되어 있는 것 같네요.
    책에서도 좋은 내용 많지만 블로그에서도 많이 얻네요. 좋은 책과 블로그 감사합니다.

  8. 윤연식님 반갑습니다.
    좋은 인연이 되길 바랍니다.

Hotfix에서의 소스코드관리

2010.05.04 11:26 by 전규현


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





아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.









우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.
계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.
Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.
Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 
Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

 Hotfix  정식 Patch
계획되지 않은 긴급한 패치
보통 충분히 테스트 되지 않고 릴리즈
또다른 문제를 일으킬 가능성이 매우 높음
다른 개발일정에 영향을 줌
고객은 수정된 버전을 바로 받아볼 수 있음
미리 계획됨
계획된 테스트를 수행하고 릴리즈
일상적인 수준의 리스크를 가지고 있음
계획된 일정대로 개발이 가능
고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

 Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.
1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?
2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 
1. 그때 그때 다르다.
2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.
Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.
그럼 개발팀 바깥이란 무엇일까요? 
테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.
이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.
Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.
  1. 상세한 버그 내용
  2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
  3. 버그로 인해서 발생하는 고객의 예상 피해
  4. 버그를 얼마나 빨리 해결해야 하는지
  5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
  6. 버그 수정에 투입해야 하는 인력 및 자원
  7. 기존 개발일정에 미치는 영향
여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 
Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.
그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.



Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

 마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.
지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?

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

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

전규현 기반시스템/소스코드관리 3WayMerge, Branch, build, Firefighter, FireFighting, hotfix, IDE, merge, Patch, release, TAG

  1. 좋은 글 잘 봤습니다. 가급적 정식패치를 가져가고 싶지만 고객은 당장해결해달라고 하는경우가 많네요 ㅠㅠ 버그의 수준이 심각한게 아니더라도 말이죠. 일단 Hotfix가 많이 나오지 않도록 코드품질에 신경써야겠고 영업측에도 Hotfix의 위험성에 대해서 설득해야 겠습니다. ^^

  2. 안녕하세요. 차우차우님
    말씀하신 현상은 우리나라 소프트웨어 회사에서 너무나 흔히 볼 수 있는 현상입니다.
    또한 우리나라 소프트웨어 회사들이 성장하지 못하는 가장 중요한 요소중 하나입니다.
    개발자들이 적당히 설득해서 영업이 바뀌었으면 벌써 잘 되었겠죠. 영업을 설득하는 것은 그렇게 쉽지 않습니다.
    특히, 경영자가 Sales oriented되어 있으면 더욱 힘듭니다. 개발자들도 심정적으로는 그렇게 하면 안되는 것을 알지만 좀더 전문적으로 강력하게 설득할 힘이 부족한 것이 현실입니다.
    그래서 저같은 전문가가 회사에 가서 경영자와 영업도 교육을 시키고, 시스템, 프로세스, 문화를 바꿔주는 것이지요. ^^
    해보다가 난관에 부닥히면 도움을 요청하세요. 감사합니다.

  3. 잘 읽었습니다. 볼 때마다 소스코드 관리 안하고 그냥 개발해서 뜨끔뜨끔합니다 ㅎㅎㅎ;;

  4. 안녕하세요. 루돌님 반갑습니다.
    엄청 오래된 블로그를 가지고 계시네요. 대단하십니다. ^^
    종종 들려서 좋은 정보를 나눠요.

  5. 그래도 cvs에 비해서 svn은 viewvc 등에서 tag를 보기가 힘든 단점이 있는거 같더라구요.
    아무튼 태그와 브랜치간에 오고가는거에 대한 문서는 보기 힘들던데
    그 부분에 대해서(실제 cvs, svn 명령어를 통해) 자세한 설명을 부탁드립니다.

  6. 안녕하세요. 구차니님
    viewvc같은 이슈는 전체 소스코드관리 이슈에서 너무나 미미한 이슈입니다. 지엽적인 이슈에 크게 좌지우지 되지 않는 것이 좋겠습니다.
    사실 시중의 모든 소스코드관리를 다루는 책에서 브랜치, 태그, 머지 등에 대해서 설명이 되어 있지만, 책을 보고 한번에 익히는 것은 대단히 어렵습니다.
    그래서 실무를 통해서 배우는 것이 가장 좋은데 제대로 하고 있는 선배들이 별로 없으니 이또한 어렵기는 마찬가지 입니다.
    그렇다고 블로그의 글을 통해서 모든 것을 전달하기도 어렵습니다. 어쨋든 나름대로 앞으로도 글을 계속 써보기는 할텐데, 글들을 보고 깨우치는 사람도 있을 것이고 그렇지 못한 사람도 있을 겁니다.
    제 Office에 한번 오시면 제가 직접 설명을 해드리면 더 빠를텐데요. ^^

    아무튼 앞으로도 계속 관심을 기울이고 실무에 적용을 해보면서 궁금한 것이 있으면 또 물어보고 이렇게 반복을 하다보면 어느새 다 깨우치게 될 겁니다.

    질문 중에서 "태그와 브랜치간의 오가는 것"이란 무엇을 말하는 것인가요? 질문이 매우 모호해서 구체적인 답변을 드리기가 어렵네요.

    댓글이나 Email을 통해서 자세히 설명을 해주시면 제가 답변을 드리도록 하겠습니다

    감사합니다.

혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

2010.05.03 14:00 by 전규현


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





소스코드관리에 대해서 얘기를 하다보면 혼자서 개발을 하기 때문에 별 고민 없이 대충 소스코드를 관리하는 경우를 많이 봤습니다.

Subversion 등의 소스코드관리시스템을 쓰더라도 그냥 소스코드를 백업 받는 수준으로 사용하고 많이 사용하면 Baseline설정(Tagging)정도 하곤하더군요. 그러면서 혼자서 개발을 하기 때문에 소스코드의 브랜치/머지가 필요 없다고 생각합니다. 하지만 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황은 꼭 발생하기 마련입니다. 만약에 이러한 상황에서 브랜치/머지를 능수능란하게 하지 못하면 기존의 수작업에 의존하는 방식으로 처리를 하면서 소스코드관리시스템이 주는 큰 혜택을 누리지 못하게 됩니다.

또, 개발자는 한명이 아니더라도 마치 혼자서 개발을 하는 것처럼 개발자들끼리 담당 소스코드를 철저히 나눠서 서로 충돌이 나는 일이 없도록 개발을 하는 경우가 허다합니다. 이런 것을 Component Owner라고 하고 이런 체제에서는 개발자들 간의 기술의 공유가 어려워지고 회사의 규모가 커질수록 개발 효율성은 점점 떨어지게 됩니다.

그럼, 어떤 상황에서 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황이 발생하는지 알아보도록 하겠습니다.

첫째, Hotfix인 경우입니다.
소프트웨어의 종류는 워낙 다양하기 때문에 획일적으로 말할 수 없습니다. 그래서 간단한 예를 하나 들어보죠. 매일 한번씩 패치를 만들어서 정해진 시간에 인터넷으로 업데이트를 하는 소프트웨어를 개발하고 있다고 칩십니다. 오늘 오후 5시에 내보낼 패치에 들어갈 Bug fix와 Feature를 열심히 넣고 있는데 긴급 Hotfix 상황이 발생한 겁니다. 따라서 정식 패치때까지 기다릴 수는 없고 일단 시급한 버그 하나만 고쳐서 서둘러서 업데이트를 해줘야 합니다. 이러한 상황에서 소스코드관리시스템을 사용하는 능숙도에 따라서 대처하는 방법들이 매우 다릅니다.

 하수

소스코드관리시스템을 거의 제대로 쓰지 못하는 경우, 오늘 고치고 있는 소스코드를 수동으로 하나씩 지워서 원래 버전을 만들어냅니다. 이러한 경우는 믿기 힘들겠지만 제가 컨설팅을 하면서 많은 회사들이 이렇게 하고 있다는 것을 접했습니다. 이렇게 원래 버전을 만들어서 Hotfix를 만들어서 내보낸 후에 다시 재작업을 합니다.

 중수

이보다 조금더 나은 경우, 원래 고치고 있던 소스코드의 디렉토리를 임시로 백업 받아 놓고 소스코드관리시스템에 있는 어제 버전의 소스코드를 다시 Check out합니다. 이렇게 Check out한 소스코드를 가지고 Hotfix를 만들어서 내보내고 오늘 작업하던 백업을 받아 놓은 소스코드와 Merge tool을 이용해서 Merge를 한 후에 정기 업데이트 버전을 만들어서 내보내는 방법입니다. 아까보다는 조금 나아 졌지만, 여전히 수작업에 많이 의존을 하고 귀찮은 작업들을 해줘야 합니다.

 고수

Subversion등의 소스코드 관리시스템을 제대로 사용한다면 이보다 좀더 손쉽습니다. 
우선 어제 릴리즈를 한 소스코드의 Baseline(Tag)에서 Hotfix용 브랜치를 만듭니다. 기존에 개발하고 있던 디렉터리는 그대로 놔두고 새로운 디렉터리에 Hotfix를 Check out 받습니다. 보고된 버그를 수정하여 자동화된 빌드스크립트를 이용해서 Hotfix를 만들어내고 업데이트에 올립니다. 정상적으로 Hotfix가 배포된 것을 확인하고 Hotfix 브랜치는 Trunk로 Merge를 합니다. 이때 3Way Merge 툴을 이용하면 됩니다. 
3Way Merge를 적용하려면 3개의 기준점이 필요합니다. 3개의 기준점은 다음과 같습니다.

Base - 어제 릴리즈한 Baseline(Tag)
Their - 오늘 Hotfix 릴리즈한 Baseline(Tag)
Mine - Trunk의 Head revision(최신소스)

3Way Merge를 통하면 거의 99% 자동으로 Merge가 되고 Conflict가 나는 소스코드들도 KDiff3나 P4Merge등의 GUI가 뛰어난 3Way Merge툴을 이용하여 쉽게 Merge를 할 수 있습니다.

그리고 현재 로컬에서 고치고 있던 소스코드와 통합을 해야 합니다. 이를 Rebase라고 하는데 SVN에서는 Update명령을 내리면 서버에서 바뀐 내용이 자동으로 Working copy와 통합이 됩니다. 이때도 3Way Merge를 이용하게 됩니다.

즉, 개발자는 소스코드 내용 고치는데만 신경을 쓰면 되고 나머지는 소스코드관리시스템이 다 알아서 해 줍니다. 소스코드 통합하는데 불과 얼마 걸리지 않고 혼동도 없습니다. 시간은 하수,중수의 수십분의 1이면 가능하게 됩니다.

혼자 개발하더라도 제대로 하지 않으면 이렇게 혼동이 있고 소스코드관리시스템의 기능을 잘 사용만하며 이렇게 손 쉬운데 개발자가 수십명, 수백명이서 하수, 중수의 방법으로 어떻게 소프트웨어를 제대로 개발할 수 있을까요?

물론 이것이 다는 아니죠. 기능을 충분히 사용하는 것은 이제 시작입니다. 더 큰 조직에서 조직적으로 제대로 사용하려면 프로세스, 규칙, 문화 등과 접목되어서 돌아가야 하는데, 이는 더 어렵습니다. 그러데 하물며 기능도 제대로 사용을 못하는 회사가 대부분인데 그 다음은 말할 필요하고 없죠.

Hotfix 경우 외에도 기존 소스코드에 큰 변경을 가해서 성공 여부를 확신할 수 없는 기능을 추가할때.
시간이 오래 걸리는 기능을 추가하면서 중간 중간에 다른 변경에 대한 릴리즈를 해야 할 때.
등 혼자서 개발을 하더라도 Branch/Merge를 해야 할 경우는 수도 없이 나오게 됩니다.

소스코드관리를 너무 쉽게 생각하면 안됩니다. 잘해 놓으면 무척 쉽고 개발에 매우 큰 도움을 주지만, 대충대충 하다보면 큰 발목을 잡히게 됩니다. 혼자 개발하더라도 제대로 하겠다는 마음가짐을 가지고 완벽하게 전체 기능을 다 알아야 합니다. 그리고 나면 이좋은 것을 왜 지금까지는 제대로 하지 않았을까 아쉬움이 들겁니다.

책을 보고 해보는 방법도 있지만 시간이 좀 많이 걸리겠지요. 주변에서 잘아는 사람에게 물어보는 것은 시간을 절약할 수 있는 좋은 방법입니다. 주변에 그런 사람이 없다면 블로그에 궁금한 것을 올려주세요. 제가 힘이 닿는한 잘 설명드리겠습니다. 제가 쓴 책(소프트웨어개발의 모든 것)에서는 이러한 부분이 이론적이 아닌 실제 방법을 자세히 설명하고 있으니 보시는 것도 도움이 많이 될 것입니다.

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


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

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

  1. 확실히 태그는 몰라도 브랜치는 사용법을 잘 모르겠더라구요. ㅠ.ㅠ
    나중에 브랜치 사용법 cvs/svn 에서 강좌가능하실까요? ^^;

  2. 안녕하세요. 구차니님
    브랜치/머지를 교과서적으로 뭔지 아는 것은 10분이면 됩니다. 하지만 제대로 쓰려고 이해를 하려면 시간이 많이 걸립니다. 그리고 수많은 케이스에서 적절하게 쓰는 방법을 모두 익히려면 1,2년 써보면서 알게 됩니다. 대부분은 시행착오로 배우는데, 시행착오 없이 배우면 더욱 좋지요. 제가 쓴 책에 자세히 적혀 있으니 참고하시고요. 필요한 부분은 구체적으로 물어봐주시면 설명 드리겠습니다. ^^
    강좌에 대해서는 한번 생각해 봐야겠네요. 작년에 Bit와 연계를 해서 교육을 실시한 적도 있기는 합니다. 그리고 몇몇 고객은 소스코드관리에 대해서만 세미나 식으로 교육을 실시한 적도 있죠.
    필요한신 것이 있으면 요청해주세요. 감사합니다.

  3. 좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.

  4. 안녕하세요. 차우차우님
    Hotfix에 대한 용어 정의는 회사마다 조금씩 다르겠지만, 일반적으로 Hotfix는 계획되지 않은 긴급패치를 말하므로 Hotfix가 많아진다는 것 자체가 문제가 될 수 있습니다. 이는 항상 호떡집에 불난 모양으로 FireFighting mode가 될 수 있습니다. 이왕 Hotfix의 버전 관리에 대해서 문의를 하셨는데 설명해야 할 내용이 댓글로 달기는 너무 많으므로 블로그에 포스트를 하도록 하겠습니다.

  5. 답변감사합니다. ^^
    역시 Hotfix가 많아진다는것 자체가 문제가 있는 상황인거네요. 릴리즈할때 좀더 완벽하게 준비한다면 hotfix를 남발하지 않아도 될테구요.
    나중에 Hotfix의 버전관리에 대해서도 포스팅해주시면 많은 도움이 되겠습니다.

  6. Hotfix에서의 버전관리포스트 올렸습니다.
    http://allofsoftware.net/entry/HotfixVersionControl

  7. 으아~ 너무 좋은 글인데요.
    재밌게 잘 읽었습니다^^

  8. 안녕하세요. Benjamin님
    재미있는 글은 아닌데 재미있게 보셨나니 SW개발을 정말 좋아하시는 것 같군요. ^^

  9. 저도 개인 프로젝트 진행 때 브랜치나 머지가 과연 필요할까 했는데 바로 이거군요!!

    감사합니다^ㅡ^/

  10. 안녕하세요. Yarmini님
    들려주셔서 감사합니다.

  11. Blog Icon
    알콜알프

    금융에서만 일을 했는데... merge에 대한 불안감은 있네요.. 제가 있던 곳에서만 그런건지 궁금하네요. 금융 계정계 같이 크리티컬한 부분에서도 merge 기능을 사용하나요??

  12. 안녕하세요. 알콜알프님
    금융쪽이라면 생각할 것이 좀더 많습니다. 물론 금융이라고 해서 소프트웨어자체가 더 복잡하다고 볼 수는 없지만, DB, Middle ware와 인터페이스가 있고, 대외계, 원장 등 연동해야 할 것이 많습니다.
    그래서 Merge를 못하는 것이 아니고 개발할 때 Merge를 감안해서 미리 생각하고 구현을 하면 됩니다.
    그렇게 하면 일반 Application보다 더 용이하게 Merge가 가능합니다.
    흔히 Merge를 하면 모든 것이 끝나는 것으로 생각을 하지만, 소스코드가 잘 Merge가 되었는지 직접 Diff를 이용해서 확인하는 것이 좋고, Merge 후 테스트를 또 해보는 것은 당연합니다.
    특히 계정계같은 숫자 하나 까딱 잘못되면 큰일나는 심각한 곳에서는 더 철저히 검증을 해야죠.
    그래도 이렇게 Merge를 이용하는 것이 완전 수동으로 하는 것보다 시간도 훨씬 적게 걸리고, 오류 가능성도 더 적습니다.

  13. Blog Icon
    이재주니

    안녕하세요 저는 기계과 대학원 생입니다.
    소프트웨어 분야는 아니지만 Simulation이다 장비 테스트다 하면서 하루에
    프로그래밍에 보내는 시간은 컴공 친구들이랑 비교해도 뒤지지 않는다고 생각합니다.(착각인가?)

    다름이 아니라 저희 대학원생들은 모두 기계과나 전자과를 나와서 소프트웨어 개발에 대한 체계적인 틀이 잡혀있지 않습니다. 코드는 어떻게 관리하는지 Document는 어떻게 만들어야 하는지 등등이요.

    [소스코드가 없어졌다] 글에서 나왔던 것 처럼 한 학생이 열심히 프로그램을 짜놓고 외국으로 가버렸습니다. 물론 소스코드를 들고 튀지는 않았지만 코드에 대한 어떤 코멘트도 Document도 없이 가버려서 그 코드를 읽고 이해하는데만 한달 가까이 걸렸던 것 같습니다. 제대로된 관리가 안되니 소스코드가 사라져버리는 일도 있었지요.
    얼마전에는 대청소를 했었는데 왠 낡은 컴퓨터가 있길래 버렸는데 알고보니 굉장히 중요한 소스코드가 들어있었던 적이 있었습니다. 결국 그 코드는 찾을 수 없었습니다.

    계속 이런 일들이 일어나는 상황에서 교수님께서 한명이 맡아서 코드관리 시스템을 만들라고 하셨습니다.
    지금 이 답글을 쓰고 있는 제가 맡게 되었는데요. 처음에는 막막하고 답답했는데 SVN에 대해 읽어 볼 수록
    이런게 있다는 걸 조금만 더 빨리 알았더라면이라는 생각이 들더군요.

    지금은 연구실에 SVN서버를 설치하기 전에 임시적으로 개인 서버를 만들어서 테스트하고 있는데요,
    SVN에 기능이 너무 많아서 어떤 기능 부터 써봐야할지 감이 잡히질 않습니다.
    모든 기능들을 테스트 해보기에는 시간이 없고, 꼭 알아야하고 제가 연구실 팀원들에게 알려주어야 할 기능들이
    있다면 조언이 가능한지 여쭙고 싶습니다.

    어쩌다보니 자기소개처럼 되어버렸네요.
    좋은 글 감사드립니다. 조만간 책도 사서 읽어봐야겠네요.^^

  14. 시중에 SVN에 관련된 책이 많이 있으니 참고를 하시면 되겠습니다. 단순 명령어 사용법 보다 핵심 원리를 깨닫고 싶다면 "소프트웨어 개발의 모든 것"이라는 책을 보시기 바랍니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바