[퍼옴] 실행 속도에 도전하는 Java 아키텍처의 변천 - JAVA 개론

출처 : http://www.jspgeek.com/tt/index.php?pl=17426&PHPSESSID=18639be6718deed229e55fb4b90c6897


Java의 역사는 Java의 실행 환경인 Java VM의 실행 속도에 대한 도전의 역사였다고 해도 과언은 아니다. 어떻게 하면 더 빨리 실행할 수 있을까 고민하는 Java VM이 걸어온 그 길에서 아키텍처의 변천사를 살펴보면, Java VM에 대해서 더욱 깊이 이해할 수 있는 기회가 될 수 있을 것이다.

Java의 역사

Java는 1995년 5월 23일에 개최된 「Sun World Expo」의 디벨로퍼 컨퍼런스에서 공개되었다. 「Java 탄생의 페이지」에 의하면 이날이 Java의 생일이라고 되고 있다. 썬마이크로시스템이 말하니까 틀림이야 없겠지만, 원래 Java의 전신은 Oak라고 하는 언어였다. Oak는1990년 12월에 시작된 Green Project의 일환으로서 개발된 언어이다. 하지만, Java는 1995년에 태어났으니까 Oak가 탄생한 1990년에 벌써 태어날 준비를 하고 있던 것이나 다름없다.

우리에게 친숙한 마스코트 "Duke"도 이 Green Project의 "중요한 부산물"이라고 Green Project의 홈페이지에 게재되어 있다. 가전업계의 열악한 자금 환경으로 받아들여지지 않았다고 한다. 실제로 Green Project의 주 성과물인 "*7"(StarSeven：대형 PDA라고도 한다.)도 햇빛을 보지 못한 것이 사실이다. 물론, 여러 가지 비즈니스적인 사정 때문에, 또는 단지 운이 없었다고 하는 견해도 있을 수 있다. 그러나, 그 크기, 무게를 생각하면, 그 것을 한 손에 쥐고 조작할 수 있는 체격은 미국인밖에 없을 것이다.

여담은 접어두고, 언어로서 Oak의 계보를 굳이 표현하자면, 아버지는 C++, 어머니는Smalltalk(interpreter라고 하는 관점에서)를 들 수 있겠고, 물론 객체 지향언어의 정통이라고 하는 사람도 있을 수 있다. (아버지가 Smalltalk로 어머니가 C++ 일까? 아니, 아버지가 C++, 어머니가 Green Project이다!). Gosling씨에 의하면, Oak는 lisp나 다른 언어에도 영향을 받았다고 한다. 초기의 Oak 매뉴얼에 따르면, Green Project의 페이지에 가면 PostScript(그립다!)의 Ver0.2을 다운로드 할 수 있다고 한다.

1995년 5월에 탄생한 Java는 1996년에 개최된 「JavaOne」에서 소개되었으며, 80 이상의 협찬 기업과 5000명 이상의 참가자로 대성황을 거두었다. 이 행사는 OpenSurce 플랫폼을 사용하면서, 포인터를 중시하고 있는 개발자들에게 오브젝트 언어가 Web의 개발 환경에 얼마나 딱 들어 맞는지 보여주는 상징적인 일이었다.

역사적으로 보면, Java의 당초 생각들은 Gosling씨의 홈페이지에 있는 Java 탄생 당시의 「original Java White Paper」에 기재되어 있다. 이 정책에 따르면 James Gosling씨가 Green Project에서 가전제품에 내장시키기 위한 용도로 Oak를 사용했으며, 현재에 이르기까지 그 정신은 아직 살아 있다. 아래와 같은 것이다. (편집: 현재, Gosling씨의 홈페이지는 폐쇄되고 있다. original Java White Paper는 현재 다음 URL로 참조할 수가 있다. 「Focus on Java：on Overview, original Java White Paper by James Gosling」).

(1)Simple

　　 프로그래머에게 단순해야 알기 쉽다.

(2)Object-Oriented

　　 객체 지향적이다.

(3)Distributed

　　 분산 오브젝트이다.

(4)Robust

　　 안정하다.

(5)Secure

　　 안전하다.

(6)Architecture Neutral

　　 시스템 환경에 독립적이다.

(7)Portable

　　 데이터 타입이 통일되어 있다.

(8)Interpreted

　　 Java의 코드를 번역하면서 실행한다.

(9)High performance

　　 메모리 효율, 동작 속도가 고성능이다.

(10)Multithreaded

　　 multi-thread이다.

(11)Dynamic

　　 실행 시에 동적으로 클래스를 로드한다.

위의 11개 항목은 White Paper에 번호 없이 쓰여져 있다. 앞으로, 이 "위대한 정신"의 항목에 따라, Java VM의 아키텍처 변천을 설명하겠다.

Simple, Object-Oriented, Distribute

Java는 포인터를 사용하지 않는 언어로써, 프로그래머가 메모리 관리를 생각하지 않아도 되어 편리해졌다. 구문도 매우 명쾌하다. 그리고 C++의 객체 지향을 계승하고 있다. URL을 지정해 원격의 오브젝트에 접근할 수 있다. 이런 기능들이 분산오브젝트 환경에 딱 들어 맞는 것이다.

White Paper에는 없지만, 네트워크상의 다른 시스템에 있는 오브젝트를 호출하는 분산 오브젝트 환경에 포인터를 사용하게 되면 머리가 아플 수도 있다. 여기서 Java 밖에 모르는(포인터를 모르는) 운(?)이 좋은 독자를 위해서, 포인터에 대해서 설명을 해 보자. 포인터란, 변수에 값이 대입된다는 개념에서, 컴퓨터의 메모리와 주소의 관계를 실현한 것이다. 우선 변수에 메모리의 주소 값을 대입해 둔다. 그리고, 그 주소에 저장되어 있는 메모리 내용을 참조할 수 있도록 한다. 이 도구가 바로 포인터이다. 포인터 자체의 형태는 포인터형이라고 알고 있지만, 포인터에 저장되어 있는 주소에 어떤 형태의 값이 저장되어 있는지 모른다. 즉, 데이터를 저장했을 때의 형태를 기억하지 못하기 때문에, 포인터는 취급할 수 없는 것이다. 게다가 주소가 가리키는 메모리에 대한 형태는 다이나믹하게 지정할 수 있다. 이런 사항들은 분산오브젝트에서는 곤란한 문제를 가져오게 된다. 예를 들면, 어느 프로그램이 다른 시스템에 있는 오브젝트를 호출하려고 한다. 그 오브젝트에 포인터가 있을 경우, 호출하는 프로그램은 상대방의 시스템의 오브젝트를 만질 수 있는 모든 메모리를 하나하나 카피해 오지 않으면 잘 작동하지 않게 된다.

옛날, CORBA라고 하는 분산 오브젝트 브로커는 OMG라고 하는 컴퓨터 산업의 실력가로 이루어진 컨소시엄에 의해서 탄생하였다. 그 중 C++은 네트워크에 분산된 오브젝트를 참조할 때 메모리 카피의 책임이 프로그래머에게 있었기 때문에, 개발자에게는 부담이 많았다. 프로그래머가 아무렇지도 않게 포인터를 사용할 경우, 네트워크상에 대량의 메모리 전송을 일으켜 버릴 수도 있다. 게다가 그 오브젝트의 라이프 사이클, 메모리의 확보, 릴리스 등이 원격이라고 하는 것을 의식해 프로그래밍하지 않으면, 메모리 어플리케이션이 종료하기도 한다. 물론 서버측도 그 위험에 처하기 마련이다.

포인터의 개념이 없는 Java에서는, 이러한 일이 모두 일어나지 않는다. 컴파일러가 포인터를 허락하지 않기 때문이다. CORBA 스팩에서도 Java의 임플리멘테이션이 있다. Java에는 RMI라고 하는 네트워크 원격 오브젝트를 호출하는 스팩이 있어, 쉽게 이용할 수 있다. 지금, 전성기인 J2EE 스팩, SOAP 등에 있어도 말이다. 이것은 곧, Simple, Object-Oriented, Distributed라고 하는 사상이 포함되어 있었기 때문이다.

Robust, Secure, Architecture Neutral, Portable

안정, 안전, 아키텍처 독립, 휴대용이라고 하는 개념은, 다양한 기종, OS, 언어환경이 혼재하는 인터넷에서는 필수 불가결한 요소이다. 메모리 관리를 프로그래머에게 강요하지 않기 때문에 '안정성'을 확보할 수 있다. 인스턴스가 없는 오브젝트를 참조하면 null exception 오류가 발생하는데, try-catch구문으로 둘러싸면 프로그램으로 처리도 가능하다. 메모리를 직접 액세스할 수 없기 때문에, 이를 악용해 PC의 부트 레이어에 불필요한 코드를 심으려고 해도 불가능 하다.

White Paper에서는 Secure 구현 정책으로 virus-free, tamper-free를 제창하고 있다. 현실 세계의 브라우저에서는 여러 구멍이 발견되고 있는 것이 현실이지만, 이상적인 목표로는 virus-free, tamper-free이다.

인터넷으로 연결되어 있는 시스템의 데이터, 실행 형식을 의식하지 않는 것이 분산 오브젝트의 필수 조건이다. 이런 생각이 Architecture Neutral, Portable이다. 예를 들어, 프로그래머가 이 오브젝트는 이 메이커의 시스템에서 실행되므로 정수는 16bit가 되어야 해. 그러니까 이쪽의 시스템에서 보내는 변수는 16bit 이하로 떨어뜨려 두지 않으면…… 이라고 생각하는 것은 모든 종류의 시스템이 접속된 인터넷상에서는 불가능에 가깝다.

Interpreted

드디어 구현의 이야기 차례이다. Interpreted란, 번역해 실행한다는 의미다. 포인터의 개념을 배제하였기 때문에, 메모리 관리의 책임을 언어측면에서 흡수하기 위해서는, 메모리 관리를 실행 환경에서 제공해야 한다. 이와 더불어, 플랫폼 의존성을 배제하고, 어느 시스템에서나 동일하게 동작하고 데이터도 플랫폼에 의존하지 않는 통일된 표현을 유지하기 위해서는, Smalltalk와 같은 interpreter 방식을 사용하는 것이 좋다.

interpreter의 상대어로 컴파일러가 있다. 컴파일러는 미리 자연 언어에 가까운 원시코드를 CPU가 즉시 실행할 수 있는 기계어로 번역해, 나중에 한번에 실행하는 것이다. 그에 반해 interpreter는, 원시 코드를 읽으면서, 순서대로 실행한다. interpreter의 시초라고 하면 Bill Gates가 만들었던 BASIC이라고 생각한다. Java는 BASIC과 달리, 원시 코드를 한 번 아르바이트 코드라고 하는 중간 코드로 번역하고 나서, 그것을 interpreter가 실행하게 되어 있다.

그런데, Java와 같은 중간 코드 방식의 interpreter는, Java가 최초이다. Smalltalk라고 말할 수도 있겠지만 그렇지 않다. 세상의 연구자의 논문을 닥치는 대로 읽어 보지 않으면 정말로 무엇이 최초 인가, 올바른 결론은 나오지 않는다. 그러나, 상용 여부와 대중적인 의미에서 그 시작을 찾아보면 UCSD Pascal이라고 생각한다. 1970년대 초의 마이크로 컴퓨터 시대는, 메모리가 매우 고가여서 CPU는 쓸데없이 늦은 기기가 될 수 밖에 없는 환경이었다. 그런 가운데, 구조화 프로그래밍과 풍부한 포맷 선언을 가졌던 UCSD Pascal의 중간 코드 컴파일 방식은, 개발자 NiklausWirth 박사의 "언어스팩과 최적화는 독립된 문제이다"라고 하는 논의를 증명하기 위해서 만들었다고도 한다. 그러나, 실제로 임플리멘테이션 측면에서는 꽤 유리했다.

중간 코드 컴파일러란, 자연 언어에 가까운 프로그램 언어를 언어스팩에 의존하지 않는 가상 시스템용의 코드로 한 번 변환하는 것이다. 중간 코드 인터프리터는, 이 코드를 실제 시스템상에서 실행되는 프로그램으로 해석하면서 실행한다. 원시 코드를 직접 코드에 포함하지 않음으로써 메모리 효율을 극대화시키셔, 작은 메모리에서도 실행할 수 있게 된다. 게다가, 이 중간 코드를 번역해 실행하는 프로그램마저 만들어 버리면, 어느 시스템에서도 실행할 수 있게 되는 것이다. 이 중간 코드는 기계어에 가까운 형태로 되어 있어서, 번역해서 실행하는 프로그램도 간단하고, 성능도 괜찮게 나온다.

실제로, 자연 언어에 가까운 프로그램 기술인 Java 언어를 *.java 파일로 작성하고 javac 커맨드로 컴파일해서 아르바이트 코드인 *.class 파일을 만들어 낸다. java.exe는 이 아르바이트 코드를 번역하면서 실행한다. 이런 흐름은 UCSD Pascal과 완전히 똑같다. 게다가 Java의 경우, 아르바이트 코드의 효율화를 생각해서, ZIP으로 압축되어 있기도 한다. CPU와 메모리의 관계와 비교하면, 인터넷의 통신 속도나, 디스크의 I/O 속도가 더 늦다. 그러므로 CPU로 ZIP으로 압축해 전송 량을 줄이던지, 압축을 하지 않고 CPU의 부하를 저하시키던지 의 선택에서 전자를 선택하는 것은 당연하다고 할 수 있다.

아르바이트 코드를 번역해서 실행하는 형식(/opt/java/bin/java라든지 java.exe)을 Java Virtual Machine(Java 가상 시스템, 이하JVM)이라고 한다. 여러 가지 기종의 여러 가지 OS로 JVM을 만들어 버리면, 어느 시스템에서도, 완전히 똑같은 아르바이트 코드를 실행할 수 있게 된다. 아르바이트 코드가 취급하는 데이터는 어느 시스템에서도 동일한 것으로서 취급할 수 있다. 아르바이트 코드가 어느 정도 기계어에 가까우면 실행도 가벼운 법이다. 번역해서 실행하기 때문에, 메모리의 부정 사용이 있으면, 번역한 시점에서 에러 처리를 할 수 있다. 이로써, 프로세스가 갑자기 죽는 일은 없어진 것이다. 이렇게 해서, 인터넷에서 요구하는 모든 요건들이 JVM이 등장함으로써 단번에 해결된다.

High Performance

기종에 의존하지 않는 가상 시스템이 전부는 아니다. 역시, 타겟 시스템 CPU에 맞게 컴파일을 해서 직접 실행할 수 있는 기계어에 비하면 퍼포먼스가 떨어지게 된다. 왜냐하면, 파싱하는 시간만큼 오버헤드가 되어, 실행속도가 떨어지기 때문이다. 이외에도, Java의 경우, 실행 시에 정의된 변수의 메모리 영역도 정리해야 한다. 즉, 로컬변수에 값을 대입하려면, 그 변수를 위한 메모리를 확보한 후 거기에 대입하고 싶은 값을 저장하게 된다. 그리고, 변수는 언젠가는 사용하지 않게 되므로 뒤처리를 해야 하는데, 하나 하나 그 자리에서 처리하기 때문에 성능 향상을 바랄 수 없다. Java에서는 가비지 콜렉션을 도입하고 있다.

HotJava 브라우저에서는, 애플릿을 움직이고 있었고 이 정도이면 위의 방식으로도 충분했다. 실제로, HotJava 브라우저의 Duke 애니메이션은 잘 되어 있어서, 처음 보았을 때는 대단하다고 생각했다. 가비지 콜렉션이 동작하고 있을 때는 조금 멈추지만, 그런 것은 애교 정도로 봐줘도 무관하다. 그러나, 오늘날에는 이러한 오버헤드는 위험하다. 왜냐하면, 초당 몇 천 개의 request를 실수 없이 처리해야 하기 때문이다.

JIT의 등장

앞에서 소개한 퍼포먼스의 문제를 해결하기 위해서 등장했던 것이 JIT(Just In Time Compiler：실행 시 컴파일)다. 이것은, 클래스가 필요할 때마다, 중간코드로부터 기계어로 컴파일해서 실행한다는 발상이다. 당연한 말이겠지만, 실행 시에 컴파일러가 기계어로 번역하기 때문에 최초로 실행할 때는 시간이 약간 걸리게 된다. 객체 지향 언어에서는, 오브젝트를 초기화하는 메소드를 정의할 수 있다. 이 정의는 constructor라고 하며, 오브젝트를 준비하는 부분이다. 컴파일은 첫 회 즉 해당 오브젝트가 만들어질 때 동작하므로, constructor가 실행될 때 속도가 떨어진다. 여러 가지 오브젝트를 자주 바꿔가며 사용하는 경우에는 컴파일이 무거워져 버린다는 결점이 있지만, 보통 인터넷 어플리케이션은 반복이 많기 때문에, interpreter에 비하면 충분히 빠르게 된다. 아마도, 반복이 전혀 없는 직선 도로와 같은 프로그램은(만드는 것도 어렵겠지만) interpreter가 더 빠를 것이다.

기계어로 컴파일되면 이식성이 없어질 거라 생각할 수 있지만 그렇지 않다. 컴파일된 기계어는 메모리로 올라가고 사용될 때를 제외하고는 로드되지 않는다. 즉, java.exe의 실행이 끝나면 없어져 버린다. 다른 UNIX 시스템으로 기동할 때는, 그 시스템의 새로운 기계어가 사용되므로, 이식에 문제는 발생하지 않는다. 물론 취급하는 데이터의 형식도 유지되므로 걱정할 필요가 없다.

JIT는 컴파일된 기계어의 성능보다는 컴파일에 필요한 시간이 중요한 사항이다.

가비지 컬렉션의 개선

Java는 확보된 메모리의 릴리스를 JVM이 자동적으로 실시한다. 이 기능을 가비지 컬렉션이라고 부른다. 그리고, JVM이 사용하는 메모리는 실행할 때 지정한다(이 영역을 heap 이라고 한다). 초기의 Java에서는 heap을 대충대충 사용하였다. 빈 곳이 없으면 정리해서 릴리스하였다. 즉, 사용하고 있지 않는 곳을 사용할 수 있게 한다는 것이다. 작은 메모리에서 동작시키면, 정리해서 릴리스한다고 해도 메모리 영역이 금방 차 버린다. Heap 사이즈를 크게 잡아주면, heap이 없어질 때까지 순조롭게 움직이다가 조금 멈추고 그리고 다시 작동하게 된다. 즉, 이 가비지 컬렉션 때문에 병목현상이 발생하게 되는 것이다.

꼭 Web 어플리케이션 프로그래머가 아니라도, 로컬 변수를 임시로 사용하는 경우도 있고, 꽤 오랫동안 오브젝트로 유지해야 하는 경우도 있을 것이다. 이 두 가지를 메모리 매니지먼트 영역에서 함께 관리하는 것은 좋지 않다.

그래서, New와 Old로 heap의 내용을 2개로 나눈 구조가 등장하게 된 것이다. 단기적으로 참조되자 마자 필요 없게 되는 변수는, New의 heap에 놓고, 빈번하게 릴리스시킨다. 한편, 어느 정도 오랫동안 메모리에 있어야 하는 변수는, Old의 heap에 놓고, 가득 찼을 때에 릴리스시킨다. 이 Old가 가득 찼을 때에 일어나는 가비지 콜렉션을 Full GC라고 부른다.

HotSpot의 등장

heap의 개선은 Web 어플리케이션 서버 실행에 긍정적인 영향을 미쳤다. 이와 동시에, Web 어플리케이션 서버는 더욱 많은 클래스를 사용할 수 있게 되었고, 프로그램도 거대하게 되었다. 이와 같이 거대한 어플리케이션에서는, JIT와 같이 새로운 클래스를 실행할 때마다 컴파일하게 되면 시간이 걸리기 때문에, 이것도 좋지 않은 방식이다. 아무리 JIT가 고속으로 컴파일한다고 해도 오버헤드가 크게 발생하기 마련이다. 그런데, 해석하는 도중에 프로파일을 취해, 특히 많이 사용되는 부분만 컴파일하고 나머지는 가만히 두면, 좀 더 빨라지지 않을까? 맞는 말이다. 이런 방식이 바로 HotSpot이다. 이 기술은 휴렛팩커드(이하 HP)가 JavaSoft에 제안해, 현재 실행되고 있다. 아~ JavaSoft는 언제 오픈 되었단 말인가!

많은 어플리케이션에서 전체 처리의 20%가 실행 시간의 80%를 차지하는 경우가 많다. 옛날, CISC 시스템과 RISC 시스템 중 어느 쪽이 더 우수하냐는 논쟁이 있었는데, HP가 재빨리 RISC를 상용화했다. 이것은, CISC 시스템에서는, 실행 시간의 대부분을 일부의 명령 세트를 실행하는데 소비되고 있어, 다른 복잡한 명령 세트를 처리하는 데는 나머지의 몇 안 되는 시간만을 사용하게 되었다. 그렇다면, 실행 시간의 대부분을 소비하고 있는 명령세트를 고속화해서, 복잡한 명령 세트를 여유 있게 실행하면 어떨까? HotSpot이 이와 같은 형식이다.

예전에 C와 Java 중 어느 쪽이 더 빠른가? 라는 질문에, 최적화 파라미터를 지정해 잘 컴파일 된 C보다 Java가 더 빠르다는 대답을 한 적이 있다. 포인터를 잘 사용한 프로그램에는 이길 수 없겠지만, 아마추어가 단지 최적화 옵션을 지정해 컴파일 한 C의 계산 프로그램과 Java를 비교하였을 때, Java가 빠르다는 예가 실제로 있었다. 몇 번이나 interpreter로 실행한 후, 프로파일을 취득해서, 이것을 기본으로 컴파일 하므로, C로 말하자면, prof 데이터를 기본으로 컴파일하는 "최적화 컴파일"과 같은 효과를 가져온다.

최근 Intel의 Itanium에서 사용하고 있는 기술인 EPIC(Explicitly Parallel Instruction Computing：명시적 병렬 명령 컴퓨팅)에서는, 컴파일 시에 최적화해, 내부 레지스터를 낭비 없게 사용해, 고성능을 발휘한다. HotSpot 기술과 매우 비슷하다. HP는 Itanium을 탑재한 HP-UX시스템에 HotSpot을 구현한 JVM을 벌써 릴리스 했으며, 높은 성능을 실현하고 있다.

그럼, 최초의 컴파일 시에 프로파일 데이터를 뽑도록 지정해서, 테스트 Run을 한번 실행해서 이러한 정보를 얻을 수 있다. 그 결과를 최적화 컴파일에 반영한다. 이는 고도의 컴파일 테크닉이다. 그렇지만, Java에서는 적당하게 해도 자동적으로 해 준다. 계산에 사용한 시나리오가 바뀔 경우, C++에서는 prof를 고쳐 컴파일을 다시 하지만, Java에서는 단지 실행만하면, 그 때에 응한 코드를 다시 얻을 수 있다.

HotSpot과 heap의 개선은 JDK(Java Development Kit) 1.3.x부터 실현되었다. 그렇게 해서, EC 사이트에서 Java를 성능의 저해없이 이용되기에 이른 것이다. HP의 Itanium용 JDK의 최신 버전은 1.4.2이다.

Multithreaded (multi-thread)

HotJava와 같이 동영상을 취급하는 브라우저에서 multi-thread는 필수 요건이다. 1개의 동영상이 움직이고 있는 동안에 다른 버튼의 조작을 할 수 없다고 하면, 완전히 쓸모가 없기 때문이다. 물론, 요즘에는 Web 어플리케이션 서버에서 복수의 request를 multi-thread로 병행하기 때문에 필요 불가결한 요소이다. 당초의 Java에서 multi-thread는 모두 JVM으로 실현되고 있었다. interpreter가 타임 쉐어링을 통해서 가상적으로 복수의 thread를 동작시키게 되어 있었다. 이러한 interpreter로 실행되는 thread를 green thread라고 부른다. 아마 Green Project의 흔적인 것 같다. JIT, HotSpot의 등장으로 실행 시에 기계어로 컴파일되므로, 가상 시스템상의 thread도, OS가 직접 관리하는 thread가 되었다. 이것을 native thread라고 부른다. Green thread에 비하면 오버헤드가 현격히 적다.

Dynamic

C++에는 네임 스페이스라고 하는 개념이 있지만, Java에는 없다. 비슷한 것을 찾자면 Class Path가 있다. Class Path는 환경 변수 CLASS_PATH에 설정해 Java를 호출할 때 파라미터로 지정한다. OS의 파일 구조를 지정하는 이유는 실행 시에 클래스를 불러 들이는 방식이기 때문이다. Java는 프로그램을 *.java로 기술해, javac 커맨드로 컴파일 해서, *.class라는 이름의 클래스 파일을 작성해서 실행한다고 설명했지만, 이 클래스 파일이 실행 시에 읽혀지므로, 읽는 디렉토리를 지정해두지 않으면 찾지를 못하게 된다.

UNIX에는, gnuzip이라는 표준 도구가 있다. 대체로 모든 UNIX OS에서 사용 가능하다. 그러나, ZIP에는 없는 것이 있다. Windows의 WinZip로 작성한 ZIP 파일은 UNIX에서 압축을 풀고 싶어도 풀 수 없다! 이럴 경우에는, JDK에 포함되어 있는 jar 커맨드라고 하는 Java 프로그램을 사용할 수 있다. Windows의 엔지니어라면 익숙할 것이다. 그러나 반대로, UNIX의 tar 커맨드로 작성한 파일을 Windows에서 풀고 싶을 때는, jar 커맨드를 사용할 수 있다. 무엇보다, Windows에는 tar 커맨드의 무료 버전은 많기 때문이다.

jar커맨드를 갑자기 등장시켜 미안하지만, Class Path에 다수의 class 파일이 있는 것도 관리 측면에서는 귀찮은 일이다. 그런 측면에서 Java에서는 WinZip과 같은 기능을 가진 jar 커맨드로 클래스 파일들을 압축할 수가 있게 되어 있다. 이 파일은 *.jar 라고 하는 확장자를 붙이기 때문에 jar파일이라고 부른다. Java판의 tar니까 jar라고 하는 것일까?

클래스를 동적으로 로드하기 때문에 메모리를 크게 절약할 수 있다. 만들어 놓은 프로그램이 전부 실행되는 것이 아니기 때문이다. Jar로 다양한 클래스를 정리해서 거대한 라이브러리를 만든다고 해도, 사용하지 않는 것은 메모리에 로드되지 않기 때문에 실행 시에 메모리를 신경 쓰지 않고 클래스 라이브러리를 작성할 수 있다. Swing도 그렇다. 전부 읽어 들인다고 생각하면 큰일일 것이다.

그런데, 실행 시에 클래스를 읽어 들이는 방식은 오늘날 Web 어플리케이션 서버 테크놀로지 발생을 재촉하는 큰 역할을 하였다. 실행 시에 동적으로 클래스를 불러 들이는 기능이 없었다면, JSP(Java Server Pages)와 같은 스팩도 생각하지 못했을 것이다. 그렇게 되면, *.jsp 파일 안에 Java언어를 묻어 둘 수 있다. 통상적으로 JSP를 참조할 때는 *.java가 신규로 생성되어 javac로 컴파일 되고 그 결과 *.class가 작성된다. 이 *.class는 Servlet으로 동작한다.

그러나, JSP도 고도로 비대화되고 있는 오늘날, 사전에 컴파일 해 두는 기능을 어플리케이션 서버에서는 표준으로 하고 있다. JSP를 *.java로 변환한 시점에서 2Gbytes를 넘어 버려 에러가 발생해 버리는 경우도 있다. 그리고, 다른 경우에는, 사전에 컴파일해 두는 것을 전제로 하고 설계를 하기도 하는데 웃기지도 않다.

한 번 운영을 시작하면 멈출 수 없는 Web 어플리케이션 서버의 경우, 버그에 의한 원시코드의 수정을 반영시키는 디플로이먼트(deployment)가 순조롭게 행해져야 한다. 클래스를 동적으로 로드하는 Java의 생각이 Web 어플리케이션 서버에도 계속되고 있는 것이다.

◆　컴퓨터 그 자체의 역사가, 이제 겨우 반세기를 지나고 있는 가운데, 벌써 8년의 역사를 가지고 있는 Java는 어느덧 결코 새로운 언어가 아니다. 마이크로 컴퓨터 소년의 시대부터, Jobs씨나, Gosling씨와 같은 세대를 보낸 엔지니어로서 Java의 스팩은 대단하다고 느낀다. 이런 나의 생각이 여러분에게 전해지면 다행일 것이다. Java를 넓은 독자층에게 아주 잘 설명할 수는 없었지만, 전술한 Original Java Whitepaper나, Java 탄생의 페이지를 아직 보지 않은 않았다면, 꼭 보기를 바란다.