코드가 있었는데요, 없었습니다
하아. 일단 한숨부터 쉬겠다. 지금 내가 하려는 이야기는 뒷골이 땅기고 머리가 지끈거리는 이야기이다. 깃(Git)과 깃허브(Github)를 아시는지. 처음 접한다면 이해하기 어려운 개념이다.
예를 들어 보고서를 쓴다고 생각해 보자. 보고서를 열심히 썼는데 윗사람이 와서 수정하라고 한다. 그래서 수정하고 파일명을 고친다. 보고서_수정. 그랬더니 또 수정하라고 한다. 보고서_수정_수정. 이번엔 제발 통과되기를 바랐건만 안타깝게도 또 수정해야 한다. 보고서_수정_수정_최종수정. 여기서 보고서_수정, 보고서_수정_수정, 보고서_수정_수정_최종수정을 만들어 관리해 주는 도구가 ‘깃’이라고 생각하면 된다. 말 그대로 파일의 ‘버전’을 관리한다.
깃이 관리하는 파일이 모여 있는 곳이 ‘깃허브’다. 웹사이트라고 생각하면 된다. 프로젝트별로 레퍼지토리(repository)라는 저장소가 있고 그 안에 깃이 관리하는 파일들이 모여 있다. 공개 저장소의 경우 파일을 작성한 사람이 아니어도 파일을 볼 수 있다. 클론(Clone)해서 가져가는 것도 가능하다.
그래서 이제 깃과 깃허브로 무엇을 하느냐? ‘협업’을 한다. 깃허브는 유용한 협업 도구다. 이것도 여러 명이 하나의 보고서를 쓴다고 생각하면 이해하기 편하다. 대략 말하자면
“자, 나는 A 파트를 쓸게. 너는 B 파트를 써. 쟤는 C 파트를 쓰고 그다음에 합치자.”
이런 상황인 것이다. 각자 맡은 파트를 열심히 쓴다. 작업이 끝나면 작업물을 깃허브에 올려서 합치면 된다. 문제는 언제나 합치는 순간 일어난다. 깔끔하게 아귀가 딱 들어맞으면 얼마나 좋을까. 만약 두 사람의 작업에 겹치는 부분이 있다면? 한 사람 작업을 지울지 둘 다 반영할지 선택해야 한다. 그 말은 그 일을 누군가 판단해야 한다는 뜻이다. 판단을 잘못하면 필요한 코드가 날아가는 일도 종종 생기곤 한다.
한 번은 이런 일도 있었다. 전날 하루 종일 작업해서 기능 하나를 만들었다. 뿌듯한 마음으로 깃허브에 올려놓고 퇴근했는데 다음 날 출근하니 내가 짠 코드가 사라졌다. 코드가 있었는데요, 없었습니다! 너무 놀라서 내가 깃허브에 올린 다음에 누가 작업을 했는지 확인했다. 사수님이었다. 대체 뭘 하신 거예요? 사수님이 본인 작업을 반영하면서 정작 내 작업은 다 되돌려 버렸다. 이게 무슨 상황이야. 허망하게 모니터를 보다가 사수님께 말을 걸었다.
“N 매니저님, 제 코드가 없어졌는데요.”
“응? 있는 그대로 합쳤는데? 어쩔 수 없네. 다시 올려요.”
다시? 잠깐만요. ‘다시’ 면 어디서부터?
‘지금 내 컴퓨터에 작업한 거 남아있나? 나 처음부터 다시 해야 하는 건가?’
다행스럽게도 작업했던 게 남아있어 아예 처음부터 다시 작업하는 불상사는 막을 수 있었다. 만약 아니었다면…. 생각만으로도 아찔하다. 하지만 나는 알고 있다. 중요한 건 꺾이지 않는 마음이라는 걸. 설령 그런 상황이더라도 나는 해냈을 것이다. (라고 믿고 싶다)
그럼 이제 남아있는 코드로 복구를 해 볼까? 시작부터 문제가 생겼다. 어떻게 복구해야 할지 모르겠다.
‘내 컴퓨터에는 남아있는데 깃허브에는 이걸 어떻게 올려야 하지? 이미 한번 올렸었는데 또 올릴 수 있나? 안 되네….’
이미 한번 올렸던 버전을 깃허브에 또 올릴 수가 없었다. 뇌가 멈춘 상태로 잠깐 멍하니 앉아있다 곧 정신을 차렸다. 나는 성실한 사람이라서. 그래서 내가 선택한 방법은 깃허브에 올라가 있는 파일들을 내려받은 다음, 내 컴퓨터에 남아있는 코드를 일일이 ‘복사/붙여 넣기’하는 것이었다. 그 수많은, 추가된 코드를 하나하나. 잘못 붙여 넣으면 오히려 에러를 발생시킬지도 모르는 위험한 방법을 택한 것이다. 그래도 무사히 코드를 복구해서 깃허브에 올려놓긴 했다. 그 사건은 나 혼자 한바탕 막일을 하고 지나갔다.
돌이켜 생각해 보면 ‘깃에서 제공하는 명령어 몇 번으로 간단하게 해결할 수 있었을 텐데’라는 후회가 든다. 사수님도 그래서 쉽게 다시 하라고 말씀하신 거겠지. 하다못해 막일을 했으면 ‘이걸 간단히 할 수 있는 방법이 있지 않을까?’라고 생각을 조금이라도 하든지. 그랬으면 찾아보고 더 성장했을 텐데. 이래서 개발자에게는 귀차니즘이 필수인가 보다. 성장의 원동력이 되니까.
깃은 아주 많은 기능을 지원하기 때문에 이런 사건 말고도 개발자의 깃 숙련도 미숙으로 인한 코드 유실도 많이 발생한다. 깃이 익숙하지 않아서 코드를 날려 먹었다는 말이다. 그래서 신입 채용 공고를 보면 자격 요건으로 ‘깃, 깃허브 사용 가능’이라는 조건이 붙기도 한다. 그걸 볼 때마다 ‘깃에 익숙하지 않은 신입 개발자가 많은 모양이구나’하고 생각하곤 한다.
나는 2년 차인 지금도 깃이 무섭다. 언제 어떻게 버전이 꼬이고 코드가 사라질지 모르기 때문이다. 그래도 선배 개발자들이 깃을 활용하는 걸 보고 배우면서 조금씩 성장하고 있다. 처음에 비하면 능숙해진 것 같아 뿌듯하기도 하고. 아무튼 코드는 있다가도 없고, 중요한 건 코드를 날려도 꺾이지 않는 (어떻게든 수습하는) 마음이다.
