컴파일드 언어, 인터프리티드 언어(Compiled, Interpreted Languages) 그리고 자바(Java)

www.mackido.com  번역

1999-5-1

 

기계어(machine code)라고 불리우는 가장 하위에 위치하는 언어는 단지 0과 1로만 이루어진 이진 패턴을 그룹지어 놓은 비트로 이루어져 있습니다. 이렇게 그룹지어진 것은 일정한 명령을 컴퓨터에 내리게 되는데 이 명령을 인스트럭션(instruction)이라고 합니다. 인스트럭션의 종류에는 반복적인 일련의 명령을 수행하는 루프(loop), 특별한 조건이 만족될 때만 어떤 일을 수행케 할때 사용하는 제어문(conditionals) 그리고 몇 개의 연산 함수(덧셈, 뺄셈, 곱셈, 나눗셈, 참 거짓을 판단하는 불리언(boolean)연산)이 있습니다. 사실상 컴퓨터 CPU가 수행하는 작업의 95%가 위에서 말한 명령으로 이루어져 있습니다. 컴퓨터는 단지 이런 작업을 정말로 빠른 속도로 한다는 점에서 대단한 것입니다. 우리가 맞닥뜨리게 되는 대부분의 문제점도 사실은 이들 단순한 인스트럭션을 조합하면 충분히 표현될 수 있습니다.

 

이러한 이진수로 이뤄진 인스트럭션은 각 프로세서 칩마다 다르고 인간이 읽고 이해하기에는 대단히 까다로운 형태를 띠고 있습니다. 그러므로 인간이 더 친숙하게 익히고 활용할 수 있는 컴퓨터 언어를 개발해야 겠다는 요구가 당연히 있어 왔고, 그런 노력 덕분에 C, C++, Pascal, Java 같은 익숙한 언어가 만들어진 것입니다.

컴파일드 언어(Compiled Language)

컴파일드 언어는 기계어로 컴파일(compile) 되는 언어입니다. 컴파일이라는 과정은 일종의 번역 작업으로 비유할 수 있습니다. 어떤 영어 문서를 스페인어 문서로 번역하는 것처럼 인간에게 친숙한 고급언어로 작성된 프로그램을 기계어로 번역하는 것입니다. 일단 번역된 것은 다시 원본으로 되돌리기 힘듭니다. 컴파일된 코드는 크기가 작으면서 컴퓨터가 가장 이해하기 쉬운 형태로 변환되므로 빠르고 최적화됩니다. 컴파일된 코드는 그러나 각 컴퓨터 프로세서에 따라 독자적인 특징을 갖고 있습니다. 그러므로 컴파일된 코드는 여러 종류의 프로세서를 자유롭게 옮겨 다니며 사용할 수 없습니다. (이를 테면 powerpc와 pentium) 컴파일 코드보다는 덜하기는 하지만 소스 코드(컴파일 이전의 프로그램) 또한 운영체계별로 다른 특징을 담고 있고, 대개의 경우 특정 라이브러리 (library, support code)를 요구합니다.

 

 

Source: https://hpc-wiki.info/hpc/Compiler

 

 

소스코드는 어느정도까지는 여러 플랫폼에서 재사용할 수 있습니다. 하지만 각 플랫폼별로 따로 컴파일 해야 합니다. 그리고 이런 컴파일을 가능케 하려면 수정을 해야 하는 경우가 많습니다. 게다가 코드중 일부만이 크로스플랫폼으로 이용할 수 있다는 점도 감안해야 합니다. 프로그램 디자인에 따라 다르기는 하지만 대개 20%에서 80% 정도가 크로스플랫폼적 성격을 갖습니다. C나 C++, 파스칼(Pascal), 포트란(Fortran) 등은 모두 컴파일 언어입니다. 이 언어로 작성한 프로그램은 대체로 플랫폼 의존성이 강하고 특별한 프로세서용으로 만들어지는 경우가 대부분입니다.

인터프리티드 언어(Interpreted Language)

인터프리티드 언어(Interpreted Language)는 컴파일 언어처럼 전체가 기계어로 미리 변환되는 것이 아니고 실행 중에 interpreted 됩니다. 컴퓨터는 프로그램 각 줄에 담긴 인스트럭션을 읽어 들여 하나 하나 해석해 가며 실행합니다. 물론 이들 각각의 인스트럭션에 해당하는 루틴은 다 native입니다. 이해를 돕기 위해 예를 들면, 사용자와 컴퓨터 사이에 통역을 둔 형태라고 할 수 있습니다. 사용자가 한 마디를 하면 통역은 곧바로 컴퓨터가 이해할 수 있는 최적의 언어로 이를 바꿉니다. 이처럼 중간에 매개하는 부분이 있다보니 컴파일 언어보다 실행 속도가 떨어지는 것은 당연합니다.

 

 

Source: https://medium.com/@mahiprashanth866

 

 

인터프리티드 언어는 프로그래머 입장에서 보면 상당한 이점이 있습니다. 한 줄씩 해석되는 언어이므로 프로그램을 수정하거나 보완한 경우 전체를 완전히 새로 recompile 할 필요 없이 즉각 실행시켜서 확인할 수 있습니다. 리컴파일할 경우 몇 분에서 길게는 몇 시간이상 걸리는 데 반해 즉각 테스트 가능한 것입니다. 또한 인터프리티드 언어는 특별한 플랫폼 의존성을 가질 필요가 없습니다. 실행 중에 인터프리티드되므로 적절한 인터프리터(interpreter)만 있다면 어떤 기종에서도 잘 실행될 수 있는 것입니다. 이런 이유로 인터프리티드 언어는 더 크로스플랫폼적 성격을 갖습니다.

 

10-20여년 전만 해도 컴퓨터는 오늘날보다 문자 그대로 수백, 수천 배나 느린 성능을 갖고 있었습니다. 그러므로 편이성을 위해 성능을 희생할 수는 없는 상황이었지요. 하지만 오늘날에는 엄청난 기술 발전 속도 덕분에 인터프리티드 언어가 서서히 세력을 확장해 가고 있는 추세입니다.

Bytecode(p-code)

컴퓨터가 interpret 한 구문은 일반적인 텍스트와는 조금 다른 모습을 갖습니다. 특별하게 축약된 형태로 변형되는데 기계어도 아니고 그렇다고 사용자가 읽고 이해할 수 있는 고급언어도 아닌 중간자적 형태를 갖습니다. 이런 코드를 기술적 용어로 P-Code라고 합니다.  p Code 테크닉은 1970년대 후반 UC 샌디에고에서 개발되었고 썬 마이크로씨스템이 자바를 개발하면서 새롭게 확장한 기술입니다. 자바는 일종의 byteCode Compiler로, 인터프리터 역할을 하는 것이라고 할 수 있습니다.

스크립팅 언어(Scripting Languages)

어떤 언어는 (대개 인터프리티드 언어) 프로그래밍 언어라고 이름 붙이기에는 다소 덜 복잡하고 단순한 기능만을 수행하는 것이 있습니다. 이런 언어는 단순한 형태의 프로그래밍인 스크립팅을 위해 사용하는 경우가 많습니다. 만약 파워풀한 독립 애플리케이션(standalone application)을 만들고 싶다면, 스크립팅 언어로는 부족합니다. 필요한 것은 프로그래밍 언어죠. 하지만 가끔 파워 유저나 프로그래머일지라도 애플리케이션에 몇가지 기능을 추가하기 위해 스크립팅 언어를 유효적절하게 사용할 수도 있습니다. 상당수의 프로그램은 자체 스크립팅 언어를 갖추고 있기도 합니다. 하이퍼카드(HyperCard)와 Quicktime (QTi)-HyperScript, MS Office와 비주얼베이직(Visual BASIC) 또는 매크로미디어 디랙터(Macromedia Director)와 링고(lingo), 그리고 애플에서 파인더를 비롯한 다수의 애플리케이션의 기능 향상을 위해 만들어 놓은 매우 광범위한 성격의 애플스크립트(AppleScript) 같은 것이 예입니다.

 

도스와 유닉스 (사실 이들은 Operating System과 사용자 사이에 놓여있는 일종의 애플리케이션입니다.) 또한 자체적인 스크립팅 언어를 갖추고 있습니다. 그 외에도 수백 가지의 스크립팅 언어가 있습니다. 예를들면, Perl, Awk, 그리고 대부분의 데이터베이스에 갖추어진 스크립팅 언어들. 그리고 HTML을 위한 스크립팅 언어인 JavaScript. 한 가지 잊지 말아야 할 점은 스크립팅 언어는 단지 단순한 기능만을 수행하는 프로그래밍 언어로 특정 애플리케이션을 위한 몇가지 작업이나 OS-Shell에 명령어를 전달하는 작업을 수행하려고 디자인한 언어라는 점입니다. 스크립팅 언어는 완전한 프로그래밍을 위해 고안된 것은 아닙니다.

자바(Java)

자바는 byteCode를 사용하는 인터프리티드 언어의 일종으로 여러 종류의 플랫폼 상에서 돌아가는 자체 구문을 갖춘 프로그래밍 언어/환경입니다. 자바를 이용해서 작성된 프로그램은 어느 플랫폼에서나 다 실행되고 이런 크로스플랫폼적 특징을 지닌 언어는 자바 외에도 몇 종이 더 있지만 대부분 해당 플랫폼에서 따로 재컴파일해야만 했습니다. 자바는 딱 한 번만(byteCode로) 컴파일한 다음 어느 플랫폼에서나 실행될 수 있다는 점에서 다릅니다.

 

 

 

또한 자바는 기존의 크로스플랫폼 개발 환경과 달리 대단히 풍부한 프레임웍스(Frameworks;프로그래밍 작업을 용이하게 해주는 object libraries)을 갖추고 있습니다. 그뿐만이 아닙니다. 자바는 pointer가 필요없습니다. 포인터(pointer)는 c/c++로 작업해본 사람들이 모두 지적하듯 제일 골치 아프고 시간을 잡아 먹는 부분입니다. 실제 모든 프로그래밍 문제 중 60% 이상이 포인터 때문에 일어난다고 조사된 바도 있지요. 포인터로 야기된 문제점을 해결하는 데 드는 비용은 종종 수천 달러에 이르기도 합니다.

 

 

 

 

자바의 장점은 또 있습니다. 자바는 frameworks/libraries를 손쉽게 패키지화할 수 있기 때문에 다른 프로젝트에서 재사용하거나 상호교환하는 것이 쉽습니다. 그러므로 자바를 이용해서 개발하는 경우, 개발 시간 측면에서나 비용면에서나 큰 이점이 있을 뿐 아니라 프로그램을 유지하고 디버깅하는 것 또한 훨씬 간편합니다. (이른바 "dangling pointers"와 같은 미묘한 버그가 아예 존재하지 않으므로) 게다가 자바로 작성한 코드는 손쉽게 재사용될 수 있습니다.^{((역자주))} 그리고 자바로 작성한 코드는 어느 플랫폼에서나 실행된다는 것도 자바의 뛰어난 강점 중 하나입니다. 비용은 적게들면서 장점은 아주 많은 정말 괜챦은 언어입니다. 불행히도, 인생에 있어서나 엔지니어링에 있어서나 댓가 없는 혜택은 없습니다.

 

성능(Performance) 문제

 

현재까지는 속도가 떨어진다는 점이 자바의 대표적 문제점으로 지적됩니다. 자바 app은 실행속도가 늦습니다. 자바는 기본적으로 인터프리티드 언어이므로 컴퓨터가 곧바로 이해할 수 있는 언어가 아닙니다. 각각의 명령어를 일단 컴퓨터가 이해할 수 있는 언어로 바꾸어주는 인터프리터가 필요합니다. 이를 JVM(Java Virtual Machine,자바 가상 머쉰)이라고 하며 이렇게 중간에 JVM이 끼어 있으므로 속도가 느립니다. 하지만 자바 속도 문제가 해결될 조짐이 여러 형태로 나타나고 있습니다.

 

 1. 컴퓨터 자체가 점점 빨라지고 있습니다. 매년 엄청난 속도로 빨라지고 있습니다. 오늘 자바가 느리게 동작한다고 해서 내일도 자바가 느리게 동작할 것으로 생각해서는 안 됩니다.

 2. 자바 인터프리터도 점점 빨라지고 있습니다. 소위 "JIT(Just-In-Time) Compiler"라는 것이 자바 실행 속도 향상에 큰 기여를 하고 있습니다. JIT Compiler는 어떤 인스트럭션을 처음 실행할 때 최적의 기계어로 컴파일 해 둔 다음, 그 인스트럭션이 다시 사용될 때마다(컴퓨터 프로그램에는 많은 루프가 있지요.) 그 최적화된 것을 참조하므로 큰 속도 향상이 이루어집니다. 기존 방식보다 통상 10배에서 20배정도 빠른 속도를 보여 줍니다. 게다가 점점 더 빨라지고 있습니다.

 3. 어떤 CPU는 제작 단계에서부터 자바를 native로 이해할 수 있도록 만들어 지고 있습니다. 그런 컴퓨터는 굉장히 빠른 자바 실행 속도를 갖습니다. 자바가 점점 더 대중화 됨에 따라 더 많은 컴퓨터가 이런 방식을 채택하게 될 것입니다. 자바가 그야말로 네이티브로 실행된다는 얘기지요.

 4. 자바의 기능 중 상당수가 라이브러리, 프레임웍스(frameworks) 형태로 만들어 지고 있는 추세입니다. 그리고 프레임웍스(JFC나 AWT 같은)는 네이티브입니다. 결국 실행되는 자바 코드의 80% 이상이 네이티브화 되는 것입니다.

 5. Native-Java를 만들기위한 여러 가지 작업이 진행 중입니다. 자바로 프로그래밍한 다음 각 플랫폼에서 따로 컴파일하여 standalone application을 만드는 것이지요. 한 번 코딩으로 모든 플랫폼에서 실행된다는 크로스플랫폼적 성격을 유지하면서도 Native speed application을 자바로 만들 수 있는 것입니다. 물론 각 플랫폼 고유의 특성을 가미하기 위해서는 그런 부분들이 미리 컴파일된 것들이 필요합니다.

 

컴퓨터의 속도 향상만으로도 자바는 충분히 빨라질 수 있는 데다 여러 가지 자바 기술 자체의 발전도 자바 속도를 보다 빠르게 해 줄 것입니다. 자바 속도 향상은 단지 시간 문제일 뿐입니다.

 

((역자주)) 자바빈즈(JavaBeans)가 그런 기능의 대표입니다. 자바빈즈의 정의는 "Visual objects at development time"입니다. 개발 툴(비주얼툴 - 이를테면 오러클의 JDeveloper라든지, IBM의 Visual Age for Java , Visual Cafe 같은...)에서 유저인터페이스를 만드는 것처럼 미리 완성해놓은 기능을 손쉽게 가져다가 쓸 수 있게 만든 것입니다. 자바빈즈는 단순히 버튼이나 스크롤 바 같은 유저 인터페이스 구성요소 차원을 넘어 여러 업무와 작업에 필요한 것들을 완제품 형태로 만들어 놓은 것입니다. 이를테면 금융업나 제조업, 의료 등에서 자주 요구되는 작업을 만들어서 제공하는 것입니다. 결국 특정 기능을 부품을 가져다 쓰는 것처럼 손쉽게 이용할 수 있게 하는 것입니다. Enterprise JavaBeans(EJB)는 자바빈즈에 분산 컴퓨팅 기능을 첨가시킨 것입니다. 다른 시스템에 있는 클래스도 내 시스템의 클래스처럼 쓰게 해주는 자바빈즈입니다.

변화의 댓가

두 번째 자바의 단점으로는 기존 환경으로부터 자바로의 전환에 다소 시간과 비용이 요구된다는 점입니다. 사람들은 일반적으로 변화를 달가워하지 않지요. 그 변화가 훨씬 더 좋은 결과를 가져올 경우에도 그렇습니다. 자바의 발목을 잡을 마지막 장애물은 자바로의 전환에 소요될 시간이 될 것입니다. 기존의 언어는 많은 사용자 숫자와 툴, 코드가 있습니다. 하부구조가 탄탄합니다. 그런 부분을 자바가 따라 잡으려면 어느 정도 시간이 걸릴 것입니다. 하지만 이미 십 수 개의 판매용 자바 개발환경이 나와 있을 만큼 자바의 발전 속도가 빠르고, 판매용 자바 라이브러리도 많이 쏟아져 나와서 자바의 영역을 날로 넓혀 가고 있습니다. 따라서 자바로의 전환에 드는 비용이 자바의 발전 속도를 늦추기는 하겠지만, 발전 자체를 막을 수는 없습니다. 변화에 대한 저항 심리나 자바의 다소 둔한 성능에도 불구하고 이미 자바 세력 확장에 힘이 실리고 있습니다. 결국, 자바가 과연 최고의 자리에 오를 수 있을 것인지가 문제가 아니고 언제 오를 수 있는가가 문제입니다.

자바스크립트(JavaScript) 와 JScript

자바스크립트는 자바와 아무런 상관이 없습니다. 사실 원래 이름도 "LiveScript"였습니다. 하지만 넷스케잎(Netscape)사는 마케팅적 측면에서의 이점이 있을 것이라는 바보같은 생각으로 LiveScript를 JavaScript로 바꾸어 명명했습니다. Sun의 Java가 몰고온 미디어의 관심을 업어보겠다는 속셈이었던 것이지요. 비유하자면 보잉사가 자사의 747 여객기를 스페이스 셔틀로 바꾸어 부른 것과 같습니다. 덕분에 사용자는 평생토록 자바와 자바스크립트를 혼동하게 되었구요.

 

 

 

 

자바는 컴퓨터 언어와 라이브러리 세트 모음(Frameworks)을 통칭한 것입니다. 자바스크립트는 HTML 페이지에 포함시킬 수 있는 스크립팅 언어로 자바와는 전혀 다른 형태를 갖고 있습니다. 자바는 분명히 잘 동작합니다. 하지만 자바스크립트는 문제가 있는 경우가 많고 심지어 넷스케잎을 충돌로 몰고가기도 합니다. 하지만 몇몇 기능을 추가하는 데 있어 자바스크립트만이 유일한 해결책이기에 어쨌든 쓰이고는 있습니다.

 

마이크로소프트는 너무 많은 기술발전이 이루어지는 것을 좋아하지 않기 때문에 (그리고 그들은 표준을 극도로 싫어합니다, 자기 회사가 만든 것이 아니라면.) 자바스크립트의 아류 비슷한 JScript를 내놓습니다. 그리고는 자바스크립트와는 다른 방식으로 작업을 엉망진창으로 만들어서 프로그래머를 고문할 수 있음을 보여 주지요. 아주 미묘한 형태로 말입니다. 이런 마이크로소프트의 행보 때문에 웹 사이트를 만드는 사람은 인터넷 익스플로러와 넷스케잎 브라우져 사이에서 선택을 강요받게 되었습니다. IE와 Netscape 양쪽 모두에서 부드럽게 실행되는 자바스크립트는 만들기가 상당히 어렵기 때문입니다. 마이크로소프트는 항상 자신들이 주도권을 갖지 못한 기술이 출현하면 어떤 방식으로든 발전 속도를 늦추는 사악한 마케팅을 펼쳐 왔습니다. 그 결과 수천 명의 프로그래머와 수백 만의 사용자가 고통을 받더라도 말이지요. 자바스크립트도 예외가 아닙니다.

결론

짧게 요약하자면 결국 자바는 대부분의 일반적 용도의 프로그래밍 언어를 대체하며 최고의 위치에 오를 것입니다. 하지만 사람들이 생각하고 있는 것만큼 빠른 속도로 이루어지지는 않을 겁니다. 사실은 자바라는 말이 떠돈지도 벌써 몇 년이 흘렀고 아직까지는 대부분의 프로그래머들 사이에서 대단한 영역을 확보하지 못한 것도 사실입니다. 하지만 몇 년 내에 자바의 진정한 위력을 확실하게 느끼게 될 것입니다.

 

참고로, 자바로 만든 프로그램은 두 가지 형태로 배포할 수 있습니다. 첫째, Applet이라는 미니 애플리케이션으로 만들 수 있습니다. 애플릿은 웹 브라우져 내에서 실행하는 프로그램입니다. (네트웍 상에서도 실행시킬 수 있습니다.) 애플릿은 보안성을 갖추고 있고, 크기가 작고, 제한된 작업만 가능합니다. 애플릿은 이미 인터넷을 통해 상당히 보편화 되었습니다. 애니메이션이라든지 데이타 입력 작업을 가능케 해주는 애플릿이 인터넷에 많이 있습니다. 애플릿은 이미 자신의 존재를 분명히 각인시켰고, 앞으로도 더욱 발전해 나갈 것입니다.

 

둘째, 자바 애플리케이션(Java Application, Java Apps)으로 만들 수도 있습니다. Apps는 독립(stand-alone) 프로그램입니다. 따라서 실행하기 위해 웹 브라우져를 띄울 필요가 없습니다. 현재까지는 자바 애플리케이션을 실행하기 위해서는 실행환경인 JVM(Java Virtual Machine)이 필요합니다. JVM은 운영체제와 함께 번들로 제공되고 있거나 애플리케이션 패키지에 포함되어 배포되고 있습니다. 자바 Apps도 점점 더 사용자층을 넓혀가고 있습니다. 포츈 500위 안에 드는 주요 기업체에서도 자바 애플리케이션으로 데이타베이스의 프런트엔드(front end)를 만들어서 여러 종류의 플랫폼 상에서 운용하고 있기도 합니다. 몇몇 시장에서는 자바 Apps가 이미 상당한 위치를 점하고 있기도 하구요. 여러 분야에서 점점 자바로 힘이 쏠리고 있습니다. 상당수 대학에서 자바를 강의하고 있으며 컴퓨터 관련 학과에서는 자바로만 이루어진 커리큘럼을 제공합니다. 점점 더 많은 프로그래머가 자바를 배우고 더 많은 자바 개발 툴이 만들어져 나오고, 이에 따라 많은 자바 라이브러리들이 출시되고 있습니다. 한 번 힘이 실리면 계속 힘이 실립니다. 산 꼭대기에서 눈덩이가 굴러 내려오는 것처럼.