[26년 독후감 08] 부트캠프 백엔드 개발자 편 with 스프링 부트 : “왜?”를 설명할 수 있는 개발자가 되기 위해

한빛미디어에서 도서를 제공받아 솔직하게 쓴 글입니다.

📖 책 정보

• 책 제목: 백엔드 개발자 편 with 스프링 부트
• 저자: 김송아
• 출판 연도: 2026년 1월
• 장르: IT/프로그래밍 · 백엔드 개발 · 스프링 부트 실전 입문서

 

❓ 책을 고른 이유 (물음표)

한빛미디어의 ‘나는 리뷰어다 2026’에 올해 처음 선정되면서 이 책을 전자책으로 지원받아 읽게 되었다. 작년에 한 번 떨어졌던 경험이 있었기에, 이번 선정은 개인적으로 더 의미 있게 다가왔다. 단순히 책 한 권을 읽는 기회가 아니라, 지난 1년 동안 꾸준히 읽고 쓰며 쌓아온 시간에 대한 작은 증명처럼 느껴졌다.

나는 프로젝트를 진행할 때 주로 백엔드를 맡아 왔다. 스프링 부트를 활용해 REST API 구조를 설계하고, 프론트엔드와 협업하며 기능을 구현하는 과정은 꽤 익숙한 영역이었다. 하지만 최근 6~7개월 동안은 다른 도구와 환경을 사용하며 개발하다 보니, 문득 “내가 스프링 감각을 잃은 건 아닐까?”라는 불안이 스쳤다. 기본을 안다고 생각했지만, 막상 다시 처음부터 설명해보라 하면 머뭇거리게 되는 순간들이 있었다.

그 시점에 이 책을 고르게 되었다. 이 책은 단순히 스프링 부트 문법을 나열하는 입문서가 아니라, “백엔드 개발자는 실제로 무엇을 고민하고 어떻게 설계하는가”에 초점을 둔 커리어 지향형 실전 가이드에 가깝다는 인상을 받았다. 내가 알고 있던 개념을 다시 구조적으로 정리하고, 어렴풋이 알고만 있었던 부분은 명확하게 언어화하는 시간이 될 것 같았다.

특히 웹 애플리케이션의 전체 흐름인 [Controller → Service → Repository → DB] 이 구조를 다시 한 번 머릿속에서 정리하고, “왜 이렇게 설계하는지”까지 이해하는 것이 이번 독서의 목표다. 단순 복습이 아니라, 내 수준을 한 단계 끌어올리는 정리의 시간. 그래서 이 책이 더욱 설레는 선택이었다.

📚 독서 과정

• 읽은 기간: 26.02.11 - 26.02.25

 

 

✍️ 책 내용

이 책은 스프링 부트를 “알려주는 책”이라기보다, 지식을 진짜 내 것으로 만드는 방법을 훈련시키는 책이다. 특정 기술의 사용법을 빠르게 익히는 것보다 더 중요한 건, 그 기술을 내 언어로 설명할 수 있는 사고력—즉 학습 능력이라는 메시지가 책 전반을 관통한다.

특히 인상 깊었던 지점은, 어노테이션 하나와 설계 구조 하나도 “그냥 넘어가지 않는다”는 태도다. 먼저 직접 구현해 보고, 그 과정에서 불편함을 몸으로 겪게 만든 다음, 그제서야 “아, 이래서 스프링이 필요했구나”라는 깨달음에 도달하게 한다.

1) “일 잘하는 백엔드 개발자”의 정의부터 다시 세우기

책은 백엔드 개발자의 실력을 단순히 “코드를 얼마나 잘 짜는가”로 판단하지 않는다. 진짜 역량은 결국 두 가지로 드러난다고 말한다.

• 얼마나 스스로 이해하고 깊이 생각하는가
• 그 이해를 바탕으로 스스로 문제를 해결할 수 있는가

언어와 프레임워크는 도구일 뿐이고, 그 도구를 선택하고 사용하는 개발자가 어떤 사고를 하느냐가 핵심 경쟁력이라는 것이다. 그래서 문법이나 사용법에만 의존하지 말고, “왜 이렇게 동작하는가”를 끊임없이 질문하고 직접 답을 찾아가는 습관을 강조한다.

스프링 부트 개발자에게 이 습관이 더 중요한 이유도 분명하다. 스프링은 너무 많은 일을 개발자 대신 해주기 때문에, “쓸 줄 아는 것”에서 만족하면 쉽게 단순 사용자가 되어버린다. 반대로 스프링이 왜 이렇게 만들어졌는지, 어떤 불편함을 해결하기 위해 이 개념이 등장했는지까지 거슬러 올라가 생각하면, 그때부터는 진짜 개발자로 성장할 수 있다는 메시지다.

2) “외우지 말고, 이해하고, 선택하라”

책은 대놓고 선언한다.

지금부터 우리는 그 어떤 것도 외우지 않는다.

대신 모든 것을 이해하고, 생각하고, 선택하는 연습을 한다.

이 흐름에서 핵심 축으로 등장하는 개념이 바로 IoC/DI다. 스프링을 “편하게 쓰는 기술”로만 접근하면, 이 개념들이 추상적인 단어로 남기 쉽다. 하지만 이 책은 그 단어를 ‘정의로 암기’시키기보다, 왜 그런 구조가 생겨났는지를 납득시키는 방향으로 전개한다. 결과적으로 독자는 단어를 아는 사람이 아니라, 구조를 설명할 수 있는 사람이 되어야 한다.

3) 어노테이션은 “주석”이 아니라 “소통”이다

책에서 재미있게 읽힌 포인트 중 하나가 어노테이션에 대한 시선이다. 예를 들어 @Override 하나를 추가했을 뿐인데, 그 의미는 단순히 “오버라이드 표시”를 넘어선다. 어노테이션은 컴파일러(그리고 스프링)에게 “내 의도가 이거니까, 틀리면 잡아줘”라고 요청하는 문법이다.

즉, 어노테이션은 그 자체로 기능을 구현하는 게 아니라, 다른 도구가 기능을 수행할 수 있도록 힌트를 주는 장치다. 스프링의 ‘마법’은 결국 이 소통 방식이 촘촘하게 설계되어 있다는 데서 온다. 개발자는 그 의미를 알고 적절하게 선택해 쓰기만 하면 된다—하지만 그러기 위해서는 “왜 이 어노테이션이 필요한가”를 이해하고 있어야 한다.

4) 스프링 부트의 편리함 뒤에 있는 ‘역할’을 설명할 수 있어야 한다

스프링 부트는 자바 기반 백엔드 개발에서 대표적인 프레임워크로 자리 잡았고, 덕분에 우리는 더 편하게 개발할 수 있다. 하지만 책은 여기서 멈추지 않는다. 스프링 웹, 스프링 MVC 같은 프레임워크 구성 요소들이 각각 어떤 역할을 하고, 왜 필요한지를 명확히 아는 것이 중요하다고 말한다.

그리고 “그걸 어떻게 증명하느냐”에 대한 답도 명확하다.

전문 용어를 달달 외워서 말하는 것이 아니라, 스스로 이해한 언어로 설명할 수 있으면 된다.

예를 들어 누군가가 DI와 IoC를 설명해 달라고 했을 때, 교과서 문장을 읊는 것이 아니라 “내가 겪은 불편함 → 해결 구조”로 자연스럽게 말할 수 있어야 한다.

5) 성장의 기본기: 클린 코드, 성능, 안정성

책이 강조하는 성장 훈련은 ‘개념 이해’에서 끝나지 않는다. 실제로 백엔드 개발자가 성장하려면 반드시 훈련해야 할 영역으로 클린 코드 습관을 제시한다.

• 메서드를 기능 단위로 잘게 나누기
• 변수명/메서드명으로 의도를 드러내기
• 주석은 정말 필요할 때만
• 패키지 구조로 설계 의도를 보여주기
• 역할(컨트롤러/서비스/리포지토리)에 맞는 네이밍 일관성 유지하기

클린 코드는 보기 좋게 정리된 코드가 아니라, 협업 가능하고 유지보수 가능한 코드라는 관점이다. 그래서 프로젝트 단위로 컨벤션을 맞추는 것(들여쓰기, 줄바꿈, 파라미터 정렬 등)도 “실무 역량”으로 연결된다.

또한 실제 서비스 관점에서는 성능 최적화와 안정성도 사용자 경험을 좌우한다. 캐싱, 인덱싱, 쿼리 최적화 같은 키워드를 소개하면서, 중요한 건 “개선했다”가 아니라 수치로 설명하는 습관이라고 강조한다. 800ms가 150ms로 줄었다는 식의 근거가 면접이나 리뷰에서 훨씬 강력한 설득력을 만든다는 것이다. 안정성 측면에서도 예외 처리, 입력값 검증, 인증/보안 등 기본기가 사용자 신뢰를 만든다고 짚는다.

6) 생성 AI 시대, 더 중요해진 건 ‘이유를 말하는 능력’

생성 AI의 등장으로 채용 시장도 변하고 있다. 이제는 “코드를 잘 짜는가”만으로 평가하기 어렵다. AI도 코드를 만들 수 있기 때문이다. 그래서 면접에서는 점점 더 이런 질문이 중요해진다.

• 왜 이 기술을 선택했는가?
• 다른 선택지는 없었는가?
• 이 문제를 어떤 판단으로 풀었는가?

즉, 결과물이 아니라 이유와 원리를 설명할 수 있는지 본다. 책은 이 지점에서 “생각하는 개발자”라는 키워드를 다시 한 번 강하게 밀어 넣는다.

7) 프로젝트 기록도 ‘나열’이 아니라 ‘핵심 기능 중심’으로

마지막으로 프로젝트 정리 방식에 대한 조언도 실전적이다. 프로젝트 경험을 모두 나열하기보다, 자신 있는 한두 가지 기능을 중심으로 어떤 기술로 어떤 문제를 해결했는지를 강조하라는 것. GitHub 역시 단순 코드 저장소가 아니라, 협업과 문제 해결 과정을 보여주는 도구이므로 README에 “이 프로젝트에서의 고민과 해결 방식”을 요약해두면 훨씬 임팩트 있게 전달된다고 말한다.

결국 기업이 궁금해하는 건 “뭘 썼냐”보다 “왜 썼고, 어떻게 이해했냐”다. 이 책은 그 질문에 답하는 훈련을 처음부터 끝까지 시켜준다.

 

❗ 책을 덮으며 느낀 변화 (느낌표)

이 책을 덮고 나니, 나는 그동안 스프링을 “써왔다”는 사실과 “이해해왔다”는 사실이 다르다는 걸 인정하게 되었다. 6개월에서 1년 반 전, 한창 스프링 부트를 붙잡고 프로젝트를 만들던 시절이 떠올랐다. 그때도 분명 열심히 했고, REST API를 만들고 계층을 나누며 나름 구조를 고민했다고 생각했다. 하지만 돌아보면 인텔리제이의 자동완성과 스프링 부트의 편리함에 많이 의존한 채, 동작하는 코드에 만족했던 순간도 적지 않았다. 이번 독서는 마치 저자가 옆에서 함께 예전 공부를 다시 정리해주는 느낌이었다. “아, 이 코드에 이런 뜻이 있었지.”, “맞아, 이렇게 설명했었지.” 하며 흩어져 있던 개념들이 하나의 그림으로 연결되었다. Controller–Service–Repository 구조가 단순한 관습이 아니라 책임을 나누기 위한 설계라는 점, IoC와 DI가 정의 암기가 아니라 객체 관리 철학이라는 점이 다시 또렷해졌다. 무엇보다 ‘왜?’라는 질문을 습관처럼 던지는 태도가 실력을 만든다는 메시지가 크게 남았다. 이제는 기능이 돌아가는지보다, 내가 이 구조를 왜 선택했는지 설명할 수 있는지를 먼저 떠올리고 싶다. 다음 프로젝트에서는 구현부터 시작하기보다 설계 의도를 먼저 정리하고, DI 방식을 선택한 이유를 기록하며, 어노테이션 하나를 쓰더라도 그 배경을 생각해보려 한다. 이 책은 새로운 기술을 알려준 책이라기보다, 내가 이미 배웠던 스프링을 다시 내 언어로 정리하게 만든 책이었다. 그리고 그 과정에서 나는 ‘코드를 작성하는 사람’에서 ‘설계를 이해하고 선택하려는 사람’으로 한 걸음 옮겨간 느낌을 받았다.

🌟 총평 및 추천 여부

• 별점: ★★★★☆ (5점 만점)
• 이 책을 추천하는 대상: 스프링 부트를 한 번쯤 써봤지만 개념이 흐릿한 개발자
• 한줄평: “스프링을 쓰는 법이 아니라, 스프링을 이해하는 법을 가르쳐주는 책.”

---

다시 해보는 용어 정리

Web (웹)

1990년에 등장한 정보 공유를 위한 인터넷의 가상 공간이다. 전 세계 어디에서든 인터넷에 연결되어 있다면 접속할 수 있는 공간이다.

API (Application Programming Interface)

정해진 규칙에 따라 애플리케이션 간에 통신할 수 있도록 제공되는 인터페이스를 의미한다. 백엔드 개발자는 이 API를 만드는 역할을 한다.

REST API

API의 한 종류로, 인터넷에서 지켜야 하는 약속(HTTP 규칙과 구조)을 잘 지켜 자원(Resource)을 중심으로 소통하는 API를 말한다.

패키징 파일 형식: JAR vs WAR

프로젝트의 배포 파일 형식은 대표적으로 JAR과 WAR 두 가지가 있다.

• JAR (Java ARchive)
• 자바로 구현된 애플리케이션이 동작하는 데 필요한 클래스 파일, 라이브러리 파일 등을 포함한다. JRE(Java Runtime Environment)만 있어도 실행 가능하며 확장자는 .jar이다.
• WAR (Web ARchive)
• 웹 애플리케이션을 실행하는 데 필요한 리소스들의 압축 파일이다. 자바 애플리케이션 중에서도 특히 웹 애플리케이션을 패키징하기 위한 형식이며, 클래스 파일뿐 아니라 JSP, 서블릿(Servlet) 등 웹 관련 파일을 포함할 수 있다.
• 스프링 부트에서는 JAR 권장
• WAR는 외장 웹 서버가 필요한 경우가 많지만, 스프링 부트는 웹 서버를 내장하여 JAR로 패키징할 수 있기 때문에 JAR 사용을 권장한다.

프로젝트 폴더/파일 구조 (Gradle 기준)

• build/
• 프로젝트를 실행/빌드할 준비를 마치면 생성되는 폴더이다. 빌드 결과물들이 생성된다.
• gradle/
• 프로젝트에서 사용하는 Gradle 관련 파일이 저장된 폴더이다. 보통 직접 열어볼 일은 많지 않다.
• gradlew / gradlew.bat
  • gradlew: macOS/Linux용
  • gradlew.bat: Windows용
• Gradle Wrapper 실행 파일이다. 프로젝트를 패키징(예: JAR 생성)할 때 사용된다.
• settings.gradle
• 프로젝트 관련 설정 파일이다. 확장자가 .gradle인 파일은 Gradle이 사용하는 설정 파일이다.

IoC (Inversion of Control, 제어의 역전)

‘제어의 역전’이란 프로그램의 흐름을 제어하는 주체가 뒤집힌다는 뜻이다.

스프링에서 말하는 ‘프로그램의 흐름’은 객체가 언제 생성되고 사용되며 소멸되는지(라이프사이클)를 관리하는 것을 의미한다.

즉, 개발자가 하던 객체 관리의 제어권을 스프링 프레임워크가 가져가는 것이다.

한마디로 객체 관리를 스프링이 하겠다는 의미다.

컨테이너(Container)

IoC로 객체 제어권을 가져간 스프링은 객체들을 한 곳에서 쉽게 관리하기 위해 저장소(상자 역할)를 만든다.

개발자가 요청하면 알맞은 객체를 꺼내 전달한다. 이 상자가 컨테이너다.

• 스프링 컨테이너
• IoC 컨테이너
• DI 컨테이너

용어는 조금씩 다르지만 보통 같은 개념을 가리킨다.

스프링 빈(Spring Bean)

컨테이너 안에 들어 있는, 즉 스프링이 생성하고 관리하는 객체를 말한다.

DI (Dependency Injection, 의존성 주입)

DI는 ‘의존성 주입’이라는 뜻이다.

IoC로 객체의 제어권이 스프링에게 넘어갔기 때문에, 개발자가 객체를 직접 생성해서 쓰기보다는 필요한 객체를 스프링 컨테이너에 요청해 주입받아 사용하게 된다.

한 줄 정리

• IoC: 객체의 생성과 관리 제어권을 개발자가 아닌 스프링에게 위임하는 것
• 컨테이너: 스프링이 관리하는 객체들을 보관하고 관리하는 저장소
• 스프링 빈: 컨테이너 안에서 스프링이 생성하고 관리하는 객체
• DI: 필요한 객체를 직접 만들지 않고 스프링 컨테이너로부터 주입받는 것

핵심 개념 요약 (Spring MVC & 주요 어노테이션)

Spring MVC

요청(Request)과 응답(Response)의 흐름을 관리하는 웹 애플리케이션 구조이다.

Model–View–Controller로 영역을 분리해 유지보수성과 확장성을 높인다.

@Component

스프링이 관리해야 하는 객체임을 표시하는 기본 어노테이션이다.

스프링은 이를 자동으로 감지해 스프링 빈으로 등록한다.

HTTP 메서드

클라이언트와 서버 간 요청 목적을 정의한다.

각 메서드는 리소스에 대해 수행할 동작을 구분하며 RESTful 아키텍처에서 중요하게 사용된다.

Controller (컨트롤러)

사용자 요청을 받아 처리하고 응답을 반환한다.

HTTP 메서드(GET, POST 등)와 URL을 매핑하여 비즈니스 로직과 연결하는 다리 역할을 한다.

Service (서비스)

도메인 객체의 기능을 조합하거나 여러 리포지터리를 연동해 비즈니스 로직을 수행한다.

컨트롤러와 리포지터리 사이의 중간 계층이다.

Repository (리포지터리)

데이터베이스와 도메인 객체를 연결한다.

데이터의 저장, 조회, 수정, 삭제(CRUD)를 담당하며 비즈니스 로직과 분리된다.

@Autowired

스프링 컨테이너에 등록된 빈을 자동으로 주입받기 위한 어노테이션이다.

개발자가 직접 객체를 생성하지 않아도 스프링이 필요한 객체를 연결한다.

DDD (Domain-Driven Design)

비즈니스 도메인을 중심으로 프로젝트를 설계하는 방법론이다.

컨트롤러–서비스–리포지터리로 역할을 나누어 복잡한 로직을 구조화할 수 있다.

REST API 설계

URL 구조와 HTTP 메서드를 활용해 자원의 생성/조회/수정/삭제를 표현하는 방식이다.

쿼리 스트링, 경로 변수, Request Body 등 다양한 전달 방식으로 요청 데이터를 처리한다.

데이터 전달 흐름

요청 데이터는 컨트롤러에서 받아 서비스와 리포지터리로 전달된다.

각 계층은 역할에 따라 데이터를 가공하거나 저장하며 매개변수를 통해 객체 지향적으로 흐름을 이어간다.

@PathVariable

URL 경로에 포함된 값을 컨트롤러 메서드의 매개변수로 추출한다.

RESTful API에서 자주 사용한다.

@RequestBody

HTTP 요청 본문(body)에 담긴 데이터를 자바 객체로 변환해 읽어온다.

주로 POST/PUT 요청에서 JSON 데이터를 받을 때 사용한다.

Request Body (JSON)

여러 필드를 가진 데이터는 Request Body를 통해 JSON 형태로 전달된다.

JSON은 키-값 형태이며, 스프링은 이를 요청 객체에 자동 매핑해 처리한다.

객체 저장과 캡슐화

문자열이 아닌 객체 전체를 저장하려면 Map의 value 타입을 Product 등 객체로 확장한다.

객체 필드는 private으로 보호하고 getter로 필요한 값만 노출해 캡슐화를 유지한다.

예외 처리

존재하지 않는 데이터를 조회하는 상황처럼 API가 오동작할 수 있는 상황을 조건문 등으로 처리해 안정성을 높인다.

예외 처리는 사용자와 시스템 모두를 위한 기본적인 방어 장치이다.

@Service / @Repository

두 어노테이션은 @Component를 포함하며 계층의 역할을 명확히 드러낸다.

• @Repository: 데이터 접근 계층의 예외 처리 지원
• @Service: 도메인/비즈니스 로직 수행 클래스임을 표현