스프링 소개

웹 브라우저가 보낸 HTTP 요청을 서버에서 어떻게 받아 처리하고 응답하는지, 그리고 그 과정을 스프링이 어떻게 도와주는지 살펴본다. 자바 웹 기술이 서블릿에서 시작해 스프링 부트까지 발전해 온 흐름을 이해하면, 스프링이 "무엇을 대신해 주는 프레임워크인지"가 분명해진다.

#1. 웹 서버와 웹 애플리케이션 서버(WAS)

#웹 서버 (Web Server)

• HTTP 기반으로 동작한다.

• 정적 리소스(HTML, CSS, JS, 이미지, 영상)를 제공한다.

• 예) Nginx, Apache

#웹 애플리케이션 서버 (WAS)

• HTTP 기반으로 동작한다.

• 웹 서버 기능(정적 리소스 제공)을 포함한다.

• 프로그램 코드를 실행해서 애플리케이션 로직을 수행한다.

  • 동적 HTML, HTTP API(JSON)

  • 서블릿, JSP, 스프링 MVC

• 예) Tomcat, Jetty, Undertow

#2. 서블릿(Servlet)

서블릿은 자바로 웹 요청을 처리하는 표준 기술이다. WAS가 요청·응답 객체를 만들어 서블릿을 호출한다.

#HTTP 요청 시 서블릿의 흐름

1. WAS는 Request, Response 객체를 만들어서 서블릿 객체를 호출한다.

2. 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용한다.

3. 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력한다.

4. WAS는 Response 객체에 담긴 내용으로 HTTP 응답 메시지를 생성한다.

#HttpServletRequest — 요청 메시지를 파싱하는 객체

#HttpServletResponse — 응답 메시지를 만드는 객체

• HTTP 응답 코드 지정

• 헤더 생성

• 바디 생성

#3. HTTP 요청/응답 데이터

#HTTP 요청 데이터 3가지

#HTTP 응답 데이터 3가지

• 단순 텍스트

• HTML (정적 리소스 또는 동적 생성)

• API JSON

#4. HTML, HTTP API, SSR, CSR

• 정적 리소스: 고정된 HTML, CSS, JS, 이미지, 영상 등을 그대로 제공한다.

• 동적 페이지: 템플릿 엔진으로 필요한 HTML을 동적으로 생성하여 전달한다.

• HTTP API: HTML이 아니라 주로 데이터(JSON)를 전달한다. 다양한 시스템에서 호출한다.

#SSR vs CSR

#5. 자바 웹 기술의 역사

timeline
    title 자바 웹 기술의 발전
    1997 : 서블릿 (HTML 생성이 어려움)
    1999 : JSP (HTML은 편하지만 비즈니스 로직까지 떠안음)
    2000년대 초 : 서블릿+JSP MVC 패턴
                : MVC 프레임워크 춘추전국 (스트럿츠, 웹워크, 과거 스프링 MVC)
    2010년대 : 어노테이션 기반 스프링 MVC (@Controller)
    현재 : 스프링 부트 (서버 내장, 빌드·배포 단순화)

1. 서블릿(1997): HTML 생성이 어렵다.

2. JSP(1999): HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할을 담당한다.

3. 서블릿 + JSP 조합 MVC 패턴: 모델·뷰·컨트롤러로 역할을 나누어 개발한다.

4. MVC 프레임워크 춘추전국 시대(2000년대 초~2010년대 초): 스트럿츠, 웹워크, 과거 스프링 MVC 등.

5. 어노테이션 기반 스프링 MVC 등장: @Controller로 춘추전국 시대를 마무리한다.

6. 스프링 부트의 등장: WAS를 내장해 빌드 결과(jar)에 서버를 포함 → 빌드·배포가 단순해진다.

#6. 스프링의 탄생과 핵심 원리 — IoC / DI / AOP { #6-ioc-di-aop }

스프링을 "왜 쓰는가"는 결국 IoC·DI·AOP 세 가지로 설명된다. 그런데 이 원리들은 어느 날 갑자기 나온 게 아니라, 그 전 시대의 무겁고 복잡한 기술에 대한 반작용으로 태어났다. 그 배경을 먼저 보면 세 원리가 왜 그런 모습인지 자연스럽게 이해된다.

#스프링은 왜 태어났나 — EJB와 로드 존슨

스프링이 등장하기 전, 자바 엔터프라이즈 애플리케이션의 표준은 EJB(Enterprise JavaBeans) 였다. EJB는 트랜잭션·보안·분산 처리처럼 어려운 일을 컨테이너가 대신 처리해 준다는 강력한 약속을 내걸었다.

문제는 그 대가가 너무 컸다는 점이다.

• 내 비즈니스 객체가 EJB가 정한 특정 인터페이스를 구현하고 컨테이너 클래스를 상속해야 했다 → 코드가 EJB 프레임워크에 강하게 종속된다.

• 설정용 XML 서술자가 방대했고, 작성할 코드가 많아 개발이 번거롭고 느렸다.

• 객체를 EJB 컨테이너 밖에서는 실행·테스트할 수 없었다 → 가벼운 단위 테스트가 사실상 불가능했다.

2002년, 로드 존슨(Rod Johnson) 은 저서 《Expert One-on-One J2EE Design and Development》에서 "이 모든 걸 EJB 없이, 평범한 자바 객체(POJO) 와 가벼운 컨테이너만으로 더 단순하게 할 수 있다"고 주장하며 직접 만든 프레임워크 코드를 함께 실었다. 이 코드가 곧 스프링 프레임워크의 씨앗이 되어 2004년 정식 출시(1.0)되었다. (이듬해 그의 다음 책 제목은 아예 《… without EJB》였다.)

// POJO — 아무 기술에도 묶이지 않은 평범한 객체
public class Member {
    private String name;
    public String getName() { return name; }
}

// POJO가 아님 — EJB 프레임워크 클래스를 상속/구현해야만 동작
public class MemberBean extends SessionBean implements EntityBean {
    // 프레임워크가 요구하는 메서드들을 억지로 구현 ...
}

스프링이 내놓은 해법은 이렇게 요약된다.

즉 EJB가 주던 이점(트랜잭션 등)은 그대로 누리되, 내 코드가 무거운 컨테이너에 묶이지 않도록 뒤집은 것이 스프링이다. 이어서 볼 IoC·DI·AOP가 바로 그 해법을 떠받치는 세 기둥이다.

스프링의 한마디 — POJO로 돌아가자

스프링의 철학은 "엔터프라이즈 기능을 쓰자고 내 코드를 프레임워크에 종속시키지 말고, 순수한 자바 객체를 그대로 두라"는 것이다. 그래서 우리가 만드는 서비스·리포지토리가 특별한 상속·구현 없이도 빈으로 동작한다.

#IoC (Inversion of Control) — 제어의 역전

전통적인 자바 코드에서는 객체가 필요한 다른 객체를 직접 생성한다. 즉, 제어의 흐름을 내 코드가 쥐고 있다.

// 전통적 방식: 컨트롤러가 의존 객체를 직접 생성한다
public class OrderController {
    // 구현체를 직접 new → OrderController가 OrderServiceImpl에 강하게 묶인다
    private OrderService orderService = new OrderServiceImpl();
}

이 방식의 문제는 강한 결합(tight coupling) 이다.

• 구현체를 OrderServiceImpl → OrderServiceImplV2로 바꾸려면 컨트롤러 코드를 고쳐야 한다.

• 테스트할 때 가짜(mock) 객체를 끼워 넣기 어렵다.

• 객체를 누가 언제 만들고 없앨지를 일일이 코드로 관리해야 한다.

IoC는 이 제어권을 스프링 컨테이너(IoC 컨테이너) 에게 넘기는 것이다. 객체의 생성·연결·생명주기를 컨테이너가 대신 관리한다. 컨테이너가 관리하는 객체를 빈(Bean) 이라고 한다.

graph LR
    A["내 코드<br/>(필요하다고 요청만)"] -->|객체 요청| B[스프링 IoC 컨테이너]
    B -->|생성·관리| C["빈(Bean)들<br/>OrderService, Repository ..."]
    B -->|주입| A

#싱글톤 — 컨테이너는 빈을 하나만 만들어 공유한다

그렇다면 컨테이너는 빈을 몇 개 만들까? 웹 애플리케이션은 보통 같은 기능을 수많은 사용자가 동시에 요청한다. 요청이 올 때마다 OrderService·Repository를 new로 새로 만들면, 초당 수백·수천 개의 객체가 생성·폐기되어 메모리와 CPU가 낭비된다.

그래서 스프링 컨테이너는 빈을 기본적으로 싱글톤(singleton) 으로 관리한다. 컨테이너당 빈을 딱 하나만 만들어 두고, 그 하나를 필요한 모든 곳에 공유해서 주입한다.

graph LR
    R1[요청 A] --> S
    R2[요청 B] --> S
    R3[요청 C] --> S
    S["MemberService<br/>(인스턴스 단 하나)"] --> R["MemberRepository<br/>(인스턴스 단 하나)"]

@Service
public class MemberService { ... }   // 평범한 클래스 — 싱글톤 코드는 한 줄도 없다

// 컨테이너는 MemberService 빈을 하나만 만든다 → 어디서 주입받아도 같은 객체
@Autowired MemberService a;
@Autowired MemberService b;
// a == b  →  true (동일한 인스턴스)

#직접 만드는 싱글톤 패턴 vs 스프링

전통적인 싱글톤 패턴은 클래스가 스스로 인스턴스를 하나로 강제한다.

public class SettingsManager {
    private static final SettingsManager INSTANCE = new SettingsManager();
    private SettingsManager() {}                          // 외부에서 new 차단
    public static SettingsManager getInstance() { return INSTANCE; }
}

하지만 이 방식은 문제가 많다.

• 싱글톤 유지용 코드(private 생성자, getInstance)가 클래스마다 반복된다.

• getInstance()로 구체 클래스에 직접 의존하게 되어, 인터페이스 기반 DI·구현체 교체·테스트가 어렵다.

• 테스트에서 가짜(mock) 객체로 바꿔 끼우기 까다롭다.

스프링은 평범한 클래스를 그대로 두고 컨테이너가 싱글톤을 보장하므로 이 단점이 모두 사라진다. 그래서 스프링 컨테이너를 싱글톤 컨테이너라고도 부른다.

#DI (Dependency Injection) — 의존성 주입

IoC를 실제로 구현하는 방법이 DI다. 객체가 필요로 하는 의존 객체를 직접 만들지 않고, 외부(컨테이너)에서 넣어 준다.

@Controller
public class OrderController {

    private final OrderService orderService;   // 인터페이스에 의존

    // 생성자 주입: 스프링이 OrderService 타입의 빈을 찾아 넣어 준다
    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }
}

@Service                                       // 이 구현체를 빈으로 등록
public class OrderServiceImpl implements OrderService {
    // ...
}

이렇게 하면 OrderController는 인터페이스(OrderService)에만 의존하고, 어떤 구현체가 들어올지는 컨테이너가 결정한다.

• 구현체를 바꿔도 컨트롤러 코드는 그대로다. (낮은 결합도)

• 테스트에서는 가짜 구현(mock)을 생성자로 넣어 주면 된다.

// 테스트: 진짜 서비스 대신 가짜 객체를 주입할 수 있다
OrderService fake = new FakeOrderService();
OrderController controller = new OrderController(fake);

#AOP (Aspect Oriented Programming) — 관점 지향 프로그래밍

로깅, 실행 시간 측정, 트랜잭션, 보안 같은 기능은 여러 메소드에 공통으로 흩어져 나타난다. 이런 공통 관심사(cross-cutting concern) 를 핵심 비즈니스 로직과 분리하는 것이 AOP다.

// AOP 없이: 모든 메소드에 시간 측정 코드가 반복된다
public void order() {
    long start = System.currentTimeMillis();   // (공통) 측정 시작
    try {
        // ===== 핵심 로직 =====
        // ...
    } finally {
        long end = System.currentTimeMillis();  // (공통) 측정 종료
        log.info("order() 실행 시간: {}ms", end - start);
    }
}

핵심 로직보다 공통 코드가 더 눈에 띄고, 메소드마다 복붙해야 한다. AOP를 쓰면 이 공통 코드를 한 곳(Aspect)에 모으고, 핵심 메소드는 순수하게 비즈니스 로직만 남긴다.

@Slf4j
@Aspect
@Component
public class TimeTraceAop {

    // 어디에 적용할지(Pointcut): com.example 패키지 하위 모든 메소드
    @Around("execution(* com.example..*(..))")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        try {
            return joinPoint.proceed();          // 실제 대상 메소드 실행
        } finally {
            long end = System.currentTimeMillis();
            log.info("{} 실행 시간: {}ms", joinPoint.getSignature(), end - start);
        }
    }
}

이제 핵심 메소드는 공통 코드 없이 깔끔해진다.

public void order() {
    // ===== 핵심 로직만 남는다 =====
}

#7. MVC 패턴

요청 처리를 역할에 따라 셋으로 나누는 패턴이다.

#FrontController 패턴

• 프론트 컨트롤러 서블릿 하나로 클라이언트의 모든 요청을 받는다.

• 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출한다.

• 공통 처리가 가능하다.

• 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 직접 사용하지 않아도 된다.

• 스프링 웹 MVC의 DispatcherServlet 이 바로 이 FrontController 패턴으로 구현되어 있다.

#8. Spring MVC 구조

DispatcherServlet이 요청을 받아 처리하는 동작 순서다.

flowchart LR
    A[클라이언트 요청] --> B[DispatcherServlet]
    B --> C[핸들러 매핑]
    C --> D[핸들러 어댑터]
    D --> E[컨트롤러 핸들러]
    E --> F[ModelAndView 반환]
    F --> G[ViewResolver]
    G --> H[View 렌더링]
    H --> A

1. 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.

2. 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.

3. 핸들러 어댑터 실행 → 핸들러 실행: 어댑터가 실제 핸들러(컨트롤러)를 실행한다.

4. ModelAndView 반환: 핸들러가 반환한 정보를 ModelAndView로 변환해서 반환한다.

5. ViewResolver 호출: 뷰 리졸버를 찾아 실행한다.

6. View 반환: 뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링을 담당하는 뷰 객체를 반환한다.

7. 뷰 렌더링: 뷰를 통해 화면을 렌더링한다.

#핵심 어노테이션

• @Controller — 스프링이 자동으로 빈으로 등록한다(내부에 @Component가 있어 컴포넌트 스캔 대상). 어노테이션 기반 컨트롤러로 인식된다.

• @RequestMapping — 요청 정보를 매핑한다. 해당 URL이 호출되면 이 메소드가 실행된다. 어노테이션 기반이라 메소드 이름은 임의로 지어도 된다.

#9. 로깅(Logging)

운영 환경에서는 System.out.println 대신 로그 라이브러리를 사용한다.

#로그 라이브러리

• Logback, Log4j, Log4j2 등 여러 라이브러리가 있는데, 이를 통합해 인터페이스로 제공하는 것이 SLF4J다.

• SLF4J는 인터페이스이고, 그 구현체로 Logback 등을 선택한다.

• 스프링 부트는 기본으로 Logback을 제공하며 대부분 이를 사용한다.

#로그 사용의 장점

• 쓰레드 정보, 클래스 이름 같은 부가 정보를 함께 볼 수 있고 출력 모양을 조정할 수 있다.

• 로그 레벨에 따라 개발 서버에서는 모든 로그를, 운영 서버에서는 일부만 출력하도록 조절할 수 있다.

• 콘솔뿐 아니라 파일·네트워크 등 별도 위치에 남길 수 있다. 파일은 일별·용량별 분할도 가능하다.

• 성능도 System.out보다 좋다.

#로그 레벨

TRACE > DEBUG > INFO > WARN > ERROR

#로그 레벨 설정 (application.properties)

# 전체 로그레벨 설정 (기본 info)
logging.level.root=info

# hello.springmvc 패키지와 그 하위 로그 레벨 설정
logging.level.hello.springmvc=debug

#로그 선언

// 1) 직접 선언
private final Logger log = LoggerFactory.getLogger(getClass());

// 2) static 으로 선언
private static final Logger log = LoggerFactory.getLogger(Xxx.class);

// 3) Lombok 사용 (권장)
@Slf4j
public class MyController {
    public void hello() {
        log.info("info log = {}", data);
    }
}