새벽에 급하게 올라온 장애 알림, 브랜치를 잘못 만졌다는 팀원의 다급한 메시지, 그리고 “일단 git reset –hard 했는데요…”로 시작하는 보고. 시니어 개발자와 주니어 개발자를 가장 빠르게 구분하는 순간은 화려한 신기능을 만들 때가 아니라, 이런 사고가 터졌을 때입니다.
add, commit, pull, push는 이미 손에 익었을 후배님도 많을 거예요. 하지만 실무에서 진짜 필요한 건 그다음 단계, 즉 커밋을 되돌리고 실수를 복구하는 명령어들입니다. 최근 dev.to에 올라온 한 아티클도 add, commit, pull, push가 이미 익숙한 개발자를 대상으로 바로 이 지점을 다루고 있습니다.
장애 상황에서 나오는 진짜 실력 차이
신입 개발자 시절에는 브랜치가 꼬이면 그냥 클론을 새로 받는 것도 방법이었어요. 하지만 연차가 쌓이고 맡는 브랜치가 커질수록, 히스토리를 통째로 갈아엎을 여유가 없어집니다. 실수를 정확히 진단하고 필요한 부분만 되돌리는 능력이 시니어와 주니어를 가르는 기준이 되는 이유입니다.
이 글에서는 사고 복구 상황에서 실제로 자주 쓰이는 다섯 가지 명령어, git reset, git revert, git reflog, git cherry-pick, git push –force-with-lease를 순서대로 살펴봅니다. 각 명령어가 무엇을 하는지뿐 아니라, 왜 이걸 알아야 채용 면접과 실무 평가에서 유리한지도 함께 짚어볼게요.
되돌리기 3형제, git reset –soft·–mixed·–hard
git reset은 커밋 히스토리, 스테이징 영역, 작업 디렉터리라는 세 개 층을 어디까지 되돌릴지 선택하는 명령어입니다. 옵션에 따라 결과가 완전히 달라지기 때문에, 차이를 모르고 쓰면 사고로 이어지기 쉽습니다.
- –soft: 커밋만 되돌리고 변경 내용은 스테이징 상태로 남깁니다. 커밋 메시지를 다시 쓰고 싶을 때 유용해요.
- –mixed(기본값): 커밋을 되돌리고 스테이징도 해제하지만, 파일 내용은 작업 디렉터리에 그대로 남습니다.
- –hard: 커밋과 스테이징, 작업 디렉터리 내용까지 모두 되돌립니다. 되돌린 변경 사항은 화면에서 즉시 사라집니다.
세 옵션 중 –hard가 가장 위험합니다. 아직 커밋하지 않은 작업이 있다면 git reset –hard 한 번으로 몇 시간 치 작업이 통째로 사라질 수 있거든요. 그래서 git 공식 문서를 비롯한 여러 레퍼런스에서도 –hard 옵션은 각별한 주의가 필요하다고 공통적으로 강조합니다.
커밋을 지우지 않고 되돌리는 git revert
운영 브랜치나 공유 브랜치에서는 git reset을 함부로 쓰면 안 됩니다. 이미 다른 팀원이 받아간 히스토리를 강제로 지우면, 누군가의 로컬 저장소와 원격 저장소가 어긋나 버리거든요.
이럴 때 쓰는 게 git revert입니다. 문제를 일으킨 커밋을 지우는 대신, 그 변경을 정확히 반대로 되돌리는 새 커밋을 추가합니다. 히스토리에는 무엇이 배포됐고 왜 문제였고 어떻게 되돌렸는지가 그대로 남기 때문에, 팀 전체가 상황을 파악하기 쉬워집니다. 원칙은 간단해요. 공유 브랜치의 잘못된 커밋은 reset이 아니라 revert로 처리한다는 것입니다.
사라진 커밋을 살려내는 git reflog
그렇다면 이미 git reset –hard를 실행해서 커밋이 사라진 것처럼 보이는 상황이라면 어떻게 할까요? 여기서 등장하는 게 git reflog입니다.
git log가 지금 브랜치에서 도달 가능한 커밋만 보여주는 것과 달리, git reflog는 HEAD가 최근 어디를 가리켰는지에 대한 로컬 기록을 따로 남깁니다. git 공식 문서에 따르면 reflog는 브랜치·리셋·체크아웃 같은 참조 이동을 순서대로 기록하기 때문에, git log에서 사라진 커밋도 reflog에서는 그대로 찾을 수 있는 경우가 많습니다.
사라진 커밋 해시를 찾았다면, 곧바로 git reset –hard로 되돌리기보다는 git branch rescue 명령으로 새 브랜치를 만들어 먼저 안전하게 확보하는 편을 권합니다. 다만 한 가지는 기억해야 해요. reflog는 한 번도 커밋되거나 스태시된 적 없는 변경 사항까지 복구해 주지는 않습니다.
커밋 하나만 콕 집어오는 git cherry-pick
다른 브랜치 전체를 병합하거나 그 위로 리베이스할 필요 없이, 딱 커밋 하나만 가져오고 싶을 때가 있습니다. 예를 들어 신규 환경 설정 커밋 하나만 현재 브랜치에 옮기고 싶은 경우가 그렇습니다.
git cherry-pick 뒤에 커밋 해시를 붙여 실행하면, 해당 커밋이 담고 있는 변경 내용을 현재 브랜치에 그대로 적용하고 새로운 해시를 가진 커밋을 만듭니다. 원본 커밋을 옮기는 게 아니라 복사하는 개념에 가깝기 때문에, 같은 변경이 두 브랜치에 서로 다른 해시로 존재하게 됩니다.
안전한 강제 푸시, git push –force-with-lease
rebase나 amend, cherry-pick으로 커밋 해시가 바뀌고 나면, 원격 브랜치와 로컬 히스토리가 어긋나 일반 push가 거부됩니다. 이때 git push –force를 쓰면 원격 브랜치를 로컬 상태로 무조건 덮어써 버립니다. 그사이 다른 사람이 같은 브랜치에 푸시했다면, 그 작업이 통째로 사라질 수 있어요.
git push –force-with-lease는 조금 더 신중합니다. 로컬이 기억하는 원격 상태와 실제 원격 상태가 같을 때만 강제 푸시를 허용하고, 그사이 다른 커밋이 올라왔다면 푸시 자체를 거부합니다. 개인 브랜치를 정리할 때도 습관적으로 –force 대신 –force-with-lease를 쓰는 팀이 늘고 있는 이유입니다.
이 명령어들이 채용 면접에 등장하는 이유
기술 면접에서 “git reset과 git revert의 차이를 설명해 보세요” 같은 질문을 받아본 후배님이라면, 이게 단순 암기 테스트가 아니라는 걸 이미 느끼셨을 거예요. 면접관은 명령어 사용법보다 이 사람이 사고 상황에서 침착하게 판단할 수 있는가를 보고 싶어 합니다.
2026년 발표된 Stack Overflow 2025 개발자 서베이에 따르면 GitHub는 코드 협업·문서화 도구 중 인지도(admired) 75.8%로 가장 높은 도구로 꼽혔습니다. Git 기반 워크플로가 사실상 업계 표준으로 자리 잡았다는 뜻이고, 그만큼 Git 활용 능력이 이력서 밖에서도 조용히 평가받는 항목이라는 의미이기도 합니다.
실무에서는 코드 리뷰 코멘트보다 사고 대응 로그에서 실력이 더 정확히 드러나는 경우가 많아요. 장애 발생 시 reset 대신 revert를 선택하고, reflog로 침착하게 복구 경로를 찾는 모습은 그 자체로 강력한 커리어 신호가 됩니다.
지금 점검해볼 체크리스트
아래 다섯 가지 중 세 개 이상에서 “아니오”가 나온다면, 다음 사고 상황에서 당황할 가능성이 높습니다. 지금 로컬 저장소에서 가볍게 연습해 보는 것을 권합니다.
- git reset의 –soft·–mixed·–hard 차이를 30초 안에 설명할 수 있는가
- 공유 브랜치에서 실수했을 때 reset이 아니라 revert를 먼저 떠올리는가
- git log에서 커밋이 사라졌을 때 reflog를 먼저 확인하는 습관이 있는가
- 브랜치 전체가 아니라 커밋 하나만 옮겨야 할 때 cherry-pick을 쓸 수 있는가
- 강제 푸시가 필요할 때 –force 대신 –force-with-lease를 습관적으로 쓰는가
관련 글
같은 Git 주제를 코드 리뷰 관점에서 다룬 글도 함께 참고하면 좋습니다. 신입과 시니어가 리뷰에서 쓰는 명령어 차이를 더 자세히 다루고 있습니다.
AI 에이전트가 대규모 커밋을 자동으로 만들어내는 요즘, Git 저장소 자체의 확장성 이슈도 함께 짚어볼 만합니다.
기술 역량이 채용 경쟁력으로 어떻게 이어지는지 궁금하다면 아래 글도 참고해 보세요.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요