자바 백엔드 입문 11편 — Spring Framework란

이 글은 자바 백엔드 입문 시리즈 59편 중 11편이에요. Phase 0 자바 기초 5편이 끝났고, 이번 11편부터 Phase 1 Spring 시작 으로 들어갑니다. 자바 백엔드의 절대 표준 Spring Framework를 처음 마주하는 글이고, 끝까지 따라오시면 "Spring이 도대체 뭘 해주는 도구인지" 가 한 줄로 정리돼요.

Spring이 어렵게 들리는 이유

처음 Spring을 검색하면 두 가지가 한꺼번에 헷갈립니다.

첫째, "Spring" 이라는 이름 자체가 여러 개거든요. Spring Framework, Spring Boot, Spring Cloud, Spring Data, Spring Security, Spring Batch... "이게 다 같은 건가 다른 건가" 가 안 잡혀요.

둘째, "왜 굳이 Spring을?" 이 안 보입니다. 그냥 자바 객체로 백엔드 짜면 안 되나? Spring이 도대체 뭘 해줘서 한국 회사가 다 이걸 쓰나? 이 질문이 풀려야 Spring 공부에 동기가 생겨요.

이 글에서는 Spring Framework를 "자바 백엔드의 운영체제" 비유로 풀어 갑니다. 끝까지 따라오시면 EJB·POJO 같은 단어가 갑자기 친근해져요.

Spring Framework란 무엇인가 — 한 줄 정의

Spring Framework는 "자바 백엔드 애플리케이션을 만드는 일이 너무 무거워서, 그걸 가볍게 만들어 주는 도구 모음" 이에요. 2003년 Rod Johnson이라는 영국 컨설턴트가 발표한 책 "Expert One-on-One J2EE Design and Development" 에서 처음 등장했고, 2004년 1.0 버전이 정식 출시됐어요.

회사 비유로 풀어볼게요. Spring Framework는 "회사 사옥의 운영팀" 같은 존재예요. 직원(자바 객체)이 일을 하려면 — 출입증·전원 콘센트·인터넷·복사기·회의실·인사 관리·근태·결제 시스템·청소 — 이 모든 인프라가 사옥 어딘가에서 돌고 있어야 해요. 운영팀이 알아서 이 모든 걸 관리하면, 직원은 그저 자기 일에 집중하면 됩니다.

Spring Framework가 자바 백엔드에서 하는 일이 똑같아요. 우리는 비즈니스 로직(직원의 일)만 짜고, "객체를 누가 만들고, 어떻게 끼워 넣고, DB 트랜잭션은 누가 열고 닫고, 웹 요청은 어떻게 받고, 보안은 어떻게 처리하는지" 는 Spring에 맡기는 거예요. 이게 Spring을 "백엔드 운영체제" 라고 부르는 이유입니다.

왜 Spring이 등장했나 — EJB의 비극과 POJO 혁명

Spring 등장 직전 2000년대 초 자바 백엔드는 EJB(Enterprise JavaBeans) 라는 표준을 썼어요. EJB는 "엔터프라이즈급 자바 애플리케이션을 만드는 표준 명세" 인데, 실전에서는 악명 높을 정도로 무거웠어요. 한 비즈니스 로직 클래스 하나를 만들려면:

• EJB 인터페이스 3개 구현 의무 (Home·Remote·Bean)
• XML 설정 파일 수십 줄
• 컴파일 후 별도 EJB 컨테이너에 배포
• 단위 테스트 거의 불가능 — EJB 컨테이너가 떠 있어야 동작

"단순한 회원 가입 로직 한 줄" 짜는 데 EJB 코드 200줄 + XML 100줄이 들어가는 게 일상이었어요.

여기에 반기를 든 사람이 Rod Johnson이에요. 그가 던진 핵심 메시지가 "POJO(Plain Old Java Object) 혁명" — "왜 평범한 자바 객체로 못 짜냐, 인터페이스 강제 상속이 왜 필요하냐" 였어요.

Spring Framework는 그 답이었어요. 평범한 자바 클래스를 그대로 쓰고, 설정·트랜잭션·DB·웹 같은 무거운 부분만 Spring이 알아서 끼워 주는 구조. EJB가 강제했던 인터페이스 상속·복잡한 XML·전용 컨테이너가 다 사라지고, 자바 백엔드의 코드 양이 절반 이하로 줄어든 혁명이었습니다.

Spring Framework의 7대 핵심 모듈

Spring Framework는 한 덩어리가 아니라 여러 모듈이 합쳐진 도구 모음이에요. 가장 자주 만나는 7대 모듈은 다음과 같아요.

모듈	역할 한 줄	이 시리즈 다루는 편
Core (IoC Container)	객체 생성·관리·주입 — Spring의 심장	9~15편 (Phase 2)
SpEL	Spring 안의 작은 표현식 언어	16편
AOP	횡단 관심사(로깅·트랜잭션) 자동 처리	17·18편 (Phase 3)
Web MVC	HTTP 요청·응답 처리 — REST API의 핵심	19~23편 (Phase 4)
Data Access	DB 연결·JdbcTemplate·@Transactional	26~28편 (Phase 6)
Testing	@SpringBootTest·MockMvc 같은 테스트 도구	33·34편 (Phase 7)
Integration	스케줄링·캐싱·메시징·REST 클라이언트	35·36편 (Phase 8)

이 7개를 한 번에 다 외우려 하지 마세요. Core (IoC Container) 한 모듈만 단단히 잡으면 나머지 6개는 같은 패턴의 연장이에요. 그래서 시리즈에서도 IoC에 7편을 통째로 썼어요.

Spring Framework vs Spring Boot — 헷갈리는 둘

여기서 입문자가 가장 자주 헷갈리는 부분 — Spring Framework와 Spring Boot가 어떻게 다른가.

• Spring Framework (2004) = 자바 백엔드를 만드는 도구 모음. 직접 쓰려면 설정이 여전히 많음.
• Spring Boot (2014) = Spring Framework + "좋은 기본 설정" 을 미리 박아둔 편의 패키지. "Convention over Configuration" 철학.

비유로 풀면 — Spring Framework는 "가구 부품과 매뉴얼", Spring Boot는 "이미 조립된 가구 한 세트" 예요. Spring Boot를 쓰면 "내장 Tomcat 서버·기본 로깅·자동 설정" 같은 게 미리 박혀 있어 단 한 줄의 설정 없이 백엔드를 띄울 수 있어요.

여기서 시험 함정이 하나 있어요. "Spring Boot는 Spring Framework를 대체한다" 가 보기로 나오면 X. Spring Boot는 Spring Framework의 "편의 래퍼" 일 뿐, 안에서 도는 건 Spring Framework 그대로예요. Spring Boot 코드의 90%는 사실 Spring Framework 코드입니다.

// 이게 Spring Boot 메인 클래스 — 단 4줄로 백엔드가 뜸
@SpringBootApplication
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}

Spring Framework만 썼다면 위 코드만으로는 절대 안 뜨고, web.xml·DispatcherServlet 설정 등 수십 줄이 더 필요했어요. Spring Boot가 그걸 다 미리 박아둔 거예요.

왜 한국 회사가 압도적으로 Spring을 쓰나

1편에서 "한국 회사 백엔드 70~80%가 자바 기반" 이라고 했는데, 그 자바 백엔드의 거의 전부가 Spring 또는 Spring Boot 기반이에요. 이유 다섯 가지:

1. 카카오·네이버·쿠팡·삼성SDS·LG CNS — 한국 대기업 IT가 거의 다 Spring 표준. 신입 채용 공고가 "Java + Spring Boot 필수" 로 박혀 있음
2. 인력 풀이 압도적 — 한국 대학·학원·인강이 다 Spring 중심으로 커리큘럼 짜여 있어요
3. 레퍼런스 풍부 — 어떤 문제든 "Spring + ○○○" 검색하면 한국어 자료가 산처럼 있음
4. 금융·통신·공공기관 표준 — 은행·통신사·정부 기관은 거의 100% Spring + Oracle DB
5. Spring Cloud로 MSA 확장 자연스러움 — 마이크로서비스 시대에도 그대로 활용 가능

스타트업 신규 프로젝트도 Go·Node.js를 쓰는 곳이 늘긴 했지만, 한국 자바 백엔드 일자리의 사실상 모든 자리가 Spring을 요구해요. 자바 백엔드를 한다 = Spring을 한다, 라는 등식이 거의 완벽하게 성립합니다.

한 줄 정리 — Spring Framework는 "자바 백엔드의 운영체제". 무거운 EJB를 끝낸 POJO 혁명에서 시작해 한국 자바 백엔드의 사실상 모든 일자리가 요구하는 표준이 됐음.

시험 직전 한 번 더 — Spring 입문자가 매번 헷갈리는 것

• Spring Framework = 자바 백엔드를 가볍게 만드는 도구 모음
• 2003년 Rod Johnson의 "Expert One-on-One J2EE..." 책에서 시작 → 2004년 1.0 정식 출시
• 등장 배경 = EJB의 무거움에 대한 반발
• 핵심 철학 = POJO(Plain Old Java Object) — 평범한 자바 객체로 백엔드 짜자
• Spring Framework 7대 모듈 — Core·SpEL·AOP·Web MVC·Data Access·Testing·Integration
• Core(IoC Container) 가 Spring의 심장 — 나머지 6개는 같은 패턴의 연장
• Spring Framework ≠ Spring Boot — Spring Boot는 Spring Framework의 "편의 래퍼"
• Spring Framework (2004) = 도구 모음, Spring Boot (2014) = 좋은 기본 설정 포함 패키지
• Spring Boot 핵심 철학 = Convention over Configuration
• @SpringBootApplication + SpringApplication.run() 4줄로 백엔드 시동
• 내장 Tomcat 서버 — 별도 WAS 설치 없이 .jar 한 개로 실행
• Spring Boot 코드의 90%는 사실 Spring Framework 코드
• "Spring Boot가 Spring Framework를 대체한다" 는 X — 안에서 도는 건 같음
• Spring Cloud = MSA 전용 추가 모듈 (서비스 디스커버리·API 게이트웨이 등)
• Spring Data = JPA·Redis·MongoDB 같은 데이터 저장소 추상화
• Spring Security = 인증·인가 처리
• Spring Batch = 대용량 배치 작업 처리
• 한국 자바 백엔드 일자리의 사실상 100%가 Spring 요구
• 카카오·네이버·쿠팡·삼성SDS·은행·통신사 — 거의 다 Spring 표준
• Spring Boot 3.x는 Java 17 이상 필수, Spring Boot 2.x는 Java 8/11 호환

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 6편 — 자바 제네릭
• 7편 — 자바 예외 처리
• 8편 — 자바 Optional null 안전
• 9편 — 자바 Stream API 람다
• 10편 — Maven·Gradle 의존성 관리

다음 글:

• 12편 — start.spring.io 첫 프로젝트
• 13편 — application.yml Spring Profiles
• 14편 — 첫 Bean 만들기 Hello Spring
• 15편 — 의존성 주입이 왜 필요한가
• 16편 — Bean이란 일반 객체와의 차이