jar과 war

예정이라면 저번 글 이후에 바로 작성하려 했지만

복용 중인 약 효과가 너무 강해서 그대로 잠드는 바람에 인제야 작성해본다.

이 글을 올리기 바로 전 Build에 대해 알아봤는데

읽지 않은 분을 위해 다시 한 번 짚고 넘어가겠다.

build 란?

'코드를 작성 후 컴파일해서 오브젝트 파일을 생성하고, 링킹 작업으로 실행 파일을 jar과 같은 라이브러리 파일로 만드는 것' 

위에 문장을 보면 익숙하게 접했던 컴파일, 오브젝트 파일 등이 보이고

링킹과 jar은 웃기게 들릴 수도 있겠지만 처음 듣는 단어였다.

그래서 저 문장을 나름 내 언어로 해석해보려고 고민하기 시작했는데....

느낌은 알겠으나 저것들을 뭐라고 말해야 할지 모르겠더라.

그래서 한번 찾아보고, 정리해보기로 했다.

일단 맨 처음으로 jar이다.

jar이란?

여러 개의 자바 클래스 파일과 클래스들이 이용하는 관련 리소스(텍스트, 그림 등) 및 

메타데이터를 하나의 파일로 모아서 자바 플랫폼에 

응용 소프트웨어나 라이브러리를 배포하기 위한 소프트웨어 패키지 파일 포맷

이라고 위키 백과에 나와 있다.

정확하게 저게 무슨 소리인지 모르겠지만 확실한 건

jar은 zip같은 압축 파일의 일종이라는 것이다.

아니 이미 ZIP라는 파일 포맷이 있는데 그냥 그거 쓰지 왜 굳이 jar을 만든 걸까?

문득 궁금증이 생긴 나는 내 친구 구글에 검색을 해봤다.

그러고 나서 여러 정보를 종합해본 결과

들어갔던 블로그의 글에 따르면

zip은 일반 파일 압축이고,

jar은 class 파일 압축이며

war은 웹 애플리케이션을 통째로 압축 하는 것이라 한다.

더불어 개념적으로는

class < jar < war < ear이라는데.....

<여긴 어디이고 나는 누구인가?>

난 분명 jar만 알고 싶었는데 war과 ear이라는 것까지 나왔다.

왠지 모르게 글을 그만 작성하고 싶어지는 마음이 들기에

초심으로 돌아가 마음을 다지며 꽤 많은 정보를 읽고 접했으니, 이제 본격적으로 살펴보자.

일단 java로 개발한 application을 배포할 때 jar 혹은 war 형태로 배포하게 되는데

이 두 개는 완전히 같은 형식을 가지고 있으나

jar[Java Archive]은

라이브러리나 일반 application을 배포하는 형식이고,

war[Web Application Archive]은

web application을 배포하는 형식이다.

마지막으로 ear[Enterprise Archive]은

하나의 웹 어플리케이션 단위를 넘어 실제 서버 배포를 위한 단위를 말한다.

조금 더 자세히 말하자면

zip의 경우 압축을 풀지 않으면 실행할 수 없기 때문에

zip의 알고리즘으로 설계된 jar와 war을 사용하게 되었는데

jar은 java class 파일들이 주로 이루어져 있고,

war은 jsp나 servlet, gif, html, jar 파일 등 웹과 관련된 파일을 가지고 있으며,

ear은 엔터프라이즈 애플리케이션에 필요한 jar이나 war 같은 모든 파일을 포함한다는 것이다.

 거기다

jar은 기본적으로 path등의 경로를 유지하기 때문에 배포된 파일 사용자들은 path 문제에서 벗어날 수 있는 데다가

war은 웹 애플리케이션 전반적인 파일을 가지고 있기에 jar도 포함되어 있다고 한다.

한마디로

jar -> 웹으로 배포하지 않은 java class 파일과 EJB 파일

war -> 웹으로 배포되는 모든 파일[jar 포함]

ear -> jar이나 war같은 모든 파일

이라는 것 같다.

대충 여기까지 알아봤으니 이만 jar과 war에 대해서는 마무리하고, 

공부하던 중 보게 된 흥미로운 글에 대해 잠시 이야기 하고자 한다.

과거 클라우드 서비스를 사용하기 전 현업에서는

war 파일을 이용하여 업데이트를 진행했는데

war을 구동하기 위해서는 필요한 시스템 라이브러리가 많아지고, 그 자체로도 거대해지는 데다가

이미지 크기가 크면 클수록 다음 업데이트를 위한 빌드나 새로운 시스템 컨테이너 기동 등에 있어.

다양한 비효율이 발생한다고 한다.

그래서 그런 비효율을 줄이기 위해 shared의 라이브러리들을 모두 static 하게 추가되는 형태로 발전되었고,

spring boot를 사용하여 was를 `임베드`하고

그 외에 필요한 spring 의존성이 모두 함께 jar로 패킹되는 방식을 사용하고 있는 데다가,

war보다 jar 파일은 jvm 머신이 설치만 되어있다면 어디에서든 동일하게 동작하는

애플리케이션을 가질 수도 있고, 거기다 war보다 가볍기까지 하다는 내용이었다.

위에 이야기로 추측해보자면

과거에는 업데이트할 때, war 파일로 이미 올렸던 이미지나 그런 모든 부분에 대해 전체적인 업데이트를 했다면

지금은 기본적인 틀이 되는 파일은 war 파일을 `임베드`해서 유지하고, 업데이트되는 부분만 jar 파일로

변경해주는 방식인 것 같다.

물론 정확하지 않고, 이 부분에 대해서는 추가로 알게 되면 수정하도록 하겠다.