들어가며
먼저 고백을 하나 하자면, 나는 개발자 출신이 아니다. 학부에서는 기계공학을 전공했고, 컴퓨터공학을 따로 배운 적은 없다. 대학원에 들어와서야 C++을 본격적으로 만졌고, 지금도 git의 모든 기능을 능숙하게 쓴다고는 못한다. 다만 “비개발자 출신 대학원생이 git에서 어디에서 헤매는지” 정도는 누구보다 잘 안다고 자신한다. 이 시리즈를 시작하는 이유는 단순하다. 과거의 나와 같이 코딩/협업 경험이 그리 많지 않은 비슷한 처지의 후배 대학원생들에게 매번 같은 조언을 구두로 반복하지 말고 기록으로 남기고자 이렇게 몇 자 써본다. 무튼 빠르게 연구에 도움이 되는 patch 기반 마인드셋을 가지는 데 이 시리즈가 작은 도움이 됐으면 한다.
첫 번째 메시지: 백업, 백업, 백업
소설가 김영하는 소설 쓰기에 제일 중요한거 하나만 알려달라는 학생의 질문에 ‘무조건 백업하라’라고 알쓸신잡에서 말한 일화가 있다. 컴퓨터가 한 번 죽었을 때 원고를 잃어본 사람만 그 무게를 안다. 그래서 그는 클라우드에도 올리고, 외장하드에도 복제하고, 자기 자신에게 메일로도 보내둔다고 했다. 한 번 사라진 글을 “다시 쓴다”는 건 사실상 불가능하다는 걸 본인이 직접 겪어봤기 때문이다.
대학원생들이 흔히 하는 실수
연구실에서 쓰는 코드도 정확히 같다. 한 번 날아간 코드는 날아갔다는 그 자체로도 적잖이 충격을 주지만 다시 복구해야 한다는 것이 더 큰 막막함을 준다. 사실 CS background의 후배들은 이 Git을 잘 사용하는 거 같은데, 생각보다 많은 대학원생이 코드를 자기 노트북 또는 워크스테이션에만 둔다.
그렇게 되면
- 내 로컬 컴퓨터에만 있는 코드
- ssh로 학교 서버에 접속해 짜놓은 코드
- 외장하드에만 백업해 둔 데이터셋 처리 스크립트
- “어차피 나만 쓸 거니까”라며 GitHub에 올리지 않은 실험 코드
이 모든 게 단 한 번의 실수 및 사고로 사라진다. 생각보다 어제까지는 잘 동작하던 데스크탑이 오늘 출근해서는 동작하지 않는 상황을 대학원 과정 내내 많이 목격했다.
세어보니 대학원 6년 동안 Ubuntu 셋업/포맷을 어림잡아 10번 정도 했다.
- 박사 입학 직후 워크스테이션 처음 셋업
- nvidia driver가 꼬여서 두세 번 다시 깖
- NAVER LABS 인턴 가서 새 컴퓨터 셋업
- StachnissLab(University of Bonn) visiting scholar로 가서 새 desktop 셋업
- 졸업하고 MIT에 postdoc으로 와서 또 셋업
그때마다 “이건 자잘한 거니까 굳이 안 올려도 되겠지” 했던 코드들이 사라졌다. 지금 와서 다시 짜면 더 잘 짜기야 하겠지만, 아무리 그래도 사라진 코드는 사라진 시간이다. 같은 시행착오를 두 번 겪는 비용은 결코 작지 않다.
그래서 git을 쓴다
git은 결국 타임머신이자 보험이다.
git commit: 변경 내용을 한 번의 snapshot으로 저장한다.git push: 그 snapshot을 원격 서버(GitHub)에 백업한다.
이 두 줄을 습관으로 만들기만 해도 위에 나열한 사고들 중 절반 이상은 “극복 가능한 일”로 끝난다.
하지만 git add .는 인생에서 지워라
git commit과 git push가 핵심이지만, 커맨드라인에서 매번 git add 파일명, git commit -m "...", git push를 손으로 치는 루틴이 몸에 배기 전까지는 번거롭게 느껴지는 게 사실이다.
아마 처음 git을 배운 이는 git add .로 add를 주로 할텐데, 이 명령어는 부디 잊기 바란다.
현재 디렉토리의 모든 변경 파일을 한꺼번에 stage한다는 의미인데, 대용량 바이너리, 실험용 임시 파일 등이 통째로 묶여 올라가는 사고의 시작점이다.
그 대신자기 손에 맞는 git client를 하나 찾아서 코드의 수정된 부분만 add할 수 있는 방법을 구축하는 것이 중요하다. 나는 lazygit을 쓴다(Vim user여서 편함). 터미널 안에서 돌아가는 TUI 클라이언트로, 파일 단위 혹은 hunk 단위로 stage할 대상을 눈으로 골라서 commit → push까지 한 화면에 끝낼 수 있다. GUI가 편하다면 GitKraken 같은 선택지도 있다.
어느 쪽이든 핵심은 같다. 커밋 대상을 한 파일씩 눈으로 확인하고 올리는 습관이다. git add .는 앞으로는 쓰지 말자.
정리
- 코드는 노트북이 아니라 GitHub에 업로드하자. 노트북은 그저 임시 작업 공간이다.
- 사고는 예고 없이 온다. SSD 사망, 도난, 포맷,
rm -rf한 번이면 끝이다. - 김영하 작가가 원고를 위해 백업에 강박을 가졌듯, 연구자도 코드를 위해
commit과push에 강박을 가져야 한다. - git ≠ 코드 공개. private repo로도 충분하다.
- 일단
git commit,git push. 이 두 줄만으로도 보험에 든 셈이다. git add .는 쓰지 마라. 커밋 대상은 항상 눈으로 골라서 올려라.- lazygit(TUI) 또는 GitKraken(GUI) 같은 client 하나를 손에 익혀두면 습관화가 훨씬 빠르다.
다음 글에서는 git이 단순한 보험을 넘어 메신저로 작동하는 방식, 그리고 그게 본인의 연구에 어떤 의미를 갖는지를 다룬다.
불 났을 때 행동 요령:
git commitgit push- 건물에서 나간다
진지한 화재 대처법이 아니다.
이 밈이 진짜로 말하는 건 화재가 아니라 습관이다.
평소에 commit과 push가 얼마나 자주, 얼마나 반사적으로 일어나야 하면 “불나면 그것부터 한다”는 농담이 가능할까.
당장 내일 컴퓨터가 망가지더라도 어제까지 작업한 내용은 어딘가에 살아남아 있어야 한다. 이 시리즈의 첫 글이 전하고 싶은 메시지가 딱 그것이다.
대학원생을 위한 Git 시리즈입니다.