Ada와 DIANA, Rational R1000 사례를 통해 텍스트 소스 대신 중간 표현을 저장하던 1980년대의 접근을 돌아보며, 오늘날의 린터·포매터 논쟁이 왜 여전히 반복되는지와 우리가 배울 점을 이야기합니다.
2025년 9월 6일
그리고 우리는 80년대에 이미 알았다 고등학교 때 (아마도 약간 과하게 자격을 갖춘) 컴퓨터 과학 선생님인 Paige 선생님이 계셨다. 그는 Ada 컴파일러 작업을 했고 80년대 초부터 프로그래밍을 해왔다.
어느 날 나를 미치게 만드는 린터 툴에 대해 불평을 했다. "지금이 2016년인데, 어떻게 아직도 이런 걸로 고생하고 있는 거지?"라는 식으로 말했다.
알고 보니, 그 문제는 40년 전에 이미 해결됐었다(그때 기준으로는 30년). 그가 Ada에서 일하던 시절에는 텍스트 소스를 전혀 저장하지 않았다 — DIANA라는 IR을 썼다. 모두가 각자 원하는 방식으로 볼 수 있도록 프리티 프린팅 설정을 가지고 있었다.
요즘 회사에서 몇 가지 린터 설정을 두고 논쟁을 벌이고 있는데, 자꾸 Paige 선생님이 떠오른다. 지금이 2025년인데, 어떻게 아직도 이런 걸로 씨름하고 있는 거지?
자, 그 답을 하려면 우리가 무엇을 놓치고 있는지 아는 게 도움이 된다.
그는 Rational R1000에서 일했던 것으로 안다. 이에 대한 정보는 많지 않다(대부분의 Ada 관련 것들처럼, 미 국방부에서 사용했기 때문이다):
R1000에는 최첨단 기능이 잔뜩 있었다: 증분 컴파일, 의미 분석, 버전 관리, 그리고 일급 디버깅이 모두 내장되어 있었다. Smalltalk 대신 Ada를 사용하는 Xerox Alto와 비슷한 워크스테이션이었다.
DIANA(Descriptive Intermediate Attributed Notation for Ada)는 Ada의 핵심 구성 요소로, 더 진보된 기능을 가능하게 했다.
Experiences with Code Generation (1984)에서 발췌
텍스트 소스 코드를 저장하는 대신, R1000은 DIANA를 썼다. 이 머신에 내장된 컴파일러와 IDE도 DIANA를 이해했기 때문에, 원하는 방식으로 소스를 볼 수 있었다. 공백과 탭은 의미에 영향을 주지 않으니 상관없었고, 시스템의 편집기는 프로그램 트리를 직접 수정할 수 있게 해줬다(오늘날에는 프로젝셔널 편집으로 알려져 있다).
Grady Booch는 이를 잘 요약한다:
R1000은 사실상 DIANA 머신이었다. 우리는 소스 코드를 저장하지 않았다. 소스 코드는 단지 DIANA 트리의 프리티 프린팅일 뿐이었다.
상상해 보라. 형식 논쟁이나 린터 싸움으로 시간을 낭비하지 않는다. 그렇다고 모두에게 같은 편집기 설정을 강요하지도 않는다(eslint-config-airbnb, 너 말이야).
그리고 다른 이점들도 있었다:
DIANA를 하드웨어 가속과 함께 사용하면서 증분 컴파일(강한 타입 언어에서는 당시 상상도 못했던), 쉬운 리팩터링(그 단어는 아직 발명되지도 않았지만), 그리고 엄청나게 빠른 통합(당시 Ada로 구축되던 대규모 시스템에 필수)을 할 수 있었다.
오늘날 우리는 (부디) 하드웨어 가속 컴파일을 걱정할 필요는 없고, 리팩터링을 위한 더 나은 도구들도 있다(고마워, Claude). 하지만 포매팅에 관해서는 퇴보했다. 모두가 프로젝셔널 편집과 라이브 환경을 쓰자고 주장하는 건 아니다(물론 그건 멋지고 더 탐구해야 한다고 생각한다). 하지만 오늘날의 프로그래밍 패러다임에 맞는 무언가를 분명히 찾아낼 수 있을 것이다.
이 글은 원래 “그냥 최소화된 코드를 푸시하면 더 쉬울 텐데”라고 말하려다, 쓰는 동안 R1000을 조사하는 게 너무 재미있어서 길어졌다. 내가 살펴본 문서들:
