Github는 git이 아니다
D+12
그래 나는 건축 소프트웨어 엔지니어 오늘은 기술에 대해서 이야기해본다. 개발 이력관리를 위해서는 git이용이 필수적이다. 대부분의 사람들은 git=github라고 생각한다. 사실 나도 그런 면모가 강하다. 하지만 오늘은 git이 무엇인지 나 나름 대고 정리해 보고, 그래서 우리에게 이게 왜 중요한지 논해보려고 한다.
git은 스냅숏이다
프로그램 개발뿐만 아니라 건축 프로젝트도 각각의 기한이 정해져 있다. 예를 들면 콘셉트단계, 실시단계 등등 해당 단계별로 결과 물을 한 세트로 묶고 그 이력을 관리하는 게 중요하다. 물론 실제 데이터는 마치 날아다니는 스파게티처럼 여기저기 날아다니지만.
이런 일들을 방지하기 위해 각 단계별로 스냅숏을 만들어서 파일을 관리하는 것이 무척 중요하다. 안 그러면 한 프로젝트가 끝났을 때마다 "도대체 우리가 뭘 한 거지"라는 물음만 남는다.
나도 바쁘게 프로젝트를 할 때 힘든 점은 파일의 이력관리를 하는 것이다. 가령 Rhino로 작업을 할 때 프로젝트가 진행됨에 따라서 내용이 변경되게 된다. 이 내용을 보통 layer로 나눠서 정리하곤 한다. 하지만 솔직히 그것도 한계가 있긴 하다. 왜냐하면 그 형상뿐만 아니라 그렇게 된 이유에 해당하는 다양한 파일들도 한 묶음으로 있어야 "그때 그래서 이렇게 했지"라고 기억해 낼 수 있었다. 만약 해당 시점에 내가 참고했던 파일과 그 결과로 만들어진 것은 한 세트로 만들고 관리하고 싶다면? git을 썼더라면이라는 생각이 든다.
그리고 git을 사용하는 게 폴더로 정리하는 것보다 훨씬 경량이다. 왜냐하면 git은 데이터가 바뀌면 새롭게 저장하지만, 그렇지 않으면 파일을 있는 그대로 둔다. 보통 폴더로 관리할 때 기존 파일을 그대로 복붙하고 어떤 내용들을 다시 덧붙이거나 삭제하거나 하는 것을 생각해 보자. 그렇다는 것은 중복되는 내용이 있음에도 해당 내용은 중복 저장이 되고 있다는 뜻이다. 이런 이유로 폴더로 관리하는 체계가 git으로 관리하는 것보다 용량을 많이 차지한다.
git은 사실 local로 대다수 작동한다.
git 하면 마치 인터넷에 올려서 협업을 해야 할 것처럼 생각하곤 한다. 하지만 git의 기능 자체는 local에서 대다수 작동한다. 우리가 사골 패턴으로 "git add.", "git commit", "git push"의 패턴을 써서 그렇지 "git push"를 하지 않아도 해당 프로젝트의 각각 스냅숏은 로컬에 남아있다. 대다수의 프로젝트를 진행할 때 협업 하기 때문이지 만약 혼자 하는 프로젝트라면 인터넷에 올리지 않아도 된다.
사내 보안이 힘들어서 프로젝트를 진행할 때 github를 사용하지 못할지도 모른다. 하지만 git자체는 local에서 사용할 수 있기 때문에 본인의 코드 이력관리용으로 git을 사용할 수 있다. 그리고 하나의 꿀팁이 있다. 바로 폴더를 git remote위치로 지정할 수 있는 것이다. 그럼 이게 뭘 가능하게 하느냐. github에 올리지 않고 사내 서버의 폴더 하나를 마치 github의 remote repo처럼 사용할 수 있다는 뜻이다. 나는 현재 사내서버에 설명한 것과 같이 설정하고 사용하고 있다. 비록 협업은 하고 있지 않지만...
실무를 위한 git은?
그렇다면 이 업계에서 git을 어떻게 써야 할까? 내가 생각했던 대로 적어본다
1. git commit 메시지와 데이터를 보낸 시점과 연동한다
건축업에서 책임소재를 명확히 하기란 상당히 어렵다. 왜냐면 모두 다 같은 버전의 파일로 일하는 일이 거의 없다. 그리고 대다수 메일로 데이터를 전송하고 있기 때문에 어디선가 반드시 문제가 생기게 되어있다. 그리고 항상 표적은 제일 만만한 사람이거나 데이터를 다룬 사람 탓이 된다. 그게 바로 건축 업계에 데이터를 다루겠다고 하는 사람들의 숙명이다. 하지만 어느 정도 대비는 되어 있어야 한다. 내가 해당시점에 어떤 파일을 보냈는지 자세히 알고 있어야 한다. 나는 그런 면에서 git을 쓰면 좋으리라고 생각한다. 특히나 git commit에는 해당 파일 세트에 대한 상세한 설명을 써붙일 수 있다. 거기에 내가 중요하다고 생각하는 정보들을 기입하고 이력을 본다면 장기적으로는 데이터 관리가 능숙해질 것이고 전쟁 같은 프로젝트에서는 본인에 대한 디펜스를 수행할 수 있다.
2. 디자인 대안을 관리한다
git은 각 시점의 스냅숏을 찍는다. 이걸 건축으로 가져와 보면 내가 마음에 들었던 디자인과 연동 시킬 수 있다. 건축가나 클라이언트의 마음은 갈대와 같다. A라는 안이 좋았다가 B가 좋았다가 다시 A가 좋아진다. 이런 경우 맥이 빠진다. A를 다시 작성하려면 온갖 폴더를 헤매면서 자료를 찾아야 한다. 그리고 내가 원망스럽게도 폴더이름이나 레이어 이름을 제대로 해놓는 일은 많지 않다. 어쩌면 당연한 일이다. 그 수많은 파일을 관리하는데 일일이 무언갈 적어놓고 관리하는 게 불가능하다. 사실 그래서 나는 폴더로 관리하는 방법을 추천하지 않는다. 폴더가 많아질수록 불필요하게 프로젝트에 투입되어야 하는 사람이 많아진다. 차라리 파일을 줄이고 git을 통해 해당 시점으로 돌아가 파일세트를 보도록 하는 게 난 맞다고 본다.
아무튼 그런 관점에서 각 디자인 대안을 스냅숏으로 관리하면 좋다. 그러면 그때의 3D, 2D 등등 모든 데이터를 되돌릴 수 있으니까
3. 자신이 좋은 개발자로 성장할 토양을 일군다
어쩌면 이게 제일 중요한 일일지도 모른다. 사실 그 누구도 내가 git을 사용하는지, 각 버전을 zip으로 묶어서 들고 다니는지 모른다. 대다수의 사람들에겐 결과물이 만들어졌는지, 그게 설치파일인지 UI가 예쁜지 등등의 이야기가 중요하다. 그런 사람들에게 가서 데이터 관리와 각 버전 관리의 중요성을 이야기하면 아마 흙 표면에 1cm 정도 파 들어가는 정도의 얕은 정도로 "그런갑 보다"할 확률이 크다. 그래서 git을 사용하는 건 이 업계에 99% 이상 사람들에겐 관심사가 아니다.
그럼에도 git을 사용해야 하는 것은 개발자로서의 끊을 놓치지 않기 위함이다. 나는 좋은 commit 메시지를 쓰고, 내일은 오늘보다 더 간결하게 코드를 짜는 것이 개발자의 숙명이라고 생각한다. 그러기 위해선 기술 능숙도 측면에선 for loop 정도 이상의 무언갈 알아야 하며, 매일매일 유용한 commit 메시지를 쓰고 자신이 관리하는 연습을 해야 한다고 생각한다.
원래는 회사 차원에서도 중요한 일로 여겨야 하는 것이 맞긴 하다. 왜냐면 본인들이 가진 지적 재산을 관리하는 일이기도 하니까. 하지만 정말 슬픈 일이지만 그런 게 중요한지, 그리고 이런 것이 가능한지 아는 사람은 1%도 되지 않는 게 현실이다. 그러니 내가 해줄 수 있는 말은 좀 더 성장하는 길에 놓이고 싶다면 최소한 git이라도 쓰는 연습을 놓치지 말라고 하고 싶다.
