앱 데이터베이스 백업하는 방법 (그리고 실제로 복원하는 법)

앱 데이터베이스를 백업하려면, 정해진 일정에 따라 파일로 내보내고(Postgres라면 표준 도구인 pg_dump를 사용), 사본을 데이터베이스와 분리된 곳에 보관한 다음, 정기적으로 빈 데이터베이스에 복원해 보며 백업이 제대로 작동하는지 확인하면 됩니다. 위험한 변경을 하기 직전에는 백업을 한 번 더 해두세요. 코드 백업(GitHub 저장소든 내보내기 파일이든)에는 데이터가 포함되지 않습니다.

이 가이드는 소규모 앱을 운영하면서 데이터를 잃을까 걱정하지 않고 싶은 분들을 위한 것입니다. 대부분의 AI로 만든 앱이 Postgres를 사용하므로 예시도 Postgres 기준이지만, 원칙은 어떤 데이터베이스에도 똑같이 적용됩니다.

백업이 보호해야 할 범위

앱은 데이터베이스 이상의 것입니다. 각 백업이 무엇을 보호하는지 알아두세요.

데이터는 다시 만들 수 없는 부분입니다. 코드는 다시 작성할 수 있고 설정은 다시 입력할 수 있지만, 고객의 주문은 그렇게 할 수 없습니다.

1단계: 잃어도 괜찮은 데이터의 양 정하기

백업 계획은 두 가지 질문으로 정해집니다.

• 최근 데이터를 얼마나 잃어도 괜찮나요? 하루에 한 번 백업하는데 저녁에 데이터베이스에 장애가 나면, 그날 변경분은 잃게 됩니다. 취미로 만든 앱이라면 괜찮지만, 주문을 받는 앱이라면 문제가 될 수 있습니다.
• 복원하는 동안 앱이 얼마나 멈춰 있어도 괜찮나요? 작은 데이터베이스는 몇 분이면 복원되지만, 큰 데이터베이스는 훨씬 오래 걸릴 수 있습니다. 실제로 필요해지기 전에 그 시간을 미리 알아두세요.

대부분의 소규모 앱에는 매일 자동 백업과 위험한 변경 전 수동 백업을 함께 두는 것이 무난한 출발점입니다. 돈이나 건강 데이터가 관련된 앱이라면 백업을 더 자주 하거나, 특정 시점(마지막 백업이 아니라 어느 순간이든)으로 되돌릴 수 있는 시점 복구(point-in-time recovery)를 지원하는 관리형 데이터베이스를 쓰는 것이 좋습니다.

2단계: 호스트가 이미 해주는 것 확인하기

많은 관리형 데이터베이스 제공업체가 자동 백업을 제공합니다. 다음을 확인하세요.

• 내 요금제에 백업이 켜져 있나요? 얼마나 자주 실행되나요?
• 백업은 얼마나 보관되나요?
• 특정 시점으로 복원할 수 있나요, 아니면 일별 스냅샷으로만 복원할 수 있나요?
• 백업 파일을 내려받을 수 있나요, 아니면 제공업체 시스템 안에서만 복원할 수 있나요?

제공업체의 백업도 유용하지만, 데이터베이스와 같은 계정에 묶여 있다는 점에서 단일 장애 지점을 공유합니다. 계정이 해지되거나 정지되거나 프로젝트가 삭제되면 백업도 함께 사라질 수 있습니다. 그래서 별도의 사본을 직접 가지고 있어야 합니다.

3단계: pg_dump로 덤프 만들기

pg_dump는 Postgres 데이터베이스를 파일로 내보냅니다. 일관된 스냅샷을 읽기 때문에 작업 중에도 앱이 계속 실행될 수 있습니다.

앱이 이미 환경 변수에 가지고 있는 연결 문자열을 사용하는 일반적인 명령은 다음과 같습니다.

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

옵션의 역할은 다음과 같습니다.

• --format=custom은 pg_restore로 읽을 수 있는 압축 파일을 만들며, 나중에 개별 테이블만 복원할 수도 있게 해 줍니다. 사람이 읽을 수 있는 .sql 파일을 원하면 --format=plain을 사용하세요.
• --no-owner는 소유자 설정 명령을 빼 줘서, 다른 데이터베이스에 복원할 때 더 간단해집니다.
• 파일 이름의 날짜는 백업들을 구분해 줍니다.

pg_dump 버전은 데이터베이스의 Postgres 버전과 같거나 더 최신이어야 합니다. 오래된 pg_dump는 실행을 거부할 수 있습니다.

명령줄을 직접 다루고 싶지 않다면 AI에게 이렇게 요청할 수 있습니다.

pg_dump를 사용해 앱 데이터베이스의 백업을 커스텀 형식으로 만들어 줘. 파일 이름에는 오늘 날짜를 넣어 줘. 연결 문자열이나 비밀 값은 출력하지 마. 끝나면 파일 이름과 크기를 알려 줘.

4단계: 자동화하기

수동 백업은 잊기 쉽습니다. 사용 중인 환경에서 지원하는 방법으로 자동화하세요.

• 데이터베이스 제공업체의 예약 백업(제공하는 경우)
• 서버나 CI 서비스의 예약 작업: pg_dump를 실행하고 파일을 스토리지에 업로드
• 호스팅 백업 서비스: 데이터베이스에 연결해 백업을 수행

어떤 방법을 고르든, 백업이 실패하면 알림이 오도록 설정하세요. 석 달 동안 조용히 실패하고 있던 백업 작업은 전형적인 공포 이야기입니다.

5단계: 다른 곳에 사본 보관하기

흔히 3-2-1 규칙이라고 부릅니다. 데이터 사본 세 개를, 서로 다른 종류의 저장소 두 곳에, 그중 하나는 외부(오프사이트)에 두라는 원칙입니다. 소규모 앱에서 실용적으로 적용하면 다음과 같습니다.

• 실시간 데이터베이스
• 제공업체의 자동 백업
• 다른 계정에 있는 오브젝트 스토리지 버킷 등 별도 저장소에 보관한 나만의 덤프

그 밖에도 다음을 지키세요.

• 접근을 제한하세요. 백업에는 모든 사용자의 데이터가 들어 있습니다. 실시간 데이터베이스와 똑같이 다루세요.
• 보관 정책을 정하세요. 예를 들어 일일 백업은 2주, 월간 백업은 1년 보관하는 식입니다. 오래된 백업은 의도적으로 삭제하고, 개인정보 보호법에 따라 요청이 오면 개인 데이터를 삭제해야 할 수도 있다는 점을 기억하세요.
• 백업을 Git에 절대 커밋하지 마세요. 저장소에 있는 덤프는 언제든 데이터 유출로 이어질 수 있습니다.

6단계: 복원 테스트하기

백업은 마지막으로 성공한 복원만큼만 믿을 수 있습니다. 최소 몇 달에 한 번, 그리고 백업 절차를 바꾼 뒤에는 반드시 복원을 해 보세요.

1. 새로운 빈 데이터베이스를 만드세요. 테스트를 위해 실시간 데이터베이스 위에 복원하면 안 됩니다.
2. 최신 백업을 그 데이터베이스에 복원하세요.

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

일반 .sql 파일이라면 대신 psql "$TEST_DATABASE_URL" -f backup.sql을 사용하세요.

1. 모든 테이블이 있는지 확인하고, 행 수를 실시간 데이터베이스와 비교하고, 최근 레코드 몇 개를 살펴보세요.
2. 가능하다면 앱 사본을 이 데이터베이스에 연결해 로그인해 보세요.
3. 복원에 걸린 시간을 기록하세요. 그것이 실제 복구 시간입니다.

7단계: 위험한 변경 전에 백업하기

다음 작업 직전에는 새로 백업을 하세요.

• 열을 삭제하거나 이름을 바꾸는 데이터베이스 마이그레이션 실행
• 데이터 대량 가져오기
• AI 에이전트가 데이터 모델을 크게 바꾸도록 하는 작업
• 오래된 레코드 삭제

AI로 만든 앱에서는 에이전트가 기능 구현의 일부로 테이블 구조를 바꿀 수 있습니다. 체크포인트와 버전 관리는 코드를 되돌려 주지만, 삭제된 행을 되살려 주지는 않습니다. 큰 변경 전의 30초짜리 백업은 저렴한 보험입니다.

흔한 실수

• Git이나 코드 내보내기를 백업이라고 생각하기. 그것은 코드일 뿐 데이터가 아닙니다.
• 복원을 한 번도 테스트하지 않기. 많은 백업이 정말 필요한 순간에야 비어 있거나, 일부만 있거나, 읽을 수 없다는 것이 드러납니다.
• 데이터베이스와 같은 계정에 백업 보관하기. 계정 하나가 해킹되거나 해지되면 둘 다 잃습니다.
• 업로드된 파일 잊기. 데이터베이스에는 파일 경로만 저장되고, 이미지 자체는 스토리지에 있습니다.
• 백업 스크립트에 비밀 값 남기기. 연결 문자열은 스크립트 본문이 아니라 환경 변수에서 읽으세요. API 키를 안전하게 보관하는 방법을 참고하세요.

백업과 Mythex

Mythex 프로젝트에는 전용 Postgres 데이터베이스를 둘 수 있으며, 연결 정보는 작업 공간과 게시된 앱에 주입됩니다. Mythex 문서에는 데이터베이스 백업 또는 복원 기능이 설명되어 있지 않으므로, 직접 계획을 세워 두세요. 에이전트에게 덤프를 만들어 달라고 요청한 뒤 내려받아 안전한 곳에 보관하세요. 특히 큰 변경 전에는 꼭 그렇게 하세요. 프로젝트 내보내기(Pro)에는 비밀 값과 node_modules를 제외한 코드가 들어가며, 데이터베이스 행은 포함되지 않습니다. 자세한 내용은 문서의 데이터베이스와 데이터 소유권을 참고하세요. 데이터베이스 자체에 대해 더 알고 싶다면 Postgres란 무엇인가를 읽어 보세요.

백업 체크리스트

• 잃어도 괜찮은 데이터의 양과 멈춰 있어도 되는 시간을 정했다
• 데이터베이스 호스트가 제공하는 자동 백업을 확인했다
• 나만의 덤프가 일정에 따라 실행되며, 실패하면 알림이 온다
• 사본은 데이터베이스와 분리되어 있고, 접근이 제한되어 있다
• 보관 정책을 문서로 적어 두었다
• 데이터베이스와 함께 업로드된 파일도 백업한다
• 빈 데이터베이스에 복원을 테스트했고, 행 수를 확인했다
• 위험한 변경을 할 때마다 그 전에 백업한다

자주 묻는 질문