✨ 스프링을 사용하는 이유

스프링

누구나 쉽고 빠르게 자바 프로그래밍을 할 수 있도록 돕는 대중적인 자바 프레임워크입니다.

 

스프링은 기존 애플리케이션 개발의 복잡성을 줄이고 편하게 개발할 수 있는 솔루션을 제공합니다. 특정 기술에 의존적이거나 복잡한 부가작업에 대해 신경쓰지 않고 비즈니스 로직 자체에 집중할 수 있도록 도와주어 개발 생산성을 높힙니다.

 

스프링은 자바 언어 기반의 프레임워크이고 자바 언어는 객체 지향 언어입니다. 스프링의 진짜 핵심은 객체 지향 언어가 가진 특징을 살려 좋은 객체 지향 애플리케이션을 개발할 수 있도록 돕는 프레임워크입니다. 

 

스프링? 스프링 부트?

스프링과 스프링 부트, 언뜻 보면 둘의 차이를 헷갈릴 수 있습니다. 간단하게 스프링부트는 스프링 프레임워크를 더 쉽게 사용할 수 있도록 도와주는 프레임워크입니다.

 

 

위는 스프링부트 공식 레퍼런스 첫 페이지 입니다. 간단하게 스프링부트 프레임워크의 소개와 피처들이 보입니다. 첫줄에 stand-alone, just run과 같은 단어들이 눈길을 끄는데요.

말 그대로 스프링부트는 애플리케이션을 켜기만 하면 바로 실행할 수 있을 정도로 초기 설정과 많은 부가기능들을 지원하여 스프링 애플리케이션을 손쉽게 개발할 수 있게 도와줍니다.

 

대표적으로 지원하는 기능으로는 내장 톰켓 서버, 스타터 라이브러리 지원, 엑추에이터 지원, 기존 복잡했던 XML 설정을 어노테이션으로 지원 등등등... 으로 많은 편의 기능을 지원하는 프레임워크 입니다.

 

OOP - 객체 지향 프로그래밍

자자 다시 본론으로 돌아와서, 스프링의 진짜 핵심은 객체 지향 프로그래밍에 있다고 했습니다.

 

객체 지향 프로그래밍은 컴퓨터 프로그램, 코드를 명령어로만 보는 시각이 아닌 각각의 독립된 주체, 즉 객체들의 모임으로 보는 관점입니다. 각각의 객체들은 상태와 행위를 가지고 서로 메시지를 주고 받으며 협력을 합니다. OOP는 프로그램을 유연하고 유지보수를 쉽게 하여 대규모 소프트웨어 개발에 많이 사용됩니다.

 

• 추상화
• 캡슐화
• 상속
• 다형성

위는 객체 지향의 네가지 특징입니다. 그 중 객체지향의 꽃은 다형성입니다.

 

다형성

다형성의 개념은 여러 형태를 받아드릴 수 있는 성질입니다. 다형성은 역할과 구현을 분리하여 다형성을 구현할 수 있습니다.

 

간단한 예를 들어 로봇 조종자와 로봇이 있다고 예를 들어보겠습니다. 로봇조종자는 매년 로봇 조종 대회에 참가합니다. 하지만 매년 사용해야하는 로봇의 기종이 달라질 수 있습니다. 그렇다면 로봇조종자는 매년 달라지는 각각의 로봇에 대한 조종 방법을 다시 처음부터 배워야할 것입니다.

 

여기서 역할과 구현을 분리한다면, 로봇이라는 역할과 각각의 다른 기종들의 로봇들의 구현을 분리한다면 로봇 조종자는 로봇 조종 방법만 알면 되고 로봇의 기종이 달라진다고 해도 로봇이라는 역할을 잘 수행한다면 로봇조종자는 새롭게 로봇 조종 방법을 배울 필요가 없어지겠죠?

 

즉 이렇게 역할과 구현으로 구분한다면 유연하게 변경에 대처할 수 있습니다. 이를 자바 언어로 본다면 인터페이스로 역할을 인터페이스의 구현체를 구현으로 생각할 수 있습니다. 다형성의 본질은 구현체를 애플리케이션 실행 시점에 유연하게 변경하여 구현이 변경되어도 클라이언트 코드는 역할만 알고 있으면 되니 클라이언트 코드 변경이 없이 유연한 변경이 가능해집니다.

 

SOLID

객체 지향을 잘 지키기 위한 SOLID 원칙이라는 것이 있습니다. SOLID 원칙 중 2번째, 5번째 원칙인 OCP, DIP는 위에서 다루었던 다형성과 밀접한 연관이 있습니다.

 

OCP - 개방 폐쇄 원칙

소프트웨어는 확장은 가능하지만 변경에는 닫혀야한다라는 개념입니다. 확장하려면 변경이 있어야하는것이 아닌가? 하는 생각이 들 수 있습니다. 이는 다형성으로 실현할 수 있습니다. 인터페이스로 역할을 만들고 구현체들을 두어 해당 역할에 대한 구현을 만들어 이를 사용하는 클라이언트는 역할을 의존하고 구현이 변경되어도 코드 변경이 이루어지지 않습니다.

 

RobotService의 구현체인 RobotServiceV1Impl

 

이렇게 역할을 두고 기능들을 구현하여 구현체를 갈아 끼울 수 있습니다. 하지만 기능이 확장되어 다른 구현체로 변경하고 싶다면 어떻게 해야할까요?

 

 

이런식으로 클라이언트 코드를 직접 변경하여 다른 구현체로 갈아끼워주어야합니다. 이렇게 된다면 기능이 확장되었을 때 이 기능을 사용하는 클라이언트 코드를 변경해주어야 하기 때문에 OCP를 지킬 수 없습니다.

 

DIP - 의존 역전 원칙

구체화에 의존하지 말고 추상화에 의존해야한다는 원칙입니다. 즉 구현체에 의존하지 않고 역할 곧 인터페이스에 의존하라는 뜻 입니다. 앞서 설명한 다형성의 특징을 생각해보면 인터페이스에 의존한다면 아주 유연하게 구현체를 변경할 수 있습니다.

 

하지만 위의 사진을 다시 본다면 RobotService를 사용하는 클라이언트는 인터페이스를 의존하지만 인터페이스의 구현체도 함께 의존합니다. 당연한 말이죠 인터페이스의 구현체를 주입해야하기 때문입니다. 하지만 구현 클래스를 의존하고 있기 때문에 DIP도 위반입니다.

 

객체 지향과 스프링

자 이렇게 다형성만으로는 OCP, DIP와 같은 설계를 지킬 수 없습니다. 하지만 짜잔 이런 문제점을 스프링은 모두 해결해줍니다. 스프링이 클라이언트 코드의 변경 없이 구현 클래스를 주입(DI)할 수 있게 지원해주기 때문에 구현체를 쉽게 부품을 교체하듯 개발할 수 있습니다.

 

DI즉 Dependency Injection 기술로 추상화를 의존하고 있는 클라이언트의 코드 변경 없이 주입하고자 하는 구현체를 스프링이 직접 주입해주므로 OCP, DIP를 지키는 유연한 애플리케이션을 개발할 수 있도록 도와준다.

 

스프링은 이러한 핵심 개념 위에서 스프링 빈, DI, IOC, AOP등과 같은 여러 기능들을 제공하여 더 객체지향적으로 개발할 수 있게 도와줍니다!