[RAD스튜디오, 관리자들을 위한 안내서] Part 1-1. RAD 탄생과 시장 트렌드

목차

머리말

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

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

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

요약 정리

이 문서 주제 밖의 참고 사항

엠바카데로의 방향

용어

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

RAD와 ASD에서부터 Agile까지

RAD의 탄생

  • 델파이(1995)와 비주얼스튜디오(1997년) 등 세상을 뒤흔든 개발 도구들이 출현한 이후 RAD는 지속적으로 진화

ASD 도입과 RAD의 인기

  • RAD 초기 설파자들은 ASD를 채택
    • 제품 생명 주기를 더 짧게함을 통해 얻는 장점 추구함
  • 당시 ASD는
    • 프로토타입을 제공하여 사용자의 피드백을 초기에 받는 방식
    • 그결과 전체 배포의 위험은 낮추고, 초기 버전부터 사용자에게 가치를 제공하게 됨

RAD도구와 ASD방식은

  • 당시 BPR 가속화에 기여함
  • 이 시기는 마이크로소프트사의 윈도우가 PC 시장을 지배하던 때와 일치함

지금까지 25년간 RAD 기반 개발 프로세스는 계속 진화함

  • 소프트웨어 설계, 테스트, 코드 관리 등과 같은 여러 보조 자산들이 출현함
  • 이것들이 모이고 커져서 오늘날의 ‘애자일 개발’에 까지 이르렀다.

소프트웨어 개발에 영향을 주는 시장 트렌드

최근 15년간, 개발 프로세스와, 소프트웨어 모두 큰 변화를 겪었다. 중요한 요소 몇가지

모바일

  • 모바일 플랫폼과 모바일 하드웨어는 우리가 정보에 접근하고 처리하고 협업하는 방식을 바꿨다.
  • 인터넷에 연결된 장비 기준으로 모바일은 데스크톱을 앞질렀다.

앱스토어

  • 앱스토어는 모바일 애플리케이션 배포 시장을 장악했다

64비트

  • 32비트는 64비트에게 밀려났다.
  • 애플 앱스토어와 구글 플레이는 이제 64비트 앱만 신규 배포를 허용한다.

BYOD 정책

  • BYOD가 트렌드가 되면서, 누가 장비를 소유하고, 데이터를 어떤 장비에서 어떻게 접근하는 지가 변화했다.
  • BYOD로 인해, 개발자는 여러 운영체제와 여러 장비(와 장비마다 다른 기능)들이 섞여있는 환경을 폭넓게 다루어야 한다.
  • BYOD는 배포와 보안 측면에서 새로운 숙제를 던졌다.

PaaS

  • PaaS로 인해 하드웨어 소유와 장애 극복 이슈에 대해 새롭게 다시 생각하게 되었다.
  • PaaS는 SaaS가 더 안정적으로 제공될 수 있는 기반이 되었고, 정기 관리 비용을 낮추었다.

상호연결성

  • 요즘 사용자들은 시스템끼리 고도로 연결되어 상호작용하기를 기대한다.
  • ‘공개 기반 혁신’을 이끌기 위해서는 API가 필요하다. API를 통해 다른 시스템과 서로 통합된 서비스를 사용자들에게 제공할 수 있어야 한다.

마이크로서비스

  • 시스템 안에서 (예를 들어, 언어 번역 서비스, 푸쉬 알리, 날씨 데이터 등과 같은) 새로운 기능을 빠르게 구현하는 대표적인 방법이 되었다.
  • 기본 전송 매커니즘은 HTTPS를, 기본 데이터 구조는 JSON을 사용한다.

컨테이너화와 DevOps

  • 소프트웨어 개발과 배포 방식을 바꾸어서, 꾸준히 그리고 빠르게 배포할 수 있는 틀을 제공했다.

데이터

  • NoSQL이 정착되고, 전통적인 SQL 데이터 저장소도 발전함에따라 데이터 저장이 폭발적으로 커지고 있다. 그 결과 데이터는 종종 새로운 원유라고 불린다.

RAD가 처음 출현했을 때는

  • 마이크로소프트사의 윈도우가 시장의 요구 사항을 지배하던 시대였지만,

그 이후 지금까지

  • 오랜 여정을 거치면서 현재 위에서 언급된 주요 시장 트렌드를 모두 담아내고 있다.

RAD Studio®의 현재

RAD스튜디오는

  • 단일 코드 베이스를 사용하여 순수 네이티브 코드로 컴파일한다.
  • 멀티 플랫폼 (윈도우, 리눅스, 맥OS, iOS, 안드로이드)용 순수 네이티브 애플리케이션을 생성한다.

RAD스튜디오 방식 만이 가진 장점은

  • 매우 유연하게 그리고 빠르게 앱을 개발할 수 있다.
    • 다른 언어와 프레임워크에 비해 RAD스튜디오가 5배까지 빠르다는 점은 오랜 기간동안 증명되었다.
    • 단일 코드 베이스 기반에서 여러 플랫폼을 다룰 수 있다.
      • 개발과 테스트 시간 모두 단축되어 시장 출시가 더 빨라진다.
  • 개발된 앱은 실행 속도가 빠르다.

델파이가 처음 만들어질 때의 설계 기본과 라이브러리와 컴포넌트 방식은 훌륭했다. 그 효과는

  • RAD스튜디오가 25년 넘게 개발자를 위해 투자를 계속할 수 있는 바탕이 됨
  • 델파이 방식을 받아들인 (C#과 .NET 등) 많은 언어와 프레임워크에서도 쉽게 파악됨
    • 델파이에 적용된 패턴은 명확하고 강력하기 때문에 쉽게 알아챌 수 있다.

델파이에 반영된 설계 기본은

  • 플랫폼의 API를 추상화하여, 쉽게 사용할 수 있는 빌딩 블록을 만들어서 제공한다.
    • 컴포넌트 (와 화면 디자인 편집기)를 제공한다.
      • 플랫폼의 API를 추상화한 쉽게 사용할 수 있는 빌딩 블록
      • 낮은 수준의 시스템 상 호출은 컴포넌트가 알아서 처리
      • VCL, FMX 등 시각적인 컴포넌트와, FireDAC 등 화면 요소가 없는 컴포넌트 모두 제공
  • 라이브러리를 제공한다.
    • 컴포넌트들을 아래에서 뒷받침
    • (파일 시스템, 날짜/시간, 화면 정보 처리 등) 재사용되는 공통 기능이 구현
    • RTL(Runtime Library), PPL(Parallel Programming Library) 등
그림. RAD스튜디오의 설계 기본

혁신과 변화의 물결이 시장에서 밀려들게 되면서

  • 현재 이 방식이 더욱 진가를 발휘할 수 있었다.
    • 그 이유는
      • 인터페이스가 중심이 되어 컴포넌트를 지원한다.
        • 강력한 개체 지향 방식임
        • 새 기능, 새 플랫폼, 새 능력을 넣기에 알맞게 설계되어 있음
        • 기존 호환성 수준도 높게 유지할 수 있음

인터페이스의 중요성

RAD스튜디오 만이 순수 네이티브 코드를 여러 플랫폼 모두에 생성하는 능력을 가지고 있다.

가장 중요한 이유는

  • 델파이에 구현된 방식이 인터페이스 중심이기 때문이다.

‘차량이 달라도 운전대를 사용하는 방식이 같다’

  • 운전대를 사용하는 법을 알면 트럭이나 보트를 운전할 때에도 자신의 차를 운전하는 것과 방식이 같다.
  • 즉, 운전자가 직접 다루는 인터페이스는 같다. (하지만 사용자가 보지 못하는 내부 작동은 차량에 따라 다를 수 있다.)
  • 마찬가지로, 개발자는 공통된 인터페이스를 사용하여 코드를 작성하지만, 구현은 각 플랫폼별로 고유한 결과가 나온다.

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