오늘 방문 /누적 방문 /완성한 레슨 소개 ↗
SECONDTEAM
데이터·DB
🗄️ 레슨

백업과 사고 대비 — 잃고 나서 후회 말고

데이터 사고는 '만약'이 아니라 '언제'의 문제. 미리 깔아두는 안전장치들.

① 오늘의 사고
"어… 주문 내역이 다 사라졌어요?"
반찬가게를 연 지 한 달. 오늘 아침, 테스트한다고 관리자 화면에서 버튼 몇 개를 눌렀는데 — 이번 달 주문 장부가 통째로 비어버렸어요. 손은 떨리고, 되돌릴 버튼은 없습니다.

이런 날은 누구에게나 옵니다. 오늘은 잃기 전에 대비하는 법을 배워요. 잃고 나서 후회하지 않게.

설명을 따라 진행하면, 여기서 직접 쳐보게 돼요 👇
~/my-shop
$ _
📚 「백업과 사고 대비 — 잃고 나서 후회 말고」 레슨 내용 전체 텍스트로 훑어보기
"어… 주문 내역이 다 사라졌어요?"
반찬가게를 연 지 한 달. 오늘 아침, 테스트한다고 관리자 화면에서 버튼 몇 개를 눌렀는데 — 이번 달 주문 장부가 통째로 비어버렸어요. 손은 떨리고, 되돌릴 버튼은 없습니다.

이런 날은 누구에게나 옵니다. 오늘은 잃기 전에 대비하는 법을 배워요. 잃고 나서 후회하지 않게.

서비스를 운영하다 데이터를 날리는 사고는 의외로 거창하지 않아요. 가장 흔한 원인은 뭘까요?
맞아요. 대형 사고보다 내 손으로 낸 작은 실수가 압도적으로 많아요. 그래서 대비는 거창한 게 아니라 작은 습관에서 시작해요.

데이터가 사라지는 길은 크게 셋이에요. 얼굴을 알아두면 미리 막을 수 있어요.

사고 3대장
· 실수 삭제 — "이거 안 쓰는 거겠지" 하고 지웠는데 진짜 쓰던 것
· 덮어쓰기 — 잘못된 값으로 저장해 원래 내용이 영영 사라짐
· 서비스 장애 — 내 잘못이 아니라 서버·DB 쪽 문제로 접근 불가

셋 다 공통점이 있어요 — "미리 복사본이 있었다면" 대부분 살릴 수 있었다는 것.

반찬가게 '오징어볶음' 가격을 9000으로 잘못 저장해서 원래 값 12000을 덮어썼어요. 백업이 없다면, 원래 가격 12000은 어떻게 될까요?

덮어쓰기는 무서워요. 그 자리에 12000이 있었다는 기록 자체가 없어요. 자동 휴지통 같은 건 기본으로 없어요. 그래서 미리 떠둔 복사본(백업)이 유일한 구명줄이에요.

가장 쉬운 백업은 지금 데이터를 파일로 내보내(export) 따로 보관하는 거예요. Claude에게 시켜봐요. 어려운 명령을 외울 필요 없이, 말로 부탁하면 돼요.

우리 반찬가게 메뉴랑 주문 데이터를 backup 폴더에 날짜 붙인 파일로 내보내줘 — 현재 데이터를 파일로 내보내달라고 부탁해요
이렇게 떠둔 복사본이 하나라도 있으면, 사고가 나도 "그날로 되돌릴" 출발점이 생겨요. 핵심은 정기적으로 떠두는 거예요.
실수 삭제를 막는 건 대단한 기술이 아니에요. '확인하는 습관' 하나예요.
😱 사고 나는 사람: "안 쓰는 거겠지" 하고 바로 삭제.
며칠 뒤 그게 단골 주문이었다는 걸 알게 됨.
😌 안 나는 사람: 지우기 전에 "이거 정말 안 쓰나? 백업은 있나?" 한 번 묻고 진행.
같은 1초, 다른 결과.

메뉴 전체 가격을 한 번에 바꾸는 것처럼 되돌리기 어려운 큰 변경 전에는, 먼저 지금 상태의 복사본을 떠두는 습관이 안전해요. 이렇게 떠두는 한 시점의 복사본을 뭐라고 부를까요?

정답! 스냅샷(snapshot)이에요. "이 시점으로 언제든 돌아올 수 있다"는 안심을 주는 사진 한 장이죠. 큰 작업 전엔 항상 한 장 찍고 시작해요.

우리 가게 데이터를 맡긴 Supabase 같은 서비스에는 백업 기능이 내장돼 있어요.

알아두면 든든한 것
· 운영 DB는 보통 자동으로 정기 백업이 떠져요 (요금제·설정에 따라 다름)
· 관리 화면에서 백업·복원 메뉴를 직접 찾아볼 수 있어요
· 단, "있겠지" 하고 믿지 말고 내 서비스에 실제로 켜져 있는지 한 번 확인!

도구의 백업 + 내가 떠두는 내보내기, 둘 다 있으면 마음이 한결 놓여요.

단골들의 주문 데이터를 한꺼번에 정리하는 큰 작업. 사고 안 나는 순서로 놓아보세요.
핵심은 '백업 먼저'예요. 되돌릴 곳을 만들어 두고 출발하면, 어떤 실수도 사고가 아니라 '되돌리면 되는 일'이 돼요.
이제 AI에게 데이터 작업을 시키는 일이 많아져요. 손님이 실제로 쓰는 운영(production) 데이터를 다룰 때, 가장 안전한 방식은?
맞아요. AI는 빠르지만 한 번에 많은 걸 되돌릴 수 없게 바꿀 수도 있어요. 운영 데이터 직접 수정은 금지가 기본, 항상 백업을 떠두고·무엇을 바꿀지 먼저 보여달라고 시켜요.

AI가 위험한 작업을 멋대로 하지 않게, 말로 안전선을 그어두면 돼요. 운영 데이터를 다룰 땐 이렇게 부탁해요.

앞으로 운영 데이터는 직접 고치지 말고, 바꾸기 전에 먼저 백업을 뜨고 무엇을 어떻게 바꿀지 나한테 보여준 다음 내 확인을 받아줘 — 실행 전 확인을 요청하는 안전 수칙을 걸어요
이 한마디가 'AI가 낸 사고'를 막는 가장 싼 보험이에요. 운영 데이터 앞에서는 항상 한 박자 늦춰요.
한 줄로
데이터는 실수 삭제·덮어쓰기·서비스 장애로 사라져요. 막는 법은 소박해요 — 정기 백업(내보내기)·삭제 전 확인·큰 변경 전 스냅샷, 그리고 운영 데이터는 AI에게도 직접 못 건드리게 하기.

여기까지가 데이터·DB 코스예요. 손님·메뉴·주문을 담고, 내 것을 지키고, 잃지 않게 대비하는 법까지 — 가게의 '기억'을 다 갖췄어요.

다음 코스에서
그런데 백업이 '데이터'를 지킨다면, 내가 만든 코드는 누가 지킬까요? 잘못 고친 코드를 한 줄로 되돌리고, 어제의 가게로 시간여행하는 법 — 다음 Git 코스에서 배웁니다. 가게는 계속 자랍니다. 🌱