한빛미디어

❕ 한빛미디어 서평단 <나는 리뷰어다> 활동을 위해 도서를 협찬받아 작성한 서평입니다.

<부트캠프 백엔드 개발자 편 with 스프링 부트> 리뷰

프론트엔드 개발자로 일하면서 늘 마음 한켠에 남아 있던 질문이 있었다.
“나는 API를 잘 ‘쓰고’ 있는 걸까, 아니면 그냥 ‘사용만’ 하고 있는 걸까?”

서비스 규모가 커질수록 화면만 잘 만든다고 해결되지 않는 순간들이 생겼다. 데이터의 흐름, 서버의 구조, 응답 설계의 의도까지 이해하지 못하면 결국 한계에 부딪힌다는 걸 느꼈다. 그래서 단순히 스프링 문법을 배우는 게 아니라, 백엔드 개발자의 사고 흐름을 따라가 보고 싶다는 마음으로 이 책을 읽게 되었다.

1.  ‘순서’가 아니라 ‘구조’를 따라가는 구성
이전에는 HTTP, MVC, DI, REST를 각각 따로 배웠다. 그때마다 머릿속엔 키워드만 남고, 실제 서버 코드와 연결되지 않았다. 이 책은 다르다. 웹 → HTTP → API → 스프링 → MVC → DDD → HTTP Request 이 흐름을 따라가다 보면, 내가 지금 어디 단계에 서 있는지 인지하게 되고 단순한 기능을 구현하는 게 아니라, 구조 위에 코드를 쌓는 경험을 하게 된다.

2. API를 바라보는 시선이 달라졌다
예전에는 응답 구조가 불편하면 “프론트에서 쓰기 어려워요”라고 말하는 게 전부였다. 하지만 컨트롤러 → 도메인 → 설계 → API 구조로 이어지는 흐름을 이해하고 나니, API는 임의의 JSON 포맷이 아니라 도메인 설계의 결과물이라는 걸 깨달았다. 이제는 API를 보면 “왜 이렇게 만들었지?”, “이 구조는 어떤 책임 분리에서 나온 걸까?” 라는 질문부터 하게 된다.

3. @Component는 그냥 문법이 아니라 선언이다
@Service, @Component, DI… 그동안은 그냥 “붙이면 동작하는 것”이라고 생각했다.
하지만 객체 생성 책임이 어디에 있는지, 왜 스프링 컨테이너에 위임해야 하는지,
테스트와 확장성에 어떤 차이를 만드는지 직접 체감하게 된다. 객체를 내가 직접 생성하느냐, 프레임워크에 위임하느냐. 이 차이는 단순한 코드 스타일이 아니라 설계의 철학이었다.

4. 구현 중심 사고에서 설계 중심 사고로
예전의 나는 “주문 조회니까 GET으로 만들자.”, “URL은 /orders/{id}면 되겠지.” 정도에서 바로 구현에 들어갔다. 지금은 다르다. 이 요청은 어떤 도메인 책임인가? 이 URL은 도메인 개념을 잘 표현하고 있는가? 정말 단순 조회가 맞는가? 같은 기능이라도, 바라보는 깊이가 달라졌다.

5. 그냥 따라가다 보면 사고가 바뀐다
이 책의 좋은 점은 일부러 번거로운 구현을 먼저 경험하게 한다는 것이다. 그 다음에 DI와 IoC를 설명한다.
그래서 개념을 외우는 게 아니라 “아, 그래서 필요했구나” 하고 납득하게 된다.

6. 이제는 ‘사용하는 개발자’가 아니라 ‘이해하는 개발자’로
스프링 부트를 다루는 법을 배우는 책이 아니라, 왜 그런 구조로 설계되었는지를 이해하게 만드는 책.
복사·붙여넣기식 개발에서 벗어나 구조를 고민하는 개발자로 한 단계 나아가고 싶은 분들께 추천한다.

#한빛미디어 #나는리뷰어다 #부트캠프백엔드개발자편with스프링부트

좀 더 자세한 리뷰 보러 가기: https://blog.naver.com/ayeonjouvence/224201269039