2019.11.05

IFTTT 플랫폼 선택을 위한 '7가지 팁'

Isaac Sacolick | InfoWorld
여러 SaaS나 퍼블릭 클라우드를 가로질러 데이터나 워크플로우를 통합하는 작업이 필요할 수 있다. 적절한 IFTTT 플랫폼이 때로는 탁월한 해답이 된다. 쉽고 간편하며 신뢰할 만한 결과를 얻을 수 있다. 
 
ⓒ Image Credit : Getty Images Bank

다양한 기술로 작업을 하는 와중에 애플리케이션이나 워크플로우 또는 데이터를 통합해 달라는 요구가 발생할 수 있다. 어떤 통합 작업은 여러 개의 데이터 소스와 실시간 데이터 스트리밍이 필요하고 데이터 보호와 관련된 엄격한 요건도 준수해야 한다. 

그러한 복잡한 통합 작업을 위해 고려해 볼만 한 방식은 델 부미(Dell Boomi)나 스냅로직(SnapLogic)과 같은 엔터프라이즈 통합 플랫폼을 이용하는 것이다. 이러한 플랫폼을 허브 삼아서 여러 개의 데이터 소스를 연결하고 변환 작업을 수행하는 한편, 다운스트림 애플리케이션에 대한 접근을 제공하는 것이다.

한편 통합 작업이 데이터 중심인 경우가 있다. 소스 시스템에서 하나 이상의 다운스트림 시스템으로 데이터를 이동해야 하는 경우다. 이 때 이용할 수 있는 여러 데이터 통합 플랫폼들이 있다. 작업 대상이 엔터프라이즈 시스템의 일괄 데이터인가, IoT 센서의 실시간 데이터인가, 아니면 여러 개의 빅데이터 플랫폼에 걸친 통합인가에 따라 사용할 수 있는 것들이다. 

마지막으로, 규모가 훨씬 큰 작업을 해달라는 요청이 들어올 수도 있다. 이 때 적절한 해결책은 구축하기 쉽고 유지관리가 간단하며 운영상 신뢰할 수 있는 방식을 모색하는 것이다. 예를 들면 다음과 같은 경우다.

- 웹사이트에 신규 사용자가 등록하면, 메일침프(Mailchimp) 또는 컨스턴트 컨택트(Constant Contact)와 같은 이메일 마케팅 도구를 통해 전송되는 뉴스레터의 구독자로 해당 사용자의 이메일이 추가된다.

- 업무를 지원하는 헬프데스크에서 사용자 관련 문제를 살펴본 결과 애플리케이션 관련 결함을 발견하면, 애자일(agile) 개발팀이 해야 할 일 목록인 백로그(backlog)에 해당 결함이 추가된다.

- 경쟁사 블로그에 신규 게시물이 나오면, 해당 게시물의 제목과 URL, 공개 데이터를 캡처하여 경쟁사 정보를 저장하는 데이터데이스에 추가한다.

이들 한 플랫폼에서의 활동이 트리거가 되어 다른 플랫폼 내부로의 데이터 액션이 필요해지는 경우다. 그리고 바로 일반적인 IFTTT(If This Then That) 패턴이기도 하다. 여러 개의 SaaS 및 퍼블릭 클라우드 서비스에 걸친 데이터와 워크플로우를 통합할 때 특히 요긴하다.

워크플로우와 관련해 여러 개의 SaaS 도구에 의존하는 조직들이 많다. 개발 팀의 백로그 관리에 지라 또는 애저 데브옵스 같은 도구 하나, 그리고 헬프데스크 티켓 처리에는 서비스나우같은 다른 도구를 사용하는 식이다. 또 디지털 마케터들은 각종 광고와 SNS, 이메일 행사에 다양한 도구를 섞어 사용하는 경우가 많다. 이 밖에 웹사이트 RSS 피드, SNS 피드, 업무 정보 소스 등 공개적인 소스에서 정보를 수집하려 하는 데이터 중심의 조직들도 많다.
 
이벤트 중심 자동화, IFTTT 플랫폼은 일반적인 통합 작업을 단순화한다
간단한 IFTTT 패턴에 맞는 통합 작업이라면, 자피어(Zapier), IFTTT, 마이크로소프트 플로우, 워카토(Workato), 트레이닷아이오(Tray.io)와 같은 이벤트 중심 자동화 플랫폼들로 충분할지 모른다. 여러 퍼블릭 클라우드 서비스는 물론, 수백 개의 SaaS 플랫폼 API에 이미 연결되고 있으며 점점 복잡해지는 통합 작업을 가능하게 해 주기 때문이다.

이들 플랫폼들은 출발 플랫폼의 트리거를 선택한 후 도착 플랫폼의 액션을 선택하는 것으로 시작한다. 예를 들면, 서비스나우 티켓이 트리거이고 지라에 결함을 기록하는 것이 액션이다. 최소한 이들 도구로는 트리거에서 액션의 서비스에 이르는 데이터 지도를 만들 수 있다. 또한 데이터 필드를 변환하고 액션 대상의 레코드를 골라내기 위한 보다 정교한 도구들도 제공된다.

IFTTT 플랫폼에서 찾아봐야 할 것
IFTTT 플랫폼 검토 시에 고려해야 할 점이 있다. 첫째, 지금 또는 향후에 통합해야 할 여러 SaaS 및 퍼블릭 클라우드 플랫폼을 제대로 이해하고 있어야 한다. 둘째, 오늘날 SaaS 도구와 클라우드 서비스가 어떻게 사용되는지를 기준으로 예상되는 통합 작업을 가정해 보는 것이다. 그리고 다음과 같은 질문을 검토할 수 있다.

1. 해당 IFTTT 플랫폼은 사용 중인 SaaS 및 퍼블릭 클라우드 서비스에 연결되는가? 널리 사용되는 세일즈포스와 같은 플랫폼들과 아마존, 마이크로소프트, 구글에서 나오는 일반적인 퍼블릭 클라우드 서비스들에 연결되는 IFTTT 플랫폼들이 많지만 본인이 사용 중인 SaaS 및 클라우드 서비스는 그에 비해 덜 흔한 것일 가능성이 있다. 

특정 IFTTT 플랫폼에 덜컥 뛰어들지 말고, 가능한 통합 작업을 미리 검토해 보는 것이 좋다. 자칫 불필요한 통합 작업이 추가로 요구될 수 있다. 

2. 필요로 하는 트리거들과 데이터 처리 기능을 지원하는가? SaaS 커넥터를 보유하는 것으로는 부족하다. 필요한 종류의 통합 작업을 해당 플랫폼이 지원도 해야 한다. 해당 통합 작업과 현재 사용 중인 SaaS 기능과의 일치 여부는 물론, 이용 가능한 매개변수화 작업을 살펴봐야 한다. 또한, 데이터에 어떤 종류의 작업이 필요한지 감안한다. 

예를 들어, 여러 개의 레코드를 하나로 합쳐야 하고, 복잡한 필드 변환을 수행하거나 데이터 검색을 인스턴스화여 데이터를 변환해야 하는데, 이를 감당할 수 없는 IFTTT 플랫폼도 있을 수 있다.

3. 액션의 정교함이 장단기 니즈와 일치하는가? 필요한 트리거를 해당 IFTTT 플랫폼이 처리할 수 있음이 확인되면, 사용 가능한 CRUD(생성(C), 읽기(R), 업데이트(U), 삭제(D)) 작업의 범위를 확인하기 위해 더욱 깊이 살펴본다. 여러 개의 레코드를 업데이트할 수 있는 여러 개의 삽입이나 검색과 같은 일괄 작업을 해당 액션이 지원하는지 여부를 검토한다.

4. 대규모 팀과의 협업이 얼마나 수월한가? 조직 내에서 이런 통합 작업 담당자가 본인뿐이라면 협업이나 버전 설정, 통합 공유 등은 문제가 아닐지 모른다. 반면, 여러 명의 사람이 접근권을 갖고 다양한 통합 작업을 개발하는 경우에는, 협업과 버전 통제, 공유, 재사용, 보안 통제 등을 검토하는 것이 필수적이다.

5. 규정 준수 요건을 충족하는가? 개인식별정보(PII), 건강보험 정보의 이전과 책임(HIPAA) 등 데이터 관리 통제 관련 요건이 존재하는 데이터 집합을 처리하는 것이 해당 플랫폼의 사용 목적이라면, 규정 준수나 개인정보 보호, 데이터 보안 등이 매우 중요한 고려 대상이다. 

6. 트랜잭션을 시험, 감시, 복구하기가 얼마나 수월한가? 통합 작업을 구축하는 것과 지원하는 것은 전혀 별개로 고려해야 할 사안이다. 트랜잭션 실패 시에 알림이 오는가? 문제를 해결한 후에 실패한 레코드에 대한 작업을 재실행할 수 있는가? 심상치 않은 활동이 갑자기 나타나면 알림이 오는가?

7. 트랜잭션 용량이 커지면 비용이 올라갈 것인가? 이들 플랫폼 중에는 작업 시작을 쉽게 해주고 한정된 수의 트랜잭션에 대해서는 무료 및 저가 옵션을 제공하는 것이 많다. 고용량 처리에 플랫폼을 사용할 계획이라면 비용이 결정적인 요소가 될 수 있다.

API에 맞게 직접 구축해야 할까?
IFTTT 플랫폼 없이 SaaS 플랫폼의 API에 맞게 개발하는 것이 더 나은 해결책이라는 생각이 들 수 있겠다. 실제로 통합할 SaaS 플랫폼과 클라우드 API의 수가 매우 적다면, 통합 작업 개발이 한 방법이 될 수 있다. 단, 이 때 개발자들은 주의를 기울일 것을 권장한다. 통합 작업은 코딩하기 쉬울지 모르지만 감시 기능 및 실패로부터의 복구 기능을 개발하려면 일이 훨씬 커진다.

SaaS 플랫폼들을 통합할 때 실패하는 경우는 흔하다. 트랜잭션 시점에 서비스 하나를 사용할 수 없거나 성능이 느려질 수 있기 때문이다. 또한, 해당 필드 변환이 탄탄하지 않고 액션이 예상치 못한 데이터를 처리하는 경우, 트랜잭션은 실패로 귀결되어 수정이 필요할 수 있다.

오늘날 IFTTT 플랫폼들은 점점 더 정교해지고 있다. 본인이 필요로 하는 종류의 변환 작업이 현재는 없다고 해도 플랫폼의 로드맵에 포함되어 있어서 향후에는 실현될 가능성이 있다. 

* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr
 


2019.11.05

IFTTT 플랫폼 선택을 위한 '7가지 팁'

Isaac Sacolick | InfoWorld
여러 SaaS나 퍼블릭 클라우드를 가로질러 데이터나 워크플로우를 통합하는 작업이 필요할 수 있다. 적절한 IFTTT 플랫폼이 때로는 탁월한 해답이 된다. 쉽고 간편하며 신뢰할 만한 결과를 얻을 수 있다. 
 
ⓒ Image Credit : Getty Images Bank

다양한 기술로 작업을 하는 와중에 애플리케이션이나 워크플로우 또는 데이터를 통합해 달라는 요구가 발생할 수 있다. 어떤 통합 작업은 여러 개의 데이터 소스와 실시간 데이터 스트리밍이 필요하고 데이터 보호와 관련된 엄격한 요건도 준수해야 한다. 

그러한 복잡한 통합 작업을 위해 고려해 볼만 한 방식은 델 부미(Dell Boomi)나 스냅로직(SnapLogic)과 같은 엔터프라이즈 통합 플랫폼을 이용하는 것이다. 이러한 플랫폼을 허브 삼아서 여러 개의 데이터 소스를 연결하고 변환 작업을 수행하는 한편, 다운스트림 애플리케이션에 대한 접근을 제공하는 것이다.

한편 통합 작업이 데이터 중심인 경우가 있다. 소스 시스템에서 하나 이상의 다운스트림 시스템으로 데이터를 이동해야 하는 경우다. 이 때 이용할 수 있는 여러 데이터 통합 플랫폼들이 있다. 작업 대상이 엔터프라이즈 시스템의 일괄 데이터인가, IoT 센서의 실시간 데이터인가, 아니면 여러 개의 빅데이터 플랫폼에 걸친 통합인가에 따라 사용할 수 있는 것들이다. 

마지막으로, 규모가 훨씬 큰 작업을 해달라는 요청이 들어올 수도 있다. 이 때 적절한 해결책은 구축하기 쉽고 유지관리가 간단하며 운영상 신뢰할 수 있는 방식을 모색하는 것이다. 예를 들면 다음과 같은 경우다.

- 웹사이트에 신규 사용자가 등록하면, 메일침프(Mailchimp) 또는 컨스턴트 컨택트(Constant Contact)와 같은 이메일 마케팅 도구를 통해 전송되는 뉴스레터의 구독자로 해당 사용자의 이메일이 추가된다.

- 업무를 지원하는 헬프데스크에서 사용자 관련 문제를 살펴본 결과 애플리케이션 관련 결함을 발견하면, 애자일(agile) 개발팀이 해야 할 일 목록인 백로그(backlog)에 해당 결함이 추가된다.

- 경쟁사 블로그에 신규 게시물이 나오면, 해당 게시물의 제목과 URL, 공개 데이터를 캡처하여 경쟁사 정보를 저장하는 데이터데이스에 추가한다.

이들 한 플랫폼에서의 활동이 트리거가 되어 다른 플랫폼 내부로의 데이터 액션이 필요해지는 경우다. 그리고 바로 일반적인 IFTTT(If This Then That) 패턴이기도 하다. 여러 개의 SaaS 및 퍼블릭 클라우드 서비스에 걸친 데이터와 워크플로우를 통합할 때 특히 요긴하다.

워크플로우와 관련해 여러 개의 SaaS 도구에 의존하는 조직들이 많다. 개발 팀의 백로그 관리에 지라 또는 애저 데브옵스 같은 도구 하나, 그리고 헬프데스크 티켓 처리에는 서비스나우같은 다른 도구를 사용하는 식이다. 또 디지털 마케터들은 각종 광고와 SNS, 이메일 행사에 다양한 도구를 섞어 사용하는 경우가 많다. 이 밖에 웹사이트 RSS 피드, SNS 피드, 업무 정보 소스 등 공개적인 소스에서 정보를 수집하려 하는 데이터 중심의 조직들도 많다.
 
이벤트 중심 자동화, IFTTT 플랫폼은 일반적인 통합 작업을 단순화한다
간단한 IFTTT 패턴에 맞는 통합 작업이라면, 자피어(Zapier), IFTTT, 마이크로소프트 플로우, 워카토(Workato), 트레이닷아이오(Tray.io)와 같은 이벤트 중심 자동화 플랫폼들로 충분할지 모른다. 여러 퍼블릭 클라우드 서비스는 물론, 수백 개의 SaaS 플랫폼 API에 이미 연결되고 있으며 점점 복잡해지는 통합 작업을 가능하게 해 주기 때문이다.

이들 플랫폼들은 출발 플랫폼의 트리거를 선택한 후 도착 플랫폼의 액션을 선택하는 것으로 시작한다. 예를 들면, 서비스나우 티켓이 트리거이고 지라에 결함을 기록하는 것이 액션이다. 최소한 이들 도구로는 트리거에서 액션의 서비스에 이르는 데이터 지도를 만들 수 있다. 또한 데이터 필드를 변환하고 액션 대상의 레코드를 골라내기 위한 보다 정교한 도구들도 제공된다.

IFTTT 플랫폼에서 찾아봐야 할 것
IFTTT 플랫폼 검토 시에 고려해야 할 점이 있다. 첫째, 지금 또는 향후에 통합해야 할 여러 SaaS 및 퍼블릭 클라우드 플랫폼을 제대로 이해하고 있어야 한다. 둘째, 오늘날 SaaS 도구와 클라우드 서비스가 어떻게 사용되는지를 기준으로 예상되는 통합 작업을 가정해 보는 것이다. 그리고 다음과 같은 질문을 검토할 수 있다.

1. 해당 IFTTT 플랫폼은 사용 중인 SaaS 및 퍼블릭 클라우드 서비스에 연결되는가? 널리 사용되는 세일즈포스와 같은 플랫폼들과 아마존, 마이크로소프트, 구글에서 나오는 일반적인 퍼블릭 클라우드 서비스들에 연결되는 IFTTT 플랫폼들이 많지만 본인이 사용 중인 SaaS 및 클라우드 서비스는 그에 비해 덜 흔한 것일 가능성이 있다. 

특정 IFTTT 플랫폼에 덜컥 뛰어들지 말고, 가능한 통합 작업을 미리 검토해 보는 것이 좋다. 자칫 불필요한 통합 작업이 추가로 요구될 수 있다. 

2. 필요로 하는 트리거들과 데이터 처리 기능을 지원하는가? SaaS 커넥터를 보유하는 것으로는 부족하다. 필요한 종류의 통합 작업을 해당 플랫폼이 지원도 해야 한다. 해당 통합 작업과 현재 사용 중인 SaaS 기능과의 일치 여부는 물론, 이용 가능한 매개변수화 작업을 살펴봐야 한다. 또한, 데이터에 어떤 종류의 작업이 필요한지 감안한다. 

예를 들어, 여러 개의 레코드를 하나로 합쳐야 하고, 복잡한 필드 변환을 수행하거나 데이터 검색을 인스턴스화여 데이터를 변환해야 하는데, 이를 감당할 수 없는 IFTTT 플랫폼도 있을 수 있다.

3. 액션의 정교함이 장단기 니즈와 일치하는가? 필요한 트리거를 해당 IFTTT 플랫폼이 처리할 수 있음이 확인되면, 사용 가능한 CRUD(생성(C), 읽기(R), 업데이트(U), 삭제(D)) 작업의 범위를 확인하기 위해 더욱 깊이 살펴본다. 여러 개의 레코드를 업데이트할 수 있는 여러 개의 삽입이나 검색과 같은 일괄 작업을 해당 액션이 지원하는지 여부를 검토한다.

4. 대규모 팀과의 협업이 얼마나 수월한가? 조직 내에서 이런 통합 작업 담당자가 본인뿐이라면 협업이나 버전 설정, 통합 공유 등은 문제가 아닐지 모른다. 반면, 여러 명의 사람이 접근권을 갖고 다양한 통합 작업을 개발하는 경우에는, 협업과 버전 통제, 공유, 재사용, 보안 통제 등을 검토하는 것이 필수적이다.

5. 규정 준수 요건을 충족하는가? 개인식별정보(PII), 건강보험 정보의 이전과 책임(HIPAA) 등 데이터 관리 통제 관련 요건이 존재하는 데이터 집합을 처리하는 것이 해당 플랫폼의 사용 목적이라면, 규정 준수나 개인정보 보호, 데이터 보안 등이 매우 중요한 고려 대상이다. 

6. 트랜잭션을 시험, 감시, 복구하기가 얼마나 수월한가? 통합 작업을 구축하는 것과 지원하는 것은 전혀 별개로 고려해야 할 사안이다. 트랜잭션 실패 시에 알림이 오는가? 문제를 해결한 후에 실패한 레코드에 대한 작업을 재실행할 수 있는가? 심상치 않은 활동이 갑자기 나타나면 알림이 오는가?

7. 트랜잭션 용량이 커지면 비용이 올라갈 것인가? 이들 플랫폼 중에는 작업 시작을 쉽게 해주고 한정된 수의 트랜잭션에 대해서는 무료 및 저가 옵션을 제공하는 것이 많다. 고용량 처리에 플랫폼을 사용할 계획이라면 비용이 결정적인 요소가 될 수 있다.

API에 맞게 직접 구축해야 할까?
IFTTT 플랫폼 없이 SaaS 플랫폼의 API에 맞게 개발하는 것이 더 나은 해결책이라는 생각이 들 수 있겠다. 실제로 통합할 SaaS 플랫폼과 클라우드 API의 수가 매우 적다면, 통합 작업 개발이 한 방법이 될 수 있다. 단, 이 때 개발자들은 주의를 기울일 것을 권장한다. 통합 작업은 코딩하기 쉬울지 모르지만 감시 기능 및 실패로부터의 복구 기능을 개발하려면 일이 훨씬 커진다.

SaaS 플랫폼들을 통합할 때 실패하는 경우는 흔하다. 트랜잭션 시점에 서비스 하나를 사용할 수 없거나 성능이 느려질 수 있기 때문이다. 또한, 해당 필드 변환이 탄탄하지 않고 액션이 예상치 못한 데이터를 처리하는 경우, 트랜잭션은 실패로 귀결되어 수정이 필요할 수 있다.

오늘날 IFTTT 플랫폼들은 점점 더 정교해지고 있다. 본인이 필요로 하는 종류의 변환 작업이 현재는 없다고 해도 플랫폼의 로드맵에 포함되어 있어서 향후에는 실현될 가능성이 있다. 

* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr
 


X