[TIL] 프로젝트 5일차.. 배송 관련 로직 더 생각해보기..

🌞 오늘은 어떤 하루였지..

MVP 구현한 것 중에서 부족한 부분을 채워 넣고 GlobalExceptionHandler를 활용해서 예외 처리들을 수정했다.

택배사, 출고지(물류센터), 배송, 송장 도메인을 천천히 둘러보면서 빠진 로직은 추가하고, 좀 더 효율적일 수 있도록 수정을 진행했다.
그 과정에서 추가적으로 재고 부분을 맡기로 해서 어디에 재고 관련 로직이 들어가면 좋을지 생각도 해봤다.

아직 로직이 확실하게 머리에 잡히지 않아서 계속 생각을 해봐야 할 것 같다.

 

💡 새롭게 알게 된 내용은 뭐가 있더라..?!

💡 findById() vs getReferenceById() 차이 완전 정리

Spring Data JPA를 사용할 때, 엔티티를 조회하는 방법으로 findById()와 getReferenceById()가 있다.
두 메서드는 유사해 보이지만 동작 방식과 사용 시 주의사항이 다르다.

✅ 기본 설명

메서드	설명
findById()	즉시 DB에서 조회하여 실제 엔티티를 반환. Optional<T> 형태로 반환됨
getReferenceById()	프록시 객체 반환. 실제 필드에 접근하는 순간 DB에서 조회됨 (Lazy Loading)

✅ 사용 예시

📌 findById()

Courier courier = courierRepository.findById(id)
    .orElseThrow(() -> new RuntimeException("존재하지 않는 택배사입니다."));

• DB에 즉시 쿼리가 실행됨
• 존재하지 않으면 바로 예외를 던질 수 있음

📌 getReferenceById()

Courier courier = courierRepository.getReferenceById(id);

• 쿼리가 바로 실행되지 않음
• 실제로 courier.getName()처럼 필드에 접근할 때 DB 조회가 일어남
• 해당 ID가 존재하지 않을 경우, 그때 EntityNotFoundException 발생

✅ 차이점 비교표

항목 findById() getReferenceById()

항목	findById()	getReferenceById()
반환 객체	Optional<T>	프록시 객체 (T)
DB 접근 시점	즉시 쿼리 실행	실제 필드 접근 시점
예외 발생 시점	조회 즉시 orElseThrow()	필드 접근 시점
트랜잭션 필요 여부	없어도 가능	반드시 필요 (Lazy Loading)
주요 사용 용도	엔티티 실제 조회	참조만 필요한 경우 (ex. 외래 키 매핑 등)

✅ 사용 시점 추천

상황 추천 메서드 이유

상황	추천 메서드	이유
엔티티를 실제로 사용해야 할 때	findById()	안정적이고 명확한 예외 처리 가능
연관 엔티티를 단순히 매핑할 때 (필드 접근 안 할 때)	getReferenceById()	프록시만 주입하므로 성능 효율적
존재 여부만 먼저 확인하고 싶은 경우	existsById() + getReferenceById()	단, 쿼리 2번 발생하므로 상황에 따라 조정

⚠️ 주의사항

• getReferenceById()는 트랜잭션이 유지되지 않으면 LazyInitializationException이 발생할 수 있다.
• getReferenceById()로 반환된 프록시는 필드 접근 시점에 예외가 발생하므로 디버깅이 어려울 수 있다.
• 실무에서는 대부분 findById().orElseThrow() 방식이 더 안정적이다.

✨ 결론

• 일반적인 CRUD 처리에서는 findById() 사용을 기본으로 하자.
• 성능을 미세하게 최적화하거나, 연관 관계만 맺고 필드 접근이 없는 경우에는 getReferenceById()도 유효하다.

🔖 마무리 요약

❗ findById()는 지금 당장 DB에서 꺼내오는 방식
❗ getReferenceById()는 "필요하면 가져올게"라는 지연 로딩 방식

 

🔒 락 경합 (Lock Contention)이란?

✅ 개념

• "여러 트랜잭션이 동시에 같은 자원(레코드)을 잠그려 하면서 충돌이 발생하는 현상"
• 대표적으로 비관적 락(FOR UPDATE) 사용 시 발생

✅ 예시 상황

• 상품 재고가 5개인데 100명이 동시에 배송을 요청함
• 첫 번째 트랜잭션이 락을 잡는 동안 나머지는 대기
• 이로 인해 시스템 응답 지연, 타임아웃, 커넥션 경합이 발생

❌ 문제점

• 대기 시간 증가 → 사용자 응답 지연
• 락 대기 중 트랜잭션이 너무 오래 머무르면 LockTimeoutException 발생 가능
• 락 대기 수가 많아지면 DB 커넥션 고갈 위험

🔧 해결 방법

• 트랜잭션 범위 최소화: 불필요한 작업은 락 밖에서 처리
• 락 타임아웃 설정 (innodb_lock_wait_timeout)
• 자원별로 분리된 락을 사용하여 충돌 분산 (ex. 상품 ID 단위로 락)
• 성능이 중요한 경우 낙관적 락 또는 메시지 큐 방식으로 구조 전환 고려

 

🗓️ 내일은 뭐 하지?!