부록 A. 프런트엔드 ↔︎ Spring 멘탈 모델 대조표
본문 곳곳에서 “프런트 다리”로 등장한 대응을 한자리에 모았다. 새 개념을 만날 때마다 이 표를 빠른 참조 카드로 곁에 두자.
| 프런트(React/Next/Node) | Spring 백엔드 | 핵심 차이·주의 | 본문 |
|---|---|---|---|
fetch로 요청 보내는 클라이언트 | 요청을 받는 서버 | 상태코드·직렬화를 내가 결정 | 1장 |
| Next.js API routes / 서버액션 | @RestController + @GetMapping | 라우팅이 어노테이션 기반, 메서드=핸들러 | 3장 |
package.json / npm run dev / npm run build | build.gradle / ./gradlew bootRun / ./gradlew build | 빌드 도구가 의존성·실행·산출물을 맡음 | 3장 |
props/context로 의존성 전달, NestJS @Injectable | DI/IoC 컨테이너, 생성자 주입 | 런타임 자동 와이어링 — 무엇으로 치환되는지 확인 | 4장 |
fetch().json() 수동 파싱 | Jackson 자동 직렬화 + @Valid | 검증·역직렬화가 프레임워크 책임 | 5장 |
| supertest로 요청 던지고 단언 | MockMvc + @WebMvcTest | “이 요청 → 이 응답” 단언, 같은 모양 | 5장 |
| Prisma/Drizzle ORM | JPA/Hibernate, 영속성 컨텍스트·더티 체킹 | “save 안 했는데 바뀜” 등 비가시 동작 | 6·7장 |
| React Query/SWR 캐시 | 영속성 컨텍스트 1차 캐시 | 캐시 수명이 트랜잭션 한 번으로 짧음 | 7장 |
Next.js middleware.ts / Express 미들웨어 체인 | Spring Security 필터체인 | 컨트롤러 닿기 전 줄지어 가로챔 | 9장 |
토큰을 localStorage vs httpOnly 쿠키에 저장 | JWT(stateless) vs 세션(stateful) | 저장 위치·폐기 전략이 보안 트레이드오프 | 10·11장 |
| Next.js SSR / 서버 컴포넌트 | Thymeleaf SSR(MPA) | “데이터+템플릿→완성 HTML”의 더 단순한 모델 | 12장 |
컴포넌트에 props 내려 주기 | Model에 데이터 담아 템플릿에 넘기기 | 전달이 클라이언트가 아니라 서버 안에서 일어남 | 12장 |
| 스펙 합의 → 구현 → 테스트 | “Ask me questions” → Plan Mode → @WebMvcTest/@DataJpaTest | AI에게 곧장 코드 시키지 말고 먼저 말로 합의 | 13장 |
부록 B. 신선도 함정 체크리스트
AI나 인터넷이 자신 있게 건네는 코드에서 “시간이 멈춘 평균값”을 가려내는 빠른 점검표다. Spring Boot 3.x / Spring Security 6.x / jakarta.* 기준으로 아래 좌측 패턴이 보이면 우측으로 고친다.
네임스페이스
| 구버전(의심) | 3.x 기준(정답) | 본문 |
|---|---|---|
import javax.persistence.* | import jakarta.persistence.* | 6장 |
import javax.validation.* | import jakarta.validation.* | 5장 |
import javax.servlet.* | import jakarta.servlet.* | 10장 |
Spring Security (6.x)
| 구버전(의심) | 6.x 기준(정답) | 본문 |
|---|---|---|
extends WebSecurityConfigurerAdapter | 제거됨 → SecurityFilterChain 빈 | 9·10장 |
configure(HttpSecurity) 오버라이드 | @Bean SecurityFilterChain filterChain(...) | 10장 |
authorizeRequests() | authorizeHttpRequests() | 9·10장 |
antMatchers() / mvcMatchers() | requestMatchers() | 9·10장 |
.and() 체이닝 | 람다 DSL 블록(auth -> auth...) | 10장 |
라이브러리
| 구버전(의심) | 최신 기준(정답) | 본문 |
|---|---|---|
jjwt Jwts.parserBuilder() / setSubject() | jjwt 0.12.x Jwts.parser().verifyWith() / subject() | 10장 |
점검 습관: ① import 첫 줄이
jakarta로 시작하는가 → ② Security가SecurityFilterChain빈인가 → ③authorizeHttpRequests·requestMatchers를 쓰는가 → ④ 라이브러리 API가 최신 빌더인가. 하나라도 어긋나면 시점이 안 맞는 코드다. 의심스러우면 AI에게 “이 코드 Spring Security 6.x에서 컴파일돼?”라고 되물어 스스로 교정하게 하자.
부록 C. REST의 엄밀한 정의와 HATEOAS
1장과 5장에서 “REST는 규칙이 아니라 아키텍처 스타일”이라고만 짚고 깊이 다루지는 않았다. 더 알고 싶은 독자를 위해 한 발짝만 더 들어가자.
REST는 로이 필딩(Roy T. Fielding)이 2000년 박사학위 논문(Architectural Styles and the Design of Network-based Software Architectures, UC Irvine, 5장)에서 정리한 아키텍처 스타일이다. 핵심은 여섯 가지 제약의 조합이다.
- client-server — 관심사를 클라이언트와 서버로 분리한다.
- stateless — 서버는 요청 사이의 상태를 들고 있지 않는다(1장의 그 stateless, 10장 JWT의 뿌리).
- cacheable — 응답은 캐시 가능 여부를 명시할 수 있어야 한다.
- uniform interface — 일관된 인터페이스로 자원을 다룬다(이 안에 HATEOAS가 들어 있다).
- layered system — 중간 계층(프록시·게이트웨이)을 둘 수 있다.
- code-on-demand (선택) — 서버가 실행 가능한 코드를 내려 줄 수 있다.
이 가운데 업계가 거의 지키지 않는 것이 HATEOAS(Hypermedia As The Engine Of Application State)다. 엄밀한 REST에서 응답은 데이터뿐 아니라 “다음에 무엇을 할 수 있는지”를 가리키는 링크(하이퍼미디어)를 함께 담아야 한다. 클라이언트가 URL을 하드코딩하는 대신 응답이 안내하는 링크를 따라 상태를 전이한다는 뜻이다.
현실의 “REST API” 대부분은 여기까지 가지 않는다. HTTP + JSON + 자원처럼 보이는 URL 수준의 느슨한 차용에 머문다. 그게 틀린 건 아니다. 다만 누군가 “그건 진짜 REST가 아니야”라고 할 때, 그 말이 바로 이 HATEOAS에서 나왔다는 것을 알아 두면 당황하지 않는다.
참고문헌
이 책은 아래 자료들을 토대로 했다. 기술 문서·블로그는 빠르게 바뀌므로, 검색 시점(2026-05-25)과 버전 메타를 함께 적는다. 실제 작업 전에는 공식 문서를 1차 근거로 재확인하기 바란다.
표준 · 권위 있는 1차 근거
- RFC 9110 — HTTP Semantics. (메서드·상태코드의 표준 정의. 1장.)
- RFC 6265 — HTTP State Management Mechanism (Cookies). (쿠키의 표준. 1·11장.)
- RFC 7519 — JSON Web Token (JWT). (JWT 구조의 표준. 10장.)
- Spring Boot 버전·지원 종료 정책 — endoflife.date/spring-boot, spring.io. 3.5 출시 2025-05-31, OSS 지원 종료 2026-06-30 / 4.0 계열 출시 2025-11-30, 4.0.6 2026-04-23.
- Spring Boot 3.0 Release Notes — github.com/spring-projects/spring-boot/wiki. Spring Boot 3.x = Java 17+ / Spring Framework 6.
- Preparing for Spring Boot 3.0 (javax→jakarta) — spring.io/blog (2022-05-24). Jakarta EE 9 기준.
- Spring Security without the WebSecurityConfigurerAdapter — spring.io/blog (2022-02-21). Security 6.x
SecurityFilterChain기준.
이론 · seminal 문헌
- Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. PhD diss., UC Irvine. (REST. 1·5장, 부록 C.)
- Fowler, M. (2004). Inversion of Control Containers and the Dependency Injection pattern. martinfowler.com. (IoC/DI, 생성자 주입. 4장.)
- Evans, E. (2003). Domain-Driven Design. Addison-Wesley. (Repository 패턴. 6장.)
- Neward, T. (2006). The Vietnam of Computer Science. (ORM 임피던스 불일치·추상화 누수. 6·8장.)
실무 자료 (블로그 · 가이드 · 커뮤니티)
- REST 검증·예외·
ResponseEntity— baeldung.com (exception handling for REST), dev.to. Spring Boot 3.x / Jakarta Bean Validation 기준. (5장.) - N+1 해법(JOIN FETCH·
@EntityGraph·배치 페치·DTO 프로젝션) — baeldung.com, tech.asimio.net, 국내외 회사 기술 블로그 포스트모템. 개념 안정. (8장.) - JWT vs 세션 논쟁(2025 흐름) — medium, ducktypelabs.com, stytch.com. 2025 인증 논쟁. (10·11장.)
- Spring Security 6
SecurityFilterChain— danvega.dev, baeldung.com. Security 6.x 기준. (9·10장.) - Thymeleaf vs React SSR/CSR — javaguides.net, wimdeblauwe.com. 2024~2025. (12장.)
- AI 페어코딩 / 스펙 주도 개발 — github.blog (spec-driven development), addyosmani.com, Anthropic Claude Code 공식 문서. 2025-10~2026-05. (2·13장.)
커뮤니티 자료(인프런 김영한 Spring 강의, 우아한형제들 백엔드 로드맵, OKKY·r/SpringBoot·velog의 반복 패턴 등)는 “검증된 사실”이 아니라 현장의 공감·논쟁 소재로 활용했다. 본문의 사실 주장(버전·API·수치)은 위 1차·권위 근거와 대조해 기재했다.