Git과 같은 버전 관리 시스템을 사용해본 경험에 대해 말씀해 주세요. | 이스트소프트 풀스택 면접 질문

Q: merge conflict을 겪었을 때 어떻게 푸셨나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 본인이 정한 커밋 메시지 규칙이 있나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 팀에서 브랜치 전략을 정해본 적 있나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

이이스트소프트풀스택경험·이력2026년 출제

답변 미리보기

Git을 처음 팀 프로젝트에 도입했을 때 가장 중요하다고 느낀 건 브랜치 전략 합의였습니다. 처음엔 모두 main에 바로 push했다가 충돌이 자주 발생했고

예상 답변 시간

60초

예상 꼬리질문

3회

난이도

난이도 중

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

기본 명령에 익숙한가?

commit·branch·merge 같은 기본 흐름이 손에 익었는지 짐작 가능한 답이 자주 통합니다. GUI에만 의존한 흔적은 깊이를 의심받는 자리입니다.

협업 흔적이 답에 있는가?

혼자 쓰던 수준인지, 여러 명이 같은 저장소를 만진 경험까지 닿는지 구분하는 자리입니다. PR·리뷰·충돌 해결 같은 단어가 답에 묻어 있는지 살핍니다.

충돌·실수를 다뤄봤는가?

merge conflict이나 잘못된 commit을 되돌린 경험이 답에 있는지 보는 자리입니다. 한 번도 막힌 적 없다는 답은 의심을 부르는 결로 통합니다.

협업 전략을 의식하는가?

main 보호, 브랜치 명명, 커밋 단위 같은 약속을 알고 따랐는지 짚는 자리입니다. 도구만 알고 협업 룰은 모르는 답은 약하게 들리는 결입니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

이스트소프트 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

저장소 용량 문제 경험으로 초기 세팅 원칙 확립약 60초 잘못된 rebase로 히스토리를 망친 경험약 120초 팀 내 Git 리더 역할을 맡아 갈등 해결 경험약 150초

브랜치 전략 + Git LFS + PR 리뷰 프로세스

약 60초

저장소 용량 문제 경험으로 초기 세팅 원칙 확립

Git을 처음 팀 프로젝트에 도입했을 때 가장 중요하다고 느낀 건 브랜치 전략 합의였습니다. 처음엔 모두 main에 바로 push했다가 충돌이 자주 발생했고, feature 브랜치를 분리하는 방식으로 바꾸면서 충돌 빈도가 크게 줄었습니다. 커밋 메시지 규칙(feat/fix/chore 접두사)을 팀 내에서 정해두면 이력 추적이 훨씬 쉬워졌습니다. 바이너리 에셋(이미지·3D 모델)은 Git LFS를 빠짐없이 설정했습니다. 처음에 LFS 없이 3D 에셋을 올렸다가 저장소 용량 폭발 문제를 겪었고, 이후 .gitattributes를 프로젝트 시작 전에 잡는 습관이 생겼습니다.

PR 리뷰 프로세스를 도입하면서 혼자 병목이 되는 것 없이 코드 품질을 유지하는 방식을 배웠습니다.

이 결의 특징

Git을 팀 프로젝트에 처음 도입했을 때 브랜치 전략을 먼저 합의한 것이 이후 충돌을 줄였다는 경험이 담긴 결입니다. 도구 도입 전 사용 규칙을 먼저 합의하는 것이 협업 도구의 효율을 결정한다는 인식이 핵심입니다.

이 결이 통하는 자리

Git 팀 도입 경험을 묻는 포지션에서 자주 등장하는 질문입니다. 브랜치 전략을 먼저 합의하는 방식이 있는 답은 면접관이 버전 관리 도입 방식을 확인하는 자리입니다.

예시 답변 2

약 120초

잘못된 rebase로 히스토리를 망친 경험

main 브랜치에서 rebase를 직접 실행했다가 팀 전체의 히스토리를 망친 경험이 있습니다. 로컬에서 커밋을 정리하려고 interactive rebase를 썼는데, 그 브랜치가 이미 원격에 공유된 상태였습니다. 팀원들이 pull했을 때 커밋 SHA가 바뀌어 히스토리 충돌이 발생했고, 혼자서 force push로 정리하려다 팀원 두 명의 작업이 날아갈 뻔했습니다. 결국 reflog로 원래 상태를 찾아 복원했고, 이후로 공유 브랜치에서는 rebase 대신 merge를 쓰고, rebase는 로컬 전용 작업에서만 사용하는 규칙이 생겼습니다.

공유 브랜치에 force push하는 것은 팀 전체의 히스토리를 덮어쓰는 행위라는 걸 그날 처음 몸으로 배웠습니다. 지금은 원격 브랜치가 있으면 rebase 전에 항상 팀원에게 확인하는 루틴이 생겼습니다. 공유 브랜치를 건드리기 전에 항상 팀에 알리는 루틴이 그때부터 생겼습니다.

이 결의 특징

main 브랜치에서 rebase를 직접 실행했다가 팀 전체 히스토리를 망친 경험에서, 공유 브랜치에는 rebase를 사용하지 않는 원칙을 도입한 결입니다. 공유 브랜치 조작은 개인 브랜치와 다른 기준이 적용되어야 한다는 인식이 핵심입니다.

이 결이 통하는 자리

Git 공유 브랜치 관리 실패 경험과 개선 방식을 묻는 포지션에서 유효한 결입니다. 공유 브랜치 원칙을 도입한 경험이 있는 답은 면접관이 버전 관리 방식을 확인하는 자리입니다.

예시 답변 3

약 150초

팀 내 Git 리더 역할을 맡아 갈등 해결 경험

팀 프로젝트에서 Git 경험이 가장 많다는 이유로 브랜치 관리를 맡는 역할을 하게 된 경험이 있습니다. 처음엔 내 방식이 맞다고 생각했는데, 팀원들이 브랜치 이름 규칙이나 커밋 메시지 형식을 어떻게 써야 하는지 헷갈려 하는 것을 보면서 규칙을 문서로 공유하지 않으면 내 머릿속에만 있는 규칙이 된다는 걸 느꼈습니다.

feature/, fix/, docs/ 브랜치 접두사와 커밋 메시지 형식을 README에 정리하고 팀 전체에 공유했습니다. 처음에는 복잡하다는 의견도 있었는데, PR을 거치면서 코드 리뷰 부담이 줄었고 팀원들이 자발적으로 따르기 시작했습니다. Git 규칙은 강제가 아니라 팀이 편해지는 이유를 함께 경험해야 정착된다는 걸 그 과정이 알려줬습니다. 지금은 새 팀을 시작할 때 브랜치 전략을 첫 미팅에서 합의하는 루틴이 생겼고, Git 규칙 문서를 먼저 만드는 것이 협업 비용을 줄이는 가장 빠른 방법이라는 게 제 경험입니다.

이 결의 특징

Git 경험이 가장 많다는 이유로 브랜치 관리 역할을 맡으면서 역할의 책임 범위가 기술 역량보다 커진다는 것을 경험한 결입니다. 기술 역량과 역할 책임은 다른 것이라는 인식이 핵심입니다.

이 결이 통하는 자리

기술 역량과 팀 역할 책임의 관계를 묻는 포지션에서 눈에 띄는 결입니다. 기술 역량이 역할 책임과 다르다는 인식을 경험에서 도출한 답은 면접관이 협업 성숙도를 확인하는 자리입니다.

위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹merge conflict을 겪었을 때 어떻게 푸셨나요?

貳본인이 정한 커밋 메시지 규칙이 있나요?

參팀에서 브랜치 전략을 정해본 적 있나요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. 이스트소프트 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히

개인정보처리방침 이용약관 문의

이이스트소프트풀스택경험·이력2026년 출제

답변 미리보기

Git을 처음 팀 프로젝트에 도입했을 때 가장 중요하다고 느낀 건 브랜치 전략 합의였습니다. 처음엔 모두 main에 바로 push했다가 충돌이 자주 발생했고

예상 답변 시간

60초

예상 꼬리질문

3회

난이도

난이도 중

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

기본 명령에 익숙한가?

commit·branch·merge 같은 기본 흐름이 손에 익었는지 짐작 가능한 답이 자주 통합니다. GUI에만 의존한 흔적은 깊이를 의심받는 자리입니다.

협업 흔적이 답에 있는가?

충돌·실수를 다뤄봤는가?

merge conflict이나 잘못된 commit을 되돌린 경험이 답에 있는지 보는 자리입니다. 한 번도 막힌 적 없다는 답은 의심을 부르는 결로 통합니다.

협업 전략을 의식하는가?

main 보호, 브랜치 명명, 커밋 단위 같은 약속을 알고 따랐는지 짚는 자리입니다. 도구만 알고 협업 룰은 모르는 답은 약하게 들리는 결입니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

이스트소프트 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

저장소 용량 문제 경험으로 초기 세팅 원칙 확립약 60초 잘못된 rebase로 히스토리를 망친 경험약 120초 팀 내 Git 리더 역할을 맡아 갈등 해결 경험약 150초

브랜치 전략 + Git LFS + PR 리뷰 프로세스

약 60초

저장소 용량 문제 경험으로 초기 세팅 원칙 확립

PR 리뷰 프로세스를 도입하면서 혼자 병목이 되는 것 없이 코드 품질을 유지하는 방식을 배웠습니다.

이 결의 특징

이 결이 통하는 자리

예시 답변 2

약 120초

잘못된 rebase로 히스토리를 망친 경험

이 결의 특징

이 결이 통하는 자리

예시 답변 3

약 150초

팀 내 Git 리더 역할을 맡아 갈등 해결 경험

이 결의 특징

이 결이 통하는 자리

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹merge conflict을 겪었을 때 어떻게 푸셨나요?

貳본인이 정한 커밋 메시지 규칙이 있나요?

參팀에서 브랜치 전략을 정해본 적 있나요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. 이스트소프트 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

개인정보처리방침 이용약관 문의