SOPT Playground

2026.08 ~ 운영 중

3,000여 명의 SOPT 활동, 명예 회원들이 사용하는 동아리 내부 커뮤니티 서비스

Java
Spring Boot
JPA
PosgreSQL
Redis

Service ↗

프로젝트 소개

팀 구성: 기획 1명, 디자인 2명, FE 2명, BE 3명

SOPT Playground는 약 2,000명의 SOPT 활동 회원과 명예 회원이 사용하는 내부 커뮤니티 서비스입니다. Backend 파트로 합류한 이후 기존 회원 목록 조회 API의 성능 문제를 발견하고, 쿼리 구조와 트랜잭션 범위를 함께 개선했습니다.

프로젝트 내용

회원 목록 조회 API의 N+1 문제 개선

해결 방법

이를 해결하기 위해 정렬 단계와 응답 생성 단계의 조회 목적을 분리했습니다. 먼저 정렬에 필요한 링크·커리어 관련 값만 QueryDSL Projection으로 한 번에 조회하고, 프로필 가중치 계산도 엔티티의 LAZY 컬렉션에 직접 접근하지 않고 Projection 결과를 사용하도록 변경했습니다. 이로써 전체 후보 회원을 정렬하는 과정에서 발생하던 반복 쿼리를 제거했습니다.

페이지네이션이 끝난 뒤에는 최종 페이지에 포함된 회원에 대해서만 실제 링크·커리어 엔티티를 fetch join해 응답을 구성했습니다. 즉 전체 후보군에 대해서는 정렬에 필요한 최소 데이터만 조회하고, 상세 엔티티 조회는 실제 응답 대상에 한정하도록 조회 범위를 나눴습니다.

추가로 회원별 커피챗 활성 여부를 개별 조회하던 로직도 페이지 대상 회원을 기준으로 한 번에 벌크 조회한 뒤 Set으로 변환해 애플리케이션에서 존재 여부를 판정하도록 변경했습니다.

트랜잭션 범위 조정을 통한 DB 커넥션 점유 최소화

문제

회원 목록 조회 성능을 개선하면서 쿼리 수뿐 아니라 서비스 전체의 트랜잭션 범위도 함께 확인했습니다.

Playground에서는 과거 행사 신청처럼 특정 시점에 요청이 몰릴 때 DB 커넥션 풀 고갈로 일부 요청에서 오류가 발생한 이력이 있었습니다. 회원 목록 API 역시 한 번의 요청에서 DB 조회, 내부 Platform 서버 호출, 검색·정렬이 연속해서 수행되는 비교적 긴 처리 흐름을 가지고 있었습니다.

앞서 설명한 것처럼 회원 기본정보는 Playground DB가 아니라 내부 Platform 서버에서 관리하고 있었기 때문에, 회원 목록을 만들기 위해 Platform 서버 호출 자체를 제거할 수는 없었습니다. 이름, 기수, 파트, 팀 등의 정보를 기준으로 검색하거나 최종 응답을 구성하려면 Platform의 데이터를 반드시 가져와야 했습니다.

원인

Platform API 외부 호출까지 서비스 메서드 전체의 @Transactional(readOnly = true) 범위 안에 포함되어 있었습니다.

기존 구조에서는 DB에서 회원 관련 정보를 조회한 뒤 Platform 서버에 HTTP 요청을 보내고, 응답을 기다린 후 두 데이터를 조합해 in-memory 필터링과 정렬을 수행했습니다. 이 과정에서 한 번 DB 커넥션을 획득한 뒤에는 실제 DB 작업이 끝났더라도 Platform 서버 응답을 기다리는 시간과 Java 코드에서 검색·정렬을 수행하는 시간까지 트랜잭션 범위가 이어질 수 있었습니다.

즉 실제로 DB를 사용하는 시간보다 훨씬 긴 시간 동안 커넥션이 점유될 수 있었고, 회원 목록처럼 처리 시간이 긴 요청이 동시에 여러 개 들어오면 커넥션 풀 여유를 줄이는 요인이 될 수 있었습니다.