태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

빈 줄도 지워서는 안된다.

2015.04.13 14:25 by 전규현


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






SVN 쓸까? Git 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 중요한 것은 SVN이나 Git 상관없이 어떻게 하면 여러 개발자들과 협업이 되도록 코딩을 하느냐다.


많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다. 또는 여러 명이 개발을 하더라도 자신의 소스코드가 정해져 있어서 혼자 개발하는 경우가 많다. 이러다 보니 협업을 위한 개발에는 별로 관심이 없다. 하지만 협업은 혼자서 때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다. 방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.


혼자서 개발을 하더라도 수많은 브랜치가 발생할 있고 한두 명끼리는 그럭저럭 개발을 하더라도 개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.


그럼 어떻게 코딩을 하는 것이 좋을까?


첫째, 줄도 고쳐서는 된다.


내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다. 설사 혼자서 고치는 소스코드라고 하더라도 습관이 된다. 협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 


뿐만 아니다. Indentation 맞지 않는다고 고치는 것도 좋지 않다. 괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다. 무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.


둘째, 파일 이름을 바꾸지 말아야 한다.


처음에 대충 파일을 만들다 보면 파일이름이 마음에 드는 경우가 있다. 그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을 피할 길을 없다. 처음에 정해야 한다. 


셋째, 함수 이름과 정의를 바꾸지 않아야 한다.


대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다. 그리고 대충 만들고 나중에 수정하는 것은 비용이 많이 든다. 아주 작은 시스템만 경험해 개발자는 이런 방법이 빠르다고 주장할지 몰라도 시스템에 개발자가 수십 명이라면 얘기가 달라진다. 대충하고 바꾸는 습관이 들어서는 안된다.


넷째, 소스코드를 재배치하지 말아야 한다.


파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge 어려워진다. 처음에 생각해서 정하고 나중에는 고치지 말아야 한다. 여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.


이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.


외에도 변수를 어떻게 선언하느냐는  협업을 위한 수많은 코딩 노하우들이 있다. 항상 개발은 혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.

물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 

필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.





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

전규현 기반시스템/소스코드관리 GIT, merge, svn

  1. Blog Icon

    비밀댓글입니다

  2. Blog Icon
    저는 조금 반대입니다.

    저는 조금 반대인게 변경해야 하는 내용이 규격화된 내용과 맞지 않는 형식이라면 고치는게 맞다고 생각합니다.
    머지를 하는게 처음엔 힘들수 있지만 일정한 표준화가 되고 난 다음부터는 그렇게 힘들지 않습니다.
    일단 제 경험상으론 그렇네요.

  3. Blog Icon
    나그네

    이럴때 필요한게 리팩토링 이지요...

    프로젝트 중간 팀원들과 리팩토링을 하여 정보를 공유하는게 좋을듯합니다..

    빈줄도 지워서는 안된다는 좀 심한듯..

소스코드가 없어졌다.

2013.09.04 19:58 by 전규현


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





필자는 소스코드가 없어진 Software 회사를 여러번 보았다. 물론 회사의 전체 소스코드가 없어진 것은 아니다. 일부 소스코드가 없어져서 낭패를 보는 경우는 매우 흔하다. 소스코드는 어떻게 없어지게 될까? 물론 아래 모든 경우는 전사적인 소스코드 관리 및 백업을 받지 않은 경우에서 발생한다.


1. 하드디스크가 망가졌다.


하드디스크는 그렇게 믿을 만한 미디어가 아니다. 어느날 갑자기 망가져 버릴 수도 있고 복구가 안되는 경우도 종종 있다. 10년간 잘 돌던 하드디스크가 PC를 옮겼더니 갑자기 먹통이 되는 경우도 있다. 이런 경우 백업이 없다면 소스코드를 잃어버리는 것이다. 각 개발자의 PC에 사본이라도 있다면 History는 없어져도 최신 소스코드는 건질 수 있지만 그렇지 않아서 소스코드르 잃어버리는 경우를 종종 보았다.


2. 외주를 주고 소스코드를 받지 않은 경우


이 경우도 의외로 많다. 개념이 없이 소스코드를 받지 않은 경우도 있고, 계약상 소스코드는 제공하지 않는 경우도 있다. 두경우 문제가 되기는 마찬가지다. 개발툴을 업그레이드하려면 소스코드가 필요한데 그럴때 외주사가 망해 버리면 영영 발목이 잡혀버린다. 이럴 때는 소프트웨어진흥원에 소스코드 에스크로를 하면 회사가 망했을 때 소스코드를 가져올 수 있다. 외주사가 망해서 소스코드가 없어지는 경우은 의외로 흔하다.


3. 개발자가 소스코드를 관리하다가 퇴사를 한 경우


회사의 중요 제품이라면 소스코드를 잃어버리는 일이 흔하지 않지만 오래된 제품이나 툴등의 소스코드라면 개발자가 대충 소스코드를 보관하고 있다가 퇴사를 해버려서 언제 어떻게 잃어버렸는지도 모르게 소스코드가 없어지는 일이 발생한다. 수년 후 나중에 소스코드가 필요할 때 없어졌다는 사실을 알게 된다.


4. 회사의 소스코드관리시스템(SCM)을 백업받지 않은 경우


소스코드관리시스템을 도입하고 백업을 받지 않는 회사는 엄청나게 많다. 놀랄 일이다. Git등의 분산SCM을 쓴다면 어딘가에 백업이 있지만 SVN을 쓰다가 서버가 날아가면 간신히 부분적인 최신 소스코드만 건지게 된다. History가 사라진 최신소스코드는 그 가치가 몇분의 일로 줄어든다. 물론 많은 회사가 소스코드관리를 제대로 하지 않아서 History가 거의 가치없는 경우가 많다. 하지만 소스코드관리를 제대로 한 경우라면 History는 꼭 필요하다. SCM의 백업은 선택이 아닌 필수다.


이를 방지하는 방법은 전사적으로 소스코드관리를 철저히 하는 것이다. 하나의 통일된 소스코드관리시스템을 사용해야 한다. 회사 몰래 개발자가 숨겨 놓은 소스코드가 존재하면 안된다. 아무리 그렇게 관리를 해도 개발자들이 개인적으로 가지고 있는 소스코드가 존재할 수 있다. 스크립트라고 등록하지 않고, Install shield 프로젝트는 등록하지 않기도 한다. 이런 문제가 발생하는 또다른 이유는 개발자가 개발자PC에서 빌드를 하기 때문이다. 빌드를 빌드 전용서버에서 빌드 담당자가 하게 될 경우 숨어 있는 소스코드를 모두 끄집어 낼 수 있다. 빌드 전용서버는 오로진 SCM에서 소스코드를 가져다가 빌드를 하기 때문에 개발자PC에 숨겨진 소스코드가 있다면 빌드가 되지 않게 된다. 개발자를 못 믿어서가 아니고 빌드는 개발자PC에서 하면 안되는 것이다.


그리고 백업을 제대로 받아야 한다. 백업은 제3의 장소에 보관해서 회사가 완전히 불타 없어져도 소스코드를 바로 복구할 수 있어야 한다는 생각으로 백업을 해야 한다.


이런 환경을 구축하는 것은 비용이 더 많이 드는 일이 아니다. 제대로 관리를 하지 않고 소스코드를 엉망으로 관리하면서 오는 비효율과 비용 및 손실과 비교하면 훨씬 이익이다.


image by Daniel Dreier




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

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

  1. 지금 모처에서 뭔가 외주로 책을 써주는데 관공서들도 기록을 최근(그나마 기록물에 대한 인식이 생긴 금세기) 것만 가지고 있더군요.
    뭐 행정서류는 일정기간이 지나면 파기하지만 역사기록물에 해당하는 것들도..
    아니 아예 기록을 보존한다는 생각이 없..
    저건 소프트업계의 부주의가 아니라 사회 전반적인 문제 같습니다.

스타트업에서 SW 개발에 꼭 필요한 시스템

2012.10.25 16:44 by 전규현


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







소프트웨어를 개발하는데 꼭 필요한 시스템들이 있다. 이것을 기반시스템, 영어로는 Infrastructure system이라고 한다. 기반 시스템은 수십 가지 종류가 있지만 회사 규모나 성격에 따라 꼭 필요한 것이 다르다. 꼭 필요한 기반시스템을 사용하지 않거나 규모에 맞지 않게 많이 사용하는 것 모두 문제다. 그리고 제대로 사용해야 효과를 극대화할 수 있다.


회사 규모가 크면 좀더 많은 기반시스템을 사용할 필요가 있지만 스타트업에서는 꼭 필요한 몇 가지만 있으면 된다. 그럼 스타트업에서 꼭 사용해야할 기반 시스템에는 어떠한 것들이 있는지 알아보자.


1. 소스코드관리시스템

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Bitbucket, Github

추천 시스템: Git, SVN


소스코드관리시스템이 없이 소프트웨어를 개발한다는 것은 상식적으로는 도저히 불가능하다. 자체적으로 구축하는 것도 가능하지만 호스팅을 권장한다. 소스코드관리시스템을 직접 구축하여 운영하려면 하드웨어 구매 비용, 관리 비용 등 만만치 않은 비용이 들어간다. 하지만 호스팅을 이용할 경우 그 수십 분의 일의 비용으로 해결할 수 있다.


호스팅으로 SVN을 이용할 경우 네트워크 속도가 느릴 경우 불편함이 있지만 DVCS(분산버전관리시스템)인 Git를 사용할 경우 문제가 많이 해결된다. Git는 SVN 사용자가 쉽게 사용할 수 있도록 거의 비슷한 명령어 체계도 갖고 있다. 요즘은 Git도 편리한 GUI Client가 많아 SVN만큼 편하게 쓸 수 있다.Git는 기능이 너무 많아 어려워하는 개발자들도 있는데 SVN을 사용하던 방식과 거의 유사하게 사용할 수도 있으므로 시도해보기 바란다.


Git 호스팅 서비스인 Bitbucket.org를 이용하면 5명까지는 무료로 10명은 월 $10, 100명은 월 $100를 내면 된다. 100명 정도까지는 호스팅을 이용하는 것이 훨씬 비용적으로 유리하다고 할 수 있다.


2. 이슈관리시스템 (버그추적시스템)

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Atlassian Jira OnDemand

추천 시스템: Jira, Redmine


요즘은 소스코드관리시스템을 아예 사용하지 않는 소프트웨어 회사가 거의 없지만 의외로 아직 이슈관리시스템을 사용하지 않는 회사는 많다. 엑셀이나 위키를 이용하거나 Email로 처리하는 회사도 있다. 그렇게 해서는 방대한 소프트웨어 개발 이슈를 효과적으로 처리할 수도 없고 많은 커뮤니케이션 비용이 들어간다. 수십 년 동안 진화를 거듭해온 이슈관리시스템들은 제대로 사용하기만 해도 회사 개발문화가 상당히 성숙하게 바뀔 수 있다. 아직 이슈관리시스템을 사용하고 있지 않다면 당장 도입하기 바란다.


과거에는 Trac, Mantis 등이 많이 사용되었다. 여전히 좋은 시스템들이지만 모든 것을 비교해보면 요즘은 Jira와 Redmine을 추천한다. 이슈관리시스템도 비용적인 측면에서 호스팅을 권장하고 Atlassian의 Jira OnDemand을 추천한다. 10명까지는 월 $10, 25명은 월 $100면 된다. OnDemand 스타트업을 위한 저렴한 비용을 제시하고 있다. 회사가 커지면 나중에 직접 구축하고 그 동안 쌓아 놓은 데이터는 마이그레이션이 가능하다.


3. 빌드시스템

필요성: ★★★☆☆

추천 형태: 자체 구축

추천 시스템: 자동화된 빌드 스크립트 자체 제작, Jenkins (구 Hudson)


위에서부터 점점 내려올수록 사용하고 있는 비율이 줄어든다. 빌드시스템은 소프트웨어 개발에 꼭 필요한 시스템이다. 많은 회사가 개발자 PC에서 Eclipse나 Visual Studio의 IDE창에서 버튼을 눌러 빌드한 소프트웨어를 그냥 출시하곤 한다. 소프트웨어 개발에서 개발자 PC는 “더러운 환경”이라고 지칭한다. 테스트를 하거나 출시를 위한 소프트웨어는 깨끗한 빌드 전용 “빌드시스템”에서 빌드해야 한다. 또 자동화된 빌드 스크립트를 제작해서 One-step으로 모든 빌드가 끝나야 한다.


적어도 하루에 한번은 자동으로 빌드를 실행하여 소스코드가 항상 빌드가 가능한 상태로도 유지해야 한다. 이를 Daily Build라고 부른다. 소수가 개발하면 이런 것 신경 안 써도 어쨌든 개발이 되기 때문에 소홀하기 쉽다. 하지만 “더러운 환경”에서 대충 개발하는 것은 대단히 위험한 일이고 Daily Build를 하지 않는 것은 협업의 기본을 모르는 행위다. 빌드시스템은 자체적으로 구축해야 한다면 Daily build나 CI(지속적인 통합)을 위해 Jenkins등의 CI툴을 이용하면 좋다.


4. Wiki

필요성: ★★☆☆☆

추천 형태: 호스팅

추천 시스템: Confluence OnDemand


꼭 사용해야 하는 시스템도 아니고 특별히 추천을 하고 싶은 서비스도 없지만 Atlassian의 호스팅 서비스를 이용하면 연동이 쉬운 같은 서비스를 이용하는 것이 좋겠다. 비용도 Jira OnDemand와 같다.


Jira를 이용해도 상당히 많은 정보가 공유되지만, Wiki는 흩어져 있는 지식과 정보를 한군데로 모으는데 효과적이다. 하지만 Wiki는 결국 Tool이기 때문에 문서를 대신 작성해주지는 않는다. 그렇다고 Wiki를 사용하기 위해서 강제로 문서화를 시도하다가는 Wiki가 방치되기 십상이다.


스펙도 작성할 능력이 좀 되고 문서화에 거부감이 없다면 Wiki를 도입하는 것도 괜찮다. 모든 문서를 Wiki가 대신할 수 없지만 많은 지식을 체계적으로 정리할 수 있는데는 유용하다. 훌륭한 회사 자산도 될 수 있고 효율적인 소프트웨어 개발에 많은 도움을 준다.


5. 프로젝트관리시스템

필요성: ☆☆☆☆☆

추천 시스템: 시스템보다는 엑셀 파일 이용


시스템을 잘못 사용하면 배보다 배꼽이 더 큰 경우다. 좋은 프로젝트관리시스템이 많기는 하지만 대부분 스타트업이 사용하기 무거운 제품들이다. 프로젝트가 지연되는 것은 프로젝트관리시스템을 사용하지 않아서가 아니다. 스펙을 제대로 작성하지 않아서 지연되는 경우가 대부분이다. 스펙이 잘 작성되어야 개발범위가 명확해지고 상세한 개발일정 수립이 가능하다.


일 단위의 개발일정이 수립되면 엑셀에 작성을 해서 관리해도 충분하다. 오히려 웬만한 프로젝트관리시스템들보다 엑셀이 더 편리하다. 회사가 좀더 커져서 수많은 프로젝트와 인력을 동시에 관리해야 할 때 프로젝트관리시스템 도입을 검토해보는 것이 좋겠다.


기반시스템은 도입하는 것보다 제대로 사용하는 것이 더 중요하다. 각 기반시스템을 사용하는데 꼭 지켜야 할 규칙을 몇 가지 제시한다.


소스코드관리시스템

1. 회사의 모든 소스코드 및 개발문서는 빠짐없이 등록해야 한다.

2. 커밋 메시지 규칙, 리뷰 규칙 등 회사의 규칙을 모든 직원이 철저히 따라야 한다.

3. 공식적인 빌드는 항상 Tag(베이스라인)를 남겨야 한다.

4. 협업을 위한 코딩 습관을 가져야 한다. 즉, 머지(Merge)가 원활하게 되게 해야 한다. 소스트리를 견고하게 가져가야 하며 개발자가 함부로 파일의 이름을 바꾸거나 이동하면 안 된다. 소스코드 내에서도 함수를 이리 저리 옮기면 안 된다. 이외에도 지켜야 할 수많은 습관들이 있는데 협업을 하면서 차츰 익히면 된다.


이슈관리시스템

1. 전 직원이 모든 이슈를 이슈관리시스템에 직접 등록해야 한다. 대리 등록은 사양한다.

2. Email, 구두, 전화, 메신저 등 다른 경로를 통한 요청은 없애나가야 한다.

3. 스스로 능동적으로 이슈관리시스템을 모니터링 해야 한다. 사장이라도 필요한 정보는 보고를 요청하지 말고 이슈관리시스템을 통해서 확인하면 된다.

4. 모든 이슈는 전 직원에 오픈한다.


지금까지 스타트업에 필요한 기반시스템과 기본적인 사용규칙에 대해서 설명했다. 기반시스템을 사용하는 것만으로 회사 역량이 세계적인 수준이 되는 것은 아니다. 그야말로 기초 중에 기초일 뿐이다. 하지만 그러한 기초도 안되어 있다면 엄청나게 비효율적으로 개발을 하고 있는 것이다.


기반시스템은 일단 경험을 해보고 제대로 사용하기 시작하면 절대로 과거로 돌아가지 못한다. 때때로 과거에는 이런 좋은 시스템도 없이 왜 그렇게 고생을 했을까 회상하기도 한다. 물론 그때는 비효율적이라는 것을 몰랐었다.


소프트웨어 회사라면 이런 기본적인 것을 잘 갖춰야 진정한 역량인 분석, 설계 등의 역량을 향상시킬 수 있다. 아직 기반시스템을 제대로 갖추고 있지 않은 회사는 저렴한 호스팅 서비스부터 당장 갖추기 바란다. 시작이 반이다. 제대로 사용하기는 어렵지만 차츰 실력이 붙을 것이다. 혹시 어려움이 있거나 궁금한 것이 있다면 나에게 문의하기 바란다.


이글은 Techit에 기고한 글입니다.


image by plewicki



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

전규현 기반시스템

  1. bitbucket이나 github를 쓰면 소스관리+이슈트래킹+위키+코드리뷰까지 패키지로 사용가능하지 않나요?
    나중에 옮겨 간다면 마이그레이션 문제가 있긴하지만..한참 커졌을 때 이야기고..
    스타트업이라면 bitbucket이나 github정도면 대부분 해결가능해 보입니다.

  2. bitbucket은 간이 이슈관리와 Wiki가 포함되어 있습니다. 하지만 간이는 간이죠. Jira와 Confluence와도 쉽게 연동됩니다. github도 이슈관리, 코드리뷰, wiki를 모두 제공하고 작은 회사에서 쓰기에는 충분해 보입니다.

  3. Blog Icon

    먼저 소프트웨어 개발의 모든것 책 너무 잘 읽었습니다.
    빌드시스템은 자체구축을 위해서는 H/W가 필요하잖아요?
    그럴때 사용하면 괜찮을 SOHO용 서버 컴퓨터로 사용할 만한 제품이 궁금합니다.
    NAS처럼 이미 많은 기능이 기본 탑재된 시스템을 사용하는 것이 좋을까요?
    커스터마이즈가 자유로운 리눅스 등을 탑재해 서버시스템을 구축하는 것이 좋을까요?

    클라이언트 개발자 포함 5~6명가량 되고 전체 프로젝트 인원 10명정도 되는 소규모 그룹에서 말이죠...^^

  4. 안녕하세요. TJ님

    우선 적은 인원이면 Hosting을 사용하길 권장합니다.
    그래도 자체 구축하실 것이라면 굳이 비싼 장비를 쓰실 필요는 없고 백업을 잘 받으시는 것이 더 중요합니다.

    OS는 관리에 용이한 OS를 선택하면 좋겠습니다. Linux를 잘 아시면 Linux가 좋겠죠.

이슈를 모으기도 정말 어렵다.

2012.05.07 07:00 by 전규현


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







많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다.


복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다.


기초적인 것이 해결이 안된 상태에서 너무 어려운 것을 적용할 수 없다.


기초적인 것들이 여러가지가 있지만 회사의 이슈들을 한군데로 모으는 것만도 정말 어렵다.


이슈(버그)관리시스템을 사용하는 회사는 많지만 이슈관리시스템에 회사의 모든 이슈를 다 모아서 개발자는 오로지 이슈관리시스템만 보고 개발을 할 수 있는 회사는 드물다.


이슈관리시스템을 통하지 않고 전화, Email, 메신저를 통해서 여전히 개발 요청을 하는 경우가 많다.


어려운 시도를 하기보다는 먼저 이슈관리시스템에 모든 이슈를 모으는 일을 먼저 해보기를 권한다. 이것만 해도 회사에 제대로 정착되는데 1년이 넘게 걸리곤 한다. 그것도 잘 되었을 경우이다.


 버그, 개발요청, 업무요청, 협업관련정보 등 개발 이슈는 무조건 다 모아야 하고, 그외에 업무 이슈들도 모으면 좋다.


개발자는 하나의 시스템에서 모든 개발 요청을 다 볼 수 있고 관리할 수 있어야 한다.


전화, Email을 통한 요청을 일부라도 허용하는 예외를 둬서는 안된다. 예외는 전체 문화를 망가뜨릴 것이다.


시스템은 많아질수록 개발자가 귀찮아지고 비효율적으로 변한다.


경영자가 관리가 잘 안된다고 생각하고 자꾸 관리하는 시스템을 늘리면 관리가 잘되는 것이 아니고 빠져나갈 구멍만 늘어간다. 중심이 되는 이슈관리시스템 하나라도 제대로 사용하는 것이 중요하다. 


개발에 투입할 절대 시간은 정해져 있으니 최대한 개발에 집중할 수 있도록 시스템은 간소화 하고 집중화 해야 한다. 시스템이 많아지면 시스템 때문에 개발 시간을 빼앗기게 된다. 


하지만 이슈관리시스템으로 모을 수 없는 것들이 있다. 원래 전문 시스템이 있는 고객요요청, 재고관리, 인사, 재무, QA관련, 프로젝트 관리, 비용처리등은 ServiceDesk, ERP, HR, MIS, QMS, PMS 등의 시스템을 사용해야 한다. 일부는 이슈관리시스템과 연동할 수 있지만 대체는 안된다. 


작은 회사에서 전문 시스템이 없을 경우 이슈관리시스템으로 대충 관리를 할 수 있지만 이는 임시이다. 나중에 회사가 커지면 전문 시스템을 도입해야 한다.


이슈관리시스템 하나만 보더라도 회사의 역량이 얼마나 되는지 대충 알 수 있다. 어디 끝내주는 방법이 없을까 고민하지 말고 이슈관리시스템 하나라도 제대로 쓸 수 있도록 하자.


image by onepointzero

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

전규현 기반시스템/버그관리

SVN보다 Git가 더 좋을까?

2011.10.25 04:56 by 전규현


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





요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.
  1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
  2. Github를 써야 한다면 Git를 써라.
  3. 그외에는 모두 SVN을 써라.
기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 
CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 

일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.
  • Folder공유 타입 - RCS, SCCS
  • Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
  • 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs
폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.
C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.
또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.
  • Offline에서 자주 개발을 해야 할 때
  • Git 기반의 Open source를 이용한 개발을 해야 할 때
  • Git 기반의 Open source 프로젝트에 참여할 때
  • Github을 써야 할 때
이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.
SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다.

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.

SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

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

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

  1. 헐.....
    마지막 문장에서... 좌절했습니다.
    :(

    열심히 보고는 있지만 (항상 좋은 글 감사합니다.)... 설명해줘라? 조언??
    -_-;;

    그냥 개발자 안할래요 :( ...

    -마음가는 길은 곧은 길-

  2. 안녕하세요. trueonot님

    개발자가 아니라면 굳이 신경쓰지 않으셔도 됩니다. ^^

  3. 최근 고민 중의 하나 였는데, 애정남처럼 깔끔히 정리를 해주시네요.^^
    저는 Git에 해당되지 않아서 SVN에 더 많은 애정을 줘야 겠습니다.

  4. 제이즈님 안녕하세요.

    SVN이냐 Git보다 어떻게 쓰느냐가 더 중요합니다.
    제가 본 90% 이상의 회사들이 SVN을 쓰던 Git를 쓰던 엉터리로 쓰면서 제 기능의 5%도 활용 못하고 있습니다.
    그만큼 제대로 쓰기는 어렵습니다.

  5. Blog Icon
    멤피스

    mercurial은 왜 버리시나요 -_-;;;
    mercurial도 쓰기 편한데.
    구글링을 해보면 git vs. mercurial에 대한 비교 논쟁은 쓸데없는 일이라고 하네요. 그냥 닥치고(?) 하나 골라서 열심히 쓰라고.

    http://gitvsmercurial.com/ 대문에 적힌 글입니다. 좀 과격하지만 맞는 말인 듯하네요. :-)

    "Who the FUCK cares?

    Use what YOU like, not what someone on the internet tells you to."

  6. 멤피스님 안녕하세요.

    mercurial도 좋은 툴임에 틀림없습니다. Git가 사용률이 더 높으므로 대표로 말씀드립니다. mercurial이 편하면 mercurial 쓰시면 됩니다. ^^

  7. Blog Icon
    yducy

    좋은 글이네요.
    Git은 막강한 만큼 배우는데 비용이 많이 들더라구요.
    Android 같이 방대한 코드를 모듈화해서 관리할 때도 Git이 좋은 것 같습니다.
    Repo라는 툴이 있으니까요..

  8. yducy님 감사합니다.

  9. Blog Icon
    나지오

    git이 배우기 어려운건 기능이 많기 때문입니다. svn처럼만 사용한다면 그리 어렵지 않습니다. 중앙 저장소 두고 중앙 관리자 두고 pull, push(svn의 update, commit) 위주로 사용하는 거지요. 그쵸, 브랜칭, 병합 등으로 가면 헷갈리지요. 그건 개념이 달라서 어렵죠. svn은 중앙집중 관리, git은 분산 개발이 모토입니다.
    근데 git이냐 svn이냐의 선택 기준은 더 있습니다. svn은 느립니다. 특히 http에 태운 svn은 이제 2011년에 보니 문제가 심각하구나 생각이 듭니다.(아직 1.7의 http 성능 향상은 써보지 않았습니다만.)
    svn은 자체 권한 관리, http 연동, ldap 연동이 가능합니다. 그런데 git은 ssh에만 태울 수 있어서 ssh를 통해 사용자 인증을 처리해야 합니다. ldap 연동이 필요하면 ssh를 구성해야 하는 거죠.

  10. 안녕하세요. 나지오님

    SVN의 속도는 Git와 비교하여 가끔 이슈를 제기합니다. Git는 repository가 개인장비에 있으므로 전광석화같은 속도를 자랑하죠. ^^ 하지만 push, pull 때는 만만치 않죠. 게다가 clone을 만들 때는 많이 기다려야죠.

    SVN은 기존의 어떠한 SCM보다 빠릅니다. diff만 왔가 갔다 하므로 네트워크 상에서 속도가 빠르죠. 실제로 수백명의 개발자가 동시에 사용을 해도 성능이 문제가 되지는 않습니다.
    단 처음에 대량으로 check out을 받을 때는 좀 기다려야죠.

    SVN과 Git는 1:1로 성능 비교를 하기에는 성격이 너무 다릅니다. ^^ 둘다 좋습니다.

  11. Blog Icon
    나지오

    블로그를 안해서 모르는데 티스토리는 원래 댓글 줄바꿈을 없애나요? 댓글에 메일 주소 쓰는 거두 없구. 댓글 달리면 어떻게 알쥐...

  12. Blog Icon
    슬픈멍멍

    결론의 그외의 상황이라면 SVN을 써라보단,,개인적으론 가능하다면 Git을 써라가 낳을것같습니다.
    Git이 GUI툴의 지원이 상대적으로 부족해보이는 면이 있긴합니다.(주관적입니다)
    하지만 로컬에서의 브랜치작업은 SVN의 상대적인 직관적 사용법과 Git의 상대적인 난해함을 모두 커버하고도 남을 만큼 강력하더군요. SVN으로 브랜치생성해서 작업을 어쩌다 한번 하는 개발자는 공감하기어려울 수도 있으나 브랜치작업이 많은경우 Git은 너무나 편리합니다.

  13. 안녕하세요. 슬픈멍멍님 ^^

    제 결론은 SVN입니다. 엄마가 좋아? 아빠가 좋아? 토론은 하루 종일 할 수도 있죠. ㅎㅎ
    SVN은 브랜치, 머지에 있어서 부족함이 없습니다. Git가 브랜치,머지가 직관적이고 쉽지만 SVN은 강력하죠. SVN의 브랜치, 머지가 좀 어렵다면 Git는 기능적으로 풍부하고 다양하지만 경험이 부족하면 어렵습니다.설명이 복잡하지만, 이게 제 결론입니다.

  14. Blog Icon
    슬픈멍멍

    Git vs SVN은 주관적인것이기도 하지만 CVS 에서 SVN으로 거의 넘어오는 것을 보면,
    언젠가는 SVN같은 중앙 저장소 방식에서 Git,Mercurial 같은 분산 버전관리시스템으로 넘어가지 않을까 추측해봅니다 ㅎㅎ

    그러나 사실 Git 이냐 SVN 보다는 어떤 형상관리툴이라도 사용한다는게 중요한것 같습니다.

    글 잘보고 갑니다. 좋은 글 많이 부타드립니다 ^^

  15. SVN을 쓰던 Git를 쓰던 거의 대부분의 회사들은 제대로 사용을 못하고 있는 것이 현실이죠.

    누가 인기를 더 끌지는 저도 궁금하네요. ^^

  16. git는 소스 한번 받아 볼때 외에는 직접 사용해 본적이 없어서 잘 모르겠고
    cvs보다는 확실히 svn이 편하지만 서버구성하기가 조금 짜증이 나더라구요

    개인적으로는 svn을 사용하고 회사규모에서 사용해야 한다면 그냥 따르는것이 좋다고 봅니다 ㅋㅋ

  17. 구차니님 안녕하세요.

    SVN 서버 구성은 회사에서 딱 한명만 잘 알면 되잖아요. ^^ 나머지 사람들은 감사하게 그냥 잘 쓰면 되겠죠.

  18. 이번 글은 너무 명확해서 참 좋으네요.

  19. 김재호님 반갑습니다. ^^

  20. 네이버에서 SVN과 GIT에 대해 검색하다가 읽게 되었습니다. 전 SVN을 잘 쓰고 있거든요. GIT가 분산저장이라는건 알겠는데 도저히 감이 안 잡히네요.

    프로젝트관리툴로는 그동안 TRAC을 써오다가 Redmine을 쓰고 있는데 GIT에 적합한 프로젝트관리툴이 뭐가 있는지도 궁금합니다.

    여튼 잘 읽고 갑니다. 아직은 SVN에 익숙해서 그런지 계속 쓰게 되네요. GIT도 차차 공부해봐야겠습니다. ㅎㅎ

  21. 안녕하세요. 동범님

    Git는 서버자체를 각 PC에 두고 서로 복제하고 Merge하는 개념입니다. ^^ SVN을 잘 쓰시면 그냥 쓰시면 됩니다.

    Trac, Redmine 등은 프로젝트관리툴이라기보다는 이슈관리시스템입니다.

    대부분의 유명한 이슈관리시스템은 거의 Git, SVN 등과 연동이 잘 됩니다.

    굳이 필요하지 않은데 Git를 쓰려고 노력할 필요는 없고, 알아봐 놓는 것은 좋을 것 같습니다.

  22. Blog Icon
    탐구생활

    좋은 글 감사합니다. 제 생각으로는 GIT은 기존 제품을 혁신하는 제품이기 보다는 오프라인에서도 사용 가능한 틈새 시장용 버전컨트롤시스템인듯합니다. GIT의 유행은 제품 자체보다 제작자(리누스 토발즈)의 네임 밸류가 큰 역할을 한거 같습니다.

  23. 안녕하세요. 탐구생활님

    Git는 결코 무시할 수 없는 시스템입니다. 많은 Opensource 프로젝트가 Git를 통해서 개발하고 있고 이들 Opensource를 이용하려면 Git를 쓰는 것이 매우 유용합니다. 회사나 프로젝트의 성격에 따라서 무엇을 쓸지 정해야 하지만 Git도 중요한 고려 사항 중 하나임은 틀림없습니다.

    문제는 무슨 툴을 쓰느냐가 아니고 어떻게 사용하냐 입니다. 뭘써도 제대로 써야 하는데 제대로 쓰는 회사는 5%도 안됩니다. 잘 쓰는 것이 중요합니다.

  24. 2011년/12년/13년에 걸쳐 국내 모바일 3사 중 한곳을 Plastic SCM 이라고 하는 상용 분산 VCS 시스템을 구축 및 지원 하고 있는데요. Git / Perforce / CC 의 장점이 혼재 되어 있는 도구 입니다. 15명 까지는 무료이고 국내 개발자 커뮤니티에게 무상 라이선스도 있으니 한번 자료를 보시는 것도 괜찮을 듯 합니다.
    개인적으로는 단순히 분산 리파지토리를 벗어나서 보다 진 일보된 협업 환경에서의 SCM Activity 가 늘어날 것으로 보고 있습니다. 아울러 리파지토리의 형태도 NoSQL 이나 Hadoop 혹은 Object DB 등으로 진화 해야만 Andorid 기반의 Local 빌드/릴리즈 환경을 가지고 갈 수 있습니다 대부분의 회사에서는 Git 에서 받아서 자체 SCM 창고에 가지고 갑니다.

  25. 와 제가 생각하는것과 비슷하네요.
    git와 svn를 써본봐로는 기본 기능만 쓰고 소규모에서는 svn이 속편하더군요.

  26. Git(정확히 말하면 GitHub)를 조금 사용해 본 결과 너무나 난해합니다. 좋은 점은 저장소가 로컬로 분산되어 있어서 개발이 빠르다는 점, Git과 Hub가 만나서 SNS 적인 통계를 제공한다는 점, 장점인지 단점인지는 모르겠으나, 모든 개발을 branch로 따고 재빠르게 작업해서 다시 merge한다는 점(이 방법은 분산 저장소 개념에 맞는 개발 방법이더군요. 공식 홈페이지에서 추천하는...)
    사실 저에게 가장 어려운 점은 저장소가 분산되고 머지되는 형태로 인해서 반드시 필요해지는 "전략"입니다. 네명이 단일 프로젝트를 관리한다고 했을 때 어떻게 branch하고 merge하는지, 분명히 정하고 넘어가야 합니다. 이게 어려워요 -_-; 사용법만 익힌다고 해결되는게 아닙니다.
    반면 SVN은 상당히 직관적이어서 commit할 때 어떻게 묶고, 이슈번호과 어떻게 연결시키느냐 정도만 정하면 무리없이 진행이 가능하고요.
    일단 git 사용은 일시중지 상태입니다. 물론 다른 프로젝트에 파생되고, 혼자 개발하는 것이라면 당연히 GitHub의 손을 들어주겠습니다. ^^

  27. 전적으로 동의합니다. 이런 상황은 흔히 벌어집니다.
    특별히 분산 개발환경이 아니라면 SVN으로 거의 커버가 됩니다. Git로도 SVN과 유사하게 쓸수는 있지만 그렇게 하려면 그냥 SVN을 쓰면 되겠죠.
    물론 Git는 훌륭하지만 사용법이 복잡하고 제대로 쓰려면 많은 것이 바뀌어야 합니다. 개발하는 방식도 좀 바뀌어야 합니다.
    현재 상황에 가장 알맞는 툴을 선택해서 사용하시는 것이 좋겠습니다.

  28. 다수의 사람들이 같은 코드를 건드릴 여지가 충분하고 새 피쳐 개발하면서 기존 릴리즈 관리하면서 난리부루스를 치게 되면 항상 SVN 이용할때 따라 오는 게 막판 merge시 tree conflict입니다. 간단하게 해결되는 것도 있겠습니다만... 파일명 바뀌고 위치 바뀌고 몇벙 이래저래 옮겨진 워킹브랜치를 머지하는 날에는 그야말로 지옥문이 열리는 걸 경험하실 수 있을겁니다.

    Git을 쓰는 이유? 물론 로컬 repository가 있어서 내가 새로 브랜치를 따든 커밋을 하든 준비가 되었다고 생각할때까지는 다른 작업자들에게 양향을 미치지 않고 작업할 수 있다는 장점도 있습니다만... 그 모든 것의 정점에 있는 기능은 아무래도 "Git을 사용하면 머지시 tree conflict걱정할 필요는 없다" 라는 게 아닐까요? 이거야말로 궁극적으로 팀이 Git을 사용해야 하는 이유라고 할 수 있겠지요.

    아직까지 SVN을 쓰면서 한번도 tree conflict를 본 적이 없거나 그게 뭔지도 모르겠다고 하시는 분이 계시다면... 뭔가 SVN을 잘못 쓰고 있는게 아닌지 한번쯤 고민해 보는 것도 좋을 것 같습니다.

    Git의 브랜칭 전략이라고 하면 http://nvie.com/posts/a-successful-git-branching-model/ 이걸 한번 보시는 게 좋을 것 같습니다. 아마도 이게 best practice가 아닐까 싶네요.

  29. Git을 사용하면 tree conflict가 발생하지 않는다는 말씀은 이해하기가 힘드네요. 머지할 때 충돌이 나는 것이 툴로 해결될 것 같지가 않는데... 혹시 경험이 있으시다면 이 부분 설명 부탁드려요.

    그리고, 현대 개발이라는 것이 이슈트래킹과 연동을 해야하는 이슈가 있는데요 Git이 이런 운영쪽과 협업에 걸림돌이 되지는 않나요?

    베스트케이스로 보내주신 블로그는 그야말로 예술적으로 쓰는군요!!!

  30. 좋은 의견 감사합니다. 메아리바람님의 질문이 있어서 몇가지 덧붙입니다.

    Git는 SVN보다 몇몇 진화된 기능이 포함되어 있습니다. SVN에서는 파일 이름을 바꾸거나 이동을 하면 추적이 안되는데 Git는 추적이 가능합니다. 따라서 Tree conflict가 줄어드는 효과가 있을 수 있습니다. 물론 SVN의 장점도 있습니다. SVN은 여러 프로젝트를 하나의 Repository에 관리하면서 공통모듈을 관리하고 부분적인 Branch를 효과적으로 사용할 수 있습니다. SVN 개발자 브랜치를 이용하면 독자적으로 개발을 해서 merge를 할 수는 있습니다.

    근본적으로 SVN을 쓰던, Git을 쓰던 Conflict를 최소화하는 개발 문화가 되어야 합니다. 구현 시작 전에 소스코드 디렉터리 구조를 미리 확정하고 파일이름도 결정해야 합니다. 또한 Public function들고 미리 정해서 컴포넌트간에 독립적으로 개발이 가능하도록 정합니다. 하나의 소스코드 파일은 나혼자만 수정한다는 생각은 버리고 동시에 수정해서 Conflict이 최소화되는 방법으로 코딩을 하는 것이 좋습니다. 여러가지 방법이 있습니다. 그리고 개발자는 프로젝트 도중에 피치못할 상황이 아니라면 파일의 Rename이나 Move는 지양해야 합니다.

    그리고 Git던 SVN이던 Merge 전략은 잘 세워서 사용해야 합니다.

    이런 환경이 아니라면 Conflict 외에도 여러가지 문제가 발생합니다. Git에서는 이런 문제를 일부 해결했습니다. Git이던 SVN이던 회사의 환경에 맞게 선택을 하는 것이 좋을 것 같습니다.

    그리고 둘다 이슈트레킹시스템과는 연동이 잘 됩니다. ^^

  31. Blog Icon
    g

    물론 Assembly를 가지고 하던 것은 C++로 거의 다 된다.
    또한 Assembly에서 안되는 것도 C++에서 되는 것도 많다.

    그러면 C++이 Assembly보다 좋은 것인가?

    Assembly에서 제공하지 않지만 C++에서 제공하는 기능이 꼭 필요한 경우라면 C++를 사용할 수도 있다.
    - C++, C로 짜여진 수많은 라이브러리를 사용해야 할 때
    - 템플릿과 constexpr를 활용한 메타프로그래밍을 할 때
    - 다형성, 상속, 캡슐화 등을 빨리빨리 구현해야 할 때
    - RAII를 활용해야 할 때

    이런 경우가 아니라면 Assembly를 쓰는 것도 좋다. Assembly가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 Assembly의 막강한 제어능력을 극히 일부만 활용하고 있어서 그럴 수 있다.

  32. Blog Icon
    h

    git과 svn을 asm과 C++로 연결하셨는데요, 둘이 고수준과 저수준의 차이가 나나요. 둘은 목표가 다르고 그 정도의 수준 차이도 나지 않습니다.

    논점을 제대로 집어내지 못한 오도는 쉽게 당신의 논점이 정당하다는 느낌을 주게 할 수는 있을지라도, 그 서술이 옳은 것이란 걸 증명해주진 못합니다.
    이런 게 바로 '허수아비 공격의 오류'죠. 쉬운 주장을 때리시느라 즐거우시긴 하셨겠지만 이제는 현실을 볼 때입니다.

  33. Blog Icon
    운영까지 고려하면

    동시 다발적으로 패치팀이 꾸려지고 각 팀에 대한 브렌치와 머지를 통해 프로덕트 버저닝이 필수인 운영환경에서는 git이 svn보다 이점이 많습니다.

  34. Blog Icon
    기다리는

    Git 기반의 Open source를 이용한 개발을 해야 할 때
    Git 기반의 Open source 프로젝트에 참여할 때
    이거 아니면 깃 쓸 이유 전혀 전혀 전혀 전혀 없습니다

    솔직히 유행 따라 쓰는거지

    svn이 얼마나 좋은 툴인데 svn기능은 다 알고 그러시는건지??


이 소스는 건들지마

2011.10.09 16:07 by 전규현


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





소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.

  • 이 소스코드는 건들지만 이번주 금요일에 릴리즈할 건데 지금 테스트 중이라서 건들면 헷갈리니까 잠시 건들지 말아줘
  • 소스코드를 수정해서 등록하는데 Conflict가 났다. 원래 수정자를 찾아 같이 모여서 소스코드를 머지했다.
  • 같은 소스코드를 서로 같이 동시에 수정하면 문제가 많으니 각 모듈마다 담당자를 따로 정해서 소스코드가 충돌하는 경우를 원천 봉쇄했다. 그래서 서로 다른 사람들의 소스코드를 잘 모른다.
  • 하나의 소스코드를 가지고 오늘은 내가 내일은 다른 사람이 수정할 수 있도록 서로 일정을 조정했다.
  • v1.0 출시 후 v1.0 유지보수와 v1.5로 업그레이드 하는 프로젝트가 동시에 진행하는데 서로 소스코드가 섞여서 소스코드 관리를 잘해야 한다.
  • 위 경우 소스코드 충돌 때문에 소스코드 브랜치를 만들어서 따로 6개월간 개발을 했는데 나중에 v1.0의 수정본을 v1.5에 합치는데 워낙 많이 바뀌어서 거의 한달이나 걸렸다. 그 한달동안에 v1.0 소스코드는 또 많이 바뀌어서 Merge하고 테스트하는데 시간이 또 많이 걸렸다. 

위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.

기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다. 

그것은 바로 "Baseline"과 "3-way merge"이다.
이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.

  • 언제 릴리즈하는지는 상관없이 언제든지 소스코드를 수정할 수 있다. 
  • 소스코드 Conflict가 일어나도 원래 수정자가 없이도 쉽게 Merge할 수 있다.
  • 소스코드에서 여러 컴포넌트를 개발했던 원래 개발자는 있지만 서로 상대방의 컴포넌트를 수정할 수 있고 동시에 수정을 해서 충돌이 가끔 일어나지만 문제 없이 Merge가 된다.
  • 소스코드를 누가 언제 수정하는지 전혀 신경 쓰지 않고 서로 동시에 수정을 할 수 있다.
  • 유지보수 프로젝트와 업그레이드 프로젝트가 동시에 진행을 해도 Merge는 불과 몇시간이 걸리지 않고 대부분 자동으로 해결된다.

Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.

아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.

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

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

  1. Blog Icon
    자바지기

    좋은 글 잘 읽었습니다. 버전 관리 시스템 기능을 최대한 활용해 문제를 해결할 수 있다는 것에 일정 부분 공감하지만 버전 관리 시스템 사용만으로는 한계가 있다고 생각합니다.

    브랜치가 생성되는 순간 이를 테스트할 수 있는 개발 환경을 쉽게 구축할 수 있는 환경이 되어야 하고, 소스 코드 머지가 subverion은 다소 문제가 되는 부분이 있어 다른 형태의 버전 관리 시스템을 사용해 보는 것도 고려해볼 필요가 있다고 생각합니다.

    그러나 다른 무엇보다 각 기능들을 어떻게 관리하느냐가 가장 중요하지 않나 생각합니다. 기능들을 잘게 나누어서 우선순위를 선정해 개발하는 방식이 갖추어져 있어야 이 모든 과정이 가능할 겁니다. 이 부분을 모두 갖춘 상태에서도 브랜치를 나누고 소스 코드를 잘 관리하는 방법은 상당히 어려운 작업이라고 생각합니다. 한, 두 달의 시간이 아닌 1,2년의 시간을 투자했을 때 진정 우리가 원하는 형태의 소스 코드 관리가 가능해지지 않을까 하는 생각이 드네요.

  2. 안녕하세요. 자비지기님
    SVN은 Merge에 있어서 정말 강한 툴이지요. ^^
    하지만 제대로 쓰려면 그 컨셉을 정말 잘 알아야 합니다.

    형상관리도 중요하고 스펙의 범위 관리도 중요하지요. 뭐하나 소홀히 얘기하기는 어렵겠네요.

  3. Git이 SVN보다는 몇가지 나은 점이 있고, 또한 3-way merge를 해서 아무런 문제 없이 머지가 되었다고 해도 그건 단지 텍스트상의 머지이기 때문에 실제로 '언제든지 소스코드를 수정할 수 있다' 가 만족되려면 상당한 수준의 테스트 케이스가 준비되어야 하고 또한 QA들의 도움이 필요한게 사실이지요.

    또한 이미 릴리즈된 버전에 픽스된 라이브 버그 픽스들을 적절히 트렁크로 가져와서 머지하는 것도 중요합니다. 안 그러면 매 버전마다 개발자들이 regression bug때문에 생고생을 하는 경우도 종종 -_-;;

  4. 안녕하세요. 우울한딱따구리님
    Git을 쓰려면 조금더 역량이 필요한 것은 사실이지요. ^^
    언제한번 SVN과 Git를 비교해보도록 하겠습니다.

왜 하나만 써야 하는가?

2011.08.13 11:32 by 전규현


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





이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 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
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템 GIT, svn, 기반시스템

  1. SVN+Git이 가장 궁금하네요. 어떤식으로 구성을 하는건가요?

  2. 안녕하세요. 구차니님
    평소에는 SVN을 쓰다가 출장을 갈 때만 git-svn을 이용해서 clone을 만들어 가는 겁니다. 출장시에는 Git를 쓰는 겁니다. 나중에 SVN과 통합할때는 dcommit 명령을 이용하면 그동안 바뀐 SVN와 merge가 되면서 통합니다. 몇가지 명령어만 알면 시행 가능합니다. ^^

  3. 좋은 글 감사합니다.
    주제와는 별도로 프로젝트 기획/정보 공유를 위해 위키를 사용하는 것에 대해서 이야기를 듣고 싶습니다.
    문서들의 버전 관리/동기화 문제 때문에 위키가 정말 적절한 솔루션이라고 생각하는 데, 막상 사용하려고 하면 프로그래머가 아닌 분은 많이 불편해 하시더군요.
    무엇보다 워드나 파워포인트와는 다르게 문서에서 이미지를 그릴 수 없고, 이미지 첨부도 불편한 점이 원인인 것 같습니다.
    업무에 위키 도입에 성공/실패한 사례가 있다면 정말 큰 도움이 될 것 같습니다.

  4. 안녕하세요.송재학님

    위키의 위상은 소스코드관리리스템이나 버그관리시스템에 비하면 5%도 안됩니다. 위키가 왠지 멋져 보이고 장점도 많지만, 쉽게 정착이 안된다는 단점이 있습니다.

    또, 프로젝트의 주요문서 (Baseline에 들어가는 문서)를 위키에 저장하게 되면 상당히 불편합니다. 특히 인쇄를 해서 검토를 할 때 불편합니다. 따라서 워드로 만들어서 SVN 등에 보관하는 것이 좋습니다. 제가 쓴 "소프트웨어 개발의 모든 것"을 보면 어떤 문서를 어디에 보관해야 하는지 자세히 설명이 되어 있습니다.

    그렇다고 하더라도 위키는 여전히 매력적인 물건입니다. 위키는 도입 실폐사례가 많지만, 대기업중 하나인 H사는 Jira, SVN과 같이 Wiki를 도입하여 정보 공유에 활발하게 쓰고 있습니다.

    Wiki의 정착이 어려운 이유는 Wiki를 잘 쓰려면 시간적인 여유도 있어야 하고 각자 능동적이어야 하는데 매일 일에 치이는 회사에서는 금방 흐지부지 되더군요.

    신중하게 생각해보세요.

  5. Blog Icon
    술푼사슴

    늘 좋은글 감사히 읽고 있습니다.

    위키에 대해서는 저는 약간 생각이 다릅니다.

    프로젝트 특성상 주요문서는 협업을 통해 검토 & 변경이 이뤄지고 변경 이력관리가 되어야 합니다.

    워드등으로 만들 경우 이를 변경하고 배포하는게 그리 효율적이지 않고 많은 비용이 드는것 같습니다.(MS Office 기반의 협업도구도 있다고는 들었습니다.)

    또 "요구사항 변경 회의(회의록)"->"요구사항 스펙 수정(변경된 스펙문서)"등 업무로 인한 산출물이 서로 연관이 있을 경우 문서간의 link를 걸어주면 왜 이게 변경이 되었고 변경원인은 무엇인지 손쉽게 관리가 가능합니다.
    (wiki의 문서간 link 기능은 정보를 통합하고 관리하는데 최적의 도구라 생각합니다.)

    현재 사내에서 위키를 문서 작성 플랫폼 및 협업 및 소통의 도구로 잘 활용하고 있습니다.(이메일을 보낼일이 있다면 내용을 위키에 작성후 링크만 이메일로 보냅니다..)

    그간 사내에 위키를 정착하려고 많이 노력을 했었는데 참여도가 저조하고 힘들어 했던 이유중의 하나는 일반적인 wiki 시스템이 사용자 편의성이 떨어진다는 점도 컸던 것 같습니다.

    저도 docuwiki, mediawiki, twiki 등을 써보았지만 괜찮은 WYSIWYG 에디터가 제공되지 않아서 전용 문법을 익히는 부담때문에 사내 적용이 힘들었는데 wiki system 을 바꾸고 예전보다 활용도가 더 많아진 것 같습니다.

  6. Blog Icon
    송재학

    좀 더 고민을 해봐야겠군요.
    일단은 프로젝트에 직접적으로 도입하기 보다는, 지식을 공유하는 용도로 써볼까합니다.
    프로젝트에 도입하는 건 다들 위키에 익숙해지고, 만족스러워한다면 다시 한 번 고려해봐야겠습니다.
    친절한 답변 감사합니다.

이슈관리시스템을 쓰면서 일이 더 많아졌다.

2011.07.20 00:22 by 전규현


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





이슈관리시스템을 쓰기 시작하면서 일이 오히려 더 많아졌다고 하소연하는 경우들이 많다.

이슈관리시스템을 쓰지 않다가 또는 전사적으로는 쓰지 않고 소수의 팀내에서만 쓰다가 이슈관리시스템을 전사적으로 제대로 쓰기 시작하면서  일이 더 많아졌다고 하곤 한다.

이것은 오히려 긍정적인 신호이다. 이슈관리시스템을 쓰지 않고는 회사내의 모든 이슈를 다 표면위로 드러낼 수도 없고 관리도 할 수 없다.

일이 많아졌다고 느끼는 것은 절대적인 일이 늘어난 것이 아니고 숨어 있던 이슈들이 모두 공유된 것 뿐이다. 이슈관리시스템이 없다면 잊혀지거나 개인이 알아서 챙기다가 유야무야되는 이슈들이 매우 많다. 이슈관리시스템은 모든 이슈들이 등록이 되고 개인의 의지에 따라서 해결이 되고 안되고가 결정이 되는 것이 아니고 전사적으로 공개적으로 처리가 된다. 물론 많은 이슈는 처리하지 않고 해결하는 것으로 종료된다.

이슈가 빠짐없이 처리되는 것은 물론 이슈를 처리하는 과정은 완전히 투명하게 공개가 된다.

억지주장을 해도 모두 알게 되고 요청을 무시하거나 늦장을 부려도 누구나 알 수 있다. 완전히 투명하게 업무가 진행된다. 투명한 업무처리를 싫어하는 사람들은 이를 꺼려할 수는 있지만 전사적으로는 대단히 큰 강점이 된다. 

따라서 이슈관리시스템에는 버그 뿐만 아니라 업무요청, 자료요청, 새로운 아이디어 등 온갖 이슈는 모두 등록하는 것이 좋다. 또한 이슈관리시스템을 사용하면서 전화로 구두로 요청하는 것은 거의 없애야 하면 이슈를 공유하고 논의하는 회의의 대부분은 사라져야 한다. 회의에 불려가는 시간도 줄어야 하며 전화나 구두로 요청하는 인터럽트도 많이 줄어야 한다. 이렇게 세이브된 시간은 쉬거나 좀더 창의적인 일을 하는데 쏟는 것이 좋겠다.

이슈관리시스템은 전사적으로 제대로 쓰는 것만으로도 회사의 개발문화에 많은 변화를 가져온다.

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

전규현 기반시스템/버그관리 개발문화, 이슈관리

  1. 이제 블로그 댓글에서 점점 Facebook 댓글로 옮겨 가고 있군요. ^^
    좋은 현상일까요?

  2. 아무래도 눈에 당장 들어오는게 페이스북 댓글이니까 더 손이 많이 가지 않을까요? ㅎㅎ 이름/비밀번호/홈페이지 이런거 일일이 입력하지 않아도 되구요. :)

  3. 페북계정은 있지만 웬지 정감이 안더라구요 ^^;

    음.. 일단 공론화 되는게 유쾌하지 않은 사람들이 많다는게 문제지만
    보이지 않는다고 다루지 않아도 될 문제는 아니니 바쁨을 즐겨야 할것 같아요 ㅎ

  4. 구차니님 안녕하세요.
    전 페북은 지인들과 소식 전하는 개인 용도로만 쓰고 있습니다. ^^

  5. 일반 블로그 댓글의 가장 큰 문제점은, 자기가 댓글을 단 글에 댓댓글이 달린 것을 알 수 없다는 점입니다.
    페북댓글을 사용하게 된 가장 큰 이유는 이 문제 때문 아닐까요?

  6. 안녕하세요. 이린님
    댓글알리미에서 제가 다른 블로그에 댓글 단것에 또 댓글이 달리면 알려주더군요. 그게 그 기능이 아닌가요? 되는 블로그가 있고 안되는 블로그도 있을 수 있겠군요.

  7. 이슈가 공유되서 일이 많아졌다는 것에 전적으로 공감합니다.

    이슈 관리 시스템을 쓰다보니 확실히 일이 좀 늘긴 했는데요,
    가만히 생각해보면 그간 잊혀지고 사라졌던 이슈들이 그대로 남아있기 때문이더군요.

    좋은 글 항상 잘 보고 있습니다. ^^

  8. 안녕하세요. kkamagui님
    항상 글을 읽어주셔서 감사합니다.

  9. 좋은 글입니다. 일이 많아진 게 아니라 드러나지 않던 게 드러나는 거란 통찰이 멋진 것 같습니다.

  10. 안녕하세요. 녹풍님
    반갑습니다. 이슈관리시스템 잘 쓰고 계시나보죠?

소스코드 Conflict

2011.02.18 22:16 by 전규현


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






소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.
하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.

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

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

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

  1. 음.. 위와 같은 충돌은
    소스코드 법칙을 세우고 서로 맞추는게 오히려 더 맞지 않을까 생각이 됩니다.

    탭간격이라던가 괄호의 규칙 이런걸 정하면 이런 소모적인 충돌은 줄어들테니 말이죠.
    그리고 추가적으로 자주 커밋하고 받으면 이런 문제가 발생할 소지가 줄어 들겠죠 ㅎ

  2. 구차니님 안녕하세요.
    코딩 컨벤션을 지키는 것은 아주 기본적이고 당연한 것이고 위 내용은 그보다 한단계 높은 수준의 습관입니다. ^^

  3. 자주 소스코드를 update하는 습관이 일단 중요한 것 같아요.
    그리고 이유 없이(없다기 보단 그냥 미관상이겠죠..) 소스코드의 줄을 맞추거나 라인을 이동하는거 정말 공감합니다..;;ㅎ

  4. 안녕하세요. 피스티스님
    맞습니다. 팀의 규모가 매우 커지고 프로젝트가 복잡해지면 update를 하는데도 나름 계획이 필요합니다. 파일이 너무 자주 바뀌기 때문에 적절한 시점에 update를 하지 않으면 상당히 복잡해집니다.

  5. Blog Icon
    줄맞추기

    좋은 글 잘 보고 있습니다.

    개발하는 시간보다 소스코드의 줄맞추는데 시간을 더 많이 소비하는 경향이 있는 일인입니다.
    줄이 안 맞는 코드는 가독성이 많이 떨어지던데..
    이런 경우는 제가 문제가 있는 건가요?

우리 회사에도 숨어서 놀고 있는 개발자가 있나?

2011.01.22 18:15 by 전규현


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






소프트웨어 개발 조직은 전통적인 관리 방법이 별로 효과적이지 않습니다. 

소프트웨어 개발 조직은 프로세스와 시스템에 의한 자율적이고 투명한 방법이 필요합니다. 그런데 전통적이고 관료적인 관리 방법도 사용하지 않고 효율적인 프로세스와 시스템도 사용하고 있지 않는 조직에서는 개발자들이 어떻게 일을 하고 있는지 잘 파악안되곤 합니다.

물론, 놀고 있는 개발자를 찾아내고자 이 글을 쓰는 것은 아닙니다. 개발자들은 스스로 자신이 해야할 일을 찾아내고 스스로 관리해야 합니다. 물론 개발자에게 업무와 이슈가 할당되고 자신에게 주어진 일을 해야 하지만 이것이 다가 아니고 많은 일들은 스스로 해야만 회사가 경쟁력을 갖출 수 있습니다.

그러기 위해서는 효율적인 프로세스와 시스템을 갖추고 있어야 하고 문서화도 잘 해야 합니다. 그러다보면 누가 얼마나 많은 일을 했는지 자연스럽게 드러나게 됩니다. 거꾸로 들키지 않고 일을 하지 않기도 어렵습니다.

개발자들이 얼마나 많은 일을 했는지 다음을 보면 알 수 있습니다.
  • SCM 사용기록 통계
    • 소스코드 라인수
    • 문서 갱신 기록
    • 다른 개발자의 코드를 리뷰한 기록
  •  Bug Track System 사용 통계
    • 보고한 이슈
    • 할당된 이슈
    • 해당 기간 동안 해결한 이슈
    • 댓글 수
  • 리뷰 기록
    • 리뷰 실시 기록
    • 리뷰 참석 기록
  • Wiki 작성 기록
  • 문서관리시스템 업데이트 기록

물론 이 기록들을 점수를 매겨서 누가 더 열심히 일했는지 절대로 알 수는 없습니다. 같은 소스코드 라인수라고 해도 서로 난이도가 다르고 버그를 똑같이 고쳐도 10분 걸리는 버그가 있는가 하면 한달동안 고쳐야 하는 버그가 있기 때문입니다. 따라서 평가에 직접적인 기준으로 삼는 것도 위험합니다.

개발자들은 이러한 시스템을 통해서 자신이 하는 작업들이 항상 기록에 남고 별도의 관리를 하지 않아도 항상 모니터링할 수 있습니다. 이러한 방법이 매일 해야 하는 일을 일일이 관리하는 것보다 훨씬 효율적입니다.

일안하고 숨어서 딴짓하는 개발자를 찾아내는 것은 그냥 부수적인 효과일 뿐입니다.

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

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

전규현 기반시스템

  1. 다르게 말하자면, 개발자는 항상 스스로 일을 찾아서 더 많은 일을 해야 한다는 느낌이 들기도 해요.
    결국에는 회사를 위해서 개발자는 희생하라 그런 느낌도 많이 들구요.

  2. 안녕하세요. 구차니님
    제 생각에는 회사와 개발자들은 희생하고 이용하고 하는 관계라기 보다는 서로에게 의지하고 돕고 같이 나아가야 하는 동반 관계라고 생각합니다. 누가 일을 열심히 하나 감시하기도 어렵고, 자율적으로 스스로 해나갈때 가장 효율이 높습니다. ^^

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바