Skip to content

Chapter 4 Grace Hopper: The First Software Engineer #1673

@jongfeel

Description

@jongfeel

Chapter 4 그레이스 호퍼: 최초의 소프트웨어 엔지니어

최초의 ‘진정한’ 프로그래머는 그레이스 호퍼라고 해도 과언은 아닙니다.
비록 그녀 이전에도 몇몇 사람이 프로그램을 작성하기는 했지만, 프로그래밍이라는 분야를 체계적으로 정립한 사람이 바로 호퍼였기 때문입니다.
이런 점에서 그레이스 호퍼를 최초의 소프트웨어 엔지니어라고 부르는 것이 더 적절할 것입니다.

호퍼는 주석, 서브루틴, 멀티프로세싱, 체계적인 개발 방법론, 디버깅, 컴파일러, 오픈 소스, 사용자 계정 및 그룹, 경영 정보 시스템 등 수많은 개념을 고안했거나 정립하는 데 기여했습니다.
그 외에도 그녀가 남긴 업적은 수없이 많습니다.

우리가 오늘날 주소(address), 이진수(binary), 비트(bit), 어셈블러(assembler), 컴파일러(compiler), 브레이크포인트(breakpoint), 문자(character), 코드(code), 디버그(debug), 편집(edit), 필드(field), 파일(file), 부동소수점(floating-point), 순서도(flowchart), 입력(input), 출력(output), 점프(jump), 키(key), 루프(loop), 정규화(normalize), 피연산자(operand), 오버플로(overflow), 파라미터(parameter), 패치(patch), 프로그램(program), 서브루틴(subroutine) 같은 용어를 사용하는 것은 모두 그녀의 노력 덕분입니다.

전쟁, 그리고 1944년의 여름

해군에 입대한 그레이스는 장교 후보생 학교를 수석으로 졸업하며 소위(lieutenant junior grade) 계급을 받습니다.
그녀는 수학에 대한 깊은 배경지식을 가지고 있었기 때문에 암호를 해독하는 업무를 맡게 되리라고 생각했습니다.
하지만 실제로 주어진 업무는 전혀 예상하지 못한 일이었습니다.
그레이스는 하버드 대학교로 배속되어 미국 최초의 컴퓨터이자, 세계에서 두 번째 컴퓨터였던 자동 순차 제어 계산기(ASCC)의 부 책임자이자 세 번째 프로그래머로 일하게 된 것입니다.

ASCC는 하버드 마크 I의 또 다른 이름입니다.
이 컴퓨터는 하워드 에이컨이 구상했으며, 그는 하버드 교수진과 해군을 설득하여 이 거대한 계산 기계를 만들어 냈습니다.
에이컨은 마크 I 프로젝트를 IBM에 제안했고, 토머스 J. 왓슨(Thomas J. Watson)이 직접 설계와 제작 비용을 지원했습니다.
그리고 5년 간 개발 끝에 IBM은 무게 9,445파운드, 높이 8피트, 폭 3피트, 길이 51피트에 달하는 장비를 완성했습니다.

마크 I은 분당 200회 회전하는 모터로 구동되어 하나의 레지스터를 다른 레지스터에 더하는 데 약 300밀리초가 걸렸습니다.
또 별도의 산술 연산 장치를 갖추고 있어 곱셈은 10초, 나눗셈은 16초, 로그 계산은 무려 90초가 소요됩니다.
그리고 이 장치는 자카르드 직기(Jacquard’s loom)처럼 너비 3인치에 달하는 긴 종이테이프에 뚫린 구멍으로 된 명령어로 제어됩니다.

마크 I은 종이테이프에 코드를 뚫어 넣는 방식으로 프로그래밍되었습니다.
이 종이테이프는 가로 줄마다 빈칸 24개로 구성되어 있고, 각 빈칸은 구멍을 뚫거나 아니면 그냥 둘 수도 있습니다.
이는 오늘날 관점에서 보면 24비트에 해당하지만 당시에는 없던 개념입니다.

마크 I 종이테이프의 24비트는 8비트씩 세 그룹으로 나뉘어 있습니다.
첫 두 그룹은 각각 입력과 출력 메모리 레지스터의 이진 주소를 나타내며, 세 번째 그룹은 수행할 연산을 지정하는 부분입니다.
예를 들어 연산 코드 0은 ‘덧셈’을 의미하기 때문에 0x131400이라는 명령어는 레지스터 0x13에 있는 숫자를 레지스터 0x14에 더하라는 지시가 됩니다.

군에서는 에이컨 팀에 맡길 일이 아주 많았습니다.
각종 대포와 함포에 대한 사격 표(firing table)를 출력해야 했고, 항법 표(navigation table)나 다양한 강철 합금에 대한 분석 결과도 출력해야 했습니다.
밀려 있는 작업은 산더미였고, 에이컨 사령관은 일이 늦어지는 것을 결코 용납하지 않았습니다.
당시는 전쟁 중이었으며, 모든 일은 반드시 일정 안에 끝나야 했습니다.

그렇게 호퍼는 주어진 단 일주일 동안 다른 프로그래머 두 명의 도움을 받으며 기본적인 사용법을 익혔습니다.
또 다른 중요한 작업 사이에 몰래 자신이 만든 프로그램을 실행해 보기도 했습니다.

규율: 1944~1945년

호퍼와 그녀의 동료들인 리처드 블로흐, 로버트 캠벨은 본격적으로 마크 I의 내부 구조를 파악하는 작업에 몰두합니다.
그러던 중 몇 가지 당황스러운 사실을 알게 됩니다.
예를 들어 에이컨이 공들여 만든 로그 함수와 삼각 함수 계산 모듈은 그 연산을 수행하는 데 기계 동작 사이클이 200번 필요하여 단순히 덧셈과 곱셈을 이용한 보간법 계산보다 오히려 더 느렸습니다.

호퍼 팀은 이런 마크 I만의 특징과 예상치 못한 문제들을 처리하기 위해 각종 최적화 기법과 요령을 정리하여 공유했습니다.
이는 점차 마크 I 프로그래밍 작업을 위한 일종의 규율이 되기 시작했습니다.
이런 규율은 마치 ‘작업장 벽에 붙어 있는 규칙’처럼 모두가 따르는 암묵적인 룰이 되었습니다.

하버드 마크 I을 프로그래밍하고 운용하는 일이 매우 힘들어서 호퍼 팀은 분업 체계를 도입합니다.
일상적인 기계 운용은 해군 병사들이 맡고, 프로그래머 세 명은 주어진 문제에 대한 코드 작성과 운용 지침을 만드는 역할을 담당했습니다.

이런 마크 I의 운영 방식은 마치 프로그램처럼 실행되었으며 그 내용도 매우 복잡했습니다.
마치 인간과 기계가 협력하여 알고리즘을 수행하는 일종의 공생 관계를 보여 주는 것 같았습니다.

마크 I은 95%에 달하는 가동률로 꾸준히 유의미한 작업을 수행할 수 있었습니다.

호퍼가 그렇게 팀을 체계적으로 조직하고 적절하게 작업 규율을 유지했기에 그 공로로 결국 에이컨 사령관은 마크 I에 대한 전체적인 운영을 호퍼에게 맡깁니다.

서브루틴: 1944~1946년

호퍼 팀은 추후 문제 해결에 참고하기 위한 코드 조각들을 따로 보관해 두기 시작합니다.
이 코드 조각들은 루틴(routine)이라고도 불렀으며, 각자의 엔지니어링 노트에 정리되어 있었습니다.

1946년 여름, 호퍼의 부관이었던 리처드 블로흐는 마크 I이 종이테이프 리더기 최대 열 개로부터 명령어를 읽을 수 있게 하는 하드웨어 개발에 착수합니다.
아울러 리더기 간 전환과 리더기에 저장된 루틴을 실행하는 명령어도 따로 만듭니다.
보조 리더기에 삽입된 테이프들은 모두 ‘상대적인(relative)’ 주소 체계를 따르도록 구성되었으며, 이에 따라 마크 I은 레지스터 주소를 자동으로 재배치(relocate)하여 처리할 수 있게 되었습니다.
그렇게 호퍼의 팀은 필요하면 재배치 가능한 서브루틴 라이브러리를 구현하게 됩니다.

하지만 호퍼는 앞선 작업에서 또 다른 가능성을 보았습니다.
그녀는 각각의 루틴을 프로그래머가 그 내부 코드에 대해 걱정하지 않고도 사용할 수 있는 새로운 ‘명령어’로 여겼습니다.
이때부터 그녀 마음속에는 ‘컴파일러’라는 새로운 개념이 움트기 시작합니다.

심포지엄: 1947년

전쟁이 끝난 후 비밀 장막이 걷히면서 컴퓨터에 관여했던 몇몇 사람 사이에 대화가 오가기 시작합니다.

에이컨은 하버드 마크 I 팀이 컴퓨팅 분야를 선도할 수 있을 것이라고 생각했습니다.
그래서 그는 학계, 산업계, 군 관계자들을 초청하여 ‘대형 디지털 계산 기계(Large Scale Digital Calculating Machinery)’라는 심포지엄을 개최합니다.
여기에는 MIT, 프린스턴, GE, NCR, IBM, 해군 등의 인사들이 참석했습니다.
에이컨은 찰스 배비지의 손자까지 초청해서 강연을 맡겼고, 이를 통해 자신과 배비지를 연관 짓는 상징적 의미를 더욱 강화했습니다.

에이컨은 자신이 배비지의 ‘지적 후계자’로 여겨지는 것을 좋아했습니다.
배비지는 케임브리지 대학교에서 아이작 뉴턴도 맡았던 루커스 수학 석좌 교수직을 지낸 인물이니까요.
그러나 훗날 호퍼는 에이컨이 배비지에 대해 알게 된 것은 마크 I이 운영된 이후였으며, 그의 발명이 배비지로부터 영감을 받은 것은 아니었다고 말했습니다.

에이컨은 참석자들에게 마크 I을 소개하면서 그 설계와 구현에 대한 공로가 모두 자신에게 있다고 말했습니다.
반면에 IBM에 대해서는 아무런 언급도 하지 않았습니다.
결국 현장에서 강연을 듣고 있던 토머스 J. 왓슨은 분노합니다.
원래 이 프로젝트를 설계하고 제작하고 자금을 댄 것은 다름 아닌 IBM이기 때문입니다.
그래서 왓슨은 이때부터 복수를 계획합니다.

이런 에이컨의 무례에도 심포지엄은 대성공을 거두었습니다.
마크 I의 시연이 이루어지고, 블로흐는 다중 서브루틴과 분기를 가능하게 한 하드웨어를 발표합니다.
그러나 심포지엄의 진짜 주제는 메모리(memory)였습니다.

폰 노이만은 1945년 6월 ‘EDVAC에 관한 초안 보고서(First Draft of a Report on EDVAC)’에 그 해결책을 제시합니다.
그 내용은 프로그램을 컴퓨터의 계산 속도만큼 빠른 속도를 가진 메모리에 저장해야 한다는 것입니다.
어차피 컴퓨터는 데이터를 저장하기 위한 메모리가 필요하므로 그 메모리에 프로그램까지 함께 저장하면 된다는 것이죠.

1949년 여름, 호퍼는 ‘에커트-모클리 컴퓨터 회사(The Eckert and Mauchly Computer Corporation, EMCC)’라는 신생 기업에 합류합니다.
이 회사는 ENIAC을 만든 두 발명가가 설립한 회사로 이들의 목표는 범용 자동 컴퓨터, 즉 UNIVAC(유니박, UNIVersal Automatic Computer) 개발이었습니다.

UNIVAC: 1949~1951년

UNIVAC I은 6,000개가 넘는 진공관으로 구성되었고, 무게는 7톤이 넘었으며, 전력 소비량은 125킬로와트에 달했습니다.

UNIVAC I은 72비트 워드24 1,000개를 저장할 수 있었고, 이는 섭씨 40도(화씨 104도)의 일정한 온도를 유지해야 하는 수은 지연선에 저장되었습니다.
각 워드는 명령어 두 개나 12자 길이의 문자 값을 저장할 수 있었으며, 각 문자는 6비트로 구성된 영숫자(alphanumeric)로 되어 있었습니다.
워드에 저장된 12자 문자 값이 모두 숫자일 경우에는 이를 숫자 값으로 간주했습니다.

산술 연산 장치는 rA, rX, rL, rF 레지스터를 네 개 가지고 있었으며, 각 레지스터는 하나의 워드를 저장할 수 있었습니다.
이들은 산술 연산의 피연산자와 결과 값을 저장하는 데 사용되었습니다.
이 기계는 12자리 숫자 두 개를 더하는 데 525마이크로초25가 걸렸고, 곱셈은 2,150마이크로초에 수행할 수 있었습니다.

호퍼는 여전히 많은 작업을 해야 했고, 그 과정에서 프로그래머가 부족하다는 것도 절감하게 되었습니다.
즉, 유능한 프로그래머37가 턱없이 부족했습니다. 그래서 그녀는 스스로 그들을 길러 내기로 결심합니다.

이를 위해 호퍼는 모클리와 협력하여 프로그래머 적성 검사를 만들었습니다.
그들은 훌륭한 프로그래머가 갖추어야 할 바람직한 특성 12가지와 필수 특성 세 가지에 합의합니다.
여기에는 창의력이나 추론 능력 같은 비교적 자명한 자질들도 포함되어 있습니다.
그렇게 그들은 프로그래머를 교육하고 더 많은 인력을 팀에 합류시키기 시작합니다.

정렬, 그리고 컴파일러의 태동

스나이더는 매우 중요한 전환점이 되는 아이디어를 떠올렸습니다.
그것은 바로 정렬은 매개변수에 따라 작동한다는 점입니다.
즉, 여러 레코드를 정렬하려면 정렬 기준이 되는 필드의 위치와 크기, 정렬 방향 등의 정보가 필요하다는 것입니다.
그래서 스나이더는 이 매개변수들을 입력받아 해당 레코드를 정렬하는 프로그램을 생성할 수 있는 프로그램을 작성합니다.

스나이더는 매개변수를 바탕으로 또 다른 프로그램을 생성하는 최초의 프로그램을 만들었습니다.
어떤 의미에서 보면 이것이 사상 최초의 컴파일러였던 셈입니다.
정렬에 필요한 매개변수를 받아 레코드를 정렬하는 프로그램을 컴파일(compile)해 주는 프로그램이었기 때문입니다.

알코올: 1949년경

EMCC의 상황은 좋지 않았습니다.
재정 상태는 늘 불안정했고 파산할 가능성도 있었습니다.
계약은 지연되기 일쑤였고, 지원금도 터무니없이 부족했습니다.
EMCC는 UNIVAC을 제작하는 데 드는 비용을 실제보다 세 배 이상 낮게 예산을 잡는 바람에 큰 어려움을 겪습니다.

결국 이 회사는 굉장히 낮은 가격에 레밍턴 랜드(Remington Rand)에 인수되었습니다.
하지만 레밍턴 랜드의 고등 연구 책임자였던 레슬리 그로브스(Leslie Groves)는 컴퓨터라는 개념 자체가 입증되지도 않았고 신뢰할 수도 없는 개념이라고 생각했습니다.

이런 상황과 스트레스로 인해 호퍼는 심각한 알코올 중독에 빠져들게 됩니다.

1949년 겨울이 다가오던 무렵, 그녀는 공공장소에서 만취 상태로 소란을 피운 혐의로 체포됩니다.
그녀는 자살까지 고민할 정도로 심각한 상태였습니다.

컴파일러: 1951~1952년

호퍼는 잠깐 짬이 날 때마다 베티 스나이더의 정렬 프로그램 생성기(sort generator)를 계속 떠올렸습니다.
컴퓨터가 스스로 프로그램을 생성하도록 가르칠 수는 없을까?
이런 생각이 그녀를 계속 사로잡았던 것입니다.

1952년 5월 호퍼는 ACM에 논문을 발표합니다.
논문 제목은 “The Education of a Computer(컴퓨터 교육)”로, 이 논문에서 그녀는 자동 프로그래밍(automatic programming)이라는 용어를 처음으로 제안합니다.
자동 프로그래밍이란 고급 언어(high-level language)를 자동으로 컴퓨터가 실행 가능한 코드로 변환하는 것을 의미합니다.

이 논문에서 호퍼는 다음 아이디어도 제시합니다.
“현재의 목표는 가능한 한 인간의 두뇌를 전자 디지털 컴퓨터로 대체하는 것이다.”

호퍼는 자신의 생각을 한층 더 자세히 표현했습니다.
그녀는 컴퓨터가 수학자에게서 계산이라는 고된 작업을 덜어 주는 대신 이제는 프로그래밍이라는 고된 작업이 그 자리를 차지하게 되었다고 말했습니다.
처음에는 프로그래밍이 흥미로울 수 있지만, “그 새로움은 금세 사라지고 프로그램을 작성하고 검토하는 일은 지루한 노동으로 전락하게 된다.”라고 지적합니다.

이어 호퍼는 “상식적으로 생각한다면 프로그래머는 다시 수학자로 돌아가야 한다.”라고 말했습니다.
그리고 이는 문제 해결에 사용할 수 있는 ‘서브루틴 목록(catalogue of subroutines)’만 있으면 가능하리라 생각했습니다(몇 달 후 그녀는 이것을 의사코드(pseudocode)라고 부릅니다).
또 그녀는 수학자가 선택한 서브루틴을 참고하여 컴퓨터가 ‘컴파일 루틴(compiling routine)’으로 특정 문제를 해결할 수 있는 프로그램을 자동으로 생성할 수 있을 것이라고 했습니다.
그리고 호퍼는 이를 ‘A형 컴파일 루틴(compiling routine of type A)’이라고 불렀습니다.

1952년에 발표한 단 한 편의 논문에서 그녀는 컴퓨터 언어에 대한 전반적인 미래를 예견합니다.

A형 컴파일러

호퍼와 그녀의 팀은 A형 컴파일러의 버전 0, 즉 A-0 개발에 착수했습니다.

A-0가 생성한 프로그램은 순수 C-10 코드로 작성한 프로그램보다 약 30% 정도 느리다는 점입니다.
이 수치는 지금 보면 그리 큰 차이가 아닐 수도 있지만 당시에는 컴퓨터 사용 비용이 시간당 수백 달러에 달했기 때문에 실행 속도는 매우 중요한 문제였습니다.
당시 기준으로는 컴퓨터 사용 비용이 프로그래머 인건비의 최소 열 배 이상이기도 했습니다.

A-0 같은 컴파일러가 자신들의 일자리를 빼앗을지도 모른다는 프로그래머들의 두려움 때문입니다.

몇 달 동안 그녀의 팀은 A-1과 A-2를 개발합니다.
이들은 기존 시스템을 다듬은 버전으로 의사코드(소스 코드)를 좀 더 쉽게 작성할 수 있도록 개선합니다.

여전히 12자 길이의 C-10 형식을 따랐지만 A형 컴파일러를 하나의 새로운 언어라기보다는 명령어를 실행하는 기계, 즉 더 나은 UNIVAC I쯤으로 생각한 듯합니다.

언어: 1953~1956년

그녀는 의사코드가 반드시 컴퓨터 하드웨어에 종속될 필요는 없다는 사실을 인식한 것입니다.

호퍼는 이런 아이디어를 혼자서 만들어 낸 것이 아니었습니다.
그녀는 여러 회사와 다양한 분야의 전문가들로 이루어진 네트워크를 구축했고, 그들과 활발한 토론과 대화를 나누었습니다.
그런 환경 속에서 혁신이 자연스럽게 꽃피었습니다.

1954년 5월, 호퍼는 자동 프로그래밍 심포지엄을 조직합니다.
그 자리에서 그녀는 MIT 출신의 젊은 연구자 닐 지얼러(Neil Zierler)와 J. 할콤 레이닝 주니어(J. Halcombe Laning Jr.)가 자신들의 대수 컴파일러(algebraic compiler)에 대해 발표하는 것을 보았습니다.
이 컴파일러는 수학 공식을 실행 가능한 코드로 변환하는 프로그램이었습니다.

특히 대수식(algebraic formula)을 간단히 코드로 변환하는 시연은 호퍼에게 훨씬 더 많은 가능성이 있음을 확신하게 만들었습니다. 그녀는 적절한 언어만 있다면 훨씬 더 많은 사람이 컴퓨팅을 활용할 수 있으리라 굳게 믿게 되었죠.

호퍼는 팀에 UNIVAC I의 12문자 형식 대신 대수식과 영어 단어를 사용하도록 지시하게 되었습니다.
이렇게 탄생한 새로운 언어가 바로 MATH-MATIC이며, 이는 프로그래머가 입력한 명령어를 A-3로 변환하는 B형 컴파일러입니다.

호퍼 팀은 프로그램의 일부를 자기 테이프에 기록했다가 삭제할 수 있는 오버레이 기법(overlay scheme)49을 고안해 냈습니다.
비록 속도는 느렸지만 이 방법을 통해 메모리 제약을 어느 정도 해소할 수 있었습니다.

MATH-MATIC 같은 컴파일러는 프로그램을 훨씬 쉽게 작성할 수 있게 해 주었지만, 프로그램의 실행 속도를 상당히 느려지게 만들었습니다.
따라서 여전히 순수 기계어(machine language)로 프로그래밍하는 사람들이 프로그램의 실행 속도와 성능적인 측면에서 더 이점이 있었습니다.

존 배커스는 할런 헤릭(Harlan Herrick)과 어빙 질러(Irving Ziller)와 함께 새로운 언어를 만들기 시작합니다.
그들은 MIT의 젊은 듀오인 래닝과 지얼러를 초청하여 그들의 대수식 컴파일러를 시연하게 했습니다.
이 시연은 관계자들에게 큰 충격을 주었는데, 생성된 코드의 실행 속도가 기계어 프로그래머가 작성한 코드보다 열 배나 느렸기 때문입니다.

1954년 11월 그는 IBM 상사에게 포트란(FORTRAN) 개발 제안서를 제출했습니다.

포트란은 IBM의 영향력 덕분에 MATH-MATIC보다 더 큰 인기를 얻게 되었죠.
당시 IBM의 704 컴퓨터는 레밍턴 랜드의 UNIVAC 컴퓨터보다 훨씬 더 많이 팔리고 있었으며, IBM은 강한 상승세를 타고 있었습니다.

코볼: 1955~1960년

1955년 호퍼는 레밍턴 랜드에 제출한 ‘데이터 처리 컴파일러의 예비 정의(The Preliminary Definition of a Data Processing Compiler)’라는 보고서에서 비즈니스 종사자들은 "A x B = C" 대신에 "MULTIPLY BASE-PRICE AND DISCOUNT-PERCENT GIVING DISCOUNT-PRICE" 라는 문장을 더 선호한다고 밝혔습니다.

호퍼는 프로그래머들 간의 원활한 소통을 돕기 위해 새롭게 창립된 ACM(Association for Computing Machinery)과 협력하여 컴퓨터 산업 최초의 용어집(glossary of terms)을 만드는 작업에 착수합니다.
이 용어집에는 오늘날까지도 사용하는 용어가 다수 포함되어 있으며, 심지어 비트(bit)에 대한 정의도 담겨 있습니다.

1959년이 되자 기업들은 프로그래밍 비용이 얼마나 빠르게 증가하고 있는지 실감합니다.
그리고 업계 전반으로 공통 언어(common language)를 사용하면 초기 개발 비용뿐 아니라 빠르게 변화하는 하드웨어에 시스템을 이전하는 데 드는 비용까지 크게 줄일 수 있다는 공통된 인식이 퍼지기 시작합니다.

호퍼는 데이터 시스템 및 언어 회의(Conference On DAta SYstems and Languages, CODASYL)를 조직했고, 1959년 봄에 국방부에서 첫 회의가 열리게 되었습니다.

이 회의에는 정부 기관, 기업, 컴퓨터 제조사에서 모인 대표자 40명이 참석합니다. 참석자 명단에는 스페리 랜드, IBM, RCA, GE, NCR, 허니웰(Honeywell) 등 오늘날에도 익숙한 이름들이 포함되어 있습니다.

그 회의에서 새로운 언어에 대해 다음과 같은 제약 조건들이 결정됩니다.

  • 영어를 최대한 활용할 것
  • 강력한 기능보다는 사용의 용이성을 우선할 것
  • 기계에 대해 독립적이고 이식 가능할 것
  • 신규 프로그래머 교육이 쉬울 것

언어위원회는 마침내 공통 업무 지향 언어인 코볼(COmmon Business Oriented Language, COBOL)을 만들게 되었습니다.

코볼은 여러 언어와 아이디어가 혼합된 하이브리드 언어였습니다.
FLOW-MATIC이 중요한 역할을 했지만, FLOW-MATIC에서 파생된 IBM의 COMTRAN과 공군의 AIMACO에서도 많은 부분을 가져왔습니다.

그리고 마침내 코볼 프로그램의 첫 번째 성공적인 컴파일은 1960년 8월 17일에 이루어지게 되었습니다.

코볼에 대한 개인적인 불만

지나치게 장황해서 읽는 사람의 정신을 마비시킬 정도고, 코딩하는 것도 고역이며 읽는 것은 더더욱 고통스러웠습니다.
프로그래밍이 마치 군대 보고서를 쓰는 것 같았고, 같이 있어야 할 것은 떨어져 있었고 떨어져 있어야 할 것은 억지로 붙여 놓았습니다.
모든 면에서 이 언어는 끔찍한 괴물(abomination) 같은 느낌이 들었습니다.

실제로 호퍼는 프로그래머들이 언어에 큰 영향을 미치지 못하도록 의도적으로 제한하는 대신 사용자와 관리자들 의견을 우선시했습니다.
그리고 그런 노력들이 언어 곳곳에 드러납니다.

제 추측으로는 그녀가 당시 업계에서는 자신 정도의 수준을 갖춘 프로그래머를 충분히 찾거나 양성할 수 없다고 판단했던 것 같습니다.
그래서 그녀는 언어를 거의 멍청할 정도로 단순한 수준, 즉 가장 낮은 공통 분모에 맞추어야 한다고 생각했습니다.

엄청난 성공

코볼은 성공했습니다.
2000년까지 작성된 모든 코드 중 약 80%가 코볼로 작성되었을 것으로 추정될 정도였으니까요.

Metadata

Metadata

Assignees

Labels

2026We Programmers우리, 프로그래머들 - AI 시대에 잊혀 가는 '프로그래머 정신'을 다시 깨우다

Projects

Status

Done

Relationships

None yet

Development

No branches or pull requests

Issue actions