로그인 / 등록 Account

통합

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 릴리스 정책은 다음과 같은 세 가지 접근 방식을 취합니다.

프라이빗

API를 내부에서만 사용할 수 있도록 하며, 기업이 API를 최대한으로 제어할 수 있습니다.

파트너

API를 특정 비즈니스 파트너와 공유하며, 품질 저하 없이 추가 수익원을 창출할 수 있습니다.

퍼블릭

API가 모두에게 제공되며, 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 끌어낼 수 있습니다.

API를 통한 혁신

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

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

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

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

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

제 3자가 퍼블릭 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 개선을 위한 노력

API가 유비쿼터스형 웹 API로 발전하면서 설계 편의성과 구현 유용성을 높이기 위한 노력이 다각도로 이루어지고 있습니다.

SOAP 감소, REST 증가

웹 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 인터페이스를 구축하여 사용자가 별다른 추측 없이도 이를 사용할 수 있도록 합니다.

SOA와 마이크로서비스 아키텍처 비교

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

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

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

API와 Red Hat

Red Hat은 온프레미스 또는 클라우드 환경에서 사용할 수 있는 오픈소스, 오픈 표준인 경량의 종합적인 모듈식 API 솔루션을 제공합니다. 이는 기존 통합 인프라의 유연성을 높이고 보다 신속하게 가치를 제공하는 방식에 있어서 매우 중요한 부분입니다.

미들웨어

Red Hat 통합

포괄적인 통합 및 메시징 기술을 통해 통합 개발을 간소화하여 하이브리드 인프라 전반의 애플리케이션과 데이터를 연결합니다. Red Hat 통합은 민첩성을 갖춘 분산형의 컨테이너화된 API 중심 솔루션입니다.

미들웨어

Red Hat Application Runtimes

클라우드 네이티브 애플리케이션을 개발하고 유지 관리하기 위한 일련의 제품, 툴 및 구성 요소로 애플리케이션 개발 및 제공을 가속화합니다. Red Hat Application Runtimes는 마이크로서비스와 같은 고도로 분산된 클라우드 아키텍처에 대해 경량화된 런타임과 프레임워크를 제공합니다.

미들웨어

Red Hat Process Automation

비즈니스 의사 결정 및 프로세스를 지능적으로 자동화하도록 지원하는 제품 세트를 통해 변화하는 비즈니스 요구 사항에 신속히 대응합니다. 비즈니스 정책과 절차를 실행하고, 비즈니스 운영을 자동화하며, 서로 다른 환경에서 비즈니스 활동 결과를 측정하세요.

API의 더 큰 가능성과 장점을 살펴 보세요