[RAD스튜디오, 관리자들을 위한 안내서] Part 1-1. RAD 탄생과 시장 트렌드
- 2021-04-27
- Posted by: Narae Kim
- Categories: 기술자료, 메인 노출
목차
1부 – 진화하는 소프트웨어 개발 세상 속의 RAD Studio®
- Part 1-1: RAD 탄생과 시장 트렌드 (현재 보고 계신 글입니다.)
- Part 1-2: RAD스튜디오가 혁신을 받아들이는 여러 방법들
- Part 1-3: 현대화에 대한 고민과 해소 방안
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스튜디오 만이 순수 네이티브 코드를 여러 플랫폼 모두에 생성하는 능력을 가지고 있다.
가장 중요한 이유는
- 델파이에 구현된 방식이 인터페이스 중심이기 때문이다.
‘차량이 달라도 운전대를 사용하는 방식이 같다’
- 운전대를 사용하는 법을 알면 트럭이나 보트를 운전할 때에도 자신의 차를 운전하는 것과 방식이 같다.
- 즉, 운전자가 직접 다루는 인터페이스는 같다. (하지만 사용자가 보지 못하는 내부 작동은 차량에 따라 다를 수 있다.)
- 마찬가지로, 개발자는 공통된 인터페이스를 사용하여 코드를 작성하지만, 구현은 각 플랫폼별로 고유한 결과가 나온다.
12.0 12.1 AI AWS C++ c++빌더 chatgpt DelphiCon ios rad서버 RAD스튜디오 UI UIUX UX uxsummit vcl 개발 개발사례 고객사례 기술레터 기술백서 데브옵스 데이터 데이터베이스 델파이 리눅스 마이그레이션 맥 머신러닝 모바일 새버전 샘플 세미나 안드로이드 웹 윈도우 인공지능 인터베이스 출시 커뮤니티에디션 코드 클라우드 파이썬 파이어몽키 현대화