PoroGramr's Log

출석관리체계에 AI 에이전트 구축하기 - 1

PoroGramr — Fri, 27 Feb 2026 10:19:23 +0900

이전에 작성했던 계획을 바탕으로 간단한 에이전트를 구현해보았다.

전체적인 구조는 위와 같다

작동 방식 (6단계)

사용자 질문 수신 - POST /api/ai/chat 엔드포인트로 질문 전송
의도 파악 - Gemini API로 질문 분석, 6가지 의도 분류, JSON으로 파라미터 추출
데이터 검색 - Switch Expression으로 라우팅, MySQL에서 실제 출석 데이터 조회
데이터 포맷팅 - 엔티티를 텍스트로 변환 (목록형/통계형)
자연어 답변 생성 - Gemini API로 친절한 답변 생성

총 2번의 GEMINI API 호출이 필요하다.

이러한 방식을 채택한 이유

1. 간단한 질문만 가능하게끔 하고 싶었다.

2. AI가 직접적으로 쿼리에 접근하는 것은 위험하다고 판단되었다,

하지만 결국 6가지 의도로 분류된 질문만 답변이 가능했기에

완전한 AI 에이전트라고 할수는 없었다.

결국 내가 원하는 에이전트는

모든 출석 데이터 관련 모든 질문에 답변 가능한 에이전트가 필요했다.

그렇게 고민을 하던 중

DB에 직접 접근 하지않고 간접적으로 접근하는 방식을 고안해냈다

Lang Chain을 적용하기 위해 FASTAPI 로 프레임워크를 변경하고

DB는 필요한 테이블만 SQLite로 추출하는 방식으로 진행하였다.

자연어 질문을 받아

랭체인을 통해 적절한 쿼리를 생성한뒤

필요한 데이터만 있는 SQLITE에서 데이터 추출 후

응답하는 구조이다

만약 랭체인을 적용하지 않았다면

1. Gemini에게 "어떤 SQL 써야 해?" 물어보기

2. SQL 받아서 SQLite에 실행하기

3. 결과를 다시 Gemini에게 넘기기

4. "이걸로 충분해?" 판단하기

5. 부족하면 2번으로 다시 돌아가기

6. 최종 답변 생성하기

LangChain 쓰면

python create_sql_agent(llm, db=db)

이 한 줄로 다 가능해진다.

이러한 구조로 변경 후 출석 관련 모든 질문에 대해 답변이 가능한 에이전트를 간단하게 개발하였다.

https://github.com/PoroGramr/PW3_AiAgent

GitHub - PoroGramr/PW3_AiAgent

Contribute to PoroGramr/PW3_AiAgent development by creating an account on GitHub.

github.com

프롬프트나 소스코드가 궁금한 자는 여기로..

추후에는 MCP나 vector db를 적용해 좀 더 고도화 해보고자 한다.

이런 AI 에이전트에 관심이 있는 분은

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=372710393

요즘 당근 AI 개발 | 당근 팀

AI로 과연 될까?라는 질문은 AI로 어떻게 하면 될까?라는 고민으로 이어졌다. 엔지니어, 프로덕트 매니저, 운영 매니저, 누구든 문제의 중심에서 AI를 도구로 삼아 새로운 길을 만들어갔다. 이 책

www.aladin.co.kr

이 책 추천합니다.

재밌어서 하루만에 다 읽음

AWS에 의존했다가 2달동안 10만원 써버린 건에 대하여..

PoroGramr — Tue, 3 Feb 2026 16:26:28 +0900

요즘 블로그에 올라오는 출석관리체계 서비스

원래는 홈서버에 배포해서 운영하다가

새해를 맞이해 클라우드로 옮겨야겠다는 생각이 들었다.

왜냐?

작년에 아파트가 한번 점검으로 인해 정전된 적이 있었다.

우리집의 네트워크 구조는

이런 구조로 구성되어 있다.

포트포워딩을 통해 홈서버로 요청이 들어가 응답이 오는 구조였는데

정전 이후 DHCP로 홈서버의 IP가 변경되면서

서버는 살아있지만 외부에서 접속할 수 없는 상황이 발생한것이다..

하필 이 당시에 나는 제주도에 있었고,,

네트워크 설정을 건드릴 수 없는 상황에 놓인것이다.

이 때 나중을 위해서라도 클라우드로 전환이 필요하다고 생각이 들었다.

그렇게 새해부터는 클라우드 비용을 지원받을 수 있게 되어서

aws로의 전환을 시도했다.

1차 전환기

일단 도메인은 가비아를 통해 구매했다.

1년치 3,300원

AWS에서 사용한 서비스 들은 다음과 같다.

EC2 - T3 micro

VPC

RDS

Route 53

ELB

클라우드 서버, DB, HTTPS 적용을 위한 서비스..

들만 사용했다..

그렇게 1달 뒤..

예?

미친 환율덕에 63542원 이라는 미친 금액이 발생했다.

2차 전환기

아무리 금액을 지원받을 수 있다고 해도

매달 63,000원

1년에 756,000이라는 돈을 청구할 수는 없다..

그렇게

RDS

Route 53

ELB

는 바로 제거했다.

RDS는 cafe24 뉴아우토반 호스팅 DB로 변경

원래는 간단한 서비스 배포용 호스팅 서비스 이지만

나는 DB용으로 사용한다.

월 450원의 저렴한 가격...

또한 HTTPS는 route53과 ELB를 사용하는게 아닌

클라우드 서버에서 nginx + certBot을 적용해 HTTPS로 전환 작업을 진행했다..

그렇게 한달이 지나고 다음 요금을 확인해보니..

19달러요?,,,..

아니 그래도 T3 micro 제일 작은거 썼는데..

미친 환율

결국 이거도 아니라고 판단했다.

너무 비싸다.

다른 방식을 찾아내야겠다고 다짐했다.

3차 전환기

aws를 사용하기엔 너무 비싸다 판단 다른 저렴한 클라우드를 찾아냈다.

해외 서비스가 아닌 국내서비스로..

달러가 너무 비싸니까..

그렇게 찾아낸 저렴한 서버

iwinv

일단 접속자가 많지 않기에 가장 저렴한 서버 vgna_1_n을 선택했다.

무려 월 5,600원

저장소도 25gb이기에

1gb의 적은 메모리에 스왑 메모리 2gb 변경하면 꽤 쓸만할거란 생각이 들었다.

그렇게 aws 서비스는 모두 해지하고..

가비아(도메인) + cafe24(db) + iwinv(서버)

을 통해 월 약 6,300원으로 운영비를 절약했다..

무려 63,000원에서 6,300원으로

10%로 절약했다.

다들 나처럼 폭탄맞지 말고..

저렴한 서비스를 찾아보도록 하자..

certbot + nginx로 https 적용하기

PoroGramr — Mon, 2 Feb 2026 13:52:50 +0900

하도 자주 반복해서 기록용으로 남겨둔다.

도메인은 구입해야한다.

Client
↓ https
nginx (host, 443)
↓ proxy_pass
Spring Boot (Docker, 8080)

전체적인 구조

1. 도메인 dns a 레코드 등록 확인

dig api.domain.xyz

해당 명령어를 통해 구입한 도메인에 a 레코드가 제대로 등록되었는지 확인한다.

새로 구입한 도메인에 경우 운 없으면 1시간이상 걸린다.

(내가 그랬다.)

2. nginx 설치 ( 호스트)

sudo apt update sudo apt install -y nginx

상태 확인:
sudo systemctl status nginx

3. nginx 기본 프록시 설정

sudo vi /etc/nginx/sites-enabled/default

아마 기본 설정들이 입력되있을 텐데

하면 다 지워진다.

server {
    listen 80;
    server_name api.domain.xyz;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

적용

sudo nginx -t
sudo systemctl reload nginx

테스트

curl http://localhost:8080/swagger-ui/index.html
curl http://api.domain.xyz/swagger-ui/index.html

둘 다 HTML 나오면 다음 단계로 진행

4. certbot 설치

sudo apt install -y certbot python3-certbot-nginx

5. HTTPS 인증서 발급

sudo certbot --nginx -d api.pw3hub.xyz

이메일 → 아무거나
약관 → Y
HTTP → HTTPS 리다이렉트 → Y

6. Spring Boot 설정 추가

server:
  forward-headers-strategy: framework

출석관리체계에 AI 에이전트 구축하기 - 0

PoroGramr — Sat, 27 Dec 2025 23:32:10 +0900

교회에서 중고등부 교사를 하면서 비효율적으로 출석 체크를 하는 현상을 확인했다...

매주 학생 리스트에 엑셀로 1,0 을 입력하며 출석을 하고 있던 것이였다..

그래서 간단하게 AI로 프론트 개발하고

백엔드는 직접 개발하며 출석관리체계를 만들어 1년간 사용했다.

부끄러운 프론트

그냥 간단하게 출석, 지각, 결석 여부를 체크하는 방식이다.

뭐 숨겨진 여러 기능이 있긴하다만..

2026년이 되면서 2.0으로 업그레이드 할 겸

지금까지 쌓은 출석 데이터를 바탕으로 AI 에이전트를 만들어보고자 한다.

"이번 달 출석 위험 학생 알려줘”

“지각이 잦은 순서로 10명 보여줘”

“지난 학기 대비 출석 개선된 학생은?”

“이번 달 한 번도 안 나온 아이들 알려줘”

“3주 연속 결석한 학생 있어?”

이런식의 자연어 질문을 AI가 해석하고 응답하게끔 하는 것이 목표다.

먼저 우리 시스템이 어떻게 사용자의 질문을 이해하고 답변하는지 큰 그림은 다음과 같다.

1. 사용자: "김민준 학생 결석 몇 번 했어?" 라고 질문을 던지면

2. 백엔드 서버 (우리의 Spring Boot 앱): 이 질문을 받아서 처리한다

3. LLM (AI 언어 모델): 백엔드 서버가 자연어 질문을 이해하고 답변을 생성할 수 있도록 도와주는 두뇌 역할을 한다. (예: OpenAI의 GPT, Google의 Gemini)

4. 데이터베이스 (우리의 MySQL DB): 실제 출석 데이터가 저장된 곳

핵심은 "LLM이 우리 데이터베이스 내용을 어떻게 알까?" 이다.

LLM은 세상의 일반적인 지식은 알아도, 우리가 쌓은 '출석 데이터'는 전혀 모르기 때문이다.

이 문제를 해결하는 기술이 바로 RAG (Retrieval-Augmented Generation, 검색 증강 생성) 이다.

핵심 기술: RAG 쉽게 이해하기

RAG는 3단계로 이루어진다. "민우 학생 결석 몇 번 했어?" 라는 질문을 예시로 설명하자면

1. Retrieval (검색):

* AI가 먼저 "아, 이건 '특정 학생의 결석 횟수'를 묻는 거구나!" 라고 질문의 의도를 파악하고

* 그 다음, 이 의도에 맞춰 우리 데이터베이스에서 실제 정보를 검색한다.

* SELECT COUNT(*) FROM attendance WHERE student_name = '민우' AND status = 'ABSENT'; 와 같은 쿼리를 실행해서 "민우, 결석, 5회" 라는 데이터를 찾아낸다.

2. Augmentation (정보 보강):

* 이제 LLM에게 보낼 질문지(프롬프트)에, 우리가 데이터베이스에서 찾아낸 정보를 추가(보강)한다.

> [LLM에게 보낼 프롬프트 예시]

> 너는 친절한 출석 관리 조교야. 아래 "정보"를 바탕으로 "질문"에 대답해줘

> # 정보:

> * 학생 이름: 민우

> * 결석 횟수: 5회

> # 질문:

> 민우 학생 결석 몇 번 했어?

3. Generation (답변 생성):

* 이렇게 정보가 보강된 프롬프트를 LLM API에 전달한다.

* LLM은 주어진 정보를 보고 아주 자연스러운 문장으로 답변을 생성하고

* "네, 민우 학생은 총 5번 결석했습니다." 와 같은 답변이 만들어지고, 우리는 이걸 사용자에게 보여주면 된다.

AI 에이전트 구축 과정 (총 4단계)

1단계: 기능 정의 및 DB 쿼리 메서드 구현

AI가 답변할 수 있는 질문의 종류를 명확하게 정의하는 것이 가장 중요하다. 이 단계가 잘 되어야 뒤따르는 개발이 수월해진다.

// 예시: AttendanceService.java 에 추가될 메서드들
public int getAbsenceCountForStudent(String studentName) {
    // ... JPA Repository를 호출하여 결석 횟수 조회 로직
}

public List<Student> findStudentsWithExcessiveLateness(int count, LocalDate startDate, LocalDate endDate) {
     // ... 지각 3회 이상 학생 목록 조회 로직
}

AI의 도움을 받아 답변을 구할 질문 5가지를 선정했다.

AI 에이전트가 답변할 핵심 질문 5가지

---

1. 장기 결석자 찾기

* 사용자 질문: "이번 달 한 번도 안 나온 아이들 알려줘"

* AI의 해석 (의도): LIST_FULL_ABSENCE_STUDENTS

* 필요한 정보:

* 기간: "이번 달" (예: 2025-12-01 ~ 2025-12-31)

* 구현 방향:

1. 해당 기간의 모든 출석/지각 기록을 조회합니다.

2. 전체 학생 명단에서, 위 출석 기록에 한 번도 등장하지 않은 학생을 찾아냅니다.

3. 찾아낸 학생들의 명단을 반환합니다.

* 선정 이유: 가장 기본적이고 필수적인 기능입니다. '관리의 시작'이라고 할 수 있는 질문이라 활용도가 높습니다.

---

2. 연속 결석 패턴 감지

* 사용자 질문: "3주 연속 결석한 학생 있어?"

* AI의 해석 (의도): FIND_CONSECUTIVE_ABSENCE_STUDENTS

* 필요한 정보:

* 주(Week) 수: 3

* 구현 방향:

1. 최근 3주간의 날짜 범위를 계산합니다. (예: 3주 전 일요일 ~ 지난주 토요일)

2. 각 주(Week)마다 결석한 학생들을 각각 조회합니다.

3. 3주 모두 결석 명단에 포함된 학생을 찾아냅니다.

* 선정 이유: 단순 조회가 아닌 '패턴'을 분석하는 질문입니다. 기술적으로 한 단계 더 깊이가 있어, 개발자의 문제 해결 능력을 보여주기 좋은 예시입니다.

---

3. 신입생 정착 현황 파악

* 사용자 질문: "신입인데 2주 연속 나온 학생"

* AI의 해석 (의도): FIND_NEW_CONSECUTIVE_ATTENDEES

* 필요한 정보:

* 신입생 기준: "최근 3개월 내 등록"

* 연속 출석 주(Week) 수: 2

* 구현 방향:

1. 먼저 '신입생' 그룹을 정의하고, 최근 3개월 내 등록한 학생 목록을 조회합니다.

2. 이 학생들을 대상으로, '2번 질문'과 유사하게 최근 2주간 연속으로 출석했는지 패턴을 분석합니다.

* 선정 이유: 학생 정보(신입생 여부)와 출석 정보를 결합해야 하는 질문입니다. 여러 도메인의 데이터를 조합하는 능력을 보여줄 수 있습니다.

---

4. 학년별 데이터 요약 및 비교

* 사용자 질문: "학년별 평균 출석률 보여줘"

* AI의 해석 (의도): GET_AVERAGE_ATTENDANCE_RATE_BY_GRADE

* 필요한 정보:

* 기간: "이번 학기" 또는 "이번 달"

* 구현 방향:

1. 해당 기간 동안 각 학년의 전체 학생 수와 실제 출석 수를 각각 계산합니다. (데이터베이스의 GROUP BY 기능 활용)

2. (실제 출석 수 / 전체 학생 수) * 100 공식을 사용하여 학년별 평균 출석률을 계산합니다.

* 선정 이유: 개별 학생 조회가 아닌, 데이터를 집계하고 통계를 내는 능력을 보여줍니다. 백엔드 개발자의 중요한 역량 중 하나입니다.

---

5. 복합 조건 분석 및 요약 (AI의 강점)

* 사용자 질문: "이번 분기 관리가 필요한 학생 요약해줘"

* AI의 해석 (의도): SUMMARIZE_STUDENTS_NEEDING_CARE

* 필요한 정보:

* '관리가 필요한'의 정의: (예시) "결석 2회 이상" 또는 "지각 3회 이상" (이 기준은 우리가 직접 정해야 합니다)

* 기간: "이번 분기"

* 구현 방향:

1. 해당 분기 동안, 결석 횟수가 2회 이상인 학생 목록을 조회합니다.

2. 지각 횟수가 3회 이상인 학생 목록도 조회합니다.

3. 두 목록을 합친 후 중복을 제거하여 최종 "관리가 필요한 학생" 목록을 만듭니다.

* 선정 이유: "관리가 필요하다"는 다소 추상적인 질문을 명확한 데이터 기준으로 정의하고, 여러 조건을 조합하여 해결하는 과정을 보여줍니다. AI 에이전트의 가장 큰 가치를 보여줄 수 있는 질문입니다.

---

* DB 쿼리 메서드 구현:

* 위에서 정의한 각 질문 유형에 맞춰, AttendanceService 또는 새로 만들 AIService에 데이터를 조회하는 메서드를 미리 만들어둔다. JPA Repository에 필요한 쿼리 메서드를 추가해야 한다.

2단계: LLM 연동 및 프롬프트 엔지니어링

Java에서 LLM을 쉽게 사용하도록 도와주는 Spring AI 프로젝트를 활용하는 것을 추천한다.

   * 의존성 추가 (`build.gradle`):

// Spring AI는 아직 정식 버전이 아닐 수 있어, repository 추가가 필요할 수 있습니다.
repositories {
   maven { url 'https://repo.spring.io/milestone' }
}
dependencies {
    implementation 'org.springframework.ai:spring-ai-openai-spring-boot-starter:1.0.0-M1' // OpenAI 연동용
}

   * API 키 설정 (`application.yml`):
spring:
	ai:
		openai:
			api-key: ${OPENAI_API_KEY} // GitHub Secret 또는 환경 변수로 관리

* 프롬프트 작성 및 API 호출:

* 1단계에서 만든 서비스 메서드를 호출하여 얻은 데이터와 사용자의 질문을 조합하여 LLM에게 보낼 프롬프트를 만든다.

     // 예시: AIService.java
     @Service
     @RequiredArgsConstructor
     public class AiChatService {
 
 		 private final OpenAiChatClient chatClient; // Spring AI가 제공
         private final AttendanceService attendanceService;
 
         public String getAttendanceAnswer(String userQuestion) {
             // TODO: 사용자의 질문 의도 파악 (초기에는 '학생 결석 횟수' 질문만 처리한다고 가정)
 
             // 1. 데이터베이스에서 정보 검색 (Retrieval)
             int absenceCount = attendanceService.getAbsenceCountForStudent("민우"); // 이름은 질문에서 파싱해야 함
 
             // 2. 프롬프트 생성 (Augmentation)
             String promptTemplate = """
                 너는 친절한 출석 관리 조교야.
                 주어진 정보를 바탕으로 사용자의 질문에 한국어로 대답해줘.
 
                 # 정보:
                 - 학생 이름: 민우
                 - 결석 횟수: {count}회
 
                 # 질문:
                 {question}
                 """;
             Prompt prompt = new PromptTemplate(promptTemplate)
                 .create(Map.of("count", absenceCount, "question", userQuestion));
 
             // 3. LLM API 호출 및 답변 생성 (Generation)
             ChatResponse response = chatClient.call(prompt);
             return response.getResult().getOutput().getContent();
         }
     }

3단계: API 엔드포인트 생성

사용자의 자연어 질문을 받고 답변을 반환하는 API를 만든다

* 컨트롤러 생성 (`AiController.java`):

     @RestController
     @RequestMapping("/api/ai")
     @RequiredArgsConstructor
     public class AiController {
 
         private final AiChatService aiChatService;
 
         @PostMapping("/chat")
         public ResponseEntity<String> chatWithAgent(@RequestBody String question) {
             String answer = aiChatService.getAttendanceAnswer(question);
             return ResponseEntity.ok(answer);
         }
     }

4단계: 간단한 UI 구현

RPS 30.19에서 42.4로: 부하테스트를 바탕으로 한 쿼리 튜닝,인덱싱과 JVM 튜닝을 통한 추천 API 성능 개선기

PoroGramr — Sat, 29 Nov 2025 17:23:16 +0900

요약 (Summary)
'동네한끼' 프로젝트의 핵심 기능인 개인화 추천 API의 부하테스트를 진행하며
응답 속도가 평균 26초에 달하는 심각한 성능 저하를 확인했습니다.
이를 해결하기 위해 로직 수정, DB 커넥션 풀 조정, 쿼리 리팩토링, 인덱스 적용, JVM 튜닝의 4단계를 거쳤습니다.
그 결과, RPS는 증가(30.19→ 42.4)하고, 응답 속도는 단축(1656ms → 1100ms)하는 성과를 얻었습니다.

1. 배경 및 문제 상황 (Background & Problem)

프로젝트 리팩토링 과정에서 메인 페이지의 '사용자 맞춤 추천 게시글 조회 API'를 점검하던 중, 예상보다 훨씬 심각한 성능 지연을 발견했습니다.

해당 API는 로그인한 사용자의 활동(좋아요, 조회 등)을 분석해 관심사를 파악하고, 이에 맞는 게시글을 추천하는 복합적인 로직을 가지고 있습니다.

1-1. 로직 흐름

User Context: 현재 접속한 사용자가 좋아요를 누른 게시글 목록 조회
Tag Analysis: 해당 게시글들의 해시태그를 분석하여 상위 태그 추출
Hybrid Recommendation:
- 추출된 태그 기반의 게시글 조회 (Personalized)
- 부족한 수량만큼 인기 게시글(좋아요/최신순) 조회 (Popularity)
- 두 리스트 병합 및 중복 제거 후 반환

1-2. 성능 측정 (Baseline)

Apache Bench(ab)를 사용하여 부하 테스트를 진행했습니다.

테스트 데이터는 10,000개를 넣고 진행하였습니다.

Total Requests: 500
Concurrency: 50

Metric	결과값
RPS (Throughput)	30.19 [#/sec]
Time per request	1656[ms]

Apache Bench 는 부하테스트에 사용하는 간단한 툴로서

짧은 시간 동안, 정해진 횟수/동시 접속 수로 HTTP 요청을 보내고, 응답 속도와 처리량을 측정해주는 도구입니다.

간단하게 작동중인 서버에 아래와 같이 요청을 보내면 부하테스트 결과를 확인할 수 있습니다.

ab -n 100 -c 10 http://localhost:8080/

-n 100 : 총 100번 요청 보내라 (requests)

-c 10 : 동시에 10명씩 붙는 것처럼(concurrent) 요청 보내라

뒤 URL : 벤치마크할 주소

아래는 실제 요청을 보내고 결과를 응답받은 예시입니다.

초당 처리 요청 수(Throughput, Requests per second)
평균 응답 시간 / 최솟값 / 최댓값
퍼센타일(50%, 90%, 95%, 99% 지점 응답 시간)
전송된 데이터량, 에러 수

를 확인 할 수 있습니다.

 ab -n 500 -c 50 \
        -H 'accept: */*' \
        -H 'Authorization: Bearer (Access Token)' \
         'https://dh.porogramr.site/api/posts/recommendPosts?limit=10'
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking dh.porogramr.site (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests


Server Software:        
Server Hostname:        dh.porogramr.site
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,4096,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        dh.porogramr.site

Document Path:          /api/posts/recommendPosts?limit=10
Document Length:        8636 bytes

Concurrency Level:      50
Time taken for tests:   79.725 seconds
Complete requests:      500
Failed requests:        499
   (Connect: 0, Receive: 0, Length: 499, Exceptions: 0)
Total transferred:      4523637 bytes
HTML transferred:       4394637 bytes
Requests per second:    6.27 [#/sec] (mean)
Time per request:       7972.543 [ms] (mean)
Time per request:       159.451 [ms] (mean, across all concurrent requests)
Transfer rate:          55.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       77  270 366.9    135    3122
Processing:   687 7319 3109.6   7163   19024
Waiting:      681 7305 3106.0   7148   18875
Total:        793 7588 3100.8   7368   20089

Percentage of the requests served within a certain time (ms)
  50%   7368
  66%   8255
  75%   9444
  80%  10052
  90%  11284
  95%  13551
  98%  16034
  99%  17632
 100%  20089 (longest request)

2. 가설 및 검증 과정 (Troubleshooting)

Phase 1. DB 커넥션 풀(HikariCP)이 원인일까?

초기 로그 분석 결과, DB 커넥션을 획득하기 위해 스레드들이 대기하는 현상이 관측되었습니다. HikariCP의 기본 설정(Size=10)이 동시 요청 50개를 처리하기엔 턱없이 부족하다고 판단했습니다.

기본 설정 값인 10개의 커넥션이 모두 사용되고 있음을 확인할 수 있었습니다.

Action:

maximum-pool-size를 10개에서 30개로 증설했습니다.

Result:

커넥션 풀을 증가시키고 Apache Bench(ab)를 사용하여 동일한 부하테스트를 진행하였습니다.

Connection Time: 954ms → 317ms (대기 시간 감소)
Processing Time: 639ms → 1435ms (처리 시간 2배 증가)
RPS: 30.19 → 27.58 (오히려 성능 하락)

커넥션 풀을 늘리자 대기하던 요청들이 한꺼번에 DB로 유입되었습니다. 하지만 DB가 이를 처리하지 못해 Processing Time이 오히려 급증했습니다.
이는 "커넥션 부족은 현상일 뿐, 근본 원인은 쿼리 처리 속도(Slow Query)에 있다"는 것을 확인할 수 있었습니다.

병목 지점은 WAS가 아닌 Database 자체였습니다.

Phase 2. 쿼리 분석 및 인덱스 튜닝 (Core Solution)

DB 처리가 느린 원인을 찾기 위해 쿼리 실행 계획(Explain)과 Hibernate 로그를 분석했습니다.

두 가지 치명적인 문제가 발견되었습니다.

2-1. 비효율적인 정렬 로직 (Filesort)

기존 코드는 Post와 PostLike를 조인한 뒤, COUNT()를 사용하여 실시간으로 좋아요 개수를 세고 정렬했습니다.

[Before]

// GROUP BY와 집계 함수 사용으로 인한 성능 저하
@Query("SELECT p.postId FROM Post p LEFT JOIN p.postLikes pl GROUP BY p.postId ORDER BY COUNT(pl.id) DESC")

이 쿼리는 매 요청마다 Using temporary; Using filesort를 유발하여 디스크 I/O를 폭증시켰습니다.

[After] 반정규화 및 쿼리 단순화

Post 엔티티에 likeCount 컬럼을 추가하여 반정규화를 진행했습니다. 조회 시에는 조인 없이 단일 테이블 조회로 변경했습니다.

// 이미 집계된 컬럼을 사용하여 정렬 단순화
@Query("SELECT p.postId FROM Post p ORDER BY p.likeCount DESC, p.createdAt DESC")

2-2. 인덱스(Index) 부재

단순화된 쿼리라도 데이터가 많아지면 Full Table Scan이 발생합니다. EXPLAIN 확인 결과, 정렬 조건(likeCount, createdAt)에 대한 인덱스가 없어 비효율적인 스캔이 발생하고 있었습니다.

Action:
복합 인덱스를 적용하여 정렬 연산(Sorting)을 인덱스 스캔으로 대체했습니다.

1.인기 게시물 조회를 위한 인덱스 (likeCount + createdAt)
CREATE INDEX idx_post_like_count ON post (like_count DESC, created_at DESC);
    
2. 최신 게시물 조회를 위한 인덱스 (createdAt)
CREATE INDEX idx_post_created_at ON post (created_at DESC);
   
3. 사용자가 좋아한 게시물 기반 추천을 위한 인덱스
CREATE INDEX idx_post_like_user_id ON post_like (user_id);

인덱싱 적용전

인덱싱 적용 후

- 다들 Type이 index로 변경된 점을 확인할 수 있다.

Phase 3. JVM 및 GC 튜닝 (Optimization)

DB 튜닝 후 RPS는 개선되었으나, 간헐적으로 응답이 튀는 현상(Tail Latency)이 있었습니다. 프로파일링 결과 GC(Garbage Collection) 수행 시 Stop-the-world가 길게 발생하는 것을 확인했습니다.

현상:

Docker 컨테이너 환경에서 메모리 제한 설정 미비로 Host OS의 메모리를 잘못 인식
Heap 영역 부족으로 빈번한 GC 발생 (Pause Time: ~3.47s)

Action:

메모리 가시성 확보: -Xms1536, -Xmx1536m 설정으로 컨테이너 메모리 제한 인식
GC 알고리즘 변경: Latency에 유리한 ZGC (-XX:+UseZGC) 적용 테스트

DockerFile에서 메모리 옵션, GC 튜닝 옵션 추가

GithubAction workflow 에서 메모리 제한 옵션 추가

Result:

튜닝 이후에는 부하테스트를 진행해도 GC Stop the World가 발생하지 않음

DB 튜닝으로 객체의 생존 주기가 짧아지면서 이미 G1GC로도 충분히 안정적인 상태가 되었지만, 메모리 설정을 명확히 함으로써 시스템 안정성을 확보했습니다. 최종적으로 GC로 인한 중단 시간은 0초에 수렴했습니다.

3. 최종 결과

세 단계의 튜닝을 거친 후의 성능 변화 그래프입니다.

단계	RPS (req/sec)	Time per request (ms)	비고
Baseline	30.19	1,656	초기 상태
1. Pool 증설	27.58	1,812	커넥션 대기 해소, DB 부하 증가
2. 쿼리/인덱스	42.42	1,178	Slow Query 해결 (Key Factor)

Lessons Learned

병목의 위치를 정확히 파악하라:
단순히 Connection Timeout 로그만 보고 Pool Size를 늘리는 것은 미봉책에 불과했습니다. Wait Time과 Processing Time을 구분하여 분석함으로써 진짜 문제(Slow Query)를 찾을 수 있었습니다.
RDB에서 인덱스는 선택이 아닌 필수다:
복잡한 비즈니스 로직을 코드로 풀기보다, DB 레벨에서 인덱스를 잘 타도록 쿼리를 설계하는 것이 성능에 훨씬 지대한 영향을 미칩니다.
데이터 기반의 의사결정:
ab 테스트와 프로파일링 도구의 수치를 근거로 튜닝 전후를 명확히 비교할 수 있었습니다.

참고: 본 포스팅의 테스트는 로컬 Docker 환경에서 진행되었으며, 실제 운영 환경과는 차이가 있을 수 있습니다.

Audit Log 조회 API 성능 개선기 - 3

PoroGramr — Fri, 8 Aug 2025 18:37:57 +0900

auditLog는 기록도 기록이지만 조회가 가장 중요한 API이다.

조회 성능을 개선하기 위해 어떤 방식이 있을가 고민하던 중 인덱싱을 적용하기로 했다.

인덱싱은 커서 기반 페이징에서 커서 키로 사용하는

CREATE INDEX idx_auditlog_loggedat_id
  ON audit_log (logged_at DESC, id DESC);

logged_at , id 에 인덱싱을 걸었다.

인덱싱 적용 후 이전과 동일하게 마지막 페이지를 조회했더니

2025-08-08 18:35:58.215 [https-jsse-nio-443-exec-9]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ LogsWithCursor com.welcommu.moduleservice.logging.AuditLogSearchServiceImpl.searchLogs(ActionType,TargetType,String,String,Long,LocalDateTime,Long,int) executed in 23 ms
2025-08-08 18:35:58.216 [https-jsse-nio-443-exec-9]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ ResponseEntity com.welcommu.moduleapi.logging.AuditLogController.search(ActionType,TargetType,String,String,Long,LocalDateTime,Long,int) executed in 24 ms

23ms가 나온다..

너무 극단적이라 당황스럽다..

Audit Log 조회 API 성능 개선기 - 2

PoroGramr — Fri, 8 Aug 2025 18:17:34 +0900

이전 게시글에서 AuditLog의 N + 1 문제를 해결하여 성능을 개선하였다.

하지만 10,000건의 데이터는 너무 적다.

여러 조언을 구해본결과 1000만건은 해야 유의미한 결과를 얻을 수 있다는 판단이 들었다.

그렇게 해서 데이터 1000만건 삽입!

audlitLog는 1000만건

INSERT INTO vivim.audit_log (actor_id, target_type, target_id, action_type, logged_at)
WITH RECURSIVE numbers AS (
SELECT 1 AS n
         UNION ALL
         SELECT n + 1 FROM numbers WHERE n < 10000000 -- 1000만 건
     )
     SELECT
         FLOOR(1 + RAND() * 100000) AS actor_id, -- 1부터 100000 사이의 랜덤 actor_id
         ELT(FLOOR(1 + RAND() * 5), 'PROJECT', 'POST', 'COMMENT', 'USER', 'COMPANY') AS target_type, -- 예시 TargetType 값
        FLOOR(1 + RAND() * 1000000) AS target_id, -- 1부터 1000000 사이의 랜덤 target_id
        ELT(FLOOR(1 + RAND() * 3), 'CREATE', 'MODIFY', 'DELETE') AS action_type, -- 예시 ActionType 값
        FROM_UNIXTIME(UNIX_TIMESTAMP('2023-01-01 00:00:00') + FLOOR(RAND() * (UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP('2023-01-01 00:00:00')))) AS logged_at -- 2023년 1월 1일부터 현재까지의 랜덤 시간
    FROM
        numbers;

audlitLogDetail는 200만건 삽입하였다.

INSERT INTO vivim.audit_log_detail (audit_log_id, field_name, old_value, new_value)
        SELECT
            al.id,
            CONCAT('field_', FLOOR(1 + RAND() * 10)),
            CONCAT('old_value_', FLOOR(1 + RAND() * 100)),
            CONCAT('new_value_', FLOOR(1 + RAND() * 100))
        FROM
            vivim.audit_log al
        WHERE
            RAND() < 0.2;

근데 문제가 발생했다.

10000건일땐 아무런 문제 없던 API가

2025-08-08 16:51:07.248 [https-jsse-nio-443-exec-9] ERROR org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception   │
│    [Request processing failed: java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space] with root cause                                                                                                                        │
│    java.lang.OutOfMemoryError: Java heap space

데이터가 1000만건이 되니 out of memory가 발생하는 것이였다..

OutOfMemoryError: Java heap space 오류는 애플리케이션이 너무 많은 데이터를 한 번에 메모리에 로드하려고 할 때 발생한다.

특히 HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory 경고는 AuditLog 엔티티를

조회하면서 AuditLogDetail과 같은 컬렉션(@OneToMany 관계)을 함께 가져올 때, Hibernate가 페이징을 메모리에서 처리하기 위해 모든 관련 데이터를 먼저 로드하기 때문에 발생한다고 한다.

1000만 건의 데이터에서는 이 방식이 메모리 부족이 발생했던 것이다..

이러한 문제를 해결하기위해 기존 커스텀쿼리에 추가한 fetch join을 제거하고

AuditLog.java에 @BatchSize를 추가하였다.

AuditLog 엔티티의 details 필드에 @BatchSize(size = N) 어노테이션을 추가하여, Hibernate가 AuditLogDetail을 가져올 때 N개의 AuditLog에 대한 상세 정보를 한 번에 가져오도록 하였다.

1. JOIN FETCH와 OutOfMemoryError의 원인

JOIN FETCH는 N+1 쿼리 문제를 해결하기 위해 매우 유용한 기능입니다. AuditLog와 AuditLogDetail의 경우, JOIN FETCH a.details를 사용하면 AuditLog를 조회할 때 연관된 모든 AuditLogDetail도 한 번의 SQL 쿼리로 함께 가져옵니다.

문제점 (페이징과 함께 사용될 때):

* 카테시안 곱 (Cartesian Product): AuditLog 하나에 여러 개의 AuditLogDetail이 있을 수 있습니다. JOIN FETCH를 사용하면 데이터베이스에서 AuditLog 레코드 수 * AuditLogDetail 레코드 수 만큼의 결과 행이 생성될 수 있습니다 (정확히는 DISTINCT

키워드를 사용하더라도 내부적으로는 더 많은 행이 생성될 수 있습니다).

* Hibernate의 메모리 내 페이징: 더 중요한 문제는 Hibernate가 OneToMany 관계를 FETCH JOIN으로 가져오면서 LIMIT 또는 OFFSET과 같은 페이징을 적용할 때 발생합니다.

* Hibernate는 HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory 경고를 띄우면서, 데이터베이스에서 모든 `AuditLog`와 그에 연결된 모든 `AuditLogDetail`을 먼저 가져온 다음, 애플리케이션 메모리에서

`LIMIT`와 `OFFSET`을 적용합니다.

* 즉, 1000만 건의 AuditLog와 그에 연결된 수천만 건의 AuditLogDetail이 있다면, 이 모든 데이터를 애플리케이션의 JVM 힙 메모리에 한꺼번에 로드하려고 시도합니다.

* 이 과정에서 JVM 힙 메모리가 부족해지면 java.lang.OutOfMemoryError: Java heap space가 발생하게 됩니다.

2. @BatchSize를 통한 해결

@BatchSize는 FETCH JOIN과는 완전히 다른 방식으로 N+1 문제를 해결하고 메모리 효율성을 높입니다.

* 지연 로딩 (Lazy Loading) 기반: @BatchSize는 기본적으로 연관 관계가 지연 로딩(Lazy Loading)으로 설정되어 있을 때 작동합니다. 즉, AuditLog 엔티티를 조회할 때는 AuditLogDetail 컬렉션을 즉시 가져오지 않습니다.

* 별도의 쿼리 실행:

1. 1단계 쿼리 (메인 엔티티): AuditLogRepositoryImpl.findByConditions에서 LEFT JOIN FETCH a.details를 제거했기 때문에, 이제 쿼리는 AuditLog 엔티티만 가져옵니다. 이 쿼리는 데이터베이스에서 LIMIT와 OFFSET을 효율적으로 적용하여 요청된 페이지의

`AuditLog` 레코드만 가져옵니다. 이 과정에서 대량의 데이터가 메모리에 로드되지 않습니다.

2. 2단계 쿼리 (컬렉션 배치 로딩): 애플리케이션 코드에서 가져온 AuditLog 객체들의 getDetails() 메서드를 호출하여 AuditLogDetail 컬렉션에 접근할 때, Hibernate는 @BatchSize(size = 100) 설정에 따라 작동합니다.

* 예를 들어, 한 페이지에 10개의 AuditLog를 가져왔다면, Hibernate는 이 10개의 AuditLog에 해당하는 AuditLogDetail을 한 번의 `IN` 쿼리로 가져옵니다.

* 만약 한 페이지에 100개의 AuditLog를 가져왔다면, Hibernate는 이 100개의 AuditLog에 해당하는 AuditLogDetail을 한 번의 `IN` 쿼리로 가져옵니다.

* 이렇게 하면 N+1 쿼리(각 AuditLog마다 AuditLogDetail을 가져오는 쿼리)를 방지하면서도, 한 번에 메모리에 로드되는 데이터의 양을 FETCH JOIN처럼 전체가 아닌, 현재 페이지의 `AuditLog`에 해당하는 `AuditLogDetail`만으로 제한할 수 있습니다.

요약:

JOIN FETCH는 페이징 쿼리에서 OneToMany 관계를 처리할 때 모든 데이터를 메모리에 로드하여 OutOfMemoryError를 유발했습니다. 반면, JOIN FETCH를 제거하여 메인 엔티티의 페이징을 데이터베이스에 맡기고, @BatchSize를 통해 연관된 컬렉션을 필요할

때마다 효율적인 배치 쿼리로 가져옴으로써, 애플리케이션의 메모리 사용량을 크게 줄여 OutOfMemoryError를 해결할 수 있었습니다.

이제 outOfMemory 문제는 해결했다.

근데 또 하나의 문제가 있다.

오프셋 기반 페이징의 단점은 마지막 페이지로 갈 수록 불필요한 조회가 진행되어 성능이 저하된다는 점이다.

첫번째 페이지 조회의 경우 2898ms의 시간이 소모되지만

2025-08-08 18:09:50.590 [https-jsse-nio-443-exec-1]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ Page com.welcommu.moduleservice.logging.AuditLogSearchService.searchLogs(ActionType,TargetType,String,String,Long,Pageable) executed in 2898 ms
2025-08-08 18:09:50.590 [https-jsse-nio-443-exec-1]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ ResponseEntity com.welcommu.moduleapi.logging.AuditLogController.searchAuditLogs(ActionType,TargetType,String,String,Long,Pageable) executed in 2898 ms

마지막 페이지의 경우 4538ms의 시간이 소모되는 것을 확인할 수 있다.

2025-08-08 18:10:02.860 [https-jsse-nio-443-exec-1]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ Page com.welcommu.moduleservice.logging.AuditLogSearchService.searchLogs(ActionType,TargetType,String,String,Long,Pageable) executed in 4538 ms
2025-08-08 18:10:02.860 [https-jsse-nio-443-exec-1]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ ResponseEntity com.welcommu.moduleapi.logging.AuditLogController.searchAuditLogs(ActionType,TargetType,String,String,Long,Pageable) executed in 4538 ms

이러한 문제는 어떻게 해결하여야 할까?

이 문제에 대한 해답으로 커서기반페이징을 적용하기로 했다.

커서 기반 페이징을 적용하고 마지막 페이지의 응답속도를 체크해보니

2025-08-08 18:27:53.733 [https-jsse-nio-443-exec-9]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ LogsWithCursor com.welcommu.moduleservice.logging.AuditLogSearchServiceImpl.searchLogs(ActionType,TargetType,String,String,Long,LocalDateTime,Long,int) executed in 2309 ms
2025-08-08 18:27:53.734 [https-jsse-nio-443-exec-9]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ ResponseEntity com.welcommu.moduleapi.logging.AuditLogController.search(ActionType,TargetType,String,String,Long,LocalDateTime,Long,int) executed in 2311 ms

2309ms의 시간이 소모되는 것을 확인할 수 있었다.

오프셋 기반 페이징은 100번째페이지를 조회할때 99번쨰 페이지까지 조회를 한 후 폐기한다

그리고 남은 100번쨰 페이지를 리턴한다.

그에 비해 커서 기반 페이징은 필요한 부분부터 조회를 시작해 리턴하기에 이러한 성능 차이를 가져올 수 있었다.

Audit Log 조회 API 성능 개선기 - 1

PoroGramr — Sat, 19 Jul 2025 19:43:57 +0900

들어가며

프로젝트 관리 시스템 프로젝트를 진행하면서

유저, 회사, 프로젝트, 댓글 등 여러 엔티티의 생성, 수정, 삭제 내역을 조회하는 API를 개발해야 했다.

ERD는 위와 같이 구성되어 있었다.

만약 수정의 경우 audit_log_detail을 통해 수정 전과 수정 후 데이터를 저장하고자 했다.

최초 구상시에는 Spring AOP를 활용해 구현하고자 했지만

AOP를 적용하기 위해선 현재 작동하는 비즈니스 로직들을 수정해야하는 상황이 발생해서

결국 AOP를 사용하지 않고 비즈니스 로직에 AuditLog에 데이터를 기록하는 로직을 추가했다.

로직 설명

예시로 프로젝트 생성 로직의 경우

createProjcet -> createAuditLog -> auditLogFactory

식의 의존 방향을 통해 생성 로그가 DB에 저장되는 방식이다.

프로젝트 수정의 경우

간단히 설명하자면

수정전과 수정후 스냅샷 비교를 통해 변경된 데이터를 auditLogDetail 에 저장하는 방식이다.

발생한 문제

해당 로직을 구현하고 10,000개의 데이터를 바탕으로 테스트하는 과정에서

조회 API가 비정상적으로 느린 현상을 발견하였다.

Spring AOP 를 활용해 응답시간을 확인해본 결과

2025-04-25 11:58:29.609 [https-jsse-nio-443-exec-6]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ List com.welcommu.moduleservice.logging.AuditLogSearchService.searchLogs(ActionType,TargetType,String,String,Long) executed in 2812 ms
2025-04-25 11:58:29.609 [https-jsse-nio-443-exec-6]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ ResponseEntity com.welcommu.moduleapi.logging.AuditLogController.searchAuditLogs(ActionType,TargetType,String,String,Long) executed in 2812 ms

요청에서 응답까지의 시간을 확인해본 결과 평균적으로 2800ms의 시간이 소요되는 것을 확인하였다.

원인 분석

콘솔 로그에 뜨는 sql 쿼리문을 분석한 결과

현재 aduditLog ↔ audiltLogDetail 간의 연관 관계에서

audiltLog를 통해 테이블 데이터를 조회할경우 audiltLogDetail의 정보도 필요하기에

aduditLog ↔ audiltLogDetail

1 + N 개의 쿼리가 나가고 있는 현상을 발견하였다.

N + 1 문제 발생!

2025-04-25 12:01:57.679 [https-jsse-nio-443-exec-9]  INFO com.welcommu.modulecommon.filter.JwtAuthenticationFilter - 유효한 JWT 토큰으로 인증된 사용자: admin@naver.com
2025-04-25 12:01:57.679 [https-jsse-nio-443-exec-9] DEBUG org.springframework.security.web.FilterChainProxy - Secured GET /api/auditLog/search?
Hibernate: 
    select
        al1_0.id,
        al1_0.action_type,
        al1_0.actor_id,
        al1_0.logged_at,
        al1_0.target_id,
        al1_0.target_type 
    from
        audit_log al1_0 
    where
        1=1
Hibernate: 
    select
        d1_0.audit_log_id,
        d1_0.id,
        d1_0.field_name,
        d1_0.new_value,
        d1_0.old_value 
    from
        audit_log_detail d1_0 
    where
        d1_0.audit_log_id=?
Hibernate: 
    select
        d1_0.audit_log_id,
        d1_0.id,
        d1_0.field_name,
        d1_0.new_value,
        d1_0.old_value 
    from
        audit_log_detail d1_0 
    where
        d1_0.audit_log_id=?
        ...

문제가 발생한 dto

public class AuditLogResponse {

    private Long id;
    private Long actorId;
    private String targetType;
    private Long targetId;
    private String actionType;
    private LocalDateTime loggedAt;
    private List<AuditLogDetailResponse> details;

    public static AuditLogResponse from(AuditLog log) {
        return new AuditLogResponse(
            log.getId(),
            log.getActorId(),
            log.getTargetType().name(),
            log.getTargetId(),
            log.getActionType().name(),
            log.getLoggedAt(),
            log.getDetails().stream().map(AuditLogDetailResponse::from).toList()  <- 문제 발생 부분
        );
    }
}

logDetail을 불러오는 과정에서 N + 1 이 발생하는 것을 확인했다.

해결과정

기존에는 audlitLog 조회시

커스텀 쿼리를 통해 여러개의 쿼리문을 보냄으로서 N + 1 문제가 발생했다.

package com.welcommu.moduleinfra.logging;

import com.welcommu.moduledomain.logging.AuditLog;
import com.welcommu.moduledomain.logging.enums.ActionType;
import com.welcommu.moduledomain.logging.enums.TargetType;
import jakarta.persistence.EntityManager;
import jakarta.persistence.TypedQuery;
import java.time.LocalDateTime;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

@Repository
@RequiredArgsConstructor
public class AuditLogRepositoryImpl implements AuditLogRepositoryCustom {

    private final EntityManager em;

    @Override
    public List<AuditLog> findByConditions(
        ActionType actionType,
        TargetType targetType,
        LocalDateTime startDate,
        LocalDateTime endDate,
        Long userId
    ) {
        StringBuilder sb = new StringBuilder("SELECT a FROM AuditLog a WHERE 1=1");
        Map<String, Object> params = new HashMap<>();

        if (actionType != null) {
            sb.append(" AND a.actionType = :actionType");
            params.put("actionType", actionType);
        }
        if (targetType != null) {
            sb.append(" AND a.targetType = :targetType");
            params.put("targetType", targetType);
        }
        if (startDate != null) {
            sb.append(" AND a.loggedAt >= :startDate");
            params.put("startDate", startDate);
        }
        if (endDate != null) {
            sb.append(" AND a.loggedAt <= :endDate");
            params.put("endDate", endDate);
        }
        if (userId != null) {
            sb.append(" AND a.actorId = :userId");
            params.put("userId", userId);
        }

        TypedQuery<AuditLog> query = em.createQuery(sb.toString(), AuditLog.class);
        params.forEach(query::setParameter);

        return query.getResultList();
    }
}

전송하는 쿼리의 수를 줄이기 위해 fetch join을 적용하여 N + 1 문제를 해결하고자 했다.

다른 해결책(예: @BatchSize, @EntityGraph)도 있지만, fetch join은 개발자가 데이터 로딩 시점을 명확하게 제어할 수 있다는 장점이 있기에 fetch join으로 해결하고자 했다.

fetch join은 JPQL 쿼리 내에서 즉시 로딩(EAGER)할 연관 관계를 명시적으로 선언하는 방식이다.

이를 통해 개발자는 데이터가 필요한 특정 상황에서만 함께 조회하도록 직접 제어할 수 있고, 이는 애플리케이션의 동작을 예측 가능하게 만들고, 다른 곳에서 발생할 수 있는 잠재적인 성능 문제를 방지하는 효과가 있기에 이 방식을 선택했다.

복잡한 동적 쿼리이기도 했고 쿼리의 동작을 명확하게 제어하고 싶었기에 이러한 방식이 더 좋다고 생각했다.

package com.welcommu.moduleinfra.logging;

import com.welcommu.moduledomain.logging.AuditLog;
import com.welcommu.moduledomain.logging.enums.ActionType;
import com.welcommu.moduledomain.logging.enums.TargetType;
import jakarta.persistence.EntityManager;
import jakarta.persistence.TypedQuery;
import java.time.LocalDateTime;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

@Repository
@RequiredArgsConstructor
public class AuditLogRepositoryImpl implements AuditLogRepositoryCustom {

    private final EntityManager em;

    @Override
    public List<AuditLog> findByConditions(
        ActionType actionType,
        TargetType targetType,
        LocalDateTime startDate,
        LocalDateTime endDate,
        Long userId
    ) {
        StringBuilder sb = new StringBuilder("SELECT DISTINCT a FROM AuditLog a LEFT JOIN FETCH a.details WHERE 1=1");
        Map<String, Object> params = new HashMap<>();

        if (actionType != null) {
            sb.append(" AND a.actionType = :actionType");
            params.put("actionType", actionType);
        }
        if (targetType != null) {
            sb.append(" AND a.targetType = :targetType");
            params.put("targetType", targetType);
        }
        if (startDate != null) {
            sb.append(" AND a.loggedAt >= :startDate");
            params.put("startDate", startDate);
        }
        if (endDate != null) {
            sb.append(" AND a.loggedAt <= :endDate");
            params.put("endDate", endDate);
        }
        if (userId != null) {
            sb.append(" AND a.actorId = :userId");
            params.put("userId", userId);
        }

        TypedQuery<AuditLog> query = em.createQuery(sb.toString(), AuditLog.class);
        params.forEach(query::setParameter);

        return query.getResultList();
    }
}

변경된 내용 요약

BEFORE
StringBuilder sb = new StringBuilder("SELECT a FROM AuditLog a WHERE 1=1");

AFTER        
StringBuilder sb = new StringBuilder("SELECT DISTINCT a FROM AuditLog a LEFT JOIN FETCH a.details WHERE 1=1");

문제 해결

fetch join을 통해 N + 1 문제를 해결하니 응답속도가 상당히 빨라졌다.

문제 해결 후 콘솔 로그

2025-04-25 12:12:10.635 [https-jsse-nio-443-exec-8]  INFO com.welcommu.modulecommon.filter.JwtAuthenticationFilter - 유효한 JWT 토큰으로 인증된 사용자: admin@naver.com
2025-04-25 12:12:10.636 [https-jsse-nio-443-exec-8] DEBUG org.springframework.security.web.FilterChainProxy - Secured GET /api/auditLog/search?
Hibernate: 
    select
        distinct al1_0.id,
        al1_0.action_type,
        al1_0.actor_id,
        d1_0.audit_log_id,
        d1_0.id,
        d1_0.field_name,
        d1_0.new_value,
        d1_0.old_value,
        al1_0.logged_at,
        al1_0.target_id,
        al1_0.target_type 
    from
        audit_log al1_0 
    left join
        audit_log_detail d1_0 
            on al1_0.id=d1_0.audit_log_id 
    where
        1=1

쿼리문도 1개가 나가는 것을 확인했다.

수정 후 응답시간

2025-04-25 12:10:11.670 [https-jsse-nio-443-exec-1]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ List com.welcommu.moduleservice.logging.AuditLogSearchService.searchLogs(ActionType,TargetType,String,String,Long) executed in 120 ms
2025-04-25 12:10:11.670 [https-jsse-nio-443-exec-1]  INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ ResponseEntity com.welcommu.moduleapi.logging.AuditLogController.searchAuditLogs(ActionType,TargetType,String,String,Long) executed in 120 ms

응답속도는 2800ms -> 120ms로 상당히 빨라진 모습을 확인할 수 있었다.

1차 성능 개선 완료.

Github Action 환경에서 모든 테스트코드가 실패한다.

PoroGramr — Sat, 19 Jul 2025 17:52:43 +0900

문제상황

Github Action을 활용해서 CI / CD를 구축하던 중

CI 과정에서 테스트 코드 검사를 활성화 후 파이프라인을 진행시켰다. 그런데..

분명 로컬에서는 잘 작동하던 테스트가

위 이미지 처럼 다수가 실패해 CI 가 제대로 동작하지 않게 되었다..

원인파악 + 해결

1차로 확인한 원인

ConfigDataResourceNotFoundException이 발생하여 테스트가 실패하고 있었다.

ConfigDataResourceNotFoundException란 스프링이 로딩할 설정파일을 읽지 못해 발생하는 익셉션이다

테스트 패키지에 application-test.yml 파일을 추가하여 해당 익셉션을 해결하였다.

추가적으로 Test 클래스마다 @ActiveProfiles 어노테이션을 추가해 설정파일 옵션을 부여해주었다.

2차로 확인한 원인

application-test.yml 에서 Redis Repository를 비활성화 해놓았다.

위 설정으로 인해 redis 관련 테스트들이 실행이 불가능해 테스트가 실패하고 있었다.

@MockitoBean
private RefreshTokenRepository refreshTokenRepository;

를 추가해 redis repository를 mock처리하여 해당 에러를 해결하였다..

많은 시도 끝에 성공..

정진

일단 CI가 작동은 하지만

아직 SpringBoot Test의 작동 방식에 대한 이해가 상당히 부족하다는 걸 깨달았다..

테스트도 방식이 여러가지라니..

순수 단위 테스트, 순수하지 않은 단위테스트...

통합테스트 등등..

어렵다. TDD

테스트 코드는 왜 짜야할까..

PoroGramr — Thu, 17 Jul 2025 00:16:06 +0900

들어가며..

최근 사이드 프로젝트를 진행하면서

테스트 코드에 대해 공부할 겸 TDD로 프로젝트를 진행하고 있다.

지금까지 다양한 백엔드 프로젝트를 진행해보았지만

테스트 코드를 작성해본 경험이 없었기에

이번 프로젝트를 진행하면서 TDD로 개발하며 무조건! 테스트 코드를 작성하며 개발을 하고자 했다.

그렇게 시작

시작은 User API를 개발하며 TDD를 진행하였다.

생성, 조회 API 까지는 나름 TDD가 할만했다.

컨트롤러, 서비스 모듈 별로 테스트를 작성하며 진행했다.

@Test
    public void 일반회원_회원가입() throws Exception{
        String id = "username";
        String password = "password";
        String nickname = "nickname";

        when(userService.customerSignUp(any(CustomerSignUpRequest.class))).thenReturn(mock(
            UserResponse.class));

        mockMvc.perform(post("/api/customers")
            .contentType(MediaType.APPLICATION_JSON)
            .content(objectMapper.writeValueAsBytes(new CustomerSignUpRequest(id, password,nickname)))
            .with(csrf())
        ).andDo(print())
            .andExpect(status().isOk());
    }

@Test
    void 일반회원_회원가입이_정상적으로_동작하는경우() {
        String id = "id";
        String password = "password";
        String nickname = "nickname";

        when(userRepository.findById(id)).thenReturn(Optional.empty());
        when(userRepository.save(any())).thenReturn(CustomerUserFixture.get(id, password));
        when(passwordEncoder.encode(password)).thenReturn("encodedPassword");

        Assertions.assertDoesNotThrow(() -> userService.customerSignUp(new CustomerSignUpRequest(id,password,nickname)));
    }

하지만 수정 부터 굉장히 복잡해졌다..

@Test
    void 고객_회원_수정이_성공적으로_동작하는_경우() {

        // given
        User existingUser = User.ofCustomer("loginId", "oldPass", "oldNick");
        // anyLong() 사용
        given(userRepository.findById(anyLong()))
            .willReturn(Optional.of(existingUser));
        given(userRepository.save(any(User.class)))
            .willAnswer(invocation -> invocation.getArgument(0));
        given(passwordEncoder.encode("newPass")).willReturn("newPass");

        UpdateUserRequest req = new UpdateUserRequest("newPass", "newNick");

        // when
        UserResponse resp = userService.updateUser(999L, req);

        // then
        assertThat(existingUser.getPassword()).isEqualTo("newPass");
        assertThat(existingUser.getNickname()).isEqualTo("newNick");
        assertThat(resp.getNickname()).isEqualTo("newNick");
    }

장단점

그래도 스스로 TDD를 하며 느낀 장점을 적어보자면

1. 익셉션 처리가 제대로 되는 지 확인할 수 있다.

2. 비즈니스 로직이 제대로 작동하는 지 확인할 수 있다.

3. 리팩토링 진행 후 추가적인 파급 효과를 확인할 수 있다.

4. 심리적 안정감

하지만 단점도 존재한다.

1. 개발속도가 상당히 느려진다.

2. 비즈니스 로직 구현보다 테스트 코드 작성하는데 시간이 더 걸린다.

뭐 어떻게 보면 단점 1,2는 같은 말이기도 하다..

더 나아가야할 점

TDD의 시작은 강의를 보며 따라하는 방식으로 진행했다.

해당 강의와 프로젝트의 로직이 완전히 똑같지는 않지만 나름 비슷한 부분은 참고하며 진행하고 있다.

하지만 진행하는 프로젝트의 로직이 점점 복잡해지면서 강의를 참고하기가 어려워지고 있다...

AI들의 도움을 받으며 겨우 겨우 작성하고 있지만

그래도 스스로 더욱 더 학습해나아가야 할 것 같다..

강의의 강사분처럼.. 혼자서 쓱쓱 테스트 코드 작성하는 개발자가 되기를 바라며..