API

Application Programming Interface

응용 프로그램 프로그래밍 인터페이스. 프로그래밍에서, 프로그램을 작성하기 위한 일련의 부(sub)프로그램, 프로토콜 등을 정의하여 상호 작용을 하기 위한 인터페이스 사양을 말한다.

API는 흔히 function, method 또는 operation 등으로 다양하게 불리는 '소프트웨어 컴포넌트'의 기능, 입력, 출력, 그리고 이에 사용되는 자료형으로 표현된다. API 자체는 어디까지나 사양(specification)만을 정의하기 때문에 구현(implementation)과는 독립적이다. 이를 실제로 구현한 것은 '라이브러리(library)'라고 부른다. 잘 설계된 API는 프로그램 개발을 보다 쉽게 해준다. API는 다양한 형태로 존재하며, 유닉스의 POSIX 표준, 윈도우의 MFC나 Win32, C++의 표준 라이브러리, Java SE API 등이 이에 해당한다.

예를 들어 그래픽 카드나 디스크 드라이브 등의 하드웨어 또는 데이터베이스를 저레벨에서 직접 조작할 때, API는 작업을 편리하게 해준다. 컴퓨터 운영 체제에서 일련의 과정들은 밑바닥에서부터 매우 저수준으로 작업이 수행되는데, API는 이러한 작업들에 대한 기능을 대상이 되는 언어에 맞게 추상화하고 프로그래머가 사용하기 편리하게 해준다. 따라서 프로그래머는 C 언어나 어셈블리어같이 저단계 프로그래밍 언어에서나 할법한 메모리 조작이나 하드웨어 조작 등을 직접 할 필요 없이, API만을 가지고도 손쉽게 이를 고레벨 프로그래밍 언어에서도 제어할 수 있다.

라이브러리와 종종 헷갈리곤 하는데 엄밀히 말하면 서로 다르다. API는 소프트웨어 개발에서 호환성을 위해 지켜야 하는 추상적인 원칙이다. 라이브러리는 이러한 API들을 기반으로 개발자에게 기능을 제공할 수 있도록 실제 구현된 구현체다. API는 여러 기업과 개발자들이 서로의 프로그램이 호환되도록 합의한 원칙이다. 라이브러리는 실제 이를 바탕으로 구현된 결과물이다. 대개의 경우 독립된 응용 프로그램(application) 간의 상호 작용은 '이미 구현된 코드'의 재사용이기 때문에 라이브러리는 다시 쓰기 위해 미리 짜놓은 코드 뭉치들을 의미하는 것이고, API를 기반으로 구현되었다고 볼 수 있다.

프레임워크는 그것을 기반으로 명확하게 정의된 대량의 라이브러리가 있다는 점에서 API와 비슷하다. 하지만 일반적인 API는 전체 제어 구조를 호출하는 쪽에서 원하는 대로 진행할 수 있지만, 프레임워크는 특정 목적을 벗어나면 기능하지 않는다.

프로그램에 플러그인 형태로 설계된 API가 적용되면, 이미 작성되어 컴파일되고 완성된 프로그램의 수정 없이 프로그램의 기능을 추가하는 것이 가능하다. Internet Explorer, 파이어폭스, 크롬과 같은 웹 브라우저 프로그램의 플러그인, 애드온과 같은 것이 바로 이러한 형식의 플러그인 API를 사용해 구현된 것이다.

API가 실제 기능 구현체인 라이브러리와 함께 제공되는 경우도 있으며, 이 경우를 SDK(Software Development Kit)라고 한다. SDK는 일반적으로 API, 라이브러리와 함께 프로그램을 개발하는 데 필요한 여러 보조 프로그램을 포함한다.

한마디로, API는 소스 코드 수준에서 정의되는 인터페이스라고 할 수 있다. 이와는 달리, 기계어 이진 바이너리 수준에서 정의되는 인터페이스는 ABI(Application Binary Interface)라고 한다.

예를 들어 명령어 창[1]에 "Hello, world!"라는 문자열을 출력하는 프로그램을 C 언어로 작성한다고 하자. 당연히 텍스트로 출력하는 printf API를 사용하여 printf("Hello, World!");라고 작성하게 될 것이며, 이는 윈도우, 리눅스, 유닉스, OS X 모두에서 동일하게 동작하도록 C 언어 API가 보장해 준다. 이 'printf'라는 것은 API를 기반으로 설계된 문법이며 이런 것들이 여러 개 쌓여 '라이브러리'가 된다. 물론 printf 같은 기본적인 것들은 다 기본적으로 탑재되어 있기 때문에 따로 이것을 '라이브러리'라고 부르진 않지만 좀 더 나아가면 운영 체제의 종류나 버전을 출력한다든가 파일의 데이터를 읽어 오는 등의 행동에는 별도의 라이브러리를 호출할 필요가 있다.

API가 없다면 프로그래머는 보다 저수준으로 내려가 실제로 명령어 창에 'Hello, world!'를 띄우기 위해 컴퓨터 메모리를 직접 건드려야 한다. 메모리 영역부터 내려가 H부터 느낌표까지 문자열 하나하나 문자열 구조체를 만들어 담고, 이를 출력하도록 운영 체제에 명령을 보내야 한다. 운영 체제마다 그것을 표시하는 방식이 다른 것은 물론이다. 하지만 API가 있기 때문에 이미 프로그래밍 언어에 정의된 'printf'를 사용하기만 하면 편리하게 텍스트를 출력할 수 있다. 즉 잘 설계된 '프로그래밍 인터페이스'를 사용하면 환경(플랫폼)이 달라져도 동일한 코드가 동일한 결과를 수행하며, 보다 편리하게 프로그래밍을 할 수 있다. 이것이 바로 API의 존재 목적이다.

유닉스는 애초에 C 언어로 개발되었기 때문에, 당연히 C 언어를 위한 API가 기본으로 제공된다. MS-DOS는 그렇지 않았기 때문에 특정 언어를 위한 API 같은 것은 없었고, 기계어(또는 어셈블리어) 수준에서 소프트웨어 인터럽트를 제공했다. MS-DOS의 이러한 방식을 지금의 관점에서 보면, ABI를 정의한 것으로 볼 수 있다.

Java를 기준으로 설명하자면, 기본적인 프로그래밍을 위한 'java.lang', 파일 입출력 및 키보드 마우스 등을 관리하는 'java.io'나 그 외에도 'java.net', 'java.util' 등이 대표적인 API들이다. 자바 기본 API 문서 즉, API를 통해 어느 환경에서 JVM을 실행하더라도 통일된 메서드를 사용하여 동일한 실행 결과를 보장하는 것이다.

프로그래밍 언어 혹은 운영 체제마다 기본으로 제공되는 API 말고도 기업들이 운영 중인 여러 API들이 많다. 전자의 요소들이 '프로그램과 운영 체제 간의 상호 작용'을 위한 프로토콜이라면, 기업에서 제공하는 API들은 대개의 경우 '기업의 서버와 개발자 본인의 프로그램 간의 상호 작용'을 위한 프로토콜을 의미하는 경우가 많다. 단, 웹에서 데이터를 전송하기 위한 목적으로 사용되는 'REST API'와는 다르며, 일반인은 물론이고 현직 개발자들도 서로 종종 혼동하기 때문에 주의.

기업들이 API를 운용하는 이유는 다음과 같다. 복잡한 프로그램일수록 개발자가 개발하는 프로그램은 그 프로그램 단독으로 돌아가는 경우가 많지 않으며 이미 개발되어 있는 무수한 여러 애플리케이션들과 소통하는 경우가 태반이다. 하지만 소통한답시고 기업들이 애플리케이션의 기반 코드와 자체 보유 데이터에 누구나 접근할 수 있도록 열어버리면 난리가 날 것이다.[2] 따라서 각 기업들은 개발자가 개발한 프로그램의 코드를 작동함에 있어 자체 애플리케이션과 실시간으로 상호 작용할 내용이 있다면 이를 위해 '소통 창구'라 할 수 있는 자체 API를 만들어 배포하는 것이다.

예를 들어, 자신이 개발자이고 이용자가 휴대폰으로 촬영한 영상을 유튜브에 업로드하고 카카오 지도에 촬영한 장소를 기록할 수 있는 앱을 만든다고 가정해 보자. 이를 구현하기 위해선 이용자의 구글 계정과 비밀번호를 받아서 유튜브에 업로드할 수 있는 기능을 만들어야 할 것이고 카카오 지도와도 상호 작용이 필요할 것이다. 한데 일개 앱 개발자가 유튜브나 구글 서버 DB에 직접 접근할 수 있을 리가 만무하다. 그렇다고 구글 입장에서는 이러한 서드 파티 앱과 상호 작용을 원천 봉쇄하는 것도 애매하므로 무차별적인 접근을 막고 '적절한 상호 작용'을 위해 자체 개발 API를 배포하는 것이다.

따라서 개발자는 배포된 API를 받고 이를 자신의 코드에 추가함으로써 원하는 기능을 구현할 수 있다. 말하자면 운용 중인 애플리케이션에 적법한 절차를 걸쳐 허락을 맡고 구현물을 받아 오거나 새로운 요소를 삽입, 수정할 수 있는 것이다.

따라서 구글, 네이버, 카카오 등 많은 IT 회사들이 사내 제품군들의 API를 제공하여 개발 편의를 돕고 자사 제품을 쓰도록 유도하고 있다. 예를 들어 구글 유튜브 Data API를 보면 각 프로그래밍 언어별로 친절하게 동영상 업로드나 업데이터, 키워드별 검색, 재생 목록 만들기 등의 기능을 제공한다. 또 다른 예시로 카카오 지도 API를 보면 API를 통해 개발자는 카카오가 제공하는 함수를 써서 특정 경로를 찍거나, 해당 위치 주변의 지도를 개발물에 띄울 수 있고 이를 개발에 활용할 수 있다.

Representational State Transfer-ful API

API는 기본적으로 '프로그래밍 인터페이스'인 만큼, API를 사용하는 것은 주로 프로그램 내부 단에서 이루어진다. 하지만 보다 다양한 분야에 쓰일 수 있도록 '네트워크'와 '웹'에 맞춰진 API 통신 아키텍처가 등장했는데, 그것이 바로 REST다. REST 개념은 2000년에 로이 필딩(Roy Fielding)이 최초로 소개했는데, HTTP의 주요 저자로서 웹의 활용성을 보다 늘리기 위해 고안했다.

REST의 정확한 정의에 대해서는 해당 문서를 참조할 것.

다시 말해 REST란 그저 정의된 '아키텍처 스타일'로, 이는 API를 활용함에 있어서 그 API가 가져야할 디자인 철학, 혹은 미덕을 의미하며, 보다 비전공적으로 설명하자면 '필수 요소' 정도로 볼 수 있다. 엄밀히 따지면 REST는 모든 '네트워크'를 위한 것이므로 네트워크가 구성된 곳이라면 어느 곳이든 사용이 가능하지만 현실적으로 99.99%의 네트워크는 우리가 소위 '인터넷'이라고 부르는 HTTP 기반 네트워크이므로 REST API라고 하면 HTTP에 쓰이는걸 의미하는 경우가 많다.[3] 심지어 그냥 'API'라고 부르면 이 REST API를 의미하는 경우도 많아졌다.

REST를 잘 준수하는 API는 따로 'RESTful API'라고 부른다. 하지만 워낙 개념이 혼용되다 보니 일부 혹은 전체 요소가 전혀 'REST'하지 않아도 'RESTful API'라고 부르는 경우가 종종 있다. 엄밀히 따지면 틀린 것으로 REST 요소를 지키지 않은 HTTP API는 그냥 '웹 API'나 'HTTP API'로 불러야 한다.

프로그래밍에서 말하는 그냥 API와 뭐가 같고 뭐가 다른지 헷갈릴 수 있는데 둘 다 상호 작용을 위한 인터페이스라는 점에서는 동일하다. 운영 체제 혹은 다른 애플리케이션과 상호 작용하기 위해 정의된 약속을 쓰는 것이다. 예를 들어, 'printf'라는 함수를 호출해서 정해진 문자열을 출력하고, 'videos.insert'라는 메소드를 호출해서 유튜브에 영상을 추가하며, 'https://openapi.naver.com/v1/nid/me'라는 HTTP 주소를 호출해서 데이터를 전송받는 것이다.

차이점이라면 REST API는 네트워크에서 '데이터'를 받아 오기 위한 것이고 프로그램에서의 API는 '코드', 나아가 코드 뭉치인 라이브러리를 받아 오기 위해 쓰는 것이다. 따라서 개발자 입장에서 구분하자면 HTTPRequest를 보내서 JSON 또는 XML 형식으로 데이터 묶음이 온다면 보통 'REST API'[4]라고 보면 되고, 그게 아니고 기업에서 설명하는 방식대로 자신의 코드에 import하여 특정 함수나 메소드를 쓸 수 있다면 코드에 빨간 줄이 그이지 않는다면 일반적인 의미의 API라고 보면 된다.

또한 REST 구조는 자체 표현 구조를 지녀야 하며, 이는 달리 말하면 '텍스트'만 오가야 한다는 것을 의미한다. 이미지나 동영상을 주고받고 싶다면 그 데이터 파일 자체를 보내는 것이 아니라 이미지 또는 동영상이 보관되어 있는 주소가 오는 것이다.

사실상 개발자가 아니면 사용할 일이 없는 일반적인 의미의 API와는 달리 REST API는 웹이라는 비교적 친숙한 도구를 매개체로 이용하며 결과물도 단순 텍스트다 보니 좀 더 광범위하게 사용되는 편이다. 앞서 언급한 IT 회사들도 단순 데이터 열람을 위해 REST API를 제공하는 경우가 많으며, 여러 데이터 열람을 위한 공공 OpenAPI나 게임 회사에서 제공하는 유저 전적, 승률, 게임 내 각종 기록들도 다 REST API로 오간다.

소스 코드 단계에서 상호 작용하는 일반 API와 달리 RESTful API는 웹을 이용하므로 거의 대부분 웹 프로토콜을 통해 주고받는다. 다시 말해, GET/POST 등의 형태로 필요한 인수를 전달받으면 거기에 맞는 결괏값을 JSON이나 XML 형태로 전송해 준다. 이를 그대로 봐도 되긴 하지만 비전문가가 보면 알 수 없는 텍스트들의 나열로 보이기 때문에 보기 이쁜 형태로 데이터를 적당히 편집하여 보기 좋은 형태로 만드는 것이 개발자의 역할이다.

게이머라면 '전적 검색 사이트'나 '로그 조회 사이트'를 떠올리면 이해하기 쉽다. OP.GG나 Maple.gg 같은 사이트들이 바로 게임사가 제공하는 외부 API를 기반으로 돌아가는 사이트다.