데이터를 안전하게 지키는 백업과 권한

백업은 데이터 안전벨트다

데이터베이스를 쓰다 보면 언젠가는 실수가 납니다. 고객 등급을 잘못 수정할 수도 있고, 엑셀에서 가져온 재고 파일이 엉뚱한 상품에 붙을 수도 있습니다. 주문 내역을 정리하다가 조건을 빠뜨린 UPDATE나 DELETE를 실행할 수도 있습니다.

백업은 이런 순간을 대비하는 안전벨트입니다. 사고가 나지 않게 해 주는 장치는 아니지만, 사고가 났을 때 돌아갈 지점을 만들어 줍니다. 종이 장부로 비유하면 중요한 수정 전에 장부를 복사해 두는 일입니다. 복사본이 있으면 잘못 고친 뒤에도 이전 내용을 확인할 수 있습니다.

PostgreSQL 공식 문서에서도 데이터베이스는 정기적으로 백업해야 하며, 백업 방법마다 장단점이 있다고 설명합니다.¹ 초보자가 처음 기억할 핵심은 하나입니다. 중요한 데이터를 바꾸기 전에는 반드시 되돌아갈 파일을 남긴다.

AI 생성 이미지

백업이 필요한 세 가지 순간

백업은 가끔 생각날 때 하는 일이 아닙니다. 업무 기준으로 시점을 정해 두어야 합니다.

1. 정기 백업

정기 백업은 매일, 매주, 매월처럼 일정한 주기로 남기는 백업입니다. 매일 주문이 들어오는 쇼핑몰이라면 하루 한 번은 백업이 필요할 수 있습니다. 월별 보고서만 관리하는 작은 데이터베이스라면 주 1회 또는 월 마감 직후 백업으로 충분할 수도 있습니다.

정기 백업의 목적은 평소의 안전망입니다. 누가 실수했는지 모를 때, 파일이 손상되었을 때, 서버를 옮겨야 할 때 기준점이 됩니다.

백업 파일 이름은 알아보기 쉽게 정합니다.

sales_db_2026-06-26.backup
sales_db_before_inventory_update_2026-06-26.backup
sales_db_before_table_change_2026-06-26.backup

파일 이름에 데이터베이스 이름, 목적, 날짜가 들어가면 나중에 찾기 쉽습니다. final, new, real_final 같은 이름은 피하는 것이 좋습니다.

2. 대량 수정 전 백업

여러 행을 한 번에 바꾸는 작업 전에는 별도 백업이 필요합니다. 예를 들어 다음과 같은 작업입니다.

• 전체 상품 가격을 5% 인상한다.

• 특정 기간 주문의 상태를 결제완료로 바꾼다.

• CSV로 받은 재고 수량을 운영 테이블에 반영한다.

• 오래된 고객 등급을 새 기준에 맞춰 일괄 수정한다.

이런 작업은 한두 줄을 고치는 일이 아닙니다. 조건 하나가 잘못되면 수백 행, 수천 행이 바뀔 수 있습니다.

순서는 항상 같습니다.

1. 백업한다.

2. 같은 조건으로 SELECT 미리보기를 한다.

3. BEGIN으로 트랜잭션을 시작한다.

4. UPDATE, DELETE, INSERT를 실행한다.

5. 결과를 확인한다.

6. 맞으면 COMMIT, 틀리면 ROLLBACK한다.

7장에서 배운 안전 순서가 여기서 다시 등장합니다. 백업은 그 순서의 가장 앞에 놓는 안전장치입니다.

3. 구조 변경 전 백업

테이블 구조를 바꾸기 전에도 백업이 필요합니다. 구조 변경은 엑셀 파일에서 열 이름을 바꾸거나 열 자체를 삭제하는 것과 비슷합니다. 다만 데이터베이스에서는 그 영향이 더 큽니다.

예를 들어 다음 작업은 구조 변경입니다.

• 고객 테이블에 새 컬럼을 추가한다.

• 상품 가격 컬럼의 데이터 타입을 바꾼다.

• 더 이상 쓰지 않는 컬럼을 삭제한다.

• 테이블 이름을 바꾼다.

• 제약 조건이나 외래키를 추가한다.

구조 변경은 조회문, 뷰, 보고서, 가져오기 작업에 영향을 줄 수 있습니다. 따라서 변경 전에는 운영 데이터베이스 백업을 남기고, 가능하면 테스트 데이터베이스에서 먼저 실행해 봐야 합니다.

GUI 백업과 pg_dump의 차이

비개발자는 pgAdmin이나 DBeaver 같은 화면 도구의 백업 기능으로 시작하는 것이 좋습니다. 메뉴를 클릭하고 파일 위치를 지정하면 되므로 실수 가능성이 적습니다.

반면 pg_dump는 PostgreSQL에서 제공하는 백업 명령어입니다. 명령어를 직접 입력해야 하지만, 반복 작업이나 예약 백업을 만들 때 유용합니다. pg_dump는 데이터베이스의 구조와 데이터를 파일로 내보내는 논리 백업 도구이며, 일반 SQL 파일이나 pg_restore에서 사용하는 아카이브 형식으로 저장할 수 있습니다.²

쉽게 말하면 이렇습니다.

• GUI 백업: 화면에서 버튼으로 백업한다. 초보자에게 편하다.

• pg_dump: 명령어로 백업한다. 자동화와 반복 작업에 좋다.

• plain SQL 형식: SQL 문장이 적힌 텍스트 파일처럼 저장된다.

• custom 형식: pg_restore로 복원하기 좋은 압축 백업 파일처럼 저장된다.

작은 실습용 데이터베이스라면 GUI 백업부터 익히면 충분합니다. 다만 업무에서 정기 백업을 운영한다면 담당자나 개발자와 함께 pg_dump 기반 자동 백업도 검토해야 합니다.

작은 데이터베이스를 백업하는 흐름

pgAdmin 기준으로 생각해 보겠습니다. 화면 구성은 버전에 따라 조금 다를 수 있지만 흐름은 비슷합니다.

1. 왼쪽 목록에서 백업할 데이터베이스를 확인한다.

2. 데이터베이스 이름을 우클릭한다.

3. Backup 또는 Backup... 메뉴를 선택한다.

4. 파일 이름과 저장 위치를 정한다.

5. 형식은 보통 Custom을 선택한다.

6. 실행 후 완료 메시지를 확인한다.

7. 백업 파일 크기가 0KB가 아닌지 확인한다.

여기서 가장 중요한 것은 어느 데이터베이스를 백업하는지 확인하는 것입니다. test_db를 백업해야 하는데 sales_db를 백업하거나, 반대로 운영 데이터베이스와 테스트 데이터베이스를 헷갈리면 이후 복원 때도 문제가 생깁니다.

명령어로 같은 일을 한다면 다음처럼 볼 수 있습니다.

sales_db 데이터베이스를 custom 형식 백업 파일로 저장하려는 문장입니다.

pg_dump -h localhost -p 5432 -U admin -F c -f sales_db_2026-06-26.backup sales_db

각 부분의 뜻은 다음과 같습니다.

• -h localhost: 접속할 서버 주소입니다.

• -p 5432: PostgreSQL 기본 포트입니다.

• -U admin: 백업을 실행할 사용자입니다.

• -F c: custom 형식으로 저장합니다.

• -f sales_db_2026-06-26.backup: 저장할 파일 이름입니다.

• sales_db: 백업할 데이터베이스 이름입니다.

실행하면 비밀번호를 묻고, 문제가 없으면 지정한 위치에 백업 파일이 생깁니다. 명령어가 조용히 끝났다고 해서 실패라고 단정하지 마세요. 파일이 생성되었는지, 파일 크기가 적절한지 확인해야 합니다.

복원은 파일을 여는 일이 아니다

백업 파일을 엑셀 파일처럼 더블클릭해서 열면 데이터가 돌아오는 것이 아닙니다. 복원은 백업 파일 안의 내용을 읽어서 데이터베이스의 상태를 다시 만드는 작업입니다.

pg_restore는 pg_dump가 만든 아카이브 백업을 데이터베이스에 복원하는 도구입니다. 복원 과정에서는 테이블을 만들고, 데이터를 넣고, 제약 조건을 다시 세우는 명령들이 실행될 수 있습니다.³ 그래서 복원은 단순한 파일 열기가 아니라 데이터베이스 작업입니다.

초보자가 가장 먼저 익혀야 할 복원 원칙은 이것입니다.

운영 데이터베이스에 바로 복원하지 말고, 테스트 데이터베이스에 먼저 복원한다.

예를 들어 sales_db의 백업 파일을 확인하고 싶다면 sales_db_restore_test 같은 빈 테스트 데이터베이스를 만든 뒤 거기에 복원합니다.

백업 파일을 테스트 데이터베이스에 복원하려는 문장입니다.

pg_restore -h localhost -p 5432 -U admin -d sales_db_restore_test -v sales_db_2026-06-26.backup

결과 해석은 이렇게 합니다.

• 오류 없이 끝나면 백업 파일이 기본적으로 복원 가능한 상태입니다.

• 오류가 나오면 파일 형식, 대상 데이터베이스, 권한, 이미 존재하는 테이블 등을 확인해야 합니다.

• 복원 후에는 테이블 목록과 주요 행 수를 확인해야 합니다.

복원 후에는 다음 SQL로 간단히 확인할 수 있습니다.

복원된 고객 수와 주문 수를 확인하려는 문장입니다.

SELECT COUNT(*) AS customer_count
FROM customers;

SELECT COUNT(*) AS order_count
FROM orders;

결과가 백업 당시 예상한 수와 비슷해야 합니다. 단순히 복원이 끝났다는 메시지만 믿지 말고, 중요한 테이블 몇 개는 직접 조회해 보세요.

테스트 복원이 진짜 백업을 완성한다

백업 파일이 있다고 해서 안심하면 안 됩니다. 복원해 본 적 없는 백업은 아직 검증되지 않은 백업입니다.

테스트 복원에서는 다음을 확인합니다.

• 파일이 실제로 복원되는가?

• 고객, 주문, 상품 같은 핵심 테이블이 있는가?

• 주요 테이블의 행 수가 맞는가?

• 자주 쓰는 보고서 조회문이 실행되는가?

• 뷰가 정상적으로 조회되는가?

• 필요한 사용자가 접속할 수 있는가?

특히 권한은 놓치기 쉽습니다. pg_dump는 개별 데이터베이스의 구조와 데이터를 백업하는 데 적합하지만, 역할과 사용자 같은 전체 서버 단위의 정보는 별도 관리가 필요할 수 있습니다. PostgreSQL의 pg_dumpall은 여러 데이터베이스와 함께 역할, 테이블스페이스 같은 전역 객체를 백업할 수 있으며, 일반 pg_dump는 이런 전역 객체를 저장하지 않는다고 설명합니다.⁴

쉽게 말해 데이터 장부만 백업해도 장부 내용은 복원할 수 있습니다. 하지만 누가 그 장부를 볼 수 있는지, 누가 고칠 수 있는지까지 완전히 되살리려면 사용자와 권한 정보도 확인해야 합니다.

권한은 출입증을 나누어 주는 일이다

데이터베이스 권한은 사무실 출입증과 비슷합니다. 모든 직원에게 금고 열쇠를 줄 필요는 없습니다. 보고서만 보는 사람에게는 읽기 권한만 주고, 재고 담당자에게는 재고 수정 권한을 주고, 관리자에게만 구조 변경 권한을 줍니다.

PostgreSQL에서는 역할과 권한으로 접근을 관리합니다. 객체에는 소유자가 있고, 다른 역할이 그 객체를 사용하려면 GRANT로 권한을 받아야 합니다. 반대로 권한을 회수할 때는 REVOKE를 사용합니다.⁵

주요 권한은 다음처럼 이해하면 됩니다.

비개발자는 처음부터 모든 권한을 외울 필요가 없습니다. 우선 SELECT, INSERT, UPDATE, DELETE의 차이만 정확히 구분하면 됩니다.

읽기 전용, 수정 가능, 관리자 권한 나누기

PostgreSQL의 역할은 사용자일 수도 있고, 사용자들을 묶는 그룹일 수도 있습니다.⁶ 실무에서는 사람마다 직접 권한을 흩뿌리기보다 역할을 기준으로 나누는 편이 관리하기 쉽습니다.

읽기 전용 사용자

읽기 전용 사용자는 데이터를 볼 수만 있고 바꿀 수 없습니다. 경영진 보고서, 매출 분석, 고객 목록 확인 담당자에게 적합합니다.

보고서 담당자에게 고객과 주문 테이블을 읽을 권한만 주려는 문장입니다.

GRANT CONNECT ON DATABASE sales_db TO report_user;
GRANT USAGE ON SCHEMA public TO report_user;
GRANT SELECT ON TABLE customers, orders TO report_user;

결과 해석은 이렇습니다.

• report_user는 sales_db에 접속할 수 있습니다.

• public 스키마 안의 객체를 사용할 수 있습니다.

• customers, orders 테이블을 조회할 수 있습니다.

• 하지만 고객을 추가하거나 주문 상태를 수정하거나 삭제할 수는 없습니다.

수정 가능한 사용자

수정 가능한 사용자는 업무에 따라 데이터를 추가하거나 고칠 수 있습니다. 예를 들어 재고 담당자는 상품 재고 수량을 수정할 수 있어야 합니다. 하지만 주문 삭제 권한까지 줄 필요는 없습니다.

재고 담당자에게 상품 테이블 조회, 추가, 수정 권한을 주려는 문장입니다.

GRANT SELECT, INSERT, UPDATE ON TABLE products TO inventory_user;

이 권한은 products 테이블을 보고, 새 상품을 추가하고, 기존 상품 정보를 수정할 수 있게 합니다. 그러나 DELETE를 주지 않았으므로 상품 행을 삭제할 수는 없습니다.

삭제 권한은 특히 조심해야 합니다. 실무에서는 삭제 대신 is_active, status 같은 상태 컬럼으로 사용 여부를 표시하는 방식이 더 안전할 때가 많습니다.

관리자 권한

관리자는 테이블을 만들고, 구조를 바꾸고, 권한을 관리하고, 백업과 복원을 수행할 수 있는 사람입니다. 관리자 권한은 편리하지만 위험합니다.

관리자 계정은 일상 업무용 계정과 분리하는 것이 좋습니다. 매일 보고서를 보는 계정이 동시에 모든 테이블을 삭제할 수 있는 계정이라면 실수의 피해가 커집니다.

좋은 운영 방식은 다음과 같습니다.

• 평소 조회는 읽기 전용 계정으로 한다.

• 데이터 입력 담당자는 필요한 테이블만 수정한다.

• 구조 변경과 권한 변경은 관리자 계정으로만 한다.

• 관리자 계정은 꼭 필요할 때만 사용한다.

• 여러 사람이 하나의 관리자 계정을 공유하지 않는다.

최소 권한 원칙

권한 관리의 핵심은 최소 권한 원칙입니다. 필요한 만큼만 주고, 필요 없어지면 회수합니다.

예를 들어 보겠습니다.

• 영업팀은 고객 연락처와 주문 이력을 조회해야 한다. → SELECT

• 물류팀은 배송 상태를 수정해야 한다. → 배송 관련 테이블의 SELECT, UPDATE

• 상품팀은 상품을 추가하고 가격을 수정해야 한다. → 상품 테이블의 SELECT, INSERT, UPDATE

• 외부 분석가는 매출 요약만 보면 된다. → 원본 테이블이 아니라 뷰에 대한 SELECT

• 퇴사자나 프로젝트 종료 계정은 접속 권한을 회수한다. → REVOKE 또는 계정 비활성화

잘못 준 삭제 권한을 회수하려는 문장입니다.

REVOKE DELETE ON TABLE orders FROM order_staff;

이 문장은 order_staff가 orders 테이블에서 행을 삭제할 수 없도록 만듭니다. 조회나 수정 권한이 따로 부여되어 있다면 그 권한은 그대로 남을 수 있습니다.

권한은 많이 줄수록 편해 보이지만, 사고가 났을 때 원인을 찾기 어렵습니다. 반대로 역할별로 권한을 좁게 나누면 처음에는 조금 번거로워도 장기적으로 안전합니다.

백업과 권한을 함께 점검하는 습관

백업과 권한은 따로 떨어진 주제가 아닙니다. 백업은 데이터를 되돌릴 수 있게 해 주고, 권한은 사고가 날 가능성을 줄여 줍니다.

대량 수정 전에는 다음 순서로 점검하세요.

1. 오늘 작업할 데이터베이스 이름을 확인한다.

2. 백업 파일을 만든다.

3. 백업 파일 이름과 위치를 기록한다.

4. 같은 조건으로 SELECT 미리보기를 한다.

5. 트랜잭션 안에서 변경한다.

6. 결과를 확인한다.

7. 필요하면 테스트 데이터베이스에 복원해 본다.

8. 작업자에게 필요한 권한만 있었는지 확인한다.

권한 점검은 다음 질문으로 시작하면 됩니다.

• 이 사람은 데이터를 보기만 하면 되는가?

• 새 데이터를 추가해야 하는가?

• 기존 데이터를 수정해야 하는가?

• 삭제까지 해야 하는가?

• 테이블 구조를 바꿔야 하는가?

• 이 권한이 언제까지 필요한가?

모든 사람에게 관리자 권한을 주는 것은 모든 직원에게 회사 금고 열쇠를 나눠 주는 것과 같습니다. 편해 보이지만 안전하지 않습니다.

이번 장의 핵심 정리

백업은 데이터베이스의 보험입니다. 정기 백업, 대량 수정 전 백업, 구조 변경 전 백업을 구분해 습관으로 만들어야 합니다.

pgAdmin이나 DBeaver의 GUI 백업은 초보자가 시작하기 쉽고, pg_dump는 명령어 기반 백업과 자동화에 유용합니다. 복원은 파일을 여는 일이 아니라 데이터베이스 상태를 다시 만드는 작업이므로, 운영 데이터베이스가 아니라 테스트 데이터베이스에서 먼저 확인해야 합니다.

권한은 출입증입니다. 읽기 전용 사용자, 수정 가능한 사용자, 관리자 권한을 나누고, 필요한 권한만 주는 최소 권한 원칙을 지켜야 합니다.

데이터를 잘 다루는 사람은 SQL을 많이 아는 사람만이 아닙니다. 실수했을 때 되돌아갈 길을 만들고, 실수의 범위를 작게 만드는 사람입니다.

참고

¹PostgreSQL Backup and Restore

²PostgreSQL pg_dump

³PostgreSQL pg_restore

⁴PostgreSQL pg_dumpall

⁵PostgreSQL Privileges

⁶PostgreSQL Database Roles