나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다.
| "소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다. |
그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다.
대부분 아래와 같은 답변들이 돌아옵니다.
- 내 PC에 소스코드가 저장되어 있습니다.
- 아직 정리가 안되서 소스코드관리시스템에 등록하지 않았습니다.
- 빌드는 IDE(Eclipse 등)에서 해야 합니다.
- 빌드하기 위해서는 이런 저런 라이브러를 알아서 직접 설치해야 합니다.
- 아참, 설정을 이렇게 바꿔야 하는데 깜빡했습니다.
- 지금 내가 소스코드를 고치고 있어서 공유가 어렵습니다.
이런 얘기가 진행되는 동안에 일은 정상적으로 진행이 되지 못하고 여러 번 만나서 대화로 소스코드 공유 문제를 해결해나가야 합니다.
혼자서 또는 개발자들끼리 익숙해져서 나름대로 방식으로 소스코드를 관리하면서 스스로 아무 문제가 없다고 생각하고 있는 개발자들은 냄비 안에서 물이 점점 뜨거워져서 죽는 개구리처럼 소스코드관리 문제가 점점 커져서 문제가 얼마나 심각한지 인식하고 있지 못하고 있는 겁니다. 이는 기본 중에 기본으로 자꾸 소스코드 관리 문제를 가지고 얘기를 하면 민망하고 한심하기도 합니다.
소스코드를 꽉 쥐고 요청하는 사람들에게 '모이'주듯이 하나씩 던져 주는 개발자들은 이로 인해서 얼마나 많은 자신의 시간을 낭비하고 있고 정작 자신이 제대로 개발할 시간은 모자라고 회사에도 손해를 끼치며 자신의 발전도 가로막는다는 것을 알아야 합니다.
정상적인 경우는 다음과 같습니다.
| 개발자가 1명이든 100명이든 1000명이든 상관없이 모든 소스코드는 당연히 소스코드관리시스템에 등록이 되어 있어야 합니다. 구차하게 이거 저거 물어보지 않아도 소스코드가 저장된 경로만 알면 누가나 소스코드를 Check out해서 클릭 몇 번이면 Build Script를 찾아내서 즉시 빌드를 할 수 있어야 합니다. 당연히 컴파일러 등의 빌드 환경은 설치가 되어 있어야죠. 여러명이 동시에 소스코드를 마구 고쳐도 전혀 걱정할 필요가 없어야 합니다. |
이때 구차하게 이거 저거 물어 봐야 빌드가 되고 IDE를 실행 해야 하고, 빌드 중간에 명령어를 입력해야 하는 등의 바로 알기 어려운 행위들을 해야 하면 안됩니다.
이 정도는 되어 있어야 Daily Build가 가능해지고 프로젝트 내내 소스코드 관리 비용을 최소화 할 수 있습니다.
이 정도는 되어 있어야 엄청 복잡한 소스코드 상황을 깔끔하게 관리할 수 있습니다.
이 정도는 되어 있어야 내가 휴가를 가도 아무나 빌드를 할 수 있습니다.
이 정도는 되어 있어야 개발자들이 빌드를 하지 않고 빌드 담당자에게 빌드를 맡길 수 있습니다.
이 정도는 되어 있어야 누구와도 심지어는 외부인과도 협업을 할 때 말 한마디면 소스코드 공유 준비는 끝납니다.
이 정도는 되어 있어야 개발자는 진짜 개발에 집중할 수 있습니다.
이게 뭐 큰 일이냐라고 생각할지 모르지만 이렇게 생각하는 개발자는 위에서 얘기한 기초 중의 기초가 안되어 있다고 생각하면 됩니다.
소스코드 관리는 워낙 기초이기 때문에 누구나 제대로 방법만 익히면 제대로 수행하는데 오래 걸릴 일도 아닙니다. 똑똑한 개발자라면 일주일이면 방법을 다 터득합니다. 분석, 설계 작업이 방법을 제대로 익히고도 제대로 하는데 수년이 걸리는 것과는 안전히 딴판입니다. 그럼에도 아직도 많은 개발자들이 소스코드 관리를 제대로 하고 있지 못하거나 제대로 하려고 흉내는 내는데 엉뚱한 곳에서 헤매는 경우가 많습니다. 원리는 매우 간단한데 말입니다.
소프트웨어 개발이라는 것이 협업이라는 것을 깨달으면 됩니다. 혼자서 개발하더라도 협업과 똑같습니다. 그렇게 해야 더 혼자 개발하더라도 더 빨리 개발할 수 있고 여럿이 개발할 때는 더욱 더 중요합니다.
소스코드관리시스템을 쓰기는 하는데 어중간하게 흉내만 내고 있다고 생각한다면 한번 확실하게 제대로 배워 놓을 필요가 있습니다. 그렇지 않으면 평생 기초 중에 기초에 문제거리를 안고 가는 겁니다.
당연한 얘기를 글로써 상기 시킨다는 현실이 참 슬프네요
답글삭제저도 한번은 그렇게 큰 사이트가 아닌데 소스만 400MB
짜리를 본적이 있었습니다. portal1,portal2,real-portal.....
같은 디렉토리가 여러개 있는데 마치 닭 갈비집 이름 처럼
"원조집","진짜원조집","진짜진짜원조집" 같은 느낌이였습니다.
시스템은 점점더 고도화되고 복잡한 기술을 사용하는데
개발 환경과 현실은 너무 구닥다리를 따르고 있습니다.
항상 좋은 글 감사합니다^^ 개발자로써 구구절절 옳은 말씀만 올려주시지만 현실과의 괴리감이 드는 건 어쩔수가 없네요. 형상관리를 하고 있지만 어느 순간에서부턴가 각 개발자끼리 마치 개별 브랜치를 가진 듯이 다른 방향으로 진행되고 있는 상황을 자주 접하게 됩니다. 물론 상황에 따라 머징이 되긴 하지만 주기적으로 이루어지는 머징도 아니고 필요에 따라, 상황에 따라 이루어지다보니 커뮤니케이션이 소홀해 지는 경우 각자의 프로젝트는 결국 다른 산으로 가고 있더군요.
답글삭제다시 한번 좋은 글로 일깨워주심에 감사드립니다~^^
안녕하세요. 옥수석님
답글삭제당연한 기초가 현실과 괴리가 있는 현실이 안타깝습니다. 대학생들을 갈쳐도 몇주면 익숙해지는 것을 십수년 경력의 개발자들도 제대로 하지 못하는 것이 현실이기는 하죠.
브랜치와 머지는 보통 개발자가 마음대로 하면 안됩니다. 이에 대한 회사의 정책이 있고 개발자는 이를 따라야죠. 일반적으로 브랜치는 승인하에서 합니다. 머지계획도 미리 작성해야 하고요. 번거로우라고 이렇게 하는 것이 아니고 이렇게 하는 것이 가장 효율적이기 때문입니다.
또 머지는 3-way머지를 해야 합니다. 보통 2-way머지툴을 가지고 머지를 하는데 이는 수십배 더 시간이 많이 들고 잘못 머지가 될 가능성도 대단히 높습니다.
이렇게 해 놓고 개발자들이 계획에 따라서 자유롭게 개발하는 것이 좋지, 대충 해놓고 뭔가 고칠려고 할 때마다 소스코드 공유/통합을 신경써야 한다면 프로젝트 기간 내내 소스관리 비용이 몇백배로 더 많이 들게 됩니다.
산으로 가고 있다면 다시 땅으로 끌어 내려야 겠네요. ^^ 필요하면 제가 세미나 등을 통해서 개발자와 경영진들을 설득시키고 교육도 시켜주곤 합니다.
Beyond J2EE님 안녕하세요.
답글삭제정말 적절한 비유입니다.
이런 소스코드는 감당하지도 못합니다. 소스코드관리시스템의 브랜치와 머지 기능을 충분히 활용하고 개발 프로세스 상에서 이를 잘 통제하면 부처님 손바닥안의 소스코드죠.
언제 다 같이 모아 놓고 세미나를 한번 하고 싶은 마음은 굴뚝 같은데 여유가 안생기네요. - -;
구차니에서 날탱구리로 블로그 및 필명을 변경했답니다.
답글삭제음.. 개인적인 질문인데, svn에서 프로젝트를 어떻게 관리 하시나요?
예를 들어 리눅스 박스의 경우 uboot / linux kernel / 자체 sw 가 있는데
세가지를 svn repository 하나에 넣으면 revision이 같이 올라가게 되고,
그렇다고 해서 분리를 해서 개별 리파지터리를 만들면 개별 주소를 기억을 하거나
별도로 관리하는 방법이 필요할 것 같더라구요.
늘 잘 안되는 것들이 포스팅이 되어서 마음이 아팠었는데
답글삭제오늘 포스팅에 대해서는 자신감이 생기네요..
svn을 사용하고 있고 capistrano를 통해서 각 환경(개발, 백업, 리얼)으로 소스를 deploy 할수 있고 이슈트래킹의 부가기능에 svn history를 연결해놔서 누가 언제 어떻게 고쳤는지 웹상으로 확인할수 있습니다. ^^ 이정도면 자신감을 가져도 괜찮겠죠?
Repository를 어떻게 나누고 각 Repository안의 프로젝트 별 디렉터리를 어떻게 구성하는지는 회사마다 다릅니다.
답글삭제일단 revision number는 신경쓰지 않는 것이 좋습니다. revision number에 의미를 부여해서 사용하면 나중에 문제가 발생합니다.
Repository구분은 각 프로젝트가 단 0.1%라도 서로 연관성이 있는지를 봐야 합니다. 공유되는 소스코드가 있는지? 나중에 쓰고 버릴 소스코드인지? 백업은 공통으로 해야 하는지? 이렇게 생각을 해보고 연관이 있으면 한 Repository에 넣는 것이 좋습니다.
Repository안의 디렉터리 구조는 각 프로젝트가 완전히 자동으로 Build가 가능하도록 구성을 해야 하는데 공통모듈이 잘 관리되고 있는 회사가 아니라면 이 말이 무슨 뜻인지 잘 모를겁니다. 하지만 공통모듈이 있다면 디렉터리를 어떻게 구성하냐에 따라서 빌드가 달라집니다.
이렇게 여러가지를 고려하여 처음부터 잘 정해 놓고 시작해야지 나중에 바꾸려고 하면 큰 문제입니다.
리파지터리 주소는 프로젝트 check out할 때 처음에 한번만 입력하면 되는 것이기 때문에 기억하는 것은 문제가 알될 것 같습니다.
안녕하세요. zeous님
답글삭제일단 SVN과 이슈트래킹(아마 Trac)을 연동해서 잘 쓰고 계시나보네요. 평균 이상은 되시네요. ^^
항상 안되는 것만 있으면 빵점이게요? 그럴리가 있겠습니까? 항상 포스트를 보면서 조금씩 고쳐나가자는 의미입니다.
SVN을 잘 쓰시는 것 같기는 한데 Branch, Merge는 어떻게 하는지 궁금하네요. 사실 SVN의 핵심은 Merge거든요. 나중에 Git나 Mercurial들의 분산소스코드관리시스템을 쓰더라도 Merge를 제대로 하지 못하면 반쪽짜리가 됩니다. 그래서 3-Way Merge를 능수능란하게 다룰 수 있어야 합니다. 어떠신가요?
branch를 전혀 쓰지 않는 것은 아닙니다.
답글삭제이번에도 새로운 프로젝트를 시작하는데 기존 소스의 서비스도 유지하면서 거기에서 파생되어서 추가적인 작업을 하고 완성후에 합치기 위해서 branch를 생성해서 작업을 하고 있습니다만은
branch를 생성하고 나서 마지막에 합칠때 실수하지 않을까 (자동으로 하게 되면 가끔 한쪽을 날려먹는 경우가 있어서 안볼수는 없더라구요)
챙겨야 할것들이 있기에 이왕이면 안만들어졌으면 하는 바램은 있습니다 ^^
SVN을 쓰는 곳, 다수가 해당 소스를 Root에 그냥 올려버리는 곳을 많이 봤습니다.
답글삭제Branch나 Tags, Merge와 같은 기능은 꺼버리고 사용하는 것과 마찬가지 인데도 불구하고 말입니다.
초반엔 인식을 심어주려고 교육도 해보고 노력했으나..역시나 이쪽 부분엔 관심 없어 하더군요.
무술고수가 항상 강조하는 기본기 "정권찌르기"를 거스르고 현란한 기술만 쓰고자 하는 사람들의 심리때문일까요? 아니면 남들이 모르니 나도 몰라도 된다..라는 심리때문일까요
가장 기본이 되는 소스코드 관리 정말 중요하죠~ 말이 필요없다고 생각합니다.
하나를 보면 열을 안다고.. 이런 기본을 중요시하는 기본기가 탄탄한 조직은 정말 안정적인 조직이라고 생각합니다. ( 비단 소스코드관리뿐만이 아닌...:)
moova님 안녕하세요.
답글삭제제가 좀 바빴네요. - -;
소스코드시스템을 쓰는 이유가 소스코드를 잃어버릴까봐 백업용도로만 쓰는 곳이 의외로 많습니다.
빠뀌지 않는 이유는
1. 막연히 새로운 것을 배우는 것이 귀찮아서
2. 나아진 다는 확신이 없어서
3. 현재 방법에 익숙해져서
4. 가르쳐 주는 사람에 대한 믿음이 부족해서
5. 소스코드를 감추려고
등등 다양합니다.
산넘어 산입니다.
그래서 카리스마 있는 사람의 도움을 받아서 설득을 하면서 강제화하는 것이 가장 좋은 방법입니다.
소스코드는 어디 있나요? 에서 트랙백 합니다. Development Team Building Consulting, 거창해 보이지만 그냥 IT 관련 개발 인력들로 부서를 만들어야 하거나 어떻게든 제대로된 유지보수 부서를 꾸려야 하는 곳에 도움을 주는 일입니다. 원문의 내용에 심히 공감하게 됩니다. 1년 반동안 다섯 Team을 컨설팅을 했었고, 두 Team은 내부적인 사정으로 포기를 했고 두 Team은 나름의 결과를 내서 회사 운영 System과 잘 ...
답글삭제소스코드는 어디 있나요? http://bit.ly/ao8197
답글삭제소스코드는 어디 있나요?. SCM 에 저장된 소스를 one-click build 는 꼭 필요하다에 한 표. 이왕이면 CI 에 daily build 의 결과물까지 web 에 바로 올라가고, 누구든 손쉽게 download 해볼 수 있으면 더 좋구… CI 에 더 나가서
답글삭제어느분이 지적하신대로 저 역시 Branch, Tags, Merge 기능을 사용해보질 못했네요 -_-;
답글삭제현재 SVN의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜치 요구는 항상 생깁니다.
답글삭제서브버전을 이용한 실용적인 버전 관리 저자 Mike Mason 역자 류광 출판사 정보문화사 오픈 소스 버전 관리 시스템인 서브버전(Subversion)의 효과적인 활용을 담고 있는『서브버전을 이용한 실용적인 버전 관리』. 이 책에서는 버전 관리 시스템을 최대한 활용하기 위한 여러 기본적인 조리 법들을 제시하고 있다. 《서브버전을 이용한 실용적인 버전 .. 버전 관리가 뭔지도 모르던 그 때 그 시절에는 그저 파일에 숫자나, 연월일을 붙여가며 해당 파일..
답글삭제