Transcript 스프링이란 무엇인가?
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: 전략 패턴 사용 용이 – AB 의존관계 고려 – 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: 인터페이스의 변경 – 원래: AB 인터페이스 – 원하는 변경: 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