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

http://news.hankyung.com/201202/201202093840t.html?ch=news

한국경제 기사인데...
이거 좀 재밌다.

http://ask.nate.com/qna/view.html?n=11065854

화이트 데이 선물로 어떤게 좋냐고 질문하면.
반짝이는거, 구두, 사람만한 인형 등등이 나오는데...
남자들은 순수하게 편지를 받고 싶어해야만 하는건가?

늘 그랬듯 제목 낚시에 퍼덕퍼덕

동아일보에 다음과 같은 기사가 떳다.

http://news.donga.com/Politics/New/3/00/20120205/43810223/1

뭐 간단히 요약하면 미군의 예산 감축때문에 '탱크 킬러'라고 불리우는 A-10공격기를 감축한다는 논지의 글이다. 그런데... 이거 당연한거 아닌가?

일단 A-10기체의 가장 주 공격무기가 30mm 기관포다. 그런데 이 녀석의 유효 사거리가 처음에 나왔을 때에는 지대공 무기들에 비해서 길었지만 지금은 지대공 무기들에 비해 짧다. 즉 기관포로 탱크를 조준사격하여 파괴시키려면 A-10기체가 지대공 무기에 격추될 가능성을 안고 싸워야 한다는 소리다.

또한 A-10은 저속기종이다. 최고속력이 마하 1을 넘지 못한다. 따라서 유도미사일 공격에 상대적으로 취약할 수 밖에 없다. (이점은 플레어를 뿌린다 해도 마찬가지다.) 따라서 이 A-10기가 전쟁에 임하기 위해서는 F-22내지는 F-15등의 공중우세기(F-22는 공중우세기 따위로 불리기엔 좀 뭐하지만;;;)로 제공권을 장악한 이후에나 출격해서 싸울 수 있다. (그래도 지대공 미사일 때문에 기관포는 못쓴다.)

미공군이 보유하던 A-10 기종중 가장 많은 기종이 A-10A인 것으로 알고 있는데 이 기종은 심지어 유도미사일 발사 기능이 없다. 애초에 냉전시기에 대량생산을 목적으로 단가를 낮춘 기종이기에 지상공격을 위한 장치를 제외하고는 철저히 배제되어 있었다. 현재는 A-10C기로 개량되어 유도기능이 있다고는 하는데 사실 이도 A-10기를 F16기종으로 교체하고자 하던계획이 예산의 압박으로 물거품이 되자 A-10기를 개량하여 실전에서 사용할 수 있게끔 개량을 해놓은 것이다.(우리가 일반적으로 아는 F16, F15등에는 기본으로 달려있다.)

이 점을 놓고 다시 말하면 A-10은 일반 전투기들에 비해서 최대적재량이 크다는 이점 말고는 아무것도 남지를 않는다. 반면에 다시 생각해보면 공중전도 제대로 안되, 저렴한 무기(기관포)를 이용해 지상의 적을 효율적으로 파괴하는 것도 아니야. 그렇다고 폭격기들에 비해서 적재량이 높은것도 아니야... 뭐 이도저도 아닌 그런 기체가 되어버린거다.미공군의 입장에서 비행기들을 도태시켜야 한다면 A-10이 가장 먼저 도태되는건 당연한 것 아닐까?.
 
사실 나는 좀 걱정인게 저 글의 리플을 보면 저 기체들 사와서 사용하자는 글들이 많던데 사실 우리나라의 지형에서는 A-10기체보다는 아파치 헬기 쪽이 더 강력한 위력을 갖기도 하고,(산악지형으로 회피기동 가능) 도태가 예정되어 있기도 한 기체를 사자는것을 보면서 그냥 좀 한숨이 나온다...

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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