토비의 스프링 13편 - SQL과 DAO의 분리, 그리고 MyBatis가 나오기까지

초기의 스프링에서는 DAO를 통해 데이터 액세스 로직을 작성하고 관리를 하였습니다. 비즈니스 로직은 서비스에 작성하고 SQL은 DAO안에 숨기면서 책임을 분리했지만 여전히 가지고 있는 문제점이 SQL을 변경하게 되면 DAO를 함께 수정해야된다는 점이 문제였습니다.SQL과 DAO를 분리하는 과정에서 어떤 트레이드 오프를 하며 발전했는지 살펴봅시다.개별 SQL 프로퍼티 방식가장 직관적인 방법은 SQL을 XML 설정 파일로 빼고, 각 SQL을 개별 프로퍼티로 주입하는 것입니다. SQL이 자바 파일에 분리되었기 때문에 재컴파일 없이 활용할 수 있습니다. XML에서 프로퍼티 명을 인식하기 때문에 컴파일 시 런타임에서 체크 가능여기서 가진 치명적인 문제점이 있는데 바로 보일러 플레이트 코드가 엄청 많이..

• format_list_bulleted spring
• · 2026. 3. 1.

토비의 스프링 정복하기 12편 - 왜 @Transactional 한 줄이면 되는걸까?

백엔드 개발을 하면서 트랜잭션을 직접 제어하는 코드를 작성해본 개발자는 많지 않을 것입니다. @Transactional 하나면 트랜잭션이 생성되고, 메서드가 끝나는 시점에 자동으로 종료되니까요. 개발자는 그 안에서 비즈니스 로직에만 집중하면 됩니다.하지만 이 추상화가 때로는 함정이 되기도 합니다. private 메서드에 @Transactional을 선언하거나, 같은 클래스 내부에서 @Transactional 메서드를 호출하는 self-invocation으로 인해 트랜잭션이 의도대로 동작하지 않는 경험, 한 번쯤 해보셨을 겁니다.이 글에서는 @Transactional에 숨어있는 AOP의 동작 원리를, 수동 프록시에서 시작해 현대 스프링에 이르기까지의 진화 과정을 통해 추적해보겠습니다."마법" 뒤에 숨겨진 ..

• format_list_bulleted spring
• · 2026. 2. 18.

토비의 스프링 정복하기 11편 - 프록시가 나오게 된 이유

프록시와 Mock프록시(AOP)와 Mock(@MockitoBean)은 목적은 다릅니다. 하나는 부가기능을 끼워넣기 위해, 다른 하나는 테스트 격리를 위해 존재합니다. 하지만 구조적으로는 놀라울 정도로 닮아있습니다.[클라이언트] → [대리 객체] → [실제 타겟]AOP 프록시: 트랜잭션, 로깅 등 부가기능을 가진 대리 객체가 타겟을 감싼다.@MockitoBean: 테스트용 가짜 객체가 스프링 컨텍스트에서 실제 빈을 대신한다.두 경우 모두 클라이언트(호출자)는 대리 객체의 존재를 알 수 없습니다. 개발자들은 프록시를 통해 호출한 쪽에서 대리 객체를 통해 실제 객체를 숨기려고 했을까요? 1단계: 수동 프록시 — 가장 원시적인 대리 객체AOP 관점: 데코레이터 패턴프록시를 구현하는 가장 직관적인 방법은 인터페이..

• format_list_bulleted spring
• · 2026. 2. 10.

토비의 스프링 정복하기 10편 - 비즈니스 로직을 기술로부터 독립시키기

[Spring] 트랜잭션 서비스 추상화토비의 스프링에서 나오는 트랜잭션 서비스의 추상화는 지금까지도 활용되고 있으며 스프링부트 환경에서도 가장 중요한 핵심 아키텍처로 활용되고 있습니다. 과거의 복잡한 트랜잭션 코드가 어떻게 @Transactional이라는 하나의 어노테이션으로 관리할 수 있게 되었는지 살펴보도록 하겠습니다.1. 트랜잭션의 시작: 원자성(Atomicity)DB는 단일 SQL에 대해서는 트랜잭션을 보장하지만, 여러 작업을 하나의 단위로 묶는 것은 애플리케이션의 역활입니다. 이 역활은 AI의 개발을 위임하더라도 트랜잭션의 범위 만큼은 백엔드 개발자가 직접 검토해야할 정도로 중요한 작업니다. 예: 은행 송금 로직출금 계좌에서 돈을 뺀다. (UPDATE)-- 여기서 예외 발생! --입금 계좌에 돈..

• format_list_bulleted spring
• · 2026. 2. 7.

토비의 스프링 정복하기 9편 - 서비스의 추상화

@Servicepublic class ReservationService { public int calculateFinalPrice(int originalPrice, String discountType) { int finalPrice = originalPrice; // 문제 1: 문자열로 타입 구분 → 오타 위험, 타입 안전성 없음 // 문제 2: 모든 할인 로직이 한 곳에 뭉쳐있음 // 문제 3: 매직 넘버(1000, 0.1) 직접 사용 // 문제 4: 정책 추가될 때마다 if문 계속 추가해야 함 (OCP 위반) if (discountType.equals("AMOUNT")) { ..

• format_list_bulleted spring
• · 2026. 2. 3.

AI와 토론하며 설계한 SSE 실시간 조회 시스템

1. 개요이번에 개발하는 프로젝트 요구사항에 실시간으로 기기의 정보를 받아와 관리자 화면에 보여줘야하는 요구사항이 있어 실시간성 기술이 필요한 기술을 사용하게 되었습니다. 제미나이와 토론하며 얻은 지식과 기술적 결정의 배경을 정리해, 비슷한 고민을 하는 분들과 나누고자 합니다.2. 기존에 웹 소켓을 사용했던 배경AWS 웹소켓은 수만 개의 커넥션을 직접 관리해 줍니다. 애플리케이션 서버는 연결 시 커넥션 정보만 저장하면, 이벤트 기반으로 쉽게 데이터를 전달할 수 있어요. 커넥션 리소스도 AWS가 처리하므로 서버 부담과 유지보수 비용이 모두 줄어듭니다. 이런 장점 덕분에 기존 애플리케이션은 소켓으로 실시간 조회를 제공했습니다. 하지만 IDC 환경에서는 상황이 다릅니다. AWS가 제공하던 기능을 직접 만들고..

• format_list_bulleted spring/SpringBoot
• · 2026. 2. 1.