Ch1. 환경 분리 전략
dev/staging/prod 분리, 권한 경계, Prisma datasource 설정 표준
핵심 요약
- Prisma 운영 사고는 코드 버그보다 환경 경계 붕괴에서 더 자주 터지므로 환경 분리부터 못 박습니다.
prod는 단독 인스턴스로 두고staging과 DB를 공유하지 않으며, 슈퍼유저 자격증명 재사용을 금지합니다.app_prod(DML)·migrate_prod(DDL, 사용 시간 제한)·readonly_prod(SELECT) 계정을 용도별로 분리합니다.DATABASE_URL(앱 트래픽)과DIRECT_DATABASE_URL(마이그레이션·관리)을 분리해 락·타임아웃 리스크를 줄입니다.prod접속은 개발자 로컬이 아니라 승인된 CI/CD·Bastion(SSO/VPN) 경로로만 허용합니다.
왜 환경 분리가 먼저인가
Prisma 운영 사고는 코드 버그보다 환경 경계 붕괴에서 더 자주 터집니다. 그래서 “어떤 환경에서 누가 어떤 데이터에 접근하는가”부터 못 박아 둬야 합니다.
분리 모델
| 계층 | 권장 모델 | 금지 모델 |
|---|---|---|
| 데이터베이스 인스턴스 | prod는 단독 인스턴스(또는 단독 클러스터) | staging과 prod 공유 |
| 스키마 | 서비스/도메인별 스키마 분리 고려 | 모든 서비스가 단일 public 스키마 공유 |
| 계정/권한 | 환경별 DB 사용자 분리 (app_prod, migrate_prod) | 하나의 슈퍼유저 자격증명 재사용 |
| 비밀정보 | 환경별 Secret Manager 키 분리 | .env 파일 복붙 |
운영 원칙
prod 연결 문자열은 개발자 로컬에 배포하지 않습니다. 운영 변경은 CI/CD 또는 승인된 Bastion
경로로만 수행합니다.
Prisma datasource 권장 패턴
// prisma/schema.prisma
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
directUrl = env("DIRECT_DATABASE_URL")
}DATABASE_URL: 애플리케이션 트래픽용(필요 시 PgBouncer 경유)DIRECT_DATABASE_URL: 마이그레이션/관리 작업용 직접 연결
운영에서는 “앱 연결”과 “DDL 연결”을 분리해야 락·타임아웃 리스크가 줄어듭니다.
권한 분리 예시
| 계정 | 용도 | 권한 |
|---|---|---|
app_prod | 애플리케이션 쿼리 | DML 중심, DDL 금지 |
migrate_prod | Prisma migrate deploy | DDL 허용, 사용 시간 제한 |
readonly_prod | 리포팅/운영 조회 | SELECT 전용 |
환경별 데이터 정책
| 환경 | 데이터 소스 | 개인정보 | 리프레시 주기 |
|---|---|---|---|
dev | 합성 데이터 + 최소 샘플 | 원칙적으로 미포함 | 필요 시 수동 |
staging | prod 마스킹 덤프(선택) | 비식별화 필수 | 주/격주 |
prod | 실제 운영 데이터 | 정책 준수 + 감사 로깅 | 상시 |
체크리스트
- 환경별 DB 인스턴스/클러스터 분리 완료
-
DATABASE_URL,DIRECT_DATABASE_URL가 환경마다 분리됨 - 마이그레이션 전용 계정이 존재하고 만료 정책이 있음
-
staging데이터 마스킹 프로세스가 문서화됨 -
prod접속은 승인된 경로(SSO/VPN/Bastion)로 제한됨