애플리케이션 커뮤니케이션에서 API와 메시징의 차이

Phil Wilkins | Cloud Developer Evangelist, Oracle | 2022년 12월

소프트웨어에 있어 다른 소프트웨어와의 소통은 필수입니다. 애플리케이션의 한 부분에 위치한 소프트웨어가 동일한 애플리케이션의 다른 부분에 서비스를 요청하거나 데이터를 상호 교환해야하는 경우도 종종 발생합니다. 하나의 애플리케이션이 전혀 다른 애플리케이션에게 서비스를 요청하거나 서로 데이터를 교환해야 하는 경우도 생깁니다.

이런 종류의 커뮤니케이션에 항상 사용되는 두 가지 매커니즘이 있습니다. 바로 애플리케이션 프로그래밍 인터페이스(API)와 메시징입니다.

종종 API와 메시징의 차이를 혼동하는 사람들이 있습니다. 이 두 용어가 굉장히 모호한 방식으로 사용되고 있기 때문입니다. API라는 약어는 그 자체로 명료한 의미를 가지고 있지만, 아래에서 설명할 여러 가지 이유로, 다양한 의미로 사용되곤 합니다. 메시징은 거의 모든 시스템 간 커뮤니케이션의 수식에 굉장히 광범위하게 사용되는 용어입니다. 그러면 지금부터 API와 메시징의 진정한 의미를 명확히 설명하도록 하겠습니다.

API의 자세한 정의

광범위하게 설명하자면 API는 소프트웨어가 서비스 요청을 수신하고, 이에 대응하는 방식을 정의한 계약이라고 할 수 있습니다. 그리고 이 계약은 소프트웨어 개발자들에 의해 수립됩니다.

꽤 간단해 보이죠? 한 단계만 놓고 보자면 그렇습니다. 그러나 실제로 API가 내포한 의미는 맥락에 따라 달라집니다. 약어를 풀어보면 API는 소프트웨어의 한 조각이 소프트웨어의 다른 조각과 상호 작용할 수 있게 하는 인터페이스 또는 '계약'에 관한 것입니다. 때로 API에 관한 대화는 고도의 아키텍처적 정의를 중심으로 흘러가기도 하고, 개발자가 API를 구현하는 특정한 방식에 대한 세부적인 내용으로 이어지기도 합니다.

API에 대해 다룬 일부 책 및 기사들은 API를 문(door)에 비유하기도 합니다. 문에 대한 묘사를 통해 API의 다양한 특징을 정의하죠. 예를 들어 자동으로 열리는 편의점 문이 될 수도 있고, 은행의 금고를 지키는, 초고도 보안 능력을 갖춘 문이 될 수도 있습니다. 애플리케이션의 계약(문의 특징)은 다음과 같은 고려 사항을 다루는 데 도움이 되어야 합니다:

상위 수준에서 API의 역할은 무엇인가요? 문으로 비유했는데, API는 고객이 멈춰서 뭔가를 만지거나 어떤 행동을 하지 않아도 자동으로 열리나요(편의점 문) 아니면 액세스를 제어하고 문 뒤에 있는 자산을 보호하나요(은행 금고)?
소프트웨어가 제 기능을 하도록 지원하기 위해 어떤 페이로드(전송되는 데이터)가 필요한가요? 예를 들어 소프트웨어가 은행 계좌번호와 보안 인증을 수신하고, 해당 은행 계좌의 잔액을 그 응답으로 제공할 수 있습니다.
이 서비스를 수행하려면 어떤 데이터가 교환되어야 하나요? 예를 들어 유효한 계좌번호와 보안 인증의 모습이 정확히 무엇인지 정의하는 일, 응답의 콘텐츠를 정의하는 일이 중요합니다. 여기에서는 세부 정보가 중요합니다. 모호한 설명은 오류를 야기할 수 있습니다.
문의 주소란 무엇인가요? 이건 보통 요청에 대한 보편적인 리소스 식별자(URL)가 형성되는 방식을 의미합니다. 즉 요청자가 API와 실제로 소통하는 방식을 말합니다.
커뮤니케이션에 어떤 프로토콜이 사용될 예정인가요? HTTP와 FTP처럼 잘 알려진 기술에서부터 STOMP와 QUIC과 같이 특수 프로토콜까지 다양합니다.
API 사용자가 준수해야 하는 이용약관은 무엇인가요? 암호화 세부 사항, API 호출 빈도 제한, 상용 서비스에 대한 차지백(charge-back) 매커니즘 등이 포함될 수 있습니다.
API는 어떤 것들을 약속하나요? 특정 기간 내에 요청이 확인 또는 수행될 것을 약속하는 API를 위한 서비스 수준 보증이 포함될 수 있습니다.

애플리케이션 개발에서의 메시징 정의

API가 소프트웨어가 서비스 요청을 송수신하는 방법을 정의하는 용어라면, 메시징은 한 시스템이 다른 시스템으로 정보를 전송하는 프로세스를 의미합니다. 키워드는 '프로세스'입니다.

다음과 같은 방식으로 생각해 볼 수 있습니다:

메시징은 정보(메시지)의 덩어리를 서비스 요청자에게서 서비스 제공자(종종 브로커라고 알려진 서드파티를 사용하여)에게로 전송하는 프로세스를 말합니다.

실제 세계의 비유를 사용하기 위해 고객에게 문자 메시지를 전송하는 기업을 예로 들어보겠습니다. 이 서비스 제공자는 수신자의 휴대폰 번호를 알아야 합니다. 그래야 모바일 통신사가 메시지를 전달할 수 있으니까요. 그러나 통신사 입장에서 페이로드 자체는 무엇이든 상관 없습니다. 문자 메시지가 영어, 스페인어, 일본어, 심지어 이모티콘 중 어떤 언어로 작성되었는지 여부를 알 필요도 없죠.
메시징은 이 메시지를 발신자에게서 고객에게로 전달하기 위해 이루어지는 모든 막후의 활동들을 지칭합니다.

사용자나 사용자의 고객은 메시징 프로세스의 작동 원리를 이해할 필요가 없습니다. 그저 통신사와 스마트폰 제조사가 각자의 일을 제대로 했을 것이라고 믿기만 하면 되죠. 마찬가지로 통신사 역시 페이로드를 이해할 필요가 없습니다. 그저 페이로드가 혼동이나 왜곡 없이 적합한 사람에게로 잘 전달되게 하기만 하면 됩니다.

대부분의 경우 기술 제약 조건을 충족하기만 하면 메시징 플랫폼이 페이로드에 대해 우려할 이유는 없다는 사실을 재차 강조하고 싶습니다. 앞선 비유로 다시 돌아가 보자면, 스마트폰과 통신사는 사용자의 문자 메시지가 영어로 작성되었든, 이모티콘으로 작성되었든 상관하지 않습니다.

API, API 플랫폼, API 관리의 구성 요소에 대한 자세한 내용을 확인해 보세요.

API와 메시징은 엔터프라이즈 시스템 안에서 함께 작동합니다.

엔터프라이즈 소프트웨어 시스템은 여러 개의 별도의 실행 가능한 프로세스에서 구축됩니다. 따라서 프로세스 간 커뮤니케이션(IPC)이 필요하죠. 이때 이루어지는 커뮤니케이션은 복잡할 수 있고, 트랜잭션 수행을 위해 형식이 엄격하게 지정된 수많은 데이터를 사용한 많은 API 호출을 여러 차례 반복해야 할 수 있습니다. 비즈니스 니즈 충족을 위해서는 이 트랜잭션들이 정교하게, 올바른 순서로 통합관리 및 완료되어야 합니다.

고객의 구매 주문을 예로 들어보겠습니다. 이 프로세스는 고객의 데이터베이스에 액세스하고, 인벤토리 데이터베이스, 회계 시스템, 송장 생성 시스템, 신용카드 청구 시스템을 쿼리하고, 재고 및 고객 계정을 조정하고, 웨어하우스 요청을 생성하고, 배송 요청을 시작할 수 있어야 합니다. 이 모든 작업들은 올바른 순서로 진행되어야 하고 정확하게 완수되어야 합니다.

과거에는 이와 같은 상호작용이 파일 시스템 또는 데이터베이스 등 공유 스토리지의 형식을 사용해 수행되었습니다. 그러나 현대의 모던 엔터프라이즈 시스템에 들어 프로세스가 직접 서로 상호 작용을 할 수 있게 되면서(주문에 대한 재고가 이전 주문을 통해 이미 할당되는 등) 프로세스 및 문제 해결 속도가 빨라졌습니다.

동기 및 비동기 동작

우리는 커뮤니케이션의 본질을 동기 또는 비동기로 특징지을 수 있습니다. 동기 커뮤니케이션은 커뮤니케이션에 참여하는 모든 당사자가 반드시 커뮤니케이션 과정에 실재해야 하고, 재전송이 가능해야 함을 의미합니다. 앞선 주문 사례에서 전자 결제에 관여하는 시스템은 반드시 실시간 상호 작용 시에도 가용해야 합니다. 커뮤니케이션이 비동기적인 성격을 띄는 경우도 있습니다. 이 경우 커뮤니케이션을 원하는 시스템 당사자가 꼭 커뮤니케이션 순간에 실재할 필요가 없습니다. 서로에게 이메일을 작성하는 상황을 떠올려보면 이해가 쉽습니다. 비동기 커뮤니케이션을 수행하기 위해서는 정보를 앞뒤로 전달할 수 있게 해 주는 중개자가 필요합니다.

이 복잡한 엔터프라이즈 메시징 시스템은 다양한 종류 또는 패턴으로 제공됩니다:

서비스 버스. 서비스 버스는 다양한 프로세스 간 접착제 역할을 하며, 앞서 언급한 복잡한 트랜잭션 속 각 프로세스를 통합관리해 줍니다. 서비스 버스 시스템에는 일반적으로 부가가치 기능들이 통합됩니다. 한 형식의 페이로드를 다른 형식으로 번역하는 기능(문자 메시지 비유에서 영어를 프랑스어로 번역하는 등), 메시지 콘텐츠를 기반으로 메시지 경로를 지정하는 기능, 심지어 복잡한 트랜잭션의 상태를 기반으로 의사결정을 내리는 기능이 여기에 포함됩니다. 예를 들어 A 및 B 작업을 병렬로 진행하거나, B 작업이 성공적으로 완료된 경우에만 C 작업을 진행하게 하거나, B 작업이 실패한 경우 D 작업이 진행되게 하거나, D작업이 실패한 경우 사람의 개입을 요청하게 할 수 있습니다.

서비스 버스 스타일의 메시징 기능은 종종 스마트 파이프를 사용하는 것으로 묘사되곤 합니다. 제공자와 소비자 간에 존재하는 '파이프' 내에 메시징 경로 지정 및 일정 관리 기능 등 인텔리전스가 추가되기 때문이죠. 이 기능은 통합관리라고도 불립니다.

메시지 제공자는 메시지를 공급하는 서비스 버스를 호출합니다. 그러면 서비스 버스가 메시지를 받아 이를 소비자에게 라우팅합니다. 라우팅이 진행되는 동안 메시지에는 변형 로직 및 필터링이 적용될 수 있습니다.

서비스 버스는 메시지 버스와 동의어입니다. 이 기술들이 처음으로 서비스 지향 아키텍처(SOA) 솔루션으로 진화했을 때 메시지 버스와 서비스 버스는 다소 차이가 있었습니다. 하지만 현재는 이 둘 간에 실질적인 차이는 없습니다. 심지어 이제 명칭 자체를 점점 버스로 줄여가는 추세입니다.
웹 서비스: 가장 광범위하게 설명하자면 웹 서비스라는 용어는 두 개의 프로세스 간 직접 동기 커뮤니케이션을 의미합니다. 보통 TCP와 HTTP 프로토콜(또는 HTTPS와 HTTP/2 등의 변형)을 사용하는 프로세스를 말합니다. 제공자 측에서 여러 동시 클라이언트 연결을 지원하는 것이 일반적이긴 하지만, 소비자와 클라이언트는 지점 간 연결로 실현됩니다. 두 프로세스 간 프록시(네트워크 방화벽에서 API 게이트웨이 및 웹 캐시로)와 네트워크(스위치 및 라우터) 중개자가 존재할 수 있지만, 제공자도 소비자도 이를 인지하지는 못합니다.
메시지 제공자는 소비자와 직접 커뮤니케이션합니다. 전송 프로세스는 가용 상태의 양 당사자에 의존합니다.
메시지 브로커:메시지 브로커는 메시지 제공자와 메시지 소비자 사이의 중재자이며, 서비스 버스 및 웹 서비스 모두와 공통점을 가집니다.

브로커는 메시지 발신자와 수신자 사이에 상주합니다. 또한 커뮤니케이션된 메시지를 수신해 수신자가 메시지를 소비할 때까지 이를 저장합니다. 즉 수신자의 즉각적인 가용 여부와 상관 없이 전송된 메시지를 처리할 수 있습니다. 이와 같은 종류의 커뮤니케이션은 종종 비동기 또는 '발사 후 망각형'이라고 묘사됩니다. 브로커가 운영 상태로 유지되는 한 특정 시간에 메시지가 전송될 것이라는 사실을 보장할 수 있기 때문입니다.

웹 서비스와의 유사성은 클라이언트와 브로커 간의 연결성이 지점 간 연결로 표시된다는 데에서 찾을 수 있습니다. 메시지 브로커는 기능상 눈에 보이지 않습니다.

서비스 버스와의 유사성은 브로커가 부가가치 서비스를 제공한다는 데서 찾을 수 있습니다. 특히 브로커가 수신자가 가용 상태가 될 때까지 수신한 메시지를 보관한다는 점에서 그렇습니다. 보다 강력한 서비스 버스와는 달리 메시지 브로커는 단순한 것들을 이해하는 능력 외에도 최소한의 인텔리전스를 보유합니다. 예를 들어 어떤 목적지가 특정 메시지 수신을 원하는지, 해당 목적지에서 메시지가 시의적절하게 소비되지 않는 경우 어떻게 해야 하는지 등을 판단합니다.

브로커가 적용된 커뮤니케이션 스타일은 단순 망 제공자(dumb pipe)를 보유한 것으로 묘사할 수 있습니다. 브로커가 최소한의 인텔리전스를 보유하고 있고, 메시지를 전송 또는 수신해야 하는 시점에 무엇이 필요한지를 파악하기 위한 엔드포인트를 필요로 하기 때문입니다. 이 스타일은 (서비스 버스의 더욱 인텔리전트한 통합 관리와 반대되는 개념으로) 코레오그라피라고 설명할 수 있습니다.

메시지 제공자는 메시지를 브로커에게 전달합니다. 그러면 브로커가 소비자가 메시지를 요청하거나 메시지를 수신할 수 있는 상태가 될 때까지 이를 보관합니다. 제공자는 소비자에게 종속되지 않습니다.

엔터프라이즈 메시징에서 스트리밍의 역할

일부 스트리밍 기술이 데이터 프로세싱의 한 요소를 지원하긴 하지만, 이 논의에서는 스트리밍을 메시징의 특별한 형태로 이해할 수 있습니다. 이 맥락 속에서의 스트리밍은 웹 서비스 또는 메시지 브로커의 커뮤니케이션 실행 여부와 관계 없이 IPS 기술을 통해 지속적인 이벤트 흐름을 동일한 목적지로 전송하는 동작을 의미합니다. (서비스 버스가 포함되는 경우는 매우 드문데, 데이터가 지나치게 많고, 지나치게 빠르게 흐르기 때문에 서비스 버스의 경우에는 추가적인 인텔리전스가 필요하기 때문입니다.)

스트리밍은 스트림 내 지속적인 데이터 흐름과 함께, 보통 거의 실시간 또는 낮은 대기 시간 연결성을 기대합니다. 이와 같은 특징은 당연한 것으로 여겨지는데, Netflix와 같은 서비스를 흔히 비디오 스트리밍 서비스라고 부르는 것을 고려하면 이해하기 쉽습니다. 제공자가 새로운 비디오 비트를 전송하는 동안 또는 메시지 브로커가 한 형식에서 다른 형식으로 비디오를 전송하는 동안 비디오 콘텐츠가 중단됐다가 시작되기를 반복하는 상황은 원치 않을 테니까요.

웹 서비스 스트리밍에 일반적으로 사용되는 기술은 WebSockets, gRPC 스트림, GraphQL 구독이 있습니다. 브로커가 적용된 메시징 스트림의 경우(Kafka와 같은 기술 사용) 전송된 이벤트의 '슬라이스'를 확인하기 위해 브로커의 작동 방식을 활용할 수 있습니다. 그 과정에서 스트림 자체에 대한 정보를 포함한 가치 있는 인사이트를 얻을 수 있으며, 이와 같은 이유로 스트리밍 분석이라는 용어가 사용됩니다.

스트리밍 분석에 적용되는 로직은 정교할 수 있지만, 메시지 브로커는 결정 또는 메시지 변경을 수행하지는 않습니다. 브로커가 단순 망 제공자로 여겨지는 이유가 바로 여기에 있습니다. 이런 종류의 스트리밍 분석 기능은 종종 Kafka Streams와 같은 기술을 통해 구현됩니다.

API 및 메시징 산업 표준

API와 메시징 시스템 자체에 대한 설명은 간단하지만 그 세부 내용과 기술 특성은 대단히 복잡합니다. 모호함은 발 들일 틈이 없죠. 정확한 산업 표준과 설명서가 반드시 필요하며, 이 표준이 적용된 최적의 사례가 제공되는 것이 이상적입니다.

지난 10여년간 특히 API에게 있어 이 영역은 발전의 영역이었습니다. 업계는 웹 서비스의 한 형태이자 아마도 모던 엔터프라이즈 소프트웨어에서 가장 널리 사용된 API 유형인 REST 기반 API용 OpenAPI 사양을 수용했습니다.

API(및 스트리밍)와 더불어 메시지 및 메시지 전송의 속성들을 정의 및 묘사하기 위한 추가 표준들이 수없이 많이 있습니다. 여기에는 프로토콜 버퍼(Protobuf라고도 불리며 gRPC와 함께 사용됨)가 포함되며 최근에는 GraphQL, JSON Schema, YAML이 추가되었습니다.

비동기 메시징 영역에서는 지난 수년간 AsyncAPI라고 불리는 정의를 중심으로 통합 노력이 성공을 거두었습니다. 이는 OpenAPI 및 타 진화하는 표준으로부터 아이디어를 얻어 많은 메시징 요구사항을 해결하는 방식입니다.

모던 분산형 애플리케이션은 여러 서비스의 모음으로 구현되며, 이 서비스들은 각각 별도의 소프트웨어 조각으로 구성됩니다. 각 소프트웨어 조각은 동일한 서버에서 실행될 수도, 그렇지 않을 수도 있습니다. API는 이 소프트웨어 조각들이 서로 커뮤니케이션을 통해 서비스를 요청하거나 정보를 교환할 수 있게 하는 방법을 제공합니다. 메시징 시스템은 비동기 커뮤니케이션 강화 및 API 호출을 위한 지능형 중재자 제공을 위한 인프라를 제공합니다. 그 방식은 대단히 단순할 수도(스마트폰 문자 메시지 작동 방식), 아주 복잡할 수도(복잡한 다단계 비즈니스 거래 통합관리) 있습니다. API를 사용해 직접 커뮤니케이션하는 분산형 서비스는 말할 것도 없죠. 다행히 진화하는 기술과 표준은 데이터베이스 호출에서부터 미디어 스트리밍에 이르기까지 모든 영역에 API를 사용할 수 있게 해 줍니다. 그리고 이 API와 메시징 표준은 지속적으로 진화와 발전을 거듭하며 모던 분산형 소프트웨어 아키텍처로의 이전을 더욱 빠르고, 손쉽고, 안전하게 만들고 있습니다.