[북스터디] 스프링 부트 핵심 가이드(ch1~ch3)를 공부해 보았다.(1편)ch1

주저리

제로베이스 백엔드 개발 과정을 수강한지도 어느덧 3개월 가까운 시간이 흘렀다. 그간 많은 학습이 있었고, 그것들의 너머에 또 새로운 학습이 있었고, 그것이 웹 개발. 스프링으로의 전환이었다.

완전한 미지. 내게는 그런 세상의 영역이었다. 첫 번째 과제로 주어진 오픈 API를 활용한 간단한 서비스 개발은 엉망진창이었고, 나의 한계를 여실히 보여주었다.

그래서 너무 좋았다. 지금 알았고, 지금 보완하고 있고 지금 해내면 된다는 점들 때문이었으리라.

하지만 이런 막연한 기대감과 설렘을 채워줄 구체적이고 뚜렷한 step by step이 필요한 것 역시 분명하다.

그런 한 가지 방법으로 제로베이스에서는 북 스터디를 제안했고, 나 역시 그에 따르는 과정을 시작하기 위해 책을 구매했다.

책과의 만남

책은, 심플하게 Spring boot의 로고가 보인다.
사실 이게 Spring boot의 로고인 줄도 몰랐었고,

또 사실, Spring에 대한 기대가 엄청 컸다.
왜냐하면, Spring을 들여다 보기 전에는 이런 말만 들어왔기 때문이다.

Spring은! 자바를 활용해서 비즈니스 로직을 쉽게 구현하기 위해 만들어졌다!!

이 말은 맞는 말이지만 처음 배우는 사람이라면 ???를
많이 할 수 밖에 없는 당혹감을 벗어나지 못하리라 생각한다.

다행히도 프로그래밍 언어를 학습하며 이러한 상황들을 많이 봐왔다.

시간이 지나며 익숙해진 것도 있고 아직 미숙한 것도 있지만,
분명한 건 뚜렷한 학습으로 결을 만들어서 내가 도달해야 하는 위치 역시 스프링이 없었으면 어떡할 뻔 헀어!

이런 위치에 와야 한다는 것은 분명하다!

책 학습 방법이 정해지기까지...

그래서 책을 펼쳤다. ch3까지는 얼마 되지도 않았다. 425page중에 고작 33page!

책을 읽어 나갔다...

1시간이 지났다. 무슨 말인지 하나도 이해를 못했다.
심지어, 나는 그때 이미 Spring을 활용한 클론코딩을 하고 있었다. 즉, 사용하고 있는 건데 책에서의 설명이 너무 내게 멀게만 느껴졌다.

이후 책을 꼼꼼히 살펴보기 위해 내용들을 공책에 써가면서 읽었다.

내가 모르는 부분이 무엇인지. 내가 의문을 가지는 부분이 어딘지를 가시적으로 보기 위해서였다.

그렇게 차곡차곡 내용을 쌓아가며, 의문부호들을 찍고 그것들을 찾아 보고, 여전히 의문인 것과, 그나마 해결된 것들.

그리고, 책에 이미지 또는 가볍게 기술된 것들처럼 보이는 것들부터 꼼꼼하게 기술했지만 내 인지 속에 들어가지 않고 넘어간 것들을 꼼꼼하게 살펴보는 시간을 가졌다.

이렇게 하고 보니 대략 10시간 정도의 시간이 걸린 거 같다.

책을 다 쓴 느낌? 그런 걸 느꼈다. 눈으로 읽기 보다 손으로 읽었다고 해야할까?

그러다가 블로그에 올리고 할 때를 위해 정리할 필요성이 있겠다는 생각이 들었다. 그래서 손으로 쓰는 것을 멈추고,

개인적인 문서 작업으로 내용들을 정리하는 작업들을 이루었다.

단순한 내용들이지만, 이런 과정으로 학습을 하니, 훨씬 더 내게 이해가 잘 되는 느낌이다. 아직 이해가 되지 않는 부분도 많지만 최대한 핵심을 정리해 보았다.

ch1 스프링 부트란?

나는 책을 읽고 내용을 재구성한 것이기에, 기술 내용이 조금 자연스럽지 못하다고 느낄 수도 있다. 하지만 책의 기술 방식이 오히려 내게는 불편했고, 그런 부분들로 인해 나는
1. 스프링부트의 등장원인(스프링의 단점)
2. 아니 그러면 스프링 왜 써요??(책이 말하는 스프링의 장점)
3. 스프링 부트에 관한 부연(편의성) 순서로 글을 기술했다.

책은 2-1-3순서로 기술되어 있다.

1. 스프링부트의 등장원인(스프링의 단점)

스프링 부트는 스프링을 쉽게 사용할 수 있게 해주는 스프링의 프로젝트 중 하나다.

스프링을 쉽게 사용할 수 있다는 점에서도 알 수 있지만 스프링에 어떤 어려운 점이 있었는지를 먼저 알 필요가 있다.

우선 정답을 먼저 이야기 하자면 책에서는 다음과 같은 스프링의 어려움을 이야기 한다.

책에 없는 부제로 내가 넣은 것들은 괄호로 기술하겠다.

==(설정의 복잡성)==
스프링 프레임워크의 경우 개발에 필요한 각 모듈의 의존성을
'직접 설정'해야 한다.
즉, 사용하고자 하는 모듈을 일일이 찾아서 넣어야 한다.

뿐만 아니라, 이러한 모듈 간의 상호작용에 필요한 호환 버전을 명시해야 한다. 이러한 각각의 모듈 간의 호환 관계까지 고려해야 하는 것은 개발자가 직접 통제해야 하는 요소들로 불편을 야기한다.

위의 내용을 보면, 스프링을 쓸 이유가 없어 보이지만, 과거에는 더 안 좋은 것들이 있었고,

이러한 직접 해야하는 일을 없애준게 다름 아닌 스프링 부트이다!

2. 책이 말하는 스프링 프레임워크의 장점.

다만, 이 이야기를 하기 전에 몇 가지 스프링의 장점이자
우리가 스프링을 써야 하는 이유를 개념적으로 책에서는 제어 역전과 스프링 프레임워크의 다양한 모듈로 기술하고 있다.

-- 제어역전(IoC)(IoC:Inversion of Control)
일반적인 자바 프로그래밍의 경우 생성자를 개발자가 '직접' 만들어서 해당 클래스 내에서 객체를 사용한다.
그러나 스프링은 이러한 객체 생성을 외부에 위임한다.

솔직히, 위의 말이 잘 이해가 되지는 않는다. @Bean에 등록하는 것만 생각한다면 그러려니 하려고 했는데, 이러한
제어역전을 실행하는 방식 중 하나가
-- '의존성 주입(Dependecny Injection)'이다.

총 3가지의 방식을 이야기하는데 아래의 내용을 봐도 바로 이해가 되지는 않았다.

• '생성자'를 통한 의존성 주입
• '필드 객체 선언'을 통한 의존성 주입
• 'setter 메서드'를 통한 의존성 주입
  이 있는데 이 중에 가장 긴 코드는
  첫 번째인
• '생성자'를 통한 의존성 주입이다.

심지어 예제의 자바 코드에서의 객체 사용법보다도 길다.
그런데 자바에서는 위를 권장한다고 한다.

설명 상으로는 납득이 안 가지만, 이것이 단순한 클래스를 만드는 것이 아니라, 인터페이스를 만들고, 그것들을 통해 따로 이를 고려하지 않아도 된다는 이야기인 것 같은데, 이런 부분이 정확하게 맞는지는 몰라서 의역적으로 이러려니 하고 넘어가게 되었던 것 같다.

그리고 IoC를 통해 관점 지향 프로그래밍이 가능하다는 점도 중요하다고 한다.
-- 관점 지향 프로그래밍(AOP: Aspect-Oriented Programming)
스프링의 아주 중요한 특징이다! 라고 말하며 이를 통해 IoC 제어역전을 실현 시킨다고 한다.

간단하게 말하면, 핵심 기능들을 만들고, 그 외의 기타적인 부가기능이지만 핵심 기능들 만큼 자주 쓰이는 기능들을 따로 이용한다는 개념인데,

이 것 역시 납득은 가지만, 뭔가 용어를 빼서 새로 정의할 정도인가 싶기는 했다.

하지만 비즈니스 관점에서 말도 안 되게 큰 로직을 구성한다는 걸 생각해 보면 위와 같은 경우를 원칙적으로 빼서 따로 관리하라고 하는 내용이 납득이 된다.

언제 어떻게 어떤 일이 발생할지 실무에서는 알 수 없기 때문에 그러한 것들을 분리하고 개별적으로 관리하는 것이 훨씬 관리의 효율을 높일 수 있다는 것이리라(물론 그렇다고 해서 지나친 분리는 안 된다. 그렇기에 해당 책에서도 정말 많이 나오는 말이 '상황에 맞게', '특별한 상황이 아니라면'...등등의 말들이 나온다.)

또한 스프링 프레임워크의 경우 비즈니스 로직을 만들기 위한 API라는 점을 고려해 볼때, 다양한 모듈을 가지고 있고 이를 활용할 수 있다는 점은 확실히 장점으로 보였다. 다만 이러한 장점을 가짐에도 불구하고 설정들을 일일이 해줘야 한다?
이것도 다 시간이 지나면서 쌓인 문제겠지만 불편함이 커졌을 것이 정말 뻔히 보였다.

3. 그래서 나온게 스프링 부트!

스프링부트는 이러한 스프링 프레임워크의 설정의 복잡성을 줄여주는 역할을 한다. 자동 설정과 각각의 모듈을 일일이 넣어주는 것이 아닌, 자주 사용되는 것을 미리 묶어둠으로써 사용의 편의성을 높였다.

뭐 이 자동이라는 말이 마법처럼 보이겠지만 실제로는 미리 사전에 자주 쓰이는 패턴을 만들어 두었다고 보는 것이 맞을 것이다. 책에서는 구체적으로 web, test, jdbc, security, data-jpa, cache 등 정말 다양한 모듈이 내장되어 있음을 이야기하는데
이걸 꼼꼼히 다 써가면서 읽어 보니까...
스프링이 얼마나 불편했을지 확 느껴졌다. 심지어 이것들의 버전까지 다 서로 알고 있어야 한다...?!

이걸 spring-boot에서는 parent라는 걸 통해 버전 충돌이 없는 검증된 조합을 제공한다고 하니,

이제 정말 스프링이라는 게 써 볼만 하겠다는 생각이 들었다.(앞서 수많은 노고를 하신 개발자 분들에게 더없는 감사를...)

우선 글이 너무 길어질듯 하니...나머지 ch2와 ch3은 2편으로 남겨 두겠다 :)