맑고 푸른 샘 소리 청음의 블로그 입니다.

어쩌다가 3부작이 되어버린 컴파일러와 인터프리터의 비교글...
드디어 마지막 글을 쓰게 되는군요.

앞서서 컴파일러가 무엇인지, 그리고 인터프리터가 무엇인지에 대해서 알아보았습니다.
그렇다면 비슷하지만 다른 두 프로그램이 어떻게 다른지에 대해서 표를 통해 알아보도록 하겠습니다.

두 프로그램을 단순히 비교하자면 이렇습니다.

컴파일러의 경우, 프로그램을 컴파일 하기 위해서는 모든 프로그램 소스를 가지고 한꺼번에 번역을 해서 목적코드를 제작합니다. 반면에 인터프리터의 경우 필요한 부분을 행(Line 보통 ';'으로 구분되는 단위)단위 구문으로 번역을 하여 바로 실행시킵니다.

이와 같은 특징 때문에 컴파일러의 경우 한꺼번에 모든부분을 번역해야 하기에 번역속도가 느린 편이라 할 수 있습니다. (일부분 컴파일 미지원) 반면에 인터프리터는 필요한 부분만 컴파일(번역)을 하기 때문에 하나하나를 컴파일 하는 속도는 빠르다고 할 수 있습니다. 대신에 프로그램을 실행하면서 컴파일을 동시에 수행하기에 프로그램을 구동하는 시간은 오래 걸리는 오래 걸리는 편입니다.


그렇다면 프로그램 실행 속도가 컴파일러가 월등히 빠르다고 한다면 왜 컴파일러를 쓰지 않고 인터프리터를 쓰는 방식을 사용하는 것일까요? 그 이유는 개발의 편의성에 있다고 할 수 있습니다.

예를 들어 프로그래머가 신나게 프로그래밍을 했습니다. 그리고 열심히 컴파일을 1시간 30분에 걸쳐서 하고, 프로그램을 실행을 했습니다. 어라... 변수 하나를 이름을 착각해서 오류가 났습니다. 그렇다면 어떻게 해야 하느냐... 변수 하나의 이름을 바꿔가지고 1시간 30분을 마구마구 컴파일을 해야 합니다.

반면 인터프리터의 경우에는 어떨까요? 인터프리터의 경우 컴파일을 따로 하지 않고 바로 실행을 합니다. 마찬가지로 변수 하나의 이름을 착각해서 오류가 났습니다. 그렇다면 그냥 그 변수 이름을 수정한 다음에 다시 인터프리터로 돌리면 됩니다.

인터프리터에는 이러한 디버깅에 유리한 이점이 있습니다.

인터프리터에 유리한 이점은 하나가 더 있습니다.
여러 운영체제에서 사용할 수 있다는 점입니다. 예를 하나 들어보도록 하겠습니다. 컴파일러의 경우 윈도우 XP, 윈도우 VISTA같이 같은 계열이라도 엔진이 서로 다른 운영체제에서는 다시 컴파일을 해줘야 하는 경우가 있습니다. 물론 리눅스나 유닉스같은 운영체제라면 더더욱 그렇습니다.

반만 인터프리터의 경우에는 고급언어를 바로 인터프리터에 입력하여 실행하는 방식이기에 해당 운영체제의 인터프리터가 설치되어 있다고 한다면 따로 컴파일 과정 없이 사용이 가능합니다.

즉. 인터프리터의 경우 OS마다 호환되는 인터프리터만 설치되어 있다면 해당 소스를 여기저기에서 사용하기에 유리합니다.


이러한 이점에도 불구하고 JAVA가 나오기 이전까지는 인터프리터 방식이 그다지 선호되지는 못했습니다. 그 까닭으로는 프로그램의 실행 속도가 컴파일러로 컴파일된 프로그램에 비해서 너무 느렸고, 또 고급언어로 된 소스코드를 이용해서 실행시키기 때문에 보안에 취약했기 때문입니다.

하지만 지금에 와서는 컴퓨터의 하드웨어적인 성능이 많이 올라가서 인터프리터 방식이라고 해서 컴파일러에 의해 컴파일된 목적프로그램에 비해서 그다지 뒤쳐지지 않게 되었고, 또 컴파일러와 인터프리터의 장점을 혼합하여 일차적인 컴파일을 통해 원래의 소스코드를 인터프리터가 읽고 사용하는 방식으로 확장되어 원본 소스코드가 공개되는 상황도 방지할 수 있게 되었습니다.


이 정도로 컴파일러와 인터프리터에 관한 내용은 마치려고 합니다.
혹시나 이 글을 읽는 사람들에게 도움이 될 수 있었으면 좋겠습니다.
긴 글 읽어주셔서 감사합니다.

이번에는 지난번 컴파일러에 이어서 인터프리터에 대해서 알아보도록 하겠습니다.
인터프리터는 지난번에 이야기했던 컴파일러처럼 고급언어로 쓰여진 프로그래밍 언어들을 컴퓨터가 실행하게끔 해주는 프로그램입니다.

위치상으로 봤을 때에는 다음과 같습니다.

고급언어와 기계어 사이에서 번역을 해주는 녀석이라는 점은 컴파일러와 인터프리터와 동일합니다.
하지만 컴파일러가 소스를 전부 변환을 해서 목적코드(exe파일)를 생성하는 것과 달리 인터프리터는 필요한 구문을 한줄(line)단위로 읽어서 번역하고, 바로 실행시킵니다.

즉, 컴파일러가 책을 번역해서 제본한 뒤 번역본(목적코드)를 주는 번역가라고 한다면 인터프리터는 외국어를 즉시즉시 번역해주는 동시통역사 인 셈입니다. 따라서 정확한 표현을 하면 이렇습니다.

인터프리터는 컴파일러와는 달리 따로 목적프로그램 즉 exe파일을 만들지 않고 바로 실행됩니다. 또한 인터프리터를 통해 프로그램이 실행되기 때문에 따로 어셈블러도 필요가 없습니다. 정확하게는 어셈블러의 역할까지도 인터프리터가 한다고 보는게 맞습니다.

인터프리터의 특징으로는 컴파일러와는 달리 컴파일 과정이 보통 생략되거나 필요한 부분만을 다시 하기 때문에 수정을 했을 경우 컴파일러에 비해서 걸리는 시간이 짧습니다.
 
또한 인터프리터의 겨우에는 OS에 상대적으로 자유로운 고급 언어로 프로그램을 짜고, 이를 해당 OS에 맞게 구현된 인터프리터에서 직접 컴파일 하기 때문에 이식성이 높습니다. 그 예로는 웹 브라우져가 있습니다.
(HTML이라는 언어를 받아 인터프리터 방식으로 웹을 표현하는 것입니다.)

하지만 최근에 있어서는 이 인터프리터라는 방식이 확장이 되어 다음과 같은 방식으로 사용되기도 합니다.

컴파일러와 인터프리터를 동시에 사용하는 방식인데요, Java가 이에 해당합니다. java.exe.라는 인터프리터가 읽을 수 있는 바이트 코드라는 코드로 javac.exe라는 컴파일러가 Java언어를 번역을 해주는 겁니다.

고급언어 코드를 javac.exe에 의해 바이트코드로 변환을 하고, 이 바이트코드를 java.exe라는 인터프리터가 한줄씩 읽어서 프로그램을 실행시키는 것이지요. 이 방식은 컴파일러 방식과 인터프리터 방식의 장점만을 골라 취할 수 있는데요.

1. 원본소스를 공개하지 않아도 된다.
 - 인터프리터 방식은 원본 소스를 가지고 프로그램을 싱행하기 때문에 소스가 공개되어야 했습니다. 하지만 위의 방식은 1차 컴파일을 마친상태에서 그것을 배포하면 되기 때문에 소스가 공개될 이유가 없습니다.
2. 수정이 편하다.
 - 인터프리터 방식이기 때문에 수정시에 전채를 재 컴파일 하는 것이 아니라 읽어오는 부분만을 다시 컴파일 할 수 있습니다. 또한 Line by Line으로 읽어오기 때문에 어느 부분에서 에러가 났는지를 추정하기가 쉽습니다. 따라서 전체를 컴파일해야 하는 컴파일러 방식에 비해서 적은 시간 내에 수정이 가능합니다.
3. 이식성이 높다.
 - 각 운영체제별로 목적프로그램을 배포하는 것이 아니라, 해당 OS에 인터프리터를 설치하고 바이트코드 상태로 프로그램을 배포하면 사용이 가능합니다.

물론 인터프리터가 장점만을 가진 것은 아닙니다.
목적프로그램을 직접적으로 생성하는 것이 아니고, 프로그램을 실행시에 매번 번역을 해야 하는 방식이다보니 프로그램의 실행 속도가 늦습니다.

인터프리터에 대한 내용은 위의 내용 정도만 숙지하고 있으면 될 듯 하고,
컴파일러 방식과 인터프리터 방식의 비교는 좀 있다가 다른 포스팅을 통해 하도록 하겠습니다.
그럼 그때까지 안뇽~

오늘은 컴파일러에 관해서 이야기 해 보도록 하겠습니다.

컴파일러란?
컴퓨터는 멍청합니다.
겉보기의 화려한 UI(User Interface)와는 달리 실제로는 '0'과 '1' 단 두가지만을 알고 있는 녀석입니다.

그러다보니 사람이 컴퓨터에게 어떠어떠한 행동을 하라는 프로그램을 짜 주기 위해서는 '0'과 '1'로 이루어진 기계어로 컴퓨터에게 알려줘야만 합니다. 하지만 사람들이 하고 싶은 이야기를 모두 '0'과 '1'로 표현하자니 프로그램을 짜기 어려운 것은 물론이고, 소스에 문제가 생겼을 때에 어느 지점에서 문제가 생겼는지 아는 것이 사실상 불가능했습니다.

따라서 사람들은 '0'과 '1'의 배열을 약어로 끊어서 'move', 'jump'등의 약어로 적은 뒤 프로그램에 의해서 기계어로 변환을 시켰습니다. 이 프로그램이 어셈블러(assembler)이고, 이 약어들이 규격화되어 어셈블리어 라는 언어가 되었습니다.

그러나 이 명령어들은 기계어들을 축약해 놓은 것에 지나지 않습니다. 위에서 언급했다 시피 컴퓨터는 멍청하기 때문에 기계어로 입력되는 명령어라는 것이 변수 c에  변수 a + b의 값을 저장하라는 명령을 내릴 때에

정확한 커리큘럼은 아니지만 이런 방식으로 적어주어야 했습니다. 이는 컴퓨터와 같은 멍청한 존재와의 대화 방식이었기에 기계어와 어셈블리어는 저급 언어(Low lever language)라고 불렀습니다. 때문에 사람들은 더 쉽게 프로그램을 작성하기 위해서 또 다른 프로그램을 만들어내기 시작합니다. 예를들어

라고 프로그램을 짜면 '너는 c라는 이름의 ~'라는 예전의 명령과 동일하게 번역을 해주는 프로그램을 만들었습니다. 이는 'Low level language'에 비해서 훨씬 사람이 이야기하는 방식에 가까운 방식이었으므로 고급 언어(High level language)라 불렸고 사람들에게 널리퍼져 지금까지도 쓰이고 있습니다.
이때 고급 언어를 저급 언어로 번역하는 것을 컴파일이라고 하고, 컴파일을 해주는 프로그램을 '컴파일러'라고 부르게 되었습니다.

따라서 대다수의 프로그램들은 아래와 같은 절차를 통해서 만들어지게 됩니다.

or

즉 컴파일러는 고급 언어를 저급 언어로 번역을 해주어 컴퓨터가 이해할 수 있게 해주는 프로그램이다. 라고 이해를 하면 될 것 같습니다. 상당수의 컴파일러들은 자체적으로 어셈블러를 가지고 있어서 따로 어셈블러를 이용하지 않고 컴파일 작업을 해서 실행 할 수 있는 파일(윈도우의 경우에는 exe 파일)로 결과 값을주고, 우리는 이 exe 파일을 실행함으로서 작성한 프로그램을 사용할 수 있게 됩니다.

다음번에는 인터프린터에 대한 내용을 가지고 돌아오도록 하겠습니다.
이번 주말까지 컴파일러와 인터프리터의 비교에 대한 내용까지 올릴 생각이니
조만간 또 만나요 ^^

윈도우 7에서 전, 후면 포트가 따로 잡혀서
후면 스피커를 이용할때는 제어판 - 소리 들어가서 후면 스피커를 기본으로...
전면 이어폰을 이용할때는 제어판 - 소리 들어가서 전면 스피커를 기본으로...
이상하게 리얼텍 드라이버를 설치했는데도 불구하고 오디오 관리자도 안나타나구요 ㅎㅎ;
(프로세스에는 살아있는데 판넬이 안나타났죠;)
이유를 확인해보니 드라이버의 문제였습니다.

정확히는 윈도우 드라이버인데요;;;
MS에서 제공하는 드라이버가 있습니다.
이게 잡히는게 리얼텍 드라이버보다 우선순위에 놓여 있어서 MS께 깔리기 때문에
리얼텍 드라이버에서 제공되는 오디오 관리자가 실행되지않는 문제가 생긴 겁니다.
따라서 강제로 리얼텍 드라이버를 잡아주면 됩니다.
방법은

일단 리얼텍 홈페이지에서 윈7용 드라이버를 설치하신 뒤
'컴퓨터' 우클릭 속성 - 장치관리자 - 사운드쪽에 HD 오디오 우클릭 - 드라이버 소프트웨어 업데이트
컴퓨터에서 소프트웨어 찾아보기 - 컴퓨터장치 드라이버 목록에서 직접 선택 - 리스트에서 Realtek 붙은 드라이버 선택

이렇게 하시면 Realtek에서 나온 드라이버로 선택이 됩니다.
그리고 나시면 오디오 관리자가 사용이 가능해지고, 헤드폰 감지가 되서
전후면 바꿔서 사용할때마다 세팅을 할 필요가 없습니다 ㅋ

...
제가 피곤한지라 사진따윈 없지만 도움이 됐으면 좋겠네요 ㅠㅠ.

가져가실분은 출처 남겨주세요.

 구글이 안드로이드 OS의 화려한 시장진출에 이어서 최근에 크롬OS에 대한 정보를 밝혀 아는 사람들 사이에서 알음알음 화제가 되고 있다. 구글 크롬OS. 대체 어떠한 운영체제이길래 이렇게 화제가 되고 있는 것일까?

 크롬os는 리눅스 기반의 OS에 크롬 웹 브라우져를 올려놓아서 프로그램들이 크롬 웹 브라우져상아서 돌아가게 만드는 OS이다. 이는 PC 사용자들의 컴퓨터 사용 목적이 인터넷 사용에 있고, 현재 돌아가는 프로그램들이 대부분 서버상에서 돌아가는 클라우드 형태로 바뀜에 따라 클라이언트단의 단말기에서는 무거운 OS를 돌려 직접적인 어플리케이션 프로그램들을 돌릴 필요가 없다는 것을 이론으로 하여 만들어진 것이라 할 수 있다.

 즉 현대의 인터넷은 파일들을 서버에 저장해 두었다가 필요하면 서버에서 실행하여 그 결과값만을 웹 브라우져 = OS 라는 공식을 만들어서 웹 브라우져로 작동시키면 된다는 이론 하에 가장 가벼운 OS를 만들자! 정도가 그 취지라고 할 수 있겠다.

 하지만 이러한 상황에서 사람들의 말이 나올 수 밖에 없는 것이 인터넷이 연결되지 않은 곳에서는 클라우드 시스템을 이용한 크롬OS는 아무것도 할 수 없는 상태에 이르게 된다는 것이 문제가 되는 것이다. 컴퓨터를 켰는데 그 PC에는 웹 브라우져만 설치되어 있다. 하지만 인터넷이 안된다면(?)
 
 나도 물론 이 문제에 대하여는 일부는 공감한다. 사용자들이 컴퓨터를 사용할때 인터넷에 접근하는 것을 주 목적으로 하지만 인터넷이 되지 않는 환경에서라도 문서작업을 하거나 동영상을 감상하는 등의 기초적인 사용을 할 수 있어야 pc라고 할 수 있음을 나도 잘 알고 있다. 하지만 결론적으로 말해서 '그러한 문제들을 과연 구글에서는 생각하지 않았을까?' 라는 답변을 해줄 수 밖에 없다.

 구글 크롬OS는 기본적으로 HDD의 필요성을 배제한다. 크롬 OS가 설치될 약 2GB정도의 용량만 있다면 그 외의 모든것은 인터넷을 통해. 클라우드 시스템을 통해 해결이 가능하다는 것이다. 하지만 그것이 과연 HDD를 꼭 쓰지 않아야 한다는 것일까?

 위에서 언급하였듯 크롬OS의 기반은 리눅스다. 그 리눅스들은 지금 HDD 기반에서 잘 돌아가고 있다. 그말인즉 크롬OS에서도 HDD의 마운트는 가능하다는 이야기이고 외장하드를 통해서 우리는 충분히 데이터를 사용할 수 있다. 그 데이터들을 사용할 일부 프로그램만 앱화 시켜서 크롬OS에서 동작 할 수 있도록 만들면 그만이다.

 외장하드를 일일히 들고 다니는게 귀찮을 수도 있다. 그렇다면 HDD를 내장해 버려도 상관 없다. 물론 HDD를 내장할 거라면 뭐하러 크롬OS를 사용하냐는 의견을 제시할 수도 있다. 하지만 생각해보라. 우리가 노트북을 들고다니는 주 목적은 들고다니면서 게임을 하려는게 아니라 인터넷을 하거나 문서작성을 하거나, 아니면 동영상 시청정도의 목적을 위해 사용한다. 그런데 굳이 밖에서 HDD를 늘 켜고 다닐 필요가 있을까?

 필자의 노트북은 배터리 수명이 다 되서 윈도우를 정상 부팅했을때 약 5~10분정도밖에 사용할 수 없다. 하지만 USB스틱을 이용해 Ubuntu 부팅을 하여 HDD를 언마운트 해 놓는 경우 30~60분 가량 사용이 가능하다.(이유는 잘 모르겠다. 아마도 가벼워서 CPU가 낮게 잡히는 것일지도) 이와 마찬가지로 크롬OS도 마찬가지일 것이다. 즉 다시 말해서 USB를 이용해서 크롬OS를 사용하면 저전력으로 노트북의 사용이 가능해질 것이다. 또 필요할때 HDD를 마운트하여 사용하면 될 것이고.

 물론 이렇게 사용하면 매번 USB를 들고 다녀야 하는 번거로움이 생긴다. 그렇다면 노트북에 낸드플래시 하나를 몰딩하면 어떨까? 물론 멀티부팅이 되어 부팅시간이 길어질 우려가 있으니 부트로더를 낸드(크롬OS) 따로 HDD(클라이언트중심 OS) 따로 작성하고 바이오스상에서 낸드 플래시를 우선 순위로 잡게 하고, 낸드플래시의 전원 On, Off를 노트북 밖의 스위치로(마치 듀얼vga 초창기 조절했던 것 처럼) 조절 할 수 있게 한다면? 저전력으로 빠른 부팅(mp3을 틀기위해서나 인터넷 강의 들을때 윈도우 켜는것도 귀찮다!!!), 빠른 인터넷 사용을 보장하는 크롬OS와 전력소모는 많더라도 게임이든 고사양 그래픽 작업이든 가능한 OS가 공존할 수 있지 않을까?

 물론 구글이 원한것과는 다른 방향이겠지만 굳이 만들어주겠다는데 안 쓸 이유는 없다. 또 사실 크롬OS가 리눅스 위에 크롬 웹 브라우져를 올려 실행시키는 것이다 보니 추후 안드로이드와의 합체 가능성도 기대해 볼 수도 있다.(4기가정도의 낸드플래시에 안드로이드 앱 설치해 가지고 노는용도로도 괜찮을 거 같다) 구글이 선택할 수 있는 경우의 수는 여러가지이다. 나는 앞으로 구글이 크롬OS를 위해서 어떤 선택을 가져가는지 기대해본다.