본문 바로가기

SPRING FRAMEWORK

자바 스프링 프레임워크(Spring Framework)란 무엇인가? POJO, DI, AOP, PSA

 


The Spring Framework is a lightweight solution and a potential one-stop-shop for building your enterprise-ready applications. 

 


요약

스프링 프레임워크(Spring Framework)이란?

스프링 프레임워크(Spring Framework, 이하 스프링)는 기업용 응용프로그램 개발을 위한 자바 기반 솔루션, 또는  '자바 기반 기업용 응용 프로그램 개발을 위한 규격화된 체계'

 

스프링 프레임워크 사용이유?

1. 복잡한 기업용 시스템 구축 가능

2. 쉽고 빠른 개발을 지원해 생산 효율 높임

3. 개발자가 도메인 관련 비즈니스 로직에만 집중할 수 있도록 지원

4. 높은 보안성, 안정성, 확장성 쉽게 확보 가능

5. 스프링 이전에 주로 사용했던 EJB의 객체지향 원칙 파괴를 극복한 순수한 객체지향 프로그래밍 스타일 지원

 

스프링 프레임워크 특징

1) POJO(Plain Old Java Object): 오래된 방식의 간단한 자바 객체

POJO(Plain Old Java Object, 오래된 방식의 간단한 자바 객체)는 특정 기술이나 규약에 종속되지 않은 가벼운 자바 객체를 사용해야한다는 원칙으로 높은 코드 가독성과 순수한 객체지향 설계를 가능하게 합니다.

 

POJO 프로그래밍의 이점

  • 특정 환경이나 기술에 비종속적이기에 코드 재사용이 가능하고, 확장 가능한 유연한 코드를 작성 가능
  • 저수준 레벨의 기술 및 환경에 종속적인 코드를 애플리케이션 코드에서 제거하여 코드 가독성 높음
  • 높은 코드 가독성으로 디버깅 용이
  • 비종속적인 코드로 인해 코드 테스트 용이
  • ★객체지향 설계 가능

2) IoC(Inversion of Control): 제어권 역전

IoC(Inversion of Control) 제어권 역전이란 객체 간의 관계 설정(의존관계), 객체 생명 주기 관리 등을 제3자(프레임워크)가 담당하도록 제어권을 넘겨주어, 객체지향 프로그래밍의 올바른 객체 캡슐화를 구현할수 있도록 하고, 개발자는 비즈니스 로직 구현에 집중할 수 있도록 하는 프로그래밍 패턴을 말합니다.

 

3) DI(Dependency Injection): 의존성 주입

DI(Dependency Injection)는 '스프링 프레임워크에서 제어권 역전을 구현하기 위해 차용한 프로그래밍 방식으로 객체 간 결합을 직접 참조가 아닌 스프링 컨테이너에서 주소값을 전달받아 참조하는 패턴'으로 정의할 수 있습니다.

 

4) AOP(Aspect Oriented Programming): 관점 지향 프로그래밍

AOP(Aspect Oriented Programming, 관점지향 프로그래밍)은 어플리케이션의 공통 관심사인 로그, 보안, 트랙잭션 등을 횡단 관점으로 객체에서 분리하여 모듈화하여 관리하는 프로그래밍 방법론이며 코드의 간결성과 재사용성을 높이고 객체지향 설계 원칙에 맞는 코드를 구현할 수 있습니다.

 

AOP(Aspect Oriented Programming, 관점지향 프로그래밍) 사용이유

  • 코드 간결성, 가독성 높임
  • 코드 재사용성 높임
  • 객체지향 설계 원칙에 맞는 코드 구현

5) PSA(Portable Service Abstraction): 일관성 있는 서비스 추상화

PSA(Portable Service Abstraction, 일관성 있는 서비스 추상화)는 추상화 기법을 어플리케이션에 적용하여 서비스와 클라이언트 간 느슨한 결합을 구현합니다. 이는 서비스의 기능에 접근하는 방식을 일관되게 유지하면서 서비스가 보유하는 기술의 수정이나 변경을 유연하게 만듭니다.

 

PSA(Portable Service Abstraction, 일관성 있는 서비스 추상화) 사용이유

  • 클라이언트와 서비스 기술의 느슨한 결합관계 구축
  • 일관된 방식으로 서비스의 기술을 사용 가능
  • 서비스가 보유한 기술을 유연하게 수정, 변경하여 사용 가능

 


 

01. What: 스프링 프레임워크(Spring Framework)의 정의

JAVA 백엔드 개발자의 처음과 끝. 스프링 프레임워크(Spring Framework, 이하 스프링)기업용 응용프로그램 개발을 위한 자바 기반 솔루션입니다. 오픈소스 기반인 이 프레임워크는 프로그램 개발을 위한 유용한 기능을 모아둔 모듈(modular)의 집합인 이루어진 스프링은 필요에 따라 모듈을 가져다 쓸 수 있기 때문에 가벼운 응용 프로그램 개발이 가능합니다.

 

 

로드 존슨(Rod Johnson)에 의해 2003년 6월에 최초로 공개된 스프링은 발전을 거듭해 지난 20년간 자바 기반 웹 어플리케이션 개발의 표준이 되었습니다.

 

물론 스프링이 개발되기 전에도 응용프로그램을 개발하는 체계는 존재했습니다. 다만, 굉장히 불편하고 코드가 복잡했습니다. JSP(Java Server Page) 기술을 사용한 아키텍처를 기반으로 응용 프로그램을 개발하던 시절에는 HTML, CSS, JAVASCRIPT, JAVA코드가 하나의 보일러플레이트(boilerplate, 하나의 작업공간)안에 모두 들어가 있어 유지 보수 난이도가 그야말로 최악이었습니다. 

 

 

이전에 기업용 응용프로그램 개발을 위해 사용하던 Java EE(자바 엔터프라이즈 에디션)의 스펙을 구현한 EJB(Enterprise JavaBean)가 기술의 복잡도가 증가해서 성능이 느렸던 것을 탈피하고자 개발되었습니다. EJB는 무거운 객체를 사용하고 의존성을 높여 자바의 장점인 객체지향 프로그래밍의 특성을 파괴하였습니다.

 

스프링은 POJO라는 개념을 차용하면서도, 오픈소스인데다 쉬운 유지 보수가 가능하고 가볍기 때문에 빠르게 EJB를 대체했습니다. 

 

그렇게 자바 웹 어플리케이션 개발에 봄(Spring)이 왔습니다. (실제로 스프링이라는 이름은 자바 기반 응용프로그램 개발 분야에 겨울과 같은 어려운 시기가 지났다는 것을 의미합니다)

 

 

Q. 프레임워크(Framework)는 무슨 뜻일까요?

프레임워크(Framework)는 말 그대로 하나의 '체계'이자 '틀'을 말하는데요. 프로그래밍에서 프레임워크는 기본적으로 프로그래밍을 하기 위한 어떤 틀이나 구조를 제공합니다. 

 

마찬가지로 스프링은 응용 프로그램 개발을 위한 규격화된 규칙과 규약을 제공해줍니다. 응용 프로그램을 만들면서 생길 수 있는 패턴화된 공통 작업이나 보안, 객체 주기 관리, 트랜잭션 관리 규칙, 어플리케이션 간 통신 방법 등을 쉽게 구축할 수 있도록 여러 모듈을 제공합니다. 따라서 개발자들은 스프링을 통해 도메인(domain, 개발의 목표가 되는 비즈니스 분야)에 관련한 비즈니스 로직에만 집중할 수 있습니다.

 

쉽게 말하면 프레임워크는 개발자들이 비즈니스 로직 구현에만 집중할 수 있도록 정형화된 규칙과 설계 구조를 제공하는 것입니다. 개발자들은 스프링에서 정한 규칙과 규약에 맞춰 자신의 코드를 작성합니다. 응용프로그램 설계 흐름이 개발자가 아닌 스프링 프레임워크로 넘어간 것입니다. 이를 제어권 역전(IoC, Inversion of Control)이라고 합니다. 이러한 프레임워크 사용시 개발 유연성에 대한 약점이 생기긴 하지만 유지 보수가 난이도가 매우 낮아지고 높은 생산성을 보장하기 때문에 많은 기업에서 사용하고 있습니다.

 

정리하자면 스프링 프레임워크(Spring Framework)는 '자바 기반 기업용 응용 프로그램 개발을 위한 규격화된 체계'고 정의할 수 있습니다.

 

02. Why: 스프링 프레임워크(Spring Framework) 사용 이유

스프링 프레임워크가 이렇게 널리 쓰이는 이유가 무엇일까요? 힌트는 앞서 말한 '기업용 어플리케이션 개발'이라는 키워드에 있습니다. 기업용 어플리케이션 또는 기업용 시스템, 기업용 프로그램은 기업의 업무(조직의 업무, 고객 비즈니스) 문제를 해결하는 시스템을 의미합니다. 

 

기업용 어플리케이션은 대량의 사용자 요청 처리, 높은 보안성, 높은 성능, 안정성, 확장성, 노동 생산성 등을 충분히 고려하여 구축해야합니다. 스프링은 개발자가 여러 자잘한 기술 문제를 고민할 필요가 없게 만들면서도 높은 성능과 안정성을 담보하는 '개발체계'와 '개발 도구'를 제공함으로써 높은 생산성을 가질 수 있습니다. 생산성이 높다는 말은 곧 기업의 비용이 줄어들고 빠른 시장 변화에 대응해 개발 속도를 높일 수 있다는 말과 같죠.

 

결국 스프링은 '복잡한 기업용 시스템 구축을 쉽고 빠르게 개발할 수 있도록 지원하면서도 일정한 성능과 안전성을 담보해주는 체계'로서 많은 개발자와 기업들이 사용하고 있는 것입니다. 사용 이유에 대해 정리해보자면 다음과 같습니다.

 

스프링 프레임워크(Spring Framework) 사용이유

1. 복잡한 기업용 시스템 구축 가능

2. 쉽고 빠른 개발을 지원해 생산 효율 높임

3. 개발자가 도메인 관련 비즈니스 로직에만 집중할 수 있도록 지원

4. 높은 보안성, 안정성, 확장성 쉽게 확보 가능

5. 스프링 이전에 주로 사용했던 EJB의 객체지향 원칙 파괴를 극복한 순수한 객체지향 프로그래밍 스타일 지원

 

여기서 우리가 가장 눈여겨 봐야할 이유는 완전한 캡슐화와 다형성을 보장하기 위한 '객체지향 프로그래밍의 지원'입니다. 이는 스프링의 특징을 나타내는 가장 주요한 이유입니다.

 

스프링이 무엇인지, 왜 사용하는지 알아보았습니다. 그러나 진짜 자바 개발자를 꿈꾸는 분들이라면 대체 스프링이 기술적으로 어떤 형태의 '체계'이기에 저러한 장점들을 가지는지 알아봐야 합니다.

 

03. How: 스프링 프레임워크(Spring Framework) 특징

스프링의 기술적인 특징은

 

1) POJO(Plain Old Java Object): 오래된 방식의 간단한 자바 객체

2) IoC(Inversion of Control): 제어권 역전

3) DI(Dependency Injection): 의존성 주입

4) AOP(Aspect Oriented Programming): 관점 지향 프로그래밍

5) PSA(Portable Service Abstraction): 일관성 있는 서비스 추상화

 

5가지로 정의할 수 있습니다.  여기서 IoC와 DI는 같은 개념으로 묶입니다. 따라서 POJO, IoC/DI, AOP, PSA가 스프링의 핵심 개념으로 구성됩니다. 일반적으로 스프링 삼각형(Spring Triangle)으로 핵심개념을 표현합니다.

 

 

스프링 삼각형 구조입니다.

 

굳이 핵심 개념을 삼각형으로 표현한 이유는 무엇일까요?

 

여기서 확인할 수 있는 것은 POJO가 다른 핵심 개념에 둘러 싸여있다는 것입니다. 이 부분이 의미가 큰데, 이는 'POJO(오래된 방식의 간단한 자바 객체) 개념이 IoC/DI, AOP, PSA를 통해 달성'된다는 것을 의미합니다. 결국 스프링은 궁극적으로 POJO를 지향하기 위해 다른 핵심 개념을 가지고 온 프레임워크입니다. 

 

다음으로 POJO부터 PSA까지 스프링의 핵심 개념에 대해 알아보겠습니다.

 

01) POJO(Plain Old JAVA Object): 오랜 방식의 순수한 자바 객체 사용

 

POJO는 매우 중한 것

 

POJO 프로그래밍이란 POJO를 이용해서 코드를 작성하는 것을 말합니다. 특정 플랫폼 기술에 종속된 무거운 객체를 만드는 것을 거부하며 나타난 용어가 바로 POJO입니다. Plain Old라는 단어가 조금 이상하게 들릴 수도 있는데, 이는 '특정 기술에 종속되지 않은' 이라는 의미입니다.

 

자바가 객체지향 패러다임을 지원하는 프로그래밍 언어이긴 하지만 자바로 코드를 짰다고 해서 POJO 프로그래밍인 것은 아닙니다. 자바 객체가 특정 기술에 객체가 종속 또는 상속되는 순간 객체지향의 원칙이 깨져버리기 십상입니다. 스프링에서는 객체지향에 작성한 코드가 완전히 부합하는지 늘 주시해야합니다. POJO 프로그래밍의 규칙은 다음과 같습니다.

 

POJO 프로그래밍의 규칙

(1) Java나 Java의 스펙(사양)에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다

(2) 특정 환경에 종속적이지 않아야 한다.

 

이 두 규칙은 특정 기술이나 프레임워크 기술을 상속해서 코드를 작성하지 말아야 한다는 규칙을 나타냅니다. 만약 어플리케이션의 요구사항이 변경되서 다른 기술로 변경하려면 특정 기술의 클래스를 사용했던 부분을 일일이 제거하거나, 수정해야 하는 참사가 발생할 수 있기 때문입니다. 객체끼리 너무 많은 영향을 주고 받는 사례가 발생한 것입니다. 또한 특정 기술의 클래스를 'extends' 키워드로 한번 상속해버리면 상위 클래스를 상속받아 하위 클래스를 확장하는 객체지향 설계기법을 적용하기 어려워집니다.

 

따라서 POJO 프로그래밍을 효과적으로 적용하기 위해서는 특정 기술에 대한 지식보다는 JDK의 API에 대한 지식과 객체지향적인 사고방식과 설계를 위한 훈련이 우선시 되어야 합니다. 위 규칙을 지키는 POJO 프로그래밍을 사용하게 되면 여러 이점이 생깁니다.

 

POJO 프로그래밍의 이점

1. 특정 환경이나 기술에 비종속적이기에 코드 재사용이 가능하고, 확장 가능한 유연한 코드를 작성 가능
2. 저수준 레벨의 기술 및 환경에 종속적인 코드를 애플리케이션 코드에서 제거하여 코드 가독성 높음
3. 높은 코드 가독성으로 디버깅 용이
4. 비종속적인 코드로 인해 코드 테스트 용이
5. ★객체지향 설계 가능

 

여기서 특히 5번째 이점이 중요합니다. 객체지향 설계는 유지보수, 확장, 협업을 쉽게 하는 매우 중요한 이점을 가졌기 때문에 개발자들은 꼭 지켜야 할 원칙입니다.

 

POJO를 정리하겠습니다.

 

POJO(Plain Old Java Object, 오래된 방식의 간단한 자바 객체)는 특정 기술이나 규약에 종속되지 않은 가벼운 자바 객체를 사용해야한다는 원칙으로 높은 코드 가독성과 순수한 객체지향 설계를 가능하게 합니다.

 

02) IoC(Inversion of Control) / DI(Dependency Injection): 제어권 역전, 의존성 주입

IoC(Inversion of Control), 제어권 역전

애플리케이션 개발 흐름의 주도권이 뒤바뀐 것을 IoC(Inversion of Control), 제어권 역전이라고 합니다. 전통적인 프로그래밍에서는 개발자가 작성한 프로그램이 라이브러리(기능 집합)의 코드를 호출해서 이용합니다. 그러나 제어권 역전에서는 외부 코드(프레임워크)가 개발자의 코드를 호출합니다. 즉, 제어권이 프레임워크에 있기 때문에 스프링이 사용자의 코드를 호출하는 것이죠.

 

이 개념은 스프링이 어플리케이션 개발의 전체 틀을 가지고 흐름을 이끌고 가기 때문에 개발자는 스프링이 요구하는 요소만 삽입, 변경을 하면서 흐름에 올라타기만 하는 것으로 이해하면 좋습니다. 

 

그렇다면 우리는 왜 개발자의 권한을 프레임워크에 위임해서 사용하는걸까요? 객체를 직접 제어하지 않고 위임하는 것이 옳은 것인지 의문이 들 수 있습니다. 

 

스프링이 IoC 패러다임을 차용한 이유는 올바른 객체지향 프로그래밍을 구현하기 위함입니다. 객체 지향에서는 각 객체가 자신의 역할과 책임을 가지고 협력하는 관계를 가지고 있으며 유연하게 객체를 수정하거나 변경할 수 있어야합니다. 객체가 높은 객체 내 응집도와 낮은 객체 간 결합도를 가지게 하는 핵심이 IoC입니다.

 

A객체가 B객체에 의존하는 형태를 구현한다면, B가 변경될 때마다 A객체를 수정해야합니다. 이는 객체지향 프로그래밍의 특징인 낮은 결합도를 위배하는 것이죠. 스프링은 이 문제를 해결하기 위해 A와 B의 의존성을 스프링이 직접 관리해줍니다. 

 

스프링은 Application Context로 모든 객체를 일괄관리하는 컨테이너가 되어 객체간 의존관계 주입, 객체 생명 주기 관리 등 꼭 필요하지만 비즈니스 로직에 벗어나는 여러 일을 대신해서 맡아주는 것입니다. 복잡한 기업용 어플리케이션에 쓰이는 수많은 객체를 편리하게 관리해주어 개발자들은 기업이 요구하는 비즈니스 로직 구현에만 집중하는 것이죠. 개발자 분들을 위해 잡다한 일처리를 대신 해주는 실무 직원이 붙은셈입니다.

 

조금 장황하니 IoC를 한 문장으로 정리해보겠습니다.

 

IoC(Inversion of Control) 제어권 역전이란 객체 간의 관계 설정(의존관계), 객체 생명 주기 관리 등을 제3자(프레임워크)가 담당하도록 제어권을 넘겨주어, 객체지향 프로그래밍의 올바른 객체 캡슐화를 구현할수 있도록 하고, 개발자는 비즈니스 로직 구현에 집중할 수 있도록 하는 프로그래밍 패턴을 말합니다.

 

그리고 이 제어권 역전이라는 프로그래밍 패턴을 자바에서 실체화하여 구현한 것이 바로 DI(Dependency Injection) 의존성 주입입니다.

 

DI(Dependency Injection), 의존성 주입

DI(Dependency Injection)는 프로그래밍에서 구성 요소간 의존 관계를 소스코드 내부가 아닌 외부에서 설정을 하여 정의를 하는 방법론입니다. 스프링이 다른 프레임워크와 차별화하여 제공하는 기능 중 가장 주요한 기능이 바로 이 DI라는 방식입니다. DI가 가진 의미를 보겠습니다.

 

Q. 의존성(Dependency)이 무엇인가요?

프로그래밍에서 의존성이 있다는 것은 객체간 참조 관계가 존재함을 의미합니다. A가 B를 참조하는 관계(A→B)라면 B객체의 변경사항이 A객체에 영향을 주게 됩니다. 

 

의존성이 강하게 결합되어 있다는 것은 매우 두려운 일입니다!

 

Q. 주입(Injection)의 의미가 무엇인가요?

주입은 외부로부터 객체의 주소값을 전달 받아 객체를 참조한다는 의미입니다.

객체를 직접 참조하는 것이 아니라 외부로부터 주입받는 관계라는 것이지요.

 

따라서 의존성 주입이란 객체 간 결합을 직접 참조(의존 관계)가 아닌 제 3자, 외부에서(spring container) 주소값을 전달받아 참조하는 패턴을 말합니다. DI에는 보통 3가지 조건이 있습니다.

 

1. 클래스나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 오직 인터페이스에만 의존하고 있어야 한다.
2. 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
3. 의존관계는 사용할 오브젝트에 대한 레퍼런스(주소값)를 외부에서 제공(주입)해줌으로써 만들어진다.

 

이 3가지 조건을 충족한다면 외부의 인터페이스로 객체간 의존성을 관리하기 때문에 코드 간 결합도가 낮아져 객체 내부 코드의 유연성이 늘어납니다. 

 

DI 방식의 핵심은 'DI는 클래스 타입이 고정되어 있지 않고 인터페이스 타입의 파라미터를 이용해 다이나믹하게 구현 클래스를 결정해서 제공받을 수 있어야 한다'는 것입니다.

 

코드 재사용을 높여 소스코드를 다양한 곳에 사용할 수 있고 코드 모듈 간의 결합도를 낮출 수 있습니다. 계층, 서비스 간의 의존성이 존재하는 경우에는 스프링 프레임워크가 서로 연결해줍니다. (매우 편리하죠!)

 

DI도 한번 정리해보죠

 

DI(Dependency Injection)는 '스프링 프레임워크에서 제어권 역전을 구현하기 위해 차용한 프로그래밍 방식으로 객체 간 결합을 직접 참조가 아닌 스프링 컨테이너에서 주소값을 전달받아 참조하는 패턴'으로 정의할 수 있습니다.

 

03) AOP(Aspect Oriented Programming): 관점 지향 프로그래밍

여러 모듈에서 공통적으로 사용하는 트랜잭션, 보안, 로깅과 같은 기능을 핵심 관심사에서 분리하여 관리하는 방법론입니다. 서론에서 스프링은 자바가 지닌 객체지향 프로그래밍의 특성을 완전히 구현하고자 하는 프레임워크라고 하였습니다. 그런데 '관점 지향 프로그래밍'은 또 무엇일까요?

 

결론부터 이야기하자면, 관점지향 프로그래밍은 객체지향 프로그래밍을 구현하기 위해 사용한 개념입니다. 단어의 뜻을 알아보죠.

 

객체지향 프로그래밍을 공부하신 분들은 객체는 SOLID 5원칙을 기억하고 계실겁니다. 

1. SRP(Single Responsibility Principle): 단일책임원칙, 모든 클래스는 하나의 책임만 가지며 클래스는 그 책임을 완전히 캡슐화해야 함

2. OCP(Open-Close Principle): 개방폐쇄 원칙, 확장에 대해서는 개방되고 변경에 대해서는 폐쇄

3. LSP(Liskov Substition Principle): 리스코프 치환 원칙, 상위 타입의 객체를 하위 객체로 치환해도 상위 타입을 정상적으로 사용 가능

4. ISP(Interface segregation principle): 인터페이스 분리 원칙, 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 함

5. DIP(Dependency inversion principle): 상위 모듈은 하위 모듈에 의존해서는 안되며 두 모듈 모두 추상화에 의존

 

여기서 단일책임원칙을 생각해보겠습니다.

 

객체는 하나의 책임을 가지고 있습니다. 쇼핑몰을 예로 든다면 '물건 구매', '물건 판매', '구매 문의' 책임을 나눌 수 있습니다.(물론 실제 구현에서는 훨씬 더 작은 책임으로 나누지만 여기서는 편의상 나누었습니다)

 

위 3가지 객체는 각자 다른 책임을 지녀 서로 다른 비즈니스 로직을 가지고 있지만, 그럼에도 동일한 기능이 필요합니다. 로그, 트랜잭션, 보안에 대한 기능은 모두 공통적으로 보유해야할 기능이죠. 만약 각 객체가 해당 기능을 따로 따로 가진다면 어떻게 될까요? 중복 코드가 늘어나 코드 가독성이 매우 떨어지고, 객체가 무거워지는 결과를 낳게 됩니다.

 

따라서 코드를 기능의 관점으로 분리하여 사용하는 패러다임이 관점지향 프로그래밍입니다. 비즈니스 로직 관점을 핵심 관심사로 분리하고 공통적인 기능을 횡단 관심사로 분리하여 객체지향적 체계를 더욱 강화하는 것이죠. 관점지향 프로그래밍의 사용이유를 정리해보겠습니다.

 

AOP(Aspect Oriented Programming, 관점지향 프로그래밍) 사용이유

1. 코드 간결성, 가독성 높임

2. 코드 재사용성 높임

3. 객체지향 설계 원칙에 맞는 코드 구현

 

따라서 관점지향 프로그래밍의 의미는 

AOP(Aspect Oriented Programming, 관점지향 프로그래밍)은 어플리케이션의 공통 관심사인 로그, 보안, 트랙잭션 등을 횡단 관점으로 객체에서 분리하여 모듈화하여 관리하는 프로그래밍 방법론이며 코드의 간결성과 재사용성을 높이고 객체지향 설계 원칙에 맞는 코드를 구현할 수 있습니다.

 

04) PSA(Portable Service Abstraction): 일관성 있는 서비스 추상화

PSA(Portable Service Abstraction, 일관성 있는 서비스 추상화)이란 개발하고자 하는 어플리케이션의 서비스에 추상화를 적용하는 방법론입니다. 컴퓨터 과학에서 추상화란 본질적인 특성을  남기고 세부사항 또는 불필요한 속성을 제거하는 것을 말합니다. 객체지향 프로그래밍의 가장 주요한 특징 중 하나이며, 자바에서는 객체-인터페이스 상속 관계가 대표적인 추상화의 예로 들 수 있습니다. 추상화에 대한 자세한 내용은 제 객체지향 관련 글을 읽어보시는 것을 추천드립니다. 

 

추상화 모델링의 예

 

 

자동차, 비행기, 자전거는 모두 '교통수단'의 특성으로 묶을 수 있습니다. 이를 자전거, 비행기, 자동차가 교통수단으로 '추상화' 되었다고 합니다. 날개 유무, 운전 가능 유무와 같은 세부적인 사항은 제거한 추상화이죠. 

 

스프링은 위와 같은 방식으로 서비스를 추상화하여 클라이언트가 서버를 이용하기 위한 접근방식을 일관된 방식으로 유지합니다. 서버의 세부사항은 모두 제거하고 서버의 연결을 담당하는 코드만 추상화하여 클라이언트에 제공하는 것이죠. 이는 마치 우리가 컴퓨터와 usb 메모리의 데이터 전송 방법은 모르더라도 커넥터에 맞게 끼우기만 하면 사용할 수 있는 것과 같습니다.  아래의 도식을 보면 서비스가 어떻게 추상화 되는지 쉽게 알 수 있습니다.

 

 

위 도식을 보면 오라클, 마리아DB 등 다양한 DBMS의 커넥터를 하나의 커넥터로 추상화시켜 클라이언트에 연결하였습니다. 이렇게 PSA원칙을 준수하면 클라이언트는 특정 DB에 맞추어 서비스를 요청하지 않아도 될 뿐만 아니라 서비스를 제공하는 인터페이스로 간접적으로 연결되어 느슨한 결합이 이루어집니다. 즉, PSA는 서비스의 기능을 접근하는 방식을 일관되게 유지하면서 기술 자체를 유연하게 사용할 수 있도록 만듭니다.

 

PSA를 정리해보겠습니다. 

 

PSA(Portable Service Abstraction, 일관성 있는 서비스 추상화) 사용이유

1. 클라이언트와 서비스 기술의 느슨한 결합관계 구축

2. 일관된 방식으로 서비스의 기술을 사용 가능

3. 서비스가 보유한 기술을 유연하게 수정, 변경하여 사용 가능

 

PSA(Portable Service Abstraction, 일관성 있는 서비스 추상화)는 추상화 기법을 어플리케이션에 적용하여 서비스와 클라이언트 간 느슨한 결합을 구현합니다. 이는 서비스의 기능에 접근하는 방식을 일관되게 유지하면서 서비스가 보유하는 기술의 수정이나 변경을 유연하게 만듭니다.

 

 

마무리

지금까지 스프링 개념과 특징에 대한 설명이었습니다. 코드 한 줄 없이 설명을 하려니 감이 조금 안잡히실 수도 있을 것 같습니다. 사실 가장 좋은 학습법은 역시 코드를 써보는 것이죠. 앞으로 스프링 사용방법(애너테이션, 프로젝트 생성 등)과 스프링 부트에 대한 글과 실제 코드를 통해 조금 더 알아보도록 하겠습니다.