[Springboot] 퇴근길 버스안에서 호다닥 공부하는 스프링부트-도구 이상형 월드컵

호기롭게 스프링부트 스터디에 뛰어들었지만 졸논 + 프로젝트 이슈로 저번주에는 제대로 참여하지 못했다..사실 어제까지 졸업논문과 프로젝트 보고서 마감일이었어서 이번 주도 공부를 못한 것은 마찬가지인데 한 주 더 건너뛰기에는너무 눈치가 보이기 때문에 버스 안에서 호다닥 벼락치기 해보았다.

 

다음 책을 참고하였다.

 

나 설치에만 두시간 걸렸다

 

빌드 도구 

스프링부트 프로젝트 레포를 보면 gadle이라는 폴더가 꼭 보였는데 도대체 저게 뭔까 항상 궁금했었다(따로 알아볼 정도로 궁금하지는 않고 그냥 볼때만 잠깐 궁금했다).  마침  이 책 2장에서 도구 선택을 다루면서, 그레이들에 대한 설명을 포함하여 2장을 먼저 읽어보기로 했다.

 

메이븐(Maven)과 그레이들(gradle)은 빌드 도구이다. 과거에는 더 많은 빌드 도구들이 있었지만, 현재는 이 두 개의 커뮤니티만 살아남은 모양이다.

 

아파치 메이븐(Apache Maven)

메이븐은 2002년에 시작된 이후로, 엄청나게 오래 사용된 도구이다. 메이븐은 선언형 접근법을 사용하여, 다른 빌드 도구보다 개념이 훨씬 간단하다. XML 형식의 pom.xml 파일에 프로젝트 의존성과 플로그인을 적기만 하면 된다.

 

mvn 명령어를 실행할 때 어떤 단계를 수행할지 지정하여 컴파일, 이전 빌드에서 생성된 산출물 삭제, 패키징, 애플리케이션 실행 등 다양한 작업을 처리한다.

 

메이븐은 컨벤션에 따라 특정 프로젝트 구조를 생성한다. 프로젝트 구조를 그대로 사용하지 않으면, 오히려 역효과가 발생한다. 

 

project-root/
├── pom.xml                        # 메이븐 프로젝트 설정 파일
├── src/
│   ├── main/                      # 애플리케이션 소스 코드
│   │   ├── java/                  # Java 소스 파일
│   │   │   └── com/example/demo/  # Java 패키지 구조
│   │   │       └── DemoApplication.java  # 메인 애플리케이션 클래스
│   │   └── resources/             # 설정 파일 및 리소스
│   │       └── application.properties  # 애플리케이션 설정 파일
│   └── test/                      # 테스트 소스 코드
│       ├── java/                  # 테스트 Java 파일
│       │   └── com/example/demo/  # 테스트 패키지 구조
│       │       └── DemoApplicationTests.java  # 테스트 클래스

 

그레이들

그레이들은 JVM(Java Virtual Machine) 프로젝트를 빌드할 때 사용하는 빌드 도구다. 메이븐의 엄격한 폴더 구조가 마음에 들지 않거나, 조금 더 유연한 설정이 필요한 환경이라면 그레이들을 사용하면 된다.

 

그레이들은 DSL(Domain Specific Language)을 사용하여 빌드 파일을 작성한다. build.gradle 파일은 최소한의 코드로 작성할 수 있으며, 그루비(Groovy) 또는 코틀린(Kotlin)을 기반으로 한다. 빌드 대기 시간을 줄이기 위한 다양한 기능을 제공한다.

 

 

• 자바 클래스의 증분 컴파일
  • 변경된 파일만 컴파일하여 빌드 시간을 줄이는 기술. 변경 사항이 없는 경우에는 기존 컴파일된 파일을 그대로 사용해 빠르게 작업을 진행한다.
  • 예: 메이븐은 전체 파일을 다시 빌드하지만, 그레이들은 변경된 부분만 처리한다.
• 데몬(Daemon)
  • 프로젝트를 컴파일하기 위해 백그라운드에서 실행되는 프로세스.
  • 일반적인 JVM 프로세스와 비슷하며, 한 번 시작되면 종료하지 않고 지속적으로 빌드 작업을 처리한다.
  • 덕분에 동일한 프로젝트를 반복적으로 빌드할 때 초기화 과정을 생략하여 빠르게 작업할 수 있다.

기본적으로는 메이븐과 비슷한 구조를 따르나, 원하는대로 커스텀 할 수 있다.

 

메이븐 vs 그레이들

메이븐은 선언형 접근 방식과 일관된 프로젝트 구조를 통해, 프로젝트와 개발 환경을 정해진 규칙 내에서 일관성 있게 유지한다. 이 규칙을 벗어나지 않는 이상 일반적으로 문제가 발생하지 않는다. 이러한 특성 덕분에 초보자나 표준화된 환경을 선호하는 경우 좋은 선택지가 될 수 있다.

 

장점

1. 일관성 유지: 프로젝트 구조와 빌드 절차가 표준화되어 개발 환경 간 차이를 최소화.
2. 안정성: 새로운 버전의 도입 시 호환성 문제가 적어 예측 가능한 빌드 가능.
3. 배우기 쉬움: 설정 파일인 pom.xml은 읽기 쉽고 선언적이기 때문에 초보자에게 적합.
4. 풍부한 플러그인: 다양한 플러그인과 문서화로 확장성 확보.

단점

1. 빌드 속도: 대규모 프로젝트에서 빌드 시간이 느릴 수 있음.
2. 유연성 부족: 정해진 구조와 규칙에서 벗어나는 작업은 추가적인 설정이 필요.
3. 의존성 문제: 특정 버전 간 의존성 충돌 시 해결이 복잡해질 수 있음.

 

그레이들은 프로그래밍/스크립팅 중심의 빌드 도구로, 높은 유연성과 최신 기능을 제공한다. 하지만 이 유연함은 경우에 따라 예상하지 못한 문제를 유발할 수 있다. 특히, 최신 버전의 프로그래밍 언어를 사용하는 경우 빌드 문제가 발생할 가능성이 있다. 하지만 대규모 프로젝트에서 메이븐보다 빠른 속도를 보인다는 장점이 있다.

 

장점

1. 빠른 속도: 증분 컴파일과 데몬 기능으로 대규모 프로젝트에서도 높은 성능.
2. 유연성: 폴더 구조와 설정 파일을 자유롭게 변경 가능.
3. 최신 기술 지원: 최신 JVM 언어(Groovy, Kotlin)로 유연한 빌드 스크립트 작성 가능.
4. 의존성 관리 강화: 강력한 의존성 관리 도구 제공.

단점

1. 복잡성: 유연성이 높아진 만큼, 예상치 못한 동작이나 문제 해결 시간이 길어질 수 있음.
2. 호환성 문제: 새로운 프로그래밍 언어나 최신 버전 사용 시 빌드 문제가 발생할 가능성.
3. 학습 곡선: DSL 기반의 빌드 스크립트 작성은 메이븐에 비해 배우기가 어렵다.
4. 작은 프로젝트에서의 효과 제한: 마이크로서비스 같은 작은 규모에서는 메이븐과 속도 차이가 크지 않음.

 

스프링부트는 메이븐과 그레이들 모두 지원한다. 어떤 도구를 사용할지는 개인의 취향에 달린 것 같다. 책에서도 두 방식 모두 경험한 뒤 끌리는거 쓰세요라고 말하고 있다.

 

아직 두 도구 모두 사용해보지 못했지만, 지금 당장 끌리는건 메이븐인 것 같다. 일관적인 구조에서 오는 안정성이 매력적인 것 같고, 무엇보다 이름이 이쁘다. 스프링부트로 대규모 프로젝트를 핸들링 할 일도 없을 것 같아서, 그레이들의 대규모 프로젝트에서의 빠른 속도보다도 안정성이 나에겐 더 적합한 방식인 것 같다 . 오류 싫어요

---

 

언어 

JVM에서는 많은 언어를 사용할 수 있지만, 자바와 코틀린을 가장 많이 쓴다. 자바는 JVM의 근본이며, 코틀린은 JVM을 사용하는 비교적 최신 언어이다. 스프링 부트는 자바와 코틀린을 완벽히 지원하며, 특히 스프링 부트 하면 자바, 자바하면 스프링 부트가 생각날정도로...떼려야 뗄 수 없는 관계이다.

 

자바☕

자바는 공식 1,0버전 이후 25년 된 프로그래밍 언어이다. 오래되었지만, 2017년 9월 이후부터는 출시 주기가 6개월로 바뀌어 기능 개선이 잦은, 꾸준히 발전 중인 언어이다. Java Never Die👑

 

자바는 오랫동안 사용되었고, 꾸준히 업데이트 되면서도 이전 버전과 일관되게 호환된다. 덕분에전 세계에서 수많은 애플리케이션 자바 베이스로 만들어졌고, 유지되고, 관리되고 또 지금도 개발되고 있다 대부분의 자바 애플리케이션은 스프링으로 개발되었다.

 

스프링 코드가 대부분 자바를 기반으로 해, 자바 베이스 스프링 부트는 많은 이점이 있다. .자바로 작성된 예제 코드, 샘플 프로젝트, 시작하기 가이드 등 다른 언어에 비해 작업이 훨씬 수월하다.

 

코틀린🌱

코틀린은 2010년 JetBrains에서 개발해, 2011년 공개된 최신 언어이다. 자바의 사용성을 개선하기 위해 만들어졌으므로 설계 초기부터 다음 사항을 고려하여 개발되었다.

 

• 간결함
• 안정성- null 값의 가능성을 사전 제거
• 상호 운영-기존의 모든 JVM, 안드로이드, 브라우저 라이브러리와 제약 없이 호환해 사용
• 도구 친화성- 수많은 IDE 또는 명령줄로 코틀린 애플리케이션 빌드

코틀린은 간결하고도 유연한 언어이다. 확장 함수, 중위 표기법 등 문법적 특징이 있다. Language with language를 정의하여, API 설계에 큰 도움이 된다. 간결함의 특징 덕분에 자바 베이스 스프링부트 코드보다도 더 짧고 읽기 쉬우면서도, 전달력을 그대로 유지한다.

 

자바 vs 코틀린

둘 중 뭘 쓰는게 좋을지 열심히 고민하고 있었는데...

 

그냥 둘 다 쓰면 되는거였다.

 

코틀린은 자바와 동일한 JVM 바이트코드 출력으로 컴파일되며, 하나의 프로젝트 안에서 자바 소스와 코틀린 파일을 함께 사용하는 것도 가능하다. 스프링 프로젝트 안에서 자바와 코틀린 컴파일러를 함께 호출할 수 있기 때문에 두 마리 토끼 모두 잡기🐇🐇가 가능하다. 

 

결국 자바와 코틀린 둘 중 어느 언어를 쓸 것인지는 취향의 문제인 것 같다.

 

나는 자바는 알고, 코틀린은 거의 모르는 상태이다. 하지만 자바도 배우기만 했지 안쓴지 2년이 다 되어가고, 또 자바는 내가 제일제일제일 싫어하고 극혐하는 언어이다. 고작 hello world를 출력하기 위해 system.out.println이라는 개 긴 문장을 써야 하는게 킹받기 그지없다. 

코틀린은 거의 모른다고 봐도 무방한 수준으로 기본 문법만 알지만, 그래도 새로운 도전 하는 셈 치고, 마침 입문서도 있으니 코틀린을 사용해보려고 한다.(물론 실습은 자바로 따라할거지만,,,,따로 공부하자 코틀린) 

 

버전 선택하기

버전 선택하기 챕터가 있어서 백엔드 인구들은 어떤 싸움을 하는거냐...라고 놀라고 있었다. 프론트엔드 프로젝트를 할 때는 특별한 이유가 없다면 거의 @latest이고, 따로 버전을 선택한 적은 거의 없기 때문이다. 최근 react 19와 일부 라이브러리 호환 문제 때문에 다운그레이드한 경험은 있지만 의도적으로 버전을 명시하여 사용한 경험은 거의 없었다.

 

근데 아니나 다를까 스프링부트도 극히 일부 예외나 임시 상황을 제외한다면, 실제 프로덕트로 배포되는 애플리케이션은 항상 현재 버전의 스프링 부트를 사용해야 한다고 한다. 물론 나는 학습 용도로 사용하기 때문에, 교재에서 사용하는 버전(꽤나 오래됨)을 사용하여 실습을 진행하고 있다.

---

간단하게 스프링 부트 애플리케이션 개발에 사용할 설정들을 알아보았다. 각 방식의 장단점을 알고, 선택을 할 수 있었다. 실습 환경에서는 Java를 사용하고,  gradle-groovy를 사용하고 있지만, Maven과 Kotlin이 더 마음에 드는 것 같다. 책을 따라서 실습을 진행하되, 코틀린을 병행하는 방향으로 공부해봐야겠다. 진짜 자바 너무 싫움