“API는 기업의 데이터에 접근하고 싶어하는 해커들에게 새로운 기회들을 제공하기도 한다”고 말한다. “보안 리스크를 없애고 고객과 기업들을 성공적으로 지켜내려면 API를 사업에 꼭 필요한 웹 애플리케이션들을 보호하듯 보호해야 합니다.”
API가 수익원으로서 잠재력이 큰 이유는 여러 플랫폼과 애플리케이션과의 연동을 통해 새로운 사업 모델을 빠르게 구현하거나 기존 사업 모델을 순식간에 확장시킬 수 있게 해주기 때문
소프트웨어의 개발 및 구축 방법론부터 새롭게 바뀌고 있다. 발 빠른 출시와 가벼움이 소프트웨어 산업의 필수 덕목으로 자리 잡음에 따라 기존의 덩치 큰 코드들은 독립적인 작은 단위로 분해되기 시작했다. 이 작은 단위를 마이크로서비스라고 부른다. 요즘 개발 업체들은 이런 마이크로서비스를 벽돌처럼 사용해 애플리케이션을 만든다. 그래서 버그를 고치거나 오류를 잡다가 실수로 코드 전체에 영향을 주는 행위도 막아진다. 이 마이크로서비스들끼리 붙여주고 연결시켜주는 것이 API의 역할이다.
웹 애플리케이션 방화벽을 API 보호하는 데에 같이 활용하고 있다고 답한 조직은 63%였다. 비슷한 비율의 조직들이 API 게이트웨이를 사용하고 있다고 답하기도 했다. 하지만 런타임 애플리케이션 셀프 프로텍션(runtime application self-protection, RASP)을 사용해 공격을 막는다는 조직은 절반도 되지 않았다.
“웹 API를 노출시키고 있는 곳이라면 접근의 용이성과 접근의 통제 사이의 균형을 맞추는 것이 지상 과제입니다.
API는 어플리케이션을 만들기 위한 하위 함수, 프로토콜, 도구들의 집합들을 말한다. 즉 명확하게 정의된 다양한 컴포넌트들간의 통신 방법이다.
가. library와 framework
API는 Software Library 와 관계가 있다. library 가 실제 구현이라면, API 는 예상되어지는 행동들이다. (예 : copy API와 copy library) API 는 implementation 와 한덩어리로 구현될 수 있다. 그래서 API 모습은 같아도 서로 다른 library 를 가지고 있을 수도 있다. API 를 implementation 과 분리하는 것은 다른 언어로 개발된 기능을 내 소스코드 내에서 쓸 수 있다는 것을 의미한다. 예를 들면 Scala 와 Java 는 바이트코드가 호환되기 때문에 Scala 개발자들은 Java API를 쉽게 이용할 수 있다.
API 사용법이 구현된 언어에 따라 다를 수 있다. 예를 들어 절차형 언어인 Lua 로 개발된 경우 코드 실행, 데이터 처리, 에러 핸들링 기능으로 구성되어 있다면, Java API 는 여러 개의 class 등과 그 method로 구성되어 있다. 따라서 호출방법과 사용방법이 달라진다.
언어 연결도 API의 영역이다. SWIG 을 F2PY로, Fortran 을 Python으로 연결하는 역할을 API로 할 수 있다.
API 는 software framework 과도 관계가 있다. framework 이란 다수의 API 를 실행하는 여러 개의 library 로 구성되어 있다. 그런데 framework 은 일반적인 API 사용법과는 달리 새로운 class 를 추가함으로써 그 기능을 사용할 수 있다. 그리고 전체적인 통제가 호출자가 아닌 프레임의 손에 있다는 것이 다르다.
나. 운영체제
API 는 어플리케이션과 운영체제를 연결해주기도 한다. 예를 들어 POSIX 는 어플리케이션이 운영체제들과 통신하기 위한 공통 API 규격들을 제공하고 있다. 이를 구현한 대표적인 사례로 Linux 와 버클리 재단이 있다..
MS 도 호환 API 의 대표 주자이다. 비록 윈도우에 한정되어서지만, 그들은 API 를 이용해서 거의 완벽하게 하위 호환성을 지원하고 있기 때문이다.
그런데, API 는 소스코드를 제공한다는 측면에서 ABI (binary) 와는 차이가 있다. 예를 들어 POSIX 는 API 이지만, Linux 는 ABI 라고 할 수 있다.
다. 리모트 API
리모트 API 는 개발자들이 프로토콜을 이용하여 원격지에 있는 자원을 활용할 수 있게 한다. 그래서 서로 다른 기술들이 함께 동작할 수 있도록 도와준다. 예를 들면 Java DB connection API 가 그렇다. 이 API 는 개발자들이 하나의 function으로 다양한 Database 들을 사용할 수 있도록 도와준다. 그래서 remote API 는 객체지향 프로그래밍에서 객체 추상화를 유지하기에 매우 유용하다. 원격지의 변경에도 내부 코드들이 변경될 필요가 없어진다.
라. Web API
Web API 는 전체 시스템과 그 리소스를 사용하는 어플리케이션 간의 연결시키는 인터페이스이다. API 설계는 서로 다른 고객들을 가진 두 개 이상의 서비스를 연결해야 할 때 매우 필요하다. 웹 분야에 서 API 는 단순히 http 프로토콜, XML, JSON 규격처럼 정의되어 있다.
Web API 가 웹 서비스와 거의 동급으로 불리는 반면, 최근의 트렌드는 SOA 기반의 SOAP 프로토콜이, ROA 기반의 REST 프로토콜로 옮겨가고 있다. 이런 움직임의 일부는 시맨틱 웹 운동이나 온톨로지 기술과도 관계가 있다. Web API 는 여러 개의 조합을 통해 매쉬업 어플리케이션이 가능하게 만들어 주기 때문이다. 그리고, 소셜 공간에서는 웹 커뮤니티들이 쉽게 컨텐츠를 공유할 수 있게 만들어 준다. 그래서 점점 더 웹이 다양하고 복잡해질 수 있게 한다.
04. 설계
API 의 설계는 ‘사용성’에 큰 영향을 끼친다. 특히 ‘정보 은닉’ 원칙은 모듈화 도구로서의 API 역할을 기술하고 있기도 하다. 모듈화란 모듈 내의 복잡성을 사용자가 이해할 필요가 없다는 뜻이다. 그래서 API 를 설계할 때는 사용자가 해당 모듈에 기대하는 기능만 포함하는 것이 좋다.
전체적인 프로그래밍 인터페이스 설계는 소프트웨어 아키텍쳐의 가장 중요한 부분과 복합적인 부분을 대표한다고도 볼 수 있다.
05. API 정책
API 는 기술기업이 다른 기업들을 통합하는 가장 일반적인 방법 중의 하나이다. API 를 제공하고 사용하는 기업들은 비즈니스 생태계의 구성원이 된다는 뜻이다.
API 를 배포하는 정책들은 다음과 같다.
Private : 회사 내부에서만 사용되는 경우
Partner : 지정된 회사만 API 를 사용할 수 있다. 예를 들면 Uber와 Lyft 는 3rd Party 개발자들이 바로 주문을 내릴 수 있도록 API 를 개방했는데, 이것이 새로운 수익 흐름을 만들어 주었다.
Public : 모든 사람들이 사용할 수 있도록 오픈된다.
06. Public API의 의미
Public API 가 될 때 가장 중요한 것은 ‘인터페이스 안정성’이다. 파라미터 하나를 추가하는 것 조차도 기존 고객들의 시스템을 파괴해 버릴 수 있다. 그래서 Public API 로 배포되는 경우 아직 개발 중이라면 unstable(불안정) 할 수 있다고 반드시 표시를 해 주어야 한다. (또는 베타라고)
간혹 Public API 중에는 일부 기능이 deprecated 되었다고 나온다. 이것은 이 기능이 곧 제거될 예정이고 더 이상 하위호환성을 지원하지 않는다는 것을 말해준다. 그래서 개발자들이 그 API 를 제거하거나 다른 기능으로 갈아타라는 뜻이다.
07. 저작권 논란
2010년 오라클이 구글을 대상으로 ‘안드로이드가 Java API 를 도용했다고’고 고소를 했다. (즉 Java API 명칭은 그대로 쓰고 소스코드를 안드로이드에 맞게 고친 것.) 구글은 OpenJDK 프로젝트에 대해 비슷한 권리를 얻기는 했지만 Java API 에 대한 권리를 얻은 것은 전혀 없었다.
담당 판사였던 윌리엄은 API 는 미국 내에서는 저작권이 인정될 수 없으며 오라클이 저작권 보호를 과대 해석했다고 판결을 내렸다. 그리고 단지 소프트웨어 명령어에 대한 저작권만을 인정했다.
판결문 : 오라클의 항소를 받아들이면 사람들이 시스템 명령어를 실행하기 위해 딱 그 버전만을 사용해야 한다는 것이 된다. 즉 같은 명령어를 실행하기 위해 다른 버전을 사용할 수 없다는 뜻이다.
그런데 2014년 항소심에서 윌리엄의 판결이 뒤집혔다. 2016년 또다시 그 판결이 뒤집혔는데, 오라클은 다시 항소할 뜻을 밝혔다.
