백엔드는 빠른 것보다 되돌릴 수 있는 것이 먼저다

1️⃣ 왜 되돌릴 수 있어야 하는가

백엔드는 항상 이 조건을 안고 갑니다.

• 요구사항은 바뀐다
• 외부 연동은 깨진다
• 운영 데이터는 한 번 들어오면 끝이다

여기서 되돌릴 수 없으면:

• 핫픽스 → 임시 로직 → 플래그 → 분기 폭발
• 데이터 보정 스크립트 난무
• “이거 건드리면 터진다” 영역 증가

👉 속도보다 회복 불가능성이 더 큰 리스크입니다.

---

2️⃣ 되돌릴 수 있음의 실체 (추상 말 금지)

① 배포 단위가 작다

• 커밋 단위 명확
• 기능 플래그로 on/off
• 스키마 변경과 로직 분리

👉 롤백이 이론이 아니라 버튼이어야 합니다.

---

② 데이터는 항상 되돌릴 수 있게 남긴다

• 물리 삭제 ❌ → 상태 전이 ⭕
• overwrite ❌ → 이력 테이블 ⭕
• 집계 결과만 저장 ❌ → 원본 보존 ⭕

“원본은 진실이다”

---

③ 외부 연동은 언제든 끊을 수 있어야 한다

• 타임아웃
• 서킷 브레이커
• 수동 disable 스위치

외부 장애 시:

• 우리 시스템부터 죽으면 설계 실패

---

④ 실패는 기록되고 재처리 가능해야 한다

• 재시도 큐
• idempotency key
• 실패 원인 로그 + 재처리 플래그

👉 실패를 “다시 시도 가능 상태”로 남기는 게 핵심입니다.

---

3️⃣ “빠른 백엔드”의 함정

실무에서 말하는 빠름 = 지금 안 깨짐

하지만 운영에서의 빠름 =

상황진짜 빠른 쪽

장애 발생	롤백 가능한 쪽
데이터 오류	재처리 가능한 쪽
요구 변경	플래그로 꺼지는 쪽
인력 교체	문서·이력 남은 쪽

👉 장기적으로는 되돌릴 수 있는 쪽이 항상 빠릅니다.

---

4️⃣ 되돌릴 수 없음의 신호 (경고등)

• “이 테이블은 건드리지 마세요”
• “데이터 한번 들어가면 못 돌려요”
• “장애 나면 수동으로 맞춰야 해요”
• “배포는 새벽에만 합니다”

이 말이 나오면 이미 기술 부채가 아니라 기술 폭탄입니다.

---

5️⃣ 백엔드 설계 기준 문장

“이 변경을 오늘 배포했다가, 내일 아무 일 없었던 것처럼 되돌릴 수 있는가?”

YES면 합격
NO면 아직 설계 중입니다.

---

정리하면
백엔드는 빠르게 가는 기술이 아니라, 안전하게 돌아올 수 있는 기술입니다.
속도는 그 다음입니다.