프로그래밍 언어를 컴파일러,인터프리터 언어로 구분짓는건 올바른 행위인가?

파이썬은 인터프리터 언어, C언어는 컴파일러 언어지 ?

이 정보는 대부분 많은 사람들이 알고있는 정보이지만, 사실 이 말은 반은 틀리고 반은 맞는 이야기 이다.
이 문장이 표현하는 의미에 대해서 자세하게 알아보자.

많은 사람들이 알고 있는 그림

처음에 아무것도 몰랐을 땐, 그저 이 그림처럼 심플하게, 컴파일러는 소스코드를 한번에 전부 읽고 실행파일을 만드는 것과, 인터프리터는 소스코드에 담겨있는 한 문장씩 번역하고 실행하는 것의 차이만을 이해하였다.

파이썬이라는 언어는 실행시킬때 한 문장씩 번역,실행이 되는구나!
C언어는 실행시키면 한번에 전부 읽어서 번역하여 실행파일을 만들어 두는구나!

라고 두가지의 개념으로 프로그래밍 언어를 구별 했으나, 이 차이는 언어를 구분짓는 올바른 비교점이 아니였다.

컴퓨터의 세계에서는 0과 1밖에 존재하지 않는 세계이다.

컴퓨터의 세계에서도 0과 1로만으로도 모든 것을 표현할 수 있다.
너무나도 저차원적인 세계이기에 우리는 그들을 이해할 수 없고, 그들에게는 인간은 너무나도 고차원적인 세계이기에 우리를 이해할 수 없다.
하지만, 서로의 언어를 이해하지 못하는 상황이기만 하였다면 얼마나 좋았을까.

컴퓨터는 스스로 움직이지 못한다.

그들을 위해 명령을 내려야 하고, 일정한 목적을 위해 명령들을 조합해야 한다. 간단한 수학 계산의 값을 알고 싶다면, 1 + 1라는 연산을 먼저 주문하고, 그 결과를 사람이 볼 수 있는 화면으로 출력하도록 해야 한다. 이것이 바로 프로그램이다.

프로그램 개발의 시작

프로그램의 작성은 따라서 명령의 집합을 표현하는 일, 즉 프로그램 소스코드를 짜는 작업으로부터 시작한다. 종이에 손으로 쓸 수도 있지만, 사람들은 소스코드 자체도 컴퓨터를 이용해 작성해 나갔다.

초창기에 컴퓨터의 소스코드 구성은 어떠하였을까?

이 시기에 주목할 만한 점은, 운영체제나 API(Application Programming Interface)와 같은 프로그램과 컴퓨터 사이의 미들웨어(middleware)가 매우 희박했고, 따라서 프로그램의 제작 방식이 매우 극단적이었다는 점이다. 컴퓨터가 제공하는 자원을 완벽히 활용하려면 기계어로 직접 통제할 줄 알아야 했기에, 많은 사람들이 직접적으로 기계어(0,1) 을 공부하여 개발하였다. 이것은 굉장히 어려웠다.

이건 단순히 외국인과 대화하는 수준이 아니다. 외국인은 사람이지만, 컴퓨터는 사람이 아니다. 농담이 아니라, 외계인과 대화한다고 해도 무방하다.

어셈블리 로는 부족해!

인간은 컴퓨터의 계산능력을 필요로 하고, 컴퓨터는 인간이 없으면 동작할 수 없는 친구들이기에, 컴퓨터가 이해할 수 있으면서,인간에게도 좀 효율적이고 편하게 작성할 수 있는 규칙을 고안해야 했다. 그리고 1948년쯤, 인간은 컴퓨터와 친해지기 위한 첫번째 걸음, Assembly(어셈블리) 를 개발하게 되었다.

어셈블러 소스 코드는 기계어에 비해 이해하기 굉장히 쉬웠으며, 일련의 세부적인 명령으로 구성되기 때문에 명령의 수가 많고 장황하였다. 어셈블러의 등장으로 많은 개발이 이루어질 줄 알았건만,그럼에도 아직까지도 매우 열악한 가독성 및 유지보수 편의성, 낮은 개발자 생산성, 무엇보다 특정 하드웨어에 대한 의존성과 같은 단점이 너무 거대하였다.

Fortran 의 등장

인간은 이러한 문제에 포기할리 없었고, 그리하여 어셈블리가 등장하고 몆년 뒤,2세대 언어가 개발됐다. 가장 먼저 나온 고수준 언어는 Fortran(포트란)이다. 포트란은 Formula Translation의 줄임말이다. 이름 그대로 이 언어의 핵심 개념은 공식 변환이다.

Fortran 언어의 핵심 개념의 대한 자세한 내용은 따로 찾아보길 바란다.

어셈블리와 고급 프로그래밍 언어의 심플한 차이

어셈블리 프로그램은 어셈블러를 통해 기계 프로그램으로 변환되지만 포트란은 같은 목적으로 컴파일러라는 것을 사용한다. 컴파일러는 고수준 소스 코드를 기계 코드로 변환할 뿐만 아니라, 최대한의 속도를 내고 최소한의 메모리 요건을 갖도록 프로그램을 최적화하는 역할도 한다. 컴파일러의 등장이 없었다면 우리는 어셈블리어 를 공부해서 기계어와 1:1 대응되는 수많은 명령어들을 외워서 사용하고 있을지도 모른다.

고급 프로그래밍 언어의 핵심은 고수준 언어의 규칙이 아닌, 고수준 언어를 기계어로 바꿔주는 컴파일러에 담겨있었다!

컴파일러의 작동원리

컴파일러에 안에 들어있는 내용들을 설명하려고 하면 velog 포스트가 100개가 있어도 부족할 지경이다. 고로 정말 단순하게 설명한다면, 완성된 소스코드를 컴파일러에게 건네주고, 컴파일러는 처음부터 끝까지 읽고 번역하여 기계어로 된 코드를 작성하고 실행시키는 로직을 가지고 있다.

이러한 환경속에서 개발자들은 기분좋게 개발일을 이어가나 했으나.. 인간의 욕심은 끝이 없었다!

컴파일러의 기술적 한계

이 컴파일러 기술의 단점은 디버깅이 용이하지 않았다는 점이 개발자를 거슬리게 한 것이였다. 프로그램이 항상 개발자의 뜻대로 완벽하게 개발 될일은 극히 드물다.
그러다 보니 개발자는 디버깅 작업에 많은 시간을 쏟게 되는데, 특히 오류를 찾아내고 수정하는 과정속에서 소스코드를 일부분만 수정하여도 컴파일러는 처음부터 끝까지 다시 읽어내서 번역하여 또 기계어 코드를 또 만들다보니, 상당히 불필요하고 비효율 적인 작업이였다.

인터프리터 개념의 등장

그래서 맨 초기에는 프로그램 실행도구로써 인터프리터라는 기술이 개발 되었고, 인터프리터는 프로그램을 한 줄씩 읽어가면서 바로 실행해보는 방식으로 작동하여, 이는 프로그래머가 코드를 작성하면서 바로바로 결과를 확인할 수 있게 해주어, 특히 프로그램의 오류를 발견하고 수정하는 데 큰 도움을 줄 수 있게 된 것입니다.

초기에는 인터프리터가 디버깅 도구로서 중요한 역할을 했다고 볼 수 있습니다.

디버깅 도구를 넘어서 하나의 번역기의 자리로 위치하다.

하지만 그렇다 해서, 인터프리터 기술이 단지 디버깅 도구로만 사용된 것은 아닙니다. 컴파일러와 대조되게 성능면에서는 취약한 것은 사실이나, 프로그래밍을 보다 쉽고 접근하기 쉽게 만들었기 때문에 Fortran 에 이어 두번째로 오래된 고급 프로그래밍 언어인 LISP 라는 언어에 인터프리터 기술을 핵심 번역기로 설계하여 만들어 지기도 하였습니다.

마지막으로, 이제는 말할 수 있다.

고급 프로그래밍 언어는 컴파일,인터프리터 방식을 논할 수도 구분 지을수도 없다. 이것은 언어의 속성이 아니다. 과거의 언어들도 컴파일러,인터프리터 두가지 방식을 이용해서 소프트웨어 개발을 할 수 있었다.
C언어는 컴파일러 언어고 Python은 인터프리터 언어라서 다른 번역기는 사용할 수 없다고? 그런 사람이 있다면 얼른 그 자리를 떠나라. C언어도 인터프리터를 이용해 개발할 수 있고, Python 또한 컴파일러를 이용해 개발할 수 있다.

중요한 것은 언어 구현체의 디자인이다.

어떤 언어가 컴파일러 방식으로 구현되어 있든, 인터프리터 방식으로 구현되어 있든 간에 CPU가 실행할 수 있는 명령은 모두 네이티브 코드인 CPU 인스트럭션 뿐이며, 개개의 CPU 인스트럭션은 아주 간단한 명령들이다.

이 두 기술은 언어 구현에 있어서 접근법이며, 기존에 존재하는 언어라도 새 구현체를 만들어서 그 작동 방식을 바꿀 수 있다.
지금 개발되고 있는 언어들 , 오래된 언어들은 언어 구현에 있어서 장점만을 취하는 형태로 사용하거나, 필요한 경우에 두가지 방식을 모두 포함하는 형태로 개발되고 있다.

따라서 어셈블리나 기계어로된 코드가 아닌 이상 대부분의 언어는 번역이 필요하고, 소스코드로부터 출발해서 기계어 코드가 실행되는 과정에서 가장 비용이 많이 드는 구간은 소스코드를 해석하는 과정이다.

기술이 아무리 발전하여도, 모든 언어의 시작점이 고수준 언어로 올라간들, 항상 종착점이 기계어로 변환이 필요하다 라는 것을 잊지 말아야 한다.

참고 자료:
컴파일러 원리,기법,도구
컴파일러와 인터프리터의 차이_Hansu Kim
프로그래밍의 간단한 역사 IT World
개발자의, 개발자에 의한, 개발자를 위해 발전한 개발툴