아폴로 AGC 인터프리터와 객체지향의 관계 - 왜 비슷해 보이는데도 바로 객체지향 시대로 이어지지 않았는가

1. 문제 제기

아폴로 유도 컴퓨터 (AGC) 의 인터프리터 구조를 보면, 현대의 추상화 계층이나 가상 머신을 떠올리게 하는 요소드링 존재한다.

실제로 Virtual AGC 의 assembly manual 은 AGC interpreter 를 computer-within-the-computer, 즉 컴퓨터 안의 가상적 컴퓨터처럼 설명하며, 일반 AGC 명령보다 더 높은 수준의 연산과 별도의 주소 공간 개념을 제공했다고 설명한다.

하지만 여기서 곧바로

"그렇다면 왜 이것이 바로 객체지향이나 현대적 고수준 프로그래밍의 주류화로 이어지지 않았는가?" 

라고 묻는다면 답은 단순하지 않다.

 

AGC 인터프리터는 극단적인 자원 제약 아래에서 탄생한 특수 목적의 추상화 기술이었다.

 

2. AGC 인터프리터는 무엇이었나

제한된 메모리 환경에서 더 많은 기능을 담기 위해 만든 interpretive layer 였다. 

이를 통해 같은 메모리 안에 더 많은 기능을 넣을 수 있게 해 주었지만, 그 대가로 실행 ㅇ속도는 상당히 느렸다

AGC 인터프리터의 1차 목적

• 추상화를 통해 코드를 구조적으로 아름답게 만드는 것이 아닌
• 제한된 메모리 안에 기능을 우겨 넣는 것
• 높은 수준의 작업을 compact 하게 표현하는 것

 

3. 왜 이것이 바로 객체지향으로 이어지지 않았는가

추상화의 아이디어와는 별개로 그 비용을 감당할 수 있는지가 더 중요 

 

4. 최종 정리

아폴로 AGC 인터프리터는 현대의 VM이나 추상 계층을 떠올리게 하는 요소를 분명히 가지고 있다. 그러나 그것을 현대 객체지향의 직접적 선구로 보는 것은 부정확하다. AGC 인터프리터의 핵심 목적은 제한된 메모리 안에 더 많은 기능을 담기 위한 특수 목적의 메모리 절약형 실행 계층이었고, 그 대가로 속도를 희생했다. 반면 객체지향은 이미 Simula 67과 초기 Smalltalk를 통해 등장해 있었지만, 당시 산업의 주류는 여전히 절차적·시스템 프로그래밍이었고, 자원 제약과 도구 부족, 생태계의 관성 때문에 빠르게 중심이 되지 못했다. 이후 software crisis와 소프트웨어 규모의 폭증이 구조화와 관리의 필요를 키우면서, 객체지향과 고수준 추상화가 점차 널리 확산되었다. 따라서 AGC 인터프리터는 “OOP로 바로 이어지지 못한 실패한 선구”가 아니라, 극단적 제약 조건 아래에서 탄생한 매우 이른 abstraction 사례로 보는 것이 가장 정확하다.