게시글에는 책의 설명과 무관한 내용이 섞여있습니다.
토비의 스프링 3.1 정독 시작하기
토비의 스프링 책을 구매한지 벌써 1년이 지났는데 현재까지 책을 다 읽지 못하고 있었다.
올해가 가기전에 정독을 하기 위해서 11월쯤 토비의 스프링 책 스터디를 진행하려던 찰나 아주 좋은 기회가 생겼다 😆
바로 책의 저자분이 직접 운영하시는 읽기모임에 참여할 수 있게된 것 .. ! 토비의 읽기모임에선 많은 개발자 분들과 소통하며 책을 읽을 수 있다. 위협적인 책의 두께 때문에 열심히 잘 참여할 수 있을까 겁이 났지만, 흔치않은 기회였기 때문에 놓치기 너무 아쉬웠고 여럿이 읽으면 책임감도 생겨서 끝까지 참여할 수 있을 것 같아 신청했다.
읽기모임이 운영되는 동안 같이 참여하는 개발자 분들에게 도움이 될 수 있도록 열심히 글을 정리할 것이다. 본격적으로 읽기전에 작가들이 제일 중요하게 생각한다는 서문부터 정리하고 시작
스프링이란 무엇인가?
스프링은 자바 엔터프라이즈 애플리케이션 개발에 사용되는 애플리케이션 프레임워크이다. 애플리케이션 프레임워크는 애플리케이션 개발을 빠르고 효율적으로 할 수 있도록 도와준다.
누군가 스프링이 무엇이냐고 물어보면 잘 디자인된 프레임워크라고 말할 것 같다. 객체지향 그리고 소프트웨어 설계에 관한 책을 읽어보면 모두 공통적으로 단순하게 작성하라고 한다. 이는 단순함이 결국 유지보수성과 재사용성을 증가시키기 때문이라고 생각한다. 스프링은 간단한 방법으로 IoC/DI, PSA, AOP를 지원한다.
이 세가지 프로그래밍 모델들이 결합을 느슨하게 만들고 애플리케이션을 유연하게 만들기 때문에 잘 디자인 되었다고 생각한다.
애플리케이션의 기본 틀 - 스프링 컨테이너
스프링은 스프링 컨테이너 또는 애플리케이션 컨텍스트라고 불리는 스프링 런타임 엔진을 제공한다. 스프링 컨테이너는 설정정보를 참고하여 애플리케이션을 구성하는 오브젝트를 생성하고 관리한다.
업무 중에 애플리케이션 계층 구조에 대한 이해가 없어서 고생한 적이 있었다. 특정 Redis 채널에 대한 Listener 를 분명 하나만 생성하였는데 구독자 수가 1이 아닌 2로 조회되는 문제였다. 알고보면 단순한 이유였는데 Spring 에 대해 무지하여 원인 파악이 매우 느렸다.
원인은 이미 Root Context 가 공통으로 사용될 설정정보를 읽어서 Listener를 Bean으로 등록하였는데 dispatcher-servlet 에서 해당 설정파일을 import 하고있던 것이었다.
당시에는 정말 몰랐다.. 저 문제를 겪고나서 기초를 모르고 개발하면 한계에 도달한다는 것을 깨달은 것 같다 🥺
공통 프로그래밍 모델 - IoC/DI, 서비스 추상화, AOP
스프링은 애플리케이션을 구성하는 오브젝트가 생성하고 동작하는 방식에 대한 것 뿐만 아니라, 애플리케이션 코드가 어떻게 작성되어야 하는지에 대한 기준도 제시해준다. 이러한 틀을 보통 프로그래밍 모델이라고 하는데, 스프링은 아래와 같은 세가지 핵심 프로그래밍 모델을 지원한다.
1. IoC/DI
IoC/DI는 스프링 프레임워크의 근간이다. 스프링 프레임워크에서 동작하는 코드는 IoC/DI 방식을 따라 작성되어야 스프링이 제공하는 가치를 누릴 수 있다.
IoC란 Inversion of Control 제어의 역전을 의미한다. 스프링 프레임워크 에서는 객체 생성, 의존 관계 설정, 객체의 생명주기를 개발자가 작성한 코드가 아닌 스프링 컨테이너가 담당한다. 스프링 컨테이너가 코드 대신 객체의 관계와 생명주기, 생성을 담당하기 때문에 제어의 역전이라고 한다.
DI란 Dependency Injection 의존성 주입을 의미한다. 개발자가 객체간의 의존성을 설정하거나 클래스에 명시하면 의존성을 IoC 컨테이너가 자동으로 연결해준다.
2. PSA(Portable Service Abstraction)
두번째로 제공하는 프로그래밍 모델은 서비스 추상화 모델이다. 스프링을 사용하면 환경이나 특정 기술에 종속되지 않고
이식성이 뛰어나며 유연한 애플리케이션을 만들 수 있다. 이를 가능하게 해주는 것이 바로 서비스 추상화이다.
서비스 추상화는 실제 구현부를 감추고 필요한 기능만을 제공하기 때문에 사용자는 실제 구현부를 모르더라도 해상 서비스를 이용할 수 있다.
당장 떠오르는 것은 @Transactional 인듯 ?! 그리고 스프링과 관련없는 내용 중에선 OS layer의 VFS가 떠올랐다.
3. AOP(Aspect Oriented Programming)
AOP는 횡단 관심사를 독립적으로 모듈화 하여 모듈성을 증가시키는 프로그래밍 패러다임이다.
스프링은 AOP를 간단하게 구현할 수 있는 강력한 라이브러리 등을 제공한다.
@Transactional도 Spring AOP 중 하나이다.
스프링의 성공요인
단순함
과거에서부터 개발자들은 소프트웨어를 더욱 단순하게 만들고 재사용 할 수 있도록 유연하게 설계하는 방법을 고민해온 것 같았다. 단순함을 추구하는 것에는 이유가 있다고 생각한다. EJB도 과거엔 많이 사용되었지만 복잡하고 불편하기 때문에 기억속으로 사라진 것처럼 말이다.
스프링 프레임워크는 EJB를 비판하며 탄생했다. 스프링은 EJB가 잃어버렸던 객체지향 언어의 장점을 다시 개발자들이 살릴 수 있도록 도와주는 도구이다. 스프링이 강력히 주장하는 것은 가장 단순한 객체지향적인 개발 모델인 POJO(Plain Old Java Object) 프로그래밍이다.
유연성
스프링은 유연성을 중요한 가치로 내세운다. 스프링은 뛰어난 유연성과 확장성으로 많은 서드파티 프레임워크의 지원을 받을 수 있다. 스프링은 프레임워크를 위한 프레임워크로 여러 프레임워크를 함께 사용하게 해주는 접착 프레임워크라고도 한다.
스프링의 개발 철학 중 하나는 항상 프레임워크 기반의 접근 방법을 사용하라이다. 스프링의 기능은 대부분 핵심 기술을 확장해서 발전시킨 결과물이다. 스프링은 개발자들이 스프링 프레임워크를 확장하여 사용하여도 버전 호환성 문제가 발생하지 않는 아주 유연한 프레임워크이다.