지난 글에서는 트랜잭션 전파 옵션(REQUIRED, REQUIRES_NEW, NESTED 등)을 통해 트랜잭션이 어떻게 전파되고 분리되는지 살펴봤다. 이번 글에서는 한 걸음 더 나아가, 트랜잭션이 실패했을 때 어떻게 처리되는가를 다룬다.이번 글에서 다룰 핵심 질문은 다

지금까지 트랜잭션의 기초(14단계), 격리 수준(15단계), 낙관적/비관적 락(16단계)을 거치면서 트랜잭션이 어떻게 시작되고, 어떻게 서로를 보호하는지 익혔다.이번에는 조금 다른 질문을 다룬다.ServiceA가 ServiceB를 호출할 때, 트랜잭션은 몇 개가 생겨야

지난 글에서 트랜잭션 격리 수준의 개념을 정리했다. Dirty Read, Non-Repeatable Read, Phantom Read가 각각 어떤 상황에서 발생하는지, 어떤 격리 수준이 이를 막는지 표로 정리했었다.그런데 이론만으로는 뭔가 찜찜하다. 실제로 발생하는지

지난 글에서 트랜잭션 격리 수준으로 동시성 문제를 1차적으로 방어하는 방법을 살펴봤다.그런데 Repeatable Read로 격리 수준을 올려도 여전히 해결되지 않는 문제가 있다.재고가 10개인데 동시에 100명이 주문하면?티켓팅에서 같은 좌석을 동시에 두 명이 선택하면

지난 글에서 @Transactional의 동작 원리와 전파 방식을 살펴봤다.트랜잭션이 "하나의 논리적 작업 단위"라는 건 알겠는데, 여러 트랜잭션이 동시에 실행되면 어떤 일이 벌어질까?이번 글에서는 아래 질문들을 다룬다.동시에 100명이 같은 데이터에 접근하면 무슨 일

지난 글에서는 Spring AI의 Advisor 패턴과 Function Calling을 다뤘다. 이번 글에서는 잠시 AI 주제에서 벗어나, 백엔드 개발의 가장 기본적인 안전장치 중 하나인 트랜잭션을 짚고 넘어간다.이런 질문들을 생각해보자.트랜잭션이 왜 필요한가?Spri

지난 글에서 Redis가 In-Memory 저장소로서 빠른 속도를 제공하고, 다양한 데이터 타입과 캐싱 전략을 통해 어떻게 시스템 성능을 끌어올리는지 살펴봤다. 그런데 여기서 자연스럽게 의문이 생긴다.Redis는 메모리에 저장하는데, 서버가 꺼지면 데이터는 어떻게 되는

지난 글에서는 Redis의 핵심 데이터 타입을 살펴봤다. String, List, Set, Hash, Sorted Set이 각각 어떤 문제를 해결하는지, 왜 Redis 안에서 직접 처리하는 게 빠른지를 이해했다.이번 글에서는 한 발 더 나아가 Redis를 캐시로 활용하

지난 글에서는 HTTP Session의 한계와 Redis를 세션 저장소로 활용하는 방법을 살펴봤다. Redis가 세션 관리에 적합한 이유는 In-Memory 저장소 특성상 매 요청마다 조회되는 세션 데이터를 빠르게 처리할 수 있기 때문이었다.이번 글에서는 Redis를

지금까지 Spring MVC 흐름, JPA, 트랜잭션을 공부하면서 서버가 요청을 처리하는 방식을 살펴봤다. 그런데 한 가지 의문이 생긴다. 우리가 매일 쓰는 쇼핑몰에서는 로그인이 유지되고 장바구니도 사라지지 않는다. HTTP는 Stateless라고 했는데, 이게 어떻게

지난 글에서는 Spring AI의 Advisor 패턴과 Function Calling을 통해 LLM이 외부 도구를 활용하는 방법을 살펴봤다. 그런데 도구를 쓸 수 있다고 해서 에이전트가 되는 건 아니다.이번 글에서는 다음 질문들을 중심으로 Agentic Workflow

지난 글에서는 RAG(Retrieval-Augmented Generation)를 통해 LLM이 외부 문서를 참조해서 답변하는 방법을 배웠다. 이번 글에서는 한 단계 더 나아간다.이런 질문들을 생각해보자.대화 기록 저장, 욕설 필터링 같은 공통 로직을 매번 Service

지난 글에서는 Vector DB와 임베딩을 다뤘다. 텍스트를 숫자 배열로 변환해서 의미 기반 유사도 검색을 할 수 있다는 것, 그리고 기존 LIKE 검색이 왜 의미 파악에 한계가 있는지를 살펴봤다.이번 글에서는 그 Vector DB를 실제로 활용하는 패턴인 RAG를 다

10단계에서 LLM은 Stateless하기 때문에 매 요청마다 컨텍스트를 직접 전달해야 한다고 배웠다. 그런데 컨텍스트가 길어질수록 토큰 비용이 폭증하고, 필요한 정보만 골라서 전달해야 한다는 문제가 남아 있었다.이번 글에서는 그 해결책의 핵심인 Vector DB를 다

지금까지 Spring AI로 Gemini와 OpenAI 같은 클라우드 API를 연동해봤다.ChatClient 하나로 다양한 모델을 추상화해서 쓸 수 있다는 것도 확인했다.그런데 이런 의문이 생길 수 있다.클라우드 API를 쓰면 데이터가 외부 서버로 나가는데, 민감한 정

지난 글에서는 LLM과 대화를 설계하는 방법을 다뤘다. System / User / Assistant 세 가지 메시지 타입을 이해하고, 히스토리를 어떻게 구성해야 AI가 맥락을 잘 이해하는지 살펴봤다.그런데 히스토리를 쌓다 보면 자연스럽게 이런 의문이 생긴다.대화가 1

지난 글에서 Spring AI의 기본 구조와 ChatClient를 통해 LLM에 질문을 던지는 방법을 살펴봤다.그런데 막상 챗봇을 만들려고 하면 이런 의문이 생긴다.AI는 내가 아까 뭐라고 했는지 기억하는가?대화가 길어질수록 비용이 얼마나 늘어나는가?어떻게 해야 AI가

지금까지 IoC/DI, Bean, Spring MVC 흐름을 익히면서 Spring이 "복잡한 것을 추상화해서 개발자가 비즈니스 로직에 집중하게 해준다"는 철학을 반복해서 봐왔다. 오늘은 그 철학이 AI 영역에서 어떻게 적용되는지를 다룬다.이번 글을 읽으면서 스스로에게

지난 글에서 JPA의 기본 구조와 엔티티 매핑, 그리고 @Transactional의 존재를 처음 만났다. 그런데 코드를 짜다 보면 이런 의문이 생긴다.product.decreaseStock()만 호출했는데 왜 DB에 UPDATE가 날아가지?save()를 안 불렀는데 어

이전 글에서 Spring MVC 흐름, JPA, 영속성 컨텍스트까지 살펴봤다. 이번 글에서는 그 위에 실전 코드를 올린다. 다음 세 가지 질문을 중심으로 이야기를 풀어간다. 반복적인 Getter/Setter/생성자 코드를 어떻게 없앨 수 있을까? 잘못된 데이터가 S