WEB(34) - 스프링(1) - 수업 66일차

목차

• Spring 수업을 들어가기 전에
  • 목차
  • 기본 용어 설명
• STS란?
• IOC 예제

---

수업에 앞서

Spring에 대해 아주 간단한 소개를 하자면 자바 엔터프라이즈 어플리케이션 개발을 위한 오픈소스 프레임워크입니다.
겨울(J2EE) 뒤에 봄(Spring)이 온다라는 의미에서 이름을 지었다고 하며, 스프링의 핵심 개발자인 유겐할러는 한 인터퓨에서 스프링의 개발 목적에 대해 다음과 같이 말했다고 합니다.

“스프링 프레임워크를 처음 개발할 때부터 변치 않는 설계 철학은 여러분의 개발 환경이 오래된 인프라든 최신 인프라든 구애받지 않고 최신 프로그래밍 사상과 기법을 활용해서 개발할 수 있게 만드는 것이었습니다.”

이전 J2EE를 사용한 시스템 개발에서는 EJB가 가장 대표적인 기술이었다고 하는데, 이 EJB는 정말 훌륭하고 많은 기능들을 제공하지만 정작 실전에서 사용하기에 난이도와 생산성, 성능 등의 문제를 갖고 있었다고 합니다. 또한 보편적인 기술로 자리잡고 난 뒤로는 더욱 더 EJB에 종속적일 수 밖에 없었기에 이에 대한 대안으로 EJB의 장점들은 내포하면서 더 나은 기술, 그리고 가장 중요한 점은 좋은 객체 지향 어플리케이션을 개발할 수 있도록 도와주기 위한 프레임워크로서 스프링을 개발했다고 합니다.

결국 스프링의 핵심은 객체 지향 언어가 가진 강력한 특징을 살려주는 자바 언어 기반의 프레임워크라는 점 입니다.

스프링 수업을 들어가기에 앞서 우선 앞으로 배울 내용들을 목차로 정리해보겠습니다.

Framework 주요목차

• Spring IOC/DI
• Spring AOP
• MyBatis Framework
• SpringMVC(Spring Legacy project)
• Ajax / JSON / REST
• SpringBoot
• Thymeleaf
• SpringSecurity
• Spring Cloud(MSA), RestTemplate, JPA

스프링 프레임워크에 대한 부가 설명 해보자면, 어플리케이션의 기반(infrastructure)을 제공하여 비즈니스 로직에 집중할 수 있도록 해주는 오픈소스 프레임워크입니다.

흔히 POJO(Plain Old Java Object) 기반 프레임워크라고도 하는데, EJB보다 단순하고 평범한 자바 오브젝트를 사용하는 것으로 객체지향적인 특징을 살려내기 위한 기술입니다.

스프링의 다른 특성으로는 Lightweight Container, IOC / DI, AOP, PSA 등이 있는데, 이에 대한 설명은 기본적인 개념 정리를 한 뒤 차차 풀어가도록 하겠습니다.

---

개념정리

스프링 프레임워크에서 빼놓을 수 없는 개념 중 하나가 응집도와 결합도입니다.

높은 응집도(high cohesion), 낮은 결합도(loose coupling)
“모듈 간의 결합도는 최소화하고 모듈 내 요소들 간의 응집도를 최대화한다”

자바를 배웠을 때와 마찬가지로 스프링 프레임워크에서도 높은 응징도와 낮은 결합도를 지향하고 있습니다.

(응집도란 자신의 역할에 집중하는 정도를 뜻하며, 모듈 내의 기능 수행을 위해 요소 간에 얼마만큼 연관된 책임이 집중되어 있는 지를 나타냅니다.)

(결합도란 모듈 간의 상호 의존 정도를 뜻합니다.)

---

그 외 용어 설명

용어	설명
객체지향(Object-Oriented)	시스템 분석 설계 기법 중의 하나
Class	Object의 설계도
Object	속성과 기능으로 구성, 시스템의 기본 단위
package	클래스들을 분류
library	라이브러리, 재사용 가능한 프로그램들의 모음(jar: 자바 프로그램 압축 파일 확장자)
component	프로그램이 실행될 때 하나의 독립적 기능 단위를 이루어 부품화되는 것
API	Application Programming Interface의 약자. 응용프로그램을 개발하기 위해 제공하는 인터페이스
Framework(자바에서의 프레임워크)	java 어플리케이션 설계, 구현, 테스트, 운영(유지보수) 등에 전반에 대한 기반(infrastructure)을 제공 다양한 컴포넌트(or 라이브러리)를 제공하고 디자인 패턴을 지원 프레임워크는 반완전한 어플리케이션이다(개발자는 비즈니스 로직에 집중하도록 하는 것이 목적) IOC/DI, AOP, MVC, Security, SpringBoot를 지원하고 Mybatis, JUnit 등과 같은 오픈 소스 프레임워크와의 통합을 지원한다

---

스프링 프레임워크에서의 핵심 개념

용어	설명
IOC	Inversion Of Control, 제어의 반전(역행), 역제어 컴포넌트를 구성하는 인스턴스 생성과 의존 관계 연결처리를 IOC 컨테이너에 이임
DI	Dependency Injection, 의존성 주입 필요로 하는 의존대상(컴포넌트 or 객체 or bean)을 injection(주입)을 통해 확보한다
DL	Dependency Lookup, 의존성 검색 필요로 하는 의존대상(컴포넌트 or 객체 or bean)을 lookup(검색)을 통해 확보한다

IOC, DI, DL의 목적: Loose Coupling(느슨한 결합도)

이 외에도 Spring IOC Container는 Singleton 방식으로 객체를 운용합니다. (Singleton Design Pattern: 시스템 상에서 단 하나의 객체를 생성하고 공유해 사용하기 위한 디자인 패턴)

---

STS를 활용하여 스프링 프로젝트 생성하는 방법을 살펴보겠습니다.

STS란?

: Spring Tool Suite, 스프링 툴 스위트(STS)는 스프링 기반 애플리케이션 개발을 위해 최적화된 이클립스 기반 통합 개발 환경을 제공합니다. Maven , Git , AspectJ 등과 같은 툴이 기본적으로 내장되어 있습니다.

STS 설치는 크게 두 가지 방법으로 진행하며 수업에서는 두 번째 방식으로 진행합니다.

1. 자체 설치
2. eclipse에서 marketplace sts 검색한 뒤 Spring Tools 4 설치 후 Spring Tools 3 Add-on (레거시)을 추가 설치합니다.

스프링 라이브러리 확보 방법은 의존하는 라이브러리들을 관리하는 도구를 사용하는 방법과 직접 추가하는 방법이 있습니다.

최근 실무에서는 gradle이 가장 많이 사용되지만, 수업에서는 maven을 사용하는 방법과 직접 추가하는 방법을 배워볼 예정입니다.

우선 직접 jar 파일들을 받은 후 build path에 추가해보도록 하겠습니다.

위와 같이 필요한 라이브러리 jar 파일들을 받은 후 Build Path - Add to Build Path를 눌러 라이브러리를 추가할 수 있습니다.

---

예제

스프링 프레임워크의 핵심 개념 중 하나인 IOC에 대해 알아보기 위해 간단한 예제 풀이를 진행하겠습니다.

우선 model 패키지에 다음과 같이 Tool이라는 인터페이스, 그리고 이 인터페이스를 구현하는 Hammer, Spade 클래스들을 만들겠습니다.

Tool

package model;

public interface Tool {
    public void work();
}

Hammer

package model;

public class Hammer implements Tool{
    public void work() {
        System.out.println("망치 도구로 일하다");
    }
}

Spade

package model;

public class Spade implements Tool{
    public void work() {
        System.out.println("삽 도구로 일하다");
    }
}

그리고 자바 프로젝트에서 /src 디렉토리 아래에 Spring Bean Configuration File로 ioc.xml 생성합니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="tool" class="model.Spade"></bean>
</beans>

위와 같이 작성하는데, <beans> 태그 안에 저희에게 필요한 클래스들을 <bean> 태그로 생성해서 어플리케이션에서 해당 bean(객체)를 요청하면 IOC 컨테이너가 반환해주는 방식입니다.

<bean> 태그를 조금 더 자세히 살펴보면 class에 명시된 model 패키지의 Spade라는 클래스의 인스턴스를 생성하려고 하는데, 이 인스턴스를 tool이라는 아이디 값으로 다루겠다는 뜻 입니다.

이렇게 작성하는 이유는 IOC Container가 시스템 시작 시 ClassPathXmlApplicationContext를 이용해 스프링 설정 파일(ioc.xml)을 로딩하기 때문입니다.(보다 자세한 설명은 아래 예제를 모두 진행한 뒤 이전에 사용하던 제어방식과 비교하여 설명드리도록 하겠습니다)

package test;

import org.springframework.context.support.ClassPathXmlApplicationContext;

import model.Tool;
public class TestUser2_IOC {
    public static void main(String[] args) {
        ClassPathXmlApplicationContext factory = new ClassPathXmlApplicationContext("ioc.xml");
        Tool tool = (Tool) factory.getBean("tool");
        System.out.println(tool);
        System.out.println(factory.getBean("tool")); // 동일한 객체의 주소값이 출력
        System.out.println(factory.getBean("tool")); // spring ioc container는 singleton 방식으로 객체를 운용한다
        tool.work();
        factory.close();        
    }
}

ClassPathXmlApplicationContext 클래스는 ClassPath에 위치한 xml 파일을 읽어 설정 정보를 로딩, root로부터 경로를 지정하기 위해 사용됩니다. 저희는 ioc.xml 위치를 지정해서 해당 xml 파일에 생성한 bean 객체를 사용합니다.

bean 객체를 사용하기 위해선 해당 인스턴스를 담을 인터페이스(예제에서는 tool 인스턴스에 할당)와 앞에 만든 factory를 사용해서 getBean()메서드로 ioc.xml에서 생성했던 tool이라는 id를 가진 bean 객체를 가져올 수 있게 됩니다.

그리고 이렇게 할당한 tool 인스턴스는 여러 번 호출하더라도 동일한 주소값이 출력되는데, Spring IOC Container가 singleton 방식으로 객체를 운용하기 때문입니다.

그리고 아래의 출력 결과는 웹 컨테이너의 동작 방식과 비슷한 모습을 보여줍니다.

위의 출력 결과를 보면 이전과 크게 다를 게 없어 보이는데 왜 굳이 IOC라는 개념을 도입해 객체를 운용하는 걸까요?

이유는 유지보수에 있습니다.

기존의 제어방식은 사용자가 망치(컴포넌트)를 사용하기 위해 Hammer 인스턴스를 생성하고 work 메서드를 호출하게 됩니다. 만약 도구(컴포넌트)를 삽(Spade)으로 변경할 경우 객체 생성부를 수정해 new Spade()와 같이 생성자를 명시해야 하겠죠.(만약 추상화나 계층 구조화 혹은 캡슐화가 되어있지 않다면 메서드 호출부 또한 변경해야 합니다)

이렇듯 기존의 방식은 컴포넌트가 변경될 경우 코드의 수정이 불가피합니다. 사용자 측과 컴포넌트 측의 결합도가 높다고 할 수 있겠죠.

그런데 이번에 배운 IOC 방식을 도입한다면, ClassPathXmlApplicationContext를 이용해 스프링 설정 파일(ioc.xml)을 시스템 시작 시에 로딩해서 필요한 객체를 생성해 저장한 뒤 어플리케이션에서 해당 객체(bean)를 요청하면 IOC 컨테이너가 해당 객체를 반환해주게 됩니다.

컴포넌트를 변경하고자 하면 ioc.xml에 생성한 bean 객체의 정보만 수정하면 되기에 사용자 측과 컴포넌트 간의 결합도가 낮아지게 되는 것이지요.
규모가 커질수록 유지보수와 단위 테스트에 용이하며 곧 배울 AOP 적용을 통한 공통 기능 처리에 기반이 됩니다.

---

이번 복습은 이것으로 마치도록 하겠습니다.

드디어 스프링 수업에 들어섰는데, 기존의 구조와는 다소 다른 부분이 있어서 낯설게 느껴지기도 합니다.
그렇지만 규모가 커질수록 이러한 구조의 효용성이 상당할 것이란 생각에 앞으로의 수업이 더욱 기대가 되네요.

다음 수업에서는 Maven을 활용한 DI 연습을 해보도록 하겠습니다.

---

맨 위로 이동하기

Java Web Programming 카테고리 내 다른 글 보러가기

공유하기

Twitter Facebook LinkedIn