2019.04.26

개발자가 로우 코드 플랫폼을 믿지 말아야 할 때

Mark Troester | InfoWorld
애플리케이션 개발 세계는 끊임없이 변화한다. 애널리스트들이 애플리케이션 개발 툴과 플랫폼의 여러 범주와 정의를 자주 수정하는 것만 봐도 알 수 있다. 빠른 발전 속도와 그에 따른 변화를 이끄는 동력은 데스크톱과 웹, 모바일, 웨어러블 등을 아우르는 고객 등급(customer-grade)의 옴니채널 앱을 신속하게 제공하기 위한 단일 플랫폼과 툴세트에 대한 수요다.
 
ⓒGettyImagesBank

개방형 표준을 기반으로 하는 적절한 로우 코드 솔루션은 “더 많은 앱을, 더 빠르게, 모든 곳에서 실행”이 화두인 시대에 큰 가치를 제공할 수 있다. 물론 로우 코드 솔루션이라고 다 똑같지는 않다. 솔루션을 평가할 때 주의해서 살펴야 할 세 가지 경고 신호는 다음과 같다.
 

로드 코드 경보 1. 블랙 박스

로우 코드는 “내부를 볼 수 없는 블랙 박스”라는 오명을 갖고 있다. 개발자들은 자신이 통제할 수 없는 어떤 것에서 미션 크리티컬 서비스를 실행하기를 꺼린다는 점을 생각하면, 왜 그런 오명이 생겼는지 이해할 수 있다. 빠르게 변화하는 환경에서 생산성 증대를 위한 답은 극단적인 노 코드 블랙 박스가 아니라 개방형 표준을 기반으로 하고 소스가 완전히 공개된 “오픈 박스”인 로우 코드 솔루션이다. 본질적으로 로우 코드는 코드를 사용하는 사람들에게서 가치가 나오는 툴이다. 즉, 노 코드 비즈니스 사용자가 아니라 전문적인 개발자가 필요하다.

전문 개발자를 위한 로우 코드의 핵심은 한 번 써서 여러 플랫폼에 걸쳐 실행하고 이 과정에서 사용자 경험에 대한 완전한 통제력을 유지하는 것이다.
 

로우 코드 경보 2. 모놀리식 아키텍처

앱 개발은 이미 복잡하다. 여러 채널에 걸친 무제한 확장성을 달성해야 하고 컨테이너와 마이크로서비스를 사용한 클라우드 기반 개발로의 빠른 전환에도 대처해야 한다. 개발 팀은 이러한 기대치를 충족하는 동시에 사용자 경험에 대한 초점도 계속 유지해야 한다.

개발자들은 로우 코드 솔루션 아키텍처에 회의적이다. 애플리케이션 개발에 적합하지 않은 구시대의 모놀리식 기술이라고 생각한다. 이렇게 생각하는 이유는 다음과 같다.

- 모놀로식 로우 코드 아키텍처는 처음에는 개발하고 배포하기 쉽지만 장기적으로 보면 “밀착 결합”되는 경향이 있고, 이로 인해 확장과 유지가 어려워진다. 어느 한 프로그램 구성 요소를 업데이트해야 하는 경우 보통 애플리케이션의 많은 부분을 다시 작성해야 한다.

- 모놀리식 로우 코드 아키텍처는 솔루션에 내장되어 잘 보이지 않는 종속성을 가진 경우가 많으므로 이해하기가 어려울 수 있다. 구성 요소를 개별적으로 개발, 테스트, 배포, 확장하는 기능이 없는 로우 코드 솔루션이 많고, 이 경우 커다란 단일체로 개발과 테스트, 프로덕션 작업을 관리해야 하는 부담이 생긴다.
 

로우 코드 경보 3. 전용 툴세트

로우 코드 솔루션에 포함된 전용 툴을 보유할 때의 이점은 툴과 플랫폼의 정렬이다. 두 가지의 출처가 한 곳이기 때문이다. 정렬은 이론적으로는 개발자, 궁극적으로는 비즈니스에 이익이 된다. 그러나 전용 툴의 현실적인 문제도 있다. 가파른 학습 곡선과 업체 종속성 문제, 미비하거나 아예 없는 코드 샘플 생태계와 자습서, 해당 업체 전용 커뮤니티 등이 대표적인 예다. 플랫폼 업체가 표준 언어 사용을 장려하면서 여전히 독자 개발 프로세스 내에 사용자를 가두어 두는 경우도 있다.

틈새 스킬을 배우고 통합하기 위해 필요한 비용과 시간이라는 문제 외에 숙련된 개발자는 업체 전용 툴로의 전환에 저항할 가능성이 높다는 문제도 있다. 회사가 전용 툴로 전환하면 소속 개발자들은 주류 개발 커뮤니티에서 멀어지는데, 이는 경력 관리에 결코 도움이 되지 않기 때문이다. 또한 전용 코드는 예제를 찾고 문제에 대처하는 데 참고할 자원이 적고 그만큼 디버그하기도 어렵다.
 

로우 코드의 성공 공식

전용 프로세스, 전용 플랫폼, 전용 코드에 따르는 경직성과 위험을 보면 전문 개발자들이 전용 툴을 도입하거나 추천하기를 꺼리는 이유를 명확히 알 수 있다. 이상적인 솔루션은 로우 코드 개발의 용이함을 AWS나 애저, 구글 클라우드 플랫폼 등이 제공하는 클라우드 기능을 활용하는 옵션까지 포함해서 개발자들이 선호하는 표준 툴과 플랫폼으로 가져오는 것이다.

서버리스 클라우드 기반 플랫폼에서 개발하면 플랫폼에서 마이크로서비스와 함수를 관리하고 자동으로 확장할 수 있다. 이를 Node.js 백엔드, 그리고 웹과 모바일을 위한 자바스크립트 기반 프론트엔드와 결합하면 풀 스택 옵션을 갖출 수 있다. 이 경우 다음을 포함한 여러 이점을 얻게 된다.

- 자바스크립트를 기반으로 구축된 서버리스와 로우 코드 플랫폼을 결합하면 기존 개발자 스킬을 사용해서 소비자 등급의 옴니채널 경험에 대한 요구를 충족할 수 있다.
- 여러 개발자, 나아가 여러 팀이 각각 독립적으로, 다른 팀이 수행한 변경 사항과 충돌하는 경우 없이 자신의 담당하는 애플리케이션 부분에서 작업할 수 있다.
- 앱 코드를 다시 쓰거나 다시 배포하지 않고 업데이트를 할 수 있다.
- 코드를 여러 앱에 재사용할 수 있으며, 기능이 격리되므로 유지 관리하기도 더 쉽다.

전체적인 결과는 개발자가 앱 기능과 사용자 경험에 집중할 수 있는 자유를 얻고, 나머지는 플랫폼이 관리한다는 것이다. 관건은 풍부한 툴과 라이브러리, 학습 자료 생태계를 갖춘, 광범위하게 사용되며 표준화된 언어(예를 들어 자바스크립트)를 기반으로 하는 로우 코드 플랫폼을 구하는 것이다. 자바스크립트는 애플리케이션의 프론트엔드와 백엔드, 양쪽에서 공통 언어를 사용하는 기능을 통해 프론트엔드 개발자가 백 엔드에 자신의 지식과 기술을 전수할 수 있는 부가적인 혜택도 제공한다.

유연한 개방형 툴과 플랫폼, 언어(자바스크립트)는 개발자와 개발자를 채용하는 회사에 모두 이익이 된다. 로우 코드 솔루션을 구매하기 위해 알아볼 때는 이 사실을 항상 염두에 두어야 한다.  editor@itworld.co.kr


2019.04.26

개발자가 로우 코드 플랫폼을 믿지 말아야 할 때

Mark Troester | InfoWorld
애플리케이션 개발 세계는 끊임없이 변화한다. 애널리스트들이 애플리케이션 개발 툴과 플랫폼의 여러 범주와 정의를 자주 수정하는 것만 봐도 알 수 있다. 빠른 발전 속도와 그에 따른 변화를 이끄는 동력은 데스크톱과 웹, 모바일, 웨어러블 등을 아우르는 고객 등급(customer-grade)의 옴니채널 앱을 신속하게 제공하기 위한 단일 플랫폼과 툴세트에 대한 수요다.
 
ⓒGettyImagesBank

개방형 표준을 기반으로 하는 적절한 로우 코드 솔루션은 “더 많은 앱을, 더 빠르게, 모든 곳에서 실행”이 화두인 시대에 큰 가치를 제공할 수 있다. 물론 로우 코드 솔루션이라고 다 똑같지는 않다. 솔루션을 평가할 때 주의해서 살펴야 할 세 가지 경고 신호는 다음과 같다.
 

로드 코드 경보 1. 블랙 박스

로우 코드는 “내부를 볼 수 없는 블랙 박스”라는 오명을 갖고 있다. 개발자들은 자신이 통제할 수 없는 어떤 것에서 미션 크리티컬 서비스를 실행하기를 꺼린다는 점을 생각하면, 왜 그런 오명이 생겼는지 이해할 수 있다. 빠르게 변화하는 환경에서 생산성 증대를 위한 답은 극단적인 노 코드 블랙 박스가 아니라 개방형 표준을 기반으로 하고 소스가 완전히 공개된 “오픈 박스”인 로우 코드 솔루션이다. 본질적으로 로우 코드는 코드를 사용하는 사람들에게서 가치가 나오는 툴이다. 즉, 노 코드 비즈니스 사용자가 아니라 전문적인 개발자가 필요하다.

전문 개발자를 위한 로우 코드의 핵심은 한 번 써서 여러 플랫폼에 걸쳐 실행하고 이 과정에서 사용자 경험에 대한 완전한 통제력을 유지하는 것이다.
 

로우 코드 경보 2. 모놀리식 아키텍처

앱 개발은 이미 복잡하다. 여러 채널에 걸친 무제한 확장성을 달성해야 하고 컨테이너와 마이크로서비스를 사용한 클라우드 기반 개발로의 빠른 전환에도 대처해야 한다. 개발 팀은 이러한 기대치를 충족하는 동시에 사용자 경험에 대한 초점도 계속 유지해야 한다.

개발자들은 로우 코드 솔루션 아키텍처에 회의적이다. 애플리케이션 개발에 적합하지 않은 구시대의 모놀리식 기술이라고 생각한다. 이렇게 생각하는 이유는 다음과 같다.

- 모놀로식 로우 코드 아키텍처는 처음에는 개발하고 배포하기 쉽지만 장기적으로 보면 “밀착 결합”되는 경향이 있고, 이로 인해 확장과 유지가 어려워진다. 어느 한 프로그램 구성 요소를 업데이트해야 하는 경우 보통 애플리케이션의 많은 부분을 다시 작성해야 한다.

- 모놀리식 로우 코드 아키텍처는 솔루션에 내장되어 잘 보이지 않는 종속성을 가진 경우가 많으므로 이해하기가 어려울 수 있다. 구성 요소를 개별적으로 개발, 테스트, 배포, 확장하는 기능이 없는 로우 코드 솔루션이 많고, 이 경우 커다란 단일체로 개발과 테스트, 프로덕션 작업을 관리해야 하는 부담이 생긴다.
 

로우 코드 경보 3. 전용 툴세트

로우 코드 솔루션에 포함된 전용 툴을 보유할 때의 이점은 툴과 플랫폼의 정렬이다. 두 가지의 출처가 한 곳이기 때문이다. 정렬은 이론적으로는 개발자, 궁극적으로는 비즈니스에 이익이 된다. 그러나 전용 툴의 현실적인 문제도 있다. 가파른 학습 곡선과 업체 종속성 문제, 미비하거나 아예 없는 코드 샘플 생태계와 자습서, 해당 업체 전용 커뮤니티 등이 대표적인 예다. 플랫폼 업체가 표준 언어 사용을 장려하면서 여전히 독자 개발 프로세스 내에 사용자를 가두어 두는 경우도 있다.

틈새 스킬을 배우고 통합하기 위해 필요한 비용과 시간이라는 문제 외에 숙련된 개발자는 업체 전용 툴로의 전환에 저항할 가능성이 높다는 문제도 있다. 회사가 전용 툴로 전환하면 소속 개발자들은 주류 개발 커뮤니티에서 멀어지는데, 이는 경력 관리에 결코 도움이 되지 않기 때문이다. 또한 전용 코드는 예제를 찾고 문제에 대처하는 데 참고할 자원이 적고 그만큼 디버그하기도 어렵다.
 

로우 코드의 성공 공식

전용 프로세스, 전용 플랫폼, 전용 코드에 따르는 경직성과 위험을 보면 전문 개발자들이 전용 툴을 도입하거나 추천하기를 꺼리는 이유를 명확히 알 수 있다. 이상적인 솔루션은 로우 코드 개발의 용이함을 AWS나 애저, 구글 클라우드 플랫폼 등이 제공하는 클라우드 기능을 활용하는 옵션까지 포함해서 개발자들이 선호하는 표준 툴과 플랫폼으로 가져오는 것이다.

서버리스 클라우드 기반 플랫폼에서 개발하면 플랫폼에서 마이크로서비스와 함수를 관리하고 자동으로 확장할 수 있다. 이를 Node.js 백엔드, 그리고 웹과 모바일을 위한 자바스크립트 기반 프론트엔드와 결합하면 풀 스택 옵션을 갖출 수 있다. 이 경우 다음을 포함한 여러 이점을 얻게 된다.

- 자바스크립트를 기반으로 구축된 서버리스와 로우 코드 플랫폼을 결합하면 기존 개발자 스킬을 사용해서 소비자 등급의 옴니채널 경험에 대한 요구를 충족할 수 있다.
- 여러 개발자, 나아가 여러 팀이 각각 독립적으로, 다른 팀이 수행한 변경 사항과 충돌하는 경우 없이 자신의 담당하는 애플리케이션 부분에서 작업할 수 있다.
- 앱 코드를 다시 쓰거나 다시 배포하지 않고 업데이트를 할 수 있다.
- 코드를 여러 앱에 재사용할 수 있으며, 기능이 격리되므로 유지 관리하기도 더 쉽다.

전체적인 결과는 개발자가 앱 기능과 사용자 경험에 집중할 수 있는 자유를 얻고, 나머지는 플랫폼이 관리한다는 것이다. 관건은 풍부한 툴과 라이브러리, 학습 자료 생태계를 갖춘, 광범위하게 사용되며 표준화된 언어(예를 들어 자바스크립트)를 기반으로 하는 로우 코드 플랫폼을 구하는 것이다. 자바스크립트는 애플리케이션의 프론트엔드와 백엔드, 양쪽에서 공통 언어를 사용하는 기능을 통해 프론트엔드 개발자가 백 엔드에 자신의 지식과 기술을 전수할 수 있는 부가적인 혜택도 제공한다.

유연한 개방형 툴과 플랫폼, 언어(자바스크립트)는 개발자와 개발자를 채용하는 회사에 모두 이익이 된다. 로우 코드 솔루션을 구매하기 위해 알아볼 때는 이 사실을 항상 염두에 두어야 한다.  editor@itworld.co.kr


X