Beyond J2EE님 안녕하세요.

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

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

안녕하세요. 옥수석님

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

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

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

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

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

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

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

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

하늘이아빠님 안녕하세요.
장문의 댓글을 남기셨네요.^^
결국은 "조삼모사"죠. 그런데, 아침에 4개 먹기를 원하는 개발자나 경영자가 너무 많죠. 아침에 4개 먹으면 저녁때 3개가 아니고 1개 먹기도 어려운 것이 현실입니다. 아침에 3개만 먹으면 저녁에 4개 아니고 7,8개를 먹을 수도 있습니다.

두렁청해님 안녕하세요.
고객사별로 소스가 따로 노는 회사는 어느 순간 성장의 한계에 부딪히게 됩니다. 그 순간이 오면 이미 되돌릴 수 없는 상태가 된 겁니다.

구차니님 안녕하세요.
범용함수란 그리 좋은 선택이 아니죠. 함수는 한가지 일만 하면서 간결하게 작성되어야 하죠. 그리고 리팩토링 시기를 놓치면 점점 혼란스러워지죠. 뭐든지 제때에 해야죠.

안녕하세요. 질문도 답도 댓글에 다 포함되어 있군요.
개발자 중에는 C&P의 폐해를 모르고 마구 해대는 사람들도 많습니다. 이미 많은 고민을 하고 계시네요.

kkommy님 안녕하세요. 대박씩이나 ^^...

돌이아빠님 안녕하세요.
돌이아빠님 블로그는 항상 즐겨 보고 있습니다. 의견 감사합니다.

위즈님 안녕하세요.
반갑습니다. 좋은 의견 감사합니다.

안녕하세요. 우울한딱따구리님
의견 감사합니다. 원래 글이라는 것이 한쪽으로 치울칠 수 밖에 없죠. 딱 중간을 지키는 것은 또 무미건조할 것이고. ^^ 저는 컨설팅을 하면서 겪는 경험들을 강도있게 표현하려고 하고 있습니다. 따라서 이런 종류의 주제를 다룰 때는 이런 논조를 유지하려고 합니다.
그리고 말씀하시는 의도도 충분히 알고 있습니다. 이 정도의 글이 아니면 그렇게 코드만을 중요시 하는 개발자들이 생각을 조금도 움직일 수 없겠죠.

툴이 이슈는 아니고 마인드의 문제를 지적한 것입니다. 개발에 있어서 코딩의 비중이 그렇게 높지 않고, 소스코드는 중요하지만, 소스코드 자체가 개발 결과물을 대표하지 않는 다는 것입니다. 소스코드를 누가 본다고 해서 모든 것을 잃는 것이 아니라는 뜻이기도 합니다. 버전컨트롤 시스템을 쓰는 회사에는 소스코드를 숨길 수는 없지만, 그렇다고 개발자들간에 소스코드가 잘 공유된다고 볼 수도 없습니다. 결국 마이드가 중요하죠.

개인적인 느낌은, 간단한 룰 및 툴의 도입으로 해결가능한 문제가 '회사 개발자 전체의 마인드 문제다' 로 지적되는 건 아닌가 해서 그럽니다. 생각보다 사람들은 자신에의 문제상황이 실제로 문제상황인지를 인지하는데 시간이 걸립니다.

자신의 버그를 자기 눈으로 찾는 것보다 다른 사람이 외부의 시각에서 발견하는 것이 더 빨리 보이는 경우는 많습니다. 그건 다른 사람이 더 똑똑해서가 아닙니다. 다른 관점으로 바라보는 것이 (혹은 내부 이해관계에 얽매이지 않은 시각으로 바라볼 수 있는 것이) 더 빨리 볼 수 있는 문제들이여서 그런 것 뿐일지도 모릅니다.

여담으로 농담 섞어 이야기하면.. 저라면 해당 회사에서 소스를 훔칠까 스펙 & 디자인 문서 훔칠까 하면 소스를 훔칠겁니다. 이유는, 소스가 스펙 & 디자인 문서보다는 거짓말을 덜하기 때문입니다.

좋은 의견 감사드립니다.
저도 소스코드를 훔칠 것 같네요. ^^ 그 이유는 대부분의 회사가 스펙이나 설계문서는 잘 작성되어 있지 않지만, 적어도 소스코드는 진짜 동작하거든요. 그리고 내가 소스코드를 잘 알고 있는 상황에서 소스코드는 상당한 가치가 있지만, 덜렁 소스코드를 남을 주면 소스코드 분석하기도 쉽지는 않습니다.

bluecodea님 의견 감사합니다.
맞습니다. 소스코드가 오픈되면 공격을 당할 수도 있습니다. 물론 Reverse engineering을 하면 왠만한 것은 알아낼 수 있지만, 소스코드가 있다면 훨씬 쉽게 공격당할 수 있죠. 물론 좋은 보안 솔루션은 소스코드가 공개되도 안전한 솔루션이겠지만, 그렇지 못한 경우도 있고, 허술하게 짜여진 보안 관련 코드들이 있으므로 소스코드를 안전하게 지키는 것이 가장 쉬운 수단이죠. 사실 많은 개발자들이 허술하게 코드를 작성해도 별문제가 안되는 이유는 공격자들이 별로 관심이 없기 때문입니다. ^^ 윈도우즈가 그렇게 많은 보안 취약점이 발견되는 이유는 바로 많은 사람들이 관심을 가지고 있기 때문입니다.
감사합니다.

머샤머샤님 안녕하세요.
소스코드관리는 매우 중요하고 소프트웨어 개발의 기본중의 기본이죠. 소스코드관리시스템을 만드시니까 당연히 잘 아시겠죠. ^^ 실루엣은 과거에 컨설팅을 했던 고객사를 통해서 들어본 적이 있습니다. 고객사가 어딘지는 짐작하실 겁니다. 앞으로 좋은 의견 많이 교환하길 기대합니다.

miing님 안녕하세요.
누구나 다 사연이 있습니다. 주변이 환경이 열심히 일하려는 개발자들은 뒷받침 못해주는 것이 첫번째 이유입니다. 이런 환경에서 오래 일하면 발전하기 어렵죠.

안녕하세요. 개발자님

이런 글들은 대부분 익명으로 올라오더군요.
저를 한번도 뵌적이 없는 분 같은데(정체를 알 수 없으니)... 절 평가하네요.

저는 소프트웨어 업계에서 17년 개발자로서 일을 했고, 한글과컴퓨터, 안철수연구소 등에서 일해왔습니다. 그리고 제 글들은 이론적이지 않습니다. Global standard에 가까운 글들을 쓰고 있습니다.

제 글들은 소프트웨어 초보자들은 이해하기 어렵습니다. 또한 고참이라고 하더라도 오랫동안 주먹구구 방식으로 개발하던 개발자들도 이해하기 어렵습니다.

또한 국내 소프트웨어 개발자나 회사나 얼마나 열악한 환경에서 주먹구구식으로 개발을 하고 있는지, 또 얼마나 미래가 없는지 잘 알고 있습니다. 또한 엔진이라고 부르는 것들, 솔루션이라고 하는 것들이 얼마나 제 값어치를 못하고 있는 것들인지도 잘알고 있습니다. 물론 개발자들이 열심히는 하지만 그것만으로는 부족하죠. 그래서 저는 컨설턴트로서 개발자를 교육하여 역량을 향상시키고 회사를 개혁시키 일을 하고 있습니다.

배우지 않으려고 하는 사람에게 도움을 줄 수는 없습니다.

물론 제글과 다른 의견들도 있을 수 있고 언제든지 토론을 환영합니다. 가능하면 토론이 될만한 의견을 올려주면 좋겠네요.