보안, 백업, 유지보수
AI 지원 데이터베이스 보안 — 접근 제어, SQL 인젝션 방지, 백업 전략, 장기적 데이터베이스 건강 유지.
프리미엄 강좌 콘텐츠
이 레슨은 프리미엄 강좌의 일부예요. Pro로 업그레이드하면 모든 프리미엄 강좌와 콘텐츠를 이용할 수 있어요.
- 모든 프리미엄 강좌 이용
- 1000개 이상의 AI 스킬 템플릿 포함
- 매주 새로운 콘텐츠 추가
🔄 Quick Recall: 이전 레슨에서 리포팅·대시보드 쿼리를 만들었어요 — 뷰, 시간 인텔리전스, 자동 리포트 배포까지. 이번에는 그 모든 데이터를 보안, 백업 전략, 지속적 유지보수로 보호해요.
보안 체크리스트
데이터베이스 보안은 소규모 프로젝트에서도 선택이 아니에요. AI가 포괄적 보안 설정을 생성할 수 있어요:
데이터베이스: PostgreSQL
환경: [개발 / 스테이징 / 프로덕션]
애플리케이션: [DB에 연결하는 것 설명]
사용자: [접근이 필요한 사람과 역할 나열]
보안 강화 체크리스트와 SQL 스크립트를 생성해주세요:
1. 역할 기반 접근 제어(RBAC) — 최소 필요 권한으로 역할 정의
2. 역할 분리: 애플리케이션(읽기/쓰기), 리포팅(읽기 전용), 관리자(전체)
3. 행 수준 보안 정책 (해당 시)
4. 연결 제한 (IP 화이트리스트, SSL 필수)
5. 감사 로깅 설정
6. 비밀번호 정책
역할 기반 접근 제어
절대 애플리케이션이나 사용자에게 기본 슈퍼유저 역할을 주지 마세요. 특정 역할을 만드세요:
-- 리포팅용 읽기 전용 역할
CREATE ROLE reporting_role;
GRANT CONNECT ON DATABASE myapp TO reporting_role;
GRANT USAGE ON SCHEMA public TO reporting_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporting_role;
-- 애플리케이션 역할 (특정 테이블 읽기 + 쓰기)
CREATE ROLE app_role;
GRANT CONNECT ON DATABASE myapp TO app_role;
GRANT USAGE ON SCHEMA public TO app_role;
GRANT SELECT, INSERT, UPDATE ON customers, orders, order_items TO app_role;
-- DELETE 권한 없음 — 애플리케이션은 소프트 삭제 사용
-- 관리자 역할 (스키마 변경, 모든 데이터)
CREATE ROLE admin_role;
GRANT ALL PRIVILEGES ON DATABASE myapp TO admin_role;
✅ Quick Check: 이 예시에서 애플리케이션 역할이 DELETE 권한을 제외하는 이유는? 대부분의 애플리케이션은 행을 실제 삭제하는 대신 소프트 삭제(
deleted_at타임스탬프 설정)를 써야 하기 때문이에요. 하드 삭제는 데이터베이스 수준에서 되돌릴 수 없어요. 앱 역할에서 DELETE 권한을 제거하면, 코드에 버그가 있어도 데이터를 실수로 지울 수 없어요.
SQL 인젝션 방지
좋은 DB 권한이 있어도, SQL 인젝션이 제어를 우회할 수 있어요. AI에게 코드를 검토하게 하세요:
이 코드에서 SQL 인젝션 취약점을 검토해주세요:
[SQL 쿼리를 구성하는 애플리케이션 코드 붙여넣기]
1. 사용자 입력이 SQL 문자열에 연결되는 곳 식별
2. 파라미터화된 쿼리/준비된 문을 사용한 안전한 버전
3. 기타 인젝션 위험 (칼럼명, 테이블명, ORDER BY 절)
규칙은 단순해요: 절대 사용자 입력을 SQL에 연결하지 마세요. 항상 파라미터화된 쿼리를 쓰세요.
# 위험 — SQL 인젝션 위험
cursor.execute(f"SELECT * FROM users WHERE email = '{user_email}'")
# 안전 — 파라미터화된 쿼리
cursor.execute("SELECT * FROM users WHERE email = %s", (user_email,))
백업 전략
AI가 필요에 맞는 백업 계획을 설계해요:
데이터베이스: PostgreSQL (500GB, 프로덕션)
RPO (최대 허용 데이터 손실): [예: 1시간]
RTO (최대 허용 다운타임): [예: 4시간]
예산 제약: [있으면]
백업 전략을 설계해주세요:
1. 백업 유형과 스케줄 (전체, 증분, WAL 아카이빙)
2. 백업 저장 위치 (로컬 + 오프사이트/클라우드)
3. 보존 정책 (백업 보관 기간)
4. 복원 절차 (시나리오별 단계)
5. 백업 검증 (백업이 실제로 작동하는지 확인 방법)
6. 구현할 정확한 명령/cron 작업
핵심 규칙: 테스트하지 않은 백업은 백업이 아니에요. 비프로덕션 서버에서 월간 복원 테스트를 스케줄링하세요.
일반적인 백업 스케줄:
- 지속적: WAL(Write-Ahead Log) 아카이빙으로 시점 복구
- 매일: 트래픽 낮은 시간에 전체 논리적 백업(pg_dump)
- 매주: 전체 물리적 백업을 오프사이트에
- 매월: 백업 무결성 검증을 위한 복원 테스트
지속적 유지보수
데이터베이스는 유지보수 없이 성능이 저하돼요. 자동 건강 점검을 설정하세요:
데이터베이스: PostgreSQL
유지보수 스크립트를 만들어주세요:
1. VACUUM ANALYZE 스케줄 (블로트 방지, 통계 업데이트)
2. 인덱스 건강 점검 (비대 인덱스, 미사용 인덱스)
3. 테이블 블로트 모니터링 (VACUUM FULL이 필요한 테이블 식별)
4. 연결 모니터링 (max_connections에 근접하고 있나?)
5. 디스크 공간 알림 (80% 용량에서 경고)
6. 장시간 실행 쿼리 탐지 (5분 초과 쿼리)
7. 복제 지연 모니터링 (해당 시)
cron 스케줄 포함 유지보수 런북으로 출력.
✅ Quick Check: VACUUM ANALYZE가 PostgreSQL 성능에 왜 중요한가요? PostgreSQL이 삭제·업데이트된 행의 공간을 즉시 회수하지 않기 때문이에요 — “데드 튜플"이 되어 테이블을 부풀리고 스캔을 느리게 해요. VACUUM이 그 공간을 회수하고, ANALYZE가 쿼리 플래너가 실행 전략을 선택하는 데 쓰는 통계를 업데이트해요. 정기적 VACUUM ANALYZE 없이는 테이블이 불필요하게 커지고 플래너가 오래된 통계로 나쁜 결정을 해요.
모니터링과 알림
문제가 놀라움이 되지 않도록 사전 알림을 설정하세요:
PostgreSQL 데이터베이스용 모니터링·알림 설정을 설계해주세요:
알림 기준:
1. X초 이상 실행되는 쿼리
2. 연결 수가 max_connections의 Y%를 초과
3. 디스크 사용량 80% 초과
4. 복제 지연 Z초 초과
5. 지난 24시간 내 백업 미완료
6. 테이블 블로트가 임계값 초과
각 알림에 대해:
- 모니터링 쿼리 또는 명령
- 프로덕션 DB에 권장되는 임계값
- Slack/이메일/PagerDuty 연동 방법
핵심 정리
- 최소 권한 원칙: 모든 역할에 최소 필요 권한만 — 절대 필요 이상 부여 금지
- SQL 인젝션 방지 = 모든 곳에서 파라미터화된 쿼리 — 사용자 입력을 SQL에 절대 연결 금지
- 백업 전략에 논리적(pg_dump)과 물리적 백업 모두 필요 + 정기 복원 테스트
- 테스트하지 않은 백업은 백업이 아니에요 — 월간 복원 검증 스케줄링
- VACUUM ANALYZE가 데드 튜플과 오래된 통계로 인한 성능 저하를 방지
- 사전 모니터링(연결 수, 디스크 사용량, 쿼리 시간)이 장애가 되기 전에 문제를 잡아요
Up next: 마지막 레슨에서 완전한 데이터베이스 프로젝트를 구축해요 — 스키마 설계부터 프로덕션 배포까지 배운 모든 것을 통합.
이해도 체크
먼저 위의 퀴즈를 완료하세요
레슨 완료!