튜링상 관련 업적
8번째 튜링상 수상자인 찰스 바크먼은 이전의 수상자 일곱 명과는 좀 다르다. 우선 그는 학계 출신이 아니라 산업계 출신이다. 이전의 수상자들은 천재적인 자질을 어린 시절부터 보여주었다는 무용담(?)을 가지고 있었으며 대부분 박사 학위 소지자였고 대학 혹은 연구소에서 대부분의 생애를 보냈다. 이에 비해 바크먼은 공부 좀 하는 이과생 정도였고 석사 학위를 가지기는 했으나 논문 없이 받은 학위였다.
좀 가방끈이 밀린다(?)고 볼 수 있는 그가 쟁쟁한 후보들 중에서 수상자로 선정된 것은 그만큼 그의 업적이 뛰어났기 때문이라고 보아야 옳겠다. 데이터베이스가 없는 컴퓨터 시스템은 상상하기가 어려운 현재의 상황을 본다면, 약 50년 전에 그에게 튜링상을 수여한 ACM 회원들의 안목에도 새삼 놀라게 된다.
그가 데이터베이스라는 신세계에 도달하는 과정을 보면 그의 도전 정신에 감탄할 수밖에 없다. 그가 대학원을 선택하는 과정이나, 회사 내에서 업무를 처리하는 과정을 보면 그는 항상 주저하지 않고 부딪혔으며 새로운 것을 두려워하지 않고 시도하는 사람이었다.
데이터베이스
데이터베이스Database에 대한 정의는 다음과 같다.
여러 사람이 공유하여 사용할 목적으로 체계화해 통합, 관리하는 데이터의 집합이다.3
위키피디아 한글판
A database is an organized collection of data stored and accessed electronically.4
위키피디아 영문판
위키피디아 영문판과 한글판에 차이가 있다. 한글판에서는 ‘여러 사람이 공유한다’는 목적을 명시하고 있으나 이는 조금 애매하다. 데이터베이스가 반드시 공유를 염두에 두는 것은 아니기 때문이다. 영문판의 정의가 더 정확하다. ‘전자적electronical‘으로, ‘저장store‘하고 ‘접근access‘할 수 있는, ‘잘 정리된organized‘, 데이터들의 모음이라고 보아야겠다.
컴퓨터의 본래 목적은 ‘계산’하는 기계였다. 하지만 컴퓨터가 등장하고 얼마 되지 않아서 그 용도는 ‘데이터를 저장하고 접근’하는 용도로 확장되었다. 이미 기관이나 기업에서는 대량의 데이터를 자동으로 처리하기 위해서 제표기tabulator라는 기계를 사용해왔었다. 제표기는 펀치카드나 펀치테이프를 입/출력장치로 사용했다.
제표기는 기계적으로 데이터를 정렬하거나 분류하는 일을 할 수 있었고, 지속적으로 개선을 통해서 덧셈과 같은 산술연산도 처리할 수 있었다. 아울러 동작하는 방식이나 순서를 제어하기 위한 장치가 있어서, 일종의 프로그래밍이 가능했다.
전자식 컴퓨터가 기계식 제표기보다 더 빠름은 당연했다. 따라서 기업에서는 기존의 제표기를 전자식 컴퓨터로 대체하기 시작했다. 기업에서 초기에 적용한 분야는 급여payroll 처리였다. 직원의 급여를 처리하기 위해서는 직원에 대한 정보를 다루어야 했고 한 번 쓰고 버릴 정보가 아니었으므로 어딘가에 저장했다가 다시 사용해야만 했다. 그런 정보는 펀치카드나 펀치테이프에 저장되었다.
전자식 컴퓨터의 성능을 극대화하기 위해 빠른 입출력장치의 등장은 필연적이었다. 기계장치를 통해 다루어지는 펀치카드와 펀치테이프의 자리를 자기테이프가 대신하게 된다. 자기테이프는 입출력 속도가 훨씬 빨랐다.
하지만 자기테이프에도 결정적인 단점은 있었다. 자기테이프는 임의 접근random access 혹은 직접 접근direct access가 불가능했다. 자기테이프에 저장된 특정데이터에 접근하려면 테이프의 처음부터 계속 감아나가면서 찾아야 했다. 위치를 미리 알고 있는 경우라고 해도 그 자리가 헤드에 올 때까지 테이프를 감아야 하므로 시간이 많이 소요되었다. 이런 문제는, 데이터를 통째로 모두 처리하는 일괄처리batch processing에서는 쟁점이 되지 않았다. 어차피 모든 데이터에 접근하려면 테이프를 처음부터 끝까지 모두 읽어야 하기 때문이었다. 예를 들어 모든 직원들의 이번 달 급여를 계산하는 경우라면 문제 될 것이 없었다. 하지만 만약 특정 직원의 급여만 다시 계산해야 한다면 너무도 비효율적이었다.
1961년에 GE에서 찰스 바크먼이 IDS를 개발하던 시기로 거슬러 올라가 보자. 이때는 아직 데이터베이스라는 용어조차 없던 시기이다. 사실 그 당시에는 대다수의 컴퓨터 기술이 아직 등장하기 전이었다.
범용 운영체제도 없었고, 파일시스템이라는 것도 없었고, DBMS도 없었고, 통신시스템도 없었다. 멀티 프로그래밍도 없었고, 시분할 시스템도 없었고, 온라인 디버깅 도구도 없었다. 본질적으로 컴퓨터에는 아무것도 없었다. 비즈니스 데이터 처리는, 일괄처리에 한 번에 한 프로그램만 수행하는 식이었고 파일도 직렬 처리serial processing 방식이었다.5
1961년에 찰스 바크먼이 만들어야 했던 시스템은, 제품 생산과 관련된 정보들을 저장 장치에 저장해 놓고 어떤 구별 가능한 값key value, 예를 들면 제품 번호 같은 것을 사용해서 접근하고 수정할 수 있어야 했다. 제품에 대한 정보는 여러 개의 정해진 세부 정보들의 모여서 단위를 이루었다. 예를 들어 주문일, 인도일, 제품 담당 부서, 제품을 위한 부속품 정보 등이다. 지금의 관점에서는 너무 일상적인 구조이지만, 당시로는 처음 시도하는 일이었다.
그가 만든 IDS는 최초의 데이터베이스 관리시스템(DBMS)으로 간주된다. ‘데이터베이스’가 아니라 ‘데이터베이스 관리시스템’이라고 불리는 이유는, 단순히 데이터의 저장 시스템인 것이 아니라 이 데이터들을 생성, 접근, 수정, 삭제하는 기능까지 포함하기 때문이었다.
처음부터 바크먼이 ‘데이터베이스’라는 용어를 생각하고 IDS를 만든 것은 아니다. IDS와 같은 형태의 시스템을 사람들은 데이터 베이스 관리 시스템Data Base Management System이라고 부르기 시작했다. 이때까지만 해도 데이터베이스는 한 단어가 아니라 두 개의 단어였다. 바크먼이 원래 사용했던 표현은 ‘데이터 저장소Data store‘였다. 하지만 ‘데이터 베이스’라는 표현이 널리 퍼지자 그는 이를 받아들이면서 약간 손을 댔다.
딕 캐닝과 제가 비즈니스 데이터 처리에 관한 전문 잡지를 ACM에서 만들 때였습니다. 잡지 제목을 ‘데이터 베이스’로 할까 아니면 ‘데이터베이스’로 할까 고민했습니다. 우리는 ‘데이터’가 있는 ‘베이스’가 아니라 ‘데이터베이스’이어야 한다고 결정했습니다. 우리가 이렇게 한 단어로 합치자 다들 그렇게 사용하더군요.2
IDS
IDS는 MIACS 시스템을 구성하는 요소이다. IDS가 담당하는 일이란, MIACS 응용 프로그램이 요청하면 레코드record라고 부르는 데이터 덩어리를 만들고, 읽고, 고치고, 지우는 것이다. 너무 간단해 보이지만, 잊지 말아야 할 점이 있다. 주어진 것이라고는 자기 디스크가 달린 컴퓨터에 기계어 혹은 원시적인 코볼COBOL 프로그램이 전부였던 시절이었다. 오늘날 우리가 흔히 부르는 파일시스템이란 것은 없었고, 시스템 라이브러리도 존재하지 않았다.
IDS는 당시 막 등장했던 자기디스크를 물리적 저장장치로 선택했다. 자기 디스크는 데이터가 어느 위치에 있건 바로 접근이 가능했다. IDS는 물리적 장치뿐만 아니라 데이터를 다루는 방식도 최신 기술을 도입했다. 가상 메모리virtual memory와 페이징paging이 대표적이다. 예를 들어 설명해 보겠다.
어떤 제품에 대한 정보를 저장하고 다룬다고 가정해보자. 그러면 다음과 같은 세부 정보를 생각할 수 있다.
- 제품 일련번호
- 제품명
- 주문 입력 일자
- 인도 예정 일자
- 생산 부서
- 부품 1
- 부품 2
- 부품 3
- 부품 4
- 현재 진행 공정
IDS가 해야 할 일은 크게 4가지이다.
- 레코드 생성 – 저장 장치에 새로운 제품 정보를 만든다.
- 레코드 접근 – 제품 일련번호가 주어지면 해당 제품 정보를 읽는다.
- 레코드 수정 – 제품 일련번호와 새 데이터가 주어지면 해당 제품 정보에 접근한 후에 특정 세부 정보를 수정한다.
- 레코드 삭제 – 제품 일련번호가 주어지면 저장 장치에서 해당 제품 정보를 삭제한다.
가장 단순하게 만든다면 위의 4가지 요청이 발생할 때마다 저장 장치에 접근해서 필요한 작업을 수행하면 된다. 이를 위해 IDS는 제품 일련번호가 주어지면 해당 제품 정보가 디스크의 어느 위치에 있는지에 관한 정보를 별도로 유지하고 있어야 한다. 그런데 물리적 장치를 직접 접근해서 다루는 일은 기계어로 작성하기에 매우 까다롭다. 하드 디스크 드라이브인 경우에는, 드라이브 번호, 디스크 원반 번호, 트랙 번호, 섹터 번호 등을 다루어야 한다.
가상 메모리 구조를 사용하면 훨씬 일이 쉬워진다. 위의 네 가지 작업이 물리적 디스크가 아니라 컴퓨터 메모리에서 벌어지는 것처럼 프로그램을 작성할 수 있다. 물론 물리적 디스크에 있는 레코드들을 필요한 순간에 메모리로 옮겨주고 때가 되면 물리적 디스크로 되돌려주는 일을 하는 별도의 프로그램이 필요하기는 하지만 그것은 IDS와의 종속성 없이 구현될 수 있으므로 장점이 된다.
그리고 페이징 방식을 사용하게 되면, 물리적 디스크에서 어떤 레코드를 메모리로 옮겨 올 때 단 한 개의 레코드만 옮기는 것이 아니라 인접해 있는 여러 개의 레코드를 같이 한 번에 옮기게 되는데, 응용 프로그램이 인접한 레코드를 연속해서 접근하게 된다면 가상메모리 관리 시스템이 이 인접 레코드들을 물리적 디스크에서 새로 가져올 필요 없이 바로 메모리에서 처리할 수 있게 되므로 성능 향상을 꾀할 수 있었다.
페이징을 이용한 가상 메모리 시스템은 엄청난 성능을 보여주었다고 한다.
우리는 IAO(사내 자동화 운영)라는 GE 조직에서 테스트를 해봤습니다… 그 조직은 GE 내부와 외부에 자체 서비스를 판매했습니다. 아주 능력 있는 사람들로 구성되어 있었습니다. 빌 헬게슨이라는 아주 쾌활한 친구가 있었는데 우리가 만든 것에 대해 아주 부정적이었습니다… 회의가 끝난 후에 빌은 “좋아요, 한 번 테스트나 해봅시다”라고 말했습니다. IAO는 오하이오의 어느 동네에 있던 GE Laminated Products 사업부에 제조 제어 시스템을 막 설치한 상태였습니다. 그 친구들은 이렇게 말했죠. “글쎄, 당신들 시스템이 설치하기는 훨씬 쉬울 것 같아 보이는군요. 만약 성능이 우리의 절반 정도만 되어도 앞으로 우리가 하는 프로젝트에 IDS를 쓰도록 하죠… 2주 만에 우리 팀은 데이터를 포함해서 테스트를 위한 시스템을 구성했습니다. 그리고 테스트를 돌렸습니다. 결과는? 그쪽 시스템보다 두 배나 빨랐습니다. 빌은 어리둥절했습니다. “어떻게 당신 시스템이 두 배나 빠를 수 있죠? 우리는 정말 최선을 다해서 만들었는데…”2
지금의 관점에서 보면 더욱 놀라운 사실이 있다. ISP II 팀이 사용한 컴퓨터는 GE 225 모델이었는데 메모리 용량이 16K 바이트였다. 그런데 그중에서 MIACS 프로그램이 차지하는 공간은 8K 바이트였다. 오늘날 일반 개인용 컴퓨터의 메모리 용량이 8G 바이트를 기본으로 하고 있음을 생각한다면 엄청나게 작은 용량에서 동작했던 셈이다.
하지만 이게 끝이 아니었다. 당시 메모리는 자기 코어 방식이었고 가격이 너무 비쌌다. 그래서 GE 225 모델의 대부분은 메모리 용량이 8K 바이트였다. 그래서 IAO 조직에서는 MIACS가 4K 바이트에서 동작할 수 있게 해달라고 요청했다. 그래서 바크먼은 IDS 구조를 대대적으로 수정했다.
IDS의 초기 방식은 일종의 매크로 방식이었다. 앞에서 언급한 4가지 명령(생성, 접근, 수정, 삭제)은 해당 작업을 하는 구체적인 코드로 바꿔치기 된 후에 컴파일되었다. 따라서 예를 들어 접근 명령을 구현하는 코드가 10줄이라고 가정하고, 응용 프로그램에 접근 명령이 10번 나온다고 하면 실제 코드 내에는 10 * 10 = 100줄의 코드가 삽입되는 셈이다. 바크먼은 이것을 서브루틴 호출 방식으로 바꿨다. 접근 명령을 위한 서브루틴을 만들고 응용 프로그램에서 접근 명령이 나올 때마다 이 서브루틴을 호출하는 식이었다. 이렇게 하면 관련된 코드의 실제 크기는 10 + 10 = 20줄로 끝나게 된다. 바크먼은 서브루틴 방식으로 수정하게 되면 성능이 떨어질 것을 우려했다. 왜냐하면 이 부분을 컴파일 방식으로 만들 수 없고 인터프리터 방식으로 만들어야 했기 때문이었다.# 하지만 결과는 오히려 정반대였다.
인터프리터 방식은 원래 버전보다 두 배나 빠른 결과를 보여줬습니다. 정말로 더 빨리 동작한 것은 아니었습니다. 더 많은 메모리 공간이 가상메모리에 사용되니까 더 많은 페이지가 메모리에 올라왔고, 그러다 보니 디스크에 대한 접근이 줄어들었기 때문이었습니다.2
마지막으로 IDS에 포함된 또 하나의 기술은 링크형 리스트linked list 구조이다. 예를 들어, 제품에 관한 레코드들이 있다고 했을 때, 이 레코드들은 모두 한곳에 순서대로 저장된다고 보장할 수 없다. 처음에는 순서대로 저장했다고 하더라도 중간에 레코드가 삭제되고 새로 추가되는 일이 빈번하게 일어나다 보면 일련번호 순서대로 디스크 내에 저장된다고 장담할 수 없다. 그런데 응용 프로그램에서는 관련된 레코드들을 모두 순서대로 접근할 경우가 있을 수 있다. 앞에서도 언급했던 급여 계산하는 프로그램이 그러하다. 만약 어떤 레코드의 다음 차례 레코드를 바로 알 수 있다면 좋을 것이다. 이를 위해 IDS에서는 같은 유형의 레코드들이 모두 리스트 형태로 연결되어 있다. 그래서 어떤 레코드를 읽은 후에 GET NEXT라는 명령을 수행하면 현재 읽은 레코드에 저장되어 있는 다음 번 레코드의 주소를 이용하여 바로 접근할 수 있다.