배경

• 설문 상세/목록 조회에서 질문·선택지 등 중첩 구조를 한 번에 응답해야 한다
• 시스템 설계 구조 상 설문 조회에 다수의 요청이 발생할 가능성이 높다

문제사항 & 고려사항

• RDB에 조회용 테이블을 추가하면 정규화/조인/매핑이 늘고, 스키마 변경·마이그레이션 비용이 크다
• 중첩 구조를 평탄화하면 코드 복잡도와 I/O 횟수 증가한다
• 캐싱만으로 해결하면 필터/정렬/페이지네이션 구현이 번거롭고, 키 설계·무효화가 복잡해진다

해결방안 → MongoDB

• 문서 지향 저장으로 설문 요약(옵션/질문/선택지/참여수)을 한 도큐먼트에 저장 → 조회 I/O 최소화
• 스키마 유연성으로 질문/옵션 변경 대응 용이하다
• 간단한 인덱스(projectId, surveyId)로 목록/상세/커서 페이징을 구현할 수 있다
• 운영 단순화: MongoTemplate 기반 벌크 업서트로 대량 갱신 비용이 감소한다
• CQRS 분리: 쓰기(JPA)와 읽기(Mongo) 트래픽 분리, 필요할 경우 읽기기능의 수평적 확장이 가능하다

스토리지 후보 비교

• RDB 조회용 테이블
  • 장점: 단일 DB 운영
  • 단점: 조인/스키마 변경 비용 상승, 중첩 구조 반영 비효율, 외부 api 호출에 대한 최적화 불가능
• Redis
  • 장점: 초저지연
  • 단점: 필터/정렬/페이징 구현 난이도 상승, 메모리 비용 상승
• Elasticsearch
  • 장점: 검색·분석 특화
  • 단점: 운영 복잡도 상승

결론

중첩 구조의 빠른 조회, 간단한 필터/정렬과 외부 api 호출 최소화를 위해, 조회 전용 저장소로 MongoDB를 선택하게 되었습니다.

• 추가로 surveyId 유니크/복합 인덱스를 보강할 수 있고,