패스트캠퍼스 챌린지

패스트캠퍼스 환급 챌린지 22일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth 2025. 4. 22. 23:50

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

 

 

 

 

 

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 22일차!
오늘은 인덱스와 DB 실행계획에 대한 개념을 학습하고, 테이블에 인덱스를 추가하는 작업을 진행하였다.

 

조회에서의 성능을 가장 드라마틱하게 올려주는 것은 '캐싱'과 '인덱스'이다.

인덱스란 책의 목차처럼, 테이블에서 원하는 데이터를 더 빠르게 찾기 위해 사용하는 데이터 구조를 말한다.

MySQL(Inno DB)는 B+ Tree 자료구조를 사용하여 인덱스를 구성한다.

 

인덱스의 리프 노드는 실제 데이터를 직접 가지고 있는 게 아니라, 해당 데이터를 어디서 찾을 수 있는지 알려주는 주소나 키 값을 가지고 있다.

InnoDB에서는 클러스터드 인덱스 구조를 사용하는데, 이 구조는 모든 데이터가 PK 기준으로 정렬되어 저장된다.

SELECT name FROM member WHERE age = 20;

위 쿼리를 실행하면 아래와 같은 과정을 거쳐 데이터를 조회한다.

1. age 컬럼에 인덱스가 있다면, 그 인덱스를 탄다.

2. 인덱스의 리프 노드에는 age가 20인 row의 PK값들이 저장되어 있다.

3. 찾은 PK값을 기준으로 클러스터드 인덱스를 조회해서 실제 데이터를 가져온다.

 

 

 

실행계획이란, MySQL 서버에서 요청한 SQL문이 어떻게 데이터를 불러올지에 대한 계획, 경로를 의미한다.

쿼리문 앞에 explain 키워드를 선언하여 실행하면 확인할 수 있다.

 

실행계획의 여러 속성 중 가장 중요한 'type'은 데이터 접근 방식을 나타낸다.

 

- ALL: 풀 테이블 스캔 (테이블 전체를 순회하기 때문에 성능이 가장 좋지 않음)

피드 조회 쿼리의 실행계획이다. 인덱스를 타고 있지 않기 때문에 type이 ALL인 것을 확인할 수 있다.

전체 테이블을 검색하는 것은 데이터가 많아졌을 때 문제가 발생할 가능성이 높아진다.

 

- ref: 인덱스를 사용하여 여러 개의 row를 찾는 경우 (비교적 성능이 좋은 편)

ref는 인덱스의 종류와 상관없이 동등 조건으로 검색할 때 사용된다.

user_post_queue 테이블에 user_id와 post_id를 추가하여 인덱스를 생성한 후 다시 실행계획을 확인해보니, ALL이었던 type이 ref로 바뀌었다.

 

- const: unique key로 단건의 데이터를 조회하는 경우 (성능 좋음)

SELECT * FROM community_user cu WHERE cu.id = 1;

 

const type은 는 위와 같은 쿼리처럼 unique key로 데이터 한 건을 조회할 때 사용된다.

(ref와 비슷하게 동등 조건(=) 으로 검색을 하지만, 유니크 여부와 반환되는 row 수로 구분된다.)

인덱스를 따로 타지 않고, 클러스터드 인덱스에 바로 접근하여 값을 조회하기 때문에 속도가 빠르다.

 

- range: 인덱스를 이요한 범위 조회의 경우

리프 노드 사이에 있는 링크를 이용해서 시작할 노드를 찾고, 범위 전체를 스캔하게 된다.

최종적으로 스캔할 범위에 다다르면 읽은 레코드를 반환하는 형식이다.

SELECT * FROM users WHERE age >= 20 AND age < 30;

age 컬럼에 인덱스가 걸려있고, 범위 조건이 걸린 쿼리이다.

 

- index: 인덱스의 리프 노드를 처음부터 끝까지 순차적으로 스캔하는 경우 (index full scan)

 

위에서 설명한 대표적인 것들 외에도 더 다양한 종류의 type이 있다.

 

 

이렇게 인덱스를 잘 활용해서 쿼리의 성능을 높이는 것도 중요하지만, 일단 가지고 오는 데이터의 개수에 제한을 걸어두는 것이 중요하다.

한 번에 조회하는 데이터의 개수가 너무 많다면 애플리케이션의 메모리가 부족해져 장애로 이어질 수 있다.

 

기업체 실습 당시, 실행계획에 대한 개념을 처음 접한 기억이 난다.

이전까지는 데이터의 수가 굉장히 적고 테이블 구조도 복잡하지 않은 프로젝트 경험만 있었기에, 처음으로 방대한 테이블들을 마주하고 상당히 충격을 받았던 게 생각난다.

그리고 실행계획을 바탕으로 튜닝 계획을 세우고, 튜닝 후 실제로 조회 성능이 좋아진 것을 직접 확인한 후 2차로 충격을 받았다ㅋㅋㅋ

진짜 백엔드를 경험해보는 느낌이었달까?

 

백엔드 공부를 하면 할수록 성능 향상의 중요성을 계속해서 느끼게 된다.

강의에서 배운 type 이외의 다른 속성들에 대해서도 더 공부해봐야겠다.