-
Notifications
You must be signed in to change notification settings - Fork 10
/
0161.txt
30 lines (16 loc) · 15.3 KB
/
0161.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
안녕하세요 포프입니다. 제가 언제나 프로젝트를 시작할 때 가장 먼저 보는 게, Source Control System(또는 Version Control System, VCS)이에요. 소스 Repository를 어디에 둘 건지에요. 옛날에는 다 호스팅 했었고요. 요즘은 온라인에서 해주는 게 많으니까, Git이나 Mercurial 많이 쓰는데, 소스 컨트롤 시스템 솔직히 몇 번씩 다뤄 본 거 같기도 하고, 어찌 보면 굉장히 호불호가 갈리는 부분이기도 해요. 제가 예전부터 언제나 주창했던 게 그랬잖아요. "세계 최고의 VCS는 Perforce다." 확실히 ~~폽씨~~ 이런 게 없어요. 돈이 든다.
그렇고 Perforce의 단점은 Centralized Version Control System. 중앙에서 Control 하는 시스템이기 때문에 SVN이나, Git이나, Mercurial처럼 내 컴퓨터에서 고친 다음에 한꺼번에 밀어 넣을 방법도 없고요. 로컬에 미리 Commit을 해 놓았다가 마지막에 sync만 시키는 방법도 없었어요. Perforce에서 뭔가 만들긴 만들었었는데 개판을 쳤었죠.
그게 문제였어요. 그래서 저도 최근에는 이제 웹 쪽 일을 많이 하고, 바이너리 파일을 넣을 일이 없으니까 Git이나 Mercurial을 많이 썼거든요. 그런데, 요즘 솔직히 Git으로 돌아갔어요. 사실 Mercurial이 Git보다 훨씬 좋아요. 그런데 Git을 쓰는 이유는 Visual Studio에서 Git을 지원하고요. Mercurial 지원해 달라는 사람들의 요청이 매우 많았어요. 1,300명이 넘게 Feature Request로 vote를 했어요. 그런데 Visual Studio에서 안 한다고 이미 Git 지원하니까, Mercurial 지원은 안 하겠다고 했어요. 그래서 Mercurial 지원이 안 되는 걸 알고 나서, Visual Studio Online나 TFS(Team Foundation Server)에서 Git을 지원하잖아요? 그래서 Git을 쓰고 있었는데요. 최근에 이제 또 다른 프로젝트를 하는 게 있으니까, 알아보고 또 한 번 뒤져 봤었죠. 뒤져봤는데 Perforce에서 새로운 버전 확인 시스템을 만들었어요. 그것도 클라우드에서 호스팅되고 Distribute도 완벽하게 되는 거죠. 그걸 Perforce Helix Cloud라고 하더라고요. 드디어 Git처럼 Distribute 버전 컨트롤을 만든 거죠. 내 컴퓨터에서 Check-in하고 다른 쪽에서 Commit하고 Push 할 수 있도록 이요.
Git이나 Mercurial을 사용해 보신 분들은 아시겠지만, 여태까지 쓸데없는 제약이 많아요. 바이너리 파일 넣기 시작하면, 용량 커져서 깨져서 안 되고, Git Repository 만들었을 때, 크기가 1GB, 2GB 넘어가면 느려지니까 라이브러리별로 Repository를 나누고, Folder 별로 Sync를 하라느니 등이 있었죠. 근데 솔직한 얘기로 Sub-module 만들지 않으면, Git과 Mercurial 쪽에서 언제나 그 얘기를 해요." 사용자가 버전 컨트롤 시스템을 잘못 쓰고 있다."고요. 근데 그게 옛날에 엄청 구리던 버전 컨트롤 시스템들이 다 우겼던 말이에요. SVN도 그런 식으로 이상한 얘기 했었고, 그전에 나왔던 CVS(Concurrent Versions System)이었나? 뭐 그것도 이상한 소리 했었는데요. Perforce가 나오면서 "웃기지 마. 우리가 알아서 해 줄게"라고 했죠. Perforce는 바이너리를 주구장창 넣어도 됐었고요. Binary 몇 TB 넣어도 문제없이 돌았어요. 그게 Perforce였어요. 한 마디로 사용자 몇천 명을 때려 박아도 (버전 관리 시스템이) 안 죽는 거죠. SVN은 파일이 많아지면 죽잖아요? 그런데 Perforce는 사용자가 몇천 명이 넘어가도 안 죽고요, 파일 사이즈가 몇 TB가 넘어가도 안 죽는 정도에요. 그 정도로 대단한 버전 컨트롤 시스템인데, Perforce가 분산 시스템을 제대로 처음부터 만들었다고 해요. 그리고 굉장히 기능들이 괜찮아요.
1. 사용자가 몇천 명이어도 상관없다.
2. 용량 제한 때문에 보통 Git repository 나누라고 그러죠? Perforce는 크기 제한 없어요. 파일 마구 넣어도 됩니다.
3. Git Repository의 Head branch에서 Repository 전체를 Clone 한 다음 사용하잖아요? Perforce에서는 이렇습니다: 필요한 Folder만 골라서 쓸 수 있습니다. Git Repository는 전체가 하나로 묶여있지만, Perforce에서는 필요한 Sub Section만 골라서 Sync 및 Commit 할 수 있대요.
한 마디로 버전 관리 시스템이라면, 당연히 위에서 언급했던 기능들을 지원했어야 하는 거죠. 당연히 Distribution 시스템의 장점이 있고 그것 때문에 다른 것을 포기할 수는 있겠지만, 그게 발전하면 할수록 지원해줘야 맞거든요. 양쪽의 장점을 살려서요. 그런데 Git이나 Mercurial은 "우리 시스템은 원래 이런 거야. 너희가 잘못 사용한 거야."라는 마인드 셋을 갖고 있었기 때문에, 오히려 불편함이 컸어요. 그리고 Merge Engine도 별로 안 좋은 경우도 많았고요. 뭐 여러 가지 문제가 많았죠. Git이 더 문제가 많았어요. 그래서 이번에 Perforce Helix Cloud를 런치를 한다고 해요. 공짜라고 하는데 어디까지 공짜인지는 모르겠고, 아직 베타 서비스거든요. 저희도 한 번 써보고 확인해보려고 Beta에 Sign-up을 해 놨어요. 근데 일단 Perforce가 여태까지 어떻게 Enterprise 수준의 Version Control System을 운영해왔는지 알고 있고요. 저번에 한 번 만들다가 p4 Sandbox가 실패한 경우가 있었고요. 이번에 처음부터 제대로 만들어서 그걸로 완벽히 밀고 있는 것 보고선, '어쩌면 Perforce는 제대로 하겠다.' 생각이 들었고, 굉장히 기대를 많이 하고 있어요. 나오면 바로 써 볼 생각이고, 혹시나 관심 있으신 분들은 한 번 찾아보세요. 저도 보고 나서 '이게 정말 괜찮으면 난 Git 버리겠다.' 생각이 들더라고요. 그거를 말씀드리고 싶었고, Git하고 Mercurial을 좀 깠는데요. 한 번 더 까자면, (예전에 했는지 아닌지 모르겠어요)
1. 얼마 전에 페이스북에서 한번 그 '우리들이 어떻게 Mercurial을 빠르게 만들었는가?'라는 그런 단체로 Paper를 블로그에 포스팅해 나가는 게 있었어요. 여기 되게 재밌는 얘기가 있었어요. 얘네들이 'Git과 Mercurial 중에 뭐 Mercurial을 고른 이유'를 말했어요. 그 이유는 Git은 본인들이 고치기가 되기 어려운 구조래요. 뭐 이런저런 설명을 해요. 근데 Mercurial은 성능 향상을 위해 코드를 고치고 Contribution 해야 하면 (Open-Source니까) 그럼 자기네가 더 쉽게 할 수 있어서 Mercurial을 골랐다고 해요.
2. 두 번째로는 되게 재밌는 게 그거예요: '왜 우리는 성능을 향상해야 했는가?' 페이스북 매우 큰 회사잖아요. 사람들이 그곳에서 굉장히 많이 일하고요. 근데 걔네는 Repository가 단 하나예요. Git이나 Mercurial에서 하는 얘기는 File Size 1GB 넘어가면 안 되고, 느려지고 하니까 Repository를 잘게 라이브러리별로 자르라고 그러잖아요? 해 보시면 알겠지만 그건 정말 더러워요. 그 문제를 해결하기 위해서 뭐 bat 스크립트 작성한 후, 처음 실행하면 알아서 Folder 만들어주고, Sync 해주고 이런 것들이 있었고요. 근데 문제는 sub-repository를 여러 개를 건들다 보면, 이런 일들이 워낙 많거든요. 리팩토링하다 보면 어떤 라이브러리 하나 고치면, 다른 라이브러리들도 다 고쳐야 하거든요. 그러다 보면 Check-in 해야 하는데, Repository가 여러 개다 보니까, 여러 개가 Check-in과 Push가 들어가야 해요. 그걸 해주는 bat 스크립트도 있지만 깨끗하진 않아요.
근데 페이스북이 하는 얘기가, "우리 직원들이 많이 일하다 보면, 내 코드만 보는 게 아니라 다른 사람들 코드 보는 일도 많고 코드 고칠 일도 많은데, 그걸 어떻게 sub-repository 만들기도 되게 어렵고 관리도 어려워지니 하나로 합쳤다. 그 대신에 이게 느려지면 우리는 애들 때려 박아서 Mercurial로 고쳐서 굉장히 빠르게 만들 것이다." 그리고 실제로 Mercurial을 굉장히 빠르게 만들었어요. 인원이 매우 많고, 그렇기 때문에 Mercurial 중간에 Memory Cache 넣고, 이상한 짓 다 해서 엄청 빠르게 만들었다고 해요. 그런데 제가 느끼는 소스 컨트롤 시스템은 솔직히 이렇거든요: 소스 컨트롤 시스템이 어찌 보면 Dev 프로세스 자체를 느리게 하거나 방해하면 안 된다고 생각해요.
물론 Commit이 Local에서 되고 그런 게 되게 빠르게 해주긴 하지만, 그 외에 여태까지 잘 되던 것을 그 패러다임이 바꿨다고 해서"다 틀렸어!" 이렇게 돌아가라고 지시하는 것보다는, '그 패러다임을 어떻게 서포트할 수 있을까?'라고 생각을 해야 하는 것이거든요.
또 페이스북이 Mercurial을 개선한 이유도 그거고요. Perforce Helix도 지금 그러고 있는 것 같아요. 문제는 아직도 Git의 사용자층이 굉장히 두껍잖아요. 사실 오픈 소스 기반으로 GitHub을 기반으로 한 것도 있고, Git 사람들은 또 그럴 거예요 "그것은 올바른 방법이 아니다." 라고요. 근데 제가 볼 때 올바른 방법은, 개발자로서 내가 쓸데없는 시간 낭비하지 않고 제가 빨리 개발할 수가 있고, 편하게 개발할 수 있는 환경이거든요. Repository 하나 다 처박고 그 안에 다 할 수 있다면 저는 무조건 Repository 하나로 가요. 당연히 그걸로 가지 누가 미쳤다고 Repository를 여러 개 나눠서 Clone 몇 번 하고 그런 걸 신경을 왜 써야 하죠? 아니면 말 그대로 Dropbox Sync 하듯이, 폴더 선택할 수 있게 Sync 하면 되는 거죠. 그래서 지금 볼 때는 물론 Perforce Helix가 Git을 완벽히 누르지는 못할 거예요. 왜냐하면, Helix는 아무래도 Enterprise 쪽으로 지원을 많이 하는 거고, Git은 지금 웹 쪽으로 많이 접목되어 있으니까요. Perforce가 결과적으론 Centralized Version Control System에서 결국 왕좌를 차지했듯이, 제가 볼 땐 Helix나 Mercurial에서 Optimization 제대로 한다면, 걔네가 (왕좌를) 넘겨받을 수도 있고 아니면 Git이 드디어 정신을 차려서 그리고 Mercurial Core도 정신을 차려서 그런 걸 이제 제대로 지원하는 방법을 생각할 수 있겠죠.
또 어찌 보면 Git이나 Mercurial 굉장히 획기적이고, 굉장히 좋은 물건이었는데요. 사실은 처음 컨셉 나온 이후로, '굉장히 거기에 안주하고 발전을 안 하는 게 아닌가?'라는 생각이 좀 들긴 해요. 엔터프라이즈 쪽의 demand나 필요성도 별로 못 느꼈던 것 같고, 그저 오픈 소스 커뮤니티 기반에서 fork 해서 이거하고, 저거 하는 데만 신경을 썼었지, 정말 회사 안에서 굉장히 커다란 Repository 하나 돌리고, 프로젝트를 Manage 하는 것들을 좀 깊이 생각하지 못한 면이 있는 것 같아요. GitHub Enterprise가 나오고는 있지만, 그것도 역시 한계가 있어요.
그리고 바이너리 지원 안 되는 게 단점이 가장 크죠. 버전 컨트롤이 바이너리를 왜 지원 하냐고 그러는데, 그것도 좀 걸고 넘어가야 해요. 바이너리 버전 컨트롤해야 해요. 안 하는 게 말이 안 되죠. 그럼 아티스트들은 버전 컨트롤 어떻게 하라는 거죠? 전에 있던 이미지 이번에 새로 만들었어요. 아티스트 입장에서는 코드가 아니니까 버전 컨트롤 안 해도 된다고 말해요. Diff도 안 되고. 사실 이미지도 Diff 할 수 있거든요? 왜냐면 MPEG도 그렇게 돌거든요. 물론 Lossy Compression이긴 하지만, 어차피 Diff는 다 돼요. 바이너리 스트림 뽑아 쓰거나 아니면 세션별로 나눠서 Diff 할 수 있어요. 그리고 이미 ~~Analysis of Merge~~ 라던가, Perforce Merge Tool 이미지 Diff 보여주는 것도 이미 나왔고요. 안 되는 게 아니잖아요? 그럼 Diff 지원해주고 그 Diff만 저장하던지요. 근데 이거는 프로그래머만을 위한 버전 컨트롤 시스템이라는 식으로 말해요. 저도 웹 개발하지만, 디자이너 들과도 협업 많이 하거든요? 저희도 이제 디자인 파일 받고 이미지 처리하고 그러거든요? 그걸 Version Control로 못한다는 게 참 웃긴 일인 것 같아요. 그리고 어떤 경우에는 진짜 Source Code 없이 dll 파일만 코드에 처박아야 할 수도 있어요. 그럼 그것도 바이너리 diff 해야 하고 복잡해지고 어쩌고저쩌고... 그래서 제가 생각할 때는 회사에서 일하는 상황에서 '과연 바이너리 지원 안 하고 소스 컨트롤이라고 부를 수가 있지?'라는 생각이 가면 갈수록 드는 거예요. 아무리 순수 웹 사이트 회사여도 그건 불가능하거든요. 뭐 이건 Dropbox에서 버전 관리를 하라는 얘긴지... 똑같은 얘기로 Folder 하나에 집어넣고 시스템 하나만으로 관리하면 편한 걸 왜 여러 개를 쓰냐는 얘기죠. 한 마디로 이메일 도메인 여러 개로 hanmail.net은 개인 메일로 쓰고, gmail.com은 스팸메일로 쓰고 이러는 것보다 도메인 하나로 합치면 편하잖아요? 물론 하나로 합칠 때 불편함도 있겠지만 필터 기능이 좋으면 되는 거니깐요. 그걸 좀 생각해서 개선하기보다는, "이건 원래 그런 거다. 우리는 이렇게 쓰니까 우리가 맞는 방향을 알려주는 순수 주의자다." 이렇게 VCS가 발전을 안 하려고 하는 것들이 솔직한 얘기로 좀 아쉬웠어요.
얘기가 좀 샜는데, 결과적으론 분산 버전 관리 시스템도 이제는 어느 정도 좀 쓸 만해질 것 같아요. 이제 Helix처럼 그렇게 새로운 것들이 개선되고 있으니까, 페이스북에서도 그런 걸 좀 냈고 사람들이 그것에 대한 필요성을 좀 더 알아 갈 것 같고요. 이제 Helix가 제대로 돌고, 클라우드 돌리기 시작하고, 사람들이 많이 Helix로 건너가면 아무래도 Git에서도 그걸 생각하기 시작할 거고요. 뭔가 좀 더 나은 방법이 나오기 시작하겠죠. 일단은 앞으로 1~2년 뒤에는 정말 쓸 만해질 것 같아요. 그렇게 Git 요즘 많이 쓰면서 저렇게 문제점도 보이고 이것저것 보고 있는데요. 조만간 나아질 것 같고요. 그리고 게임 개발하시는 분 중에 그런 Distributed Version Control System을 생각하시는 분들은 Mercurial 여러 개 연동하고, DropBox Hack 같은 삽질을 많이 하셨을 것 같아요. 저도 해봤거든요. 그거 할 시간 있으면, 대신 Perforce를 해보시라고 전해주고 싶어요. 공짜라고는 하는데 어디까지가 공짜인지 모르겠어요 아직 정확한 가격대가 안 나와 있으니까. 'GitHub하고 비슷한 모델로 가지 않을까?' 이런 생각도 들고요. 아니면 용량 따라갈 수도 있고요. 그리고 Helix를 자기 컴퓨터에 깔아서 쓰는 법도 있대요. 그러나 License를 사야 하겠죠. 공짜는 아니니까요. 하시고 싶으신 분들은 시도해보면 좋겠고요. 이리저리 말이 많았으니 오늘도 이 정도로 끝마치죠. 방이 더워요. (웃음) 끊을게요. 포프였습니다.