노코드/로우코드 도구가 실패하는 7가지 이유
컨텐츠 정보
- 조회 657
본문
노코드/로우코드 개발 도구의 잠재적 이점으로는 애플리케이션 개발 속도 향상, 비용 절감, 민첩성 향상 등이 있다. 그러나 이 기술이 모든 상황에 적합한 것은 아니며, 때에 따라 노코드/로우코드 솔루션이 생산성을 저해할 수도 있다.
그랜드 뷰 리서치(Grand View Research)는 2023년부터 2030년까지 전 세계 로우코드 개발 플랫폼 시장이 연평균 약 23%의 성장률을 보일 것으로 예상한다. 이 보고서는 이런 성장의 원인을 디지털 전환과 비즈니스 운영 자동화에 대한 관심이 증가했기 때문이라고 분석한다. 또한 신속한 솔루션과 보다 간소화된 비즈니스 프로세스에 대한 수요가 증가했기 때문일 수도 있다.
개발이 더 쉬워질 것이라는 약속이 매력적이기는 하지만, 기업은 조직은 노코드/로우코드 도구와 플랫폼의 잠재적인 함정을 피할 수 있도록 준비해야 한다. 저희는 기술 리더들에게 이런 솔루션으로 마이그레이션할 때 주의해야 할 점을 물었다.
#1. 깊이감과 유연성의 상실
노코드/로우코드의 핵심적인 사용례는 숙련되지 않은 사용자도 소프트웨어를 만들 수 있도록 하는 것이다. 이를 통해 소프트웨어를 만들 수 있는 사람의 범위를 넓히는 것은 물론, 개발자를 더 적게 고용해 기업에 재정적인 혜택을 줄 수 있다. 그러나 노코드/로우코드 솔루션을 채택하는 기업은 그 과정에서 어느 정도의 유연성을 잃을 수 있다는 것을 각오해야 한다.
클라우드 서비스 업체인 케이런트(Caylent)의 클라우드 네이티브 개발 부문 선임 이사인 클레이튼 데이비스는 “노코드/로우코드 플랫폼은 일반적으로 비즈니스 사용자가 간단한 앱을 빠르게 개발할 수 있도록 미리 정의된 템플릿과 구성 요소 세트를 제공한다. 그러나 이런 템플릿은 최종 사용자의 요구에 부응하는 진정한 맞춤형 솔루션을 만드는 데 필요한 유연성과 깊이가 부족한 경우가 많다”라고 지적했다.
노코드/로우코드 도구와 플랫폼은 내부 비즈니스 솔루션이나 간단한 작업에는 충분하지만, “사용자 경험이 채택과 만족도에 중요한 고객 대면 애플리케이션에 필요한 기준을 충족하지 못한다”라고 데비이스의 평가다.
노코드/로우코드 도구는 애플리케이션 아키텍처를 제대로 통제해야 하는 개발자에게는 제한적이다. 비디오 압축 기술 개발업체인 딥 렌더(Deep Render)의 CTO 아살란 자파르는 “확장성 옵션이 있는 로우코드 플랫폼을 사용하거나 필요할 때 API를 활용해 사용자 지정 기능을 통합하는 것”이라고 해결책을 제시했다.
#2. 지나치게 단순화된 솔루션
지나치게 단순화된 솔루션은 비즈니스 사용자가 문제의 뉘앙스를 완전히 해결하지 못하는 애플리케이션을 만들 수 있다. 딥 렌더는 자사의 비디오 코덱을 비교하는 애플리케이션을 구축하는 과정에서 이런 문제에 직면했다. 자파르는 “처음에는 노코드 플랫폼 덕분에 애플리케이션의 기본 버전을 신속하게 프로토타입으로 제작하고 배포할 수 있었다. 기존의 개발 방법으로 처음부터 시작하는 것에 비해 시간이 크게 절약됐다”고 말했다. 그러나 개발이 진행되면서 딥 렌더는 큰 장애물에 부딪혔다.
자파르는 “시장에서 우리 제품을 차별화할 수 있는 맞춤형 기능을 통합하는 과정에서 플랫폼의 한계가 더욱 분명해졌다”라며, ”다층적 비디오 비교 지표나 AI 기반 개선 기능과 같은 고급 기능을 통합하는 것은 지루하고 시간이 많이 걸리는 과정이 됐다”고 설명했다.
맞춤형 통합에 대한 지원이 부족해 딥 렌더는 플랫폼의 제약 조건을 해결하는 데 추가 시간을 투자해야 했고, 이로 인해 맞춤형 솔루션을 제공하는 역량이 떨어졌다. 자파르는 “이 경험을 통해 노코드 도구를 사용해 신속하게 무언가를 구축하는 속도와 편리함의 장점과, 더 복잡한 엔터프라이즈 수준의 요구에 맞게 제품을 확장할 때의 유연성 부족 사이의 절충점을 알게 됐다”고 덧붙였다.
#3. 확장 실패
AI 튜토리얼과 도구 공유 플랫폼 DigitalSamaritan의 설립자이자 소프트웨어 엔지니어인 쿠샹크 아가왈은 “노코드/로우코드는 최소 기능 제품(Minimum Viable Products)의 프로토타이핑이나 테스트에는 매우 유용하지만, 규모를 확장하는 데는 극히 부족하다”고 지적했다.
예를 들어, 아가왈은 AI 도구인 프롬프트 지니(Prompt Genie)에 대한 아이디어를 노코드 접근 방식을 사용해 단 4일 만에 출시하고, 첫 번째 유료 고객을 확보했다. 하지만 일단 제품을 시장에 출시하고 나니, 확장 과정에서 큰 어려움을 겪었다. 당시 사용한 노코드/로우코드 플랫폼은 사용자 증가에 대처할 수 있도록 설계되지 않았기 때문이다.
아가왈은 “프롬프트 지니를 완전히 재구축하고 모든 사용자를 이전해야 했는데, 이 작업은 정말 까다로웠다. 데이터 손실, 다운타임, 워크플로우 중단 등의 문제가 발생할 수 있다. 아이디어의 검증 정도에 따라, 노코드/로우코드를 건너뛰고 확장성을 고려해 처음부터 새로 구축할 수 있다”고 밝혔다.
자파르는 작고 덜 복잡한 애플리케이션에는 적합하지만, “이런 플랫폼은 대규모 엔터프라이즈 애플리케이션의 요구 사항을 충족하는 데 어려움을 겪을 수 있다. 미션 크리티컬 시스템에 사용하기 전에 플랫폼의 장기적인 실행 가능성을 평가해야 한다”고 조언했다.
#4. 신뢰할 수 없는 LLM
오늘날 대부분의 노코드/로우코드 개발은 LLM을 사용하는데, 이는 많은 비용으로 이어질 수 있다. AWS 수석 머신러닝 엔지니어인 데반시 아가왈은 “LLM은 다음에 나올 단어를 예측하는 데 정말 능숙하다. 이를 바탕으로 문장과 코드를 생성할 수 있다. 그러나 LLM은 인간처럼 추론하지는 않는다”라며, “소프트웨어 제품의 요구 사항은 매우 복잡하고 끊임없이 진화하고 있다. LLM에서 적절한 결과를 얻으려면 여러 가지 프롬프트를 시도해야 하는데, 그렇게 하면 비용이 많이 들 수 있다”라고 지적했다.
또한, 제품 요구 사항이 계속 바뀌기 때문에 LLM에 제품 요구 사항에 대한 모든 정보를 제공하고 솔루션을 생성할 것을 기대하는 것은 어려운 일이다. 데반시 “챗GPT에게 작성한 코드의 실수를 지적하고 수정하라고 하면, 완전히 새로운 솔루션을 생성할 것이다. 제품 요구 사항이 변경될 때 어떤 혼란이 야기될지 상상해 보라”고 덧붙였다.
#5. 보안 위험
프로젝트 관리 소프트웨어 업체 퀵베이스(Quickbase)의 CIO 존 케네디는 “CIO라면 기업에 제공하는 기술이 기술이 안전하고 유용해야 한다고 생각한다. 안타깝게도 모든 노코드/로우코드 플랫폼이 보안과 거버넌스를 촉진하는 프레임워크를 기반으로 구축된 것은 아니다”라고 말한다. 예를 들어, 의료 분야처럼 규제가 엄격한 산업은 엄격한 요구사항이 있는데, 모든 플랫폼이 이를 지원하도록 만들어진 것은 아니다.
케네디는 “노코드 플랫폼이 기업 전체에 배포되거나 외부 사용자에게 개방되는 경우, 액세스와 제어를 제한하는 것이 현명할 수 있다”라며,”퀵베이스에는 수많은 고객이 관리하고 통합할 수 있는 수많은 도구와 업체를 사용하는데, 이 모든 정보와 데이터를 필요할 때 언제 어디서나 안전하게 액세스할 수 있어야 한다”고 강조했다.
코드에 작은 보안 결함이라도 있는 노코드 도구를 사용해 많은 웹사이트가 만들어지면, 치명적인 보안 위험이 발생한다. 데반시 아가왈은 “이 모든 웹사이트와 수백만 명의 사용자를 취약하게 만들 수 있다. 이런 노코드 도구를 사용하는 사람은 위험을 해결하는 방법을 모르기 때문에 해당 웹사이트는 오랫동안 위험에 노출된다”고 지적했다.
노코드/로우코드 도구의 사용이 증가함에 따라, 이런 종류의 심각한 위험도 기하급수적으로 증가하고 있다. 데반시 아가왈은 좋은 방법은 “항상 사람이 운전석에 앉게 하고 도구는 보조적인 역할로만 활용하는 것”이라며, “팀에 이런 도구로 만든 것을 검토할 수 있는 전문가가 한 명 이상 있어야 한다”고 강조했다.
#6. 솔루션 업체 종속
많은 노코드/로우코드 플랫폼이 폐쇄형 생태계로 작동하기 때문에 솔루션 업체를 바꾸기가 어려울 수 있다. 쿠샹크 아가왈은 “이런 종류의 의존성은 비용 상승으로 이어질 수 있고 유연성을 제한하며, 해당 플랫폼이 사용자가 필요한 기능의 서비스를 중단할 위험이 항상 존재한다”라고 지적했다.
마이크로소프트의 보안 기술 책임자 시리 바르마 베지라주는 “플랫폼을 바꿔야 한다면 그것은 악몽과도 같은 일이다. 플랫폼에 종속되어 있기 때문에 플랫폼을 바꾸려면 새로운 플랫폼을 처음부터 이해해야 한다”라며, 플랫폼을 바꾸는 것은 모든 것을 처음부터 다시 구축하는 것을 의미한다고 설명했다. 베지라주는 “반면, 코드를 사용하면 일부 인프라 구성 요소와 종속성만 변경하면 된다”고 덧붙였다.
#7. 기술에 대한 과소평가
노코드/로우코드의 기술적 단점에 대해 이야기하면서 이들 도구의 잠재력을 과소평가하는 것도 문제이다. 알테릭스(Alteryx)의 최고 데이터 및 분석 책임자인 앨런 제이콥슨은 “어떤 사람은 솔루션의 이름과 비기술직 직원이 이용한다는 점 때문에 편견을 가질 수 있다. 이런 편견은 안타깝게도 이런 솔루션이 덜 강력하거나 덜 정교하다는 잘못된 가정으로 이어진다”고 지적했다. 제이콥슨은 팀이 도구의 모든 기능을 학습하고 이해하도록 함으로써 이런 오해를 해결할 수 있다고 말했다.
dl-itworldkorea@foundryco.com
관련자료
-
링크
-
이전
-
다음






