API 개념, 기능, 장점
1. API란
API는 애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로, 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 나타낸다.
API를 사용하면 구현 방식을 알지 못해도 제품 또는 서비스가 서로 커뮤니케이션할 수 있으며 애플리케이션 개발을 간소화하여 시간과 비용을 절약할 수 있다. 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리하는 경우 API는 유연성을 제공하고 설계, 관리, 사용 방법을 간소화하며 혁신의 기회를 제공한다.
API는 당사자들 간 계약을 나타내는 도큐멘테이션을 갖춘 계약으로 비유되기도 한다. 한쪽 당사자가 특정한 방식으로 구성된 원격 요청을 보내면 다른 쪽 당사자의 소프트웨어가 이에 응답하는 방식이기 때문이다.
API는 개발자가 새로운 애플리케이션 구성 요소를 기존 아키텍처에 통합하는 방식을 간소화하므로 비즈니스 팀과 IT팀 간의 협업에도 도움이 된다. 디지털 시장은 새로운 경쟁 기업이 새로운 애플리케이션과 함께 등장하여 업계 전체의 판도를 바꾸기도 하는 등 끊임없이 변화할 수밖에 없으므로, 이에 대응해 비즈니스 요구사항도 빠르게 변화하는 경우가 많다. 따라서 경쟁력을 유지하려면 혁신적인 서비스를 신속하게 개발하고 배포하도록 지원해야 한다. 클라우드 네이티브 애플리케이션 개발은 개발 속도를 높이기 위한 식별 가능한 방식이며, API를 통한 마이크로서비스 애플리케이션 아키텍처 연결에 기반한다.
API는 클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방식이지만, 고객 및 다른 외부 사용자와의 데이터 공유를 허용하기도 한다. 퍼블릭 API는 파트너와의 연결 방식을 간소화하고 확대할 수 있을 뿐만 아니라 보유한 데이터를 활용해 수익을 창출할 수 있기 때문에 고유의 비즈니스 가치를 지닌다(예: Google Maps API).
도서를 유통하는 회사를 한 예로 들어보겠다. 이 도서 유통업체에서 고객에게 애플리케이션을 제공하여 서점 직원이 유통업체의 도서 재고를 확인하도록 할 수도 있지만, 애플리케이션을 개발하는데 많은 비용과 시간이 들고 플랫폼의 제약을 받을 수 있으며 지속적인 유지관리가 필요할 것이다.
그 대안이 바로 재고 확인용 API를 제공하는 것이다. 이 접근 방식에는 다음과 같은 여러 가지 이점이 있다.
고객이 API를 통해 데이터에 액세스할 수 있으므로 한곳에서 재고 정보를 통합할 수 있다.
API 작동에 변화가 없는 한, 도서 유통업체는 고객에게 영향을 미치지 않고 내부 시스템을 변경할 수 있다.
도서 유통업체의 개발자, 도서 판매자 또는 제3자가 공개적으로 제공되는 API를 이용하여 고객이 원하는 도서를 찾도록 도와주는 애플리케이션을 개발할 수 있으며 이는 매출을 늘리거나 기타 비즈니스 기회를 창출할 수 있다.
간단히 말해서, API는 리소스에 대한 액세스 권한을 제공하고 보안과 제어를 유지할 수 있게 해주며 액세스 권한을 어떻게, 누구에게 제공할지 여부만 결정하면 된다.
API 보안이란 결국 API를 잘 관리하는 것을 의미합니다. API에 연결하고 API에 노출된 데이터 또는 기능을 사용하는 애플리케이션을 생성하는 것은 레거시 시스템과 IoT(사물 인터넷)를 비롯하여 어떤 환경이든 연결하는 분산형 통합 플랫폼을 통해 수행할 수 있다.
API 릴리스 정책은 다음과 같은 세 가지 접근 방식을 취한다.
프라이빗(Private): API를 내부에서만 사용할 수 있도록 하며, 기업이 API를 최대한으로 제어할 수 있다.
파트너(Partner): API를 특정 비즈니스 파트너와 공유하며, 품질 저하 없이 추가 수익원을 창출할 수 있다.
퍼블릭(Public): API가 모두에게 제공되며, 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 끌어낼 수 있다
2. API를 통한 혁신
파트너 또는 일반 사용자에게 API를 공개하면 다음과 같은 이점을 얻을 수 있다.
새로운 수익 채널을 확보하거나 기존 수익 채널을 확장한다.
브랜드 인지도를 확대한다.
외부 개발을 활용하고 협업을 수행하여 오픈 혁신을 촉진하거나 효율성을 높인다.
1) API 성과 실현
도서 유통업체의 예를 들면, 이 회사의 한 파트너가 서점에서 원하는 도서를 쉽게 찾을 수 있는 애플리케이션을 개발한다고 가정해 보겠다. 이렇게 고객 환경을 개선하면 더 많은 손님이 서점을 찾을 것이고 기존의 수익 채널이 확대되는 효과를 얻게 된다.
제 3자가 퍼블릭 API를 사용하여 매장이 아니라 유통업체로부터 직접 도서를 구입하는 애플리케이션을 개발할 수도 있으며 이는 도서 유통업체에게 새로운 수익 채널을 열어 준다.
특정 파트너 또는 전 세계 사람들과 API를 공유하면 긍정적인 효과를 가져올 수 있으며 각각의 파트너십을 통해 브랜드 인지도 측면에서 회사 자체의 마케팅 활동을 넘어서는 성과를 거둘 수 있다. 퍼블릭 API처럼 기술을 모든 사람에게 공개하면 개발자가 API를 사용하여 애플리케이션의 에코시스템을 구축할 수 있다. 더 많은 사람들이 기술을 사용할수록 비즈니스를 함께할 사람도 늘어나게 된다.
기술을 대중에게 공개함으로써 예기치 않은 결과가 발생할 수도 있으며 이 결과가 전체 산업을 와해시키기도 한다. 앞서 예를 든 도서 유통업체의 경우 도서 대여 서비스를 제공하는 새로운 기업이 나타나 비즈니스 방식을 근본적으로 바꿀 수 있으며, 파트너 그리고 퍼블릭 API를 통해서는 내부 개발자 팀보다 규모가 큰 커뮤니티에서 발휘되는 창의력을 활용할 수 있다. 새로운 아이디어는 어디서든 나올 수 있으며 기업은 시장의 변화를 인지하고 적절히 대응할 준비를 갖춰야 한다. 바로 여기서 API가 큰 도움이 될 수 있다.
3. API의 역사
API는 개인용 컴퓨터가 나오기 훨씬 전인 컴퓨팅 초기에 등장했으며 대개 운영 체제의 라이브러리로 사용되었다. 메인프레임 간에 메시지를 전달하는 경우도 있었지만 거의 항상 시스템에서 로컬로 작동했다.
약 30년이 지난 후에야 API는 로컬 환경에서 분리되었으며 2000년대 초반에는 데이터의 원격 통합을 위한 주요 기술이 되었다.
4. 원격 API
원격 API는 커뮤니케이션 네트워크를 통해 상호 작용하도록 설계되었다. 여기서 ‘원격’이란 API에 의해 조작되는 리소스가 요청을 보내는 컴퓨터의 외부에 있음을 의미한다. 가장 광범위하게 사용되는 커뮤니케이션 네트워크가 인터넷이기 때문에 대부분의 API는 웹 표준을 기반으로 설계되며, 모든 원격 API가 웹 API인 것은 아니지만 웹 API가 원격이라고 가정할 수는 있다.
웹 API는 일반적으로 요청 메시지에 HTTP를 사용하여 응답 메시지 구조의 정의를 제공한다. 이러한 응답 메시지는 일반적으로 XML 또는 JSON 파일의 형태이다. 다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML과 JSON 둘 다 자주 사용된다.
5. API 구현 방법
API가 유비쿼터스형 웹 API로 발전하면서 설계 편의성과 구현 유용성을 높이기 위한 노력이 다각도로 이루어지고 있다.
1) SOAP 감소, REST API 증가
웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신한다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있다.
또 다른 사양은 REST(Representational State Transfer)로, REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라고 한다. SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없다.
Roy Fielding의 논문인 ‘네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)’에 정의된 것처럼 RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있다.
클라이언트 서버 아키텍처: REST 아키텍처가 클라이언트, 서버, 리소스로 구성되며 HTTP를 통해 요청을 처리한다.
스테이트리스: 요청이 통과하는 서버에는 클라이언트 콘텐츠가 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장된다.
캐시 가능성: 캐싱으로 일부 클라이언트-서버 간의 상호 작용이 제거된다.
계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있다.
코드 온디맨드(옵션): 서버가 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있다.
통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함한다.
- 요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리됩니다.
- 표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.
- 자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
- 애플리케이션 상태 엔진으로서의 하이퍼미디어: 리소스를 할당한 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 찾을 수 있어야 합니다.
제약 조건이 많아 보이지만 규정된 프로토콜보다는 훨씬 간단하다. 이 때문에 RESTful API가 SOAP보다 더 많이 사용되고 있다.
최근 몇 년간 OpenAPI 사양은 REST API를 정의하는 공통 표준으로 부상했다. OpenAPI는 언어 독립적인 방식으로 개발자들이 REST API 인터페이스를 구축하여 사용자가 별다른 추측 없이도 이를 사용할 수 있도록 한다.
6. SOA와 마이크로서비스 아키텍처 비교
원격 API를 가장 많이 사용하는 두 가지 아키텍처 접근 방식은 SOA(Service-Oriented Architecture)와 마이크로서비스 아키텍처이다. 이 두 가지 접근 방식 중에서 더 일찍 개발된 SOA의 초기 모습은 모놀리식(Monolithic) 애플리케이션을 개선한 것이었다. 하나의 모놀리식 애플리케이션이 모든 작업을 수행하지만 일부 기능은 ESB(엔터프라이즈 서비스 버스)와 같은 통합 패턴을 통해 느슨하게 연결된 다른 애플리케이션에서 제공될 수 있다.
SOA는 모든 면에서 모놀리식 아키텍처보다 단순하지만 구성 요소의 상호 작용에 대해 명확한 이해가 이루어지지 않을 경우 다양한 변경이 환경 전체 복잡성을 가중할 위험이 있다. 이처럼 복잡성이 더해지면서 SOA가 해결해야 할 일부 문제가 다시 발생한다.
마이크로서비스 아키텍처는 느슨하게 연결된 전문 서비스를 사용한다는 점에서 SOA 패턴과 유사하나, 여기서 더 나아가 전통적인 아키텍처를 더욱 세분화한다. 마이크로서비스 아키텍처 내의 서비스는 RESTful API와 같은 일반적인 메시징 프레임워크를 사용한다.
RESTful API를 사용하면 어려운 데이터 변환 트랜잭션이나 추가 통합 계층 없이 상호 커뮤니케이션을 구현할 수 있으며, 새로운 기능과 업데이트를 더 빠르게 제공할 수 있다. 각 서비스는 개별적으로 제공되며 아키텍처의 다른 서비스에 영향을 미치지 않고 하나의 서비스를 교체하거나 강화하거나 삭제할 수 있다. 이 경량의 아키텍처는 배포된 리소스나 클라우드 리소스를 최적화하고 개별 서비스의 동적 확장성을 지원한다.