2010년 5월 3일 월요일

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

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

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를 해야 할 경우는 수도 없이 나오게 됩니다.

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

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

댓글 16개:

  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에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다. 2010/05/03 - [기반시스템/소스코드관리] - 혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까? 차우차우 2010/05/03 22:49 좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를..

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

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

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

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

    감사합니다^ㅡ^/

    답글삭제
  11. 소프트웨어 개발의 모든 것 - 김익환.전규현 지음/페가수스 소프트웨어 개발의 모든 것이라 제목이 붙긴 했다만 물론 제목은 뻥이다. 어떻게 이 얇은 책이 소프트웨어 개발의 모든 것을 다루겠는가. 사실은 소프트웨어 공학의 모든 것이 책 내용과 조금 더 어울리긴 하지만 그렇게 이름지었으면 난 죽을 때까지 이 책을 안 읽었을 것이다. 나는 컴퓨터 과학의 대부분의 분야가 아주 재밌고 흥미롭지만 소프트웨어 공학 만큼은 질색이다. 그럼에도 불구하고 이 책은 꽤나..

    답글삭제
  12. 안녕하세요. Yarmini님
    들려주셔서 감사합니다.

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

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

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

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

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

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

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

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

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

    답글삭제