왜 나는 내 백업 스크립트를 신뢰하지 않게 되었고 대신 SaaS를 만들었는가
Source: Dev.to
“오 이런” 순간
우리 모두 겪어봤죠. $5짜리 VPS에 사이드 프로젝트를 띄워두고, pg_dump 혹은 mysqldump를 매일 새벽 3시에 실행하도록 간단한 bash 스크립트를 짜서 crontab에 올려두고, 책임감과 안전함을 느꼈던 그때.
6개월 뒤, 실제로 그 데이터가 필요해졌을 때 백업 폴더를 열어보면:
- 파일 크기: 0 KB.
- 혹은 더 최악인 경우: 파일은 존재하지만 복원 명령을 한 번도 테스트해보지 않아 복원에 실패하고, 버전 불일치 때문에 여기저기 에러가 터지는 상황.
이게 바로 내가 Oops Backup을 만들게 된 이유입니다.
개발자는 백업 자체—“데이터가 저장됐는가?”—에 집착하지만 복구—“서버에 불이 나도 5분 안에 서비스를 복구할 수 있는가?”—에 대해서는 거의 신경 쓰지 않죠.
내가 만든 엉성한 쉘 스크립트와 크론 잡은 세 가지 큰 문제점을 가지고 있었습니다:
- 가시성 부족 – 백업이 조용히 실패해도(디스크 부족, 인증서 변경 등) 나는 늦게야 알게 됩니다.
- 스토리지 지옥 – 데이터베이스와 같은 서버에 백업을 저장하는 것은 재앙을 부르는 레시피입니다. 스크립트로 S3에 옮기는 건 유지보수가 번거롭습니다.
- 복구 불안 – 데이터베이스 복구는 보통 SSH로 접속해 파일을 찾고, 압축을 풀고, 가져오기 명령이 제대로 동작하길 기도하는 과정이었습니다.
솔루션 구축 (그리고 “아니오”라고 말하기 배우기)
나는 백업 과 복구를 사후적인 생각이 아니라 일등 시민으로 대우하는 도구를 만들기로 했습니다.
- 인프라를 단순하게 유지하는 것을 굉장히 좋아합니다. Oops Backup은 Docker 컨테이너 안에서 깔끔히 실행되고, Portainer로 관리되며, 내 스택에 자연스럽게 녹아듭니다.
- 자동 스케줄링 – 더 이상 수동으로 크론을 편집할 필요가 없습니다.
- 스토리지 – S3 호환 스토리지(AWS, Cloudflare R2, Backblaze B2), Oops Storage, 혹은 SFTP 전송을 위한 네이티브 통합을 제공합니다.
- 원클릭 복구 – UI에서 백업을 탐색하고 특정 데이터베이스 인스턴스로 바로 복구할 수 있습니다.
기능 정리
공개적으로 개발한다는 것은 잘못을 인정하는 것을 의미합니다. 처음엔 모든 것을 지원하고 싶었습니다: MongoDB, PostgreSQL, MySQL, 그리고 Microsoft SQL Server. 지난 주에 MSSQL 지원을 공식적으로 중단했습니다.
왜? 가벼운 도구 안에 Windows‑중심의 MSSQL 생태계를 포함시키는 것은 프로젝트를 부풀리고 핵심 사용자층에게 집중하는 걸 방해했습니다. 내가 아는 인디 해커와 개발자들의 약 95 %는 “LAMP” 혹은 “MERN” 스택을 사용합니다. MSSQL을 뺌으로써 Postgres, Mongo, MySQL 경험을 완벽하게 만들기에 더 집중할 수 있었습니다. 때때로 제품을 살리기 위해서는 기능을 과감히 없애야 합니다.
현재 UI를 마무리하고 다듬는 중이며, 그 과정을 X, Threads, Bluesky에 공유하고 있습니다.
3년 전 만든 backup.sh 파일을 더 이상 믿고 싶지 않다면, 내가 만들고 있는 것을 확인해 보세요:
솔직하고 가혹한 피드백을 기다립니다. 현재 사용 중인 백업 솔루션에 없는 가장 큰 기능은 무엇인가요?