왜 항상 트랜드에 뒤쳐지는 걸까요? 

그게 참 궁금합니다.

git은 단순 형상 관리 툴인데, 이거 하나만 가지고 기술 트렌드가 뒤처졌다고 말할 수 있을까요? 

겨우 git 하나 가지고 뒤처졌다고 키득거리는게 더 한심하네요.

솔직히 인정할건해야져 ㅋㅋㅋㅋㅋㅋ 지금 SI 만 봐도 기술트렌드는 갖다 버린지 오래인데 

뒤쳐지는게 당연한게..

영->한 번역 기다려야죠ㅋㅋㅋㅋㅋ

개발이든 뭐든 전세계 주력 언어는 영어고요
한국 인구 5천만 밖에 안되는데다 ( -> 번역할 노동 인구 + 번역물 소비층)
영어가 메인언어가 아니라서 어쩔 수 없죠ㅠ

오늘도 애타게 번역을 기다리는 1인 입니다ㅠ

저는 형상관리를 3년 전 프로젝트에서 svn 설치했습니다.

이유는 아래와 같습니다.

1. 먼저 깃을 써본 사람이 없습니다. 사원 빼고는 써본 사람이 없습니다.

대리, 과장, 차장, 부장 그리고 고객사까지 깃을 써본 사람이 없습니다.

깃을 쓸려면 알아야 쓰는데, 누가 교육하나요?

교육해줄 사람도 없고, 교육 받을려거나 스스로 공부할 사람도 없습니다.

2. 기능 차이가 없습니다.

깃이던 svn이던 '우리의 프로젝트에서 원하는 기능'은 차이가 없습니다.

말 그대로 '형상관리'만 되면 됩니다.

브랜치, 마스터브랜치, 푸시, 로컬 커밋 등... 다 필요없는 기능입니다.

svn은 '커밋은 커밋이야'로 끝납니다.

git이 공학용 계산기 느낌이고, svn은 탁상용 계산기 느낌이죠.

그리고 svn은 svn이고 git은 git이라고 별도의 프로그램으로 봅니다.

구글크롬과 파이어폭스, 사파리, 익스플로러처럼 말이죠.

@콘푸로스트

1. SI 차세대에서 git을 써본 사람이 없어서 제가 직접 git 사용법, git branch 전략을 가이드 했습니다.

2. git과 svn이 정말 차이가 많이 납니다.

svn도 잘 사용하기는 했지만, git 쓰다보면 svn이 엄청 답답하게 느껴집니다.

괜히 이 글을보고 정말 svn을 고집하는 분이 생길수도 있을거 같아 댓글 남겨 봅니다. 사용 안해보신분들은 사용해 보시길 추천합니다.

위의 의견에 덧붙혀

1. 교육해줄 사람도 없고, 교육 받을려거나 스스로 공부할 사람도 없습니다

=> 왜 먼저 학습해서 알려주고 전파할 생각을 하지 못할까요

2. 브랜치, 마스터브랜치, 푸시, 로컬 커밋 등... 다 필요없는 기능입니다.

=> 이런 분에게는 '형상관리' 자체가 필요 없습니다. 그냥 수정할때마다 파일 복사해서 백업해두는거랑 뭐가 다릅니까

우리나라에서의 git 트렌드가 세계적인 시점과 차이가 나는 이유는 바로 @콘푸로스트 님의 댓글을 보면 잘 아실거라 생각되네요.

load2000 

말은 참 번지르르 하시는데, 교육하고 전파하는게 말이 쉽죠. 한두명도 아니고요.

고객사도 가르치실려구요? 

참 이상적이신 분이네요

콘푸로스트 /

>>>>> 깃이던 svn이던 '우리의 프로젝트에서 원하는 기능'은 차이가 없습니다.

>>>>> 말 그대로 '형상관리'만 되면 됩니다.

>>>>> 브랜치, 마스터브랜치, 푸시, 로컬 커밋 등... 다 필요없는 기능입니다.

왜 전세계가 Git에 열광하고 있는지, 그 이유에 대해 아직 1%도 이해하지 못하시는 것 같군요.

콘푸로스트

고객사에서 svn을 쓴다면 어쩔 수가 없죠. svn 도 훌륭한 형상관리 도구입니다.

그런데 고객사에서 하는 일 이외에는 전혀 git을 쓸 생각을 안해보신건가요?

안해보신 이유가 정말 "브랜치, 마스터브랜치, 푸시, 로컬 커밋 등... 다 필요없는 기능입니다." 이렇게 생각하시는 거라면

한번 요즘 개발 방법과 트렌드에 대해서 스터디라도 한번 참여해보시는걸 추천드립니다.

svn이 안좋고 git 이 최고다! 이걸 주장하는게 아니라

svn의 불편함을 개선해서 만들어진게 git이고 실제로 많은 사람들이 그 편리함에 git 으로 마이그레이션을 하고 있습니다.

추가로 이상적이라는 칭찬은 감사합니다.

제가 몇년전에 갓 신입 벗고 이직한 회사에서 svn을 아무 전략없이 지금 콘푸로스트님 처럼 백업용도로 사용하고 있길래

몇날 몇일 준비해서 연구소 소장님 이하 모든 it담당자 들에게 git에 대해서 소개하고 바꿔야 하는 이유에 대해서 설명해서 전사적으로 다 바꿨습니다.

일단 되든 안되든 부딪혀보면 이상도 현실이 됩니다.

신기술을 도입할 때 프로젝트의 일정이나 팀원의 수준 등을 감안해서 현실적인 접근을 하는 것은 좋은 것입니다. 하지만 어디까지가 '현실적인 접근'이고 어디서부터가 새로운 것을 배우는 데에 대한 거부감이나 귀찮음을 정당화하는 것인지는 명확하게 구분할 필요가 있습니다.

우리나라가 소프트웨어 분야에 있어서 세계적인 기술 동향을 5년 쯤 격차를 두고 따라가는 건 분명한 사실이고, 새로운 기술은 써보지 않으면 필요성 자체를 느끼지 못하는 것도 당연한 일입니다.

90년대 사람들은 지하철을 타면서 지구 반대편에 사는 사람의 개인 방송을 실시간으로 시청할 수 없다는 점을 불편하게 생각하지 않았습니다.

깃과 비교한 서브버전의 단점들도, 마찬가지로 더 나은 무언가를 경험해보지 않으면 깨닫지 못하는 불편함입니다.

우리나라 특성이죠

하지만 도입하고 따라잡는 속도도 탑이죠

애초에 우리나라는 git이 유리한 상황이 아닙니다.

git은 여러 사람이 협업하기 유리한 여러가지 svn에 없는 기능들을 제공합니다.

로컬로 스테이징 커밋 후 푸시해서 공유하는 방식이라 잠시 오프라인일 때도 사용이 가능하죠.

근데 우리나라에서 중요한 프로젝트들은 하나같이 "망분리"된 환경에 있습니다.

민감한 프로젝트의 경우는 파일 하나하나마저 개발환경내에 넣거나 뺄때마다 위쪽 결재 받아야 가능하죠. 외부 인터넷 접근 당연히 안되니 npm 이나 gradle maven도 오프라인 모드로 써야 하구요.

이러니 애초에 git의 이점 자체가 의미가 없습니다. 오히려 궂이 커밋하고 푸시를 분리한 불편함만 있을 뿐.

이렇듯 모든 새로운 기술들이 무조건 좋은 게 아닙니다.

단순 게시판 만드는데 하둡이나 몽고DB 같은데다 넣을 필요는 없잖아요? 그냥 기존 DB 쓰면 편한데.

HJOW // RDBMS와 NoSQL은 용도가 다르지만 깃은 완벽하게 서브버전의 상위 호환입니다.

그리고 설사 우리나라의 SI 환경에서 깃을 쓰기 힘든 이유가 있다 전제를 해도 그건 결국 신기술 도입을 방해하는 후진적인  "한국적 IT 환경"이 있다는 이야기로 귀결됩니다.

우리나라 IT 업계가 기술 추세를 못 따라가던지 못 따라가게 하는 후진적 특징이 있던지 그게 서로 크게 다른 이야기 같아 보이진 않습니다.

fender// 완벽한 상위호환은 아닙니다.

git이 svn대비 불편한 게 한두 가지가 아닙니다. 근데 그게 git의 근본적인 구조에 기인한지라...

git때문에 소스코드 날릴 뻔한 적도 한두번도 아니고, 그렇다고 롤백명령 날리면 이번엔 내가 작업한게 날라가는 상황이 펼쳐지고

그때문에 결국 폴더째로 압축해서 날짜별로 보관하는 기현상이 생겨나죠. 몇몇 기능은 명령어를 외워서야만 사용이 가능하고. 근데 SVN은 이런일이 웬만해선 일어날 수가 없습니다.

"git에 익숙하지 않다"로 끝내기엔 이런 사람이 엄청나게 많다는 것

여기 okky에서 git 관련 문의글에서 해결책이라는 게 명령어 실행하라는 것만 봐도 문제라는 인식이 있어야 합니다. 코딩 외 모든 조작은 GUI로 가능해야 하는 게 맞습니다. git은 그렇지 않습니다.

브랜치의 경우는 SVN 불편한 건 맞습니다. 근데 쓸 일 자체가 없어서... 특정시점 기준으로 프로젝트 자체를 분기하는 방법은 얼마든지 있으니까요. 병합할 수가 없어서 문제지. 이 브랜치 병합이 용이하다는 부분에서는 git이 확실히 좋긴 합니다.

물론 외부 오픈 가능한 프로젝트이고, 노트북 들고 나가서 작업이 가능하면 git의 장점을 여실히 체험할 수 있죠.

git이 svn대비 불편한 게 한두 가지가 아닙니다. 근데 그게 git의 근본적인 구조에 기인한지라...
git때문에 소스코드 날릴 뻔한 적도 한두번도 아니고, 그렇다고 롤백명령 날리면 이번엔 내가 작업한게 날라가는 상황이 펼쳐지고

솔직히 이건 깃의 "근본적인 문제"가 아니라 HJOW님이 서브버전 만큼 깃에 익숙하지 않아서 발생하는 문제인 것 같습니다.

반면에 디렉터리 이력을 관리할 수 없다던가 브랜치 관리가 불편하다던가 기본적으로 스태싱을 지원하지 않는다던가 하는 건 서브버전의 근본적인 단점이 맞습니다.

git이든 svn이든 결국 도구일뿐이고, 뭐가 됐든 일하는데 지장이 없으면 굳이 git과 svn가지고 기술 수준을 논할 필요가 있는가 생각합니다. 구글이나 페북같은 회사들도 git 을 안쓰는데, 그걸로 기술수준이 낮다고 말하기는 힘들겠죠.

그리고 git의 러닝커브가 높은 점은 분명 git의 "근본적인 문제"라고 할 수 있습니다. 기능적으로 보면 git이 좋긴 합니다. 하지만 너무 많은 기능이 있는 바람에 잘 못 사용하다간 이력이 꼬여버리는 건 큰 문제라고 봅니다. git을 보면 저는 C가 생각이 납니다. 뭐든 할 수 있지만, 전적으로 사용자가 책임을 져야하죠.

그런면에서 저는 mercurial이 참 좋은데 사람들한테 인기가 없네요. 쉽게 이해할만한 git보단 단순한 branch모델을 제공하고, 약간은 제한된 workflow라서 실수할 여지도 줄어들고, 배우기도 쉬운데, 왜이리 인기가 없는지... bitbucket도 지원종료하고...

대충 이런 겁니다.

저는 십 년 넘게 피처폰을 쓰고 있고 그건 그냥 귀찮아서입니다. 누군가 그걸로 제가 현대 문명에 뒤떨어진 사람이라고 한다면 잘못이겠죠. 아이패드는 잘 쓰고 있으니 스마트폰의 장점을 모르는 것도 아니까요.

그런데 만약 요즘 시대에 어느 나라 국민의 80%가 피쳐폰을 쓴다면 어떤가요?

그건 분명 무언가 구조적인 문제가 있는 상황이라고 보아야 합니다. 국가의 통신 인프라나 경제 수준 등이 심각하게 망가져있지 않으면 2021년에 그런 통계가 나오긴 쉽지 않으니까요.

그리고 깃이건 프론트 기술이건 세계적인 기술 동향에서 보급률이 보통 5년 씩 뒤쳐지는 건 그런 부류의 문제로 보아야 합니다.

비슷한 이야기로, 나이 지긋한 어르신들이 스마트폰 활용을 못 한다면 그것 또한 단순히 취향의 문제는 아닙니다. 그 분들 한테 스마트폰 사드리면 능숙하게 인터넷 검색하고 유튜브 찾아보고 할 수 있는데 취향이 달라서 안 하는 것이 아니니까요.

우리나라 SI 현장에서 아직 서브버전 사용하는 곳이 많다면 솔직히 그런 프로젝트 참가자 대부분이 깃도 주요 기능을 잘 알고 있고 그 이상 능숙하게 사용할 줄 알지만 개인 취향 같은 문제로 그런 선택을 한 것은 아닐 겁니다.

신기술 도입 같은 건 개인의 선택일 때는 취향의 문제이지만 통계로 잡히는 보급률 같은 것이 현저한 차이를 보인다면 거기서부턴 구조적 문제를 의심해 보아야 하는 것입니다.

저도 SI 개발을 오래했고 git, svn, cvs, source safe 등을 몇년씩 써본 입장에서 정리해 드립니다.

1. git이 svn 상위호환 맞습니다.

2. git이 svn 보다 배우기 어렵다. 

 - svn 수준으로만 쓰려고 해도 git이 알아야 할 +알파가 있기는 합니다.

 - 새로운걸 받아들이기 어려운 사람 한정으로 분명 단점입니다.

 - 프로젝트에서 svn, git을 모르는 사람에게 둘다 5분이면 기본적인 사용가이드는 전파할 수 있었습니다.

3. 위에 언급한 대부분의 git 단점은 잘못된 정보입니다.

 - 커밋하고 푸시가 단점인가? → svn에 대비 git의 최고 장점입니다. svn은 작업이 완료된 후에 커밋이 기본 가이드이기에, 나만 알고 있는 변경이력 관리가 안되죠.

 - git을 사용하면 소스코드가 날라가나? → 이건 좀 근본없는 예시네요. rebase를 모르시는거 같습니다.

 - 롤백명령 날리면 이번엔 내가 작업한게 날라가는? → reset 얘기인거 같은데, 역시 rebase를 모르시는거 같습니다.

 - git이 gui로 모든 조작이 불가능한가? → 일반적으로 프로젝트에서 사용하는 기능들은 모두 gui로 사용 가능합니다. (eclipse의 경우, svn이 추가 셋업없이 사용가능한 적이 없었습니다. git은 몇년전부터 기본으로 탑재되어 있구요.)

4. svn이 디렉터리 이력을 관리할 수 없지는 않는데, svn을 써본지 너무 오래되신거 같네요.

5. git 단점은 커밋ID를 16자리(보통 4자리로 축약해서 쓰지만) 기억하기 뿐입니다. 이건 마치 김수한씨를 찾는게 아닌 김수한무두루미~를 찾는 느낌이랄까..

6. svn은 단순히 소스형상만 관리하지만, git은 소스형상관리 + 알파가 있습니다.

소스코드를 수정하는데 VSCode 보다 메모장이 편한 개발자가 있을수 있죠.

옆에서 보는 개발자는 답답합니다. 

심지어 옆 개발자한테 메모장 편하니까 메모장을 써야 한다고 한다면, 같이 일하고 싶을까요?

단순히 git vs svn 구글 트렌드 결과로 구조적인 문제까지 가야 하나 생각합니다. 언어적인 문제, 산업구조의 문제, 문화의 문제 등등 여러가지가 겹쳐있겠죠. 저걸 다 고쳐야할 문제라고 할 수도 있겠습니다만.

결국 결론은 git을 쓰는게 선진적인가, 훨씬 우수한가라는 점에 있겠습니다. 트렌드로 보면 분명 한국에서 svn이 세계평균보다 오래 살아남은 것 같네요. 한국의 여러가지 상황에서는 svn의 단점, git의 장점이 덜 부각되었다고 볼 수 있겠죠. 그래서 그것이 문제인가? 그건 잘 모르겠습니다. 한국개발자 대부분이 귀찮아서 svn을 계속 썼는가? 그럴수도있고 아닐수도 있죠. 대부분의 개발자가 시도했지만 러닝커브를 이겨내고 배울만한 큰 매력이 없었을 수도 있습니다. 이걸 단순히 귀찮아서라고 표현할 수도 있지만, 손해득실을 따져서 나오는 결론이라고 할수도 있습니다. 이렇게 된데에는 구조적인 문제라고 해도 좋고, 한국의 상황이 그래서라고 할 수도 있습니다.

결국은 돌고 돌아서 구조적인 문제인가라는 결론은 git을 쓰는 것이 우수한 개발자인가와 같다고 볼 수 있겠네요. 좀 더 나아가면 SI는 나쁜 개발이고, 네카라쿠같은 서비스는 좋은 개발인가? 제조업은 나쁘고 서비스업은 좋은가? 이런 거랑 비슷한 맥락이라고 보여집니다.

IE 와 크롬(및 크로스 브라우저) 논란하고 하나도 다른 게 없는 얘기네요...

그때도 IE 정당화 하는 분들 몇몇 있었죠.

하지만 요즘 당장 대기업들부터 IE를 버리려고 하는 추세입니다.

이미 만든 프로젝트는 어쩔 수 없다 쳐도, 차기 프로젝트의 요구사항 중 하나가,

"우린 크롬만 쓸거나 크롬에 맞게 설계해 달라" 입니다. 심지어 가장 입김이 센 사업팀에서 나오는 얘기죠.

그게 한 5년전 얘기죠. 크로스 브라우저 붐이 일어나고 꽤 오랜 시간 지난 얘기지만.

지금 보면 꽤 옛날 얘기입니다.

조만간 형상관리도 같은 수순을 밟으리라 봅니다.