‘선구자들이 귀뜸하는’ 로우코드 실수 7가지

기업들이 소프트웨어 개발 효율성을 높이고 디지털 비즈니스 노력을 지원하기 위해 로우코드(Low-code) 도구와 프로세스를 배치하고 있다. 이 기술을 성공적으로 활용하려면, 보편적인 실수를 피해야 한다.

리서치회사 가트너(Gartner)는 전 세계 로우코드 개발 시장이 2021년에 138억 달러일 것으로 전망했으며, 이는 2020년보다 23% 증가한 수치다. 팬데믹 중 원격 개발 증가로 인해 로우코드 도입이 지속적으로 증가했다는 설명이다.

로우코드 애플리케이션 개발은 새로운 것이 아니지만 ‘디지털 혁신, 초 자동화, 구성 가능한 비즈니스의 등장’의 융합으로 인해 도구가 등장하고 수요가 증가하고 있다고 해당 조사 기관은 진단했다. 

그러나 로우코드 제품과 프로세스의 배치에는 수많은 함정이 존재하며, 조직들은 이를 방지하거나 개발 운영에 대한 영향을 최소화할 수 있도록 이를 인지해야 한다고 가트너는 강조했다.
 

개발 근간을 간과
온라인 검색 제품 제공기업 엘라스틱(Elastic)의 CISO 맨디 안드레스는 “내가 경험한 가장 큰 문제는 로우코드 전략이 실제로 제공하는 것에 대한 오해에 기초한다. 많은 조직들이 비용을 절감하거나 개발 속도를 높이는 기회로써 로우코드 전략을 도입하고 있다. 하지만 로우코드 전략으로 개선할 수 있는 것이 무엇인지 이해하는 경우에만 성공할 수 있다”라고 말했다.

로우코드 전략은 경험이 부족한 개발자가 고급 기능을 생성할 수 있도록 지원함으로써 프로젝트에 필요한 개발자 비용을 낮추는 데 도움이 될 수 있다고 안드레스가 말했다. 개발 속도도 이점이 될 수 있으며, 애플리케이션에 구성요소가 재사용되는 경우는 더욱 그렇다.

안드레스는 “그러나 애플리케이션을 개발하기 위해 필요한 광범위한 비즈니스 및 거버넌스 프로세스가 많은 기업에서 부재하다. 비즈니스 요건은 무엇일까? 우리가 업무 분장 등을 구현하기 위해 필요한 주요 비즈니스 컨트롤은 무엇일까? 이를 확인해야 한다”라고 말했다.

안드레스는 “과거 로우코드 개발 노에는 정의된 SDLC[Software Development Lifecycle] 프로세스를 따를 필요가 없다는 인식이 존재했다. 또 비즈니스 요건 전체를 문서화하여 검토하지 않았다. 결과적으로 애플리케이션에 중요한 비즈니스 규칙이 누락되어 있다는 사실이 속속 드러났다”라고 말했다.

안드레스는 그 결과 애플리케이션 재수행으로 완료에 필요한 시간이 3배가 되어 팀이 로우코드 개발 접근방식을 도입하여 얻은 비용 절감 효과가 상쇄됐다고 전했다.

역량의 적절한 배치 실패
로우코드 도구의 이점 중 하나는 프로젝트를 완료하기 위한 숙련된 개발자의 필요성이 감소할 수 있다는 것이다. 하지만 그렇다고 해서 숙련된 전문가가 필요 없어진다는 뜻은 아니다.

법률 및 소비자 데이터 서비스를 제공하는 기업 LNLP(LexisNexis Legal & Professional)의 부사장 겸 CAO(Chief Automation Officer) 비네이 무미가티는 “로우코드 개발을 배치한 팀들은 각 로우코드 플랫폼에 매우 능숙해야 한다. 또 적절한 제품 인증 및 할 일과 하지 말아야 할 일에 대한 지식을 갖추어야 한다”라고 말했다.

무미가티는 “내 경험상, 로우코드 솔루션을 개발하기 위해 맞춤형 코딩 집중적 소프트웨어 애플리케이션을 잘 작성하는 소프트웨어 엔지니어를 배치하는 것은 실수이다. 그들은 대부분 수천 줄의 코드를 작성하여 유지보수 또는 확장이 어려운 맞춤형 애플리케이션을 개발하는 경우가 많다. 그리고 이것은 로우코드 플랫폼을 제대로 활용하는 방법이 아니다”라고 말했다.

예를 들어, 렉시스넥시스의 J2EE 엔지니어링팀은 ‘법규명령 처리’ 애플리케이션을 제공하기 위해 한 로우코드 자동화 플랫폼에 대한 교차 교육을 받았다. 무미가티는 “기성 기능을 활용하기 위해 [로우코드] 플랫폼 제공업체가 규정한 방법론과 모범 사례에 따라 애플리케이션을 구축하는 대신에 개발팀은 각종 기능을 위해 복잡한 코드를 작성했다. 그저 [해당] 플랫폼을 사용하여 워크플로를 백엔드 엔진으로서 조율했을 뿐이다”라고 말했다.

이러한 맞춤형 코딩으로 인해 본래 비용 및 시간 전망치가 3배나 증가했고, 심각한 성능 및 유지보수성 문제가 나타났다. 결국 제공업체의 전문적인 서비스팀을 이용하여 애플리케이션 전체를 재작성 하게 되었다고 무미가티는 말했다.

현업 참여의 부재
로우코드 플랫폼은 주로 비즈니스 커뮤니티의 시민 개발자가 신속한 애플리케이션 제공을 달성하도록 한다. 이를 감안할 때 초기 의사결정 프로세스에서 비즈니스 사용자를 제외하는 것은 좋은 생각이 아니라고 무미가티가 말했다.

무미가티는 “우리가 목격한 주된 실수 중 하나는 비즈니스 사용자가 프로젝트 시작 시부터 참여하지 않는 것이다. 로우코드 ‘모델 주도적 개발’ 플랫폼의 경우 비즈니스 사용자를 처음부터 참여시키는 것이 성공의 열쇠다. 처음부터 비즈니스 참여의 부재는 주요 재개발 및 예산/일정 변화로 이어질 수 있다”라고 말했다.

그에 따르면 로우코드 프로젝트에 강력한 비즈니스-IT 관계가 포함되어야 한다. 무미가티는 비즈니스 참여가 부실했던 고객 온보딩 플랫폼을 예로 들었다. 플랫폼이 제공되었을 때, 비즈니스 사용자들은 프로세스 로직, 의사결정 규칙, 보고, 사용자 인터페이스가 복잡한 운영 변화 관리를 초래한다는 이유로 인해 이를 거부했다고 그가 말했다.

무미가티는 “첫 스프린트부터 비즈니스 부문을 참여시켜야 한다. 비즈니스 사용자는 (로우코드 플랫폼의) 모든 단계에서 프로세스 모델을 설계하고 비즈니스 로직을 정의하며 UI 형태/인터페이스가 생성되며 데이터 요소가 전환한 방식을 시각화 할 수 있다. 궁극적으로 정확히 비즈니스가 상상했던 애플리케이션이 완성된다”라고 말했다.

문화 및 조직 구조 업데이트 실패
리서치회사 IFRG(Info-Tech Research Group)의 애플리케이션 활동 수석 조사 분석가 앤드류 컴슨은 “로우코드 및 노코드(No-code) 전략은 제대로 하는 경우 비즈니스 관리 애플리케이션 및 시민 개발로의 전환을 지원하는 훌륭한 도구이다”라고 말했다.

컴슨은 “그러나 많은 조직들이 이 새로운 환경의 번영을 위해 기업 문화, 소프트웨어, 위험 책임 구조의 상당한 변화와 IT 운영 모델이 필요하다는 사실을 잊고 있다. 궁극적으로 전통적인 소프트웨어 제공 활동, 고립된 비즈니스 및 IT팀, 형편없는 기업 시스템 품질은 로우코드 및 노코드 기술의 진정한 잠재력을 제한하고 구현 및 장기 유지보수 비용을 높인다”라고 말했다.

IT는 운영자 겸 솔루션 구현자에서 ‘신뢰할 수 있는 파트너, 코치, 플랫폼 지원자’로 변신해야 한다. 컴슨은 “비즈니스는 소프트웨어 구현 및 개발 결정을 담당해야 하고 그들이 추진하는 기업 환경의 변화가 무엇인지 투명하게 밝혀야 한다. 어쨌든, 로우코드 및 노코드 기술의 진정한 가치는 우리가 그 기능을 100% 활용하기 위해 업무 방식을 최적화할 의지가 있을 때 드러난다”라고 말했다.

과도하게 야심 찬 목표 설정
로우코드 플랫폼은 개발을 개선하는 중요한 도구가 될 수 있지만 완벽함과는 거리가 멀다. 무미가티는 “로우코드 플랫폼의 주된 실수는 일부 기술적인 한계를 고려하지 않는 것이다”라고 말했다. 

LNLP는 복구 및 시스템 대체 작동 기능 또는 대규모 배치 처리를 통해 대규모 트랜잭션 중심적 애플리케이션을 처리하기 위해 로우코드 플랫폼을 확장하기 위해 시도했던 바 있다.

무미가티는 “여러 시스템 또는 복잡한 데이터 구조의 통합 중심적 데이터 또는 서비스 조율이 수반된 상황에서 로우코드 플랫폼은 확장되지 않는다는 사실을 발견했다”라고 말했다. 해당 기업은 문서 및 트랜잭션 처리 애플리케이션에서 대량으로 발생하는 데이터의 배치 처리가 수반된 담보대출 처리 애플리케이션 및 돈세탁 방지 애플리케이션에 로우코드 플랫폼을 사용했다.

해당 시나리오에서 해당 기업은 로우코드 플랫폼이 필요한 속도와 품질을 제공할 수 없다는 사실을 발견했다. 애플리케이션이 프로세스 중간에 실패했다. 무미가티는 “우리는 (로우코드 플랫폼을 통해) 대량의 데이터를 배치 모드로 100% 처리할 수 있는 능력이 없었다. 고객 경험에 영향이 큰 주된 운영 및 규제 문제였다”라고 말했다.

너무 많은 도구 배치
무엇이든 과도하면 좋지 못하다. 이는 로우코드 및 노코드 도구에도 적용되며, 이것들이 제대로 작동하지 않을 때는 더욱 그렇다.

소프트웨어 기업 뉴타닉스(Nutanix)가 이 문제에 부딪혔다. 회사의 CIO 웬지 파이퍼는 이를 ‘바벨탑’에 비유했다. "같은 언어를 사용하지 않는 많은 도구를 배치하면 양호한 수준의 자동화에 도달할 수 없을 것이다”라고 그녀가 말했다.

파이퍼는 “결국 모든 팀원에게 각 도구의 사용 방법을 교육한 후에야 자율 운영 지원에 진정한 진전이 나타났다”라고 말했다.

또한 로우코드 기술은 제공업체들이 광고한듯이 구현하기가 단순하지 않을 수 있다고 컴슨이 말했다. 그는 “진정한 이점은 기업 애플리케이션, 데이터 웨어하우스, 시스템에 다양한 서비스 및 데이터를 활용하고 통합하는 능력이 있을 때 나타난다. 하지만 많은 조직들이 구형 시스템 아키텍처에 제한되어 있으며 보편적인 데이터 정의가 없고 그들의 애플리케이션은 기술 부채 부담이 있다”라고 말했다.

API 게이트웨이, 데이터 레이크, 클라우드 플랫폼, 기타 통합 및 집합 도구는 로우코드 기술과의 시스템 호환성을 개선하는 데 도움이 될 수 있다고 컴슨이 말했다. 그는 “하지만 이것들이 근본적인 아키텍처 및 데이터 관리 문제를 해결하지는 않는다”라고 말했다.

부실한 프로세스 잔존
로우코드 도구의 잠재력은 엄청나다. 파이퍼는 “약간의 교육을 통해 모든 IT팀원이 특수 워크플로의 주요 요소를 자동화하여 정확도와 효율성을 높일 수 있다. 하지만 자동화 보급이 만병통치약은 아니다. 끔찍한 프로세스는 아무리 기계가 신속하고 정확하게 실행하더라도 여전히 끔찍한 프로세스이다”라고 말했다.

형편없는 수동 프로세스를 멋진 프로세스로 바꾸는 특별한 ‘기계 마법’은 없다고 파이퍼가 말했다. 그녀는 “그 첫 단계로써 우리 팀은 후보 프로세스를 평문 언어로 작성해야 한다. 문제를 보여주고 개선된 워크플로로 이어지는 해야 할 일에 대한 설명을 확인해야 한다”라고 말했다. 문서가 이해되면 프로세스를 로우코드 도구를 통해 코드로 전환할 준비가 된 것이다.

자동화는 점진적으로 실행될 때 가장 좋다고 파이퍼가 말했다. 그녀는 “IT팀은 자동화가 영향력을 갖기 위해 문제가 되는 복잡한 프로세스를 처음부터 끝까지 자동화해야 한다고 생각한다. 나의 팀과 나는 재작업이 필요했던 단계를 자동화하는 데 노력을 집중시키는 것이 이런 도구의 이점을 경험하기 위한 진정한 핵신이라는 사실을 배웠다”라고 말했다. ciokr@idg.co.kr