튜링상 관련 업적
고급 프로그래밍 기술 분야와 컴파일러 제작 분야에 미친 영향
1966년 튜링상 선정 이유2
고급 프로그래밍 언어high-level programming language와 컴파일러compiler는 땔래야 땔 수 없는 관계이다. 고급 프로그래밍 언어가 실제로 현장에서 사용되기 위해서는 그 언어를 기계어로 변환해주는 컴파일러가 필수적으로 있어야 하기 때문이다.
튜링상 수상자가 처음으로 선정된 해는 1966년이다. 이때는 이미 컴퓨터가 군사용에서 벗어나 산업용으로 널리 퍼지기 시작한 때였다. 기업의 회계 업무를 자동화하고 각종 통계 처리에 적극 활용되었다. 그러면서 컴퓨터 프로그래밍 산업이 모습을 드러냈다. 정부 연구소와 학교 연구실에서만 이루어지던 프로그래밍 개발을 하나의 업으로 삼는 회사가 등장한 것이다.5 아직 소프트웨어라는 단어조차 등장하기 전이었고 소프트웨어 프로그램이 거래가 가능한 물건이 될 수 있다는 생각까지 이르지는 못했지만 특정 업체로부터 개발을 수주받아서 전용의 프로그램을 작성해주는 도급개발 회사들이 성장하고 있었다. 이렇게 프로그래밍이 하나의 산업이 될 수 있었던 것은 포트란이나 코볼COBOL과 같은 고급 프로그래밍 언어가 있었기 때문이다.
앨런 펄리스는 1956년에 IT라는 컴파일러를 개발함으로써 이 분야의 선도자가 되었다. IT 컴파일러 자체는 큰 성공을 거두지 못했지만 다른 컴파일러 개발에 큰 촉매제가 되었다. 또한 이런 경험이 그를 알골 언어 설계의 적임자로 만들었다. 알골은 현대 프로그래밍 언어의 틀을 만들었다.
알골에 대한 논의가 시작된 1957년을 돌이켜보면 이른바 수요와 공급의 불균형이 심각한 상태였다. 전자식 컴퓨터가 품은 가공할 가능성에 모두들 반했지만 그 가능성을 현실화하기에는 프로그래밍이 너무도 힘들었다.
컴퓨터 프로그래밍이라는 개념은 19세기의 찰스 배비지로 거슬러 올라간다. 그가 제안한 해석엔진Analytical Engine이라는 이름의 계산 기계는 프로그램을 입력받아 수행하는 방식이었다.6 처음 만들 때 기능이 고정되어 버리는 것이 아니라 프로그램에 의해 다양하게 기능이 바뀔 수 있는 기계에 대한 동경은 마침내 ENIAC에서 이루어졌다. 하지만 ENIAC의 프로그래밍 방식은 오늘날의 컴퓨터와 사뭇 다르다. 오늘날의 컴퓨터에서는 프로그램이 기계어 코드들로 구성되지만, ENIAC에서는 컴퓨터를 구성하는 하드웨어 구성요소들을 전선으로 연결하는 것이 프로그래밍이었다. 매우 손이 많이 가고 정신 없는 방식이었다.
그래서 하나의 대안으로 오늘날의 컴퓨터에서 볼 수 있는 저장형 프로그래밍 방식이 제안되었다. 메모리라는 공간에 기계어 코드들을 넣어놓고 차례차례 하나씩 그 기계어 코드들을 처리하는 방식이다. 물리적으로 전선을 다시 연결하지 않아도 되니 훨씬 편한 방법이었다. 이제 프로그래밍은 전선의 연결이 아닌, 기계어 코드의 나열이 되었다.
그렇지만 기계어 코드를 다루기는 쉽지 않았다. 당시의 컴퓨터를 사용하는 가장 큰 목적은 수치 계산이었다. 행렬이나 방정식을 계산하는 일이 대부분이었다. 수학 공식을 기계어 코드로 변환하는 일은 많은 시행착오를 요구했다. 가장 초창기의 컴퓨터 사용자들은 즉각 문제의식을 가졌다. 한두 번이면 몰라도 이런 까탈스러운 작업을 계속 반복한다는 것은 어처구니 없었다.
최초의 저장형 프로그래밍 방식 컴퓨터 중 하나로 꼽히는 EDSAC의 사용자도 같은 생각이었다. 일단 컴퓨터를 만들고 나서 써보려고 하니 고난의 연속이었던 셈이다. 뭔가 개선안이 필요했다. 그래서 나온 것은 어셈블리어와 서브루틴 호출이다.
어셈블리어는 기계어 코드를 인간이 이해하기 쉬운 자연어로 표현하는 방식이다. 예를 들어 1과 2를 더하는 일을 해야 한다고 가정해보자. 이를 기계어 코드로 표현하면 다음과 같을 수 있다.§§
0001100000010002그냥 봐서는 이게 무슨 일을 하는 기계어 코드인지 알 수가 없다. 컴퓨터의 기계어 설명서를 뒤져서 한 비트씩 분석해야만 이것이 1+2를 의미함을 알아낼 수 있을 것이다. 위의 기계어 코드 구조를 분석하면 다음과 같다.
00011000 0001 0002
(더하기) (1) (2)그렇다면 이제 아래와 같이 표현할 수 있지 않을까?
ADD 1, 2직관적으로 우리는 이것이 1과 2를 더하는 작업임을 눈치챌 수 있다. 앞의 코드와 이 코드의 차이점이라면 단지 표현 방식을 바꾼 것이다. 후자와 같은 방식을 어셈블리어assembly language 프로그래밍이라고 한다. 어셈블리어 코드를 사용하면 기계어 코드를 직접 사용하는 것에 비해 실수를 줄일 수 있다. 그렇지만 어셈블리어로 작성한 코드를 그대로 컴퓨터에 입력할 수는 없다. 왜냐하면 컴퓨터가 이해하는 코드는 반드시 기계어로 되어 있어야 하기 때문이다. 따라서 이 직관적인 어셈블리어 코드를 기계어 코드로 변환하는 과정이 필요하다. 그 역할을 해주는 프로그램을 어셈블러assembler라고 한다.
서브루틴subroutine은 코드의 재사용을 도와주는 방법이다. 예를 들어 제곱근을 계산하는 코드를 작성했다고 가정해보자. 제곱근 계산이 필요할 때마다 똑같은 코드를 다시 작성하는 일은 무척이나 비효율적이다. 특히나 기계어 코드로 다시 작성하는 일은 생각만 해도 끔찍할 것이다. 따라서 제곱근을 계산하는 코드를 일단 작성하면, 필요할 때마다 이 코드를 가져다 사용하는 것이 현명하다. 서브루틴의 개념은 최신 프로그래밍 언어에도 그대로 이어져오고 있다.
현대적 프로그래밍 언어의 탄생
어셈블리어와 서브루틴 재활용은 급한 불을 꺼주는 역할을 했다.¶¶ 1950년대 초반에 컴퓨터를 보유한 기관의 수는 손에 꼽을 정도였다. 이곳의 프로그래머들은 어셈블리어와 서브루틴 재활용을 통해 일의 효율을 높일 수 있었다. 하지만 여전히 개선점이 눈에 보였다.
어셈블리어는 코드를 직관적으로 이해하기 쉽게 도와주기는 했으나 여전히 컴퓨터의 기계어를 익혀야 한다는 문제가 있었다. 컴퓨터마다 기계어가 달랐기 때문에, 좀 더 구체적으로 보자면 하드웨어 구조를 알아야만 사용할 수 있었기 때문에 프로그래머를 확보하기가 쉽지 않았다. 좀 더 인간의 언어에 유사하고 하드웨어에 독립적인 방식이 필요했다.
서브루틴의 사용도 개선이 필요했다. 단순히 서브루틴을 복사해서 사용하게 되면 그만큼 프로그램의 크기가 증가하게 되는데 메모리 용량이 작았던 당시의 컴퓨터에서는 심각한 단점이었다. 또한 서브루틴의 인자값과 결과값을 정교하게 다룰 방법이 필요했다.
현대적인 프로그래밍 언어는 Autocode에서 시초가 보였다.7 영국 맨체스터(Manchester) 대학교의 Mark I 컴퓨터에 구현된 Autocode는 기계어의 구조를 몰라도 프로그래밍할 수 있었다. 값을 저장하는 대입문assignment, 값을 비교하는 조건문conditional statement, 프로그램의 수행 흐름을 바꾸는 분기문jump statement, 서브루틴 호출문 등이 등장했다. Autocode로 작성된 프로그램을 기계어로 변환해주는 컴파일러도 개발되었다.
최초의 컴파일러는 서브루틴 사용 개선에서 비롯되었다. 최초의 컴파일러라고 간주되는 A-0 컴파일러는 현대적인 의미의 컴파일러라고 보기는 어렵다. 현대적인 관점에서 본다면 링커linker에 가깝다. 즉 여러 개의 기계어 코드 덩어리들을 하나로 합쳐주는 역할을 한다.8 A-0 컴파일러가 입력으로 받아들이는 프로그램 코드는 서브루틴 호출문들을 모아 놓은 형태였다. 그저 서브루틴 호출들을 나열한 것에 지나지 않았다. 컴파일러Compiler라는 이름이 붙은 이유도 서브루틴 코드들을 컴파일compile 즉, 차곡차곡 하나로 모으는 일을 하기 때문이었다.
이런 초기 컴파일러들은 여러 문제점을 가지고 있었는데 가장 심각한 것은 효율이었다. 프로그래밍 시간을 단축시키려는 목적이 매우 컸음에도 불구하고 컴파일러 자체의 효율이 너무 떨어져서 컴파일에 걸리는 시간이 너무 오래 걸렸을 뿐만 아니라 변환된 코드의 효율도 너무 떨어졌다. 사용상의 여러 제약과 처리 비효율로 인해서 컴파일러는 현장에서 받아들여지지 않았다.
1957년에 포트란이 발표되자 상황은 바뀌었다. 포트란은 비교적 일반 언어에 가까운 표현을 사용했기 때문에 이해하기가 쉬웠고 무엇보다도 결과물의 효율이 좋았다. 새로운 세상을 맛 본 프로그래머들은 이제 옛날로 돌아가고 싶어하지 않았다. 포트란을 개발한 IBM은 포트란 덕분에 컴퓨터를 더 많이 판매할 수 있었고 컴퓨터 업계를 단번에 휘어잡았다. 꼬리인 줄 알았던 프로그래밍 언어가 몸통을 흔들었다.
더 편리하고 효율적인 프로그래밍 언어를 위한 제안이 쏟아졌다. 누군가 이를 조율해서 궁극적으로 완벽한 프로그래밍 언어를 제시해야 할 필요가 있었다. 그렇게해서 알골은 태어났다.
답글 남기기