참여 계기 & 다짐
디스코드에서 토비의 스프링 3.1 저자이신 이일민(이하 토비)님께서 주관하시는 '토비의 스프링 3.1 읽기 모임'이 생긴 걸 알게 되었는데, 좋은 경험과 유익한 시간이 될 것 같아 읽기 모임에 참여하게 되었습니다.
이전에도 읽어본 적이 있기는 하지만 이번에 읽었을 때는 또 어떤 느낌을 받을지, 어떤 것들을 느낄지 기대가 되며 다시 토비의 스프링 3.1을 펼쳤습니다.
하지만 이번에는 다른 분들과 생각을 공유하는 것이기 때문에 이전과의 차이도 둘 겸, 각 챕터별로 읽은 후 블로그에 제 생각과 느낀 점들을 정리하려고 합니다.
또 이번에는 책에 나와 있는 예제들을 실제 코드로 작성해 봅니다.
github 주소: https://github.com/kiekk/tobyspringin5
들어가며
토비 님께서 책에서 강조하신 부분은 의외로 '서문'이었습니다. 보통 저자들이 이 책에서 중요한 점, 포인트들을 서문에 작성한다고 하는데 토비 님도 이 책을 통해서 배웠으면 하는 점들을 서문에 작성해두셨기 때문에 이번 '읽기 모임'을 하시는 분들에게 "서문은 한 번씩 읽어봤으면 좋겠다."라고 당부하셨습니다.
서문
스프링이란 무엇인가?
스프링은 자바 엔터프라이즈 애플리케이션 개발에 사용되는 애플리케이션 프레임워크다.
쉽게 말해 자바로 기반으로 한 프레임워크입니다.
스프링 컨테이너
스프링은 스프링 컨테이너 or 애플리케이션 컨텍스트라고 불리는 스프링 런타임 엔진을 제공합니다.
스프링 컨테이너는 설정 정보를 참고해서 애플리케이션을 구성하는 오브젝트를 생성하고 관리하기 때문에
스프링을 사용하기 위해서는 먼저 스프링 컨테이너를 다루는 방법, 그리고 스프링 컨테이너가 참고하는 설정 정보를 작성하는 방법을 알아야 합니다.
IoC/DI, 서비스 추상화, AOP
프레임워크는 애플리케이션을 구성하는 오브젝트가 생성되고 동작하는 방식에 대한 틀, 애플리케이션 코드가 어떻게 작성돼야 하는지에 대한 기준을 제시하는데, 이런 틀을 프로그래밍 모델이라고 합니다.
스프링에서는 세 가지 핵심 프로그래밍 모델을 지원합니다.
IoC/DI는 오브젝트의 생명주기와 의존관계에 대한 프로그래밍 모델입니다.
스프링의 모든 기술과 API, 컨테이너 또한 IoC/DI 방식으로 되어 있기 때문에 스프링을 이해하는데 가장 기본이 되며 가장 중요한 기술입니다.
서비스 추상화
서비스 추상화는 환경이나 서버, 특정 기술에 종속되지 않고 이식성이 뛰어나며 유연한 애플리케이션을 만들 수 있습니다.
AOP
AOP는 코드에 산재해서 나타나는 부가적인 기능을 독립적으로 모듈화 하는 프로그래밍 모델입니다.
AOP를 사용하면 개발자들은 다양한 서비스를 적용하고도 깔끔한 코드를 유지할 수 있으며, 핵심 로직에 집중할 수 있게 됩니다.
기술 API
스프링은 개발의 다양한 영역에 사용할 수 있는 기술 API를 제공하는데, 모두 스프링의 프로그래밍 모델에 따라 작성되어 있기 때문에 개발자들이 쉽게 API들을 가져와 사용할 수 있습니다.
스프링의 성공요인
스프링이 성공한 요인으로 2가지 가치를 꼽자면 '단순함'과 '유연성'입니다.
단순함
스프링 이전에 EJB는 불필요하게 복잡했기 때문에 나중에 와서는 자바의 본질인 객체지향 언어라는 특징을 잃게 되었습니다.
스프링은 잃어버린 객체지향 언어의 장점을 다시 살리기 위해 나온 도구이고, 그래서 스프링이 가장 강하게 주장하는 것이 바로 가장 단순한 객체지향적인 개발 모델인 POJO 프로그래밍입니다.
POJO(Plain Old Java Object) : 그냥 우리가 알고 있는 Java Object라고 생각해도 무방합니다.
유연성
스프링은 유연성과 확장성이 매우 뛰어나기 때문에 다른 프레임워크와 접목이 편리합니다.
스프링은 프레임워크를 위한 프레임워크 또는 여러 프레임워크를 함께 사용하게 해주는 접착(glue) 프레임워크라고도 불립니다.
스프링 학습과 활용의 어려움
책 출간 당시 스프링이 공개된 지 9년째이면, 현재 2022년 기준으로는 18년이 됩니다.
9년 후에도 스프링의 핵심 가치와 혜택을 누리지 못하는 개발자들이 있다고 토비 님이 말씀하셨는데, 그건 18년이 되는 현재 또한 마찬가지인 것 같습니다.
아직까지도 토비의 스프링 3.1이 바이블이라고 불리는 이유, 또는 많은 사람들이 어렵다고 하는 이유에 대해서 한 번 생각해 봤습니다.
제 개인적인 생각으로는 스프링을 사용해 개발을 하고는 있지만 당장 개발 업무를 하기 위한 실무 지식이나 사용 방법에 대해서만 관심을 가지다 보니 토비 님이 강조하시는 스프링의 원리나 핵심 가치에 대해서 놓쳤던 게 아닐까 싶습니다.
그런 부분들을 놓치다 보니 자연스럽게 토비의 스프링 3.1이 어렵게 느껴질 수밖에 없다고 생각했습니다.
저의 취준생~신입 개발자로서 스프링을 학습할 때를 되돌아보면 저 또한 당장 업무를 하기 위해 필요한 지식들만 학습해왔던 것 같습니다.
그렇다 보니 당장 개발을 할 수 있더라도 조금이라도 문제가 생기거나 이슈가 생기면 원인 파악조차 쉽지 않은 상황이 발생했고, 그런 상황들을 겪으면서 내가 무엇을 사용하는지는 제대로 알고 사용해야 하지 않나 싶은 생각이 들었습니다.
'Spring > Toby's Spring Reading Club' 카테고리의 다른 글
1-5장. 서비스 추상화 (0) | 2023.01.08 |
---|---|
1-4장. 예외 (0) | 2023.01.08 |
1-3장. 템플릿 (0) | 2023.01.07 |
1-2장. 테스트 (0) | 2022.09.19 |
1-1장. 오브젝트와 의존관계 (0) | 2022.09.05 |
댓글