크롤러 - 취미 프로젝트 크롤러 백업 구조 정리기

용량 문제를 계기로 DB dump, JSON 산출물, Mini PC 복제를 정리한 기록

취미로 운영하는 프로젝트는 회사 서비스와는 다른 제약이 있다. 가장 큰 차이는 비용이다. 트래픽이 크지 않더라도 데이터는 계속 쌓이고, 자동화가 늘어나면 어느 순간 운영 문제를 만나게 된다. 그렇다고 매번 서버를 키우거나 유료 리소스를 늘리는 방식으로 해결하고 싶지는 않았다.

이번 작업도 그런 고민에서 시작했다. 원래 크롤러는 하나의 운영 환경에 거의 의존하고 있었다. 그러다 Oracle Cloud 무료 VPS의 사양이 줄어들 수 있다는 이야기를 듣고, Mini PC로 이전하는 계획을 세웠다. 나중에 기존 사용자에게는 영향이 크지 않다는 정보를 확인하면서 완전 이전은 보류했지만, 이미 준비한 Mini PC를 그냥 두기에는 아까웠다.

그래서 방향을 바꿨다. “서버를 옮길 것인가?”가 아니라 “이미 있는 자원으로 백업과 복구 가능성을 어떻게 높일 것인가?”를 기준으로 다시 봤다.

 

 

표면적인 문제는 용량 부족이었다

처음 눈에 보인 문제는 디스크 용량이었다. 크롤러가 만드는 산출물, DB dump, 압축 파일, 캐시, Docker 계층이 섞이면서 로컬 디스크 사용량이 계속 올라갔다. 특히 크롤러가 하나에서 두 개의 운영 자원으로 확장되면서, 어디까지가 실제 운영 데이터이고 어디부터가 임시 파일인지 구분하기 어려워졌다.

단순히 큰 파일을 찾아 지우는 방식으로도 당장은 공간을 확보할 수 있다. 하지만 그 방식은 위험했다. 백업이 된 줄 알고 원본을 지웠는데, 나중에 보니 복구할 수 없는 상태라면 용량 문제보다 더 큰 장애가 된다.

그래서 먼저 질문을 바꿨다.

• 어떤 데이터가 반드시 복구 가능해야 하는가?
• 어떤 데이터는 다시 만들 수 있는가?
• 백업이 “존재한다”는 것과 “복구 가능하다”는 것은 어떻게 구분할 것인가?
• 원본을 삭제해도 된다는 기준은 무엇인가?

이 질문을 던지고 나니, 실제 문제는 단순한 용량 부족이 아니었다. 백업 경로와 삭제 기준이 충분히 명확하지 않은 것이 더 큰 문제였다.

DB와 JSON 산출물을 분리해서 보기

크롤러 시스템에는 성격이 다른 데이터가 섞여 있었다. 하나는 DB에 들어간 정제된 데이터이고, 다른 하나는 크롤러가 만들어낸 JSON 산출물이다.

DB는 복원 절차가 중요하다. 단순 파일 복사보다 logical dump를 남기고, 압축한 뒤 복구 목록을 확인할 수 있어야 한다. 또한 DB에는 민감하거나 내부 운영과 가까운 정보가 포함될 수 있으므로 암호화된 백업 경로로 보내는 편이 맞다.

반면 JSON 산출물은 사람이 직접 열어 확인해야 할 때가 많다. 다른 PC에서 빠르게 내용을 확인하거나, 특정 작품 단위로 문제를 추적해야 할 수도 있다. 그래서 JSON은 과하게 암호화하기보다 일반 파일 형태로 백업해 접근성을 유지하는 편이 낫다고 판단했다.

정리하면 기준은 이랬다.

• DB: 압축된 dump로 남기고, 암호화된 백업 경로에 보관한다.
• JSON 산출물: 다른 PC에서도 쉽게 열 수 있도록 일반 백업 경로에 둔다.
• 로컬 디스크: 영구 보관소가 아니라 운영 캐시로 본다.

이 기준을 세우고 나니 “무엇을 남기고 무엇을 지울 수 있는지”가 훨씬 명확해졌다.

OneDrive만 믿지 않기

기존에는 OneDrive가 중요한 백업 위치였다. 개인 프로젝트에서 OneDrive는 비용 대비 꽤 좋은 선택이다. 이미 사용 중인 저장소를 활용할 수 있고, 다른 PC에서도 접근하기 쉽다.

하지만 백업을 OneDrive 하나에만 의존하면 또 다른 단일 장애점이 된다. 계정 문제, 동기화 문제, 원격 저장소 문제 중 하나만 생겨도 복구 계획이 흔들릴 수 있다.

그래서 Mini PC 두 대를 보조 복제 지점으로 사용하기로 했다. 완전히 새로운 클라우드 비용을 추가하지 않고, 이미 준비된 장비를 활용해 복구 가능성을 높이는 방식이다.

최종 구조는 다음과 같이 잡았다.

• DB dump는 최근 3일치를 유지한다.
• DB dump는 OneDrive와 Mini PC A, Mini PC B에 복제한다.
• JSON 산출물은 OneDrive와 Mini PC 복제본을 함께 둔다.
• 로컬에는 필요한 기간의 운영 데이터와 캐시만 남긴다.

이렇게 하면 OneDrive에 문제가 생겨도 Mini PC 쪽에 복구 재료가 남는다. 반대로 Mini PC 중 하나가 꺼져도 OneDrive와 다른 Mini PC를 통해 최소한의 복구 경로를 유지할 수 있다.

삭제는 백업 성공 이후에만

이번 작업에서 가장 중요하게 본 부분은 삭제 조건이었다. 용량을 줄이는 것보다 중요한 건, 지워도 되는 상태를 객관적으로 확인하는 일이었다.

그래서 백업이 끝났다는 marker를 기준으로 retention cleanup이 동작하도록 정리했다. 파일을 만들고, 압축하고, 원격 저장소와 Mini PC에 복제한 뒤, 검증 가능한 상태가 되었을 때만 정리를 진행하는 방식이다.

 

 

 

 

이 흐름의 핵심은 단순하다.

백업 완료가 확인되기 전에는 원본을 지우지 않는다.

백업 자동화에서 흔히 놓치기 쉬운 부분이 이 지점이라고 생각한다. “매일 백업 스크립트를 실행한다”는 것만으로는 충분하지 않다. 실패했을 때 어떤 상태로 남는지, 성공 여부를 무엇으로 판단하는지, 삭제 작업이 어떤 조건에서만 실행되는지가 더 중요하다.

자동화와 검증

백업은 사람이 기억해서 실행하는 작업이 되면 결국 빠진다. 그래서 DB dump, JSON 산출물 복제, retention cleanup은 주기적으로 실행되도록 자동화했다. 다만 자동화 자체보다 검증을 더 중요하게 봤다.

확인한 내용은 다음과 같다.

• DB dump 파일이 생성되는지
• 압축 파일이 정상인지
• 복구 목록을 읽을 수 있는지
• OneDrive와 Mini PC 복제본이 만들어지는지
• marker가 올바르게 남는지
• marker가 없을 때 cleanup이 실행되지 않는지
• 작업 후 로컬 디스크 사용량이 실제로 줄었는지

실제 정리 후 home disk 사용률은 77%에서 69%로 낮아졌다. service disk는 68%에서 66%로 낮아졌다. Docker build cache도 약 3GB 정도 정리했다.

숫자만 보면 엄청난 개선처럼 보이지 않을 수도 있다. 하지만 이번 작업의 목적은 단순히 몇 GB를 지우는 것이 아니었다. 어떤 데이터가 어디에 있고, 무엇을 기준으로 지워도 되는지 정리하는 것이 더 중요했다.

특히 service disk의 큰 사용량은 일반 백업 파일이 아니라 실행 중인 Docker, container, DB 계층에서 발생하고 있었다. 이 부분은 임의로 삭제하면 안 된다. 더 줄이려면 DB retention, vacuum, container 재배포 같은 별도 운영 작업으로 다뤄야 한다.

남긴 것들도 있다

정리 작업에서 중요한 건 무엇을 지웠는지만큼 무엇을 남겼는지도 기록하는 것이다.

실행 중인 runner 디렉터리, 현재 프로세스가 사용하는 패키지 캐시, 서비스가 사용 중인 런타임 캐시는 삭제하지 않았다. 겉으로 보기에는 큰 용량을 차지하지만, 운영 중인 프로세스와 연결되어 있으면 안전한 삭제 대상이 아니다.

반대로 npm cache, pip cache, 오래된 브라우저 테스트 캐시, Docker build cache처럼 다시 받을 수 있는 데이터는 정리했다. 이런 데이터는 삭제해도 기능 데이터가 사라지는 것은 아니지만, 다음 빌드나 테스트에서 다운로드 시간이 늘 수 있다. 그래서 “삭제 가능”과 “삭제해도 비용이 없는 것”도 구분해서 봐야 했다.

문서화까지 해야 끝난다

마지막으로 운영 문서를 업데이트했다. 백업 경로, 보관 기준, 삭제 기준, 남겨둔 항목과 이유를 기록했다.

개인 프로젝트에서는 문서화를 미루기 쉽다. 혼자 아니까 굳이 적지 않아도 된다고 생각하기 때문이다. 하지만 몇 달 뒤 다시 보면 기억이 흐려진다. 특히 백업과 삭제 정책은 기억에 의존하면 위험하다.

이번에는 “어디에 무엇이 어떤 주기로 생기는지”, “로컬 디스크에서 무엇을 지워도 되는지”, “아직 지우면 안 되는 것은 무엇인지”를 남겼다. 나중에 다른 PC에서 백업물을 찾거나 복원 작업을 해야 할 때, 문서가 첫 번째 진입점이 되도록 하기 위해서다.

배운 점

이번 작업을 하면서 백업은 파일을 어딘가에 복사하는 일이 아니라는 걸 다시 느꼈다.

중요한 건 다음 세 가지였다.

• 그 파일을 어디서 찾을 수 있는가
• 어떤 순서로 복구할 수 있는가
• 원본을 지워도 되는 기준이 무엇인가

취미 프로젝트라도 데이터가 계속 쌓이고 자동화가 늘어나면 결국 운영 문제가 생긴다. 이번 개선은 그 운영 문제를 비용을 크게 늘리지 않고 정리한 과정이었다.

처음에는 서버 이전 문제처럼 보였다. 하지만 실제로는 백업 구조, 복구 가능성, 삭제 기준, 로컬 용량 관리가 얽힌 문제였다. 완전 이전 대신 Mini PC를 보조 복제 지점으로 활용했고, DB와 JSON 산출물을 분리했으며, 백업 marker를 기준으로 cleanup을 수행하도록 정리했다.

결과적으로 얻은 것은 단순한 여유 용량이 아니었다. 이제는 “백업이 있다”가 아니라 “어디에 있고, 어떻게 검증했고, 어떤 조건에서 지워도 되는지”를 설명할 수 있게 되었다. 개인 프로젝트 운영에서 이 차이는 꽤 크다.