DB 마이그레이션 + 데이터 처리 룰

Pre-launch 단계의 판단 룰. 실사용자 생긴 후엔 일부 룰 재검토 필요 (하단 표시).

1. 리셋 시 마이그레이션 통합

Dev / Prod DB 전부 DROP + 재생성 상황이면 기존 000~NNN 마이그레이션 파일을 단일 baseline 으로 통합.

Why: 히스토리는 기존 환경의 점진적 진화 추적할 때만 가치. 처음부터 다시 만드는 상황엔 불필요.

예외: 운영 중인 환경에선 절대 기존 마이그레이션 편집 / 통합 X — 항상 새 파일 추가.

사례: 2026-04-22 — 7 개 마이그레이션을 00001_baseline.sql 로 통합.

2. 필터는 insert 시점에 (WHERE 매번 X)

저장 가치 있는 데이터만 DB 에 넣음. "일단 다 저장 + 조회 시 WHERE 로 필터" 패턴은 쿼리 누락 리스크 + 무의미한 데이터 혼입 의 이중 비용.

예: 종목 마스터 KOSPI/KOSDAQ 만 취급한다면 company.json 에서 corp_cls ∈ {Y, K} 만 INSERT. "나중에 코넥스 필요할 수도" YAGNI 방어는 재동기화 4 분이면 끝나니 불필요.

적용: 도메인 취급 범위 명확하면 저장 시점에 거름. 범위 확장 필요 시 재동기화가 보통 단순.

3. Pre-launch 엔 Down 마이그레이션 생략

goose 의 -- +goose Down 섹션은 pre-launch 에서 안 씀. goose.UpContext 만 호출하므로 Up 만.

적용 시점 변경: 실 사용자 생긴 후 데이터 복구 시나리오 발생 시 그때 Down 추가.

4. 스케줄러 on/off 는 env 플래그

매일 동작 스케줄러 / 외부 API 주기 호출은 환경별 동작 다르므로 코드 분기 X. 환경변수 *_ENABLED 패턴.

// config.go
StockSyncSchedulerEnabled: envBool("STOCK_SYNC_SCHEDULER_ENABLED", true),
DisclosureMonitorAutoStart: envBool("DISCLOSURE_MONITOR_AUTO_START", true),
ANALYSIS_SCHEDULER_AUTO_START: envBool("ANALYSIS_SCHEDULER_AUTO_START", false),

dev .env.local 에서 false, prod 미설정 (default true).

적용: 크론 / 스케줄러 / 외부 API 주기 호출은 항상 env 플래그.