대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 웹 환경은 수많은 고객이 동시에 요청을 보내는 특성을 가진다. 이러한 환경에서 스프링이 어떻게 수만 개의 객체 요청을 효율적으로 처리하는지 그 핵심 원리인 싱글톤 컨테이너에 대해 알아본다.1. 웹 애플리케이션과 싱글톤의 필요성 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성한다. 만약 고객 트래픽이 초당 100회 발생한다면, 초당 100개의 서비스 객체가 생성되고 소멸되어야 한다. 이는 심각한 메모리 낭비를 초래한다. 이 문제를 해결하기 위해 해당 객체가 딱 1개만 생성되고, 이를 공유하도록 설계하는 것이 바로 싱글톤 패턴(Singleton Pattern)이다.2. 스프링 컨테이너: 싱글톤 레지스트리 직접 자..

지금까지는 개발자가 직접 AppConfig 객체를 생성하고 의존관계를 주입하였다. 이제부터는 스프링 프레임워크의 핵심인 스프링 컨테이너에 이 역할을 맡기는 방법을 알아본다.1. 스프링 컨테이너로의 전환순수 자바 기반의 AppConfig를 스프링 기반으로 변경하기 위해서는 두 가지 어노테이션이 필요하다.@Configuration: 해당 클래스를 설정을 구성하는 정보로 사용하겠다는 선언이다.@Bean: 메서드를 호출하여 반환된 객체를 스프링 컨테이너에 등록하라는 지시어이다.@Configurationpublic class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(memberR..

앞선 글에서 살펴본 것처럼, 구현 객체가 스스로 다른 구현 객체를 생성하고 연결하는 구조는 DIP와 OCP 원칙을 위반한다. 이 문제를 해결하기 위해 애플리케이션의 전체 동작 방식을 구성하고 객체 간의 관계를 설정하는 별도의 존재가 필요하다.1. 관심사의 분리 (Separation of Concerns) 애플리케이션을 하나의 공연이라고 가정해본다. 이전의 설계는 로미오 역할을 맡은 배우가 줄리엣 역할을 할 배우를 직접 초빙하는 것과 같았다. 즉, 배우가 연기라는 본연의 책임 외에 '상대 배우 캐스팅'이라는 과도한 책임까지 지고 있었던 것이다.배우: 자신의 배역을 수행하는 것에만 집중해야 한다. 어떤 상대 배우가 오더라도 똑같이 공연할 수 있어야 한다.공연 기획자: 공연을 구성하고, 담당 배우를 섭외하며,..

스프링의 필요성을 체감하기 위해, 스프링 프레임워크의 도움 없이 순수 자바(Pure Java)만으로 비즈니스 요구사항을 구현해 본다. 이 과정에서 다형성을 활용한 설계가 실제 운영 환경에서 어떤 한계에 부딪히는지 확인하는 것이 핵심이다.1. 비즈니스 요구사항과 설계우리가 구현할 시스템은 회원 가입, 조회 기능과 등급별 할인 정책을 포함한 주문 서비스이다.1.1. 회원 도메인 요구사항회원 등급: 일반(BASIC), VIP 두 가지 등급이 존재한다.데이터 저장: 자체 DB를 구축할 수도 있고, 외부 시스템과 연동할 수도 있다. (현재는 미확정 상태)1.2. 주문 및 할인 정책 요구사항할인 정책: 모든 VIP 등급 회원에게는 1,000원을 할인해 주는 '고정 금액 할인'을 적용한다.유연성 확보: 할인 정책은 ..

스프링 프레임워크가 자바 엔터프라이즈 시장의 표준으로 자리 잡은 이유는 단순히 기능이 많아서가 아니다. 스프링의 본질은 '자바 언어가 가진 객체 지향의 특징을 극대화할 수 있도록 돕는 것'에 있다. 그 시작점인 자바 진영의 역사와 객체 지향 설계 원칙에 대해 정리한다.1. 자바 진영의 추운 겨울과 스프링의 탄생 스프링이 등장하기 전, 자바 엔터프라이즈 개발의 중심에는 EJB(Enterprise JavaBeans)가 있었다. EJB는 당시 기술적으로 권위 있는 표준이었으나, 다음과 같은 치명적인 단점이 존재했다.높은 복잡도와 의존성: EJB 표준을 따르기 위해 비즈니스 로직보다 프레임워크에 종속적인 코드를 더 많이 작성해야 했다.어려운 테스트: 프레임워크 없이는 단독으로 테스트하기가 매우 까다로웠다.비싼 ..

1. 최적화, 그 이상의 기록이 필요한 이유 JPA와 벌크 연산을 활용하여 성능 문제를 해결하는 방법은 이미 앞서 다루었다. 그러나 단순히 코드를 수정했다고 해서 최적화가 끝났다고 단정하는 것은 위험하다. 진정한 엔지니어라면 "이 개선이 실제로 얼마나 효과가 있었는가?"라는 질문에 수치로 답할 수 있어야 한다. 성능 향상을 판단하기 위해서는 구체적인 데이터가 필요하다. 특히 대량의 데이터를 처리하는 배치(Batch) 작업에서는 다음과 같은 지표가 핵심이 된다.총 실행 시간: 작업의 시작부터 종료까지 얼마나 소요되었는가?실행된 SQL 쿼리 수: 의도한 대로 벌크 연산이 수행되어 쿼리 수가 줄었는가?쿼리 유형별 통계: SELECT, INSERT, DELETE 중 어떤 쿼리가 병목을 일으키는가?이러한 지표를..

1. 들어가며 애플리케이션을 개발하다 보면 수천, 수만 건의 데이터를 한꺼번에 저장하거나 삭제해야 하는 상황을 마주하게 된다. 이때 우리가 흔히 사용하는 JPA의 기본 메서드들(saveAll, deleteAll)이 예상보다 훨씬 느리게 동작하는 경험을 하곤 한다. 현실에 비유하자면, 수백 개의 택배 상자를 보낼 때 상자마다 트럭 한 대씩을 배정하여 보내는 격이다. 상자들을 큰 컨테이너 하나에 모아 한 번에 배송한다면 훨씬 효율적일 것이다. 데이터베이스 세계에서는 이를 벌크 연산(Bulk Operation)이라 부른다. 이번 글에서는 JPA 환경에서 벌크 연산이 왜 효율적으로 동작하지 않는지, 그리고 이를 어떻게 최적화할 수 있는지 구체적인 사례를 통해 살펴본다.2. IDENTITY 전략과 Batch I..

1. 들어가며애플리케이션을 개발하다 보면 대량의 데이터를 데이터베이스에 저장하거나 수정해야 하는 상황을 마주하게 된다. 이때 성능 최적화의 핵심 기술 중 하나인 벌크 연산(Bulk Operation)과 그 효율에 큰 영향을 미치는 JPA ID 생성 전략에 대해 심도 있게 고찰해 본다.2. 벌크 연산(Bulk Operation)이란? 벌크 연산의 개념은 실생활의 택배 배송에 비유하면 이해가 명확해진다. 여러 개의 물건을 보낼 때, 각 물건을 작은 박스에 하나씩 따로 담아 개별 배송하는 것보다 큰 박스 하나에 모아 한 번에 보내는 것이 훨씬 효율적이다. 이는 배송 횟수를 줄여 시간과 비용을 획기적으로 절감할 수 있게 한다. 소프트웨어 개발에서도 동일한 논리가 적용된다. 데이터베이스에 쿼리를 수행할 때, 수..