Spring에서 데이터베이스 트랜잭션은 @Transactional로 관리됩니다. 이 애노테이션은 AOP 기반 프록시가 트랜잭션 경계를 만들어 주는 방식으로 동작하며, 애플리케이션은 JPA를 통해 DB에 접근합니다.이렇게 여러 구성 요소가 겹쳐 DB 트랜잭션을 사용하다 보니 실제 동작을 정확히 이해하지 못한 채 무작정 @Transactional을 붙이거나 흐름을 파악하지 못해 시행착오를 겪는 경우가 많습니다. 그래서 이번 글에서는 로그를 확인하면서 프레임워크가 트랜잭션을 실제로 어떻게 시작·합류·커밋·롤백하는지 살펴보려고 합니다. TL;DR결론: REQUIRED → REQUIRED에서 내부 RuntimeException(unchecked exception)은 바깥까지 전파되어 전체 롤백된다.가장 보편적으로..

1. 새롭게 배운 개념/지식RestTemplate 적용잘한 점 : RestTemplate 사용법과 Redis 자료구조와 활용방안에 대해서 공부했다. 공부 방법: Redis 자료구조와 활용방안(레디스 공식 유튜브: 짧고 지루하지 않게 설명 잘함. 단점은 영어라서 피곤, 개발자를 위한 레디스: 자료구조와 활용방안 부분만 봤는데 좋은 책이였다! gpt나 블로그 보지 말고 그냥 이 책 보는 것이 시간 낭비 안함. 짧게 정리된 것만 보면 별 생각을 안하게 되는데, 책을 보면서 따라가다보면 생각을 하게 되기 때문이다. )RestTemplate 사용법과 Redis 자료구조는 정리를 해두었는데, 이거 정리해두니 다른 사람 코드가 잘 읽혔다! 2. 문제를 해결하면서 얻은 인사이트캐시 구현을 어느 레이어에서 어떤 방식으..

Spring에서 Redis 서버에 연결하려면 무엇이 필요할까? Spring에서 Redis에 연결하려면 클라이언트 드라이버(Lettuce, Jedis 등)가 필요합니다.RedistTemplate은 RedisConnectionFactory를 통해 RedisConnection을 얻고 이 커넥션을 사용해 명령을 실행한 뒤 반납합니다.RedisConnection은 Spring Data Redis가 제공하는 추상화 계층으로 내부적으로 Lettuce나 Jedis 같은 클라이언트 라이브러리를 사용해 실제 Redis 서버와 통신합니다.Spring Data Redis는 클라이언트별로 전용 팩토리를 제공합니다. 즉, 어떤 클라이언트를 쓸지는 어떤 커넥션 팩토리를 생성하느냐로 결정됩니다.LettuceConnectionFac..

상품 목록 조회는 페이징과 정렬 조건이 적용된 상태로 제공되는 API입니다.브랜드 ID를 포함하지 않아 여러 브랜드의 상품을 한 페이지에서 볼 수 있으며 정렬 기준은 최신 순입니다.쇼핑몰에서 클릭 수가 많이 발생할 것을 대비해 먼저 정렬 조건에 맞춰 DB 인덱스를 적용했습니다.또한, 트래픽이 가장 많이 집중되는 1·2페이지에는 Redis를 활용한 글로벌 캐시를 도입하여 응답 속도를 높였습니다.세부 테스트 수치와 지표 해석은 보고서 링크에서 확인할 수 있습니다.목록 조회 시 적용한 DB 인덱스 전략상위 페이지에 적용한 글로벌 캐시 설계와 K6 성능 테스트 진행 결과

한 일주문/결제과정에서 여러 작업(재고차감, 포인트 사용)의 원자성 보장 : 트랜잭션을 이용동시성 처리 : 좋아요 수 증감, 재고 차감, 포인트 사용에 대해 하나의 자원에 여러 요청이 몰렸을 때 정합성을 보장하기 위한 처리. DB를 이용하여 적절한 lock 사용하기쿠폰 설계 : 정액/정률이라는 여러 정책을 개방/폐쇄 원칙에 맞게 설계하고 주문 단계에 적용하기 공부해야 할 것 Springframework의 Transaction에 대해 알아보기 해야 할 일 이번주 프로젝트를 하면서 고민했던 부분이 Facade 계층에 코드가 너무 많아 지는 것이였는데 application 계층 내에 유효성 검증을 위한 별도 Resolver 를 두도록 코드 리팩토링 resolver를 사용하는 부분 코드 리뷰 요청드리기 :..

이번 글에서는 @Transactional 사용 시 유의해야 할 사항 중 특히 조용한 롤백 현상에 대해 이야기합니다.겉으로는 정상 처리된 것처럼 보이지만 실제로는 데이터가 커밋되지 않는 상황이 발생할 수 있습니다.왜 이런 일이 일어나는지 그리고 이를 어떻게 예방할 수 있는지 살펴봅니다.이커머스, SNS의 "좋아요 수" 등록 기능의 멱등성 처리 설계 "좋아요 등록은 멱등해야 한다."라는 요구사항을 개발하기 위해 DB 유니크 제약을 사용했다. 그래서 아래 단계로 생각하고 코드를 작성했다.1. 좋아요 등록이 되어 있으면 익셉션이 발생할 것이다. 2. 해당 익셉션을 잡아서 비즈니스 익셉션을 발생하게 하면 호출부에서 처리할 수 있겠지//LikeUseCase@Transactionalpublic LikeResult.L..

이번주 이커머스를 구현하면서 당면했던 내용을 정리해본다. JPA를 사용하면서 알아야 하는 것들도메인 중심으로 개발하고 각 도메인이 연결되었을 때 역할, 책임, 경계에 대해 고민하면서 구현하는 한 주였다. 하지만 JPA라는 도구를 사용하면서 JPA엔티티를 도메인 엔티티와 같게 두고 사용하기에 도메인을 DB에 저장할 때 어떤 형태로 어떤 방법으로 할 지에 대한 것도 매뉴얼 적으로 알 필요가 있었다. 1. VO를 JPA/QueryDSL에서 사용할 때 @Convert vs @Embedded AttributeConverter는 VO ↔ DB 컬럼 값 간 변환이 필요할 때 사용하는 것으로, 크게 @Convert, @Embedded 방법이 있다.두 방식의 큰 차이는 Convert는 컬럼 1개로 저장하고, Embedd..

Aggregate 분리를 고민한 이유이커머스 개발을 위한 설계를 진행하면서 시퀀스 다이어그램을 그리는 과정에서 Aggregate에 대해 공부하고 고민하게 되었다.“이 도메인을 하나의 Aggregate로 묶을까, 아니면 분리할까?”시작은 “어떤 Service에 요청해야 할까?” 였다처음에는 단순히 기능 흐름을 정리하려고 시퀀스 다이어그램을 그리고 있었다.그런데 어느 순간 이런 의문이 들었다.“브랜드 정보를 가져올 때, ProductService에 요청해야 할까?아니면 BrandService에 직접 요청해야 할까?”예를 들어, 상품 목록을 조회할 때는 당연히 ProductService를 떠올린다.하지만 실제 화면에는 브랜드 이름과 설명 같은 정보도 함께 필요하다.그렇다면 ProductService가 Bran..

7월 12일부터 시작한 경력자 부트캠프의 1주일이 지났다. 지난 한 주간은 TDD에 대한 것을 주제로 아래 내용을 익혔다. TDD로 범위를 작게 개발하는 것.테스트코드를 작성하는 방법테스트더블을 이용한 테스트코드 법 그리고 일주일이 지난 이번 토요일엔 여러 형태의 코드 리뷰를 받았다.렌 멘토님의 전체 코드 리뷰 : 멤버 한 분의 코드를 보면서 코드리뷰를 했는데 비슷한 고민을 하면서 코드를 작성하기 때문에 공감가는 부분이 많았다. 이 시간에 많은 인사이트를 받았다랜덤 리뷰 : 다른 팀 멤버들과 랜덤하게 조가 편성되어 각자가 받은 PR을 공유했다. 우리 팀은 주제로 이야기를 나눴는데 @Transactional 에 대한 부분과 테스트코드에 대한 이야기를 했다. Transaction의 범위와 readonly=t..

테스트 코드를 작성하면서 배운 것을 작성해봅니다. 단순히 “코드가 잘 돌아가는지 확인하는 용도”를 넘어서 리팩토링의 자신감을 얻고, 테스트 더블을 다루며 다양한 상황을 제어하는 방법을 익혔습니다.또한 Spy와 Mock을 직접 써보면서 둘 사이의 차이를 체감할 수 있었고, 그 차이가 단순한 동작 여부를 넘는다는 것도 알게 되었습니다.아래는 제가 테스트 코드를 작성하면서 정리한 주요 포인트들입니다.목차테스트 코드로 얻는 리팩토링의 안정감테스트 더블(Test Double)이란?Spy와 Mock을 구분하며 느낀 점Spy와 Mock, 단순히 “실제 동작 여부”만의 차이가 아니다 [1] 테스트 코드로 얻는 리팩토링의 안정감처음에는 API 요구사항만 만족하게 코드를 작성했다. 하지만 개발을 진행하며 여러 가지 사항들..

스프링 프레임워크의 핵심적인 역할 중 하나는 의존성 주입(Dependency Injection)을 통해 객체 생성과 관리 책임을 개발자 대신 수행하는 것입니다. 이러한 역할을 가능하게 하는 주체가 ApplicationContext, 즉 스프링의 IoC 컨테이너입니다.이 글에서는 스프링이 애플리케이션 실행 시 어떻게 컴포넌트를 탐색하고, 어떤 방식으로 빈을 등록하는지를 정리했습니다.또한 @Component와 @Bean이 각각 어떤 상황에서 사용되는지, 자동 구성과 명시적 설정의 차이도 작성하였습니다. 스프링은 의존성 주입(DI)을 통해 객체 생성과 관리를 개발자 대신 수행함이 역할을 담당하는 주체는 ApplicationContext, 즉 IoC(의존성주입) 컨테이너애플리케이션 실행 시, 스프링이 컴포넌트를..

TDD 법칙 세 가지실패하는 단위 테스트 를 작성할 때까지 실제 코드를 작성하지 않는다.컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.테스트 코드와 실제 코드가 함께 나올 뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.이런 방식은 결과적으로 실제 코드를 거의 모두 테스트하게 되어, 테스트 코드의 관리가 어려워질 수 있다.따라서 테스트 코드에도 실제 코드와 동일한 품질 기준을 적용하는 것이 중요하다.이번 글에서는 유지보수가 쉬운, 클린한 테스트 코드를 작성하는 방법에 대해 살펴본다. 깨끗한 테스트 코드깨끗한 테스트 코드를 만들려면 가독성이 필요하다!1. 보조 메서드로 중복 제거: 세부구현을 없애고 의도 ..