이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트 초반에는 모두가 main 브랜치에 직접 커밋하다가 충돌이 자주 발생했습니다. 4명이 동시에 같은 파일을 수정하면 merge할 때 30분을 소요하는 것이 일상이었습니다.
제가 feature 브랜치를 각자 만들고 PR로 머지하는 규칙을 제안했습니다. 처음에는 팀원들이 복잡하다고 했지만, 1주일 만에 충돌이 눈에 띄게 줄어들었습니다. merge 시간이 5분 이내로 줄었고, 모두가 익숙해졌습니다. 처음에는 저도 규칙을 설명하는 것이 귀찮았지만, 결과가 좋으니 보람을 느꼈습니다.
이 경험에서 버전 관리 도구는 규칙 없이 사용하면 오히려 생산성을 떨어뜨릴 수 있다는 것을 배웠습니다. 도구보다 팀이 공유하는 브랜치 전략이 더 중요하다고 생각합니다.
2주 동안 각자 개발하다가 통합하려니 같은 파일이 50군데 충돌하는 상황이 생겼어요. Git을 쓰긴 했는데 각자 긴 시간 동안 브랜치를 떼어놨기 때문이었습니다. 처음엔 어디서부터 시작해야 할지 몰라서 당황했어요.
git log로 변경 이력을 추적하고, 파일별로 어떤 변경이 더 최신인지 판단하면서 하나씩 해결했습니다. 충돌 해결에 3시간이 걸렸는데, 이후 브랜치를 짧게 유지하고 자주 머지하는 방식으로 바꿨어요. 이 사건 덕분에 팀 전체가 브랜치 관리에 훨씬 신경 쓰게 됐습니다.
이 경험에서 브랜치를 오래 열어둘수록 통합 비용이 커진다는 걸 배웠어요. 지금은 하루에 한 번 이상 원격 브랜치와 동기화하는 습관이 생겼습니다.
팀 프로젝트에서 커밋 메시지가 제각각이라 나중에 어떤 커밋이 무엇인지 찾기 어려운 문제를 경험했어요.
'고침', 'fix', '버그수정' 처럼 동일한 종류의 변경인데 이름이 다 달라서 이력을 읽는 게 힘들었습니다. Conventional Commits 형식을 팀에 제안해서 feat:, fix:, docs: 같은 타입 프리픽스를 쓰는 규칙을 만들었어요. 처음엔 팀원들이 귀찮아했지만 2주 만에 모두 익숙해졌습니다.
한 달 뒤에 버그 원인 추적할 때 해당 변경이 어디서 들어왔는지 5분 만에 찾을 수 있었어요. 과거에는 30분 넘게 이력을 뒤졌던 것과 비교하면 확실히 달랐습니다. 버전 관리는 저장 기능뿐 아니라 팀이 과거를 읽을 수 있게 하는 커뮤니케이션 도구라는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 incross 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.