엔지니어링 철학: 그레이스 호퍼, 컴퓨터가 인간의 언어를 말하게 하다

핵심 요약

• 호퍼의 철학 전체를 한 문장으로 요약하면 이렇습니다. 컴퓨터가 인간의 언어를 말하게 하라, 인간에게 기계의 언어를 강요하지 말라.
• 최초의 컴파일러 A-0(1952)은 번역의 부담을 기계에 지웠습니다. 모든 프로그래머가 영원히 손으로 치러야 했던 비용을, 소프트웨어 안에서 단 한 번 자동화한 것입니다.
• 1나노초 전선은 지연 시간을 손에 쥘 수 있는 물건으로 바꿔놓았습니다. 11.8인치라는 실물 덕분에, 낭비된 시간의 비용이 더 이상 추상적이지 않게 되었습니다.
• “우리는 늘 이렇게 해왔다”는 그녀에게 이 언어에서 가장 위험한 문장이었습니다. 그리고 그녀의 모든 발명품은 바로 그 문장에 대한 응답이었습니다.

원칙

“인간은 변화에 알레르기가 있습니다. ‘우리는 늘 이렇게 해왔다’고 말하기를 좋아하죠. 저는 그것과 싸우려 합니다. 그래서 제 벽에는 시계 반대 방향으로 도는 시계가 걸려 있습니다.” – 그레이스 호퍼¹

이 기질은 하나의 신념에서 흘러나옵니다. 기계가 인간을 섬기도록 만들어야지, 그 반대가 되어서는 안 된다는 신념입니다. 프로그래밍이란 특정 기계를 위해 숫자로 된 명령어를 손으로 짜 넣는 일을 의미하던 1953년, 호퍼는 데이터 처리 문제를 영어 단어로 기술하고 번역은 컴퓨터에게 맡기자고 제안했습니다. 경영진은 불가능하다고 답했습니다 – 컴퓨터는 영어를 이해하지 못하니까요.² 그녀가 정말로 주장한 것은 컴퓨터가 영어를 이해한다는 게 아니었습니다. 그녀가 주장한 것은, 번역의 부담이 기계에 속한다는 것이었습니다. 기계 안에서라면 단 한 번 자동화할 수 있으니까요. 모든 프로그래머가 영원히 짊어지는 대신에 말입니다. 이것이 철학 전체입니다. 컴퓨터가 인간의 언어를 말하게 하라, 그 반대가 아니라.

70년이 지난 지금, 그것이 얼마나 급진적이었는지 놓치기 쉽습니다. 당시 지배적인 전제는, 프로그래밍이란 기계의 언어로 사고할 수 있는 사람들을 위한 난해한 기술이며, 그것이 그저 이 일의 본질이라는 것이었습니다. 호퍼의 대답은 이랬습니다. 그 일의 본질이란 누군가가 한 번 내린 선택이었고 그 뒤로 아무도 다시 들여다보지 않았을 뿐이라고 – “우리는 늘 이렇게 해왔다”가 물리 법칙처럼 굳어버린 것이라고요. 그녀의 경력 전체는 바로 그 굳어짐에 대한 거부입니다. 최초의 컴파일러, 최초의 영어에 가까운 언어, 그리고 사람들이 받아들이고 있던 한계가 실은 진짜가 아니라고 평생에 걸쳐 가르친 일입니다.

반反교조주의 성향과 접근성이라는 사명은 같은 본능을 양쪽에서 바라본 것입니다. 추상화 – 사람이 자기 언어로 의도를 표현하면, 도구가 그것을 기계 수준으로 번역해 내려주는 것 – 는 프로그래밍 위에 얹은 편의 기능이 아닙니다. 호퍼에게 그것은 바로 프로그래밍의 목적이었습니다. 그러지 않았다면 배제되었을 사람들에게 기계를 열어주는 일 말입니다. 2016년 오바마 대통령이 그녀에게 대통령 자유 훈장을 수여했을 때, 표창문은 그것을 분명하게 적었습니다 – 그녀는 “최초의 컴파일러를 발명했으며, 그 덕분에 프로그램을 일상 언어로 작성한 뒤 컴퓨터가 이해할 수 있도록 번역할 수 있게 되었다”고요.³ 좋은 도구라면 그것을 쓰는 인간을 위해 최적화해야지, 그것을 돌리는 기계를 위해 최적화해서는 안 된다는 주장의 밑바닥에도 똑같은 신념이 자리합니다.

배경

그레이스 브루스터 머리 호퍼는 1906년 12월 9일 뉴욕시에서 태어났습니다.⁴ 1928년 배서 칼리지에서 수학과 물리학 학사 학위를, 이어 1930년에 석사를, 1934년에는 예일에서 수학 박사 학위를 받았습니다 – 그녀 세대의 여성으로는 거의 아무도 갖지 못한 수학 박사 학위였습니다.⁴ 그녀는 1930년대 내내 배서에서 수학을 가르쳤는데, 이 사실이 중요합니다. 프로그래머이기 전에 그녀는 교사였고, 어려운 개념을 손에 잡히게 만들려는 본능은 끝내 그녀를 떠나지 않았습니다.

1943년 12월, 전쟁 한가운데에서 그녀는 미국 해군 예비역에 입대했습니다. 처음에 해군은 망설였습니다 – 그녀는 서른여섯 살이었고 체중 기준에 한참 미달했죠 – 하지만 그녀는 밀어붙였고, 1944년 하버드의 병기 계산 프로젝트(Bureau of Ordnance Computation Project)에 배치되어 하워드 H. 에이킨 밑에서 하버드 마크 I의 최초 프로그래머 중 한 명이 되었습니다.⁴ 마크 I은 방 하나를 가득 채우는 전기기계식 계산기였습니다. 호퍼는 561쪽짜리 매뉴얼 A Manual of Operation for the Automatic Sequence Controlled Calculator를 공동 집필했는데, 이 책은 여러 해 동안 그 기계를 프로그래밍하는 방법에 관한 기초 문헌이 되었습니다.⁴

전쟁이 끝난 뒤 그녀는 현역을 떠났지만 예비역으로 남았고, 1949년에는 에커트-모클리 컴퓨터 사(Eckert-Mauchly Computer Corporation) – 곧 레밍턴 랜드의 일부가 됩니다 – 에 합류해 미국 최초의 상업용 컴퓨터인 UNIVAC I 작업을 맡았습니다.⁴ 일회성 연구용 기계에 코드를 손으로 용접하던 일에서 벗어나, 이제는 평범한 기업도 쓸 수 있는 제품을 만들려고 애쓰던 바로 그곳에서, 그녀 인생의 문제가 또렷해졌습니다. 에이킨이 그녀에게 기계를 주었습니다. UNIVAC은 그녀에게 고객을 주었습니다. 고객은 프로그래밍을 할 줄 몰랐고, 호퍼는 그것을 고객이 아니라 컴퓨터가 풀어야 할 문제라고 판단했습니다.

그 작업

최초의 컴파일러: A-0 (1952)

1952년 무렵 호퍼는 A-0 시스템을 만들었는데, 이것은 널리 최초의 컴파일러로 인정받습니다.⁵ 그 발상은 돌이켜보면 민망할 만큼 단순했지만, 당시에는 이단이었습니다. 프로그래머들은 유용한 서브루틴 라이브러리를 쌓아두긴 했지만, 그중 하나를 재사용하려면 그 명령어들을 손으로 자기 프로그램에 베껴 넣고 모든 메모리 주소를 일일이 고쳐야 했습니다. 호퍼의 A-0은 그 대신 각 서브루틴을 짧은 호출 번호로 가리키고 인자만 넘겨주면 되도록 했습니다. 그러면 시스템이 테이프에서 루틴을 끌어와 주소를 해결하고 실행 가능한 프로그램으로 조립했습니다.⁵

순수주의자들은 A-0이 현대의 최적화 컴파일러라기보다 오늘날 우리가 로더나 링커라 부를 만한 것에 더 가깝게 작동했다고 – 옳게도 – 지적합니다.⁵ 그 말은 사실이고 짚어둘 가치가 있습니다. 하지만 오래 살아남는 것은 그 개념적 도약입니다. 프로그램이 편리한 기호로 작성된 명세가 될 수 있고, 한 조각의 소프트웨어가 그 명세를 기계어로 자동 번역할 수 있다는 것 말입니다. 이제 번역은 기계의 일이었습니다. 그녀가 왜 그 일을 했는지에 대한 호퍼 자신의 표현은 UNIVAC 시절에 관한 그녀의 말 속에 남아 있습니다. “저는 한때 수학 교수였습니다. 그 시절 수학을 배우지 못하는 학생이 일정 수 있다는 걸 알게 되었죠. 그러고 나서 저는 사업가들이 우리 컴퓨터를 쉽게 쓸 수 있게 만드는 일을 맡게 되었습니다.”² 그 이후의 모든 컴파일러 – 누군가가 날것의 기계 명령어보다 높은 수준의 언어로 작성한 모든 코드 한 줄 한 줄 – 는 그 결정의 후손입니다.

FLOW-MATIC와 COBOL로 가는 길

A-0은 기호를 번역했습니다. 다음 단계는 그 기호를 영어로 만드는 것이었습니다. 1955년에서 1959년 사이, 호퍼와 레밍턴 랜드의 그녀 팀은 FLOW-MATIC을 만들었습니다. 연산을 수학 표기가 아니라 영어에 가까운 문장으로 표현한 최초의 프로그래밍 언어였습니다.⁶ FLOW-MATIC 프로그램은 INPUT, COMPARE, MOVE 같은 명령으로 읽혔습니다 – 수학자가 아니어도 사업가가 읽고 대략 이해할 수 있는 단어들이었죠. 그것은, 그녀의 표현을 빌리자면, 결코 기계의 언어로 사고하지 않을 사람들도 컴퓨터를 쓸 수 있게 만들려는 의도적인 작업이었습니다.

FLOW-MATIC은 곧장 COBOL로 이어졌습니다. 1959년 CODASYL 위원회가 공통의 비즈니스 지향 언어를 설계하려고 소집되었을 때, FLOW-MATIC은 당시 존재하던 영어에 가장 가까운 데이터 처리 언어 중 가장 성숙한 것이었고, 새 표준의 주된 토대가 되었습니다.⁶ 호퍼는 COBOL의 개념적 할머니라고 불릴 만합니다 – 유일한 저자는 아니지만, 영어에 가깝고 기계에 독립적인 비즈니스 언어를 생각할 수 있게 만든 사람은 바로 그녀의 작업과 옹호였으니까요. 그리고 여기에 함께 묶인 두 번째 급진적 발상이 기계 독립성입니다. 그녀는 프로그램이 하나의 컴퓨터에 손으로 맞춰지는 대신 서로 다른 컴퓨터 사이에서 이식 가능해야 한다는 관념을 옹호했고, 이는 한 번 작성해 이식한다는, Unix와 C가 유명하게 만든 신념의 직계 조상입니다. 같은 코드, 같은 영어가, 결코 그것을 위해 작성되지 않은 기계 위에서 돌아가는 것입니다. COBOL은 주변의 거의 모든 것보다 오래 살아남았습니다. 수십 년이 지난 지금도 세계의 은행과 정부 시스템을 돌리고 있는데, 이것이야말로 인간 독자를 중심에 두고 만든 발상의 내구성을 보여주는 조용한 증명입니다.

나노초: 지연 시간을 물질로 만들다

호퍼의 가장 유명한 교육 도구는 코드가 전혀 아니었습니다. 그것은 한 가닥의 전선이었습니다. 언젠가 위성 통신이 왜 그렇게 오래 걸리느냐는 질문을 받자, 그녀는 시간의 비용을 사람이 손에 쥘 수 있는 것으로 만들기로 했습니다. 그녀는 11.8인치로 자른 전선 토막을 나눠주곤 했는데 – 전기가 1나노초, 즉 10억분의 1초 동안 이동할 수 있는 최대 거리였습니다 – 그렇게 해서 추상적인 지연 단위가 손안의 물건이 되게 했습니다.⁷ 그런 다음 그녀는 984피트 길이의 코일을 꺼내 들었습니다. 저것이 바로, 그녀가 설명하길, 1마이크로초라고요. “가끔 저는 우리가 그것을 모든 프로그래머의 책상 위에 하나씩 걸어두어야 한다고 생각합니다.” 그녀가 말했습니다. “그러면 마이크로초를 내버릴 때 자기가 무엇을 내버리고 있는지 알게 될 테니까요.”⁷

이 전선은 컴파일러를 움직인 것과 똑같은 교사의 본능이, 다른 교훈을 겨냥한 것입니다. 컴파일러는 이렇게 말했습니다. 기계를 쓰기 위해 기계의 언어로 사고할 필요는 없어야 한다. 나노초는 이렇게 말했습니다. 하지만 기계의 물리는 존중해야 한다. 지연 시간은 슬라이드 위의 숫자이기를 멈추고, 빛의 속도에 지배받으며 신호가 물리적으로 가로질러야 하는 길이가 되었습니다. 낭비된 매 마이크로초는 당신이 아무 이유 없이 신호에게 달리게 만든 전선입니다. 이 전선들은 지금 스미스소니언 미국사 국립박물관에 보관되어 있습니다.⁸ 그것은 또한, 거의 정확히, 존 카맥의 “빛의 속도는 형편없다”이기도 합니다 – 40년 앞서, 구리로 만든 것이죠. 둘 다 지연 시간이라는 단단한 물리적 바닥을, 추상화로 치워버리거나 손짓으로 무시할 수 없는 것으로 만들었습니다. 눈으로 볼 수 있거나, 손에 쥘 수 있었으니까요.

버그, 그리고 반反교조의 기질

1947년 9월 9일, 하버드 마크 II – 에이킨의 후속 기계이자 호퍼가 일하던 팀 – 의 운영자들은 70번 릴레이, F 패널에 끼인 나방 한 마리에서 고장의 원인을 찾아냈습니다. 그들은 그 곤충을 떼어내 작업 일지에 테이프로 붙이고 이렇게 적었습니다. “버그가 발견된 실제 첫 사례.”⁹ 나방이 그대로 붙은 그 일지 페이지는 이제 스미스소니언이 소장하고 있습니다.⁸

이 이야기의 정직한 버전이 중요한 이유는, 호퍼가 워낙 잘 풀어놓는 바람에 사실관계가 흐려졌기 때문입니다. 나방은 실제였고 날짜도 기록으로 남아 있습니다. 하지만 공학적 결함을 뜻하는 “버그”라는 단어는 그녀보다 한참 앞서 쓰였습니다 – 멀게는 토머스 에디슨 시대까지 거슬러 올라가죠 – 그리고 운영자들은 거의 틀림없이 말장난을 하고 있었습니다. 이미 알고 있던 공학 용어와 방금 떼어낸 진짜 곤충을 겹쳐 놓은 것이죠.⁹ 대부분의 증언에 따르면 호퍼는 그것을 발견한 사람도 아니었습니다. 그녀가 한 일은, 특유의 능란함으로, 그 일화와 “버그”·”디버깅”이라는 어휘를 대중화해서 그것들이 이 분야의 모국어가 되게 만든 것입니다.⁹ 그러니 정확한 공로는 이렇습니다. 그녀는 “버그”를 만들어낸 사람도 아니고 나방을 잡은 사람도 아마 아니지만, 그 이야기와 단어가 자리 잡게 만든 사람이었습니다. 그것은 그 나름의 기여입니다 – 다시, 교사의 기여입니다.

이 모든 것의 밑바탕에 있는 기질은 물려받은 전제에 대한 상시적인 전쟁이었습니다. 그녀의 벽시계는 일부러 시계 반대 방향으로 돌았습니다. 모두가 고정된 것으로 여기던 관습이, 다른 것을 만들기로 마음먹는 순간 임의적인 것이 됨을 증명하기 위해서였죠.¹ “우리는 늘 이렇게 해왔다”는 호퍼에게 이 언어에서 가장 위험한 문장이었고 – 컴파일러도, 영어에 가까운 언어도, 이식 가능한 프로그램도, 손안의 전선도 모두 그 문장에 대한 응답이었습니다.

방법론

이 방법론은 40년에 걸쳐 일관됩니다 – 병기 계산, 상업용 컴퓨팅, 언어 설계, 그리고 평생에 걸친 가르침을 관통합니다.

번역의 부담을 기계로 옮겨라. 그녀 경력에서 반복되는 동작은, 지금 모든 인간이 손으로 하고 있는 일 – 주소를 해결하고, 숫자 연산 코드로 사고하고, 코드를 특정 컴퓨터 하나에 맞추는 일 – 을 가져와 소프트웨어 안에서 단 한 번 자동화하는 것입니다. 컴파일러가 이 발상이고, FLOW-MATIC이 이 발상이며, 기계 독립성이 이 발상입니다.⁵⁶

사람들이 자기 언어로 말하게 하라. 프로그래밍은 사용자가 있는 자리로 찾아가야 합니다. 사업가라면 명령어 집합을 외우는 대신 MOVE와 COMPARE를 쓸 수 있어야 합니다. 접근성은 도구에 나중에 덧붙인 기능이 결코 아니었습니다. 호퍼에게 그것은 도구가 존재하는 이유 그 자체였습니다.²⁶

추상적인 것을 물질로 만들어라. 어떤 발상이 존중하기에는 너무 추상적일 때 – 1나노초, 낭비된 1마이크로초 – 그 교훈을 강제하는 물리적 물건을 만드세요. 전선은 공학으로서의 교육법입니다. 손에 쥐고 있는 물건과는 논쟁할 수 없으니까요.⁷

“우리는 늘 이렇게 해왔다”를 불신하라. 물려받은 관습을 법이 아니라 가설로 다루세요. 시계 반대 방향으로 도는 시계는 사물의 형태로 구현된 방법론입니다. 그저 다르게 해봄으로써 그 제약이 임의적임을 증명하는 것이죠.¹

허락이 아니라 용서를 구하라. “좋은 아이디어라면, 그냥 밀고 나가세요. 허락을 받는 것보다 사과하는 편이 훨씬 쉽습니다.” 그녀는 이렇게 조언했습니다 – 교조와 싸우는 일의 실천적 따름정리입니다. (이 정서는 그녀보다 앞서며 정확한 표현은 출처마다 다르지만, 해군과 이 분야가 기억하는 형태로는 그 말이 그녀의 것입니다.)¹⁰ 옛 방식에 이해관계를 둔 사람들이 축복해주기를 기다려서는 추상화에 이를 수 없습니다.

영향의 사슬

그녀를 빚은 사람들

하워드 에이킨과 하버드 마크 I. 에이킨은 호퍼에게 그녀의 첫 컴퓨터와 첫 어려운 문제를 건넸고, 그녀가 공동 집필한 마크 I 매뉴얼은 기계가 어떻게 명령받는가에 대해 엄격하게 사고하도록 강요했습니다 – 바로 그녀 일생의 작업이 될 질문이었죠. (직접적 영향)

미국 해군. 해군은 그녀에게 제도, 규율, 그리고 끝내 무대를 주었습니다. 그녀는 40여 년에 걸쳐, 때로는 떠났다 돌아오며 군복을 입었습니다. 신뢰할 수 있고 반복 가능하며 가르칠 수 있는 절차를 향한 군의 요구는, 프로그래밍이 장인의 솜씨가 아니라 체계적이고 전수 가능한 것이어야 한다는 그녀의 신념을 빚었습니다. (형성적 영향)

수학 교수로 보낸 세월. 기계 이전에, 그녀는 가르쳤습니다. 교사의 질문 – 나처럼 사고하지 않는 사람에게 이것을 어떻게 손에 잡히게 만들까? – 은 컴파일러, 영어에 가까운 언어, 그리고 전선의 씨앗입니다. (형성적 영향)

그녀가 빚은 것들

모든 고급 언어. 컴파일러는 날것의 기계어가 아닌 다른 무언가로 프로그래밍하는 것을 가능하게 했습니다. FORTRAN, COBOL, 그리고 그 이후의 모든 것은 A-0이 증명한 전제 위에 서 있습니다. 도구가 인간에게 편리한 기호를 기계 명령어로 번역할 수 있다는 전제 말입니다.⁵

COBOL과 비즈니스 컴퓨팅. COBOL의 개념적 할머니로서, 호퍼는 영어에 가깝고 기계에 독립적인 프로그래밍을 전 세계 기업들의 손에 쥐여주었습니다. 이 언어는 지금도 세계 금융·정부 시스템의 막대한 몫을 돌리고 있습니다.⁶

프로그래밍의 목적으로서의 접근성. 가장 깊은 유산은 언어가 아니라 하나의 입장입니다. 더 많은 사람에게 기계를 열어주는 것이 곧 작업이지, 그 작업의 부산물이 아니라는 입장이죠. 오바마의 표창문 – “수백만 명이 더 프로그래밍에 다가설 수 있게 된 것을 우리는 그레이스 호퍼에게 감사할 수 있습니다” – 이 바로 이것입니다.³

관통하는 줄기

유키히로 마츠모토는 프로그래머의 행복을 위해 최적화하도록 Ruby를 설계했습니다 – 언어가 인간에게 굽혀야지, 인간이 언어에 굽혀서는 안 된다고요. 그것은 호퍼의 “사업가들이 우리 컴퓨터를 쉽게 쓸 수 있게 만들라”를 1995년에 다시 말한 것입니다. 컴퓨터가 인간의 언어를 말하게 하라의 직계 철학적 후계자죠. 존 카맥의 “빛의 속도는 형편없다”는 그녀의 나노초 전선을 한 문장으로 옮긴 것입니다 – 둘 다 지연 시간이 물리적이며, 추상화로 치워버릴 게 아니라 존중해야 할 단단한 바닥이라고 못 박습니다. 그녀가 다만 40년 앞서 그곳에 닿았고, 손에 쥘 수 있는 구리로 만들었을 뿐입니다. 그리고 톰슨과 리치의 Unix와 C는, 운영체제가 하나의 기계에 용접되는 대신 한 번 작성되어 이식될 수 있도록 만들어졌으니, 호퍼가 COBOL을 위해 옹호한 기계 독립성의 실천적 완성입니다. 같은 프로그램이, 결코 그것을 위해 작성되지 않은 하드웨어 위에서 돌아가는 것이죠. (시리즈 연결)

내가 여기서 얻는 것

내가 간직하는 교훈은, 추상화란 시간이 남을 때 더하는 사치가 아니라 – 그것이 작업 전체라는 것입니다. 호퍼는 1952년에 프로그래밍을 들여다보고, 어려운 부분을 기계를 만지는 모든 인간이 짊어지고 있음을 보았으며, 그 부담을 단 한 번만 치르면 되는 소프트웨어 속으로 옮겼습니다. 그것이 내가 지금 만드는 모든 것에서 시도하는 동작입니다. 인간이 손으로, 거듭거듭 하고 있는 번역 작업을 찾아내, 그것을 도구 속으로 자동화해 넣는 것이죠. 기준은 품질이 유일한 변수라는 것과 똑같습니다 – 질문은 결코 “사람이 이 인터페이스를 견디도록 훈련시킬 수 있는가?”가 아니라 “왜 그래야만 하는가?”입니다.

내가 지금 만들며 살아가는 세계 – 에이전트, 도구 루프, AI 시스템 – 에서 호퍼의 두 갈래는 둘 다 하중을 떠받치고 있으며, 정확히 생산적인 방식으로 서로 당깁니다. 접근성 쪽은 이렇게 말합니다. 인간이 자기 언어로 의도를 표현하게 하고, 기계가 필요로 하는 무엇으로든 시스템이 그것을 번역해 내려가게 하라 – 그것은 거의 문자 그대로 LLM 도구 호출 계층이 하는 일, 70년 뒤의 영어 컴파일러입니다. 물리 쪽은 이렇게 말합니다. 하지만 추상화가 비용에 대해 당신에게 거짓말하게 두지 말라. 모든 모델 호출은 1나노초짜리 전선이고, 인터페이스가 친절하다는 이유로 그것들을 쌓아 올리는 것이야말로 눈에 보이지 않는 마이크로초를 내버리는 방식입니다. 그리고 그 기질 – 시계 반대 방향으로 도는 시계, “우리는 늘 이렇게 해왔다”에 대한 거부 – 은, 지금의 관습을 법으로 착각하는 분야 주위에서 내가 가장 절실히 필요로 하는 부분입니다. 그 신념, 즉 안목은 물려받는 전통이 아니라 살펴보고 바꿀 수 있는 기술적 체계라는 신념은, 1952년의 컴파일러에서 2026년의 에이전트 하네스까지 곧장 이어집니다.

FAQ

그레이스 호퍼의 엔지니어링 철학은 무엇인가요?

호퍼의 핵심 신념은, 기계를 인간을 섬기도록 만들어야지 그 반대가 되어서는 안 된다는 것이었습니다. 인간의 의도를 기계 명령어로 번역하는 부담은 소프트웨어 안에 속하며, 모든 프로그래머가 영원히 짊어지는 대신 단 한 번 자동화되어야 한다는 것이죠. 그 하나의 신념이 최초의 컴파일러(A-0, 1952)와 최초의 영어에 가까운 프로그래밍 언어(FLOW-MATIC)를 낳았고, 둘 다 기계의 언어로 사고할 수 없는 – 그리고 그럴 필요도 없어야 할 – 사람들이 컴퓨터를 쓸 수 있게 만드는 것을 겨냥했습니다.²⁵⁶ 이 접근성이라는 사명과 짝을 이룬 것이 집요한 반反교조 성향이었는데, “우리는 늘 이렇게 해왔다”가 이 언어에서 가장 위험한 문장이라는 그녀의 견해에 그것이 응축되어 있습니다.¹

그레이스 호퍼는 무엇을 발명했나요?

그녀는 1952년 A-0 시스템을 만들었는데, 이것은 널리 최초의 컴파일러로 인정받으며 기호로 된 프로그램 명세를 기계어로 자동 번역했습니다.⁵ 이어 그녀는 FLOW-MATIC(1955–1959) 개발을 이끌었습니다. 영어에 가까운 문장을 사용한 최초의 프로그래밍 언어였고, COBOL의 주된 토대가 되었습니다.⁶ 그녀는 COBOL의 개념적 할머니이자 기계 독립적 프로그래밍의 옹호자로 불립니다. 그녀는 미국 해군에서 소장 계급에 올랐고, 1986년에 해군 최고령 현역 장교로 전역했으며, 2016년 사후에 대통령 자유 훈장을 받았습니다. 해군 구축함 USS 호퍼는 그녀의 이름을 딴 것입니다.³⁴

그레이스 호퍼의 “나노초” 전선은 무엇이었나요?

그것은 그녀의 가장 유명한 교육 도구였습니다. 11.8인치로 자른 전선 토막으로, 전기가 1나노초(10억분의 1초) 동안 이동할 수 있는 최대 거리였습니다. 그녀는 그것을 나눠주어 추상적인 지연 단위가 손에 쥘 수 있는 물건이 되게 했습니다.⁷ 그녀는 그것을 1마이크로초를 나타내는 984피트짜리 코일과 대비시키며, 프로그래머들에게 그것이 “마이크로초를 내버릴 때 무엇을 내버리고 있는지”를 보여준다고 말했습니다.⁷ 교훈은 지연 시간이 추상적이지 않다는 것 – 신호가 가로질러야 하는 물리적 길이라는 것이었습니다. 이 전선들은 지금 스미스소니언 미국사 국립박물관에 있습니다.⁸

그레이스 호퍼가 “컴퓨터 버그”라는 용어를 만들었나요?

아닙니다. 그리고 정직한 버전이 더 흥미롭습니다. 1947년 9월 9일, 하버드 마크 II의 운영자들은 릴레이에 끼인 나방을 발견해 작업 일지에 테이프로 붙이고 “버그가 발견된 실제 첫 사례”라고 적었습니다. 그 일지 페이지는 스미스소니언이 소장하고 있습니다.⁸⁹ 하지만 공학적 결함을 뜻하는 “버그”라는 단어는 그 나방보다 수십 년 앞섭니다 – 토머스 에디슨 시대에 이미 쓰였죠 – 그리고 운영자들은 거의 틀림없이 이미 알고 있던 용어로 말장난을 하고 있었습니다. 대부분의 증언에 따르면 호퍼는 그 나방을 직접 발견하지 않았습니다. 그녀가 한 일은, 그 일화와 “버그”·”디버깅”이라는 어휘가 이 분야의 표준 언어가 될 때까지 대중화한 것이었습니다.⁹

출처