프로그래밍 라이브러리

저장형 프로그램 방식의 전자식 컴퓨터를 처음 만든 이들에게 프로그래밍은 새로운 도전이었다. 0과 1의 조합으로 된 기계어 코드는 직관적으로 이해되기 어려웠고 그래서 완전한 프로그램을 작성하는 일은 고단했다.

초기의 컴퓨터는 수학 계산을 위해 만들어졌다. 하지만 컴퓨터 프로세서의 핵심에 있는 산술 계산부Arithmetic Unit는 일반적으로 덧셈과 곱셈까지만 지원했다. 뺄셈은 보수complement 계산 방식을 사용하면 덧셈으로 구현이 가능했지만 나눗셈은 그것이 어려웠다.

단순한 사칙 연산만 처리하는 컴퓨터는 의미가 없었다. 삼각함수나 로그함수 등을 할 수 있어야 했다. 그래서 프로그래머는 방정식 계산을 위한 프로그램을 작성하려면 결국 나눗셈을 위한 코드와 삼각함수 등을 위한 코드를 짜야 했다. 이런 계산은 같은 프로그램 내에서도 반복적으로 나타날 수 있었고, 새로운 프로그램에서 또 다시 필요할 수 있었다.

고된 프로그래밍 노동을 덜어주기 위해서 윌크스가 이끄는 팀은 서브루틴subroutine이라는 개념을 제시했다. 그의 밑에서 일한 휠러가 최초의 서브루틴 코드를 작성했다. 서브루틴이란 어떤 특정한 일을 하는 코드 덩어리를 말한다. 앞에서 언급한 나눗셈이나 삼각함수 등과 같은 일이 예가 될 수 있다. 나눗셈용 서브루틴은 두 개의 값을 전달받으면 두 개의 값으로 나눗셈을 계산하는 코드 덩어리이다.​9​ 이런 나눗셈용 서브루틴이 이미 만들어져 있다면 프로그래머는 그 코드를 그대로 재사용하면 된다. 그가 새로 작성하는 프로그램 내에서 나눗셈 계산이 필요한 지점이 있으면 나눗셈용 서브루틴을 호출하는 것이다. 여기서 ‘호출’이라는 것은 프로세서가 해당 서브루틴이 저장된 메모리 번지로 이동하는 것을 말한다. 계산에 사용될 두 개의 값이 특정 장소(메모리의 특정 번지 혹은 프로세서 내의 저장공간)에 있다고 미리 약속되어 있으므로, 서브루틴으로 이동하기 전에 그 특정 장소에 피제수dividend와 제수divisor를 저장해야 한다.

‘호출’된 나눗셈용 서브루틴은 미리 약속되어 있는 특정 장소에서 두 개의 값을 가져온 후에 나눗셈 계산을 하고 그 결과값인 몫quotient을 역시 미리 약속된 특정 장소에 놓아 둔다. 이제 서브루틴의 일이 끝났으므로 원래의 프로그램으로 되돌아가야 할 것이다. 이를 위해서 서브루틴으로 이동하기 전에, 되돌아올 코드 위치의 주소를 역시나 미리 특정 장소에 저장해 놓은 상태이다. 따라서 서브루틴이 종료되면 그 특정 장소에 저장해 놓은 주소값을 읽어 그 위치로 이동한다(즉, 되돌아간다).​10​

윌크스와 휠러는 서브루틴이 매우 유용함을 체감했다. 그래서 이들은 프로그래밍 방법에 관한 책에 서브루틴을 포함시켰다. 수학용으로 사용될 수 있는 공통 작업들은 많았다. 나눗셈, 삼각함수, 로그함수, 절대값 등은 방정식 계산에서 언제든지 필요할 수 있었으므로 이렇게 자주 사용될 가능성이 높은 작업을 서브루틴으로 만들어 모아 놓으면 좋을터였다. 윌크스와 휠러는 이것을 프로그래밍 라이브러리programming library라고 불렀다.

수학적 연구소의 프로그래밍 방법론은 당시로는 매우 획기적이었다. 존 폰 노이만이 이끌던 프린스턴의 고등연구소 팀도 얼마 후 저장형 프로그램 방식의 컴퓨터를 완성했지만, 기계어를 그대로 사용해서 프로그래밍을 했다. 이런 차이는 연구소의 전반적인 분위기가 달랐기 때문으로 해석된다. 케임브리지의 EDSAC은 처음에 학계로부터 큰 관심을 받지 못했다. 윌크스 교수가 컴퓨터를 만들겠다고 열변을 토하면 주위에 있는 교수들이 모두 피하는 분위기였다고 한다. 그래서 EDSAC이 완성된 직후에는 주로 젊은 학생들이 참여해서 작은 프로그램들을 작성했다. 이들이 그 결과물을 지도교수에게 보고하자 그제서야 교수들이 흥미를 보이기 시작했다고 한다.​4​ 이에 비해서 고등연구소는 폰 노이만이 주도적으로 이끌었고 그에게는 컴퓨터로 풀고 싶은 문제들이 있었다. 사용자가 제한되어 있었으므로 프로그래밍의 편이성에 대한 고민이 영국 쪽에 비해 적었다.

프린스턴에서는 디테일에 대한 관심이 덜했습니다. 그건 그들이 몇 개 안 되는 아주 큰 프로그램들을 돌렸기 때문이라고 생각합니다. 예를 들어서 펀치 테이프를 로딩하는 방식을 보면, 우리는 테이프의 처음 시작 지점에 아무것도 찍혀 있지 않아도 되었습니다. 컴퓨터가 알아서 첫 번째 구멍이 찍힌 지점을 찾아 로딩을 했죠. 하지만 프린스턴의 기계는 정확하게 테이프의 특정 지점부터 구멍이 뚫려 있어야만 했습니다… 기본적으로 관심사가 좀 달랐던 거죠. 우리는 특히나 사용자가 결과를 얻어내기 쉽게 만들려고 노력했습니다. 그래서 프로그래밍 스타일도 아주 일찍부터 모듈화했지요. 그리고 우리는 폰 노이만이 지지하던 흐름도flowchart를 알고 있었지만 뭔가를 설명할 필요가 있을 때가 아니면 실제로는 사용하지 않았습니다. 문제를 이해하고, 그것을 서브루틴으로 분할한 후, 메인 프로그램의 통제 아래에 있도록 그 서브루틴들을 잘 배치한다면 굳이 흐름도 없이도 프로그램을 돌아가게 만들 수 있다는 것이 우리의 생각이었습니다.​11​

1 2 3 4 5 6 7 8