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

목차

머리말

1부 – 진화하는 소프트웨어 개발 세상 속의 RAD Studio®

• Part 1-1: RAD 탄생과 시장 트렌드
• Part 1-2: RAD스튜디오가 혁신을 받아들이는 여러 방법들
• Part 1-3: 현대화에 대한 고민과 해소 방안

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

• Part 2-1: 크로스플랫폼 개발과 비즈니스
• Part 2-2: 멀티 플랫폼 개발의 모든 것 – 개발 도구 비교, 앱 개발 방법 비교 등 (현재 보고 계신 글입니다.)

3부 – RAD Studio® 현재 – 미래를 위한 투자

요약 정리

이 문서 주제 밖의 참고 사항

엠바카데로의 방향

용어

두 세상에서 최고가 되기 – 왜 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스튜디오를 고려하게 되는 이유 중 하나이다.

---

검색

12.0 12.1 AI AWS C++ c++빌더 chatgpt DelphiCon ios rad서버 RAD스튜디오 UI UIUX UX uxsummit vcl 개발 개발사례 고객사례 기술레터 기술백서 데브옵스 데이터 데이터베이스 델파이 리눅스 마이그레이션 맥 머신러닝 모바일 새버전 샘플 세미나 안드로이드 웹 윈도우 인공지능 인터베이스 출시 커뮤니티에디션 코드 클라우드 파이썬 파이어몽키 현대화