각 기업에 적합한 로우코드, 노코드 또는 프로세스 자동화 플랫폼은 무엇일까? 답은 플랫폼이 비즈니스 목표를 얼마나 잘 충족하는지에 따라 다르다. 여기서는 선택 범위를 좁히는 데 도움이 되는 7가지 질문을 살펴본다.

ⓒ Getty Images Bank

<이미지를 클릭하시면 크게 보실 수 있습니다>

코로나19 팬데믹 기간을 거치면서 로우코드, 노코드, 프로세스 자동화 플랫폼과 이런 기능을 포함한 기타 비즈니스 플랫폼 수가 급격히 증가했다. 최근 가트너 매직 쿼드런트에서는 애플리케이션 및 소프트웨어 개발을 위한 17개 로우코드 플랫폼을 순위별로 정리했다. 포레스터는 웨이브(Wave)에서 시민 개발자용 로우코드 플랫폼 12가지를 선별했으며, 디지털 프로세스 자동화 부문에서도 13가지 플랫폼을 선정했다. G2는 85가지 로우코드 개발 플랫폼과 364가지 노코드 개발 플랫폼이 포함된 목록을 만들었다.

프로토타입으로 실행하는 것은 고사하고 단순히 검토만 하기에도 너무 많다. 그러나 웬만한 기업은 이미 하나 이상의 플랫폼을 가지고 있을 가능성이 높다. 최근 데이터에 따르면 기업 77%는 로우코드 개발 툴을 사용 중이며 대기업 66%는 최대 4개의 로우코드 플랫폼을 사용하고 있다.

기업은 로우코드와 노코드 플랫폼을 사용해서 애플리케이션 현대화 속도를 높이고 스프레드시트를 워크플로우와 데이터베이스로 변환하고 비효율적인 작업을 혁신한다. 로우코드를 사용하는 혁신적인 방법에는 LLM을 애플리케이션에 통합하고 현장과 사무실 작업자를 연결하는 워크플로우를 구축하고 다양한 부서에 분석 기능을 배포하는 것이 포함된다.

프로세스 자동화는 애플리케이션 개발을 넘어 비즈니스 운영을 주도하는 구현을 목표로 한다. 애피안(Appian)의 제품 전략 부문 SVP인 말콤 로스는 "프로세스 자동화 툴은 기업에서 워크플로우를 정의하고 작업을 자동화해 효율성을 높이기 위해 필수적이다. 이 툴은 기업의 운영을 조율하고 워크플로우를 능률화하고 생성형 AI와 같은 혁신을 수용한다"라고 말했다.

플랫폼을 선택하기 전에 알아야 할 점

플랫폼을 찾고 있다면 평가 과정에서 여러 부서의 요구사항과 사용례를 고려하는 것이 중요하다. 또한 기업이 이미 보유한 플랫폼 위에 새로운 애플리케이션을 구축할지도 결정해야 할 수 있으므로 플랫폼의 기능과 운영 요구사항 충족 여부를 검증하는 것도 마찬가지로 중요하다. 다음은 다양한 비즈니스 사용례를 위한 플랫폼을 평가할 때 고려해야 할 7가지 질문이다.

1. 플랫폼이 비즈니스 유형과 애플리케이션 요구사항에 맞는가?
2. 플랫폼이 다양한 사용례를 지원하는가?
3. 플랫폼이 어떤 유형의 개발자와 기술적 역량을 대상으로 하는가?
4. 플랫폼이 AI를 통해 어떻게 혁신하고 있는가?
5. 플랫폼이 기본적으로 제공하는 기능은 무엇인가?
6. 학습 난이도는 어느 정도인가?
7. 플랫폼이 기술, 운영, 보안 측면의 요구사항을 충족하는가?

비즈니스 유형과 애플리케이션 요구사항에 맞는가?

개발 플랫폼을 검토할 때는 솔루션 업체가 내 기업과 비슷한 규모의 동일 업종 기업, 그리고 해결하려는 문제와 비슷한 비즈니스 문제를 가진 기업을 대상으로 하는지를 확인해야 한다. 업체의 웹사이트, 사례 연구, 블로그 및 기타 리소스를 검토하는 것이 좋다. 쉽게 확인할 수 있는 이런 지표는 평가와 프로토타이핑에 시간을 투자하기에 앞서 해당 플랫폼이 내가 목표로 하는 사용례를 해결할 가능성이 높은지 판단하는 데 도움이 된다.

암독스(Amdocs)의 부서장 아비샤이 샤를린은 "로우코드 또는 노코드 플랫폼을 선택할 때는 벤더의 주 공략 대상(중소기업 또는 대기업인지), 내가 목표로 하는 비즈니스 애플리케이션의 유형, 기존 애플리케이션을 대체하는지, 또는 복잡한 요구사항이 있는지 등을 파악하는 것이 중요하다"라고 말했다.

타인스(Tines)의 CEO이자 공동 창업자인 오인 힌시는 플랫폼이 실제 환경의 문제를 해결하는지를 평가해야 한다면서 "플랫폼이 데모에서 보이는 인상적인 모습을 확인하는 데 그치지 말고 실제 요구사항을 충족하는지, 대규모에서 효과적으로 배포할 수 있는지 확인하는 것이 중요하다"라고 말했다.

플랫폼이 다양한 사용례를 지원하는가?

또 다른 중요한 고려 사항은 플랫폼이 IT와 보안, 데이터 거버넌스를 지원하는 툴을 갖추고 여러 사업부 또는 부서에 걸쳐 다양한 사용례를 지원할 수 있는지다. 하나 또는 좁은 범위의 사용례만 지원하는 로우코드 또는 노코드 플랫폼은 기업의 기술 부채를 가중시키고 IT 리소스를 소비할 수 있다.

퀵베이스(Quickbase)의 제품 관리 부문 SVP인 데비 로버츠는 "단일 프로젝트나 워크플로우의 한 가지 문제를 해결하기 위해 로우코드 또는 노코드 솔루션을 선택하는 경우가 매우 많다. 이 경우 기업 전반적인 협업을 위해 기술 부채가 추가되거나 섀도우 IT가 발생하게 된다. 이런 툴에서 성공적인 결과를 얻기 위해서는 사업팀과 IT팀이 긴밀한 파트너십을 구축하는 것이 중요하다. 그래야 비즈니스팀과 운영팀이 IT 리소스를 더 적게 사용하면서도 빠르게 움직이고 IT팀은 필요한 거버넌스 감독 체계를 확보할 수 있다"라고 말했다.

닌텍스(Nintex)의 CIO 웨이슨 바나타는 로우코드 및 노코드 플랫폼을 감독할 방법을 평가하고 개발된 사용례의 효과를 지속적으로 평가하는 것이 중요하다면서 "직원이 툴을 사용하는 것과 툴을 어떻게 사용하는지는 별개의 문제"라고 언급했다. 바나타는 특히 시민 개발 문화를 장려할 때는 성공 지표를 정의하고 지침을 제공하는 것이 좋다고 덧붙였다.

노코드를 사용한 시민 개발의 혁신에는 대시보드 개발, SaaS 툴 전반의 워크플로우 연결, 스프레드시트를 모바일 툴로 대체하기, 상당한 기술 부채를 짊어진 부서별 레거시 앱 업그레이드하기 등이 포함될 수 있다.

어떤 유형의 개발자와 기술적 역량을 대상으로 하는가?

로우코드와 프로세스 자동화 플랫폼이 일반적으로 애플리케이션을 구축하고 지원하는 개발자와 기술자를 대상으로 한다면 노코드 플랫폼은 기초적인 기술을 갖춘 비즈니스 인력을 대상으로 한다. 현재 많은 플랫폼이 로우코드와 노코드 환경을 모두 제공하며, 자연어 프롬프트를 사용해 애플리케이션을 구축할 수 있도록 생성형 AI 툴을 제공하는 플랫폼도 여러 개다.

트레이닷에이아이(Tray.ai)의 공동 창업자이자 CEO인 리치 월드론은 "개발자와 비즈니스 기술자, 현업 직원들이 협업할 수 있는 여러 방법을 제공하는 플랫폼은 증가하는 비즈니스 요구사항을 수용하고 협업, 개발 속도, 팀 생산성을 가속화한다"라고 말했다.

또한 월드론은 시간이 지나면서 요구사항이 로우코드 또는 노코드 플랫폼의 맞춤 구성 범위와 역량을 초과할 수 있는 만큼 플랫폼의 확장성을 검토해야 한다면서 "코드를 많이 사용하는 접근 방식까지 지원하는 툴은 더 많은 사용례와 개발자 선호도를 반영할 수 있다. 또한 포괄적인 API를 갖추면 툴이 회사와 명확하게 분리되고 업체 종속을 유발하지 않는다"라고 말했다.

존 스노우 랩(John Snow Labs)의 CTO인 데이비드 탈비는 비기술직 사용자의 애플리케이션 구축을 지원하기 위해 노코드 플랫폼을 고려 중인 경우 이들에게 이런 역할을 맡을 만큼의 시간과 관심이 있는지 확인하는 것이 중요하다면서 "노코드 툴은 의사, 변호사, 회계사, 관리자 등 비기술직 사용자를 대상으로 한다. 사용자는 교육과 훈련을 받아야 하며 문제가 발생할 경우의 대처 방법을 알고 있어야 한다"라고 조언했다.

AI를 통해 어떻게 혁신하고 있는가?

생성형 AI가 로우코드 개발에 어떤 변화를 일으킬 것인지에 대한 최근 글에서 필자는 플랫폼 업체가 개발자 경험을 개선하고 애플리케이션을 구축하는 데 필요한 스킬셋을 줄이기 위해 생성형 AI 기능을 사용한다고 설명한 바 있다. 또한 많은 플랫폼은 검색 기능, 요약 기능, 예측 기능 등 생성형 AI로 최종 사용자의 역량을 강화한다.

생성형 AI와 ML은 경쟁이 치열하고 계속 발전 중인 기능이므로 로우코드 및 노코드 벤더와 프로세스 자동화 플랫폼이 각자의 혁신으로 경쟁하는 것은 당연한 일이다. 후보 업체에 현재 역량, 이를 통해 고객이 얻는 혜택, 그리고 개발 로드맵을 물어야 한다.

페가(Pega)의 CTO 돈 슈어만은 "생성형 AI는 창의적인 파트너 역할을 하면서 새로운 비즈니스 워크플로우를 위한 설계를 제안하고 대부분 주제별 전문가가 일상적인 작업에 쫓겨 놓치는 아이디어를 제공할 수 있다. 비즈니스 전문가는 콘텐츠 요약, 답변 찾기와 같은 생성형 AI의 생산성 향상 기능을 그러한 기능이 가장 필요한 워크플로우에 적용한다"라고 말했다.

슈어만에 따르면, 이런 기능 중 일부는 빠르게 기본적인 요소가 되면서 더 이상 실질적인 경쟁 우위를 제공하지 못하고 있다. 슈어만은 "로우코드 개발자가 전체 워크플로우를 완전히 새로 만드는 데 도움이 될 수 있는 새로운 발전이 이뤄지고 있다. 생성형 AI 엔진에 업계 베스트 프랙티스를 공급하면 몇 개의 프롬프트만으로 몇 초 만에 엔터프라이즈급 애플리케이션 전체를 설계하고 사용자와 개발자가 발견하지 못한 아이디어를 제안할 수 있다"라고 말했다.

기본적으로 제공하는 기능은 무엇인가?

앱 개발 플랫폼은 기업의 SaaS 플랫폼, 독자적인 애플리케이션, 데이터 리포지토리와 접속이 가능하면서 외부 파트너, 플랫폼 및 써드 파티 플러그인 생태계와의 통합을 지원해야 한다. 로우코드와 노코드 플랫폼은 종단간 워크플로우의 일부인 애플리케이션 개발의 기술적 접근 방식, 규모, 사용 편의성을 두고 경쟁한다.

다음 질문은 플랫폼이 가진 기능의 범위와 깊이를 측정하는 데 도움이 된다.

• 플랫폼의 다양성과 유연성을 보여주는 기능은 무엇인가? 예를 들어 양식 작성에는 드롭다운, 확인란과 같은 일반적인 UI 요소가 필요하지만 진보된 로우코드 플랫폼에는 더 정교한 기능이 있다. 대시보드를 개발 중이라면 차트 유형의 다양성과 구성 유연성을 확인해야 한다. 워크플로우 엔진의 경우 예외 처리, 재사용 가능한 하위 프로세스 개발, 자동화 기능, 역할 기반 책임 등이 핵심 기능에 포함된다.
• 플랫폼이 SaaS, 통합 툴, API를 포함한 다른 플랫폼과 손쉽게 통합되는가? 코파도(Copado)의 에반젤리즘 SVP인 데이비드 브룩스는 어느 플랫폼도 섬처럼 떨어져 있지는 않으므로 통합과 지원되는 연결의 수를 살펴봐야 한다고 말했다. 브룩스는 "대부분의 종단간 비즈니스 프로세스에는 두 개 이상의 플랫폼과 서비스가 포함되므로 통합을 쉽게 해주는 완전한 API와 툴을 갖춘 플랫폼을 선택해야 한다"고 말했다.
• 셀프 서비스 검색, 학습, 사용을 위해 API를 문서화하고 외부 개발자에게 노출하는 데 있어 솔루션이 어떻게 도움이 되는가? IBM의 애플리케이션 현대화 부문 제품 관리 GM인 제이슨 가트너는 플랫폼 API를 평가할 것을 권했다. 성공적인 디지털 트랜스포메이션은 핵심 비즈니스 기능을 드러내기 때문이다. 가트너는 "각 API는 주요 자산과 인프라를 특정해 연결되며, 종단간 비즈니스 트랜잭션을 완료하기 위해 어느 API를 어떻게, 어떤 순서로 호출해야 하는지를 외부 개발자가 디지털 방식으로 학습할 수 있어야만 유용하다"라고 말했다.

이들 질문은 플랫폼의 기능에 부합하는 사용례가 많은지, 그리고 회사 및 외부 생태계에 얼마나 쉽게 연결할 수 있는지 평가하는 데 도움이 된다.

학습 난이도는 어느 정도인가?

필자는 1시간 생산성 테스트를 통해 노코드 플랫폼을 평가하는 경우가 많다. 공식적인 교육 없이 1시간 내에 유용한 무언가를 개발할 방법을 알아내지 못하면 문제가 된다. 필자는 진도가 막히면 이를 플랫폼 문서와 검색 기능의 품질을 테스트할 기회로 활용한다. 해당 문제를 해결하는 데 도움이 되는 페이지를 찾을 수 있다면 플랫폼 문서화가 잘 되어 있다는 의미다.

로우코드와 프로세스 자동화 플랫폼은 익히고 마스터하는 데 더 많은 시간이 걸리지만 개발자는 비교적 빠르게 플랫폼에서 생산적으로 작업할 수 있다. 대기업을 대상으로 하며 핵심 애플리케이션 개발을 지원하는 플랫폼이라면 인증 과정과 성숙한 파트너 생태계를 갖추고 있어야 한다.

SAP의 앱 개발, 프로세스 자동화, 디지털 워크스페이스 마케팅 및 솔루션 부문 VP인 시드 미스라는 "빠르고 쉬운 개발은 사용자가 새로운 기회와 규제 및 규정 준수 문제에 빠르게, 많은 경우 실시간으로 대응하는 데 도움이 된다. 로우코드와 노코드 플랫폼은 사용하기 쉬워야 하고 개발자가 대대적인 IT 또는 외부 리소스 투자 없이 새로운 아이디어를 실험하고 테스트할 수 있도록 해야 한다"라고 강조했다.

여러 팀이 배우면서 경험을 벤치마킹하는 방법이 좋다. 이렇게 하면 들쭉날쭉한 기술 수준을 상쇄하고 여러 팀의 도입을 얼마나 쉽게 이끌어낼 수 있을지 판단할 수 있다.

닌텍스의 바나타는 "팀이 플랫폼에 얼마나 신속하게 적응할 수 있을지 파악하는 것이 효율적인 구현과 지속적인 사용을 위해 중요하다"라고 말했다.

코파도의 브룩스는 개발 커뮤니티 및 파트너의 규모가 손쉬운 지표가 될 수 있다면서 "큰 사용자 기반은 사용의 용이함을 입증하는 좋은 지표인 동시에 필요한 경우 채용할 인력 풀도 충분하다는 것을 의미한다"라고 말했다.

기술, 운영, 보안 측면의 요구사항을 충족하는가?

기업은 기술, 운영, 보안 요구사항이 포함된 비기능적 기준과 가격, 데이터, 법적 요구사항에 관한 비즈니스 기준을 다루는 요구사항 템플릿을 마련해야 한다. 애플리케이션 및 프로세스 개발을 지원하는 플랫폼은 디지털 트랜스포메이션, 애플리케이션 현대화 및 기타 전략적 비즈니스 우선순위의 엔진을 움직이는 역할을 하므로 더 많은 부분을 고려해야 한다.

운영 모델, 요구사항, 규모에 따라 다음과 같은 질문을 고려한다.

• 플랫폼이 다양한 데이터 소스의 통합, 비즈니스 로직의 코드화 및 업데이트, 사용자 인터페이스 맞춤 설정 경험을 간소화하거나 개선하는가? 각자 목표로 하는 경험의 유형을 기준으로 플랫폼이 개발을 어떻게 간소화할 수 있는지 확인하고, 개발팀이 현재 이 목표를 달성하고 있는지와 그 방법을 벤치마크한다. SADA의 소프트웨어 아키텍처 책임자인 저스틴 브룩스는 "이런 플랫폼이 개발의 필요성을 없애는 것이 아니라 개발 작업을 간소화하거나 개발자가 아닌 인력으로 작업을 전환한다는 것을 이해해야 한다"라고 말했다.
• 테스트, 배포, 기타 데브섹옵스 요구사항을 포함한 기존 소프트웨어 개발 수명주기(SDLC)에 로우코드 플랫폼이 얼마나 잘 부합하는가? 디스코프(Descope)의 공동 창업자 마이어 워넌은 "플랫폼이 회사의 CI/CD 프로세스에 얼마나 잘 정렬되는지를 파악해야 한다. 다양한 환경을 지원하지 않고 SDLC와 분리된다면 툴을 사용해서 절감한 모든 시간을 기술 스택의 나머지 부분과 연결하는 데 소비하게 될 것"이라고 설명했다.
• 플랫폼이 어떤 보안 기능을 제공하며, 다양한 규정에 어떻게 대처하는가? 많은 조직은 심층적인 보안 설문지를 작성하고 툴을 사용해서 기술 및 서비스 제공업체를 검증한다. 닌텍스의 바나타는 "기업은 데이터 암호화, 다중 요소 인증, FedRAMP나 GDPR과 같은 규정 준수 등 필요한 보안 조치를 조사하고 검증해야 한다"라고 권했다.
• 플랫폼이 어떻게 확장되고 가격은 어떻게 책정되며 개발자의 수, 애플리케이션 또는 애플리케이션 사용량을 확장할 경우 총비용은 얼마나 소요되는가? 뉴젠(Newgen)의 제품 관리 부문 책임자인 바룬 고스와미는 플랫폼의 확장성, 맞춤 구성 옵션의 유연성, 총소유 비용을 평가해야 한다면서 "이런 요소는 플랫폼이 현재의 비즈니스 요구사항을 충족할 뿐만 아니라 미래의 변화에 적응하고 장기적인 비즈니스 목표를 달성하는 데 도움이 되는지 확인하는 데 있어 필수적"이라고 언급했다.
• 플랫폼이 어떤 관찰가능성 및 모니터링 기능을 제공하는가? 플랫폼에서 자동으로 생성되는 문서, 다양한 문제 유형별 지식의 품질, 그리고 기술 지원의 효과도 평가해야 한다.

로우코드 또는 노코드 플랫폼의 위험과 혜택 평가

대부분 기업에서 애플리케이션 현대화, 새로운 고객 및 직원 경험 개발, 비즈니스 프로세스 자동화, 생성형 AI 기능을 통한 새로운 가치 찾기에 대한 요구가 커지고 있다. 로우코드, 노코드, 비즈니스 프로세스 자동화 플랫폼은 이런 프로젝트의 속도를 높여줄 수 있지만 중요한 것은 플랫폼의 기능과 운영, 규정 준수 역량이 비즈니스 요구사항과 일치하는 것이다.

처음으로 도입할 로우코드 또는 노코드 플랫폼을 평가하는 기업은 기술 전략, 새로운 플랫폼이 해결해야 할 비즈니스 및 기술 문제, 그리고 성공의 기준을 정의해야 한다. 크라우드보틱스(Crowdbotics)의 CEO 아난드 쿨카니는 로우코드 또는 노코드 플랫폼의 대안을 고려할 것을 권장하면서 "체계적인 코드 재사용을 우선시하는 AI 기반 소프트웨어 개발은 코드를 처음부터 작성하는 데서 비롯되는 위험을 크게 줄여주므로 고려 대상에 넣어야 한다"라고 말했다.

소나(Sonar)의 개발자 관계 및 커뮤니티 담당 VP 피터 맥키는 출구 전략이 필요하다면서 "플랫폼 사용을 중단할 경우 어떻게 작업을 유지할 수 있는지가 가장 중요한 질문 중 하나"라고 덧붙였다.

대부분 플랫폼은 애플리케이션을 손쉽게 다른 플랫폼으로 내보내고 전환하는 방법을 제공하지 않는다. 다만 특정 기능에 따라 출구 전략이 간소화될 수는 있다. 데이터 내보내기 툴, 통합 플랫폼에 연결된 API, 건강한 개발 파트너 생태계를 보유한 자체 문서화 플랫폼은 출구 계획을 실행하는 데 따르는 위험과 비용을 낮춰줄 수 있다.
editor@itworld.co.kr

Isaac Sacolick editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지