이 단계에서 얻는 것
이 단계는 “스프링을 안다”에서 한 단계 더 나아가, 데이터/정합성/성능을 근거 있게 다룰 수 있게 만드는 구간입니다.
- DB 성능 감각: 인덱스/실행 계획을 보고 “왜 느린지”를 추적하고, 튜닝 방향을 세울 수 있습니다.
- 정합성 감각: 트랜잭션/격리 수준/락/데드락을 이해해서 “깨지지 않는” 설계를 할 수 있습니다.
- 캐시/메시징 감각: Redis 캐시 패턴, Kafka/Outbox 같은 비동기 설계를 “언제/왜” 쓰는지 연결할 수 있습니다.
- 데이터 관측/운영 감각: “느린 쿼리/락 대기/캐시 미스/컨슈머 지연” 같은 신호를 지표/로그로 연결합니다.
이 모듈을 보는 방법
이 페이지 아래에 연결된 글이 순서대로 정렬됩니다.
- 인덱스/실행 계획으로 “느림”을 해부하고
- 트랜잭션/락으로 “정합성”을 확보하고
- 캐시/메시징으로 “확장/운영”을 설계하는 흐름으로 읽으면 좋습니다.
각 글의 연습은 “완성 프로젝트”가 목표가 아니라, 작은 재현/관찰로 감각을 만드는 것이 목표입니다.
왜 이런 순서인가
데이터 관련 문제는 결국 다음 순서로 좁혀집니다.
- 쿼리가 느리다 → 실행 계획/인덱스/풀/락 대기 중 어디가 원인인지 분해
- 정합성이 깨진다 → 트랜잭션 경계/격리 수준/동시성 제어를 재설계
- 트래픽이 커진다 → 캐시/비동기/샤딩 같은 확장 전략을 선택
그래서 “인덱스/EXPLAIN → 트랜잭션/락 → 캐시/메시징 → 설계 문제” 순서를 기본으로 둡니다.
다음 단계로 넘어가기 전(권장 기준)
- EXPLAIN을 보고
ALL/filesort/temporary같은 위험 신호를 읽고, 인덱스/쿼리 개선 방향을 말로 설명할 수 있다 - 격리 수준/락 때문에 생기는 현상(데드락/락 대기)을 로그/지표로 구분할 수 있다
- 캐시를 “붙여서 빨라졌다”가 아니라, 키/TTL/무효화/스탬피드까지 포함해 설계할 수 있다