꾸준히열심히하자

[Spring] 쿠키/세션의 한계, 인터셉터로 극복하기

꾸준한승준씨 — Thu, 11 Jun 2026 14:51:44 +0900

1. 문제 제기 : 쿠키/세션만 활용했을때 치명적 한계

현재 기획중인 '학원 강사 주간 수업 현황 보고 API 서버' 에서는 인가된 강사만이 학생의 데이터를 조회 하고 등록할수있어야한다.
초기에는 쿠키와 세션만을 활용해서 로그인을 구현하려고 했으나 문제가 발생했다. 사용자가 로그인을 하지않은 상태에서도 특정 URL을 치고 들어오면 막을 방법이 없다는것이다.
이것을 막기위해서 코드내에 session.getAttribute() 를 사용해서 로그인한 사용자인지 아닌지 로직을 모든 컨트롤러의 API 엔드포인트 마다 검증하는 로직을 추가해야한다.
이는 코드중복을 낳고, 향후 유지보수 까지 불가능하게하는 최악의 설계이다.
핵심 비즈니스 로직과 공통 관심사(인증)을 분리 해야만 했다.

2. 기술선택의 트레이드 오프: 서블릿 필터 vs 스프링 인터셉터

서블릿 필터: 서블릿 컨테이너(WAS) 단에서 동작하며 가장 앞단에서 요청을 걸러낸다. 이는 DispatcherServlet 을 호출하기도 전에 걸러내므로 효과가 좋아보이지만 로직 구현중 chain.doFilter() 호출을 하나라도 빼먹는다면 다음 단계로 넘어가지않고 화면이 하얗게 멈춰버리는 위험이 생긴다.
스프링 인터셉터: 스프링 MVC 구조 내(DispatcherServlet 이후)에 동작한다, preHandle 메서드에서 true 또는 false 만 반환하면 코드 흐름에서 직관적으로 제어할수있기에 개발 제약이 적다.

최종결정: 로그인 인가 단계는 WAS단에서 걸려야할만큼은 무거운 작업이 아니고 개발 편의성과 안정성이 높은 스프링 인터셉터를 최종 아키텍쳐로 선정했다.

3. 아키택처 적용 계획 : Argument Resolver와 결합한 컨트롤러 최적화

인터셉터로 인증 방어선을 구축하더라도, 컨트롤러에서 현재 로그인한 강사의 정보를 꺼내 쓰려면 여전히 HttpServletRequest를 뒤져 세션을 찾아야 하는 번거로움이 남는다. 이 문제를 해결하기 위해 향후 본격적인 프로젝트 구현 시 Argument Resolver를 적극 도입할 계획이다.

// 기존의 지저분한 방식
public String registerReport(HttpServletRequest request) {
    HttpSession session = request.getSession(false);
    Instructor instructor = (Instructor) session.getAttribute("loginMember");
    // ...
}

// Argument Resolver 적용 후 구상하는 클린 코드
public String registerReport(@Login Instructor loginInstructor) {
    // ... 세션 탐색 코드가 완전히 사라짐
}

학원 관리 API 서버 로그인: 왜 쿠키 대신 세션을 선택하고 30분 타임아웃을 걸었는가?

꾸준한승준씨 — Mon, 8 Jun 2026 17:47:44 +0900

학원 관리 API 서버 로그인: 왜 쿠키 대신 세션을 선택하고 30분 타임아웃을 걸었는가?

Category: Backend Security / Architecture | Project: 학원 강사 관리 시스템

1. [문제 발생] 브라우저 쿠키의 치명적 보안 결함

F12를 누르면 쿠키를 클라이언트가 변경할수있다.
내가 만들 학원 강사 API 서버에서 A강사가 B강사의 주간 수업현황이 궁금하거나 악의적으로 사용하기위해
브라우저 쿠키의 보안 결함을 사용하여 해킹을 시도 할수있다.

2. [원인 분석 및 트레이드오프] 쿠키 vs 세션의 딜레마

- 내가 이해하지 못했던 쿠키와 세션의 개념을 쉽게 풀어적은것

쿠키는 클라이언트가 가지고 있는 주머니 이고 세션은 서버가 가지고 있는 금고이다 세션에서는 중요한 정보만을 가지고 있고 서버가 클라이언트에게 임의의 랜덤값(키)를 주면 클라이언트는 키를 쿠키안에 저장을 하고 클라이언트가 요청 할때 마다 랜덤키를 서버에게 보내 서버는 랜덤키를 확인한후 인증을 통과시켜준다.

쿠키의 장점은 서버가 관리하는것이 아닌 클라이언트가 관리하는것이기 때문에 속도가 빠르지만 위변조가 가능하다는것이 단점이고
세션의 장점은 중요한 정보를 서버가 관리 하고 그 중요한 정보에 접근하기 위한 인증키인 랜덤키를 클라이언트에게 전달하여 보안에 신경쓸 수 있다. 하지만 메모리를 차지하는 비율이 높아 너무 큰 데이터를 넣으면 안된다.

3. [해결 및 적용] 학원 관리 API 서버의 세션 타임아웃 설계

그래서 내 프로젝트인 학원 관리 API 서버에서는 세션을 사용할것이고
강사들이 매일 수업 하자마자 학생들의 수업현황을 적기 때문에 세션 타임아웃을 30분으로 설계할것이다.

세션 생성코드

// 세션이 있으면 세션 반환 , 없으면 신규 세션 생성
HttpSession session = request.getSession()
// 세션에 로그인 회원 정보 보관
session.setAttribute(Key,Value)

타임 아웃 설계

server.servlet.session.timeout=180

[Spring/Java] @Repository의 진짜 역할(예외 변환)과 Optional의 올바른 사용법

꾸준한승준씨 — Fri, 8 May 2026 23:27:18 +0900

️ @Repository의 진짜 역할

@Repository는 DB에 접근하는 객체이니 스프링 관리 빈(Bean)으로 등록하고 (실제로 내부에 @Component를 포함하고 있다),
가장 중요한 역할인 복잡한 DB 전용 에러들을 스프링의 표준 에러(DataAccessException)로 바꿔 보내기 위해 적어주는 애노테이션이다.

Optional: 내용물이 있을 수도, 없을 수도 있는 상자

Optional은 '내용물이 있을 수도 있고, 없을 수도 있는 택배 상자' 같은 개념이라고 생각하면 이해하기 쉽다.
데이터가 없다고 무작정 null을 던져서 에러(NullPointerException)를 발생시키는 대신, 안전하게 빈 상자를 건네주는 역할을 한다.

public Optional<Member> findByLoginId(String loginId) {
    List<Member> all = findAll();
    for (Member m : all) {
        if (m.getLoginId().equals(loginId)) {
            // 찾았을 때: 객체를 Optional 상자에 예쁘게 포장해서 반환
            return Optional.of(m);
        }
    }
    // 못 찾았을 때: null 대신 '빈 상자'를 반환 (안전함)
    return Optional.empty();
}

스프링 검증 로직 진화 과정과 DTO 분리 전략

꾸준한승준씨 — Thu, 7 May 2026 22:24:12 +0900

스프링 메시지 소스(MessageSource) 설정 오류 해결 및 rejectValue()와 FieldError의 차이점

꾸준한승준씨 — Wed, 6 May 2026 23:19:19 +0900

오늘의 의문점: rejectValue()는 어떻게 거절된 값을 알까?

FieldError 객체를 직접 생성할 때는 인자로 rejectedValue(사용자가 잘못 입력한 값)를 직접 넘겨주어야 했다.
하지만 BindingResult의 제공 메서드인 rejectValue()를 사용할 때는 rejectedValue를 인자로 주지 않는데도, 화면에 잘못 입력한 값이 그대로 남아서 유지된다. 어떻게 이게 가능한 걸까?

해소점: BindingResult의 타겟(Target) 인지 능력

그 해답은 BindingResult의 위치와 역할에 있다.
BindingResult는 컨트롤러 메서드 파라미터에서 항상 검증할 타겟 객체(예: @ModelAttribute Item item) 바로 뒤에 선언된다. 즉, BindingResult는 자신이 검증해야 할 Target 객체의 정보를 이미 내부에 품고 있다.

핵심 동작 원리
rejectValue("필드명", "오류 코드")를 호출하면, 스프링 내부에서 알아서 타겟 객체에 접근한다. 그리고 해당 필드의 현재 값을 가져와서 자동으로 FieldError의 rejectedValue로 넣어주는 마법을 부린다.

⚠️ 주의할 점: rejectValue의 두 번째 인자는 실제 보여줄 오류 메시지 텍스트가 아니라, errors.properties에서 메시지를 찾기 위한 '오류 코드(Message Code)'이다.

[Spring MVC 2] 검증(Validation) 심화: BindingResult와 데이터 유지의 비밀

꾸준한승준씨 — Thu, 23 Apr 2026 23:27:14 +0900

️ 스프링 검증(Validation) 2편: BindingResult 완벽 이해

스프링에서 검증 오류를 처리할 때 가장 중요한 BindingResult의 핵심 동작 원리와 데이터 유지 방법을 정리합니다.

1. BindingResult의 '전담 마크' 원칙

BindingResult는 반드시 검증할 대상인 @ModelAttribute 바로 다음 매개변수에 위치해야 합니다.

    // ❌ 잘못된 예: student의 에러를 잡을 수 없음

    public String add(@ModelAttribute Student s, @ModelAttribute ClassInfo c, BindingResult result) { ... }

    // ⭕ 올바른 예: 각 객체마다 전담 바구니 배치

    public String add(@ModelAttribute Student s, BindingResult studentResult, 

                  @ModelAttribute ClassInfo c, BindingResult classInfoResult) { ... }

* 이유: 스프링은 자신의 직전(왼쪽) 인자만 검증 대상으로 인식합니다.

2. 400 에러 페이지 방어하기

컨트롤러 매개변수에 BindingResult가 없으면, 타입 미스매치(숫자 칸에 문자 입력 등) 발생 시 스프링은 즉시 예외를 던지고 Whitelabel Error Page를 보여줍니다.

BindingResult가 있으면: 일단 컨트롤러를 호출합니다! 대신 에러 내용을 바구니에 담아 넘겨줍니다.
덕분에 개발자는 if (bindingResult.hasErrors())를 통해 에러를 인지하고 사용자에게 다시 입력 폼을 보여줄 수 있습니다.

3. 사용자 입력 값 유지 (rejectedValue)

검증에 실패했을 때, 사용자가 방금 입력한 잘못된 값이 사라지면 사용자 경험(UX)이 매우 나빠집니다. 이를 해결하기 위해 FieldError의 rejectedValue를 사용합니다.

    new FieldError("item", "price", item.getPrice(), false, null, null, "에러 메시지");
  

여기서 3번째 인자인 item.getPrice()(거절된 값)가 BindingResult에 보관되고, 타임리프의 th:field는 모델 객체가 아닌 이 보관소에서 값을 우선적으로 찾아 화면에 다시 뿌려줍니다.

"기록은 기억보다 강하다. 오늘도 한 걸음 더 성장!"

[Spring MVC 2] 19일 만의 복귀! 검증(Validation) 시작

꾸준한승준씨 — Wed, 22 Apr 2026 22:48:24 +0900

19일 만의 복귀: 스프링 검증(Validation) V1 핵심 정리

길었던 방황을 끝내고 다시 백엔드 공부의 시동을 켰습니다. 6월 학원 관리 시스템 프로젝트를 위해 꼭 필요한 컨트롤러의 HTTP 요청 검증 뼈대를 다지는 시간입니다.

1. 컨트롤러의 주요 역할

"HTTP 요청이 정상인지 검증하는 것"

클라이언트가 보낸 데이터가 올바른지 가장 먼저 확인하는 문지기 역할입니다. 여기서 꼼꼼하게 불량 데이터를 걸러내야 안쪽에 있는 핵심 서비스(비즈니스 로직) 계층을 안전하게 보호할 수 있습니다.

2. @ModelAttribute의 숨겨진 기능

컨트롤러의 매개변수로 @ModelAttribute를 사용하면, 파라미터를 객체에 바인딩해 주는 것뿐만 아니라 Model에 객체를 자동으로 담아주는 역할까지 뒤에서 조용히 수행합니다.

    @ModelAttribute Item item

    // 위 코드는 아래 코드와 완전히 동일한 효과를 냅니다.

    model.addAttribute("item", item);

3. GET 요청에서 빈 객체(new Item())를 넘겨주는 진짜 이유

❌ 흔한 착각: "리다이렉트해서 돌아왔을 때 데이터를 유지하기 위해서다?"

⭕ 팩트 체크:

화면을 그리는 타임리프의 th:object="${item}"이 에러를 뱉지 않게 하기 위해 우선 빈 상자라도 쥐어주는 것입니다.
검증 실패 시 사용자가 입력한 값을 유지한 채 폼으로 다시 돌아가야 할 때, 리다이렉트를 하면 아예 새로운 요청이 되어 데이터가 싹 날아갑니다.
따라서 return "validation/v1/addForm"; 처럼 뷰 템플릿 이름만 그대로 반환(포워드)하여, Model에 담겨있는 기존 입력값들이 화면에 그대로 렌더링되어 유지되도록 하는 것이 핵심입니다.

4. Safe Navigation Operator (?.)

타임리프나 스프링 SpEL에서 참조 변수에 접근할 때 서버가 뻗는 대참사를 막아주는 아주 유용한 디테일입니다.

일반 접근 (참조변수.필드): 변수가 null이면 여지없이 NullPointerException 폭탄이 터집니다.
안전한 접근 (참조변수?.필드): 변수가 null인 경우 에러를 터뜨리지 않고 부드럽게 null을 반환하고 넘어갑니다.

어둠 속에서 다시 켠 작은 빛. 멈추지 말고 꾸준히 가보자!

[Troubleshooting] 타임리프 IllegalAccessException 에러 원인 분석과 public 접근 제어자의 중요성

꾸준한승준씨 — Thu, 2 Apr 2026 19:08:29 +0900

[트러블슈팅 1] 타임리프 기본 객체 조회 에러 (Spring Boot 3.x)

1. 에러 메시지

java.lang.IllegalArgumentException: The 'request','session','servletContext' and 'response' expression utility objects are no longer available by default...

2. 발생 원인
과거 Spring Boot 2.x 버전에서는 타임리프 화면 단에서 ${session}, ${#request} 등을 통해 웹 기본 객체를 직접 조회할 수 있었습니다.
하지만 뷰(View) 템플릿이 백엔드의 깊은 객체인 session, request 등에 직접 접근하는 것은 보안상 취약하며 객체지향 설계에도 어긋납니다. 따라서 Spring Boot 3.x (타임리프 3.1 이상)부터는 프레임워크 차원에서 이 직접적인 접근을 원천 차단했습니다.

3. 해결 방법 (실무 정석)
화면에서 직접 객체를 뒤지지 않고, 컨트롤러(Controller)에서 데이터를 꺼내어 Model에 담아 전달하는 방식을 사용합니다.

HttpSession의 getAttribute()로 데이터를 꺼낸 뒤, Model의 addAttribute()를 이용해 뷰(View)로 넘겨주어 해결했습니다.

[트러블슈팅 2] 자바스크립트 인라인 객체 접근 권한 에러

1. 에러 메시지 (Root Cause)

java.lang.IllegalAccessException: ... cannot access a member of class ... with modifiers "public"

2. 발생 원인
타임리프의 자바스크립트 인라인 기능(<script th:inline="javascript">)을 사용하던 중 터진 에러입니다.
타임리프가 백엔드에서 넘겨준 커스텀 객체를 자바스크립트가 쓸 수 있도록 JSON 형태로 자동 변환(직렬화)하려 했으나, 해당 클래스의 접근 제어자가 public이 아니어서 내부 데이터에 접근(Access)하지 못해 발생했습니다.

3. 해결 방법
해당 객체의 클래스 레벨에 public 키워드를 명시적으로 붙여주어 접근 권한을 열어주어 해결했습니다.

[CS 심화] 왜 객체에 public을 붙여줘야 할까?

리플렉션(Reflection): 외부의 라이브러리나 프레임워크가 런타임에 내 코드의 객체를 분석하고 사용하는 기술입니다.
타임리프나 Jackson 같은 라이브러리가 자바의 리플렉션을 활용해 객체의 데이터를 읽어갈 때, 해당 클래스와 Getter 메서드가 반드시 public으로 개방되어 있어야만 데이터를 정상적으로 조회하고 사용할 수 있습니다.

(Spring) 순수 자바의 한계와 AppConfig의 등장: DI/IoC로 OCP, DIP 완벽 해결하기

꾸준한승준씨 — Wed, 11 Mar 2026 23:14:48 +0900

1. 순수 자바로만 코드를 작성했을 때의 문제점

순수 자바로 코드를 작성할 때, OrderServiceImpl 클래스는 DiscountPolicy 인터페이스에만 의존해야 합니다. 하지만 실제 코드를 보면 다음과 같은 문제가 발생합니다.

public class OrderServiceImpl implements OrderService {
    // private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

위 코드는 FixDiscountPolicy 또는 RateDiscountPolicy 같은 구현체 인스턴스에도 직접 의존하고 있는 상태입니다. 이는 DIP(의존역전원칙) 위반입니다.

또한, 갑자기 할인 정책이 바뀌어 RateDiscountPolicy로 변경해야 할 때, 클라이언트인 OrderServiceImpl의 코드를 직접 수정해야 합니다. 이는 OCP(개방폐쇄원칙) 위반입니다.

2. 공연 기획자의 등장 (AppConfig)

이를 해결하기 위해 하나의 공연을 애플리케이션이라고 예시를 들어보겠습니다. 여기서 역할(인터페이스)은 '로미오와 줄리엣'입니다.

로미오 역할로 캐스팅된 강동원(구현체, 배우)이 있다고 가정해 보겠습니다. 강동원은 본인의 연기에만 집중하면 되지, 상대역인 줄리엣 역할로 누가 캐스팅될 것인지까지 신경 쓸 필요가 없습니다.
누가 캐스팅되어야 할지 결정하는 것은 공연 기획자가 해야 할 일입니다.

따라서 자바 코드에서도 이 '공연 기획자' 역할을 하는 클래스를 만들어야 합니다. 배우를 캐스팅하고(구현 객체를 생성하고) 연결해 주는 AppConfig 클래스를 생성해 보겠습니다.

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), disCountPolicy());
    }

    @Bean
    public DisCountPolicy disCountPolicy() {
       //return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }

    @Bean
    public MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

@Configuration : AppConfig에 애플리케이션의 설정을 구성한다는 뜻입니다.
@Bean : 스프링 컨테이너에 스프링 빈으로 등록합니다.

이 AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 DI(Dependency Injection) 컨테이너라고 합니다. 위 코드가 바로 스프링으로 전환한 코드입니다.

3. DIP, OCP를 완벽히 준수한 클라이언트 코드

이제 AppConfig를 도입한 후 OrderServiceImpl의 코드가 어떻게 바뀌는지 살펴보겠습니다.

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DisCountPolicy disCountPolicy;

    // 생성자를 통해 의존관계를 주입(DI) 받음
    public OrderServiceImpl(MemberRepository memberRepository, DisCountPolicy disCountPolicy) {
        this.memberRepository = memberRepository;
        this.disCountPolicy = disCountPolicy;
    }
}

이제 OrderServiceImpl은 더 이상 구체적인 클래스에 의존하지 않고 오직 인터페이스에만 의존합니다. 완벽히 DIP, OCP를 지킨 코드라 할 수 있습니다.

4. 스프링 컨테이너 적용 (OrderApp)

마지막으로 이를 실행하는 OrderApp 클래스입니다.

public class OrderApp {
    public static void main(String[] args) {
        // AppConfig appConfig = new AppConfig();
        // MemberService memberService = appConfig.memberService();
        // OrderService orderService = appConfig.orderService();
        
        ApplicationContext ap = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = ap.getBean("memberService", MemberService.class);
        OrderService orderService = ap.getBean("orderService", OrderService.class);

        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);
        
        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

여기서 ApplicationContext를 스프링 컨테이너라고 합니다. 기존에는 개발자가 직접 AppConfig를 생성해서 직접 객체를 조회했지만, 이제는 스프링 컨테이너를 통해서 스프링 빈(객체)을 찾아서 사용하게 됩니다.

(Spring) 스프링(Spring)의 존재 이유: 객체 지향 프로그래밍과 SOLID 원칙

꾸준한승준씨 — Mon, 9 Mar 2026 22:59:46 +0900

스프링 프레임워크와 객체 지향 설계의 핵심

1. 스프링과 스프링 부트 (Spring & Spring Boot)

스프링 (Spring)

스프링은 DI(Dependency Injection) 컨테이너 기술을 중심으로 하는 강력한 프레임워크입니다. 핵심 기술인 스프링 프레임워크를 기반으로 다양한 생태계(Spring Boot, Spring Data 등)를 구성하고 있습니다.

스프링 부트 (Spring Boot)

스프링 부트는 복잡한 스프링을 편리하게 사용할 수 있도록 지원하는 도구입니다.

복잡한 외부 라이브러리 버전을 크게 신경 쓰지 않아도 최적화된 조합을 제공합니다.
내장 톰캣(Tomcat) 서버 등을 제공하여 별도의 복잡한 설정 없이 애플리케이션을 실행할 수 있습니다.

2. 스프링의 핵심: 좋은 객체 지향 프로그래밍

스프링의 핵심 개념: 스프링은 자바 기반의 프레임워크로, 개발자가 '좋은 객체 지향 애플리케이션'을 개발할 수 있도록 도와주는 프레임워크입니다.

좋은 객체 지향 프로그램이란?

단순한 명령어의 나열이 아닌, 객체들의 모임이며 이 객체들끼리 메시지를 주고받으며 협력합니다.
프로그램이 유연하고 변경에 용이하다는 특징을 가집니다.

3. 다형성 (Polymorphism): 객체 지향의 꽃

유연하고 변경에 용이한 객체 지향 프로그램을 만들 때 다형성은 필수입니다. 다형성은 애플리케이션의 '역할'과 '구현'을 분리해 줍니다.

자동차 비유: 자동차 사용자(클라이언트)는 '자동차 인터페이스(역할)'의 사용법만 알면 됩니다. 내부 엔진이 어떻게 굴러가는지, K3인지 아반떼인지 구체적인 '구현체(클래스)'의 내부 구조를 알 필요가 없습니다.

다형성의 본질: 클라이언트의 코드를 전혀 변경하지 않고도, 서버의 구현 기능을 유연하게 변경하고 확장할 수 있습니다.

4. 객체 지향 설계의 핵심 원칙 (SOLID)

좋은 객체 지향 설계를 위해 반드시 알아야 할 SOLID 원칙 중 핵심적인 4가지를 정리해 보았습니다. (참고: SOLID는 원래 5가지 원칙이며, 여기서는 작성한 핵심 4가지를 다룹니다.)

1. SRP (Single Responsibility Principle) : 단일 책임 원칙 하나의 클래스는 단 하나의 책임만 가져야 합니다. 클래스의 변경이 있을 때, 다른 곳에 미치는 파급 효과가 적다면 SRP를 잘 지킨 것입니다.
2. OCP (Open-Closed Principle) : 개방-폐쇄 원칙 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 합니다. 다형성을 활용하여 인터페이스(변경 X)를 두고, 새로운 구현체를 만들어(확장) 기능을 추가하는 방식입니다.
3. LSP (Liskov Substitution Principle) : 리스코프 치환 원칙 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서, 언제나 하위 타입의 인스턴스로 교체할 수 있어야 합니다. 쉽게 말해, 구현체는 인터페이스의 규약과 의도를 모두 지켜야 한다는 뜻입니다.
4. DIP (Dependency Inversion Principle) : 의존관계 역전 원칙 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안 된다"는 원칙입니다. 즉, 클라이언트 코드가 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 유연한 변경이 가능해집니다.

결론: 스프링은 왜 필요한가?

순수 자바 코드만으로는 다형성을 활용하더라도 OCP와 DIP 원칙을 완벽하게 지키기 어렵습니다. (클라이언트 코드의 변경이 불가피함)

스프링은 DI(의존성 주입)와 DI 컨테이너를 제공함으로써, 이 문제를 해결합니다. 스프링을 활용하면 다형성과 더불어 OCP, DIP를 완벽하게 지키며 유연한 애플리케이션을 설계할 수 있게 됩니다.