[🔥TroubleShooting - MoodBuddy🔥] 너의 쿼디티아이는 뭐니?!

📌 프로젝트 소개

팀원 : PM(1) / Design(1) / Frontend(2) / Backend(3)
기간 : 2024.03 ~ 2025.03
링크 : https://github.com/M-ung/MoodBuddy_Server
서비스 내용 : 사용자가 작성한 일기를 바탕으로 감정 분석하는 웹 서비스
소통 : GitHub, Slack, Notion, Discord

---

🔥TroubleShooting🔥

Problems

우리 서비스 'MoodBuddy" 에는 특별한 기능이 있다. 바로 "쿼디티아이(QuddyTI)" 이다.

쿼디티아이(QuddyTI)란?
단순히 MBTI를 생각하면 된다.
사용자가 한 달 동안 작성한 일기를 기반으로 "일기 작성 횟수, 일기 분석을 통해 나온 감정, 주제" 를 기반으로 일기 성격 유형을 판별해주는 서비스이다.
이는 한 달 기반으로 결과가 나와야 하기 때문에 매달 00시에 쿼디티아이(QuddyTI) 생성(현재 달) 및 수정(지난 달)이 발생한다.

처음 1차 배포 때는 단순히 스케줄러를 사용해서 아래와 같이 구현했다.

@Component
@RequiredArgsConstructor
public class QuddyTIScheduler {
    private final QuddyTIFacade quddyTIFacade;

    @Scheduled(cron = "0 0 0 1 * ?")
    @Transactional
    public void aggregateAndSaveDiaryData() {
        quddyTIFacade.createAndUpadteQuddyTI();
    }
}

스케줄러를 돌려 매달 00시에 동작하도록 구현했다.

하지만 아래와 같은 문제점들이 발생했다.

1. 한 번에 모든 사용자의 데이터를 처리하려다 보니 데이터가 많아질수록 쿼리 부하 증가
2. 트랜잭션이 길어지고, 전체 데이터 처리 시간이 늘어나면서 서버 부하 발생
3. 사용자가 많아질수록 데이터 증가로 인해 하나의 스케줄러에서 처리하는 방식이 점점 부담스러워짐

---

How

그래서 위 문제들을 해결하기 위해 "Spring Batch" 를 우리 서비스에 도입하기로 했다.

Spring Batch란?
Spring Batch는 대량의 데이터를 효과적으로 처리할 수 있도록 설계된 배치 처리 프레임워크다.
스케줄러가 단순 반복 실행을 하는 것과 달리, 대량 데이터를 효율적으로 나누어 처리하고, 재시도 및 실패 복구 기능을 제공한다.

Spring Batch의 핵심 개념
1. Job: 하나의 배치 작업 단위
2. Step: Job을 구성하는 개별 단계
3. ItemReader: 데이터를 읽는 역할
4. ItemProcessor: 데이터를 가공하는 역할
5. ItemWriter: 데이터를 저장하는 역할

위 "Spring Batch" 를 적용하게 되면 아래와 같은 기대 효과를 얻을 수 있다.

1. 성능 개선: 작은 단위로 데이터를 처리하여 DB 부하 감소
2. 안정성 향상: 실패한 작업을 자동으로 재시도 가능

---

Process

먼저 기존 스케줄러는 Spring Batch의 트리거 역할을 할 수 있게 변경한 후 아래와 같이 설계했다. 그리고 Spring Data JPA를 활용해서 생성, 수정, 조회를 해결하려고 했다.

하지만 Spring Data JPA를 활용한 방식에는 아래와 같은 문제점들이 있었다.

1. 대량 데이터 처리 시 성능 저하
2. JPA의 기본적인 Bulk Update/Insert의 한계

그래서 Spring Data JPA 보다 JDBC 방식으로 생성, 수정, 조회를 구현하였다.
코드는 아래와 같다.
또한, 쿼디티아이 작업을 하나로 하는 것이 아닌, 생성과 수정 작업을 두 개로 분리하여 DB 부하를 분산하기로 했다.

스케줄러는 두 개로 나눴더라도 같은 시간에 실행하면 위와 같은 문제가 발생할 수 있기 때문에 생성과 수정 스케줄러를 각각 다른 매달 말일과 1일로 분리해서 실행하도록 설계했다.

---

Result

문제 해결로 아래와 같은 결과를 얻었다.
1. 사용자 10,000명 기준, 쿼디티아이 생성 평균 약 919ms, 수정 평균 약 14,528ms로 성능 개선.
2. 스케줄러 → Spring Batch 트리거 방식으로 전환하여 유지보수성을 향상.
3. JPA 대신 JDBC 사용으로 더티 체킹 오버헤드를 제거하고 batch 성능 최적화.
4. 쿼디티아이 생성과 수정 작업을 분리하여 DB 부하를 분산

---

Thoughts

이번 Spring Batch 도입을 통해 스케줄러 기반의 대량 데이터 처리를 개선하는 경험을 할 수 있었다.

처음 적용한 스케줄러 방식에서는 대량 데이터 조회 및 업데이트로 인해 트랜잭션이 길어지고 성능 저하 문제가 발생했지만, Spring Batch를 활용하여 작은 단위로 나누어 처리할 수 있었으며 성능을 개선하고 안정성을 확보할 수 있었다.

위 경험들을 통해 대량 데이터 처리는 단순히 스케줄러로 적용해야겠다는 생각보단 Spring Batch와 같은 프레임워크를 적용하는 것이 필수적이라는 생각을 했다.

또 Spring Data JPA의 편리성으로 인해 이에 의존하기보단 알고 쓰는 것이 중요하다는 것을 깨달았다. 불편하더라도 성능적으로 떨어지면 JDBC와 같은 기술을 적용할 수 있는 설계 능력을 갖춘 개발자가 되어야겠다고 생각했다.

---