git - 수백 명이 한 코드를 함께 고치는 법

누구나 한 번쯤 이런 파일을 만들어본 적이 있을 것입니다.

보고서.pptx로 시작했던 문서가 어느새 보고서_수정.pptx가 되고, 보고서_최종.pptx를 거쳐 보고서_최종_진짜최종.pptx에 이릅니다. 운이 나쁘면 보고서_찐막_진짜최종_이게진짜final.pptx까지 가기도 하지요. 분명 더 나은 문서를 만들려고 고친 것인데, 정작 폴더 안에는 어느 것이 진짜 최신인지 알 수 없는 파일 더미만 남습니다.

이 사소한 혼란은, 사실 혼자 일하는 한 그럭저럭 견딜 만합니다. 파일이 좀 지저분해도 만든 사람은 대개 어느 게 최신인지 기억하니까요. 진짜 문제는 다른 곳에서 터집니다. 여럿이 동시에 같은 것을 고치기 시작할 때입니다.

수십 명이 한 권의 책을 동시에 쓴다면

상상해보시지요. 한 권의 두꺼운 책을 수십 명이 동시에 써 내려가고 있습니다. 누군가는 3장을 다듬고, 누군가는 7장을 새로 쓰고, 또 누군가는 앞에서 쓴 용어가 뒤와 맞지 않아 전체를 손보는 중입니다.

이제 이들이 각자 고친 원고를 하나로 합쳐야 합니다. 그런데 A가 가진 최종.pptx와 B가 가진 최종.pptx의 내용이 다릅니다. 둘 다 자기 것이 최신이라고 믿습니다. 같은 문단을 두 사람이 서로 다르게 고쳤다면 어느 쪽을 따라야 할까요? 누가, 언제, 왜 이 문장을 바꿨는지 모른다면, 잘못된 수정을 가려낼 수조차 없습니다. 파일 이름 뒤에 _진짜최종을 아무리 붙여봐야 소용없습니다. 사람이 여럿이 되는 순간, ‘최종’이라는 말은 의미를 잃기 때문입니다.

소프트웨어는 정확히 이런 식으로 만들어집니다. 수십, 때로는 수백 명의 개발자가 같은 코드 뭉치를 동시에 고칩니다. 글자 하나만 틀려도 프로그램 전체가 멈출 수 있는, 대단히 예민한 글입니다. 그러니 개발자들에게 버전 관리는 결벽이 아니라 생존의 문제였습니다. 그리고 이 문제를 풀기 위해 만들어진 도구가, 우리가 한 번쯤 이름은 들어봤을 ‘git’입니다. git의 존재 이유는 처음부터 끝까지 협업이었습니다. 혼자라면 굳이 필요 없었을 도구입니다.

git이 함께 만드는 방식

git은 이 문제를 이렇게 풉니다.

무언가를 고칠 때마다 그것을 지우지 않고 하나의 매듭으로 묶어 기록합니다. 개발자들은 이 매듭을 ‘커밋(commit)‘이라 부릅니다¹. 매듭마다 무엇이 바뀌었는지, 누가 바꿨는지, 그리고 왜 바꿨는지가 함께 남습니다. 그래서 git으로 관리되는 작업물은 단순한 파일이 아니라, 지금의 모습에 이르기까지의 모든 과정을 품은 역사책에 가깝습니다.

여러 사람이 서로를 방해하지 않도록 각자 자기만의 갈래에서 따로 작업합니다. 개발자들은 이 갈래를 ‘브랜치(branch)’, 곧 나뭇가지라고 부릅니다. 본래의 줄기에서 가지를 쳐 나와, 그 위에서 마음껏 고치고 실험합니다. 내 가지에서 무엇을 하든 다른 사람의 가지에는 영향을 주지 않습니다.

각자의 가지에서 자란 작업을 다시 하나로 합칩니다. 이것을 ‘병합(merge)‘이라 합니다. 그리고 바로 이 합치는 과정에서, git의 가장 중요한 태도가 드러납니다.

충돌은 숨기지 않는다

두 사람이 같은 부분을 서로 다르게 고쳤을 때, git은 이것을 ‘충돌(conflict)‘이라 부르며 멈춰 섭니다. 그런데 git이 여기서 하는 일이 흥미롭습니다. git은 충돌을 자기 마음대로 해결하지 않습니다. 둘 중 하나를 임의로 고르지도, 더 나중에 고친 쪽을 무조건 이기게 하지도 않습니다. 대신 이렇게 말합니다. “여기, 두 사람의 생각이 다릅니다. 한쪽은 이렇게, 다른 쪽은 저렇게 고쳤습니다. 어느 쪽을 택할지, 혹은 둘을 어떻게 합칠지는 사람이 직접 결정하십시오.”

git은 충돌을 덮어버리는 도구가 아니라, 충돌을 정확히 드러내는 도구입니다. 차이가 있는 바로 그 지점을 또렷이 짚어주고, 판단은 사람에게 돌려줍니다. 이것이 수백 명이 한 덩어리의 코드를 함께 만들면서도 무너지지 않는 비결입니다.

흥미로운 것은 개발자들이 이 모든 과정을 식물의 언어로 부른다는 사실입니다. 줄기에서 갈라지는 가지(branch), 모든 기록이 뻗어 나오는 뿌리(root), 가지와 가지가 얽힌 전체 구조를 나무(tree)라 부르고, 깃허브²에서 매일의 작업을 초록색 칸으로 보여주는 화면을 사람들은 ‘잔디밭’이라 부릅니다.

버전 관리라는 행위가 하나의 줄기에서 갈라져 나오고, 제각기 뻗어 자라다가, 다시 하나로 합쳐지는 나무의 생김새와 너무도 닮아 있었으니까요. 그 닮음을 알아챈 사람들이 식물의 모티브를 가져와 이름을 붙인 것이지요. 가지라는 이름은 가지처럼 갈라지는 그 구조를 보고 붙인 이름입니다. 다시 말해, 소프트웨어를 만드는 일이 본질적으로 건축보다 정원 가꾸기에 가깝다는 사실을, 이 일을 하는 사람들은 일찌감치 알아보고 그렇게 불러온 것입니다.

돌보지 않으면 잡초밭이 된다

정원에 빗대는 데에는 또 다른 이유가 있습니다.

많은 사람들이 의아해합니다. 구글이나 네이버 같은 회사는 새로운 기능이 그리 자주 나오지도 않는데, 왜 그토록 많은 개발자가 필요할까? 겉보기에 멈춰 있는 듯한 서비스에 수천 명이 매달리는 이유가 무엇일까?

답은 정원에 있습니다. 아무도 손대지 않은 소프트웨어는 가만히 있어도 어느 날 갑자기 멈춥니다. 코드는 한 글자도 바뀌지 않았는데 말입니다. 그것이 기대고 있던 주변 환경—운영체제, 함께 맞물려 돌아가는 다른 프로그램들, 끊임없이 새로 등장하는 보안 위협—이 쉴 새 없이 변하기 때문입니다. 며칠만 손을 놓아도 잡초가 올라오는 정원처럼, 소프트웨어도 돌보지 않으면 서서히 잡초밭이 됩니다.

그러니 그 수많은 개발자들은 새것을 짓고 있는 것이 아닙니다. 끊임없이 잡초를 뽑고, 가지를 치고, 흙을 갈아엎으며 정원이 멎지 않도록 함께 돌보고 있는 것입니다. 유지란 가만히 있는 일이 아니라, 멈추지 않는 공동의 노동입니다.

우리 사회라는 거대한 정원

여기까지 오면, 한 가지 생각을 떨치기 어려워집니다. git이 코드라는 작은 세계에서 푼 문제가, 사실은 우리가 사는 큰 세계의 문제와 똑같다는 것입니다.

우리 사회야말로 수많은 사람이 동시에 손대고 있는 거대한 공동 작업입니다. 회사도, 가정도, 도시도, 한 나라도, 누구 하나가 처음부터 끝까지 혼자 설계한 것이 아닙니다. 수많은 사람이 각자 다른 자리에서, 각자의 가지 위에서, 동시에 무언가를 바꾸고 있습니다. 그리고 그 변경들은 끊임없이 부딪힙니다. git이 코드 안에서 매일 마주하는 ‘충돌’을, 우리는 삶에서 매일 겪고 있는 셈입니다.

여럿이 진심으로 무언가를 함께 만들면, 부딪치지 않을 도리가 없습니다. 충돌은 협업이 실패했다는 증거가 아니라, 여럿이 진짜로 함께하고 있다는 증거입니다. 아무도 부딪치지 않는다면, 그것은 사이가 좋아서가 아니라 누구도 진심으로 손대지 않고 있다는 뜻일지도 모릅니다.

그렇다면 우리 사회가 자주 서툴러 보이는 까닭은, 충돌이 있어서가 아닐 것입니다. 충돌을 다루는 방식이 서툴러서입니다. 우리는 너무 자주 충돌을 덮어버리거나, 목소리 큰 쪽이 이기게 하거나, 아예 가지를 잘라내고 갈라서버립니다. git이 가르쳐주는 방식은 그 반대입니다. 차이를 숨기지 말고 정확히 드러낼 것. 어느 한쪽을 임의로 이기게 하지 말 것. 그리고 그 차이를 어떻게 합칠지, 끝내 사람이 마주 앉아 결정할 것.

생각해보면, 잘 가꿔진 정원일수록 손이 많이 닿은 정원입니다. 여러 사람의 서로 다른 취향과 판단이 부딪히고 조율된 흔적이 거기 새겨져 있습니다. 우리가 함께 만들어 가는 모든 것이 그러할 것입니다. 부딪힘을 두려워해 아무도 손대지 않은 자리에는 잡초만 무성하고, 차이를 정직하게 마주한 자리에서야 비로소 무언가 자랍니다. 어쩌면 git이 우리에게 건네는 가장 조용한 가르침은 이것인지도 모릅니다. 함께 만든다는 것은 부딪히지 않는 일이 아니라, 부딪힌 자리를 끝내 외면하지 않는 일이라는 것.