미리보기

프로젝트 설명

• 주제: 쿠폰 발급 고도화 프로젝트

• 링크: couponify

쿠폰 발급 과정에서 발생한 동시성 문제 해결

• 문제

  • 쿠폰 발급 과정에서 JPA의 쓰기 지연으로 인해 트랜잭션이 충돌하여 데드락 문제 발생

  • 동시성 제어 부족으로 쿠폰 잔여 수량과 발급된 쿠폰 수량이 일치하지 않는 문제 발생

• 해결

  • JPA의 비관적 락을 적용하여 데드락 문제를 해결하고, 동시성을 제어하여 데이터 정합성을 유지

  • Redisson 분산 락을 도입해 비관적 락의 한계를 보완하고, 분산 환경에서도 데이터 정합성을 유지

• 성과

  • 쿠폰 발급 과정에서 발생한 동시성 문제를 해결하며 데이터 정합성을 안정적으로 유지함

핵심 비즈니스 로직에 대한 JUnit 테스트 코드 작성

• 문제

  • 테스트 코드가 없는 상태에서는 새로운 기능을 추가하거나 기존 로직을 수정할 때마다 수동으로 모든 테스트를 반복해야 하는 비효율 발생

• 해결

  • 도메인 및 서비스 계층의 핵심 비즈니스 로직에 대해 테스트 코드를 작성하여 안정성을 사전에 검증

  • 쿠폰 발급 동시성 테스트를 통해 트랜잭션 충돌 가능성을 확인하고, 이를 해결할 방안을 설계

• 성과

  • 핵심 로직의 안정성 향상

  • 코드 수정 및 기능 추가 시 자동화된 테스트를 통해 예기치 않은 오류를 빠르게 확인 가능

Repository 구조 리팩토링

• 문제

  • Repository가 특정 데이터베이스 접근 기술에 종속되어 있어, 기술의 교체나 확장이 어려움

• 해결

  • Infrastructure 계층에서 영속성 관리를 전담하도록 설계하여 느슨한 결합 구조 달성

  • CouponRepository 인터페이스를 CouponJpaRepositoryImpl 구현체로 구현함으로써, 구현체의 세부 로직을 캡슐화

• 성과

  • 도메인 로직이 영속성 기술에 종속되지 않도록 하여, 데이터베이스 접근 기술의 교체 및 확장이 용이해짐

환경 설정 관리 최적화

• 문제

  • 여러 기술을 사용하는 시스템에서 환경별 설정 파일이 길어지고, 관리가 복잡해짐

• 해결

  • 환경 설정을 프로파일별로 관리하는 대신, 사용하는 기술별로 설정 파일을 분리하여 관리

    • ex) 데이터베이스, 캐시 등 각 기술에 대한 설정을 독립적으로 관리

• 성과

  • 각 기술별 설정 파일을 독립적으로 관리함으로써 환경 설정의 가독성 및 유지보수성 향상

일관된 예외 처리

• 문제

  • 예외 처리 로직이 중복되고, 클라이언트에 전달되는 예외 응답 형태가 일관되지 않음

• 해결

  • 커스텀 예외 객체와 전역 예외 핸들러를 구현하여 발생 가능한 모든 예외를 일관되게 처리

• 성과

  • 예외 처리 로직 및 예외 응답 형태의 일관성을 유지함으로써, 클라이언트와 서버 간 통신의 명확성을 높임

응집도를 높이기 위한 원시 타입 포장 객체 도입

• 문제

  • Quantity와 같은 원시 값을 직접 사용하는 로직에서 유효성 검증이 분산되어 관리 포인트가 많아짐

• 해결

  • Quantity와 같은 원시 값을 포장 객체로 구현하여 단일 책임 원칙 적용

  • 원시 값에 대한 유효성 검증 로직을 포장 객체 내에서만 처리하도록 설계

• 성과

  • 유효성 검증 로직의 관리 포인트가 하나로 통합되어 유지보수가 쉬워졌으며, 코드의 재사용성 및 응집도 향상

프로젝트 설명

• 주제: 대규모 트래픽 대응을 위한 마이크로서비스 아키텍처 기반 쇼핑몰 시스템

• 인원: BE 4

• 링크: SASAP!CK

Redis 데이터 동기화 문제 해결

• 문제

  • 장바구니 요구사항에는 30일의 만료시간이 필요하여 Redis 사용을 결정

  • Redis에 저장된 장바구니 데이터에 <상품 ID, 이름, 수량, 가격> 정보가 모두 포함되어 있어, 상품 정보가 변경되거나 삭제될 때 Redis와 DB 간 동기화 문제 발생

  • 상품 정보 변경 시마다 장바구니에 담긴 상품 데이터를 수동으로 업데이트해야 하므로 비효율적

• 해결

  • Redis 장바구니 데이터에는 상품 ID와 수량만 저장하고, 그 외의 정보는 장바구니 조회 시 DB에서 최신 정보를 가져오도록 변경

  • 장바구니 상품 추가, 삭제 등 조회 외의 작업은 Redis에서 처리하여 I/O 부하를 줄임

• 성과

  • Redis와 DB 간 동기화 비용 감소

  • 상품 정보가 변경되더라도 실시간으로 최신 데이터 반영

주문 생성 시 비동기 방식으로 주문 및 결제 처리 로직 구현

• 문제

  • 토스 페이먼츠 결제 모듈의 복잡한 결제 과정과 사용자 상호작용 요구를 간과

• 해결

  • 주문 생성 시 결제 관련 로직을 비동기로 처리하여 결제 여부와 관계 없이 즉시 응답 반환

  • Kafka 메시지 큐를 사용하여 결제 완료 시 주문 상태를 자동으로 업데이트

    • 복잡한 라우팅으로 인한 RabbitMQ의 성능 저하를 고려해, 높은 데이터 처리와 분산 환경에 적합한 Kafka를 선택

• 성과

  • 비동기 처리로 사용자 대기 시간을 단축

  • Kafka 기반 이벤트 처리로 효율적인 주문 관리

상품 재고 관리 과정에서 발생한 동시성 문제 해결

• 문제

  • 여러 클라이언트가 동시에 재고를 수정하는 과정에서 데이터 무결성을 보장하지 못해 동시성 문제 발생

• 해결

  • 기존의 캐시로 Redis를 사용중이었고 분산 환경 기반의 시스템이기에 확장성 면에서 Redisson 선택

  • Redisson 기반 분산 락을 적용하여 데이터 정합성 유지

• 성과

  • 분산 환경에서도 안정적인 분산 락을 통해 동시성 문제를 해결하고, 재고 관리의 정확성을 높임

전략 패턴을 활용한 알림 관련 로직 캡슐화

• 문제

  • 알림의 유형별 로직을 단일 비즈니스 메서드에 구현하면, 새로운 유형 추가 시 기존 코드에 영향을 미쳐 유연한 확장이 어려움

• 해결

  • 전략 패턴을 적용하여 알림 관련 로직을 캡슐화하고, 알림 유형에 따라 별도의 전략 클래스를 구현

• 성과

  • 개방-폐쇄 원칙을 준수하여 기존 코드 변경 없이 새로운 요구사항에 유연하게 대응할 수 있게 됨

프로젝트 설명

• 주제: 기업 간 거래(B2B) 프로세스를 자동화하고 효율적으로 관리할 수 있는 플랫폼 개발

• 인원: BE 3

• 링크: B2B Project

Spring Security와 JWT를 이용해 게이트웨이 필터 및 각 서비스 필터에서 회원 인증/인가 처리

• 문제

  • 게이트웨이에서 JWT 토큰을 헤더에서 추출한 뒤, 사용자 인증 정보를 SecurityContextHolder에 저장하는 방식으로 구현

  • 게이트웨이에서 JWT 토큰 검증은 수행되었으나, 각 MSA 서비스로 사용자 인증 정보가 전달되지 않는 문제 발생

  • 각 MSA 서비스가 서로 다른 포트에서 구동되며, SecurityContextHolder는 기본적으로 ThreadLocal 방식을 사용하기 때문에, 쓰레드 간 데이터가 공유되지 않음

• 해결

  • 게이트웨이에서 JWT 토큰 검증만 수행하고, Claims 정보를 각 MSA 서비스로 헤더를 통해 전달하는 방식으로 변경

  • 각 MSA 서비스는 전달 받은 사용자 인증 정보를 별도의 필터를 통해 SecurityContext에 저장하여 서비스의 컨트롤러에서 사용할 수 있도록 구현

• 성과

  • 각 MSA 서비스로 사용자 인증 정보가 전달되지 않던 문제를 해결하여 인증/인가 흐름을 일관되게 유지

  • MSA 환경에서 세션 동기화가 필요한 세션 기반 인증의 한계를 보완하고, 안정적인 인증 처리를 구현

배송담당자 전체조회 시 발생한 FeignClient N+1 호출 문제 해결

• 문제

  • 배송담당자 전체 조회 시, 배송담당자 도메인과 다대일 관계인 허브 도메인을 함께 조회해야 했음

  • MSA 아키텍처에서 각 배송담당자 객체의 허브 ID를 사용해 각각 FeignClient 호출로 허브 정보를 조회했기 때문에 N+1 호출 문제가 발생

    • ex) 배송담당자가 5명일 경우 각각의 허브 조회를 5번 호출하게 되어 N+1 쿼리가 발생

• 해결

  • 허브 ID 리스트를 모아 한 번의 FeignClient 호출로 여러 허브 정보를 조회하도록 변경

    • JPA의 IN 쿼리 방식처럼 여러 허브 ID를 한 번에 전달하고, 이를 통해 한 번의 FeignClient 호출로 여러 허브 정보를 조회

• 성과

  • 100명의 배송담당자 조회 시 FeignClient 호출 횟수를 100번에서 1번으로 줄여 네트워크 부하 최적화

  • 100명 조회 시 평균 조회 속도를 1100ms에서 30ms로 단축하여 약 97% 성능 개선 달성

• 대학생 IT 연합 해커톤

• 대학생 IT 연합 동아리