항해+ 백엔드 코드 4주차 회고

이번주의 주된 과제는 '데이터베이스'였다. 이미 구현한 데이터베이스도 있지만, 인덱스 튜닝 등 더 보완해 나가는 주 였다.

항해 추천인코드: NYFKU8

✍️ 이번 주 주제: 데이터베이스

이번 주의 메인 과제는 **'데이터베이스'**였습니다.
이미 지난주에 데이터베이스까지 구현하였지만, 인덱싱 등 더 보완하는 시간을 가졌습니다.

---

📌 과제 링크

• Step07 PR
• Step08 PR

---

🗂️ 과제 요약

• STEP07 - Integration
  • (선택) 기존 설계된 테이블 구조의 개선이 필요한 점을 식별하고 ERD에 반영
  • Infrastructure Layer 작성
  • 기능별 통합 테스트 작성
• STEP08 - DB
  • Infrastructure 는 RDBMS ( MySQL ) 기반으로 작성합니다.
    • 조회 성능 저하가 발생할 수 있는 기능을 식별하고, 해당 원인을 분석하여 쿼리 재설계 / 인덱스 설계 등 최적화 방안을 제안하는 보고서 작성

---

🔍 데이터베이스 설계 원칙

• 동일 위상의 데이터만 한 테이블에 구성 (ex. 상품과 리뷰는 분리)
• 컬럼 제약조건 엄격히 설정 (NOT NULL, UNIQUE, DEFAULT 등)
• 초기 설계부터 인덱싱 고려 (자주 사용되는 컬럼 기준)
• 정규화로 일관성과 중복 최소화, 반정규화로 조회 성능 향상

---

📈 인덱스 & 쿼리 최적화 핵심

📌 인덱스 설계 기준

• 조회에 자주 사용되는 컬럼 우선
• 중복이 적고 변경이 적은 컬럼에 설정
• 복합 인덱스 설계 시, 선행 컬럼의 카디널리티 고려
• LIKE, IN, 범위 조건의 인덱스 활용 주의

📌 쿼리 실행 계획 (Query Plan)

• EXPLAIN을 통해 인덱스 활용 여부, 풀 테이블 스캔 여부 확인
• Using filesort, Using temporary 발생 시 성능 저하 가능성

📌 Covering Index

• 조회에 필요한 모든 컬럼이 인덱스에 포함되어 있으면 Index Only Scan 가능

📌 동적 확장성 고려

• 상품 옵션이 다양해질 경우 옵션 테이블 분리 구조로 확장성 확보
• 범용적인 옵션 설계 필요 시 키-값 형태 또는 옵션 유형 분리 고려

---

🔁 Sync Schedule 전략

• 실시간 정합성보다 주기적인 배치 처리로 조회 성능 극대화
• 통계 데이터는 별도 테이블에 저장하여 조회 쿼리 단순화

---

🧠 데이터베이스 설계에 대한 소회

이번 주 멘토링에서 코치님의 인사이트가 특히 기억에 남는다.

"비정규화와 정규화는 각각 어떤 상황에 필요할까?"
이에 대해 코치님은 이렇게 말씀하셨다.

"정규화는 더 이상 정규화할 수 없을 때까지 진행하고,
성능 문제가 발생했을 때 그제서야 비정규화를 고려한다."

 

이 말이 인상 깊었던 이유는,

코치님은 항상 정해진 답이 없는 문제에도 불구하고,
생각하는 방법과 판단 기준을 세워주는 분이라는 느낌을 받았기 때문이다.