기획자가 깃에 대해 불평하기
이런 이야기를 하면 코드를 작성하는 일을 하는 분들이 많은 곳에서 완전 쪽팔리는 짓이라는 사실을 잘 알고 있습니다. 하지만 아는 척 행동하기보다는 그냥 모른다고 말하고 불평해 볼 작정입니다. 불평을 정리하다가 내 스스로 생각이 좀 더 잘 정리되어 문제 해결 방법에 가까워질 수 있을까 기대해보면서요.
코드를 작성하는데 더 익숙한 분들은 형상관리도구 깃을 훨씬 더 잘 이해하고 더 쉽게 적응하는 것 같습니다. 이전에 더 오래되고 규모가 더 작은 팀에서는 주로 SVN을, 규모가 더 크고 현대에 가까운 팀에서는 주로 퍼포스를 사용했습니다. 처음에는 이런 도구들의 특징을 잘 이해하지 못했지만 시간이 흐르며 트위터 타임라인에 주로 나타나는 코드를 작성하는데 익숙한 분들의 요구사항과 게임 개발팀의 요구사항 사이에 차이를 조금이나마 이해할 수 있게 되었습니다.
이전에 사용하던 형상관리도구와 깃의 가장 큰 차이점은 커밋이 서버에 작업 내용을 올리는 동작이 아니라는 것입니다. 커밋은 내 로컬에 작업 내용을 등록하는 것이고 이걸 푸시 해야 서버에 등록하는 것입니다. 흔하게 작업 내용을 커밋 했으니 받아서 확인해 보라는 말을 듣고 풀 해서 확인해 보면 아무 것도 안 올라와 있어 다시 푸시 해 달라고 이야기한 경험이 많습니다.
트러블 슈팅을 해야 하는 상황이 일어나면 깃은 개발팀의 여러 직군이 이해할 수 있는 언어로 이야기하지 않습니다. 소스트리나 깃 포크 같은 비주얼 클라이언트는 잘 동작할 때는 괜찮지만 잘 동작하는 시나리오에서 조금`이라도 벗어나면 커맨드라인에서 동작하는 깃이 토해낸 에러 메시지를 그대로 띄우고 작업을 멈춥니다. 또 그 다음의 모든 작업을 거부합니다.
가령 커밋 하기 전에 풀 했더니 디테치드 헤드가 생긴 상황을 생각해 봅시다. 깃 클라이언트는 시도해 볼 수 있는 커맨드를 표시한 다음 멈추는데 이 상태를 해결하기 전에는 커밋, 푸시, 풀 등 아무 것도 할 수 없는 상태가 됩니다. 그런데 에러 메시지에 표시된 힌트 커맨드로는 이 상태를 해소할 수 없습니다. 물론 에러 메시지에 표시된 커맨드로 상태를 해결할 수 있었다면 그 메시지를 내게 보여주는 대신 직접 수행했을 겁니다.
비주얼 클라이언트에서 이 상태를 해결하는 방법은 새 로컬 브랜치를 만들고 체크아웃 한 다음 디테치드 헤드에 표시된 파일을 새 브랜치에 커밋하고 기존 브랜치로 돌아와 다음 행동을 하거나 새 로컬 브랜치를 조사해 필요한 파일을 가져와 커밋하는 것입니다. 하지만 비주얼 클라이언트는 이 과정에 어떤 힌트도 주지 않습니다. 그냥 모든 작업을 거부할 뿐인데 기술적인 배경이 없다면 이 상황이 상당히 무섭게 다가올 수밖에 없습니다. 가령 이런 겁니다. 디테치드 헤드에 표시된 파일을 그냥 지워도 될까요? 혹시 다른 작업을 시도하다가 로컬에 아직 커밋하지 않은 내 작업을 날리게 되지 않을까요? 깃 커밋은 아직 서버에 올라가지 않은 상태라던데 일련의 문제 해결을 위한 작업들로 내 로컬 커밋이 사라지지 않을까요?
비슷한 트러블 슈팅 상황일 때 퍼포스에서는 어떻게 해결했을까요. 일단 퍼포스 개발환경은 대부분 단일 브랜치에서 진행되므로 같은 상황이 일어나지 않습니다. 혹시 해결할 수 없는 문제가 발생하더라도 일단 작업을 커밋할 수 있습니다. 퍼포스에서는 웬만한 문제가 생겨도 커밋을 거부하지는 않습니다. 그리고 점심 먹으러 가면서 문제가 생긴 트리를 강제 업데이트 하면 문제 대부분은 해결됩니다. 무식하다고 생각할 수 있지만 단순해서 한 번만 배워 놓으면 웬만해선 까먹지 않고 스스로 문제를 해결할 수 있습니다.
최근에 브랜치를 머지하다가 쪽팔린 경험을 한 적이 있습니다. 깃 비주얼 클라이언트의 화살표 방향으로 미루어 깃에서 머지는 내가 작업 중이던 피처 브랜치를 메인 브랜치에 ‘머지해 가는’ 방식이라고 예상했습니다. 피처 브랜치를 체크아웃 한 상태에서 머지 인터페이스를 통해 머지를 시도했는제 아무 일도 일어나지 않았습니다. 실제 동작은 머지 당하는 브랜치를 체크아웃 한 다음 머지 해 올 브랜치를 선택해 머지하는 방식이었습니다. 머지 후에는 비주얼 클라이언트 상 화살표가 머지 해 올 브랜치에서 머지 당할 메인 브랜치 쪽으로 그려지는데 이 인터페이스는 내 입장에서 암만 생각해도 머지 해 올 브랜치를 체크아웃 한 상태에서 머지를 수행해야 할 것처럼 보였습니다. 머지는 ‘머지 당할 브랜치를 체크아웃 한 상태에서 한다’고 그냥 외웠습니다.
코드를 작성하는데 익숙한 분들을 보면 깃 개발 모델에 딱히 불편함을 느끼는 것 같아 보이지는 않습니다. 제 입장에서도 처음에는 로컬과 리모트가 분리된 모델 정도로 단순하게 이해하고 시작했습니다. 그런데 시간이 흐르면서 기술에 상대적으로 덜 익숙한 여러 직군이 한 팀에서 일하고 로컬과 리모트가 구분된 환경에 대한 설명이 부족하며 핵심 개발 모델이 피처 브랜치에서 작업해 이를 메인에 머지해 가는 것이고 크기가 아주 큰 바이너리 파일이 많은 환경에 깃 도입은 기술적으로, 또 정책적으로 준비할 것이 많고 또 모든 사람들에게 상당한 교육이 필요하다는 생각이 듭니다.
이런 고민 끝에 그래서 저 자신은 깃에 좀 더 익숙해졌을까요? 실은 그렇지 않습니다. 어떤 트러블슈팅 상황에서는 작업을 백업한 다음 'Fuck this noise, I give up.'을 사용합니다. 다른 분들의 트러블슈팅을 더와 드려야 하는 입장인데 큰일입니다.
