"멋쟁이사자처럼 홍익대학교 14기 신규 부원 모집 및 선발 관리 서비스"
지원서 접수부터 서류/면접 합격자 발표, 그리고 면접 일정 안내까지 선발의 전 과정을 관리하는 백엔드 시스템입니다.
client : www.likelionhongik.com
server : api.likelionhongik.com
Tech Stack
•
Backend: Java 21, Spring Boot 3.4.1, Spring Data JPA
•
Database: MySQL
•
DevOps: AWS EC2, GitHub Actions
My Contributions
1. [성능 최적화] 합격자 조회 쿼리 튜닝
•
상황: 합격자 발표 시점에 지원자들이 동시에 몰려 순간적인 트래픽 스파이크 발생이 예상됨.
•
문제: 기존 로직은 Student(학생 정보)를 먼저 조회하고, 이를 바탕으로 StudentResult(결과)를 다시 조회하는 방식으로 2번의 DB I/O가 발생하거나, 연관 관계 조회 시 N+1 문제가 발생할 위험이 있었음.
•
해결: JOIN FETCH를 적용한 커스텀 쿼리(findByStudentIdAndName)를 작성하여, 학생 정보 검증과 합격 여부 조회를 단 1회의 쿼리로 처리하도록 리팩토링.
•
성과: DB 커넥션 점유 시간을 단축하고 서버 리소스 효율을 극대화하여 안정적인 조회 서비스 제공.
2. 면접 일정 안내 시스템
•
기능: 서류 합격자에게 배정된 면접 시간과 장소, 주의사항을 개인화하여 제공.
•
구현: StudentResult 엔티티 내에 면접 정보를 포함하고, 합격 여부(PASS)인 경우에만 해당 DTO 필드가 노출되도록 비즈니스 로직을 설계하여 정보 보안 강화.
3. 읽기 전용 트랜잭션 최적화
•
최적화: 단순 조회 로직에는 @Transactional(readOnly = true)를 명시하여 JPA의 더티 체킹 부하를 제거하고, 리플리카 DB 활용 가능성을 열어둠.
Trouble Shooting & Deep Dive
[DB] 동시성 조회를 위한 쿼리 리팩토링
•
Before
// 비효율적 방식: 학생 조회 후 결과 조회 (쿼리 2회 발생)
Student student = studentRepository.findByStudentId(id);
StudentResult result = resultRepository.findByStudent(student);
Java
복사
•
After
// 최적화 방식: JOIN FETCH로 한 번에 조회 (쿼리 1회 발생)
@Query("SELECT sr
FROM StudentResult sr JOIN FETCH sr.student s
WHERE s.studentId = :studentId AND s.name = :name")
Optional<StudentResult> findByStudentIdAndName
(@Param("studentId") String studentId, @Param("name") String name);
Java
복사
•
Impact: 학번과 이름을 조건으로 인덱스를 타게 하고, 불필요한 서브 쿼리나 추가 조회를 원천 차단하여 조회 응답 속도를 개선.