해당 문서는 X의 Grok4가 답변한 내용을 토대로 작성 되었습니다. Grok4를 채택한 이유는 Grok4의 추론, 연구 능력이 특히 강하다는 AI 타임즈의 기사를 읽었던 기억이 있어서 채택해 보았습니다.

조금 바보같은 의문일 수 있지만 SQL 옵티마이저에 대한 공부를 진행하던 중 의문이 들었다.
SQL 옵티마이저에 대한 내용을 파악할수록 SQL 옵티마이저가 AI 기반으로 동작하도록 개발되었다면 SQL 옵티마이저가 실행 계획 수립 시 실수하는 부분들이 줄어들고 더 정확한 비용으로 빠른 실행을 하지 않을까? 하는 단순 궁금증에서 시작했다.
내용에 들어가기 앞서 SQL 옵티마이저에 대해 알아보자.

SQL 옵티마이저와 옵티마이저의 실행 계획 수립 방법에 대해

• SQL 옵티마이저란?
  • SQL 쿼리를 실행할 때, 가장 효율적인 방법(최적의 것)을 자동으로 선택하는 엔진
  • 주요 역할: 쿼리 파싱 후 실행 계획 생성 및 비용(CPU, I/O 작업, 메모리 사용 등) 평가
  • 필요 이유: 대규모 데이터에서 비효율 적인 실행으로 인한 성능 저하 방지
• SQL 옵티마이저 작동 원리
  1. 쿼리 파싱: 쿼리 구문을 분석하고 논리적 표현으로 변환
  2. 가능한 실행 계획 생성: 쿼리를 재구성하거나, 인덱스 사용, 조인 순서 변경 등 다양한 대안을 만듦
  3. 비용 평가: 각 계획의 예상 비용을 통계 정보를 활용하여 계산
  4. 최적 계획 선택: 비용이 가장 낮은 계획을 선택하고, 실행 엔진으로 넘김
• SQL 옵티마이저의 종류
  • 규칙기반 RBO (Rule-Based Optimizer)
    • 미리 정의된 규칙에 따라 계획 선택
    • 간단하고 예측 가능 함
    • 데이터 통계 무시, 대규모 데이터에서 비효율적
  • 비용기반 CBO (Cost-Based Optimizer)
    • 데이터 통계와 비용 모델로 최적 계획 계산. 동적이고 정확함.
    • 실제 데이터에 맞춰서 최적화 가능
    • 통계가 부정확할 경우 잘못된 실행계획 수립

      * 이 글을 쓰게 된 이유* : 여기서 궁금한 점이 생겼다.

      나는 옵티마이저의 작동 원리 중 비용 기반의 옵티마이저에서 통계를 수립할 때 동작하는 원리가 AI 모델과 같이 학습을 통해 스스로 선택하는 구조인지가 궁금했다.
      만약 아니라면 앞으로 발전할 DBMS에서 AI 기반의 옵티마이저가 선택될 가능성과 이미 실천되고 있는 DBMS가 있지 않을까? 하는 생각에 Grok4에게 질문했다.

Grok4! CBO에서 실행 계획 생성을 위해 통계를 수립하고 쿼리를 재구성할 때 AI와 같이 딥러닝을 기반으로 스스로 학습하는 구조로 되어있어? 아니면 단순한 알고리즘 기반으로 작동이 되나?

하단부터는 Grok4가 들려준 대답이다. Grok4에서는 Grok3랑은 다르게 Grok이 질문을 이해하고 정보를 수집하는 과정들을 사용자도 볼 수 있더라... 진화하는 Grok...

• 통계를 수집하고 비용을 계산하는 방식은 DBMS에 따라 다르지만, 대부분의 경우 AI나 딥러닝처럼 "스스로 학습"하는 구조가 아니라, 미리 정의된 수학적 모델과 알고리즘에 기반한 "단순한" (하지만 정교한) 규칙 기반 접근입니다.

  전통적인 CBO 작동 방식: 단순 알고리즘 기반

• 대부분의 CBO는 AI 없이 작동합니다.
  • 통계 수집: DBMS가 자동 또는 수동으로 테이블/인덱스 통계를 모읍니다. (데이터 분포도, 행 수, Index 등을 포함 함)
  • 쿼리 재구성 및 계획 생성: 쿼리를 논리적 트리로 변환 후, 가능한 실행 계획(조인 순서, 인덱스 사용 등)을 나열 하고 각 계획의 비용을 계산, 최저 비용 계획 선택.
  • 사용 알고리즘: 동적 프로그래밍 혹은 휴리스틱에 의존

    최근 옵티마이저의 추세

• 2025년 현재 일부 DBMS와 연구에서 CBO에 AI를 통한 학습 기능을 추가하고 있습니다.
• 전통적인 CBO의 한계 보완 및 통계 추정이나 계획 선택을 데이터로 부터 학습합니다.
  • MSSQL 2025: AI 통합으로 쿼리 최적화 지원, ML 모델이 실시간으로 쿼리 패턴을 학습해 실행 계획 자동 조정
  • 연그 및 오픈소스: Balsa처럼 강화학습 에이전트가 쿼리를 학습
  • 클라우드 DBMS: Amazon Redshift나 Google BigQuery에서 ML 기반 자동 최적화. 쿼리 실행 이력으로 모델 학습 및 스스로 적용

    AI 옵티마이저의 장단점

• 학습 구조는 복잡한 쿼리에서 더 정확하지만, 학습 데이터가 필요하고 오버헤드(훈련시간)가 발생.

웹개발자로 일한지 5년차에 접어들었다. 5년차 숫자로 보면 대단해 보이지만 막상 실속은 없는 개발자로 시간만 보낸 기분에 개발자라는 직업을 내려놓을까 생각도 여러번 했었던 것 같다. 그래도 계속 하고 싶었다. 웹 개발이 계속 하고 싶었다기 보단... 사실은 DB를 계속 다루고 싶었다.

만 4년을 꽉 채우고 처음 입사한 회사에서 퇴사했다. 그 후로 1년을 그냥 쉬었다. 개발에 대한 흥미가 떨어지기도 했고 심적으로 지친 상태에서 개발자라는 직업에 많은 생각이 들었던 것 같다. 코로나로 인해 내 예상보다 빨라진 IT 붐과 퇴사와 함께 업계가 죽어갔다. (사실 업계라기 보단 경제가 죽어간 거지만...) 나는 바보처럼 좋은 연차를 쌓고도 파도를 타지 못한 개발자가 되었다. 그렇게 나는 퇴사 후 개발과 멀어졌다.

그래도 하고 싶은 건 많았다.

개발과 담을 쌓으면서도 하고 싶은 건 여전히 많았다. 나는 혼자서 1인 프로젝트를 진행하고 싶었다. 새로 생긴 취미에 도움이 될만한 웹사이트를 개발하고 싶었고 그걸 위해 디자인을 배우고 싶었고 배운 디자인으로 이모티콘도 출시하고 싶었다. 그리고 이 모든 건 잘 실행되지 않았다. 단기간에 배울 수 있는 건 없다. 나는 이 사실을 너무 잘 알고 있었지만 내가 6개월동안 디자인을 배우는 걸 허락하는 개발 회사는 없었다. 디자인은 왜... 하고 비웃던 수많은 면접관들이 있었다. 백엔드 하실건데 디자인을 왜 배우세요, 프론트 개발자도 아니고. 퍼블리셔도 아니고. 초반엔 나도 성실하게 대답했다. 원하는 바가 확실했으니까 근데 이런 질문들이 계속 될 수록 회의감이 크게 다가왔다. 개발자들은 진짜로 개발 공부만 하는건가? 깊이를 중요시 하는 건가? java 개발자가 ai에 대한 공부를 하는 건 흥미롭게 생각하면서 왜 다른 공부에 대한 차별적인 발언은 이렇게나 많을까? 이런 불만을 가질거면 증명해야했다. 내가 배운 디자인이 내가 공부했던게 나중에 나에게 이런 장점으로 다가오잖아. 잘 봐 그래도 배워두길 잘했다고. 그렇게 증명하기 위해서 나는 타협해야 했다. 돈이 없었기 때문에...ㅋㅋ 진짜로 인생 살기 힘들다.

다시 개발에 흥미를 붙이는게 우선이다.

인생 사는 거 별거 없다 하고 싶은 일만 하면서 살아가는 사람이 어디있겠나. 나는 어릴때부터 개발자가 하고 싶었다. 이 길만 바라보고 살았더니 너무 이른 경력에 현타가 온 것 같다. 내가 이 일을 못하게 되면 나는 더이상 할 수 있는게 없다는 생각이 너무 무섭게 다가왔다. 이게 내가 개발에 흥미를 잃었던 가장 큰 이유다. 1년을 쉬면서 깨달았다 이 일 저 일 해보면서 시간을 들이지 않고 얻을 수 있는 건 없고 그와 대조되게 사실은 의지와 노력만 있다면 어디든 가서 살아남을 방법은 있다. 그게 꼭 죽도록 노력할 필요도 없고 몸을 갈아 생활할 수 있는 일이기도 하다. 그래서 두렵다고 생각하지 않기로 했다. 우선 다시 개발에 흥미를 붙이고 DB 외의 알고리즘에도 흥미를 붙이려고 한다. DB는 내가 정말 좋아해서.. 1년 쉬는 동안에도 놓지 않았었다. 프로젝트 구상을 하면 꼭 DB 설계까지는 완성했고, 자격증도 취득하고 이제 하던 건 괜찮으니 안하던 걸 진행하기만 하면 된다. 두려워하지말고 앞으로 나아가보자. 사람들도 다 무서운게 있을거다 그걸 견디며 살아가는 사람도 있고 피하며 살아가는 사람도 있을거고 둘 중 뭐가 잘못됐고 뭐가 맞는 건지는 아무도 모른다. 정해진 답이 없기 때문에... 나는 내가 가는 길이 맞는 길이라고 생각하며 살아가려고 한다. 남들과 비교하기 보단 그게 내 정신 건강에도 좋을 거 같음... 힘내자 비교하지말고 느려도 남들보다 모자라도 일단 완성이라도 하자... 완성하지 못한 사람이 할 수 있는 말은 없다... ㅜㅜ 에휴

난 선생님도 좋아하고 선생님의 춤도 좋아하고 선생님이 알려주는 힙합 댄스도 좋아하니까 선생님이 불편하다고 느끼는 사항들을 최대한 개선해드리고 싶었어요.

그래서 생각해낸게 바로 간단출결체크 웹페이지 개발이다.

이 구상에서 가장 먼저 생각해낸 것은 "코로나 전자출입명부"이다. 전 국민이 가는 가게 마다 출입 기록을 작성했던 그 때의 기억을 떠올리며 아주 간단하게 개발을 진행해 보려고 한다.

(1)사이트의 구상

사이트 구상의 경우 아주 간단하게 작성했다. 기획서를 작성하기 전 대략의 필요한 기능 정리를 하는 식으로 진행하였다.

(2)DB 설계

DB 설계 시 MYSQL의 장점을 최대한 살려보고자 하였다.

• DATETIME과 TIMESTAMP의 차이
• TIMESTAMP는 1970-01-01 00:00:01 ~ 2038-01-19 08:44:07 까지의 데이터만 지원한다.
• DATETIME의 경우 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 사이의 데이터를 지원한다.
• (MYSQL 5.6.4 버전 이상 기준) TIMESTAMP의 경우 4 BYTE + 3BYTE의 크기를 필요로 하며 DATETIME의 경우 5BYTE +3BYTE 크기를 필요로 한다
• TIMESTAMP 타입을 갖는 쿼리는 캐시로 저장되지만 DATETIME 타입을 갖는 쿼리는 캐시로 저장되지 않는다.

간단 출결 체크 웹의 경우 TIMESTAMP의 범위를 넘어갈 일이 없기 때문에 메모리 크기와 캐시등 비용 이슈를 고려해 TIMESTAMP의 데이터 타입을 체택하였다.

확인 필요한 사항

양도 가능한 클래스인 경우 양도로 출석체크 시 양도받은 사람의 명도 적어야 하는지? 추가로 사이트가 거대해질 경우를 대비해 클래스 강사님의 이름도 정리해 두는 컬럼 작성할 것

1. 공간복잡도 (Space Complexity) : 알고르짐에 사용되는 메모리의 총량
2. 시간복잡도 (Time Complexity) : 알고리즘에 수행되는 연산 횟수 총량 (** 훨씬 더 많이 사용되는 개념)

요즘은 하드웨어의 성능이 좋아져서 공간복잡도보다 시간복잡도에 대한 내용이 더 중요하게 생각 된다.

int get_sum(int arr[], int n) {
    int sum = 0; 
    int i = 0;
    for(i = 0 ; i <n ; ++i) {
        sum += arr[i];
    }
}

위와 같은 get_sum(a,b)의 경우

• 공간복잡도: n + 3
  • n의 의미: 배열에 담기는 개수
  • 3의 의미: 사용된 변수 (sum, i, n)
• 시간복잡도: n
  • for문이 반복되는 횟수로 시간복잡도를 계산한다

int get_sum(int n) {
    int sum = 0; 
    int i = 0; 
    int j = 0; 

    for(i = 1; i <=n; ++i) {
        for(j = 1; j <=i ; ++j) {
            sum += j; 
        }
    }
}

위와 같은 get_sum(n)의 경우 시간복잡도를 계산하는 방법

즉 반복되는 횟수는 1 + 2 + 3 + ... + n 까지의 합을 구하는 것과 같다 따라서 위 get_sum(n)의 시간복잡도는 n(n+1)/2 가 된다.

• BIG-O 표기법
  • 시간복잡도와 공간복잡도의 최고차항만을 표기하여 간략하게 나타내는 표기법으로 보통 알고리즘을 수행하는데 걸리는 표준시간 대신 최악의 시간을 산출하여 표기한다

• 선형구조 ➡️ 스택(Stack) ➡️ 큐(Queue) ➡️ 리스트(List)

• 비선형구조 ➡️ 트리(Tree) ➡️ 그래프(Graph)

• 선형구조 : 데이터를 일렬로 연결

• 연결리스트 - 단일 연결리스트, 이중 연결 리스트 (배열의 단점을 극복하기 위해 나옴)

• 트리 - 이진 탐색 트리 (자식 노드의 최대 개수가 2개인 트리 구조)

• 그래프 - 방향, 접점을 가지는 구조 (지하철 노선도와 같은 모양)

• 알고리즘이란?

  • 문제를 해결하는 방법
  • 자료구조를 구현하려면 알고리즘이 필요함

• 알고리즘 종류

  1. 유클리드 알고리즘 - 두 수 사이의 최대공약수를 구하기
  2. 정렬 알고리즘 - 원소들을 정렬하기
  3. 탐색 알고리즘 - 원소 찾기
  4. DFS 알고리즘 - 깊이 우선 탐색 (이진 탐색 트리)
  5. BFS 알고리즘 - 너비 우선 탐색 (이진 탐색 트리)
  6. 그래프 알고리즘 - 그래프 구조에서의 삽입, 탐색
  7. 그외: 해시 알고리즘, 탐욕 알고리즘, 동적 계획법

최소한의 CPU, I/O, 메모리를 사용하여 최대한 빠른 시간내에 원하는 데이터 작업을 수행하도록 만드는 것 "불필요한 자원을 사용하지 않도록 하는 것"

• SQL 수행 속도는 환경에 의존적인 값으로 환경이 변하면 함께 변한다. 즉, 개발환경과 운영환경에서 동일한 SQL을 수행할 경우 차이가 발생할 수 있다는 뜻이다.
• SQL 튜닝은 분석 및 설계 단계를 시작으로 개발 및 구현, 운영 단계에서도 지속적으로 해야 한다.

SQL 튜닝의 시점

1. 분석 및 설계 단계 에서의 튜닝 확인

• 사용자의 데이터 처리 및 조회 패턴을 감안한 업무 요건 분석
  • *사용자의 입장에서 설계가 우선적이다. *
• 중요 업무 화면에 SQL 성능 최적화를 고려한 화면 설계
  • 필수 검색어 혹은 조회 기간 필수 입력 등으로 과부하 제어
• 업무 성격에 따른 최적화 된 데이터 모델링
• 최적의 실행 계획 수립을 위한 DBMS 파라미터 및 통계 정보 관리

2. 개발 및 구현 단계

• 개발 운영 환경 차이에 중점을 두고 튜닝한다.
  • 개발/운영 환경 차이가 발생하는 이유
    • 파라미터, 통계 정보 수립 정책 상이
    • 개발과 운영의 데이터 양의 차이

SQL 튜닝 절차

_"튜닝 대상 SQL 수집 > SQL 문제점 분석 및 개선사항 도출 > 개선사항 적용 및 개선 효과 확인" _

1. 튜닝대상 SQL 수집

• 현재 문제가 되는 SQL 과 향후 문제가 될 SQL을 수집한다.

  • 현재 문제가 되는 SQL 이란?

  1. SQL 실행에 필요 이상의 자원을 사용하고 있는 경우
  2. 자원을 독점하여 다른 SQL에 영향을 끼치는 경우
     • 향후 문제가 될 SQL 이란?
  3. 추후 데이터가 증가하거나, 사용자가 증가할 경우 서버의 자원을 대량으로 점유할 가능성이 있는 경우
• 개발, 운영팀의 협의가 어려운 경우 튜너가 문제가 되는 SQL을 추출해야 한다. 이런 경우, 데이터가 운영 환경과 유사한 경우와 운영 환경과 유사하지 않은 경우 두가지로 나누어 확인한다.

  1. 데이터가 운영 환경과 유사한 경우

  • 모니터링 툴이 있다면, 수행 시간 목표치를 정하고 목표값보다 긴 SQL을 추출.
    • 모니터링 툴이 없는 경우, SQL 대상으로 처리 속도, CPU 점유 시간, I/O 등을 검색해 특정치 이상의 SQL을 추출.

      2. 데이터가 운영 환경과 다른 경우

  • 중요도가 높은 SQL을 중심으로 운영 환경과 흡사한 환경에서 실행 계획을 별도로 확인
    • 여의지 않는다면 테이블 인덱스 구성 확인, 데이터 성격을 파악하여 실행 계획 유지 검증
    • 추출이 완료 되면 추출된 SQL의 우선순위를 확립한다.

TIP. 운영 중인 시스템이라면 SQL 수행 이력 정보 확인 혹은 1회 자원 사용량 * 실행 횟수에 대한 누적 자원 사용량이 많은 SQL일수록 개선효과가 확실하게 나타난다. ** SQL 튜닝은 업무에 대한 파악이 수반되어야 정확한 개선이 가능하다. **

2. SQL 문제점 분석 및 개선 사항 도출

1. 개발, 운영 환경이 유사한 경우

+ 수행이력 정보가 분석을 위한 정보 가치가 있다.  

2. 데이터가 운영 환경과 다른 경우

+ 해당 SQL의 실행 계획을 중심으로 튜닝 대상 SQL을 판단하고 분석한다. 

3. 개선 사항 적용 및 개선 효과 확인

• 개선 사항을 개발자에게 전달하면 검토과정을 거쳐 적용하게 됨
  • 개선사항이 요구사항에 위배되지 않는지, 유사 형태 SQL 사용이 있는지, 개선 사항 적용 시 발생할 부작용 사례가 있는지에 대한 검토가 이루어져야 한다.
• 튜너가 제시하는 개선사안이 무조건 정답은 아니기 때문에 개발자와 튜너 간의 소통은 매우 중요하다. *

SQL 튜닝 유형

1. 인덱스 사용 적절한 인덱스가 없거나 인덱스를 활용하지 못해 문제가 되는 SQL이 가장 많음
2. 조인 조인 순서가 성능에 영향을 주는 경우가 있음 드라이빙 테이블의 이해가 중요

** SQL 튜닝 시에는 옵티마이저와 실행계획을 파악하는게 가장 중요하다. 옵티마이저의 원리를 이해하고 실행계획을 정확히 판독할 수 있으면 이미 튜닝이 가능한 수준이다. **

01. JAVA Builder Pattern

• 생성 패턴 중 하나
• 불필요한 코드의 양을 줄여 줌
• Setter 메소드가 없는 인스턴스를 생성하여 변경 불가능하게 하는데 용이하다 (변경가능성 최소화)
• 유연성 확보 가능 (변수가 새로 추가됐을 경우)
• 변수의 개수와 변경 가능성을 중점적으로 보고 빌더 패턴을 적용하면 된다
• 필수적인 멤버 변수와 선택적인 멤버 변수를 효과적으로 구분할 수 있음

02. Java Assertion

• private 메소드에서 사용함
• 선행 조건의 의미가 아닌 테스트용 코드 (확신하는 값의 점검 용)
  • 코드 실행 전 사전 조건 점검 or 코드 실행 후 사후 조건 점검
• assert가 참인 경우 아래 코드 실행, assert가 거짓인 경우 Exception 처리 됨
• 실행 시 VM Option에 -ea를 붙여줘야 assert 구문이 실행 됨
• 운영에서는 해당 assert 구문이 실행되지 않을 수 있음!! (옵션에 따라 다르지만 대게 실행되지 않음)
• 운영에서 예외를 처리하려면.. Exception으로 받아 로그를 남기는게 더 운영 관점에서는 오류 찾기가 수월할지도..

03. ORM(Object-Relational Mapping) 과 JPA

• ORM
  • class와 rdb를 매핑한다는 뜻이며, 기술적으로는 애플리케이션의 객체를 RDB 테이블에 자동으로 영속화 해주는 것
  • 다시 말해 객체와 데이터 관계의 설정
  • SQL 쿼리가 아닌 method를 통한 DB 조작이 가능해진다
  • 객체지향적인 코드 작성이 가능해진다
  • 프로젝트 규모가 크고 복잡하여 설계가 잘못된 경우는 속도에 영향이 갈 수도 있다

04. TDD (Test Driven Developer)

• 테스트가 주도하는 개발
• 실패하는 테스트코드 작성 -> 테스트가 성공하는 프로덕션코드 작성 -> 테스트가 성공하면 프로덕션 코드를 리팩토링
• 한번에 한가지만 검증하기
• spring boot 테스트
  • MockMvc
    • MockMvc는 웹 어플리케이션을 애플리케이션 서버에 배포하지 않고 테스트용 MVC환경을 만들어 요청 및 전송, 응답기능을 제공해주는 유틸리티 클래스
    • 컨트롤러를 테스트 하고 싶을 때 사용
• @Mock
  • 테스트 시 실제 객체를 생성할때 의존성이 복잡하게 얽혀있는 경우 가짜 객체를 생성하는 방식
• given-when-then 패턴이란 1개의 단위 테스트를 3가지 단계로 나누어 처리하는 패턴
• @SpringBootTest
• 통합테스트
• Maven 빌드 시 junit 제외하기
  • clean install -Dmaven.test.skip=true
• @DataJpaTest

• 아파치에서 제공하는 자바용 프로젝트 관리 도구
• 프로젝트의 전체적인 라이프사이클을 관리
• 아파치의 Ant의 대안으로 만들어졌다.
• 오픈 소스 소프트웨어
• 사용할 라이브러리와 연관되어 함께 다운로드 되어야 하는 라이브러리를 자동으로 다운로드 및 업데이트 해주는 관리 도구
• pom.xml 에 관련 라이브러리를 선언한다.

Gradle 이란?

• 안드로이드 앱의 공식 빌드 시스템
• 오픈 소스 빌드 자동화 도구로, 거의 모든 종류의 소프트웨어를 빌드할 수 있을 정도로 유연하게 설계되어 있음
• Groovy 기반의 Domail Specific Language를 사용하여 코드가 간결하다.
• 빌드 캐시를 사용하여 재사용이 유연하며 빠르다.
• JVM 기반으로, JDK가 설치되어 있어야 한다.

아무래도 코드의 간결성이나 빌드 속도 등을 고려했을 때, Gradle을 사용하는게 더 유리해보인다. Gradle은 Maven을 참고하여 설계된 빌드 관리 도구이기 때문에 Maven의 단점을 커버하는 건 당연한 걸지도..?

틀린 부분도 있을 수 있으니 차근차근 더 깊게 공부해서 알아가는 걸로~~

갑자기 자바에서 캐시 적용을 찾는 이유?

우선 잊어버리기 전에 이 캐시 적용을 찾아보게 된 계기를 적어놓겠다. 웹 사이트를 개발할때는 보통 이 사이트를 개발해달라고 요청하는 클라이언트들이 있다. 우리가 사이트를 개발하면 프론트/어드민 페이지 두 개의 사이트를 개발하게 되는데 클라이언트들이 어드민에서 콘텐츠를 등록하면 그게 프론트에 노출되는 방식으로 사용이 된다. 그런데 내가 쇼핑몰 사이트 유지보수를 맡게 되고 얼마 지나지 않아 클라이언트 쪽에서 이런 문의가 왔다.

어드민에서 콘텐츠를 등록했는데, 콘텐츠가 노출이 안돼요!

왜? 내가 처음 이 문의를 받았을 때 들었던 생각은 왜..? 라는 단어 뿐이었다. 어드민에서 콘텐츠를 등록하면 당연히 DB에 해당 데이터들이 쌓이게 될 거다. 그럼 프론트에서 데이터를 노출 시킬때 DB를 조회해서 보여주기 때문에 컨텐츠가 제대로 등록이 됐다면 나오는게 당연한데?? 무슨 이런 문의가 왔나 싶었는데 그 후에 또 다른 문의가 왔다.

시간이 지나니 노출이 되네요.. 혹시 캐시 갱신이 몇 분인가요?

캐시? 나는 보통 쇼핑몰처럼 사용자가 많이 몰리는 사이트가 아닌 back-end 단에서 데이터를 가공하는, 어드민의 그 어드민 정도 되는 사이트를 관리하던 입장이어서 데이터에 캐시를 둔다는 사실이 너무도 생소했다. 내게 있어 오직 중요한건 대량의 데이터를 insert/select할 때 timeout이 발생하지 않기 위해 불필요한 쿼리 및 join을 줄이는 것 뿐이었으니... 그리고 그걸 질문하는 순간 넌 대체 2년동안 뭘 한거냐며 뒤지게 혼났다 🤦‍♀️oO(모를수도 있지 ㅡㅡ 아는 척 하는 것보다야 낫구만) 이게 내가 캐시를 찾아보게 된 이유다.

그렇다면 캐시 적용을 하는 이유는 무엇인가?

캐시란 무엇인가부터 적기에는 나는 너무 바쁘고, 그런 사소한건 구글을 검색하면 나오기 때문에 간단히 넘어가겠다! 그렇다면 나는 여기서 가장 단편적인 궁금증이 떠올랐다. 왜? 그걸 왜 적용하는데? 사용자 한명이 메인에 접근한다고 생각해보자. 쇼핑몰의 특성상 메인에서 조회되어 불러올 데이터들(상품들)이 있을거다. 뭐, 기획전이나 메인배너, 신규상품, 인기상품, 기획전 상품등등등. 사용자 한명이 들어올 때마다 select 쿼리가 대략 5번씩 실행된다고 가정해보자. 그렇다면 그 한명이 새로고침을 10번 하면 50번의 쿼리가 날라가고, 100번한다면 500번, 1000번이면 5000번의 동일한 쿼리가 DB를 거쳐 웹페이지에 뿌려지게 된다. 상품의 경우를 생각해보면 상품은 보통 하루에 한번씩 데이터가 필요할 때마다 update 되게 되어진다. 10분을 주기로 생각해볼때 10분안에 1000개의 상품이 모두 변경될 가능성이 있을까? 물론 아예 없다고 할 수는 없지만 그런 경우는 사이트를 오픈한다던가 하는 매우 특수한 경우일 것이다. 그렇다면 이 5개의 select 쿼리를 사용자가 들어올 때마다 매 초, 날라간다는 건 사이트에 부하가 걸리기 좋은 상황이라고 볼 수 있다. 이런 상황에서 데이터를 캐시 잡아 사용자가 들어올 때 캐시에 저장된 데이터를 뿌려주고, 설정한 시간마다 캐시를 갱신하는 방식을 사용하게 되는 것이다. 한마디로 말하자면 사이트의 부하를 최소화하기 위한 방식이다.

사이트 부하 방지? 오케 좋았어! 그러면 구현은?

그래 그래 이 정도면 캐시를 사용하는 이유도 알았고 부하 관련해서 매우 중요한 역할을 하는 것도 알았다. 그렇다면 구현은? spring을 사용하는 프로젝트에서 해당 캐시 구현 및 적용은 어떤 방식으로 하게 되는 걸까?

메인 클래스에 아래와같이 선언 되어 있으면 캐시를 사용한다는 뜻 @EnableCaching @Cacheable ehcache.xml을 작성해서 캐시..어쩌구 아무튼 그걸 설정을 해줘야 한대 이거에 대해서 좀 찾아보는게 좋겠어 !