로우코드 플랫폼을 고르는 7가지 선택 기준

마이크로서비스, 맞춤형 애플리케이션, 혁신적인 고객 경험, 엔터프라이즈 워크플로우, 독자적인 데이터베이스를 코딩하는 것이 비즈니스 측면에서 합리적인 경우는 많다. 그러나 비즈니스 및 기술팀이 개발 속도를 높이고 기술적인 모범 사례를 즉각 제공하고 데브옵스를 간소화하고 지속적인 개선을 지원하기 위해 로우코드(low-code), 노코드(no-code) 플랫폼을 고려해야 하는 경우도 있다.

로우코드 플랫폼은 여러 범주로 나뉜다. 일부는 웹 및 모바일 사용자 인터페이스와 워크플로우를 신속하게 개발하는 데 초점을 둔다. 많은 데이터 시각화, 데이터 통합 및 데이터 준비 툴이 로우코드이며 새롭게 부상하는 로우코드 플랫폼은 머신 러닝, 사물인터넷(IoT), IT 자동화를 지원한다.

여기서는 애플리케이션 개발, 지원, 개선을 가능하게 해주는 로우코드 플랫폼을 중점적으로 살펴본다. 로우코드 플랫폼 선택을 위한 몇 가지 원칙을 공유한다. 플랫폼 선택을 위한 검토와 활동은 공통적이지만 여러 세부적인 부분을 잘 살펴야 한다.

1. 여러 사용 사례를 파악하고 평가

로우코드 및 노코드 기능의 인기는 지난 몇 년 사이, 특히 많은 기업이 코로나19로 인해 신속하게 애플리케이션을 구축하고 업그레이드해야 했던 2020년 들어 크게 높아졌다. 다른 모든 기술 범주가 그렇듯이 로우코드에도 다양한 기능과 개발 접근 방식을 제공하는 여러 플랫폼이 있다.

로우코드 플랫폼은 조직에서 애플리케이션 개발 속도를 높이고 기능 개선을 더 쉽게 지원하는 데 도움이 돼야 한다. 그러나 무엇보다 최종 사용자 경험, 데이터 요구 사항, 워크플로우 기능을 비롯한 여러 요소에 대해 자신이 원하는 애플리케이션 유형을 기준으로 평가해야 한다.

로우코드 플랫폼을 조사하고 테스트할 때는 여러 앱 개발 요구사항과 사용 사례를 고려하는 것이 중요하다. 가장 중요한 점은 플랫폼이 할 수 없는 것, 할 수 있더라도 쉽게 못 하는 것이 무엇인지 찾고, 플랫폼이 커버하는 범위와 장단점을 파악하는 것이다. 어느 한 사용 사례에 효과적이라는 이유로 로우코드 접근 방식을 선택할 경우 그것이 이후의 지속적인 요구에 맞는 최적의 접근 방식이 맞는지 확신할 수 없다.

2. 누가 애플리케이션을 개발하는지 명시

플랫폼이 로우코드를 표방한다는 것은 애플리케이션을 개발하기 위해 얼마간의 코딩 기술이 필요하다는 것을 의미한다. 노코드를 내세우는 플랫폼은 사용자 인터페이스, 워크플로우 및 통합을 구축하기 위한 시각적 툴을 제공한다.

그러나 이것은 한 측면일 뿐이고, 더 중요한 것은 누가 애플리케이션을 설계, 개발, 유지할 것인지 분명히 하는 것이다. 일부 로우코드 플랫폼은 기술자를 위한 툴, 즉 소프트웨어 개발 기술이 있는 사람을 대상으로 한다. 이와 달리 시민 개발 플랫폼은 비즈니스 분석가 또는 주제별 전문가가 애플리케이션을 개발하고 지원할 수 있게 한다. 일부 플랫폼은 두 가지를 모두 지원하지만, 각 사용 대상을 위한 툴과 기능은 서로 다르다.

대상 개발자는 플랫폼에 대해 배우고 애플리케이션을 구축하는 데 관심과 열정을 가져야 하며 지속적인 개선을 지원할 시간적 여유도 있어야 한다. 선택 과정의 초기부터 이들을 참여시키면 비즈니스 우선순위에 부합하는 툴을 사용하는 데 동참하도록 할 수 있다.

3. 고객 만족과 추천 정도를 살필 것

사람들은 기대치를 넘어서지 않은 플랫폼에 대해 잘 이야기하지 않는다. 모든 기술 플랫폼에서 수많은 긍정적인 리뷰를 쉽게 찾을 수 있다. 일부 플랫폼은 보유한 애플리케이션과 고객, 개발자의 수를 내세운다.

하지만 그런 플랫폼보다는 고객 만족 보고서를 공유하는 플랫폼이 더 낫다. 규모가 클수록 더 확고하게 자리를 잡은 플랫폼이다. “엔터프라이즈급” 플랫폼은 가트너 매직 쿼드런트(Gartner Magic Quadrants), 포레스터 웨이브(Forrester Waves) 및 기타 분석가 보고서에 포함될 가능성이 크다.

필자는 고객 만족을 중시한다. 열렬할 정도의 팬이 있는 플랫폼을 찾는다. 우수한 로우코드 플랫폼을 만들기 위해서는 뛰어난 최종 사용자 경험을 제공하고 기술 전문가가 감탄할 만한 기능을 제공하고 경영진에게 장단기적 가치를 입증해야 한다. 일부 로우코드 플랫폼은 이와 같은 여러 측면 중 일부에서 부족할 수 있으며, 해당 플랫폼의 기술을 사용해 반복 가능한 성공을 견인하기가 어렵다.

4. 사용량 요구사항을 정의하고 비용을 추정

로우코드 플랫폼의 비즈니스 모델과 가격 모델은 매우 다양하다. 일부는 최종 사용자 가격 체계를 사용하므로 애플리케이션 사용자 또는 사용량이 많을수록 더 큰 비용을 지불해야 한다. 개발 규모별로, 애플리케이션 또는 개발 시트의 수와 같은 척도에 따라 플랫폼 가격을 책정하는 경우도 있다. 또한 각기 개별적으로 판매되는 여러 제품을 제공하는 기업도 있다. 대부분은 포함되는 기능을 기준으로 계층화된 가격 구조를 사용한다.

많은 플랫폼에서 평가판과 개념 증명 개발은 쉽게 접할 수 있지만 최종적인 개발 및 프로덕션 요구 사항을 파악하는 것이 중요하다.

또한 가격만으로 로우코드 플랫폼을 평가하는 실수를 피해야 한다. 궁극적으로 이러한 플랫폼을 사용해서 쾌적한 사용 경험과 개발 생산성, 견고한 운영 기능을 실현할 수 있어야 한다. 총소유비용을 계산하려면 모든 재무적 요소를 고려해야 한다.

5. 통합 요구사항에 높은 우선순위 부여

로우코드 애플리케이션을 사일로 형태로 개발할 수는 없다. 애플리케이션은 엔터프라이즈 시스템, API, 클라우드 및 데이터 센터 데이터베이스와 써드 파티 데이터 소스에 통합돼야 한다. 조직이 IoT 데이터 파이프라인 또는 머신 러닝 모델을 개발 중이라면 이를 로우코드 플랫폼과 통합하고자 할 가능성이 높다.

거의 모든 플랫폼이 API를 제공하지만 API로 무엇을 할 수 있는지, API의 성능이 얼마나 좋은지, 벤더가 개발팀을 어떻게 지원하는지는 플랫폼마다 천차만별이다. 지속해서 유지관리해야 하는 복잡한 통합이 필요한 로우코드 애플리케이션을 개발하는 사태는 누구나 피하고 싶을 것이다.

출발점 중 하나는 IFTTT(If This Then That) 플랫폼을 검토하고 로우코드 플랫폼과 통합되는지, 어떤 작업과 트리거를 지원하는지 확인하는 것이다. 프로덕션에서 이러한 플랫폼을 사용하지 않는다고 해도 기능을 검토하고 통합 개념 증명을 구현하기에 좋은 대상이다.

6. 호스팅, 데브옵스, 거버넌스 옵션 검토

로우코드는 한때 SaaS 및 클라우드 호스팅 옵션과 거의 같은 뜻으로 쓰였으며 하이브리드 클라우드와 데이터센터 옵션을 제공하는 경우는 극소수였다. 더는 아니다. 로우코드 플랫폼은 이제 호스팅 유연성을 두고 경쟁한다. 데브옵스 옵션 검토 역시 중요한 고려 사항이다. 데브옵스 기능, 특히 다음과 같은 부분에서 로우코드 플랫폼은 저마다 다르다.

• 애플리케이션 버전 관리 또는 버전 제어 시스템과의 통합
• 개발, 테스트 및 기타 환경 전반에서 개발 수명주기 지원
• 백로그와 로드맵을 관리하는 툴에 연결되며 애자일 개발 프로세스 지원
• 지속적 통합/지속적 배포, 지속적 테스트 또는 IT 서비스 관리 변경 관리 프로세스와 통합
• 데이터 스냅샷, 미러, 복제를 지원하거나 프로세스를 추출, 변형, 로드하여 재해 복구 및 데이터 과학 지원

로우코드 플랫폼에 자바, 닷넷 또는 자바스크립트 데브옵스 기능 수준의 유연함을 기대해서는 안 된다. 로우코드 플랫폼으로 간다면 목표는 앱 개발 및 운영을 지원하기 위해 필요한 모든 골격 작업을 간소화하는 데 있으므로 그 외의 부분에서 타협해야 한다. 관건은 비즈니스 및 기술 요구사항을 충족하는지 여부이지, 코딩 및 소프트웨어 개발을 위해 설계된 툴과 프로세스에 부합하는지 여부가 아니다.

마지막으로, 사업부 인력이 애플리케이션을 구축하고 지원할 수 있도록 할 계획이라면 플랫폼의 시민 개발 거버넌스 옵션을 검토해야 한다.

7. 규정 준수 및 보안 요구사항 이해

플랫폼을 평가하는 순서는 중요하다. 규정 준수와 보안이 가장 마지막으로 평가할 또는 중요도가 낮은 사항이라고 오해해서는 안 된다. 플랫폼을 평가할 때는 ‘반드시’ 해야 하는 것과 해야 하는 것의 차이를 구분하고 여러 기준을 각기 언제 평가할지 결정해야 한다.

HIPAA 규정 준수, 데이터 계통(data lineage) 기능, 감사 기능, 데이터 주권 규정 준수, 액티브 디렉터리 통합, 호스팅 제약이나 그 외의 타협 불가능한 요소가 있는 애플리케이션을 개발하는 경우 각 해당 요구사항을 가장 먼저 평가하는 것이 좋다. 그 후 애플리케이션 구현을 시작할 때 로우코드 플랫폼이 역할 기반 관리, 데이터 마스킹 및 기타 보안 고려 사항에 어떻게 대응하는지 확인해야 한다.

필자는 20년째 로우코드, 노코드 플랫폼을 사용, 리뷰하고 있다. 이것이 대부분 기업에 큰 잠재력을 지니고 있다고 확신한다. 그러나 플랫폼 간의 차이가 크기 때문에 충분히 시간을 들여 선택 옵션을 조사하고 검증해야 한다. 

출처URL : https://www.itworld.co.kr/news/194569

※ 위 포스팅이 문제있을 시 삭제처리 하겠습니다.