API의 역사와 발전

나 잘래

개요

웹개발, 특히 서버 개발의 세계에서 가장 처음으로 마주하게 되는 것은 아마도 API 일것입니다.

Application Programming Interface

즉, 프로그램끼리의 상호작용을 위한 이 인터페이스는 현대의 모든 프로그램, 하드웨어 사이에서 데이터를 주고 받기위한 표준적인 방법론으로 받아들여지고 있는데요.

언제부터, 어떻게 이 API라는 개념이 출발한 것일까요?

 

본 아티클은 아래 유튜브 영상을 토대로 정리하였습니다.

https://www.youtube.com/watch?v=LzMp6uQbmns

 

폰노이만의 ‘서브루틴 라이브러리’ 개념 제창

Planning and Coding of Problems for an Electronic Computing Instrument

헤르멘 골드스타인과 폰노이만이 컴퓨터가 만들어지기도 전에 “컴퓨터가 있으면 이런 식으로 프로그램을 만들면 좋겠다” 라는 생각에서 작성한 현대 프로그래밍의 조상님급 문서입니다

 

 

 

 

 

 

 

 

 

위 책에서 처음으로 서브루틴 라이브러리 이라는 개념을 제창하게 되었습니다.

*<Planning and Coding of Problems for an Electronic Computing Instrument - 12.3장에서>

우리는 어떤 문제를 코드로 작성한 일련의 과정을 “루틴(routine)“이라고 부르며, 다른 루틴 안에 삽입될 수 있도록 구성된 루틴을 “서브루틴(subroutine)“이라고 부릅니다. 앞서 언급했듯이, 우리는 적절히 조직된 자동 고속 계산 장치가 이러한 서브루틴들을 광범위하게 수집해 포함하게 될 것이라 생각합니다. 이러한 서브루틴들은 약 15~20개의 단어 길이부터 시작해 다양할 수 있으며, 이는 자기 와이어(magnetic wire)나 테이프 같은 외부 기억 매체의 형태로 “기록 라이브러리(library of records)”로 존재할 것입니다.

이렇게 서브루틴을 통해 사전에 처리될 수 있는 문제들의 성격은 매우 다양하며, 지금 일반적으로 인식되는 것보다 훨씬 넓은 범위에 이를 것입니다.

이러한 가능성에 대한 몇 가지 예시는 **다음 장(13장과 14장)*에서 다루어질 예정입니다. 그 장들에서는 우리가 생각하는 가능성과 목표가 구체적으로 어떤 모습일 수 있는지에 대해 더 명확한 그림을 제시할 것입니다.

 

해당 책의 Key Idea는 대다수의 프로그램들이 서브루틴 라이브러리 라고 일컫는 일반적인 동작 절차들의 모음 (ex 덧셈, 뺄셈 등) 이 프로그램의 오류를 줄이고 효율을 높일 것이라는 것입니다. (시도되고, 테스트된 코드를 재사용하는 것이므로)

 

서브루틴 라이브러리 그리고, 모리스 윌크스(Maurice Wilkes) 의 EDSAC

https://ko.wikipedia.org/wiki/에드삭

에드삭 - 위키백과, 우리 모두의 백과사전

에드삭(EDSAC) 은 최초의 실용적인 목적의 프로그램 내장 컴퓨터 입니다.

폰 노이만의 EDVAC 보고서에서 영향을 받아 구현되었고, 케임브리지 대학교의 모리스 윌크스 교수 팀이 1949년 만들었습니다.

데이터 저장은 수은 지연관(수은의 높은 밀도를 이용하여 데이터를 저장)을 통해 수행했습니다.

모리스의 튜링상

https://amturing.acm.org/award_winners/wilkes_1001395.cfm

윌크스 교수는 최초로 내부에 프로그램을 저장하는 컴퓨터인 EDSAC을 설계하고 제작한 인물로 가장 잘 알려져 있습니다. 1949년에 제작된 EDSAC은 수은 지연선(memory delay line) 메모리를 사용했습니다.

그는 또한 휠러(Wheeler)와 길(Gill)과 함께 1951년에 출간한 『전자 디지털 컴퓨터용 프로그램 준비(Preparation of Programs for Electronic Digital Computers)』의 공동 저자로도 유명한데, 이 책에서는 프로그램 라이브러리 개념이 사실상 처음으로 도입되었습니다.

 

컴퓨터 과학계의 노벨상이라고 불리는 튜링상은 서브루틴 라이브러리 라는 주제에 대해 처음으로 제창한 폰노이만이 아닌, 모리스 윌크스에게 수여되었는데요.

그 이유는 모리스 윌크스가 처음으로 라이브러리의 개념을 실질적인 활용의 레벨으로 끌어올렸기 때문입니다.

모리스 윌크스는 레이더에 관한 연구를 하고 있었고, EDSAC 을 실질적으로 활용하기 위해 처음으로 **Airy 미분방정식(**광학, 파동 방정식 등에서 흔히 사용하는 미분방정식)을 프로그램화 했습니다.

 

당시에 모리스는 실용적인 프로그램 사용을 염두에 두었기 때문에, 바이너리코드가 아닌, 어셈블리 코드로 코드를 작성했습니다. 그리고 다음과 같은 메모를 남겼습니다.

Maurice Wilkes의 회고록 중..
1949년 6월 무렵… 나는 Airy 미분방정식의 수치적 적분을 계산하는, 내 생애 첫 ‘실제(non-trivial)’ 프로그램을 작동시키기 위해 애쓰고 있었다. EDSAC 컴퓨터실과 천공 카드 장비 사이를 오가던 중 계단 모서리에서 잠시 멈춘 그 순간 문득 이런 깨달음이 왔다.

”앞으로 내 인생 대부분은 내 코드의 오류를 찾는 데 쓰이게 되겠구나.”*
— Maurice Wilkes, Memoirs

 

모리스는 모든 코드를 일일히 직선적으로 작성하다보니, 오류가 발생하기 쉬웠고, 수정하기 어려운 문제가 생겼음을 깨달았습니다.

그리고, 이러한 문제의 부분적인 해결 방법을 제자인 서브루틴 라이브러리 에서 찾았습니다.

 

윌러

당시에 어떤 코드를 작성한다는 것은 어셈블리어로 모든 로직을 함수 호출 없이 구현한다는 것이었고, (요즘으로 치면 매번 +, *, if, for 같은 걸 직접 비트 연산으로 만들어 써야 하는 셈입니다.) 이를 해결할 구조를 구성한 사람이 사람이 당시 모리스의 제자였던 윌러였습니다.

윌러가 생각한것은 다음과 같습니다.

1. EDSAC에서는 수은관 메모리를 저장소로 사용하고 명령어를 각 메모리 주소에 저장하는데, 이를 이용하여 특정 주소에 특정 주소에 반복적으로 쓰일 계산 루틴 (ex. 곱셈) 을 저장함
2. 메인 프로그램에서 해당 주소로 점프 하여 계산을 수행함.
3. 계산 결과를 정해진 주소 에 저장함.
4. 메인 프로그램은 다시 정해진 주소 의 값을 읽어 활용

개념 당시 구현 방식 현대 개념

서브루틴 저장	메모리 주소(수은관)에 저장	함수 정의
서브루틴 호출	메모리 점프 + 인자 주소 참조	함수 호출 with 파라미터
결과 반환	지정된 주소에 결과 저장	return 값
복귀 처리	복귀 주소를 따로 저장 후 점프	call stack / return 주소

즉, 기존에 모든 로직에 대해 일일히 로직을 작성하던 것에서, 미리 작성된 코드를 재사용할 수 있게 기반을 마련한 것이고, 현대의 프로그램의 함수 호출, 나아가 모듈화 의 기반을 마련한 것입니다

당시, 칭찬에 인색했던 모리스 교수또한 제자의 연구를 보고 EDSAC에 존재했던 42개의 지시문 (T(transfer), U(점프) 등 명령어) 로 만든 경이적인 창의성의 결정체(tour de force of ingenuity) 라는 평가를 내렸습니다.

 

이 역사적인 사진은 실제로 EDSAC을 위한 코드를 작성하는 사람의 사진인데요.

왼쪽의 화살표로 가르켜진 사물함에 실제로 여러개의 서브루틴 라이브러리가 들어가있습니다.

당시 코드 작성 절차는 다음과 같았습니다.

1. 철제 캐비넷에서 필요한 라이브러리를 가져옵니다.
2. 가운데의 기계에 넣어서 메인프로그램 코드(천공 종이 카드 혹은 테이프) 에 복사를 합니다.
3. 라이브러리 코드가 복사된 테이프에 실제 로직을 일일히 작성하고, 라이브러리 코드를 호출합니다.
4. EDSAC에 코드를 넣어서 실행시킵니다.

 

사실상 오늘 날의 코드에서 외부 라이브러리, 의존성을 import 해오고, 사용하는 방식과 논리적으로 다르지 않죠!

이후, 모리스와 윌크스는 책을 냈습니다.

바로

the preparation of programs for an electronic digital computer (AKA. WWG) 전자 디지털 컴퓨터를 위한 프로그램 준비

라는 책입니다.

1951년 출간된 이 책은 컴퓨터 프로그래밍을 다루는 최초의 책이자 이후 몇년간 유일한 프로그래밍 서적이었습니다.

윌러는 이 책을 비롯해서 이후 논문에서 아래와 같은 아이디어들을 제시했는데요.

• 서브루틴
• 서브루틴 라이브러리들
• 일반성 vs 성능 trade off (추상화와 성능 선택)
• 라이브러리 문서화의 어려움과 중요성
• 동적 디버거 ( 런타임 중에 디버깅 )
• 고차 함수 (함수를 인자로 받거나 반환하는 함수, 함수형 프로그래밍)

종이를 이어붙이고, 느리게 움직이는 수은관으로 프로그래밍을 하던
그 시절에 이 모든 현대적인 아이디어들을 떠올렸다는게 참 놀랍습니다

 

API의 독립

서브루틴 라이브러리를 만들어낸 윌크스와 모리스는 API 라는 개념을 따로 분리하지는 않았습니다.

왜냐하면,

• 컴퓨터가 하나였기때문에(EDSAC), 이식성이 필요없었고,
• 기존의 레거시 프로그램이 없었기때문에
  • 즉, 하위호환성이라는 개념이 필요 X

API 라는 개념 자체를 논의할 필요가 없었던 것입니다.

그러나 이후

• 새로운 기계가 만들어지고
• 새로운 알고리즘이 만들어지면서

기존의 인터페이스(API)를 재구현하면 성능 향상 이 가능해졌고, API와 라이브러리가 독립적인 생명력을 가지게 되었습니다.

 

 

API 라는 용어 자체는 1968년 Data structures and techniques for remote computer graphics 논문에서 처음 언급된 것으로 보여집니다.

그러나, 이 논문이 API 라는 개념 자체에 대해서 처음으로 떠올렸다고 보기는 어렵습니다.

논문에서는 하드웨어 독립성과 일관된 애플리케이션 프로그램 인터페이스의 중요성 을 강조했고 그 과정에서 API라는 용어가 돌출되었습니다. 이는 이미 그 당시 많은 개발자들이 인지하고 있던 내용이었고, 라이브러리의 사용에 대해서 필연적으로 수반되는 추상적인 개념이 API라는 발견으로 이어지게 된 것입니다.

 

API는 어떻게 구성되어있고 왜 중요할까?

Joshua Bloch 은

응용 소프트웨어를 만들기 위한 서브루틴 정의, 프로토콜, 도구들의 집합, 다양한 소프트웨어 컴포넌트 간의 명확히 정의된 소통 방식 - 위키피디아

에서 나아가

구현 방식과 독립적인 기능 집합을 정의 구현을 바꾸더라도 사용자는 영향을 받지 않게 하는 것

이라고 정의하고 있습니다.

또한, 아래 두가지 질문에 모두 YES 라는 대답을 할 수 있다면 API라고 할수 있습니다.

1. Does it provide a set of operations defined by their inputs and outputs? (입력과 출력으로 정의된 일련의 연산들을 제공하나요?)
2. Does it admit reimplementation without compromising its users?(기존 사용자의 사용에 지장을 주지 않고 다시 구현할 수 있나요?)

초기 API의 형태는 대표적으로 다음과 같은 사례들이 있습니다.

• 3.1. API의 역사와 다양한 형태
  • IBM S/360 인스트럭션 세트는 1964년에 출현하였으며, 이는 프로그래머들이 어셈블리 언어 프로그램을 IBM 컴퓨터와 통신하는 방법으로, api의 한 예로 볼 수 있다. [170]
  • C 표준 라이브러리는 1975년에 등장했으며, 이는 포트빌리티를 보장하는 api의 역할을 이해하고 있던 K&R의 C 책에서 다루어졌다. [177]
  • C 표준 라이브러리는 시스템 간의 상호작용을 수행하는 프로그램이 표준 라이브러리의 기능에 국한될 경우 변화 없이 다른 시스템으로 이동될 수 있음을 강조한다. [183]
  • **"Write once, run anywhere"**라는 개념은 api덕분에 프로그램을 변화 없이 다른 컴퓨터로 옮길 수 있다는 점에서 중요하다. [185]
  • UNIX 시스템 콜은 여러 유닉스 유사 운영 체제에 걸쳐 재구현되었으며, I/O 및 인터럽트와 같은 시스템 호출을 수행하는 데 사용된다. [188]
• 3.2. ️ 하드웨어와 API의 역사
  • 컴퓨터 터미널은 초기 컴퓨터와의 상호작용을 위해 사용되었으며, DEC VT100과 같은 스마트 터미널은 특별한 이스케이프 시퀀스를 통해 프로그램과 터미널 간의 통신을 가능하게 했다. [191]
  • IBM PC에서 프로그램은 저수준 하드웨어와의 상호작용을 위해 BIOS 호출을 사용해야 했으며, 이는 개방형 아키텍처의 정의를 따랐다. [197]
  • 명령어 기반 인터페이스(MS-DOS)는 일반적인 프로그래밍 언어의 메소드 호출과 유사한 기능을 할 수 있으며, 스크립팅 언어를 사용하여 api처럼 작동할 수 있다. [200]
  • 모뎀과의 상호작용은 ATDT와 같은 명령어로 이루어졌으며, 이는 오래 전부터 현재의 휴대전화에서도 여전히 활용되고 있다. [206]
  • 휴대전화의 두 개의 컴퓨터(주 컴퓨터와 베이스밴드) 간의 통신은 특정 코드(EDT 코드)로 이뤄지며, 이는 여러 번 재구현된 api의 예시이다. [208]
• 3.3. API의 정의와 발전
  • Adobe PostScript는 언어이자 api로, 애플의 매킨토시가 레이저 프린터와 통신하는 데 사용되었으며, 페이지를 인쇄할 내용을 설명하는 기능을 가지고 있다. [210]
  • api와 언어 간의 명확한 구분은 없으며, 일부 api는 언어를 담고 있다는 점에서 동일하다. [211]
  • SMB(서버 메시지 블록 프로토콜)는 파일 공유 및 인쇄를 위한 상부 통신 메커니즘으로, 전통적인 api와 같은 방식으로 프로그래밍하지는 않지만 통신을 가능하게 한다. [215]
  • 현대의 웹 api는 Delicious 같은 웹 서비스를 활용하여 다양한 프로그램을 구축하는데 사용되며, 초기 기기에서 현대 웹 애플리케이션에 이르기까지 여러 형태로 발전해왔다. [217]
  • api는 수명이나 형태가 다양하며, 시스템 내 구성 요소 간의 Operation 방법으로, 디지털 유니버스를 연결하는 접착제 역할을 한다. [228]