롤백과 백업: 문제가 생겨도 안전하게 되돌리는 방법
18강. 롤백과 백업: 문제가 생겨도 안전하게 되돌리는 방법
1. 이번 강의에서 해결할 문제
문제가 생겼을 때 reset --hard나 force push로 main을 되돌리면 다른 변경과 감사 이력이 사라질 수 있습니다. 되돌림 커밋과 데이터별 백업을 구분합니다.
2. 학습 목표
3. 핵심 개념
롤백은 실행 중 서비스를 이전 정상 버전으로 돌리는 운영 조치이고, Git revert는 기존 커밋의 반대 변경을 새 커밋으로 기록합니다. 정적 Pages 사이트는 소스 이력이 백업 역할을 하지만 localStorage 사용자 진도는 서버에 모이지 않으므로 사이트 운영자가 복구할 수 없습니다. 서버 데이터베이스는 별도 백업·복원 테스트가 필요합니다.
되돌림과 백업을 구분하기
| 용어 | 대상 | 결과 | 한계 |
|---|---|---|---|
| rollback | 현재 서비스 버전 | 마지막 정상 버전 재배포 | 사용자 데이터 복원과 다름 |
git revert | 특정 커밋의 변경 | 반대 변경을 새 커밋으로 추가 | 이후 정상 변경까지 함께 되돌리지 않도록 diff 검토 필요 |
| backup | 소스 밖의 데이터·설정 복사본 | 복원에 사용할 별도 산출물 | 파일 존재만으로 복원 가능성을 보장하지 않음 |
| restore | 백업에서 실제 상태 복구 | 새 환경에서 데이터 사용 가능 | 절차·권한·버전 호환 검증 필요 |
정적 소스, 브라우저 localStorage, 서버 DB는 책임이 다릅니다. Git으로 HTML 소스를 복원해도 사용자의 브라우저에만 있던 학습 기록은 운영자가 가져올 수 없습니다. 반대로 DB 백업이 있어도 해당 애플리케이션 버전과 스키마에 실제 복원해 보지 않았다면 복구 시간을 장담할 수 없습니다.
실행 전에 반드시 고정할 값
문제 배포 SHA:
되돌릴 커밋 SHA:
마지막 정상 배포 SHA:
문제 커밋 이후 정상 커밋:
영향 파일과 사용자 경로:
복구 브랜치 이름:
검증 명령과 승인자:
"어제쯤 정상"이라는 기억으로 선택하지 않습니다. 배포 이력의 SHA와 실제 공개 화면을 연결해 확인합니다.
4. 단계별 실습
1. PowerShell
실행 위치: 깨끗한 저장소 루트
실행 전 확인: git status가 깨끗하고 문제 SHA·마지막 정상 SHA·포함 파일을 git show로 확인합니다.
대상: 가상 문제 커밋 한 개
아래 0123... 값은 실행용 SHA가 아닙니다. 실제 사고 대응에서는 배포 기록에서 검증한 전체 SHA로 교체하고, 공유 main이 아니라 별도 복구 브랜치에서 진행합니다.
git fetch origin main
git status --short --branch
git log -5 --oneline
$badCommit = "0123456789abcdef0123456789abcdef01234567"
if ($badCommit -eq "0123456789abcdef0123456789abcdef01234567") {
throw "예시 SHA를 실제로 검증한 문제 커밋 SHA로 교체하세요."
}
git show --stat $badCommit
git switch -c ops/revert-bad-deploy origin/main
git revert --no-edit $badCommit
npm.cmd run build
git diff origin/main...HEAD --stat
명령을 한 단계씩 이해하기
fetch는 원격 main 상태를 읽어 오지만 현재 작업 파일을 바꾸지 않습니다.status와log로 브랜치·변경·최근 SHA를 확인합니다. 깨끗하지 않다면 stash나 reset을 자동 선택하지 말고 변경 소유자를 확인합니다.git show --stat로 되돌릴 커밋이 실제 문제 파일만 포함하는지 확인합니다.git switch -c ... origin/main이 최신 원격 main에서 별도 복구 브랜치를 만듭니다.git revert는 과거 커밋을 삭제하지 않고 상쇄하는 새 커밋을 만듭니다.- build와 diff가 복구 결과와 영향 범위를 검증합니다.
- PR 검토와 배포 후 사용자 경로 확인이 끝나기 전에는 복구 완료로 보지 않습니다.
예상 이력은 다음과 같습니다.
A 정상 ─ B 문제 ─ C 이후 정상 변경 ─ R(B를 상쇄하는 revert)
reset --hard B^로 main을 이동하면 B 뒤의 C까지 공개 이력에서 밀어낼 수 있지만, revert R은 C를 유지하면서 B의 변경만 상쇄하도록 검토할 수 있습니다.
예상 결과: 실제 SHA로 바꿨을 때 원래 이력을 보존하는 revert 커밋과 검증된 복구 diff가 생성됩니다.
2. GitHub 웹 화면
실행 위치: 복구 PR과 Actions
실행 전 확인: 잘못된 SHA를 다시 확인하고 다른 정상 변경이 함께 취소되지 않는지 diff를 검토합니다.
대상: revert 커밋의 Pages 배포
1. 복구 PR diff 확인
2. build 성공 확인
3. main 병합
4. Pages deploy 완료 확인
5. 사용자 경로 재점검
예상 결과: 복구 과정과 원인이 커밋·PR·workflow 이력에 남습니다.
5. 배포·운영 흐름이 동작하는 이유
revert는 과거 이력을 삭제하지 않고 상쇄 변경을 추가하므로 협업 중인 main에서 안전합니다. build와 PR diff는 복구가 다른 정상 변경을 제거하지 않는지 검증합니다.
6. 자주 하는 실수와 안전한 해결법
7. 직접 실습
8. 이해 점검 질문 3개
9. 핵심 요약
다음 강의 연결
복구 기준을 마련했으므로 19강. 배포 방식 선택에서 정적 사이트·서버·컨테이너마다 배포와 롤백 전략이 어떻게 달라지는지 비교합니다.
롤백과 백업: 문제가 생겨도 안전하게 되돌리는 방법 미니 퀴즈
선택 즉시 정답과 해설을 확인할 수 있습니다. 결과는 이 브라우저에만 저장됩니다.
학습을 마쳤나요?
직접 실습과 점검 질문까지 확인한 뒤 완료로 표시하세요.