Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

Kori

중재자그룹
  • 포스트

    646
  • 가입

  • 마지막 방문

  • 방문일수

    35

Kori 님이 마직막으로 취득한 날:

Kori 님은 가장 좋아하는 콘텐츠를 가지고 있습니다!

2 팔로워

최근 프로필 방문자

최근 방문자 보기가 꺼져있어서 다른 사람에게 보이지 않습니다.

Kori 님의 성취

Experienced

Experienced (11/14)

  • Posting Machine Rare
  • Reacting Well
  • One Month Later
  • Problem Solver Rare
  • Week One Done

최근 배지

46

평판

37

답변

  1. Hagop Panosian의 "Delphi App For Go-Kart Racing Tops Both App Stores!" 을 번역했습니다. (원문 작성: 2024년 4월, 최종 번역: 2024년 4월) 엠바카데로 MVP이자 Pre-Sales 이사인 Stephen Ball이 만든 델파이 앱이 2024년 4월 12일부터 14일까지 주말 동안 Apple App Store(iOS)와 Google Play(Android) 차트 모두에서 1위를 차지했다. 이 앱은 Go-Kart 경주에서 영감을 받아, 운전자와 기계공이 기어비를 이해하여 경주 트랙에서 Go-Kart 성능을 극대화하도록 돕는다. 흥미롭게도, 이 앱은 제한된 사용자층을 대상으로 함에도 불구하고, 출시된 지 불과 며칠 만에 두 앱 스토어의 유료 스포츠 앱 카테고리에서 1위 자리에 올랐다. 중요한 사실 Android 및 iOS용 네이티브 앱들은 모두 델파이 코드에서 컴파일되었다. RAD 스튜디오의 Artwork Generator는 앱 스토어에서 요구하는 아이콘과 아트를 생성하는 과정을 크게 단순화했다. 앱에 있는 회전하는 톱니바퀴 그래픽은 새로운 Skia 프레임워크를 사용하여 기어비에 따라 톱니바퀴의 속도를 조정한다. Stephen Ball의 개인 블로그 글을 여기에서 읽어볼 수 있다.
  2. David Millington의 "How to achieve common tasks with the new Clang toolchain in 12.1" 을 번역했습니다. (원문 작성: 2024년 4월, 최종 번역: 2024년 4월) 새 Clang 도구 체인이 출시되었다! RAD 스튜디오 12.1과 C++빌더 12.1에는 완전히 새로 만들어지고 완전히 업데이트된 C++ 컴파일러, 링커, STL, 런타임 등이 제공된다. 또한 여러분은 예전 Win64 도구 체인도 병렬로 사용할 수 있기 때문에 쉽게 업그레이드할 수 있다. 이는 우리가 향후에 예전 레거시 도구 체인을 제거하기 전까지 그렇다. 우리는 이것이 '버전 1' 릴리스이고 예전 도구 체인과 몇 가지 면에서 다르다는 것을 알고 있다. 그래서 특정 작업을 수행할 때 새 도구 체인을 사용하는 방법을 이 글에 정리해 두었다. 아직 존재하지 않지만 향후 릴리스에 제공될 기능들 그리고 현재 달성할 수 있지만 그 방법이 명확하지는 않은 것들이 이 글에 모두 포함된다. 추가 정보가 있으면 이 글을 업데이트하겠다. 차례 출시와 현황! 일반적인 작업들 빠른 컴파일 패키지 CMake 임포트(Imports) 부스트(Boost) 소스 전처리하기 및 어셈블리로 컴파일하기 DLL Import 라이브러리들을 생성하기 C++ Win64 Modern용으로 델파이 컴포넌트/패키지를 빌드하기 여러분이 좋아하는 것을 알려주세요! 세이프 하버 선언문 출시와 현황! 우리는 우리가 하고 있는 일들과 그 상태에 대해 공개해오고 있다. 그건 정말 좋았고 계속해서 그렇게 하길 바라고 있다! 주요 소통 내용들은 아래와 같다. 가장 최근부터 나열했다: 2024년 2월: 웹 세미나, 12.1에 대한 Behind the Build – 가장 최근의 기술 개요이며 매우 주목할 가치가 있다. 12.1 출시 웨비나에서는 12.1에 존재하는 것과 존재하지 않는 것에 대해 가볍게 요약한다. Behind the Build에서 이미 많은 세부 사항을 다루었기 때문이다. 이 블로그 글도 명확하게 설명한다. 2023년 11월: Clang 프리뷰와 함께 12.0 출시 2023년 9월: 12.0에 대한 Behind the Build 2023년 3월: 블로그, 'C++빌더가 선보일 새로운 기능: 멋진 프리뷰를 확인해보세요!' – 이 글이 게시된 이후 일부 기술적 세부 사항들이 변경되었음을 참고하기 바란다. 하지만 우리의 목표들을 분명하게 볼 수 있을 것이다. 12.1에 담긴 것들의 최신 상태 정보를 파악하려면, 12.1 Behind the Build 시청을 권한다. 12.1에서 출시된 것들에 대한 기술 정보를 파악하려면, 2024년 2월 Behind the Build를 시청하고 업그레이드 도움말 문서도 읽어 보기 바란다. 기술이 다르기 때문에 그리고 최초 출시이기 때문에, 기능들에 차이가 있다. 일반적인 작업들 빠른 컴파일 Bcc64x에는 아직 –jobs 파라미터가 없다. 이것은 여러 CPU들을 최대한 활용하기 위해 사용되는 파라미터다. 향후 제공 예정이다. TwineCompile을 사용할 것을 권한다. GetIt 구독 시 무료로 제공되고 있다. 우리는 베타 기간 동안 TwineCompile 개발자와 협력했으며, TwineCompile은 새 도구 체인을 지원한다. 새 Clang과 기존 Clang은 컴파일 성능이 매우 비슷하다. (주요 차이점은 링커인데, 새 Clang에서 훨씬 더 빠르다.) Clang 15는 Clang 5보다 더 많은 기능을 수행하지만 그럼에도 불구하고 성능은 매우 비슷하다. Xerces 라이브러리를 컴파일한 결과는 다음과 같다. 릴리스 모드에 컴파일 했으며 링크 시간을 포함한 결과다. 4코어 VM에 있는 파일 300개이다. Xerces 릴리스 빌드(링크 시간 포함) – 파일 300개, 4코어 VM. 빌드 시간은 분:초 단위임. 구 Clang Win64컴파일(Twine 사용 안함) 2:13 새 Clang 64-bit Modern 컴파일(Twine 사용 안함) 2:18 구 Clang Win64, 컴파일(Twine 사용함) 00:38 새 Clang 64-bit Modern 컴파일(Twine 사용함) 00:41 대략 CPU 코어 수에 따라 컴파일 시간이 선형적으로 감소한다. 이 테스트에서는 코어가 4개이며 약 3.5배 더 빨랐다. 16 코어에서는 10~12배 더 빠르다고 볼 수 있다. 패키지 12.1에서, 새 Clang은 패키지 연결(linking)을 정적으로만 지원한다. 이것이 중요하다는 것을 우리는 알고 있다. 그리고 동적 연결은 다가오고 있다! 델파이 패키지들 대부분이 제공된다(Behind the Build의 22:16 지점 참조). 그것들은 .libs로 제공되며 여러분의 EXE 또는 DLL 안에 연결할 수 있다. (즉, 프로젝트를 빌드하기만 하면 된다. 자동으로 링크된다. C++빌더의 헤더들은 자동-링크를 사용하기 때문이다.) 일반적으로, 패키지는 아키텍처적으로 유용하다. 또한 기술적으로 유용한데, VCL의 복사본이 여러 개이면 문제가 발생할 수 있다는 점을 고려하면 그렇다 (예: DLL이 VCL을 사용하는 경우) 그 사실 역시 우리는 알고 있다. 그리고 동적 패키지를 소비할 수 있는 순간이 다가오고 있다. 우리가 집중한 것은 이번 릴리스에 담은 것들의 품질이다. 즉, 우리가 제공하는 것들의 상태가 최고가 되도록 했다. 그래서 정적 패키지가 제대로 작동하는지 확인하는 데 집중했다. C++ 소스 패키지는 현재 정적 라이브러리로만 빌드가 가능하다. 그리고 이제 C++ 패키지용 BPL 파일 구축도 계획되어 있다. CMake 새 도구 체인을 위한 CMake 지원은 12.1에 포함되지 않다. 주된 이유는 범위를 줄여서 타사 도구가 아닌 도구 체인 자체에 집중하기 위해서였다. 패키지와 마찬가지로, 이것 역시 다가오고 있다. 대규모 CMake 전용 소스 빌드를 테스트하기 위해 내부적으로 사용한 몇 가지 해킹이 있다. 하지만 안타깝게도 공유하기에 적합하지 않다. 공식적으로 CMake가 나올 때까지 기다려 주기 바란다. 임포트(Imports) import64.lib에서 임포트 누락과 관련된 몇 가지 버그 리포트가 있었다. 우리는 이것을 조사하고 있다. 부스트(Boost) 12.1용 Boost를 GetIt에 출시했다. 이것은 클래식, Clang Win32, 예전 Clang Win64용이다. 새 도구 체인용 Boost는 현재 작업 중이다. 계속 지켜봐 주기 바란다. 소스 전처리하기 및 어셈블리로 컴파일하기 현재 IDE 안에서 어셈블리로 사전 처리하거나 컴파일하면 실패한다. 하지만, Build Outup 안에 보이는 명령 줄은 잘 작동한다. 그 이유는 이 명령들을 실행하는 msbuild의 타겟이 예전 도구 체인의 DLL 컴파일러를 실행하려고 하기 때문이다. 우회 해결책은 두 가지가 있다. (예를 들어) IDE 안에서 전처리를 시도한다. 그 명령줄을 복사한다. 임시 출력 파일 이름을 여러분이-선호하는-이름.i로 변경한다. 그리고 RAD 스튜디오 명령 프롬프트 안에서 실행한다. 이와 동일한 절차가 어셈블리로 컴파일하는 데에 적용된다. Codegear.Cpp.Targets 파일을 편집한다(참고: 먼저 백업을 해 두는게 좋다.) 그러면, IDE 안에서 명령들이 예상대로 실행된다. <Target Name="__CLANGPreprocessCreate" DependsOnTargets="$(PreprocessDependsOnTargets);"> <PropertyGroup> <CLANG_RunPreprocessor>true</CLANG_RunPreprocessor> <CLANG_OutputFileName>$(PreprocessOutputFilename)</CLANG_OutputFileName> <CLANG_EmitNativeObject>false</CLANG_EmitNativeObject> <!-- Workaround for RS-68975. We must use cpp tools intead --> <!-- !!! CHANGED --> <RunBCCOutOfProcess Condition="'$(Platform)'=='$(cWin64xPlatform)'">true</RunBCCOutOfProcess> <RunBCCOutOfProcess Condition="'$(Platform)'!='$(cWin64xPlatform)'">false</RunBCCOutOfProcess> </PropertyGroup> <ItemGroup> <CppFiles Include="@(InputFile)"/> </ItemGroup> </Target> <Target Name="CLANGPreprocess" DependsOnTargets="__CLANGPreprocessCreate;_CLANGCoreCompile"/> <Target Name="__CLANGToAssemblyCreate" DependsOnTargets="$(ToAssemblyDependsOnTargets);"> <PropertyGroup> <CLANG_EmitNativeAssembly>true</CLANG_EmitNativeAssembly> <CLANG_OutputFileName>$(AssemblyOutputFilename)</CLANG_OutputFileName> <CLANG_EmitNativeObject>false</CLANG_EmitNativeObject> <!-- !!! ADDED --> <RunBCCOutOfProcess Condition="'$(Platform)'=='$(cWin64xPlatform)'">true</RunBCCOutOfProcess> <RunBCCOutOfProcess Condition="'$(Platform)'!='$(cWin64xPlatform)'">false</RunBCCOutOfProcess> </PropertyGroup> <ItemGroup> <CppFiles Include="@(InputFile)"/> </ItemGroup> </Target> DLL Import 라이브러리들을 생성하기 임의의 DLL을 가져오려면 임포트(import) 라이브러리가 필요하다. 우리 링커는 기존의 모든 COFF와 잘 작동되도록 되어 있다(여기에는 MSVC에서 사용할 수 있도록 하기 위해 써드-파티들이 DLL용으로 만든 임포트 라이브러리들도 포함된다.) 그러나, 여러분이 직접 생성해야 하는 경우, 먼저 DLL에 대한 정의(.def) 파일이 필요하다. 그렇게 하려면, LLVM-MinGW의 gendef.exe 파일을 사용하면 된다. 아직 우리 제품 안에 들어있지 않으므로 다운로드해야 한다. 다음은 써드-파티이며 우리가 확인하거나 바이러스를 검사하지 않았다. 하지만 공식 llvm-mingw 사이트에서는 Martin Storsjö의 github 릴리스를 권장한다. 한 가지 릴리스는 이것이다: https://github.com/mstorsjo/llvm-mingw/releases/tag/20220906 gendef.exe의 복사본을 찾았다면, 실행한다: gendef file.dll 그러면 file.def가 생성된다. 참고: 몇몇 사람들은 .def 파일의 파일 이름이 올바르지 않다는 것을 발견했다. .def 파일은 일반 텍스트이다. 여러분은 파일을 열어서 LIBRARY <dllname>.dll이 포함되어 있는지 확인할 수 있다. 여기서 <dllname>이 틀렸을 수 있다. 실제 DLL 이름이 아니라 "a"만 표시되어 있는 것을 우리가 본 적이 있기 때문이다. 그런 다음 새 링커를 사용하여 해당 임포트 라이브러리를 생성하면 된다(RAD 스튜디오의 명령 프롬프트에서 실행하거나 또는 일반 명령 프롬프트에서 rsvars.bat을 실행): ld.lld.exe -m i386pep --out-implib file.lib file.def (또는 LLVM 도구를 사용하여 llvm-dlltool.exe를 사용한다.) 이제 여러분의 DLL용 임포트 라이브러리가 생겼다. file.dll의 경우 file.lib 임포트 라이브러리를 가지게 된다. DLL을 빌드할 때 DLL 임포트 라이브러리 생성하기 위와 똑같은 작업을 수행하고 싶은데, 타사 DLL이 아닌 자체 DLL에 대해 수행하고 싶은가? IDE는 빌드할 때 이 작업을 자동으로 수행한다. 하지만, 여러분이 명령줄에서 이 작업을 수행할 수도 있다: bcc64x -tD -Xlinker --out-implib=dll.lib dll.cpp 또는 bcc64x -tD dll.cpp -Wl,--out-implib,dll.lib 두 변형 모두 DLL과 동시에 임포트 라이브러리를 생성한다. C++ Win64 Modern용으로 델파이 컴포넌트/패키지를 빌드하기 패키지를 빌드할 때, 여러분은 예전 Win64 대상 플랫폼뿐만 아니라 새 Win64 대상 플랫폼에서도 사용할 수 있도록 해야 한다. 그렇게 하지 않으면, 고객이 프로젝트에서 Win64 Modern 대상 플랫폼을 사용할 때 그 컴포넌트들은 팔레트에서 회색으로 표시된다. (기술적 빌드하기 측면도 있다. 델파이의 경우 Win64가 하나만 있지만 C++의 경우 두 개가 있다. ELF와 COFF, 그리고 여러분은 COFF 정적 라이브러리 파일을 여러분의 패키지에게 제공해야 한다.) 그렇다면 컴포넌트들을 어떻게 업데이트하는가? 여러분의 패키지 안에서, Target Platforms를 마우스 오른쪽 버튼으로 클릭하고 Windows 64-bit와 Windows 64-bit (Modern)을 둘 다 추가한다. 이제 각 플랫폼으로 다시 빌드하면 여러분에게 필요한 출력 파일을 얻을 수 있다. 즉, bcc64x는 Windows 64-bit Modern 플랫폼용으로 빌드된 (정적) 패키지에 대해 링크할 수 있다. 그러나, 그 패키지 역시 IDE 안에 설치되어야 한다. 그리고 IDE는 그 컴포넌트를 사용할 수 있는 플랫폼을 추적한다(예를 들어 Windows 전용 컴포넌트가 macOS 앱에서 사용되지 못하도록 하기 위해서다). 이제 두 Win64 플랫폼을 모두 추가했으니, Win32 디자인타임 패키지를 다시 빌드한다. 이것은 IDE 안에 설치되는 패키지이다. 그리고 그 패키지 안에 들어있는 컴포넌트들이 어느 플랫폼에서 사용될 수 있는지에 대한 정보가 들어있다. 이제, 여러분은 그 컴포넌트를 설치한다. 그리고 팔레트 안에 있는 그 컴포넌트 위로 마우스를 가져가면 Windows 64-bit Modern이 플랫폼으로 나열되는 것을 볼 수 있다. 여러분이 생성하고 있는 파일들은 다음과 같다. Win32: <package>.lib(정적 라이브러리로서의 패키지) 그리고 <package>.bpi(동적 패키지 임포트 라이브러리) Win32의 경우, 컴포넌트 패키지 하나는 두 개의 패키지로 분할되어야 한다.디자인 타임(IDE용, Win32 전용) 패키지와 런타임(앱용, 모든 플랫폼용, 즉 Win32, Win64 및 Win64 Modern) 패키지이다. Win64: <package>.a(정적 라이브러리로서의 패키지) 그리고 <package>.bpi(동적 패키지 가져오기 라이브러리) Win64X* / Windows 64-bit Modern: <package>.lib(정적 라이브러리로서의 패키지 - 향후 제공될 동적 패키지에 대해 위의 참고 사항 참조) * 우리는 "x"를 이름에 자주 사용한다. 그 이유는 컴파일러 이름이 bcc64x이기 때문이다. 여러분은 두 가지를 달성했다. 여러분의 런타임 패키지에 Windows 64-bit Modern 플랫폼을 추가하고 앱을 빌드할 때 그 패키지 안에서 링크하는 데 필요로 하는 바이너리 파일들을 제공했다. IDE에게 그 컴포넌트들이 Windows 64-bit modern에서 사용할 수 있다고 알려주었다: 프로젝트에 그 플랫폼을 추가한 후 디자인 타임 Win32 패키지를 다시 빌드하고 IDE에 다시 설치한다. 여러분이 좋아하는 것을 알려주세요! 새 도구 체인은 기반이 되는 릴리스이다. 미래를 위한 많은 것들과 우리가 미래에 할 수 있는 것들을 의미한다. 우리는 이것을 구축할 때 올바른 결정을 내리는 것을 목표로 삼았다: 여러분은 모든 곳에서 그 증거를 볼 수 있을 것이다. 플랫폼 규칙부터 C 런타임 선택, 64비트 바이너리, 품질 및 기능 범위에 대한 집중에 이르기까지 말이다. 또한, 우리는 차이점을 최소화하고 기존 코드와의 호환성을 보장하기 위해 열심히 노력했다. 자세한 내용은 도움말 문서에 있다. 우리는 앞으로 이 도구 체인을 사용하여 우리가 출시하게 될 제품들을 만날 날을 기대하고 있다. 그리고 지금 여러분에게 얼마나 효과가 있을지 보고 싶다! 세이프 하버 선언문 논의된 모든 계획은 현재의 당사 의도를 나타낸다. 당사의 개발 계획 및 우선순위는 변경될 수 있다. 이는 경쟁 요인, 리소스 가용성, 독립 소프트웨어 공급업체들이 공통적으로 가지는 기타 공통된 문제 등의 영향을 받는다. 따라서, 우리는 여기서 어떠한 약속이나 기타 형태의 보증도 제공하지 않는다. 설명된 제품 중 일부 또는 전부를 언급된 일정이나 순서에 맞게 제공한다는 약속이 아니다. 개발 일정 대한 이러한 일반적인 표현 즉 "제품 로드맵"은 어떤 형태의 약속으로 해석되거나 추론되어서는 안 된다. 그리고 업그레이드, 업데이트, 개선 및 기타 유지 관리 릴리스에 대한 고객의 권리는 해당 소프트웨어 라이선스 계약 안에만 명시된다. 중요: 기능들은 완료되고 GA(일반 공급) 출시가 될 때까지 약속되지 않는다.
  3. 데이비드 밀링턴(David Millington)의 "The new Clang Toolchain in C++Builder 12.1!" 을 번역했습니다. (원문 작성: 2024년 4월, 최종 번역: 2024년 4월) 차례 C++빌더 12.1 안에 있는 새 C++ Clang 도구 체인! 기술적 정보 무엇을 제공하는가? 아직 없는 것은? 이미 있는 것은? 미래 C++빌더 12.1 안에 있는 새 C++ Clang 도구 체인! RAD 스튜디오 12.1은 빅 뉴스다: 우리의 새 Clang-기반 도구 체인의 첫 버전을 출시했다. 이는 전체 기술 스택의 완전한 개정판이며, 모든 C++을 발전하게 만드는 기반이 된다. 탄탄하고 현대적이고 '올바른 방식으로 수행된' 기반이다. 기술적 정보 새 툴체인은 Windows 64비트 Intel 앱을 대상으로 하며 새 STL 그리고 새 C++ 런타임이 포함된 Clang 15를 기반으로 한다. 또한 Windows의 Universal C Runtime(UCRT)을 사용한다. 새 링커가 들어 있다. 그리고 COFF 및 PDB 오브젝트와 디버그 파일 포맷을 사용한다. 자세한 내용은, 두 번째 Behind the Build 웹 세미나를 참조하면 된다. 12.1이 출시되기 몇 주 전에 진행된 세미나다. 또한, 업그레이드에 대한 도움말 문서에는 알아야 할 주요 사항들이 있다. 모든 바이너리(컴파일러, 링커 등등)들은 64비트 EXE다. 즉, 대용량 메모리 요구 사항들을 처리할 수 있다 - 그리고 C++에서 이것이 얼마나 자주 필요한지 알면 여러분은 놀랄 것이다. 여기에는 외부 프로세스를 호출하는 IDE에서 컴파일할 때도 포함된다. Clang: 미래를 향한 탄탄한 기반 무엇을 제공하는가? 이 도구 체인은 기능보다 품질 우선(버전 1이지만 우리가 출시하는 것이 견고하길 원했기 때문)에 집중했다. 그리고 올바른 일을 하는 것과 올바른 선택을 하는 것, 사용자에게 영향을 미치는 품질 관련 핵심 영역을 해결하는 것, C++빌더의 미래가 정말 흥미롭도록 밑받침하는 것에 집중했다. 올바른 선택의 예: 플랫폼 표준 COFF 개체 파일 오브젝트를 사용하고 있다. 플랫폼 표준 PDB 디버그 오브젝트를 사용하고 있다 (필요한 경우, 여러분이 다른 특수 디버거들을 사용할 수 있도록 한다). 오픈 소스 소프트웨어를 많이 쓰도록 하고 있다. LLVM의 STL(libc++) 등 중복 작업을 제거하고 있다: 예전에는 우리 자체 C 런타임이 가지고 있었다. 하지만 지금 Windows 안에는 런타임(UCRT)이 내장되어 있다. 우리는 그걸 사용한다 예전 Win64 도구 체인과 새 도구 체인을 IDE에서 나란히 제공한다(그렇다. 둘 다 있다!). 따라서 여러분은 이전 Win64 도구 체인에서 새 도구 체인으로 업그레이드하고 테스트할 수 있다. 플랫폼을 선택 바꿔꾸기만 하면 된다. 이는 업그레이드 시 크게 도움이 된다. 갑작스럽게 전환을 하지 않아도 된다. 여러분에게 영향을 미치는 품질 관련 영역의 예: 링커: 이제는 더 이상 메모리 문제가 더 이상 없어야 한다. Chrome을 빌드하는 데 사용되는 것과 동일한 링커다. 링커: 기존 ilink보다 약 4배 빠르다. STL: 완전히 교채했다. 고품질 STL이다. 표준 테스트 결과들이 매우 우수한 것이다. 미래가 흥미롭도록 밑받침하는 예: Clang의 최근 버전이다. 최신 상태를 유지하기가 훨씬 더 쉽다(현재 가장 최신 버전이 아닌 유일한 이유는 움직이는 목표들을 줄여서 그 영향을 최소화하기 위함이다). 플랫폼 표준을 통해 상호 운용성을 지향한다. 오픈 소스 STL은 충실한 (계속되는) 품질과 기능을 지향한다. 등등. 기능보다 품질 우선의 예: C++ 표준 준수에 중점을 두었다. 작년 중반, 출시 9개월 전, 우리는 이미 이전 도구 체인에 비해 더 많은 테스트를 통과했다. 추가 품질에 매우 중점을 두었다. 예외 처리에 특히 집중했다. 여러 테스트 스위트들을 통과할 뿐만 아니라 다양한 시나리오에 대해 700개가 넘는 새 테스트들을 만들었다. 아직 없는 것은? 기능보다 품질 우선은 이 버전 1 안에 모든 것을 넣지는 않았다는 의미기도 하다. 없는 것들 중에 주목할만 것들은 다음과 같다: 이번 릴리스에서는 패키지가 정적으로만 연결될 수 있다. 동적으로 연결되지 않는다; 이와 비슷한데, C++로 빌드된 패키지는 현재 정적으로 링크되어야 한다(예: .libs로 빌드); 아직 CMake를 지원하지 않는다. 또한 현재 Boost 등 GetIt의 라이브러리를 업데이트하는 과정도 진행 중이다. 이 기능들에 대한 계획, 일반 작업과 이를 달성하는 방법에 대한 정보는 이 블로그 글을 읽어보기 바란다. 위 사항들이 문제 되지 않는다면, 이 도구 체인을 사용하는 것을 권장한다. 전체적인 품질이 크게 향상되었기 때문이다. 이미 있는 것은? 이득이 매우 크다! 여기 저기에 있던 기술 지원 티켓들을 종료한다. 과거에 작동하지 않았던 코드가 이제는 작동하기 때문이다. 새롭고 빠른 링커를 사용해 보자. 새 고품질 STL(std::variant 또는 다른 타입들에서 문제가 있었던 적이 있는가? 지금 시도해 보자.) PDB 포맷을, 원한다면, 사용한다. 예: WinDbg를 사용하려는 경우 뛰어난 C++ 호환성: 써드 파티 코드를 컴파일해야 한다면, 이 도구 체인을 사용하자. 왜 그런지 알게 될 것이다! 미래 이것은 기반이 되는 릴리스이다. 꼭 사용해 보시기 바란다! RAD Studio 또는 C++Builder를 설치하면, 이전 Win64 도구 체인과 새 Win64 도구 체인을 동시에 병렬로 사용할 수 있다는 점을 기억하자. 여러분의 프로젝트들에서 이 새 도구 체인을 추가하기만 하면 된다 (Projects 창에서 마우스 오른쪽 버튼을 클릭하고 Add Platform에서, 'Win64 Modern'을 클릭). 그러면 이 둘 사이를 왔다갔다 할 수 있다. 원하는 것을 더블-클릭하면 활성화된다. 향후에는 예전 Win64 도구 체인을 제거할 계획이다. 동적 패키지를 출시하게 된다면 말이다. 그러니, 이 두 도구 체인들이 함께 제공되는 지금을 일종의 업그레이드 지원 기능이라 생각하고 활용하기를 권장한다. 여러분도 우리만큼 이번 릴리스를 기쁘게 느끼기를 바란다. 우리는 이것이 버전 1이라는 것을 알고 있다. 하지만 품질 측면에서 견고한 버전 1이다. 우리는 여러분이 이 버전을 써보고 여러분의 코드를 대상으로 해보는 것을 정말 기대하고 있다. 이전에는 달성할 수 없었지만 이제는 달성할 수 있는 것들이 무엇인지 확인하기 바란다!
  4. 누구나, 35분동안 이 비디오를 그대로 따라하면 메모장 (notepad.exe)을 구축할 수 있습니다. Alister Christie는 델파이를 배우려는 개발자에게 도움이 되도록 LearnDelphi.tv를 운영하고 있습니다. 매우 많은 교육 자료, 비디오 등을 제공하고 있습니다. 한글로 번역된 도서인 "델파이로 더 빠르게 코딩하기" 도서의 저자이기도 합니다.
  5. << 위로 이동 (최신 버전 포함 모든 버전) "RAD 스튜디오 12 아테네 - 릴리스 1"을 정리한 Docwiki (원문 보기)를 번역한 글입니다. 메인 페이지(영문 )로 이동 >> 과거 버전들의 새 기능 모아 보기(영문)로 이동 >> 참고: 12 아테네에서 새로 포함되었던 기능(영문)을 모두 볼 수 있다. RAD 스튜디오 12 아테네 - 릴리스 1 (12.1이라고도 부름)을 이제 설치할 수 있다. RAD 12.1은 RAD 스튜디오 12의 기능을 바탕으로 하여 제품 전반에 걸쳐 기존 기능을 강화하고 몇가지 새 기능들을 추가했다. RAD 스튜디오 12는 품질 향상에 주력했다. 하지만, C++ 도구 체인과 IDE에서 현격한 향상이 반영되었다. 주요 기능들과 품질 집중 영역은 다음과 같다: C++ Clang 도구 체인 분할 에디터 (Split Editor) IDE (통합 개발 환경) Debugger (디버거) 안드로이드 타겟 API 레벨 34 VCL VA 델파이 컴파일러 기타 라이브러리들 차례 1. [12.1]에서 강화된 점을 제품 영역 별로 보기 1.1 C++ Clang 도구 체인 1.1.1 여러분이 할 수 있는 것은? 1.1. 2 제한 사항 (Limitations) 1.1.3 특별 참고 사항 (Special Notes) 1.1.3.1 가상 파일 시스템 (Virtual File System) 1.1.3.2 POSIX 및 기타 RTL 메서드들 1.1.3.3 C++ 표준 호환성 1.1.4 패키지와 라이브러리 1.2 분할 에디터(Split Editor) 1.2.1 분할 에디터 사용하기 1.2.2 디자이너와 코드 1.2.3 촛첨 추적하기 1.2.4 도킹(Docking)과 배치(Layouts) 1.3 IDE 향상 1.3.1 델파이LSP 코드 완성 1.4 디버거 1.5 안드로이드 타겟 API 레벨 34 1.6 품질 향상 1.6.1 VCL 1.6.2 C++용 Visual Assist 1.6.2.1 기타 라이브러리 1.7 기타 참고 (See Also) 1. [12.1]에서 강화된 점을 제품 영역 별로 보기 1.1 C++ Clang 도구 체인 RAD 스튜디오 12.1은 윈64용 Clang 도구 체인 업그레이드를 IDE 안에 통합했다. 새 도구 체인 전체가 IDE 안에 완전히 통합되어서 일반 플랫폼처럼 사용된다. 이 도구 체인에 포함된 것들로는 새 Clang 15 컴파일러, LLVM lld 링커, libc++ STL, UCRT C 런타임, 등등이 있다. 이 도구 체인은 기존 윈64 플랫폼과 함께 병행 제공된다. 윈 64용으로는 VCL과 FMX 지원, DLL, 정적 라이브러리, 콘솔 애플리케이션 등이 지원된다. IDE 안에서 Target Platforms를 오른쪽 클릭하고 Win64 (Modern)를 추가하면 된다. 1.1.1 여러분이 할 수 있는 것은? 이 도구 체인은 VCL과 FMX로 실제 애플리케이션을 만들도록 준비가 되어 있다. IDE는 완전하게 통합되었다. 올바른 옵션들을 컴파일러 드라이버와 링커에게 전달한다. 여러분은 특별한 우회 조치 또는 컴파일러 명령-줄 플래그(flag)들이 전혀 필요하지 않을 것이다. 알아둘 점: 동적 패키지 설정이 되어 있다고 해도, 여러분의 앱은 패키지를 정적으로 링크한다. 위 이미지는 파이어몽키로 만든 미로 앱(우리 깃허브에 있음)을 새 Clang 도구 체인으로 만든 것이다. 1.1. 2 제한 사항 (Limitations) 몇 가지 라이브러리들(예: SOAP)은 이 도구 체인 안에 들어 있지 않다. 이는 테스트 점검을 줄이기 위해서다. 즉 가장 많이 필요한 라이브러리들의 품질에 집중하기 위해서다. 사용할 수 있는 라이브러리들/패키지들에 대한 전체 목록은 아래와 같다. 패키지(예: VCL 등등)들은 여러분의 앱에 정적으로 링크된다. RAD 스튜디오 12.1에는 동적 패키지 소비(예: BPL 파일들을 EXE와 함께 배포하여 동적으로 연결하기)기능이 들어 있지 않다. 패키지의 내용물들은 EXE 안에 정적으로 링크된다. 이는 ‘Runtime packages’ 설정을 Project Options에서 어떻게 지정해도 마찬가지이다. 패키지를 C++로 생성하기. RAD 스튜디오 12.1이 지원하는 패키지는 현재 오직 델파이로 작성한 것들 뿐이다. 1.1.3 특별 참고 사항 (Special Notes) 1.1.3.1 가상 파일 시스템 (Virtual File System) IDE는 가상 파일 시스템 (Virtual File System, VFS)을 유지한다. 즉 여러분은 프로젝트 생성하기, 파일 생성하기, 기존 파일 변경하기, 그것들을 컴파일하고 실행하기 등을 디스크에 저장하지 않고 할 수 있다. 예전엔, 그렇게 하기 위해, 우리 도구 체인들은 모두가 컴파일러와 링커의 DLL 버전을 가지고 있어서 IDE VFS 안으로 낚아 챘다(hooking). 새 Clang 업그레이드에서는 Clang VFS 오버레이(overlay)를 사용한다. 임시 VFS 파일들은 컴파일 후에 제거되는 것이 기본 설정이다. 이 설정을 끄려면, Project Options > C++ Compiler > Advanced로 가서, Remove temporary VFS files after compilation 옵션을 끄면 된다. 1.1.3.2 POSIX 및 기타 RTL 메서드들 RAD 스튜디오는 표준 윈도우 RTL 메서드 세트를 완전하게 준수하지 않았었다. 그래서 많은 POSIX 버전과 사용자 정의 함수들을 제공했었다. 그것들 중 몇 가지가 빠졌을 수도 있다. 1.1.3.3 C++ 표준 호환성 RAD 스튜디오는 libc++ 15.0을 사용한다. C++ 언어 표준 규약을 아래 페이지에서 확인하자. C++14 C++17 C++20 (RAD가 지원하지 않음) C++23 (RAD가 지원하지 않음) 참고: 포맷 라이브러리에는 libc++ 16에서 도입한 지원이 있다. 따라서, RAD 스튜디오 12.1은 아직 이것을 지원하지 않는다. ( {fmt} 라이브러리는 테스트되지 않았지만, 잘 작동할 것이다.) 기타 항목들, 예를 들어, Parallelism TS, spaceship operator 등등이 libc++ 안에 있다. 하지만 아직 그 버전에 대한 도움말에는 반영되지 않았다. 1.1.4 패키지와 라이브러리 새 lld 링커는 ilink보다 현격하게 빠르다(약 4배 더 빠름). 더 큰 파일 크기를 쉽게 처리한다. 따라서 동적 링크를 (링크 시간이나 링커 메모리 때문에) 우회용으로 사용할 필요가 없다. 동적 패키지 소비는 아키텍처상의 이유로 중요하다. 그리고 RAD 스튜디오는 다음 릴리스에서 동적으로 링크되는 델파이 런타임 패키지 업그레이드를 계획하고 있다. 포함된 라이브러리들과 포함되지 않은 라이브러리들에 대한 목록을 패키지 설명서 페이지에서 찾아보자. 1.2 분할 에디터(Split Editor) RAD 스튜디오 12.1에서는, IDE에서 분할 에디터(Split Editor) 화면을 지원한다. 여러 에디터들을 나란히 그리고 위 아래에 놓고, 또는 섞어서 그 모든 화면을 같은 창 안에 배치할 수 있다. 또한, 모든 탭 세트들을 떠다니는 창 (floating window)으로 끌어 낼 수 있다, 또한 IDE 안으로 다시 끌어 넣을 수도 있다. RAD 스튜디오의 에디터 화면은 수준 높은 방식으로 구현되었다. 따라서 복잡한 사용자 정의 배치와 조작이 가능하다. 즉, 간단한 2열 배치, 여러 행 배치 또는 여러분의 작업 흐름에 딱 맞는 맞춤 배치를 할 수 있다. 여러 탭 모두가 똑같은 유닛을 열어 놓고 편집할 수 있다. 또는 한 탭에는 폼 디자이너를 열어 놓고, 그 유닛의 코드를 다른 여러 탭에서 열어 놓고 작업할 수도 있다. 어느 탭에서 디자이너를 보여줄 것인지를 서로 이동할 수도 있다. 분할 에디터의 갯수에는 제한이 없다. 가로든 세로든 마찬가지다. 1.2.1 분할 에디터 사용하기 분할 에디터에 접근하려면, 탭을 마우스 오른쪽 버튼으로 클릭하고 Split > 또는 Move >를 선택한다. Split은 선택한 탭의 다른 버전을 새로 생성한다. 반면, Move는 그 위치에 있는 탭을 닫고 여러분이 IDE 안에서 선택한 위치에서 그 탭을 연다. 분할 에디터를 사용하는 또 다른 방법은, Projects 창 안에 있는 파일을 아무 에디터 안으로 끌어 놓는 것이다. 그러면, 그 파일은 해당 탭 그룹 안에서 새 탭으로 열린다. 두 개의 탭이 하나의 창 안에 있으면, 두 세트 모두 각자의 제목 표시줄을 가진다. 다음을 수행할 수 있다: 에디터 탭 또는 에디터 탭 세트를 끌어서 IDE 창 안의 어느 측면이든 놓으면 그곳에 붙는다(docking). 끌어서 도킹하기는 이미 열려있는 다른 에디터의 측면(왼쪽, 오른쪽, 위쪽, 아래쪽)에서도 작동한다. 이미 열려있는 다른 탭 세트안에 탭을 병합하려면, 넣고 싶은 에디터의 중앙으로 끌어 놓으면 된다. (탭들을 담고 있는) 떠다니는 창도 끌어 넣을 수 있다. 끌어서 바깥에 놓으면, 자체 창이 된다(탭 하나 또는 탭 집합). 더 많은 동작들을 각 탭에서 할 수 있다. 예를 들어, 도킹되어 있는 탭 세트들 사이에서 이동하기를 하려면, 개별 탭을 한 위치에서 다른 위치로 끌어 옮기면 된다. 각 탭 세트를 끌어서 끄집어 내면, 자체 창이 된다. 제목 표시줄을 끌어서 이동시킨다. (드래그를 할 때는 Ctrl 키를 누른 채 끌고 가자. 그러면, 도킹을 시도하지 않으므로, 떠다닐 수 있다) 마찬가지로, 각 창을 다른 탭 세트 옆에 도킹할 수도 있다. 그러려면, 제목 표시줄을 드래그하면 된다. 참고: 대부분의 에디터들/그룹들은, 닫히면, 그냥 사라진다. 그러나, 최초의 에디터, 즉 메인 창의 유일한 에디터로 사용되는 창을 'X' 버튼으로 닫으면 포함된 모든 탭들이 닫힌다. 그럼에도 불구하고, 그 공간은 여전히 열려있다. 원본 에디터는 닫을 수 없다. 그리고 화면에는 항상 그 공간이 있다. 여러분이 탭 그룹을 닫을 때까지 이 공간은 아무 영향도 미치지 않는다. 일상적인 작업에서 이것을 생성, 이동 또는 도킹하는 동작이 끼치는 영향은 전혀 눈에 띄지 않는다. 1.2.2 디자이너와 코드 분할 에디터들를 서로 옆에 놓고, 동일한 파일의 내용을 열어서 편집할 수 있다. 두 에디터 모두 동일한 파일의 내용을 볼 수 있다. 에디터 하나 안에서 타이핑을 하면서, 다른 에디터에서 그 위치로 간다면 입력한 텍스트가 이미 들어 있을 것이다. 그런데, 두 화면 모두 스크롤이 독립적이다. 따라서 동일한 파일 안의 여러 위치들을 편집할 수 있다. 동일한 파일을 편집하는 탭의 갯수에는 제한이 없다. 참고: 명실할 점은. 단 하나의 파일(내부 용어로 모듈 또는 파일 버퍼)을 여러 에디터 화면에서 열었을 경우에, 한 에디터에서 변경한 사항은 언제나 그 파일을 보고 있는 다른 모든 에디터에도 반영된다는 점이다. 하나의 편집기에서 내용을 변경하면 '복사', '중복' 등과 같은 동작을 전혀 하지 않는다. 파일 하나는 그 내용도 하나다. 비록 여러 에디터에서 열고 편집하더라도 말이다. 달리 설명하자면, 한 에디터에서 파일을 편집할 때 해당 변경 사항은 파일 자체에 반영된다. 그 에디터에만 반영되는 것이 아니다. 정의하자면, 동일한 파일을 열고 있는 다른 에디터들 안에도 언제나 변경 사항이 들어간다. 1.2.3 촛첨 추적하기 RAD 스튜디오에서 UI 디자인의 핵심 원칙은 초점을 명확하게 하는 것이다. RAD 스튜디오 12.1 이전 버전에서는, 현재 초점이 맞춰진 창은 강한 파란색이었다. 한쪽에 도킹된 창이든 (그때 당시에는 하나만 있었으므로 단일) 에디터 탭이든 관계없이 그랬다. 그와 동일한 기술이 적용된다. 그런데, 이제는 여러 에디터가 있으므로, 탭 그룹의 제목 표시줄과 해당 특정 탭이 진한 파란색으로 표시된다. 이로 인해 정말, 정말 명확하게 알 수 있게 된다. 촛점이 없는 에디터를 가진 각 에디터 그룹들은 제목 표시줄의 '배경' 색상이 창백하다. 심지어 그 그룹에서 맨 위에 있는 탭(해당 그룹이 촛점을 받은 경우 실제로 촛점을 가지게 되는 탭)조차도 회색으로 표시된다. 따라서 촛점이 없음을 알 수 있다. 1.2.4 도킹(Docking)과 배치(Layouts) 12.1부터는, RAD 스튜디오를 사용하면 Object Inspector와 같은 창들을 원하는 곳 어디든 이동하고 도킹할 수 있다. 실제 사용시, 도킹 가능한 창(Object Inspector, Structure view 등등)과 도킹 가능한 에디터/에디터 그룹 사이에 차이가 거의 없다. 따라서 필요에 맞게 강력한 배치를 구성할 수 있다. 데스크탑 레이아웃은 열려 있는 에디터(및 에디터 그룹, 해당 위치, 도킹된 위치 등)들과 예전 방식에서도 도킹 가능했던 창들이 함께 배치되는 세트이다. 여러 개의 창을 가질 수 있으며, 각 창마다 여러 개의 탭이 들어 있을 수 있다. 에디터를 구성했다면, 데스크탑 레이아웃으로 저장해야 한다. 그렇지 않으면 쉽게 잃게 된다. 또한, 그 구성은 해당 데스크톱 레이아웃이 변경되는 경우 바뀐다. 예를 들어, IDE가 디버깅을 시작하면, 디버그 레이아웃으로 전환되고, 그러면 디버그 레이아웃 구성이 적용된다. 레이아웃이 바뀔 때, 새로 전환되는 레이아웃 안에는 해당 위치가 없는 모든 탭 그룹(개별 탭도 마찬가지로, 별도로 도킹되어 있는 한)이라면 도킹이 해제되어 떠다니는 창이 된다. 1.3 IDE 향상 1.3.1 델파이LSP 코드 완성 RAD 스튜디오 12.0에서 코드 완성 기능이 추가되었었다. 즉, 타이핑할 때 자동으로 코드 완성 팝업이 나타나게 할 수 있다. 이 DelphiLSP 이전 기능은 도움이 되는 제안들을 목록으로 제공했다. 이전처럼 점을 찍어야만 즉 수작업으로만 불러낼 수 있는게 더 이상 아니다. 그러나, 타이핑할 때 이것이 자동으로 나타나면, 특정 항목을 타이핑하기가 어려운 경우들도 종종 있다. 예를 들어, 새 변수 이름은 (알려져 있지 않은 식별자이므로) 자동으로 제안되지 못한다. 코드 완성 기능에서는 여러분이 스페이스(Space) 키를 눌렀을 때 제안 목록의 맨 위에 있는 항목이 수락되었다. 그러므로, 여러분이 작성 중인 내용은 무시되었다. RAD Studio 버전 12.1에서는 그 기능성을 보다 향상했다. 이제는 auto-invoke 기능은 On으로 되어있고, 코드 완성을 자동으로 불러낼 때는, 여러분이 현재 선택된 자동 완성을 수락하려면, 오직 Tab과 Enter 키를 사용해야 한다. 다른 키 즉 스페이스(Space), 여는 중괄호, 점 등과 같은 다른 키는 효과가 없다. 즉, 코드 완성을 자동으로 불러낼 때는, 여러분이 반드시 완성을 수락하겠다고 선택해야 한다는 의미다. 이제 무언가를 실수로 자동 완성하는 일은 없을 것이다. 코드 완성을 일반 방식으로 불러낼 때는, 위 키들을 사용하여 제안된 내용을 수락할 수 있다. 이는 11.3 및 이전 버전에서와 마찬가지다. 다시 말하자면, 이 동작은 이전의 모든 일반 방식의 코드 완성에서 전혀 바뀐 것이 없다. 해당 auto-invoke 기능은 Off가 기본 설정이다. 이 기능을 켜고, 새 완성 키 탭들에 대해 더 알아보려면 Code Insight 설명서를 참고하자. 1.4 디버거 버전 12.1에서, 델파이 윈32, 델파이 윈64, C++ 윈32만 제외하고, 모든 디버거들이 LLDB 15를 사용한다. 이는 Clang 업그레이드에서 사용되는 것과 동일한 디버거이다. 이전 버전에서는 LLDB 12를 이 플랫폼들에 사용했지만, 이제는 업그레이드되었다. 1.5 안드로이드 타겟 API 레벨 34 RAD Studio 버전 12.1은 Android API 레벨을 34로 업데이트한다. 이 변경을 위해 안드로이드 SDK 도구 사용 변경이 필요했으며, 몇 가지 추가 안드로이드 플랫폼 도구들이 필요했고, Java 런타임 업데이트도 필요했다. 자세한 내용은 다음과 같다: 12.1 버전은 플랫폼 기능들 중에서 설치된다. 그리고 Eclipse Temurin JDK OpenJDK 17(핫스팟) JVM을 권장한다. 12.1 버전에서는 명령-줄 도구 Android SDK 컴포넌트들이 우리의 기본 Android SDK 설치에서 나와서 업데이트되었다. 기본 targetSdkVersion 매니페스트 애트리뷰트(attribute)는 이제 34이다. RAD Studio 12.1은 .apk 파일 생성 시 성능이 눈에 띄게 향상되었다. 왜냐하면 12.1은 Google의 zipflinger 라이브러리와 signflinger 라이브러리를 패키징을 하는 명령-줄 도구 안에서 활용하기 때문이다. Android 패키징의 개선 사항은 다음과 같다: Android DEX 작업 (DEX 컴파일 및 DEX 병합)은 이제 증분식이다 (이제 이 작업은 오직 입력 파일이 해당 출력 파일과 관련하여 오래된 것으로 간주되는 경우에만 시작된다). 12.1 버전에서는 빌드 시스템이 이전되었다. 전에는 오래되고 단종된 Google의 AAPT 명령-줄 도구를 사용했지만, 이제는 Google의 새 도구인 AAPT2를 사용한다. Google의 AAPT2 명령-줄은 이제 각 Android 리소스 파일을 컴파일하고 그것들을 모아서 하나의 .zip 파일 안에 패키징을 한다. 그 패키지 안에는 해당 매니페스트 파일과 Android 리소스 테이블도 들어 간다. 새 Packager 명령-줄 도구는 패키지되는 리소스 파일, 네이티브 라이브러리, 자산 파일 및 .dex 파일을 최종 .apk 또는 기본 모듈 파일 안에 넣는다. 1.6 품질 향상 1.6.1 VCL VCL TEdit은 이제 윈도우 최신 버전에 있는 쉬운 접근성(Ease of Access)의 텍스트 커서(Text Cursor)에서 올바르게 작동한다. 이 방식에 따라, 우리는 IDE에 대한 접근성을 다시 살려 놓았다. 예전에는 위 이슈 때문에 비활성화가 기본 설정이었다. JAWS를 IDE에서 기본 설정으로 (다시) 잘 사용할 수 있다. NumberBox가 개선되었다. 음수 값을 사용할 수 있다. ProgressBar State는 이제 VCL 스타일 하에서 지원된다. 1.6.2 C++용 Visual Assist 파일을 저장하지 않고 닫는 경우, VA에 캐시가 남아 있는 문제가 해결되었다. 이름바꾸기는 이제 이벤트 핸들러의 이름도 변경한다. 컴포넌트의 이름을 바꾸면, 디자이너 안에서도 그 이름이 바뀐다. 이는 12.0에서 빠뜨렸던 기능이다. 오브젝트의 프로퍼티에 대한 코드 완성은 이제 올바르게 작동한다. 코드 완성 결과로 인해 예상치 못한 값이 표시되는 경우가 더 이상 없다. 코드 완성이 발동하지 않는 이슈가 해소되었다. VA가 써드 파티 라이브러리에서 작동하지 않는 이슈가 해소되었다. #include 전처리기 지시문 자동 완성을 < 및 ""로 사용할 때 이제는 올바르게 작동한다. 사소한 UI 향상들이 메뉴에 반영되었다. 1.6.2.1 기타 라이브러리 RAD Studio 12.1에서는 데이터베이스 부문에 다음과 같은 개선 사항들이 도입되었다: TIBDataSet 에디터(IBX)가 개선됨. FireDAC 지원에 Firebird 버전 5가 추가됨.여기에는 Firebird 5용 TFDFBBackup 안에서 병렬 작업이 되도록 하는 지원이 포함됨. FireDAC 지원에 PostgreSQL 버전 16이 추가됨. 최신 버전인 IBToGo 및 IBLite(InterBase 2020 업데이트 5에 맞춰짐)는 이제 안드로이드에서 작동한다. 파이어몽키의 12.1에는 다음이 포함되었다: 맥OS에서 불투명 형식으로 저장된 투명 비트맵은 Windows에서처럼 동작한다(즉, 투명 색상이 검은색으로 변한다). 인터넷 부문에서, 12.1에는 다음이 포함되었다: TRestClient는 현재 사용자 목록뿐만 아니라 로컬 컴퓨터 목록의 인증서 사용을 지원한다. 웹 16진수 색상 구문을 StringToColor 함수에서 지원한다. REST 디버거가 테이블 셀에서 값을 복사하는 기능. RAD 서버 사용자의 사용자 이름을 변경하는 기능. 1.7 기타 참고 (See Also) Installation Notes Release Notes New features and fixed issues 과거 버전들의 새 기능 모아 보기(영문) View full RAD 스튜디오 버전별 신기능
  6. Kori

    [12.1] 아테네 - 릴리스 1

    << 위로 이동 (최신 버전 포함 모든 버전) "RAD 스튜디오 12 아테네 - 릴리스 1"을 정리한 Docwiki (원문 보기)를 번역한 글입니다. 메인 페이지(영문 )로 이동 >> 과거 버전들의 새 기능 모아 보기(영문)로 이동 >> 참고: 12 아테네에서 새로 포함되었던 기능(영문)을 모두 볼 수 있다. RAD 스튜디오 12 아테네 - 릴리스 1 (12.1이라고도 부름)을 이제 설치할 수 있다. RAD 12.1은 RAD 스튜디오 12의 기능을 바탕으로 하여 제품 전반에 걸쳐 기존 기능을 강화하고 몇가지 새 기능들을 추가했다. RAD 스튜디오 12는 품질 향상에 주력했다. 하지만, C++ 도구 체인과 IDE에서 현격한 향상이 반영되었다. 주요 기능들과 품질 집중 영역은 다음과 같다: C++ Clang 도구 체인 분할 에디터 (Split Editor) IDE (통합 개발 환경) Debugger (디버거) 안드로이드 타겟 API 레벨 34 VCL VA 델파이 컴파일러 기타 라이브러리들 차례 1. [12.1]에서 강화된 점을 제품 영역 별로 보기 1.1 C++ Clang 도구 체인 1.1.1 여러분이 할 수 있는 것은? 1.1. 2 제한 사항 (Limitations) 1.1.3 특별 참고 사항 (Special Notes) 1.1.3.1 가상 파일 시스템 (Virtual File System) 1.1.3.2 POSIX 및 기타 RTL 메서드들 1.1.3.3 C++ 표준 호환성 1.1.4 패키지와 라이브러리 1.2 분할 에디터(Split Editor) 1.2.1 분할 에디터 사용하기 1.2.2 디자이너와 코드 1.2.3 촛첨 추적하기 1.2.4 도킹(Docking)과 배치(Layouts) 1.3 IDE 향상 1.3.1 델파이LSP 코드 완성 1.4 디버거 1.5 안드로이드 타겟 API 레벨 34 1.6 품질 향상 1.6.1 VCL 1.6.2 C++용 Visual Assist 1.6.2.1 기타 라이브러리 1.7 기타 참고 (See Also) 1. [12.1]에서 강화된 점을 제품 영역 별로 보기 1.1 C++ Clang 도구 체인 RAD 스튜디오 12.1은 윈64용 Clang 도구 체인 업그레이드를 IDE 안에 통합했다. 새 도구 체인 전체가 IDE 안에 완전히 통합되어서 일반 플랫폼처럼 사용된다. 이 도구 체인에 포함된 것들로는 새 Clang 15 컴파일러, LLVM lld 링커, libc++ STL, UCRT C 런타임, 등등이 있다. 이 도구 체인은 기존 윈64 플랫폼과 함께 병행 제공된다. 윈 64용으로는 VCL과 FMX 지원, DLL, 정적 라이브러리, 콘솔 애플리케이션 등이 지원된다. IDE 안에서 Target Platforms를 오른쪽 클릭하고 Win64 (Modern)를 추가하면 된다. 1.1.1 여러분이 할 수 있는 것은? 이 도구 체인은 VCL과 FMX로 실제 애플리케이션을 만들도록 준비가 되어 있다. IDE는 완전하게 통합되었다. 올바른 옵션들을 컴파일러 드라이버와 링커에게 전달한다. 여러분은 특별한 우회 조치 또는 컴파일러 명령-줄 플래그(flag)들이 전혀 필요하지 않을 것이다. 알아둘 점: 동적 패키지 설정이 되어 있다고 해도, 여러분의 앱은 패키지를 정적으로 링크한다. 위 이미지는 파이어몽키로 만든 미로 앱(우리 깃허브에 있음)을 새 Clang 도구 체인으로 만든 것이다. 1.1. 2 제한 사항 (Limitations) 몇 가지 라이브러리들(예: SOAP)은 이 도구 체인 안에 들어 있지 않다. 이는 테스트 점검을 줄이기 위해서다. 즉 가장 많이 필요한 라이브러리들의 품질에 집중하기 위해서다. 사용할 수 있는 라이브러리들/패키지들에 대한 전체 목록은 아래와 같다. 패키지(예: VCL 등등)들은 여러분의 앱에 정적으로 링크된다. RAD 스튜디오 12.1에는 동적 패키지 소비(예: BPL 파일들을 EXE와 함께 배포하여 동적으로 연결하기)기능이 들어 있지 않다. 패키지의 내용물들은 EXE 안에 정적으로 링크된다. 이는 ‘Runtime packages’ 설정을 Project Options에서 어떻게 지정해도 마찬가지이다. 패키지를 C++로 생성하기. RAD 스튜디오 12.1이 지원하는 패키지는 현재 오직 델파이로 작성한 것들 뿐이다. 1.1.3 특별 참고 사항 (Special Notes) 1.1.3.1 가상 파일 시스템 (Virtual File System) IDE는 가상 파일 시스템 (Virtual File System, VFS)을 유지한다. 즉 여러분은 프로젝트 생성하기, 파일 생성하기, 기존 파일 변경하기, 그것들을 컴파일하고 실행하기 등을 디스크에 저장하지 않고 할 수 있다. 예전엔, 그렇게 하기 위해, 우리 도구 체인들은 모두가 컴파일러와 링커의 DLL 버전을 가지고 있어서 IDE VFS 안으로 낚아 챘다(hooking). 새 Clang 업그레이드에서는 Clang VFS 오버레이(overlay)를 사용한다. 임시 VFS 파일들은 컴파일 후에 제거되는 것이 기본 설정이다. 이 설정을 끄려면, Project Options > C++ Compiler > Advanced로 가서, Remove temporary VFS files after compilation 옵션을 끄면 된다. 1.1.3.2 POSIX 및 기타 RTL 메서드들 RAD 스튜디오는 표준 윈도우 RTL 메서드 세트를 완전하게 준수하지 않았었다. 그래서 많은 POSIX 버전과 사용자 정의 함수들을 제공했었다. 그것들 중 몇 가지가 빠졌을 수도 있다. 1.1.3.3 C++ 표준 호환성 RAD 스튜디오는 libc++ 15.0을 사용한다. C++ 언어 표준 규약을 아래 페이지에서 확인하자. C++14 C++17 C++20 (RAD가 지원하지 않음) C++23 (RAD가 지원하지 않음) 참고: 포맷 라이브러리에는 libc++ 16에서 도입한 지원이 있다. 따라서, RAD 스튜디오 12.1은 아직 이것을 지원하지 않는다. ( {fmt} 라이브러리는 테스트되지 않았지만, 잘 작동할 것이다.) 기타 항목들, 예를 들어, Parallelism TS, spaceship operator 등등이 libc++ 안에 있다. 하지만 아직 그 버전에 대한 도움말에는 반영되지 않았다. 1.1.4 패키지와 라이브러리 새 lld 링커는 ilink보다 현격하게 빠르다(약 4배 더 빠름). 더 큰 파일 크기를 쉽게 처리한다. 따라서 동적 링크를 (링크 시간이나 링커 메모리 때문에) 우회용으로 사용할 필요가 없다. 동적 패키지 소비는 아키텍처상의 이유로 중요하다. 그리고 RAD 스튜디오는 다음 릴리스에서 동적으로 링크되는 델파이 런타임 패키지 업그레이드를 계획하고 있다. 포함된 라이브러리들과 포함되지 않은 라이브러리들에 대한 목록을 패키지 설명서 페이지에서 찾아보자. 1.2 분할 에디터(Split Editor) RAD 스튜디오 12.1에서는, IDE에서 분할 에디터(Split Editor) 화면을 지원한다. 여러 에디터들을 나란히 그리고 위 아래에 놓고, 또는 섞어서 그 모든 화면을 같은 창 안에 배치할 수 있다. 또한, 모든 탭 세트들을 떠다니는 창 (floating window)으로 끌어 낼 수 있다, 또한 IDE 안으로 다시 끌어 넣을 수도 있다. RAD 스튜디오의 에디터 화면은 수준 높은 방식으로 구현되었다. 따라서 복잡한 사용자 정의 배치와 조작이 가능하다. 즉, 간단한 2열 배치, 여러 행 배치 또는 여러분의 작업 흐름에 딱 맞는 맞춤 배치를 할 수 있다. 여러 탭 모두가 똑같은 유닛을 열어 놓고 편집할 수 있다. 또는 한 탭에는 폼 디자이너를 열어 놓고, 그 유닛의 코드를 다른 여러 탭에서 열어 놓고 작업할 수도 있다. 어느 탭에서 디자이너를 보여줄 것인지를 서로 이동할 수도 있다. 분할 에디터의 갯수에는 제한이 없다. 가로든 세로든 마찬가지다. 1.2.1 분할 에디터 사용하기 분할 에디터에 접근하려면, 탭을 마우스 오른쪽 버튼으로 클릭하고 Split > 또는 Move >를 선택한다. Split은 선택한 탭의 다른 버전을 새로 생성한다. 반면, Move는 그 위치에 있는 탭을 닫고 여러분이 IDE 안에서 선택한 위치에서 그 탭을 연다. 분할 에디터를 사용하는 또 다른 방법은, Projects 창 안에 있는 파일을 아무 에디터 안으로 끌어 놓는 것이다. 그러면, 그 파일은 해당 탭 그룹 안에서 새 탭으로 열린다. 두 개의 탭이 하나의 창 안에 있으면, 두 세트 모두 각자의 제목 표시줄을 가진다. 다음을 수행할 수 있다: 에디터 탭 또는 에디터 탭 세트를 끌어서 IDE 창 안의 어느 측면이든 놓으면 그곳에 붙는다(docking). 끌어서 도킹하기는 이미 열려있는 다른 에디터의 측면(왼쪽, 오른쪽, 위쪽, 아래쪽)에서도 작동한다. 이미 열려있는 다른 탭 세트안에 탭을 병합하려면, 넣고 싶은 에디터의 중앙으로 끌어 놓으면 된다. (탭들을 담고 있는) 떠다니는 창도 끌어 넣을 수 있다. 끌어서 바깥에 놓으면, 자체 창이 된다(탭 하나 또는 탭 집합). 더 많은 동작들을 각 탭에서 할 수 있다. 예를 들어, 도킹되어 있는 탭 세트들 사이에서 이동하기를 하려면, 개별 탭을 한 위치에서 다른 위치로 끌어 옮기면 된다. 각 탭 세트를 끌어서 끄집어 내면, 자체 창이 된다. 제목 표시줄을 끌어서 이동시킨다. (드래그를 할 때는 Ctrl 키를 누른 채 끌고 가자. 그러면, 도킹을 시도하지 않으므로, 떠다닐 수 있다) 마찬가지로, 각 창을 다른 탭 세트 옆에 도킹할 수도 있다. 그러려면, 제목 표시줄을 드래그하면 된다. 참고: 대부분의 에디터들/그룹들은, 닫히면, 그냥 사라진다. 그러나, 최초의 에디터, 즉 메인 창의 유일한 에디터로 사용되는 창을 'X' 버튼으로 닫으면 포함된 모든 탭들이 닫힌다. 그럼에도 불구하고, 그 공간은 여전히 열려있다. 원본 에디터는 닫을 수 없다. 그리고 화면에는 항상 그 공간이 있다. 여러분이 탭 그룹을 닫을 때까지 이 공간은 아무 영향도 미치지 않는다. 일상적인 작업에서 이것을 생성, 이동 또는 도킹하는 동작이 끼치는 영향은 전혀 눈에 띄지 않는다. 1.2.2 디자이너와 코드 분할 에디터들를 서로 옆에 놓고, 동일한 파일의 내용을 열어서 편집할 수 있다. 두 에디터 모두 동일한 파일의 내용을 볼 수 있다. 에디터 하나 안에서 타이핑을 하면서, 다른 에디터에서 그 위치로 간다면 입력한 텍스트가 이미 들어 있을 것이다. 그런데, 두 화면 모두 스크롤이 독립적이다. 따라서 동일한 파일 안의 여러 위치들을 편집할 수 있다. 동일한 파일을 편집하는 탭의 갯수에는 제한이 없다. 참고: 명실할 점은. 단 하나의 파일(내부 용어로 모듈 또는 파일 버퍼)을 여러 에디터 화면에서 열었을 경우에, 한 에디터에서 변경한 사항은 언제나 그 파일을 보고 있는 다른 모든 에디터에도 반영된다는 점이다. 하나의 편집기에서 내용을 변경하면 '복사', '중복' 등과 같은 동작을 전혀 하지 않는다. 파일 하나는 그 내용도 하나다. 비록 여러 에디터에서 열고 편집하더라도 말이다. 달리 설명하자면, 한 에디터에서 파일을 편집할 때 해당 변경 사항은 파일 자체에 반영된다. 그 에디터에만 반영되는 것이 아니다. 정의하자면, 동일한 파일을 열고 있는 다른 에디터들 안에도 언제나 변경 사항이 들어간다. 1.2.3 촛첨 추적하기 RAD 스튜디오에서 UI 디자인의 핵심 원칙은 초점을 명확하게 하는 것이다. RAD 스튜디오 12.1 이전 버전에서는, 현재 초점이 맞춰진 창은 강한 파란색이었다. 한쪽에 도킹된 창이든 (그때 당시에는 하나만 있었으므로 단일) 에디터 탭이든 관계없이 그랬다. 그와 동일한 기술이 적용된다. 그런데, 이제는 여러 에디터가 있으므로, 탭 그룹의 제목 표시줄과 해당 특정 탭이 진한 파란색으로 표시된다. 이로 인해 정말, 정말 명확하게 알 수 있게 된다. 촛점이 없는 에디터를 가진 각 에디터 그룹들은 제목 표시줄의 '배경' 색상이 창백하다. 심지어 그 그룹에서 맨 위에 있는 탭(해당 그룹이 촛점을 받은 경우 실제로 촛점을 가지게 되는 탭)조차도 회색으로 표시된다. 따라서 촛점이 없음을 알 수 있다. 1.2.4 도킹(Docking)과 배치(Layouts) 12.1부터는, RAD 스튜디오를 사용하면 Object Inspector와 같은 창들을 원하는 곳 어디든 이동하고 도킹할 수 있다. 실제 사용시, 도킹 가능한 창(Object Inspector, Structure view 등등)과 도킹 가능한 에디터/에디터 그룹 사이에 차이가 거의 없다. 따라서 필요에 맞게 강력한 배치를 구성할 수 있다. 데스크탑 레이아웃은 열려 있는 에디터(및 에디터 그룹, 해당 위치, 도킹된 위치 등)들과 예전 방식에서도 도킹 가능했던 창들이 함께 배치되는 세트이다. 여러 개의 창을 가질 수 있으며, 각 창마다 여러 개의 탭이 들어 있을 수 있다. 에디터를 구성했다면, 데스크탑 레이아웃으로 저장해야 한다. 그렇지 않으면 쉽게 잃게 된다. 또한, 그 구성은 해당 데스크톱 레이아웃이 변경되는 경우 바뀐다. 예를 들어, IDE가 디버깅을 시작하면, 디버그 레이아웃으로 전환되고, 그러면 디버그 레이아웃 구성이 적용된다. 레이아웃이 바뀔 때, 새로 전환되는 레이아웃 안에는 해당 위치가 없는 모든 탭 그룹(개별 탭도 마찬가지로, 별도로 도킹되어 있는 한)이라면 도킹이 해제되어 떠다니는 창이 된다. 1.3 IDE 향상 1.3.1 델파이LSP 코드 완성 RAD 스튜디오 12.0에서 코드 완성 기능이 추가되었었다. 즉, 타이핑할 때 자동으로 코드 완성 팝업이 나타나게 할 수 있다. 이 DelphiLSP 이전 기능은 도움이 되는 제안들을 목록으로 제공했다. 이전처럼 점을 찍어야만 즉 수작업으로만 불러낼 수 있는게 더 이상 아니다. 그러나, 타이핑할 때 이것이 자동으로 나타나면, 특정 항목을 타이핑하기가 어려운 경우들도 종종 있다. 예를 들어, 새 변수 이름은 (알려져 있지 않은 식별자이므로) 자동으로 제안되지 못한다. 코드 완성 기능에서는 여러분이 스페이스(Space) 키를 눌렀을 때 제안 목록의 맨 위에 있는 항목이 수락되었다. 그러므로, 여러분이 작성 중인 내용은 무시되었다. RAD Studio 버전 12.1에서는 그 기능성을 보다 향상했다. 이제는 auto-invoke 기능은 On으로 되어있고, 코드 완성을 자동으로 불러낼 때는, 여러분이 현재 선택된 자동 완성을 수락하려면, 오직 Tab과 Enter 키를 사용해야 한다. 다른 키 즉 스페이스(Space), 여는 중괄호, 점 등과 같은 다른 키는 효과가 없다. 즉, 코드 완성을 자동으로 불러낼 때는, 여러분이 반드시 완성을 수락하겠다고 선택해야 한다는 의미다. 이제 무언가를 실수로 자동 완성하는 일은 없을 것이다. 코드 완성을 일반 방식으로 불러낼 때는, 위 키들을 사용하여 제안된 내용을 수락할 수 있다. 이는 11.3 및 이전 버전에서와 마찬가지다. 다시 말하자면, 이 동작은 이전의 모든 일반 방식의 코드 완성에서 전혀 바뀐 것이 없다. 해당 auto-invoke 기능은 Off가 기본 설정이다. 이 기능을 켜고, 새 완성 키 탭들에 대해 더 알아보려면 Code Insight 설명서를 참고하자. 1.4 디버거 버전 12.1에서, 델파이 윈32, 델파이 윈64, C++ 윈32만 제외하고, 모든 디버거들이 LLDB 15를 사용한다. 이는 Clang 업그레이드에서 사용되는 것과 동일한 디버거이다. 이전 버전에서는 LLDB 12를 이 플랫폼들에 사용했지만, 이제는 업그레이드되었다. 1.5 안드로이드 타겟 API 레벨 34 RAD Studio 버전 12.1은 Android API 레벨을 34로 업데이트한다. 이 변경을 위해 안드로이드 SDK 도구 사용 변경이 필요했으며, 몇 가지 추가 안드로이드 플랫폼 도구들이 필요했고, Java 런타임 업데이트도 필요했다. 자세한 내용은 다음과 같다: 12.1 버전은 플랫폼 기능들 중에서 설치된다. 그리고 Eclipse Temurin JDK OpenJDK 17(핫스팟) JVM을 권장한다. 12.1 버전에서는 명령-줄 도구 Android SDK 컴포넌트들이 우리의 기본 Android SDK 설치에서 나와서 업데이트되었다. 기본 targetSdkVersion 매니페스트 애트리뷰트(attribute)는 이제 34이다. RAD Studio 12.1은 .apk 파일 생성 시 성능이 눈에 띄게 향상되었다. 왜냐하면 12.1은 Google의 zipflinger 라이브러리와 signflinger 라이브러리를 패키징을 하는 명령-줄 도구 안에서 활용하기 때문이다. Android 패키징의 개선 사항은 다음과 같다: Android DEX 작업 (DEX 컴파일 및 DEX 병합)은 이제 증분식이다 (이제 이 작업은 오직 입력 파일이 해당 출력 파일과 관련하여 오래된 것으로 간주되는 경우에만 시작된다). 12.1 버전에서는 빌드 시스템이 이전되었다. 전에는 오래되고 단종된 Google의 AAPT 명령-줄 도구를 사용했지만, 이제는 Google의 새 도구인 AAPT2를 사용한다. Google의 AAPT2 명령-줄은 이제 각 Android 리소스 파일을 컴파일하고 그것들을 모아서 하나의 .zip 파일 안에 패키징을 한다. 그 패키지 안에는 해당 매니페스트 파일과 Android 리소스 테이블도 들어 간다. 새 Packager 명령-줄 도구는 패키지되는 리소스 파일, 네이티브 라이브러리, 자산 파일 및 .dex 파일을 최종 .apk 또는 기본 모듈 파일 안에 넣는다. 1.6 품질 향상 1.6.1 VCL VCL TEdit은 이제 윈도우 최신 버전에 있는 쉬운 접근성(Ease of Access)의 텍스트 커서(Text Cursor)에서 올바르게 작동한다. 이 방식에 따라, 우리는 IDE에 대한 접근성을 다시 살려 놓았다. 예전에는 위 이슈 때문에 비활성화가 기본 설정이었다. JAWS를 IDE에서 기본 설정으로 (다시) 잘 사용할 수 있다. NumberBox가 개선되었다. 음수 값을 사용할 수 있다. ProgressBar State는 이제 VCL 스타일 하에서 지원된다. 1.6.2 C++용 Visual Assist 파일을 저장하지 않고 닫는 경우, VA에 캐시가 남아 있는 문제가 해결되었다. 이름바꾸기는 이제 이벤트 핸들러의 이름도 변경한다. 컴포넌트의 이름을 바꾸면, 디자이너 안에서도 그 이름이 바뀐다. 이는 12.0에서 빠뜨렸던 기능이다. 오브젝트의 프로퍼티에 대한 코드 완성은 이제 올바르게 작동한다. 코드 완성 결과로 인해 예상치 못한 값이 표시되는 경우가 더 이상 없다. 코드 완성이 발동하지 않는 이슈가 해소되었다. VA가 써드 파티 라이브러리에서 작동하지 않는 이슈가 해소되었다. #include 전처리기 지시문 자동 완성을 < 및 ""로 사용할 때 이제는 올바르게 작동한다. 사소한 UI 향상들이 메뉴에 반영되었다. 1.6.2.1 기타 라이브러리 RAD Studio 12.1에서는 데이터베이스 부문에 다음과 같은 개선 사항들이 도입되었다: TIBDataSet 에디터(IBX)가 개선됨. FireDAC 지원에 Firebird 버전 5가 추가됨.여기에는 Firebird 5용 TFDFBBackup 안에서 병렬 작업이 되도록 하는 지원이 포함됨. FireDAC 지원에 PostgreSQL 버전 16이 추가됨. 최신 버전인 IBToGo 및 IBLite(InterBase 2020 업데이트 5에 맞춰짐)는 이제 안드로이드에서 작동한다. 파이어몽키의 12.1에는 다음이 포함되었다: 맥OS에서 불투명 형식으로 저장된 투명 비트맵은 Windows에서처럼 동작한다(즉, 투명 색상이 검은색으로 변한다). 인터넷 부문에서, 12.1에는 다음이 포함되었다: TRestClient는 현재 사용자 목록뿐만 아니라 로컬 컴퓨터 목록의 인증서 사용을 지원한다. 웹 16진수 색상 구문을 StringToColor 함수에서 지원한다. REST 디버거가 테이블 셀에서 값을 복사하는 기능. RAD 서버 사용자의 사용자 이름을 변경하는 기능. 1.7 기타 참고 (See Also) Installation Notes Release Notes New features and fixed issues 과거 버전들의 새 기능 모아 보기(영문)
  7. Kyle Wheeler의 "From Enhanced Training to Cutting-Edge Tooling: Embarcadero’s Commitment to Elevating Your Development Experience" 을 번역했습니다. (원문 작성: 2024년 3월, 최종 번역: 2024년 3월) 많은 분들이 알고 있듯이, 2024년 엠바카데로에서는 많은 일들이 벌어지고 있다. 그리고 여러분을 위한 것들은 사실 훨씬 더 많다. 우리는 3년 만에 가장 큰 릴리스 중 하나를 출시했으며, 교육과 도구 둘 다 더욱 강화했다. 또한 열정적인 커뮤니티는 계속 성장하고 있다. 여기 RAD 12가 있다! 더 많은 것들이 올 것이다! 우리 개발팀의 훌륭한 작업을 통해 제공된 RAD 스튜디오 12 그리고 곧 나올 12.1 릴리스를 보면, 지금이야말로 라이선스를 업그레이드, 구매 또는 갱신하기에 가장 좋은 시기라고 말하고 싶다! 그 성과와 노력들에 대해 나는 너무나 자랑스럽게 생각한다. 우리 커뮤니티가 기대하는 수준의 안정성과 신뢰성을 보장하는 동시에 미래를 향해 나아가고 있기 때문이다. 이처럼 우리의 제품 관리 팀은 기대의 균형을 맞추고 실제로 전달하는 역할을 훌륭히 해 왔다! 커뮤니티 강화 우리는 지난 몇 번의 개발 주기에 걸치면서, 우리가 작업 중인 내용을 더욱 투명하게 공개하려고 노력했다. 그리고, 많은 사람들이 언급했듯이 그 반응은 좋았다. 또한, 우리는 커뮤니티가 보다 더 함께 할 수 있도록 새로운 방식을 통해 열심히 노력해 왔다. 늘 그랬듯이, 우리의 도구가 얼마나 멋진지 보여 주는 것을 계속해오면서도, 다른 한편으로, 그 도구를 사용하여 어떻게 실제로 여러분의 제품을 더욱 발전시키는지에 대한 방법들을 보여주기 위해 노력했다. 이러한 노력 중에는 교육 콘텐츠 추진도 해당된다. 이는 주로 Developer Advocate인 Ian이 주도했다. 여러분은 이미 Ian을 만나거나 그의 활동들을 들어본 적이 있을 것이다. 웨비나 일정이 빠르게 채워지고 있다. 우리 팀으로부터 직접 의견을 들을 수 있는 여러 기회들에 많은 분들이 참여할 수 있기를 바란다. 이런 웨비나에서 좋았던 점으로는 통로 양쪽의 솔직함과 우리가 받은 피드백을 꼽을 수 있다. RAD 스튜디오가 가야 할 길에 대한 우리의 통찰력을 높이기 위해, 우리는 올해 초 설문 조사를 보냈고 많은 의견을 받았다. 많은 피드백을 수집하면서 그것들을 실행으로 옮기는 한편, 특히 우리의 C++ 사용자들 그리고 바깥의 더 큰 C++ 커뮤니티로부터 의견을 듣고자 했다. 그래서 지금 새 설문조사가 진행 중이다! 우리는 이 피드백을 우리의 제품 계획에 반영할 수 있기를 기대한다. 모바일 개발을 위한 새 기능들 소비자들이 마주하는 대다수의 앱들에서는, 모바일이 차이를 만든다. 여러분이 우리의 IDE 중 하나를 손에 쥐게 되면, 여러분이 그 IDE의 장점들을 즉시 사용할 수 있기를 진심으로 바란다. 우리의 IDE의 가장 큰 장점은 모든 플랫폼에서 보기 좋고 훌륭하게 작동하는 앱을 구축하는 것이다. 바로 그런 이유로, 델파이 및 RAD 스튜디오의 엔터프라이즈 또는 프로페셔널을 구입할 때 마다, 여러분에게 무료로 자기 주도형 종합 모바일 개발 교육 과정을 제공하여, 여러분의 모바일 개발 게임이 향상될 수 있도록 하는 점에 대해 기쁘게 생각한다! 그러다 보니, 나는 다시 RAD 스튜디오 Studio 12.1을 돌아보며 사용자의 요구 사항들이 충족하기 위한 작업들이 어떻게 진행되고 있는지를 돌아보게 되었다. 12.0에서 출시되고 미리 보여주었더 기반 기능들 중 몇 가지들은 이제 12.1에서 구현될 예정이다. 그 점에 대해 우리가 거는 기대는 매우 크다. 현재 메인트넌스 플랜을 유지 중인 사용자를 위한 베타 프로그램이 진행되고 있다. 잘 활용해 보길 바란다. 초대장을 아직 받지 못했다면, 고객 담당자에게 자세한 내용을 문의하면 된다. 신규 사용자라면, 구매할 때마다 신나는 교육 기회가 제공되고 있고, 최신 베타 빌드에 바로 액세스할 수 있는 프로모션이 진행 중이니 잘 살펴보기 바란다. RAD 스튜디오 아키텍트의 새 기능 현대식 아키텍처는 현대식 도구가 필요하다. 그 중 일부는 RAD 스튜디오 12에서 제공하고 있다. 그 밖에도, 여러분의 개발 워크플로 및 도구로는 IDE 자체 이상의 구성 요소들 여러 가지가 필요하다는 점을 우리는 잘 알고 있다. 우리는 자매 회사인 YellowFin과 협력하여 아키텍트 에디션 고객에게 동급 최고의 BI 도구를 제공하게 되었음을 발표하게 되어 기쁘게 생각한다. 지금은 새 라이선스를 구매하는 고객들에게만 특별히 제공되고 있지만, 앞으로 몇 달 안에 기존 고객에게도 이를 제공할 수 있는 방법을 모색 중이다. 이에 대한 자세한 내용과 진행 중인 모든 프로모션을 알아보려면 여기를 클릭하기 바란다.
  8. Jim McKeeth의 "CamSextant – Cool Apps Selection" 을 번역했습니다. (원문 작성: 2020년 4월, 최종 번역: 2024년 3월) 오늘 Cool Apps로 선정된 앱은 CamSextant다 (제작: Omar Reis). CamSextant는 천체의 물체들을 실시간으로 식별하고 추적할 때 사용하는 애플리케이션이다. 이 Cool Apps 시리즈 중에, 증강 현실 애플리케이션을 소개하는 것은 처음이다. 그래서 매우 기쁘다. CamSextant는 델파이로 개발되었다. 엠바카데로의 파이어몽키 멀티-디바이스 도구들을 사용하여 여러가지 멋진 기능들을 구현했으니 살펴 보자. 아래 비디오에서 볼 수 있듯이, CamSextant는 증강 현실 오버레이를 사용해 물체들을 식별하고 추적한다. 호스트 장치의 다양한 기능들(GPS, 자력계, 가속도계 등)을 사용하여 동작하는데, Omar는 이것을 '센서 퓨전(sensor fusion)'이라고 부른다. 자세한 내용은 아래 링크들에 있다. CamSextant는 물체들을 추적할 뿐아니라, 물체들의 이름을 알 수 있으며, 그 위치를 계산한다. 게다가, 사용자는 물체들의 위치를 추적하고 저장할 수도 있다. 비디오 보기: (옮긴이: 현재 이 비디오는 해당 서버 이전으로 인해 보이지 않으므로 생략함) 아래 링크를 통해 Omar가 CamSextant에 사용한 라이브러리들에 대해 더 많은 것들을 알 수 있다. 또한 이른바 크로스 플랫폼 '센서 퓨전(sensor fusion)'에 대한 설명 및 데모도 제공된다. 그가 만든 것은 정말 특별하다. 시간을 들여 확인해 볼 가치가 있다. CamSextant는 안드로이드와 iOS 플랫폼에서 무료로 사용할 수 있다. 이 링크들을 클릭하면 된다. 이번 엠바카데로 멋진 앱으로 선정된 Omar Reis와 CamSextant에게 다시 한번 감사한다. CamSextant 이면에 있는 도구들에 대해 더 알아보려면: 깃허브 저장소 CamSextant을 받으려면: 구글 플레이 스토어 iOS 앱스토어 더 많은 사례 보기: Cool Apps 사례 모아 보기 2023 기업용 개발 사례 모아 보기 모든 사례 보기
  9. Jim McKeeth의 "Aircraft Tracking Dashboard – Cool Apps Selection" 을 번역했습니다. (원문 작성: 2020년 5월, 최종 번역: 2024년 3월) Cool Apps 어워드는 일반 소비자 애플리케이션 뿐만 아니라, 델파이를 이용해 정말 멋진 일을 한 사람에게도 수여된다. 오늘 선정된 사례가 여기에 해당된다 오늘은 열기구 기반 항공기 추적기를 소개한다. 제작자는 David Akerman의이다. David는 ADS-B 응답기 신호를 추적하겠다는 아이디어를 가지고 있었다. 이 신호는 항공기들이 자신들의 위치를 전송하는 데 사용한다. 그는 한 단계 더 나아가 ADS-B 수신기를 고고도 기구(high-altitude balloon, HAB)에 부착했다. 그는, "수신기가 지방 지리 상공에서 얼마나 더 멀리 '볼 수' 있는지, 그리고 지구의 곡률의 영향을 덜 받는 고도에서는 얼마나 향상되는 지 확인하는 것은 흥미로울 것이다" 라고 말했다. 이 로우(raw) 위치 데이터를 갖추게 되자, David는 웹 애플리케이션을 델파이로 만들었다. 그 앱은 그 데이터들을 해석하고, 기구(balloon)들의 위치와 다양한 항공기들의 위치를 구글 맵 위에 시각화했다. 아래 동영상과 위 이미지에서 볼 수 있듯이, 그 애플리케이션은 멋지다. 그리고 해당 데이터를 실시간으로 명확하게 표시한다. 게다가 그 탁월한 범위는 인상적이다. 비디오 보기: (옮긴이: 현재 이 비디오는 해당 서버 이전으로 인해 보이지 않으므로 생략함) David는 자신이 사용한 방법들과 개발 절차를 자신의 웹사이트에 설명해 놓았다. 나는 델파이가 이런 프로젝트에 참여하는 것이 아주 멋진 일이라고 생각한다. David의 애플리케이션은 나에게 정말로 깊은 인상을 주었다. 오늘의 멋진 앱으로 선정된 David Akerman과 그의 기구 기반 항공기 추적기(Balloon-Based Aircraft Tracker)를 살펴보고 큰 박수를 보내주길 바란다. David의 작업에 대해 더 알아보려면: 웹사이트 더 많은 사례 보기: Cool Apps 사례 모아 보기 2023 기업용 개발 사례 모아 보기 모든 사례 보기
  10. Jim McKeeth의 "CEF32 Emulator Framework – Cool Apps Selection" 을 번역했습니다. (원문 작성: 2020년 4월, 최종 번역: 2024년 3월) 오늘 Cool Apps로 선정된 앱은 CEF32 에뮬레이터 프레임워크다 (제작: Alan Conroy). CEF32는 사용자가 하드웨어 구성을 에뮬레이트하고 자신만의 에뮬레이터를 만들 수 있는 프레임워크다. 델파이와 VCL은 이 프레임워크 개발에서 중요한 역할을 했다. Alan은 애플리케이션을 훌륭하게 만들어냈다. Alan은 세 가지 목표를 가지고 CEF32를 만들었다. 1) 에뮬레이션의 정확성과 현대식 하드웨어가 에뮬레이션을 구동하는 속도 사이에서 적절한 균형을 유지할 것. 2) 에뮬레이터를 위한 기본 사용자 인터페이스가 일관적일 것. 3) 에뮬레이터 개발이 빠르고 쉽도록 할 것. 그러기 위해, 일반적으로 사용할 수 있는 컴포넌트들가 유틸리티들을 제공할 것. CEF32는 플러그인 아키텍처를 사용한다. 따라서, 컴포넌트들을 골라서 맞추는 방식을 통해 엄청나게 다양한 구성을 만들어낼 수 있다. 포함되어 있는 컴포넌트들이 매우 풍부하다는 점이 인상적이다. 그래서 여러분은 자신만의 에뮬레이터를 아주 사용자 친화적으로 만들 수 있다. 델파이가 2020년에 25주년을 기념하는 중이라서, 델파이의 과거를 살짝 보여주는 듯한 앱을 찾아보는 것도 멋진 일이었다. CEF32은 멋진 유틸리티로써 델파이의 과거를 기리면서도 현대의 델파이 또한 담고 있다. 아래 링크를 통해 다운로드 받고 지금 바로 사용해 보자! Alan Conroy와 CEF32 에뮬레이터 프레임워크에게 엠바카데로의 Cool Apps로 선정된 것에 대해 다시 한번 축하한다. CEF32에 대해 더 알아보려면: 웹사이트 다음에 소개될 Cool Apps 앱: Marc Hoffmann의 ExBox라는 앱이다. 이 앱을 사용하면 여러분의 프로젝트를 최대한 활용할 수 있게 될 것이다. 더 많은 사례 보기: Cool Apps 사례 모아 보기 2023 기업용 개발 사례 모아 보기 모든 사례 보기
  11. Jim McKeeth의 "How to View Digits of Pi in Real-Time with Delphi for Pi Day 2024" 을 번역했습니다. (원문 작성: 2024년 3월, 최종 번역: 2024년 3월) 다음은 Embarcadero MVP이자 GDK 소프트웨어 미국 이사인 Jim McKeeth가 게시한 글이다. π 데이는 2024년에도 어김없이 돌아왔다 (옮긴이: 3월 14일은 π데이로 기념하기도 하고 아인슈타인 생일로도 기억하는데 이런 관점들이 유독 우리나라에서는 화이트 데이에 가려진 현실이 한편 안타깝기도 합니다). 나는 델파이 방식을 축하하기 위해, Rudy의 Big Numbers 라이브러리를 사용하여 만들었던 이전 샘플을 다시 열어서, π 숫자가 생성되는 동안 실시간으로 볼 수 있는 기능을 추가했다. 이전에는 어떤 자리수를 지정하든 그 만큼 생성해냈다. 하지만, 그 결과는 작업이 모두 완료된 후에 한꺼번에 표시되었었다. 차례 Rudy의 Big Numbers 라이브러리란? Pi를 델파이로 생성하는 방법은? 실시간으로, Pi의 십진수 값을 보자 Bailey-Borwein-Plouffe Pi Code를 델파이 안에서 이 멋진 Vaporwave Athena Pi Day 배경 이미지를 어디에서 얻을 수 있는가 ? Rudy의 Big Numbers 라이브러리란? 이 라이브러리는 작고한 Rudy Velthuis가 원작자이다. 이 라이브러리는 델파이가 Big Integer, Big Decimal, and Big Rational 숫자를 지원할 수 있도록 추가한다. 얼마나 큰 수를? 글쎄, 여러분이 얼마나 큰 메모리를 가지고 있는냐에 달려있다. 최대값에 대한 한계는 실제로 없다. 이 라이브러리는 매우 사용하기 쉽고, 성능은 놀라울 정도로 좋다. 매우 다양한 샘플, 데모, 유닛 테스트들이 있다. BigRational 타입은 실험 중이라고 표시되어 있으며, BigInteger들은 BigDecimal들보다 성능이 더 좋은 경향이 있다. Pi를 델파이로 생성하는 방법은? 작년에 나는 이 샘플을 작성하여 델파이를 가지고 Pi를 계산했었다. 그 샘플은 Chudnovsky 알고리즘과 Bailey Borwein Plouffe (BBP) 알고리즘 둘 다를 지원한다. BBP는 더 빠르며, 숫자를 순차적으로 생성해내는 일종의 꼭지이다. 그래서 나는 이 알고리즘에 콜백을 추가하는 것이 더 합리적이라고 생각했다. 이 콜백은 한번에 숫자 64 개를 반환한다. 하지만, 그 덩어리 크기는 여러분이 쉽게 바꿀 수 있다. 실시간으로, Pi의 십진수 값을 보자 Pi의 숫자 표시를 보면서 나는 묘하기도 하고 흥미롭다고 느꼈다. 현재는 콘솔 앱에서만 콜백 기능을 지원하고 있다. 하지만, 앞으로 파이어몽키 앱도 마찬가지로 업데이트할 예정이다. Bailey-Borwein-Plouffe Pi Code를 델파이 안에서 이 업데이트된 코드 (이 콜백 함수가 담겨 있음)는 다음과 같다. function BBPpi(Places: UInt64; CallBack: TChunkCallback = nil): TDigits; // Bailey-Borwein-Plouffe begin SetLength(Result, Places); var idx: Uint64 := 0; var q := BigInteger.One; var r := BigInteger.Zero; var t := BigInteger.One; var k := BigInteger.One; var n := BigInteger.Create(3); var l := BigInteger.Create(3); var buffer: TDigits; SetLength(buffer, CallbackChunkSize); var bufferIdx: Integer := 0; while true do begin if 4*q+r-t < n*t then begin result[idx] := n.AsInt64; // 딱 1 바이트(byte)임 inc(idx); if Assigned(Callback) then begin buffer[bufferIdx] := n.AsInt64; inc(bufferIdx); // 버퍼가 가득 찼는지 확인한다. 그렇다면, 콜백을 호출하고 bufferIdx를 리셋한다 if bufferIdx = CallbackChunkSize then begin Callback(buffer); // 버퍼를 사용해 콜백한다 bufferIdx := 0; // 버퍼 인덱스를 리셋한다 end; end; if idx >= places then break; var newR := 10 * (r - n * t); n := (10 * (3 * q + r)) div t - 10 * n; q := q * 10; r := newR; end else begin var newR := (2 * q + r) * l; var newN := (q * (7 * k)+2+(r * l)) div (t * l); q := q * k; t := t * l; l := l + 2; k := k + 1; n := newN; r := newR; end; end; // 남아 있는 버퍼를 다루기 if (bufferIdx > 0) and Assigned(CallBack) then begin SetLength(buffer, bufferIdx); // 버퍼의 크기를 실제로 사용되는 크기에 맞춘다. 콜백 전에 수행함. CallBack(buffer); end; end; 여기 이 아래에 있는 예시는 위 코드를 호출한다. 그리고 나서 그 결과 숫자들을 한번에 하나씩 콘솔에 출력한다. var firstChunk: Boolean = True; procedure WritelnCallBack(Chunk: TDigits); begin var digits: String; if firstChunk then begin digits := DigitsToString(Chunk).Insert(1,'.'); firstChunk := False; end else digits := DigitsToString(Chunk); // 시연을 하기 위해서는 출력 속도를 늦춰라 for var i := low(digits) to High(digits) do begin Write(digits[i]); sleep(100); end; end; const Places = 10000; begin BBPpi(Places, WritelnCallBack); Writeln; end. 현재, 위 코드는 익명 메서드 참조를 하나 사용하고 있다. 이것이 오버헤드가 조금 생긴다는 점을 나도 알고 있다 하지만, 그것으로 인해 얼마나 차이가 생기는지를 비교하지는 않았으며 그 콜백 타입을 변경할 필요가 있는지에 대해서도 크게 생각하지 않는다. 속도를 약간 늦춰야 한다고 생각했는데, 이 프로그램의 목적은 숫자를 보는 것이기 때문이다. 또한 유닛 테스트를 하나 추가했다. 콜백으로부터 나오는 출력이 함수 호출의 결과와 일치하는지 확인하기 위해서이다. Delphi/Pascal procedure BBPpiTest.CompareCallbackToResult; begin var CallBackString := ''; var CallBackStringBuilder: TChunkCallBack := procedure(Chunk: TDigits) begin CallBackString := CallBackString + DigitsToString(Chunk); end; var calcPi := DigitsToString(BBPpi(100, CallBackStringBuilder)); Assert.AreEqual(calcPi, CallBackString); end; 이 멋진 Vaporwave Athena Pi Day 배경 이미지를 어디에서 얻을 수 있는가 ? 좋은 질문이다! 나는 이것은 4K까지 키웠다. 그리고 변형 버전들도 몇 가지있다... 이 예시들 중 몇 가지를 직접 해보고 싶은가? RAD 스튜디오 최신 버전의 무료 평가판을 다운로드 할 수 있다. (이 기고는 엠바카데로 MVP가 작성했음)
  12. Jim McKeeth의 "Sylt App für den Urlaub (App for Vacation) – Cool Apps Selection" 을 번역했습니다. (원문 작성: 2019년 12월, 최종 번역: 2024년 3월) 오늘 Cool Apps로 선정된 앱은 Sylt App für den Urlaub(휴가를 위한 Sylt 앱)이다 (제작: Rolf Eschenbach). Sylt 앱은 휴가 정보에 대한 원스톱 리소스다. 유용한 도구와 정보로 가득 차 있다. Sylt App für den Urlaub은 FireDAC과 FMX 컴포넌트를 사용해 델파이로 개발되었다. 안드로이드와 iOS 플랫폼에서 사용 가능하다. Rolf는 오랜 시간 델파이의 개발자이자 교육자로 활동해왔다. 그는 수상 스포츠를 상당히 좋아한다. 그는 하나의 앱에서 바람, 날씨, 여행 정보를 확인할 수 있도록 이 앱을 개발했다. 여행 다이어리, 체크리스트, 환율 계산기, 바람 차트, 일기 예보, 현재 날씨 정보 등을 모두 하나의 앱에서 확인 할 수 있다. Sylt App für den Urlaub은 현재 유럽의 40여개 지역의 현지 정보들이 들어 있다. Sylt App für den Urlaub은 안드로이드에서 무료로 다운로드 가능하며, iOS에서 다운로드 할 때는 소액의 비용이 청구된다. 둘 다 독일어를 기본 언어로 채택한 앱이다. 이 앱은 실제로 동작하는 델파이의 멋진 예제다. 내가 직접 사용해 보고싶은 멋진 기능들이 정말 많다. 이번 엠바카데로의 멋진 앱 선정작으로 Sylt App für den Urlaub를 소개할 수 있어 기쁘다. 여러분 모두 다음 유럽 여행에서 이 앱을 다운로드하여 사용해 보길 바란다. Sylt App für den Urlaub 찾아보기 구글 플레이 스토어 애플 스토어 웹사이트
  13. 마크로 칸투의 수상 연설 전문에서는, 파스칼의 40년 역사와 델파이의 역사를 당시 상황과 함께 매우 재미있게 읽을 수 있습니다. 수상 연설 전문을 번역한 글 링크:
  14. 이안 바커 (Ian Barker)의 "New GetIt Web Portal" 을 번역했습니다. (원문 작성: 2023년 6월, 최종 번역: 2024년 3월) 스페인 살라망카 대학에서 주최하는 국제 파스칼 학회(The International Pascal Congress)에서 Marco Cantú가 자랑스럽게도 니클라우스 비르트상(Niklaus Wirth Award)을 수상하게 되었다. 심사위원단의 상장에는 "Marco Cantú는 파스칼 커뮤니티에서 가장 뛰어나고 참신한 저명한 인물이다."라는 문장으로 마무리되었다. 이 보다 더 나은 표현은 없는 것 같다. 국제 파스칼 학회(International Pascal Congress)의 공식 발표 엠바카데로에서 일하면서 매우 좋은 점 중 하나는 멋진 사람들을 많이 만날 수 있다는 점이다. 모두 놀라울 정도로 똑똑하고, 자신의 분야에 재능이 있고, 제품에, 특히 델파이, 오브젝트 파스칼에 대한 열정을 가진 사람들이다. 우리 델파이 개발자들은 Marco가 파스칼 언어의 가장 강력한 옹호자임을 이미 모두가 알고 있다. 그는 엠바카데로에 합류하기 훨씬 전부터 커뮤니티에서 빛나는 존재였다. 그에게 많은 것을 배운 사람이 나 혼자만은 아닐 것이다. 델파이와 오브젝트 파스칼에 관한 Marco의 저서는 사실상 이 언어에 대한 참고서이다. 다른 팀원들과 RAD 스튜디오의 관리를 책임지고 있는 그는 오브젝트 파스칼 언어 자체와 IDE를 지속적으로 혁신하고 발전시키고 있다. 우리 대부분이 하루 종일 몰입하여 오브젝트와 클래스로 필수 앱을 만들고, 누군가의 최고로 애정하는 게임을 만들거나, 발전소를 컴퓨터를 통해 연결하여 구성할 수 있는 것은 이 덕분이다. 이런 반응을 보이는 것은 나뿐만이 아니다. Marco의 수상 소식을 접한 다른 사람들의 반응을 살펴보자. "델파이와 파스칼은 최근 몇 년간 기술 부흥기를 맞이했다. Marco가 파스칼 언어를 훌륭하게 관리해온 덕이다. 그는 수년 동안 파스칼 커뮤니티의 일원으로 활동해 왔다. 나도 그가 그 공로를 인정받게 된 것을 기쁘게 생각한다". – David Millington. 다시 한번, 엠바카데로의 모든 직원이 Marco에게 진심 어린 축하를 전한다. 마지막으로 그의 소감을 들어 보자.
  15. 마르코 칸투 (Marco Cantu) 블로그에 게시된 "Niklaus Wirth Prize Acceptance Speech: A Personal View of the History of Pascal and Delphi" 을 번역했습니다. (원문 작성: 2023년 7월, 최종 번역: 2024년 3월) 이 블로그 글은 살라망카에서 개최된 국제 파스칼 학회(International Pascal Congress)에서 내가 했던 연설의 내용이다. 하지만, 나의 지극히 개인적인 관점에서 파스칼의 역사에 대해 본 나의 소회다. 연설을 시작하기 전에 이 이벤트를 위해 만들기 위해 수고를 아끼지 않은 국제 파스칼 학회 조직 위원회, 특히 Sergio에게 감사를 전한다. 그리고 내가 매우 뜻깊은 상을 받을 수 있도록 심사해 준 심사 위원단에게 감사의 말을 전하고 싶다. 수상 소감에 쓴 바와 같이, "니클라우스 비르트 상을 수상하게 되어 매우 기쁘게 생각한다. 내가 니클라우스 비르트 박사를 매우 존경하기 때문이기도 하고, 또 한편으로, 30년 이상 파스칼 언어 및 파스칼 개발자 커뮤니티와 함께 해왔기 때문이기도 하다. 내가 해 온 일들을 인정해 준 협회에 감사드린다. 그 동안 나는 저자, 컨퍼런스 연사로 활동했으며, 최근에는 파스칼 기반 컴파일러이자 IDE로서 가장 널리 사용되는 델파이의 제품 매니저로서 활동하고 있다. 이 상은 내 개인적인 업적을 인정받는 상인 동시에, 오랜 기간 나와 함께 일하고 협력한 많은 사람들의 업적에 대한 인정이라고 생각한다. 파스칼과 델파이에 열정을 가진 많은 사람들에게 감사의 마음을 전한다." 이번 수상 연설의 제목은 "파스칼과 델파이의 역사에 대한 개인적인 견해"로 정했다. "개인적인 견해"란 내 삶이 어떻게 영향을 받았는지, 그리고 오브젝트 파스칼 커뮤니티가 전반적으로 현재의 모습을 갖추는 데 조금이나마 내가 어떻게 도움이 되었는지를 뜻한다. 다시 말해, 파스칼 언어와 도구의 역사를 살펴보는 동시에 내 경험도 함께 고찰 해보았다. 마지막에는 현재의 델파이 언어와 그 생태계에 대한 몇 가지 생각을 덧붙이려 한다. 면책 조항: 이 글의 일부 역사적 사실은 내 개인적인 기억대로 기술한 것이다. 세월이 많이 흐른 만큼 내 기억이 정확하지 않을 수 있다. 일부 내용은 혹시라도 사실이 아닌 것을 말하지 않기 위해 일부러 너무 자세한 내용까지 들어가지 않았다. 마지막으로, 이 글의 모든 내용은 내가 근무하는 엠바카데로의 공식 입장이 아니라 내 개인적인 관점이라는 걸 알아 두길 바란다. 1970년, 니클라우스 비르트 박사가 파스칼 언어를 공식적으로 소개했을 때 나는 어린 아이였다. 그리고 컴퓨터를 접할 기회도 없었다. 그때는 개인용 컴퓨터가 존재하지 않았고, 전화기는 여전히 벽에 플러그에 꽂아 사용할 때였다. (이 파일은 Creative Commons Attribution-Share Alike 2.5 Generic 라이선스 하에 사용했다.) 나의 첫번째 파스칼 컴파일러는 ZX Spectrum에서 사용한 UCSD 파스칼이었다. 여러분 중 젊은 세대를 위해 설명하자면, ZX Spectrum는 64K 메모리를 갖춘 Z80 프로세서 기반 컴퓨터였다. (하지만 RAM은 48K만 사용 가능했고, 나머지 16K는 ROM에 맵핑 되어 있었다.) (이 파일은 Creative Commons Attribution-Share Alike 4.0 International 라이선스 하에 사용했다.) UCSD 파스칼은 "pcode"를 기반으로한 인터프리터였다. 초기 파스칼 언어 도구는 주로 컴파일러가 아닌 인터프리터였다. Java JVM과 별반 다르지 않은 아키텍처를 기반으로 했다. 이것으로 작성할 수 있는 프로그램들은 임베디드 베이직(BASIC) 언어보다는 훨씬 빨랐다. 그러나 Z80 어셈블리 코드를 사용하는 것만큼 빠르지는 않았다. 우리 세대의 대다수가 그렇게 시작했고 나도 마찬가지였다. 코드를 작성해 (또는 잡지에 있는 코드를 복사해서) 좋은 그래픽과 괜찮은(물론, 당시 기준으로 괜찮은) CPU를 갖춘 작은 컴퓨터에서 실행했다. 내가 대학교에 다니기 시작할 때엔, 파스칼은 프로그래밍을 배우기 위한 기초 언어로 여겨지고 있었다. 더 이상 그렇지 않다는 점이 안타깝다. 왜냐하면 파스칼은 학습하기에 훌륭한 언어이기 때문이다 (이에 대해서는 나중에 더 자세히 다루겠다). 당시 내가 참고했던 서적은 비르트박사의 언어 매뉴얼인 "파스칼 사용자 매뉴얼과 보고서(The Pascal User Manual and Report)"은 아니라, 1976년에 나온 그의 성공적인 저서인 "알고리즘+데이터 구조 = 프로그램 (Algorithms + Data Structures = Programs, Prentice-Hall Series in Automatic Computation)"이었다(https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs). 위키피디아에는 "이 책은 당시 가장 영향력 있는 컴퓨터 과학 서적 중 하나였고, 비르트박사의 다른 저서와 마찬가지로 교육에 광범위하게 사용되었다."라고 설명 되어있다. 그 당시 컴퓨터와 파스칼 언어를 둘러싸고 또 다른 일이 벌어지고 있었다. 80년대 초중반의 이야기다. 바로 PC 혁명이 시작된 것이다. IBM이 최초의 PC를 출시했고, 연이어 PC의 복제품들이 나타나기 시작했다. (Federigo Federighi - 본인 저작물, CC BY-SA 4.0) 나는 운이 좋게도 Olivetti M24를 소유하고 있었다. 이 컴퓨터에는 플로피 드라이브(바로 그 "플로피" 드라이브)가 두 개가 있었다. 나중에서야 나는 하드 드라이브로 업그레이드했다. 내 기억으로는 20MB였을 것이다. 이 컴퓨터는 IBM보다 훨씬 빠른 CPU를 탑재한 흥미로운 컴퓨터였다. Olivetti는 당시의 훌륭한 이탈리아 회사로, 현대적인 조직으로 운영되며, 직원들에게 실리콘 밸리 스타일의 혜택을 제공했다. (하지만 이건 이 주제를 벗어난 이야기다.) 내가 M24를 언급하는 이유는, 이 제품을 사용해 터보 파스칼을 실행할 수 있었기 때문이다. 버전 3이었던 것 같은데, 아마 이 IDE에서 가장 성공적인 버전이었던 것 같다. 나는 터보 파스칼 이야기를 좀 더 하고자 한다. 파스칼 사용자뿐만 아니라 전체 개발자 커뮤니티가 터보 파스칼로부터 받은 영향이 매우 크다고 생각하기 때문이다. 대다수가 잘 알고 있는 이야기를 또 다시 반복해 말하게 되어 미안하지만, 여러분 중 젊은 세대들이 당시 상황을 더 잘 이해할 수 있기를 바라기에 양해를 부탁한다. (디지털 리서치 제공 - http://www.hampa.ch/pce/screenshots/index.html, 퍼블릭 도메인) 초창기에는, 하드웨어 공급업체들이 자신들의 OS를 설계했으며 그것을 위한 개발자 도구도 제공했다. 애플도 그랬고, 그 후에 사라진 다른 업체들도 마찬가지였다. 공개 옵션은 오직 CP/M 운영 체제뿐이었다. 이것은 Gary Kildall의 회사인 Digital Research에서 제공했다. IBM은 다른 방식을 채택했다. IBM은 너무나 큰 회사였고, 각 부분들을 모두 제작하려면 시간이 많이 필요했을 것이다. 그래서 IBM은 소프트웨어들 즉 운영체제와 프로그래밍 도구둘 모두를 라이선스하기로 결정했다. 원래 마이크로소프트는 그 중 프로그래밍 도구만 제공하기로 되어 있었다. 그리고 OS는 디지털 리서치에서 제공하기로 되어있었다. 하지만, 결국에는 마이크로소프트가 MS DOS를 IBM에게 제공했다. 거의 무료로 말이다. 그 프로젝트를 전체를 잡기 위해서였다. 재미있는 이야기이다. 하지만, 오늘 주제에서 약간 벗어난다.이 이야기는 디지털 리서치(또는 Intergalactic Digital Research)가 역사적인 기회를 놓친 것에 대한 이야기이기 때문이다. (Rama & Muse'e Bolo - 파일: IBM_PC-IMG_7271.jpg, CC BY-SA 2.0 fr) IBM PC 이야기로 다시 돌아와서, IBM의 PC가 출시 될 때, 거기에는 마이크로소프트가 제공하는 프로그래밍 언어들 함께 들어있었다: BASIC C, 파스칼이 들어있었다. 정말일까? 그렇다. 파스칼이다. 같은 시기에, 취리히 폴리테크닉에서 수학을 전공한(음악도 전공) 어떤 프랑스 기업가가 있었다. 그는 덴마크의 어떤 사람이 CP/M 컴퓨터용 매우 빠른 파스칼 컴파일러를 만들었다는 사실을 알게 되었다. "컴파스 파스칼, Compas Pascal"이라는 컴파일러였다(버전마다 이름이 달라졌었음). PolyData라는 회사의 제품이었다. 그 제품은 주로 그 지역에 있는 사람들에게 유통되고 있었다. 언젠가, 수정된 버전의 카피를 구하러 Anders의 집까지 자전거를 타고 다녀온 개발자와 이야기를 나눈 적이 있다. 그 미국계 프랑스인은 그 덴마크 개발자와 그의 회사에 라이선스 계약을 제안했다. 파스칼 컴파일러를 유통하겠다고 말이다. 그 미국계 프랑스인은 그 당시에는 돈이 없었다. 그래서 Byte(그 당시 가장 유명한 컴퓨터 잡지였음)와 협상하여 선불 없이 광고를 게재하는 조건으로 광고 계약을 맺었다. 그 광고를 통해 발생한 매출로 비용을 지불하려 한 것이다. 그 뿐만이 아니었다. 그 미국계 프랑스인은 컴파일러를 49.99 달러에 판매하기로 결정했다. 그 당시 다른 유사한 도구들의 가격은 모두 300달러가 훨씬 넘었다. 그 제품도 처음에는 마찬가지였다. 그 덴마크 개발자가 이 사실을 알게 되었고, 자신이 로열티를 받기로 한 것을 고려할 때, 그 가격 정책은 정말 바보같은 아이디어라고 생각했다. 터보 파스칼이 Byte 잡지에 게재되자마자, 터보 파스칼은 바로 히트를 쳤다. 볼랜드의 창립자인 Philippe Kahn은 지불해야 할 광고 비용보다 훨씬 더 많은 돈을 벌었다. 그리고 Anders Hejisberg는 덴마크에서 캘리포니아의 스코츠 밸리로 이사했고, 제품 개발에 전념했다. Hejlsberg가 쓴 것처럼 "그 이후의 이야기는 모두가 아는 대로"다. 아마 여러분은 이제 마이크로소프트 파스칼에 무슨 일이 생겼는지 궁금할 것이다. 마이크로소프트 파스칼은 터보 파스칼의 성공으로 인해 그 존재가 가려졌다. 그리고 나중에 단종되었다. 마이크로소프트 파스칼은 고가의 컴파일러였다. 나중에 마이크로소프트는 터보 파스칼에 대항하기 위해 "퀵 파스칼"을 출시했지만 결국 그 버전도 성공하지 못했다. 언어 자체의 문제는 아니었다. 시장에 원인이 있었다. 당시 많은 개발자들이 파스칼을 사용했지만 마이크로소프트의 도구를 사용하지는 않다. 그렇다면 터보 파스칼의 대단한 점은 무엇이었을까? 물론 그 언어 자체가 위대하기 때문이다. 우리 모두가 좋아하는 바로 그 언어말이다. 하지만, 터보 파스칼은 역사 상 최초의 통합 개발 환경(IDE) 중 하나라는 이유도 있었다. 그 당시에 개발자들은 편집기을 사용하여 코드를 입력하고, 파일로 저장했다. 그리고 나서, 커맨드 라인 컴파일러를 실행했다. 출력를 주의 깊게 확인하여 오류가 나는 줄들을 파악했으며, 다시 편집기를 열고 해당 줄으로 갔다. 그리고 다시 저장하고, 다시 컴파일해야 했다. 모두가 알다시피, 프로그램은 한번에 하나만 실행할 수 있었다. MS DOS에서는 말이다. 마침내 그 프로그램을 컴파일했다면, 개발자들은 디버거를 실행할 수 있었다. 디버거 역시 또 다른 별도의 도구였다. 도구 하나 안에서 코드 작성, 컴파일, 디버깅을 모두 할 수 있다는 점은 그저 좋은 아이디어 정도가 아니었다. 시간을 엄청나게 절약해주었다. 여러분은 아마 "그래 재미있긴 하네 하지만, 왜 40년이나 된 소프트웨어인 터보 파스칼 이야기에 이렇게 많은 시간을 쓰고 있는거지?"라고 생각할 수도 있겠다. 바로 그것이 이유다. 터보 파스칼이 40주년을 맞이하는 것이 올해 말이기 때문이다, 1983년 처음 출시었으니 말이다! 터보 파스칼에는 독특한 다른 특징들이 있다. 그 빠른 성능은 여러가지 요인들에 기인한다. 그 코드에서 많은 부분은 어셈블리로 되어 있다. 뿐만 아니라 싱글 패스(single pass) 컴파일러라는 사실도 큰 도움이 되었다. 싱글 패스 컴파일러의 경우에는, 사용할 수 있는 구문에 제한이 있다. 하지만, 빠르다. 오늘날에도 몇몇 컴파일러들은 여전히 싱글 패스 컴파일러다. 델파이 11 알렉산드리아 역시 그 중 하나다. 참고로, 명령줄에서 DCC를 호출하면 버전 번호를 확인할 수 있다. 그 델파이 컴파일러의 버전은 35이다. 이는 터보 파스칼 시절까지 거슬러 올라간다. 터보 파스칼은 "말도 안되는 책-같은 라이선스"로 판매되었다. 우편 주문을 통해 직접 판매되었다. 볼랜드는 터보 파스칼 카피 약 25만 장을 첫 2년동안 판매했다. 1980년대 초반의 개발자용 도구 판매로는 어마어마한 수치이다. 볼랜드는 DOS용으로 첫 "TSR(terminate-and-stay-resident program)" 프로그램인 Sidekick과 다른 개발 도구들을 만들었다. 하지만, 여기서는 다룰 내용은 아니다. 니클라우스 비르트 이야기로 돌아가겠다. 그도 가만히 있지는 않았다. 파스칼 언어가 대학에서뿐만 아니라 기업에서도 성공을 거둔 후, 그는 그 뒤를 이러 모듈라(Modula)-2를 설계했다. 모듈라-2에 담긴 많은 아이디어들은 초기 터보 파스칼 버전에 반영되었다. 유닛이라는 개념이 바로 여기에서 시작되었다. 언어 측면에서 보면, 모듈라-2+와 모듈라-3도 있었다. 이 마지막 버전은 핵심 언어에 오브젝트 지향 기능을 추가한 것이다. 이는 Olivetti를 포함한 산업 연구소들에서 설계했다. 시기하게도, 나는 대학을 졸업하면서 Olivetti에서 근무하게 되었고, Modula-3 연구를 접했다. 그 연구 이야기는 너무 앞서 나가는 주제인 것 같다. (공정 사용) 다시 내 얘기로 돌아가서, 나는 Olivetti M24에서 터보 파스칼 3를 사용했다. 후속 컴퓨터들과 후속 버전들이 출시되는 동안에도 나는 여전히 파스칼 언어를 계속 사용했다. 대학 시절, 파스칼은 나의 첫 프로그래밍 언어였다. 내 기억이 맞다면, 내 첫 프로젝트는 여러 지점 간의 최단 경로를 계산하는 그래프 분석 애플리케이션을 구축하는 것이었다. 그런데 그 대학에서 결국 나는 다른 프로그래밍 언어에 관심을 갖게 되었다. 운영체제 수업에서 나는 C 언어를 배웠다. 그리고 고급 컴퓨터 과학 수업에서는 프로그래밍의 새 트렌드들을 접하게 되었다. 당시는 오브젝트 지향 프로그래밍(OOP)가 걸음마를 시작하던 시기였으며, 스몰토크(Smalltalk) 역시 마찬가지 였다. 함수형 프로그래밍이 대세였고 LISP가 유명했었다. 논리 프로그래밍은 프롤로그(Prolog)가 이끌고 있었다 (볼랜드 터보 프롤로그도 있었다. 하지만 크게 성공하지는 않았다) (아마존 닷컴 도서 목록, 공정 사용) 물론, 스몰토크(Smalltalk)는 내 경력에서 가장 중요한 역할을 했다. 나는 Ada도 조금 공부했는데 왜 배웠는지는 잘 기억나지 않는다(Ada는 파스칼 문법에 뿌리를 두고, begin/end 같은 것들을 사용하는 언어이다). 또 상당히 낯선 언어인 에펠(Eiffel)도 배웠다. 이 언어는 소프트웨어 계약의 시초가 되었다. 클래스 불변식, 전제 조건, 후제 조건을 언어의 명시적 기능으로 만들었었다 (상당히 특이한 경우다). 에펠은 Ada에서 파생되었다. 그렇다. 80년대 후반과 90년대 초반에는 프로그래밍 언어들의 세계가 서로 상당히 달랐다. (작성자 제공 사진, 공정 사용) 어쨌든, 이 모든 새로운 방향의 영향을 받아서 파스칼의 세계는 오브젝트에 관심을 갖기 시작했다. "오브젝트 파스칼"이라는 이름은 애플이 자신들이 사용하는 언어를 부르던 이름이다. 볼랜드에서 나온 제품은 "터보 파스칼 위드 오브젝트(urbo Pascal with Objects)"이었다. 이 제품은 큰 성공을 거두지 못했으며, 터보 파스칼은 계속 쇠퇴해갔다. 여러분이 아마 알고 있겠지만, 당시 코드들은 여전히 남아 있다. 여러분은 오브젝트 타입 선언을 델파이에서 할 수 있다. 델파이 모바일 컴파일러에는 그 타입이 없다보니, 버그 리포트와 불만이 우리에게 접수되고 있기도 하다. 재미있는 비화다. 스몰토크는 좋은 언어다. 하지만 사용하기에는 다소 실용적이지 않았다. 소스코드라는 개념이 없기 때문이었다. 개발자들은 그저 런타임에 메시지나 메서드를 추가하는데, 그것들 역시 오브젝트이다. 그 당시의 컴퓨터에게는 너무 무거웠다. 한 작은 회사가 윈도우 버전을 만들었는데, 아키텍처가 크게 최적화되어 있었다. 그리고 오브젝트를 통해 윈도우 API를 관리하기 위한 클래스 라이브러리를 개발했다. 이 언어의 이름은 액터(Actor)였고, 제조 회사는 "Whitewater Group"이었다. 이 클래스 라이브러리는 나중에 볼랜드에 인수되어 C++용 오브젝트 윈도우 라이브러리가 되었다. 또 내가 너무 앞서 가는 것 같다. (공정 사용, 원본 표지) 내가 대학교를 졸업할 때쯤부터 커리어를 시작할 때쯤까지 집중하게 된 것은 사실 새롭게 도입된 C++ 언어였다. 처음에는 컴파일러를 찾기가 어려웠다. 학위 논문에서는 C++에서 C로 변환하는 변환기를 사용했다. 나중에 C 컴파일러를 사용하여 최종 코드를 작성했다. 당연히 디버깅을 할 수는 없었다. 볼랜드 터보 C++가 곧 출시되었고, 이어서 마이크로소프트 비주얼 C++가 나오면서 모든 것이 바뀌었다. 내가 C++에 집중하고 있을 때였지만, 나의 첫 직장에서의 업무는 터보 파스칼 책을 영어에서 이탈리아어로 번역하는 일이었다. 그로 인해 나는 파스칼 언어와 라이브러리뿐만 아니라 책을 쓰는 과정에대해서도 많이 배웠다. 얼마 지나지 않아 나는 C언어로 윈도우 프래그래밍 하는 법을 배웠다. 이 때 윈도우 API 개발에 대한 정식 가이드의 가장 유명한 저자 Charles Petzold의 이름에서 따온 "Petzold 스타일"로 배웠다. C++와 클래스 라이브러리 사용법을 아는 것은 엄청난 보너스였다. 볼랜드는 방금 언급한 오브젝트 윈도우 라이브러리(OWL)라는 정교하고 방대한 클래스 라이브러리에 모든 노력을 총동원했다. 마이크로소프트는 매우 얇은 레이어를 사용하기로 결정했다. 그래서 오브젝트 구조를 활용하거나 많은 것을 추가하지 않고 API를 캡슐화했다. 기술적으로 봤을 때 이는 더 제한적이고 기능면에서 명백히 열등했다. 누가 이겼을까? 비주얼 C++와 MFC가 살아남았다. 여전히 얇은 레이어로. 여전히 비주얼은 아니다. (작가 제공 사진) 앞서 말했듯이 나는 몇 년 동안 주로 볼랜드 C++와 OWL에 집중했지만, 비주얼 C++와 MFC에도 관심을 기울였다. 내가 볼랜드 이벤트에 참석하고 세션을 진행하기 시작한 시기가 있었다. 그 때 나는 볼랜드 C++와 OWL에 대해 3권의 책을 썼다. 나는 교육 및 컨설팅 일도 했는데, 주로 MFC를 위한 일이었다. 그러다 1984년 샌호세에서 터보 C++ 제품 관리자와 회의를 했던 날이 있었다. 라이브러리를 개선하고 사용하기 쉽게 만들기 위해 논의했다. 나는 GUI를 보다 쉽게 만들 수 있도록 시각적 레이어를 추가하는 것을 제안했다. 제품 관리자는 그의 동료인 Zack Urlocker에게 나를 소개했다. 그리고 나는 델파이의 첫 데모를 보게 되었다. 그 당시에는 아직 델파이라는 이름이 정해지지는 않았다. 여러 이름들이 후보에 올랐다. 핫 하다는 뜻에서 와사비라는 이름 부터 VBKiller라는 뜻의 VBK라는 이름 등 다양했다. 이름 후보 중 하나인 델파이는 지금은 고인이 된 Danny Thorpe가 제안한 것이다. 오라클과 강력한 데이터베이스의 연결성 때문에 오라클과 대화하는 곳이라는 뜻의 이름이었다. 회사는 앱빌더로 결정하려고 했다. 그 이름은 여전히 제품에서 기본 IDE창 이름으로 사용되고 있다. 하지만 앱빌더라는 이름은 이미 사용되고 있었기에 결국 델파이가 선택되었다. 돌이켜보면 델파이가 훨씬 좋은 이름이었다. 신제품은 모든 면에서 입이 떡 벌어질 정도로 놀라웠다. 델파이는 OOP 및 컴포넌트, 시각적 간소함, 우수한 OOP 아키텍처 덕분에 그 이름이 찰떡 궁합이었다. (그 당시 기준이지만 지금의 기준으로도 여전히 훌륭하다.) OWL에 비해, 윈도우 API와 플랫폼 메시징 시스템의 깔끔한 맵핑 및 캡슐화 측면에서 상당히 발전했다. 단순히 VB에 대한 해답이 아니었다. 커다란 혁명처럼 보였다. 1995년 2월에 제품이 출시되기 전, 나는 그 회사를 그만뒀다. 그리고 델파이에 집중하기 위해 교육 및 컨설팅 회사를 창업했다. 또 델파이에 대해 책을 쓰기위한 계약도 맺었다. (사진 출처 https://github.com/ahejlsberg) 델파이는 우리를 다시 Hejlsberg에게로 이끌었다. Hejlsberg는 오브젝트 모델과 언어 확장을 설계하여 델파이 성공에 중요한 역할을 했다. 이는 델파이와 델파이 생태계의 성공의 기반이 되었다. 그는 언어 천재였다. 대부분의 언어 전문가들은 일생 동안 하나의 훌륭한 프로그래밍 언어를 설계한다. 어떤 사람들은 일반적으로 같은 분야에서 두 개를 설계해서, 그에 대한 공로를 인정받기도 한다. 하지만 Hejlsberg처럼 델파이, C#, 타임스크립와 같이 서로 다른 분야에서 세 가지 서로 구분되는 언어를 개발 한 사람은 극히 드물다. 그 뿐만 아니라 그는 훌륭하고 겸손한 사람이며 매우 친근하고 사람을 편하게 해주는 사람이었다. (작가 제공 사진) 어쨌든, 다시 1995년 2월 14일로 돌아가 보자. 샌프란시스코의 Moscone 센터에서 SD West(Software Development West) 컨퍼런스의 일환으로, 델파이가 공식적으로 출시된 날이다. 여담이지만, 몇 년간 우리 업계에서는 SD West 컨퍼런스를 잊고 있었다. 요즘에는 자바 원, MS 빌드, 애플의 WWWDC, 구글 이벤트, 페이스북의 개발자 컨퍼런스 등이 있다. 각 회사마다 자체적으로 이벤트가 있다. 그 시절에는 회사 컨퍼런스(예전의 대규모 볼랜드 컨퍼런스 같은)도 있었지만 개발자를 위한 업계 전반의 이벤트도 있었다. C++로 유명한 Stroustrup이나 파이썬으로 유명한 Guido van Rossum과 함께 마이크로소프트 개발자, 볼랜드 개발자, 오픈소스 커뮤니티와 유료 도구에 대한 컨퍼런스가 있을 수도 있다. 나는 일부 행사에 참석하고 연설할 수 있는 행운을 얻었다. 패널과 토론은 즐거웠다. 도구 공급업체들 사이에 진정한 경쟁이 벌어졌다. 각각의 도구가 동일한 프로그램을 작성하는 세션이 있었는데, 거기서 관객들이 환호성을 질렀다. (동영상 보기 https://youtu.be/0q1BkHcZ5kE) 얘기 중 딴 길로 새서 미안하다. 다시 델파이로 돌아가서, 런칭 이벤트는 인상적이었다. 데모를 본 사람들은 놀라서 할 말을 잃었다. 윈도우 UI를 쉽게 구축할 수 있었고, 예외 처리를 올바르게 수행하고, 백그라운드에서는 오브젝트 지향 프로그래밍이 이루어졌던 것이다. 데모 프로그램에서 액세스 위반이 발생했다. 그러나 갑작스럽게 충돌하지 않고 잘 처리하였다. 운이 좋게도 나는 그 이벤트에 참석했다. 내 기억에는 런칭 애프터 파티는 샌프란시스코에 있는 익스플로러토리움 이전 전 장소에서 열렸다. 그 곳은 Robert Oppenheimer의 동생이자 입자 물리학자인 Frank Oppenheimer가 설립한 실험 중심의 과학 박물관이었다. 델파이는 출시하자마자 업계에서 즉시 히트 했다. 몇 년 전의 터보 파스칼처럼. 비즈니스 세계는 DOS에서 윈도우(윈도우의 첫번째 실제 버전인 윈도우 95가 곧 출시되었다)로 넘어가고 있었다. DB 지향 도구(Clipper, 볼랜드 dBase, Paradox)를 사용하는 DOS 인터페이스에서 윈도우로 전환하는 것은 복잡했다. 델파이와 델파이의 강력한 데이터 지향성, 즉 DB 컴포넌트, BDE, DBGrid를 통한 데이터 인식 UI컨트롤, 디자인 시점의 라이브 데이터(모던 툴이 종종 제공하지 못하는 기능으로, UI가 데이터로 채워진 것을 확인하려면 복잡한 빌드/배포/디버그 주기가 필요했다) 이것이 부분적인 이유였다. 또 다른 이유는 델파이로 컴파일된 코드가 빠르다는 것이었다. 데이터베이스 4GL언어보다 훨씬 빨랐다. 주요 경쟁 상대인 비주얼 베이직보다도 훨씬 빨랐다. 곧 출시될 자바 VM보다도 훨씬 빨랐다. 델파이의 속도는 빨랐다. 비용 문제 또는 정치적 이유로 하드웨어에 대한 접근이 제한된 국가에서 더욱 높이 평가되었다. 지금까지도, 델파이는 초기에 그 성능이 중요한 국가에서도 국제적으로 큰 성공을 거두고 있다. 내가 앞서 자바를 언급한 이유가 있다. 자바도 1995년에 출시되었다. 1995년은 프로그래밍 언어의 해로 볼 수 있다. 자바, 자바스크립트, 루비, PHP 그리고 델파이. 이 모두가 거의 30년 전에 비슷한 시기에 시작되었다. 그때 파이썬도 있었지만 거의 사용되지 않았다. 자바스크립트는 1995년 12월 4일 첫 등장을 했다. 자바의 첫 등장은: 1995년 5월 23일 파이썬은 1994년 1월에 1.0버전을 출시했다. (첫번째 출시는 1991년이었다) PHP는 1995년 6월 8일에 도입되었다. 루비는 1995년에 처음 등장했다. 지금 이야기 중인 델파이는 1995년 2월 출시했다. 그런데 이제 프로그래밍 언어를 둘러싼 논쟁을 보면, 자바와 파이썬은 새로운 언어, 델파이와 파스칼은 오래된 언어라고 한다. 어떻게 된 걸까? 델파이가 충분히 발전하지 않았나? 난 동의하지 않는다. 델파이는 많이 발전했다. 내 책이나 다른 많은 온라인 자료에서 전체적인 내용을 확인할 수 있다. 자바스크립트는 최근 몇 년 동안 무엇이 새로워졌는가? 파이썬 2와 비교하여 파이썬 3의 혁신적인 것은 무엇인가? 새 출시 작의 문서를 읽어보았다. (https://docs.python.org/3/whatsnew/3.0.html) 작은 확장 기능, 데이터 유형과 RTL의 변경같이 멋지고 중요한 변경이 많지만 언어면에서의 혁명은 아니다. 그렇다면 델파이의 무엇이 오래되었나? 파스칼 언어이기 때문일까? RAD 모델이기 때문인가? 신기하게 최근 애플과 구글은 프리뷰 창에서 UI를 미리 보는 것이 좋은 생각이라고 인정한 것 같다. 오브젝트 파스칼을 사용하면 원하는 어떤 아키텍처로든 코드를 작성할 수 있다. 가비지 컬렉터가 없는 것이 낡은 방식인가? 아마 그럴 수도 있다. 하지만 메모리 사용을 제어하는 것 자체는 나쁜 생각은 아니다. (화면 캡쳐 https://delphi.embarcadero.com/) 다시 델파이로 돌아가보면, 제품은 몇 년에 걸쳐 계속 발전해 왔다. 여러 회사들이(볼랜드, 코드기어 사업부, 엠바카데로, 현재에는 아이데라) 일을 이끌어 왔고, 다양한 제품 관리자들이 있었고, 다수의 훌륭한 전문가들이 R&D팀의 일원으로 일했다. 마지막으로 회사 측면에 대한 이야기를 하고싶다. 나는 이렇게 몇 년 동안 내가 한 일에 대해 잊고, 제품과 제품 생태계로 돌아가고 싶다. 제품은 많은 변화를 겪었다. 델파이 2에는 윈도우 95용 32비트 컴파일러가 있었다. 언어는 초기 몇 년 동안 많이 발전했다. 델파이 6 시기에, 볼랜드는 리눅스 데스크탑 애플리케이션을 빌드하기 위한 리눅스 호스팅 IDE인 카일릭스(Kylix)를 만들 었다. 나중에 볼랜드는 .NET을 수용하여(어느 정도는 너무 과하게) 오늘날까지 살아남은 새로운 IDE 아키텍처 "갈릴레오(Galileo)"를 만들었다. 이전에 언급했듯이 델파이 1이 출시될 때 나는 나의 교육 및 컨설팅 회사를 설립했다. 동시에 책을 쓰기 시작했고, 프로그래밍 잡지에 많은 글을 기고하기도 했다: 델파이 인포맨트(Delphi Informant)와 델파이 매거진(Delphi Magazine)을 비롯해 윈도우 테크 저널(Windows Tech Journal)과 몇 권의 이탈리아 컴퓨터 잡지에 글을 게재했다. 내 말은, 모두 우편으로 보내는 실제로 인쇄되는 잡지였다. (작가 제공 사진) 내 책부터 시작하겠다. 파스칼 언어와 관련된 나의 첫 번째 책은 "마스터링 델파이 1(Mastering Delphi 1)"이었다. 나는 IDE와 언어뿐만 아니라 라이브러리까지 모두 다루겠다는 생각으로 시작했다. 이 책을 쓰는 데는 많은 시간이 걸렸다. 당시에는 미국 출판사와 협업하는 것도 복잡했다. 나는 우편을 통해 인쇄된 초고를 받아서 수정할 곳을 마크한 다음에 다시 캘리포니아에 있는 출판사에 우편으로 보내야 했다. 어쨌든 이 책을 쓰는 데 너무 오랜 시간이 걸렸다. 그럼에도 불구하고 훌륭한 투자이자 할 가치가 있는 일이었다. 1,500 페이지에 달하는 놀라운 양이었다. 그렇다. 엄청난 분량의 책이었다. 얇은 종이를 사용해야 할 정도였다. 그 책은 성공적이었지만 히트작은 아니었다. 책을 쓰는 데 많은 시간이 걸렸기 때문에, 델파이에 관한 첫 번째 책이 아니었다. 하지만 긍정적인 평가를 받았다. 여러 나라의 언어로 번역되었으며, 독자들 사이에서 칭찬이 자자했다. 나는 후속 작 "마스터링 델파이 2, 3, 4"을 계속 썼고, 책 판매량은 계속 증가했다. 이유는 알 수 없지만, 그 책은 브라질에서 대히트였다. 브라질의 일부 판본은 영어 판과 거의 비슷하게 많이 팔렸다. (작가 제공 사진) 전반적으로 마스터링 델파이의 여러 판본은 20개 이상의 언어로 번역되었다. 전체 목록이 있는지는 잘 모르겠지만, 내 웹사이트에 있는 목록은 최신 상태가 아니다. 몇 년 동안은 책을 쓰면서 대부분의 시간을 보냈다. 나머지는 시간 동안에는 교육, 컨설팅, 학회에서 강연을 했다. 오브젝트 파스칼에 대한 책을 몇 권 집필했는가? 마스터링 델파이1, 2, 3, 4, 5, 6, 7, 그리고 2005 중간에는 더 고급 주제를 다루는 델파이 개발자 핸드북(Delphi Developers Handbook)과 카일릭스에 관한 책을 썼다. 나중에는 내가 직접 책을 출판하기 시작했다. 나는 델파이 2007 핸드북, 델파이 2009 핸드북, 델파이 2010 핸드북, 델파이 XE 핸드북을 썼다. 이후 오브젝트 파스칼 핸드북(인쇄본 2개)의 네 가지 버전을 출간했다. 이로써 오브젝트 파스칼과 델파이를 다룬 총 16권의 영문 앤쇄 서적을 출간했다. 나는 Cary Jensen과 함께 3권의 Delphi Developer Days에 기고했다. 내 계획은 여기서 멈추지 않는다. 현재 두 개의 리뷰 프로젝트를 진행중이다. 곧 출시될 델파이의 다음 버전을 위한 언어 핸드북의 새로운 판에 관련해 참여하고 있다. 또 지금은 고인이 된 Pawel Glowacki가 쓴 매우 특별한 책, Expert Delphi의 업데이트 작업에도 참여중이다. 시간이 걸리겠지만, Pawel의 유산이 사라지지 않도록 참여하게 된 프로젝트다. (Paolo Rossi가 촬영한 사진으로 추정) 몇 년 동안 나는 교육, 트레이닝, 컨설팅도 했다. 이탈리아. 유럽, 전 세계에서 일을 했다. 너무 많아 정확한 숫자는 세어보지 않았지만, 호주에서 브라질, 캐나다에서 싱가포르, 뉴질랜드에서 일본, 중동까지 많은 나라에서 세션을 진행했다. 중동에서는 델파이로 인해 교통 체증까지 발생했다. 북쪽으로는 노르웨이 남쪽으로는 몰타까지, 서쪽으로는 포르투갈, 동쪽으로는 폴란드까지 대부분의 유럽 국가에서도 세션을 진행했다. 독일, 프랑스, 영국은 자주 방문했다. 덴마크, 스웨덴, 노르웨이도 그에 못지 않게 방문했다. 컨퍼런스와 기타 다른 이벤트들을 위해 미국을 수 없이 방문했던 것은 말할 필요도 없다. 교통 체증 이야기로 돌아가보겠다. 들어 볼만한 이야기다. 쿠웨이트에서 재무부를 위해 델파이 교육 세션을 진행했다. 쿠웨이트에는 세금이 없는 나라라서 조금 이상한 일이긴 했지만 재무부가 있었다. 이야기를 나누던 중 개발자들이 나에게 말했다. 많은 사람들이 한 델파이 애플리케이션에 불만이 있다는 것이다. 교통체증을 불러오고 있다는 이유에서 말이다. 내가 여러 소프트웨어 문제를 들어봤지만, 이런 일은 없었다. 많이 이상했다. 대다수의 수도들이 그렇듯 도시 인구의 상당수가 정부 기관에서 일하는 것을 알게 되었다. 그 대부분이 8시에 출근한다고 했던 것 같다. 그러나 직원들은 8시를 넘겨 출근하기도 했고 때로는 9시 전에야 겨우 출근하기도 했다고 한다. 그래서 출입할 때 스캔해야 하는 배지가 도입됐다. 델파이 애플리케이션으로 작동했다. 이제 모든 직원들이 아무 시간에나 출근하는 것이 아니라 정시에, 동시에 출근한다고 했다. 그로 인해 교통 체증이 발생한다는 것이다. 파스칼로 작성된 프로그램때문에 발생한 교통체증이다. (작성자 제공 사진) 나는 Cary Jensen과 그의 아내 Loy와 함께 3년 간 Delphi Developer Days라는 교육행사를 진행했다. 나는 그 활동은 매우 좋아했다. 그것은 특별한 경험이었다. 유용한 정보가 가득한 이틀이었다. 유럽과 미국에서 4~5차례 반복해서 개최되었다. 3년 동안 진행했다. 청중과 소통할 수 있는 훌륭한 행사였다. 우리는 친구 및 지역 커뮤니티 방문도 주최했다. (작성자 제공 이미지) 가장 좋았던 이벤트는 초기 볼랜드 컨퍼런스였다. 5,000여 명의 개발자들 앞에서 "델파이의 재미있는 측면" 이라는 세션을 진행한 순간이 최고였던 것 같다. 온라인에서 다시 보기 할 수 있는 세션이다. 한 번 보길 추천한다. 그러나 실제로 현장에서 보는 것이 진짜 재미있다. 목표는 가장 복잡하고 어려운 방법으로 쓸데없고 이상한 작업을 수행하는 것이었다. 이 세션은 TNothing이라는 컴포넌트로 시작되었다. 정말 아무것도 아니었기 때문이었다. 컴퓨터를 감염시키거나 화면을 거꾸로 뒤집는 "홍역"이라는 앱을 만든다 거나 아니면 델파이 메뉴를 훨씬 더 멋진 알파벳 순서로 바꾸는 것 같이 말이다. 직접 봐야 하는데, 꽤 편리할 수도 있다. 그럴 수도 있다. 또 다른 아이디어는 윈도우 리소스를 고갈시키고 시스템을 일부러 충돌시키는 것도 있었다. (실제로는 쉬운 일이다) 어떤 버전에서는 도전 과제가 '윈도우 2000에서 2000개의 창(Windows) 만들 수 있는가' 였다. 정답이 무엇인지 짐작할 수 있는가? 때는 밀레니엄 버그의 시대였다. 청중들 중 일부 젊은 세대에게는 재미있는 일이었을 수 있다. 하지만 밀레니엄 버그는 소프트웨어 개발자들에게는 재미있는 일이 아니었다. 개발자들은 1999년 12월 31일 다음날이 1900년 1월 1일이 아니라 2000년 1월 1일이라는 걸 프로그램이 이해하도록 많은 노력을 기울였기 때문이다! 알겠지만 대부분의 소프트웨어들은 두 자릿수 연도 시스템을 이용하고 있었다. (그 이미지를 보려면: https://lighttouchdesigns.com/project/borland-2/) 볼랜드 컨퍼런스로 돌아가서, 그 이벤트들은 정말 훌륭했다. 수 천명의 사람들이 참석했다. 놀이공원에서 밤을 보내고, 밤 늦은 시간에는 게임 연구소에서 보내는 등 정말 재미있었다. 오늘날 델파이 세계에서 그런 분위기를 느낄 수 있는 곳은 브라질의 컨퍼런스 뿐이다! 하지만 독일과 이탈리아를 비롯해 일본, 호주 등 전 세계 여러 나라에서도 100명이 넘는 인원이 모이는 행사를 개최하는 활발한 커뮤니티가 있다. 델파이는 분명히 전성기는 지났지만, 여전히 제품은 건재하며, R&D투자의 타당성을 보여주는 좋은 비즈니스를 창출하고 있다. 델파이 커뮤니티는 여전히 전 세계 곳곳에서 모든 종류의 소프트웨어를 개발하고 있다. 회사 프레젠테이션을 위해, 델파이와 파스칼이 활발히 사용되고 있는 산업의 목록을 만들어 보았다. 이것은 단순히 생각속에만 존재하는 사례가 아니다. 나는 각 산업별로 회사 이름도 기억하고 있다. 하지만 대부분 이름을 밝힐 수 없는 경우가 많다. 석유 및 가스 항공 우주 대용량 데이터 처리 GIS 애플리케이션 회계 키오스크 애플리케이션 통신 소프트웨어 측량 자동차 항공기 운용관리 원격 컴퓨터 액세스 건축 헬스케어 비즈니스 분석 시스템 관리 음악 편집기 비디오 게임 데이터 베이스 프론트 엔드 농업 관리 IoT 관리 전자 인보이스 기차 및 철도 모든 유형의 모바일 앱 판매 시점 정보 관리(POS) 정부 공학 프로젝트 생산 시스템 모니터링 애니메이션 영화 텔레비전 완전한 ERP 시스템 실시간 금융 은행 시스템 세금 신고 제조업 물류 창고 자동화 개발자 툴 광고 회로 기판 설계 배송 및 물류 트럭 추적 사용 사례 중 일부는 정말 환상적이다. 파스칼로 컴파일 된 코드는 나이아가라 폭포를 비추고, 자동화 화물 항구의 컨테이너 크레인을 움직이며, TV에서 스포츠 경기의 실시간 3D 선수 정보를 표시한다. 또 세금 신고서를 작성하고, 정부에 전자 송장을 전송하며, CPU를 설계하고, 모두가 알다시피 델파이 자체를 구축하는 데 사용되고 있다! 커뮤니티는 훌륭하고, 써드파티 벤더와 오픈 소스 커뮤니티 모두가 그 생태계를 위해 큰 역할을 하고 있다. 그 중 일부는 이번 이벤트에도 참여하고 있다. 오브젝트 파스칼로 구축된 가장 성공적인 애플리케이션은 무엇일까? 비즈니스와 산업 혁신적 측면에서 나는 스카이프(Skype)를 꼽고 싶다. 마이크로소프트는 스카이프에 수십억 달러를 투자했다. 정확히는 85억 달러다. 여러 해에 걸친 시도 끝에 다시 만들었다. 그러나 이제는 더이상 많이 사용되지 않고 비즈니스는 활력을 잃었다. (작성자 제공 사진) 내 얘기로 다시 돌아가서, 10여 년 전 Micheal Swindell이 나에게 전화해 일자리를 제안했다. 정말 좋은 자리였다. 이전 몇 년 동안 나는 엠바카데로와 협력해 신입개발자 교육(일부 새로운 지사에서)과 실제 개발 쪽에서 일했다. 마지막에 마이크로소프트가 변경한 윈도우 API에 묶이는 바람에 출시하지 못한 몇 안 되는 컴포넌트 중 하나를 작성했다. 엄밀히 따지면 제품과 함께 제공된다. 하지만 실제로 활성화되지는 않았다. 그 당시 나는 엠바카데로의 도구(그리고 일부 써드 파티벤더) 리셀러이기도 했다. 그래서 비즈니스 측면과 회사 운영에 대한 몇 가지 아이디어를 가지고 있었다. 델파이 제품관리자가 되어 보겠냐는 제안을 받고 나는 잠시 고민했다. 큰 변화가 생길 것 같았다. 나는 대부분 독립적으로 일을 해왔다. 그리고 가정에도 복잡한 일이 있던 시기였다. 하지만 내가 이 일을 하고싶다는 것을 곧 깨달았다. 그래서 나는 일을 함께 하기 위한 조건을 제시했다. 회사는 동의했다. 몇 주 안에 나는 스코츠 벨리에서 계약서에 사인을 했다. 나중에 나는 1년에 네 다섯번 캘리포니아로 출근했다. 요즘은 회사가 완전히 분산되어 있고 온라인으로 운영되고 있기 때문에 캘리포니아로 갈 일은 드물어졌다. 제품 관리자가 되는 것은 큰 변화를 가져왔다. 개발자를 위한 도구의 제품 관리자가 되기 위해서는 개발자가 되어야 했다. 하지만 소프트웨어를 작성하지는 않았다. 제품 관리자는 회사의 모든 부서에 관련되어 일을 해야 한다. 영업팀과 마케팅팀이 제품 판매량을 늘릴 수 있도록 도와야 한다. 동시에 그들의 의견을 평가하고, 궁극적으로는 고객의 의견도 수렴한다. 새로운 기능 계획을 수립하고, 무엇을 어떻게 할 수 있는지 알고 있는 아키텍트들과 논의한다. 또한 개발 계획에 따라 새로운 속성에서부터 알고리즘과 새로운 컴포넌트에 이르기까지 모든 것을 논의한다. 코드 리뷰를 돕고, 내부와 베타 빌드 테스트하고, 길고 자세한 베타 문서를 작성하고, 문서 팀이 그 문서를 제품의 공식 문서로 전환하는 것을 돕고, 프리젠테이션을 위한 런치 데크를 꾸몄다. (David I의 구글 이미지 검색) 이 몇 년 동안 엠바카데로와 아이데라에서 나는 훌륭한 사람들과 또 개발자들과 함께 일할 수 있는 기회를 가졌습니다. David I라고도 부르는 David Intersimone에 대해 언급하려 한다. 그는 수 년 동안 델파이와 파스칼을 홍보하는 데 엄청난 역할을 해 왔다. 또한 R&D에서 함께 했던 훌륭한 개발자들과 여전히 함께 일하고 있는 많은 사람들, 이들과 함께 일할 수 있었던 것이 큰 기쁨으로 남아있다. 그리고 다른 PM, Dev Rel 직원, 전도사들뿐만 아니라 영업 및 기타 직군 역할의 사람들도 마찬가지다. 많은 사람들이 10년동안 나와 함께 일해왔다. 다정한 사내 커뮤니티가 있어, 많은 사람들과 친구로 지내며, 다른 곳으로 이직한 사람들과도 계속 연락하며 지내고 있다. 물론, 오브젝트 파스칼과 델파이 커뮤니티 및 그 생태계에서도 나는 즐겁다. 항상 감사하고 있다. 회사를 대표하는 얼굴 중 하나가 되어, 잘 알려진 사람이 되고 보니, 커뮤니티 일원이었던 과거와는 모든 게 달랐다. 나는 회사가 잘못한 일이나 하지 않은 일에 대한 비판의 대상이 되기도 했다. 당연한 일이다. 때로는 약간 좌절스러울 때도 있다. 하지만 대부분의 사람들은 나의 역할을 이해하고 지지해 주었다. 그리고 제품을 올바른 방향으로 유지하기 위해 하는 작은 노력들에 감사했다. 그렇다면 델파이는 어떨까? 다양한 오브젝트 파스칼 컴파일러들은 요즘 어떤 상태에 있을까? 델파이는 여전히 윈도우에서 강세를 보이고 있다. 나는 마이크로소프트의 많은 사람들과 연락하며 지낸다. 윈도우팀은 델파이가 진화하는 플랫폼을 지원하기 위해 하는 일의 진가를 알아주고 있다. 나는 이 분야에서 많은 일을 해왔다. WebView 2 제어 통합(Chromium Edge 브라우저 엔진)부터 MSIX 지원까지 내가 집중했던 몇 가지 분야를 이야기해보겠다. (작성자 제공 이미지) 여전이 핵심 타겟은 윈도우다. 그러나 오브젝트 파스칼은 모바일분야에도 어느 정도 진출을 했다. 성공적인 모바일 앱이 몇 개 있다. 사실 나는 모바일 앱을 하나 만들었다. 그 앱은 구글 플레이 스토어에서 25만회 이상 다운로드를 기록했다. 그만두게 되어 안타깝게 생각한다. 정말 멋진 스토리다. 그 앱은 아들과 함께 재미로 작성했다. 그리고 아들 친구들이 설치할 수 있게 업로드했다. 요상한 작은 앱이었다. "대기 게임"이라고 하는 것인데: 약 30분 마다 어떤 것을 할 수 있는 게임이었다. 나는 그래서 그 게임을 아들을 위해 업로드했다. 곧 수천 건의 다운로드가 발생하면서 입소문을 타며 다운로드 수가 상승하기 시작했다. 우리는 앱에 광고를 추가했고, 약간의 돈도 벌었다. 레고와 관련된 앱이었다 그 회사에서는 그 앱을 좋아하지 않았다. 당연한 일이었다. 그래서 그만 둘 수밖에 없었다. PM 업무 이야기로 다시 돌아와서, 나는 10년이 넘게 델파이 제품 관리자로 가장 오래 일하고 있다. 나는 팀과 함께 일하고 있고 다른 회사 제품도 일부 책임지고 있지만 말이다. 이 역할에서 어떤 성과를 이뤄냈을까? 골고루 성과를 내기란 쉽지 않다. 언어는 내 기대만큼 빠르게 발전하지는 않는다. 하지만 우리의 고객은 안정성과 성능을 매우 중요시한다. 때로는 사소한 기능 하나가 새로운 언어 패러다임을 도입하는 것 보다 더 큰 변화를 가져올 수도 있다. 또한 호환성은 제품이 갖추어야 할 특성이며, 핵심 원칙이다. 비록 어떤 때에는 새로운 개발 속도를 늦추는 방해요인이 되기도 하지만 말이다. (작성자 제공 이미지) 지난 10년간 우리는 이 언어에 좋은 기능들을 많이 추가했다. 이 내용에 대해 다루는 세션이 내일 있을 예정이므로 여기서는 많은 시간을 할애하지 않겠다. 내가 제일 좋아하는 기능은? 인라인 변수인 것 같다. 작은 구문 변경같이 보이지만 실제로 그 영향은 매우 크다. 블록 범위와 수명이 도입된 것이다. 타입 추론이 도입된 것이다. 작은 변화인 동시에 커다란 변화다. 제거된 기능도 있다. 실수를 인정하고 그것을 바로잡으려는 것은 일반적으로 어려운 결정이다. 기존의 결정을 뒤집는 것. 그 결정에 개입된 개인의 자존심을 건드리는 일이다. 회사 입장에서도 어렵기는 마찬가지다. 하지만 프로그래밍 언어와 그 생태계의 건강을 위한 결정이며, 길게 봤을 때 가장 좋은 선택인 경우가 많다. 고객이나 내부의 강한 압박에도 불구하고 무언가를 제거하거나, 무언가를 하지 않기로 결정하는 것이 새로운 기능을 추가하는 것만큼 중요할 때가 있다. 나는 윈도우 UWP와 윈도우 휴대폰을 지원을 위한 압박이 기억에 남는다. 우리는 지원하지 않기로 결정했고, 지금은 그럴 의미가 없어졌다. 하지만 가끔은, 추가해야 할 기능들을 추가하지 않고 기다리면 안 될 때도 있다. 결정은 늘 어렵다. 델파이는 좋은 웹 개발 사례를 얻지 못했으며, 이것은 큰 타격이 되었다. (작성자 제공 이미지) 나는 10년 동안 엠바카데로에 있으면서 계속 책을 쓸 수 있었고, 오브젝트 파스칼 핸드북은 새로운 에디션을 출간했다. 파스칼 개발자들을 만나러 다니는 여행도 계속 할 수 있었고, 코드도 계속 작성했다. 나의 업무의 일부를 자동화하기도 했다. 새로운 기능들의 아키텍처를 디자인하고 정의하는데 도움을 주었으며, 데모와 내부 문서를 작성하기도 했다. 다시, 오브젝트 파스칼은 현재 어떤 상태일까? AI와 몰입형 현실, 메타버스, 암호화폐의 급변하는 세계에서도 그 가치가 있을까? 이 질문에 상세하게 답변하는 것이 쉽지는 않지만, 짧게 대답해 본다면, "예"라고 답을 할 것이다. 나는 중괄호 언어를 포기하면 안 된다고 생각한다. 중괄호 언어는 C 언어에서 파생된 수많은 언어들을 일컫는 것이다. 이들은 가독성보다는 간결한 표기법을 우선시한다. 왜 앰퍼샌드를 두개(&&) 사용하는 것이 and를 타이핑하는 것보다 좋을까? 한 글자 밖에 차이가 나지 않지만, 키보드에서 더 찾기 쉽고 읽기도 훨씬 편하다. 더 나은 가독성을 요구하고 권장하는 것은 파스칼 커뮤니티만이 아니다. 파이썬도 여기에서는 또 다른 주요 선수다. 파스칼 개발자가 파이썬을 좋아하는 것은 놀라운 일도 아니다. 엠바카데로는 파이썬 개발자들이 파스칼과 델파이를 사용하기를 희망하고, 그렇게 되도록 노력하고 있다. (이미지 제공 엠바카데로 테크놀로지스) 파이썬과 오브젝트 파스칼은 공통점이 많다. 둘 다 프로그래밍을 배우기 위해 좋은 언어로 시작했고, 업계에서도 한 자리를 차지하게 되었다. 대부분의 대학교들은 훌륭한 언어를 가르치기보다는 취업에 도움이 되는 언어를 가르치고 있다. 나는 이것이 좋은 아이디어가 아니라고 생각한다. 프로그래밍을 시작하고 나서도 사용하는 언어를 다른 언어로 바꿀 수도 있다. 하지만 하나의 언어에 대해서만 알고 있다면, 그 언어에 갇힐 수도 있다. 구체적인 예를 들어보겠다: 나의 첫 프로그래밍 수업은 파스칼에 기반을 두고 있었다. 오브젝트 파스칼은 그 당시 존재하지 않았기 때문에 그냥 파스칼이다. 작년에 내 아들이 대학교에서 처음으로 프로그래밍 수업을 들었다. 구문의 핵심 요소를 배우기 위해 C, 오브젝트와 메모리에서의 그 관리법을 배우기 위해 C++, 오브젝트와 클래스가 작동하는 방법에 대해 더 간단하면서 높은 수준의 자바를 혼합한 수업이었다. 그 어떤 모던 오브젝트 파스칼 컴파일러를 가져와 봐도: 3가지 목적을 모두 달성할 수 있었을 것이다. 복잡한 C++ 없이도 프로그래밍의 기초와 OOP를 제대로 수행하는 방법을 배우는 목적을 말이다. 제네릭, 예외 처리 및 다른 모던 프로그래밍의 핵심 원칙을 포함한다. 대학에서의 이런 트렌드를 되돌릴 수 있을까? 쉽지 않을 것이다. 하지만 파이썬으로 시작하는 개발자가 더 많아진다면, 오브젝트 파스칼이 좋은 대안이 될 수 있다. 다시 묻는다. 오브젝트 파스칼 언어와 그 생태계의 강점은 무엇일까? 나는 수도 없이 말할 수 있다. 피해 갈 수 있는 문제를 복잡한 방법으로 해결하고, 나중에 처음 그 문제를 해결했던 복잡한 방법으로 인해 생긴 문제를 처리하기 위한 또다른 해결책을 만들어야 하는 요즘의 히스테리컬한 상황에도 나는 의문을 가진다. 배포를 예로 이야기해 보겠다. 내 설명을 좀 더 쉽게 이해시키기 위해 조금 극단적으로 이야기하겠다. 현실은 약간 더 복잡하다. 우리 고객 중에는 최대 2천만 줄의 코드로 만들어진 대형 애플리케이션을 하나의 실행 파일로 구축한 경우가 있다. 단 하나의 파일로 말이다. 평균적인 모던 애플리케이션은 배포할 파일이 수천 개나 된다. 그리고 올바른 파일을 적절한 버전으로 배포하려면 꽤 복잡한 오케스트레이션 도구가 필요하다. 그리고 여러분의 코드에 따라 배포하기위한 적절한 파일은, 패키지 리포지토리에서 가져와야 한다. 개발자가 그 동안에 라이브러리를 삭제하지 않길 바라지만, 장담은 할 수 없다. 오브젝트 파스칼의 장점으로 돌아가 보자. 빠른 컴파일, 네이티브 컴파일 코드(일반적으로 더 빠르고 더 안전함), 런타임과 배포 종속성이 매우 적거나 아예 없는 점이 장점이라는 건 우리 모두 알고 있다. 심지어 비주얼 C++ 마저도 배포하기 위해서는 런타임이 필요하다. 물론 올바른 버전이 필요하기 때문에, 어떤 윈도우 컴퓨터에서도 10개의 MSVC 런타임 DLL은 필요하다. 가비지(garbage) 컬렉션이 적어서, 애플리케이션이 빠르고 메모리 사용량이 적다는 것은 말했던가? 다른 면도 있다. 파스칼은 친환경적이다. 최근에 자주 언급되는 꽤 오래된 연구가 있는데, 파스칼과 C가 가장 친환경적인 언어에 속한다는 내용이다. 바로 이 점이 내가 연설을 마치기 전에 다루고 싶은 마지막 포인트다. 오늘날에는 심각한 양의 에너지가 데이터 센터와 클라우드 컴퓨터를 구동하는 데 사용된다. 엄청난 수치는 아니지만, 전 세계 전력의 3%가 클라우드 시스템에 사용된다는 추정치를 봤다. 그 수치는 계속 증가하고 있다. 1990년대 후반에는, 컴퓨터의 발전이 더딘 국가(예를 들어 브라질과 러시아와 같이, 여러 가지 이유로)에서는 컴파일된 파스칼을 베이직 인터프리터보다 선호했다. 지금도 마찬가지다. 메모리와 CPU 효율이 좋은 프로그램을 사용함으로써 에너지 소비를 줄일 수 있다. 단언하건대, C나 C++으로 서버 측 애플리케이션을 작성하고 싶어 하는 사람은 없을 것이다. 여러분은 아마 파이썬을 사용하고 싶을 수 있다. 하지만 오브젝트 파스칼을 사용하면, 훌륭하면서도 동시에 효율적인 언어를 사용하는 것이다. 휴대폰의 배터리 수명을 생각한다면, 자바를 덜 사용해야 한다는 것도 마찬가지로 중요한 사실이다. 오브젝트 파스칼 생태계가 유일한 답은 아니지만, 더 많이 인식되어야 한다는 점은 중요하다. 비슷하게, 더 나은 코딩 스타일을 위해 준수하고, 견고하고, 가독성이 좋은 언어를 사용하여 프로그래밍 하는 방법을 배워야 한다는 인식이 널리 퍼지는 것도 매우 좋을 것이다. 내가 앞서 몇 번 언급했지만, 우리는 대학교에 다니고 있기 때문에, 이 주제는 우리에게 의미가 있다. 모든 것에 두루 적용되는 답은 없다. 중괄호 언어만 있는 것도 아니다. 경쟁의 장을 넓게 열어두고, 개발자들이 편견없이 각 작업에 적절한 툴을 선택할 수 있도록 해야 한다. 이미 이야기한 것처럼, 델파이 및 파스칼 애플리케이션이 아직 많은 비즈니스에 사용되고 있는 것에는 이유가 있다. 또한 훌륭하고 건강한 생태계도 있다. Spring4D, Skia4Delphi, 게임 엔진과 스레드 라이브러리, REST 서버, 마이크로서비스 아키텍처를 살펴보자. 처음으로 우리는 회사로서 이바지하고 있다. 우리는 델파이용 Bold를 오픈 소스로 출시했고, 최근에는 Octoid라는 헤더 생성도구를 출시했다. 앞으로 더 많은 기술이 공개될 예정이다. 관심 있는 사람들을 위해 일부 오래된 기술을 유지하는 것도 중요하다. 우리는 파이썬 생태계를 만들었다. 파이썬 개발자들에게는 VCL과 FMX의 서브셋을 무료로 사용할 수 있도록 했다. 델파이 개발자들에게는 파이썬 컴포넌트를 무료로 제공했다. 그리하여 오브젝트 파스칼에서 인기 있는 파이썬 라이브러리를 바로 사용할 수 있도록 했다. AI 라이브러리들도 포함된다. 그리고 이더리움 블록체인을 위한 암호화 라이브러리도 사용 가능하다. 많은 움직임과 변화가 일어나고 있다. 오브젝트 파스칼은 죽지 않았다. 개발자들은 가만히 멈춰 있지 않는다. 빠르게 움직이는 세상속에 우리도 함께하고 있다. 내가 최근에 쓴 책에 나오는 내용으로 마무리하겠다. 내가 쓴 책을 인용하는 게 멋지지 않다는 걸 알지만, 그래도 시도해볼 가치는 있다고 생각한다. 언어에 대한 내 세션 중 일부에 사용한 슬라이드인데, 계속 반복 사용하고 있다. "강력함과 단순함, 표현력과 가독성, 학습과 전문 개발에 모두 탁월한 기능: 이것이 오늘날의 오브젝트 파스칼의 특징이다." "모바일 시대를 포용하는 컴파일러와 개발 도구를 갖춘 다재 다능한 도구” 미래를 위해 준비됨과 동시에 과거에 단단한 뿌리를 둔 언어 내가 전하고 싶었던 내용은 여기 까지다. 다시 한번 이 상을 받게 되어 영광이다. 파스칼과 델파이 그리고 내 인생에 대한 이 이야기가 여러분이 새로운 것을 배우는 데 도움이 되었기를 바란다.
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.