개발자

“로우코드가 위험하다는 주장은 위선” 로우코드/노코드와 보안 취약점의 상관관계

Lee Atchison | InfoWorld 2022.03.16
필자는 ‘로우코드와 노코드 개발에서 신경 써야 할 4가지 보안 문제’라는 기사를 흥미롭게 읽었다. 여기서는 기본적으로 기업이 로우코드 솔루션을 경계해야 한다는 것을 전제로 한다. 로우코드로 인해 보안 문제가 발생할 수 있기 때문이다.

담당 기자인 크리스 휴스는 “애플리케이션 개발에 참여하는 직원이 많아지면서 로우코드 개발로 인한 새로운 취약점이 발생하거나 보안 문제가 드러나지 않을 수 있다”라고 말했다.

하지만 필자는 휴스의 주장에 전혀 동의하지 않는다. 구체적으로 말하면, 본래 로우코드/노코드 솔루션에는 안전하거나 위험한 것이 존재하지 않는다. 로우코드/노코드 솔루션의 안전성은 모든 애플리케이션 개발 플랫폼과 시스템, 프로세스, 정책에 대해 수동이나 자동 여부에 관계없이 기업이 투자한 것에 비례한다.

애플리케이션 개발자 수를 줄이면 보안 취약점이 생길 확률이 낮아지는 것은 맞다. 하지만 이런 논리라면 애플리케이션을 안전하게 만드는 최고의 방법은 엔지니어링 팀의 규모를 축소해 개발할 애플리케이션 수를 줄이는 것과 다름없다. 애플리케이션 수가 적을수록 애플리케이션 보안 문제도 감소한다는 명제는 참이지만 사실 말장난에 불과하다.

이런 주장은 애플리케이션 개발에 대한 협소한 시각을 반영한다. 유능한 CSO는 기업을 억압하지 않으며, 기업의 성장을 독려한다. 기업이 커지고 빠르게 성장할수록 보안 문제에 대처하는 것은 더욱 어렵다. 기업이 개발할 수 있는 애플리케이션을 제한하는 데 치중하며 보안 문제를 개선하는 것은 CSO가 기업의 성공에 기여하는 좋은 방법이 아니다. 최고의 CSO는 성장의 기회 속에 내재된 보안 문제를 해소할 방법을 찾아낸다.

로우코드라고 해서 다를 게 없다. 기업은 ‘시민 개발자’가 유용한 애플리케이션을 개발하도록 지원함으로써 성장할 수 있다. 보안 취약점을 막는 가장 좋은 방법은 CSO와 IT 담당자가 시민 개발자의 고품질이고 신뢰할 수 있으며, 안전한 로우코드 개발 플랫폼 개발을 지원하는 데 중점을 두는 것이다.

이를 위해서는 로우코드 개발 플랫폼 사용에 반발하는 것이 아닌, 기업용 로우코드 개발 툴을 도입하고 사용자가 직접 작동 방식을 배우도록 하며, 사용을 장려해야 한다. 또한, 로우코드 개발 툴이 제공하는 환경의 안전성을 보장할 필요가 있다.

이런 전략은 로우코드 개발이 자칫 섀도우 IT로 전락하는 것을 막고, 로우코드 사용 활성화를 통한 기업의 성장을 돕는다. 다만, CSO와 보안팀, 다른 기업 IT팀의 감독 하에 로우코드 전략을 시행해야 한다. 기업의 성장은 시민 개발자의 인적 가치를 활용해 개발 조직의 다른 가치를 강화한다.
 

또 하나의 다른 툴일 뿐인 로우코드

컴퓨팅 초창기로 돌아가면, 개발자는 어셈블리어나 기계어로 프로그램을 개발했다. 이런 원시적 언어로 프로그램을 짜는 것은 쉽지 않았으며, 지극히 단순한 작업조차 경험이 많은 개발자가 필요했다. 오늘날 많은 소프트웨어가 자바(Java)와 루비(Ruby), 자바스크립트(JavaScript), 파이썬(Python), C++와 같은 고급 프로그래밍 언어로 개발된다. 이들 고급 언어는 사용자가 복잡한 코드를 더 쉽게 작성하고 기계어 프로그램의 복잡성에 신경 쓸 필요 없이 더욱 큰 문제를 해결하는 데 집중하도록 하기 때문이다.

<그림 1>에서 볼 수 있듯이, 고급 프로그래밍 언어의 출현으로 기계어 및 어셈블리어 프로그래밍이 강화됐으며, 적은 코드로 더욱 많은 것을 달성할 수 있게 됐다. 따라서 더욱 크고 좋은 애플리케이션을 빠르게 완성하는 데 있어 효율성이 크게 개선됐다. 소프트웨어 개발은 여전히 전문 기술 및 기법을 요구하는 고도로 특화된 작업이었다. 하지만 더 많은 사용자가 고급 언어를 배울 수 있게 되면서 소프트웨어 개발자 계층이 늘었다. 생산적 소프트웨어 개발자 시대가 열린 것이다.
 
<그림 1> 초기 개발 툴 ⓒ IDG

결국 개발자는 더욱 크고 복잡한 애플리케이션을 개발하기 시작했다. 개발 역량을 높이기 위해 프로그래밍 플랫폼과 프레임워크, 툴셋을 제작하기 시작했다. 개발자는 ASP.NET, 루비 온 레일스(Ruby on Rails), 제이쿼리(jQuery), 스프링(Spring), 리액트제이에스(React.js)와 같은 프레임워크를 통해 고급 애플리케이션을 더욱 쉽게 제작할 수 있었다. 이후 SaaS 및 클라우드 서비스가 출현하면서 개발자의 역량은 더욱 강화됐다.

이들 모든 고급 툴과 서비스가 등장하면서 <그림 2>처럼 사용자가 더욱 나은 개발 경험을 하고 적은 코드로 더 많은 것을 개발하는 추세를 가속화했다. 또한, 복잡한 애플리케이션을 빠르게 완성하는 능력이 크게 향상됐다. 고급 애플리케이션 개발이 더욱 쉬워졌을 뿐만 아니라 유능한 개발자가 되는 데 필요한 교육량도 줄었다. 교육이 줄어든다는 것은 개발자가 더 많아진다는 것을 의미한다. SaaS 및 클라우드 기반 애플리케이션 시대가 시작됐다.
 
<그림 2> 확장된 개발 툴 ⓒ IDG

시간이 흐르면서 많은 개발자가 더욱 크고 복잡한 애플리케이션을 개발하기 시작했다. 인공지능 및 머신러닝 기능이 주목을 끌고 있으며, 로우코드/노코드 툴은 더욱 복잡한 애플리케이션을 제작할 수 있는 능력을 향상시킨다. 이들 툴은 <그림 3>에서 볼 수 있듯이, 다른 개발 툴의 역량을 강화하고 더 적은 코드로 더 많은 것을 개발하는 추세를 이어간다. 또한, 경험이 적은 개발자에게 개발의 기회를 더 많이 제공한다. 이제 직접적이고 집중적인 개발자 교육을 받는 직원은 고급 작업을 수행하는 애플리케이션을 제작할 수 있다. 시민 개발자의 시대가 도래한 것이다.
 
<그림 3> 현대 개발 툴 ⓒ IDG

시민 개발자는 전혀 새롭거나 참신하지 않다. 기존 소프트웨어 개발자 역할에서 진화한 것에 불과하다. 시민 개발자가 소프트웨어를 개발하는 과정에서 로우코드/노코드의 위험성과 안전성, 유용성을 좌우하는 그 어떤 것도 없다.

로우코드/노코드 툴이 이전 툴보다 근본적으로 안전하지 않거나 유용성이 떨어진다는 말은 위선적이다. 로우코드/노코드 툴은 모든 기업이 필요로 하고 향후 의존하게 될, 진화하고 있는 툴셋이다.
 

거센 반발에도 굳건한 로우코드

로우코드가 다른 개발 환경 개선과 다를 게 없음에도 로우코드를 반대하는 과대 선전이 많은 것은 이례적이거나 예상치 못한 상황은 아니다. 새 툴셋이 으레 겪는 반발이다. 기업 IT 인프라를 클라우드로 이전하거나 중요한 기업 애플리케이션에 리액트(React)를 사용하는 것을 고려하지 못한 시절은 그리 오래되지 않았다. 또한, 자바가 기업 IT 개발에 있어 유일하게 안전한 언어로 인정되던 때도 있었다.

로우코드가 섀도우 IT를 조장한다는 우려에 관해서는, 클라우드 컴퓨팅이 섀도우 IT로 여겨졌던, 혹은 루비 온 레일즈(Ruby on Rails)나 리액트가 비공식 애플리케이션에만 사용되던 시절은 오래 전이 아니다.

로우코드/노코드 및 AI 지원 개발 툴은 정착할 것이고, 중요성 역시 계속 커질 것이다. 기업 IT팀과 보안팀은 이들 툴의 성장에 앞장서지 않고 반발하거나 사라지기를 원하는 경우, 시대에 뒤쳐질 것이다.

로우코드는 적절히 다루기만 하면 다른 플랫폼과 시스템, 개발 환경에 비해 어떤 추가적인 보안 위험도 없다. 게다가 운영 위험이나 관리되지 않은 비용이 더 많지도 않다. 결국 핵심은 로우코드를 적절히 다루는 것이다. 로우코드가 섀도우 IT로 이어지거나 모니터링되지 않고 방치되면 여느 섀도우 IT 프로젝트 및 방치된 다른 프로세스처럼 위험에 노출될 가능성이 있다.

로우코드 개발 툴과 플랫폼은 신뢰할 수 있는 수준으로 발전했다. 인지도 있는 업체가 공급하는 고품질의 기업용 로우코드 시스템은 특히 그렇다. 
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.