비관적 락은 “이 데이터는 충돌할 가능성이 높다”고 보고, 한 트랜잭션이 수정하려는 데이터를 잡고 있는 동안 다른 트랜잭션이 기다리게 만드는 방식Transaction ASELECT ... FOR UPDATE→ Product 행 Lock 획득Transaction B같은 Product 조회 시도→ 기다림A재고 차감COMMIT→ Lock 해제B이제 조회→ A가 반영한 최신 재고 확인→ 차감 1. 왜 이름이 "비관적" 락일까?처음부터 "여러 사용자가 같은 데이터를 동시에 수정하면 충돌할 가능성이 높다"고 생각하기 때문.그래서 충돌이 실제로 일어난 뒤 처리하는 것이 아니라, "아예 먼저 잠가놓고 다른 트랜잭션이 기다리게 하자"는 접근 2. 문제 상황DB stock = 100Transaction ASELECT ..

목표초기 재고를 100이라 한다. `stock = 100`100번 차감하면 정상적인 결과는 `100 - 100 = 0`이다.그런데 여러 스레드가 동시에 `stockService.decrease(productId);`를 호출하게 한 뒤 최종 재고를 확인한다.기대값 = 0실제값 = ?예: 73 81 64 ... 일반 테스트로는 순차 실행되기 때문에 동시성 문제를 재현하기 어렵다.Thread A ──────────┐Thread B ──────────┤Thread C ──────────┤ 동시에 같은 재고 접근Thread D ──────────┤... │Thread N ──────────┘위와 같은 상황을 만들어야하기 때문에, `ExecutorService`, `Cou..

1. 동시성(Concurrency)여러 작업이 같은 시간대에 겹쳐서 진행되는 상황 예를 들어 쇼핑몰에 재고가 1개 남았는데, 사용자 A의 구매 요청과 사용자 B의 구매 요청이 거의 동시에 들어오는 경우이다.서버에서는 각 요청을 서로 다른 스레드가 처리할 수 있다.요청 A → Thread A 요청 B → Thread B두 스레드가 동시에 같은 상품의 재고를 읽고 수정하게 될 수 있다. 2. 공유 데이터동시성 문제가 생기려면 중요한 조건이 있다.여러 실행 흐름이 같은 데이터를 공유한다. // Productstock = 10Thread A, B 둘 다 같은 상품을 본다.즉 두 요청이 서로 완전히 독립적인 데이터만 다룬다면, 이런 충돌이 일어나지 않을 수 있다.문제는 `여러 요청 → 같은 상품 → 같은 st..

@Transactional 시작 ↓ Entity 조회 ↓ Entity가 영속 상태가 됨 ↓ Entity의 값 변경 ↓ JPA가 변경을 감지 ↓ flush ↓ UPDATE SQL 실행 ↓ commit 1. JPA에서 `findById()`를 하면 무슨 일이 일어날까?평소에는 보통 이렇게 생각한다.Product product = productRepository.findById(productId).orElseThrow();단순하게 보면 `DB에서 Product를 가져온다`고 생각할 수 있다.그런데 JPA에서는 한 가지 일이 더 있다.조회한 `Product` 객체를 영속성 컨텍스트가 관리하기 시작할 수 있다.Database │ │ SELECT ▼Pro..

여러 DB 작업이 하나의 업무를 구성한다면, 일부만 성공한 상태가 남지 않도록 하나의 트랜잭션으로 묶을 수 있다. 1. 트랜잭션이란?하나의 논리적인 작업 단위 계좌 이체를 생각해보자.A가 B에게 10,000원을 보낸다. DB에서는 실제로 두 작업일 수 있다.A 계좌 100,000 → 90,000 B 계좌 50,000 → 60,000 그런데 첫 번째 작업만 성공하고 두 번째 작업이 실패하면, A는 잔고가 10,000원 감소하고 B는 그대로가 된다.돈이 사라진 것이다. 그래서 이 두 작업을 `A 잔액 차감 + B 잔액 증가` 하나의 업무로 본다.결과도 둘 중 하나여야 한다. (둘 다 성공 or 둘 다 실패) 2. 주문도 마찬가지쿠폰 사용 → 재고 차감 → 포인트 차감 → 주문 저장각각은 다른 DB 변경일 ..

Controller ↓Application Service ↓Domain ↓Repository Interface ↓Infrastructure / Repository 구현체 각 계층은 왜 존재하는가?Application Service와 Domain은 무엇이 다른가?Repository Interface는 왜 두는가?DIP는 왜 필요한가? 1. Layered Architecture란?계층형 아키텍처. 프로그램의 역할을 여러 층으로 나누는 구조.Spring Boot에서 흔히 보는 구조는 `Controller → Service → Repository → Database`이다.이것도 대표적인 Layered Architecture인데, 각 계층에 다른 책임을 준다. 2. 왜 굳이 계층을 나누나?아주 극단적인 코드를..

객체는 단순히 데이터를 담는 통이 아니라, 가능하면 자기 데이터와 관련된 규칙도 함께 책임지게 할 수 있다. 1. 도메인이란 무엇인가?우리가 프로그램으로 해결하려는 업무 영역 쇼핑몰이라면 `주문`, `상품`, `재고`, `쿠폰`, `결제`, `회원`, `배송`과 같은 것들이 쇼핑몰이라는 업무 영역, 즉 도메인에 속한다.은행 시스템이라면 `계좌`, `이체`, `잔액`, `대출`, `예금`과 같은 개념들이 있을 것이다.따라서 `Product`, `Coupon`, `Order` 같은 클래스는 단순히 Java 클래스를 하나 만든 것이 아니라 실제 업무 개념을 코드로 표현한 것이라고 볼 수 있다. 2. 도메인 객체란?public class Product { private int stock;}이 객체는 `..

규칙들을 어떤 순서로 실행해야 하는가? 백엔드 기능은 여러 작업을 단순히 나열하는 것이 아니라, 실행 순서와 실패 시 남는 상태까지 생각해서 설계해야 한다.예를 들어 주문 하나에도 `쿠폰 검증`, `재고 차감`, `포인트 차감`, `주문 저장` 과 같은 작업들이 있을 수 있다.중요한 것은 "전부 다 실행하면 되지." 하는 게 아니다.무엇을 먼저 해야 하지? 중간에 실패하면 어떻게 되지? 순서를 바꾸면 어떤 문제가 생기지? Seqence Diagram이란?누가 누구를 어떤 순서로 호출하는지 시간 흐름에 따라 그려놓은 그림 아주 단순한 상품 조회 API를 예로 들면,Client | | GET /products/1 vController | | findProduct(1) vProductS..

이미 사용된 쿠폰은 사용할 수 없다. 이런 요구사항이 있다고 예를 들자.if (coupon.isUsed()) { ...} 바로 위와 같은 코드를 생각하는 것이 아니라,먼저 이렇게 생각해야 한다.누가 사용하는가?어떤 상태여야 사용할 수 있는가?사용하면 상태가 어떻게 바뀌는가?어떤 경우에 실패해야 하는가?실패하면 기존 상태는 어떻게 되어야 하는가? 왜 요구사항을 바로 코드로 옮기면 안될까?자연어 요구사항은 생각보다 모호하다.`쿠폰을 사용할 수 있다.` 이 문장만 보고 구현하면 여러 질문이 빠진다.누가 사용할 수 있지?본인 쿠폰만 가능한가?이미 사용한 쿠폰은?존재하지 않는 쿠폰은?유효기간은?사용한 뒤에는 어떤 상태가 되지?실패했을 때 상태는? 개발자가 이런 것을 정리하지 않고 바로 구현하면 코드 안에서..