과거의 배움을 오늘의 성장으로,
성장하는 개발자 신온유입니다.

참여인원

• 총 5명 (백엔드 2명, 프론트엔드 3명)

담당 포지션

• 백엔드 및 인프라

아키텍쳐

ERD

주요 작업

QueryDSL 도입을 통한 복잡한 JPQL 쿼리 리팩토링을 통한 성능 및 유지보수성 향상

• 문제상황

  • 로그인한 사용자의 팔로워 및 팔로잉 관계를 고려한 게시글 조회 기능 구현에서, JPQL로는 복잡한 동적 쿼리를 처리하기 어려웠고, 코드의 가독성과 유지보수성이 낮아 개발 효율이 떨어지는 문제가 발생함.

• 해결 과정

  1. 도입 이유: 복잡한 동적 쿼리를 처리해야 하는 게시글 조회 기능에서 기존 JPQL로는 코드가 비대해지고 가독성이 떨어져 유지보수가 어려운 상황이었음. 더불어, 다양한 정렬 조건(예: 인기순, 최신순)을 추가해야 했기 때문에, 더 유연하고 타입 안전한 쿼리 작성이 가능한 QueryDSL 도입이 필요했음
  2. QueryDSL 도입: 기존 JPQL을 QueryDSL로 전환하여 코드 직관성과 안정성을 높였으며, 동적 쿼리 생성을 유연하게 처리할 수 있도록함
  3. 정렬 기준 구현: 인기순, 최신순 등 다양한 정렬 조건을 열거형(Enumeration)으로 추상화하여 관리함으로써, 확장성과 일관성을 확보함.

• 결과

  • 성능 향상: 평균 응답 시간이 13% 감소하고, 처리율이 16% 증가하여 동시 요청 처리량을 개선함.
    • 유지보수성 향상: QueryDSL 도입으로 코드 재사용성과 가독성이 높아졌으며, 프로젝트 확장 시 유지보수가 용이해짐.
    • 추가 개발 용이성: 열거형 정렬 방식으로 새로운 정렬 기준을 쉽게 추가할 수 있어, 요구사항 변화에 유연하게 대응할 수 있도록 함.

• JPQL 사용 (전)

• Query DSL 도입(후)

알림 조회 서비스 최적화

• 문제상황

  • 알림 조회 서비스의 초기 성능 테스트에서 사용자 수가 증가함에 따라 평균 응답 시간이 크게 늘어나고, 처리량이 감소하는 문제가 발견되었습니다. 이로 인해 서비스가 많은 사용자를 동시에 지원하지 못하고, 사용자 경험이 저하되는 우려가 있었습니다.

• 해결과정

  1. 성능테스트

     • JMeter를 사용하여 1000명과 10000명의 동시 요청을 시뮬레이션하며 성능 테스트를 진행한 결과, 서비스가 동시 요청을 효율적으로 처리하지 못하고 성능 저하가 발생함을 확인함.

  2. Redis 도입

     • 성능 문제를 해결하기 위해 Redis 캐싱을 도입하여 동일한 요청에 대한 데이터베이스 조회를 줄여 응답 속도를 높임. TTL 설정으로 최신 알림 상태를 유지하면서 효율적인 캐싱이 가능하도록 구현함.
     • 캐싱 전략: notification:{username}:page:{pageNumber} 형식으로 페이지별 캐싱. 삭제 시 해당 사용자의 모든 캐시 데이터를 일괄 삭제하여 일관성 유지.

• 결과

  • Redis 도입 후 성능 테스트를 재실행한 결과, 다음과 같은 개선 효과를 확인함.
  • 응답 시간 93% 감소: 10000명 동시 요청 시 평균 응답 시간이 93% 단축됨.
  • 처리량 12% 증가: 캐싱 적용 후 처리량이 12% 증가하여 다수의 동시 요청을 효율적으로 처리할 수 있게 됨.

참여인원

5명 (백엔드 3명, 프론트엔드 2명)

담당포지션

• 백엔드 및 AI

아키텍쳐

주요 작업

Spring Security 설정 중 순환참조 문제 해결

• 문제상황

  • Spring Security 설정 과정에서 JwtFilter와 UserDetailsService 간에 순환 참조 문제가 발생하여 애플리케이션이 정상적으로 실행되지 않는 오류가 발생함.

• 원인분석

  • UserDetailsServiceImpl이 빈으로 명시적으로 등록되지 않았기 때문에 발생한 문제로 확인됨.
  • UserDetailService는 Spring Security에서 추상화된 상태로 제공되며, 세부 구현은 개발자가 직접 정의해야 함.
  • 이러한 상황에서, Jwt 토큰을 검증하는 필터인 JwtTokenFilter에서 토큰검증을 위한 유저네임 로드를 하였음.
  • JwtTokenFilter에서 JWT 토큰 검증 시 유저 정보를 로드하려고 UserDetailService를 호출했으나, 기본 구현체인 InMemoryUserDetailsManager가 로드되며 Spring Security 설정 코드까지 호출하게 되어 순환 참조 문제가 발생함.

• 해결과정

  • 순환 참조 문제 확인 및 원인 탐색
    • PasswordEncoder 빈 설정이 문제의 원인일 가능성을 발견하고 이를 별도의 클래스로 분리하여 임시적으로 해결했으나 근본적인 해결책은 아니었음.
  • UserDetailsService 빈 설정 문제 점검
    • UserDetailsServiceImpl 클래스에 @Service 어노테이션이 누락되어 있어, 기본 구현체인 InMemoryUserDetailsManager가 빈으로 참조된 문제를 발견함.
  • JwtFilter
  • UserDetailServiceImpl
  • InMemoryUserDetailsService

• 어노테이션 추가 및 빈 설정 수정

  • UserDetailsServiceImpl 클래스에 @Service 어노테이션을 추가하여 JwtFilter가 올바른 구현체를 참조하도록 수정함.
  • 이를 통해 순환 참조 문제를 근본적으로 해결하고 애플리케이션이 정상적으로 실행되도록 함.

  관련하여 작성한 포스팅

냉장고 데이터 수집과 AI 모델 구축의 문제 해결 및 최적화

• 문제상황
  • 냉장고 내부 식재료 데이터를 수집하여 탐지 모델을 구축해야 했으나, 실제 냉장고를 섭외하지 못하는 물리적 제약과 식재료 데이터 확보의 어려움이 존재함.
  • 적절한 식재료 인식 모델이 부족하여 데이터를 직접 수집하고 라벨링해야 하는 상황이 발생함.
• 해결과정
  1. 대체 냉장고 환경 구성
     • 실제 냉장고 대신 택배 박스를 냉장고 형태로 개조하고, 카메라와 IoT 장비(Arduino, Raspberry Pi)를 부착하여 데이터를 수집함.
     • 식재료 데이터 수집에는 방송용 모조 과일 및 채소를 사용하여 실제 데이터를 대신함.
  2. AI 모델 학습
     • 상용 API가 대부분 B2B용이거나 커스터마이징이 제한적이어서 YOLOv5 모델을 채택해 자체 라벨링한 데이터를 학습함.
     • 비닐 포장된 식재료도 인식할 수 있도록 추가 학습을 진행하여 다양한 상태의 식재료를 효과적으로 탐지할 수 있도록 학습시킴.
• 결과
  1. 제한된 예산과 자원 내에서 데이터 수집 시스템을 성공적으로 구축함.
  2. 대체 냉장고 환경을 활용하여 향후 다양한 실내 IoT 프로젝트에도 적용 가능한 기반을 마련함.
• 라벨링 이미지