PostgreSQL 리드·아키텍트 기술면접

WAL 아카이빙은 pg_basebackup으로 매일 Full Backup을 수행하고, archive_command로 WAL 세그먼트를 S3 Glacier로 전송하여 비용을 절감합니다. RPO 5분, RTO 1시간을 목표로 WAL은 스트리밍과 아카이빙을 병행하며, 최근 7일은 Hot Storage에, 이후는 Cold Storage로 전환합니다. 복구 테스트는 매주 자동화된 환경에서 랜덤 시점 복구를 수행하고 데이터 무결성을 검증합니다. 백업 보관은 일일 백업 7개, 주간 백업 4개, 월간 백업 12개를 유지하며, 규정 준수를 위해 연간 백업은 별도 보관합니다. 모니터링 시스템으로 WAL 아카이빙 지연, 백업 실패, 스토리지 용량을 추적하고 임계치 초과 시 알림을 발송합니다.

하이브리드 모델을 제안합니다. 중앙 DBA 팀(3-4명)이 표준, 보안, 성능 기준을 수립하고 플랫폼을 관리하며, 각 개발팀은 Terraform과 Ansible로 자동화된 DBaaS 플랫폼을 통해 셀프서비스로 데이터베이스를 프로비저닝합니다. DBA 팀은 코드 리뷰 방식으로 스키마 변경을 검토하고, Liquibase/Flyway로 마이그레이션을 자동화하며, 개발팀에 교육과 컨설팅을 제공합니다. 모니터링은 Prometheus/Grafana로 통합하고, 성능 이슈는 pg_stat_statements 기반 자동 분석 도구로 개발팀이 1차 대응하되, 복잡한 튜닝은 DBA 팀이 지원합니다. 이를 통해 개발 속도와 데이터베이스 안정성을 모두 확보하고, Inner Source 방식으로 베스트 프랙티스를 공유합니다.

각 마이크로서비스에 사이드카 패턴으로 PgBouncer를 배치하여 서비스별 연결 격리와 장애 격리를 구현합니다. 애플리케이션은 HikariCP로 로컬 풀링(pool_size=10)을 하고, PgBouncer는 Transaction Pooling 모드로 실제 DB 연결을 최소화합니다. PostgreSQL max_connections는 500으로 설정하고, 서비스별 쿼터를 부여하여(예: 서비스당 20-30 연결) 특정 서비스의 연결 폭증이 전체 시스템에 영향을 주지 않도록 합니다. PgBouncer의 server_idle_timeout과 server_lifetime으로 유휴 연결을 정리하고, reserve_pool로 긴급 상황 대비 연결을 예약합니다. 모니터링으로 서비스별 연결 사용률, 대기 시간, 연결 거부를 추적하고, Prometheus로 메트릭을 수집하여 오토스케일링 임계치를 동적으로 조정합니다.

먼저 pg_stat_activity로 현재 실행 중인 쿼리의 상태와 wait_event를 확인하여 Lock 대기나 I/O 병목을 파악합니다. pg_stat_statements로 해당 쿼리의 평균 실행 시간, 호출 횟수, 블록 읽기 수를 과거 데이터와 비교하여 성능 저하 시점을 특정합니다. EXPLAIN ANALYZE로 실행 계획을 분석하여 Seq Scan으로의 변경, Nested Loop의 비효율, 또는 예상 row 수와 실제 차이를 확인합니다. 통계 정보가 오래되었다면 ANALYZE를 실행하고, 인덱스가 bloat되었다면 REINDEX를 검토합니다. 동시 실행 쿼리가 많다면 pg_locks로 잠금 경합을 확인하고, 시스템 리소스는 iostat와 vmstat로 디스크 I/O와 메모리를 점검합니다. 최종적으로 쿼리 재작성, 인덱스 추가, 파라미터 튜닝 중 가장 효과적인 해결책을 선택합니다.

Schema per Tenant 방식을 선택합니다. 단일 데이터베이스에서 테넌트별로 스키마를 분리하여 논리적 격리를 제공하며, search_path로 테넌트 컨텍스트를 전환합니다. Database per Tenant는 완벽한 격리를 제공하지만 1000개 테넌트에서 연결 관리와 백업이 복잡하고, RLS는 단일 테이블 구조로 성능 오버헤드가 큽니다. 스키마 방식은 공통 코드(함수, 타입)를 public 스키마에서 공유하고, 테넌트별 데이터만 분리하여 유지보수가 용이합니다. 대규모 확장 시 테넌트를 여러 데이터베이스 인스턴스로 샤딩하되, 라우팅 레이어에서 테넌트 ID 기반으로 연결을 분배합니다. 백업은 테넌트별로 독립 수행하고, 민감 데이터는 pgcrypto로 암호화하며, 감사 로그는 별도 스키마에 기록하여 규정 준수를 보장합니다.

먼저 CloudWatch와 Performance Insights로 CPU, 메모리, IOPS 사용률을 분석하여 과도하게 프로비저닝된 인스턴스를 적정 크기로 축소합니다. Provisioned IOPS를 GP3로 전환하여 IOPS와 처리량을 독립적으로 조정하고, 읽기 워크로드가 많다면 Read Replica로 분산합니다. 백업 보관 기간을 규정 준수 범위 내에서 최소화하고, 스냅샷은 Lifecycle Policy로 오래된 것을 자동 삭제합니다. 데이터 전송은 VPC Endpoint로 인터넷 경유를 줄이고, 대용량 데이터는 S3 Export로 처리합니다. Aurora PostgreSQL은 스토리지 자동 확장과 서버리스 옵션으로 유휴 시간 비용을 절감하지만, 읽기 중심 워크로드가 아니면 RDS 대비 비용 효율이 낮을 수 있어 워크로드 특성을 정밀 분석 후 결정합니다. 최종적으로 Reserved Instance로 1-3년 약정 시 최대 40% 추가 절감이 가능합니다.

상황(Situation): 대규모 스키마 변경 시 개발팀은 2주 내 배포를 원했고, DBA 팀은 최소 4주의 검증 기간을 요구했습니다. 과제(Task): 양측의 요구를 만족시키면서 비즈니스 일정을 맞추고 안정성을 확보해야 했습니다. 행동(Action): 먼저 변경을 3단계로 나누어 점진적 배포 계획을 수립했습니다. 1단계는 영향도가 낮은 테이블부터 시작하고, 스테이징 환경에서 부하 테스트와 롤백 시나리오를 검증했습니다. DBA 팀에게는 자동화된 스키마 마이그레이션 도구(Liquibase)와 모니터링 대시보드를 제공하여 검증 시간을 단축시켰고, 개발팀에게는 각 단계별 배포 일정을 명확히 제시했습니다. 결과(Result): 3주 만에 안전하게 배포를 완료했고, 이후 이 프로세스가 표준이 되어 스키마 변경 리드타임이 50% 단축되었습니다. 양 팀의 신뢰도 향상되어 협업 문화가 개선되었습니다.