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

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

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

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

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

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

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

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

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

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

감사합니다.

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

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

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

루돌님 안녕하세요.
좋은 의견 감사합니다. 루돌님이 말씀하시는 것을 충분히 이해하지만 좀더 부연 설명을 하는 것이 좋겠네요. 루돌님은 어떤 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을 비교하면서 소스코드관리 방법이 어떻게 달라졌는지 자세히 글을 쓰는 것도 좋겠네요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

안녕하세요. Winetalks님

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