[RAD스튜디오, 관리자들을 위한 안내서] Part 2-2: 멀티 플랫폼 개발의 모든 것 – 개발 도구 비교, 앱 개발 방법 비교 등

2021-04-27
Posted by: Narae Kim
Categories: 기술자료, 메인 노출

댓글 없음

한글 전체 문서 PDF 다운로드: [한글] RAD스튜디오 관리자를 위한 안내서_April_2021 PDF 파일 다운로드하기

영문 전체 문서 PDF 다운로드: [영문] RAD스튜디오 관리자를 위한 안내서_April_2021 PDF 파일 다운로드하기

두 세상에서 최고가 되기 – 왜 RAD스튜디오인가

멀티 플랫폼 실현

웹 기술을 이용하면

새로운 장비와 새로운 플랫폼을 빠르게 수용할 수 있다.
하지만 이 방법은 웹 브라우저와 그 기능 수준 내에서만 구현할 수 있다는 제약이 있다.
- 결국 BPR에서 요구하는 능력을 확보하지 못하는 경우가 발생한다.
- 웹 페이지를 제공하는 방식은 속도 또한 느려서 UX 수준이 낮다는 문제를 초래할 수도 있다.

실제로는 디바이스에 설치된 애플리케이션이 필요하다.

최상의 신뢰성, 속도, UX를 제공하고
(특히 보안 권한이 요구되는 곳에서) 장비의 기능에 액세스할 수 있어야 한다.

디바이스에 설치된 모바일 애플리케이션을 만드는 방법은 두 가지이다.

완전히 컴파일된 네이티브 방식
하이브리드 앱 방식
- 장비 상에서 웹앱을 실행한다.
- 브라우저를 제공하는 셸(Shell) 안에서 작동된다.
  - 장비의 기능에 액세스할 수 있다.

순수 네이티브 대 하이브리드 애플리케이션

순수 네이티브 코드는

전통적으로 플랫폼 제조사에서 제공하는 도구를 사용한다.
Xcode, 비주얼스튜디오, 안드로이드 스튜디오 등

순수 네이티브 개발의 장점은

네이티브한 UX, 네이티브한 속도와 성능
코드가 완전히 바이너리로 컴파일 됨에 따른 수준높은 보안

제조사 도구를 사용하여 네이티브의 장점을 취하면

각 플랫폼별로 개발팀을 각각 보유해야 하고
코드 개발과 관리도 각각 따로 할 수 있어야 한다.
즉, 개발 비용이 더 커진다.

많은 개발자들이 하이브리드 앱을 추구한다.

그 이유는
- 네이티브 장점을 취하기 위한 시간, 비용, 운영 부담이 커지는 것을 감당하기 힘들기 때문이다.
- 스크립트 방식 즉 하이브리드 방식은 단일 팀에서 애플리케이션 하나를 개발하면 되기 때문에 비용이 낮아진다.
- 앱 하나로 여러 플랫폼에 동시에 커버할 수 있다.
하지만, 보안, 성능, UX 등 네이티브의 장점을 희생해야 한다.

스크립트 방식 즉 하이브리드 앱이 성능이 낮고 보안이 취약하다.

그 이유는
- 스크립트 방식의 언어는 코드가 해석되면서 바로 실행되기 때문이다.
실행 중에 코드를 해석하는 방식은
- 성능 상 병목이 되기도 하고
- 해커가 장난칠 수 있는 잠재적인 보안 취약점이 되기도 한다.
- 게다가 웹 애플리케이션은 네이티브 애플리케이션보다 훨씬 많은 메모리를 사용한다.

닷넷이나 자바스크립트 런타임 웹키트 즉 JavaRuntime 등의 런타임을 사용한다면

그 런타임 자체가 추가적인 보안 위협을 노출한다.
이들 런타임 역시 상당한 메모리 사용이 필요한다.
메모리 관리를 위해 가비지 컬렉터가 들어있기도 하다.

타협 하지 않기 – 크로스 플랫폼과 순수 네이티브 모두에서 최고를 추구하기

RAD스튜디오 만의 방식은

크로스 플랫폼 개발 시 타협할 필요가 없다.
- 개발팀 하나로 모든 플랫폼을 목표로 한번에 개발한다.
- 완전하게 컴파일되는 순수 네이티브 애플리케이션을 개발한다.
  - 자연스러운 UX, 매우 빠른 성능, 회고 수준의 보안을 제공한다.

RAD스튜디오에서 LLVM을 사용하여 컴파일하면

각 플랫폼에 최적화된 애플리케이션이 생성된다.
RAD스튜디오는 Xcode에서 사용하는 것과 같은 컴파일러를 사용하여 iOS와 맥OS용 앱을 만든다.

자바보다 더 낮은 수준으로 컴파일 한다.
따라서 안드로이드 용 게임을 만드는 개발자와 같이 CPU와 GPU를 바로 접근한다.
메모리 컬렉터를 이용하여 메모리를 부풀릴 필요가 없다.

RAD스튜디오의 멀티 플랫폼 개발은

FMX 프레임워크를 사용한다.
- 2011년 9월
  - 델파이 XE2에서 처음 발표되었다.
- 이후 지속 발전하여
  - 단일 코드 기반이면서 순수 네이티브 UX의 성능과 보안을 제공한다.
- 콘트롤에 있는 Platform Default 속성을 사용하면 해당 플랫폼의 고유한 룩앤필이 반영된다.
  - 물론 개발자는 필요한 곳을 얼마든지 커스터마이징 할 수도 있다.
FireUI 기능이 제공된다.
- 개발자가 UI 디자인과 작동을 (어떤 장비에서도) 즉시 볼 수 있다.
  - 개발 중에 결과를 즉시 볼 수 있으면 개발 시간을 훨씬 줄어든다.
컴파일러의 공통 아키텍처가 사용된다.
- 언어 지원과 프레임워크 지원을 모든 플랫폼에 대해서 할 수 있다.
- RAD스튜디오의 FMX코드 역시 윈도우, 맥OS, 리눅스, 안드로이드, iOS에서 실행된다.
- 그 결과, 개발 생산성 수준이 더욱 높다.
RAD스튜디오는 IDE 안에서 바로 앱스토어 용 앱을 공증하고 배포할 수 있다.
- 빌드 절차가 단순화된다.

FMX가 자마린 폼즈 (Xamarin Forms)와 다른 점

Xamarin Forms는

2014년 5월에 발표되었다.
XAML을 사용하여 FMX와 유사한 시도를 했다.
- Xamarin개발자들은 콘트롤의 하위 집합을 이용하여 크로스 플랫폼 개발을 할 수 있다
하지만, Xamarin은 2가지 영역에서 RAD스튜디오보다 떨어진다.
- 언어의 능력이 제한된다.
- 닷넷 기반이므로 메모리 관리에 제한을 받는다.
  - 가비지 컬렉터가 iOS에 추가되기 때문이다.
  - 안드로이드에서는 닷넷과 자바의 가비지 컬렉터가 모두 동작하게 된다.

엔터프라이즈 데이터와 원격 데이터 연결

RAD스튜디오로는 강력한 데스크톱과 모바일 앱을 개발할 수 있다.

원격 장비에 데이터를 제공하기 등 강력한 앱에 필요한 모든 요소를 갖추고 있다.

데이터를 원격에서 연결할 수 있도록 하는 여러 방식들이 지난 몇년간 RAD스튜디오에 도입되었다.

현재 파이어닥 컴포넌트는
- SQL과 NoSQL 데이터베이스 15종 이상을 로컬과 원격 연결을 지원한다.
- 그 외의 데이터베이스는 ODBC를 통해서 연결할 수 있다.
180종 이상의 엔터프라이즈 시스템과 빅데이터 시스템을 표준 SQL을 통해 직접 연결할 수도 있다.
- Jira, Salesforce, Microsoft Teams, Google Drive, eBay, Facebook, Slack, Twitter, Amazon Marketplace 등등에 연결
- 이 기술은 파트너를 통해 제공된다.
- 하지만, 180 중 많은 대상이 이미 엔터프라이즈 에디션에 포함되어 있다.

RAD스튜디오를 이용하여 이상적인 미들 티어를 만들 수 있다.

여러 데이터베이스와 많은 엔터프라이즈 데이터 소스에 빠르게 연결할 수 있는 능력이 있기 때문이다.
여러 시스템을 연결하고 서비스를 생성하고, 데이터 제공을 빠르게 구현할 수 있다.
간단한 미들 티어는 컴포넌트를 사용하여 코드를 작성하지 않고도 만들 수 있다.
외부로 웹서비스를 노출할 수 있으며, 데이터스냅 (마이다스를 기반으로 세션의 기초 연결을 실현한다)을 활용한다.
RAD서버가 제공된다.
- 완전히 RESTful로 구성된 MEAP
- Docker 구성 제공
- 사용성 분석, 리포트 등이 내장

코드가 적은 로우 코드 (Low-Code) 애플리케이션 플랫폼과 RAD

로우 코드 애플리케이션 플랫폼 (LCAP)

가트너(Gartner)의 정의
- 애플리케이션 개발, 실행, 관리를 빠르게 할 수 있도록, 선언방식이고, 프로그래밍 추상화 수준이 매우 높은 개발 플랫폼이다.
- 모델 중심 또는 메타데이타 기반의 프로그래밍 언어, 한단계 개발 등이 사용된다.
- LCAP은 UI, 비즈니스 프로세스, 데이타 서비스를 제공하고 지원한다.

LCAP에 대한 관심이 커지는 주된 이유는

비즈니스 자동화에 대한 요구 때문이다.
비즈니스 프로세스 검토에 촛점을 맞추고 변경된 비스니스를 지원할 수 있는 앱을 만들어야 하기 때문이다.
크로스-플랫폼을 지원하고 개발을 신속하게 하기 위해서다.
- LCAP가 만들어내는 소프트웨어는 대부분 웹 기술을 기반으로하는 하이브리드 앱이다.

로우 코드가 시장에서 팔릴 때는

종종 “시민 개발자”가 가능하다는 약속을 기반으로 한다.
- 즉 누구나 조그만 훈련하면 앱을 만들 수 있다는 약속이다.
이론 상 좋기는 하지만, 현실에서는
- 맞춤식 개발을 할 수 있는 범위가 제한된다.
- 학습곡선도 매우 높다.
- 써드 파티와 연동하거나 관리하려면 제조사에 크게 의존해야한다.
- 몇몇 시스템은 웹 기반 고급 RAD 도구를 제공하기도 한다.
  - 더욱 숙련된 개발자들이 일단 해당 LCAP의 프레임워크와 모델을 익히고 나면 단순 작업 이상을 할 수 있다.

로우 코드를 적용할 때 주의 해야할 점은

시민 개발자 방식은 비즈니스 소프트웨어가 조각조각 나누어지는 결과를 초래하기 쉽다.
- 명확한 애플리케이션 전략을 가지고 있어야 한다.
- 명확한 전략이 없으면,
  - 장기적으로 변경과 관리가 어려운 기술 채무가 생기게 된다.

많은 로우 코드 플랫폼의 가격 정책은

대체로 앱을 사용하는 사용자당 구독비용을 내는 방식을 사용한다.
이 경우, 총비용이 오히려 상당히 커질 수 있다.
게다가 가트너의 주의 사항에 따르면,
- 실제로 많은 로우 코드 제조사들은 전문 서비스를 통해 상당한 매출을 올린다.
  - 즉 해당 도구를 지원하기 위해서 시민 개발자가 아니라 자사의 프레임워크를 잘 아는 전문 개발자들을 제안한다.
- 대부분의 경우 LCAP 총소유비용은 최초 예상보다 현격하게 더 높다.

RAD스튜디오는 지난 수십년 동안

BPR에서 요구하는 바를 지원해왔다.
로우 코드 개발을 추구해왔다.
애플리케이션의 프로토타입을 신속하게 만들 수 있다.
필요한 것이면 무엇이든 붙일 수 있는 오픈 에코시스템이 형성되어 있다,

LCAP를 찾고 있다면 이 질문을 하고 싶다.

특정 LCAP 제공자에게만 속한 틈새 기술을 선택하는 것과 기존의 팀이 델파이를 쓸 수 있도록 하는 것 중 어느 것이 더 좋은 투자일끼?
후자는 주요 플랫폼을 커버하는 네이티브 애플리케이션을 더 빠르게, 그리고 더 확실한 결과를 제공할 수 있다.
이점이 RAD스튜디오를 고려하게 되는 이유 중 하나이다.

한글 전체 문서 PDF 다운로드: [한글] RAD스튜디오 관리자를 위한 안내서_April_2021 PDF 파일 다운로드하기

영문 전체 문서 PDF 다운로드: [영문] RAD스튜디오 관리자를 위한 안내서_April_2021 PDF 파일 다운로드하기

Post Views: 114

[RAD스튜디오, 관리자들을 위한 안내서] Part 2-2: 멀티 플랫폼 개발의 모든 것 – 개발 도구 비교, 앱 개발 방법 비교 등

목차

두 세상에서 최고가 되기 – 왜 RAD스튜디오인가

NEWS

월별 소식

검색