[Spring] 스프링과 객체지향 프로그래밍 (1)

개요

스프링을 공부하며, IoC와 DI 개념에 대해서 공부하긴 했어도, 저를 포함하여 많은 분들에게는 와닿지 않을 것입니다.

스프링을 공부하기 이전에, 스프링은 왜 탄생했고, 스프링 이전에는 어떻게 개발을 하였으며, 어떤 과정으로 스프링이 탄생했는지 구체적으로 짚고 넘어가고자 합니다.

스프링의 탄생 배경, 객체지향 프로그래밍과 다형성 등 스프링의 핵심 이념에 대해 다루어 보았습니다.

목차

1. 스프링이란?
2. 스프링 탄생의 배경과 스프링의 진짜 핵심
3. 객체지향 프로그래밍과 다형성
4. 역할과 구현의 분리
5. 좋은 객체지향 설계의 5가지 원칙 (SOLID) - (2)에서 계속

1. 스프링이란?

보통 스프링이라고 하면, 특정한 하나의 기술을 가리키는 것이 아니라, 여러 기술의 모음을 가리킵니다.

• 스프링 프레임워크: 필수.
• 스프링 부트: 필수.
• 스프링 데이터 - CRUD를 편리하게 사용하게 해 줍니다. Spring Data, JPA emd.
• 스프링 세션
• 스프링 시큐리티
• 스피링 Rest Docs - API 문서화를 편리하게 관리하도록 돕습니다.
• 스프링 배치 (batch) - 배치 처리에 특화
• 스프링 클라우드

스프링 프레임워크는 다양한 핵심 기술을 제공합니다.

• 핵심 기술: 스프링 DI 컨테이너, AOP 이벤트 등.
• 웹 기술: 스프링 MVC, 스프링 Web Flux
• 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원 등
• 기술 통합: 캐시, 이메일, 원격 접근, 스케쥴링
• 테스트: Spring 기반 테스트 지원 (JUnit 4, 5 등)
• 언어: Java, Kotlin, Groovy 등 JVM 기반 언어들
• 최근에는 스프링 부트를 통해서 스프링 프레임워크 기술들을 간편하게 설정하여 사용할 수 있습니다,.

스프링 부트는 기존의 스프링 단독 사용에 비해 다음과 같은 이점을 가집니다.

• 단독으로 실행 가능한 스프링 어플리케이션을 쉽게 생성할 수 있습니다.
• Tomcat과 같은 웹 서버를 기본으로 내장하여, 바로 실행할 수 있습니다.
• 손쉬운 빌드 구성을 위한 starter 종속성을 제공합니다.
• 스프링에 필요한 외부 라이브러리를 자동으로 구성합니다.
• 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능을 제공합니다.
• 위와 같은 장점 덕분에, 최근에는 다양한 실무 환경에서 기본으로 사용되고 있습니다.

스프링이라는 개념은 위의 내용 뿐만이 아니라, 매우 포괄적인 내용을 전부 일컫습니다.

따라서 문맥에 따라서 가리키는 개념이 다를 수 있습니다.

• 스프링 DI 컨테이너 (핵심 중의 핵심, Bean을 관리하는 등의 역할)
• 스프링 프레임워크
• 스프링 부트, 프레임워크 등을 모두 포함하는 스프링 생태계 (가장 보편적으로 사용됨)

2. 스프링 탄생의 배경과 스프링의 진짜 핵심

스프링을 왜 만들었을까요? 스프링은 어떤 배경을 통해 탄생했을까요?

이러한 배경을 알아야 하는 이유는, 왜 만들어졌는지 알아야 제대로, 효율적으로 사용할 수 있기 때문입니다.

 

스프링이 현재 어떻게 사용되고 있는지는 핵심이 아닙니다.

보통 '스프링' 하면, 웹 백엔드 개발, IoC, DI, 전자정부 프레임워크 등등을 떠올리기 쉬운데요.

이런 것들은 스프링의 결과물이지, 스프링의 핵심이라고 할 수 없습니다.

 

스프링의 핵심을 생각해 보겠습니다.

스프링은 우선, Java 기반의 프레임워크입니다. Java의 가장 큰 특징은 (물론 이식성도 있지만) 객체지향 언어라는 점입니다.

스프링은, Java가 가진 객체 지향의 강력한 특징을 살려내는 프레임워크라고 할 수 있습니다.

즉, 스프링은 좋은 객체 지향 어플리케이션을 개발할 수 있게 도와 주는 프레임워크입니다.

 

스프링 이전에는 EJB (Enterprise Java Beans)가 보편적으로 사용되었습니다.

하지만 EJB는 EJB 의존적으로 개발을 해야 했기 때문에, 객체지향의 장점도 모두 잃어버리고, EJB에 종속되었습니다.

이러한 맥락에서, 차라리 기존 자바로 돌아가서 객체지향 개발을 하자는 의미에서 POJO (Plain Old Java Object)라는 개념도 등장하게 되었습니다.

스프링이 등장한 이후, Java를 이용한 객체지향 개발을 매우 편리하고 효율적으로 할 수 있게 되었습니다.

3. 객체지향 프로그래밍과 다형성

객체지향 개발은 무엇일까요?

좋은 객체지향 프로그래밍이란, 컴퓨터 프로그램을 명령어의 모음으로 보는 것에서 벗어나, 여러 개의 독립된 단위, 즉 객체의 모임으로 파악하고자 하는 것입니다. 각각의 객체는 메세지를 주고 받고, 데이터를 처리하는 등의 협력을 하게 됩니다.

코드를 객체 단위로 보게 되면, 프로그램을 유연하고 변경이 용이하게 만들 수 있습니다. 즉, 유지/보수가 쉬워집니다. 따라서 대규모 소프트웨어 개발에 많이 사용됩니다.

 

유연하고 변경이 용이하다는 말은, 코드를 마치 레고 블럭 조립하듯, 컴퓨터 부품을 갈아 끼우듯, 원하는 키보드와 마우스를 장착하듯, 자유롭게 변경할 수 있는 경우를 말합니다.

이러한 레고 블럭, 컴퓨터 부품, 키보드와 마우스를 컴포넌트라고 부릅니다. 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법이 객체지향 개발인 것입니다.

유연함과 변경 용이함은, 객치지향 프로그래밍의 개념 중에서도 다형성에 해당합니다.

 

다형성을 쉽게 이해하기 위해, 간단한 예시를 들어 보겠습니다.

우리 실생활을 역할과 구현으로 구분하여 생각해 봅시다.

우리가 자동차를 운전할 때, 차종에 따라서 운전하는 방법이 아예 바뀌나요? 그렇지 않습니다.

차 종류와 상관 없이, 핸들을 통해 방향을 전환하고, 가속과 브레이크 등의 기본 조작법은 모두 동일하죠. (물론 세세한 건 다를 수 있습니다.)

이는 자동차라는 역할에 대한 구현만 바뀌었기 때문입니다. 자동차가 바뀌어도 운전자에게는 아무런 영향을 주지 않죠.

 

기아 K3, 테슬라 모델 3 등은 자동차라는 역할에 대한 특정 구현입니다. 이들은 '자동차' 라는 인터페이스를 따라서 구현되었고, 따라서 자동차로써 기대되는 모든 기능을 충족합니다.

운전자는 특정 자동차의 구현에 의존하는 것이 아니라, 자동차라는 역할 (interface) 에 대해서만 의존하고 있습니다. 

'자동차' 라는 역할을 만들고, 구현을 분리한 것은 '운전자'를 위해서입니다.

운전자 (client)가 자동차의 내부 구조를 몰라도 되고, 구현체 (자동차)가 내부적으로 바뀌더라도, 자동차의 역할만 잘 하고 있다면 클라이언트에게 영향을 주지 않습니다.

또, 구현체 자체를 다른 것으로 바꾸어도 (K3 -> 모델 3), 운전자는 바뀔 필요가 없습니다.

즉, 자동차는 무한히 확장이 가능하고, 운전자는 여전히 운전이 가능합니다!

4. 역할과 구현의 분리

다형성을 이용한 객체 지향 개발도 마찬가지입니다. 코드를 역할과 구현으로 구분하면, 개발이 단순해지고, 유연해지며, 변경도 편리해집니다.

• 클라이언트는 대상의 역할 (인터페이스)만 알면 됩니다.
• 클라이언트는 구현 대상의 내부 구조를 몰라도 됩니다.
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않습니다.
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않습니다.

위의 용어를 Java에 대응시켜 봅시다.

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클라스, 구현 객체
• 객체를 설계할 때, 역할과 구현을 명확히 분리
• 객체 설계 시 역할 (인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체를 만듭니다. 즉, 구현보다 인터페이스가 먼저입니다.

MemberService가 MemberRepository라는 인터페이스에 의존하고 있는 상황을 가정해 보겠습니다.

MemberService는 MemberRepository의 save() 기능을 사용하려고 합니다.

인터페이스 MemberRepository의 구현체로는 MemoryMemberRepository, JdbcMemberRepository 두 개가 존재합니다.

MemberRepository는 역할이고, 실제 구현은 MemoryMemberRepository, JdbcMemberRepository가 되겠지요.

MemberService는 MemberRepository에만 의존하고 있으므로, 실제 구현은 둘 중 어느 것이 선택되어도 상관 없습니다.

 

객체는 서로 협력하는 관계입니다. 혼자서 존재하는 객체는 없으며, 클라이언트가 요청을 보내고 서버가 응답하듯, 수많은 객체는 서로 협력 관계를 가집니다.

다형성의 본질을 이해하려면, 협력이라는 객체 사이의 관계에서 시작해야 합니다.

위의 예시에서 볼 수 있듯, 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있습니다.

 

따라서 역할과 구현을 구분한다는 것은,

• 유연하고, 변경이 용이해집니다.
• 확장 가능한 설계가 가능합니다.
• 클라이언트에 영향을 주지 않는 변경이 가능합니다.
• 인터페이스를 안정적으로 잘 설계하는 것이 중요합니다. (한계점)

인터페이스를 잘 설계하는 것이 매우 중요한 것은, 생각해 보면 당연한 일입니다.

자동차라는 개념이 잘 설계되어 있지 않다면, 즉 핸들로 방향 조절, 브레이크로 감속 등의 개념이 정해져 있지 않다면, 사용하는 자동차마다 각각 제각각의 방법으로 기능이 구현되어 있겠지요. 이럴수록 운전자는 차를 바꿀 때마다 사용 방법을 새로 익혀야 할 것이고, 이는 좋은 설계가 아닙니다.

뿐만 아니라, 인터페이스를 수정한다면, 모든 운전자가 인터페이스 사용법을 다시 배워야 하기 때문에, 처음부터 잘 설계하는 것이 매우 중요합니다.

 

정리

설계가 유연하고, 변경이 용이하여 유지/보수가 쉬운 프로그램을 만들기 위해서는 객체지향 프로그래밍, 그 중에서도 다형성이 정말 중요합니다.

스프링은 객체지향 언어인 Java의 강점, 그 중에서도 다형성을 극대화하여 사용하도록 도와 줍니다.

스프링의 제어 역전 (Inversion of Control; Ioc), 의존관계 주입 (Dependency Injection; DI)는 다형성을 활용하여 역할과 구현을 편리하게 다룰 수 있도록 돕습니다.

 

 

* 본 글은 인프런 "스프링 핵심 원리 - 기본편 (김영한)" 강의를 들으며 공부한 내용을 정리한 글입니다.