면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
저는 팀 프로젝트 초반에 같은 파일을 두 명이 동시에 수정하다가 머지 충돌이 크게 나서 어떤 코드를 남겨야 할지 몰라 당황한 적이 있습니다. 처음엔 무작정 제 코드로 덮어썼다가 팀원의 작업이 사라진 걸 뒤늦게 알았습니다. 그 뒤로는 충돌이 나면 먼저 상대에게 어떤 부분을 왜 바꿨는지 물어보고 함께 화면을 보면서 합치는 방식으로 바꿨습니다. 그 사건 이후로 저희 팀은 같은 파일을 동시에 건드릴 것 같으면 미리 슬랙으로 알리는 규칙을 만들었습니다.
저는 팀 프로젝트에서 다들 main 브랜치에 바로 커밋하다가 배포 직전에 완성되지 않은 기능까지 섞여서 문제가 된 적이 있습니다. 그때 제가 먼저 기능별로 브랜치를 나누고 완성된 것만 병합하는 방식을 제안했습니다. 처음엔 절차가 늘어난다고 귀찮아하는 팀원도 있었지만, 다음 배포에서 문제 코드가 섞이지 않는 걸 직접 경험하고 나서는 다들 자연스럽게 따라줬습니다. 주도적으로 문제를 해결한다는 게 거창한 게 아니라 불편함을 먼저 짚고 대안을 제시하는 것이라는 걸 배웠습니다.
저는 스터디 프로젝트에서 커밋 메시지가 제각각이라 나중에 어떤 변경인지 찾기 어려운 문제를 겪었습니다. 리뷰할 때마다 커밋 로그만 봐서는 무슨 작업인지 알 수 없어서 매번 코드를 직접 열어봐야 했습니다. 그래서 간단한 커밋 메시지 규칙, 예를 들어 기능 추가와 버그 수정을 접두어로 구분하는 방식을 정리해서 제안했고 팀원들도 동의해 적용했습니다. 이후로는 로그만 봐도 무슨 변경인지 파악할 수 있어 리뷰 속도가 눈에 띄게 빨라졌습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.