2025년 8월 08일·7분
그레이스 호퍼와 코딩을 바꾼 컴파일러 혁명
그레이스 호퍼가 컴파일러를 어떻게 발명하고, 읽기 쉬운 코드를 주장하며 COBOL 같은 언어에 어떤 영향을 주었는지 알아보세요—소프트웨어 작성과 유지보수 방식을 바꾼 이야기입니다.
그레이스 호퍼가 컴파일러를 어떻게 발명하고, 읽기 쉬운 코드를 주장하며 COBOL 같은 언어에 어떤 영향을 주었는지 알아보세요—소프트웨어 작성과 유지보수 방식을 바꾼 이야기입니다.
우리 대부분은 코드를 읽기 쉽고 재사용 가능하며 비교적 이식성이 있을 것으로 기대합니다. 변수에 이름을 붙이고 라이브러리를 호출하며, 직접 본 적 없는 기계에서도 프로그램이 실행될 거라 가정하죠. 그런 기대는 우연히 생긴 것이 아닙니다. 그것은 인간과 컴퓨터가 일을 나누는 방식에서 일어난 큰 변화의 결과이며, 컴파일러가 그 다리 역할을 했습니다.
초기의 프로그래머들은 지금처럼 ‘코드를 타이핑’하지 않았습니다. 그들은 너무 세밀하고 취약한 수준에서 컴퓨터를 다뤄서 모든 명령이 기계 수작업처럼 느껴지던 시절을 살았습니다. 핵심 질문은 이렇습니다:
프로그래밍은 어떻게 하드웨어 특화된 기술에서 팀이 시간이 지나도 유지할 수 있는 인간 중심의 실천으로 이동했는가?
그레이스 호퍼는 그 시대에 급진적이던 아이디어를 밀어붙인 인물입니다: 컴퓨터가 번역을 더 많이 해야 한다. 사람들에게 한 기계에 맞춘 길고 오류가 많은 명령을 쓰도록 강요하는 대신, 호퍼는 더 인간 친화적인 지시를 실제로 실행되는 낮은 수준의 단계로 바꿀 수 있는 초기 컴파일러류 작업을 선구했습니다.
그녀의 작업은 ‘번역’이 사치가 아니라 생산성 혁신임을 증명했습니다. 의도를 더 명확히 표현할 수 있게 되면:
컴파일러가 등장하기 전의 프로그래밍 모습, 컴파일러가 실제로 무엇을 하는지(전문 용어 없이), 그리고 호퍼의 A-0 작업과 COBOL의 등장이 소프트웨어를 읽기 쉽고 표준화된 언어로 어떻게 밀어갔는지 살펴보겠습니다. 그 과정에서 이식성, 팀워크, 장기 유지보수, 그리고 코드가 단지 기계를 위한 것이 아니라 사람도 이해할 수 있어야 한다는 일상적 가정이 현대 개발에 어떤 영향을 미쳤는지 알게 될 것입니다.
명확한 오류 메시지, 이식 가능한 코드, 또는 지침처럼 읽히도록 설계된 언어의 혜택을 받아본 적이 있다면, 당신은 호퍼가 만든 세계에 살고 있는 것입니다.
그레이스 호퍼는 프로그래밍을 ‘더 쉽게’ 만들려고 시작하지 않았습니다. 그녀는 초기 컴퓨팅이 요구하는 곳에서 시작했습니다: 기계의 한계와 함께. 수학자로 교육받은 그녀는 제2차 세계대전 중 미 해군에 합류해 하버드 마크 I 작업에 배치되었습니다. 이 기계는 대규모 전기기계식 컴퓨터 중 하나였습니다.
마크 I는 실수로 재부팅할 수 있는 노트북이 아니었습니다—실제로는 방 하나를 차지하는 자원으로 팀이 공유하고 엄격히 예약해서 사용하는 값비싼 장비였죠.
컴파일러가 등장하기 전의 프로그래밍은 우리가 인식하는 코드 쓰기와는 달리 제어판의 배선을 다루는 일에 더 가까웠습니다. 명령은 하드웨어 요구에 정확히 맞아야 했고, 종종 숫자 코드나 매우 낮은 수준의 연산으로 표현되었습니다. 기계에 더하기를 시키거나 값을 이동시키려면 기계 자체의 어휘로 한 단계씩 표현해야 했습니다.
그 일은:
초기 컴퓨터는 희귀했고 ‘컴퓨터 시간’은 예산 항목이었습니다. 프로그램을 여러 번 돌려보며 실험할 수 없었습니다. 팀은 신중히 준비하고 이중 점검한 뒤 차례를 기다려 작업을 실행해야 했습니다. 낭비된 분은 실제 문제 해결에 쓰이지 못했습니다.
이 압박은 호퍼의 사고에 영향을 주었습니다: 인간이 기계의 언어를 말하는 데 더 많은 노력을 쏟고 있다면, 병목은 하드웨어뿐 아니라 방식 자체에 있다는 점입니다.
컴파일러가 등장하기 전, 프로그래머들은 컴퓨터의 ‘모국어’로 말했습니다.
기계어는 프로세서가 직접 실행할 수 있는 0과 1의 연속입니다. 각 패턴은 ‘이 두 수를 더하라’, ‘이 값을 이동하라’, ‘다음 단계로 점프하라’ 같은 의미를 가집니다. 정확하지만 인간이 읽고 쓰고 디버깅하기에는 잔혹할 정도로 어렵습니다.
어셈블리 언어는 기계어에 별명을 붙인 것입니다. 원시 비트를 쓰는 대신 LOAD, ADD, JUMP 같은 짧은 단어와 메모리 주소를 씁니다. 어셈블러가 그 단어들을 특정 기계가 이해하는 0과 1로 번역합니다.
어셈블리는 순수 기계어보다 쉬웠지만, 여전히 사람들에게 레지스터, 메모리 위치, 정확한 연산 순서처럼 하드웨어식으로 생각하게 강요했습니다.
초기 컴퓨터들은 교환 가능하지 않았습니다. 서로 다른 기계는 다른 명령어 집합, 메모리 배치, 숫자 표현 방식을 가졌습니다. 한 프로세서용으로 작성된 프로그램은 종종 다른 기계에서 실행되지 못했습니다.
소프트웨어는 ‘레시피’라기보다 특정 자물쇠를 위한 맞춤형 열쇠에 가까웠습니다.
프로그램이 낮은 수준의 단계로 구성되어 있었기 때문에, ‘간단한’ 요청—새 보고서 열 추가, 파일 형식 변경, 반올림 방식 조정—이 프로그램 전체에 파급 효과를 낼 수 있었습니다.
새 기능이 추가로 명령을 필요로 하면 메모리 주소를 재배치하고 점프 대상을 업데이트하며 오래된 배치를 가정한 모든 곳을 다시 확인해야 했습니다. 컴퓨터 시간은 귀했지만, 인간의 시간이 진짜 병목이었고 비즈니스 문제와 거의 관련이 없는 세부 사항에 태워지고 있었습니다.
초기 컴퓨터는 강력했지만 문자 그대로였습니다. 하드웨어가 이해하는 좁은 연산 집합으로만 지시를 따랐습니다. 그래서 프로그래밍은 종종 한 단계씩 기계에 직접 말하는 것처럼 보였습니다.
컴파일러는 작업 패턴을 뒤집었습니다: 사람들이 ‘기계어를 말하는’ 대신 더 인간 친화적인 형태로 지시를 쓸 수 있게 하고, 소프트웨어가 번역을 맡도록 한 것입니다. 실용적으로 말하면, 컴파일러는 프로그램을 만들어내는 프로그램입니다.
컴파일링은 사람이 읽고 쓸 수 있는 코드를 컴퓨터가 실행할 수 있는 명령으로 바꾸는 과정입니다. 이를 주방 로봇이 필요로 하는 정확한 버튼 조작으로 레시피를 번역하는 것에 비유할 수 있습니다.
높은 수준에서 컴파일러는 보통:
마법은 컴퓨터가 갑자기 ‘영어를 이해’하게 되는 것이 아니라, 컴파일러가 지루하고 오류가 쉬운 변환 작업을 속도와 일관성으로 처리한다는 점입니다.
사람들은 둘 다 인간 친화적 코드를 실행하는 데 도움이 되므로 컴파일러와 인터프리터를 혼동하곤 합니다.
간단한 구분 방법은:
외형상 둘 다 “코드를 쓰면 실행된다”로 비슷하지만, 작업 흐름과 성능의 트레이드오프가 다릅니다. 호퍼 이야기에서 중요한 점은, 컴파일이 '코드 쓰기'를 하드웨어 세부사항보다 의도를 표현하는 일로 바꾸었다는 점입니다.
그레이스 호퍼의 A-0 시스템(대체로 1952년경)은 초기의 ‘컴파일러류’ 도구 중 하나로 꼽힙니다—오늘날의 전체 자연어에 가까운 고급 언어를 기계어로 번역하는 현대 컴파일러와 같지는 않았습니다.
프로그래머는 모든 명령을 손으로 쓰는 대신 미리 만들어둔 루틴을 식별자로 참조하는 프로그램을 작성할 수 있었습니다. A-0은:
프로그래머가 아직 영어 같은 코드를 컴퓨터가 ‘이해’하게 만든 것은 아니었습니다. 대신 반복적이고 오류가 쉬운 어셈블리 작업—알려진 빌딩 블록을 선택하고 조합하는 작업—을 자동화하도록 컴퓨터에 요청했던 것입니다.
A-0은 서브루틴에 대한 강력한 아이디어에 기대었습니다. 입력/출력, 수학 연산, 데이터 이동 같은 기능에 이미 테스트된 루틴이 있다면, 매번 그것을 다시 쓰지 않아도 됩니다.
이것은 일상 작업을 두 가지 큰 방식으로 바꿨습니다:
A-0의 깊은 영향은 기술적 측면뿐 아니라 문화적 측면에도 있었습니다. 그것은 프로그래밍이 신뢰할 수 있는 구성요소로 설명(describe)하고 도구가 기계적 작업을 처리하도록 하는 것일 수 있다는 관점을 제시했습니다.
그 재사용, 표준화된 루틴, 번역 자동화라는 태도는 컴파일러, 표준 언어, 현대 소프트웨어 개발 관행의 기초가 되었습니다.
초기의 프로그래머들은 기계와 싸웠을 뿐 아니라 서로가 생각하는 ‘진짜’ 프로그래밍이 무엇인지에 대해서도 충돌했습니다. 많은 엔지니어에게 진지한 작업이란 하드웨어에 닮은, 촘촘하고 숫자 중심이며 명시적인 명령을 의미했습니다. 평범한 언어처럼 보이는 것은 부정확하고 느슨하다는 의심을 샀습니다.
호퍼는 컴퓨터가 사람을 섬겨야 한다고 주장했습니다. 그녀는 비즈니스 용어에 가까운 더 읽기 쉬운 표기법을 밀어붙였고, 이는 인간이 기계형 단계로 생각해야 효율적이라는 핵심 신념에 도전했습니다.
회의론자들은 영어 같은 명령이 모호하고 중요한 세부를 숨기며 게으른 사고를 조장할 것이라고 걱정했습니다. 호퍼의 반론은 실용적이었습니다: 대부분의 프로그래밍 시간은 명령을 입력하는 데 쓰이지 않고, 나중에 그것을 이해하는 데 쓰입니다.
읽기 쉬운 코드는 프로그램을 ‘쉽게’ 만드는 것이 아니라 ‘살아남게’ 만드는 것입니다. 코드가 의도를 전달할 때, 팀은 변경을 더 빨리 검토할 수 있고, 새 인력을 온보딩할 때 실수를 줄일 수 있으며, 모든 결정을 역공학하지 않고도 문제를 진단할 수 있습니다.
이것은 수년이 지나도 더 중요해집니다. 소프트웨어는 직무, 부서, 때로는 원래 목적보다 오래 살아남습니다. 인간 친화적 구조와 명명은 변경 비용을 줄이며, 변경 비용은 종종 소프트웨어에서 가장 큰 비용입니다.
호퍼의 접근에는 한계도 있었습니다. 초기 컴파일러와 도구는 미성숙했고, 고급 코드는 수작업으로 튜닝한 어셈블리보다 느리거나 크기가 더 커질 수 있었습니다. 디버깅은 간접적으로 느껴질 수 있었습니다: 오류가 소스 텍스트가 아닌 컴파일된 출력에서 나타날 수 있었습니다.
그럼에도 장기적 이득은 분명했습니다: 읽기 쉬운 소스 코드는 더 많은 사람으로 더 큰 시스템을 구축하고, 첫 버전이 배포된 후에도 시스템을 유지할 수 있게 해주었습니다.
COBOL(Common Business-Oriented Language)은 프로그램이 기계를 배선하는 사람들뿐 아니라 비즈니스를 운영하는 사람들이 읽을 수 있게 만드는 단순한 목표를 중심에 두고 만들어졌습니다. 그레이스 호퍼는 이 아이디어를 강하게 밀었습니다—코드가 수년간 살아남고 팀 간 이동하며 인력 교체를 견디려면 이해 가능해야 했습니다.
COBOL은 급여, 재고, 청구 등 비즈니스 데이터 처리용으로 설계되었습니다. 데이터의 ‘모양(shape)’이 수학만큼 중요하기 때문에 COBOL은 레코드, 필드, 그리고 프로그램이 무엇을 하는지에 대한 명확한 설명을 강조했습니다.
야망의 큰 부분은 명료성에 있었습니다. COBOL은 누군가가 프로그램을 훑어보면 의도를 따라갈 수 있도록 영어 같은 구조를 활용했습니다. 이것은 프로그래밍을 ‘쉽게’ 만드는 것이 아니라, 비즈니스 시스템에서 실수의 비용이 클 때 감 audit와 유지보수에 도움이 되도록 가독성을 높이는 것이 목적이었습니다.
COBOL의 진짜 혁신은 문법만이 아니었습니다. 여러 벤더가 구현할 수 있는 공통 규격으로서의 표준화였습니다.
하나의 제조업체나 회사 전용 언어에 묶이는 대신 COBOL은 위원회와 공식 명세에 의해 형성되었습니다. 그 과정은 느리고 정치적일 수 있었지만, 여러 벤더가 구현할 수 있는 공유 목표를 만들었습니다.
실제로 이는 조직이 COBOL에 투자할 때 더 큰 확신을 주었습니다: 교육 자료가 오래가고, 채용이 쉬워지며, 하드웨어가 바뀌더라도 코드가 살아남을 가능성이 커졌습니다.
표준화는 기대도 바꿨습니다. 언어는 더 이상 단지 기계와 함께 ‘따라오는’ 도구가 아니었습니다. 그것은 인간이 지침을 쓰는 방식과 컴파일러가 번역하는 방식에 대한 공개 합의—규칙—이 되었습니다.
COBOL의 장점은 설명하기 쉽습니다: 명시적이고 데이터 구조가 중심이며 장기적인 비즈니스 시스템을 지원합니다. 그 장수성은 우연이 아니며, 명료성과 안정성을 우선한 설계 선택의 결과입니다.
비판도 분명합니다. COBOL은 장황할 수 있고, 가독성이 현대 언어에 비해 경직되게 느껴질 수 있습니다. 그러나 장황함은 종종 의도된 것이었습니다: 코드가 그 작업 과정을 보여주므로 감사, 유지보수, 인수인계에 도움이 됩니다.
COBOL은 언어들이 개인적 지름길이 아니라 표준 중심의 인프라—공유되고 가르칠 수 있으며 오래가도록 설계된 것—로서 행동하기 시작한 전환점을 표시합니다.
초기 프로그램들은 종종 특정 기계에 ‘결혼’되어 있었습니다. 컴퓨터를 바꾸면 파일을 옮기는 것뿐 아니라 프로그램을 다시 써야 하는 경우가 많았습니다. 명령어와 관습이 달랐기 때문입니다. 이는 소프트웨어를 취약하고 비싸게 만들었고, 새 하드웨어 채택을 늦췄습니다.
컴파일러는 강력한 분리를 도입했습니다: 더 높은 수준의 언어로 프로그램을 쓰면 컴파일러가 특정 컴퓨터의 네이티브 명령으로 번역합니다.
사람들이 말하는 이식성은 같은 소스 코드가 다양한 기계에서 빌드될 수 있다는 뜻입니다—각 대상에 맞는 적절한 컴파일러가 있고 기계 특정 가정을 피하면 말이죠. 급여 시스템을 새 컴퓨터마다 처음부터 다시 작성하는 대신, 조직은 논리를 유지하고 단지 재컴파일하면 되었습니다.
이 변화는 하드웨어 개선의 경제성을 바꿨습니다. 제조업체는 더 빠르거나 더 성능 좋은 기계를 출시할 수 있었고, 고객은 수년간의 소프트웨어 투자를 버릴 필요가 없었습니다.
컴파일러는 안정적인 비즈니스 요구와 빠르게 변하는 기술 사이의 ‘어댑터 레이어’가 되었습니다. 프로세서, 메모리 모델, 주변기기가 바뀌더라도 애플리케이션의 의도는 온전히 유지될 수 있었습니다. 일부 변경은 여전히 입/출력 등에서 업데이트를 필요로 했지만, 핵심 아이디어는 더 이상 특정 연산 코드(opcode)에 묶이지 않았습니다.
언어가 표준화되면 이식성은 크게 향상됩니다. 표준 규칙은 한 컴파일러용으로 작성된 코드가 다른 컴파일러에서도 컴파일될 가능성을 높여 벤더 종속을 줄이고 소프트웨어 공유를 쉽게 만듭니다.
그 유산은 오늘날 곳곳에 있습니다:
그레이스 호퍼가 인간 친화적이고 널리 사용 가능한 프로그래밍을 밀어붙인 것은 단순한 편의가 아니었습니다. 그것은 소프트웨어를 기계 특정 명령에서 여러 하드웨어 세대를 견디는 이식 가능한 자산으로 바꾸는 데 기여했습니다.
컴파일러는 단지 프로그래밍 속도를 높인 것이 아니라 소프트웨어 팀의 조직 방식을 재구성했습니다. 코드가 비즈니스 규칙에 더 가까운 고급 용어로 작성될 수 있게 되자 다양한 사람들이 더 효과적으로 기여할 수 있었습니다.
초기 프로젝트는 종종 분석가(시스템이 무엇을 해야 하는지 정의), 프로그래머(그걸 코드로 번역), 운영자(작업을 실행하고 기계 시간을 관리) 같은 역할로 분리되었습니다. 컴파일러가 도입되면서 분석가는 워크플로를 보다 구조화되고 일관된 방식으로 설명할 수 있었고, 프로그래머는 하드조립에 덜 시간을 쓰고 그 워크플로와 일치하는 논리 설계에 더 많은 시간을 쓸 수 있게 되었습니다.
그 결과는 더 깔끔한 인수인계였습니다: 요구 사항 → 읽기 쉬운 소스 코드 → 컴파일된 프로그램. 이는 특정 기계의 요령을 아는 소수 전문가에게 프로젝트가 의존하는 정도를 줄였습니다.
소프트웨어가 몇 주가 아니라 몇 년 동안 살아남게 되자 유지보수가 주요 비용이 되었습니다. 수정, 업데이트, 작은 정책 변화가 쌓이면 비용이 커졌습니다. 읽기 쉬운 소스 코드는 그것을 견딜 수 있게 했습니다: 새로운 사람이 수천 개의 저수준 명령을 해독하지 않고도 의도를 이해할 수 있었습니다.
컴파일러는 이름 붙인 변수, 재사용 가능한 루틴, 더 명확한 제어 흐름 같은 구조를 장려함으로써 이를 지원했습니다. 코드가 스스로 설명할 때, 유지보수는 고고학이 되지 않습니다.
명확한 추상화는 테스트와 디버깅도 개선했습니다. 잘못된 단일 기계 명령을 쫓기보다 팀은 기능 단위로 문제를 추론할 수 있고 모듈이나 함수로 이슈를 격리할 수 있었습니다.
초기에는 컴파일러가 암호 같은 오류를 만들어내기도 했지만, 그럼에도 불구하고 소스 코드를 조직화하고 단계별로 동작을 검증하며 의미가 표현된 곳에서 변경하라는 규율을 촉진했습니다.
컴파일러는 인간 친화적 지시를 기계 친화적 명령으로 번역합니다. 이 변화는 소프트웨어를 더 빠르게 작성하고 공유하기 쉽게 만들었지만, 사람들이 코딩에 대해 말할 때 여전히 등장하는 몇 가지 신화를 낳기도 했습니다.
컴파일러는 주로 코드가 언어 규칙을 따르는지 검사하고 번역 가능한 결과물을 만드는 역할을 합니다. 논리가 잘못되면 컴파일러는 종종 잘못된 동작을 하는 유효한 프로그램을 기쁘게 생산합니다.
예를 들어 급여 계산이 잘못된 수식, 놓친 엣지 케이스, 또는 놓친 시간대 가정 때문에 잘못 지급될 수 있지만 여전히 깨끗하게 컴파일될 수 있습니다.
고급 언어는 특정 종류의 오류—CPU 명령을 섞거나 메모리를 수동으로 관리하는 실수 등—를 줄여주지만 버그를 없애지는 않습니다. 여전히:
가독성은 큰 이점이지만 가독성이 곧 정확함은 아닙니다.
코드는 잘 이름 붙여지고 멋지게 포맷되었더라도 여전히 안전하지 않거나(예: 사용자 입력을 무조건 신뢰) 느릴 수 있습니다(예: 루프에서 반복적인 DB 호출).
더 나은 프레이밍은: 읽기 쉬운 코드는 문제를 ‘찾고’ ‘고치기’ 쉽게 만든다입니다. 그것이 보장하는 것은 아닙니다.
컴파일러는 도구이지 베이비시터가 아닙니다. 신뢰성은 사람들의 작업 방식에서 나옵니다:
그레이스 호퍼는 사람이 이해할 수 있는 코드를 주장했습니다. 그 가치를 이어가려면 가독성과 함께 ‘신중함’을 결합해야 합니다.
호퍼의 핵심 베팅은 단순했습니다: 우리가 사람에게 이해되는 방식으로 작업을 묘사할 수 있다면, 컴퓨터가 번역을 담당해야 한다. 이 아이디어는 파이썬이나 자바스크립트를 쓰든 산업용 컴파일러 도구체인을 통해 앱을 배포하든 거의 모든 현대 프로그래밍 경험에 스며들어 있습니다.
오늘날 ‘컴파일러’는 드물게 단일 프로그램입니다. 파싱, 검사, 변환, 최적화, 실행 가능한 결과물(기계어, 바이트코드, 최적화 번들)을 만드는 파이프라인입니다. 고, 러스트, 스위프트, C#을 쓰든 당신은 호퍼가 주장한 동일한 약속의 혜택을 누리고 있습니다: 인간의 단순 반복 노동을 줄이고 의도를 명확히 하며 기계가 반복 변환 작업을 수행하게 하는 것입니다.
이것이 바로 현대 개발이 여전히 더 높은 수준의 인터페이스로 이동하는 이유이기도 합니다. 예를 들어 Koder.ai와 같은 플랫폼에서는 채팅 인터페이스로 원하는 것을 설명하면 에이전트 기반 워크플로가 웹, 백엔드, 모바일용 애플리케이션을 생성하고 다듬는 데 도움을 주면서도 내보낼 수 있는 소스 코드를 생성합니다. 호퍼식으로 말하면 목표는 동일합니다: 지루한 번역 작업을 의도 표현과 검토 가능한 출력, 빠른 반복으로 옮기는 것입니다.
현대 컴파일러는 단순히 번역만 하지 않습니다—가르치고 보호합니다.
정확한 줄과 수정 제안을 가리키는 오류 메시지를 볼 때, 그것은 프로그래밍을 기계 의식의 의식이 아니라 인간 활동으로 다루어온 유산입니다.
최적화도 조용한 승리입니다: 컴파일러는 개발자에게 매번 모든 명령을 손으로 튜닝하도록 강요하지 않고도 코드를 더 빠르거나 작게 만들 수 있습니다.
정적 분석(종종 컴파일러에 통합되거나 보조 도구로 사용됨)은 타입 불일치, 도달 불가능한 코드, 널 가능성 같은 문제를 고객에게 전달되기 전에 조기에 포착합니다.
이 모든 것은 더 빠른 개발 사이클로 이어집니다: 더 명확한 코드를 쓰고, 도구가 문제를 일찍 지적하고, 빌드가 다양한 환경에서 신뢰할 수 있는 출력을 만들게 합니다. ‘컴파일러’라는 단어를 한 번도 안 말해도, IDE가 버그를 밑줄 긋거나 CI 빌드가 정확한 진단으로 실패하거나 툴체인 업데이트 후 릴리스가 빨라질 때마다 그 효과를 느낍니다.
이것이 일상에서 울려 퍼지는 호퍼의 비전입니다.
그레이스 호퍼의 컴파일러 작업은 단지 컴퓨터를 프로그래밍하기 쉽게 만든 것이 아니라 소프트웨어가 무엇이 될 수 있는지를 바꿨습니다. 컴파일러 이전에는 모든 개선이 세밀하고 낮은 수준의 노력에 의존했습니다. 컴파일러 이후에는 인간의 시간이 아이디어, 규칙, 동작에 더 많이 쓰일 수 있게 되었고, 명령 하나하나를 번역하는 데 소모되지 않게 되었습니다.
두 가지 전환이 차이를 만들었습니다:
이득은 서로를 강화했습니다. 코드가 읽기 쉬우면 개선하기 더 쉽습니다. 번역이 자동화되면 팀은 소프트웨어를 리팩터링하고 필요에 맞춰 적응시킬 여유가 생깁니다. 그래서 컴파일러는 일회성 요령이 아니라 현대 언어, 도구, 협업의 기초가 되었습니다.
컴파일러는 ‘프로그래밍을 쉽게 만든다’는 의미보다 프로그래밍을 확장 가능하게 만든다는 데 더 가깝습니다. 한 사람의 의도가 더 큰 프로젝트, 더 큰 팀, 더 긴 시간, 더 많은 기계에 걸쳐 전달되도록 해줍니다.
만약 내일 누군가가 당신 팀에 합류한다면, 그들이 당신의 코드를 더 빨리 이해하도록 하기 위해 지금 당장 할 수 있는 작은 변화는 무엇인가요—더 나은 이름, 더 명확한 구조, 혹은 ‘왜’에 대한 짧은 주석 하나일까요?
그레이스 호퍼는 초기 컴파일러류 도구를 개척해 프로그래밍을 하드웨어 특정 명령에서 사람 중심의 소스 코드로 옮기는 데 기여했습니다. 그녀의 작업은 도구가 인간의 의도를 기계가 실행할 수 있는 단계로 번역할 수 있음을 증명해, 소프트웨어를 더 빠르게 작성하고 더 쉽게 공유하며 더 오래 유지보수할 수 있게 했습니다.
컴파일러가 등장하기 전에는 프로그래밍이 종종 특정 컴퓨터에 맞춘 기계어 또는 매우 낮은 수준의 명령을 작성하는 일이었습니다. 작업은 수동적이고 취약했으며 변경이 느렸습니다. 작은 기능 추가도 주소, 점프, 메모리 배치 등 하드웨어에 깊이 결합된 부분을 대대적으로 고쳐야 할 수 있었습니다.
기계어는 CPU가 직접 실행하는 0과 1의 원시 비트 패턴입니다. 어셈블리는 LOAD, ADD, JUMP 같은 읽기 쉬운 니모닉을 사용하지만 여전히 특정 기계의 명령어 집합에 묶여 있고 레지스터, 주소, 연산 순서를 생각하게 만듭니다.
컴파일러는 사람이 쓴 소스 코드를 컴퓨터가 실행할 수 있는 하위 수준 형태(종종 실행 파일)로 변환합니다. 또한 언어 규칙을 검사하고 출력을 최적화할 수 있어, 사람이 반복적이고 실수하기 쉬운 번역 작업을 수동으로 할 필요를 줄입니다.
컴파일러는 일반적으로 프로그램 전체(또는 큰 단위)를 사전에 번역해 실행 가능한 결과물을 만듭니다. 인터프리터는 실행하면서 한 줄씩 번역하고 바로 실행합니다. 현대 시스템은 두 방식을 혼합하는 경우가 많지만, 성능과 배포 관점에서 작업 흐름 차이가 남아 있습니다.
A-0은 프로그래머가 식별자로 미리 작성된 루틴을 참조하면, 해당 루틴들의 기계어 블록을 찾아 끌어와 합쳐서 실행 가능한 프로그램을 만든 도구였습니다(오늘날의 링킹과 유사). 영어처럼 읽히는 고급 언어를 번역하진 않았지만, 자동화와 재사용이 수작업 조립을 대체할 수 있음을 증명했습니다.
서브루틴을 재사용하면 동일한 로직을 반복해서 다시 쓰지 않아도 됩니다. 그 결과:
COBOL은 비즈니스 프로그램을 읽기 쉽고 오랜 기간 안정적으로 유지되게 만드는 것을 목표로 했습니다. 레코드와 필드, 명확한 구조를 강조했고, 더 중요한 영향은 표준화였습니다. 여러 벤더가 구현할 수 있는 공통 규격을 통해 벤더 락인 위험을 줄이고 코드와 기술이 다른 시스템에서도 통용되게 만들었습니다.
이식성이란 같은 소스 코드를 각 대상 기기에 맞는 컴파일러로 빌드하면 다른 기기에서도 실행할 수 있다는 의미입니다. 컴파일러가 각 목표에 대한 번역을 담당하므로 조직은 하드웨어를 교체할 때도 핵심 비즈니스 로직을 그대로 유지할 수 있었습니다. 단, 기계 특정 가정을 피해야 합니다.
컴파일러는 언어 규칙을 강제하고 코드를 번역하지만, 논리적 결함을 자동으로 고쳐주지는 않습니다. 실제 버그를 줄이려면:
같은 실천이 필요합니다.