통합 API: SaaS 애플리케이션 간 격차 해소

통합 API(애플리케이션 프로그래밍 인터페이스)는 여러 기본 API와 동시에 통신할 수 있는 추상화 계층 역할을 하는 API입니다.

결과적으로 통합 API의 각 객체와 엔드포인트는 기본 API 의 해당 객체 및 엔드포인트에 매핑됩니다. 이를 통해 SaaS 회사는 통합 API와의 단일 통합을 구축하고 각 기본 API와의 통합을 즉시 제공할 수 있습니다.

이 기사에서는 통합 API, 작동 방식, 과제와 기능, SaaS 회사에 어떤 이점을 제공하는지 자세히 알아봅니다.

통합 API는 어떤 문제를 해결하나요?

SaaS 구매자는 구매한 솔루션에서 원활한 기본 통합을 기대하게 되었습니다. 상호 운용성은 더 이상 있으면 좋은 것이 아니라 필수 사항입니다. 그러나 다른 도구와 이러한 기본 통합을 구축하는 것은 배송 및 유지 관리에 상당한 엔지니어링 리소스가 필요하기 때문에 오늘날 모든 SaaS 회사가 직면한 과제입니다.

모든 통합에 대해 엔지니어는 보안 인증을 구축하고, 타사 앱의 API 문서를 검토하고, 사용 사례를 제공하는 데 필요한 비즈니스 로직을 구현하고, 최종 사용자를 위한 직관적인 구성 환경을 구축해야 합니다.

그리고 이는 새로운 기능 요청이 추가될 때, 타사 API가 주요 변경 사항을 릴리스할 때 통합을 유지하고 업데이트하는 데 관련된 모든 작업과 개발자가 고객이 통합 문제를 디버깅하는 데 소비하는 시간을 설명하지 않습니다.

SaaS 통합 의 맥락에서 통합 API는 각 타사 앱의 API 문서를 이해하는 문제를 해결하기 위한 방법으로 최근 몇 년간 등장했습니다.

핵심적으로 이는 엔지니어링 팀이 통합마다 한 번씩 모든 개별 API의 뉘앙스, 모양 및 명명법을 지속적으로 학습하거나 재검토하는 수고를 덜어줍니다.

통합 API는 어떻게 작동하나요?

통합 API가 실제 사례를 통해 어떻게 작동하는지 살펴보겠습니다.

고객이 CRM과 제품을 통합해 달라고 요청한다고 상상해 보세요. 사용자 기반 전체에서 일부 고객은 Salesforce를 사용하고 다른 고객은 HubSpot을 사용하고 일부는 Dynamics 또는 Pipedrive를 사용합니다.

통합 CRM API는 각 기본 CRM API에 대한 참조를 유지하여 이러한 각 CRM의 API를 추상화합니다.

출처: 파라곤

여기의 예에서는 각 기본 CRM에 "연락처"를 나타내는 개체가 있음을 보여줍니다.

HubSpot은 이를 연락처라고 부르고 Salesforce는 리드와 연락처 개체를 모두 제공하며 Pipedrive는 연락처를 잠재 고객으로 참조합니다. 통합 API 내에서 "연락처" 개체를 호출하면 통합 API는 지정된 서비스의 해당 개체를 참조합니다.

이제 개체 수준 참조가 첫 번째 계층이지만 해당 개체 내에 추상화되는 속성이나 필드도 있습니다. 위의 예에서는 이름, ID, 회사 등에 대한 다른 명명법이 포함될 수 있습니다.

따라서 팀이 여러 CRM 통합을 구축하는 경우 이론적으로는 모든 기본 CRM 통합을 동시에 제공할 수 있는 통합 CRM API를 사용하여 단일 통합을 구축할 수 있습니다.

카테고리별 통합 API

다양한 SaaS 애플리케이션에는 고유한 데이터 모델, 구조 및 기능이 있으므로 모든 API를 단일 API로 통합할 수는 없습니다.

따라서 공급업체는 일반적으로 CRM, 회계 또는 광고와 같은 특정 SaaS 업종과 관련된 여러 통합 API를 제공합니다. 이러한 SaaS 애플리케이션은 상대적으로 유사한 데이터 구조를 가지며 많은 공통 개체 또는 속성을 공유하기 때문입니다.

통합 API를 설계할 때 API 공급자는 통합 API에 포함할 기본 API를 신중하게 선택해야 합니다. 기본 API가 중복될수록 통합 API가 제공할 수 있는 적용 범위가 더 넓어집니다.

그러나 통합 API에 서로 유사하지 않은 애플리케이션이 포함된다면 기본 API가 공유하는 모든 개체와 속성을 표시할 수 없으므로 유용성이 떨어집니다. 예를 들어, CRM과 회계 애플리케이션을 포함하는 통합 API는 "고객" 개체 외부에서는 나머지 애플리케이션의 데이터 모델 간에 겹치는 부분이 많지 않을 수 있으므로 그다지 유용하지 않을 수 있습니다.

통합 API의 이점은 무엇입니까?

통합 API는 수십 개의 통합을 제공하고 유지해야 하는 엔지니어링 팀에 여러 가지 이점을 제공합니다.

API 추상화

엔지니어링 팀은 각 서비스의 개별 API를 배우고 상호 작용하는 대신 통합 API와 인터페이스하는 방법을 카테고리별로 한 번만 배우면 됩니다.

이를 통해 이러한 통합을 더 쉽고 빠르게 구축할 수 있을 뿐만 아니라 통합의 복잡성을 줄이는 데도 도움이 됩니다.

또한 유지 관리와 관련하여 통합 API 공급업체는 기본 API와의 통신을 처리할 책임이 있으므로 팀은 기본 API 중 하나에 대한 주요 변경 사항에 대해 걱정할 필요가 없습니다. 궁극적으로 통합 API 공급업체는 통합이 계속 작동하도록 추상화를 업데이트할 책임이 있습니다.

관리형 인증

통합 API 제공업체는 일반적으로 API 키를 통하든 OAuth를 통하든 기본 API를 사용한 인증의 복잡성을 추상화하는 관리형 인증 서비스를 제공합니다.

여러 API와 직접 통합하는 경우 사용자 자격 증명 관리 및 보안 토큰 새로 고침 정책 보장을 포함하여 각 API에 대한 인증 프로세스를 관리해야 합니다.

각 애플리케이션이 인증을 처리하는 방식에 미묘한 차이가 있다는 점을 고려하면 이는 특히 많은 수의 API를 사용하여 작업하는 경우 번거롭고 오류가 발생하기 쉬운 작업이 될 수 있습니다.

벌채 반출

기본적으로 통합 API는 기본 API에 프록시 요청을 보냅니다. 따라서 타사 애플리케이션에 대한 요청에 대한 데이터를 수집하고 분석합니다. 결과적으로 요청이 실패하면 통합 API 공급자는 이 이벤트를 기록하고 기본 API에서 반환된 오류 메시지에 대한 세부 정보를 제공할 수 있습니다.

이 로깅 기능은 통합 시 발생할 수 있는 문제를 신속하게 식별할 수 있으므로 팀에 유용할 수 있습니다. 여러 타사 API의 로그를 검토하는 대신 통합 API 공급자를 사용하여 로깅 및 오류 보고를 중앙 ​​집중화할 수 있습니다.

디버깅 오류가 있는 경우 통합 API 공급자는 기본 API 자체보다 더 자세한 오류 메시지를 제공할 수 있는 경우가 많습니다. 이는 오류 응답을 분석하고 문제의 근본 원인에 대해 더 많은 컨텍스트를 제공할 수 있기 때문에 오류 진단에 소요되는 시간을 크게 줄이고 사고 대응 시간을 단축할 수 있기 때문입니다.

사전 구축된 사용자 인터페이스

대부분의 통합 API 제공업체는 고객이 통합에 인증할 수 있도록 사전 구축된 인터페이스를 제공하므로 구성 환경을 직접 구축할 필요가 없습니다.

이렇게 하면 팀이 각 통합에 대한 사용자 경험을 디자인하는 부담을 덜어주고, 통합 API에서 구축할 수 있는 수십 가지 잠재적 통합을 고려할 때 시간 절약 측면에서 더욱 복잡해질 수 있습니다.

통합 API를 사용할 때의 문제점은 무엇입니까?

통합 API는 위에서 공유한 이점을 제공하지만 기업이 점점 더 인식하기 시작한 일부 구조적 한계로 인해 무력화됩니다.

사용 사례 제한

통합 API는 기본 API 사이에서 "공유" 객체와 엔드포인트만 추상화할 수 있다는 점을 고려하면 모든 통합에서 비교적 간단하고 일반화 가능한 기능만 구축할 수 있습니다. 이는 통합 API 솔루션의 가장 큰 제한 사항입니다.

또한 통합 API 내에서 지원되는 애플리케이션이 많아질수록 제한도 더 커집니다.

출처: 파라곤

이러한 제한 사항에 대한 몇 가지 예를 살펴보겠습니다.

양립할 수 없는 기능

통합 중 하나와 관련된 기능이나 속성이 포함된 통합 기능을 구축해야 하는 경우 통합 API로는 불가능합니다.

예를 들어, "통합 피드백 API"를 통해 여러 고객 피드백 도구와 통합하고 싶다고 가정해 보겠습니다. 한 도구가 피드백 점수가 1~10 사이인 정량적 모델을 활용하는 반면 다른 도구는 "메모"와 함께 "부정적, 중립적, 긍정적인" 것만 수집하는 경우 통합 API가 이러한 사용 사례를 지원할 수 있는 방법이 없습니다. 이를 하나의 참조로 묶습니다.

누락된 필드

통합을 통해 업데이트해야 하는 속성이 지원되는 통합의 특정 하위 집합에만 사용할 수 있는 경우 해당 속성은 통합 API 내에서 사용할 수 없습니다.

예를 들어, 기본 타사 애플리케이션 중 일부에 우편번호 필드가 있더라도 그렇지 않은 한 통합 API를 통해 우편번호에 속성으로 액세스할 수 없습니다.

사용자 정의 개체 및 필드

기본적으로 통합 API는 각 기본 API에 대해 사전 정의된 참조 세트를 제공합니다. 그러나 사용자 정의 개체나 필드를 혼합에 도입하면 통합 API 공급자는 해당 개체나 필드가 무엇인지 예측할 수 없습니다. 따라서 사용자 정의 개체 또는 필드와 관련된 통합을 지원할 수 없습니다.

고객이 타사 애플리케이션 내에서 사용자 정의 개체 사용을 지원하기 위해 제공하는 통합을 요구하는 경우 이는 큰 방해가 될 수 있습니다.

비율 제한

통합 API를 통해 한 번에 여러 API를 통합하는 경우 각 API의 속도 제한을 알고 통합 논리가 하나의 API에 대한 제한을 초과하지 않는지 확인해야 합니다.

이는 구축하는 논리가 비율 제한에 대한 가장 낮은 임계값을 사용하여 API의 비율 제한을 준수해야 함을 의미합니다. 간단히 말해서, 비율 제한이 가장 낮은 API가 통합을 제한하는 요소가 됩니다. 해당 API의 엔드포인트에 너무 많은 요청을 하려고 하면 통합 API의 다른 API가 기술적으로 동일한 볼륨을 지원할 수 있더라도 요청이 실패하기 시작합니다.

해당 통합을 위해 특정 엔드포인트에 대량 요청을 할 때 속도 제한 오류가 발생하지 않도록 하려면 일괄 처리 또는 조절을 사용하여 각 API에 보내는 요청 속도를 제어해야 합니다.

따라서 더 낮은 속도 제한을 해결하는 것이 여전히 가능하지만 기본 통합 중 하나의 제한 사항을 수용하기 위해 코드베이스에 추가적인 복잡성을 구축하게 됩니다.

보안

통합 API에서는 일반적으로 각 통합에 대해 개별 범위를 선택할 수 있도록 허용하는 대신 API를 사용하기 위해 타사 서비스의 모든 범위에 대한 액세스 권한을 부여해야 합니다.

즉, 통합을 사용하기 위해 사용자를 인증하면 해당 사용자는 통합에 필요한 데이터뿐만 아니라 해당 타사 서비스와 관련된 모든 데이터에 대한 액세스 권한을 귀하에게 부여해야 합니다.

예를 들어, 통합 API를 통해 CRM 통합을 구축하고 있으며 CRM은 영업, 마케팅 및 고객 지원 데이터에 액세스할 수 있습니다. 사용자가 통합을 사용하기 위해 자신의 계정을 인증하면 애플리케이션에 필요한 모든 것이 판매 데이터인 경우에도 세 가지 데이터 세트 모두에 대한 액세스 권한이 부여됩니다.

이로 인해 고객의 보안 문제가 발생할 수 있습니다. 이러한 우려를 완화하려면 액세스를 요청하는 데이터가 무엇인지 사용자에게 투명하게 알리고 해당 데이터가 필요한 이유를 명확하게 설명하는 것이 중요합니다.

또한 공급업체가 일반적으로 통합 API를 호스팅한다는 점을 고려하면 공급업체가 무단 액세스나 위반으로부터 사용자 데이터를 보호하기 위한 강력한 보안 조치를 갖추고 있는지 확인해야 합니다.

독선적인 데이터 모델

공급업체가 다양한 기본 API와 참조 엔드포인트를 조정하는 방법은 공급업체의 의견에 따라 다릅니다. 이는 대부분의 사용 사례에서 문제가 되지 않지만, 귀하가 동의하지 않거나 예상되는 동작을 준수하지 않는 추상화를 제시할 수 있는 경우가 있습니다.

로드맵 제약

여러 범주에 걸쳐 모든 타사 API의 일대일 추상화를 제공하는 임베디드 통합 플랫폼 과 비교할 때, 통합 API 공급업체는 통합 API를 구축한 범주로 제한됩니다.

시간이 지남에 따라 새로운 통합 API를 구축할 수 있고 구축할 예정이지만, 현재 지원되지 않는 카테고리와의 통합을 요청하는 경우 해당 통합이 제공될 때까지 몇 년을 기다려야 할 가능성이 있습니다.

유일한 예외는 공급업체가 요청된 통합이 적합한 범주에 대해 통합 API를 구축하는 경우입니다. 그러나 SaaS 생태계의 폭과 그들이 지원할 수 있는 잠재적 카테고리를 고려할 때 이러한 경우는 거의 없습니다.

통합 API를 사용해야 하는 경우

통합 API가 팀에 적합한 솔루션인지 결정할 때 간단한 의사 결정 기준을 따르면 됩니다.

위의 네 가지 사항에 자신있게 동의할 수 없다면 통합 API를 사용하는 것을 원하지 않을 수도 있습니다.

대신, 임베디드 통합 플랫폼은 통합 개발 프로세스를 간소화하는 데 도움이 되는 보다 포괄적인 도구를 제공하는 동시에 훨씬 더 심층적인 통합을 구축할 수 있게 해주기 때문에 더 나은 솔루션일 수 있습니다.

B2B SaaS 통합 문제

SaaS 제품의 기본 통합 로드맵을 확장하는 데 도움이 되는 솔루션을 결정하는 것은 쉬운 일이 아닙니다. 현재 사용 사례뿐만 아니라 고객이 향후 요청할 수 있는 모든 사용 사례를 해결할 수 있는지 확인해야 합니다.

고객이 요구하는 사용 사례가 특정 카테고리 내의 모든 통합에서 균일하다면 통합 API는 최소한의 노력으로 수십 개의 통합을 제공하는 훌륭한 솔루션이 될 수 있습니다.

이는 새로운 플레이어가 많이 등장하는 개발 중인 시장이며 확실히 B2B SaaS 통합 문제를 해결하는 흥미로운 접근 방식입니다.

종합 가이드에서 API, API의 이점, 과제 및 사용 사례에 대해 모두 알아보세요.