솔루션 회사를 몇년 다니다보니 내가 생각하는 웹서비스 환경의 경험이 적다는 생각이 들어서 A to Z까지 천천히 따라가면서 조금이나마 경험을 늘릴 수 있는 계기가 되지 않을까 싶어서 서적을 하나 구매해보았다.

이하 포스팅할 내용은 모두 스프링 부트와 AWS로 혼자 구현하는 웹 서비스라는 책을 읽고 작성한 내용으로 학습한 내용을 정리하기 위함이다.

• 개발환경은 책과 좀 다르다. 시간도 지났고 기존에 사용하던 환경이 있으므로
  • openJDK 11
  • Gradle 6.7
  • IntelliJ 유료버전

1. 인텔리제이로 스프링 부트 시작하기

이미 인텔리제이는 사용하고 있지만 책에서 언급한 이클립스에 비해 인텔리제이가 가진 장점은 다음과 같다.

• 강력한 추천 기능(Smart Completion)
• 훨씬 더 다양한 리팩토링과 디버깅 기능
• 이클립스의 깃(Git)에 비해 훨씬 높은 자유도
• 프로젝트 시작할 때 인덱싱을 하여 파일을 비롯한 자원들에 대한 빠른 검색 속도
• HTML과 CSS, JS, XML에 대한 강력한 기능 지원
• 자바, 스프링 부트 버전업에 맞춘 빠른 업데이트

인텔리제이는 무료버전과 유료버전이 모두 존재하지만 커뮤니티(무료) 버전만 사용하더라도 개발에 큰 지장은 없다. 자바 개발에 대한 모든 기능 및 Maven, Gradle과 같은 빌드 도구도 모두 지원한다.

여담으로 둘다 써본 경험에서 불편했던 점은 딱 한가지였는데 임베디드 톰캣이 아닌 외부 톰캣과 연동하는 경우 커뮤니티 버전에선 공식적으로 지원하지 않아서 별도의 플러그인을 설치해서 사용했는데 그게 좀 귀찮았던 기억이 있다.

그리고 이클립스를 쓰다가 인텔리제이로 넘어오면 가장 당황하는 것이 워크스페이스가 없이 프로젝트와 모듈의 개념만 있다는 점이다. 이 말은 인텔리제이는 한번에 하나의 프로젝트만 열린다는 점이다.

Gradle로 프로젝트 생성

ArtifactId는 프로젝트의 이름이 된다

그동안 Maven만 사용해봤는데 Gradle이 가진 장점과 단점은 무엇인지 추후에 찾아봐서 포스팅 해봐야겠다.

시간이 지나면서 버전이 바뀐 영향인지 프로젝트 생성부터 책과 약간 다르게 진행이 되긴 하는데 또 그래야 더 찾아보고 공부가 되지 않을까 하는 생각도 들었다.

Gradle 프로젝트 생성 완료

Gradle 프로젝트를 springBoot 프로젝트로 변경하기

• 초기 build.gradle 파일

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

plugins {
    id 'java'
}

group 'com.springboot.service'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
}

test {
    useJUnitPlatform()
}

음… 여기서부터 책과 벌써 다르다. 아무래도 책의 출판시점에서 2년이나 지났으니 각종 라이브러리, 도구들의 버전업이 일어나면서 여러 내용들이 바뀐듯 하다.

구글링을 해보니 저자분이 [2020.12.16] 기준으로 최신 라이브러리로 버전업한 내용에 대해 정리해놓은 글이 있어서 해당 내용을 참고하였다.

참고링크 : 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 (2020.12.16)

변경된 도구들의 버전은 다음과 같다.

기초가 부족한 관계로 기초부터 다시 정리도 하는 겸사겸사 첫주제는 spring framework로 정했다.

Srping Framework란

스프링 프레임워크(Spring Framework)는 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로 간단히 스프링(Spring)이라고도 한다. 동적인 웹 사이트를 개발하기 위한 여러 가지 서비스를 제공하고 있다.

대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준프레임우커의 기반 기술로서 쓰이고 있다.

특징

1. 크기와 부하의 측면에서 경량 컨테이너로서 자바 객체를 직접관리한다.

   • 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다

2. 제어 반전 혹은 제어 역행(IoC: Inversion of Control)을 지원한다.

   • 컨트롤의 제어권이 사용자가 아닌 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.
   • IoC는 DI와 DL에 의해 구현된다.
     • DL(Dependency Lookup) : 의존성 검색
       • 컨테이너에서는 객체들을 관리하기 위해 별도의 저장소에 빈을 저장하는데 저장소에 저장되어 있는 개발자들이 컨테이너에서 제공하는 API를 이용하여 사용하고자 하는 빈을 검색하는 방법
     • DI(Dependency Injection) : 의존성 주입
       • 의존성 주입이란 객체가 서로 의존하는 관계가 되게 의존성을 주입하는 것으로 객체지향 프로그램에서 의존성이란 하나의 객체가 어떠한 다른 객체를 사용하는 것을 의미한다.
       • IoC에선 각 클래스 사이에 필요로 하는 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동으로 연결해 주는 것을 말한다.

3. POJO(Plain Old Java Object) 방식의 프레임워크이다.

   • 직역하면 오래된 방식의 간단한 자바 오프젝트라는 말이다.

   • 일반적인 J2EE 프레임워크에 비해 구현을 위하여 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가볍다.

   • 쉽게 이야기하면 getter/setter 메소드로 이루어진 Java Benas를 생각하면 된다.

   • 예를 들어 자바 서블릿 코드를 작성할 때는 보통 HttpServlet을 상속받아야 한다.

     1 2 3

     public TestServlet extends HttpServlet { ... }

     이처럼 서블릿 프로그래밍을 하는 것만으로 객체지향 프로그래밍의 가장 핵심적인 기능 중 하나인 상속을 할 수 없고 HttpServlet에서 제공하는 기능을 어떻게 재사용할 것인지 판단해야하는 부분도 생겼다.

   • POJO는 이러한 제약이 없는 일반적인 객체를 말하는데 여기서 상속이나 인터페이스 구현을 사용하지 않는 객체가 아니라 어떠한 라이브러리나 프레임워크 등 자바 언어 사양 외에 어떠한 제한을 강제받지 않는 자바 오브젝트를 뜻하는 것이다.

4. 관점 지향 프로그래밍(AOP: Aspect Oriented Programming)을 지원한다.

   • 기존의 객체지향 프로그래밍(OOP: Object Oriented Programming) 에서는 객체의 재사용으로 인해 반복되는 코드의 양을 줄일 수 있었지만 여전히 많은 부분에서 중복된 코드가 발생한다.
   • 예를 들어 로그, 권한 체크, 인증, 예외 처리와 같은 소스상에서 반복될 수 밖에 없는 필수적인 요소들로 코드의 가독성이나 유지보수적인 측면에서 좋지 않았다.
   • AOP는 OOP를 대체하는 개념이 아닌 OOP를 좀 더 OOP처럼 사용하기 위하여 보완하는 개념으로 공통적으로 반드시 필요하지만 중복해서 작성해야하는 핵심 이외의 코드들을 외부로 분리하여 관리한다.
   • 이렇게 외부에서 관리하는 공통기능을 핵심 로직에 영향을 끼치지 않게 잘 끼워넣어 개발하면 무분별하게 중복되는 코드를 제거하면서 공통기능의 수정을 통해 모든 핵심 로직의 공통기능을 수정하여 효율적인 유지보수가 가능해지면서 재활용성이 극대화된다.
   • 즉, 위에서 예를 들었던 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 분리하여 관리할 수 있다는 것이다.

5. MVC (Model2)

   • MVC는 Model, View, Controller 를 뜻하며 사용자 인터페이스와 비즈니스 로직을 분리하여 개발하는 것으로 웹 프로그래밍 개발에선 거의 표준처럼 사용되고 있으며 일반적으로 Model2를 지칭한다.
     • Model은 데이터를 처리하는 영역
     • View는 렌더링되서 실제로 보이는 화면
     • Controller는 사용자의 요청을 받고, 응답을 주는 로직을 담당
   • 이처럼 소스를 분리하여 각 소스의 목적을 명확히하면 모듈화를 통해 재사용성을 늘리고 유지보수를 쉽게 할 수 있으며 확정성도 좋은 장점이 있다.
   • 간단한 흐름을 살펴보면 요청 -> 컨트롤러 -> 모델 -> 컨트롤러 -> 뷰 의 흐름이라고 생각하면 된다.
     (MVC와 관련된 자세한 내용은 추후 기회가 된다면 별도로 포스트하겠다.)

이상으로 스프링 프레임워크의 특징에 대하여 대략적으로 정리를 해보았다.

Reference

• 위키백과
• POJO(Plain Old Java Object) 란?
• Spring 개념 정리