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 게이트웨이 사용이 포함됩니다. 레거시 시스템과 사물 인터넷(IoT)을 비롯하여 어떤 환경이든 연결하는 분산형 통합 플랫폼을 통해 API에 연결하고 API에 의해 노출된 데이터 또는 기능을 사용하는 애플리케이션을 만들 수 있습니다.

파트너 또는 일반 사용자에게 API를 공개하면 다음과 같은 이점을 얻을 수 있습니다.

• 새로운 수익 채널을 확보하거나 기존 수익 채널을 확장합니다.
• 브랜드 인지도를 확대합니다.
• 외부 개발을 활용하고 협업을 수행하여 오픈 혁신을 촉진하거나 효율성을 높입니다.

이렇게 바람직한 성과를 API가 어떻게 실현할 수 있을까요?

도서 유통업체의 예로 돌아가 보겠습니다.

이 회사의 한 파트너가 서점에서 원하는 도서를 쉽게 찾을 수 있는 애플리케이션을 개발한다고 가정해 보겠습니다. 이렇게 고객 환경을 개선하면 더 많은 손님이 서점을 찾을 것이고 기존의 수익 채널이 확대되는 효과를 얻게 됩니다.

제 3자가 퍼블릭 API를 사용하여 매장이 아니라 유통업체로부터 직접 도서를 구입하는 애플리케이션을 개발할 수도 있으며 이는 도서 유통업체에게 새로운 수익 채널을 열어 줍니다.

특정 파트너 또는 전 세계 사람들과 API를 공유하면 긍정적인 효과를 가져올 수 있으며 각각의 파트너십을 통해 브랜드 인지도 측면에서 회사 자체의 마케팅 활동을 넘어서는 성과를 거둘 수 있습니다. 퍼블릭 API처럼 기술을 모든 사람에게 공개하면 개발자가 API를 사용하여 애플리케이션의 에코시스템을 구축할 수 있습니다. 더 많은 사람들이 기술을 사용할수록 비즈니스를 함께할 사람도 늘어나게 됩니다.

기술을 대중에게 공개함으로써 예기치 않은 결과가 발생할 수도 있으며 이 결과가 전체 산업을 와해시키기도 합니다. 앞서 예를 든 도서 유통업체의 경우 도서 대여 서비스를 제공하는 새로운 기업이 나타나 비즈니스 방식을 근본적으로 바꿀 수 있으며, 파트너 그리고 퍼블릭 API를 통해서는 내부 개발자 팀보다 규모가 큰 커뮤니티에서 발휘되는 창의력을 활용할 수 있습니다. 새로운 아이디어는 어디서든 나올 수 있으며 기업은 시장의 변화를 인지하고 적절히 대응할 준비를 갖춰야 합니다. 바로 여기서 API가 큰 도움이 될 수 있습니다.

API는 개인용 컴퓨터가 나오기 훨씬 전인 컴퓨팅 초기에 등장했으며 대개 운영 체제의 라이브러리로 사용되었습니다. 메인프레임 간에 메시지를 전달하는 경우도 있었지만 거의 항상 시스템에서 로컬로 작동했습니다. 약 30년이 지난 후에야 API는 로컬 환경에서 분리되었으며 2000년대 초반에는 데이터의 원격 통합을 위한 주요 기술이 되었습니다.

원격 API는 커뮤니케이션 네트워크를 통해 상호 작용하도록 설계되었습니다. 여기서 원격이란 API에 의해 조작되는 리소스가 요청을 보내는 컴퓨터의 외부에 있음을 의미합니다. 가장 광범위하게 사용되는 커뮤니케이션 네트워크가 인터넷이기 때문에 대부분의 API는 웹 표준을 기반으로 설계되며, 모든 원격 API가 웹 API인 것은 아니지만 웹 API가 원격이라고 가정할 수는 있습니다.

웹 API는 일반적으로 요청 메시지에 HTTP를 사용하여 응답 메시지 구조의 정의를 제공합니다. 이러한 응답 메시지는 일반적으로 XML 또는 JSON 파일의 형태입니다. 다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML과 JSON 둘 다 자주 사용됩니다.

웹 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 인터페이스를 구축할 수 있으므로 사용자는 별다른 추측 없이도 이를 이해할 수 있습니다.

부상하는 또 다른 API 표준은 쿼리 언어이자 서버측 런타임으로 REST의 대안인 GraphQL입니다. GraphQL은 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선순위를 둡니다. REST를 대체할 수 있는 GraphQL은 개발자가 단일 API 호출로 다양한 데이터 소스에서 데이터를 끌어오는 요청을 구성할 수 있도록 지원합니다.

원격 API를 가장 많이 사용하는 두 가지 아키텍처 접근 방식은 SOA(서비스 지향 아키텍처)와 마이크로서비스 아키텍처입니다. 이 두 가지 접근 방식 중에서 더 일찍 개발된 SOA의 초기 모습은 모놀리식(Monolithic) 애플리케이션을 개선한 것이었습니다. 하나의 모놀리식 애플리케이션이 모든 작업을 수행하지만 일부 기능은 ESB(엔터프라이즈 서비스 버스)와 같은 통합 패턴을 통해 느슨하게 연결된 다른 애플리케이션에서 제공될 수 있습니다.

SOA는 모든 면에서 모놀리식 아키텍처보다 단순하지만 구성 요소의 상호 작용에 대해 명확한 이해가 이루어지지 않을 경우 다양한 변경이 환경 전체 복잡성을 가중할 위험이 있습니다. 이처럼 복잡성이 더해지면서 SOA가 해결해야 할 일부 문제가 다시 발생합니다.

마이크로서비스 아키텍처는 느슨하게 연결된 전문 서비스를 사용한다는 점에서 SOA 패턴과 유사하나, 여기서 더 나아가 전통적인 아키텍처를 더욱 세분화합니다. 마이크로서비스 아키텍처 내의 서비스는 RESTful API와 같은 일반적인 메시징 프레임워크를 사용합니다. RESTful API를 사용하면 어려운 데이터 변환 트랜잭션이나 추가 통합 계층 없이 상호 커뮤니케이션을 구현할 수 있으며, 새로운 기능과 업데이트를 더 빠르게 제공할 수 있습니다. 각 서비스는 개별적으로 제공되며 아키텍처의 다른 서비스에 영향을 미치지 않고 하나의 서비스를 교체하거나 강화하거나 삭제할 수 있습니다. 이 경량화된 아키텍처는 분산된 리소스나 클라우드 리소스를 최적화하고 개별 서비스의 동적 확장성을 지원합니다.

웹후크는 2개의 API 간에 경량화 이벤트 기반 통신을 가능케 하는 HTTP 기반 콜백 기능입니다. 웹후크는 다양한 웹 애플리케이션이 다른 애플리케이션에서 소량의 데이터를 수신하기 위해 사용하지만 GitOps 환경에서 자동화 워크플로우를 트리거하는 데 사용될 수도 있습니다.

웹후크는 통신의 책임을 클라이언트가 아닌 서버에 부과하므로 종종 리버스 API 또는 푸시 API라고 불립니다. 서버가 응답할 때까지 데이터를 요청하는 HTTP 요청을 전송하는 클라이언트 대신에 서버는 데이터가 제공되자마자 단일 HTTP POST 요청을 클라이언트에 전송합니다. 웹후크는 닉네임이 있지만 API가 아니며 서로 연동됩니다. 웹후크를 사용하려면 애플리케이션에 API가 있어야 합니다.