Study Plus는 스터디를 진행 한 후에 스스로 부족하다고 느낀 부분과 더 공부가 필요한 부분, 스스로가 생각하지 못한 부분에 대해서 추가적인 공부를 진행한 것입니다. 개인적으로 추가하는 Study입니다. 빠샤🔥
Maven vs Gradle
Maven과 Gradle 모두 빌드 도구입니다. 두 빌드 도구 모두 어플리케이션을 사용하면서 필요한 다양한 외부 라이브러리들을 다운로드하고 해당 라이브러리를 사용하는 상황에서 설정 파일에 필요한 라이브러리들의 대한 정보, 종속성 등을 입력하면 자동으로 해당 라이브러리들을 관리해줍니다.
또한 프로젝트에서 작성한 java 코드와 각종 xml, jar 파일등을 WAS이나 JVM이 인식 가능하게 해주는 과정을 진행해 줍니다. "빌드 자동화 도구" 라고 할수 있겠네요!
빌드는 다음과 같은 과정을 거칩니다.
- 종속성 다운로드 = 외부 라이브러리 다운로드합니다.
- 소스코드를 바이너리 코드로 컴파일합니다.
- 바이너리 코드들을 패키징합니다. jar, EAR등의 형식으로 패키징 됩니다.
- 테스트 자동화 = 테스트를 자동으로 실행하고 결과를 보고합니다.
- 배포 = 소프트웨어 배포 과정을 간소화하고 프로덕션 시스템에 배포합니다.
두 빌드 도구는 비슷한 라이프 사이클을 사용합니다.
위 사진은 Maven의 라이프 사이클입니다.
- clean: 빌드 시 생성되어 있던 파일을 삭제합니다.
- vaildate: 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인합니다.
- compile: 프로젝트 소스코드를 컴파일 합니다.
- test: 단위 테스트를 실행하는 단계입니다. 테스트 실패 시 빌드 실패로 처리하며, 해당 단계를 스킵 가능합니다.
- package: 실제 컴파일 된 코드들과 리소스들을 jar, war등의 배포를 위한 패키지로 만듭니다.
- verify: 통합 테스트 결과에 대한 검사를 실행합니다. 품질 기준에 충족하는지 확인합니다.
- site: 프로젝트 문서, 사이트를 생성하는 단계입니다.
- deploy: 만들어진 package를 원격 저장소에 release하는 단계입니다.
위와 같은 라이프 사이클에 의하여 작업을 수행하며, 전반적으로 프로젝트 관리 기능을 포함하고 있습니다.
반면 Gradle의 LifeCycle은 3단계로 나누어집니다.
- Initialization Phase: setting.gradle 파일을 이용하여서 Setting 인스턴스를 생성합니다. 해당 파일에 따라서 project 별로 project인스턴스를 생성합니다. (인스턴스: 자바 메모리 상에 객체가 올라가는 것을 의미합니다.)
- Configuration Phase: build.gradle 파일을 이용해서 빌드 실행에 영향을 받는 빌드 스크립트를 판단하고 이를 통해서 task graph가 생성됩니다.
- Execution Phase: 의존 관계에 따라서, task를 실행합니다. task는 병렬적으로 실행 가능합니다.
크게 나누면 위와 같은 3단계를 거치지만 해당 단계들은 빌드에 중점적으로 설명이 되어 있습니다. Gradle도 Maven과 마찬가지로 패키징, 테스트, 배포 단계를 거치게 됩니다. 차이점이라고 한다면 Gradle은 Task로 정의하여서 실행하지만, Maven은 명령어로 실행된다는 점입니다.
하지만, 이렇게 라이프 사이클이 비슷한 빌드 도구임에도 Gradle과 Maven의 성능에 차이가 있습니다. Gradle의 경우가 더 높은 성능을 가지고 있습니다. 이유가 무엇일까요?
1. 제한적인 증분 빌드 사용과 병렬 처리
Maven은 병렬 특정 상황에서만 병렬 처리를 지원합니다. 전체 빌드 과정을 병렬로 실행하지 않습니다. 또한 일부 플러그인만 병렬 처리를 지원합니다. 해당 특성은 Gradle에 비해서 빌드 성능을 제한합니다.
또한 Maven은 의존성을 정적으로 관리합니다. 빌드 반복할 때마다 pom.xml 파일에서 필요한 모든 의존성을 파악하여서 의존성 그래프를 만듭니다. 모든 빌드에 위와 같은 작업을 거친다면 동적으로 의존성을 처리하는 Gradle과 차이가 나게 됩니다.
2. 효율적인 설정 구조
Maven은 XML 형식의 파일을 사용하여, 복잡한 설정과 낮은 가독성을 가지고 있습니다. 이러한 복잡도는 빌드 프로세스의 이해도를 높이는 것 뿐만 아니라 빌드 시간을 높이기도 합니다. 반면 Gradle은 DSL을 사용해서 간결하고 가독성이 높은 설정을 제공합니다. (DSL: 특정 도메인의 요구 사항을 효율적으로 표현하기 위해서 설계된 언어) 따라서 두 빌드 도구의 설정 파일 형태에 따라서 성능차이가 발생할 수 있습니다.
3. 설정의 유연성
Maven 설정은 일종의 상속 구조를 가지고 있습니다. 부모의 POM 파일에서 정의된 설정이 자식의 POM 파일로 상속되어서 사용됩니다. 즉, 자식 프로젝트는 부모 프로젝트의 설정을 상속받아 사용할수 있습니다. 이를 통해서 중앙 집권적인 특성과 유사한 프로젝트 간의 설정을 공유하여서 사용할 수 있다는 장점을 가졌습니다. 하지만 이러한 상속 구조가 복잡성을 증가시켜, 때로는 예상하지 못하는 부작용을 초래할 수 있습니다.
반면, Gradle은 프로젝트 간의 의존성을 사용해서 다른 프로젝트의 설정을 현재 프로젝트에 의존성을 추가하면, 현재 프로젝트는 마치 자체 설정 처럼 사용할 수 있습니다.
4. 다양한 플러그인 존재
Gradle은 자바, Kotlin, 안드로이드 등 다양한 언어와 프레임워크를 지원합니다. 또한 DSL을 사용해서 가독성 높고 쉬운 설정을 제공합니다. 이를 기반으로 Maven에 비해서 다양한 플러그인이 제작되게 되었습니다.
위와 같은 이유로 현재는 대부분의 경우에 Gradle이 사용되고 있습니다. 자세하게 알아보니 재밋네요😎
템플릿 엔진
템플릿 엔진이란 데이터와 템플릿을 결합하여서 동적으로 콘텐츠를 생성하는 역할을 하는 소프트웨어나 도구입니다. 주로 웹 어플리케이션에서 사용되며, 서버 측이나 클라이언트 측에서 사용가능합니다. 쉽게 말하면 HTML, CSS + DATA를 해주는 소프트웨어입니다.
템플릿 엔진은 서버측에서 주로 사용되는 서버 사이드 템플릿엔진과 클라이언트 측에서 사용되는 클라이언트 사이드 템플릿 엔진으로 나누어집니다.
Server side Template engine
서버에서 DB or API에서 가져온 데이터를 미리 정의된 Template에 넣어서 Html을 그려서 클라이언트에 전달해주는 역할을 해줍니다. 즉, HTML에서 고정적으로 사용되는 부분은 템플릿으로 만들어두고 동적으로 생성되는 부분만 끼워넣는 방식으로 생성됩니다.
1) 서버가 클라이언트의 요청을 받습니다.
2) 필요한 데이터를 받아 옵니다.
3) 미리 정의된 Template에 적절하게 넣습니다.
4) 서버에서 HTML을 만들고 클라이언트에게 전달합니다.
Client side Template engine
HTML 형태로 코드를 작성할 수 있으며, 동적으로 DOM을 그리게 해주는 역할을 합니다. 즉, 데이터를 받아서 DOM 객체에 동적으로 그려주는 프로세스를 담당합니다. 예를 들면, 웹 페이지에서 여러 카테고리를 선택하는 경우 같은 형식의 프레임에 내용만 바뀌어서 변경되는 것을 볼 수 있습니다.
1) 클라이언트에서 공통으로 사용할 프레임을 미리 Template으로 만들어 놓습니다.
2) 서버에서 필요한 데이터를 받습니다.
3) 데이터를 Template에 적절한 위치에 replace하고 DOM 객체 동적으로 그려줍니다.
두개의 템플릿 엔진을 동시에 사용하여서 각각의 장점을 한번에 사용하여서 웹 어플리케이션의 다양한 요구를 충족하고 최적의 성능을 달성할 수 있습니다.
JSP vs Thymeleaf
제 프로젝트에서는 thymeleaf 서버 사이드 템플릿엔진을 사용하였습니다. 하지만 해당 템플릿엔진 말고도 다른 템플릿 엔진들이 많이 존재했습니다. 많이 사용되었던 JSP 템플릿엔진과의 비교를 통해서 Thymeleaf의 장점과 다른 템플릿엔진의 특징을 알아보겠습니다.
JSP
해당 템플릿 엔진은 HTML에 JAVA 코드를 넣어서 동적 웹사이트를 생성합니다. JSP가 실행되면 자바 서블릿으로 변환이 되어서 웹 어플리케이션 서버에서 동작되면서 필요한 기능을 수행하고 그렇게 생성된 데이터를 웹페이지와 함께 클라이언트에게 전송합니다.
1. 브라우저가 서버에게 JSP에 대한 정보를 요청합니다.
2. 요청한 JSP가 최초로 요청된 경우에만 해당 코드가 서블릿 코드로 변환됩니다.
3. 해당 서블릿을 컴파일해서 클래스 파일을 생성합니다.
4. 요청을 처리하고 응답하여서 웹 브라우저에 전송합니다.
Thymeleaf
해당 템플릿은 위와는 다르게 서블릿 파일을 생성하지 않습니다. HTML을 그대로 사용하는, 자연 템플릿 방식을 사용합니다. 이를 통해서 웹 브라우저에서 직접 열리는 경우에도 HTML 파일처럼 보이고 작동하게 합니다. 따라서 상대적으로 자연스러운 템플릿을 제공하여, 개발자와 디자이너 모두가 효율적으로 협업할 수 있는 환경을 조성합니다. 실제로 스프링 부트에서는 해당 템플릿 엔진을 JSP보다 많이 사용합니다. 그 이유는 아래와 같습니다.
1. JSP는 서블릿이라는 형태로 변환되어서 실행됩니다. 따라서 view에 비즈니스 로직이 포함되며 무거워지게 됩니다. 하지만 타임리프는 서블릿으로 변환되지 않기에 비즈니스 로직이 분리되어 있습니다. 따라서 프론트와 서버가 분리되어서 코딩이 되는 요즘에 어울린다고 볼수있습니다.
2. JSP는 JAR 패키징이 불가능합니다. WAR 패키징만 가능한데, 해당 패키징은 JAR과 달리 웹 서버나 WAS가 필요합니다. 하지만 타임리프는 JAR 패키징이 가능합니다. 따라서 훨씬 편리하게 사용 가능합니다.
어노테이션
Annotation은 사전적인 의미로는 주석이라는 뜻입니다. 자바에서는 코드 사이에 주석처럼 쓰이며 특별한 의미, 기능을 수행하도록 하는 기술입니다. 즉, 프로그램에 추가적인 정보를 제공해주는 메타데이터라고 볼 수 있습니다. 다른 프로그램에게 유용한 정보를 제공하는 역할입니다.
어노테이션은 컴파일러에게 코드 작성 문법 에러를 체크하도록 정보를 제공합니다. 또한 빌드 시에 코드를 자동으로 생성하도록 정보를 제공합니다. 마지막으로 실행시에 특정 기능을 실행하도록 정보를 제공합니다.
https://zz132456zz.tistory.com/40
[Spring] 스프링에서 많이 사용하는 어노테이션 정리 (Annotation)
◈ 빈 자동 등록에 사용할 수 있는 annotation 종류 @Repository Data Access Layer의 DAO 또는 Repository 클래스에 사용한다. DataAccessException 자동변환과 같은 AOP의 적용 대상을 선정하기 위해서 사용된다. @Servi
zz132456zz.tistory.com
위와 같이 다양한 어노테이션이 상황에 알맞게 사용됩니다.
출처
https://velog.io/@key1018/스프링-입문-빌드-관리-도구
https://velog.io/@leesomyoung/Maven과-Gradle의-차이-및-비교
https://developerpearl.tistory.com/m/102
https://usefultoknow.tistory.com/entry/템플릿-엔진Template-Engine-이란#recentComments
