스프링이란 무엇인가

자바, 스프링 개발자들의 종착역이자, 주기적으로 다시 돌아오는 그곳, <토비의 스프링 3.1>을 드디어 읽는다.

한창 개발 걸음마를 막 떼고 스프링으로 아장아장 기어다니며 CRUD를 할 때즈음, 토비의 스프링을 찬양하고 있는 많은 개발자들을 보았고, 역시 지식이 깊어지려면, 책을 통해서 지식을 정리하고 깊이를 다지는 시간이 필요하겠구나, 생각했다. 하지만, 개발을 이제 막 배운 그때의 나에게 토비 책은 너무나도 무시무시했고, 토비책을 읽다가 개발을 포기한 사람들의 증언도 여럿 읽고 나니, 이 책은 개발자로서 레베루업이 필요할 때즈음, 다시 꺼내봐야겠다고 생각했다.

그리고 지금이다. 퇴사 후, 이직을 준비하는 동안, 지식의 깊이를 좀 더 다져놓고 싶다는 생각이 들었고, 집앞 도서관에서 (아무도 빌려가지 않는) 토비님의 책을 빌려서 읽기 시작했다. 처음에는 가볍게 읽기 시작했지만, 읽을 수록 인사이트가 쌓여, 기록하면서 제대로 읽고 싶어졌다. 그래서 나의 세컨 브레인인 이곳 블로그에 짧은 글들로 그 내용을 적어보며, 토비님으로부터 얻은 인사이트를 내것으로 만들어보고자 한다.

1. 정의

스프링은 자바 엔터프라이즈 개발을 효율적으로 만들 수 있도록 도와주는 오픈소스 경량급 어플리케이션 프레임워크이다.

어플리케이션 프레임워크

  • 스프링을 처음 만든 것은 로드 존슨이라는 유명한 자바 개발자이다.

  • 원해는 2003년에 자바 엔터프라이즈 개발에 관한 J2EE 어플리케이션 설계와 개발의 모든 영역에 대한 개발 전략을 다룬 책을 냈었는데, 책 내부에서 "항상 프레임워크 기반으로 접근하라"는 원칙에 따라 모든 예제에 대하여 프레임워크를 먼저 만들고 나서, 프레임워크를 이용하는 코드를 만드는 방식으로 작성되었다고 한다.

  • 이 책은 많은 개발자들에게 사랑받았고, 책의 예제 코드로만 쓰기에는 코드가 너무 좋고 아깝다는 의견에 따라 본격적으로 오픈소스 프로젝트로 구성하게 되었다.

  • 책에서 자바 엔터프라이즈 개발의 전 계층에 등장하는 기술과 어플리케이션 전 영역에 대한 효과적인 설계와 개발 기법을 다루고 있었기 때문에 예제 코드도 어플리케이션 개발의 전반을 다루고 있었고, 그 때문에 스프링 프로젝트도 어플리케이션 전 영역을 다루게 되었다.

  • 스프링이 특히나 "어플리케이션 프레임워크"라고 불리는 이유는 여러 계층의 다양한 기술을 한 군데 모아놓았기 때문은 아니다. 그보다는 어플리케이션 전 영역에 걸쳐서 일관된 형식의 프로그래밍 모델을 제시했고, 핵심 기술을 바탕으로 각 분야의 특성에 맞게 필요를 채워주고 있기 때문이다.

  • 스프링의 존재 목적은 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 전 계층과 전 영역에 전략과 기능을 제공해줌으로써 어플리케이션 개발을 편리하게 해주는 "어플리케이션 프레임워크"로 사용되는 것이다.

    • MVC 프레임워크, JDBC/ORM 지원 프레임워크 : 스프링이 다루는 일부 영역만 본 것

    • IoC/DI 프레임워크, AOP 툴 : 스프링이 제공하는 핵심 기술에만 주목

경량급

  • 경량급이라는 말은 스프링 등장 이전의 EJB 기술과 비교하여 붙은 수식어이다.

  • 결코 기술이 가볍다거나 유치하고 용도가 제한적이라는 부정적인 의미가 아니라 좋은 성능을 가지고 뛰어난 기능을 수행함에도 불구하고 이전의 EJB 기술과 비교하여 불필요한 코드가 없이 가볍다는 것이다.

  • EJB

    • 전체적으로 무겁고 복잡한 구조 : 개발환경, 운용서버, 개발과 빌드, 테스트 과정, 작성된 코드 등

    • 기술에 대한 과도한 욕심

    • 반드시 비싸고 무거운 WAS 를 구축해야만 어플리케이션 동작이 가능함

    • 툴의 도움을 받아야만 할 수 있는 설정들, 까다로운 패키징, 불편한 서버배치 등 어렵고 복잡하고 무거웠음

  • Spring

    • 가장 단순한 서버환경인 톰캣이나 제티에서도 완벽 동작

    • 단순한 개발툴과 기본적인 개발 환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 어플리케이션 개발이 가능함

    • 서블릿 컨테이너만으로도 충분하니 복잡하고 무거운 WAS 구성하고 유지할 필요가 없음

    • EJB 나 다른 프레임워크에서 제공하는 기능들은 다 갖추고 있음에도 불구하고 프레임워크나 서버환경에 의존적인 반복적인 코드를 제거하여 코드 줄 수도 적도 훨씬 가볍다.

자바 엔터프라이즈 개발을 편하게

  • "어플리케이션 개발을 편하게 해준다"는 말을 쓰려면, 개발자가 복잡하고 실수하기 쉬운 로우 레벨 기술에 많은 신경을 쓰지 않아도 되어 어플리케이션의 핵심인 사용자의 요구사항, 비즈니스 로직에만 집중할 수 있어서 빠르고 효과적으로 구현할 수 있는 상태를 말한다.

  • 스프링 이전에도 EJB 를 포함하여 많은 자바 프레임워크들이 이러한 가치를 내걸었지만, 엔터프라이즈 개발의 고민거리와 부담을 덜어주는 대신, 다른 차원의 더 큰 복잡함을 어플리케이션 개발에 끌고 들어와 결국 개발자들이 많은 불편을 느끼고 지치게 만들었다.

  • 하지만 스프링은 달랐다. 엔터프라이즈 개발에서 필수적으로 요구되는 기술적 요구를 충족하면서도 어플리케이션 개발을 복잡하게 만들지 않았다는 점이 가장 큰 차이점이다.

오픈소스

  • 스프링은 오픈소스 프로젝트이지만 좀 특이하다. 많은 오픈소스 프로젝트처럼 개발과정에 많은 사람들이 자유롭게 참여하고 개발과정도 공개되어있어서 현재 다루어지는 이슈나 피쳐도 확인이 가능하다. 개발자들은 커뮤니티를 통해 자유롭게 토론하고 의견을 개진할 수 있고, 버그를 신고하거나 기능 추가를 요청할 수 도 있다.

  • 하지만 스프링 프로젝트에 직접 참여하여 코드를 작성하고 개선시킬 수 있는 것은 일부 개발자로 한정된다. "스프링소스"라는 회사를 만들어서 전 세계에서 손 꼽히는 자바 개발자들이 직접 스프링 프레임워크의 개발에 참여한다.

  • 이렇게 되면, 오픈소스가 가진 자유로운 참여, 집단제작, 커뮤니티를 통한 활발한 의견교류와 버그 리포트, 기능추가 요청 등의 장점은 유지하면서도 힘든 지속가능성과 오류 및 기능 개선에 대한 신뢰 부족의 단점은 해결하는 성공적인 오픈소스 소프트웨어가 될 수 있다.

2. 목적

스프링의 목적은 앞에서도 살펴본 바와 같이 "자바 엔터프라이즈 시스템 개발을 편리하게 하기 위해서"이다.

그렇다면, 이전에는 자바 시스템 개발이 얼마나 힘들었는가?

  • 2000년대 초반에는 자바 어플리케이션 개발 프로젝트의 80% 이상이 실패했다고 한다.

  • 이유는 크게 두 가지였다.

    • 하나는 기술적인 제약조건과 요구사항이 늘어갔기 때문이었고

    • 또 다른 하나는 엔터프라이즈 어플리케이션이 구현해야 할 핵심 기능인 비즈니스 로직의 복잡함이 증가했기 때문이다.

  • 기술적인 제약조건과 요구사항

    • 흔히 말하는 엔터프라이즈 시스템이란 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템을 말한다.

    • 기업에서 일하는 도중에 사용하는 시스템이기 때문에, 여러가지 기술적으로 신경써야 할 것이 많았다.

      • 뛰어난 성능, 안정성, 사용자 인터페이스, 리모팅 접속 기술, 다중 데이터베이스의 트랜잭션 처리하는 분산 트랜잭션 지원 등

    • 이런 점들은 계속 어플리케이션 개발에 필요한 점들을 추가해갔고, 이를 개발자와 설계자가 온전히 책임지고 적용을 했어야 했다.

  • 비즈니스 로직의 복잠함 증가

    • 엔터프라이즈 개발이 한창 활발해질 시기에는 기업의 업무 형태가 점차 사람 중심에서 컴퓨터 중심으로 옮겨오고 있었다. 기존에는 회계 처럼 복잡한 계싼이나 빠른 분석에만 이용되었던 컴퓨터 프로그램이 이제는 다양한 기업과 조직의 업무를 지원하는 다양한 프로그램의 성격을 띄어야 했다. 이 때문에 비즈니스 로직이 점차 복잡해졌다.

복잡함을 가중시키는 원인 : 두 개를 동시에 고려해야한다.

  • 결국, 기술적으로도 제약조건과 요구사항이 늘어났고, 비즈니스 로직에 있어서도 계속 복잡해지는 상황이었는데, EJB 나 스프링 이전의 자바 엔터프라이즈 시스템 개발에서는 이런 서로 다른 성격의 두 종류의 코드들이 한 곳에 얽혀있었다. 두 가지 중 하나만 다루는 것도 복잡해 죽겠는데, 두 개를 동시에 고려하며 개발을 진행해야했다.

3. 전략

  • 결국 핵심은 기술관련 코드와 비즈니스 로직을 어떻게 분리하느냐였다.

  • EJB 도 이런 목적을 위해서 등장하였지만, 결과적으로는 실패했다.

    • 두 성격이 다른 코드들을 분리하는데는 성공했지만, EJB 라는 특정 기술에 코드와 구조, 설계가 종속되도록 디자인되었고, 중간에 EJB 에서 다른 기술로 전환하는 것이 매우매우매우 힘들었다.

    • 이렇게 특정 기술에 코드가 종속되자, 전체적인 설계도 자바 특유의 객체지향 설계구조를 만들어낼 수가 없었다. 항상 클래스가 그 기술에서 요구하는 특정 인터페이스나 특정 클래스를 상속해야했다.

  • 스프링은 다시 근본으로 돌아가자는 관점에서 시작하였다. 자바가 가지고 있는 객체지향적인 장점을 되살리는 방법을 이용하되, 원래 EJB 가 추구했던 기술코드와 비즈니스 로직의 분리를 성공적으로 해냈다.

  • 스프링의 성공원인

    • 비 침투적 기술 : 기술의 적용 사실이 코드에 직접 반영되지 않기 때문에 구조와 설계가 유연해지고, 특정 기술에 얽메이지 않게 되어 다른 기술에로의 전환이 쉽다.

      • 반면 침투적인 기술은 기술과 관련된 코드나 규약이 코드에 등장한다. 특정 클래스나 인터페이스, API 등의 코드가 일반 비즈니스 로직에 마구 등장한다.

3-1. 서비스 추상화

  • 서비스 추상화를 통해 코드가 특정 환경이나 기술에 종속되지 않도록 하였고, 기술에 대한 접근 방식을 일관적으로 유지할 수 있도록 했다.

3-2. 기술코드와 비즈니스 로직 분리

  • AOP 를 이용하여 기술과 비즈니스 로직을 분리해냈고, 별도의 모듈로 관리하게 해주었다.

  • 기술적인 코드가 반복되고 중복되지 않고 한 곳에서만 등장하므로, 변경사항에 대응하기가 훨씬 편해졌다. (한곳만 고치면됨)

3-3. 객체지향과 DI

  • 결국 스프링은 객체지향과 DI 이다.

  • 스프링은 주로 기술적인 복잡합을 해결하는 문제나 기술적인 복잡합이 비즈니스 로직에 침범하게 하지 못하게 할 때에는 DI 를 이용하였고, 비즈니스 로직의 복잡함을 해결하고자 할 때에는 객체지향을 이용하였다.

  • 서비스 추상화, 템플릿/콜백 패턴, AOP 와 같은 기술들은 모두 DI 를 바탕으로 하고 있고, 이런 DI 는 객체지향이 기반이 되어야 충분히 효과적으로 사용될 수 있다.

    • DI 할 후보를 고민하다보면 -> 자연스럽게 객체지향적인 설계를 떠올리게 된다.

4. pojo programming

스프링의 핵심, POJO

  • 스프링의 핵심은 엔터프라이즈 서비스 기능을 POJO에 제공하는 것이다.

    • 다른 말로 하자면, 스프링의 핵심은 트래잭션, 보안과 같은 엔터프라이즈 시스템 개발에서 요구되는 기술을 POJO 방식으로 개발된 어플리케이션 핵심 로직을 담은 코드에 제공해준다.

    • 이는 곧 엔터프라이즈 기술을 자바 비즈니스 핵심 로직에서 분리해냈다는 의미도 내포한다.

  • 스프링 삼각형 : 스프링소스의 CTO 인 아드리안 콜리어가 스프링의 핵심 개념을 설명하기 위해서 만든 것으로 아래와 같이 세 개의 요소로 이루어졌다.

    • IoC/DI

    • AOP

    • PSA, Portable Service Abstraction (서비스 추상화)

  • 스프링 어플리케이션은 POJO 를 이용해서 만든 어플리케이션의 코드 + POJO 가 어떻게 관계를 맺고 동작하는지 정의해둔 설계정보로 이루어진다.

    • 즉, DI 의 핵심 개념처럼 필요한 오브젝트는 유연하게 확장 가능한 형태로 만들어두고, 이들 사이의 연결은 외부에서 다이나믹하게 해준다는 것이다.

POJO란 무엇인가

  • pojo 는 Plain Old Java Object의 줄임말이다. 즉, EJB 처럼 복잡하고 제한이 많은 기술이 아니라, 자바의 단순한 오브젝트만을 이용해서 어플리케이션의 비즈니스 로직을 만드는 프로그래밍 기법을 말한다.

  • 그런데 그냥 자바 오브젝트를 사용했다고 하면 되는데 왜 저렇게 용어를 붙여서 어렵게 말하는가?

    • 당시에 마틴 파울러라는 개발자가 200년에 컨퍼런스 발표를 준비하다가 만들어낸 용어이다.

    • 그냥 자바 오브젝트만 이용해서 어플리케이션 비즈니스 로직을 개발하는게 EJB 쓰는 것보다 훨씬 좋은데, 왜 개발자들이 안쓸까? 고민을 하다가, EJB 처럼 그럴듯한 이름이 없어서라고 결론을 내고, POJO 라는 멋진 이름을 고안해내 부르기 시작했다고 한다. (ㅋㅋㅋㅋ)

    • 실제로 POJO 프로그래밍 개발은 그 이후, 굉장히 성공적이게 되어 이를 지원하는 것을 장점으로 내세운 프레임워크와 기술들이 쏟아져 나왔다고 한다.

조건

그냥 자바 오브젝트를 이용하고 EJB 를 안쓴다고 다 POJO 라고 부를 수 있는 것은 아니다. 아래와 같이 3가지의 조건은 적어도 지켜져야 POJO 프로그래밍 기법을 사용했다고 말할 수 있을 것이다.

  1. 특정 규약에 종속되지 않는다.

    1. EJB2 는 특정 규약을 따라서 비즈니스 컴포넌트를 만들어야 했다. POJO 가 아니다.

    2. 스트럿츠 1 역시 특정 클래스를 상속해서 만들어야 하는 규약이 있었다. 역시 아니다.

    3. 자바의 경우, 단일상속 제한이 있기 때문에 이렇게 특정 규약을 따라야 한다면, 객체지향적으로 설계하기가 굉장히 어려워진다.

  2. 특정 환경에 종속되지 않는다.

    1. EJB3의 경우, JNDI 라는 서버 서비스를 반드시 필요로 한다. EJB3의 의존 오브젝트 정보를 그곳에서 가져와야 하기 때문이다.

    2. 특정 벤더의 서버나 특정 기업의 프레임워크 안에서만 동작 가능한 코드도 곤란하다.

    3. 특정 OS 에서 제공하는 기능을 직접 호출하거나 환경에 종속적인 클래스나 API 를 직접 쓰는 것도 안된다.

    4. 특히 비즈니스 로직을 담고있는 POJO클래스는 웹이라는 환경정보나 웹 기술을 담고있는 클래스나 인터페이스를 사용해서는 안된다. 웹 이외의 클라이언트에서 사용할 수 없기 때문이다.

    5. 비즈니스 로직 코드 사이에 캐시와 관련된 API 가 등장하거나, 웹 프레임워크의 클래스를 직접 이용하는 부분이 있다면, 진정한 POJO 라고 할 수 없다.

  3. 객체지향적인 자바 언어의 기본에 충실하게 만들어져야한다.

    1. 객체지향적인 원리에 충실하면서

    2. 환경과 기술에 종속되지 않고

    3. 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 진정한 POJO 라고 할 수 있겠다.

장점

  1. 특정 기술이나 환경에 종속되지 않는다.

  2. 객체지향적인 설계를 자유롭게 적용할 수 있다.

스프링이 엔터프라이즈 시스템의 복잡함을 다루는 방식

  • 비즈니스 로직의 복잡함과 엔터프라이즈 기술의 복잡함을 분리해서 구성할 수 있게 도와준다.

    • 스프링 자체는 비즈니스 로직을 담당하는 POJO에서는 모습을 감춘다.

5. 기술

  • 스프링의 Ioc/DI, AOP, PSA 등의 기술들은 결국, PJO 기반의 엔터프라이즈 개발을 편라하게 해주는 도구일 뿐이다. 다른 말로 하자면, 스프링이 가장 중요하게 생각하는 객체지향 원리를 충실히 적용해서 나온 결과물들이기도 하다.

  • 스프링 사용자라면, 스프링이 위와 같은 기술을 제공하지 않아도, IoC/DI, AOP, PSA 등의 기술을 적용해서 쓸 줄 알아야 한다. 단순히 스프링이 제공하는 기술만 가져다가 쓰는 것이 아니다.

5-1. 제어의 역전 Inversion of Control / 의존관계 주입 Dependency Injection

  • 스프링의 가장 기본이 되는 기술이자 핵심 개발 원칙

  • AOP 와 PSA, 템플릿/콜백 패턴 모두 IoC/DI 에 근간을 두고 있다.

  • 유연한 확장을 가능하게 해주는 기술이다.

    • 객체지향 설계 원칙의 OCP 로 잘 설명할 수 있다. 변경에는 닫혀있지만, 확장에는 열려있는 형태.

    • A -> B 라는 의존관계를 가지고 있다면,

      • B 는 A와 상관없이 자유롭게 변경될 수 있고, B가 변경된다고 해도 A는 아무런 영향을 받지 않게 된다.

      • B관점에서는 유연한 확장이고, A입장에서는 변경 없이 재사용 가능한 것이다.

      • B가 B1, B2, B3 와 같이 의존대상이 바뀐다고 하더라도 상관없고, B1, B2, B3 처럼 의존 대상이 바뀐다고 하더라도 A는 그대로 여전히 재사용 가능하다.

  • 디자인 방식 중에서도 오브젝트 합성과 관련된 패턴에서 자주 사용될 수 있다.

  • 핵심 기능의 변경 : DI 대표적인 적용 방법은 의존 대상의 구현을 바꾸는 것

    • 디자인 패턴의 전략패턴의 대표적인 예

      • 예) 서비스 오브젝트가 사용하는 DAO 가 있을 때, 그것에 대한 구현을 JDBC, JPA, 하이버네이트, iBatis 등 다양한 방식으로 변경하는 것

    • 예) 사용자 관리 서비스에서 사용자의 등급을 결정하는 정책을 담은 코드를 DI 로 분리하는 것

  • 핵심 기능의 동적인 변경 : 어플리케이션이 동작하는 중간에 의존대상을 다이나믹하게 변경할 수 있다.

    • 예) 사용자의 등급에 따라 다른 DB 를 이용하게 해서 VIP 사용자는 좀 더 빠른 처리 속도를 보장한다.

  • 부가기능의 추가

  • 인터페이스의 변경

  • 프록시

  • 템플릿과 콜백

  • 싱글톤과 오브젝트 스코프

  • 테스트

5-2. 에스펙트 지향 프로그래밍 AOP

  • AOP 는 객체지향의 부족함을 보완해주는 보조적인 프로그래밍 기술이다.

  • 적용 기법

    • 스프링과 같이 다이나믹 프록시를 사용하는 방법

      • 기존 코드에 영향을 주지 않고 부가기능을 적용하게 해주는 데코리이터 패턴을 응용한 방법

      • 엔터프라이즈 개발에서 필요로 하는 AOP 는 대부분 이 프록시 방식이다.

    • 자바 언어의 한계를 넘어서는 언어의 확장을 이용하는 방법

      • AspectJ 라는 유명한 오픈소스 AOP 등을 이용하는 것이다.

      • 기존의 프록시 AOP 방식에서는 불가능했던 다양한 조인 포인트를 제공한다.

      • 고급 AOP 기능을 적용하려면 자바 언어와 JDK 의 지원만으로는 불가능하다.

  • 적용 단계

    • 1단계 : 미리 준비된 AOP 이용

      • 스프링이 만들어둔 것을 가져다가 사용하는 방법

      • 예) 대표적으로는 트랜잭션, @Configurable 에노테이션 이용한 DI 적용해주는 기능

    • 2단계 : 전담팀을 통한 정책 AOP 적용

      • 소수의 AOP 담당자 관리하에 적용해보는 방법

      • 예) 보안, 로깅, 트레이싱, 실시간 성능 모니터링과 같이 정책적으로 적용할 만한 기능에 AOP 이용

      • 예) 개발 가이드라인이나 표준을 따르는기 검증하는 작업에 이용될 수도 있음. JSP 뷰에서 DAO 나 서비스 계층의 오브젝트를 직접 호출하면 안된다는 정책이 있는데, 이를 무시하고 짤 경우, 모든 DAO 메소드 호출에 적용되는 AOP 를 하나 만들어서 메소드 호출이 있어났을 때, 호출 경로를 조사한다.

      • AOP 는 쉽게 추가하거나 제거 가능하다!

  • 3단계 : AOP 의 자유로운 이용

5-3. 서비스 추상화 Portable Service Abstraction

  • 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해준다.

  • 단순히 종속성 해제 뿐만 아니라, 테스트가 어렵게 만들어진 API 나 설정을 통해 주요 기능을 외부에서 제어하게 만들고 싶을 때도 이용할 수 있다.

  • 스프링에서 제공하지 않는다면, 개발자가 직접 추상 레이어를 도입하고 일관성 있는 API 를 정의해서 사용하면 된다.

6. 정리

  • 스프링을 이용할 때에는 철학과 목표를 분명하게 이해하고 사용해야한다.

  • 스프링은 오픈소스 소프트웨어이며, 어플리케이션 개발과 관련된 모든 기술과 영역을 종합적으로 다루는 어플리케이션 프레임워크이다.

  • 엔터프라이즈 어플리케이션 개발이 복잡해지는 이유는 비즈니스 로직과 엔터프라이즈 시스템의 기술적인 요구 때문이다. 기존의 해결방법들은 자바의 객체지향적인 장점을 포기하는 방식이었으며, 복잡도도 낮추지 못하였다.

  • 기존 방식의 대안책으로 등장한 POJO 개발방식은 자바의 근본인 객체지향적 장점을 잘 이용할 수 있도록 해주었고, 환경과 규약에 의존하지 않는다. 이를 통해 자바 엔터프라이즈 시스템 개발의 복잡함이 주는 많은 문제를 해결해왔다.

  • 스프링의 목적은 이런 POJO programming 을 이용해서 엔터프라이즈 어플리케이션 개발을 보다 쉽고 효율적으로 할 수 있도록 지원해주는 것이다.

  • POJO 방식의 개발을 돕기 위해서 스프링은 IoC/DI, AOP, PSA 와 같은 기능 기술을 프레임워크와 컨테이너라는 방식을 통해 제공한다.

결국 스프링은 자바 엔터프라이즈 개발의 복잡함을 덜어주는 POJO 방식의 프로그래밍을 보다 쉽고 효율적으로 할 수 있도록 기능기술을 제공해주는 어플리케이션 프레임워크이다.

Previous스프링 프로젝트 시작하기Next스프링 핵심 기술의 응용

Last updated