Unit 5.2 — 수동 트랜잭션 3가지 함정
F-LAB JAVA · 7주차 · Phase 5 · 수동 트랜잭션의 한계
🏆 Phase 5 완주 — 수동 트랜잭션의 결정적 함정
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- 3가지 함정 개요 는?
- 함정 1 — rollback 누락 의 위험은?
- 함정 1 — close 누락 (Connection 누수) 은?
- 함정 2 — 트랜잭션 경계 모호 는?
- 함정 2 — commit 후 외부 작업 의 함정은?
- 함정 3 — 트랜잭션 전파 어려움 은?
- 함정 3 — 중첩 트랜잭션 의 복잡성은?
- 실무 영향과 해결 방향 은?
- Phase 6 (PlatformTransactionManager) 예고 는?
🎯 핵심 한 문장
수동 트랜잭션의 3가지 결정적 함정 — (1) rollback/close 누락 같은 실수 누락 (운영 사고로 직결), (2) 트랜잭션 경계가 모호해 commit 후 외부 API 호출 같은 잘못된 위치의 코드, (3) 메서드 A 가 메서드 B 를 호출할 때 트랜잭션 전파 (새 트랜잭션? 참여? 중첩?) 가 수동으로는 거의 불가능 — 이 세 함정이 @Transactional 의 propagation 옵션과 AOP 자동화의 직접적 동기다.
수동 트랜잭션의 결정적 함정 3가지는 운영 사고와 직결되는 실무 문제다.
함정 1 — 실수 누락:rollback()또는close()누락 시 — Connection 이 풀로 반환 안 되어 Connection 누수 (HikariCP 풀 고갈), 트랜잭션 leak (이상한 데이터 영속), 운영 사고 (서비스 다운).
함정 2 — 트랜잭션 경계 모호: 어디부터 어디까지가 트랜잭션? — commit 후 외부 API 호출 (이메일/Slack/결제) 시, commit 은 됐는데 외부 호출 실패면 일관성 깨짐 (트랜잭션 후 처리 = After Commit 패턴 필요).
함정 3 — 트랜잭션 전파 어려움: 메서드 A 가 메서드 B 호출 시 — B 가 새 트랜잭션? A 의 트랜잭션 참여? 중첩? — 수동으로는 거의 불가능 (전파 정책 자체 표현 X).
이 세 함정이 — @Transactional 의 7가지 propagation 옵션 (REQUIRED / REQUIRES_NEW / NESTED / ...) + AOP 자동화 의 직접적 동기다 (Phase 6-7 에서 해결).
비유 — 셰프의 3가지 실수
3가지 함정 = 셰프의 3가지 실수:
[1] 식기 안 정리 (rollback/close 누락):
- 사고 시 식기 안 치움
- 다음 손님 못 받음 (풀 고갈)
- 부엌 마비
[2] 식기 정리 후 손님 만남 (commit 후 외부):
- 식기 정리 (commit) 끝
- "이메일 보내자" (외부 API)
- 이메일 실패!
- "어, 식기는 정리됐는데?"
- 일관성 깨짐
[3] 다른 셰프 도와줘 (트랜잭션 전파):
- 메서드 A 가 B 부름
- B 도 트랜잭션?
- 둘이 합쳐? 따로?
- 수동으로 표현 어려움
@Transactional 의 답:
- 함정 1: 어노테이션이 알아서 (실수 X)
- 함정 2: @TransactionalEventListener (After Commit)
- 함정 3: propagation 옵션 (REQUIRED/REQUIRES_NEW/NESTED)
ILIC:
- 1020 메서드 × 함정 위험 = 운영 사고 risk
- @Transactional 도입 = 안정성
면접 단골:
- propagation
- 5가지 함정 (Phase 7)
- 프록시 동작→ 3가지 함정 = 실수 + 경계 + 전파, 운영 사고 risk, @Transactional 답.
🧭 9개 섹션 로드맵
1. 3가지 함정 개요
2. 함정 1 — rollback 누락
3. 함정 1 — close 누락 (Connection 누수)
4. 함정 2 — 트랜잭션 경계 모호
5. 함정 2 — commit 후 외부 작업
6. 함정 3 — 트랜잭션 전파 어려움
7. 함정 3 — 중첩 트랜잭션
8. 실무 영향 + 해결 방향
9. Phase 5 완주 + Phase 6 예고1️⃣ 3가지 함정 개요
1.1 3가지 함정
3가지 함정:
함정 1 — 실수 누락:
- rollback 누락
- close 누락
함정 2 — 트랜잭션 경계 모호:
- 어디까지가 트랜잭션?
- commit 후 작업
함정 3 — 트랜잭션 전파 어려움:
- 메서드 A → B 호출
- 새/참여/중첩1.2 함정의 결과
함정의 결과:
함정 1 → 운영 사고:
- Connection 누수
- 풀 고갈
- 서비스 다운
함정 2 → 일관성 깨짐:
- 부분 성공
- 데이터 불일치
- 비즈니스 사고
함정 3 → 코드 복잡 / 버그:
- 의도 불명확
- 재사용 어려움
- 디버깅 ↓1.3 면접 빈도
면접 빈도:
함정 1:
- 기본 (Connection 누수 등)
- 자주 질문
함정 2:
- 중급 (After Commit)
- 가끔
함정 3:
- 고급 (propagation)
- 자주 (시니어급)
Phase 7 에서 7.3 ★ 깊이 = 5가지 함정 (확장)1.4 ILIC 의 맥락
ILIC 의 위험 시나리오 (수동 가정)
ILIC = 102 테이블 × 1020 메서드:
함정 1 (실수):
- 1020 메서드 중 일부 rollback/close 누락
- 운영에서 발견 (사고)
- HikariCP 풀 고갈 (1-2 시간 후)
- 서비스 다운
함정 2 (경계):
- 결제 → DB 업데이트 → 이메일 발송
- 이메일 실패 → DB 만 업데이트
- 사용자에게 알림 X
- 불일치
함정 3 (전파):
- 배송 처리 → 운임 계산 → 이메일
- 각자 트랜잭션?
- 합쳐?
- 코드 복잡
→ 모든 함정 = ILIC 의 운영 위험
→ @Transactional 의 필요성1.5 자기 점검 답변
3가지 함정 개요는?
답:
1. 함정 1:
- 실수 누락
-
함정 2:
- 경계 모호
-
함정 3:
- 전파 어려움
-
결과:
- 운영 사고 / 불일치 / 복잡
2️⃣ 함정 1 — rollback 누락
2.1 rollback 누락의 결과
rollback 누락 결과:
예외 발생했는데 rollback X:
- 트랜잭션 메모리에 (uncommitted)
- DB 락 유지
- Connection 점유 (풀 X)
- 운영 사고
→ 가장 흔한 실수2.2 흔한 실수 코드
// 흔한 실수 (rollback 누락)
public void process() {
try {
tx.begin();
// 비즈니스 로직
throw new RuntimeException("에러");
tx.commit(); // 도달 X
} catch (Exception e) {
// tx.rollback(); ← 빠뜨림!
log.error("Error", e);
throw e;
} finally {
em.close();
}
}
// 결과:
// - 트랜잭션 미완료 상태
// - Connection 풀에서 빌린 상태
// - DB 락 유지
EntityTransaction tx;
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
EntityManager em;
class EntityManager { void close() {} }
org.slf4j.Logger log;2.3 발생 빈도
발생 빈도:
- 신입 개발자 / 급한 코드 / 코드 복사
- 모든 메서드에 같은 패턴 → 한두 개 누락
- 1020 메서드 → 1-5개 누락 가능
운영에서 발견:
- 부하 시 풀 고갈
- 1-2 시간 후 다운2.4 일관성 보정 코드
// 안전한 패턴 (active 체크)
try {
tx.begin();
// 비즈니스
tx.commit();
} catch (Exception e) {
if (tx.isActive()) { // active 체크
tx.rollback();
}
throw new RuntimeException(e);
}
// 또는 finally 에서 (이중 안전)
} finally {
if (tx.isActive()) {
tx.rollback(); // 만약 commit 안 됐으면
}
em.close();
}
EntityTransaction tx;
class EntityTransaction {
void begin() {}
void commit() {}
void rollback() {}
boolean isActive() { return false; }
}
EntityManager em;
class EntityManager { void close() {} }2.5 일부만 rollback (또 다른 실수)
// 또 다른 실수 (특정 예외만 rollback)
try {
tx.begin();
// 비즈니스
tx.commit();
} catch (BusinessException e) {
tx.rollback(); // 비즈니스 예외만
throw e;
}
// catch (RuntimeException e) 없음!
// → 런타임 예외 발생 시 rollback X
// → 트랜잭션 leak
EntityTransaction tx;
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
class BusinessException extends Exception {}2.6 ILIC 의 맥락
// ILIC 에서 실수 위험 (수동, 가정)
@Service
public class ShipmentService {
public void processBatch(List<Long> ids) {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
for (Long id : ids) {
Shipment s = em.find(Shipment.class, id);
s.process();
em.merge(s);
}
tx.commit();
} catch (BusinessException e) {
tx.rollback();
log.error("Business error", e);
throw e;
}
// ❌ RuntimeException 처리 X
// ❌ finally 없음 (em.close X)
// → 운영에서 풀 누수
}
}
class Shipment { void process() {} }
class BusinessException extends Exception {}
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
class EntityManager {
EntityTransaction getTransaction() { return null; }
<T> T find(Class<T> c, Object id) { return null; }
<T> T merge(T t) { return null; }
void close() {}
}
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
org.slf4j.Logger log;2.7 자기 점검 답변
함정 1 — rollback 누락의 위험은?
답:
1. 결과:
- 트랜잭션 leak
-
빈도:
- 흔한 실수
-
시나리오:
- catch 누락 / 부분 처리
-
운영:
- 풀 고갈
3️⃣ 함정 1 — close 누락 (Connection 누수)
3.1 Connection 누수
Connection 누수:
em.close() 또는 conn.close() 누락:
- Connection 풀로 반환 X
- 영원히 점유
결과:
- HikariCP 풀 고갈
- 후속 요청 timeout
- 서비스 다운3.2 누수 시나리오
// 누수 시나리오 1: finally 누락
public void process() {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
// 비즈니스
tx.commit();
} catch (Exception e) {
tx.rollback();
}
// finally 없음!
// em.close() 누락
// → Connection 누수
}
// 누수 시나리오 2: 예외 발생 후
public void process() {
EntityManager em = emf.createEntityManager();
Object data = riskyOperation(); // 예외 발생!
// em.close() 도달 X
em.close();
}
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
class EntityManager {
EntityTransaction getTransaction() { return null; }
void close() {}
}
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
Object riskyOperation() { return null; }3.3 HikariCP 의 동작
HikariCP 의 동작:
풀 크기 = 20:
- Connection 1-20 풀에서 빌림 / 반환
- 사용 후 close() = 반환
누수 시:
- 빌리고 반환 X
- 풀 점차 고갈 (20 → 0)
- 새 요청 = waiting
- 30초 timeout → 에러
운영 모니터링:
- HikariCP 의 metric 추적
- 비정상 시 알람3.4 LeakDetectionThreshold
# 누수 탐지 (HikariCP 설정)
spring:
datasource:
hikari:
leak-detection-threshold: 30000 # 30초
# 동작:
# - Connection 30초 이상 사용
# - 경고 로그
# - 호출 스택 출력
# - 누수 원인 추적3.5 누적 효과
누적 효과:
메서드별 누수 가능성:
- 1020 메서드 × 0.1% 누수 = 1 메서드
- 부하 시 자주 호출 → 누수 ↑
시간 따라:
- 1시간: 풀 50% 사용
- 2시간: 풀 80% 사용
- 3시간: 풀 고갈 → 서비스 다운
→ 운영 사고3.6 ILIC 의 맥락
# ILIC 의 HikariCP 설정
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000
leak-detection-threshold: 30000 # 누수 탐지
# 운영 모니터링:
# - HikariCP metric (active / idle / pending)
# - 누수 시 즉시 경고
# - 비정상 패턴 추적// ILIC 의 자원 관리 (수동 시)
// 보일러플레이트 + 실수 위험 ↑
// @Transactional (실제 사용)
// → Spring 이 자동
// → 누수 X3.7 자기 점검 답변
함정 1 — close 누락 (Connection 누수) 은?
답:
1. 누수:
- 반환 X
-
결과:
- 풀 고갈
-
HikariCP:
- leak-detection-threshold
-
운영 사고:
- 시간 따라 누적
4️⃣ 함정 2 — 트랜잭션 경계 모호
4.1 경계의 중요성
경계의 중요성:
트랜잭션 = ACID 보장 범위:
- begin 부터 commit 까지
- 이 안의 작업은 모두 / 모두 X
경계 모호 시:
- "어디까지 트랜잭션?"
- 헷갈림
- 잘못된 코드 위치4.2 경계 안 vs 밖
// 명확한 예
try {
tx.begin();
// === 트랜잭션 안 ===
em.persist(entity);
em.merge(other);
// === 트랜잭션 안 끝 ===
tx.commit();
} catch (Exception e) {
tx.rollback();
} finally {
em.close();
}
// 트랜잭션 밖:
// - tx.begin 전
// - tx.commit 후
// - tx.rollback 후
EntityTransaction tx;
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
EntityManager em;
class EntityManager {
void persist(Object o) {}
<T> T merge(T t) { return null; }
void close() {}
}
Object entity;
Object other;4.3 모호한 케이스
// 모호 1: commit 후 작업
try {
tx.begin();
em.persist(order);
tx.commit();
// commit 후
sendEmailToCustomer(); // ← 여기 트랜잭션?
// 만약 실패 → 어떻게?
} catch (Exception e) {
tx.rollback();
// 이메일 실패 시 rollback?
// 이미 commit 됐는데?
}
// 모호 2: begin 전 작업
EntityManager em = emf.createEntityManager();
List<Order> orders = repository.findOrders(); // 다른 트랜잭션?
EntityTransaction tx = em.getTransaction();
tx.begin();
// ...
class EntityManager { void persist(Object o) {} void close() {} EntityTransaction getTransaction() { return null; } }
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
EntityTransaction tx;
EntityManager em;
Object order;
void sendEmailToCustomer() {}
Repository repository;
class Repository { java.util.List<Order> findOrders() { return null; } }
class Order {}4.4 시각화의 어려움
시각화의 어려움:
수동 코드에서:
- try/catch 범위
- tx.begin / tx.commit
- 시각적 표시 X
vs 어노테이션:
- @Transactional 명시적
- 메서드 = 트랜잭션
- 명확
→ 자동화의 가치4.5 다른 쓰레드 / 비동기
// 함정: 비동기에 트랜잭션 전달?
try {
tx.begin();
Order order = em.persist(newOrder);
// 비동기 작업
CompletableFuture.runAsync(() -> {
em.merge(order); // ← 다른 쓰레드!
// 다른 EntityManager / 다른 트랜잭션?
});
tx.commit();
} catch (Exception e) {
tx.rollback();
}
// 비동기 작업과 메인 트랜잭션 분리
// 매우 복잡
EntityTransaction tx;
EntityManager em;
class Order {}
Object newOrder;
class CompletableFuture {
static void runAsync(Runnable r) {}
}
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
class EntityManager {
<T> T persist(T t) { return null; }
<T> T merge(T t) { return null; }
}4.6 ILIC 의 맥락
// ILIC 의 트랜잭션 경계 시나리오
@Service
public class ShipmentService {
public void processShipment(Long id) {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
// ① DB 작업 (트랜잭션 안)
Shipment s = em.find(Shipment.class, id);
s.markAsShipped();
em.merge(s);
tx.commit();
// ② commit 후 외부 호출 (트랜잭션 밖)
slackNotifier.notify("Shipped " + id); // 외부 1
emailService.send(s.getCustomerEmail()); // 외부 2
trackingService.register(s.getBlNo()); // 외부 3
// 만약 외부 3 실패 → DB 는 이미 commit
// 일관성 깨짐!
} catch (Exception e) {
if (tx.isActive()) tx.rollback();
throw new RuntimeException(e);
} finally {
em.close();
}
}
}
// → 경계 모호 + 외부 작업 위험
class Shipment {
void markAsShipped() {}
String getCustomerEmail() { return null; }
String getBlNo() { return null; }
}
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
class EntityManager {
EntityTransaction getTransaction() { return null; }
<T> T find(Class<T> c, Object id) { return null; }
<T> T merge(T t) { return null; }
void close() {}
}
class EntityTransaction {
void begin() {}
void commit() {}
void rollback() {}
boolean isActive() { return false; }
}
SlackNotifier slackNotifier;
class SlackNotifier { void notify(String s) {} }
EmailService emailService;
class EmailService { void send(String s) {} }
TrackingService trackingService;
class TrackingService { void register(String s) {} }4.7 자기 점검 답변
함정 2 — 트랜잭션 경계 모호는?
답:
1. 경계:
- begin ~ commit
-
모호:
- 어디까지?
-
시각화 X:
- 수동 코드
-
비동기:
- 더 복잡
5️⃣ 함정 2 — commit 후 외부 작업
5.1 commit 후 외부 호출
commit 후 외부 호출:
시나리오:
1. DB 업데이트 (트랜잭션)
2. commit
3. 이메일 발송 (외부 API)
외부 API 실패 시:
- DB 는 이미 commit
- rollback X (이미 commit)
- 사용자는 알림 못 받음
- 일관성 깨짐5.2 코드 예시
// 문제 코드
try {
tx.begin();
// 1. DB 업데이트
Order order = new Order();
em.persist(order);
tx.commit(); // ← 커밋!
// 2. 이메일 발송 (외부)
emailService.send(order.getEmail());
// 만약 이메일 서비스 다운 →
// 예외 발생
// DB 는 이미 commit
// 사용자에게 알림 X
} catch (Exception e) {
if (tx.isActive()) tx.rollback();
// 이미 commit → rollback 의미 X
throw e;
}
EntityTransaction tx;
class EntityTransaction { void begin() {} void commit() {} void rollback() {} boolean isActive() { return false; } }
EntityManager em;
class EntityManager { void persist(Object o) {} }
class Order { String getEmail() { return null; } }
EmailService emailService;
class EmailService { void send(String s) {} }5.3 반대 패턴 (이메일 먼저)
// 반대 패턴 (이메일 먼저)
try {
tx.begin();
// 1. 이메일 먼저
emailService.send(email); // ← 외부 API 안에서!
// 2. DB 업데이트
em.persist(order);
tx.commit();
} catch (Exception e) {
tx.rollback();
// 이메일은 이미 보냄 (외부 효과)
// rollback 못 함 (메일은 외부)
// 일관성 깨짐
}
// 이메일 보내고 → 트랜잭션 실패 → DB 안 만들어짐
// 사용자: "메일 받았는데 주문 없네?"
EntityTransaction tx;
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }
EntityManager em;
class EntityManager { void persist(Object o) {} }
EmailService emailService;
class EmailService { void send(String s) {} }
String email;
Object order;5.4 해결 방향 — After Commit 패턴
해결 방향:
After Commit 패턴:
- 트랜잭션 commit 후에만 외부 호출
- rollback 시 외부 호출 X
- 일관성 보장
수동으로 구현:
- boolean flag
- 메모리에 작업 큐
- 복잡 / 실수 위험
Spring 의 답:
- @TransactionalEventListener(AFTER_COMMIT)
- 자동 처리5.5 Spring 의 답 (미리보기)
// Spring 의 답 (@TransactionalEventListener)
@Service
public class OrderService {
@Autowired ApplicationEventPublisher publisher;
@Transactional
public void createOrder() {
// DB 작업
Order order = saveOrder();
// 이벤트 발행 (commit 후 처리)
publisher.publishEvent(new OrderCreatedEvent(order));
}
}
// 이벤트 리스너 (commit 후만 실행)
@Component
public class OrderEventListener {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleOrderCreated(OrderCreatedEvent event) {
emailService.send(event.getOrder().getEmail());
// commit 성공 시에만 실행
// rollback 시 실행 X
}
}
// → After Commit 패턴 자동
class Order { String getEmail() { return null; } }
class OrderCreatedEvent {
OrderCreatedEvent(Order o) {}
Order getOrder() { return null; }
}
class ApplicationEventPublisher { void publishEvent(Object e) {} }
ApplicationEventPublisher publisher;
Order saveOrder() { return null; }
class TransactionPhase { static int AFTER_COMMIT = 0; }
@interface TransactionalEventListener { int phase(); }
@interface Transactional {}
EmailService emailService;
class EmailService { void send(String s) {} }5.6 ILIC 의 맥락
// ILIC 의 패턴 (실제 @Transactional 사용)
@Service
public class ShipmentService {
@Autowired ApplicationEventPublisher publisher;
@Transactional
public void processShipment(Long id) {
// DB 작업 (트랜잭션 안)
Shipment s = shipmentRepository.findById(id).orElseThrow();
s.markAsShipped();
// 이벤트 발행 (commit 후 처리)
publisher.publishEvent(new ShipmentShippedEvent(s));
}
}
@Component
public class ShipmentEventListener {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onShipped(ShipmentShippedEvent event) {
// commit 성공 후만 실행
slackNotifier.notify("Shipped");
emailService.send(event.getShipment().getCustomerEmail());
trackingService.register(event.getShipment().getBlNo());
}
}
// 효과:
// - DB commit 실패 → 외부 호출 X
// - DB commit 성공 → 외부 호출
// - 일관성 보장
class Shipment {
void markAsShipped() {}
String getCustomerEmail() { return null; }
String getBlNo() { return null; }
}
ShipmentRepository shipmentRepository;
interface ShipmentRepository { java.util.Optional<Shipment> findById(Long id); }
class ShipmentShippedEvent {
ShipmentShippedEvent(Shipment s) {}
Shipment getShipment() { return null; }
}
ApplicationEventPublisher publisher;
class ApplicationEventPublisher { void publishEvent(Object e) {} }
SlackNotifier slackNotifier;
class SlackNotifier { void notify(String s) {} }
EmailService emailService;
class EmailService { void send(String s) {} }
TrackingService trackingService;
class TrackingService { void register(String s) {} }
@interface Transactional {}
@interface TransactionalEventListener { int phase(); }
class TransactionPhase { static int AFTER_COMMIT = 0; }5.7 자기 점검 답변
함정 2 — commit 후 외부 작업의 함정은?
답:
1. 외부 호출:
- 트랜잭션 밖
-
실패 시:
- rollback 의미 X
-
해결:
- After Commit 패턴
-
Spring:
- @TransactionalEventListener
6️⃣ 함정 3 — 트랜잭션 전파 어려움
6.1 전파 (Propagation) 의 의미
전파 (Propagation):
메서드 A 가 메서드 B 호출 시:
- B 가 트랜잭션 가져야?
- A 의 트랜잭션 참여?
- 새 트랜잭션?
- 중첩?
= 트랜잭션 전파 정책6.2 시나리오 (간단)
// 시나리오:
// A 는 트랜잭션, A 가 B 호출
public void serviceA() {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
// A 의 작업
serviceB(); // ← B 호출
// A 의 작업
tx.commit();
} catch (Exception e) {
tx.rollback();
} finally {
em.close();
}
}
public void serviceB() {
// B 도 트랜잭션 필요?
// - 새로? (B 만의)
// - A 의 트랜잭션 참여? (같은 거)
}
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
class EntityManager { EntityTransaction getTransaction() { return null; } void close() {} }
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }6.3 옵션 1 — 참여 (REQUIRED)
옵션 1 — 참여 (REQUIRED, 가장 일반):
B 는 A 의 트랜잭션 참여:
- A 의 commit 시 B 도 commit
- A 의 rollback 시 B 도 rollback
- 하나의 트랜잭션
수동 구현:
- B 가 A 의 EntityManager 받음
- 또는 ThreadLocal 사용
- 복잡!6.4 옵션 2 — 새 트랜잭션 (REQUIRES_NEW)
옵션 2 — 새 트랜잭션 (REQUIRES_NEW):
B 는 별도 트랜잭션:
- A 는 잠시 정지
- B 가 commit / rollback 후
- A 계속
예시:
- 로그 기록 (반드시 저장)
- A 가 rollback 해도 로그는 남음
수동 구현:
- 별도 EntityManager
- 트랜잭션 시작
- 복잡!6.5 옵션 3 — 중첩 (NESTED)
옵션 3 — 중첩 (NESTED):
B 는 A 의 부분 트랜잭션:
- SAVEPOINT 사용
- B 실패 시 SAVEPOINT 까지만 rollback
- A 는 계속 진행 가능
수동 구현:
- SAVEPOINT 명시
- JDBC 직접
- 매우 복잡6.6 수동의 어려움
// 수동 REQUIRED 구현 시도
public void serviceA() {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
// A 작업
// B 호출 (같은 트랜잭션 참여)
serviceB(em); // ← em 전달
// A 작업
tx.commit();
} catch (Exception e) {
tx.rollback();
} finally {
em.close();
}
}
public void serviceB(EntityManager em) {
// em 받음 (A 의 트랜잭션)
// B 작업
// commit / rollback X (A 가 결정)
}
// 문제:
// - 메서드 시그너처 변경 (em 전달)
// - 모든 호출 체인 변경
// - 매우 침투적
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
class EntityManager { EntityTransaction getTransaction() { return null; } void close() {} }
class EntityTransaction { void begin() {} void commit() {} void rollback() {} }6.7 ILIC 의 맥락
// ILIC 의 전파 시나리오 (수동, 가정)
// 배송 처리 + 운임 계산 + 알림
public void processShipment(Long id) {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
// 1. 배송 업데이트
Shipment s = em.find(Shipment.class, id);
s.markAsShipped();
// 2. 운임 계산 (서비스 호출)
freightService.calculate(em, s); // em 전달!
// 3. 로그 기록 (별도 트랜잭션 원함)
// → 수동으로는?
// → 별도 EntityManager 만들고 별도 begin/commit/close
EntityManager logEm = emf.createEntityManager();
EntityTransaction logTx = logEm.getTransaction();
try {
logTx.begin();
logEm.persist(new ShipmentLog(id, "SHIPPED"));
logTx.commit();
} catch (Exception e) {
if (logTx.isActive()) logTx.rollback();
// 로그 실패 → 메인 트랜잭션은?
} finally {
logEm.close();
}
tx.commit();
} catch (Exception e) {
if (tx.isActive()) tx.rollback();
} finally {
em.close();
}
}
// → 매우 복잡
// → 실수 위험
// @Transactional + propagation
// → 간단
// → 다음 Phase
class Shipment { void markAsShipped() {} }
class ShipmentLog { ShipmentLog(Long id, String s) {} }
FreightService freightService;
class FreightService { void calculate(EntityManager em, Shipment s) {} }
EntityManagerFactory emf;
class EntityManagerFactory { EntityManager createEntityManager() { return null; } }
class EntityManager {
EntityTransaction getTransaction() { return null; }
<T> T find(Class<T> c, Object id) { return null; }
void persist(Object o) {}
void close() {}
}
class EntityTransaction {
void begin() {}
void commit() {}
void rollback() {}
boolean isActive() { return false; }
}6.8 자기 점검 답변
함정 3 — 트랜잭션 전파 어려움은?
답:
1. 전파:
- 메서드 호출 시 정책
-
3 옵션:
- 참여 / 새로 / 중첩
-
수동:
- 거의 불가능
-
@Transactional:
- propagation 옵션
7️⃣ 함정 3 — 중첩 트랜잭션
7.1 중첩 (NESTED) 의 의미
중첩 트랜잭션 (NESTED):
부분 rollback 가능:
- 외부 트랜잭션 안에
- 내부 트랜잭션 (SAVEPOINT)
- 내부 실패 시 SAVEPOINT 까지만 rollback
- 외부는 계속
유용한 케이스:
- "한 단계 실패해도 전체 X"7.2 시나리오
시나리오:
주문 처리 (외부):
- 1. 재고 차감 (내부 - 가능하면)
- 2. 결제 (필수)
- 3. 배송 (필수)
목표:
- 재고 차감 실패해도 결제 / 배송 진행
- 결제 / 배송 실패는 전체 rollback
중첩 트랜잭션:
- 재고 차감 = 내부 (SAVEPOINT)
- 결제 / 배송 = 외부7.3 JDBC SAVEPOINT
// JDBC 의 SAVEPOINT
Connection conn = dataSource.getConnection();
conn.setAutoCommit(false);
try {
// 외부 트랜잭션
// 내부 (SAVEPOINT)
Savepoint savepoint = conn.setSavepoint();
try {
// 재고 차감
updateStock(conn, ...);
} catch (Exception e) {
// 부분 rollback (SAVEPOINT 까지)
conn.rollback(savepoint);
log.warn("재고 차감 실패", e);
}
// 외부 계속
processPayment(conn);
processShipping(conn);
conn.commit();
} catch (Exception e) {
conn.rollback(); // 전체 rollback
} finally {
conn.close();
}
DataSource dataSource;
interface DataSource { Connection getConnection() throws SQLException; }
void updateStock(Connection conn, Object... a) {}
void processPayment(Connection conn) {}
void processShipping(Connection conn) {}
org.slf4j.Logger log;7.4 수동의 복잡성
수동의 복잡성:
- SAVEPOINT 명시
- 부분 rollback 처리
- 예외 분기
- 모든 경우 처리
실수 시:
- 부분 rollback 누락
- 전체 commit / rollback 잘못
- 디버깅 어려움7.5 @Transactional 의 NESTED
// @Transactional NESTED (간단)
@Service
public class OrderService {
@Transactional // 외부
public void createOrder() {
// 1. 외부 트랜잭션
try {
stockService.deduct(); // NESTED
} catch (StockException e) {
// 부분 rollback (자동)
log.warn("재고 차감 실패");
}
// 2. 외부 계속
paymentService.process();
shippingService.create();
// 자동 commit
}
}
@Service
public class StockService {
@Transactional(propagation = Propagation.NESTED)
public void deduct() {
// 부분 트랜잭션
}
}
// → 간단, 어노테이션만
class OrderService {}
class StockService {}
@interface Transactional { Propagation propagation() default Propagation.REQUIRED; }
enum Propagation { REQUIRED, NESTED, REQUIRES_NEW }
class StockException extends RuntimeException {}
StockService stockService;
PaymentService paymentService;
ShippingService shippingService;
class PaymentService { void process() {} }
class ShippingService { void create() {} }
org.slf4j.Logger log;7.6 ILIC 의 맥락
// ILIC 의 중첩 시나리오 (가상)
@Service
public class ShipmentService {
@Transactional // 외부
public void processShipment(Long id) {
// 1. 배송 업데이트
Shipment s = shipmentRepo.findById(id).orElseThrow();
s.markAsShipped();
// 2. 운임 계산 (NESTED - 실패해도 OK)
try {
freightService.calculate(s);
} catch (FreightCalculationException e) {
// 부분 rollback (운임만)
log.warn("운임 자동 계산 실패, 수동 처리 필요");
// 메인 트랜잭션은 계속
}
// 3. 알림 로그
notificationService.logShippedEvent(id);
// 자동 commit
}
}
@Service
public class FreightService {
@Transactional(propagation = Propagation.NESTED)
public void calculate(Shipment s) {
// 부분 트랜잭션
// 실패 시 SAVEPOINT 까지만 rollback
}
}
// → 어노테이션만으로
// → 수동은 매우 복잡
class Shipment { void markAsShipped() {} }
ShipmentRepository shipmentRepo;
interface ShipmentRepository { java.util.Optional<Shipment> findById(Long id); }
FreightService freightService;
class FreightCalculationException extends RuntimeException {}
NotificationService notificationService;
class NotificationService { void logShippedEvent(Long id) {} }
@interface Transactional { Propagation propagation() default Propagation.REQUIRED; }
enum Propagation { REQUIRED, NESTED }
org.slf4j.Logger log;7.7 자기 점검 답변
함정 3 — 중첩 트랜잭션의 복잡성은?
답:
1. 중첩:
- 부분 rollback
-
JDBC:
- SAVEPOINT
-
수동:
- 매우 복잡
-
@Transactional NESTED:
- 간단
8️⃣ 실무 영향 + 해결 방향
8.1 실무 영향 종합
실무 영향:
함정 1 (실수):
- 운영 사고 (Connection 누수)
- 서비스 다운
- 1-2 시간 내 발견
함정 2 (경계):
- 데이터 불일치
- 사용자 경험 ↓
- 비즈니스 사고
함정 3 (전파):
- 코드 복잡
- 재사용 X
- 디버깅 ↓
→ 모두 운영 / 비즈니스 위험8.2 해결 방향
해결 방향:
1. 자동화 (보일러플레이트 X):
- @Transactional 어노테이션
- AOP / 프록시
→ Phase 7
2. 추상화 (인터페이스):
- PlatformTransactionManager
- DataSource 정신
→ Phase 6
3. 전파 정책 명시:
- propagation 옵션
- 7가지
→ Phase 7
4. After Commit:
- @TransactionalEventListener
→ Phase 7 (5가지 함정)8.3 5주차 + 6주차 + 7주차
5주차 + 6주차 + 7주차:
5주차 (패턴):
- DI / OCP / 템플릿+전략
- 프록시
6주차 (DB 접근):
- DataSource
- ACID
- JdbcTemplate (자원 자동)
7주차 Part B (트랜잭션 추상화):
- PlatformTransactionManager (DataSource 정신)
- @Transactional (프록시 + AOP)
- propagation
- = 모든 학습의 응축8.4 실무 선택
실무 선택:
거의 모든 자바 백엔드:
- @Transactional 사용
- 수동 트랜잭션 안 씀
- Spring 의 표준
예외:
- 매우 특수 (수동 제어 필요)
- 미세 튜닝
→ @Transactional 압도적8.5 학습 가치
학습 가치:
수동 트랜잭션 이해 →
@Transactional 의 자동화 가치 절감 →
깊은 이해 →
함정 회피
Phase 7 의 7.3 (5가지 함정):
- 모두 수동의 함정에서 파생
- 어노테이션 시 발생 가능
- 면접 단골8.6 ILIC 의 맥락
ILIC 의 실무
ILIC = @Transactional 표준:
- 102 테이블
- 1020 메서드
- 모두 어노테이션
수동의 함정 학습:
- 함정 의식
- @Transactional 사용 시도 회피
- 깊은 이해
Phase 6-7 학습으로:
- propagation 정책 활용
- After Commit 패턴
- 함정 회피
→ 안정 운영8.7 자기 점검 답변
실무 영향과 해결 방향은?
답:
1. 영향:
- 사고 / 불일치 / 복잡
-
해결:
- 자동화 / 추상화
-
5+6+7주차:
- 응축
-
실무:
- @Transactional 표준
9️⃣ Phase 5 완주 + Phase 6 예고
9.1 Phase 5 학습 종합
🔧 Phase 5 — 수동 트랜잭션의 한계
Unit 5.1 — 결합 문제:
- 비즈니스 + 인프라 혼재
- SoC 위반
- 보일러플레이트
Unit 5.2 — 3가지 함정 ← 여기:
- 함정 1: 실수 누락
- 함정 2: 경계 모호
- 함정 3: 전파 어려움
→ 수동 트랜잭션의 결정적 한계
→ 자동화의 동기9.2 핵심 메시지
Phase 5 핵심 메시지:
"수동 트랜잭션은 비즈니스 로직과 인프라의 결합 +
실수 누락 + 경계 모호 + 전파 어려움 의 4 결정적 문제.
이 4 문제 모두를 풀어주는 게 Spring 의 트랜잭션 추상화."9.3 Phase 6 예고
🎯 Phase 6 — PlatformTransactionManager (3 Unit)
Unit 6.1 — 인터페이스 추상화:
- PlatformTransactionManager
- 5주차 DI / DIP 정신
- 6주차 DataSource 와 같은 사상
Unit 6.2 — 3가지 구현체:
- DataSourceTransactionManager (JDBC)
- HibernateTransactionManager (Hibernate)
- JpaTransactionManager (JPA)
Unit 6.3 — 사용 전후 비교:
- 수동 vs PlatformTransactionManager
- 코드 개선9.4 Phase 6 의 가치
Phase 6 의 가치:
- 트랜잭션의 인터페이스 추상화
- 5주차 DI / DIP / OCP 정신
- 6주차 DataSource 와 같은 사상
- @Transactional 의 기반
→ 이해 깊이 ↑9.5 Phase 6 → Phase 7
Phase 6 → Phase 7:
Phase 6:
- 인터페이스 추상화 (TM)
- 수동에서 한 단계 자동
Phase 7 (★★★ 핵심):
- @Transactional
- 프록시 + AOP
- 5가지 함정
- 면접 단골
→ 점진적 추상화
→ Phase 7 가 정점9.6 7주차 진행
🗂️ Part A — 데이터 모델링과 ORM (완주)
✅ Phase 1-4 (16)
🔄 Part B — 트랜잭션 추상화의 진화
✅ Phase 5 (2) ← 여기, 완주!
⏭ Phase 6 (3)
⏭ Phase 7 (3) — 모두 ★깊이
총: 18/24 Unit (75%, Phase 5 완주!)9.7 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 3가지 함정? | 실수 / 경계 / 전파 |
| rollback 누락? | 트랜잭션 leak |
| close 누락? | Connection 누수 |
| 풀 고갈? | 서비스 다운 |
| commit 후 외부? | After Commit |
| @TransactionalEventListener? | AFTER_COMMIT |
| 트랜잭션 전파? | REQUIRED 등 |
| NESTED? | SAVEPOINT |
| @Transactional 답? | 모두 해결 |
| Phase 6-7? | 추상화 + 자동화 |
9.8 자기 점검 체크리스트
함정 1 (실수)
- rollback / close
Connection 누수
- 풀 고갈
함정 2 (경계)
- commit 후
After Commit
- 패턴
함정 3 (전파)
- 메서드 호출
NESTED
- SAVEPOINT
영향
- 실무 위험
해결
- @Transactional
Phase 6 예고
- PlatformTransactionManager
9.9 추가 심화 질문
Q1: 트랜잭션 leak 의 발견?
답:
- HikariCP metrics (active / idle)
- leak-detection-threshold
- 운영 모니터링 (APM)
- 로그 분석
Q2: After Commit 의 구현 방법?
답:
- TransactionSynchronization
- @TransactionalEventListener
- 수동: synchronizationManager.registerSynchronization()
Q3: 트랜잭션 격리 레벨?
답:
- READ UNCOMMITTED (가장 약함)
- READ COMMITTED
- REPEATABLE READ
- SERIALIZABLE (가장 강함)
- DB 별 기본 다름 (MySQL = REPEATABLE READ)
Q4: 분산 트랜잭션 (XA)?
답:
- 여러 DB 동시 트랜잭션
- 2PC (Two-Phase Commit)
- 복잡 / 성능 ↓
- 마이크로서비스 환경: Saga 패턴 권장
Q5: read-only 트랜잭션?
답:
- @Transactional(readOnly = true)
- 성능 최적화 (snapshot)
- 변경 X (Dirty Checking X)
- 조회 전용
🎯 핵심 요약 — 3줄 정리
1. 3가지 함정
- 함정 1: rollback/close 누락 → Connection 누수, 풀 고갈, 서비스 다운
- 함정 2: 트랜잭션 경계 모호 → commit 후 외부 작업 실패, 일관성 깨짐
- 함정 3: 트랜잭션 전파 어려움 → 메서드 호출 시 참여/새로/중첩 표현 X
2. 실무 영향
- 운영 사고 (Connection 누수, 서비스 다운)
- 데이터 불일치 (commit 후 외부 호출 실패)
- 코드 복잡 (전파 정책 수동 구현 불가능)
3. 해결 방향
- Phase 6: PlatformTransactionManager (인터페이스 추상화, 5주차 + 6주차 정신)
- Phase 7: @Transactional (프록시 + AOP + propagation 7가지)
- @TransactionalEventListener (After Commit 패턴)
- 자바 백엔드의 표준
🏆 Phase 5 완주 — 수동 트랜잭션의 한계
🔧 Phase 5 — 수동 트랜잭션의 한계
✅ Unit 5.1 트랜잭션이 비즈니스 로직과 결합
✅ Unit 5.2 수동 트랜잭션 3가지 함정 ← 여기, Phase 5 완주
→ 수동의 결정적 한계 이해
→ 자동화의 동기 정확히 인식
→ Phase 6 (인터페이스 추상화) 의 기반📚 다음으로...
Phase 6 — PlatformTransactionManager
🎯 Phase 6 — PlatformTransactionManager (3 Unit)
Unit 6.1 — 인터페이스 추상화
Unit 6.2 — 3가지 구현체 (DataSource/Hibernate/JPA TM)
Unit 6.3 — 사용 전후 비교Phase 6 주제:
- Spring 의 트랜잭션 추상화
- PlatformTransactionManager 인터페이스
- 3가지 구현체 (JDBC / Hibernate / JPA)
- 5주차 DI + 6주차 DataSource 정신
- @Transactional 의 기반
7주차 누적 진행
🗂️ Part A — 데이터 모델링과 ORM (완주)
✅ Phase 1-4 (16)
🔄 Part B — 트랜잭션 추상화의 진화
✅ Phase 5 (2) ← 완주
⏭ Phase 6 (3)
⏭ Phase 7 (3) — 모두 ★깊이
총: 18/24 Unit (75%, Phase 5 완주!)🏆 Phase 5 완주 — 수동 트랜잭션의 한계
Software Developer