로컬 개발 DB를 운영과 얼마나 같게 맞출 것인가

맞춰야 하는 것

로컬과 운영의 차이 때문에 생기는 문제는 대개 예측 가능한 지점에서 나온다.

1. DB 엔진과 메이저 버전

가장 중요하다. 엔진이 다르면 SQL 방언, 타입 처리, 함수가 다르다.

```sql

-- SQLite에서는 통과, PostgreSQL에서는 실패하는 예

SELECT * FROM t WHERE created_at > '2026-08-01' -- 타입 처리 차이

```

컨테이너로 운영과 같은 이미지를 쓰는 것이 가장 확실하다.

2. 문자셋과 정렬 규칙(collation)

정렬 순서와 대소문자 구분이 달라진다. 한글·이모지 처리에서 차이가 드러난다.

3. 타임존 설정

로컬이 KST, 운영이 UTC면 날짜 경계 계산이 달라진다. 이런 버그는 특정 시간대에만 재현되어 찾기 어렵다.

달라도 되는 것

• 데이터 규모 (성능 테스트는 별도 환경에서)
• 복제 구성, 백업 설정
• 연결 풀 크기
• 하드웨어 사양

이런 것까지 맞추려면 비용이 크고, 대부분의 개발 작업에서는 필요 없다.

시드 데이터

시드가 '정상 케이스만'이면 문제가 늦게 발견된다. 포함해야 할 것:

| 유형 | 예 |

|---|---|

| 빈 상태 | 관계 데이터가 0건인 사용자 |

| 대량 | 목록이 1000건 넘는 계정 |

| 특수문자 | 이름에 따옴표·이모지·긴 문자열 |

| 경계 날짜 | 월말, 연말, 윤년 |

| NULL | nullable 컬럼이 실제 NULL인 행 |

| 상태 조합 | 각 상태 코드마다 최소 1건 |

이런 데이터가 있으면 UI 깨짐이나 쿼리 오류가 개발 중에 드러난다.

운영 데이터 복사

가장 현실적인 시드는 운영 데이터지만, 그대로 가져오면 안 된다.

• 개인정보(이름·이메일·전화·주소) 마스킹
• 결제 정보 제거
• 규모 축소 (전체가 아니라 표본)

마스킹 스크립트를 만들어두고 정기적으로 갱신하는 방식이 흔하다. 다만 마스킹이 불완전할 위험이 항상 있으므로, 조직 정책을 먼저 확인해야 한다.

합성 데이터로 대체하는 방법도 있다. 초기 구축 비용은 크지만 유출 위험이 없고, 위의 경계 케이스를 의도적으로 넣을 수 있다.

초기화 절차

새로 합류한 사람이 몇 분 안에 실행 가능해야 한다.

```bash

docker compose up -d db # 운영과 같은 엔진·버전

npm run db:migrate # 스키마 적용

npm run db:seed # 시드 투입

```

이 세 줄이 문서에 있고 실제로 동작하면 온보딩 비용이 크게 준다. 자주 깨지는 지점이므로 신규 입사 때마다 확인하는 것이 좋다.

리셋 가능성

로컬 DB는 언제든 버리고 다시 만들 수 있어야 한다.

```bash

npm run db:reset # drop → migrate → seed

```

이 명령이 있으면 이상한 상태에 빠졌을 때 디버깅 대신 초기화로 넘어갈 수 있다. 반대로 로컬 DB에 수작업으로 만든 소중한 데이터가 쌓여 있으면, 그 자체가 재현 불가능한 환경이 된다.

최종 수정 2026-08-28