우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다.

히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다.

그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내놔도 뒤지지 않을만큼 뛰어나지만 골결정력 등 섬세한 고급 기술들이 부족하다고 생각했었다.

하지만 히딩크는 이를 전면 부정하고 고등학교 축구팀처럼 기초 체력 훈련에 집중했다. 주변의 반대가 심했지만 강행했다.

그리고 월드컵에서 그 결과를 보았다. 경기 후반 다른 나라 선수들이 지쳤을 때 우리 선수들은 한발 더 뛸 수 있었고 승리로 이어졌다.

우리나라 개발자들은 개인기들은 뛰어나다. 즉, 코딩을 잘하는 개발자도 많고 온갖 지식도 많이 안다.

솔직히 이 정도로 많이 아는 개발자들은 전세계적으로 찾아보기 어렵다. 그럼에도 세계적인 소프트웨어 회사가 우리나라에 없고, 세계적인 제품을 찾아보기 어려운 것은 기초 체력이 부족하기 때문이다.

개발자들이 많이 아는 지식은 혼자서 배우고 익힐 수 있는 것들이다. 이것은 노력하는 개발자라면 누구나 다 잘 한다.

하지만 기초 체력은 혼자서는 절~대로 배울 수 없는 것들이다. 대부분 잘 갖춰진 개발문화를 가진 SW회사에서 몇년씩 일하면서 자연스럽게 배울 수 있는 것들이다. 그렇게 쌓은 기초 체력을 갖춘 개발자들이 버글버글 해야 그들이 뭉쳐서 좋은 소프트웨어도 만들고 그중에서 세계적인 소프트웨어도 나올 수 있다.

그런 좋은 환경에서 배울 수 있는 기초 체력은 코딩도 아니고 Domain 지식도 아니다.

아래와 같은 것들이다.

• 소프트웨어 개발에 있어서의 개방의 문화
• 리뷰 문화
• 공유 문화
• 협업 문화
• 신뢰의 문화
• 효율적인 개발 프로세스
• 소스코드 관리 기법
• 이슈 관리 기법
• 빌드/릴리즈 기법
• 테스트

이런 것들이 몸에 베어 있어야 한다. 몸에 베이지 않고 지식으로만 알고 있는 것은 막상 시행하려고 할 때 제대로 실행하기 어렵다. 엉뚱한 방향으로 흘러가서 이상하게 되어 버린다.

또 기초 체력에 해당하는 것들은 비싼 툴을 쓰고 정교한 세계 최고의 방법론, 프로세스를 도입한다고 해서 나아지지 않는다. 오히려 방해가 되는 경우가 많다.  그런 비싼 툴과 정교한 프로세스를 그것을 필요로 하는 곳이 따로 있는데 맞지도 않는 것을 쓰게 되면 반감만 커지게 된다.

툴은 꼭 필요하지만 환경에 맞게 필요한 툴과 적절한 프로세스가 필요한 것이다. 그 기반하에서 문화가 꾸준히 쌓이게 된다. 

이런 기초 체력이 뒷받침 되어야 다음과 같은 고급 역량이 생기기 마련이다.

• 분석 역량
• 설계 역량
• 기술 전략 수립

단어만 놓고 보면 우리도 다 하는데라고 생각할지 모른다.

이는 태권도 10급이 태권도 9단에게 나도 태권도 할 줄 안다고 하는 것과 비슷하다.

Global 하게 경쟁 좀 하려면 4,5단은 되어야 하는데 우리나라에서 유단자 찾기 어려운 이유가 기초 체력을 먼저 갖추기 어려운 환경에서 일하기 때문에 이런 고급 기술은 닦을 시간도 없고 방법도 모르기 때문이다.

그래서 내가 중요하게 생각하는 것이 개발 환경을 먼저 바꿔 놓는 것이다.

기본적으로 이슈관리시스템, 소스코드관리시스템만 제대로 사용해도 반쯤은 바뀐 것이다.

이런 시스템들을 쓰면 우리가 눈치 채지 못하지만 여러가지 원칙, 프로세스를 저절로 배우게 된다. 수십년간 수많은 SW회사들의 성공하는 방법이 녹아 있는 것이 그런 시스템, 툴 들이다.

따라서 이들을 원칙 그대로 사용만 해도 많은 것을 얻게 된다. 기존의 방법과 다르다고 툴을 무시하고 또는 이상하게 변형하면 99.9% 잘못된 방향으로 가고 있는 것이다.

그리고 빌드, 테스트, 리뷰 등등을 하나씩 갖춰나가면 어느덧 꽤 효율적인 조직의 모습을 갖출 것이다.

이때 나타나는 조직의 모습은 다음과 같다.

• 회사의 모든 개발 이슈가 투명하게 Open 된다.
• 모든 업무의 커뮤니케이션이 원활하며 이런 것에 시간 낭비 하지 않는다.
• 모든 소스코드는 공개가 되어 있고, 협업이 원할하다.
• 숨어서 개발하는 개발자는 더이상 존재하지 않는다.
• 경영자와 관리자는 개발 진행 상황을 한눈에 파악하고, 각 개발자들의 업무 진행 상황을 쉽게 파악한다.

대부분은 이쯤에서 만족할 수 있을지도 모르겠다.

하지만 여기까지는 진짜 "기초 체력"이다.

국내 대회에서는 꽤 상위권에 오를 수 있다. 하지만 월드컵에 나가면 한 골 넣기도 어렵다.

이제 "고급 역량"이 필요할 때다.

분석/설계/기술전략 등의 "고급 역량"은 단기간에 배울 수도 없다. 그렇다고 혼자 방법과 길을 알아서 익힐 수도 없다. 그렇게는 너무나 오래 걸려서 은퇴할 때가 될 것이다.

"고급 역량"은 이미 "고급 역량"을 갖춘 선배, 동료들과 진짜 프로젝트를 수행하면서 몸으로 익히는 것이다.

어느정도 방법과 길을 아는데는 몇개월 안걸리지만 진짜 역량이 높아지는데는 5년, 10년이 걸리고 20년이 지나면 또 역량이 올라간다.

우리나라 많은 개발자들이 관리 쪽을 기웃거리다가 또 유지보수에 시달리다가 20년 쯤 지나면 이도 저도 아닌 상태와는 많이 다르다.

기초 체력을 익히는 첫걸음은 기초 체력이 부족하다는 것을 인정하는 것이다. 스스로를 인정하지 않으면 바뀔 수 없다. 이렇게 환경부터 하나씩 고쳐나가야 한다. 

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다.

2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?

소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.

여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.

필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.

그 이유는 다음과 같은 것들이 있다.

• 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다. 
• 보통 에러처리와 약간의 버그는 무시한다.
• 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
• 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
• 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다. 

따라서 재사용 가능하도록 만든다면 낭비가 될 수 있다.
보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.

제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.

그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다. 

그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.

• 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
• 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
• 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
• 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
• 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.

 사실 아주 작은 제품이나 소수의 팀이 개발하는 제품이 아니라면 위의 모든 것을 가정하기는 대단히 어렵다.

스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다. 

어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.

스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.

이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.

프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.

단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.

프로토타입이란?

프로토타입 (경제/경영)

양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다.

by 다음 백과사전 (http://100.daum.net)

소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다. 

이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다.
스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 경우가 있다. 스펙이 이렇게 불분명한 부분이 가득하다면 십중팔구 프로젝트는 산으로 갈 것이다.
그래서 스펙을 쓰면서 나중에 코딩에 들어가기 전에 미리 한번 만들어보는 것이다. 이렇게 만드는 프로토타입은 되는지 안되는지만 검증을 하는 것이므로 최대한 간단하게 만든다.

회사의 코딩 규칙을 따르지도 않고
에러 처리도 제대로 하지 않고
주석도 달 필요가 없다.

제대로 개발하려면 1주일 이상 걸릴 것도 몇시간에 걸쳐서 되는지만 확인해보는 것이다.
그렇기 때문에 이때 작성한 소스코드는 버리는 것이다. 절대 재활용하면 안된다. 규칙도 따르지 않고 에러처리도 안되고 주석도 없는 코드를 재활용하는 것은 대단히 불안한 일이다.

이렇게 검증을 해나가면서 스펙을 적으면 프로젝트가 계획된 시간에 끝날 가능성이 점점 높아지게 된다.

그렇다고 모든 내용을 다 검증해가면서 스펙을 적을 수는 없다. 어떤 항목은 된다는 감을 믿고 그냥 적어야 할 때도 있다. 모든 것을 다 검증하면 비용과 시간이 너무 많이 들기 때문이다. 따라서 검증할 것을 적당히 조율하면서 어느정도 Risk도 감수를 하면서 프로젝트를 진행해야 한다. 이때 발생한 Risk는 별도의 Risk 관리를 통해서 제어를 해야 한다.

프로젝트는 "해봤더니 안되더라"가 아니다.
그렇다고 모든 것을 검증하면서 할 수는 더욱 없다.
적절한 프로토타입을 통한 검증과 적절한 Risk관리를 병행하는 것이 가장 효율적이다.

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다."

동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다.

우리나라 개발자들은 그 정도가 훨씬 심하다.

우리나라에서는 회사가 크던 작던 상관없이 대부분 5년, 10년 개발한 제품도 변변한 문서가 하나 없는 것이 현실이다. 이것만 보더라도 협업의 수준이 얼마나 낮은지 알 수 있다.

협업이란

1. 여러 사람들이 가지고 있는 지식과 경험의 도움을 받고
2. 서로 머리를 더해서 더 좋은 생각을 이끌어내 내고 
3. 일을 서로 나눠서 하는 것을 말한다.

이런 협업을 하는데 있어서 Template은 중요하지 않다. 협업이 필요한 내용이 공유를 할 수 있을 만큼만 적히면 된다. 적힌 것이 있어야 서로 공유를 하고 도움을 받을 수 있다. 만약 적히지 않고 머리 속에 있는 내용을 공유하려면 매번 말로 설명하는 수밖에 없다. 얼마나 피곤한 일인가. 또한 본인도 기억하지 못하는 사태가 벌어진다.
대표적으로 스펙과 설계는 협업이 매우 중요하다.
스펙과 설계를 제대로 적지 않고 리뷰를 하면서 계속 발전시켜나갈 수 없다. 한사람의 머리속으로 기억을 하면서 말로 공유를 하면 일을 서로 나눠서 개발하기도 어렵다.

하지만... 우리나라에서는 소프트웨어 개발을 할 때 변변한 문서도 없이 여러명이서 나눠서 개발을 잘도 한다. 물론 효율적으로 협업이 되지 않는다. 스펙과 설계가 불명확하여 개발자들이 코딩할 때 다 알아서 하고 나중에 통합도 잘 안된다. 스펙과 설계를 적기가 어려워서 최근에는 Agile 방법론이 인기를 끌고 있지만, 이것도 하나의 방법일 뿐이다. 

뭔가 적어야 할 때 Template을 꺼내놓고 틀에 맞춰서 적으려고 고민하기 보다는 서로 협의하고 확인을 받아야 하고 도움을 받아야 할 내용들을 적어서 수시로 리뷰를 하면서 진행을 해보라. Text 에디터로 Plain text로 적어도 아무 상관이 없다. 이렇게 효과적으로 적고 협업을 자주 하다보면 스펙과 설계를 어떻게 적어야 효과적으로 프로젝트가 진행이 될지 조금씸 감을 잡을 수 있을 것이다.

우리 식대로

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다.

 

체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을 해 놓은 회사도 있다. 

이 "우리 식대로"라는 것이 표준적이고 일반적인 방법과는 사뭇 달라서 어떻게 보면 기발하기도 한 것들을 많이 이룩해 놓은 경우가 있다.

 

소스코드 관리, 버그관리, 빌드, 분석, 설계, 테스트 등 전반에 걸쳐서 아주 독특하고 비효율적인 방법들은 너무나도 많이들 만들어 놓았다.

결론부터 말하면 주먹구구인 회사보다 "우리 식대로" 회사가 문제가 더 크다. 주먹구구인 회사는 백지와 같아서 하나씩 배워나가고 바꿔나가면 되는데, "우리 식대로" 회사는 바뀌기가 더욱 어렵다. 

"우리 식대로"는 충분한 경험과 통찰력 없이 나름대로의 방식으로 만들어 놓은 것들이라서 잘 적응해서 사용하고는 있지만, 효율이 높지도 않을 뿐더라 프로젝트의 규모가 커지거나, 개발 분야가 확대 되거나 Global한 Business를 할 때 꼭 문제가 발생한다.

 

이렇게 문제가 발생해도 "우리 식대로"에 익숙해진 사람들은

• 기존 방식이 익숙해져서
• 새로운 방식이 더 좋다고 믿을 수가 없어서
• 그 동안 투자한 것(Sunken cost)이 아까와서
• "우리 식대로"를 구축한 사람들이 정치적으로 방해해서
• 제대로된 새로운 방식 도입에 상당히 어려움을 겪게 된다.

그래서 나름대로 방식으로 뭘 해보려고 하면 나는 "하지 말라"고 한다. 소프트웨어를 개발하는 기본적인 원리와 체계는 대부분 표준적인 방법이 있고, 이를 먼저 익히고 경험한 후에야 "나름 대로 방식"으로 응용이 가능하다. 그러기 위해서는 남들은 또 외국에서는 어떻게 하는지 항상 관심을 가지고 있어야 한다. 

요상망측한 툴들을 만들어 놓고 뿌듯해 하지 말자. 나중에 발목 잡힌다.

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.

다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."

물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.

예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.

절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.

문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.

아래에 문서를 만드는 4가지 경우가 있다.

• 문서 거의 없이 개발하는 경우 (쓸모 없는 문서, 개발중에 안보는 문서, 나중에 문서를 만드는 경우도 여기 해당) 
• 스펙문서를 포함해서 한두개의 문서를 효과적으로 적는 경우 
• 각 단계에서 수십개의 문서를 철저히 만드는 경우 (거대 방법론)
• 거대 방법론을 흉내 내지만 문서는 거의 안보는 경우. 문서따로 개발따로 (우리 주변에서 흔히 보는 경우)
• 최종 결과물만 거대 방법론 흉내내는 경우. 나중에 제출용으로 문서를 만든다. (이것도 친근하다)

이중에서 당연히 권하는 것은 1번이고 다음은 2번이다.
3,4,5번 보다는 차라리 2번이 낫다.

문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.

일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.

SVN보다 Git가 더 좋을까?

요즘 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에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

2020년 7월에 추가한 내용

이 글을 작성한지 9년이 지났다. 그래서 주변 환경이 많이 바뀐만큼 결정의 기준도 바뀌었다. 9년 전인 2011년에는 git를 쉽게 지원하는 client도 시원치 않았다. 하지만 지금까지 많은 기술의 변화가 있었다. 그래서 SVN을 쓸지 Git을 쓸지 결론을 말하지만 다음과 같다.

• 회사에서 이미 SVN을 쓰고 있어서 Git으로 마이그레이션이 어렵다면 SVN을 써라.
• 발주사에서 SVN을 써야 한다고 하면 SVN을 써라.
• 그외에는 모두 Git을 써라.
• 회사를 새로 시작한다면 Git을 써라.
• SVN을 쓰고 있어도 Git으로 마이그레이션을 하고 싶으면 해라.
• SVN에서 Git으로 바뀐다면 Repository 전략을 바꾸어야 한다.

추가 의견으로 Git을 쓴다면 Cloud 서비스를 이용하는 것을 권장한다. 서버를 직접 관리하는 것보다 시간, 비용면에서 효율적이다. Github, GitLab, Bitbucket, Azure Repos 등이 있다.

같은 조건이라면 Git을 사용하기를 권장하지만, SVN을 사용한다고 큰 문제가 있는 것이 아니다. SVN을 잘 쓰고 있다면 계속 사용해도 문제가 없고, 시간과 비용을 들여서 Git으로 옮겨가고 싶다면, 시도해볼만 하다.