개발에서 롤백(Rollback): 정의, 방법 및 작동 방식

개발에서 롤백이란

롤백은 시스템을 이전의 안정적인 상태로 되돌리는 작업입니다. 개발 맥락에서 이는 Git에서 커밋을 취소하거나, 데이터베이스 트랜잭션을 롤백하거나, 서버에서 애플리케이션의 이전 버전으로 돌아가는 것을 의미할 수 있습니다. 이 용어는 영어 “rollback”에서 유래했으며 모든 플랫폼의 개발자 용어에 확고히 자리 잡았습니다.

롤백의 필요성은 새로운 변경 사항이 기능을 손상시키거나, 오류를 발생시키거나, 품질 검사에 실패할 때 발생합니다. 잘 조직된 개발 프로세스에서 롤백은 실패의 신호가 아니라 워크플로에 내장된 표준 절차입니다. 팀이 문제가 있는 변경 사항을 빠르게 롤백할수록 사용자에게 미치는 버그의 영향이 줄어듭니다.

다양한 도구는 서로 다른 롤백 메커니즘을 제공합니다: Git은 안전한 revert와 파괴적인 reset 사이의 선택권을 제공하고, 데이터베이스는 트랜잭션 롤백을 지원하며, CI/CD 시스템은 버전 간에 트래픽을 전환할 수 있습니다. 접근 방식의 선택은 컨텍스트와 변경 기록 보존 요구 사항에 따라 달라집니다.

Git revert vs git reset: 차이점

Git revert는 이전 변경 사항을 취소하는 새 커밋을 생성하는 안전한 롤백 방법입니다. 기록은 선형으로 유지되고 모든 이전 커밋이 보존됩니다. 여러 개발자가 작업하는 공유 브랜치에서 되돌리기 위한 유일한 올바른 선택입니다. Git revert는 기록을 삭제하지 않습니다 — 롤백 사실을 새 변경 사항으로 추가합니다.

Git reset은 현재 브랜치 포인터를 지정된 커밋으로 이동시키고 이후의 모든 변경 사항을 폐기합니다. 플래그(soft, mixed 또는 hard)에 따라 reset은 작업 디렉토리와 인덱스를 다르게 처리합니다. hard 모드는 기록에서 변경 사항을 완전히 제거하므로 공유 브랜치에 위험하며 로컬 작업에만 적합합니다.

revert 사용 시기

Revert는 공유 브랜치(main, develop, release)에서 사용됩니다. 기록을 보존하고 다른 개발자가 변경 사항이 취소되었음을 이해할 수 있게 합니다. revert 후 안전하게 git pull을 실행할 수 있습니다 — 시스템은 다시 쓰여진 기록과 관련된 충돌을 생성하지 않습니다. 팀 작업에서 revert가 기본 표준입니다.

# 새 커밋을 생성하여 마지막 커밋 취소
git revert HEAD

# 해시로 특정 커밋 취소
git revert a1b2c3d

reset 사용 시기

Reset은 아직 변경 사항을 게시하지 않은 로컬 브랜치에서 적합합니다. 실험 중이었고 기록을 완전히 정리하려면 — reset hard가 그렇게 할 것입니다. 로컬 브랜치에서는 reset mixed를 사용하여 커밋을 취소하면서 작업 디렉토리에 변경 사항을 유지하여 다시 커밋할 수 있습니다.

# 마지막 커밋 취소, 작업 디렉토리에 변경 사항 유지
git reset HEAD~1

# 완전 취소 — 변경 사항이 영구적으로 제거됨
git reset --hard HEAD~2

데이터베이스 롤백: 트랜잭션과 ACID

트랜잭션 롤백은 현재 트랜잭션 내에서 수행된 모든 변경 사항을 취소하고 데이터베이스를 트랜잭션 시작 시점의 상태로 되돌리는 작업입니다. 이는 원자성을 보장합니다 — ACID의 네 가지 원칙(Atomicity, Consistency, Isolation, Durability) 중 하나입니다. 트랜잭션의 어떤 단계에서 오류가 발생하면 롤백이 실행되고 데이터는 원래 상태로 돌아갑니다.

롤백 메커니즘은 WAL(Write-Ahead Log)을 통해 구현됩니다. 데이터 페이지를 수정하기 전에 DBMS는 로그에 이전 값과 새 값을 기록합니다. 롤백 중에 시스템은 로그를 읽고 수정된 모든 페이지의 원래 값을 복원합니다. 이는 정전이 발생하더라도 트랜잭션을 올바르게 취소할 수 있도록 보장합니다.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: 부분 롤백

긴 트랜잭션에서는 세이브포인트를 사용하는 것이 편리합니다 — 전체 트랜잭션을 완료하지 않고 롤백할 수 있는 중간 저장 지점입니다. 이를 통해 복잡한 작업 내에서 오류를 처리하면서 다른 부분의 진행 상황을 잃지 않습니다. 세이브포인트는 대부분의 관계형 DBMS(PostgreSQL, MySQL, Oracle)에서 지원됩니다.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

배포 롤백: 전략과 도구

배포 롤백은 실패한 배포 후 실행 중인 애플리케이션을 이전 버전으로 되돌리는 것입니다. 이는 프로덕션 환경에 중요한 기능입니다: 복구 시간(MTTR)은 SLA 및 사용자 경험에 직접적인 영향을 미칩니다. 최신 플랫폼은 아키텍처 및 가용성 요구 사항에 따라 여러 롤백 전략을 제공합니다.

Blue-green 배포

Blue-green은 두 개의 동일한 환경(blue: 현재 버전, green: 새 버전)이 동시에 실행되는 전략입니다. 성공적인 배포 후 트래픽이 green으로 전환됩니다. 새 버전이 올바르게 작동하지 않으면 트래픽 스위치가 blue로 돌아갑니다. 롤백은 즉시 수행되며 재배포가 필요하지 않습니다 — 라우팅만 변경하면 됩니다.

자동 롤백이 포함된 Canary 릴리스

Canary 배포는 트래픽의 일부를 새 버전으로 보내고 메트릭(오류율, 응답 시간, 성공적인 요청 비율)을 모니터링합니다. 메트릭이 악화되면 시스템이 자동으로 canary를 롤백하고 모든 트래픽을 안정적인 버전으로 보냅니다. Kubernetes 및 서비스 메시(Istio, Linkerd)는 이 전략을 기본 지원합니다.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

개발에서 롤백의 실제 예제

개발자가 변경 사항을 롤백해야 하는 세 가지 일반적인 시나리오를 살펴보겠습니다. 각 시나리오는 터미널의 간단한 명령부터 CI/CD를 포함하는 다단계 절차까지 고유한 접근 방식이 필요합니다.

시나리오 1: main에 실수로 커밋

실수로 버그가 있는 커밋을 main에 푸시했습니다. 팀의 기록을 잃지 않고 변경 사항을 롤백하는 것이 목표입니다. git revert를 사용하여 되돌리기 커밋을 만든 다음 git push를 실행하세요. 모든 팀 구성원이 롤백을 확인하고 충돌 없이 작업을 계속할 수 있습니다. 이것이 가장 안전하고 투명한 방법입니다.

git checkout main
git pull origin main
git revert HEAD
git push origin main

시나리오 2: 데이터베이스 마이그레이션 실패

데이터베이스 마이그레이션이 실패하고 일부 데이터가 손상되었습니다. 마이그레이션 스크립트에서 트랜잭션 롤백을 사용하고 이미 적용된 변경 사항은 백업에서 복원하세요. 잘 설계된 시스템에서는 각 마이그레이션이 트랜잭션으로 래핑됩니다 — 오류 발생 시 DBMS가 자동으로 롤백을 수행합니다.

시나리오 3: 심각한 버그가 있는 배포

새 버전을 배포한 후 인증이 작동하지 않음을 발견했습니다. blue-green을 사용하는 경우 롤백은 라우터를 다시 전환하는 것입니다. 롤링 업데이트의 경우 kubectl rollout undo 명령이 이전 버전으로 되돌립니다. 이상적으로 롤백 프로세스는 자동화되어 1분을 넘지 않아야 합니다.