I AM Seung Hyeon

백엔드 시스템에서 시간(Time)은 생각보다 훨씬 까다로운 주제이다.특히 다음과 같은 상황에서는 문제가 자주 발생한다.서버는 한국(KST)인데, 사용자는 해외에 있음DB에 저장된 시간이 환경마다 다르게 보임로컬에서는 정상인데, 운영 서버에서 시간이 9시간 어긋남로그, 배치, 만료 시간 계산이 뒤틀림“모든 내부 시간은 UTC로 저장하고, 보여줄 때만 변환한다.” 1. 왜 UTC로 통일해야 하는가?로컬 타임존(KST 등)으로 저장할 때 문제점서버 위치가 바뀌면 시간 기준이 달라진다컨테이너(Docker), 클라우드 환경에서 TZ 설정 누락 시 오동작여러 국가 사용자 서비스 시 시간 계산이 복잡해진다서머타임(DST) 문제 발생 가능UTC로 저장하면 얻는 장점서버 위치와 무관한 일관성DB, 로그, 배치, 캐시 ..

1) 한 줄 정의@Transactional(readOnly = true)는 해당 트랜잭션이 읽기 전용임을 트랜잭션 관리자에게 힌트로 제공해,런타임에 알맞은 최적화를 가능하게 하는 설정이다.이 값은 기본값이 아니며, 명시하지 않으면 읽기/쓰기 트랜잭션으로 동작한다.이 설정은 어디까지나 힌트이므로, 구현체가 이를 해석하지 못하면 무시될 수 있다. 2) 무엇이 최적화되는가(1) JPA/Hibernate 관점Spring + Hibernate 조합에서 읽기 전용 트랜잭션을 사용하면 일반적으로 세션 Flush 모드가 MANUAL로 바뀌고,기본 읽기 전용 플래그를 활용하여 Dirty Checking(변경 감지)을 최소화한다.그 결과 스냅샷 보관이 줄거나 생략되어 메모리/CPU 사용량이 감소한다.Flush가 자동으로..

웹 애플리케이션에서 데이터를 조회할 때, 수만 건 이상의 데이터를 한 번에 내려받는 것은 매우 비효율적이다.이런 경우에 사용하는 대표적인 기법이 바로 페이지네이션(Pagination)이다.페이지네이션이란? 페이지네이션은 대량의 데이터를 페이지 단위로 나누어 사용자에게 제공하는 방식이다.예를 들어, 데이터베이스에 10,000건의 로그가 있을 때, 이를 한 번에 모두 내려받기보다 20개씩 나눠서 보여주는 방식이다.이를 통해 메모리 사용을 줄이고, 사용자 경험을 개선하며, 네트워크 비용도 줄일 수 있다.Spring Data JPA에서 페이지네이션 구성 요소Spring Data JPA는 페이지네이션을 위해 여러 유틸리티를 기본 제공한다. 대표적으로 아래 3가지가 있다. 1. Pageable 인터페이스페이지 요청..

Spring Data JPA를 사용하다 보면 전체 데이터를 삭제해야 할 때 deleteAll()과 deleteAllInBatch() 두 가지 메서드 중 무엇을 써야 할지 고민하게 된다두 메서드는 이름만 보면 비슷해 보이지만, 동작 방식, 성능, 주의사항 모두 다르기 때문에 잘 구분해서 사용해야 한다 1️⃣ deleteAll() — 하나씩 순회하며 삭제userRepository.deleteAll();내부적으로는 findAll()로 모든 데이터를 조회한 뒤,for 루프로 한 건씩 EntityManager.remove() 호출즉, n개의 delete 쿼리가 실행된다✅ 특징JPA가 영속성 컨텍스트를 유지한 채 개별 엔티티를 추적엔티티 리스너, 연관된 Cascade, orphanRemoval 등 모두 동작❗ 단점..