결제 도메인 쿼리 인덱스로 응답 속도 145배 개선

인덱스를 추가해서 쿼리 성능을 대폭 개선했음. 17.8s → 0.12s (145배 향상).

문제 발생

특정 페이지 로딩이 수십 초씩 걸리는 현상이 있었음. 데이터가 쌓일수록 더 느려지는 선형 구조였음. 사용자 입장에서 받아들이기 어려운 수준이었고, 트랜잭션 타임아웃까지 발생할 수 있는 상황이었음.

원인 분석

-- EXPLAIN 실행 결과
-- type: ALL (전체 테이블 스캔)
-- rows: 수십만 건
-- Extra: Using filesort

WHERE 조건에 사용되는 컬럼에 인덱스가 없어서 전체 테이블을 스캔하고 있었음. 데이터가 적을 때는 문제가 없었지만 운영 데이터가 쌓이면서 급격히 느려졌음.

인덱스 추가

-- 조회 패턴에 맞게 복합 인덱스 설계
CREATE INDEX idx_balance_history_partner_dt
  ON tb_partner_balance_history (partner_sn, created_dt DESC);

복합 인덱스 설계 원칙:
- 카디널리티 높은 컬럼 앞에 (id > 상태코드)
- WHERE 조건과 ORDER BY 방향 맞추기
- 너무 많은 인덱스는 쓰기 성능 저하

결과

다음

작업 후기

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.

특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 함. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아옴.

개발 방식

• 변경 전 현재 동작 스크린샷이나 수치 메모
• 수정 후 같은 케이스로 확인
• 관련 화면이 있으면 숫자 cross-check
• 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력

작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중.

다음