복잡한 설문과 위치 기반 서비스를 위한 DB 선정기

1. 서비스 개요 및 데이터 환경

• 목적: 학생 성향, 가변적 성적 데이터를 분석하여 최적의 교육 환경(학교/학원)을 매칭하는 플랫폼.
• 핵심 로직:
  • 구조가 다른 비정형 설문(가변 성적) 데이터 수집 및 고속 조회.
  • 다중 태그(관심사, 학습 고민 등) 간의 교집합을 구하는 다차원 매칭 알고리즘.
  • 유저 거주지 기반 최단 거리 지점 추천 (LBS).

---

2. 기능별 DB 기술 상세 비교 및 선택 근거

A. 비정형 데이터 처리 (가변 성적, 설문 결과)

• MySQL (JSON): JSON 타입을 지원하나 내부적으로 BLOB 형태의 텍스트 덩어리로 저장됨. 쿼리 실행 시 매번 파싱(Parsing) 오버헤드가 발생함.
• PostgreSQL (JSONB + GIN): JSONB 타입은 이진(Binary) 형태로 저장되어 조회 시 파싱 과정이 생략됨. GIN(역인덱스)을 통해 JSON 내부의 특정 Key/Value를 콕 집어서 인덱싱이 가능함.
• 결정: 데이터 형태를 고정하기 어려운 가변적 환경에서 RDBMS의 무결성과 초고속 다중 검색 성능을 보장해야 하므로 PostgreSQL 선택.

B. 다중 태그 매칭 (배열 데이터 교집합 검색)

• MySQL: 다대다(N:M) 매핑 테이블 생성이 강제되어 데이터 증가 시 무거운 JOIN 연산이 필연적임. 단일 컬럼 텍스트 저장 시 LIKE 검색을 해야 하므로 Full Table Scan 발생.
• PostgreSQL (Native Array): RDBMS임에도 Native Array(VARCHAR[]) 타입 지원. &&(교집합), @>(포함) 같은 배열 전용 연산자를 인덱스와 결합해 JOIN 없는 초고속 매칭 가능.
• 결정: 매핑 테이블을 없애 복잡한 JOIN 쿼리를 제거하고 백엔드 애플리케이션의 개발 생산성을 극대화할 수 있으므로 PostgreSQL 선택.

C. 위치 기반 서비스 (가장 가까운 지점 K-NN 검색)

• MySQL (Spatial): 공간 함수는 훌륭하나, "가장 가까운 N개"를 찾는 검색 시 ORDER BY ST_Distance(...) LIMIT N 방식을 써야 함. 대상 범위의 모든 거리를 메모리에서 계산 후 정렬(File Sort)해야 하므로 병목 우려.
• PostgreSQL (PostGIS): 공간 데이터 업계 표준. <-> 연산자와 GiST 인덱스를 결합하면 전체를 스캔하여 정렬하지 않음. 인덱스 트리 구조상 가장 가까운 노드부터 탐색(K-NN Search)하여 결과를 즉시 추출함.
• 결정: LBS 연산 구조 자체가 아키텍처 수준에서 최적화된 PostgreSQL 선택.

---

3. 예상되는 반박 및 내 생각 (Trade-off & Architecture)

• 반박 1: 배열(Array)이나 JSON을 남용하는 것은 RDBMS의 기본인 제1정규화(1NF) 원칙에 위배되는 것 아닌가?

  • 내 생각: 기술적 비정규화가 맞음. 그러나 무조건적인 정규화로 매핑 테이블을 쪼개는 것은 잦은 연산을 유발함. 해시태그나 성적처럼 그 자체로 독립적인 엔티티가 아닌 '종속된 속성' 데이터는 특수 타입을 활용하는 것이 쿼리 복잡도 감소 측면에서 압도적 우위. 실용성과 매칭 성능을 위한 의도된 트레이드오프임.

• 반박 2: MySQL 8.0도 기능이 좋은데, 굳이 익숙한 생태계를 벗어날 필요가 있는가?

  • 내 생각: 단순한 기능 '지원' 여부가 아닌 코어 로직을 받쳐줄 '인덱싱 메커니즘(GIN 등)'의 근본적 차이에 주목함. 비즈니스 로직(다차원 매칭)에 가장 핏이 맞는 엔진을 택하는 것이 합리적임.

---

4. 결론

• 본 프로젝트에서 DB는 수동적인 데이터 저장소가 아니라, 백엔드 서버의 연산 부하를 덜어주는 '능동적인 다차원 매칭 연산 엔진' 역할을 수행해야 함.
• 비정형성 제어, 배열 연산, 공간 탐색 최적화라는 3가지 핵심 비즈니스 요구사항을 완벽히 지원하는 PostgreSQL 도입을 최종 결정함.