팀프로젝트 3일차
결국 두려워했던 그놈이 나타났다.
물론 초급 프로젝트의 스크립트 충돌에 두려움은 없었으나...
문제는 Scene <- 이놈이었다.
두 시간 만에 전해진 청천벽력
오늘은 팀원들과 각자 작업한 내용을 병합하기로 한 날이었다.
그런데 오후 2시쯤 자리에서 사라졌던 팀원이 4시가 다 되어 나타나더니 말을 꺼냈다. MainScene에서 병합 충돌(Merge Conflict)이 발생했고, 멘토님께 도움을 청했지만 결국 해결하지 못했다는 것이었다. 결론은, MainScene을 복구할 수 없으니 전부 다시 작업해야 할 것 같다는 말이었다.
청천벽력같은 소리였다. 물론 MainScene의 구조가 복잡하지 않고 대부분의 작업이 C# 스크립트로 이루어져 재작업이 아주 불가능한 건 아니었다. 하지만 오늘은 다 같이 소스코드를 합치기로 계획한 날이다. 이 중대한 문제를 2시간이나 지나서야 공유했다는 건, 팀의 전체 계획에 치명적인 일이었다.
왜 유니티 Scene 병합은 까다로운가
나도 이번에 제대로 알게 된 사실이지만, 유니티의 씬(.unity) 파일은 일반 소스코드처럼 Git이 양쪽의 변경사항을 똑똑하게 합쳐주지 않는다. 충돌이 나면 보통 한쪽 리비전의 변경사항을 선택해 다른 쪽을 덮어쓰는 방식으로 해결해야 한다. 즉, 누군가의 작업물이 통째로 유실될 위험이 크다는 뜻이다.
이 사실을 팀원에게 전해 듣고, 오늘 오전 내내 씬 충돌을 막기 위해 ZEP에서 대화를 나누며 병합 방식에 대해 논의했다. 하지만 결국 터질 일이 터지고 만 것이었다.
중요한 건 실력이 아니라 '태도'와 '소통'
팀원에게는 "이걸 왜 이제 이야기하냐"며 조금 화를 냈다.
사실 개발 현장이란 그렇다. 지난번 회사에서도 비슷한 기억이 있다. 신입 개발자 한 명이 혼자 야근을 하다가 자기 파트에서 병합 충돌을 낸 걸 모르고, 몰래 SFTP로 덮어쓰기 업로드를 했다. 혼자 밤늦게까지 수정하다가 결국 해결하지 못했고, 그 문제를 해결하기 위해 내가 밤 12시에 허겁지겁 재출근을 해야 했다.
사람인 이상 문제는 일어나는 게 당연하고 완벽히 막을 수도 없다. 20년 이상 개발하신 팀장님도 소스코드를 잘못 짜고 병합 충돌을 내는 걸 수도 없이 봤다.
하지만 중요한 건, 자신이 빠르게 문제를 인지하고 해결할 수 없으면 관계된 사람들에게 빨리 공유하는 것이다.
이건 능력의 문제가 아니라, 같이 일하는 사람들에 대한 '예의'의 문제다. 물론 자신이 해결할 수 없을 것 같은 문제를 끝내 해결했을 때의 쾌감은 엄청나다. 하지만 그 과정에서도 전체적인 상황을 파악하는 능력은 반드시 필요하다. 소스코드의 Context만 중요한게 아니라는 것이다.
실체를 마주하다
한숨을 한번 쉬고, 바로 git pull을 받아 충돌이 난 리비전을 찾아보았다.
그리고 조금 당황했다.
너무나도 익숙한, 직렬화된 YAML 구조였기 때문이다.
정확히 어떤 오브젝트의 어떤 속성인지는 몰라도, 최소한 Git이 알려주는 충돌 내용은 명확했다.
HEAD에서는 오브젝트의 속성이 변경되었고,- 다른 브랜치에서는 새로운 오브젝트가 추가되었다.
나는 곧바로 Git이 생성한 충돌 표시 라인들을 제거하고 양쪽의 코드를 모두 남겼다.
그리고 누구의 작업분도 날아가지 않고 MainScene이 완벽하게 복구되었다.
회고
이후 팀원들과 이 문제를 예방하기 위한 논의를 했다. 내가 Merge Pull Request를 전담해서 진행할까 하는 의견도 나왔다. 하지만 내 부담이 너무 커지기도 하고, 프로젝트 또한 내일이면 마무리된다. 무엇보다 부트캠프 강사님이 엄연히 계시는데, 문제를 예방하겠다는 명목으로 내가 규칙을 거는 건 조금 건방지지 않나 하는 생각이 들었다.
부트캠프가 2~3달 지나 모두의 실력이 오른 상황이라면 모를까, 내가 현업 개발자였다는 이유만으로 이제 막 걸음마를 떼기 시작한 팀원들을 주도하려 드는 건 명백한 월권이라는 생각이 내심 들었다. 그래서 그 방법은 그만두기로 했다.
대신, 다음과 같은 규칙을 정했다.
1. 최대한 자주 pull을 받아 병합의 난이도를 낮춘다.
2. Scene 파일은 순차적으로 작업하여 동시 수정을 피한다.
보통 현업에서는 씬 작업을 할 때, 병합용 메인 씬을 따로 두고 각자 개별 씬을 복제해서 작업하거나, 또는 1인 1씬으로 역할을 나눈다고 한다.실제 현업의 씬은 오브젝트와 계층 구조가 훨씬 복잡하기에 오늘처럼 Raw Data를 직접 수정하는 방식은 권장되지 않으며, 불가능할 확률도 높기때문이다. 하지만, 이렇게 명확한 구조가 보이는 상황에서 Raw Data라고 만지지 못할 이유가 무엇이겠는가.
개발에 몸 담은 이래에 내게 최고로 짜릿했던 트러블 슈팅 경험은 저번 회사에서 겪었던 ios apns HTTP2 마이그레이션 경험이었다. 자바버젼, 리눅스버젼, 서버 os의 모든걸 업그레이드를 해야한다는걸 깨닫고 결국 팀장님과 상의후에 쓰지않는 서버에 ios용 프로젝트를 새로 기동시킨 일이었다. 그런데 이번 경험은 아주 간단했지만 그정도의 짜릿함을 준것 같다.
