토비의 스프링 Vol.1 후기

chisae·2024년 6월 17일

책 후기

목록 보기

1/5

안녕하세요, 오늘은 토비의 스프링 3.1 Vol.1에 대한 후기를 남기고자 합니다, 오랜만에 책을 읽어보니깐 상당히 재미가 있었는데요, 그런 김에 책 후기를 적을 때는 서술체를 쓰고자 합니다, 때문에 평소에 쓰는 경어와 차이가 있으니, 만약 제 포스팅을 보는 사람이 있으시다면 이 점을 양해해주면 감사하겠습니다.

계기

역량 부족

최근 역량이 부족하다는 사실을 파악할 수 있었고, 이 부분을 해결하기 위해서 나는 극단적인 해결법을 도입하기를 원했다, 기존에 내가 했던 공부 방식은 이러했다.

레퍼런스 확인 (Git 레포지토리, 블로그)
온라인 강의 확인
Document 확인

하지만 이 방식에는 치명적인 문제점이 있었다, 바로 기본기를 쌓기에는 다소 부적절한 면이 존재했고, 그 이유는 깊은 고민을 하지 않았기에 생긴 일이라고 생각했다, 때문에 기존 방식에서 추가로 책을 읽고 평소에는 적당히 생각하고 넘어갔을 부분들도, 한 번씩 더 체크해보는 습관을 들이기 시작했다,

아 그래서 그런거구나

또한 작년, 백엔드 개발을 처음 시작했을 당시 김영한님의 스프링 강의를 처음부터 끝까지 수강을 했던 경험이 있다, 당시에 대부분의 내용을 "아 그렇구나~" 라는 느낌으로 수강을 했고, 단순히 지식들을 머리에 쑤셔넣기 바쁜 시기였다, 그리고 제대로 된 이해를 못한 상태에서 일단은 머리를 박고 프로젝트를 시작하다보니, 아주 사소한 거 부터 문제점이 많았고 그 만큼 삽질도 엄청나게 많이했다,

이후, 고디터를 리뉴얼까지 했을 때 쯤에는 김영한님의 강의를 다시 한번 듣고 싶은 욕구가 많았었다, 김영한님의 강의를 처음부터 끝까지 들어서 백엔드 개발의 흐름은 대강 파악할 수 있었지만, 어느정도 아는 상태에서 들었다면 공부의 순 기능인 "아 그래서 그런거구나!" 라는 느낌으로 강의를 듣고, 내 문제점을 확실하게 찾고 더 개선할 수 있을거란 생각이 들었다, 그래서 강의보다 한 단계 더 깊은 생각을 가질 수 있는 책을 읽음으로서 이 고민을 해결하고자 했다.

그리고 추가적인 계기는 아래 링크를 통해서 확인 가능하다.

https://velog.io/@chisae/%ED%8E%B8%EB%8F%99%EB%B6%80%EA%B0%80-%EB%AD%94%EA%B0%80%EC%9A%94-%EC%A4%91%EA%B0%84-%EC%A0%90%EA%B2%80
<편동부가 뭔가요? (중간 점검)>

규칙

6개월간 10권

우선, 이번에 나는

객체지향의 사실과 오해
토비의 스프링 1,2
자바 ORM 표준 JPA 프로그래밍
실전 스프링 부트
도커/쿠버네티스를 활용한 컨테이너 개발 실전 입문
컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커
Real MySql8.0
Clean Code
개발자의 글쓰기

약 6개월간 하루 5~6시간 씩 책을 10권 읽고 그걸 코드에 적용할거다.

때문에 평소 하던대로 시작하기 전에 책 선정부터 고민을 하고, 책 후기들을 한 번씩 보면서 책을 어떻게 읽으면 효율적으로 읽을 수 있을지부터 고민을 했다, 그렇게 나는 책을 읽기 시작하기 전에 세 가지 규칙을 정할 수 있었고, 이 규칙 덕분에 새로운 지식을 얻거나, 기존 지식을 검증하고, 현재 내 문제를 전체적으로 살펴 볼 수 있었다.

참고로 SQ3R 같은 읽기 방식이 있었지만, 조금은 더 자유롭게 나한테 맞는 방법을 찾고자 했다.

<정리>
: 처음 알게된 지식들을 주로 정리하는 항목이다 → 이해보다는 정의를 하는 느낌이다.
<의문>
: 책을 읽다가 의문이 생기는 부분들을 정리하는 항목이다.
<생각>
: 기존에 알았던 지식을 새로 검증할 때 자유롭게 쓰는 항목이다 → 어떤 흐름(느낌)인지를 주로 적는다.

그리고 여기서 하나의 히든 케이스도 있다.

<문제>
: 책을 읽다가 현재 내 코드에 문제점이 있으면 그날에 바로 수정해야할 코드를 적는 항목이다, 한 챕터에 무수히 나올 수도 있고 아예 안 나올수도 있는 부분이라 이 케이스가 나오면 엄청 좋은 경우이다.

여기서 추가로, 옛날에 책을 읽었을 때 중요시 여겼던 '저자의 책 쓰는 습관' 을 파악하여 저자가 어떤식으로 책을 쓰고, 어떻게 독자에게 의미를 전하는지를 알고자 했다, 이 방식은 책을 읽다보면 흔히 중간에 몰입이 깨지는 상황속에서도 내용을 정리하기 쉽고, 어차피 한 챕터에서 전하고자 하는 내용이 한 가지 있다면 그 한 가지에 대한 부연 설명이 많이 덧붙여 있는 경우가 많기에, 집중해야할 때만 집중하기 위해선 먼저 이 습관을 파악해야한다.

참고로 내가 생각했을 때 토비의 스프링의 경우 한 챕터당 여러 중간 제목과 소제목이 있는데,
처음엔 로우 레벨의 코드를 보여주면서 점차 개선을 해 나간다, 이때 중간 제목을 잘 보아야한다,
중간 제목에는 하나의 규칙이 있을 확률이 높고, 소제목은 주로 그런 중간 제목을 뒷받침 해주는 내용들이 있다.

정리 중독

이제 규칙도 정했으니 어떤식으로 정리를 할지도 정해야한다, 하루에 약 100~150 페이지 가량을 읽고, 그걸 정리하면 매번 2~3 페이지 분량의 요약본이 나왔다, 그리고 글자 수를 세어보니 공백제외 총 20,286자가 나왔다,

일단 정리의 경우 내가 3이라는 숫자를 좋아해서, 3번에 걸쳐 정리가 되도록 했다.

우선 책을 읽으면서 노트에 적고 싶은 부분이 있으면 모든 부분을 다 적는다.
그리고 디스코드에 옮기는 과정을 통해 다시 복기하면서, <의문>과 같이 추가 정보가 필요한 경우 추가 정보를 기입한다.
그 중에서 당장에 코드에 적용해야할 부분들은 노션에 옮겨 따로 관리한다.

후기

책 후기라고 제목을 적어놓고 엄청나게 긴 서론이었다, 하지만 처음 책과 관련된 포스팅인 만큼 어떤식으로 책을 읽을지에 대해서는 이번 포스팅에 한해서는 적어두는게 맞는 거 같다고 판단해서 적어두었다, 그러므로 다음 책 후기 포스팅에서는 바로 본론부터 설명할 예정이다.

한 줄 요약

이번 토비의 스프링 3.1 Vol.1을 한 줄 요약하자면,

스프링을 잘 다루기 위해선 DI를 잘 이해해야한다.

책을 정독하다보면 매 챕터마다 DI에 관한 얘기는 빠지지 않고 나온다는걸 알 수 있을거다, 정말 처음에 DI가 왜 중요한지 알았을 때는 엄청난 쇼크로 나한테 다가왔었고, DI와 인터페이스가 어떤 관계를 가지고 있는지, 인터페이스를 통해서 또 여러가지 패턴을 만들 수 있다는 점 등... 스프링의 궁극적인 목적이 무엇이고 그걸 잘 지키기 위해서는 어떤 느낌으로 성장해야하는지를 설명하면서, 챕터1부터 챕터9까지 정말 슬슬 질린다는 생각이 들 정도로 DI의 중요성을 재차 강조하였다,

또한 김영한님의 강의 중에서, 토비의 스프링이 재밌어서 그냥 정독 하셨다는 얘기를 하신적이 있다, 그리고 내 추측이지만 토비의 스프링의 흐름과 김영한님의 강의 흐름이 사뭇 비슷한 느낌이 있었다, 예를 들어서 로우 레벨에서 시작하여 조금씩 개선을 한다는 점과 이때 왜 이렇게 개선을 했는지 규칙을 알려주시는 부분에서 비슷한 느낌이 들었다, 그나마 차이라고 한다면 김영한님의 강의가 조금은 더 하이 레벨의 기술을 다루었다는 점인 거 같다.

조금만 더 자세히..?

그러면 지금부터 각 챕터별 핵심과 어떤 규칙이 있었는지, 책을 통해서 해결할 수 있었던 문제들에 대해서 정리해보도록 하겠다,

Chapter 1. 오브젝트와 의존관계

챕터1에서도 정말 많은 내용을 다루었다, 그리고 내가 생각했을 때 챕터1의 핵심은 아래의 몇가지이다.

관심사의 분리를 하는 이유
인터페이스 도입을 하는 이유
DI가 무엇인지

관심사를 분리해야하는 이유는 간단하다, 요구사항은 정말 끊임없이 변경된다, 실제로 내 서비스 같은 경우에도 최근 사용자 세부정보와 관련하여 요구사항이 변경되어 테스트 코드를 바꾸고 비즈니스 로직 역시 바꿔줘야 하는 상황이 발생했다, 그리고 개발자라면 다 알고 있는 사실이지만 이런 변경이 있을 경우 "영향이 적어야 한다",

이는 단일책임원칙(SRP)와 연관지어서 생각하면 더 쉽게 이해할 수 있을거다, 각 객체는 한 가지의 책임과 행동만을 할 수 있어야한다, 만약 게시글이라는 객체가 있다면 당연히 게시글과 관련된 작업만 할 수 있어야한다, 하지만 만약 게시글이 슈퍼 멀티 기능을 가진 게시글이라서 알아서 신고 기능이나 대화 기능이나 댓글 기능까지 갖추고 온갖 작업을 다 할 수 있다면, 게시글과 관련해서 조금의 요구사항이 바뀌면 여러 오브젝트 레벨에서 영향이 발생할 거다, 그러므로 관심사를 분리해주는 것으로 이를 방지할 수 있다,

그리고 여기서 추가로 관심사를 분리해주기 위해서는 어떤 방법을 써야할까? "이때 필요한게 바로 DI와 인터페이스다", DI는 A 오브젝트가 B 오브젝트를 '직접' 의존하는 상황에서 B 오브젝트가 변경될 경우 A 오브젝트에 영향을 미칠 수 있다, 그래서 DI를 제대로 사용하기 위해서는 두 개의 오브젝트가 인터페이스를 통하여 "느슨하게 연결되어야 한다",

이는 의존 역전 원칙(DIP)과 인터페이스 분리 원칙(ISP)를 지키는 사례라고 볼 수 있다, 하나의 인터페이스로 여러 개의 구현을 바꿔가면서 사용하는 것이 다형성의 첫 번째 장점이자 이유이기에 이를 지켜야햔다, 그리고 인터페이스를 통하여 고수준 모듈과 저수준 모듈의 결합도를 낮출 수 있고 덕분에 변경에 더 유연해질 수 있다, 이외에도 인터페이스를 사용하면 프록시, 데코레이터, 어댑터 등 다양한 목적을 위해서 사용할 수 있으며 인터페이스 분리 원칙을 통하여 오브젝트 사이의 관계를 더욱 명확하게 해줄 수 있다.

아래는 의존 역전 원칙과 관련된 예시 코드이다, 이를 이해하면 더 쉽게 이해할 수 있을거다.

// Low-level Module: EmailService
public class EmailService {
    public void sendEmail(String recipient, String message) {
        // 이메일 전송 로직
        System.out.println("Sending email to " + recipient + ": " + message);
    }
}

// Low-level Module: SmsService
public class SmsService {
    public void sendSms(String recipient, String message) {
        // SMS 전송 로직
        System.out.println("Sending SMS to " + recipient + ": " + message);
    }
}

// High-level Module: OrderService
public class OrderService {
    private EmailService emailService;
    private SmsService smsService;

    public OrderService() {
        this.emailService = new EmailService();  // 저수준 모듈에 직접 의존
        this.smsService = new SmsService();      // 새로운 저수준 모듈에 직접 의존
    }

    public void placeOrder(String customerEmail, String customerPhone) {
        // 주문 처리 로직
        System.out.println("Order placed!");

        // 주문 확인 이메일 발송
        emailService.sendEmail(customerEmail, "Your order has been placed.");

        // 주문 확인 SMS 발송
        smsService.sendSms(customerPhone, "Your order has been placed.");
    }
}

안 좋은 케이스이다, 직접 의존되어 잇기 때문에 OrderService는 요구사항이 바뀌면 서비스 영역의 코드도 바뀌어야한다, 참고로 좋은 설계는 Domain, Presentation, DAO가 변경되더라도 Service에 영향이 가지 않는 것이 좋은 설계이다,

// Abstraction: NotificationService
public interface NotificationService {
    void notify(String recipient, String message);
}

// Low-level Module: EmailService
public class EmailService implements NotificationService {
    public void notify(String recipient, String message) {
        // 이메일 전송 로직
        System.out.println("Sending email to " + recipient + ": " + message);
    }
}

// Low-level Module: SmsService
public class SmsService implements NotificationService {
    public void notify(String recipient, String message) {
        // SMS 전송 로직
        System.out.println("Sending SMS to " + recipient + ": " + message);
    }
}

// High-level Module: OrderService
public class OrderService {
    private List<NotificationService> notificationServices;

    public OrderService(List<NotificationService> notificationServices) {
        this.notificationServices = notificationServices;  // 인터페이스에 의존
    }

    public void placeOrder(String customerEmail, String customerPhone) {
        // 주문 처리 로직
        System.out.println("Order placed!");

        // 주문 확인 알림 발송
        for (NotificationService service : notificationServices) {
            service.notify(customerEmail, "Your order has been placed.");
            service.notify(customerPhone, "Your order has been placed.");
        }
    }
}

의존 관계 사이에 인터페이스를 도입함으로써 더욱 느슨한 관계를 유지할 수 있게 됐다, 덕분에 요구사항이 바뀌더라도 Service 영역에 코드가 강제로 바뀌어야 하는 상황을 방지할 수 있게 되었다.

여튼 챕터1의 주된 내용은 이와 같으며, 이외에 IoC 동작 방식, IoC가 무엇인지, 싱글턴 패턴이 무엇인지, 싱글톤 패턴의 한계, 스프링을 통한 싱글톤 패턴의 극복 등의 내용을 다루고 있다.

Chapter 2. 테스트

두 번째 챕터인 테스트이다, 사실 나는 테스트와 관련해서 항상 고민이 많았었다, 왜냐면 테스트는 특이하게도 공부를 할만한 자료가 비교적 적은편이었고, 실제로 기존에 난 PostMan이나 웹을 통하여 테스트를 했었다, 그리고 이 방법은 정말 비효율적인 방법이었다는걸 이번에 깨달을 수 있었다, 아래는 챕터2에서 내가 중요하다 느낀 것들이다

테스트는 환경이나 실행 순서에 영향 없이 일관적이어야 한다
코드 작성과 테스트 수행은 짧을수록 효과적이다
테스트하기 쉬운 코드가 좋은 코드다

기존에 서비스를 만들면서 난 삽질을 정 ~ 말 많이했다, 왜냐면 테스트를 비즈니스 로직의 한 영역이 다 완성되면 PostMan이나 웹을 통하여 했었고, 이는 그냥 '미친짓' 이었다, 개발자라면 대부분의 사람이 공감할 내용이지만 문제는 정말 예측 불가능한 영역에서 발생한다, 정말 사소한 것 일수도 있고 아니면 애초에 설계 자체를 잘못했을 가능성도 존재한다, 실제로 나도 문제를 해결 못해서 편법으로 그 기능을 아예 없앤 터무니 없는 경우도 있었다,

때문에 테스트는 짧을수록 효과적이다, 이번에 서비스를 만들면서 가장 신기했던 점은 기존에 비즈니스 로직을 하루만에 만들면, 이틀은 에러를 수정하는데 시간을 보내서 작업 효율이 정말 떨어졌다, 하지만 테스트 빈도가 짧아진 덕분에 문제를 쉽게 해결했고, 덕분에 생각 했던 거 보다 엄청 빠르게 개발을 할 수 있었다, 실제로 이번엔 스프링에서 제공하는 Validator와 관련해서 문제가 있었는데, Config를 설정해두지 않아 발생했던 문제였다.

이외에도 Interceptor가 테스트 환경에 영향을 주어 지속적으로 테스트를 실패한 경험도 있으며, 테스트를 하기 좋은 코드를 작성하기 위해서 노력하다 보니 DTO를 더 효율적으로 만들 수 있었다, 덕분에 Domain의 요구사항이 바뀌더라도 DTO만 변경하면 되고 Service의 영향을 최소화 할 수 있었다,

그리고 여기서 더 나아가 대부분의 테스트 코드는 그냥 평범하게 될만한걸 테스트 하는 개발자도 있다, 하지만 사용자는 개발자가 의도한대로 절대 움직이지 않는다, 나 같은 경우에도 서비스를 사용하다보면 이상한 행동을 해서 메인 페이지로 돌아가곤 한다, 때문에 테스트 코드를 작성할 때 절대 들어올 수 없는 값이거나 발생하면 안되는 경우만 따로 모아서 Bad Case 테스트 코드를 따로 만들어서 문제가 발생하면 적절한 예외가 나오는지 확인하는 테스트 코드를 따로 작성하여 관리하고 있다.

이외에도 챕터2 에서는 JUnit, DI를 이용한 테스트 방법, 테스트의 컨텍스트 공유 등을 다루고 있다.

Chapter 3. 템플릿

챕터3인 템플릿의 경우 개발을 하면서 코드 중복을 줄일 수 있는 여러 방법을 설명해준 챕터였다, 아래는 내가 생각했을 때 중요하다 느낀 것들이다.

템플릿 메소드 패턴
전략 패턴

추상클래스는 기본적으로 여러 클래스가 공통 상태(필드)를 공유하고 일부 공통 메서드의 구현을 공유할 경우에 용이하다, 그래서 나 같은 경우 구인글의 세부정보와 멤버의 세부정보가 겹치는 부분이 많아서 Details 라는 추상 클래스를 만들어서 코드 중복을 방지해줄 수 있었다,

Chapter 4. 예외 처리

챕터4인 예외 처리 역시 나한테 너무 흥미로운 챕터였다, 평소 예외 처리를 얼마나 확실하게 하는지가 실제 운영 환경에서 이슈를 덜 발생할 수 있는 지름길이라고 생각하고 있기에, 이번 챕터에서 예외 처리와 관련해서 더 깊은 고민을 많이 할 수 있었다, 아래는 내가 생각하는 중요한 것들이다.

예외 처리가 무엇인가?
언제 예외 처리를 해야 하는가?
예외 처리를 하는 방법은 어떤게 있는가?

우선, 모든 예외는 적절하게 복구하거나 작업을 중단 시키고 운영자에게 통보를 해야한다, 때문에 모든 예외처리는 어느정도 대안책이 존재해야한다, 그럼 예외 처리는 어떤 방법이 존재할까? 예외 처리는 메서드에 throws를 달아서 예외 처리하는 역할을 메서드를 호출한 쪽에 맡기는 방법과, 전환을 통하여 예외로 변경하여 던지는 방법, 예외 상황을 해결하여 정상 상태로 돌려놓는 방법이 있다,

그리고 이와 관련해서 더 깊은 이해를 하기 위해서는 체크 예외와 언체크 예외에 대해서 알고 있어야한다, 체크 예외는 IOException 같이 컴파일 단계에서 확인이 가능하다 때문에 체크 예외는 돈과 같이 중요한 로직의 경우 적용하는 것이 좋다, 왜냐하면 체크 예외는 복구 하지 않으면 시스템을 다운시키기 때문이다, 그래서 무조건 처리해야하는 미션 크리티컬한 로직의 경우 체크 예외를 달아두면 강제성이 생겨서 좋다,

그리고 반대로 체크 예외를 던지면 시스템을 강제로 복구하거나 다운시켜야 하기 때문에 전환을 이용하여 체크 예외를 언체크 예외로 전환시켜 처리하는 것도 가능하다, 언체크 예외는 RuntimeException을 상속 받는 경우이며, 때문에 시스템을 다운 시켜야 할 수준이 아니라면 체크 예외를 언체크 예외로 전환 시켜서 조금 더 유연한 방법으로 해결 가능하다.

그리고 나 같은 경우에는 예외 처리에 신경을 많이 쓰다 보니깐 많은 부분에서 예외 처리 코드를 적용했고, 이는 코드 중복을 발생시켰다 그래서 예외 처리 가독성을 높이고 코드 재사용성과 확장성을 높이기 위해서 예외 코드들을 Global 영역으로 옮겨 중앙 집중화 시킴으로써 더욱 용이하게 예외 처리를 관리할 수 있도록 리팩토링 했었다.

Chapter 5. 서비스 추상화

서비스 추상화 챕터는 트랜잭션 관리를 서비스 추상화를 통하여 더 유연하고 확장성 있게 사용하는 방법을 주로 다루는 챕터였다, 근데 서비스 추상화 부분과 관련해서는 앞서 나왔던 내용들과 중복된 부분들이 많아서 다소 흥미가 떨어진 챕터이기도 했다, 그래서 아쉬운 점이 많은 챕터이기에 나중에 시간이 있을 때 한번 정도 더 읽음으로써 저자가 어떤걸 전달하고자 했는지 확실하게 파악할 필요가 있는 챕터다,

하지만 그렇다고 해서 아예 얻은게 없는 챕터는 아니다, 이 챕터에서는 주로 트랜잭션과 관련된 내용을 다루었기에 트랜잭션안에서 트랜잭션이 실행될 수 있는지? (중첩 트랜잭션 or 트랜잭션 전파) 와 같은 의문이나 트랜잭션 롤백과 관련하여 따로 테스트를 해보면 좋을 거 같은 생각, 테스트 코드에 트랜잭션을 활용하면 좋은 부분, 기존 Service 영역에 적용했던 @Transactional을 조금은 더 필요한 부분에 사용할 수 있도록 리팩토링을 하였다.

Chapter 6. AOP

6번 째 챕터인 AOP는 내가 가장 제대로 이해하고 싶었던 기술 중 하나였다, 스프링의 3대 기술인 IoC/DI, AOP, PSA 중 하나이며, AOP를 잘 이해하고 있으면 앞으로 개발을 할 때 많은 부분에서 용이하게 쓸 수 있을 거 같아서 흥미가 많았던 챕터였다, 아래는 내가 느낀 중요한 키워드들이다.

AOP란?
여러 관련된 패턴들
포인트 컷

AOP는 핵심 기능과 부가 기능을 분리하여 개발자들이 핵심 기능(비즈니스 로직)에 집중할 수 있도록 하는 프로그래밍 방식이다, 나 같은 경우에는 AOP를 이용하여 사용자 접근과 관련된 로직을 비즈니스 로직에서 뺼 수 있었는데, 기존에는 토큰을 받아오면 매 메서드마다 사용자를 인증하는 코드를 매번 가져왔어야 했지만, 이는 엄청난 코드 중복을 발생했고 AOP를 이용하여 Accessor 를 만들어서 더욱 편하게 사용자 접근을 관리할 수 있었다,

그리고 여기서 끝이 아니라 AOP와 관련해서 한 번쯤 들어봤을 프록시와 데코레이터 패턴이 밀접한 관계라는 사실을 알 수 있었다, 프록시는 타깃에 대한 접근 방법을 제어해주는 역할(어느 순간 수정이 안되는지, 언제 생성 되는지 등)을 해주며, 데코레이터 패턴은 타깃에 부가적인 기능을 런타임 시에 동적으로 부여해주는 패턴이었다,

그리고 포인트 컷은 부가 기능을 적용할 위치를 뜻하는 단어인데, 나 같은 경우에는 앞서 Interceptor를 테스트 영역에도 적용 시켜서 의미 없이 몇 분동안 삽질을 한 경험이 있었다, 그래서 나의 경우 포인트 컷이 중요한 키워드로 다가왔었다.

Chapter 7. 스프링 핵심 기술의 응용

7 번째 챕터인 스프링 핵심 기술의 응용에서는 스프링 DI와 서비스 추상화 등을 이용하여 SQL 서비스 기능을 점진적으로 확장 및 발전시키는 과정을 다루었다, 근데 나 같은 경우에는 이 챕터가 여태까지 내가 읽어왔던 1~6 챕터를 정리해주는 느낌이 강하게 들었다, 덕분에 책을 읽으면서 사소한 의문들이 많이생겼다, 의문들은 아래와 같다.

현재 내 서비스에 동시성 문제를 유발 시키는 부분이 있을까?
계속해서 분리해서 관리하는게 좋다고 하는데 그 분리의 기준이(최소 단위)가 뭘까?
계속해서 XML을 통해서 빈 메타 정보를 설정하는데 굳이 왜 이걸 쓰는걸까?
의존해서 가져오는 경우에는 무조건 인터페이스를 써서 느슨하게 연결하는게 좋은 설계일까?
자동와이어링을 이용하면 컨테이너가 이름이나 타입을 기준으로 알아서 준비를 하는데 자동 주입이 어려운 경우는 어떤게 있을까?
로우 레벨의 기준은 어디까지인걸까?
저수준 기술을 알면 어떤 이점이 있을까?

와 같은 의문들이 생겼고, 책을 읽다가 답을 찾은 경우도 있고 나중에 디스코드로 옮기는 과정에서 내용을 추가한 경우도 있다, 때문에 저 질문에 대한 답변을 기억하는 경우도 있고 희미하게 기억하는 경우도 있다, 여튼 다른 챕터에 비해서 사소한 부분에서 많은 의문이 생겼던 파트였다,

특히나 흥미로웠던 점은 700페이지 가까이 나오지 않았던 스프링 3.1버전이 이번 챕터에서 처음으로 나왔다는 점이다, 스프링 3.1버전 부터는 어노테이션과 관련된 얘기가 많아졌는데, 왜 어노테이션이 등장했는지와 스프링은 1.0부터 3.1까지 거의 완벽에 가까울 정도로 구버전 호환성을 유지하고 있다는 점이나 그 이유가 스프링의 근본이 변하지 않았기 때문이라는 이유를 들었을 때는 몸에 소름이 돋았다, 덕분에 지금 읽고 있는 토비의 스프링 Vol.2를 더 재밌게 읽을 수 있는 기반이 되었다,

Chapter 8. 스프링이란 무엇인가

가장 중요한 파트라고 생각한다,

아무리 손으로 적고 그걸 디스코드에 옮기고 다시한번 노션에 옮기더라도 모든 부분을 기억못한다, 나는 멍청하기 때문에 솔직하게 읽은 시간에 비하여 다른 사람보다 효율이 떨어졌을 수도 있다, 그리고 이 의심은 책을 읽으면서 당장에 내 문제점을 찾고 내가 성장을 한다는걸 느끼고 있음에도 불구하고, 이미 고질병이 되어버렸기에 계속해서 의심했다,

하지만, 이 챕터를 통해 나름 괜찮게 공부 했다는걸 알 수 있었다, 조금 뜬금없는 없는 얘기이지만 내가 옛날에 편집이나 블로그를 운영했을 시절, 어느순간 갑자기 잘해지는 시기가 있었다, 어릴 때는 하다보니깐 잘된줄 알았지만, 성인이 된 지금은 매번 그 시기마다 '궁극적인 목적'를 자연스럽게 정립했고, 나는 그 정의를 잘 지켰었다,

예를 들어, 편집의 경우 간혹 재미 없는 부분을 편집으로 살리고자 하는 경우가 있는데, 이건 틀린 접근이라 생각하고 있다, 편집의 궁극적인 목적은 편집이 '주'가 되어선 안된다, 영상에 나오는 출연자들이 '주'가 되어야 하며 출연자들이 재밌어야지 몰입이 된다, 때문에 대충 컷편집하고 연출으로 살리는 경우도 있는데, 그거보다 영상 구성을 잘하고 재밌는 부분만 살리면 솔직히 큰 편집이 필요없다, 실제로 내 편집의 장점은 이것이었고, 내 영상은 다른 사람의 영상보다 약 1.5배씩은 조회수가 잘 나왔었다.

얘기가 중간에 산으로 갔지만, 사실 이것도 빌드업이다, 앞서 나는 책을 읽으면서 정리를 꾸준히 했다고 말했다, 그리고 챕터를 진행하면서 점점 내가 생각하는 스프링이 무엇인지에 대한 정의를, 나만의 방법대로 정립할 수 있었고, 큰 기대를 하지 않고 읽은 이 챕터에서, 내가 여태까지 정립한 정의가 저자가 생각하는 정의와 매우 유사하다는 사실을 알 수 있었다, 그리고 이걸 꺠달은 나는 "드디어 내가 옳은 방향으로 가고 있구나" 라는 생각이 들었다,

한 가지 예시로 들자면, 처음 스프링 공부를 했을 때는

"자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경랑급 애플리케이션 프레임워크"

라는 스프링의 정의를 달갑게 받아들이지 못했다, "그래서 뭐 어쩌라고?" 라는 느낌이었다, 하지만 약 2주간 스프링의 이해와 원리를 공부하다 보니 이제는 저 정의가 스프링을 표현할 수 있는 아주 정확한 방법이라고 생각한다,

DI는 미래를 프로그래밍 하는 거다.
자바의 근본적인 목적은 객체지향 프로그래밍을 통해 유연하고 확장성 좋은 애플리케이션을 빠르게 만드는 거다.
원래 엔터프라이즈 개발은 편하지 않기 때문이다.

실제로 책에 나온 내용들 중 하나이고 가장 마음에 드는 3개만 간추려서 가져왔다, 이 세 가지만 잘 이해를 했다면 위에 정의가 왜 그런지 이해하기 쉬울 것이다.

별개로 이 챕터에서 특히 마음에 들었던 부분이 하나 있는데, 스프링을 잘 쓰기 위해서 자바 언어 문법을 공부하고 JDK의 API 사용법을 자세히 공부하거나 자바 언어 스펙까지 공부한다고 해서 스프링을 잘 다룰 수 있냐? 라는 의문에 대하여, 저자가 아주 시원하게 그건 아니라고 한 점이다, 나도 가장 중요하게 여기는게 목표를 확실하게 인식하고 정답이 없는 영역이더라도 정답과 가까운 영역에라도 가고자하는 마음이라고 생각한다, 문법을 모르면 공부하면 되고 자바 언어 스펙을 몰라서 문제가 발생하면 그것도 공부하면 된다, 하지만 정답이 없는 문제를 해결할 수 있고, 그 상황이 익숙한 상황이 되어야지 좋은 개발자가 되는 길이라고 생각한다,

Chapter 9. 스프링 프로젝트 시작하기

포스팅이 너무 길어졌기 때문에 챕터 9는 조금 더 짧게 적도록 하겠다, 토비 9장은 간략하게 아키텍처 관련해서 깊게 생각해볼 수 있는 챕터였다, 오브젝트 레벨을 넘어서 아키텍처 레벨에도 객체지향을 적용하여 더 유연한 설계를 해야겠다는 생각을 가졌다,

그리고 각 영역에서 처리해야하는 일을 명확하게 나눠야한다, 예를 들면 HttpServletRequest가 Service로 넘어가서 처리되어선 안된다, 근데 내가 그짓을 했다, 조회수 업데이트 과정에서 HttpServletRequest를 받는데 그걸 Service 영역에서 처리가 되도록 해서 코드 몇줄을 수정하니 영역을 확실하게 나눌 수 있었다.

여튼, 챕터9에서 내가 중요하게 여긴 부분은 아키텍처 설계이다.

최고의 선택

지금까지 내 포스팅을 읽었다면, 소제목의 이유를 이해할 수 있을거다, 처음 선택한 책으로 토비의 스프링 Vol.1은 정말 최고의 선택이었다, 문제와 의문과 성장의 연속이었고 솔직하게 말하자면 위에 내용도 어느정도 줄인 버전이다~~(앞서, 요약만 해서 2만자가 넘는다고 했다)~~, 이제야 두 번째 책인데 정말 많은걸 얻을 수 있었다, 그래서 책 10권을 다 읽은 후가 기대되는 부분이다.

여튼 이걸 비유하자면, 보통 공포게임이 스토리가 좋은 경우가 많은데, 공포게임을 한번 해보고(서비스를 만들어보고) 유튜브를 통해서 공포게임 스토리 요약본(토비의 스프링)을 보는 느낌이었다! (이게 맞나?), 이외에도 과거에 POCU 아카데미에서 객체지향 공부를 했을 때, 프로그래밍 패러다임과 관련해서 여러 진영이 싸우는 경우가 있다고 들었는데, 당시에는 "너무 호들갑 아닌가..?" 라고 생각했는데, 이제 뭔가 조금은 그 이유를 알 거 같은 기분이다..

객체지향의 사실과 오해

끝으로, 원래는 객체지향의 사실과 오해를 먼저 읽었는데, 결론적으로 이 책은 절반 가량 읽고 다음을 기약했다, 그 이유로는 객체지향의 사실과 오해는 이상한 나라의 앨리스를 예시로 들어서 책 제목 그대로 객체지향이 무엇인지, 놓치고 있느 핵심이 무엇인지, 어떻게 활용해야하는지 등을 다루는 책이었다,

처음 책을 읽으면서 들었던 생각은 "조금만 더 일찍 봤어야 했나"라는 생각이 들었지만, 이후에는 "혹시 내가 아직 경험이 부족해서 저자의 전달을 만족할 만큼 이해가 안되는건가?" 라는 생각이 들었고, 결론적으로 객체지향의 개념을 설명하기 위해서 지속적으로 앨리스를 비유했고 대부분이 '기존에 알고 있던 사실의 검증' 느낌이 났었기에 몰입하기 조금 어려웠다,

때문에 당장에 필요성도 떨어지는 느낌만 들어서 책을 절반 가량만 읽은 상태이고 나중에 다시 읽어볼 거 같다.

감사합니다.

chisae

무형자산을 만들고 싶은 개발자

다음 포스트