API란?

API는 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 의미합니다.

API를 사용하면 제품이나 서비스를 구현하는 방법을 몰라도 다른 제품 및 서비스와 통신할 수 있습니다. 이를 통해 애플리케이션 개발을 간소화하고 시간과 비용을 절감할 수 있습니다. 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리할 때 API를 활용하면 유연성을 높이고 설계, 관리, 사용을 간소화하며 혁신의 기회를 창출할 수 있습니다.

API는 당사자 간의 합의를 문서화한 계약에 비유되기도 합니다. 한쪽이 특정 방식으로 구성된 원격 요청을 보내면 다른 쪽의 소프트웨어가 정해진 방식으로 응답하는 구조입니다.

API는 개발자가 새로운 애플리케이션 구성 요소를 기존 아키텍처에 통합하는 과정을 간소화하므로, 비즈니스 팀과 IT 팀 간 협업을 지원합니다. 급변하는 디지털 시장에서는 새로운 애플리케이션을 앞세운 경쟁업체가 산업 전체의 판도를 바꾸기도 하며, 이러한 상황에서 비즈니스 요구 사항도 빠르게 변화하는 경우가 많습니다. 경쟁력을 유지하려면 혁신적인 서비스를 신속하게 개발하고 배포할 수 있어야 합니다. 클라우드 네이티브 애플리케이션 개발은 개발 속도를 높이는 대표적인 방법이며, API를 통해 마이크로서비스 애플리케이션 아키텍처를 연결하는 방식에 기반합니다.

API는 클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방법일 뿐만 아니라 고객과 기타 외부 사용자에게 데이터를 공유할 수 있도록 합니다. 퍼블릭 API는 파트너와 연결되는 방식을 간소화하고 확장할 뿐만 아니라 데이터를 수익화할 가능성을 제공한다는 점에서 고유한 비즈니스 가치를 지닙니다. Google Maps API가 대표적인 예입니다.

한 도서 유통 회사를 예로 들겠습니다. 이 회사는 서점 직원이 유통업체의 도서 재고를 확인할 수 있는 클라우드 애플리케이션을 고객에게 제공할 수 있습니다. 이 애플리케이션은 개발 비용이 많이 들고 플랫폼에 따라 제한될 수 있는 데다 개발에 오랜 시간이 걸리고 지속적인 유지 관리가 필요할 수 있습니다.

또는 도서 유통업체에서 재고 현황을 확인할 수 있는 API를 제공할 수도 있습니다. 이 접근 방식에는 다음과 같은 몇 가지 장점이 있습니다.

• API를 통해 고객이 데이터에 액세스하도록 지원하면 재고 관련 정보를 한곳에 통합하는 데 도움이 됩니다.
• API의 동작이 변경되지 않는 한 도서 유통업체는 고객에게 영향을 주지 않고 내부 시스템을 변경할 수 있습니다.
• API를 공개하면 도서 유통업체, 서점 또는 타사 개발자가 고객이 원하는 책을 찾을 수 있도록 지원하는 애플리케이션을 개발할 수 있습니다. 이는 매출 증대나 새로운 비즈니스 기회로 이어질 수 있습니다.

간단히 말해 API를 사용하면 보안과 제어를 유지하면서 리소스에 대한 액세스를 개방할 수 있습니다. 액세스를 어떤 방식으로 누구에게 개방할지는 사용자가 결정할 수 있습니다. API 보안의 핵심은 효과적인 API 관리이며, 여기에는 API 게이트웨이 사용이 포함됩니다. API에 연결하고 API를 통해 제공되는 데이터나 기능을 사용하는 애플리케이션을 만들려면 레거시 시스템과 사물인터넷(IoT)을 비롯한 모든 요소를 연결하는 분산형 통합 플랫폼을 활용할 수 있습니다.

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

• 새로운 수익 채널을 창출하거나 기존 수익 채널을 확대할 수 있습니다.
• 브랜드의 도달 범위를 확장할 수 있습니다.
• 외부 개발과 협업을 통해 개방형 혁신을 촉진하거나 효율성을 높일 수 있습니다.

이제 API가 이러한 효과를 어떻게 만들어내는지 살펴보겠습니다.

앞서 살펴본 도서 유통 회사의 예로 돌아가 보겠습니다.

이 회사의 파트너 중 한 곳이 사람들이 서점 진열대에서 원하는 책을 검색하는 데 사용할 애플리케이션을 개발한다고 가정하겠습니다. 이렇게 향상된 고객 경험은 유통업체의 고객인 서점에 더 많은 소비자를 유입시키고 기존 수익 채널을 확장합니다.

또는 타사가 퍼블릭 API를 사용해 소비자가 매장을 거치지 않고 유통업체에서 직접 책을 구매할 수 있는 애플리케이션을 개발할 수도 있습니다. 이는 도서 유통업체에 새로운 수익 채널을 열어줍니다.

특정 파트너나 전 세계 사용자와 API를 공유하면 긍정적인 효과를 얻을 수 있습니다. 파트너십이 늘어날 때마다 기업의 자체 마케팅 활동을 넘어 브랜드 인지도를 확대할 수 있습니다. 퍼블릭 API처럼 기술을 모두에게 개방하면 개발자가 해당 API를 중심으로 애플리케이션 에코시스템을 구축하도록 장려할 수 있습니다. 귀사의 기술을 사용하는 사람이 많아진다는 것은 더 많은 사람이 귀하와 비즈니스 관계를 맺을 가능성이 높다는 것을 의미합니다.

기술을 공개하면 새롭고 예상치 못한 결과로 이어질 수 있으며, 때로는 산업 전체에 큰 변화를 가져오기도 합니다. 앞서 예로 든 도서 유통 회사의 경우, 도서 대여 서비스를 제공하는 새로운 업체가 등장해 기존 비즈니스 방식을 근본적으로 바꿀 수 있습니다. 파트너 API와 퍼블릭 API를 활용하면 사내 개발자 팀보다 규모가 큰 커뮤니티의 창의적인 역량을 활용할 수 있습니다. 새로운 아이디어는 어디에서나 나올 수 있으며, 기업은 시장의 변화를 파악하고 이에 대응할 준비가 되어 있어야 합니다. 이때 API가 도움이 될 수 있습니다.

API는 개인용 컴퓨터가 등장하기 훨씬 이전인 컴퓨팅 초창기에 등장했습니다. 당시에는 API가 보통 운영 체제용 라이브러리로 사용되었습니다. API는 대부분 해당 시스템 내부에서만 작동했지만 때로는 메인프레임 간에 메시지를 전달하기도 했습니다. 약 30년 후 API는 로컬 환경에서 벗어나기 시작했습니다. 2000년대 초반에는 원격 데이터 통합에 중요한 기술로 자리 잡았습니다.

원격 API는 통신 네트워크를 통해 상호작용하도록 설계됩니다. 여기서 원격이란 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라고 합니다. REST는 SOAP와 근본적인 차이가 있습니다. SOAP는 프로토콜인 반면 REST는 아키텍처 스타일입니다. 따라서 RESTful 웹 API에는 공식 표준이 없습니다. Roy Fielding의 논문 '네트워크 기반 소프트웨어 아키텍처의 아키텍처 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)'에 따르면 다음과 같은 RESTful 시스템의 6가지 기본 제약 조건을 준수하는 API를 RESTful API라고 할 수 있습니다.

• 클라이언트-서버 아키텍처: REST 아키텍처는 클라이언트, 서버, 리소스로 구성되며 HTTP를 통해 요청을 처리합니다.
• 무상태성: 요청과 요청 사이에 클라이언트 콘텐츠가 서버에 저장되지 않습니다. 대신 세션 상태에 관한 정보는 클라이언트에서 유지합니다.
• 캐시 가능성: 캐싱을 사용하면 일부 클라이언트-서버 간 상호작용이 필요하지 않을 수 있습니다.
• 계층화된 시스템: 클라이언트와 서버 간의 상호작용은 추가 계층을 거쳐 이루어질 수 있습니다. 이러한 계층은 부하 분산, 공유 캐시, 보안과 같은 추가 기능을 제공할 수 있습니다.
• 온디맨드 코드(선택 사항): 서버는 실행 가능한 코드를 전송하여 클라이언트의 기능을 확장할 수 있습니다.
• 일관된 인터페이스: RESTful API 설계의 핵심 제약 조건으로 다음 4가지 요소를 포함합니다.
  • 요청에서 리소스 식별: 요청에서 리소스를 식별하며 리소스는 클라이언트에 반환되는 표현과 구분됩니다.
  • 표현을 통한 리소스 조작: 클라이언트는 리소스를 표현하는 파일을 받습니다. 이러한 표현에는 리소스를 수정하거나 삭제하는 데 충분한 정보가 포함되어 있어야 합니다.
  • 자기 기술적 메시지: 클라이언트에 반환되는 각 메시지에는 클라이언트가 해당 정보를 처리하는 방법을 알 수 있을 만큼 충분한 정보가 포함됩니다.
  • 애플리케이션 상태 엔진으로서의 하이퍼미디어: 리소스에 액세스한 후 REST 클라이언트는 하이퍼링크를 통해 현재 가능한 다른 모든 작업을 확인할 수 있어야 합니다.

이러한 제약 조건이 많아 보일 수 있지만, 정해진 프로토콜을 따르는 것보다는 훨씬 간단합니다. 이러한 이유로 RESTful API는 SOAP보다 더 널리 사용되고 있습니다.

최근에는 OpenAPI 사양이 REST API를 정의하기 위한 공통 표준으로 자리 잡았습니다. OpenAPI는 사용자가 최소한의 추측으로 API를 이해할 수 있도록, 개발자가 특정 언어에 구애받지 않고 REST API 인터페이스를 구축할 수 있는 방식을 제공합니다.

또 다른 API 표준으로 등장한 GraphQL은 REST의 대안이 되는 쿼리 언어이자 서버 측 런타임입니다. GraphQL은 클라이언트가 요청한 데이터만 정확히 제공하는 것을 우선시합니다. REST의 대안인 GraphQL을 사용하면 개발자가 한 번의 API 호출로 여러 데이터 소스에서 데이터를 가져오는 요청을 구성할 수 있습니다.

SOAP와 REST의 차이점 자세히 알아보기

원격 API를 가장 많이 사용하는 두 가지 아키텍처 접근 방식은 서비스 지향 아키텍처(SOA)와 마이크로서비스 아키텍처입니다. 이 두 접근 방식 중 더 오래된 SOA는 모놀리식 애플리케이션을 개선하기 위해 등장했습니다. 하나의 모놀리식 애플리케이션이 모든 기능을 수행하는 것과 달리 SOA에서는 엔터프라이즈 서비스 버스(ESB)와 같은 통합 패턴을 통해 느슨하게 결합된 여러 애플리케이션이 각각 일부 기능을 제공할 수 있습니다.

SOA는 대부분의 측면에서 모놀리식 아키텍처보다 단순하지만 구성 요소 간의 상호작용을 명확하게 파악하지 못하면 한 요소의 변경이 환경 전반에 연쇄적으로 영향을 미칠 수 있습니다. 이러한 추가적인 복잡성으로 인해 SOA가 해결하고자 했던 문제 중 일부가 다시 발생할 수 있습니다.

마이크로서비스 아키텍처는 특화된 서비스를 느슨하게 결합하여 사용한다는 점에서 SOA 패턴과 유사하지만 기존 아키텍처를 더욱 세분화합니다. 마이크로서비스 아키텍처의 서비스는 RESTful API와 같은 공통 메시징 프레임워크를 사용합니다. 각 서비스는 복잡한 데이터 변환 작업이나 추가적인 통합 계층 없이 RESTful API를 통해 서로 통신합니다. RESTful API를 사용하면 새로운 기능과 업데이트를 더 빠르게 제공할 수 있을 뿐만 아니라 이를 더 촉진할 수 있습니다. 각 서비스는 독립적입니다. 아키텍처의 다른 서비스에 영향을 주지 않고 개별 서비스를 교체, 개선하거나 제거할 수 있습니다. 이 경량화 아키텍처는 분산 또는 클라우드 리소스를 최적화하고 개별 서비스의 동적 확장성을 지원합니다.

SOA 자세히 알아보기

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

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

웹후크 자세히 알아보기

모델 컨텍스트 프로토콜(MCP)과 API는 모두 서로 다른 시스템을 연결하는 디지털 브리지 역할을 합니다. MCP 기능은 API를 기반으로 구축되며, API가 없다면 MCP도 존재할 수 없습니다. 

두 기술은 작동 방식과 설계 목적에 차이가 있습니다.

• MCP는 언어 모델을 외부 툴 및 데이터에 연결하여 실시간으로 적응하고 유연하게 대응하는 워크플로우를 지원합니다. 
• 전통적인 API 워크플로우는 정해진 규칙을 따릅니다. 두 시스템이 연결되면, 이후 상호작용은 개발자가 프로그래밍한 특정 작업 범위로 제한됩니다.

MCP와 API의 차이점 자세히 알아보기