스프링이란 무엇인가?

Report
Chapter 8.
스프링이란 무엇인가?
Sep. 2014
Youn-Hee Han
http://link.koreatech.ac.kr
8.1 스프링의 정의
2
8.1 스프링의 정의
 일반적인 스프링의 정의
– 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플
리케이션 프레임워크
– 스프링의 기원
• 로드 존슨(Rod Jhonson)이라는 유명 J2EE 개발자가 출간한 “Expert One-onOne J2EE Design and Development”이라는 제목의 책에 소개된 예제 샘플
 정의 내 단어 1 - 애플리케이션 프레임워크
– 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진
행하는데 일차적인 목표
– 애플리케이션 전 영역을 관통하는 일관된 프로그래밍 모델과 핵
심 기술 제공
2
8.1 스프링의 정의
 정의 내 단어 2 – 경량급
– 불필요하게 무겁지 않다는 뜻
– 예전의 무거운 EJB (Enterprise JavaBeans)의 과도한 엔지니어링
기술에 비해 가벼운 스프링을 설명하는 단어
– 코드는 더 단순하고 개발과정은 더 편리해짐
– EJB에서 불편했던 고급 기능을 세련된 방식으로 적용가능
– 스프링으로 만들어진 코드는 EJB기반으로 만들어진 코드와 기술
수준은 비슷하면서도 생산성과 품질면에서는 더 유리함
2
8.1 스프링의 정의
 정의 내 단어 3 – 자바 앤터프라이즈 개발을 편하게
– 근본적으로 앤터프라이즈 개발의 복잡함을 제거하고 편하게 개발
할 수 있는 해결책 제공
– EJB 1.0 스펙에서 제시된 EJB 목표와 비슷
– 스프링은 위와 같은 EJB가 궁극적으로 이루려고 했던 목적을 제
대로 실현해주는 프레임워크
2
8.1 스프링의 정의
 정의 내 단어 4 – 오픈소스
– 소스가 모두에게 공개되고 특별한 라이선스를 취득할 필요없이
자유롭게 이용가능
– 스프링에 적용된 오픈소스 라이선스
• Apache License Ver. 2.0
• 상업적인 제품에 포함하거나 비공개 프로젝트에 자유롭게 이용가능
• 다만 스프링을 이용하고 있으며, 원 저작자에 대한 정보는 포함해야
하는 의무사항 존재
• 필요하다면 기존 소스를 수정하여 사용가능하며 수정된 내용에 대한
공개 의무는 없음
– 온라인 커뮤니티
• 의견 공유, 버그 신고, 기능 추가 요청, 피드백 등
– 공식적인 개발자 및 업체
• 초기부터 공식적인 개발자 그룹 존재해왔음
• SpringSource 업체에서 코드 개발 주관해옴
• 2009년 SpringSource는 VMWare 업체에 합병됨
 더욱 안정된 환경과 조직에서 스프링 소스를 개발하고 있음
2
8.2 스프링의 목적
7
8.2.1 앤터프라이즈 개발의 복잡함
 앤터프라이즈 개발의 복잡함
2
8.2.1 앤터프라이즈 개발의 복잡함
 앤터프라이즈 시스템이 복잡한 이유
– 1. 엔터프라이즈 IT에 대한 기술적인 제약조건과 요구사항 증가
•
•
•
•
•
서버의 자원을 효율적으로 공유 및 배분해야 하는 요구
보안, 안정성, 확장성 요구
웹과의 연동 요구
위와 같은 요구사항은 계속하여 증가하고 있음
새로운 기술의 지속적인 등장
– 2. 비즈니스 로직의 복잡함 증가
• 여러 조직의 업무를 처리하기 위한 핵심 비즈니스 로직 복잡
• 기존 전통적인 기업 업무 처리에 대한 엔터프라이즈 시스템 의존도
가 지속적으로 높아지고 있음
• 매우 많은 예외사항
• 비즈니스 로직의 잦은 변경
2
8.2.1 앤터프라이즈 개발의 복잡함
 앤터프라이즈 시스템이 복잡한 이유
– 3. 엔터프라이즈 IT 기술과 비즈니스 로직의 복잡함이 함께 얽혀
있음
• 개발자가 동시에 두 가지를 모두 신경 써서 개발해야 하는 과도한 부담
2
8.2.2 복잡함을 해결하려는 도전
 제거될 수 없는 근본적인 복잡함
– 엔터프라이즈 개발은 현실적으로 매우 복잡함
• 기술적인 복잡함을 해결하고자 보안을 취약하게 할 수 없음
– 근본적으로 앤터프라이즈 개발에 나타나는 복잡함의 원인은 제
거 대상이 아니라 그것을 효과적으로 상대할 수 있는 전략과 기
법이 중요
• 비즈니스 로직의 복잡함
• 기술적인 복잡함
• 위 두 가지 복잡함을 분리하여 처리하는 것이 효율을 높이는 첫걸음
 실패한 해결책: EJB (Enterprise Java Beans)
– EJB의 실패 원인
• EJB의 침투적 (Invasive)인 성격
 반드시 코드는 EJB라는 기술과 관련된 코드, 규약, 환경 및 스펙에 종속
됨
• 기술적인 복잡함을 덜어주려다가 오리혀 더 큰 복잡함을 추가하는
11
실수를 범함
8.2.2 복잡함을 해결하려는 도전
 효과적인 해결책: 스프링
– 비침투적인 방식 활용
• 기술의 적용 사실이 코드에 직접적으로 반영되는 것을 최소화함
 스프링 기술의 적용에 따라 필요한 작업은 요구되지만, 애플리케이션
코드 이곳 저곳에 불쑥 등장하거나 코드의 설계와 구현 방식을 제한하
지 않는다.
– 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분
리 가능
• 성격이 다른 복잡함이 서로서로 분리가 잘 되어짐
– 개발의 효율성을 극대화하는 방향으로 발전됨
12
8.2.3 복잡함을 상대하는 스프링의 전략
 기술적 복잡함을 상대하는 전략
– 문제 1. 기술에 대한 접근 방식에 일관성이 없고 개발 코드가 특
정 환경에 종속됨
• 변화하는 동적 환경
 서버의 교체, API 사용 방법의 변화
• 일관성이 없는 기술의 난립
 호환이 안되는 표준, 오픈 소스의 난립 등
– 문제 1에 대한 해결 전략
• 인터페이스 활용을 통한 서비스 추상화
 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리, 이
용하는 측에서는 인터페이스를 통해 접근
• 불필요한 예외를 잡아야 하거나 throw선언을 최대한 방지
• 템플리/콜백 패턴을 통해 반복적인 작업 코드 제거
 개발자는 핵심 로직에 집중 가능
13
8.2.3 복잡함을 상대하는 스프링의 전략
 기술적 복잡함을 상대하는 전략
– 문제 2. 기술적 처리 담당 코드가 비즈니스 로직 처리 코드에 섞
여서 등장
• 비즈니스 로직 전후의 트랜잭션 경계설정 코드 등장
• 비즈니스 로직에 보안 적용 코드 등장
• 계층 사이에 주고 받는 데이터 변환 문제
– 문제 2에 대한 해결 전략
• AOP
 비즈니스 로직 담당 코드로 부터 기술 관련 코드를 완벽하게 분리할 수
있는 기술
 코드의 복잡함이 비즈니스 로직의 복잡함 이상으로 불필요하게 증대됨
을 방지해줌
14
8.2.3 복잡함을 상대하는 스프링의 전략
 비즈니스 로직의 복잡함을 상대하는 전략
– 복잡함의 정도 차이
• 비즈니스 로직 ≫ 기술적 로직
 비즈니스 로직이 훨씬 복잡하고 더욱더 복잡해지고 있음
 업무 정책과 흐름의 복잡도 증가
– 치명적 손실/위험 정도의 차이
• 비즈니스 로직 ≫ 기술적 로직
 비즈니스 로직 핵심 코드에 오류가 있다면 시스템을 사용하는 업무 자
체에 매우 큰 지장을 주거나 치명적 손실 발생
» 예. 1) 증권사 사이트에서 주식거래 완료를 했는데도 체결이 안되어 있음. 2)
은행 계좌 잔고가 이유도 없이 줄어듬  회사 문 닫을 수도 있음
15
8.2.3 복잡함을 상대하는 스프링의 전략
 비즈니스 로직의 복잡함을 상대하는 전략
– DB에서 비즈니스 로직 처리 방법의 변화
• 이전 방식
 비즈니스 로직이 잘 반영되도록 SQL을 잘 작성함
 저장 프로시저 (Stored Procedure)에서 핵심 로직 처리
• 최근에 깨달은 교훈
 DB에 비즈니스 로직을 두는 것은 유지보수가 매우 불편함
 테스트가 매우 힘듦
• 최근 추세
 DB는 단지 영구적인 저장과 복잡한 조건을 가진 검색 정도의 기능으로
한정
 데이터를 가공하고 분석하고 처리하는 로직은 가능하면 객체 지향
애플리케이션 서버에 둠
 비즈니스 로직의 복잡함을 상대하는 전략은 자바의 객체지향 기술
그 자체
» 스프링은 자바의 객체 지향 방식을 최대한 활용하도록 은밀히 도와줌
16
8.2.3 복잡함을 상대하는 스프링의 전략
 핵심 도구: 객체지향과 DI
– 스프링의 모토
• “기본으로 돌아가자”
• 기본적인 객체지향에 충실한 설계가 가능하도록 도와줌
– DI를 기본으로 둔 기술
• 서비스 추상화, 템플릿/콜백, AOP 등 스프링의 중요 기술
• 인터페이스로 분리하고 구체적인 클래스의 객체는 동적으로 의존관
계를 만듦
– DI의 역할
• 자연스럽게 객체지향적인 설계와 개발로 이끌어줌
• DI를 의식하면서 설계할 때 고려하는 것들
 DI를 적용할 후보가 더 없나?
 변경되는 것은 어떤 것일까?
 성격이 다른 기능은 무엇일까?
17
8.2.3 복잡함을 상대하는 스프링의 전략
 핵심 도구: 객체지향과 DI
– 객체 지향 설계의 중요성
• 비즈니스 로직 자체의 복잡함을 해결하려면 DI 보다는 객체지향 설
계 기법이 더 중요
• 객체 지향 설계 기법
 상속, 다형성, 위임등을 포함한 다양한 디자인 패턴 및 설계 기법
– 스프링은 객체 지향 설계 및 코딩을 단지 거들 뿐임
– 복잡한 엔터프라즈 시스템 개발을 잘 하는 방법
• 객체 지향 설계 기법에 익숙해져야 함
• 스프링만 잘 공부하는 것으로는 부족함
18
8.3 POJO 프로그래밍
19
8.3.1 스프링의 핵심: POJO
 “스프링의 정수(Essence)는
앤터프라이즈 서비스 기능을
POJO에 제공하는 것“
– 앤터프라이즈 서비스 기능
• 트랜잭션 및 보안 기능 등
– 위 말을 뒤집어 생각하면
앤터프라이즈 서비스 기능과
POJO라는 비즈니스 로직을
담은 코드가 잘 분리했다는 것을 의미
 스프링의 가장 강력한 특징 및 목표
– 분리되었지만 반드시 필요한 앤터프라이즈 서비스 기술을 POJO
방식으로 개발된 비즈니스 핵심 로직을 담은 코드에 제공함
20
8.3.1 스프링의 핵심: POJO
 스프링의 핵심 개념을 설명하기 위해 만든 유명한 그림
– 애플리케이션을 POJO로 개발할 수 있도록 하는 가능기술
(Enabling Technology)
• IoC/DI
• AOP
• PSA (Portable Service Abstraction)
21
8.3.2 POJO란 무엇인가?
 POJO (Plain Old Java Objects)의 단어 유래
– Martin Fowler가 2000년도에 컨퍼런스 발표를 위해 만든 용어
– 발표 내용의 핵심
• EJB는 너무 복잡하고 제한이 많은 기술임을 설명
– 그럼에도, 많은 개발자가 자바의 단순한 객체만을 사용하는 것
을 꺼리는 이유를 생각함
– 그 이유 중 하나가 EJB와 같은 멋진 이름이 없었기 때문이라고
생각
• “POJO 방식의 기술을 사용합니다.” ≫ “간단한 자바 객체를 사용합
니다.“
 위 발표 이후…
– POJO를 지원하는 것을 장점으로 내세우는 많은 프레임워크와
기술이 쏟아져 나옴
– 심지어 EJB 3.0 조차 기존의 문제점을 반성하고 POJO를 적극
도입하기 시작함
22
8.3.3 POJO의 조건
 POJO의 조건
– 특정 규약(Contract)에 종속되지 않는다.
• 개발자는 자유로운 객체지향 설계에 방해를 받으면 안됨
• 반대 예
 스트럿츠 1에서 빈은 특정 클래스를 상속해서 만들어야 함
– 특정 환경에 종속되지 않는다.
• 반대 예
 EJB 3에서 빈은 반드시 JNDI 기술을 통해서 가져와야 함
 WebLogic 서버에서만 사용가능한 API를 사용하는 빈
 웹 환경에 의존적인 빈
» 비즈니스 로직 처리 빈이 HttpServletRequest 객체를 직접적으로 이용하는
경우
• 애노테이션 사용하는 빈
 해당 애노테이션이 특정 환경에만 적용된다면 부적합
– 재사용성이 높아야 한다.
• 반대 예
 책임과 역할이 다른 코드를 모두 가지고 있는 덩치 큰 빈
23
8.3.4 POJO의 장점
 POJO의 장점
– 깔끔한 코드 생산
– 자동화 테스트에 유리
– 객체지향 설계를 자유롭게 적용가능
 로드 존슨 (스프링 창시자)
– “자바 언어의 객체지향적인 설계와 구현 방식이야 말로 그 어떤
새로운 기술, 환경, 도구보다 더 실제 프로젝트를 성공시키는 데
중요한 요소”
24
8.3.5 POJO 프레임워크
 POJO 프레임워크
– POJO를 이용한 프로그래밍이 가능하도록 기술적인 기반을 제공
하는 프레임워크
– 대표적인 POJO 프레임워크
• 스프링: 앤터프라이즈 애플리케이션 개발의 모든 영역에 POJO 방식
구현을 가능하도록 함
 개발자들이 객체지향적인 설계와 원리에 집중할 수 있도록 도와줌
• 하이버네이트: DB 이용 기술에 POJO를 적용함
25
8.4 스프링 기술
26
8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
 IoC/DI
– 스프링의 핵심 기본 기술, 스프링의 핵심 개발 원칙
• 두 개의 객체를 분리해서 개발
• 그 두 개의 객체 사이에 인터페이스를 두고 느슨하게 연결
• 실제 사용할 대상은 DI를 통해 외부에서 지정받음
– 다른 두 가지 기본 기술인 AOP와 PSA도 IoC/DI에 기반을 둠
– 3대 기술은 아니지만 템플리/콜백도 IoC/DI에 기반을 둠
 IoC/DI 사용 이유?
– “개방 폐쇄 원칙 (OCP)를 지키며 어플리케이션의 유연한 확장을
위하여…“
• 폐쇄 관점에서 볼 때 재사용성도 높아짐
27
8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
 IoC/DI의 역할 1: 전략 패턴 사용 용이
– AB 의존관계 고려
– B관점에서는 유연한 확장이 자유로움
• 전략 패턴 사용
 B의 구현 방식을 필요에 따라 B1, B2, B3로 변경
– A관점에서는 자유롭게 확장된 B를 자유롭게 재사용할 수 있음
• 즉, 의존 대상이 B1, B2, B3로 변경되어도 A는 그대로 사용
– 활용 예
• 사용자 관리 서비스를 구현한 B1에서 사용자 등급을 변경하는 정책이 변경
되면 새롭게 B2를 구현하고 DI를 통해서 A에게 새로운 사용자 관리 서비스
를 넘겨줌
28
8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
 IoC/DI의 역할 2: 부가기능 추가 방법 용이
– 데코레이션 패턴 적용이 쉬워짐
– 활용 예
• 트랜잭션 기능 부여
• 클라이언트와 타겟 객체 코드에는 전혀 영향 없음
 IoC/DI의 역할 3: 인터페이스의 변경
– 원래: AB 인터페이스
– 원하는 변경: A  C 객체
• C는 B 인터페이스를 구현하지 않음
– 방법: 어댑터 객체 D 생성
• B 인터페이스를 구현하면서 내부적으로 C 객체를 호출하는 객체
– 결과: A  B (D 객체)  C
29
8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
 IoC/DI의 역할 4: 프록시
– 지연된 로딩 (Lazy Loading) 적용
– Remoting (원격 객체 호출) 구현에 활용
 IoC/DI의 역할 5: 템플릿과 콜백
– 템플릿
• 반복적으로 등장하지만 항상 고정적인 작업 흐름을 담당
– 콜백
• 자주 변경되는 부분
– 템플릿 호출시에 콜백 객체를 DI 하여 사용함
– 스프링은 20여가지의 전형적인 템플릿/콜백 적용 기술 제공
• 전형적인 DI가 사용되지 않는 경우도 많음
30
8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
 IoC/DI의 역할 6: 싱글톤과 객체 스코프
– 스프링의 DI 컨테이너
• 빈 객체의 생성, 관계설정, 이용, 소멸 담당
• 객체의 스코프 제어
– 기본 객체 스코프을 싱글톤으로 보장해줌
• 즉, 프로그래머가 특별하게 신경쓰지 않고 객체를 생성하여도 엔터
프라이즈 용으로 활용 가능함
– 싱글톤이 아닌 다른 스코프가 필요해도 쉽게 구성가능
• Prototype 스코프
• Request 스코프
• Session 스코프
 IoC/DI의 역할 7: 테스트
– 목 오브젝트 생성 및 주입
• 수정자 메소드를 직접 호출하는 수동 DI를 사용가능
31
8.4.2 애스팩트 지향 프로그래밍 (AOP)
 AOP 특성
– OOP와 AOP는 서로 배타적인 것이 아님
– AOP는 OOP의 기술적인 한계를 극복해주는 보조적인 프로그래
밍 기술
• OOP를 더욱 OOP 답게 코딩 가능하게 해 줌
• POJO 만으로 앤터프라이즈급 어플리케이션 개발의 핵심 역할 수행
 AOP 적용 기법
– 1. 다이내믹 프록시 사용
• 스프링에서 주로 활용하는 방식
 메소드 호출에 대해 부가기능 추가
• 앤터프라이급 개발에서 필요한 대부분의 AOP는 다이내믹 프록시
방법으로 충분
– 2. AspejctJ 사용
• 고급 AOP 적용시 활용
32
8.4.2 애스팩트 지향 프로그래밍 (AOP)
 AOP 적용 단계
– 1단계: 미리 준비된 AOP 이용
• 트랜잭션 처리 - 대표적 AOP 기술
 @Transactional 애노테이션 사용
• 도메인 객체에 DI를 자동 적용하는 기술
 @Configurable 애노테이션 사용
 AspectJ 사용 필요
– 2단계: 전담팀을 통한 정책 AOP 적용
• 예 1. 전체 객체 및 서비스에 대한 보안, 로깅, 데이터 추적 (트레이
싱), 실시간 성능 모니터링 같은 정책적 기능 구현에 적용
• 예 2. 개발 가이드라인이나 표준을 따라서 코딩이 되고 있는지를 검
증하는 작업
 JSP 뷰에서 DAO의 직접 이용등을 검출할 수 있음
– 3단계: AOP의 자유로운 이용
• 개발자 스스로가 AOP를 활용하여 특정 기능을 AOP 기능으로 분리
• 주의: 다른 팀이나 개발자가 만드는 곳에 몰래 적용하면 안됨
33
8.4.3 포터블 서비스 추상화 (PSA)
 PSA (Portable Service Abstraction)
– 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에
접근하게 해주는 기술
– 스프링은 엔터프라이즈 개발에 사용되는 다양한 기술에 대해
PSA를 제공함
• PlatformTransactionManager: 트랜잭션 서비스 추상화 인터페이스
• org.springframework.mail.javamail 패키지
• OXM (Object-XML Mapping) 기능
– PSA를 실현하기 위해 필요한 기술  IoC/DI
34

similar documents