개발자 백업 — 코드는 이미 백업돼 있고, SSD는 서랍용이 아닙니다
백업 글은 대개 "전부 복사해 두라"로 끝납니다. 그런데 개발자의 디스크는 사정이 다릅니다 — 제일 큰 폴더들이 사실은 백업이 필요 없는 것들이거든요.
뭘 백업해야 하는지부터 가르고, 어디에 담을지(여기서 SSD 함정이 나옵니다), 어떻게 둘지 순서로 정리합니다.
결론부터
| 질문 | 답 |
|---|---|
| 코드도 백업하나 | 이미 돼 있습니다 — 원격 저장소가 그 역할입니다 |
| 진짜 백업 대상은 | 다시 못 만드는 것 — 아래 목록 |
| 잠자는 백업 매체는 | 외장 HDD 가 무난 — SSD 는 서랍 보관용이 아닙니다 |
| 구조는 | 3-2-1 — 사본 셋, 매체 두 종류, 하나는 다른 곳에 |
| 꽂아둬도 되나 | ❌ 백업할 때만 연결이 안전합니다 |
1. 백업 대상부터 가르기 — 개발자는 절반이 공짜입니다
디스크에서 자리를 차지하는 것들을 "다시 만들 수 있는가"로 갈라 보세요.
| 무엇 | 백업 |
|---|---|
| 코드 | 필요 없음 — 원격 저장소(git push)가 이미 사본입니다 |
| node_modules·빌드 산출물·도커 이미지 | 필요 없음 — 명령 한 줄로 다시 생깁니다 |
| 프로그램·운영체제 | 필요 없음 — 다시 설치하면 됩니다 |
| 로컬 LLM 모델 파일 | 필요 없음 — 다시 받으면 됩니다 |
| 사진·문서·개인 자료 | ✅ 여기가 진짜 대상입니다 |
| 키·인증서·환경 설정, .env | ✅ 원격에 없는 경우가 많습니다 |
| 로컬 DB 데이터, 원격에 없는 브랜치 | ✅ 잃으면 못 되돌립니다 |
"내 컴퓨터가 오늘 밤 사라지면 되돌릴 수 없는 것" — 그것만이 백업 대상입니다. 개발자는 작업의 큰 덩어리(코드)가 이미 원격에 있어서, 가를 줄만 알면 백업할 양이 생각보다 작습니다.
⚠️ 단, git 은 push 한 것까지만 백업입니다. 로컬에만 있는 브랜치·스태시·커밋 안 한 변경은 원격에 없습니다. "코드는 백업돼 있다"는 말은 push 습관이 있을 때 성립합니다.
2. 매체 고르기 — SSD 는 서랍 보관용이 아닙니다
여기가 이 글에서 제일 중요한 부분입니다. 빠르다고 백업용으로 외장 SSD 를 고르기 쉬운데, 용도가 어긋납니다.
SSD 가 데이터를 지키는 방식은 셀에 전하를 가둬 두는 것이라, 전원이 끊긴 채 오래 두면 전하가 조금씩 새어 나갑니다. 자주 켜는 컴퓨터에서는 문제가 안 되지만, 서랍에 넣어두고 잊는 백업은 정확히 그 약점을 찌르는 사용 방식입니다. 얼마 만에 문제가 되는지는 온도와 셀 상태에 따라 달라 못 박을 수 없지만, 애초에 그 용도로 설계된 물건이 아니라는 것이 판단 기준으로는 충분합니다.
| 매체 | 잠자는 백업으로 |
|---|---|
| 외장 HDD | ✅ 무난합니다 — 전원 없이 두는 보관에 상대적으로 강합니다 |
| 외장 SSD | ⚠️ 자주 쓰는 이동용이 맞는 자리입니다 |
| 클라우드 | ✅ "다른 곳 사본" 역할로 — 아래 3-2-1 참조 |
이 축은 SSD 수명(TBW)과 다른 이야기입니다 — TBW 는 "얼마나 쓸 수 있나"(쓰기 총량)이고, 여기는 "안 쓰고 두면 어떻게 되나"(보존)입니다. 수명이 많이 남은 SSD 도 서랍 보관에는 맞지 않습니다.
HDD 라고 만능은 아닙니다 — 기계 부품이라 떨어뜨리면 약하고, 언젠가는 고장 납니다. 그래서 매체를 고르는 것보다 사본 수로 안전을 만드는 것이 다음 절입니다.
3. 구조 — 3-2-1 하나면 됩니다
백업 설계는 이 한 줄로 끝납니다.
사본 3개 · 매체 2종류 · 1개는 다른 장소에
예: 컴퓨터(원본) + 외장 HDD + 클라우드- 사본 3 — 원본 포함 셋. 하나가 죽어도 둘이 남습니다
- 매체 2종 — 같은 종류 둘은 같은 이유로 같이 죽을 수 있습니다
- 다른 장소 1 — 도난·화재·정전 서지는 한 방에서 일어납니다. 클라우드가 이 자리를 값싸게 채워 줍니다
거창해 보이지만 1번 절에서 대상을 걸렀다면 지킬 양이 작아서, 외장 HDD 하나 + 클라우드 동기화 폴더 하나로 이미 완성입니다.
4. 운용 — 꽂아둔 백업은 백업이 아닙니다
외장 디스크를 항상 꽂아두면 안 됩니다. 두 가지 이유입니다.
- 랜섬웨어 — 컴퓨터가 감염되면 그 순간 연결돼 있는 드라이브도 같이 암호화될 수 있습니다. 백업이 원본과 같이 죽는 경우입니다
- 같은 사고 — 서지·정전·실수의 영향권이 원본과 같아집니다. 정전 때 쓰기 중이던 디스크가 위험하다는 것은 UPS 글의 그 이야기입니다
백업할 때만 연결하고, 끝나면 뽑아 두세요. 주기는 "잃어도 되는 기간"으로 정하면 됩니다 — 일주일치 사진은 아깝지만 견딜 수 있다면 주 1회, 매일이 아까우면 클라우드 동기화가 그 틈을 메웁니다.
자주 묻는 질문
클라우드만으로 하면 안 되나요
동기화형 클라우드는 실수 삭제도 그대로 동기화됩니다(휴지통 복구 기간이 지나면 끝). 백업의 반쪽은 되지만, 내 손에 있는 사본 하나(외장 HDD)와 짝을 이룰 때 3-2-1 이 완성됩니다.
외장 SSD 를 이미 백업용으로 샀는데요
버릴 필요는 없습니다 — 자주 연결해서 쓰는 방식이면 괜찮습니다. 문제는 "넣어두고 잊는" 운용이니, 그 역할만 HDD 나 클라우드에 넘기세요. 외장 SSD 는 이동·작업용으로는 좋은 물건입니다.
NAS 는요
집 안의 "항상 켜진 사본"으로 좋은 자리입니다. 다만 같은 집·같은 전기 안에 있으니 "다른 장소 1"을 대신하지는 못합니다 — 3-2-1 의 클라우드 자리는 남습니다. 상시로 도는 물건이라 UPS 판단이 같이 붙는 자리이기도 합니다.
노트북에서 교체하고 남은 SSD 를 백업용으로 쓰면요
서랍 보관용이면 위와 같은 이유로 권하지 않습니다. 남은 SSD 의 좋은 자리는 베어본 미니PC 에 살리는 것이나 외장 케이스에 넣어 자주 쓰는 이동용입니다.
백업 프로그램이 필요한가요
대상을 1번처럼 걸러 놓으면 폴더 복사로도 됩니다. 도구는 취향의 영역이라 이 사이트가 특정하지 않습니다 — 구조(3-2-1과 분리 보관)가 도구보다 중요합니다.
정리
- 백업 대상은 "다시 못 만드는 것"뿐입니다 — 코드는 push 돼 있는 한 이미 백업입니다
- 잠자는 백업 매체로 SSD 를 고르지 마세요. 전원 없이 두는 보관은 SSD 가 설계된 용도가 아닙니다 — 외장 HDD 가 무난합니다
- 구조는 3-2-1 — 사본 셋, 매체 두 종류, 하나는 다른 곳에
- 백업할 때만 연결하세요. 꽂아둔 백업은 원본과 같이 죽습니다
- push 안 한 로컬 작업은 git 도 못 지켜줍니다 — push 가 백업 습관의 절반입니다
SSD 의 다른 축(쓰기 수명)은 TBW 읽는 법에, 외장 저장 장치의 속도는 외장 SSD 글에 있습니다.
실제와 다른 내용이 있으면 알려주세요. 확인 후 갱신합니다.