1. 읽기 전 나의 상태#
- 스프링 부트 사용에 급급하여 개념을 정리하지 않음(기본기 부족)
- 스프링이라는 거대한 태산에 압도당함
2. 인상 깊었던 내용(+ 추가 학습)#
2.1 1주 차 스프링 부트와의 첫 만남: 스프링 부트와 웹,API#
1. 스프링, 스프링 부트와의 첫 만남
2. 스프링 부트와 웹
3. 보이지 않는 곳의 핵심 기능,API
4. 스프링 부트 프로젝트의 시작- 프레임워크와 라이브러리의 가장 큰 차이점은 코드를 호출하는 지점(제어 흐름)이다.
- 프레임워크는 정해진 흐름 속에서 사용자의 코드를 호출한다. 라이브러리는 사용자가 직접 호출한다.
- 컴퓨터로 비유하면 스프링은 내부 구조, 동락 원리에 가깝다. 반면 스프링 부트는 컴퓨터를 실제 사용하는 경험이다.
- 컴퓨터를 처음 사용했을 때 CPU, RAM, 회로부터 배웠다면 금방 흥미를 잃었을 것이다. 마찬가지로 스프링도 우선 스프링 부트를 통해 사용 경험을 쌓고 자연스럽게 내부 원리(스프링)를 접하는 방법을 권장한다.
- 인터넷이 도로라면 웹은 인터넷 위에 달리는 자동차와 같다.
2.2 2주 차 스프링 코어와 프로젝트 시작#
5. 스프링 코어
6. 스프링 MVC
7. 컨트롤러와 HTTP
8. 모델- 스프링 코어의 핵심은 IoC(Inversion of Control) 컨테이너다.
- 스프링은 단순한 라이브러리가 아니다. 객체의 생성과 관계를 대신 관리하는 프레임워크다.
- 스프링의 IoC 구현을 따라가면 자연스럽게 DI, 컨테이너, Bean을 이해할 수 있다.
- MVC(Model-View-Controller)는 화면과 비즈니스 로직을 분리하기 위한 소프트웨어 설계 패턴이다.
- Spring Web MVC는 Servlet API 위에서 동작하는 웹 프레임워크다. 정확히는 Java Servlet API 기반 위에 추상화를 제공한다.
- Spring이 웹 애플리케이션 개발을 단순화하기 위해 등장한 만큼, MVC는 시작부터 핵심 구성 요소였다.
- Spring MVC 외에도 Spring WebFlux(Reactive Stream 기반, 고성능/비동기 스트림에 적합)가 있다.
- 과거 MVC는 서버 중심 구조였다. 하지만 현재는 React, Vue, Fetch API 등이 등장하면서 View와 일부 상태 관리가 클라이언트로 이동했다. 물론 서버에서도 여전히 MVC 구조를 사용한다.
- Spring MVC는 단순한 패턴이 아니다. 팀 개발의 기본 구조, 테스트 분리, REST API 설계 기반, 대규모 서비스의 구조적 안정성을 제공한다.
- Spring MVC는 화면을 분리하는 단순한 패턴이 아닌 관심사를 분리하여 유지보수성과 확장성을 확보하는 구조적 기반이다.
- 스프링에서 Model은 단순한 ‘데이터 객체’를 의미하지 않는다. 애플리케이션의 비즈니스 규칙을 담당하는 계층을 의미한다.
2.3 3주 차 난생 첫 프로젝트, 상품 조회와 등록 API#
14. 백엔드 개발자를 위한 면접 핵심 노트
9. 상품 등록 기능으로 학습하는 도메인 주도 개발 & 패키지 구조 - AI 시대의 개발자는 더 이상 단순 코드를 작성하는 사람이 아니다. 무엇을 만들어야 하는지 정의하고, AI가 생성한 결과를 검증하며, 문제를 재구성할 수 있는 사구력을 요구한다. 결국 차별화는 도구 사용 능력이 아닌 사고의 깊이에서 발생한다.
- 도메인 주도 개발(DDD, Domain-Driven Design)이란 기술 중심이 아닌, 비즈니스(도메인) 중심으로 소프트웨어를 설계하는 방법이다.
- 도메인은 기술이 아닌, 해결하려는 현실 세계의 문제다.
- 도메인은 단순 데이터 구조가 아닌 데이터가 지켜야할 비즈니스 규칙과 책임이 담겨있다.
- 일반적인 계층형 패키지 구조
- 간단한 프로젝트에서는 문제가 발생하지 않는다. 이해하기 쉽고 빠른 개발이 가능하다.
- 하지만 기능이 커지면 코드가 흩어진다. 도메인 응집도가 낮아지고 Service가 비대해진다. 비즈니스 규칙이 Service 계층에 집중되면 도메인 객체는 단순 (Anemic Domain Model) 데이터구조로 전략하기 쉽다.
- DDD
- 기술 계층이 아닌, 도메인(기능) 기준으로 패키지를 묶는다. 도메인 응집도가 높고 테스트하기 쉬워진다. 하지만 학습 비용이 높고 초기 설계 비용이 크다.
- 책에서는 DDD를 패키지 정리 방법으로 소개한다. 하지만 DDD는 단순한 구조 정리가 아닌 비즈니스 중심 설계 철학이다. Entity, Value Obeject, Aggregate, Ubiquitous Language와 같은 개념을 포함하며, 복잡한 도메인을 다룰 때 진가가 나타난다. 따라서 모든 프로젝트에 반드시 필요한 방법은 아니며, 규모와 복잡도에 따라 선택적으로 적용하는 것이 바람직하다.
- 실무에서는 레이어드 아키텍처와 도메인 중심 패키지를 섞어 사용한다.
3. 변화#
- 공식문서와 Quick Documentation 기능을 사용하는 비율이 증가했다.
- 학습과 정리의 중요성을 뼈저리게 느꼈다.
4. 앞으로의 계획#
- 프로젝트를 진행하며 삽질, 깨달은 내용 정리
마치며#
좋았던 점#
- 얇은 책이라 부담 없이 읽고 참여하기 좋았다.
- 최대한 쉽고 친절하게 설명해 주시려는 배려가 느껴졌다. 추가 학습을 위한 추천 키워드도 인상 깊었다.
- 자신감이 떨어졌거나, 어떤 내용을 학습해야 할지 벽에 부딪힌 상황에 읽기 좋다.
- 무심코 지나갔던 내용을 한 번 더 생각, 정리하는 시간을 가졌다.
- 깊이를 더하기 위해 공식 문서를 참고하고 매주 후기를 작성할 때 가장 좋았다. 특히 프로젝트 구조, 도메인 주도 설계(DDD, Domain-Driven Design)가 기억에 남는다.
아쉬웠던 점#
- 계곡에 가서 신발을 벗고 물에 발만 담근 채 돌아온 느낌이라 아쉬웠다.
- 설 연휴로 흐름이 끊겨 아쉬웠다.
- 실습이 적어 아쉬웠다.
- 능동적으로 참여하는 챌린지라기보단 정적으로 혼자 독서하는 기분이라 아쉬웠다. 참여하는 활동, 미션이 많았으면 좋겠다.