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