alt

JSONB vs 정규화: 데이터베이스 설계

Shared on May 3, 2026

Q시즌 교육기획팀 멘토링 – 데이터 저장 및 인프라 설계

개요

  • 대상: Q시즌 26·27기 백엔드 개발자 김윤근(멘티)
  • 목적: 데이터 저장 구조, 성능, 통계, 로그 처리, 인프라 구성 등에 대한 실무적 조언 및 방향성 제공
  • 형식: 25분 멘토링 세션(멘토와 멘티 간 질의응답)

주요 토픽

1. 데이터 저장 방식

  • 정규화 vs JSONB
    • 질문 유형별 스키마가 다양해 별도 테이블을 만들면 관리가 어려움 → JSONB 컬럼 사용 권장
    • MySQL 5.7에서는 JSON 타입이 없으므로 텍스트 컬럼에 JSON 문자열 저장 → 서비스 레벨에서 파싱
  • 성능
    • 정규화된 테이블이 일반적으로 빠르지만, 데이터 양이 적거나 복잡도가 낮으면 JSONB도 충분히 성능 허용
    • 인덱스 필요성은 실제 데이터 분포와 양을 보면서 결정

2. 제약조건(Constraints)

  • 포린키: 거의 사용하지 않음 → 데이터 무결성은 어플리케이션 레벨에서 검증
  • 유니크키: 필요 시 적용 가능하지만, 프로젝트 단계에서는 필요 최소화 권장

3. 통계 처리

  • 실시간 vs 배치
    • 실시간 요청이 없으므로 배치(스케줄링)으로 통계 생성 권장
    • 통계 결과는 별도 테이블에 저장 → 쿼리 비용 최소화
  • 인덱스
    • 데이터 양이 적으면 인덱스 필요 없으며, 정규화된 구조라면 인덱스 부담이 적음

4. 로그(히트맵) 저장

  • 로그 데이터: 터치 좌표, 디바이스 정보 등 대용량, 비정형
  • 추천 저장소
    • MongoDB 또는 Elasticsearch 등 NoSQL 사용 → DB 커넥션 풀 부담 감소
    • 일반 서비스 DB와 분리해 운영
  • 데이터 포맷
    • JSON 형태로 저장 → 비정형 데이터에 유연
    • 좌표 비율 보정 로직은 서비스 레벨에서 처리

5. 인프라 구성

  • Kubernetes & CI/CD
    • 기능 개발이 먼저이므로, 프론트/백엔드 개발 중에도 CI/CD를 도입해 효율성 확보
  • 부하 테스트 & 모니터링
    • API 개발 완료 후 부하 테스트 → 성능 검증
    • 모니터링/알러트는 이후 단계에서 추가
  • 클라우드 선택
    • GCP 권장 (OCI보다 편리)
    • 필요 시 OCI, GCP 등 비용/특징 비교 후 결정

의견 및 시사점

  • JSONB 활용: 정규화보다 유연성이 높으며, 비정형 데이터 처리에 적합
  • 제약조건 최소화: 개발 속도와 유연성을 위해 포린키·유니크키를 최소화하고, 어플리케이션 레벨에서 검증하도록 설계
  • NoSQL 활용: 로그나 히트맵 같은 비정형 대용량 데이터는 MongoDB 또는 Elasticsearch에 저장해 성능과 확장성 확보
  • 통계는 배치: 실시간 요청이 없으므로 배치 처리와 별도 테이블 저장으로 쿼리 비용 최소화
  • 인프라 단계별 도입: 기능 개발 우선 → CI/CD → 부하 테스트 → 모니터링 순으로 단계적 도입

핵심: “정규화보다 JSONB 컬럼을 쓰는 것이 유연성이 높다” – 데이터 구조가 자주 바뀔 경우 JSONB가 더 적합함을 강조


Q&A 하이라이트

질문답변
JSONB vs 별도 테이블데이터 유형이 다양하고 관리가 어려움 → JSONB 권장
정규화된 테이블이 빠르다일반적이지만, 데이터 양이 적으면 JSONB도 충분히 빠름
통계는 언제 만들까?실시간이 아니라면 배치(스케줄링)으로 생성
로그 저장소는 어디가 좋을까?MongoDB/Elasticsearch 등 NoSQL 사용, 일반 DB와 분리
인프라 도입 시점기능 개발 완료 후 CI/CD → 부하 테스트 → 모니터링 순서