이미 많은 기업들이 디지털 탈바꿈(Digital Transformation)을 통한 기업 가치사슬의 변화 및 새로운 비즈니스로의 전개를 모색하고 있다. 비전과 목표모델 정의, 디지털 조직 도입 및 인력 확보, 운영과 피드백 및 통제 거버넌스 수립 등을 추진하고 있다.

또한 중요한 과제로서 오픈 플랫폼을 구축하여 나름의 디지털 생태계 조성을 위해 노력하고 있다. 고객과 연결, 파트너와 연결, 써드파티와 연결 등을 가능하게 하는 것이 오픈플랫폼이다. 디지털 이전의 시대에는 1대1 연결 방식이었다면 오픈 플랫폼은 1대다 연결방식이다. 보다 광범위하게, 보다 빠르게, 보다 다양하게 연결할 수 있다는 장점이 있다.

이런 이유로 오픈플랫폼 도입은 디지털탈바꿈의 필수이면서 가장 중요한 어젠더가 되어 있다. 잘 알 것 같으면서도, 거리감이 느껴지는 오픈API와 오픈 플랫폼에 대해서 알아보고자 한다. 

[1부] 오픈API란 무엇인가
[2부] 오픈API 디자인과 문서화
[3부] 오픈 플랫폼의 구성요소

 

시스템 분산과 통합

기업의 정보시스템은 매우 다양한 어플리케이션, 기술로 구성되어 있다. 메인프레임을 주로 사용하던 시기에는 대다수의 정보시스템이 메인프레임에 포함되어 있었다. 일부 단위 시스템은 업로드/다운로드 등으로 수작업 처리를 하거나, 핵심 시스템인 메인프레임에 영향을 최소화 하기 위하여 단방향 비동기 시스템 연동을 하고 있었다.

동기 처리는 동기화 시간 동안 시스템 자원이 강제로 할당되어 단위시스템의 장애 발생 시 메인프레임의 메인 처리에 영향을 줄 수 있다. 또한 기술과 비즈니스 환경이 빠르게 발전하고 정보화 사회가 가속화되면서 “Time to Market” 이 중요해지기 시작하였고 해당 업무에 전문화, 최적화 하기 위하여, 차세대 시스템 혹은 시스템 다운사이징 과정을 거쳐 고유의 IT 기술로 구현되어 수많은 단위 시스템으로 나뉘어 지게 되었다. 기업 내 수십 혹은 100개 이상의 단위 시스템 간의 효율적인 연동이 이슈가 되었으며, MCI, EAI/ESB, FEP 등의 채널 및 어플리케이션 통합 기술이 발전하게 되었다.

이러한 연계 미들웨어의 요소 기술인 분산 시스템 연동 기술은 2000년대 초반까지 CORBA, EJB, RMI, COM 등 원격 객체/컴포넌트 통신 방식이(Component Oriented 혹은 Object-Oriented) 활발히 연구되었으나, Stub/Skeleton 객체 등을 통하여 복잡하게 통신하여야 했으므로 점점 인기가 시들어져 가고, HTTP 기반의 웹서비스 기술을 활용하여 비즈니스적인 의미를 가지는 서비스 기능 단위로 묶어서 분산 시스템 연동을 하는 SOA(Service Oriented Architecture)가 유행하게 되었다.

SOAP API

SOA 웹서비스는 원격 서비스를 호출하는 개념이며, 대표되는 것이 SOAP(Simple Object Access Protocol) API 다.

SOAP API는 SOAP Envelope, SOAP Header, SOAP Body 로 구성된 XML 형식으로 구성되어 메시지의 사이즈가 커져서 시스템의 자원의 소모가 상대적으로 많으며, UDDI 에 WSDL 을 배포하고 검색할 수 있게 구성해야 하므로 아키텍처도 복잡하다.
 

[그림 1] SOAP API 퍼블리싱 및 호출 개념도

 

REST API

반면에, SOAP 보다 간결한 아키텍처 스타일로 최근 많이 사용되고 있는 REST(REpresentational State Transfer) API 는 원격 자원을 호출하는 개념인 ROA(Resource Oriented Architecture) 웹서비스이다.

REST는 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍처 스타일이고 REST API 는 REST 아키텍처 스타일을 따르는 API 이며, 일부 아키텍처 제약을 따르는 것을 RESTful API 라고 한다. REST 창시자인 Roy Fielding 은 "하이퍼텍스트를 포함한 self-descriptive 한 메시지의 uniform interface를 통해 리소스에 접근하는 API" 라고 정의하였다.

Uniform Interface 제약조건은 다음의 4가지이다.

• identification of resources
• manipulation of resources through representations
• self-descriptive messages
• hypermedia as the engine of application state (HATEOAS)

식별되어(Identification) 요청된 Resource를 실행해 봤더니(manipulation), 그 시점에 해당 Resource를 대표하는(Representation) 상태를(State) 응답 내용 자체만으로도 처리 결과가 이해가 가능한 메시지 형태를 만들고(self-descriptive messages), 응답 시점에 호출 가능한 어플리케이션을 Hyperlink 형태로 포함시켜(HATEOAS) 전송하는(Transfer) API 라는 것이다.

 
 
[그림 2] REST API 요청 및 응답 예시

Account 라는 자원에 GET 이라는 조작을 했을 때 표현되는 상태를(balance, currency, value) 응답 메시지만으로도 이해 가능하게끔 쉽게 기술하고(200 OK, JSON), 또한 이 리소스의 상태를 바꿀 수 있는 하이퍼링크를(deposit, withdraw, transfer, close) 포함시켜 보낸 것이다.

SOAP 에서는 WSDL(XML)을 분석하여 이에 맞는 SOAP 메시지(XML)를 요청하고 응답을 받아 해석해야 하는 반면에, REST API는 친숙한 HTTP URI를 간결한 JSON 형태로 호출하고 응답을 받을 수 있어 아키텍처가 단순하고 사용하기 편하며 실행 속도가 빠르다.

 

API의 역할별 분류

API를 어떤 목적으로 사용하는가에 따라 다음과 같이 나눌 수 있으며, 오픈 플랫폼에서는 대외적으로 Open API, Partner API, Composite API를, 내부 시스템에서는 Internal API, Composite API를 주로 활용한다.

Open API: 혹은 Public API, 외부에서 제약없이 호출할 수 있도록 공개된 API. 오픈 플랫폼에서 기본적으로 제공되어야 할 API 형태이다.

Partner API: 혹은 제휴 API, 핀테크기업 등 제휴업체와 사전 협의 후 제작하여 제공하며 이용 라이선스, 권한 등이 별도로 필요하다.

Internal API: 혹은 Private API, 기업 내부 시스템에서만 사용될 수 있으며, ESB 시스템이나 내부용 API Gateway 에 등록되어 호출되거나, API 서버에 직접 등록되어 Client 에서 호출될 수도 있다.

Composite API: 복수의 API를 한번에 동기적으로 호출하는 방식으로 처리 속도를 높일 수 있으며, 개별 API 의 성공, 실패를 하나의 Response 에 Composite Subrequest 로 구별하여 되돌려준다.
 

[그림 3] Salesforce의 Composite API 호출 예시

1부 정리

비즈니스가 다양해지고 서비스 라이프사이클이 빨라지면서 단일 메인프레임 시스템으로부터 다양한 기술로 구현된 단위시스템으로 분산되었고, 분산 시스템 간의 어플리케이션 통합 연계를 위하여, 시스템 내부 컴포넌트 간 호출에 주로 사용되던 API가 웹서비스 기술과 만나 HTTP 기반의 웹 API로 발전하였다. SOAP 기술의 복잡함으로 인하여 SOAP API 보다는 REST API가 주로 사용되고 있으며, REST 아키텍처 제약 중 일부를 따르는 것을 RESTful API 라고 한다. 웹 API의 용도에 따라 Open API, Partner API, Internal API, Composite API 로 분류된다.

- 끝 -