Forge Fate
한국어
백엔드·인프라

초급에서 중급으로 성장하는 Spring 백엔드 개발자 실전 로드맵

약 22분

근거와 검증 범위 — 공식 문서 기반 학습 로드맵

공식 기술 문서를 참고해 학습 단계와 확인할 역량을 제안합니다. 특정 기간에 중급 역량을 얻는다고 검증한 과정이나, 모든 예제의 실행 결과를 모은 보고서는 아닙니다.

튜토리얼 몇 개를 끝내거나 애너테이션을 외웠다고 해서 Spring 애플리케이션의 전체 동작을 이해했다고 보기는 어렵습니다. 더 탄탄한 학습 과정은 기간이 아니라 역량으로 평가해야 합니다. 즉, 무엇을 설명하고 구현하며 테스트하고 진단할 수 있는지가 중요합니다.

‘중급 Spring 개발자’에 대한 공식 정의나 누구에게나 적용되는 검증된 학습 기간은 없습니다. 이 로드맵에서는 데이터베이스를 사용하는 중소 규모 서비스를 구축하고 테스트하며, 보안을 적용하고 문제를 진단해 운영할 수 있는 사람을 중급 개발자로 정의합니다.

1. 강의를 선택하기 전에 목표부터 정하기

“몇 달이면 끝낼 수 있을까?”라고 묻기보다 주제마다 다음 네 가지를 점검해 보세요.

  1. 어떻게 작동하는지 설명할 수 있는가?
  2. 예제를 그대로 베끼지 않고 구현할 수 있는가?
  3. 성공하는 경우와 실패하는 경우를 모두 테스트할 수 있는가?
  4. 문제가 발생했을 때 원인을 진단할 수 있는가?

학습 일정을 정할 때는 기존 프로그래밍 경험과 확보할 수 있는 학습·실습 시간을 고려하는 것이 좋습니다. 다만 검토한 근거 자료만으로는 이러한 요인이 학습 속도에 어떤 영향을 미치는지 확인할 수 없습니다. 따라서 일정은 반드시 지켜야 할 약속이 아니라 상황에 따라 조정할 수 있는 계획으로 생각하세요.

실용적인 중급 수준의 기준은 다음과 같습니다.

  • REST API를 개발하고 패키징할 수 있다.
  • 관계형 데이터베이스에 데이터를 저장할 수 있다.
  • 의미 있는 트랜잭션 경계를 설정할 수 있다.
  • 여러 범위에서 애플리케이션 동작을 테스트할 수 있다.
  • 인증과 인가를 적용할 수 있다.
  • 느린 데이터베이스 작업의 원인을 조사할 수 있다.
  • 운영에 필요한 신호를 외부에 제공하고 보호할 수 있다.

이 로드맵에서는 서로 관련된 개념을 같은 맥락에서 연습할 수 있도록, 단계가 진행될 때마다 하나의 프로젝트를 계속 발전시키는 방식을 권합니다. 이는 교육과정 구성을 위한 제안일 뿐, 서로 분리된 연습 문제보다 우수하다는 사실이 근거로 입증된 것은 아닙니다.

2. 1단계: Spring을 이해하는 데 필요한 Java 기초 다지기

이 로드맵에서는 Spring의 추상화에 크게 의존하기 전에 관련 Java 메커니즘부터 익힐 것을 권합니다. 그래야 Spring 내부에서 일어나는 일을 살펴볼 때 필요한 개념과 디버깅 도구를 갖출 수 있기 때문입니다. 다만 이런 학습 순서가 누구에게나 더 효과적이라는 사실이 검토된 근거로 확인된 것은 아닙니다.

먼저 다음 내용을 공부하세요.

  • 클래스, 객체, 인터페이스, 상속, 합성
  • 컬렉션과 제네릭
  • 예외와 스택 트레이스
  • 스트림과 함수형 인터페이스
  • 기본적인 단위 테스트
  • 기초적인 동시성과 변경 가능한 상태를 공유할 때의 위험
  • Maven 또는 Gradle
  • IDE와 디버거를 활용해 익숙하지 않은 코드 탐색하기

Java와 Spring Boot 버전은 함께 선택해야 합니다. 현재 Oracle은 JDK 17, 21, 25, 26을 비롯한 여러 Java SE 버전의 문서를 제공합니다.[S1] 조사 시점에 Spring Boot 4.1.1은 Java 17 이상을 요구하고 Java 26까지 지원했으며, 공식 문서에는 여러 개의 안정화된 Boot 브랜치도 안내되어 있었습니다.[S2]

그렇다고 특정 Java 버전 하나가 보편적으로 ‘최선’이라는 뜻은 아닙니다. 유지보수 중인 Java 계열 하나와 호환되는 안정적인 Spring Boot 브랜치 하나를 선택하고, 해당 세대에 맞춰 작성된 학습 자료를 사용해야 한다는 의미입니다. 오래된 Boot 2 튜토리얼과 최신 Boot 의존성, 서로 다른 세대의 보안 설정을 섞으면 세대별 기준 환경과 API가 달라 혼란이 생길 수 있습니다.[S2]

다음 단계로 넘어가기 전에 Spring 없이 작은 Java 프로그램을 만들어 보세요. 실제 업무 규칙을 모델링하고, 구현체를 교체할 필요가 있는 곳에는 인터페이스를 사용하며, 오류를 의도적으로 처리하고 자동화된 테스트도 포함해야 합니다.

3. 2단계: Spring의 동작 원리 이해하기

모든 애너테이션의 기능을 외우는 것부터 시작하지 마세요. 먼저 애플리케이션 객체를 발견하고 생성하며 설정하고 서로 연결하는 컨테이너를 이해해야 합니다.

Spring 핵심 컨테이너 문서에서는 Inversion of Control, bean, 의존성, scope, component scanning, 애너테이션 기반 설정, Java 설정, application context, environment abstraction을 다룹니다.[S3]

다음 질문에 집중하세요.

  • bean이란 무엇인가?
  • 누가 bean을 생성하는가?
  • bean에 필요한 의존성은 어떻게 전달되는가?
  • 어떤 설정 때문에 해당 bean이 생성되는가?
  • 동일한 의존성을 충족하는 bean이 두 개라면 어떻게 되는가?
  • 환경에 따라 설정은 어떻게 달라지는가?
  • bean은 얼마나 오래 유지되는가?

일관된 실습을 위해 이 로드맵에서는 constructor injection을 사용합니다. 다만 이것이 다른 방식보다 우수하다는 사실이 근거로 입증되었다는 의미는 아닙니다. 다음과 같은 작은 실험도 해보세요.

  • 하나의 의존성 구현체를 다른 구현체로 교체한다.
  • component scanning으로 생성하던 bean을 명시적 설정으로 생성하도록 바꾼다.
  • 의도적으로 missing-bean 오류를 만들고 원인을 설명한다.
  • 모호한 의존성을 만든 다음 의도적으로 해결한다.
  • 애플리케이션 시작 실패 메시지를 관련 cause chain의 아래쪽부터 읽는다.

목표는 단순히 오류를 고치는 것이 아닙니다. 컨테이너가 왜 그렇게 동작했는지 미리 예측할 수 있어야 합니다.

4. 3단계: 작은 REST API를 처음부터 끝까지 만들기

독서 목록, 할 일 관리, 간단한 예약 API처럼 의도적으로 범위를 좁힌 서비스를 만들어 보세요.

Spring 공식 REST 가이드에서는 Spring Initializr로 프로젝트를 생성하고, @RestController에서 요청을 처리하며, GET 요청을 매핑하고, 파라미터를 바인딩하고, 객체를 JSON으로 직렬화하는 방법을 보여줍니다. 또한 @SpringBootApplication을 사용하고 실행 가능한 JAR로 패키징하는 방법도 설명합니다.[S4]

이 요소들을 활용해 다음 기능을 갖춘 인메모리 API를 구현하세요.

  • 여러 개의 HTTP endpoint
  • JSON 요청과 응답
  • 명시적인 업무 규칙
  • dependency injection
  • 입력값 검증 실습
  • 예측 가능한 오류 응답
  • 반복해서 사용할 수 있는 빌드 및 실행 명령

문서에 설명된 요청 처리 순서를 이해해야 합니다. Spring은 요청을 controller method에 매핑하고 request parameter를 바인딩한 뒤 객체를 반환하며, 그 객체를 JSON으로 직렬화합니다.[S4] 애플리케이션 시작, 서비스 실행, 응답 구성, 하위 수준의 HTTP 출력은 이 가이드에서 입증된 동작으로 단정하지 말고 별도의 조사 주제로 다루세요.

책임을 분리했을 때 동작이 더 명확해진다면 controller, application, domain의 책임을 나누세요. 단지 다이어그램을 흉내 내기 위해 불필요한 layer를 만들 필요는 없습니다.

REST 서비스를 입문 프로젝트의 중심으로 삼는 것은 편집상의 권장 사항이지, 과학적으로 효과가 입증된 교육 방식은 아닙니다. 다만 작은 애플리케이션 하나에서 여러 Spring 개념이 연결되어 작동하는 과정을 직접 확인할 수 있다는 실용적인 장점이 있습니다.[S3][S4]

5. 4단계: SQL, 관계형 데이터베이스, JPA 추가하기

repository interface가 데이터베이스 지식을 대신한다고 생각해서는 안 됩니다. 객체 중심의 persistence layer를 공부하면서 관계형 모델도 함께 익혀야 합니다.

다음 내용을 공부하세요.

  • 테이블, primary key, foreign key
  • uniqueness를 비롯한 각종 constraint
  • join
  • 기본적인 normalization
  • schema migration
  • 대표적인 SELECT, INSERT, UPDATE, DELETE 문
  • entity mapping과 relationship
  • repository query
  • transaction boundary

ORM 추상화가 모든 작업을 감추도록 두기 전에 주요 사용 사례의 SQL을 직접 작성해 보세요. 관계를 매핑했다면 그에 대응하는 테이블과 key 구조도 그릴 수 있어야 합니다.

Spring Data JPA는 paging, slicing, sorting, limiting, offset scrolling, keyset scrolling을 지원합니다. Page에는 전체 개수 정보가 포함됩니다. Slice나 scrolling 같은 대안은 관련 작업의 일부를 피할 수 있으며, keyset scrolling은 index를 이용해 offset 방식 조회의 단점을 보완하기 위한 방식입니다.[S5] 어느 한 접근법이 항상 최적인 것은 아니므로 실제 접근 패턴과 데이터베이스를 기준으로 평가해야 합니다.[S5]

다음으로 transaction을 어디에 둘지 결정하세요. Spring Data JPA 문서에서는 repository의 transaction 설정을 설명하며, 여러 repository 작업을 포괄하는 외부 service 또는 facade transaction으로 경계를 정의하는 예제를 보여줍니다. 또한 직접 선언한 query method에는 transaction 설정이 자동으로 적용되지 않는다고 설명합니다.[S6]

이 단계에서는 인메모리 저장소를 관계형 데이터베이스로 교체하고 다음 기능을 추가해야 합니다.

  • schema constraint
  • repository query
  • sorting
  • pagination 또는 다른 형태의 windowed result
  • 여러 데이터베이스 작업이 포함된 업무 기능 최소 하나

6. 5단계: 정상 동작만 하는 CRUD에서 벗어나기

CRUD는 데이터가 시스템을 통과할 수 있다는 사실만 보여줍니다. 다음으로 실패, 부하, 작업 간 경쟁 상황을 추가하여 중급 수준의 문제 해결 능력을 연습해 보세요.

다음과 같은 상황을 추가합니다.

  • 중복 요청
  • uniqueness 충돌
  • 잘못된 입력값
  • domain rule 위반
  • 동시 update
  • 대규모 결과 집합
  • 여러 단계로 구성된 작업 도중의 부분 실패
  • 느린 query

두 번의 write를 수행하는 작업을 만든 다음 두 번째 write를 강제로 실패시키고, 두 변경 사항이 모두 rollback되는지 확인하세요. service 또는 facade transaction을 사용하면 여러 repository 작업을 하나의 경계로 묶을 수 있습니다.[S6] 복잡한 사례를 다루려면 데이터베이스 isolation, locking, rollback rule, Spring의 proxy 동작을 추가로 공부해야 합니다. 기본 transaction 문서만으로 모든 상황을 판단할 수는 없습니다.[S6]

Page와 더 가벼운 result-windowing 방식을 비교하고 실제 실행되는 SQL을 관찰하세요.[S5] 습관적으로 pagination 유형을 선택하지 말고 client에 실제로 필요한 정보가 무엇인지 먼저 확인해야 합니다.

마지막으로 느린 query 하나를 재현하고 해당 SQL, 입력값, 실행 시간을 기록하세요. PostgreSQL query plan과 EXPLAIN ANALYZE를 활용한 자세한 조사는 8단계에서 종합적으로 다룹니다.

7. 6단계: 계층적인 테스트 전략 세우기

질문에 따라 서로 다른 범위의 테스트를 사용하세요.

Spring Boot는 핵심 테스트 지원, test auto-configuration, 특정 영역에 집중한 testing module, 널리 사용되는 spring-boot-starter-test를 제공합니다. MVC, JPA, security, REST client처럼 특정 영역에 집중하는 테스트와 전체 애플리케이션 테스트도 지원합니다.[S7]

실용적인 전략은 다음과 같습니다.

  • Spring이 필요 없다면 domain과 application logic을 단위 테스트한다.
  • controller, repository, security rule, external-client 동작에는 범위를 좁힌 테스트를 사용한다.
  • 전체 애플리케이션 테스트는 중요한 통합 흐름에만 사용한다.
  • 성공뿐 아니라 실패도 의도적으로 테스트한다.

테스트 모음에는 최소한 다음 항목이 포함되어야 합니다.

  • 업무 규칙 테스트 하나
  • controller 흐름 하나
  • persistence 동작 하나
  • rollback 상황 하나
  • 보호된 resource 접근 상황 하나
  • 중요한 end-to-end 애플리케이션 흐름 하나

unit, focused, integration, end-to-end 테스트 사이에 근거로 입증된 보편적인 비율은 없습니다. 확인하려는 질문에 안정적으로 답할 수 있는 가장 작은 범위를 선택하세요. Boot 세대에 따라 testing annotation과 module 구성이 달라질 수 있으므로 선택한 Boot 브랜치의 문서도 확인해야 합니다.[S7]

8. 7단계: 보안을 애플리케이션 동작으로 이해하기

보안은 token filter나 로그인 설정을 복사하는 작업에 그치지 않습니다. identity와 authority가 애플리케이션을 통해 어떻게 전달되는지 이해해야 합니다.

Spring Security의 servlet authentication architecture는 SecurityContextHolder, SecurityContext, Authentication, granted authority, AuthenticationManager, ProviderManager, authentication provider를 중심으로 구성됩니다.[S8]

다음 내용을 설명할 수 있어야 합니다.

  • authentication과 authorization의 차이
  • 현재 authentication 정보가 어디에 표현되는지
  • authority가 접근 결정에 어떻게 사용되는지
  • 어떤 component가 authentication 요청을 처리하는지
  • authentication 실패와 authorization 거부가 어떻게 다른지

이후 눈에 보이는 동작을 테스트하세요.

  • 인증되지 않은 요청은 보호된 resource에 도달할 수 없다.
  • 인증되었지만 필요한 authority가 없는 사용자는 접근을 거부당한다.
  • 권한을 부여받은 사용자는 요청에 성공한다.
  • 실패 응답에 불필요한 내부 정보가 노출되지 않는다.

framework 설정은 보안의 일부에 불과합니다. OWASP Top Ten 2025에서는 broken access control, security misconfiguration, software supply-chain failure, cryptographic failure, injection, authentication failure, security logging and alerting failure 등의 범주를 주요 위험으로 제시합니다.[S9] 이는 보안 인식과 우선순위 설정을 위한 자료이지 애플리케이션이 안전하다는 것을 입증하는 수단은 아닙니다.[S9]

Threat modeling, secret 관리, transport security, dependency 유지보수, security testing, incident response는 [S8]과 [S9]에서 구체적으로 다룬 근거 범위를 벗어나지만 이후에 공부할 수 있는 주제입니다. 이 목록은 완전한 목록도 아니며, 여기에서 별도의 보안 표준으로 검증한 것도 아닙니다.

9. 8단계: 근거를 바탕으로 성능 문제 진단하기

endpoint가 느릴 때 곧바로 caching이나 infrastructure부터 추가하지 마세요.

추적 가능한 조사 과정부터 시작합니다.

  1. 느린 endpoint를 찾아 문제를 재현한다.
  2. 어떤 애플리케이션 작업에서 시간이 소요되는지 확인한다.
  3. 생성된 SQL과 query 실행 횟수를 조사한다.
  4. 중요한 query의 execution plan을 확인한다.
  5. 관련 요인을 하나만 변경한다.
  6. 다시 측정한다.

PostgreSQL은 각 query의 plan을 생성하며 EXPLAIN을 사용하면 해당 plan을 확인할 수 있습니다.[S10] sequential scan, index scan, join, sorting 등의 plan node와 row estimate, loop, buffer 활동을 살펴보세요.[S10]

실제 실행 데이터가 필요하고 statement를 실행해도 안전할 때 EXPLAIN ANALYZE를 사용하세요. 이 명령은 statement를 실제로 실행하므로 데이터를 변경하는 작업에는 각별히 주의해야 합니다.[S10] plan과 실행 시간은 데이터 분포, 통계, 설정, hardware 등의 요인에 따라 달라집니다.[S10]

index scan이 언제나 sequential scan보다 우수한 것은 아닙니다. 실제 dataset, 반환되는 row 수, 통계, workload를 함께 고려해 해석해야 합니다.[S10] 관련 요인을 한 번에 하나씩 바꾸고 다시 측정한 뒤 실제 동작이 개선되었는지 기록하세요.

ORM fetch plan, N+1 query, batching, connection-pool tuning을 자세히 다루려면 이 로드맵보다 범위가 좁고 구체적인 근거가 필요합니다. SQL을 관찰하고 데이터베이스 plan을 해석할 수 있게 된 다음 별도로 공부하세요.

10. 9단계: 운영할 수 있는 서비스 만들기

로컬에서 실행된다고 해서 관리하기 쉬운 서비스가 되는 것은 아닙니다. 서비스가 정상인지, 어떻게 동작하는지를 보여주는 신호도 필요합니다.

Spring Boot Actuator는 health, metrics, auditing을 비롯한 운영 환경용 관리·모니터링 기능을 제공합니다. endpoint는 HTTP 또는 JMX를 통해 노출할 수 있으며, Actuator starter를 사용하는 것이 권장되는 활성화 방법입니다.[S11]

다음 항목을 추가하세요.

  • 접근이 보호된 health endpoint
  • 유용한 애플리케이션 및 runtime metrics
  • structured log
  • externalized configuration
  • 문서화된 시작 절차
  • 재현 가능한 실행 파일 build
  • 반복 가능한 deployment process

환경에 필요한 management endpoint만 노출하고 적절한 access control을 적용하세요. Actuator를 추가하는 것만으로 효과적인 observability가 완성되지는 않습니다. endpoint 보호, 보관 정책, dashboard, alert, incident procedure도 의도적으로 설계해야 합니다.[S11]

이 단계의 결과물은 실제로 배포한 서비스일 수도 있고, 로컬에서 운영 환경에 가깝게 설정한 서비스일 수도 있습니다. 중요한 것은 다음 질문에 답할 수 있는 역량입니다.

  • 서비스가 실행 중인가?
  • traffic을 받을 준비가 되었는가?
  • 무엇이 실패하고 있는가?
  • 어떤 작업이 느린가?
  • 환경 사이에서 무엇이 달라졌는가?
  • 다른 개발자가 어떻게 안정적으로 build하고 실행할 수 있는가?

11. 하나의 최종 프로젝트에 모든 내용 통합하기

재고, 예약, 주문, 작업 조율 시스템처럼 데이터베이스를 사용하는 REST 서비스 하나를 평가용 프로젝트로 활용하세요.

다음 기능을 구현합니다.

  • HTTP endpoint와 JSON response
  • 명시적인 업무 규칙
  • constraint가 적용된 관계형 schema
  • 여러 단계로 구성된 transactional operation
  • sorting과 pagination
  • authentication과 authorization
  • unit test, focused test, 선별한 full-application test
  • 중요 query의 query plan 분석
  • health와 metrics endpoint
  • externalized configuration
  • 반복해서 실행할 수 있는 executable build

이 최종 프로젝트의 구성은 관련 기술이 서로 맞물려 동작하는 방식을 바탕으로 설계한 합리적인 교육과정 제안입니다.[S3][S4][S5][S6][S7][S8][S10][S11] 비교 교육 연구로 뒷받침된 방식은 아니며 모든 학습자에게 똑같이 적합하다고 보장할 수 없습니다.

개인 실습을 위해 엔지니어링 노트를 작성하는 것도 고려해 보세요. 의미 있는 문제가 생길 때마다 증상, 최초 가설, 수집한 근거, 원인, 변경 사항, 결과를 기록합니다. 이 로드맵에서는 자신의 추론 과정을 검토할 수 있게 만드는 방법으로 서면 진단을 중요하게 여기지만, 문제를 해결하는 것만큼 이 습관이 가치 있다는 사실이 검토한 근거로 입증된 것은 아닙니다.

12. 중급 수준 준비도 체크리스트

복사한 설정에 의존하지 않고 다음 항목 대부분을 직접 보여줄 수 있다면 이 로드맵을 넘어 다음 단계로 나아갈 준비가 된 것입니다.

  • Spring이 애플리케이션의 의존성을 어떻게 생성하고 연결하는지 설명할 수 있다.[S3]
  • 누락되거나 모호한 bean 설정을 진단할 수 있다.[S3]
  • controller mapping과 parameter binding을 거쳐 객체 응답이 JSON으로 직렬화되는 요청 흐름을 추적할 수 있다.[S4]
  • 서로 호환되는 Java와 Spring Boot 버전으로 애플리케이션을 재현 가능하게 build하고 실행할 수 있다.[S1][S2]
  • 중요한 repository 작업의 기반이 되는 schema와 SQL을 설명할 수 있다.
  • 사용 사례와 실제로 관찰한 데이터베이스 동작을 바탕으로 paging, slicing, scrolling 중 적절한 방식을 선택할 수 있다.[S5]
  • 여러 repository 작업에 걸쳐 transaction boundary를 설정하고 설명할 수 있다.[S6]
  • 작업 실패 시 rollback 동작을 검증할 수 있다.[S6][S7]
  • 위험에 따라 적절한 test scope를 선택할 수 있다.[S7]
  • Spring Security가 authentication과 authority를 어떻게 표현하는지 설명할 수 있다.[S8]
  • authenticated, unauthenticated, authorized, denied 동작을 테스트할 수 있다.[S7][S8]
  • 체크리스트를 보안의 증거로 오해하지 않으면서 주요 웹 위험 범주를 파악할 수 있다.[S9]
  • query plan을 분석하고 그 근거를 다음 조사 방향을 정하는 데 활용할 수 있다.[S10]
  • 유용한 health와 metric 신호를 노출하고 보호할 수 있다.[S11]
  • 서비스를 어떻게 설정하고 build하고 시작하며 모니터링하는지 설명할 수 있다.

초급에서 중급으로 가는 과정은 애너테이션을 빠르게 훑는 경주가 아닙니다. Java 기초에서 framework 이해로 나아가고, 단순한 기능 개발에서 테스트·보안·진단·운영으로 역량을 확장하는 과정입니다.

모든 단계에서 하나의 애플리케이션을 계속 발전시키세요. 다음에 무엇을 공부할지 고민된다면 체크리스트에서 아직 직접 증명할 수 없는 첫 번째 항목을 선택하면 됩니다.

Sources

오류 제보·의견 보내기

글 제목과 주소가 포함된 메일 초안을 엽니다. 내용과 받는 사람을 확인한 뒤 보내주세요.

받는 사람: [email protected]

메일 앱에서 작성

메일 앱이 열리지 않으면 아래 내용을 복사해 평소 쓰는 이메일에 붙여 넣으세요.

문의 안내

관련 글