API란 무엇인가요?

API는 특정 상호작용에 필요한 데이터와 기능만 노출하고 그 밖의 내부 구현 세부 정보는 숨깁니다. 이러한 추상화는 시스템 무결성을 보호하고 소프트웨어 구성요소 간 통신을 간소화합니다.

API에는 하드웨어 및 펌웨어 API, 운영 체제 API, 라이브러리 및 프레임워크 API, 웹 API 등 다양한 종류가 있으며, 큰 틀에서 보면 모두 동일한 방식으로 작동합니다. 즉, 두 소프트웨어 간의 계약을 정의하여 요청하고 반환할 수 있는 항목을 지정합니다.

통합을 중심으로 설명하는 이 문서에서는 주로 웹 API(소프트웨어가 네트워크를 통해 요청할 수 있도록 지원하며 흔히 HTTP를 사용하는 API 유형)의 작동 방식과 차이점, 그리고 시스템 연결, 데이터 동기화 및 워크플로 자동화에 웹 API가 사용되는 방식을 살펴봅니다.

API 통신은 클라이언트와 서버 간의 요청과 응답이라는 관점에서 이해하면 유용합니다. 요청을 제출하는 애플리케이션이 클라이언트이고 서버는 응답을 제공합니다. API는 이 둘 간의 통신 방식을 정의합니다.

간단한 예로 서드파티 결제 처리를 살펴보겠습니다. 사용자가 전자상거래 사이트에서 제품을 구매할 때 사이트에서 “PayPal로 결제” 옵션을 제공할 수 있습니다. 이 기능은 API를 통해 연결됩니다.

• 구매자가 결제 버튼을 클릭하면 API 호출이 시작됩니다. 이 요청은 API의 URI(Uniform Resource Identifier)를 통해 애플리케이션에서 웹 서버로 전송되어 처리되며, 요청 동사, 헤더 및 경우에 따라 요청 본문이 포함됩니다. 이러한 요소를 통해 무엇을 어떤 방식으로 요청하는지 지정합니다.
  
  
• API는 클라이언트로부터 유효한 요청을 받으면 해당 요청을 외부 프로그램이나 웹 서버(이 경우 서드파티 결제 시스템)로 전달하고 요청된 정보가 포함된 응답을 반환합니다.
  
  
• API는 데이터를 초기 요청 애플리케이션(이 경우 제품 웹사이트)으로 전송합니다.

최종 사용자에게는 이 전체 과정이 보이지 않으며 결제가 성공했다는 확인 메시지만 표시됩니다.

API는 하드웨어에 가까운 계층부터 대부분의 사람들이 매일 상호작용하는 웹 서비스에 이르기까지 소프트웨어의 모든 계층에 존재합니다. 일상적인 대화에서는 API와 웹 API를 같은 의미로 사용하는 경우가 많습니다. 하지만 API에는 다양한 사용 사례를 지원하는 여러 유형이 있으며, 다음과 같은 유형이 있습니다.

• 하드웨어 및 펌웨어 API를 통해 소프트웨어는 프로세서 및 센서와 같은 디바이스의 물리적 구성요소와 통신할 수 있습니다.
  
  
• 운영 체제 API를 통해 소프트웨어는 파일, 프로세스 및 메모리 관리와 같은 서비스를 위해 운영 체제와 통신할 수 있습니다.
  
  
• 라이브러리 및 프레임워크 API는 함수, 메서드 및 후크와 같이 미리 작성된 코드를 제공하며, 개발자는 네트워크를 거치지 않고 애플리케이션 내에서 이러한 코드와 직접 상호작용할 수 있습니다. 
  
  
• 데이터베이스 API를 통해 소프트웨어는 데이터베이스와 통신하고 데이터베이스에 저장된 정보를 조작 및 추출할 수 있습니다.
  
  
• 웹 API를 통해 소프트웨어는 흔히 HTTP를 사용하여 네트워크를 통해 요청을 보낼 수 있습니다. 웹 API는 원격 API의 한 유형으로, 단일 디바이스 내부가 아닌 서로 다른 시스템 간의 통신 및 리소스 조작을 지원합니다.

*일부 레거시 시스템에서는 FTP, SMTP 및 SSH와 같은 네트워크 프로토콜을 통합 인터페이스로 직접 제공한다는 점에 유의해야 합니다. 기술적으로는 이러한 프로토콜도 광범위한 API 정의에 해당하지만, 무엇과 인터페이스하는지가 아니라 통신 방식에 따라 분류되므로 통합을 중심으로 한 논의와는 관련성이 떨어집니다.

웹 API는 통합에 가장 일반적으로 사용됩니다. 위에 나열된 다른 API 유형과 달리 웹 API는 네트워크를 통해 서로 다른 애플리케이션 간에 통신하도록 설계되었습니다.

REST는 오늘날 웹 API에서 가장 널리 사용되는 아키텍처 스타일입니다. REST API는 RESTful API라고도 하며, 확장 가능하고 유연하며 서로 분리된 웹 서비스를 구축하기 위해 Roy Fielding이 처음 정의한 6가지 아키텍처 제약 조건을 따릅니다.

REST는 데이터를 리소스 형태로 제공하며, REST API는 GET, POST, PUT, PATCH 및 DELETE와 같은 HTTP 메서드를 사용하여 이러한 리소스와 상호작용합니다. 각 리소스는 일반적으로 API 엔드포인트라고 하는 고유한 URI로 식별됩니다. 이는 클라이언트가 API 요청을 보내는 특정 주소입니다.

REST는 다음과 같은 제약 조건으로 정의됩니다.

• 통일된 인터페이스 - 표준화된 통신 규칙을 설정합니다. 동일한 리소스에 대한 모든 요청은 동일한 형식을 따라야 합니다. 각 리소스에는 하나의 URI가 있어야 합니다.
  
  
• 클라이언트/서버 분리 - 클라이언트와 서버 애플리케이션은 서로 종속되지 않고 독립적으로 발전할 수 있어야 합니다. 클라이언트가 알고 있는 유일한 정보는 리소스 URI입니다.
  
  
• 무상태성 - 서버는 요청 간에 세션 상태를 저장하지 않습니다. 각 요청은 자체적으로 완결되어야 하며 요청을 처리하는 데 필요한 모든 정보를 포함해야 합니다.
  
  
• 캐시 가능성 - 모든 리소스는 가능한 경우 캐시할 수 있어야 하며, 서버는 이러한 리소스를 캐시할 수 있다고 명시해야 합니다.
  
  
• 계층형 시스템 아키텍처: REST의 각 요청은 자체적으로 완결되어 있으므로 클라이언트는 원본 서버와 통신하는지 중개 서버와 통신하는지 알 필요가 없습니다. 따라서 REST는 많은 클라이언트에 서비스를 제공하는 퍼블릭 API에 적합합니다.
  
  
• 온디맨드 코드(선택 사항): REST API는 일반적으로 데이터를 반환합니다. 마지막 제약 조건이자 유일한 선택적 제약 조건인 이 원칙에서는 클라이언트가 필요할 때 실행할 수 있는 JavaScript와 같은 실행 가능 코드를 반환할 수 있습니다.

REST 원칙에 대한 자세한 설명은 여기에서 확인하세요.

SOAP는 메시지의 구조화 및 전송 방식에 엄격한 표준을 적용하는 XML 기반 메시징 프로토콜입니다. 실제로 거의 전적으로 HTTP를 통해 실행되는 REST API와 달리 SOAP는 전송 프로토콜에 구애받지 않습니다. HTTP, SMTP 및 기타 프로토콜을 통해 작동할 수 있어 HTTP가 항상 기반 프로토콜로 사용되는 것은 아닌 엔터프라이즈 환경에서 더 뛰어난 유연성을 제공합니다.

SOAP 메시지는 메시지 처리 방식을 지정하는 엄격한 구조를 따르므로 REST보다 더 많은 정보가 필요하지만 그만큼 더 표준화되어 있습니다. SOAP의 공식 표준, 기본 제공 오류 처리 및 엄격한 보안 사양은 여전히 높은 가치를 제공하며, 이에 따라 오늘날에도 금융 및 의료와 같은 산업에서 계속 사용되고 있습니다.

RPC는 웹 API보다 먼저 등장했으며 레거시 구현과 최신 구현이 모두 존재합니다. 서브루틴 호출 또는 함수 호출이라고도 하는 RPC를 사용하면 애플리케이션이 원격 서버의 함수나 메서드를 로컬에 있는 것처럼 실행할 수 있습니다. RPC는 리소스가 아닌 작업을 중심으로 구성됩니다. RPC API는 일반적으로 각 리소스에 개별 URI를 사용하는 대신 단일 엔드포인트를 제공하고 요청 페이로드 내에서 수행할 작업을 지정합니다.

JSON-RPC의 직접적인 전신인 XML-RPC는 XML을 사용하여 호출과 응답을 인코딩합니다. SOAP보다 오래된 기술이지만 더 단순하여 구현하기가 쉽습니다. 다만 XML은 형식이 장황하기 때문에 JSON 기반 대안보다 데이터 크기가 크고 처리 부담도 큽니다. 본질적으로 JSON-RPC의 직접적인 전신입니다.

JSON-RPC는 XML-RPC와 동일한 방식으로 작동하지만 XML 대신 JSON을 사용합니다. JSON은 XML보다 간결하고 파싱하기 쉬우므로 JSON-RPC는 이전 기술인 XML-RPC보다 가볍고 가독성이 높습니다.

gRPC는 RPC 계열의 최신 고성능 기술입니다. 처음에는 Google에서 개발했으며 현재는 오픈 소스 프로젝트로 유지관리되고 있습니다. 기존 RPC 구현에서 텍스트 기반 형식을 사용하는 것과 달리 gRPC는 JSON이나 XML보다 더 작고 빠른 메시지를 생성하는 바이너리 직렬화 형식인 Protocol Buffers(또는 Profobuf)를 사용합니다.

또한 HTTP/1.1이 아닌 HTTP/2를 통해 실행되므로, 성능이 더욱 향상됩니다. gRPC는 내부 마이크로서비스 통신에 널리 사용되며 양방향 스트리밍을 지원하므로 실시간 데이터 흐름에 적합합니다.

GraphQL은 더욱 효율적으로 리소스를 가져올 수 있도록 Facebook이 2012년에 개발한 오픈 소스 쿼리 언어이자 서버 측 런타임입니다. 클라이언트가 원하는 데이터를 정확히 지정할 수 있도록 하여 오버페칭(필요한 것보다 많은 데이터를 수신하는 것)과 언더페칭(필요한 데이터를 수신하기 위해 여러 번 요청해야 하는 것)을 방지하도록 설계되었습니다. GraphQL은 클라이언트가 여러 리소스를 쿼리할 수 있는 단일 엔드포인트를 사용하며, 결과는 하나의 응답으로 반환됩니다.

GraphQL은 매우 유연하지만 REST보다 복잡하며, 클라이언트의 데이터 요구사항이 크게 달라지는 복잡한 환경에서 주로 사용됩니다.

여기에서 REST와 GraphQL을 더욱 자세히 비교해 보세요.

앞서 언급한 API는 모두 클라이언트가 요청을 시작하는 요청/응답 모델을 따릅니다. 통합 측면에서 주목해야 할 두 가지 중요한 예외가 있습니다.

• WebSocket(WebSocket API)은 지속적인 양방향 연결을 유지하므로 실시간 데이터 피드와 같은 실시간 사용 사례에 적합합니다.
  
  
• Webhook은 이 모델을 완전히 반대로 적용합니다. 클라이언트가 요청을 시작하는 대신 지정된 이벤트가 발생하면 서버가 클라이언트에 알림을 푸시합니다.

퍼블릭 API는 인터넷에 완전히 공개되며 일반적으로 제한이 없거나 최소한의 제한만 적용되어 모든 개발자 또는 조직이 사용할 수 있습니다. 개발자는 API 키를 발급받아야 할 수도 있지만 그 외에는 이러한 API를 사용하기 위한 요구사항이 거의 없습니다. 외부 통합 및 서드파티 개발을 장려하도록 설계되었습니다.

*여기에서 자세히 알아볼 수 있는 “OpenAPI 사양(OAS)”과 혼동해서는 안 됩니다. 

프라이빗 API는 일반에 공개되지 않으며 지정된 조직 내에서만 액세스할 수 있습니다. 프라이빗 API는 흔히 프라이빗 네트워크에 격리되어 있으며 액세스하려면 엄격한 인증이 필요합니다. 조직은 일반적으로 이러한 API를 사용하여 내부 소프트웨어 시스템을 연결합니다.

액세스 측면에서 파트너 API는 퍼블릭 API와 프라이빗 API의 중간에 해당하며, 특정 그룹의 승인된 비즈니스 파트너가 사용할 수 있습니다. 퍼블릭 인터넷을 통해 액세스할 수 있는 경우도 있지만 일반에 공개되지는 않으며 승인된 사용자에게만 액세스 권한이 부여됩니다. 파트너 API는 B2B 데이터 공유 또는 데이터 스트림 수익화 등에 사용되며, 그 사용은 흔히 특정 파트너 계약에 따라 관리됩니다. 

*복합 API는 액세스 유형별 분류에 포함되기도 하지만 액세스 수준보다는 아키텍처 패턴으로 이해하는 것이 더 적절합니다. 복합 API는 여러 API 호출을 결합하며 퍼블릭, 프라이빗 또는 파트너 API 형태로 제공될 수 있습니다. 이에 대해서는 API 및 마이크로서비스 섹션에서 자세히 설명합니다.

API 설계는 API가 데이터와 기능을 노출하는 방식을 결정하는 의사결정 프로세스입니다. 설계 프로세스에서 팀은 API에 사용할 프로토콜과 아키텍처 스타일을 결정하고, 명명, 응답 구조 및 오류 처리에 대한 일관된 규칙을 수립하며, 액세스 인증 및 권한 부여 방식을 결정하고, 기존 버전과 호환되지 않는 변경 사항을 관리하기 위한 버전 관리 전략을 정의합니다. 이러한 결정을 비롯한 다양한 결정에 따라 API의 작동 방식과 개발자가 API와 상호작용하는 방식이 달라집니다.

기본적으로 이 프로세스는 “이 API는 어떻게 사용될 것인가?”와 같은 질문에서 시작하여 조직의 요구사항을 충족하는 API 설계 청사진을 개발하는 단계로 이어집니다.

조직의 API 거버넌스 정책은 API 설계에 영향을 미치는 경우가 많습니다. API 거버넌스는 조직이 API를 개발, 배포 및 사용하는 방식을 규정하는 포괄적인 표준, 정책 및 관행을 의미합니다. 효과적인 API 설계를 통해 이러한 사전 정의된 정책을 준수하는 API를 구축할 수 있습니다.

API 문서는 기술 사용 설명서와 같은 역할을 하며, 지원되는 프로토콜, 언어 및 인증 방법, 코드 스니펫, 구조 정의를 비롯해 개발자가 API를 사용하는 데 필요한 기타 정보를 제공합니다. 포괄적인 최신 API 문서는 개발자에게 더 나은 API 경험을 제공하고 성공적인 API 도입, 통합 및 관리를 지원합니다.

API 우선(또는 API 설계 우선)은 API를 애플리케이션의 기반으로 간주하여 애플리케이션 코드를 작성하기 전에 API를 먼저 설계하는 소프트웨어 개발 접근 방식입니다. 조직은 백엔드 비즈니스 로직과 데이터베이스 구조부터 시작하는 대신, 흔히 OpenAPI와 같은 API 사양을 사용하여 계약을 먼저 정의한 후 이를 중심으로 나머지 애플리케이션을 구축합니다.

이는 통합이 많은 조직에서 선호되는 접근 방식으로, 확장성, 안정성 및 일관성이라는 이점이 있습니다. API가 신뢰할 수 있는 기준 정보의 역할을 하며 웹 및 모바일 앱, 사물인터넷(IoT) 디바이스, AI 앱 및 모델, 기타 시스템 등 모든 사용자가 개별 맞춤형 통합 대신 동일한 API 계층과 상호작용합니다.

일부 조직에서는 API 설계 우선과 API 우선을 서로 다른 접근 방식으로 간주합니다. 후자는 API 자체를 고유한 라이프사이클, 제품 관리자 및 로드맵을 갖춘 제품으로 취급하는 보다 광범위한 조직 차원의 접근 방식입니다.

마이크로서비스는 애플리케이션을 더 작고 독립적인 서비스로 나누는 아키텍처 스타일입니다. 이러한 서비스는 API를 통해 통신하며, 여러 프로토콜과 스타일을 함께 사용하는 경우가 많습니다. 예를 들어 외부 대상 서비스에는 REST API를, 내부 서비스 간 통신에는 gRPC를, 이벤트 기반 흐름에는 Webhook을 사용할 수 있습니다. 마이크로서비스 아키텍처를 사용하면 개발자가 특정 서비스에 가장 적합한 프레임워크를 유연하게 선택할 수 있습니다.

또한 개발자는 각 서비스를 서로 독립적으로 테스트, 배포, 업데이트, 통합, 유지관리 및 확장할 수 있습니다. 장애 격리가 간소화되어 단일 구성요소에 장애가 발생해도 전체 애플리케이션이 중단되지 않으며, 서비스가 느슨하게 결합되어 있으므로 내부 구현이 변경되면 통합이 중단될 수 있습니다.

마이크로서비스에서 흔히 발생하는 문제 중 하나는 이른바 “채티 프런트엔드” 문제입니다. 기존 애플리케이션에서는 데이터가 하나의 데이터베이스에 저장되며 클라이언트는 한 번의 호출로 이 데이터베이스를 쿼리할 수 있습니다. 마이크로서비스에서는 데이터가 여러 서비스에 분산되어 있으므로 클라이언트가 필요한 데이터를 가져오기 위해 수십 건의 개별 요청을 통해 수십 개의 서비스와 통신해야 할 수 있습니다. 복합 API는 오케스트레이션 계층 역할을 하는 통합 엔드포인트를 제공하여 이 문제를 해결합니다. 이 엔드포인트는 클라이언트 요청을 받아 여러 백엔드 서비스와 통신하여 요청된 데이터를 수집한 후 단일 페이로드로 클라이언트에 반환합니다.

복합 API를 사용하면 클라이언트가 하나의 작업을 위해 여러 차례 왕복 호출을 수행할 필요가 없습니다. 또한 내부 시스템의 복잡성을 숨겨주므로 클라이언트는 어떤 마이크로서비스가 어떤 데이터를 처리하는지 알 필요 없이 복합 엔드포인트에 연결하는 방법만 알면 됩니다. 또한 내부 마이크로서비스 통신을 사용하는 단일 호출이 일반적으로 외부 네트워크를 통한 여러 차례의 왕복 호출보다 빠르므로 지연 시간을 줄일 수 있습니다.

마이크로서비스 아키텍처는 다양한 이점을 제공하지만 API의 노출 범위가 확대되고 복잡성이 증가하므로 강력한 API 관리가 더욱 중요해집니다.

API 관리는 API의 라이프사이클 전반에 걸쳐 API를 게시하고, 보호하고, 제어하고, 모니터링하는 프로세스입니다. 이러한 작업은 일반적으로 API 관리 플랫폼을 통해 중앙 집중식으로 수행되며, 이를 통해 조직은 모든 API에 일관된 정책을 적용할 수 있습니다. 이러한 플랫폼 중 다수에는 설계 및 문서화 툴도 포함되어 있지만, 이 섹션에서는 API 관리의 운영 측면에 중점을 둡니다.

API 관리에는 다음 항목에 대한 감독이 포함됩니다.

API 게이트웨이는 클라이언트가 여러 백엔드 서비스에 액세스할 수 있도록 단일 진입점을 제공하는 소프트웨어 계층입니다. API 게이트웨이를 사용하면 클라이언트가 게이트웨이 뒤의 복잡한 아키텍처를 이해하거나 직접 상호작용할 필요가 없으며, 마이크로서비스로 인해 급증하는 API를 관리하는 데 도움이 됩니다.

주요 기능에는 라우팅, 인증, 속도 제한 및 모니터링이 포함됩니다. 게이트웨이는 요청 집계도 처리할 수 있으므로 복합 API를 구현하는 데 흔히 사용됩니다.

API 보안은 API와 API가 전송하는 데이터를 오용, 악성 봇 공격 및 기타 사이버 보안 위협으로부터 보호하는 일련의 관행과 절차입니다.  API 보안에는 인증(사용자의 신원 확인), 권한 부여(사용자에게 허용된 작업 결정), 암호화, 입력값 검증 등이 포함됩니다. 일반적인 보안 기술로는 인증을 위한 API 키 및 OpenID Connect(ODIC)와 권한 부여를 위한 OAuth가 있습니다. 강력한 API 보안 태세는 승인된 사용자와 애플리케이션만 API에 액세스하도록 보장하는 데 도움이 됩니다. 

속도 제한과 스로틀링은 API 요청의 양과 흐름을 제어하여 시스템의 안정성과 가용성을 유지하는 데 도움이 됩니다. 속도 제한은 개별 클라이언트가 지정된 기간에 수행할 수 있는 호출 수를 제한하며, 스로틀링은 일반적으로 요청을 지연하거나 대기열에 추가하여 시스템이 수락하는 호출량을 관리합니다. 속도 제한은 상업적인 기능도 수행하여 조직이 유료 API의 사용량 등급을 적용할 수 있도록 합니다.

속도 제한과 스로틀링은 주로 운영상의 고려 사항이지만, 서비스 거부 및 크리덴셜 스터핑 공격을 차단하는 데 도움이 되는 부가적인 보안 기능도 수행합니다.

API 관리는 설계 단계에서 수립한 버전 관리 전략을 적용합니다. 관리 플랫폼을 통해 조직은 트래픽을 올바른 API 버전으로 라우팅하고, 여러 버전을 동시에 실행하며, 이전 버전의 지원 중단을 관리할 수 있습니다. 이를 통해 팀은 기존 통합이 중단 없이 마이그레이션할 시간을 확보하면서 호환성을 깨뜨리는 변경 사항을 포함한 업데이트와 새 버전을 출시할 수 있습니다.

API는 엔터프라이즈 시스템, 서비스 및 파트너를 서로 연결하는 역할을 하므로 API가 어떻게 작동하고 있는지 파악하는 것이 매우 중요합니다. API에 장애가 발생하면 이에 의존하는 모든 통합에 문제가 발생할 수 있습니다. 모니터링과 관측 가능성을 통해 팀은 이러한 문제가 연결된 시스템 전반으로 확산되기 전에 이를 감지하고 진단할 수 있습니다.

API 모니터링은 API의 성능, 가용성, 기능 및 사용량을 추적하고 지연 시간이나 오류율과 같은 메트릭이 사전 정의된 임계값을 초과하면 알림을 제공합니다. 관측 가능성은 모니터링을 확장한 개념으로, 메트릭, 로그 및 추적을 사용하여 시스템 상태를 더욱 심층적으로 파악하고 모니터링에서 포착되지 않는 정보를 식별합니다.

API 사용량을 파악하면 팀이 용량을 계획하고, 잠재적 위협에 대응하고, 정부 및 규제 요구사항을 준수하는 데 도움이 됩니다.

API는 데이터와 서비스를 교환할 수 있도록 소프트웨어 애플리케이션, 시스템 및 워크플로를 연결하며, 이러한 기능을 흔히 API 통합이라고 합니다. 오늘날 대부분의 통합 환경에서 API는 서비스와 시스템 간의 정보 이동에서 핵심적인 역할을 합니다.

일반적인 엔터프라이즈 사용 사례는 다음과 같습니다.

API를 통해 팀은 서드파티 서비스를 애플리케이션 및 워크플로에 통합할 수 있습니다. 예를 들어 핫소스 회사가 웹사이트에 파트너 소매업체를 표시하는 매장 찾기 지도를 추가하려는 경우, 지도 애플리케이션의 API를 사용하여 해당 정보를 사이트에 삽입할 수 있습니다.

조직은 API를 사용하여 파트너, 공급업체 및 고객과 데이터 및 서비스를 공유합니다. 물류 회사는 API를 사용하여 주문 추적 정보를 제공함으로써 소매업체가 해당 정보를 자체 시스템에 통합할 수 있도록 할 수 있습니다.

조직은 API를 사용하여 고객 관계 관리(CRM) 및 전사적 자원 관리(ERP) 플랫폼과 같은 엔터프라이즈 시스템 간의 데이터 교환을 지원합니다. CRM 플랫폼에서 고객 주소가 업데이트되면 이 변경 사항을 연결된 시스템 전체에 자동으로 전파할 수 있습니다.

API는 대규모 언어 모델(LLM) 및 머신 러닝 모델과 같은 AI 툴에 액세스하고 이를 애플리케이션 및 워크플로에 통합하는 데 사용됩니다. AI 모델 통합은 다른 서드파티 통합과 동일한 방식으로 이루어집니다. 팀이 복잡한 모델을 내부에서 직접 구축하고 훈련하는 대신 API를 사용하여 외부 모델에 액세스할 수 있습니다.

AI 에이전트도 API를 사용하여 서비스에 액세스하고 작업을 완료하지만, 개발자가 호출할 API와 호출 방법을 미리 결정하는 기존 통합과는 다르게 작동합니다. AI 에이전트는 런타임에 이러한 결정을 내리며, 문제를 분석하고 툴을 선택하여 즉석에서 해결책을 탐색할 수 있어야 합니다. 이를 위해서는 툴을 검색하고 사용 방법을 파악할 수 있는 일관된 방식이 필요합니다.

Anthropic이 도입하고 현재 Linux Foundation에서 관리하는 오픈 소스 표준인 Model Context Protocol(MCP)은 AI 모델 및 에이전트를 외부 애플리케이션 및 시스템과 연결하여 이러한 격차를 해소합니다. MCP 서버는 일반적으로 기존 API 위에서 “범용 번역기” 역할을 하며, MCP와 호환되는 모든 AI 애플리케이션이 사용할 수 있도록 툴의 기능을 표준화된 방식으로 설명합니다. 개발자는 모든 AI 애플리케이션과 모든 툴 간에 맞춤형 통합을 구축하는 대신 특정 툴을 위한 하나의 MCP 서버를 구축하여 호환되는 모든 에이전트에서 사용할 수 있도록 할 수 있습니다. MCP는 AI 애플리케이션용 USB-C 포트에 비유되곤 하며, 여러 맞춤형 커넥터 대신 하나의 표준 커넥터를 제공합니다.

모바일 및 웹 애플리케이션은 API를 사용하여 백엔드와 통신하고 데이터베이스나 비즈니스 로직에 직접 액세스하지 않고도 데이터를 검색하거나 작업을 트리거합니다. 조직은 백엔드 기능을 한 번 구축한 후 API를 사용하여 웹, iOS 및 Android 클라이언트에 제공할 수 있습니다. 백엔드를 다시 구축하지 않고도 새로운 채널을 추가할 수 있습니다.

일부 조직은 여기서 한 단계 더 나아가 백엔드 포 프런트엔드 접근 방식을 사용합니다. 이 방식은 핵심 비즈니스 로직을 한곳에 유지하면서 공유 API 위에 클라이언트별 경량 계층을 추가합니다.

일부 애플리케이션은 클라이언트가 정보를 요청할 때까지 기다릴 수 없습니다. 실시간 및 이벤트 기반 API는 이러한 관계를 뒤집어 클라이언트가 반복적으로 업데이트를 요청할 때까지 기다리는 대신 정보가 변경되거나 특정 이벤트가 발생하는 즉시 정보를 푸시합니다.

Webhook은 특정 이벤트가 발생하면 연결된 시스템에 알림을 보내는 반면, WebSocket 및 gRPC 스트리밍은 지속적인 데이터 흐름을 위해 연결을 계속 유지합니다. 이러한 기술은 금융 거래 플랫폼, 채팅 시스템, 멀티플레이어 게임 및 IoT 센서 데이터 교환을 지원하며, 지속적인 폴링 없이도 시스템을 최신 상태로 유지합니다.