2018.12.03

글로벌 칼럼 | 개발자들이 '로우코드 플랫폼'에 대해 다시 생각해야 하는 이유

Isaac Sacolick | InfoWorld
새로운 애플리케이션에 대한 비즈니스 수요는 그 어느 때보다 크다. 동시에 더 많은 소프트웨어 프로젝트와 애플리케이션 출시를 지원할 수 있는, 더 빠르고 혁신적인 방법을 찾으라는 IT에 대한 요구의 목소리도 커지고 있다. 하지만 아무리 프로세스나 툴이 발전하더라도 그것은 말처럼 쉬운 문제가 아니다.
 
ⓒ Getty Images Bank 

로우코드(low-code) 개발, 노-코드(no-code) 개발, 그리고 시민 개발(citizen development)이라는 3가지 방법론들은 IT 개발자로 하여금 치를 떨게 만든다. 하지만 꼭 그렇게 거부해야 할까. 이런 방법론들을 무조건 나쁜 것으로 치부하고 넘어가기 전에 한 번쯤 이들을 제대로 이해하고, 제대로 된 전문가의 지도가 있다면 실제로 효과적인 방법론이 될 수 있지는 않을지 생각해 볼 필요가 있다. 

또한 이런 방법론의 한계를 좀 더 구체적으로 파악한다면 이들에 대한 부정적인 견해를 내놓을 때에도 구체적인 분석과 근거에 기반해 반대할 수 있게 될 것이다.
 

비즈니스 리더들이 로우코드 플랫폼에 관심갖는 이유 

많은 개발 팀은 다음과 같은 압박에 직면하고 있으며 이로 인해 비즈니스 리더들은 IT 개발자들을 보조하기 위해 새로운 접근 방식을 물색하고 있다.

- 3개 부서에서 생산 작업을 추적하기 위해 스프레드시트를 공유하고 있다. 스프레드시트의 데이터 검증은 제한적인 데다 오류가 발생해 작업 품질 문제가 발생하고 있는 상황이다. 스프레드시트를 없애고 부서의 생산성과 품질을 향상시키는 새로운 워크플로우 애플리케이션을 며칠 이내에 프로토타입으로 제작, 개발, 테스트 및 배포까지 하는 것이 가능하겠는가. 

- 한편 현장 운영팀은 고객을 방문할 때마다 여러 기업 시스템의 정보를 업데이트 해 달라고 요청받고 있다. 과연 개발팀은 운영팀을 위해 시스템에 쉽고 빠르게 연결할 수 있는 단일 툴을 제공하는 모바일 애플리케이션을, 얼마나 신속하게 제작해 낼 수 있을까. 

비즈니스 리더들은 운영을 디지털화하고, 고객에게 개인화된 경험을 제공하면 할수록 상당한 경쟁 우위를 확보할 수 있다는 것을 알고 있다. 이들은 애자일한 관행을 지원하고, 애플리케이션을 조기에 출시하며, 사용자들로부터 배우고, 변화하는 수요와 기회에 맞춰 애플리케이션을 조정하고자 한다.
 
이 가운데서도 특히 CIO 및 CFO는 애플리케이션 개발 및 지원 비용에 각별히 신경쓴다. 그렇기 때문에 지속적으로 지원이 필요한 레거시 플랫폼과 전용 애플리케이션의 수를 줄이고 싶어한다. 이들은 유능한 소프트웨어 개발팀이 수익을 창출하거나, 막대한 경쟁 우위를 제공해 줄 수 있는 애플리케이션을 개발해 주기를 기대한다. 또한 운영 환경에 새롭게 구축된 애플리케이션의 확장성과 성능을 확인하고자 한다. 

이를 위해 비즈니스 리더들은 소프트웨어 개발 생산성과 품질을 향상시킬 개발 프로세스 및 기술을 관리할 애자일한 방법을 찾게 된다.

IT 업체들은 애플리케이션 개발, 지원을 좀 더 용이하게 만들어 줄 플랫폼과 툴을 채택하는 것으로 이런 문제에 대처하고 있다. 예를 들어, IDE(Integrated Development Environment, 통합 개발 환경) 및 코드 에디터와 같은 툴들을 사용하면 자바, .Net, PHP, 자바스크립트, 파이썬 및 기타 프로그래밍 언어로 커스터마이징 애플리케이션을 개발해야 하는 상황에서 생산성을 끌어올릴 수 있다. 

한편 애플리케이션 개발, 지원에 필요한 코드를 최소화하는 전략을 택하는 경우도 있다. 이들을 로우코드, 노-코드, 또는 시민 개발 플랫폼이라고 부른다. 이들은 보통 클라우드 기반 기술들로, 애플리케이션 개발을 위한 툴을 제공하며, 생산 사용례에서 애플리케이션을 구동하며, UI와 데이터, 그리고 워크플로우를 다른 기술과 통합하기도 한다. 

비즈니스 리더들이 주로 듣게 되는 내용들은 다음과 같다. 
- 로우코드 툴 공급업체 아웃시스템스(OutSystems)의 개발 지원 책임자 스테이시 르바인은 로우코드 방식에 대해 다음과 같이 말했다. "비즈니스적 관점에서 로우코드 플랫폼이 가치있는 이유는 로우코드 개발을 할 경우 전통적인 코드에서 신경쓰던 미묘한 뉘앙스들에 대해 개의치 않고 복잡한 핵심 프로세스를 전달하는 데에만 온전히 집중할 수 있기 때문이다. 개발자들로서는 애플리케이션을 더 빠르게 내놓을 수 있고, 이로 인해 비즈니스에 더 많은 가치를 제공할 수 있다."

- 또 다른 로우코드 툴 업체 퀵 베이스(Quick Base)의 전략 및 제품 담당 수석 부대표 제이 제이미슨은 "오늘날 기업 환경에서는 개발자에 대한 수요는 크고 공급은 턱없이 부족한 상황이다 보니 개발자가 무척 귀한 몸이 되었다. 이제 소프트웨어가 지배하는 세상이 오면서, 기업들로서는 개발 역량을 최대한 확보하는 것이 무척 중요해졌다. 로우코드 플랫폼은 이런 상황에 대한 나름의 해결책을 제시해 준다"고 말했다. 

이들 플랫폼 중에는 15년 전부터 존재해 왔던 것들도 있으며, 특히 요즘 들어서는 소프트웨어 애플리케이션 개발에 투자하는 기업들이 늘어나면서 로우코드 플랫폼을 채택하는 곳도 늘고 있다.
 

로우코드와 노-코드, 그리고 시민 개발 간 차이점 

한편, 이들 플랫폼을 지칭하는 용어들이 다소의 혼란을 야기하기도 한다. 
로우코드 플랫폼이란 용어는 애플리케이션을 개발하기 위해 필요한 코딩이 있음을 의미하지만, IT 업체는 애플리케이션을 개발하기 위해 저인력 툴을 판매하고 있다. 이는 드래그 앤 드롭 인터페이스, 시각적 프로그래밍 모델, WYSIWYG 사용자 인터페이스 설계 도구 및 잠재적으로 높은 품질의 애플리케이션을 만들 수 있는 기타 패러다임의 형태일 수 있다.

로우코드 플랫폼이라는 용어는 그 자체로 애플리케이션에 어느 정도의 코딩은 필요하다는 뜻을 내포하고 있다. 그러나 관련 솔루션 업체에서는 애플리케이션 개발에 필요한 저인력 툴을 판매하고 있다. 드래그-앤-드롭 인터페이스라던지 시각적 프로그래밍 모델, WYSIWYG 유저 인터페이스 디자인 툴 등 보다 적은 시간을 투자해서 가능한 한 최상의 퀄리티로 애플리케이션을 만들 수 있게 해 주는 여러 가지 기능들이 그것이다. 

로우코드 플랫폼은 스스로를 개발자와 차별화한다. 좀 더 정교하고 복잡한 로우코드 플랫폼은 애플리케이션 개발자들을 표적으로 삼으며 개발 과정을 쉽고 생산적으로 만들고자 한다.

한편, 애플리케이션 개발에 코드가 거의, 또는 아예 필요없는 플랫폼도 있다. 이런 플랫폼들을 사용하면 자체적인 애플리케이션을 생성하고 지원할 수 있다. 개발자들은 이러한 '노-코드' 플랫폼을 사용해 정교한 애플리케이션을 제작해 낸다. 때로는 이런 노-코드 플랫폼을 비즈니스 개발자에게 위임할 경우 이것이 시민 개발 플랫폼이 되기도 한다. 

이 플랫폼들은 리서치 업체마다 부르는 이름도 다르다. 가트너는 이를 '서비스형 애플리케이션 플랫폼(APaaS, Application Platforms as a Service)'이라고 부르며, 포레스터는 이들을 두 카테고리로 나누어 애플리케이션 개발 및 전달을 위한 로우코드와 비즈니스 개발자들을 위한 로우코드로 구분했다.
 

로우코드와 노-코드 플랫폼 검토 시 해야 할 핵심 질문

로우코드 플랫폼에서 가장 중요한 것은 비즈니스가 필요로 하는 종류의 애플리케이션을, 괜찮은 품질의 사용자 경험과 함께 제공할 수 있느냐다. 이것을 기존의 프로그래밍 방식보다 더 저렴한 비용, 시간 및 인력으로 달성할 수 있는지 여부다.  

이들 플랫폼 가운데 상당수는 일반적인 개발 언어 및 관련 환경처럼 모든 종류의 애플리케이션 개발에 다 사용할 수 있는 것이 아니라 특정한 부류의 애플리케이션 개발에만 맞도록 최적화 되어 있기도 하다. 이들은 개발자가 애플리케이션을 빠르고 쉽게 만들 수 있도록 일종의 가이드 라인을 제공한다.
 
그렇다면 로우코드, 노-코드 및 시민 개발 플랫폼을 검토할 때 어떤 사항들을 중점적으로 봐야 할까. 다음의 질문들은 이와 같은 플랫폼들을 검토할 때 반드시 물어야 할 사항들이다. 

- 해당 플랫폼이 어떤 류의 애플리케이션 개발에 도움을 주는가. 
- 플랫폼이 만족스러운 사용자 경험을 제공하는가, 아니면 결국에는 네이티브 코드로 다시 커스터마이징하는 과정을 거쳐야 하는가. 
- 해당 플랫폼이 제공하는 통합이 자사가 개발하고자 하는 애플리케이션에 부족함이 없는가. 
- 개발자 경험과 기술 기대치가 조직의 역량과 잘 부합하는가.
- 해당 플랫폼이 지원하는 호스팅 모델 및 규정 준수 표준이 자사의 규제 필요를 충족하는가.
- 이 플랫폼의 개발 프로세스 및 애플리케이션 수명 주기는 자사가 개발하고자 하는 애플리케이션의 최소 기준치를 충족하는가. 
- 개발하려는 애플리케이션에 대해 비용 모델은 잘 부합하는가. 
 

'롱 테일', 로우코드 및 노-코드 플랫폼이 더 적합한 경우

로우코드 업체 킨톤(Kintone) CEO 데이브 란다는 로우코드 및 노-코드 플랫폼이 충분히 성숙해 이제는 상당히 정교한 수준의 애플리케이션 제작에 사용될 수 있다고 말했다. 

한편 또 다른 업체 카스피오(Caspio) CEO 프랭크 자마니는 "이 플랫폼들을 사용하는 것이 적합한 애플리케이션이 따로 있다"며, "모든 기업은 롱 테일 프로세스를 가지고 있다. 대부분의 기업에서는 주력 운영 기능이 가장 많은 주목을 받지만, '롱 테일' 문제를 해결하지 않고는 그 어떤 조직도 혁신할 수 없다"고 설명했다. 롱 테일 프로세스는 모든 부서에 존재한다.

- 마케팅의 경우 기업 웹사이트에 게재되는 콘텐츠에 대한 편집 과정을 추적하는 하나의 방법으로 로우코드 플랫폼이 사용될 수 있다.
- 인사과라면 새로운 직원이나 계약 업체를 채용하기 위한 프로세스 간소화에 사용될 수 있을 것이다. 
- 재무부의 경우 부서별 예산을 제안, 검토 및 조정하는 연례 워크플로우가 될 수 있을 것이다.
- 운영팀에서는 주요 위기 상황이나 문제에 대응하도록 설계된 특수 애플리케이션 제작에 이 같은 플랫폼을 사용한다. 
- 개인적으로, IT 부서에서 로우코드 플랫폼을 사용해 부서 예산을 관리하고, IT 자산 추적 및 혁신 파이프라인을 관리한 경험이 있었다. 
- 로우코드 플랫폼은 또한 공급망 측면과 파트너와의 워크플로우, 그리고 공급업체 관리를 위한 툴 등을 관리할 때에도 사용된다.
 

개발자에게 로우코드란, 적군인가 아군인가 

이러한 롱 테일 사용례들의 공통점은, 이 문제를 해결하기 위해 애플리케이션을 개발해야 한다는 비즈니스 사례를 설득력있게 만들기가 쉽지 않다는 것이다. 그 결과 일부 사용례들은 충분한 지원을 받지 못하기도 한다.

- 이메일, 스프레드시트 등 기타 오피스 툴로 임시 방편 워크플로우를 만들어 문제를 해결하려는 경우
- IT의 통제권에서 벗어난, 외부 구입 기술을 사용해 문제를 해결하는 경우. 이는 비효율과 리스크를 증가시키는 일종의 쉐도우 IT가 된다. 
- 가장 최악의 경우는 해결책이 아예 없는 상태에서, 그 어떤 정보나 콜라보레이션 툴도 제공하지 않고 '알아서 해결하라'는 식으로 직원들에게 떠밀어 두는 것이다.

이런 바람직하지 못한 결과를 피하려면, 개발자가 앞장서서 로우코드 솔루션을 사용하도록 주도해야 한다. 특히 좀 더 복잡하고 정교한 애플리케이션 개발에 로우코드 기술을 사용할 수 있다면 기존의 개발 방식으로는 비용이나 시간 측면에서 도저히 감당할 수 없었던 비즈니스 수요를 충족할 수 있게 될 것이다. 

또한 로우코드 플랫폼이 제공하는 가이드라인이 애플리케이션 품질을 향상시키고, 사용자 경험을 개선하며, 네이티브 개발 언어를 사용해 만든 애플리케이션보다 안전한 호스팅 플랫폼을 제공해 줄 것으로 기대해 볼 수 있다. 

또한 개발자들은 유지 및 지원 가능한 애플리케이션 개발에 있어 시민 개발자들의 노력을 보조, 지원해 줄 수도 있다. 로우코드 및 노-코드 플랫폼이 있으면 시민 개발이 가능하긴 하겠지만, 그럼에도 여전히 UI 디자인이나 데이터 아키텍처, 명명규칙(naming conventions), 테스팅과 같은 작업에서는 비즈니스 개발자들의 도움이 필요하다. editor@itworld.co.kr 


2018.12.03

글로벌 칼럼 | 개발자들이 '로우코드 플랫폼'에 대해 다시 생각해야 하는 이유

Isaac Sacolick | InfoWorld
새로운 애플리케이션에 대한 비즈니스 수요는 그 어느 때보다 크다. 동시에 더 많은 소프트웨어 프로젝트와 애플리케이션 출시를 지원할 수 있는, 더 빠르고 혁신적인 방법을 찾으라는 IT에 대한 요구의 목소리도 커지고 있다. 하지만 아무리 프로세스나 툴이 발전하더라도 그것은 말처럼 쉬운 문제가 아니다.
 
ⓒ Getty Images Bank 

로우코드(low-code) 개발, 노-코드(no-code) 개발, 그리고 시민 개발(citizen development)이라는 3가지 방법론들은 IT 개발자로 하여금 치를 떨게 만든다. 하지만 꼭 그렇게 거부해야 할까. 이런 방법론들을 무조건 나쁜 것으로 치부하고 넘어가기 전에 한 번쯤 이들을 제대로 이해하고, 제대로 된 전문가의 지도가 있다면 실제로 효과적인 방법론이 될 수 있지는 않을지 생각해 볼 필요가 있다. 

또한 이런 방법론의 한계를 좀 더 구체적으로 파악한다면 이들에 대한 부정적인 견해를 내놓을 때에도 구체적인 분석과 근거에 기반해 반대할 수 있게 될 것이다.
 

비즈니스 리더들이 로우코드 플랫폼에 관심갖는 이유 

많은 개발 팀은 다음과 같은 압박에 직면하고 있으며 이로 인해 비즈니스 리더들은 IT 개발자들을 보조하기 위해 새로운 접근 방식을 물색하고 있다.

- 3개 부서에서 생산 작업을 추적하기 위해 스프레드시트를 공유하고 있다. 스프레드시트의 데이터 검증은 제한적인 데다 오류가 발생해 작업 품질 문제가 발생하고 있는 상황이다. 스프레드시트를 없애고 부서의 생산성과 품질을 향상시키는 새로운 워크플로우 애플리케이션을 며칠 이내에 프로토타입으로 제작, 개발, 테스트 및 배포까지 하는 것이 가능하겠는가. 

- 한편 현장 운영팀은 고객을 방문할 때마다 여러 기업 시스템의 정보를 업데이트 해 달라고 요청받고 있다. 과연 개발팀은 운영팀을 위해 시스템에 쉽고 빠르게 연결할 수 있는 단일 툴을 제공하는 모바일 애플리케이션을, 얼마나 신속하게 제작해 낼 수 있을까. 

비즈니스 리더들은 운영을 디지털화하고, 고객에게 개인화된 경험을 제공하면 할수록 상당한 경쟁 우위를 확보할 수 있다는 것을 알고 있다. 이들은 애자일한 관행을 지원하고, 애플리케이션을 조기에 출시하며, 사용자들로부터 배우고, 변화하는 수요와 기회에 맞춰 애플리케이션을 조정하고자 한다.
 
이 가운데서도 특히 CIO 및 CFO는 애플리케이션 개발 및 지원 비용에 각별히 신경쓴다. 그렇기 때문에 지속적으로 지원이 필요한 레거시 플랫폼과 전용 애플리케이션의 수를 줄이고 싶어한다. 이들은 유능한 소프트웨어 개발팀이 수익을 창출하거나, 막대한 경쟁 우위를 제공해 줄 수 있는 애플리케이션을 개발해 주기를 기대한다. 또한 운영 환경에 새롭게 구축된 애플리케이션의 확장성과 성능을 확인하고자 한다. 

이를 위해 비즈니스 리더들은 소프트웨어 개발 생산성과 품질을 향상시킬 개발 프로세스 및 기술을 관리할 애자일한 방법을 찾게 된다.

IT 업체들은 애플리케이션 개발, 지원을 좀 더 용이하게 만들어 줄 플랫폼과 툴을 채택하는 것으로 이런 문제에 대처하고 있다. 예를 들어, IDE(Integrated Development Environment, 통합 개발 환경) 및 코드 에디터와 같은 툴들을 사용하면 자바, .Net, PHP, 자바스크립트, 파이썬 및 기타 프로그래밍 언어로 커스터마이징 애플리케이션을 개발해야 하는 상황에서 생산성을 끌어올릴 수 있다. 

한편 애플리케이션 개발, 지원에 필요한 코드를 최소화하는 전략을 택하는 경우도 있다. 이들을 로우코드, 노-코드, 또는 시민 개발 플랫폼이라고 부른다. 이들은 보통 클라우드 기반 기술들로, 애플리케이션 개발을 위한 툴을 제공하며, 생산 사용례에서 애플리케이션을 구동하며, UI와 데이터, 그리고 워크플로우를 다른 기술과 통합하기도 한다. 

비즈니스 리더들이 주로 듣게 되는 내용들은 다음과 같다. 
- 로우코드 툴 공급업체 아웃시스템스(OutSystems)의 개발 지원 책임자 스테이시 르바인은 로우코드 방식에 대해 다음과 같이 말했다. "비즈니스적 관점에서 로우코드 플랫폼이 가치있는 이유는 로우코드 개발을 할 경우 전통적인 코드에서 신경쓰던 미묘한 뉘앙스들에 대해 개의치 않고 복잡한 핵심 프로세스를 전달하는 데에만 온전히 집중할 수 있기 때문이다. 개발자들로서는 애플리케이션을 더 빠르게 내놓을 수 있고, 이로 인해 비즈니스에 더 많은 가치를 제공할 수 있다."

- 또 다른 로우코드 툴 업체 퀵 베이스(Quick Base)의 전략 및 제품 담당 수석 부대표 제이 제이미슨은 "오늘날 기업 환경에서는 개발자에 대한 수요는 크고 공급은 턱없이 부족한 상황이다 보니 개발자가 무척 귀한 몸이 되었다. 이제 소프트웨어가 지배하는 세상이 오면서, 기업들로서는 개발 역량을 최대한 확보하는 것이 무척 중요해졌다. 로우코드 플랫폼은 이런 상황에 대한 나름의 해결책을 제시해 준다"고 말했다. 

이들 플랫폼 중에는 15년 전부터 존재해 왔던 것들도 있으며, 특히 요즘 들어서는 소프트웨어 애플리케이션 개발에 투자하는 기업들이 늘어나면서 로우코드 플랫폼을 채택하는 곳도 늘고 있다.
 

로우코드와 노-코드, 그리고 시민 개발 간 차이점 

한편, 이들 플랫폼을 지칭하는 용어들이 다소의 혼란을 야기하기도 한다. 
로우코드 플랫폼이란 용어는 애플리케이션을 개발하기 위해 필요한 코딩이 있음을 의미하지만, IT 업체는 애플리케이션을 개발하기 위해 저인력 툴을 판매하고 있다. 이는 드래그 앤 드롭 인터페이스, 시각적 프로그래밍 모델, WYSIWYG 사용자 인터페이스 설계 도구 및 잠재적으로 높은 품질의 애플리케이션을 만들 수 있는 기타 패러다임의 형태일 수 있다.

로우코드 플랫폼이라는 용어는 그 자체로 애플리케이션에 어느 정도의 코딩은 필요하다는 뜻을 내포하고 있다. 그러나 관련 솔루션 업체에서는 애플리케이션 개발에 필요한 저인력 툴을 판매하고 있다. 드래그-앤-드롭 인터페이스라던지 시각적 프로그래밍 모델, WYSIWYG 유저 인터페이스 디자인 툴 등 보다 적은 시간을 투자해서 가능한 한 최상의 퀄리티로 애플리케이션을 만들 수 있게 해 주는 여러 가지 기능들이 그것이다. 

로우코드 플랫폼은 스스로를 개발자와 차별화한다. 좀 더 정교하고 복잡한 로우코드 플랫폼은 애플리케이션 개발자들을 표적으로 삼으며 개발 과정을 쉽고 생산적으로 만들고자 한다.

한편, 애플리케이션 개발에 코드가 거의, 또는 아예 필요없는 플랫폼도 있다. 이런 플랫폼들을 사용하면 자체적인 애플리케이션을 생성하고 지원할 수 있다. 개발자들은 이러한 '노-코드' 플랫폼을 사용해 정교한 애플리케이션을 제작해 낸다. 때로는 이런 노-코드 플랫폼을 비즈니스 개발자에게 위임할 경우 이것이 시민 개발 플랫폼이 되기도 한다. 

이 플랫폼들은 리서치 업체마다 부르는 이름도 다르다. 가트너는 이를 '서비스형 애플리케이션 플랫폼(APaaS, Application Platforms as a Service)'이라고 부르며, 포레스터는 이들을 두 카테고리로 나누어 애플리케이션 개발 및 전달을 위한 로우코드와 비즈니스 개발자들을 위한 로우코드로 구분했다.
 

로우코드와 노-코드 플랫폼 검토 시 해야 할 핵심 질문

로우코드 플랫폼에서 가장 중요한 것은 비즈니스가 필요로 하는 종류의 애플리케이션을, 괜찮은 품질의 사용자 경험과 함께 제공할 수 있느냐다. 이것을 기존의 프로그래밍 방식보다 더 저렴한 비용, 시간 및 인력으로 달성할 수 있는지 여부다.  

이들 플랫폼 가운데 상당수는 일반적인 개발 언어 및 관련 환경처럼 모든 종류의 애플리케이션 개발에 다 사용할 수 있는 것이 아니라 특정한 부류의 애플리케이션 개발에만 맞도록 최적화 되어 있기도 하다. 이들은 개발자가 애플리케이션을 빠르고 쉽게 만들 수 있도록 일종의 가이드 라인을 제공한다.
 
그렇다면 로우코드, 노-코드 및 시민 개발 플랫폼을 검토할 때 어떤 사항들을 중점적으로 봐야 할까. 다음의 질문들은 이와 같은 플랫폼들을 검토할 때 반드시 물어야 할 사항들이다. 

- 해당 플랫폼이 어떤 류의 애플리케이션 개발에 도움을 주는가. 
- 플랫폼이 만족스러운 사용자 경험을 제공하는가, 아니면 결국에는 네이티브 코드로 다시 커스터마이징하는 과정을 거쳐야 하는가. 
- 해당 플랫폼이 제공하는 통합이 자사가 개발하고자 하는 애플리케이션에 부족함이 없는가. 
- 개발자 경험과 기술 기대치가 조직의 역량과 잘 부합하는가.
- 해당 플랫폼이 지원하는 호스팅 모델 및 규정 준수 표준이 자사의 규제 필요를 충족하는가.
- 이 플랫폼의 개발 프로세스 및 애플리케이션 수명 주기는 자사가 개발하고자 하는 애플리케이션의 최소 기준치를 충족하는가. 
- 개발하려는 애플리케이션에 대해 비용 모델은 잘 부합하는가. 
 

'롱 테일', 로우코드 및 노-코드 플랫폼이 더 적합한 경우

로우코드 업체 킨톤(Kintone) CEO 데이브 란다는 로우코드 및 노-코드 플랫폼이 충분히 성숙해 이제는 상당히 정교한 수준의 애플리케이션 제작에 사용될 수 있다고 말했다. 

한편 또 다른 업체 카스피오(Caspio) CEO 프랭크 자마니는 "이 플랫폼들을 사용하는 것이 적합한 애플리케이션이 따로 있다"며, "모든 기업은 롱 테일 프로세스를 가지고 있다. 대부분의 기업에서는 주력 운영 기능이 가장 많은 주목을 받지만, '롱 테일' 문제를 해결하지 않고는 그 어떤 조직도 혁신할 수 없다"고 설명했다. 롱 테일 프로세스는 모든 부서에 존재한다.

- 마케팅의 경우 기업 웹사이트에 게재되는 콘텐츠에 대한 편집 과정을 추적하는 하나의 방법으로 로우코드 플랫폼이 사용될 수 있다.
- 인사과라면 새로운 직원이나 계약 업체를 채용하기 위한 프로세스 간소화에 사용될 수 있을 것이다. 
- 재무부의 경우 부서별 예산을 제안, 검토 및 조정하는 연례 워크플로우가 될 수 있을 것이다.
- 운영팀에서는 주요 위기 상황이나 문제에 대응하도록 설계된 특수 애플리케이션 제작에 이 같은 플랫폼을 사용한다. 
- 개인적으로, IT 부서에서 로우코드 플랫폼을 사용해 부서 예산을 관리하고, IT 자산 추적 및 혁신 파이프라인을 관리한 경험이 있었다. 
- 로우코드 플랫폼은 또한 공급망 측면과 파트너와의 워크플로우, 그리고 공급업체 관리를 위한 툴 등을 관리할 때에도 사용된다.
 

개발자에게 로우코드란, 적군인가 아군인가 

이러한 롱 테일 사용례들의 공통점은, 이 문제를 해결하기 위해 애플리케이션을 개발해야 한다는 비즈니스 사례를 설득력있게 만들기가 쉽지 않다는 것이다. 그 결과 일부 사용례들은 충분한 지원을 받지 못하기도 한다.

- 이메일, 스프레드시트 등 기타 오피스 툴로 임시 방편 워크플로우를 만들어 문제를 해결하려는 경우
- IT의 통제권에서 벗어난, 외부 구입 기술을 사용해 문제를 해결하는 경우. 이는 비효율과 리스크를 증가시키는 일종의 쉐도우 IT가 된다. 
- 가장 최악의 경우는 해결책이 아예 없는 상태에서, 그 어떤 정보나 콜라보레이션 툴도 제공하지 않고 '알아서 해결하라'는 식으로 직원들에게 떠밀어 두는 것이다.

이런 바람직하지 못한 결과를 피하려면, 개발자가 앞장서서 로우코드 솔루션을 사용하도록 주도해야 한다. 특히 좀 더 복잡하고 정교한 애플리케이션 개발에 로우코드 기술을 사용할 수 있다면 기존의 개발 방식으로는 비용이나 시간 측면에서 도저히 감당할 수 없었던 비즈니스 수요를 충족할 수 있게 될 것이다. 

또한 로우코드 플랫폼이 제공하는 가이드라인이 애플리케이션 품질을 향상시키고, 사용자 경험을 개선하며, 네이티브 개발 언어를 사용해 만든 애플리케이션보다 안전한 호스팅 플랫폼을 제공해 줄 것으로 기대해 볼 수 있다. 

또한 개발자들은 유지 및 지원 가능한 애플리케이션 개발에 있어 시민 개발자들의 노력을 보조, 지원해 줄 수도 있다. 로우코드 및 노-코드 플랫폼이 있으면 시민 개발이 가능하긴 하겠지만, 그럼에도 여전히 UI 디자인이나 데이터 아키텍처, 명명규칙(naming conventions), 테스팅과 같은 작업에서는 비즈니스 개발자들의 도움이 필요하다. editor@itworld.co.kr 


X