왜 하나만 써야 하는가?
2011/08/13 11:32 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 2008년에 작성한 소프트웨어 회사의 개발 역량 평가 표에는 20점 중 2점을 차지하고 있다.
2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표
종종 "여러개를 쓰면 어떤가?"하는 궁금증이 있어서 그 이유를 설명하고자 하다.
회사가 아무리 크더라도 소스코드관리시스템은 하나만 쓰는 것이 좋다. 한 종류의 시스템을 여러개 설치에서 쓰는 것도 좋지 않다. 또한 특별한 이슈가 없는 경우라면 하나의 Repository에 소스코드를 관리하는 것이 좋다.
여러 시스템을 쓰는 경우는 대부분 팀마다 각자 취향에 따라서 VSS도 쓰고 SVN도 쓰고 Git도 쓰는 경우이다. 이러한 경우 각자 핑계들이 있다. Visual Studio에 최적화된 VSS를 써야 한다는 둥, 오픈소스를 이용하기 때문에 Git가 좋다는 둥의 주장을 하다가 각 팀에서 알아서 쓰기로 결정을 종종 하게 된다.
팀마다 다른 시스템을 쓰게 되면 여러가지 문제가 발생한다.
첫째, 공통 모듈 관리가 전혀 안되서 공통 모듈을 서로 복사해서 쓰기도 하고 비슷한 모듈을 따로 개발하기도 한다. 공통모듈이 없는 SW회사는 거의 없다. 관리를 안할 뿐이다. 이것이 얼마나 큰 문제가 되냐고 생각하는 사람들도 있다. 하지만 제품이 많아지고 고객이 많아지면 이렇게 복사된 공통모듈로 개발은 엉망진창이 된다. 유지보수 비용이 몇배로 들게 된다.
둘째, 개발자는 각 팀마다 스위치가 자유로워야 하는데 서로 다른 시스템을 배우기 위해서 시간이 들어간다. 기본 기능은 배우는데 얼마 안걸리지만 완전히 손에 익어서 능수능란하게 쓰기에는 시간이 걸리는데 괜히 쓰지않아도 될 시간이 들게 된다.
그외에 전사적으로 관리가 잘 안되서 백업도 비용이 더 많이 들고 여러가지 문제가 발생한다. 주먹구구 식으로 작은 규모로 대충 개발할 때 문제가 눈에 안 띨분이지 나중에 댓가를 치르게 된다. 나중에 문제가 발생한 후에 통합은 거의 불가능하다 처음부터 하나를 써야 한다.
버그관리시스템은 개발자들만 쓰는 것이 아니다. CEO를 비롯해서 전직원 모두가 쓰는 시스템이다.
그런데 각 팀마다 서로 다른 시스템을 쓰고 있는 경우라면 십중팔구 개발자나 QA팀만 쓰고 있는 경우이다. 전사적으로 통일된 결정이 없었고 회사의 지원이 없어서 개발자들이 팀내에서 알아서 결정해서 쓰는 경우가 많다. 이는 반쪽만 사용하고 있는 경우이다.
버그관리시스템은 개발을 포함해서 회사의 거의 모든 이슈가 관리되는 곳이다. 기껏해야 회계나 HR이슈들이 빠질 뿐이다. 그런데 팀마다 다른 시스템을 쓰고 있다면 이슈가 통합되서 관리도 안되고 통계도 안나오고 개발팀 바깥의 부서에서는 여러 시스템을 모두 써야 하는 불편함도 있다.
또한 여러 시스템을 다 배워야 하기 때문에 이만저만 불편한 것이 아니다. 이또한 나중에 통합은 어려우므로 처음에 하나로 잘 결정해야 한다.
종종 SVN을 쓰면서도 출장을 자주 나가서 출장지에서 직접 개발을 해야 하는 경우들도 있다. 이런 경우 SVN과 Git를 연동해서 쓰면 유용하다.
SVN만 사용하면 출장을 나가서 1주일동안 여러가지 기능과 버그를 수정했을 경우 복귀후 Commit을 하게 되면 그동안 수정한 내용이 한번에 커밋이 되서 관리가 어려워진다.
이때 SVN Repository를 Git에 담아서 출장을 가서 개발할 때마다 여러번 Commit을 하면 복귀후 SVN과 다시 통합을 하면 그 History가 고스란히 합쳐진다.
이런 경우 처럼 Git를 보조적으로 쓰는 것도 좋다.
나는 보통의 SW회사에서 소스코드관리시스템과 버그관리시스템 2개면 충분하다고 주장한다. 사실 왠만큼 회사가 커지기 전까지는 이 두가지면 충분하다.
결재가 필요하기 때문에 전자결재를 위한 그룹웨어를 도입하고 싶어하기도 한다. 하지만 소프트웨어 회사에서 그룹웨어는 그렇게 효율적이지 않다. 전자결재는 SW개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.
그 외에 작업관리, 고객요청관리, 테스트 관리등 여러가지 관리의 필요성을 느끼게 된다.
일단 이 두개만 가지고 쓸 수 있는 한 최대한 써보기를 권한다. 그러면 의외로 거의 모든 것을 다 커버하게 된다는 것을 알게 될 것이다.
그후에 회사의 규모가 정말로 커져서 인원이 몇백명이 되고 좀더 관리를 잘 하고 싶으면 테스트관리나 서비스데스크등 개발자들에게는 부담이 안되지만 관리에 도움이 되는 시스템을 우선적으로 도입하면 좋다.
나중에 통합은 어렵다. 이미 여러개의 시스템을 쓰고 있다면 합칠 수 있다면 지금이라도 합치는 것이 좋다. 나중에는 늦는다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by nerovivo
RSS Feed
이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 2008년에 작성한 소프트웨어 회사의 개발 역량 평가 표에는 20점 중 2점을 차지하고 있다.
2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표
종종 "여러개를 쓰면 어떤가?"하는 궁금증이 있어서 그 이유를 설명하고자 하다.
| 소스코드관리시스템을 여러개 쓰고 있다면? |
회사가 아무리 크더라도 소스코드관리시스템은 하나만 쓰는 것이 좋다. 한 종류의 시스템을 여러개 설치에서 쓰는 것도 좋지 않다. 또한 특별한 이슈가 없는 경우라면 하나의 Repository에 소스코드를 관리하는 것이 좋다.
여러 시스템을 쓰는 경우는 대부분 팀마다 각자 취향에 따라서 VSS도 쓰고 SVN도 쓰고 Git도 쓰는 경우이다. 이러한 경우 각자 핑계들이 있다. Visual Studio에 최적화된 VSS를 써야 한다는 둥, 오픈소스를 이용하기 때문에 Git가 좋다는 둥의 주장을 하다가 각 팀에서 알아서 쓰기로 결정을 종종 하게 된다.
팀마다 다른 시스템을 쓰게 되면 여러가지 문제가 발생한다.
첫째, 공통 모듈 관리가 전혀 안되서 공통 모듈을 서로 복사해서 쓰기도 하고 비슷한 모듈을 따로 개발하기도 한다. 공통모듈이 없는 SW회사는 거의 없다. 관리를 안할 뿐이다. 이것이 얼마나 큰 문제가 되냐고 생각하는 사람들도 있다. 하지만 제품이 많아지고 고객이 많아지면 이렇게 복사된 공통모듈로 개발은 엉망진창이 된다. 유지보수 비용이 몇배로 들게 된다.
둘째, 개발자는 각 팀마다 스위치가 자유로워야 하는데 서로 다른 시스템을 배우기 위해서 시간이 들어간다. 기본 기능은 배우는데 얼마 안걸리지만 완전히 손에 익어서 능수능란하게 쓰기에는 시간이 걸리는데 괜히 쓰지않아도 될 시간이 들게 된다.
그외에 전사적으로 관리가 잘 안되서 백업도 비용이 더 많이 들고 여러가지 문제가 발생한다. 주먹구구 식으로 작은 규모로 대충 개발할 때 문제가 눈에 안 띨분이지 나중에 댓가를 치르게 된다. 나중에 문제가 발생한 후에 통합은 거의 불가능하다 처음부터 하나를 써야 한다.
| 버그관리시스템을 여러개 쓰고 있다면? |
버그관리시스템은 개발자들만 쓰는 것이 아니다. CEO를 비롯해서 전직원 모두가 쓰는 시스템이다.
그런데 각 팀마다 서로 다른 시스템을 쓰고 있는 경우라면 십중팔구 개발자나 QA팀만 쓰고 있는 경우이다. 전사적으로 통일된 결정이 없었고 회사의 지원이 없어서 개발자들이 팀내에서 알아서 결정해서 쓰는 경우가 많다. 이는 반쪽만 사용하고 있는 경우이다.
버그관리시스템은 개발을 포함해서 회사의 거의 모든 이슈가 관리되는 곳이다. 기껏해야 회계나 HR이슈들이 빠질 뿐이다. 그런데 팀마다 다른 시스템을 쓰고 있다면 이슈가 통합되서 관리도 안되고 통계도 안나오고 개발팀 바깥의 부서에서는 여러 시스템을 모두 써야 하는 불편함도 있다.
또한 여러 시스템을 다 배워야 하기 때문에 이만저만 불편한 것이 아니다. 이또한 나중에 통합은 어려우므로 처음에 하나로 잘 결정해야 한다.
| SVN과 Git를 같이 쓰는 경우는? |
종종 SVN을 쓰면서도 출장을 자주 나가서 출장지에서 직접 개발을 해야 하는 경우들도 있다. 이런 경우 SVN과 Git를 연동해서 쓰면 유용하다.
SVN만 사용하면 출장을 나가서 1주일동안 여러가지 기능과 버그를 수정했을 경우 복귀후 Commit을 하게 되면 그동안 수정한 내용이 한번에 커밋이 되서 관리가 어려워진다.
이때 SVN Repository를 Git에 담아서 출장을 가서 개발할 때마다 여러번 Commit을 하면 복귀후 SVN과 다시 통합을 하면 그 History가 고스란히 합쳐진다.
이런 경우 처럼 Git를 보조적으로 쓰는 것도 좋다.
| 다른 시스템은 쓸 필요가 없나? |
나는 보통의 SW회사에서 소스코드관리시스템과 버그관리시스템 2개면 충분하다고 주장한다. 사실 왠만큼 회사가 커지기 전까지는 이 두가지면 충분하다.
결재가 필요하기 때문에 전자결재를 위한 그룹웨어를 도입하고 싶어하기도 한다. 하지만 소프트웨어 회사에서 그룹웨어는 그렇게 효율적이지 않다. 전자결재는 SW개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.
그 외에 작업관리, 고객요청관리, 테스트 관리등 여러가지 관리의 필요성을 느끼게 된다.
일단 이 두개만 가지고 쓸 수 있는 한 최대한 써보기를 권한다. 그러면 의외로 거의 모든 것을 다 커버하게 된다는 것을 알게 될 것이다.
그후에 회사의 규모가 정말로 커져서 인원이 몇백명이 되고 좀더 관리를 잘 하고 싶으면 테스트관리나 서비스데스크등 개발자들에게는 부담이 안되지만 관리에 도움이 되는 시스템을 우선적으로 도입하면 좋다.
| 결론 |
나중에 통합은 어렵다. 이미 여러개의 시스템을 쓰고 있다면 합칠 수 있다면 지금이라도 합치는 것이 좋다. 나중에는 늦는다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by nerovivo
'기반시스템' 카테고리의 다른 글
| 왜 하나만 써야 하는가? (6) | 2011/08/13 |
|---|---|
| 우리 회사에도 숨어서 놀고 있는 개발자가 있나? (2) | 2011/01/22 |
| 몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다. (0) | 2009/03/05 |
| 깨끗한 개발 환경, 빌드 환경, 테스트 환경 (6) | 2009/02/05 |
| 서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System) (11) | 2009/02/03 |
| 이클립스 프로젝트 필수 유틸리티 개정판 : Subversion, Ant, JUnit, Trac (2) | 2009/01/28 |
Trackback Address: http://allofsoftware.net/trackback/231
SVN+Git이 가장 궁금하네요. 어떤식으로 구성을 하는건가요?
안녕하세요. 구차니님
평소에는 SVN을 쓰다가 출장을 갈 때만 git-svn을 이용해서 clone을 만들어 가는 겁니다. 출장시에는 Git를 쓰는 겁니다. 나중에 SVN과 통합할때는 dcommit 명령을 이용하면 그동안 바뀐 SVN와 merge가 되면서 통합니다. 몇가지 명령어만 알면 시행 가능합니다. ^^
좋은 글 감사합니다.
주제와는 별도로 프로젝트 기획/정보 공유를 위해 위키를 사용하는 것에 대해서 이야기를 듣고 싶습니다.
문서들의 버전 관리/동기화 문제 때문에 위키가 정말 적절한 솔루션이라고 생각하는 데, 막상 사용하려고 하면 프로그래머가 아닌 분은 많이 불편해 하시더군요.
무엇보다 워드나 파워포인트와는 다르게 문서에서 이미지를 그릴 수 없고, 이미지 첨부도 불편한 점이 원인인 것 같습니다.
업무에 위키 도입에 성공/실패한 사례가 있다면 정말 큰 도움이 될 것 같습니다.
안녕하세요.송재학님
위키의 위상은 소스코드관리리스템이나 버그관리시스템에 비하면 5%도 안됩니다. 위키가 왠지 멋져 보이고 장점도 많지만, 쉽게 정착이 안된다는 단점이 있습니다.
또, 프로젝트의 주요문서 (Baseline에 들어가는 문서)를 위키에 저장하게 되면 상당히 불편합니다. 특히 인쇄를 해서 검토를 할 때 불편합니다. 따라서 워드로 만들어서 SVN 등에 보관하는 것이 좋습니다. 제가 쓴 "소프트웨어 개발의 모든 것"을 보면 어떤 문서를 어디에 보관해야 하는지 자세히 설명이 되어 있습니다.
그렇다고 하더라도 위키는 여전히 매력적인 물건입니다. 위키는 도입 실폐사례가 많지만, 대기업중 하나인 H사는 Jira, SVN과 같이 Wiki를 도입하여 정보 공유에 활발하게 쓰고 있습니다.
Wiki의 정착이 어려운 이유는 Wiki를 잘 쓰려면 시간적인 여유도 있어야 하고 각자 능동적이어야 하는데 매일 일에 치이는 회사에서는 금방 흐지부지 되더군요.
신중하게 생각해보세요.
늘 좋은글 감사히 읽고 있습니다.
위키에 대해서는 저는 약간 생각이 다릅니다.
프로젝트 특성상 주요문서는 협업을 통해 검토 & 변경이 이뤄지고 변경 이력관리가 되어야 합니다.
워드등으로 만들 경우 이를 변경하고 배포하는게 그리 효율적이지 않고 많은 비용이 드는것 같습니다.(MS Office 기반의 협업도구도 있다고는 들었습니다.)
또 "요구사항 변경 회의(회의록)"->"요구사항 스펙 수정(변경된 스펙문서)"등 업무로 인한 산출물이 서로 연관이 있을 경우 문서간의 link를 걸어주면 왜 이게 변경이 되었고 변경원인은 무엇인지 손쉽게 관리가 가능합니다.
(wiki의 문서간 link 기능은 정보를 통합하고 관리하는데 최적의 도구라 생각합니다.)
현재 사내에서 위키를 문서 작성 플랫폼 및 협업 및 소통의 도구로 잘 활용하고 있습니다.(이메일을 보낼일이 있다면 내용을 위키에 작성후 링크만 이메일로 보냅니다..)
그간 사내에 위키를 정착하려고 많이 노력을 했었는데 참여도가 저조하고 힘들어 했던 이유중의 하나는 일반적인 wiki 시스템이 사용자 편의성이 떨어진다는 점도 컸던 것 같습니다.
저도 docuwiki, mediawiki, twiki 등을 써보았지만 괜찮은 WYSIWYG 에디터가 제공되지 않아서 전용 문법을 익히는 부담때문에 사내 적용이 힘들었는데 wiki system 을 바꾸고 예전보다 활용도가 더 많아진 것 같습니다.
좀 더 고민을 해봐야겠군요.
일단은 프로젝트에 직접적으로 도입하기 보다는, 지식을 공유하는 용도로 써볼까합니다.
프로젝트에 도입하는 건 다들 위키에 익숙해지고, 만족스러워한다면 다시 한 번 고려해봐야겠습니다.
친절한 답변 감사합니다.