존 배커스와 FORTRAN: 소프트웨어를 확장시킨 언어

왜 FORTRAN이 큰 의미였나

1950년대 초반, 컴퓨터는 정부, 대학, 대기업에서만 쓰이는 드물고 비싼 기계였다. 그 시절엔 계산 능력이 뛰어났지만, 그것을 프로그래밍하는 일은 매우 느리고 고통스러웠다. 많은 프로그램이 기계어 또는 어셈블리로 직접 작성되었고, 각 명령은 하드웨어의 작은 연산 집합과 정확히 일치해야 했다. 수식의 작은 변경 하나가 긴 코드 구간을 다시 써야 한다는 의미였고, 한 번의 실수로 몇 시간 기다린 끝에 전체 실행이 실패하기도 했다.

존 배커스와 IBM의 뜻밖의 아이디어

존 배커스는 IBM의 엔지니어로, 저수준 코딩에서 얼마나 많은 시간이 낭비되는지를 목격했다. 그는 작은 팀을 이끌고 급진적인 시도를 했다: 프로그래머가 문제를 생각하는 방식에 더 가까운 형태로 수학 중심의 지시문을 쓰게 하고, 컴파일러가 그것을 빠른 기계어로 번역하게 하자.

이 프로젝트가 바로 FORTRAN(“Formula Translation”의 약자)이었고, 대상은 사무처리보다 수치 연산을 하는 IBM의 과학 고객들이었다. 약속은 간단했다: 더 적은 코드를 쓰고 버그를 줄이며 IBM 704 같은 기계에서 여전히 효율적으로 실행되도록 하자.

큰 질문: 충분히 빠를 수 있을까?

그때 많은 프로그래머는 고급 언어가 사치라고 믿었다. 그들은 “영어 같은” 것이 정교하게 튜닝된 어셈블리보다 훨씬 느리게 실행될 것이라고 가정했다. 컴퓨터가 엄청나게 비쌌고 계산 시간이 엄격히 배분되던 시절에 성능은 단순한 "있으면 좋은 것"이 아니라 핵심이었다.

따라서 FORTRAN은 단순히 새로운 문법이 아니었다. 그것은 자동화가 숙련된 인간의 기술과 맞먹을 수 있다는 내기에 가까웠다: 컴파일러가 과학자와 엔지니어가 신뢰할 만큼 충분히 좋은 코드 생성이 가능하다는 것을 증명해야 했다.

이 글에서 다룰 내용

FORTRAN의 이야기는 기술적 돌파구와 문화적 전환의 혼합이다. 이어서 우리는 고급 언어 이전의 프로그래밍이 어땠는지, 배커스 팀이 어떻게 손으로 쓴 코드와 경쟁할 수 있는 컴파일러를 만들었는지, 그리고 그 성공이 소프트웨어의 경제에 어떤 변화를 가져왔는지—오늘날 팀들이 여전히 따르는 패턴을 포함해 살펴볼 것이다.

고급 언어 이전: 어셈블리만 있던 현실

FORTRAN 이전에 “프로그래밍”은 보통 컴퓨터 자체의 어휘로 명령을 작성하는 것을 의미했다—혹은 약간 덜 불친절한 형태였다.

기계어와 어셈블리가 주된 방식이었다

초기 컴퓨터는 기계어, 즉 숫자형 연산 코드와 메모리 주소를 실행했다. 이걸 대규모로 관리하기는 거의 불가능했기 때문에 프로그래머들은 많은 숫자를 짧은 기호로 대체해주는 어셈블리 언어를 사용했다. 하지만 어셈블리는 여전히 하드웨어에 대한 얇은 층에 불과했다. 수학적으로 무엇을 원하는지를 기술하는 대신, 레지스터 하나하나, 메모리 접근 하나하나로 어떻게 할지를 단계적으로 써야 했다.

과학 계산의 경우 루프, 메모리 배치, 중간 값 관리를 수작업으로 처리해야 했다. 수식의 작은 변경 하나가 프로그램의 여러 부분을 다시 써야 하는 결과를 낳곤 했다.

고통의 포인트: 시간, 오류, 락인

어셈블리 프로그래밍은 느리고 취약했다. 흔한 문제는 다음과 같았다:

• 시간 소모: 작성과 디버깅이 근본 수학보다 훨씬 오래 걸렸다.
• 오류에 취약: 잘못된 주소 하나, 누락된 자리올림, 오프 바이 원 버그가 결과를 무효화할 수 있었다.
• 하드웨어 종속 코드: 프로그램은 IBM 704 같은 특정 기계 모델에 강하게 묶였다. 다른 시스템으로 옮기려면 처음부터 다시 시작해야 하는 경우가 많았다.

빠른 반복이 중요한 이유

과학자와 엔지니어는 단지 한 번 계산을 돌리는 사람들이 아니었다—그들은 모델을 다듬고, 시뮬레이션을 재실행하며, "만약"의 시나리오를 탐색했다. 각 업데이트가 며칠 또는 몇 주의 재코딩과 테스트를 의미할 때 실험은 느려질 수밖에 없다.

여기서 새로운 형태의 비용이 드러났다: 프로그래머의 시간. 하드웨어가 비쌌지만 숙련된 사람들의 시간도 비쌌다. 1950년대 중반이 되자 병목은 항상 기계 속도가 아니라 사람이 기계를 유용하게 작동시키는 데 걸리는 시간인 경우가 많았다.

존 배커스와 IBM의 새로운 프로그래밍에 대한 도박

존 배커스는 원래부터 예정된 ‘컴퓨터 선구자’가 아니었다. 초반 방황과 미군 복무를 거쳐 1950년대 초 IBM에 들어온 그는 귀찮은 작업에 대한 실용적 참을성 부족과 야심찬 공학 프로젝트를 조직하는 재능으로 빨리 두각을 나타냈다.

IBM의 목표: 704의 가치를 뽑아내자

IBM은 문제이자 기회를 한 기계에 담고 있었다: IBM 704. 당시로선 강력한 기계였고 부동소수점 연산 같은 수치 작업에 유리한 기능을 제공했다. 하지만 기술·과학 고객들은 어셈블리 작성에 막대한 시간을 쓰고 있었다. 프로그래밍이 그 수준으로 느리다면 훌륭한 컴퓨터도 제대로 활용되지 못할 것이었다.

IBM의 도박은 단순히 말하면 위험한 시도였다: 속도를 포기하지 않고 704를 더 쉽게 프로그래밍하게 만들자.

컴파일러 중심으로 구성된 팀

배커스는 FORTRAN을 두 개의 불가분의 프로젝트로 다뤘다: 사람들이 쓸 수 있는 언어와 그것을 빠른 기계어로 번역할 수 있는 컴파일러. 진짜 내기는 후자였다. 많은 전문가들은 “자동 프로그래밍”이 수작업으로 튜닝한 어셈블리를 대체하기엔 항상 비효율적일 것이라고 믿었다.

그때의 ‘고급’이 의미하던 것

그 당시에 고급 언어는 단지 ‘보기 좋은 문법’이 아니었다. 그것은 수식, 루프, 구조화된 지시문을 문제의 수학과 논리에 더 가깝게 쓰고, 컴파일러가 이를 숙련된 프로그래머가 손으로 만든 코드와 경쟁할 수 있는 수준으로 만들어줄 것이라는 신뢰를 의미했다. IBM과 배커스가 얻으려 했던 신뢰는 바로 그 점이었다.

FORTRAN의 약속(그리고 사람들의 회의론)

FORTRAN의 핵심 약속은 단순하지만 급진적이었다: 기계에게 어떻게 하나하나 지시하는 대신 문제에 익숙한 수학적 표현에 훨씬 가깝게 명령을 쓸 수 있게 한다는 것.

엔지니어는 어셈블리에서 요구하던 로드·덧셈·저장·분기 시퀀스를 일일이 쓰는 대신 “이 수식을 많은 값에 대해 계산하라” 같은 표현을 쓸 수 있었다. 희망은 프로그래밍이 아이디어를 표현하는 쪽으로 바뀌고, 하드웨어의 배선도 같은 글쓰기에서 벗어나는 것이었다.

평이한 말로서의 "컴파일"

FORTRAN은 컴퓨터에서 직접 실행되지 않았다. 별도의 프로그램—컴파일러—가 FORTRAN 소스 코드를 그 기계의 저수준 명령어로 번역했다.

비유하면, 사람이 읽을 수 있는 언어로 작성하면 컴파일러가 그걸 기계가 바로 이해할 수 있는 말로 바꿔주는 숙련된 통역사와 같다.

설계 목표: 가독성, 속도, 실용성

배커스 팀은 드문 조합을 목표로 했다:

• 가독성: 대수 표기와 일반적인 과학 표기와 맞닿는 코드.
• 속도: 손으로 쓴 어셈블리에 근접하는 실행 성능.
• 실용성: 수치 작업에 실제로 필요한 기능들.

특히 마지막 항목이 중요했다. FORTRAN은 모든 것을 다 하려 한 것이 아니라 오류를 줄이고 실제 계산을 처리하는 데 초점을 맞췄다.

왜 사람들은 의심했나

회의론은 강했다. 많은 프로그래머들은 성능을 위해선 완전한 통제가 필요하다고 믿었고, “자동” 번역은 낭비적일 것이라고 우려했다. 또 다른 사람들은 디버깅을 걱정했다: 컴파일러가 최종 명령을 생성한다면 기계가 실제로 무엇을 하고 있는지 어떻게 알 수 있겠는가?

분명한 대상 사용자

FORTRAN의 초기 사용자는 엔지니어와 과학자였다—방정식을 돌리고, 모델을 테스트하고, 결과를 만들어야 하는 사람들. 그들에게 약속은 새로움이 아니라 시간 절약, 전사 오류 감소, 그리고 소수의 어셈블리 전문가가 아닌 여러 사람이 읽고 유지할 수 있는 프로그램이었다.

컴파일러 과제: 영어 같은 코드를 빠르게 만들기

FORTRAN은 단순히 프로그램을 쓰는 새로운 방식이 아니었다—그것은 프로그램을 번역하는 새로운 방식을 요구했다. 이 번역의 성공 여부가 FORTRAN이 혁명이 될지 아니면 사소한 사례가 될지를 결정했다.

컴파일러란 무엇인가(일상적 비유)

컴파일러를 기술 회의의 숙련된 통역사로 생각해보자. 당신은 "이 방정식을 계산하고 각 값에 대해 반복하라" 같은 고수준 문장을 말하지만 청중은 제한된 저수준 어휘만 이해한다. 형편없는 통역사는 의미를 맞게 전달하더라도 어색하고 느리고 돌아가는 번역을 할 것이다. 훌륭한 통역사는 의미와 효율성 둘 다를 보존해 즉시 실행 가능한 형태로 전달한다.

FORTRAN은 그런 훌륭한 통역사를 필요로 했다.

언어 우아함보다 컴파일러 품질이 중요했던 이유

초기 프로그래머들은 아름다움이나 편의성 때문에 FORTRAN을 선택한 것이 아니다. 그들은 그것이 ‘제값을 치러줄’ 때만 선택했다: 즉 코드 작성 시간이 줄어들면서 런타임에 불이익이 없어야 했다. IBM 704 같은 비싼 기계에선 낭비된 CPU 시간은 곧 돈 낭비였고, 과학 작업에선 느린 코드가 결과를 제때 가져오지 못할 수 있었다.

그래서 진짜 제품은 언어 사양이 아니라 컴파일러의 출력물이었다. 컴파일된 프로그램이 수작업 어셈블리만큼 빠르게 동작하면 전환을 정당화할 수 있었다. 그렇지 않다면 아무리 언어가 좋아 보여도 포기되었을 것이다.

핵심 기술 난제: 수식을 빠른 기계어로 바꾸기

FORTRAN의 장점인 "수학을 수학처럼 쓰기"는 컴파일을 어렵게 했다. 컴파일러는 다음을 해야 했다:

• 대수식의 우선순위 등을 정확히 구문 분석할 것
• 값을 레지스터에 유지할지 메모리에 둘지 결정할 것
• 안전하게 계산 순서를 재배치해 명령 수를 줄일 것
• 낭비 없는 루프를 생성할 것

채택을 좌절시킬 수 있는 회의론

많은 엔지니어는 고급 코드는 정의상 느릴 수밖에 없다고 생각했다. 배커스 팀은 성능으로 그 가정에 맞서야 했다: 컴파일된 프로그램이 경쟁력 있고 예측 가능하며 신뢰할 수 있다는 증거를 보여줘야 했다.

최적화: 사용자를 사로잡은 비밀 무기

FORTRAN의 큰 약속은 단지 코드를 더 빨리 쓰게 해주는 것이 아니라 컴파일된 프로그램이 여전히 빠르게 실행될 수 있다는 점이었다. 초기 채택자들은 취미 개발자가 아니라 기계시간과 결과 제출 시점에 민감한 엔지니어와 과학자들이었기 때문에 이것은 결정적이었다.

최적화가 의미하는 바(평이한 설명)

최적화는 컴파일러가 개발자 대신 추가 작업을 수행하는 것이다. 당신은 명확하고 수학에 가까운 문장을 쓰고, 컴파일러는 그걸 더 적은 명령과 적은 메모리 접근으로 실행되도록 조용히 재작성한다.

목표는 ‘영리함’이 아니라 예측 가능한 효율성이었다—그래서 사람들이 FORTRAN으로 작성하면 느린 벌을 받지 않는다고 신뢰할 수 있어야 했다.

사용자가 체감할 수 있는 최적화들

FORTRAN 컴파일러는 다음 같은 개선을 적용했다:

• 반복 작업 회피: 루프 안에서 변하지 않는 값은 한 번만 계산한다.
• 레지스터의 스마트한 사용: 자주 쓰이는 값을 메모리 대신 레지스터에 둔다.
• 대수적 단계 정리: 기계가 수행해야 할 연산 수를 줄인다.
• 루프 처리 개선: 불필요한 분기와 부기 작업을 줄여 루프를 촘촘하게 만든다.

이런 것들은 프로그래머가 명령 타이밍이나 메모리 주소를 신경 쓰지 않아도 되게 했다—바로 어셈블리 프로그래머가 중요하게 여긴 세부사항들이다.

왜 이것이 어셈블리 프로그래머를 설득했나

어셈블리는 항상 강력한 논리를 가졌다: "내가 직접 하면 더 빠르게 만들 수 있다." 초기 회의론자들은 고급 언어가 거추장스럽고 비효율적인 기계어를 만들 것이라고 생각했다.

배커스 팀은 그 회의론을 제품 요구사항으로 다뤘다. 최적화는 부가 기능이 아니라 추상화가 성능 포기를 의미하지 않음을 증명하는 증거였다.

평판 효과

FORTRAN 프로그램이 많은 실제 작업에서 수작업 어셈블리와 경쟁할 수 있다는 소문이 퍼지자 채택이 가속화되었다. 컴파일러는 신뢰할 수 있는 팀원처럼 여겨졌다: 의도를 명확히 쓰면 컴파일러가 세부를 맡아 하드웨어를 존중하는 결과를 내준다는 믿음이 생겼다.

FORTRAN이 쉽게 만든 것들: 루프, 서브루틴, 배열

FORTRAN은 단순히 ‘보기 좋았다’는 것을 넘어 실무적 아이디어들을 담아 과학자와 엔지니어의 일상적 작업과 직접 연결되었다: 반복 계산, 재사용 가능한 메서드, 예측 가능한 방식으로 많은 수를 저장하기.

수학과 맞닿는 루프

과학 프로그램은 반복 작업으로 가득하다: 측정값 합산, 시간 단계, 해를 향한 반복, 많은 데이터 지점에 걸친 동일 방정식 적용 등. 어셈블리에서는 이런 반복이 수동 점프 논리로 작성되었고 잘못되기 쉬웠으며 나중에 읽기 어려웠다.

FORTRAN의 DO 루프는 의도를 명확히 했다:

      SUM = 0.0
      DO 10 I = 1, 100
         SUM = SUM + X(I)
 10   CONTINUE

여러 분기와 카운터를 수동으로 관리하는 대신 범위를 지정하고 수식에 집중할 수 있었다.

재사용을 위한 서브루틴

엔지니어링 작업은 반복된다: 행렬 곱셈, 단위 변환, 다항식 평가, 표준 데이터 포맷 읽기 등. 서브루틴은 신뢰할 수 있는 한 루틴을 여러 곳에서 호출하게 해 복사·붙여넣기로 생기는 실수를 줄였다.

게다가 서브루틴은 큰 프로그램을 작은 부분으로 나눠서 사람들이 독립적으로 검토·테스트·개선할 수 있게 했다.

과학 데이터의 자연스러운 형태, 배열

측정값, 벡터, 표, 그리드, 행렬은 과학 계산의 핵심이다. 배열은 많은 별도의 변수를 관리하거나 메모리 주소 산술을 수동으로 하는 대신 그 구조를 직접 표현하게 해주었다.

‘미스테리 점프’ 감소, 버그 감소

어셈블리 중심의 제어 흐름은 많은 조건·무조건 분기에 의존했다. 잘못된 라벨 하나가 조용히 결과를 망가뜨릴 수 있었다. 루프와 명명된 서브루틴 같은 구조적 구성은 뒤얽힌 분기 논리의 필요성을 줄여 프로그램을 검증하기 쉽고 변경에 덜 취약하게 만들었다.

연구에서 실무로: FORTRAN이 성공한 곳

FORTRAN은 연구실의 재미있는 아이디어에 그치지 않고 실제 업무에서 반복적으로 사용되었기 때문에 널리 성공했다. 언어는 영향력 있을 수 있지만 일상 업무를 바꾸지 못할 수도 있다. FORTRAN은 실무자들이 실제 마감과 예산을 걸 만큼 신뢰했기 때문에 일상 업무를 바꿨다.

초기 대규모 사용자: 과학과 공학

초기 채택자는 계산에 목숨을 거는 그룹들—항공우주 프로그램, 물리 실험실, 기상·기후 연구, 구조·전기 계산을 하는 공학 부서였다. 이들은 장난감 예제가 아니라 작은 생산성 개선이 더 많은 실험, 더 많은 설계 반복, 손으로 튜닝한 어셈블리 속에 숨어 있던 오류를 더 빨리 찾게 해주는 워크로드였다.

FORTRAN은 배열(행렬·그리드), 루프(반복 수치 단계), 서브루틴(수학 중심 코드를 관리 가능한 조각으로 조직) 같은 핵심 기능이 문제의 형태와 잘 맞았다.

프로그램 공유가 현실적이 되다

어셈블리 프로그램은 특정 기계에 강하게 결속되어 있고 다른 사람이 읽고 고치기 어려운 스타일로 쓰였다. FORTRAN은 마법처럼 모든 기계에서 돌아가게 하진 않았지만 프로그램을 더 이해하기 쉬운 형태로 만들었다. 조직 내에서, 그리고 점점은 조직 간에도 코드를 전달하고 수정하는 일이 실용적으로 가능해졌다.

재사용이 구호가 아니게 되다

프로그래머가 더 높은 수준으로 계산을 표현할 수 있게 되자 신뢰할 수 있는 루틴 모음을 유지하는 것이 의미를 가졌다. 팀은 수치 방법, I/O 패턴, 도메인별 계산을 덜 두려워하며 재사용할 수 있게 되었고, 코드가 유지·개선 가능한 자산이라는 인식이 자리잡기 시작했다. 이 전환은 프로그래밍을 1회성 수공예에서 반복 가능한 작업으로 밀어주는 데 기여했다.

FORTRAN의 긴 그림자: 이후 언어들에 남긴 아이디어

FORTRAN은 한 기계를 더 쉽게 프로그래밍하게 만든 것만이 아니다. 그것은 언어가 무엇을 해야 하고 컴파일러가 무엇을 할 수 있는지에 대한 기대를 세웠다—둘 다 아직 논쟁 중이던 시대에.

컴파일러 기술을 기능으로 인식하게 함

FORTRAN 성공의 핵심 교훈은 언어 설계와 컴파일러 설계가 분리될 수 없다는 것이다. 초기 비평가들은 단순히 ‘영어 같은’ 코드 자체를 의심한 것이 아니라 컴파일러가 그것을 효율적인 기계어로 번역할 수 있을지 의심했다. FORTRAN 팀의 답은 컴파일과 최적화에 대대적으로 투자하는 것이었고, 이 관점은 이후 많은 언어 프로젝트에 영향을 미쳤다.

더 나은 컴파일러 기술이 더 나은 언어를 가능하게 한다는 믿음은 이후 수십 년간 이어졌다: 더 안전한 추상화, 더 명확한 문법, 성능을 포기하지 않는 생산성.

최적화를 기대치로 만들다

FORTRAN은 특히 수치 워크로드에 대해 컴파일러가 경쟁력 있는 코드를 생성해야 한다는 관념을 보편화하는 데 기여했다. 모든 후속 언어가 동일한 성능 목표를 쫓진 않았지만 기준이 바뀌었다: 고수준 ≠ 느림. 이로 인해 루프 분석, 계산 재구성, 레지스터 관리 같은 최적화 기법이 컴파일러 구성의 표준 주제가 되었다.

이식성과 표준화: 느리지만 필연적이었던 흐름

초기 FORTRAN은 IBM 하드웨어에 밀접히 묶여 있었고 이식성은 주된 판매 포인트가 아니었다. 그러나 FORTRAN이 기관과 기계들 사이에서 퍼질수록 동일한 과학 코드를 다시 쓰는 비용이 명확해졌다. 시간이 지나면서 FORTRAN은 업계를 언어 표준화로 밀어붙이는 주요 원동력 중 하나로 평가받게 되었다.

결과는 즉각적이지도 완전하지도 않았지만, 한 베ンダ나 기계 세대를 넘는 언어는 안정적인 정의(표준)를 필요로 한다는 선례를 만들었다.

한계와 비판: FORTRAN이 해결하지 못한 것들

FORTRAN은 복잡한 계산을 어셈블리의 홍수 속에서 벗어나게 했지만 프로그래밍을 ‘쉽게’ 만들지는 못했다. 초기 사용자들은 고급 언어가 한 세트의 골칫거리를 제거하는 동안 새로운 문제를 드러낸다는 것을 발견했다.

가독성 대 성능은 공짜 점심이 아니다

FORTRAN의 속도 평판은 코드의 모습과 작법에 대한 트레이드오프를 동반했다. 프로그램은 종종 컴파일러가 최적화할 수 있는 방식으로 재구성되었고, 이로 인해 새로운 팀원이 이해하기 어려운 코드가 될 수 있었다.

하드웨어가 다양한 세계에서의 이식성 한계

FORTRAN이 프로그램을 기계 간 이동시키는 데 도움을 주긴 했지만 초기에는 "이식 가능"에도 별표가 있었다. 컴퓨터들은 단어 크기, I/O 장치, 기본 수치 동작이 달랐다. 팀들은 때로 같은 프로그램의 서로 다른 버전을 유지하거나 특별 기능을 위해 기계별 부분을 섞어 써야 했다.

언어가 복잡성을 완전히 제거하지는 못함

FORTRAN은 과학 계산을 위해 만들어졌지 모든 것을 위해 만들어지진 않았다. 매우 큰 코드베이스를 조직하는 강력한 도구는 부족했고, 디버깅은 여전히 느리고 초기 컴파일러는 난해한 오류를 내놓기도 했다.

오늘날에도 익숙한 논쟁

FORTRAN은 개발자가 최고 성능을 우선해야 할지, 아니면 더 명확한 코드와 고수준 추상화를 택해야 할지에 대한 논쟁을 촉발했다. 당시에도, 지금도 정답은 상황에 따라 다르다. FORTRAN은 추상화가 효과를 낼 수 있음을 증명했지만, 모든 편의의 경계가 있다는 교훈도 남겼다.

현대 소프트웨어 팀을 위한 교훈

FORTRAN이 성공한 이유는 개발자 시간을 희소 자원으로 간주했기 때문이다. 배커스와 IBM은 단순히 보기 좋은 문법을 만든 것이 아니라 도구에 투자하면 전혀 새로운 종류의 소프트웨어가 가능해진다는 것을 증명했다.

생산성이 '영리함'을 이긴다

FORTRAN의 주장은 간단했다: 줄 수를 줄여 더 정확한 프로그램을 더 많이 내놓자. 현대 팀도 이 교훈을 계속해서 재학습한다. 안전한 API, 명확한 모듈 경계, 고통스러운 워크플로우를 자동화하는 스크립트에 한 주를 쓰는 것이 뜨거운 루프에서 3%를 더 짜내는 것보다 더 큰 가치를 돌려주는 경우가 많다.

추상화에 대한 신뢰를 얻어라

사람들은 추상화가 통제를 포기하는 것처럼 느껴 의심했다. 컴파일러는 손으로 튜닝한 어셈블리에 근접한 속도를 제공해 그 불신을 바꿔 놓았다.

현대의 비슷한 사례는 프레임워크, 관리형 런타임, 클라우드 서비스에 대한 신뢰다—그러나 그 신뢰는 당연히 주어지지 않는다. 추상화가 깨질 때 팀은 수동 모드로 후퇴한다. 치료법은 1957년과 같다: 측정 가능한 성능, 투명한 동작, 예측 가능한 실패 모드.

도구가 가능성을 바꾼다

FORTRAN은 언어만이 아니라 고급 프로그래밍을 대규모로 가능하게 한 컴파일러 노력이었다. 오늘날 동등한 것들은:

• 최적화하고 경고를 제공하는 컴파일러 및 인터프리터
• 코드 리뷰를 빠르게 하는 린터와 포맷터
• 변경을 일상적 사건으로 만드는 테스트와 CI

또한 자동화를 통해 인간의 일을 ‘컴파일러 같은’ 시스템으로 옮기는 새로운 도구들도 있다. 예를 들어 Koder.ai 같은 플랫폼은 채팅으로 원하는 바를 설명하면 에이전트 기반 시스템이 실제 애플리케이션(예: 웹의 React, 백엔드의 Go+PostgreSQL, 모바일의 Flutter)을 생성·반복하도록 한다. 실제로 계획 모드, 스냅샷, 롤백 같은 기능은 FORTRAN이 증명해야 했던 것과 같은 효과—고수준 의도, 운영 제어의 상실 없이—을 제공하려는 시도다.

좋은 도구는 단순히 버그를 막는 것이 아니라 더 큰 야망을 가능하게 한다. 더 작은 팀으로 더 큰 시스템을 구축할 수 있게 해준다.

마무리

배커스의 지속적 영향은 ‘코드 주변의 시스템’—언어, 컴파일러, 관행—이 사람들의 작업을 더 빠르고 자신 있게 만들어 소프트웨어가 확장된다는 아이디어다. 그 전략은 오늘날의 엔지니어링 팀에게도 여전히 유효한 플레이북이다.