PL/I — 과학·비즈니스·시스템 통합을 시도한 IBM의 거대 언어 (1964)
Entity (인물·조직)lectureverified2026-05-09

PL/I — 과학·비즈니스·시스템 통합을 시도한 IBM의 거대 언어 (1964)

#vch#lecture-intro#A-language#g3

PL/I — 과학·비즈니스·시스템 통합을 시도한 IBM의 거대 언어

1. 요약

PL/I(Programming Language One)는 1964년 IBM과 SHARE Language Development Committee가 발표한 통합 프로그래밍 언어이다. FORTRAN(과학 계산)·COBOL(비즈니스)·ALGOL(학술) 세 갈래로 분리되어 있던 1960년대 초의 프로그래밍 생태계를, 하나의 언어로 모두 처리하려는 야심찬 시도였다. IBM System/360 메인프레임과 짝을 이루어 1960~80년대 대형 메인프레임 환경의 표준 언어로 사용되었고, Multics 운영체제의 구현 언어이기도 했다. 1976년 ANSI 표준화(X3.53-1976).

2. 등장 배경

1960년대 초 프로그래밍 환경은 분리된 섬이었다.

  • FORTRAN (1957) — 과학·공학 계산. 비즈니스 자료 처리에 부적합.
  • COBOL (1959) — 비즈니스 자료 처리. 수치 계산에 약함.
  • ALGOL 60 — 학술 영역. 산업적 보급 약함.

기업이 과학과 비즈니스 작업을 같은 컴퓨터에서 수행하려면 두 개 이상의 언어를 운영해야 했다. IBM이 System/360(1964년 발표, 1966년 출시) — 과학·비즈니스 통합 메인프레임 — 을 발표하면서, 짝이 될 통합 언어가 필요했다.

1963년 10월 IBM 위원회는 처음에는 FORTRAN을 확장해 보려 했지만 실패했다. "given the constraints of Fortran, they were unable to do this and embarked on the design of a new programming language based loosely on ALGOL". 결과가 PL/I이다.

3. 핵심 특징

  1. 블록 구조와 재귀(Block Structure & Recursion) — ALGOL 60의 영향. 중첩 블록·재귀 호출 지원.
  2. 예외 처리(Exception Handling) — ON-units를 통한 런타임 조건 처리. 후일 Java try/catch의 사상적 조상.
  3. 멀티태스킹(Multitasking) — EVENT, TASK 데이터 타입을 언어 차원에서 지원. 운영체제와의 통합.
  4. 포인터 기반 동적 저장(Pointer + BASED Variables) — ALLOCATE/FREE를 통한 동적 메모리 관리. C의 malloc/free보다 8년 앞섬.
  5. 구조적 프로그래밍 구문 — DO/END, IF/THEN/ELSE, SELECT/WHEN. 이 시기 구조적 프로그래밍을 언어 표준으로 받아들인 첫 IBM 언어.

4. 주 용도

  • IBM System/360 메인프레임: 과학 계산 + 비즈니스 자료 처리 통합.
  • Multics 운영체제: MIT·Bell Labs·GE의 야심찬 운영체제 프로젝트가 PL/I로 작성됨. UNIX·C가 여기서 반동으로 태어남.
  • 금융·은행·정부 메인프레임: 1990년대까지 IBM 메인프레임 환경에서 광범위하게 사용.

5. 그 시대 설계 도구 매핑

도구역할PL/I와의 관계
HIPO 차트 (Hierarchy + Input-Process-Output) (IBM, 1970년대)계층적 함수 분해 + I/O 명세. IBM 자체 표준.PL/I 프로시저 분해의 기본 도식
Flowchart (ANSI 표준 흐름도)알고리즘 시각화PL/I 코드 작성 전 단계 표준
VDM (Vienna Development Method) (IBM Vienna Lab, 1967~)최초의 대규모 형식적 명세 방법론PL/I 언어 자체의 형식적 정의를 위해 만들어진 방법론
Constantine-Yourdon Structured Design (1974~)모듈 분해·결합도/응집도PL/I 대규모 시스템 분해에 적용

→ VDM의 의의: PL/I 자체를 형식적으로 정의하기 위해 만들어진 방법론이 언어보다 더 오래 살아남았다. VDM은 후일 Z notation, B method 등 형식적 명세 운동의 출발점이 된다. 즉 언어는 죽어도 설계 방법론은 살아남는다는 본 강의 핵심 명제의 직접 사례.

6. 강의 활용

핵심 명제와의 연결: PL/I는 언어 통합에는 실패했지만, 형식적 명세(VDM)라는 더 깊은 영역을 열었다. 즉 언어가 아무리 야심차게 만들어져도, 설계와 명세가 부재하면 살아남지 못한다 — 거꾸로 말하면 설계 방법론은 언어를 넘어서 산다.

강의에서의 위치: G3에서 대척점 사례. Pascal·C는 작고 정돈된 길을 갔고, PL/I는 모든 것을 포함하는 길을 갔다. 결과는 — 작고 정돈된 쪽이 살아남았다. 이는 본 강의의 No Design, No Code와 정반대로 Too Much Design, No Survival의 사례이기도 하다.

오늘날의 흔적:

  • VDM·Z·B method 등 형식적 명세는 안전 필수(safety-critical) 영역에서 살아있음.
  • Multics의 야심은 UNIX의 Worse is Better 철학에 대척점으로 인용된다.
  • IBM 메인프레임에는 여전히 PL/I 코드가 남아있음 (z/OS Enterprise PL/I).

오늘 LLM 시대로의 다리: PL/I의 실패는 모든 것을 하나의 언어로 시도하면 언어가 무거워져 사라진다는 교훈을 준다. LLM 시대의 Spec-driven Development는 정반대 방향 — 언어는 작게, 명세는 풍부하게. 그러나 명세를 형식화하는 방법은 PL/I 시대의 VDM 정신이 살아 돌아온 것이기도 하다.

출처

  • Wikipedia, "PL/I", https://en.wikipedia.org/wiki/PL/I
  • Bjørner, D., & Jones, C. B. (Eds.). (1978). The Vienna Development Method: The Meta-Language. Springer LNCS 61.
  • IBM. (1976). PL/I Language Reference Manual.

그룹 시리즈

→ synthesis/group-g3 (시대 그룹 종합 카드)