동일 서버 안에 별도 경로 · 별도 DB 스키마로 격리된 개발 환경을 만든다.
운영 데이터 · 트래픽 · 메일 · 스케줄러에 무영향(회귀 0)을 최우선으로.
현재 Creatiview Suite는 운영본 하나만 존재한다. 안전하게 실험·검증할 별도 공간이 없다.
운영과 같은 서버 안에 코드·데이터·부작용이 완전히 분리된 개발 공간을 확보한다.
이 머신이 곧 라이브 운영 웹서버다. 운영 데이터·트래픽에 어떤 영향도 주지 않는다.
형제 경로에 코드를 복제하고, 로컬 MySQL에 별도 스키마를 둔다. 신규 서버 비용 0.
격리는 경로 분리가 아니라 데이터 계층 분리 + 부작용 차단(메일·스케줄러)이 핵심이다. 경로 분리는 기본 전제다.
셋업 방향은 추정이 아니라 서버 실측값을 근거로 정했다. 운영은 앱서버·DB서버가 물리 분리돼 있다.
MySQL 8 전용 콜레이션이라 MariaDB로는 덤프 import가 실패한다. → dev 엔진도 MySQL 8이어야 함.
메일은 실제 Gmail SMTP로 발송된다. DB나 설정을 공유하면 그대로 운영 사고로 이어진다.
경로만 복사하고 .env를 그대로 두면 dev가 운영 DB에 직접 쓴다. 격리가 깨진다.
판단 기준은 dev 장애가 dev에만 머무는지가 아니라 dev가 운영을 해칠 수 있는지이다. 따라서 격리는 경로가 아니라 데이터 계층에서 이뤄진다.
두 후보의 격리 안전성은 동일하다(둘 다 별도 스키마). 차이는 초기 데이터 유무뿐.
| 옵션 1 · 빈 스키마 | 옵션 2 · 전체 덤프 ✅ | |
|---|---|---|
| 운영 격리 | 동일 | 동일 |
| 데이터 | 없음 | 운영과 동일 형태 |
| 로직 검증 | 불가 | 가능 |
| 부담 | 최소 | 62MB — 사실상 0 |
이 솔루션의 가치는 ReportStore 정합 불변식 · 비용보정 money-math · AI 그라운딩처럼 실제 형태의 집계 데이터가 있어야만 검증되는 로직이다. 빈 스키마면 앱은 뜨지만 검증 대상이 없다.
전량 rpt_* 집계 팩트라 PII 리스크도 낮다.
운영성 테이블(sessions·cache·jobs·tokens) truncate + 계정 메일 마스킹. dev 워커가 운영 잔재 job을 실행하는 사고를 원천 차단한다.
"별도 스키마"는 이름공간만 나눈다. 같은 인스턴스(운영 DB서버 1.201.175.67)면 장애·자원 도메인은 공유된다.
| InnoDB 버퍼풀 | 운영 hot page 축출 |
| max_connections | 운영이 굶음 |
| CPU · IO · 디스크 | 폭주 시 운영 DB 중단 |
앱서버 로컬 MariaDB(11.4.4)는 2025-02 테스트 방치본(빈 test·커넥션 0). 제거하고 그 자리에 MySQL 8.0을 설치.
결정적 근거: 운영 콜레이션 utf8mb4_0900_ai_ci는 MySQL 8 전용 → MariaDB는 import 실패. 정렬·money-math 경계 동작도 어긋난다.
로컬에 두면 운영 앱서버(1.201.174.47)와 같은 머신을 공유하므로 웹 티어 경합이 남는다. 완화: dev innodb_buffer_pool_size 512MB 캐핑 + systemd MemoryMax·CPUQuota 상한. 신규 서버 비용은 0.
증분을 배제한 이유: 룩백 수집으로 지난 날짜의 rpt_fact_* 행이 나중에 값이 바뀐다(restatement). 날짜 이후만 추가하는 방식은 이 정정을 놓쳐 dev를 운영과 어긋나게 만든다. 62MB 전량 집계라 전체 교체가 증분보다 싸고 정확하다.
refresh-dev-db.sh는 처음부터 범위 파라미터 구조(FULL / --since=YYYY-MM)로 만든다. ①→③ 전환 시 스크립트 재작성 없이 인자만 바꾼다.
포트 방식(artisan serve)은 SSO·쿠키 도메인 테스트에 제약이 있다. 따라서 운영과 동일한 HTTPS·쿠키 흐름을 재현하는 별도 서브도메인 vhost로 노출한다.
dev는 crontab을 등록하지 않는다. 룩백 수집이 운영 데이터·외부 API·메일을 건드리지 않게 하기 위함. 필요하면 개별 커맨드만 수동 실행.
실제 발송 없이 로그로만.
키 충돌 방지.
dev 전용 새 APP_KEY.
운영은 앱서버와 DB서버가 물리 분리돼 있다. dev는 앱서버(.47) 로컬에 두고, 그 서버의 기존 MariaDB(방치본)를 제거한 뒤 MySQL 8.0을 새로 설치해 dev DB로 쓴다. 운영 DB서버(.67)는 건드리지 않는다.
스크립트로 구성해 단계별로 확인하며 진행한다. 스크럽(Task 3) 완료 전에는 dev에서 워커·메일을 실행하지 않는다.
형제 경로로 clone, composer install, 권한 정리.
MariaDB 제거 → MySQL 8.0.45 설치, 스키마 생성, 운영 덤프 import.
운영성 테이블 truncate, 메일 마스킹.
local·dev DB·log 메일. 새 APP_KEY.
docroot·TLS 발급, SSO 쿠키 정책.
스케줄러 미등록 확인, refresh 스크립트.
자동 테스트 프레임워크가 없으므로 php -l · php artisan about · tinker 덤프 · curl 200으로 각 단계를 확인한다.
운영 스키마·파일 무변경. dev DB는 운영 DB서버(.20)가 아닌 로컬이라, dev 폭주가 운영 DB에 도달하지 않는다.
--all-databases 1회 백업 후 제거. 필요 시 벤더 repo 재설치로 원복. PHP는 mysqlnd라 운영 .20 접속 무영향.
Task 3 완료 전에는 dev에서 queue:work·스케줄러·메일 커맨드를 절대 실행하지 않는다.
반드시 .env.example 기반 신규 작성. 실 크리덴셜·SMTP·prod URL 이월을 막는다.
dev 구축 실패 시 롤백은 dev 트리 삭제 + 로컬 MySQL/스키마 제거로 완결된다. 운영 영향 0.
이 문서는 승인 전 검토용이다. 위 항목을 확정하면 Task 1부터 스크립트 단위로 실행한다.
본문에 나온 기술 용어를 한 줄로 설명한다. 비개발자도 흐름을 따라갈 수 있게.