리오의 개발일지
close
프로필 사진

리오의 개발일지

github: @dldydtjs2965

  • 분류 전체보기
    • 프로젝트
    • 데이터베이스
      • Redis
      • Elasticsearch
    • JAVA
    • Python
      • Flask
    • Javascript
      • Node.js
      • React
      • Nest.js
    • Git
    • 인공지능
      • Claude
    • CS
      • 알고리즘
    • 일상
    • 도서
    • devops
      • aws
    • spring
      • SpringBoot
      • Spring Security
      • JPA
  • 홈
  • 태그
  • 방명록

토비의 스프링 정복하기 17편 - POJO를 DDD 관점으로 해석하기

1. POJO는 왜 여전히 중요한가토비의 스프링이 출간되던 시절, POJO는 EJB라는 무거운 컨테이너 종속 구조를 벗어나기 위한 반란이었습니다. 마틴 파울러가 "Plain Old Java Object"라는 이름을 붙인 이유 자체가, 개발자들이 단순한 자바 객체를 쓰는 것을 '초라하게' 느끼지 않도록 하기 위함이었습니다.2026년 현재 EJB는 사실상 사라졌고, Spring Boot가 사실상 자바 웹 프레임워크의 표준이 되었습니다. 그런데 아이러니하게도, 시간이 흘러 함수형 패러다임과 이벤트 패러다임 등 많은 이론들이 나왔지만 여전히 객체 지향은 더 중요해졌습니다. 그리고 Spring Boot의 자동 설정, 수많은 스타터 의존성, 그리고 각종 애노테이션 조합 속에서 우리의 도메인 객체가 여전히 "진짜 P..

  • format_list_bulleted spring
  • · 2026. 3. 15.

토비의 스프링 정복하기 16편 - 스프링 생태계의 진화

스프링이 가져온 봄스프링이 등장하기 전, 개발자들은 비즈니스 로직보다 인프라 문제를 해결하는 데 더 많은 시간을 써야 했습니다. 웹 서버 구축, HTTP 통신, 직렬화, DB 접근까지 모두 직접 구현해야 했기 때문입니다.이를 해결하기 위해 등장한 것이 EJB였습니다. EJB는 이런 인프라 문제를 프레임워크 수준에서 해결해주었지만, 오히려 새로운 부담을 안겨줬습니다. 특정 인터페이스를 강제로 구현해야 했고, 무거운 WAS가 필요했으며, 방대한 XML 설정은 유지보수를 어렵게 만들었습니다.스프링은 이 반성에서 출발했습니다. 특정 프레임워크에 종속되지 않는 순수한 자바 객체, 즉 POJO만으로 애플리케이션을 구성할 수 있다는 것이 핵심이었고, 개발자들이 다시 비즈니스 문제에 집중할 수 있는 환경을 만들어줬습니..

  • format_list_bulleted spring
  • · 2026. 3. 10.

토비의 스프링 정복하기 15편 - XML에서 어노테이션으로

들어가며스프링의 DI 설정 방식은 크게 세 단계를 거쳐 진화했습니다.XML 시대 — 모든 빈 설정을 XML에 기술Java Config 시대 (Spring 3.x) — XML을 @Configuration 클래스로 대체Auto Configuration 시대 (Spring Boot) — 관례 기반 설정과 의존성 감지로 설정 자동화1. 어노테이션 기반 프로그래밍의 진화1.1 메타정보로서의 어노테이션어노테이션의 역할은 코드의 동작을 직접 기술하는 게 아니라, 프레임워크가 참조하는 메타정보를 제공하는 것입니다. XML은 모든 정보를 명시적으로 기술해야 했습니다. 어노테이션은 리플렉션 API를 통해 클래스 정보를 자동으로 수집합니다.@Servicepublic class UserServiceImpl impleme..

  • format_list_bulleted spring
  • · 2026. 3. 8.

토비의 스프링 정복하기 14편 - 과거부터 이어져 온 설계 패턴 4가지

들어가며토비의 스프링 7장 후반부는 SQL 레지스트리를 런타임에 수정 가능하게 만드는 과정을 다룹니다. 솔직히 말하면, SQL을 런타임에 교체하는 시나리오 자체는 현대 스프링에서 거의 사용되지 않습니다. MyBatis를 쓰면 매퍼 XML을 수정하고 재배포하면 되고, JPA를 쓰면 SQL을 직접 관리하지 않는다.하지만 이 과정에서 적용되는 설계 패턴들은 현대 스프링에서도 매일 마주치게 됩니다. 이 글에서는 현재적인 스프링에서는 그 개념을 어떻게 활용하는지에 대해 설명하려고 합니다.1. 인터페이스 분리 원칙(ISP) - 기존 코드를 건드리지 않는 기능 확장토비의 스프링에서의 맥락기존 SqlRegistry는 등록과 검색만 제공했습니다. 여기에 SQL 수정 기능이 필요해졌을 때, SqlRegistry에 직접 u..

  • format_list_bulleted spring
  • · 2026. 3. 3.

토비의 스프링 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.
  • navigate_before
  • 1
  • 2
  • 3
  • 4
  • ···
  • 12
  • navigate_next
공지사항
전체 카테고리
  • 분류 전체보기
    • 프로젝트
    • 데이터베이스
      • Redis
      • Elasticsearch
    • JAVA
    • Python
      • Flask
    • Javascript
      • Node.js
      • React
      • Nest.js
    • Git
    • 인공지능
      • Claude
    • CS
      • 알고리즘
    • 일상
    • 도서
    • devops
      • aws
    • spring
      • SpringBoot
      • Spring Security
      • JPA
인기 글
전체 방문자
오늘
어제
Copyright © ri5 모든 권리 보유.
SKIN: Copyright © 쭈미로운 생활 All rights reserved. Designed by JJuum.
and Current skin "dev-roo" is modified by Jin.

티스토리툴바