검색메뉴

KR

닫기

비즈니스

DX자료실

홍보센터

회사소개

인재영입

블로그

고객의 소리

SNS

DX Lounge

LG CNS 기술블로그 DX Lounge에서 최신 IT 소식을 만나보세요!

CNS Tech

DX시대, 떠오르는 ‘노코드/로우코드’ 운영 전략은?

2022.10.13


DX거버넌스를 앞당기는 노코드/로우코드
오늘날, 디지털 트랜스포메이션(Digital Transformation, DX)은 조직 생존의 문제로 자리 잡았습니다. 코로나 19 대유행으로 인해 디지털 혁신은 시급한 이슈로 떠올랐는데요. 일상 회복 단계에 놓인 현재, 디지털 비즈니스 운영은 조직 전체에 요구되는 DX 거버넌스 전략의 일부가 됐습니다.
DX는 기술과 관련된 디지털 혁신의 일부입니다. 정확히는 패러다임을 의미하며, 비즈니스 모델 촉진, 고객 경험 향상에 디지털 기술이 어떤 관련성과 긍정성을 보였는가에 중점을 둡니다. 즉, 빠른 테스트 주기로 비즈니스 및 고객 가치를 창출하고, 지표로 확인하는 것이 어느 때보다 중요합니다.
이번 주제인 노코드/로우코드(No-Code/Low-Code)는 팬데믹 이후 바뀐 기업 운영 방식, 급증하는 앱 수요, 치열한 경쟁을 가속화하고, 비즈니스 간소화 및 거버넌스를 통합해 DX를 앞당기기 위한 기술 동향으로 거론되고 있습니다.
노코드/로우코드로 인한 거버넌스 변화
노코드/로우코드는 새로운 발명품이 아닙니다. 웹이 발전한 모든 구간에 노코드/로우코드 솔루션이 존재했죠. 그러나 지금처럼 비즈니스 전체를 관통하는 동향은 아니었습니다. 그렇다면 왜 노코드/로우코드가 DX 가속화를 위한 기술 동향으로 떠오른 걸까요?



가트너에 따르면, 기업 내 노코드/로우코드를 주로 사용하는 사례는 아래와 같습니다.
1) 템플릿 또는 데이터 수집(58%)
2) 애플리케이션 내 비즈니스 프로세스 및 워크플로를 조정하는 애플리케이션(49%)
3) 종이, 이메일 또는 스프레드시트를 대체하는 애플리케이션(42%)
4) 현재 사용 중인 애플리케이션을 보조하는 애플리케이션(22%)
4가지로 구분했지만, 각 사례의 목적들이 큰 차이를 보이는 건 아닙니다. 기존 문서와 스프레드시트로 해결한 데이터를 좀 더 효율적인 방법으로 해결하고자 노코드/로우코드를 사용해 아이디어를 실현한다는 것이 주요 목적입니다.
마치 80년대 등장한 스프레드시트가 종이를 대체하기 시작한 것처럼 텍스트가 아닌 이미지, 동영상 등 더 다양한 데이터를 수용하게 된 현대에 필요한 애플리케이션을 노코드/로우코드로 해결한다는 겁니다.
노코드/로우코드를 단순히 개발 품질로만 얘기한다면 조악하기 그지없는 물건으로 볼 수 있습니다. 하지만 비즈니스마다, 데이터마다, 워크플로마다 다른 애플리케이션을 모두 개발자가 개발하는 것만큼 비효율적인 생산성도 없죠.
문제는 노코드/로우코드 앱이 범람하면서 조직 또는 부서마다 데이터 흐름이 다양해지고, 비정형 데이터의 생성도 증가해 거버넌스가 혼란스러운 변화를 마주하고 있다는 점입니다.
가트너는 조직이 개발한 새로운 애플리케이션의 약 70%가 노코드/로우코드 기술을 사용할 것이며, 이는 2020년보다 25% 증가한 수치일 것으로 전망했습니다.
유럽의 경우 직면한 기술 문제를 해소하려면 약 80만 명의 개발자가 더 필요한 상황인데요. 이를 노코드/로우코드 기술을 사용하는 시민 개발자(Citizen Development, Cit-dev)로 대체하는 건 육성이나 비용 측면에서도 꽤 합리적인 얘기처럼 들립니다. 조직 내 모든 부서가 각기 다른 여러 개의 노코드/로우코드 앱으로 데이터를 수집하고, 워크플로를 조정하지 않는다면 말이죠. 이는 CIO, CSO 등 담당자에게는 합리적인 것과 거리가 먼 얘기입니다. 이러한 거버넌스 변화에서 DX를 앞당기기 위해 노코드/로우코드를 적극적으로 활용한다면 운영 전략부터 재고해야 합니다.
직원들의 데이터 수집 및 워크플로 조정을 방해하지 않으면서 개발 리소스를 최소화하고, DX를 실현할 수 있도록 말입니다.
시민 개발자 운영 전략
기업이 원하든, 원치 않든 시민 개발자는 내부에서 늘어날 겁니다. 직원은 더 효율적으로 자신의 업무를 처리하고 싶을 것이고, 조직의 가이드라인을 벗어나지 않는 선에서 노코드/로우코드 솔루션을 사용하는 건 기술 지식이 없는 직원에게는 마법 같은 최선의 물건일 테니 말입니다.
그들이 노코드/로우코드에 접근한 순간, 시민 개발자로서 IT 리소스를 생산하게 됩니다. 결코 막을 수 없죠. 어떤 직원이 시민 개발자가 되더라도 대처할 수 있는 전략을 세워야 합니다.
다음은 시민 개발자 운영을 위한 5가지 가이드라인입니다.



1) 노코드/로우코드를 위한 파이프라인을 만들어라
대부분 시민 개발자는 자신이 만든 리소스가 IT 조직에 얼마나 많은 부담을 주는지 인지하지 못합니다. 자신의 업무를 처리하기 위한 도구이자 리소스일 뿐 중앙 시스템에 영향을 끼치지 않는다고 생각하기 때문입니다. 물론 영향이 없는 경우도 있습니다.
하지만 큰 위협이 단 하나의 영향에서 비롯될 수 있다는 걸 고려하면 IT 담당자가 관여하지 않아도 배포할 수 있는 파이프라인이 시민 개발자에게도 주어져야 합니다. 복잡한 파이프라인이 워크플로에 무겁다면 업무용 메신저에 노코드/로우코드 리소스를 연결하는 것만으로도 시작은 충분합니다.
2) 노코드/로우코드 워크플로를 감독하라
시민 개발자가 생겨나는 걸 막을 수 없다면 조직 내 노코드/로우코드 리소스는 끊임없이 증가할 것입니다. 파이프라인을 벗어난 결과물도 생기게 되죠. 모든 시민 개발자의 업무 과정을 IT 담당자가 해결해줄 수는 없습니다. 시민 개발자가 해결하지 못한 것을 IT 담당자가 떠맡게 되는 시나리오만큼 끔찍한 것도 없습니다.
그렇기 때문에 IT 담당자의 역할은 시민 개발자의 워크플로가 파이프라인을 벗어나는지 감독하는 것에 머물러야 합니다. 감독하는 과정을 파이프라인에 포함할 수 있다면 가장 좋습니다.
3) 노코드/로우코드 애플리케이션의 유지보수 계획을 마련하라
시민 개발자의 리소스는 일시적인 업무를 처리하기 위한 것도 많습니다. 그러나 IT 담당자는 해당 리소스가 일시적인지, 워크플로에 계속 머물러 있는지 알 수 없습니다. 노코드/로우코드 리소스도 수명 주기가 존재하는데요. 시민 개발자가 워크플로나 캠페인에 따라서 노코드/로우코드 리소스의 수명 주기를 파악하고, 유지보수 계획을 마련했을 때 파이프라인에 올릴 수 있도록 제한해야 합니다.
4) 제로트러스트 보안을 도입하고, 교육하라
노코드/로우코드 도구를 사용하기 위해서 시민 개발자는 수많은 계정을 만듭니다. 이 계정으로 언제, 어떤 네트워크에서 접근하고, 데이터 흐름을 만들어 낼지 전부 파악할 수 없습니다. 심지어 파이프라인을 벗어나지 않았다고 생각할 수도 있죠. 그렇다면 제로트러스트 보안을 도입하는 것이 가장 넓은 범위의 보안 위협을 해결하는 방법입니다. 어느 것도 신뢰하지 않고, 지속해서 검증하는 제로트러스트 보안은 파이프라인을 벗어나지 않게 안정감을 줄 뿐 아니라 보안 담당자가 항상 모니터링할 수 있도록 지원합니다. 시민 개발자에게 제로트러스트 보안 교육은 필수입니다.
5) 애플리케이션 상태 및 현황 모니터링을 요구하라
노코드/로우코드 리소스의 수명 주기만큼 쌓이는 데이터의 양도 무시할 수 없습니다. 하지만 대부분 노코드/로우코드 앱은 특정 업무를 빠르게 해결하기 위한 용도로 사용되기 때문에 그 외 데이터는 무시되는 경향이 있습니다. 이 데이터들이 쌓이면서 앱 상태를 무겁게 만들고, 무거운 앱은 또 다른 노코드/로우코드 앱으로 전환될 가능성이 큽니다. 그럴 경우 기존 노코드/로우코드 앱에 데이터가 계속 쌓일 수 있고, 지표는 분산됩니다. 담당하는 시민 개발자가 상태 및 현황을 모니터링하도록 워크플로를 구성해야 합니다.
Catalyst no-code Workflow
페이져듀티(PagerDuty)의 자회사 카탈리틱(Catalytic)이 개발한 ‘카탈리틱 노코드 워크플로(Catalytic no-code workflow)’는 현재 유일한 시민 개발 워크플로 관리를 위한 클라우드 플랫폼입니다. 웹 기반 인터페이스로 즉각적인 설정, 빠른 구축, 빠른 변경이 특징으로 카탈리틱은 시민 개발자를 염두에 두고 거버넌스 균형을 맞췄다고 설명합니다.
카탈리틱 노코드 워크플로는 약 650개 이상의 앱 또는 솔루션과 통합합니다. 이미 회사에서 사용 중인 모니터링, 티켓팅, 채팅 도구를 연결해 빠르게 노코드/로우코드 워크플로를 구성할 수 있는데요. 또한, 노코드/로우코드 리소스를 사용한 직원, 고객, 파트너 온보딩, 세일즈 및 유통 파이프라인 보고, 계약, 구매, 채용 등 모든 유형의 콘텐츠에 대해 감독할 수 있도록 프로세스를 설계할 수 있습니다.
채용 프로세스 아웃소싱 회사인 가이던트 글로벌(Guidant Global)은 전 세계 약 2,600명의 직원이 계약을 관리합니다. 그중에서 몇 가지 반복적인 업무는 자동화 가능성이 있었지만, 개발 리소스를 사용하기에는 비효율적이었습니다.
그래서 가이던트 글로벌은 마이크로소프트의 로우코드 워크플로 자동화 서비스인 파워 오토메이트(Power Automate)로 프로세스를 자동화하고, 이를 관리하기 위해 카탈리틱 노코드 워크플로를 도입했습니다. 카탈리틱 노코드 워크플로에는 자동화 프로세스에 대한 교육 프로그램이 설정되어 있고, 직원이 업무를 수행하기 전에 카탈리틱 노코드 워크플로에서 교육 및 테스트를 진행해야 합니다. 여기에 개인정보보호 및 보안 관련 교육을 병행하며, 이 워크플로 안에서 직원은 자신이 필요한 자동화 프로세스를 개발해 사용할 수 있습니다. 만약 지속적인 유지보수나 애플리케이션이 필요하지 않은 상황이 오면 담당한 직원은 워크플로에서 배제됩니다.
가이던트 글로벌은 파워 오토메이트로 조직 내 시민 개발자의 요구를 충족하는 것과 동시에 카탈리틱 노코드 워크플로로 파이프라인 구축 및 거버넌스 관점에서 감독하는 것이 가장 중요한 사항이라고 설명합니다. 이는 노코드/로우코드 활용과 함께 거버넌스 변화가 일어나야 DX를 가속할 수 있다는 걸 잘 보여주는 사례입니다.



Catalyst no-code Workflow (출처: Catalytic)

섀도우 IT 운영 전략
섀도우 IT(Shadow IT)란 IT 담당자의 승인과 감독을 벗어난 소프트웨어 또는 클라우드 서비스가 조직 내에서 사용되는 현상이나 인프라를 의미합니다. 과거 조직 시선에서는 섀도우 IT가 위협일 수밖에 없었습니다. 보안 아키텍처를 벗어난 것이기에 대부분 조직 IT 문제의 시작이었기 때문이죠.
최근 이런 인식이 변하고 있습니다. 시장의 빠른 변화를 섀도우 IT로 대응해 성과를 낸 사례가 증가하면서 발생하지 않은 보안 위협보다 대응할 비즈니스에 초점을 두는 방법을 긍정적으로 검토하는 경영진이 늘었기 때문입니다. 대부분 섀도우 IT 노코드/로우코드 솔루션 활용에 익숙한 직원이 다룬다면 레거시 시스템보다 높은 업무 효율성으로 비즈니스를 검증하고, 확장할 기회를 마련할 수 있습니다. 검증이 완료되면 비즈니스를 전체 조직과 통합하고, 노코드/로우코드 리소스를 폐기하는 것으로 위협에서 벗어납니다.
그러나 모든 직원, 모든 시민 개발자가 이 방식을 따르는 건 아닙니다. 더군다나 비IT 부서에서 관리 없이 섀도우 IT가 벌어질 때 조직은 데이터 사일로를 파악하지 못할 수도 있습니다. 시민 개발자 운영 전략이 개발에 대한 감독 및 관리라면, 섀도우 IT는 더 방대한 영역에 대한 검토와 승인을 의미합니다. 다음은 섀도우 IT를 효율적으로 운영하기 위한 5가지 프레임워크입니다.

섀도우 IT (출처: Cisco)

1) 조직 내 섀도우 IT를 확인하고, 용도를 파악하라
조직 내 섀도우 IT가 만연한 것은 직원의 일탈이 아닐 수 있습니다. 내부 프로세스로 해결할 수 없는 부분이 섀도우 IT가 도달한 범위까지 뻗어 있다는 의미인데요. 대부분 섀도우 IT는 회사에서 지원하지 않는 기술을 도입하려는 시도로부터 시작하기 때문에 섀도우 IT를 확인하는 것만으로도 일부 비즈니스 프로세스 탐색하고, 직원 경험에 대한 통찰력을 얻을 수 있습니다.
2) 섀도우 IT가 어떤 보안 위협을 초래할 수 있는지 확인하라
섀도우 IT의 장점을 효율성으로 전환하기 위해 섀도우 IT를 활용하는 부서 또는 직원에게 보안 절차나 관리를 강요하는 건 도움이 되지 않습니다. 편의를 위해 보안 절차를 피해서 숨은 현상이 섀도우 IT입니다. 그렇기에 보안 평가와 캠페인 일정을 확인하고 섀도우 IT의 보안 위협이 얼마나 지속되는지 확인해야 합니다. 만약 보안 위협에서 벗어날 수 없는 섀도우 IT라면 통합보다는 캠페인 가이드라인이나 대안을 제시하는 쪽이 더 나은 방법입니다.
3) 섀도우 IT를 기업 솔루션으로 도입 및 기존 시스템과 통합할 수 있는지 확인하라
섀도우 IT에서 사용하는 기술은 보통 개인용과 기업용으로 따로 제공합니다. 기술의 용도 파악과 보안 평가가 이뤄졌다면 효율성과 지속성에 따라서 기업에 도입하는 것이 괜찮은 전략일 수도 있습니다. 이로써 가장 쉽게 섀도우 IT를 조직 내에서 제거할 수 있을 것입니다.
4) 섀도우 IT에 대한 대안을 제시할 수 있는지 탐색하라
섀도우 IT를 기존 시스템과 통합할 수 없을 수 있습니다. 일시적인 캠페인이라면 다행이지만, 지속할수록 보안 위협이 커질 가능성이 높은 존재일 수도 있죠. 그렇다고 대안 없이 제한하면 직원은 섀도우 IT로 진행하던 업무를 파악되지 않은 다른 섀도우 IT로 옮길 것입니다. 제한하기 전에 비슷하면서 통합하기 수월한 솔루션이 있는지 탐색하고, 먼저 마이그레이션을 제시해야 해당 업무에 대한 다음 섀도우 IT를 방지할 수 있습니다.
5) 노코드/로우코드로의 확장 여부를 확인하라
위 4단계를 거쳤다면 섀도우 IT의 향방도 결정도 할 수 있습니다. 지속해서 사용할 섀도우 IT는 조직의 업무 프로세스에 포함해야 하고, 이후에는 섀도우 IT를 활용한 부서나 직원 외 다른 부서 또는 직원에게 전달돼야 합니다. 그리고 이 과정에서 일부 사용한 섀도우 IT를 조직 전체로 확장할 때 어려움에 부딪힐 수 있습니다. 그렇다고 IT 부서에 맡기기에는 꽤 많은 자원을 낭비할 것입니다. 그럴 때 고민할 수 있는 솔루션이 시민 개발자가 노코드/로우코드를 활용하는 것이고, 이미 섀도우 IT가 노코드/로우코드로 구성돼 있다면 시민 개발자 운영 전략에 따라서 담당할 시민 개발자 및 리소스를 워크플로와 연결하기만 하면 됩니다.
섀도우 IT 운영 프레임워크의 핵심은 ‘섀도우 IT를 막을 수 없다는 것’과 ‘섀도우 IT의 효율부터 판단하는 것’입니다. 효과적인 DX 전략은 빠른 테스트와 대응입니다. 테스트는 이미 널리 퍼진 섀도우 IT로 조직의 깊은 내부에서 이뤄지고 있습니다. 효율을 판단한 이후에는 조직 내 확장, 비즈니스로의 확장까지 결정하는 것이고, 이를 빠르게 파이프라인으로 내보내기 위해서는 노코드/로우코드 활용을 통해 가시적인 커뮤니케이션을 할 필요가 있는 것이죠. 당연히 의사결정 구간마다 테스트와 검증을 반복하기 때문에 섀도우 IT부터의 시작을 바텀업(Bottom-up) 방식으로 해결하는 것이 의사결정 지연을 막는 방법입니다.
킨톤이 설명하는 섀도우 IT 위협과 노코드/로우코드 솔루션
노코드/로우코드 플랫폼 개발사인 킨톤(Kintone)은 ‘조직에서 섀도우 IT가 사용되고 있다는 건 현재 시스템이 수용할 수 없는 구체적인 워크플로가 있다는 신호이다.’라고 설명합니다.
IT 부서는 항상 거버넌스와 대응 계획을 가지고 있습니다. 그러나 거버넌스를 벗어난 경우를 파악하는 건 다른 문제인데요. 시스코가 기업 CIO들에게 설문 조사한 결과에 따르면, 조직 전체에서 실행되는 클라우드 애플리케이션 및 서비스의 수를 물었을 때 51개라는 응답했으나 실제 조사에서는 730개로 나타났습니다. 그만큼 조직이 수용하지 못하는 리소스가 조직 워크플로 전반에 영향을 끼치고 있다는 의미입니다. 이 수많은 채널을 IT 부서가 모두 해결한다는 건 불가능합니다.
킨톤은 자사 노코드/로우코드 플랫폼이 섀도우 IT의 거버넌스 문제를 해결할 수 있는 솔루션이라고 말합니다.
직원이 현재 직면한 문제를 해결할 수 있는 리소스가 없을 때 가장 먼저 업무에 대한 워크플로를 그립니다. 워크플로에 대한 요구사항이 정의되면 조직이 승인한 킨톤 플랫폼을 실행하고, 그려놓은 요구사항에 맞춰서 코드 없이 드래그 앤 드롭으로 새로운 워크플로를 구축합니다. 새로운 워크플로는 연결된 조직의 기존 시스템에 구축되므로 감독할 수 있는 범위 내에 존재하고, 새로운 소프트웨어를 도입할 필요성을 낮춥니다. 직원이 섀도우 IT에 의존하기 전에 시스템과 연결된 노코드/로우코드부터 접근하도록 파이프라인을 설계하라는 것입니다.
이렇게 구축된 파이프라인은 비교하고, 선정해 업무와 연결하기까지 시간이 걸리는 섀도우 IT를 불편하게 만듭니다. 직원이 워크플로를 개선하겠다고 생각한 직후 노코드/로우코드 솔루션부터 찾을 테니 말이죠. 이것이 비IT 부서 또는 직원에게 디지털 자유를 주면서 섀도우 IT를 유용하게 활용할 방법이라고 킨톤은 설명합니다.

킨톤 (출처: Kintone)

노코드/로우코드가 실패하는 이유는 무엇일까요?
시민 개발자는 개발자가 아니다
조직 또는 시민 개발자 당사자가 ‘시민 개발자는 개발자’라는 인식을 갖는 것은 위험합니다. 시민 개발자와 개발자는 개발을 직업으로 삼느냐, 삼지 않느냐는 큰 차이부터 시작하기 때문입니다.
시민 개발자가 노코드/로우코드를 활용하게 되는 원인은 단순히 쉬워서가 아닙니다. 개발을 배운다는 관점에서 접근하면 노코드/로우코드보다 조금 더 시간이 필요한 건 맞지만, 노코드/로우코드가 읽기도 쉽고, 높은 성능을 갖춘 구조화되고 효율적인, 표준을 잘 따르는 코드를 개발하기 위한 것이 아니라면 쉽게 개발할 수 있게 도와주는 수많은 프레임워크와 라이브러리가 존재한다는 측면에서 난이도만의 문제가 아니라는 걸 이해해야 합니다.
개발자는 프로그래밍 개념과 다양한 언어, 시스템 아키텍처를 배우고 이해하면서 코드 작성을 연습하는 데에 많은 시간을 쏟습니다. 이렇게 많은 시간을 쏟아야 하는 이해를 도구를 사용함으로써 얻을 수 있다는 건, 마치 밀키트를 조리할 수 있다면 전문 요리인이라고 말하는 것과 다르지 않습니다.
시민 개발자가 노코드/로우코드 도구를 사용하는 이유는 특정 업무를 해결하기 위한 IT 리소스를 쉽게 만들어서 사용하기 위함입니다. 이들의 일이 개발로 바뀌어서 시민 개발자라고 부르는 게 아닙니다. 목적이 개발이라면 시간을 노코드/로우코드 도구가 아닌 프로그래밍에 베팅하는 쪽이 훨씬 효율적입니다. 마케팅, 회계, 영업 등 기존 업무를 유지한 채로 베팅하기에 노코드/로우코드 도구의 접근성이 더 나을 뿐입니다.
이런 인식 차이가 없다면 노코드/로우코드는 실패할 가능성이 큽니다. 노코드/로우코드로 어떤 프로젝트의 문제 해결 방안을 찾았더라도 점차 개발자를 향한 요구사항이 확대되고, 결국 노코드/로우코드 도구가 해결할 수 없는 한계를 맞이하게 됩니다. 그리고 그것을 깨달았을 때는 이미 다른 문제로 넘어간 순간입니다. 이 문제도 노코드/로우코드로 해결할 수 있을까요?
개발자는 노코드/로우코드 도구의 한계를 고려하고, 프로젝트의 끝을 결정할 수 있습니다. 시민 개발자는 개발에 집중하지 않으므로 업무 시간도 부족하고, 전문성도 뒷받침되지 않습니다. 이에따라 새로운 섀도우 IT에 접근할 명분이 생기고, 조직 내 새로운 애플리케이션이 추가되며, 지속 불가능한 거버넌스를 가속합니다.
가트너는 2024년까지 전체 애플리케이션 개발 활동의 65% 이상이 노코드/로우코드로 개발한 애플리케이션일 것으로 예측했습니다. 그러한 애플리케이션은 대부분 지속하지 못하고, 끝내 한계를 맞이합니다. 좀 더 쉽게 말하면 일반적인 애플리케이션보다 소프트웨어 생명 주기가 짧다는 것입니다. 시민 개발자가 본연의 업무에 충실하도록 돕는 역할을 노코드/로우코드에 맡길 경우, DX 전략이 시민 개발자의 행동을 프로세스로 수용할 수 있어야 노코드/로우코드의 실패 확률을 줄일 수 있을 겁니다.
노코드/로우코드는 애플리케이션 제공보다 구축에 더 집중한다
노코드/로우코드의 사용은 최소 기능 제품(Minimum Viable Product, MVP)이 최종 목표일 확률이 높습니다. 본래 MVP는 아이디어를 검증하고, 확장하기 위한 초기 단계 제품을 의미합니다. 노코드/로우코드는 빠르게 MVP를 만들 수 있는 좋은 방법이지만, 그건 애플리케이션을 어떻게 제공할 것인지 고려됐을 때 얘기입니다.
섀도우 IT를 확인해 비즈니스 모델을 구축하는 건 워크플로의 확장성을 확인했을 때 판단할 수 있지만 시민 개발자의 노코드/로우코드 사용은 필요한 업무에 맞게 애플리케이션을 구축해 사용한다는 측면이 더 강합니다. ‘제공을 고려하고 개발한 것’과 ‘제공을 고려하고 개발하지 않은 것에서 확장할 아이디어를 발견’하는 건 엄연히 다릅니다.
이는 속도 면에서 고민할 부분입니다. 노코드/로우코드는 워크플로를 따라 기능을 배치해 테스트/검증을 반복하기에 개발 템포가 빠릅니다. 지속적인 제공 및 그 외 요소까지 짧은 기획 단계에서는 추가하기 어려운데요. 이것을 프로세스로 잡으려 한다면 더 많은 아이디어와 제약이 필요하고, 시민 개발자의 리소스를 낭비하게 될 겁니다. 경영진이 비즈니스 변환을 가져올 기술을 쉽게 판단할 수 없을 때 천 번이나 할 수 있었던 테스트/검증을 백 번밖에 할 수 없다면 DX 전략도 느릴 수밖에 없다는 얘기입니다.
노코드/로우코드는 구축에 더 집중할 수밖에 없습니다. 제공까지 검토하는 건 DX 전략에 따른 비즈니스 변환을 포함합니다. 당연히 비즈니스에 대한 의사결정을 시민 개발자에게 맡기는 건 아주 위험할 수 있고, 속도도 더딜 테니 노코드/로우코드의 실패 가능성이 커집니다. 속도를 줄이지 않으면서도 노코드/로우코드 관리 및 의사결정까지 이어지는 파이프라인을 갖출 때 DX 가속에 노코드/로우코드로 대응할 수 있습니다.
[출처]

https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences
https://f.hubspotusercontent40.net/hubfs/5600897/Content/Whitepaper/Catalytic-whtiepaper-technical%20overview%2004.pdf
https://www.pagerduty.com/catalytic/
https://blog.kintone.com/business-with-heart/tackling-the-challenges-of-shadow-it-with-no-code/low-code-solutions
https://www.gartner.com/en/newsroom/press-releases/2021-02-15-gartner
글 ㅣ LG CNS 정보기술연구소