API

내위키
(웹 API에서 넘어옴)

Application Programming Internface의 약자.

다른 프로그램이 어떤 운영체제, 라이브러리, 서버의 정보나 기능을 사용할 수 있도록 그 방법을 표준화한 인터페이스를 뜻한다. 원래는 운영체제가 그 위에 돌아가는 프로그램이 운영체제의 기능과 정보에 접근하는 인터페이스를 뜻하는 용어로 주로 쓰였지만 요즈음 인터넷 서버 또는 웹사이트가 다른 프로그램이 기능이나 정보를 사용할 수 있도록 접근하는 인터페이스를 뜻하는 용어로도 많이 쓰이고 있다.

운영체제 API

아예 운영체제를 직접 만들 게 아니면 거의 모든 프로그램은 운영체제라는 건물 안에 세들어 사는 신세이고, 그 건물 안에서 생활하기 위해서는 현관문은 어떻게 열고, 엘리베이터는 어디에 있고, 관리비는 어떻게 내고, 등등 여러 가지 생활 정보를 알아야 한다. 이런 것들은 운영체제가 일종의 매뉴얼로 제공해야 한다. 물론 세들어 사는 프로그램의 처지에서 보면 아주 많은 부분을 운영체제가 알아서 처리해 주므로 어마어마한 수고를 덜 수 있다.

예를 들어 아파트의 현관문을 열 때, 집 아이콘 버튼 + 3자리 호실 번호 + 4자리 비밀번호 + 종 아이콘 버튼을 눌러야 한다면 이는 하나의 인터페이스다. 만약 자바스크립트의 함수 형태로 바꾸어 보자면,

Boolean openDoor(int roomNumber, int password);

이렇게 될 것이다. 집 아이콘 버튼과 종 아이콘 버튼은 모든 경우에 눌러야 하므로 openDoor() 함수를 부르는 것이나 마찬가지고, 매개변수로 호실 번호(roonNumber)와 비밀번호(password)를 넘겨준다.[1] 그려면 openDoor() 함수는 Boolean 값을 돌려주는데, true면 문이 열릴 것이고, false면 삑 소리와 함께 문이 열리지 않을 것이다. 호실 번호와 비밀번호를 인식해서 데이터베이스 저장되어 있는 암호와 대조하고, 맞을 경우에 기계 장치를 작동시켜서 문울 열어주고, 틀렸으면 삑 소리를 내는 동작은 모두 아파트의 보안 시스템이 알아서 해 준다. 우리는 그냥 정해진 인터페이스를 통해 호실 번호와 비밀번호만 전달해 주면 되며, 그에 따른 결과를 받는다. 이것이 API라고 할 수 있다.

특히 컴퓨터는 여러 가지 하드웨어가 조립된 구조물의 형태고, 각 요소는 다를 수 있다. CPU도 인텔 혹은 AMD일 수 있고, 그래픽 카드는 NVIDIA, AMD, 인텔 등 여러 가지 회사가 있다. 프로그램이 이런 하드웨어를 직접 다뤄야 한다면 하드웨어에 따른 컨트롤 방법 차이를 몽땅 감안해야 한다. 예를 들어 윈도우가 나오기전 DOS 시절에는 운영체제가 그래픽 카드를 조작하기 위한 표준화된 API를 제공하지 않았기 때문에 그래픽 기능을 쓰려면 응용프로그램이 시중에서 쓰이는 여러 그래픽 카드 종류 각각에 맞춰 그래픽을 출력하는 코드를 집어 넣어야 했다. 반면 운영체제가 하드웨어에 관계 없이 표준화된 API를 제공하면[2] 프로그래머의 수고를 어마어마하게 줄일 수 있다.

실제로 MS-DOS 시절에 게임을 만들 때에는 인터럽트라는 방법을 이용해서 하드웨어를 직접 컨트롤해야 했다. 이것도 하나의 API에 해당하지만 그래픽 카드가 다르면 컨트롤하는 방법도 다르기 때문에 이런 걸 일일이 다 감안해야 했다.[3] 윈도우는 그래픽 하드웨어의 종류에 관계 없는 일관된 API를 제공하는 GDI가 있었지만 속도가 너무 느려서 게임에서 쓰기 어려웠다. 이후 고속 컨트롤 API인 DirectX가 제공되면서 그래픽 처리에 관한 수고는 눈물날 정도로 줄어들었다.[4] 운영체제에서 제공하는 API는 보통 명령어 또는 함수 형태로 제공되므로 프로그램은 이들을 호출하면서 적절한 매개변수를 제공함으로써 원하는 기능을 수행하거나 정보를 주고받을 수 있다.

MS-DOS가 제공하는 각종 파일 및 디스크 조작 기능을 좀 더 저수준으로 활용할 때에도 인터럽트 21이라는 기능을 썼으며 실질적인 MS-DOS의 API라 할 수 있다. 그런데 이걸 까딱 잘못 쓰면 프로그램 오류는 기본이고 파일이나 심지어 디스크 전체를 날려먹을 수도 있을 만큼 위험성이 컸다. 지금은 파일이나 디렉터리를 지우는 일은 있을 수 있지만 디스크까지 홀랑 날려먹을 가능성은 매우 적다. 무엇보다도 인터럽트는 숫자의 조합으로 명령을 구성하므로 숫자 하나만 잘못 써도 그런 일이 벌어질 수 있지만 윈도우 API는 함수의 이름으로 명령을 구별하기 때문에 그런 위험성은 적다.

플랫폼 API

자바와 같이 여러 운영체제에서 굴러가는 가상머신을 기반으로 한 앱은 자바가 제공해 주는 API로 프로그래밍해서 여러 운영체제에서 돌릴 수 있다. 크롬이나 파이어폭스 같은 웹 브라우저는 단순 웹 서핑을 넘어서 갖가지 작업을 처리할 수 있는 플랫폼으로 성장했으며, 브라우저의 기능을 확장시켜 주는 갖가지 확장 프로그램도 만들 수 있다. 예를 들어 웹 페이지에 뜨는 광고를 선택적으로 차단해 준다든가, 단어를 클릭하면 사전을 띄워준다든가, 유튜브 동영상을 다운로드할 수 있다든가,[5] 하는 기능들은 웹 브라우저가 제공해 주는 확장 프로그램 API를 사용해서 프로그래밍한다. 또한 어도비 포토샵의 커스텀 필터라든가, 프리미어 프로의 각종 서드파티 플러그인라든가, 이런 것들도 각 프로그램이 제공해 주는 API를 사용해서 만드는데, 이들 프로그램은 웬만하면 윈도우와 맥OS는 기본으로 지원하므로 역시 운영체제에 독립된 형태가 된다.

웹 API

최근에는 인터넷을 통해서 정보를 주고받는 게 거의 기본이 되다 보니 네트워크를 통해 서버와 클라이언트가 정보를 주고받는 인터페이스로서 API가 대단히 중요해졌다. 이를 원격 API라고 하는데 특히 요즘은 웹을 통해서 정보를 주고받는 웹 API의 중요성이 아주아주 커졌다. 특히 모바일 쪽에서는 이걸 안 쓰는 앱이 거의 없을 정도다. 당장에 우리가 많이 사용하는 날씨 앱의 경우에도 날씨 정보를 제공하는 웹 서버로부터 API를 통해 정보를 받아온다. 공공 데이터도 웹 API로 개방되는 추세다. 아예 정부가 운영하는 공공데이터포털도 있다.

API를 제공하는 측에서 지정한 방식에 따라 URL로 요청하는 데이터의 종류와 변수를 넘겨주면, 데이터가 JSON 방식으로 돌아온다. 거의 대부분의 API는 무료라고 해도 등록을 하고 키를 받아와야 한다. 그냥 열어 놓으면 DDOS 같은 사이버 공격의 대상이 되기도 쉽고, 쓸데 없는 요청도 많이 들어오기 때문에 제한은 걸어둘 필요가 있다.

워낙에 많이도 활용하고, 또 웹 API를 활용하는 프로그래밍의 기본에 가깝다 보니 대부분 모바일 앱 프로그래밍 교재에는 약방의 감초처럼 들어간다. 웹 API는 REST로 표준화되는 경향을 보이고 있었으나 GraphQL이라는 강력한 도전자가 나타나서 치열한 경쟁구도에 접어들고 있다.

각주

  1. 두 매개변수는 각각 3자리와 4자리 숫자인데 int를 안 쓰고 String을 쓴 이유는, 예를 들어 비밀번호가 0000라면 password가 int일 경우 0 하나만 입력하든 0000을 입력하든 password는 똑같이 0이다. 데이터베이스에 저장된 값과 대조하는 것은 문제가 없지만 0을 한 번만 눌러도 문이 열리게 하는 것은 별로 좋은 것은 아니므로 정확히 3자리, 4자리의 숫자를 입력했는지 판단하기 위해서 String으로 값을 받는다. 그 전에 비밀번호를 0000으로 설정해 놓는 멍청이가 있어서는 안 되겠다.
  2. 같은 유형에 속하는 개별 하드웨어는 드라이버를 통해 운영체제가 하드웨어를 제어할 수 있는 인터페이스를 제공하고, 운영체제는 API를 제공하여 같은 유형에 속하는 하드웨어를 제품에 관계 없이 제어할 수 있다.
  3. 이 때는 앱을 만드는 회사마다 자체적으로 당시에 널리 쓰이는 그래픽 카드의 드라이버를 만들고, 그 드라이버를 앱에 물려서 쓰는 경우가 대다수였다. 회사마다 각자 그래픽 카드 드라이버를 만들어야 했으니 버그 대잔치는 말할 것도 없었다.
  4. 한편 MS는 이를 통해 윈도우 지원 게임이 왕창 늘어난 것을 바탕 삼아 비디오 게임기 Xbox를 만들었다.
  5. 유튜브 동영상 다운로드 기능은 구글이 만드는 크롬에서는 웹 스토어에 올라오지 못하도록 막지만 파이어폭스는 그런 거 신경 안 쓴다.