[Database] 실무 체크리스트 & 마이그레이션 (MongoDB ↔ MariaDB) - 5

1. 설계 시작 전 체크리스트

1-1. 도메인 특성 체크

• 이 데이터는 돈/재고/포인트 등 정합성이 중요한가?
• 법적/회계적 규제와 직접 연결되는 데이터인가?
• 실수/버그 발생 시 되돌리기 어려운가?

→ “예”가 많다면 RDB(예: MariaDB)를 우선 검토

• 구조가 자주 바뀔 수 있는가?
• 초반에 다양한 실험을 진행해야 하는 도메인인가?
• 로그/이벤트/클릭/센서 데이터처럼 양이 폭발적으로 증가하는 유형인가?

→ “예”가 많다면 MongoDB/NoSQL을 우선 검토

1-2. 접근 패턴 체크

• 화면/기능 단위로 문서 하나를 읽고 쓰면 충분한가?
• 복잡한 조인과 다차원 집계보다, 단일 도큐먼트 조회가 많은가?
• JSON 응답과 DB 구조가 거의 그대로 1:1 매핑되는가?

→ “예”가 많다면 MongoDB에 잘 맞을 가능성이 크다.

• “기준일자별/카테고리별/지역별” 집계가 많고,
• 다양한 조건으로 SQL을 날려 보고 싶은 요구가 많은가?
• BI/리포트/분석 도구들과 연계가 중요한가?

→ “예”가 많다면 RDB 쪽이 자연스럽다.

---

2. 마이그레이션 방향별 메모

2-1. MariaDB → MongoDB 로 옮기고 싶을 때

주로 이런 경우

• 초기에는 RDB로 시작했지만,
  로그/이벤트 데이터가 쌓이면서 한계가 느껴지는 경우
• 스키마 변경이 잦아서 매번 ALTER TABLE 하는 것이 부담되는 경우
• 문서/콘텐츠 등 JSON 구조가 더 자연스러운 데이터가 많아지는 경우

체크 포인트

1. 어떤 테이블/도메인만 옮길지 범위 정의

   • 전체 DB를 한 번에 MongoDB로 옮기지 말고,
   • 로그/이벤트/부가 정보부터 분리하는 방식이 일반적이다.

2. 도큐먼트 구조 설계

   • 기존 테이블 구조를 그대로 도큐먼트로 옮겨오는 대신,
   • “어떤 화면/기능에서 어떤 정보를 한 번에 보느냐” 기준으로 설계
   • 필요하다면 일부 정규화를 풀고 중첩 구조로 재설계

3. 이중 쓰기(dual write) 기간 고려

   • 일정 기간 동안 RDB와 MongoDB에 동시에 기록해서,
   • 데이터 일관성을 검증하는 전략도 많이 사용

4. 쿼리/리포트 방식 변경

   • 기존 SQL 기반 리포트는 그대로 RDB에 남겨두고,
   • 신규 분석/실험용 쿼리는 MongoDB에서 수행하는 식으로 역할 분리

2-2. MongoDB → MariaDB 로 옮기고 싶을 때

주로 이런 경우

• 초기에는 MongoDB로 빠르게 시작했지만,
• 사업이 커지면서 회계/정산/재고 등 안정된 구조가 필요해질 때
• 정합성·감사·외부 연동 요구가 늘어날 때

체크 포인트

1. 정규화 설계

   • 현재 MongoDB 도큐먼트를 기준으로 엔티티(테이블)를 다시 정의
   • 중첩 배열/문서에서 어디까지를 분리된 테이블로 빼야 할지 결정

2. 키 설계 (PK/FK)

   • 기존 _id(ObjectId)를 어떻게 RDB의 PK로 옮길지 결정
   • 필요시 새로운 숫자형 PK를 만들고, MongoDB _id를 별도 컬럼에 보관

3. 데이터 정제 및 마이그레이션 스크립트

   • MongoDB에 들어 있는 불완전/불규칙 필드를 정리
   • 예외 케이스를 처리하는 마이그레이션 로직 작성

4. 트랜잭션/정합성 설계

   • 기존에는 단일 도큐먼트로 처리되던 작업을,
   • 여러 테이블의 트랜잭션으로 나누는 구조를 설계

---

3. 자주 나오는 실무 이슈와 팁

3-1. “처음부터 한 DB로 끝까지 가고 싶다”

현실적으로

• 모든 요구사항을 한 종류의 DB로 완벽히 해결하기는 어렵다.

• 특히 서비스가 성장하면

  • 일부 도메인은 정합성이 최우선,
  • 일부 도메인은 분석/로그/머신러닝용 데이터가 된다.

  팁

  • 처음부터 “나중에 다른 DB를 붙일 수 있는 구조”를 염두에 두는 것이 좋다.
  • 예: DB 접근 레이어를 추상화, 마이그레이션을 고려한 ID/키 설계 등

3-2. “NoSQL이라서 아무 스키마도 안 정해도 된다”는 오해

• MongoDB는 스키마 유연성이 크지만,

• 완전히 무계획으로 사용하면

  • 조회/집계가 어려워지고,
  • 나중에 데이터 정제가 더 힘들어진다.

  팁

  • 최소한 “필수 필드”와 “선택 필드”에 대한 기준은 잡고 시작하자.
  • 코드 레벨에서 DTO/Schema를 정의하거나, MongoDB의 검증 기능을 활용할 수 있다.

3-3. 인덱스 설계와 쿼리 패턴

• RDB든 MongoDB든, 인덱스가 없으면 성능은 금방 한계에 부딪힌다.

• 자주 사용하는 쿼리 조건/정렬 기준을 기준으로 인덱스를 설계해야 한다.

  팁

  • “서비스에서 실제로 날아가는 쿼리가 무엇인지”를 로그/모니터링으로 확인한 뒤,
    인덱스 설계를 반복적으로 튜닝하는 것이 현실적이다.

---

4. MongoDB + MariaDB 하이브리드 설계 시 체크리스트

• 어떤 도메인이 근본 데이터(source of truth) 인지 정의했는가?
• 두 DB 간 데이터를 어떻게 동기화할지 전략이 있는가?
  • 예: 이벤트 기반, 배치 동기화, 이중 쓰기 등
• 양쪽 DB에 서로 다른 스키마를 허용할지, 아니면 최대한 비슷하게 맞출지 기준이 있는가?
• 장애/복구 시 시나리오를 그려보았는가?
  • 한쪽 DB가 다운될 때 서비스는 어떻게 동작해야 하는가?

---

5. 간단 의사결정 템플릿

새로운 기능/서비스를 설계할 때, 다음과 같은 질문 순서로 정리해볼 수 있다.

1. 도메인 정체성

   • 돈/재고/정산/계약 쪽인가?
   • 아니면 로그/행동/실험/문서 쪽인가?

2. 변화 속도

   • 필드와 구조가 앞으로 자주 바뀔까?
   • 초기에는 실험 위주, 나중에는 안정 위주인가?

3. 조회/집계 패턴

   • 복잡한 SQL 집계/조인이 중요한가?
   • 아니면 문서 단위로 읽고 쓰는 패턴이 더 중요한가?

4. 팀 역량

   • 팀이 지금 가장 잘 다루는 DB는 무엇인가?
   • 새로운 DB를 도입했을 때 운영 부담은 감당 가능한가?

5. 확장성 요구

   • 짧은 시간 안에 데이터가 폭발적으로 증가할 가능성이 큰가?
   • 그때 수평 확장이 필수적인가?

이 질문에 대한 답을 바탕으로

• RDB(예: MariaDB)
• MongoDB
• 둘의 조합

중에서 선택하면 된다.

---

6. 정리

• MongoDB와 MariaDB는 서로 대체재라기보다, 각자 잘하는 일이 다른 도구다.
• 실무에서는
  • DB 선택 전 체크리스트
  • 마이그레이션 방향별 고려사항
  • 하이브리드 설계 시 체크 포인트
    를 미리 생각해 두면, 나중에 구조를 크게 바꾸는 비용을 줄일 수 있다.
• 이 시리즈를 바탕으로
  • 프로젝트 초반 설계 문서,
  • 팀 내 DB 선택 논의,
  • 블로그/문서 정리
    등에 활용할 수 있을 것이다.