작년 여름까지만 해도 두명에서 세명정도의 작은 그룹에서만 git을 사용해왔습니다.
git브랜치 전략 수립, Commit Convention 정하기, 작업이 끝난 브랜치는 상의 후 정리하기 등등
여러 시행착오 끝에 자연스럽게 루틴이 형성되어 있었습니다. 기업마다 다양한 방법이 있겠지만 어떤 방법이든 적응할 수 있다고 생각했죠.
22년 하반기부터 지금까지는 git을 활용하여 훨씬 많은사람들과 협업을 해볼 수 있었습니다.
4명부터 5명, 8명, 그리고 30명 가량의 사람들이 함께 참여하는 프로젝트까지...
프로토 타입 수준의 iOS앱부터 실제 앱스토어에 출시하는 앱까지 10개 정도의 프로젝트를 경험해보았던 것 같습니다.
훨씬 많은 사람들과의 협업을 하면서 다짐하였던 주의해야할 점들을 몇가지 적어보려합니다.
1. 동시 다발적으로 merge하지 말자(특히 충돌 해결 중에 하지말자)
8명이서 프로젝트를 진행하던 중 다같이 개발상황을 주고 받고 동시에 merge를 하면서 프로젝트 파일이 망가져버린 상황이 발생하였습니다.
xcode 프로젝트 자체가 열리지 않던 것이죠.
원인은 아래와 같습니다.
8명 전부는 아니겠지만 merge가 완료되기 전 일부 인원에게 Conflict가 동시다발적으로 발생하였고
누군가의 conflict를 해결하기 전에 동시에 conflict 코드를 수정하고 merge하면서 코드가 꼬여버린 것이었습니다.
conflict가 본인의 시점에서는 해결된 것처럼 보이겠지만 각각 8명의 다른 방식으로 수정된 코드가 합쳐지면서 망가지게 된 것이죠.
망가져버린 xcodeproj파일 코드의 문제점을 찾는 것은 한정된 개발 시간안에 해결하기엔 어려워보였고 결국
merge하기 직전의 commit기록으로 돌아가서 다시 merge하는 것으로 해결할 수 있었습니다.
2. Key파일은 gitIgnore에 잘 적용이 되었는지 확인.
git에 실수로 AWS 키 or KAKAO API키 등을 push하여 현업자이신 팀원분께 많이 죄송했던 적이 있습니다ㅎㅎㅎㅎ
Google firebase관련 PList 포함
3. ThirdParty 라이브러리 사용시 반드시 적용 당시 버전 명시해두기
버전 업데이트가 되면서 처음 개발할 당시와 상황이 달라져 Error가 발생할일이 생각보다 많은 것 같습니다..
본인이 아닌 다른 사람이 개발을 할때는 더 많이 발생하게 되는데 이때 버전을 제대로 명시해두지 않으면 굉장히 번거롭죠.
Sendbird API 적용 후 팀원분께서 pull받은 후 작업중 Erorr가 발생하면서 깨달았습니다.
물론 이것저것 막 가져다 쓴 것이 더 큰 문제였지만 이것 또한 주의할 습관인 것 같네요.
3. 문제가 발생했다면 아무리 작은 문제도 공유하자.
a. 카카오 LOCAL API를 통해 기능 구현 중 법정동과 행정동 구분의 문제로 클라이언트 측에서 원하는대로 주소가 출력되지 않았습니다.
이상하다고 여겼지만 눈에 띄지 않았고 제 나름대로 더 급한 문제를 해결하기 위해 넘어갔었습니다.
이문제는 iOS와 Android, Server 모두 같은 API를 사용하였기 때문에 클라이언트 측 요청으로 긴급회의가 열리는 수준까지 일이 커졌습니다.
아무도 발견하지 못했다는 것도 이상하긴 했지만 일단 제가 그때 바로바로 문제를 공유하였다면 더 신속하게 문제를 해결할 수 있었을 것 같아서 마음이 아팠습니다.
b. 프로파일 인증문제가 있다는 것을 모르는 상태로 외주 개발을 시작하였습니다.
다른 일정으로 인해 외주 프로젝트는 주로 저녁시간에 작업을 하게 되었죠.
작업 중 인증문제(본인 계정 아님)로 인해 개발을 할 수 없었고 늦은 저녁시간으로 인해 바로 해결할 수 없었습니다.
먼저 작업을 시작한 분께 여쭤보았습니다. 이 문제에 대해 알고 있었지만 테스트가 불가능한 상태로 코드만 작성하고 계셨더군요...
4. 문서 내용을 너무 믿지 말자. 꼼꼼히 확인해보고 테스트해보자. 인수인계 때 특히...
분명 이전 작업자 분께서 이전 스프린트까지의 기능 구현을 완료해두었다고 문서에 표시해 두셨습니다.
저는 안일한 마음가짐으로 모두 테스트해보면서 꼼꼼히 체크하진 않았죠.
결국 작업중 완료되었어야할 기능들에서 구멍이 몇가지 발견되었고 구현이 아예 되어있지 않은 부분도 발견되었습니다.
물론 이는 테스트해보지 않은 PM과 이전 작업자에게도 책임이 있을 수 있지만
인수인계 중에 더 꼼꼼히 코드 파악을 하면서 체크했다면 조금 더 매끄럽게 일을 해결할 수 있었을 것 같습니다.
저도 일을 조금 미루게 되면서 일이 커졌습니다 ㅎㅎㅎㅎ.
5. 클라이언트 관점에서 테스트해보자.
내가 직접 돈주고 맡긴다고 생각하고 개발을 하려고합니다 항상.
외주를 하면서 클라이언트 측에서 QC 검수를 하면서 수정 요청이 정말 많이 들어왔습니다.
주말동안 200건이 넘는 요청사항을 처리해야할 일이 있었는데 지금 다시 생각만해도 대재앙이었습니다.
그 상황속에 다른 팀원분의 개발자로서의 길을 현타가 왔다는 말을 듣고도 동요하지 않던 제 자신으로부터 제 길에 확신을 느끼긴 했지만요.
아무튼 1픽셀 단위로 본다는 디자이너의 관점을 체감할 수도 있었던 것 같기도하고 한층 더 섬세한 개발자로 성장할 수 있었던 경험이었습니다.
그 외...
a. 선조치 후보고
본인의 작업중 에러가 발생한다고 남의 코드를 수정하고 push한 후에 나중에서야 말해주는 분...
두세명이서 작업한다면 대수롭지않게 넘어갈 수도 있을 것 같지만 30명이 넘는 사람들이 작업할때 이 소식을 들었을 땐 피곤함이 느껴졌습니다.ㅎ ㅎㅎㅎㅎㅎ 생각보다 이런 상황이 많았기 때문이죠.
이런일이 생기지 않도록 다시 한 번 브랜치 merge는 각각 조장들에게 PR을 보낸 뒤 조장들의 승인이 있을 때에만 merge되도록 강력히 요청하였습니다.
b. 에러가 있을 때 push하지 말것.
이것도 콘솔게임 세이브 하듯이 git에 commit & push해서 활용하시는 분들이 계셨는데
30명 프로젝트 도중 엄청난 스노우볼을 굴려버렸습니다.
결국 전원작업을 중지시킨 후 모두 모여 일괄적으로 한 화면으로 에러코드를 전부 해결하였습니다.
댓글