배경
우리 팀은 2일 간 Git에 부딪히면서 어느 정도 익숙해졌지만, 아직도 헷갈리는 부분이나 알 수 없는 오류에 부딪히는 경우가 많았다. 그 과정에서 시간도 에너지도 꽤 소비하게 되었는데, 오늘은 크게 두 가지 문제가 있었다. 그 문제들을 어떤 식으로 해결했는지 정리하고 싶다.
문제 1 - 일부 로컬에서만 build가 되지 않는 빌드
다같이 Pull Request로 dev 브랜치에 merge하고 각자의 개인 브랜치에 pull하여 시험 삼아 빌드를 해봤는데, 이상하게도 팀원 두 명이 Xcode에서 build가 되지 않았다. 아무래도 각 팀원의 Git 이해도가 어떨지 불분명하다보니, 문제 원인이 뭔지 확실하게 파악하고 싶었는데 아무래도 해당 팀원들은 자신의 컴퓨터를 직접 화면으로 볼 수 있다보니 로컬 디렉토리의 문제라고 확신한 것 같았다. 하지만 화면을 보지 못하는 제3자인 나는 원인에 대한 확신을 할 수 없었다. 그래서 무척 조심스러울 수 밖에 없었던게 결국엔 팀원의 이해도를 의심하며 문제를 접근하게 되는 것이니 말을 예쁘게 하려고 노력한 것 같다.
접근법 1
일단 해당 팀원에게 화면 공유를 부탁하여 로컬에 제대로 최신 빌드가 pull 되었는지 확인하였고, Xcode에서도 이상하게 build가 되지 않는 것을 확인하였다. (같은 최신 빌드를 가진 다른 팀원들은 build가 잘 되었다) 화면을 통해 확인한 덕분에 팀원이 추측한 대로 개인 로컬의 문제임을 납득할 수 있었고, 오류 메시지도 그와 일치하는 것을 확인하였다.
접근법 2 및 workaround
처음 겪는 문제였기에 다소 당황했지만, 결국 Git에서 해당 팀원의 로컬로 파일이 가면서 발생한 문제라고 생각했기에, 해당 프로젝트 파일을 직접 지우고 새로 clone하는 방법을 제시했다. 다행히도 이 방법이 먹혔고, 파일을 지운 후 clone으로 새로 받고 왔더니 무사히 build가 가능하였다.
해결 방안
이 문제를 근본적으로 예방할 수 있는지는 잘 모르겠다. Git 서버의 문제라면 더더욱 해결이 불가능하고.. 맥 특유의 난해한 PATH 문제인가 싶기도 했지만 그 가능성은 낮다고 본다. 다만 알 수 없는 이유로 파일이 누락되거나 정상 빌드임에도 불구하고 Xcode에서 build가 불가능하다면, 파일을 지우고 새로 clone하는 workaround가 꽤 유효한 것 같다. (이 문제 이후로도 한 번 더 비슷한 상황이 생겨서 똑같이 해결했다)
문제 2 - Git: Locked develop branch
내가 맡은 기능을 구현하기 위해 집중하고 있다보니, 다른 이의 Pull Request merge 후 pull을 해달라는 말을 한 번 놓쳤다. 그래서 dev(메인 공용 개발 브랜치)를 pull 했어야 했던 시점으로부터 커밋을 두 개 진행해버렸다. 파일을 따로 저장하고 새로 clone해올까? 라는 생각도 했지만, 문득 비슷한 문제를 접했던 생각이 나서 그 접근법을 되짚어 갔다.
접근법 및 해결방법
reset을 해서 PR 시점으로 돌아가고 싶은데 이러면 수정 사항이 날아가버리니까, 새 로컬 브랜치를 파서 해당 커밋들을 사라지지 않도록 한 후 리셋하기로 했다.
git branch feat-dy-backup
git reset HEAD~2
git pull origin dev
git cherry-pick {feat-dy-backup에 저장된 커밋 해시들}
git branch -d feat-dy-backup느낀점
중간에 cherry-pick을 하지 않고 rebase를 통해 해결해도 되었을 것 같긴 한데, cherry-pick을 사용해서 훨씬 깔끔하게 끝난 것 같다. 원격 저장소와 로컬 저장소를 왔다갔다 하는 과정에서 잊기 쉬운 점은, 로컬 저장소 안에서는 꽤 자유롭게 커밋과 브랜치를 정렬할 수 있다는 점인 것 같다.
문제 3 - 커뮤니케이션: 꾸준한 개인 브랜치 push의 의의
이 문제는 팀원과 기술적인 얘기를 하면서 생긴 커뮤니케이션 문제였다. PR을 통해 새로이 병합된 브랜치를 모두가 pull한 후 각자 개인 브랜치에도 제대로 push하는 게 중요하다는 생각이 문득 들었다. 브랜치가 꼬이기 전에 제때 pull해주는 게 중요한데, 그때마다 push를 해주면 다른 팀원의 브랜치 위치도 원격으로 볼 수 있기 때문에 그런 팀원들에게도 리마인더를 줄 수 있었다. 그런 인사이트를 공유하다가, 돌연 개인 브랜치에 push를 해도 PR이 생기니 곤란하다는 의견이 나왔다.
문제 접근
이 의견이 나왔을 때는 나는 무척 당황했다. 왜냐하면 내가 알고 있던 지식이 전면 부정당했기 때문이다. 이게 곤란했던 이유는 첫째로 내 Git 지식을 기반으로 다른 팀원들에게 알려줬기에 내 지식이 틀렸다면 나는 큰 잘못을 하게 된 것이고, 둘째로는 그것을 정면으로 반박했을 때 생길 수 있는 감정 소비로 이어지는게 두려웠다. 부끄럽게도 여러가지 표정이 내 얼굴을 오갔지만, 침착함을 되찾고 화면 공유를 통해 그것(개인 브랜치에 push할 때도 PR이 요구되는지)을 보여달라고 요청했다.
문제 파악
그 화면공유 요청과 함께 다른 팀원의 의견도 오고 가면서, 알고보니 그 의견은 추측에 기반한 이야기였다는 것이 밝혀졌다. 다만 그 의견이 전달되는 방식이 '추측'이 아닌 '사실'을 전달하는 방식이었기에 이야기가 충돌된 것이었다. 이를 파악하는 과정에서 감정이 서로 고양되었지만, 최대한 웃으면서 이야기하려고 노력했기에 분위기를 완화시킬 수 있었다. 문제는 표면 위로 잘 드러났고, 감정은 표면 아래에서 소화되었다.
팀원과의 인사이트 공유
위 문제 파악이 끝난 후 나는 우리 팀의 커뮤니케이션에 대해서 이야기의 운을 떼었다. 감정이 계속 고양되는 것을 걱정한 팀원이 우려를 표했지만, 나는 "여기 있는 팀원들이랑 이 팀이 해체되어도 앞으로도 계속 교류하면서 잘 지내고 싶고, 그래서 서로 간의 대화 방식을 얘기하고 싶다"고 말했다. 실제로 그렇게 생각했기 때문이다. '정상 빌드임에도 불구하고 Xcode에서의 build가 실패하는 문제'를 다룰 때, 서로가 보고 있는 화면이나 전제하고 있는 것이 달라 문제 파악에 시간이 소비되었던 점을 이야기했다. 그리고 추측에 기반한 이야기를 사실처럼 전달하는 방식을 지양했으면 좋겠다는 이야기를 했다. 누군가가 잘못했다는 것이 중요하기보다는, 효율적이고 원활하게 소통하기 위해 함께 노력해야 할 부분이라는 점을 강조했다. 다행히 이런 의견이 팀원들에게 잘 받아들여졌고, 감정이 서로 고양되었던 팀원과도 응어리가 없는지 서로 DM으로 확인하며 잘 마무리되었다.
