스프링부트로 프로젝트를 시작하고 개발을 조금 하다 보면 application.properties 파일의 존재를 알게 된다.
오늘은 여기 있는 Dependencies에 대해서 알아보도록 하자
Dependencies에 관심을 가지게 된 이유는 요청을 Jackson 라이브러리는 어디에 있는지? 그리고 마법의 라이브러리 lombok을 사용하기 위함이었다.
간단하게 아래 사진처럼 요청이 들어오고 나가는 과정을 거친다. 빨간색으로 처리된 부분을
이전 글에서도 언급했었던 직렬화, 역직렬화 내용이다.
중요하니까 한 번 더 정리하고 넘어가자
- Serialization : 직렬화 → 객체 → 텍스트(사람이 볼 수 있는 형태로, Csv, JSON …), 바이너리
@RequestBody어노테이션에서 도와준다.
- De-Serialization : 텍스트, 바이너리 → 객체 이 과정은
@ResponseBody어노테이션에서 도와주기 때문에 없다면 원하는 결과를 얻을 수 없을 것이다.
엥? 난 @ResqonseBody 어노테이션을 달아준 적 없는데? 한다면
@RestController 를 내부에 포함되어있다.
Converter는 누가 만들어준거지?
나는 MessageConverter와 같은 것을 만들어 준 적도 설치한 적도 없는데,
처음 프로젝트 생성할 때에 Spring Web가 맵핑 라이브러리인 Jackson 라이브러리가
설치되어 자연스럽게 사용할 수 있게 되었다.
lombok 추가하기
드디어 lombok 내용인데 롬복을 사용하기 위해서 라이브러리를 추가하다가 이 글을 쓰게 됐다.
롬복이 어떤 기능을 하고 어떤 처리를 하는지를 깊게 다루는 글이 아니기에 lombok이 궁금하다면
다음에 정리할 예정이니 기다려주세요~
롬복을 사용하기 위해서는
application.properties > dependenices에 추가를 해야 한다.
무엇을 어떻게 어디서 구해서 추가할까요?
🔗https://mvnrepository.com/search?q=lombok
롬복을 사용하고 싶어서 초기 세팅에서 추가하지 않았다면 위 레퍼지토리에서
원하는 버전을 찾아서 추가해주면 된다.
위 사이트에서 나는 lombok을 검색했고 뭐가 많이 나오는데 Proect lombok이
가장 사용된 수가 높아서 사용하게 됐다. (높은 사용자는 신뢰감을 준다… 아마도?)
개발자들은 특히 나는 아마추어라 최신 버전을 사용하는 것이 무섭기 때문에, 자연스럽게 또 나는 usages 가장 높은 1.18.24를 선택했다.
선택하면 위와 같은 페이지를 볼 수 있는데 딱 봐도 compileOnly~ 요렇게 적혀있는 내용이 있는걸 보고
뭔가 익숙한데 하면서 다시 인텔리제이 properties 파일을 확인했다.
Dependency Configuration!?
라이브러리들을 관리하는 Dependency Configuration이다.
Implementation, testImplementation … 등등 다양하게 많은데 뭔가 방금 Maven Repo에서 찾은
compileOnly ~ 내용을 이곳에다가 추가하면 될 것만 같은 기분이 든다.
하지만 롬복은 추가 설정을 해주어야 하지만 이 글은 Dependency를 정리하는 글 이니까 설치 얘기는 스킵!
다시 왜 Implementation, testImplementation 들이 나뉘어 있는데 나는
뭐든 세분화해서 나눠두면 가독성, 유지보수, 효율성을 개선을 목적이라고 생각한다.
그래서 좀 알아보려고 한다.
compileOnly
말 그대로 컴파일할 때만 사용되는 compileOnly이다.
컴파일에서 사용되는 건 뭐지? 그러고 보니 lombok을 compileOnly로 설정했던 거 같은데?
롬복으로 알아보자
롬복이 제공하는 기능 중 Getter, Setter를 간편하게 제공하는 기능이 있다.
그럼 컴파일 시에만 사용하니까 Getter,Setter는 런타임에서는 사용이 안 되는 거 아니야?
내가 실행한 서버가 정상 작동 안 하는 거 아니야?
응 아니다!
자바는 컴파일을 마치면 .class 파일을 생성하는데
@Getter , @Setter 를 붙여둔 파일을 확인했다.
어노테이션은 사라지고 내가 작성하지 않은 게터, 세터가 생겨있었다.
최근 롬복 버전에서는 @Generate 어노테이션도 붙는다고 한다.
그래서 런타임 시에도 잘 처리될 것이다.
아니 그럼 이렇게 게터,세터 만들어서 넣는 거면 이게 런타임까지 가져가는 거 아니야?
runtime 시점까지 가져간다는 것은 라이브러리가 런타임 시에도 필요하다는 것인데
롬복은 컴파일 시에 자신의 역할 게터,세터 생성 목적을 이뤘기에 가져갈 필요가 없다.
그냥 다 implementation 하는건 어떤데?
implementation은 추가로 설명하겠지만 컴파일, 런타임시 모두 필요하다는 것이다.
귀찮으면 다해도 되겠지만 누가 봐도 런타임에 사용되지 않을 , 컴파일 시에는 사용되지 않을
것을 가지고 있는 건 비효율적이다.
롬복으로 두 개의 차이를 실험해보고자 했다!
가장 직관적으로 차이를 볼 수 있게 빌드시켜 얻은 Jar 파일의 메모리 크기를 비교해보았다.
2MB 차이가 있음을 알 수 있었다.
빠른 배포, 빠른 빌드를 위해서는 메모리가 낮은 게 좋겠죠?
이렇게 알 수 있듯이 CompileOnly는 jar에 포함되지 않아 가벼워진다.
runtimeOnly
compileOnly와 달리 runtime시에만 사용되도록 하는 옵션이다.
이 옵션을 사용하면 프로젝트 빌드 시점에 사용되지 않기 때문에 컴파일, 빌드 속도가 더 빨라진다.
compileOnly 처럼 테스트를 하는 날이 온다면 추가하도록 하겠습니다~
어떻게 Gradle은 이렇게 나눠서 실행해줘요?
인텔리제이 기준 우측 코끼리를 눌러 확인하면 Dependencies를 확인할 수 있다.
여기서 compileClasspath, runtimeClasspath를 나누어 실행을 관리한다.
implementation
라이브러리가 컴파일, 런타임 시점 모두 필요한 경우에는 implementation 옵션을 선택한다.
이런 옵션들을 Main과 Test로 구분해두었기에 Test에서도 필요한 또는 Test에서만 필요한 라이브러리라면
앞에 Test를 붙여서 위에서 설명한 적절한 옵션을 선택해서 사용해야 한다.
