2021.06.02

"IFTTT, TDD 방법론, 로우코드"…효과적인 API 검증 방법 3가지

Isaac Sacolick | InfoWorld

많은 소프트웨어 개발자들이 새 애플리케이션을 구축하거나 개선하는 작업을 할 때 분명 한번쯤은 직면했을 상황을 하나 살펴보자.
 
제품 소유자가 새로운 SaaS 애플리케이션과의 통합을 필요로 하는 에픽과 여러 기능을 정의한다. 소유자는 SaaS 플랫폼이 API에 어떤 기능을 노출하는지에 관해 여러 전제를 하고, 이 전제를 워크플로우와 프론트 엔드 애플리케이션 요구사항에 반영했다. 소유자는 애자일 개발 팀이 가능하다면 한 번의 스프린트에서 스파이크를 완료해 이러한 전제를 검증할 것으로 기대한다.
 
문제는 이것이다. 개발 팀이 얼마나 쉽게 조사를 수행하고 전제를 검증할 개념 증명을 이상적으로 구현할 수 있는가?
 
이러한 검증은 어떤 트랜잭션과 뷰가 노출되었는지에 관해 엔드포인트를 점검하는 것에 그쳐서는 안 된다. 데이터 품질도 확인하고 성능을 고려하고 궁극적으로 가용한 API를 통해 요구사항을 충족하려면 어떤 개발 작업이 필요한지를 판단해야 한다. 또한 개발자들은 이 평가 작업의 일부로 필요한 인증 및 기타 보안 고려 사항도 점검해야 한다.
 
스프린트에서, 가급적 너무 많은 코드를 쓰지 않으면서 이 과제를 수행할 수 있을까?

API와의 통합은 일반적인 애플리케이션 및 데이터 통합 요구사항이므로 개발 팀은 기능을 검토하고 전제를 테스트하는 데 도움이 되는 툴 사용을 고려해야 한다. 또한 많은 SaaS, 엔터프라이즈 및 기타 써드 파티 툴과 통합하는 조직은 개발 속도를 높이고 견고한 통합 기능을 제공하고 통합과 관련된 운영 기능도 수행할 수 있는 통합 플랫폼을 고려해야 한다.

API 검증을 위한 세 가지 접근 방법을 소개한다.
 

IFTTT 플랫폼으로 가능한 통합은 무엇인가?

요구사항이 일반적으로 사용되는 SaaS 플랫폼과의 통합이라고 가정해 보자. 이 경우 간단한 접근 방법은 IFTTT(If This Then That) 플랫폼이 가능하게 해주는 작업과 트리거, 그리고 반환되는 데이터 유형과 형식, 품질을 검토하는 것이다.
 
재피어(Zapier)는 트리거와 작업을 검토 및 테스트할 수 있는 3,000개 이상의 앱과의 통합을 제공한다. 통합은 한 앱에서 다른 앱으로 새 레코드를 푸시하는 데 사용되는 간단한 형태일 수도 있고, 더 복잡해서 필터와 경로, 포맷 및 기타 기능을 활용할 수도 있다. 후자는 한 앱의 트리거가 적절한 레코드를 찾아 두 번째 앱에서 이를 업데이트해야 할 때 필요한 경우가 많다. 포맷 기능은 데이터 정제와 기타 데이터 조작도 가능하게 해준다.
 
재피어는 통합을 테스트하고 모니터링하기 위한 툴도 제공한다. 이러한 운영 기능은 다양한 시나리오가 다양한 유형의 작업을 트리거하는 복잡한 통합과 API를 검증할 때 매우 유용하다.
 
그 외의 IFTTT 툴로는 Automate.io, IFTTT, 인티그레이틀리(Integrately), Tray.io, 워카토(Workato)가 있다. 이와 같은 툴은 빠른 출발을 위해 API 개념 증명을 테스트하고 개발하는 데 도움이 될 수 있다. 그러나 개발 팀은 개발자가 이러한 툴을 통해 필요한 통합을 생성, 테스트, 운영화할 수 있는 경우 프로덕션에서도 툴 사용을 고려해야 한다.
 

테스트 주도 개발 접근 방법을 사용하여 API 검증

필요한 통합이 상용이 아닌 써드파티 API와 관련되거나 IFTTT 플랫폼에 연결되지 않는 특정 산업용 플랫폼인 경우에는 어떻게 될까? 또는 복잡한 통합, 워크플로우 조율, 데이터 조작 또는 데이터 볼륨으로 인해 IFTTT 플랫폼의 실용성이 떨어지는 경우에는 어떻게 해야 할까?
 
개발 팀은 테스트 주도 개발(TDD) 방법론을 사용해서 API를 검증하고 프로토타입을 진행하는 방법을 고려할 수 있다. 이 접근 방법에서 개발 팀은 복합 서비스 또는 애플리케이션에서 직접 API 기능을 사용하기 전에 단위 테스트와 더 높은 수준의, 조율되고 자동화된 지속적 테스트를 구축한다.
 
TDD는 예상 사용 및 경계 사례를 정의하고 문서화하므로 API와 마이크로서비스 개발에서 강력한 접근 방법이다. 테스트 자동화는 하향 영향을 일으킬 수 있는 서비스에 대한 변경을 파악하는 데 도움이 된다.

이 접근 방법은 써드파티 API를 소비할 때도 마찬가지로 효과적이다. 개발자는 포스트맨(Postman)과 같은 툴을 사용해서 API 사양을 가져오고 API를 이해하고 테스트 모음을 만든 다음 이 테스트를 지속적 통합/지속적 제공(CI/CD) 파이프라인 및 기타 데브옵스 툴에 통합할 수 있다. 그 외에 카탈론(Katalon), 래피드API(RapidAPI), 파라소프트(Parasoft), 스마트베어 레디API(SmartBear ReadyAPI)와 같은 툴이 있다.

이러한 테스트는 API 검증에도 도움이 되지만, 나중에 개발자가 자동화된 지속적 테스트를 위해 사용할 수도 있다. 프로덕션에서는 써드 파티 API 변경으로 인해 테스트가 중단되는지, 이 API를 사용하는 서비스와 애플리케이션에 대한 검토 및 수정이 필요한지, 필요하다면 언제 필요한지를 확인하는 데 도움이 될 수 있다.
 

로우코드 통합 플랫폼을 사용하여 재사용 가능한 게이트웨이 구축

여러 플랫폼과 통합할 계획이고, 수많은 서비스와 애플리케이션에서 이 통합을 재사용해야 한다면? 회사에서 허브스팟(HubSpot), 워크데이(Workday), SAP 또는 기타 플랫폼과의 통합이 필요한 직원 온보딩 애플리케이션, 마케팅 툴, 현장 운영 워크플로우를 맞춤 구성하는 중일 수도 있다.
 
필자는 부미(Boomi)의 제품 책임자인 에드 마코스키와 중간 및 대규모 조직에서 데이터 공유와 워크플로우 및 협업 구현 측면의 기회에 대해 논의한 적이 있다. 이러한 조직에는 API 검증 이상이 필요하다. 이들은 확장 가능한 통합 프로세스를 요구한다. 마코스키는 여기서 발생하는 어려움에 대해 “모든 데이터 소스를 연결하고, 조직 내의 모든 데이터를 이해하고, 이 데이터를 통합하고, 서비스를 개발하고, 사용자 주도 워크플로우를 만들고, 이를 사용자와 접하는 프론트 엔드 애플리케이션에 노출하는 것과 같은, 종단간에 걸쳐 모든 사람을 모든 것에 연결하는 이 전체적인 그림을 그려야 하는 문제를 개발자가 어떻게 해결할 수 있을까?”라고 표현했다.
 
부미와 같은 통합 플랫폼에는 빠른 개발, 테스트 및 배포를 위해 일반적인 SaaS 및 엔터프라이즈 플랫폼 및 로우코드 툴에 대한 커넥터가 포함된다. 점 대 점 통합을 만드는 대신 여러 하향 애플리케이션과 복합 서비스에 하나의 통합을 활용할 수 있다.
 
그 외의 통합 플랫폼에는 지터비트(Jitterbit), 뮬소프트(MuleSoft), PMG, 스냅로직(SnapLogic)이 있다. 애플리케이션 통합 또는 서비스형 통합 플랫폼(iPaaS)은 사용의 용이함, 데이터 관리 기능, 운영 기능, 셀프 서비스 옵션을 포함한 다양한 기능에서 상호 차별화된다.
 
통합 플랫폼은 다양한 비즈니스 요건과 부서 워크플로우에 맞추어 환경을 맞춤 구성하고자 하는 조직에 매우 전략적인 수단이다. 예를 들어 온보딩 애플리케이션을 맞춤 구성해서 특정 역할로 작업에 참여하는 사람들 위해 기본적인 단계만 보여줄 수도 있고, 새로 채용한 기술자가 장비를 선택하도록 하거나 영업 담당자가 출장 기본 사항을 설정하도록 허용할 수도 있다.
 
개발자가 기억해야 할 중요한 점은 API 검증은 통합 과정의 첫 단계에 불과하다는 것이다. 그 이후 개발자는 재사용 및 확장이 가능하고 견고하고 지원되는 통합을 만들어야 한다. 이를 위해서는 비즈니스 서비스 수준 목표와의 통합을 지원하도록 설계된 운영 환경에 통합을 연결해야 한다. 통합 및 iPaaS 플랫폼은 이러한 옵션을 제공하며, 통합을 핵심 개발 및 운영 역량으로 삼고자 하는 조직에게 매우 큰 이점을 제공할 수 있다. editor@itworld.co.kr    



2021.06.02

"IFTTT, TDD 방법론, 로우코드"…효과적인 API 검증 방법 3가지

Isaac Sacolick | InfoWorld

많은 소프트웨어 개발자들이 새 애플리케이션을 구축하거나 개선하는 작업을 할 때 분명 한번쯤은 직면했을 상황을 하나 살펴보자.
 
제품 소유자가 새로운 SaaS 애플리케이션과의 통합을 필요로 하는 에픽과 여러 기능을 정의한다. 소유자는 SaaS 플랫폼이 API에 어떤 기능을 노출하는지에 관해 여러 전제를 하고, 이 전제를 워크플로우와 프론트 엔드 애플리케이션 요구사항에 반영했다. 소유자는 애자일 개발 팀이 가능하다면 한 번의 스프린트에서 스파이크를 완료해 이러한 전제를 검증할 것으로 기대한다.
 
문제는 이것이다. 개발 팀이 얼마나 쉽게 조사를 수행하고 전제를 검증할 개념 증명을 이상적으로 구현할 수 있는가?
 
이러한 검증은 어떤 트랜잭션과 뷰가 노출되었는지에 관해 엔드포인트를 점검하는 것에 그쳐서는 안 된다. 데이터 품질도 확인하고 성능을 고려하고 궁극적으로 가용한 API를 통해 요구사항을 충족하려면 어떤 개발 작업이 필요한지를 판단해야 한다. 또한 개발자들은 이 평가 작업의 일부로 필요한 인증 및 기타 보안 고려 사항도 점검해야 한다.
 
스프린트에서, 가급적 너무 많은 코드를 쓰지 않으면서 이 과제를 수행할 수 있을까?

API와의 통합은 일반적인 애플리케이션 및 데이터 통합 요구사항이므로 개발 팀은 기능을 검토하고 전제를 테스트하는 데 도움이 되는 툴 사용을 고려해야 한다. 또한 많은 SaaS, 엔터프라이즈 및 기타 써드 파티 툴과 통합하는 조직은 개발 속도를 높이고 견고한 통합 기능을 제공하고 통합과 관련된 운영 기능도 수행할 수 있는 통합 플랫폼을 고려해야 한다.

API 검증을 위한 세 가지 접근 방법을 소개한다.
 

IFTTT 플랫폼으로 가능한 통합은 무엇인가?

요구사항이 일반적으로 사용되는 SaaS 플랫폼과의 통합이라고 가정해 보자. 이 경우 간단한 접근 방법은 IFTTT(If This Then That) 플랫폼이 가능하게 해주는 작업과 트리거, 그리고 반환되는 데이터 유형과 형식, 품질을 검토하는 것이다.
 
재피어(Zapier)는 트리거와 작업을 검토 및 테스트할 수 있는 3,000개 이상의 앱과의 통합을 제공한다. 통합은 한 앱에서 다른 앱으로 새 레코드를 푸시하는 데 사용되는 간단한 형태일 수도 있고, 더 복잡해서 필터와 경로, 포맷 및 기타 기능을 활용할 수도 있다. 후자는 한 앱의 트리거가 적절한 레코드를 찾아 두 번째 앱에서 이를 업데이트해야 할 때 필요한 경우가 많다. 포맷 기능은 데이터 정제와 기타 데이터 조작도 가능하게 해준다.
 
재피어는 통합을 테스트하고 모니터링하기 위한 툴도 제공한다. 이러한 운영 기능은 다양한 시나리오가 다양한 유형의 작업을 트리거하는 복잡한 통합과 API를 검증할 때 매우 유용하다.
 
그 외의 IFTTT 툴로는 Automate.io, IFTTT, 인티그레이틀리(Integrately), Tray.io, 워카토(Workato)가 있다. 이와 같은 툴은 빠른 출발을 위해 API 개념 증명을 테스트하고 개발하는 데 도움이 될 수 있다. 그러나 개발 팀은 개발자가 이러한 툴을 통해 필요한 통합을 생성, 테스트, 운영화할 수 있는 경우 프로덕션에서도 툴 사용을 고려해야 한다.
 

테스트 주도 개발 접근 방법을 사용하여 API 검증

필요한 통합이 상용이 아닌 써드파티 API와 관련되거나 IFTTT 플랫폼에 연결되지 않는 특정 산업용 플랫폼인 경우에는 어떻게 될까? 또는 복잡한 통합, 워크플로우 조율, 데이터 조작 또는 데이터 볼륨으로 인해 IFTTT 플랫폼의 실용성이 떨어지는 경우에는 어떻게 해야 할까?
 
개발 팀은 테스트 주도 개발(TDD) 방법론을 사용해서 API를 검증하고 프로토타입을 진행하는 방법을 고려할 수 있다. 이 접근 방법에서 개발 팀은 복합 서비스 또는 애플리케이션에서 직접 API 기능을 사용하기 전에 단위 테스트와 더 높은 수준의, 조율되고 자동화된 지속적 테스트를 구축한다.
 
TDD는 예상 사용 및 경계 사례를 정의하고 문서화하므로 API와 마이크로서비스 개발에서 강력한 접근 방법이다. 테스트 자동화는 하향 영향을 일으킬 수 있는 서비스에 대한 변경을 파악하는 데 도움이 된다.

이 접근 방법은 써드파티 API를 소비할 때도 마찬가지로 효과적이다. 개발자는 포스트맨(Postman)과 같은 툴을 사용해서 API 사양을 가져오고 API를 이해하고 테스트 모음을 만든 다음 이 테스트를 지속적 통합/지속적 제공(CI/CD) 파이프라인 및 기타 데브옵스 툴에 통합할 수 있다. 그 외에 카탈론(Katalon), 래피드API(RapidAPI), 파라소프트(Parasoft), 스마트베어 레디API(SmartBear ReadyAPI)와 같은 툴이 있다.

이러한 테스트는 API 검증에도 도움이 되지만, 나중에 개발자가 자동화된 지속적 테스트를 위해 사용할 수도 있다. 프로덕션에서는 써드 파티 API 변경으로 인해 테스트가 중단되는지, 이 API를 사용하는 서비스와 애플리케이션에 대한 검토 및 수정이 필요한지, 필요하다면 언제 필요한지를 확인하는 데 도움이 될 수 있다.
 

로우코드 통합 플랫폼을 사용하여 재사용 가능한 게이트웨이 구축

여러 플랫폼과 통합할 계획이고, 수많은 서비스와 애플리케이션에서 이 통합을 재사용해야 한다면? 회사에서 허브스팟(HubSpot), 워크데이(Workday), SAP 또는 기타 플랫폼과의 통합이 필요한 직원 온보딩 애플리케이션, 마케팅 툴, 현장 운영 워크플로우를 맞춤 구성하는 중일 수도 있다.
 
필자는 부미(Boomi)의 제품 책임자인 에드 마코스키와 중간 및 대규모 조직에서 데이터 공유와 워크플로우 및 협업 구현 측면의 기회에 대해 논의한 적이 있다. 이러한 조직에는 API 검증 이상이 필요하다. 이들은 확장 가능한 통합 프로세스를 요구한다. 마코스키는 여기서 발생하는 어려움에 대해 “모든 데이터 소스를 연결하고, 조직 내의 모든 데이터를 이해하고, 이 데이터를 통합하고, 서비스를 개발하고, 사용자 주도 워크플로우를 만들고, 이를 사용자와 접하는 프론트 엔드 애플리케이션에 노출하는 것과 같은, 종단간에 걸쳐 모든 사람을 모든 것에 연결하는 이 전체적인 그림을 그려야 하는 문제를 개발자가 어떻게 해결할 수 있을까?”라고 표현했다.
 
부미와 같은 통합 플랫폼에는 빠른 개발, 테스트 및 배포를 위해 일반적인 SaaS 및 엔터프라이즈 플랫폼 및 로우코드 툴에 대한 커넥터가 포함된다. 점 대 점 통합을 만드는 대신 여러 하향 애플리케이션과 복합 서비스에 하나의 통합을 활용할 수 있다.
 
그 외의 통합 플랫폼에는 지터비트(Jitterbit), 뮬소프트(MuleSoft), PMG, 스냅로직(SnapLogic)이 있다. 애플리케이션 통합 또는 서비스형 통합 플랫폼(iPaaS)은 사용의 용이함, 데이터 관리 기능, 운영 기능, 셀프 서비스 옵션을 포함한 다양한 기능에서 상호 차별화된다.
 
통합 플랫폼은 다양한 비즈니스 요건과 부서 워크플로우에 맞추어 환경을 맞춤 구성하고자 하는 조직에 매우 전략적인 수단이다. 예를 들어 온보딩 애플리케이션을 맞춤 구성해서 특정 역할로 작업에 참여하는 사람들 위해 기본적인 단계만 보여줄 수도 있고, 새로 채용한 기술자가 장비를 선택하도록 하거나 영업 담당자가 출장 기본 사항을 설정하도록 허용할 수도 있다.
 
개발자가 기억해야 할 중요한 점은 API 검증은 통합 과정의 첫 단계에 불과하다는 것이다. 그 이후 개발자는 재사용 및 확장이 가능하고 견고하고 지원되는 통합을 만들어야 한다. 이를 위해서는 비즈니스 서비스 수준 목표와의 통합을 지원하도록 설계된 운영 환경에 통합을 연결해야 한다. 통합 및 iPaaS 플랫폼은 이러한 옵션을 제공하며, 통합을 핵심 개발 및 운영 역량으로 삼고자 하는 조직에게 매우 큰 이점을 제공할 수 있다. editor@itworld.co.kr    



X