태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '소스코드관리'

소스코드는 어디 있나요?

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의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜치 요구는 항상 생깁니다.

베이스라인

2009.08.04 23:12 by 전규현


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




"Baseline"이라는 용어가 생소한 개발자들이 있을 수 있습니다.

우리말로 번역을 하면 "기준선"이라고도 하는데, 헷갈리므로 그냥 Baseline이라고 사용해도 무관할 것입니다.

소스코드는 살아 있습니다. 매 순간 변화하고 있다고 봐도 됩니다. 실제로 몇 천명의 개발자가 참여하는 프로젝트에서는 소스코드 관리시스템의 로그를 보면 거의 매 순간 소스코드가 바뀌는 것을 알 수 있습니다. 또 작은 프로젝트라고 하더라도 어느 순간에 소스코드가 바뀔지는 알 수 없습니다. 그래서 Baseline을 관리하지 않으면 소스코드의 어느 의미 있는 순간을 잡아내는 것이 쉽지 않습니다. 그래서 Baseline을 관리합니다.

Baseline을 설정하는 방법은 여러 가지가 있습니다. 소스코드를 통째로 특정 디렉터리에 복사를 해 놓는 것도 Baseline설정의 한 방법입니다. 그 순간의 소스코드를 언제든지 꺼내 올 수 있죠. 하지만, 더 편리하고 일반적인 방법은 소스코드관리시스템의 Baseline설정 기능을 이용하면 됩니다. Visual SouceSafe에서는 Label이라고 하며 CVS, SVN에서는 Tag라고 합니다. 이중에서 SVN이 Baseline을 설정하는데 탁월한 성능적인 우위를 가지고 있습니다.

Baseline 설정이 왜 필요할지 해보지 않고 선뜻 이해를 한다는 것은 불가능합니다. 여태 Baseline 설정 한번 하지 않고도 소프트웨어를 잘 개발해 왔으니까요. 그럼 Baseline을 설정하지 않으면 어떠한 부작용들이 있는지 알아보죠.

가장 먼저 버그가 발생했을 경우 정확하게 버그가 발생한 그 버전에 대한 소스코드를 찾기가 어려워서 정확한 버그 재현이 곤란해질 수 있습니다. 그리고 릴리즈가 통제가 되지 않을 수도 있습니다. 즉, 1.5버전을 빌드해서 만들어 놓고, 은근 슬쩍 소스코드 몇 개 바꾸고 그냥 1.5버전을 다시 빌드해서 그냥 내보내는 겁니다. 사소한 것으로 생각해서 이렇게 하는 경우도 있지만, Baseline이 관리되지 않은 조직에서는 흔히 볼 수 있는 일입니다. 

Baseline은 주민등록과 같이 개발팀에서 낳은 모든 아이(소프트웨어)의 기록입니다. 개발팀에서는 아무리 많이 소스코드를 바꾸어도 출생기록이 남는 것은 아닙니다. 하지만, 일단 소프트웨어가 빌드 되어서 개발팀 바깥으로 나가서 테스트팀으로 넘기던, 고객이 소프트웨어를 사용하던, Baseline라인이 관리되어야 합니다. 소스코드 한 줄을 바꿔서 다시 릴리즈를 했어도 Baseline은 바뀐 것이고, 다른 소프트웨어로 관리가 되어야 합니다. 그렇지 않으면 아이는 수십명 낳아놓고 각 아이들의 출생 기록도 없고, 이름도 없는 아이들이 많아지는 겁니다. 많은 아이 중에서 한 아이가 아픈데, 누가 아픈 것인지 정확하게 지칭도 못하는 일이 발생하기도 합니다.

소스코드관리시스템을 이용하면 아주 쉽게 Baseline을 설정할 수 있습니다. 기존에 Baseline을 설정하지 않고도 소프트웨어 개발에 문제가 없다고 하더라도, 기존의 방법에 익숙해진 것 뿐이지 문제가 없는 것도 아니고 효율적이지도 못합니다. 소프트웨어를 빌드하고 릴리즈하는 기준을 현재변화하고 있는 소스코드가 아닌 Baseline을 이용하는 방법으로 전환을 해야 합니다. 각론에 들어가면 회사마다 Baseline설정 규칙이 달라질 수는 있겠지만, 소프트웨어를 공식 빌드하고 릴리즈하기 위해서는 Baseline을 설정한다는 규칙은 바뀌지 않습니다.

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

전규현 기반시스템/소스코드관리 Baseline, 릴리즈, 빌드, 소스코드관리, 형상관리

  1. 저희는 cvs에서 tag를 이용하고 있는데, 작은 규모 치고는 소장님께서 잘 운영을 하고 있었던 거군요 -ㅁ-!

  2. 구차니님 안녕하세요. 개발팀 규모가 아무리 작아도 Baseline은 설정해죠. ^^ CVS의 단점 중의 하나가 프로젝트의 규모가 커지면, Tag, Branch 생성에 시간도 오래 걸리고, 시스템 공간을 많이 차지하는 것입니다. 대규모프로젝트를 하다보면 CVS의 불편함을 종종느끼게 됩니다.

이 소스코드는 나 밖에 못 건드려!

2009.07.19 11:01 by 전규현


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



"우리 팀은 각자 맡고 있는 소스코드가 달라서 서로 충돌 일이 전혀 없어요"

" 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게"

"내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려"

"지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 없어요. 이거 끝날 때까지 기다려주세요."

 

이와 같은 현상이 친숙하나요? 그럼 Parallel Development(병행개발)와는 거리가 멉니다.

개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 항상 Lock 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다.

 

아키텍처적인 이슈를 제외하고는 개발자들은 서로 같은 소스코드를 얼마든지 동시에 수정할 있고, 소스코드가 충돌이 일어나더라도 얼마든지 쉽게 해결할 있어야 합니다. 또한 동일한 소스코드를 기반으로 길고 짧은 프로젝트를 동시에 진행하면서 나중에서 손쉽게 Merge 있어야 합니다. 이런 식으로 개발을 하지 않으면 대형 프로젝트는 너무 오래 걸릴 밖에 없습니다.

 

또한 때문에 개발자들이 Component Owner식으로 자신만 소스코드를 다룰 있다면 개발자들간에 소스코드 공유가 취약해지며 서로 단절된 개발을 하기 십상이 됩니다.

 

하지만 이런 Component Owner방식에 익숙한 환경에서는 이것이 너무 당연하게 생각이 되므로 이것을 바꾸려는 생각을 하기란 쉽지가 않습니다. 지금이 방식이 익숙하고 문제가 없어 보이고 이런 환경에서 발생한 문제들을 온갖 편법으로 피해 왔기 때문에 바꾸기가 쉽지 않습니다. 하지만 이로 인해 발생하는 문제들은 무시할 없습니다.

 

Parallel Development 제대로 수행하려면 소스코드관리시스템을 단순히 소스코드 저장소 용도로 사용해서는 부족합니다. 소스코드관리시스템을 제대로 사용하기 위한 프로세스와 규칙이 필요하며 Branch Tag, Merge 용도에 맞게 능숙하게 사용할 있어야 합니다.


이미지출처 : Microsoft Office Online

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

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

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

  1. Blog Icon
    mv

    지금 회사에서 svn을 쓰고 있습니다. 그냥 깔아서 쓰고 있죠. 문서공유와 프로젝트 소스코드를 관리하기 위함입니다.하지만 svn담당자는 branch가 뭔지,tag가 뭔지, merge기능이 뭔지 모르더군요. 그냥 계정주고 인스톨만 하면 끝인줄 압니다. 안타깝죠~.그렇게 깔아놓고 후배들에게 무언가를 가르칩니다. 안타깝죠.~

  2. 안녕하세요. SVN을 그렇게 사용한다면 SVN이 주는 혜택의 5%정도밖에 못보는 거죠. "소스코드관리시스템을 사용하고 있습니까?"라는 질문에 "Yes"라고 답하기 곤란한 경우죠.

  3. Blog Icon

    비밀댓글입니다

  4. 결론은 버전 컨트롤 인가요 ㅋ
    아직 태그만 사용해봤지 브랜치는 사용해 보질 않아서 ㅠ.ㅠ 한 10% 기능밖에 못쓰는거 같아요

  5. 안녕하세요. 구차니님
    결론이 버전컨트롤이라기보다는 이것은 소프트웨어를 개발하는데 있어서 아주 기초가 되는 사항이기 때문에 결론보다는 시작이라고 해야 적당한 것 같습니다. 단순히 소스코드를 공유하고 백업 받는 기능을 익히는데는 5분이면 족하지만, 그 외에 중급/고급 기능은 제대로 익히는데 몇년이 걸리기도 합니다.

  6. 그래서 우리 팀엔 규칙이 있죠.. 먼저 커밋한 사람이 이기는거다.. ^^;

  7. 안녕하세요. whitekid님
    불변의법칙이죠. 먼저 커밋하는 사람이 장땡이죠. ^^
    거대한 프로젝트에서는 나중에 커밋하는 사람이 Merge하는데 며칠이 걸리기도 합니다. 아무리 툴의 지원을 받아도 그런 경우도 있죠.

  8. ㅋㅋ 가장 먼저 커밋 하는 사람이 장떙? ㅋㅋ

  9. ASH84님 안녕하세요.
    왠만한 규모의 프로젝트에서는 Merge를 잘 이용하며 손쉽게 공동작업이 짧은 시간에 이루어집니다.

  10. 저희는 ClearCase를 쓰고 있는데...
    "소스코드관리시스템을 이용하고 계십니까?" 라는 질문에 "No"라고 해야 할듯 싶네요..에공~

누가 소스코드를 몰래 바꿔놨다.

2009.07.13 19:57 by 전규현


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



누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회
사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.

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


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

전규현 기반시스템/소스코드관리 Peer Review, 빌드, 소스코드관리, 슈퍼맨3, 테스트

소스코드관리 상세 조사 결과 리포트

2009.03.08 16:18 by 전규현


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



지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 2주에 걸쳐서 2차 조시를 실시했습니다.

질문항목이 26개나 되는 상당히 긴 투표였지만, 많은 분들이 응해주셔서 나름대로 의미있는 수치를 얻을 수 있었습니다. 투표에 참여해주신 모든 분께 감사드립니다.

투표위젯에 참 참여자 수를 보는 방법이 없어서 가장 많은 득표를 한 항목으로 미루어 짐작해서 35명이 투표에 참여한 것으로 생각하고 있습니다.

질문은 다음과 같았습니다.



각 항목별로 총 득표수는 다음과 같습니다. 아래 조사는 소스코드관리시스템을 사용하는 회사를 기준으로 계산을 할 것이므로 1번 항목은 100%입니다.


그럼 각 항목 별로 분석을 해보도록 하겠습니다.

1) 관리방법

2번 항목은 모든 개발자가 얼마나 소스코드관리시스템을 철저히 사용하는지에 대한 조사입니다. 소스코드의 Working copy가 개발자 PC나 개발서버에 임시로 있을 수는 있어도, 보관의 목적으로 다른 곳에 보관을 하면 안됩니다. 

3번 항목은 소스코드와 문서를 같이 보관하고 있는가에 대한 조사입니다. 즉, 소스코드 뿐만 아니라 Baseline에 포함이 되어야할 모든 문서도 같이 보관을 해야 합니다. 조사결과 문서를 같이 보관한다는 응답이 40%에 불과하는데, 실제로 Baseline에 포함될 모든 문서와 자료를 다 보관하는 경우는 40%보다 더 적을 것으로 생각이 되는 군요. Baseline을 설정할 때 항상 문서와 소스코드는 같은 버전으로 짝을 이루어야 합니다. 대부분의 소프트웨어 개발 회사가 문서 작성에 소흘하기 때문에 이 항목은 아예 신경을 안쓰는 경우가 많습니다.

2) Baseline
이 항목들은 Baseline을 얼마나 제대로 설정하고 있는가에 대한 조사입니다.
Baseline을 설정한다는 응답도 54%로 낮은 편이나 제때 빠짐없이 Baseline을 항상 설정한다는 응답은 26%에 불과하다는 것을 알 수 있습니다. 특히 프로젝트 종료후 한번만 Baseline을 설정하는 경우도 있었습니다.

똑, 특이할만 한 점은 앞의 조사에서 문서도 같이 저장하는 경우는 40%이나 문서도 같이 Baseline을 설정하는 경우는 17%에 불과합니다. 즉, Tag나 Label을 만들 때 문서는 제외하고 소스코드만을 포함하는 경우입니다. 


3) Rule
8번 항목을 보면 대부분의 회사가 메시지 작성 규칙이 없음을 알 수 있습니다.즉, 개발자들이 알아서 메시지를 남기거나 안남기기도 한다는 것이죠. 실제로 많은 회사들의 경우를 보면 소스코드관리시스템의 History가 거의 쓸모 없는 경우가 대부분입니다. 단순히 소스코드 저장소 역할만 하는 것이죠.

9번은 버그관리시스템과 연동이 되는지 보는 것인데, 8번과 같은 비율이 나온 것은 좀 이상하네요. 8번은 그야말로 기본적인 항목이고, 9번은 좀더 성숙도가 높은 항목인데요. 어쨋든, 소스코드관리시스템과 버그관리시스템은 서로 연동을 하면 개발 생산성을 높일 수 있습니다. 그리고, 버그ID가 없이 소스코드를 임의로 수정하는 일을 막을 수 있습니다. 시스템에서 버그 ID가 없으면 소스코드를 수정할 수 없도록 막을 수도 있습니다.

10번 항목은 소스코드가 항상 빌드가 가능한 상태를 유지하는지에 대한 질문입니다. 나름대로 회사들이 Broken tree를 방지하기 위해서 노력하고 있네요. 

4) Review
이번 리뷰에 대한 조사 결과는 기대보다 대단히 낮은 것을 볼 수 있습니다. 일단 리뷰를 거의 안하고, 소스코드를 등록할 때도 리뷰자를 남기는 경우가 별로 없네요. 즉, 리뷰의 대한 저변은 매우 낮은 것을 알 수 있습니다.
특이한 것은 Pair programming을 하는 회사가 11%나 되네요. 

5) Build
자동으로 Daily Build를 하고 있는 회사는 29%에 불과했습니다.
개발자 중에는 매일 빌드를 한다고해서 Daily Build를 하는 것으로 착각하는 경우가 있는데, Daily Build는 자동화 되어서 매일 지정된 시간에 자동으로 빌드를 하는 것을 말합니다.

6) 응용
이 항목은 개발자들의 공동작업을 얼마나 효율적으로 소스코드관리시스템을 이용해서 유연하게 처리하고 있는지 조사한 것입니다.
일단 Branch를 사용하고 있는 회사는 꽤 많습니다.(40%) 이에 비해서 Branch를 승인받아야 한는 경우는 17%에 불과합니다. 개발자들이 Branch를 아무 때나 만들 수 있다면 자칫 Branch가 관리가 안될 수도 있습니다.
소스코드를 Merge하는 회사는 60%정도이고 이중에서 아직도 상당히 많은 회사가 2-way merge나 눈을 이용해서 수동으로 Merge를 하고 있는 것으로 알 수 있습니다.
3-way merge툴을 아는 개발자가 40%나 되지만 그 활용도는 대단히 떨어집니다.(23%)
즉, 안다고 제대로 활용할 수 있는 것은 아니네요.


7) 백업
소스코드관리시스템은 꼭 백업을 받아야 합니다. 그런데, 약 60%만이 백업을 받고 있고 그중에서 안전한 장소에 백업을 보관하고 있는 회사는 훨씬 더 적습니다. (26%)

총평)
소스코드관리시스템 사용에 대한 성숙도를 따져보면 평균적으로 초,중급 정도의 사용도를 보이고 있습니다. 하지만, 이는 제가 실제로 접하는 여러 회사들이 평균보다도 높은 수치입니다. 그 원인이 블로그의 방문자들의 수준이 더 높던가, 얼굴을 보지 않고 이루어지는 투표라서 더 관대하게 투표를 했다고 생각합니다. 그렇다고 하더라도 아직 소스코드관리시스템의 활용도는 대단히 낮은 상태라고 볼 수 있습니다. 물론 소스코드관리시스템을 쓰지조차 않는 조직과 비교하면 상대적으로 낫겠지만, 개선할 점이 많습니다. Allofsoftware 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.

다시한번 설문에 응해주신 모든 분께 감사드립니다.
저작자 표시 비영리 변경 금지
신고

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

  1. 예상대로 코드리뷰에 대한 결과는 저조하군요. 흠...

  2. 헝그리맨님 안녕하세요.
    코드리뷰는 가장 정착시키기 어려운 개발문화 중의 하나입니다. 실리콘밸리에서도 귀찮기는 마찬가지이지만, 규칙으로 정해 놓고 누구나 따릅니다.

  3. Blog Icon
    [1002]

    3번 Rule 에서 8,9번 항목의 경우 처음 질문 때 의도가 명확치 않으면 구분해서 쓰지 않고 중복 체크를 할 것 같습니다만.
    그리고 버그트래커-버전관리툴 이 연동된 시스템을 쓰는 개발자 입장에선 버그 번호를 쓰는게 더 쉽습니다. 아무 설명도 안쓰고 버그 번호만 쓰면 되거든요. (상세 내용은 어차피 버그트래커에서 계속 덧글로 달리므로. 그리고 버그 트래커와 버그 번호 연동되는 시스템인 경우 버그 번호만 룰에 맞춰 남기는게 훨씬 보기에도 좋고 추적성 면에서도 좋습니다. 그리고 SVN Log 로 쓸 수 있는 텍스트 양은 한계가 있습니다. 차라리 별도 문서를 남기죠)
    3 way merge 의 경우.. 툴 자체가 편하긴 하나, 자동 테스트가 구축되고 커밋 빈도가 높은 곳의 경우 그냥 눈으로 비교하는 것으로도 충분합니다. (한 changeset 당 코드 변화량이 적은 경우) changeset 당 코드 변화량과 conflict 단위가 큰 경우 툴의 편의성 문제로 보기보다는 그렇게 conflict 단위가 크게 가는 상황 자체가 문제일지도 모르죠.
    그리고 질문이 있다면.. '팀/프로젝트 규모 대비 필요한 만큼의 성숙도' 의 기준이 정해진 것이 있는지 궁금합니다.

  4. 좋은 의견 감사합니다.
    8,9번 항목의 경우 실제로 그렇게 하고 있는 개발자라면 다 이해를 할 것입니다. 제대로 하고 있는 곳이라면 8,9번을 다 체크하겠지요.
    머지는 팀이 커질수록 머지에 많은 노력이 들어가는데, 눈으로 비교해서 머지하는 것은 시간도 많이 걸리고 실수의 가능성도 크다고 생가가합니다. 팀이 커지고 동시에 많은 사람들이 소스코드를 중복해서 수정하더라도 Conflict가 가능하면 적게 생기도록 하는 것이 좋습니다. 이런 경험이 쌓이면 자연스럽게 어떻게 해야 Conflict가 적게 생기는지 요령이 생깁니다.
    3,4명의 개발자들이 동시에 개발하는 팀에서는 어떻게 해도 큰 문제가 되지는 않습니다. 개발팀이 커질 수록 신경을 써야겠지요.
    제가 소프트웨어공학 컨설팅을 하기 때문에 '팀/프로젝트 규모 대비 필요함 만큼의 성숙도'에 대한 기준은 가지고 있습니다. 하지만 많은 회사들이 그 기준에 미치지 못하고, 발생하는 수많은 문제를 피해 다님으로서 스스로의 생산성과 역량을 떨어뜨리는 결과를 가져오고 있습니다. 팀의 규모와 역량에 알맞은 규칙과 툴을 적절하게 이용하면 훨씬 더 생산성을 높일 수 있는데, 심지어는 자신만의 세계에 갇혀서 이러한 변화를 거부하는 개발자도 많답니다.

  5. Blog Icon
    한인철

    안녕하셔요?
    이제는 개발자에서는 조금 멀어진 애 늙은이 입니다.^^
    제가 종사하는 분야에서는 아직도 주먹구구식으로 개발이 이루어지고 있습니다.
    후배들에게는 체계가 갖추어진 환경을 물려주기 위해 공부 중입니다.

    그런데, 코드리뷰는 어떻게 해야 하나요?
    막연한 질문이지만, 간단히 설명 부탁드립니다.
    혹시, 좋은 무료도구가 있을까요?
    집필하신 책을 주문했는데, 그 안에 답이 있을까요?

    그리고, 버그추적시스템을 소개와 비교 부탁드립니다.

    감사합니다.

  6. 한인철님 안녕하세요.
    코드리뷰는 가장 필요하면서도 매우 정착시키기 어려운 개발문화입니다. 코드리뷰는 종류가 여러가지고 있고, 개발 조직에 따라서 알맞은 방법을 써야 하며 제도적으로, 시스템적으로 뒷받침이 필요합니다. 여러 도구가 있기는 하지만 당장 도구가 없어서 코드리뷰를 못하는 것은 아닙니다. 일단 시작하는 것이 중요하고 시작하기 위한 기본적인 지식은 갖춰야죠. 좀더 구체적인 것이 필요하면 연락주세요.

    그리고 버그추적시스템은 제 책에도 소개가 되어 있고, 현재 투표가 진행중인데, 투표가 끝나면 글을 올릴 예정입니다.

    감사합니다.

사라진 소스코드

2009.02.28 10:59 by 전규현


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



바이너리는 있는데 소스코드는 없어서 낭패를 보신 적은 없으신가요?

소스코드 백업은 흔히 소홀히 하기 쉽습니다.
사고가 발생한 후에야 문제가 되고, 사고가 그렇게 자주 발생하는 것은 아니죠.
자주 발생하지는 않지만, 일단 발생하는 타격이 아주 큽니다.
일상 생활에서는 보험을 들지만, 소프트웨어를 개발하는 현장에서는 보험을 드는 격인 백업을 제대로 하는 경우는 흔히 보기 어렵습니다.

소스코드는 이러한 경우에 흔히 사라지거나 깨지게 됩니다.
이 때 백업이 없으면 낭패가 됩니다.

  • HDD는 그리 드물지 않게 깨집니다. 그냥 운영 중에 HDD가 깨져버리는 경험은 많이들 있을 겁니다.
  • 장비를 사무실 내에서 옮기거나, 회사가 이사를 갈 때는 HDD가 깨지는 경우가 더 흔합니다.
  • 컴퓨터바이러스 등의 악성 코드에 의해서 데이터가 파손되거나 시스템이 망가질 수 있습니다.
  • 번개나 전기 공사중의 시스템에 과도한 전류 등의 문제로 시스템이 망가지는 경우
  • 화재, 지진, 홍수 등의 재난으로 시스템이 완전히 망가질 수 있습니다.
  • 시스템이나 HDD를 도난 당할 수 있습니다.
  • 개발자가 개발을 하다가 실수로 소스코드 전체 혹은 일부 파일을 삭제할 수 있습니다.
  • 여러 개발자가 파일서버에서 동시에 개발을 하다가 실수로 다른 개발자가 개발해 놓은 내용을 무시하고 싹 Overwrite를 해버릴 수 있습니다.

그래서 소스코드를 백업을 받아야 하는데, 아래와 같이 불완전하게 백업을 받으면 완벽한 보험장치가 될 수 없습니다.
  • 소스코드를 보관하고 있는 시스템을 RAID로만 구성하고 별도로 백업 받지 않음
  • 소스코드가 보관되어 있는 시스템의 다른 디렉터리에 파일을 복사해서 백업
  • 사내의 다른 시스템에 미러링 또는 정기적으로 복사
  • 소스코드는 소스코드관리시스템에 있지만, 또한 각 개발자들의 PC에도 일부 또는 전체가 있어서 소스코드관리시스템이 망가져도 어딘가에는 소스코드가 있다. 
  • 주기적으로 DVD로 백업을 받아서 사내에 보관
  • 사내에 소스코드는 팀 별로 여러 시스템에 보관이 되어 있는데, 팀 별로 알아서 스스로 백업을 받는다.

위의 경우 대부분의 사고에도 소스코드를 복구할 수 있겠지만, 화재가 발생 한다면 백업 받아 놓은 DVD도 같이 싹 타버릴 것입니다. 실제로 911테러나 고베 대지진 때 수많은 회사들이 백업 데이터가 없어서 문을 닫은 경험들이 있습니다. 이런 큰 사건이 아니라고 하더라도 화재 등의 사건은 발생할 수 있고, 회사는 화재에 대한 보험을 거의 다들 들고 있습니다. 하지만, 그런 화재보험이 소스코드를 복구 시켜 주지는 않습니다. 대부분의 회사가 화재를 경험하는 일은 평생 없겠지만, 누군가는 겪게 되고, 화재 뿐만 아니라도, 서두에서 언급했던, 백업이 필요한 수많은 경험들은 한번씩은 해봤을 겁니다. 
그래서 백업은 아래와 같이 3단계로 이루어져야 합니다. 

기본적으로 소스코드관리시스템을 사용한다는 전제하에 설명을 하겠습니다. 그래야, 최종 소스뿐만 아니라 소스코드 History도 모두 보관을 할 수 있습니다. 아래 활동은 개발팀마다 각각 수행하면 안되고, 회사가 아무리 커도 전체소스코드를 한군데서 관리를 하며 백업도 한번에 받아야 합니다. 


  • 소스코드관리시스템은 RAID를 구성하거나 실시간 미러링 시스템을 만들어서 시스템 장애 시 항상 복구가 가능해야 합니다. 이는 시스템이 항상 작동하도록 해줍니다.
  • 소스코드관리시스템은 하루에 한번 DVD등의 미디어에 Incremental 백업을 받아야 합니다. 그리고 백업 받은 DVD는 사내에 보관합니다. Incremental 백업은 크기가 크지 않으므로 그리 오래 걸래지 않습니다. 이는 시스템이 망가져도 적어도 24시간 이전의 소스코드로 돌아갈 수 있도록 해줍니다.
  • 소스코드관리시스템은 일주일에 한번 DVD로 Full 백업을 받아서 회사 외부의 안전 장소에 보관을 해야 합니다. 안전한 장소는 은행의 안전금고 등이 될 수 있습니다. 이는 회사가 완전히 불타서 없어져도, 적어도 일주일 전의 소스코드로 완전히 복구를 해줍니다.
소스코드를 안전하게 백업을 받았다가 불의의 사고 시 복구를 한다고 해도, 소스코드를 가지고 제품을 만들어 내는데 일주일 또는 수주가 걸린다고 하면 안됩니다. 백업의 목표는 소스코드 복구 후 24시간 안에 원래 제품을 그대로 만들어 낼 수 있어야 합니다. 그러기 위해서는 정확한 개발환경, 빌드환경, 테스트환경 정보가 문서에 기록이 되어서 소스코드관리시스템에 같이 보관이 되어 있어야 하고, 빌드는 완전히 자동화 되어서 빌드환경 구성 후 빌드 스크립트만 실행하면 제품이 만들어지도록 준비가 되어야 합니다. 

이 정도가 되어야 제대로 된 백업을 받고 있다고 할 수 있습니다. 

뭐, 백업을 이정도까지 완벽하게 받는냐?라고 반문하시는 분이 계실지 모릅니다. 

그런 분이 질병 보험을 들면서, 한달에 보험료를 3만원만 내면, 감기, 골절 등 대부분의 질병은 다 보장이 되는데, 암 등의 죽을 수 있는 병은 보장이 안된다고 하면 어떻게 생각하시겠습니까? 
또, 죽을 병이 보장이 되려면 보험료를 4만원을 내야 한다고 하면 어떻게 하시겠습니까? 나는 절대 암에 걸리지 않을 거야 하고 3만원만 내시겠습니까?  아니면 암에 꼭 걸릴 것을 예상하고 4만원을 내십니까? 
대부분은 암에 절대로 걸리지 않을 것이라고 생각하면서도 일단 암에 걸리면 타격이 크니, 4만원을 보험료로 내는 선택을 할 겁니다.

백업도 마찬가지입니다. 절대로 화재나 지진등의 사고는 발생하지 않을 것이지만, 대비를하는 것입니다. 그 대비 비용이 사고 발생 후의 피해 보다는 훨씬 작기 때문입니다.

보험료를 지불한 만큼 보장을 받는 것입니다.

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

전규현 기반시스템/소스코드관리 백업, 빌드자동화, 소스코드관리

  1. 예전에 만든 프로그램에서 버그가 발견되었지만, 소스파일을 날려버려서 새로 만든 적이 있습니다. 그 이후로 항상 웹과 USB, HDD에 삼중보관을 하고 있죠. 그런데 솔직히 위의 방법은 지나친 감이 있네요. 회사 차원에서 별도의 백업팀이 있으면 할만할지 모르겠지만 개인에게는 어려울 것 같습니다.

  2. 아리새의 펜촉님 안녕하세요.
    누구나 자신에게는 큰 사고가 일어난다고 생각하지 않습니다. 경험하신 일은 소스코드를 날려버리신 일인데, 보통 자신이 경험한 일 정도만 대응을 합니다.
    위와같이 3단계로 백업을 하려면 백업팀은 아니고 백업담당자는 필요합니다. 대부분의 백업은 자동화를 하고, 주간백업정도는 수동으로 해야할 일이 있습니다. 백업담당자는 자신의 일중에서 10~20%정도는 백업을 해야합니다.
    위와 같이 3중보관을 하고 계신다면 99.9%의 사고에는 완전할 수 있습니다. 0.1%의 사고까지 방지를 할지는 비용대비 효과를 생각해서 스스로 판단해야 할 일입니다. 작은회사들이 그렇게 투자하는 일은 흔하지 않습니다.
    하지만 회사의 규모가 커질수록 큰 사고에 대해서 생각하지 않을 수 없습니다.

  3. svn과 같은 형상관리를 적용해 보시는 것은 어떨까요?

  4. 하루님 안녕하세요.
    형상관리를 적용하는 것은 기본이죠. 위의 모든 얘기도 형상관리를 적용한 다음의 얘기입니다. 단, 저는 형상관리라는 말은 잘 사용안합니다. 가능하면 소스코드관리라고 얘기합니다. SVN을 백업받는 얘기라고 생각하시면 됩니다. ^^

하루에 몇 번 커밋하세요?

2009.01.07 15:35 by 전규현


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





한 개발자가 하루에서 수도 없이 커밋(Commit)을 하고 있다면 소스코드관리시스템을 백업서버로 쓰고 있을 가능성이 높습니다.
사실 이러한 경우를 매우 자주 봤습니다.

혹시 코딩을 하다가 점심 먹으러 간다고 한번 커밋하고 중간 중간에 수시로 커밋을 하고 있으면 이건 좋은 방법은 아닙니다.
혹시 이런 방법으로 소스코드관리시스템(SVN, CVS, VSS, ClearCase 등)을 사용하고 계신지 확인해보십시오. 본인이 아니라도 이렇게 백업용도로 사용하고 있는 동료나 후배가 없는지 확인해보십시오.

커밋을 하면 소스코드의 Revision이 바뀌게 되는데, 각각의 Revision은 의미를 가지게 됩니다. 
그 의미가 "점심 먹으러 나가면서 임시로 저장" 이렇게 되면 곤란합니다.

각 Revision의 정보는 우리회사 개발의 역사로서 영원히 남게 되는데 그런 쓰레기 정보를 남기면 안되죠.
누군가는 각 Revision에서 바뀐 내용을 알기 위해서 Diff를 해볼 것이고, 이를 이용해서 Merge도 할 수 있고, 원 소스코드 작성자에게 내용을 물으러 올 수도 있습니다.

그래서 커밋(Commit)은 아무 때나 아무렇게나 하면 안됩니다. 각 회사마다 소스코드관리시스템을 사용하는 규칙이 필요하고, 이를 지켜야 합니다.
소스코드를 수정하기 위해서는 항상 버그ID(Issue ID)가 필요하며 그에 따른 수정 내용은 한번에 커밋을 하는 것이 바람직합니다. 그리고 커밋을 할 때는 회사의 규칙에 맞는 형식으로 Message를 남겨주어야 합니다. 이때 버그ID와 수정 내용 및 Peer Review(Desk check 정책을 사용할 경우)를 한 사람은 꼭 기록하는 것이 좋습니다.

이렇게 쌓인 소스코드관리시스템의 History와 마구잡이로 규칙없이 사용한 History는 나중에 그 가치와 활용도가 확연히 차이가 나며 개발 생산성에 많은 영향을 주게 됩니다. 

사소해 보이지만 쌓이면 정말 큰 차이가 나는 중요한 개발 규칙 중 하나입니다.

이미지출처 : Microsoft Office Online

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

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

  1. 커밋은 자주하는 것이 좋죠. 로컬에 있는 소스는 부패하기 쉬운 코드입니다.

  2. allting님 안녕하세요.
    저와 다른 의견이지만 의견을 주셔서 감사합니다.
    자주 커밋을 하면 PC가 망가져도 소스코드를 지킬 수 있는 장점이 있는 반면 제가 위에서 나열한 단점도 있겠습니다. GIT같은 분산형 SCM을 써서 일부 보완을 하기도 합니다.
    제가 사람들에게 강조하는 것은 항상 원칙이죠. 원칙에서 좀 벗어나도 지금의 환경에서는 문제가 없을 수 있어도 조직이 아주 커지는 등의 환경이 바뀌면 문제가 있을 수 있기 때문이죠. 그래서 원리와 원칙을 이해하고 있으면 여러 상황에도 가장 효과적인 방법을 제시할 수 있겠죠.
    감사합니다.

  3. 저도 위에 댓글 다신 allting님과 같은 생각입니다.
    소스 관리의 목적에는 물론 그 히스토리를 보존하겠다는 의미도 있겠지만,
    공동작업시의 소스의 동기화도 무시할 수 없는 의미가 있기 때문이지요.

    아무래도 혼자서 커밋안하고 소스를 점유하고 있으면,
    동기화라는 측면에서 그만큼 리스크를 안고 가는 거라고 해석할 수도 있고,
    동료에게도 피해가 가게 마련입니다.

    실무적인 측면을 좀 더 강조해서 조심스레 반대의견을 적어 봅니다.

  4. 루돌님 안녕하세요.
    좋은 의견 감사합니다. 루돌님이 말씀하시는 것을 충분히 이해하지만 좀더 부연 설명을 하는 것이 좋겠네요. 루돌님은 어떤 SCM을 사용하시나요?
    좋은 토론거리를 찾은 것 같아서 좋습니다.

    1. 예를 들어서 버그ID 123번을 할당 받은 다음에 이를 수정하는데 10분이 걸렸으면 소스코드를 가져와서 10분동안 수정하고 확인 후 커밋을 하면 됩니다. 이런 경우는 커밋하는데 10분 밖에 걸리지 않습니다.

    2. 다른 경우 150번 버그를 수정하는데 여러 소스코드를 수정해야 하고 하루 종일 걸렸으면 이를 다 수정한 후데 커밋을 해야죠. 중간 중간에 백업을 목적으로 커밋을 하는 사람이 많은데 중간에 수정하다 만 소스는 커밋을 해도 공동작업에 별로 도움이 되지 않습니다.

    3. 그러면 이런 경우는 어떨가요? 하루에 5개의 버그를 수정해야 하는데, 이를 모두 수정한 다음에 한번에 커밋을 하는 경우는 바람직하지 않죠. 각 Revision은 하나의 Issue해결과 일치 시키는 것이 좋죠.

    2번의 경우 하나의 파일을 2명이 수정하는 경우가 생기는데 SVN은 자동으로 Merge를 해주고, Conflict가 일어날 경우 3-way merge툴을 이용하면 편리하게 Merge가 됩니다. 그리고 2번에서 백업용도로 커밋하는 경우 완전히 테스트되지 않은 코드가 커밋이 되어서 Broken Tree가 발생하면 여러사람에게 민폐를 끼칠 수도 있게 됩니다.
    과거 VSS를 사용할 때는 Lock정책을 이용했기 때문에 한사람이 코드를 통째로 수백개씩 Lock을 걸어서 Lock 풀어달라고 하기 일쑤였는데, SVN을 사용하면서 그 방식이 달라졌습니다.
    VSS또는 Lock방식의 소스코드관리리스템을 사용하고 있다면 루돌님이 말씀하신 문제가 발생합니다. 하지만 SVN은 내가 어떤 파일을 수정하고 있어도 다른 사람은 그 사실을 알 수가 없죠. 비로소 내가 Commit을 해야 알게 되죠.

    다음에는 VSS와 SVN을 비교하면서 소스코드관리 방법이 어떻게 달라졌는지 자세히 글을 쓰는 것도 좋겠네요.

  5. 자주하는 것이 나쁜 것이 아니라 의미없는 커밋이 잘못된 것 같습니다. Task가 작은 단위라도 하나 하나가 의미가 있다면 문제가 없다고 봅니다. 루돌님께서 말씀하신 소스의 동기화도 팀내부의 룰에 따라 의미있는 Task 단위로 운영된면 된다면 조금 늦게 공유되더라도 더 효율적이라고 생각합니다. 테스트 되지 않은 Task는 때로는 구현되지 못한 것 보다 더 못하고 비효율적인 것을 양산할때가 많은 것 같습니다. 이와 함께 CI를 운영한다면 더 효율적일 것이라 생각합니다.

  6. 정의의소님 안녕하세요.
    제가 답변을 다는 사이에 의견을 주셨네요. 제 답변 내용과 같은 내용도 포함되어 있네요. :)
    좋은 의견 감사합니다.

  7. 개발 완료 80%가 되면 일단 서버에 올립니다. 그전엔 귀찮아서 잘 않하게 되죠.

  8. 묘재님 안녕하세요.
    제가 묘재님 개발 환경을 정확하게 모르니 정확하게 의견을 달기가 어렵네요. ^^
    그렇게 하신다면 혹시 주로 혼자나 소수의 인원이 개발을 하시나요? SCM의 History는 알파이전에는 별 의미가 없으니 그렇게 하셔도 문제는 없지만 소스 공유라던지 안전한 보관 문제로 어떻게 하는 것이 가장 좋은지는 생각해 볼 문제 입니다.

  9. 이 글을 읽고 나니, 이클립스의 Mylyn 이란 프로젝트가 왜 생겼는지 알겠네요. Mylyn은 태스크 관리도 있지만 버전관리와도 통합이 되어 있어서 커밋시에 자동으로 관련된 버그나 태스크를 로그에 포함시켜 줍니다.

  10. yeoupooh님 안녕하세요.
    그렇습니다. 이러한 일련의 개발 프로세스를 좀더 편리하게 하기 위한 여러가지 프로젝트들이 있었고, 지금도 계속 만들어내고 있습니다.

  11. 지속적인 통합(CI)을 이용할 경우 잦은 커밋이 도움이 된다라고 알고 있지만 그렇다고 임시저장성까지 포함하지는 않다고 생각합니다. 오픈소스프로젝트의 소스저장소를 보면 정말 자세하게도 업무단위를 작은 조각으로 나누고 모든 커밋에 최소한 comment가 있더군요. 커멘트도 없이 무조건 저장용으로 쓰는것 과는 많은 차이가 있는 것 같습니다.
    그렇다고 커밋을 너무 미루면 소위 빅뱅통합의 악몽이 재현될 수도 있을 것 같고 커밋을 자주 할 수 있도록 업무단위를 나누는게 좋을 것 같은 생각이 듭니다.

  12. 챠우차우님 안녕하세요.
    저도 같은 의견입니다. 업무 단위는 최대 1,2일 이하로 나누어서 최소한 하루, 이틀에 끝낼 수 있도록 해야 하고, 버그를 수정하는 경우는 이보다 훨씬 작은 일이 될 수 있겠죠.
    여러가지 수정을 한 것을 미뤄놨다가 한꺼번에 커밋을 하는 것도 나쁜 방법이죠.
    단위의 업무가 끝날 때마다 해당 버그ID와 같이 커밋을 하는 것이 깔끔하죠.

  13. 제가 수행하는 프로젝트의 경우, 되도록 의미 있는 changeset 을 한꺼 번에 commit 하라는 규칙을 정해 놓고 있고, 적어도 컴파일이 되는지 확인한 후 commit 하라고 하고 있습니다.(솔직히 의미 있는 changeset 을 검증할 만한 방법이 없기 때문에 실효성 있는 규칙인지는 잘 모르겠습니다) 덧붙여 issue&defect management 와의 연동을 위해 로그 메시지에 ticket ID(또는 버그 ID)를 입력하는 경우에는 message 가 아주 짧더라도 정상 commit 되도록 pre-commit hook 을 사용하고 있습니다.

    SCM에서 commit 단위를 정하는 것은 쉽지 않은 일이라 생각합니다. 프로젝트에서 채용하고 있는 프로세스 및 S/W Infra와도 밀접한 관련이 있는 것 같구요.

    Ray님께서 그 동안 쓴 글들의 행간에 숨어 있는 가정을 생각하면 위 글이 잘 이해되지만 이 글만 읽으신 분들은 약간 오해할 수도 있을 것 같습니다.

  14. 김윤수님 안녕하세요.
    소프트웨어 개발에서 기계적으로 되는 부분은 그렇게 많지 않죠. 그럼에도 하지만 원칙과 규칙을 가지고 있는 것은 상당히 중요하죠. 의미있는 changeset을 한꺼번에 commit하라는 규칙은 원칙이지만 100% 지키는 것은 불가능하죠. 예외 상황은 얼마든지 만들어낼 수 있고 애매한 경우도 있죠.
    그리고 이것을 잘 지켰는지 검증해서 패널티를 준다는 것은 별로 좋은 방법이 아니죠.

    모든 글에는 잘 썼던 못 썼던 반대 의견이 있을 수도 있고 오해도 있을 수 있는데, 그리 나쁜 현상이라고 보지 않고 꺼려하지도 않습니다. 오히려 여러 사람의 의견을 들을 수 있는 좋은 기회라고 생각합니다.
    감사합니다.

  15. Blog Icon
    [1002]

    Trac 과 같은 이슈 트래커들의 경우 커밋 로그에 Trac 용 문법을 같이 지원하죠. 이를테면 커밋로그에 'fixed #432' 라 쓰면 Trac 의 timeline 에서 커밋로그 출력할 때 티켓 #432 번 하이퍼링크가 뜨죠. 이러한, 툴들에서 지원하는 편리함에 익숙해지면 위에서 언급하신 규칙과 아주 자연스럽게 맞아떨어집니다. 규칙도 간단하면서 같이 일하는사람이 편하죠.
    단, 매일매일 점진적 디자인개선(리팩토링)을 하고 싶을 경우 리팩토링 행위 자체가 버그는 아닌지라 고민을 하게 됩니다. (매번 리팩토링 작업을 티켓으로 올리기엔 여러 모로 문제가 있으므로) 그래서 '커밋된 코드들은 빌드와 테스트들을 깨뜨리지 않아야 한다' 같은 규칙 및 별도 커밋로그 룰을 추가해주어 해결하는게 좋습니다.

  16. [1002]님 안녕하세요.
    항상 원칙을 먼저 이해하고 응용을 하는 것이 중요합니다. 버그의 범위를 어떻게 보느냐는 의견이 서로 다르겠지만, 저는 소프트웨어 변경을 가져오는 모든 이슈를 버그로 간주합니다. 즉, 새로운 기능의 추가조차도 버그로 간주를 합니다. 그래서 리팩토링 같은 경우도 모두 이슈를 등록합니다.
    이슈를 등록하지 않은 경우는 알파 베이스라인을 설정하기 전의 개발 단계정도 입니다.
    위에서 언급한 '커밋된 코드들은 빌드와 테스트들을 깨뜨리지 않아야 한다'는 것은 소스코드 관리의 가장 중요한 기본원칙으로 누구나 지켜야 합니다. 원칙을 지키시는 개발 방법을 사용하고 계시는 군요.

  17. Blog Icon
    한인철

    좋은 지적입니다.
    무심한 행동을 돌아볼 수 있게 해주는 글이었습니다.
    커밋의 원칙을 따르되, 백업의 안전성 보장해주는 임시 리비전 같은 것이 지원되면 좋을 듯 하네요.
    아쉽게도 기존 도구가 지원하지 않으니, 외부 도구를 생각하게 됩니다.
    주기적으로 백업하는 아크로에디트의 김성동님의 ScheduleZipper, 파일을 저장할 때마다 백업하는 FileHamster 같은 도구가 있습니다.

  18. 한인철님 안녕하세요.
    반갑습니다. 로컬작업의 백업이나 History관리 방법은 많으니 적절히 선택하면 좋을 것 같습니다. GIT를 이용해서 자신의 PC에서는 별도로 버전관리를 하면서 Main SVN과 주기적으로 Merge하는 방법도 있고, SVN에 Working 브랜치를 만들어서 관리하는 회사도 있습니다. 개발팀의 규모와 프로젝트의 성격 등을 고려해서 방법을 선택하면 됩니다. 하지만 항상 소스코드 관리의 원칙은 명심을 해야 할 것 같습니다.

  19. Blog Icon
    한인철

    안녕하셔요?
    버전관리를 적용하려고 서브버전으로 공부하는 중입니다.
    작은 회사지만, 표준을 정하는 것이라 생각할 것이 많군요.
    여기에 올리는 것이 적합한지 모르겠지만, 몇 가지 조언을 부탁드립니다.

    1. 참조문서
    요구명세서, 회의록, 참고문서등 개발에 관련된 참조문서들을 저장소에 저장해야 할까요?
    체크아웃 한번으로 모든 자료를 얻을 수 있다는 장점은 충분히 이해합니다.
    하지만 단점도 있다고 생각됩니다.
    우선 체크아웃하는 크기 문제이고, 여러 브랜치로 작업하는 경우에는 불필요하게 중복해서 체크아웃해야 하는 것도 불만입니다.
    이런 문서를 어떻게 관리하는 것이 좋을까요?

    2. 중간파일
    라이브러리 같은 중간 파일을 효율적으로 이용하려면 어떻게 하는 것이 좋을까요?
    빌드시간 등의 문제로 인해, 소스에서 라이브러리를 빌드하는 것 보다, 빌드된 라이브러리를 이용하는 것이 효율적일 경우도 있을 겁니다.
    그렇다고, 소스와 결과물인 라이브러리를 모두 커밋하는 것은 좋은 방법이 아닐 것 같은데요.

    3. 릴리즈의 실행파일
    즉시 실행시켜 볼 수 있도록 릴리즈의 실행파일을 보관해 두려면, 어떤 방법이 있을까요?
    최종 결과물인 실행파일은 커밋할 필요가 없죠.
    그런데, 과거 릴리즈를 새로 빌드하는 것이 어려운 경우도 있을 겁니다.
    어렵더라도, 원칙대로 보관하지 않는 것이 좋을까요?
    버전관리와 별도로 보관하는 것이 좋을까요?

    결국, 무엇을 저장할 것인가, 효율적인 방법은 무엇인가 하는 문제입니다.
    비슷비슷하지만, 조금씩 관점이 달라서 나누어 문의드립니다.
    고견 부탁드립니다.
    감사합니다.

  20. 한인철님 안녕하세요.
    장문의 글을 올려주셨군요. ^^ 3가지 모두 제가 쓴 책인 "소프트웨어개발의 모든 것"에서 중요하게 설명한 내용들입니다. 정답을 말씀드리면 정확한 답은 상황을 봐야 합니다. 하지만 일반적인 범주라고 생각하면 Baseline에 들어가는 것이 무엇인가에 대한 질문입니다. 원칙을 설명드리면 Baseline에는 개발문서와 소스코드, 빌드 스크립트, 외부 라이브러리의 바이너리등이 들어갑니다. 좀더 자세한 것은 책을 참조하세요. 그리고 각 질문의 표준 답안은 다음과 같습니다.

    1. 참조문서 - 요구명세서은 필수적으로 Baseline에 포함이 됩니다. 회의록과 참조문서는 원칙은 Baseline에 포함이 안됩니다만 프로젝트에 따라서 포함을 시킬 수도 있습니다. 상황에 따라서 생각해 봐야 합니다.

    2. 중간파일 - *.obj, *.lib, *.o 파일들은 원칙적으로 SVN에 저장하지 않습니다. 빌드시간 절약이 그렇게 큰 장점은 아닙니다. 단 우리가 빌드해서 만들어 낼 수 없는 바이너리 파일은 저장을 해야 합니다.

    3. 릴리즈의 실행파일 - 과거 릴리즈를 새로 빌드하는 경우가 어렵다고 하는 말씀하시는 것을 보내 Baseline 설정을 제대로 하지 않으신 겁니다. Baseline만 제대로 설정하면 언제든지 바이너리를 만들어 낼 수 있으므로 바이너리는 보관하지 않습니다. 최근 바이너리들은 별도의 서버에 얼마동안 보관해도 됩니다.

    한인철님의 상황을 정확하게 모르고 Detail한 답을 드리는 것으 자칫 위험할 수 있지만 그렇다고 무조건 그때그때 다르다라고 말하는 것은 또 아닌 것 같아서 일반적인 경우와 원칙 위주로 말씀드렸습니다. 좀더 상황에 맞는 답을 듣고 싶으시면 Email을 주시거나 전화(019-313-3929)로 연락을 주셔도 됩니다. 감사합니다.

  21. Blog Icon
    Wisedog

    안녕하세요, 전규현님.
    Commit 관련해서 질문이 있습니다. Commit 할때 반드시 이슈 ID를 적으라고 했는데, 만약 어떤 어플리케이션을 새로 만드는 과정이라면 어떤식으로 Commit 메시지를 적어야할까요? 버그가 생기면야 이슈ID를 적는데, 새로 만드는 과정이면? 어느날 갑자기 1.0이 됐을때 한 번 커밋하는것은 그것대로 문제가 아닐까요? 궁금해서 물어봅니다. 답변 부탁드리겠습니다~ : )

  22. 안녕하세요. wisedog님
    신제품을 개발하는 중이라면 이슈관리시스템에 개발할 내용을 적지는 않습니다. 따라서 이슈가 없죠. 그럴 때는 이슈ID를 적지 않아도 됩니다. 어떤 회사는 시제품 개발때도 대표 이슈를 등록해서 그 ID를 적는 경우도 있습니다. 어떻게 하셔도 상관은 없습니다.

  23. Blog Icon
    Winetalks

    한가지 궁금점이 있습니다.
    커밋 전에 Peer Review를 한다고 하셨는데,
    경험 상 커밋 전에 동료를 따로 불러서 리뷰하기는 어려워 보이는데..
    혹시 사용하시는 방법 등이 있으신가요?

    제 경우 커밋 후에 시스템이 이를 알리면 시니어 멤버가 리뷰 하는 형태였거든요.
    물론 이것이 올바른 방법은 아닌 것은 알지만
    커밋 전에 시니어 멤버를 따로 부르는 것도 어려워 보여서요.

    좋은 방법이 있을 지 문의 드려봅니다 ^^

  24. 안녕하세요. Winetalks님

    커밋후에 리뷰를 하는 것은 완전하지 않은 소스코드를 등록하는 것이므로 원칙에서는 어긋납니다.
    커밋 전 간단히 리뷰하는 방법은 Peer desk check이라고 합니다. 그리고 꼭 시니어 멤버가 리뷰를 할 필요는 없습니다.
    이를 도와주는 시스템이 있어서 좀더 편리하게 리뷰할 수는 있지만 꼭 시스템이 필요한 것은 아닙니다.
    SCM에 따라서 임시로 Commit을 해서 리뷰후 Commit을 확정하는 시스템도 있습니다.
    좀더 확대를 하면 분산SCM에서는 자신의 Repository에는 자유롭게 Commit을 하고 중앙 Repository와 Sync할 때 리뷰하는 방법도 있습니다.
    결론은 시스템이 문제가 아니고 꼭 시니어 멤버가 아니더라도 리뷰를 적절하게 하는 것이 중요합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바