“그렇다면 이런 AI 에이전트 자체를 Delphi로 만들면 어떨까?”

이번에 소개하는 PasClaw는 이 질문에 직접 도전하고 있는 흥미로운 오픈소스 프로젝트이다. 이번 영상은 PasClaw의 제작자인 Eli M.이 직접 보내온 것이다. PasClaw가 무엇인지, 어떻게 만들어졌는지, 어떤 기능을 갖고 있는지, 그리고 개발 과정에서 어떤 실험을 해 왔는지를 약 35분 동안 소개한다.

Eli는 이 영상에서 PasClaw의 기능을 소개하는 데만 그치지 않고, 어떤 기술을 사용했고 왜 그렇게 구현했는지도 설명한다. Code Vault를 이용해 기존 Delphi 코드를 AI가 참고하도록 하는 방법, 로컬 LLM과 RAG를 활용하는 방법, MCP와 Skills를 연결하는 방법 등도 소개한다.

FireMonkey로 만든 PasClaw Desktop, WebLLM과 WASM을 이용한 브라우저 실행, 여러 장치를 연결해 AI 작업을 하는 분산 AI 실험 등도 보여준다.

마지막 데모에서는, Delphi와 VCL/FMX를 비교하는 작은 애플리케이션을 만들어 보는 과정을 볼 수 있다. 사용자가 만들고 싶은 애플리케이션을 PasClaw에서 설명하면 AI가 웹 검색을 하고, 필요한 정보를 찾아보고, HTML 애플리케이션을 만들어 낸다. 그 HTML 애플리케이션은 웹 브라우저뿐 아니라 PasClaw Desktop 안에서도 실행된다.

제작자가 이야기하는 미래의 개발 방식은 매우 단순하다. “소프트웨어가 필요하세요? 좋아요. 금방 만들어 드릴게요.” 그리고 이것은 단순히 완전히 새로운 프로그램을 만드는 것뿐 아니라, 기존 소프트웨어를 사용자가 자신의 필요에 맞게 수정하고 확장하는 방향으로도 이어질 수 있다고 이야기한다.

이 비디오는 Kai Summer Wave 이벤트 시리즈 5일차 세션에서 1시간 40분 지점부터 약 35분 간 소개되었다. 그 영상을 한국어로 더빙했다.

"AI를 Delphi 개발에 어떻게 활용할 것인가?”라는 질문에 대한 답을 찾고 있다면, PasClaw은 직접 실험해 보고, 배우고, 아이디어를 얻을 수 있는 좋은 출발점이 될 수 있다.

PasClaw을 만든 주 기여자, Eli M.

Eli M.은 FMX Express를 통해 활동하고 있는 Delphi 개발자이다.

FMX Express는 Delphi와 C++Builder의 FireMonkey(FMX)를 이용한 크로스플랫폼 개발을 중심으로 다양한 팁과 샘플, 프로젝트를 소개해 온 개발자 사이트이다. Android, iOS, macOS, Windows, Linux 등 다양한 플랫폼을 대상으로 한 FireMonkey 개발 사례를 다루고 있다.

현재 FMX Express의 GitHub 조직에는 다양한 저장소가 공개되어 있으며, FireMonkey 크로스플랫폼 샘플뿐 아니라 AI 관련 프로젝트도 찾아볼 수 있다. PasClaw 역시 FMXExpress 조직의 대표적인 오픈소스 프로젝트로 공개되어 있다.

Eli는 Delphi-PRAXiS에서 PasClaw을 직접 소개하면서, TypeScript나 Rust, Go 개발자들이 강력한 AI 에이전트를 만들고 있다면 Delphi 개발자도 그렇게 할 수 있어야 한다는 취지로 프로젝트의 목표를 설명했다. 그리고 그 결과물이 바로 PasClaw이다.

PasClaw은 무엇인가?

PasClaw는 Delphi/Object Pascal로 만들어진 AI 에이전트 프레임워크이다. 단순히 LLM API에 질문을 보내고 답을 받아오는 프로그램이 아니다. 여러 LLM과 연결할 수 있고, Embarcadero Kai의 로컬 엔드포인트로도 사용할 수 있다. MCP 클라이언트와 서버 역할을 모두 수행할 수도 있다.

에이전트가 작업을 수행할 수 있도록 도구 호출, 메모리, Skills, 세션, MCP, 워크플로, 여러 LLM 제공업체 연결, HTTP API 등 다양한 기능을 갖추고 있다. 현재 공개된 저장소에서도 CLI, TUI, Web UI, MCP, OpenAI 호환 API, Skills, 스케줄링, 채널 연동 등을 확인할 수 있다.

PasClaw 프로젝트에서는 Delphi로 AI 에이전트를 만들고, 그 AI 에이전트를 이용해 다시 Delphi 애플리케이션을 만드는 흥미로운 개발 사이클이 실제 프로젝트에서 이루어지고 있다. 예를 들어, PasClaw용 Delphi FMX 클라이언트는 Embarcadero Kai가 만들었으며, PasClaw Studio 역시 Kai에게 제작하도록지시한 결과물이다.

관련 링크

35분 동안 제작자의 시연과 설명을 한국어 더빙으로 편하게 볼 수 있다. 위 내용 중 하나라도 관심이 간다면 아래 영상을 시청해 보기 바란다.

• 한국어 더빙 영상 보기
• PasClaw GitHub 저장소: https://github.com/FMXExpress/PasClaw
• FMX Express 웹사이트: https://www.fmxexpress.com/

• 제목: How Exotic Is C++Builder 13?
• 작성자: Volker Hillmann - 2026년 10월
• 링크 https://blogs.embarcadero.com/how-exotic-is-cbuilder-13/

C++Builder(C++빌더)는 더 넓은 C++ 세계 안에서 종종 일종의 이색적인 존재처럼 취급된다. 때로는 웃으면서 하는 말이고, 때로는 꽤 진지하게 하는 말이다. 그 뒷면에는 더 근본적인 질문이 놓여 있다. 다른 곳에서는 흔해진 라이브러리, 도구, 작업흐름 가운데 상당수를 쉽게 쓸 수 없다면, 그 개발 환경은 과연 얼마나 C++ 생태계에 속한다고 할 수 있을까?

나에게는, 이 질문은 처음에 보이는 것보다 더 깊은 의미가 있다.

C와 C++는 수많은 프로그래밍 언어들에 볼 수 있는 그저 그런 두 가지가 아니다. 현대 IT 인프라의 상당 부분이 (직접적으로든 간접적으로든) 이 두 언어 위에 세워져 있다. 운영체제, 데이터베이스, 네트워크 스택, 컴파일러, 그래픽 시스템, 런타임, 암호화, 수많은 기반 라이브러리 등은 이 생태계가 없었다면 우리가 아는 형태로 존재하기 어려웠을 것이다.

그래서 curl, zlib, OpenSSL, PostgreSQL, Skia, Boost 같은 프로젝트는 어쩌다 프로젝트에 유용할 수 있는 선택적인 도구가 아니다. 이 가운데 상당수는 다른 프레임워크, 프로그래밍 언어, 애플리케이션이 설 수 있도록 하는 기술적 토대의 일부다.

나는 여기에서 C++의 핵심적인 강점 하나를 본다. 이 언어는 활용 범위가 엄청나게 넓다. 운영체제, 메모리, 하드웨어에 가깝게 작업할 수 있고, 검증된 C API를 직접 사용할 수 있다. 동시에 템플릿, Concepts, Ranges, 제네릭 아키텍처로 고도로 추상적인 모델도 만들 수 있다.

이런 폭넓음은 가끔 과소평가되는데, 이는 추상화라는 개념이 Python 등 다른 고수준 언어와 더 강하게 연관되어 있기 때문이다. 하지만, 나는 그런 구분이 오해를 부른다고 생각한다. 현대 C++의 추상화는 Python 등 다른 고수준 언어 뒤에 숨을 필요가 없다. 진짜 강점은 저수준 인프라부터 고도로 추상적인 애플리케이션 모델에 이르기까지 하나의 언어 안에서 계속 개발할 수 있다는 점이다. 즉, 도중에 C++ 언어의 경계를 넘어 다른 언어로 가느라 타입, 메모리, 런타임 동작, 기반 시스템에 대한 통제력을 갑자기 잃는 일이 없다.

우리의 adecc 라이브러리가 이러한 접근 방식을 보여주는 한 가지 예다. adecc는 현대적인 C++ 개념을 데이터 접근, 모델, 사용자 인터페이스와 연결한다. 이것이 제공하는 추상화 수준을 통해 전통적인 보일러플레이트의 상당 부분이 제거될 수 있다. 하지만 이런 추상화가 진정으로 의미를 가지려면, 그저 고립된 자기만의 세계에 머물러서는 안된다. 기존 IT 환경에 직접 연결될 수 있을 때 비로소 정말 흥미로워진다.

그래서 오픈소스 생태계에 접근하는 일은 중요하다.

만약 내가 curl, OpenSSL, PostgreSQL, XML 파서, PDF 라이브러리, 그래픽 시스템 등 수많은 빌딩 블록을 직접, 그리고 내 통제 아래 사용할 수 있다면, 단순히 개별 기능 몇 가지를 얻는 것 이상의 가치를 얻을 수 있다. 즉, 내가 만든 추상화를 기존 IT 세계의 상당 부분과 직접 연결할 수 있는 능력을 얻게 된다.

그리고 바로 그 지점에서 이 이야기가 시작되었다.

목차

• 시작은 라이브스트림이었다
• 8월: 가능하다는 것을 증명하기
• 9월: 증명에서 재현 가능성으로
• BuildEngine: 단순한 빌드 스크립트가 아니다
• 겉모습이 아키텍처보다 중요해질 때
• 이 시스템이 눈에 보이도록 만들기
• 진짜 통합 문제들을 해결하기
• 패치, XML, 통제된 빌드 정의
• 라이브러리는 바이너리 그 이상이다
• 빌드 시스템에서 출발해 사용할 수 있는 생태계로
• 간극 메우기: 빌드에서 출발해 바로 사용할 수 있는 패키지로

시작은 라이브스트림이었다

8월 첫째 주에 진행한 C++ 라이브스트림 중 하나에서, 우리는 Visual Studio 프로젝트를 작업하고 있었다. 그 프로젝트에는 curl, zlib, nlohmann-json이 필요했다. 그 환경에서는 이 작업이 거의 평범한 일이었다. 라이브러리는 빠르게 설정되고 통합되었다. 그래서 우리는 그냥 다음 단계로 넘어갈 수도 있었다.

하지만, 그 대신, 토론이 C++Builder 13으로 옮겨갔다.

왜 C++Builder에서는 같은 과정이 이렇게 간단하지 않을까? 다른 C++ 환경에서는 당연해진 인프라가 왜 C++Builder에서는 그와 같이 자연스러워지지 않았을까? C++Builder가 이름에 C++를 달고 있고 이제 최신 Clang 기반 도구체인을 사용한다면, 주변 C++ 세계도 똑같이 쉽게 닿을 수 있어야 하지 않을까?

내 즉각적인 답은 꽤 분명했다. 이 라이브러리들은 GetIt(겟잇) 패키지 매니저에 들어 있어야 한다. 그것들은 Embarcadero(엠바카데로)가 제공하고 유지보수해야 한다 라는 것이 내 주장이었다.

이 관점은 Embarcadero 생태계 자체를 살펴보면서 더욱 강해졌다. Delphi(델파이)도 이 기술적 토대에서 결코 떨어져 있지 않다. Embarcadero의 프레임워크와 라이브러리 역시 C와 C++ 세계에서 유래한 기술을 사용한다. 직접 사용하기도 하고, Delphi로 포팅한 형태로 사용하기도 하고, 둘을 섞은 형태로 사용하기도 한다.

그 자체에 본질적으로 잘못된 점은 없다. 오히려 이 인프라가 얼마나 바탕이 되는 지를 증명한다. 하지만 나에게는 분명한 의문도 하나 생긴다. C++Builder 개발자가 원본 C나 C++ 라이브러리에 Delphi 계층을 거쳐 접근해야 하는 이유가 무엇일까? 그 라이브러리를 C++에서 직접 사용할 수 있는 경우에도 말이다.

만약 검증된 C나 C++ API를 제공하는 라이브러리가 있다면, 나는 그 타입, 도움말 문서, 예제, 커뮤니티를 직접 사용하고 싶다. 원본 프로젝트의 새 버전을 직접 따라가고 싶다. 언제 추가 추상화 계층이 따라잡는 지에 의존하지 않고 싶다.

그러다 보니, 라이브스트림에서의 논의는 편의성의 문제를 넘어섰다. 논의는 훨씬 더 단순하면서도 더 어려운 질문으로 이어졌다. 내 기대가 기술적으로 현실적인가?

Embarcadero에 이 라이브러리들을 제공해 달라고 요청하기 전에, 나는 현재의 도구체인를 사용해 이 라이브러리들을 실제로 빌드할 수 있는지 알고 싶었다.

그것이 첫 번째 프로젝트가 되었다.

8월: 가능하다는 것을 증명하기

첫 번째 프로젝트의 목적은 일부러 좁게 잡았다. 최신 오픈소스 라이브러리를 C++Builder 13과 그 bcc64x 도구체인으로 안정적으로 빌드할 수 있는지 보여 주는 것이 전부였다.

나는 새로운 패키지 매니저를 만들려던 것이 아니었다. 영구적인 써드-파티(Third-Party) 인프라를 구축하려던 것도 아니었다. 목표는 증명이었다.

간단하게 들리지만 그렇지 않았다.

대형 오픈소스 라이브러리를 포팅하려면 컴파일러를 고르고 빌드 버튼을 누르는 것보다 훨씬 많은 일이 필요하다. 빌드 시스템을 이해해야 하고, CMake 로직을 따라가야 하고, 컴파일러 감지 방식을 분석해야 하고, 플랫폼별 분기를 살펴봐야 한다. 의존성, 생성되는 소스, 때로는 여러 겹으로 중첩된 빌드 시스템도 이해해야 한다. 또한 어느 시점에는 C와 C++ 경험도 충분히 있어야 한다. 즉, 빌드 끝에 표시되는 오류 메시지의 실제 원인은 개념적으로 여러 층 떨어진 곳에 있을 수 있음을 알아볼 수 있어야 한다.

이런 일은 모든 C++Builder 개발자들이 반드시 해야 하는 일이 아니다. 모든 개발자가 할 줄 알아야 하는 일도 아니다. 오히려 정반대다. 데이터베이스, 그래픽 라이브러리, 암호화 컴포넌트가 필요한 개발자는 그 뒤에 있는 빌드 체계 전체의 전문가가 먼저 되지 않아도 그것을 쓸 수 있어야 한다.

하지만 그렇게 하는 길이 기술적으로 열려 있음을 증명하려면, 먼저 그 일을 내가 직접 해야 했다.

그 이유 때문에, 나는 그 실험을 편리한 몇 가지 예제로만 한정하지 않았다. Boost 1.92가 첫 라운드에 포함되었다. OpenGL, SDL2, Raylib도 마찬가지였다. Skia는 내 도전을 상당히 어렵게 만들었다. 왜냐하면, Skia는 목록 속에 있는 라이브러리 하나 수준이 아니기 때문이다. Skia에는 내부와 외부 의존성이 복잡하게 얽혀 있다. 추가 도구들이 있고, 컴파일러, 플랫폼, 빌드 시스템에 대한 그 스스로의 고유한 가정이 있다.

8월 말까지 우리는 스무 개가 넘는 라이브러리를 성공적으로 빌드했다. 내부 의존성까지 센다면 실제로 관련된 오픈소스 환경은 그보다 상당히 더 많다.

거기까지 가는 길은 결코 순탄하지 않았다.

기쁜 순간도 있었다. 몇 시간, 길게는 며칠에 걸친 조사 끝에 라이브러리가 마침내 깔끔하게 빌드되어, 근본적인 아이디어가 옳았음을 확인해 준 때였다. 힘든 순간도 있었다. 처음에는 거의 이해가 되지 않던 실패에 여러 시간을 쏟은 때였다.

가장 답답했던 경우 중에는 프로젝트가 Borland나 Embarcadero 관련 매크로를 정확하게 감지해 놓고도 결과적으로는 완전히 잘못된 동작을 하는 경우가 있었다. 오래된 호환성 코드가 컴파일러에 특화된 경로를 활성화했는데, 그 코드는 사실 완전히 다른 세대의 도구체인을 위해 작성된 것이었다.

언뜻 보면 합리적으로 보인다. 프로젝트는 Borland나 Embarcadero를 감지하고 그에 해당하는 분기를 선택하기 때문이다. 하지만, 이 도구체인의 역사와 전처리기 로직을 자세히 따라가 보아야 비로소 분명해지는 사실이 있다. 최신 bcc64x는 기술적으로 현재의 Clang에 훨씬 더 가깝다는 사실이다. 그 경로들을 선택하는 옛 컴파일러보다 훨씬 더 Clang 에 가깝다.

나는 정확히 그런 상황에서 여러 시간을 보냈다. 가끔은 가정을 의심해 보았고, 때로는 처음에 유망해 보였던 접근을 버리기도 했다. 하지만 그 덕분에 성공한 빌드 하나하나가 더 의미 있어졌다. 성공할 때마다, 근본적인 문제는 C++ 자체도, 컴파일러의 기본 능력도 아니라는 점이 확인되었기 때문이다.

어려움은 대개 역사의 무게에서 나오는 것들이었다.

바로 그 이유 때문에, 나는 이 증명을 완성하고 싶었다.

주변 라이브러리 세계에 접근하기가 다른 도구체인보다 어렵다는 이유만으로 C++Builder를 이색적으로 봐야 한다는 생각을 나는 받아들이고 싶지 않았다. 최신 C++Builder가 기술적으로 C++ 생태계에 속한다고 믿었기 때문이다. 그 점을 보여 주고 싶었다. 장난감 같은 예제가 아니라 실제 프로젝트로 말이다.

8월 말에, 내 입장에 대한 증명이 완성되었다.

C++Builder는 현대 오픈소스 세계와 근본적으로 단절되어 있지 않다. 많은 프로젝트들이 맞춤 수정이 필요하고, 일부 빌드 시스템들은 보정이 필요하며, 소스 안의 일부 가정들은 실제 도구체인과 맞지 않다. 하지만 그 생태계에 닿을 수는 있다.

그래서, 이 프로젝트는 개인적인 실험 이상으로 커졌다.

이 프로젝트는 Embarcadero를 향한 행동을 요구하는 촉매가 되었다.

나는 공개적으로 이야기만 한 것이 아니다. 이메일도 썼고 답장도 받았다. 그 소통에 대해서는 여기서 이야기하고 싶지 않다. 핵심이 개별 답변들보다 더 중요하기 때문이다.

기술적 증명은 마쳤다.

될 수 있다.

나에게 이것은, 유지보수되는 제공 형태가 미래에 등장하지 못할 근본적인 기술적 이유가 없다는 뜻이다. GetIt이나 다른 적절한 인프라를 통해서든 말이다.

나는 지금도 이 점이 전략적으로 중요하다고 믿는다. 최신 C와 C++ 오픈소스 생태계에 직접 접근하는 일은 단순히 패키지를 더 추가하는 문제가 아니다. C++Builder가 더 넓은 C++ 세계 안에서 얼마나 자연스럽게 자리 잡을 수 있는지에 영향을 준다.

이것이 첫 번째 결론이었다.

두 번째 결론은 덜 편안했다.

증명은 통했다.

구조는 그렇지 못했다.

9월: 증명에서 재현 가능성으로

8월 말이 되자 첫 번째 프로젝트에는 CMake 조정들, 특수 파라미터들, 배치 파일들, 패치들, 보조 도구들, 프로젝트별 조치들이 쌓여 있었다. 증거를 위한 프로젝트로서는 그래도 괜찮았다. 그것의 목적은 그 길이 기술적으로 열려 있음을 증명하는 것이었기 때문이다.

하지만 장기적인 해결책이라고 받아들여 질 수는 없었다.

라이브러리를 한 번 성공적으로 빌드하는 것과, 몇 달 뒤에 다른 머신에서, 버전이 바뀐 뒤에도, 같은 정의된 전제 조건으로 똑같은 결과를 재현할 수 있는 것 사이에는 근본적인 차이가 있다.

증거(evidence)는 재현 가능성(reproducibility)이 되어야 했다.

바로 그래서, 9월에 두 번째 프로젝트가 시작되었다.

이 증명 프로젝트에서 시작되어 결국 무언가가 다른 곳에서 나타나는지 기다려 볼 수도 있었다. 하지만 나는 그러고 싶지 않았다. 우리의 프로젝트를 위해 이 인프라가 필요했고, 첫 번째 프로젝트가 이미 기술적 기반이 존재한다고 보여 준 상태였다.

그래서 나는 다시 시작했다.

예전 스크립트들을 확장하는 방식이 아니었다. 재현 가능한 빌드들을 위한 시스템을 설계하는 방식이었다.

그 시스템은 BuildEngine이 되었다.

BuildEngine: 단순한 빌드 스크립트가 아니다

BuildEngine 자체는 C++Builder로 작성되었다. 또한 이미 오픈소스 세계의 일부를 사용하고 있다. 그 통합 대상들은 애초에 이 논의를 시작하게 만든 것들이다.

그 핵심에는 유한 상태 기계(finite state machine, FSM)가 있다. 하지만 FSM은 아키텍처의 한 부분일 뿐이다.

각 라이브러리는 일련의 정의되어 있는 상태들을 거친다. 검증된 다운로드로 시작해, 소스 준비, 패치 적용, 구성, 빌드, 테스트, 설치, 게시, 문서화로 이어진다. 그래서 이 시스템은 더 이상 명령어 목록을 서술하지 않는다. 이 시스템은 상태, 의존성, 어떤 상태가 유효한지를 결정하는 증거 등을 모델링한다.

이와 함께, 이 엔진은 작업이 동시에 실행되도록 설계되었다.

여러 워커(worker)들이 서로 독립적인 작업을 병렬로 처리한다. 한편, 별도의 쓰레드 하나는 여러 빌드 시스템들이 만들어내는 출력을 분석하고, 그것을 줄여 통제된 콘솔 표현을 만든다. 기반 빌드 시스템이 병렬 실행을 지원하는 경우에는 BuildEngine도 그것을 활용한다. 동시에 실행할 수 있는 테스트 스위트(suite)들도 마찬가지다.

그래서 이 시스템에는 병렬성이 여러 층으로 존재한다. 그러면서도 무슨 일이 벌어지는지에 대한 통제력은 포기하지 않고 가지고 있다.

테스트 수행 역시 나에게 똑같이 중요해졌다.

프로젝트가 업스트림 테스트들을 제공하면 우리는 언제나 그 테스트들을 실행한다. 나는 라이브러리 하나가 그저 컴파일되고 링크되었다는 사실만으로는 만족한 적이 없다. 테스트가 실패하면 그 이유를 이해하고 싶었다. 테스트는, 우리 환경에서 의미 있게 실행되지 못한다는 분명한 기술적 이유가 있을 때만 제외했다. 예를 들어 진짜로 Linux 전용일 때 제외했다.

그런 고집에는 시간이 들었고, 때로는 아주 많이 들었다. 하지만 그것이 결과물의 품질을 바꿔 놓았다. 빌드에 성공했다는 것은 컴파일러가 코드를 받아들였다는 것만 알려 준다. 업스트림 테스트 스위트에 성공하면, 훨씬 더 많은 것을 알 수 있다. 그래서 만든 사람들의 의도대로 결과 라이브러리가 동작하는지에 대해 파악할 수 있다.

그런데도 이 모든 것은 처음에 아주 단순한 겉모습 뒤에 숨겨져 있었다.

BuildEngine은 콘솔 애플리케이션이었다.

겉모습이 아키텍처보다 중요해질 때

겉보기에 단순한 이 사실은 또 다른 유형의 논의를 불러왔다.

C++를 비판하는 몇몇 사람들은 콘솔 인터페이스를 보고는 그것을 곧바로 낡은 기술과 연결지었다. 그런 시각에서 콘솔 프로그램은 거의 구식이라고 정의된다.

그런 반응은 많은 것을 드러낸다는 생각이 들었다.

그 콘솔 뒤에는 상태 기반 시스템이 있었다. 여러 워커, 층층이 쌓인 병렬성, 비동기 출력 분석, 의존성 추적, 자동 패치, 테스트, 증거 평가, 써드-파티 환경 전체의 재현 가능한 생성이 모두 그 안에 있었다.

하지만 겉모습만 보고 첫 판단을 내리게 된다면, 그 어느 것도 보이지 않는다.

이 차이는 나에게 중요했다. C++ 자체를 둘러싼 더 넓은 긴장을 반영하기 때문이다. C++는 때로 눈에 보이는 전통들을 통해 평가받는다. 최신 C++가 실제로 무엇을 표현할 수 있는지, 그것으로 만든 시스템이 실제로 무엇을 할 수 있는지는 평가에서 빠진다.

나에게는 껍데기보다 내용이 더 중요하다.

그래도 그 비판에는 쓸모 있는 효과가 하나 있었다.

BuildEngine 세계를 얼마나 숨겨 두어야 하는지 나 자신에게 묻게 되었기 때문이다.

그래서, Server와 Manager가 나오게 되었다.

이 시스템이 눈에 보이도록 만들기

BuildEngine Server가 가능해진 이유는 BuildEngine 자체가 가능해진 이유와 정확히 같다. 이미 우리만의 통제된 생태계 안으로 가져온 라이브러리들을 사용했기 때문이다.

이 점은 나에게 중요하다. Server는 어쩌다 빌드 시스템 옆에 놓이게 된 웹 프런트엔드가 아니기 때문이다. BuildEngine Server 자체는, 우리가 구축한 라이브러리들이 실제 애플리케이션에서 사용될 수 있다는 사실을 증명한다.

HTTP와 서버 쪽에서는 boost::beast를 사용할 수 있고, curl, OpenSSL, nlohmann-json, pugixml도 함께 쓴다. 압축과 아카이브 처리는 zlib, 다른 압축 라이브러리, libarchive를 기반으로 한다. 마크다운 처리에는 cmark-gfm을 사용한다. 구문 강조, Mermaid, MathJax는 해당 JavaScript 패키지들을 통해 통합된다.

그 결과물은 웹 콘텐츠를 보여 주는 서버 이상이다. BuildEngine이 만들어낸 오픈소스 스택이 실제로 동작하며 통합된 형태다.

이로써 순환 고리의 또 다른 부분이 닫힌다. 더 이상 이 라이브러리들은 시스템이 만든 결과물(artefact)에 머물지 않는다. 다음 세대 도구가 세워질 수 있는 토대이기도 하다.

BuildEngine Server는 BuildEngine이 만든 정보를 노출한다. 그래서 탐색하고, 검사하고, 재사용하고, 배포할 수 있도록 한다.

그 일부가 도움말 문서다.

이 서버는 마크다운을 처리하고, 구문 강조, Mermaid 다이어그램, MathJax를 통합한다. 여기에 목차 기능, 내비게이션, 전용 인쇄 보기도 더한다. 그래서 빌드 지침, 아키텍처 문서, 라이선스, 기술 설명, 다이어그램, 수식이 하나의 일관된 도움말 문서 환경의 일부가 될 수 있다.

이것은 보여 주기 위한 기능처럼 보일 수 있다. 하지만 더 깊은 목적이 있다. 재현 가능성은 바이너리 아티팩트만의 문제가 아니다. 그 아티팩트를 둘러싼 지식을 접근할 수 있고 이해할 수 있게 만드는 일도 포함한다.

BuildEngine Server는 라이브러리 전체 환경에 대한 REST API도 제공한다.

그러면 다른 도구도 이 정보에 접근할 수 있다. 라이브러리, 버전, 의존성, 메타데이터가 더 이상 하나의 사용자 인터페이스 안에 갇혀 있지 않기 때문이다. 이 서버는 이미 선택한 라이브러리들을 그 의존성과 함께 패키징해서, 만들어진 번들을 다운로드로 제공할 수 있다.

BuildEngine Manager는 문제의 또 다른 부분을 다룬다.

이 도구의 사용자 인터페이스는 일부러 VCL을 사용해 작성했다.

이 선택은 의도적이다. 나는 C++Builder를 관련 없는 프런트엔드 기술 뒤에 숨기고 싶지 않다. 이 환경이 최신 C++ 개발을 할 수 있다면, 그 주변 도구들도 그 점을 직접 보여 줄 수 있어야 한다.

Manager의 작업 중 하나는 보안 점검 결과를 다루는 것이다. 알려진 보안 이슈에 대한 정보를 읽어 온다. CVE와 기타 점검 결과를 검토하고 분류할 수 있게 해 준다. 또한 그 평가를 저장해서, 영향을 받는 라이브러리들의 정보와 함께 배포할 수 있도록 한다.

이 영역에서는 그래픽 인터페이스가 정말 유용하다. 빌드 시스템은 보안 정보를 자동으로 수집하고 연관지을 수 있다. 하지만 어떤 점검 결과가 관련이 있는지, 수용할 만한지, 완화되었는지, 조치가 필요한지는 결국 사람이 판단해야 한다.

Manager가 그 계층을 제공한다.

이 지점에서 프로젝트를 둘러싼 상호작용이 특히 흥미로워진다.

한쪽에는 C++Builder 개발자들이 있었다. 이들은 이 생태계가 존재해야 하는지에 대한 이론적인 논쟁에 관심이 없었다. 이들은 해결책을 원했다. 쓸 수 있는 라이브러리, 예측 가능한 빌드, 모든 개발자가 같은 도구체인 문제를 처음부터 다시 발견하지 않아도 되는 길이 필요했다.

다른 쪽에는 C++ 비판자들이 있었다. 이들은 눈에 보이는 겉모습을 재빨리 판단했다. 그 아래에 있는 아키텍처와 엔지니어링의 규모는 이들에게 보이지 않는다.

두 반응은 서로 다른 방식으로 프로젝트에 영향을 주었다.

첫 번째 그룹은 이 작업이 왜 필요한지를 확인해 주었다.

두 번째 그룹은 좋은 엔지니어링이 늘 저절로 설명되지는 않는다는 점을 일깨워 주었다.

진짜 통합 문제들을 해결하기

라이브러리 속으로 깊이 들어갈수록, 반복되는 기술적 패턴이 더 뚜렷해졌다.

통합 문제의 상당 부분은 C++Builder가 근본적으로 라이브러리를 컴파일하지 못하기 때문에 생기는 게 아니다. 프로젝트가 도구체인을 잘못 분류해서 생긴다.

bcc64x는 Clang을 기반으로 한다. 동시에 호환성 정의와 구조도 존재한다. 이것들은 GNU나 MinGW 환경을 닮았다. 몇몇 프로젝트는 이런 특성 중 하나를 감지하고는 곧바로 MinGW를 다루고 있다고 결론짓는다. 그런 다음 실제 환경과 맞지 않는 빌드 경로를 활성화한다.

실제 조합은 더 흥미롭다. 최신 Clang 컴파일러가 있고, GNU와 비슷한 C++ 표준 라이브러리 환경이 있고, 동시에 Windows 런타임과 UCRT가 있다. Embarcadero가 배포하는 환경에는 고유한 특성도 있다. 여기에는 문제가 되는 임포트(import)도 포함된다. 이것은 이미 우리가 부트스트랩 과정에 통제된 방식으로 바로잡고 있다.

위의 이유들 때문에, 개별 라이브러리 빌드가 시작되기 전에 핵심적인 조정이 이루어진다. 그 목적은 bcc64x를 MinGW로 바꾸는 것이 아니다. 써드-파티 프로젝트들이 개별 호환성 표시를 바탕으로 도구체인을 잘못된 분기로 몰아넣지 않도록 하는 것이다.

라이브러리 소스에 남아 있는 옛 Borland 지원에도 같은 원칙이 적용된다. 기존 호환성 코드가 오히려 최신 빌드를 깨뜨리는 원인인 경우가 가끔 있다. 그 코드가 현재의 bcc64x와 닮지 않은 컴파일러 세대를 기술하고 있기 때문이다.

이 패턴들을 이해하자, 모든 실패들을 고립된 개별 문제로 다루는 일을 멈출 수 있었다.

그 패턴들은 인프라의 일부가 되었다.

패치, XML, 통제된 빌드 정의

여전히 실제 소스 변경이 필요한 라이브러리들이 있다.

그 변경은 수작업 수정이 아니다.

필요한 패치는 빌드 정의의 일부다. 패치는 버전 관리되고, 검증되고, 자동으로 적용된다. 그래서 이 시스템은 어떤 수정이 어떤 라이브러리 버전에 속하는지, 어떤 조건에서 필요한지를 알고 있다.

그렇기 때문에, 동작하는 소스 트리는 더 이상 개인의 기억이나 수작업 편집의 결과물이 아니다. 정의된 소스로부터 다시 만들어낼 수 있다.

작업흐름에도 같은 원칙이 적용된다.

나는 이 두 번째 프로젝트가 끊임없이 늘어나는 스크립트들의 모음이 되는 것을 원하지 않았다. 그래서 개별 라이브러리들의 프로세스와 파라미터들을 XML로 선언적으로 서술한다.

이 서술은 패키지가 어디에서 왔는지, 어떤 버전을 쓰는지, 다운로드를 어떻게 검증하는지, 어떤 의존성이 있는지, 어떤 준비 단계가 필요한지, 어떤 패치를 적용하는지, 각 단계를 어떻게 실행하는지를 정의한다.

두 번째 XML 서술은 전체 빌드 환경을 정의한다.

이 시스템은 일부러 CMake로 한정하지 않았다. 실제 오픈소스 세계는 서로 다른 빌드 시스템을 사용한다. 그래서 BuildEngine은 Meson과 MPC도 다룬다. Python과 Perl은 프로젝트가 필요로 하는 곳마다 환경의 통제된 일부가 된다.

나는 CMake 엔진을 만들고 싶지 않았다.

나는 오픈소스 환경을 재현할 수 있는 엔진을 원했다.

라이브러리는 바이너리 그 이상이다

이 프로젝트는 라이브러리가 언제 정말로 완성되는가에 대한 나의 이해도 바꿔 놓았다.

처음에는 링크에 성공하는 것이 성과였다.

이제는 그것만으로 충분하지 않다.

빌드가 끝나면 아티팩트가 정의된 구조 안에 설치되고 게시된다. 라이선스 정보가 발견되어 추가되고, 소스의 출처와 버전은 추적 가능한 상태로 남으며, SBOM이 만들어진다.

전문적인 환경에서 이것은 필수다. CVE가 나타나는 순간, OpenSSL이 어딘가에서 쓰이고 있다는 사실만 아는 것으로는 충분하지 않다. 어떤 버전이 있는지, 어디에서 왔는지, 어떤 컴포넌트가 그것에 의존하는지 알아야 한다.

그 정보는 아티팩트에 속한다.

도움말 문서도 마찬가지다.

유용하고 기술적으로 가능한 경우에는, 라이브러리를 만드는 데 사용한 정확한 소스 리비전에서 Doxygen 도움말 문서를 직접 만들어낸다. 그래서 이 문서는 인터넷에 있는 관련 없는 최신 버전을 가리키지 않고, 아티팩트에 속한다.

유한 상태 기계는 이 작업이 이유 없이 반복되지 않도록 보장하기도 한다.

성공한 빌드는 그 자체로 증거다. 소스가 바뀌지 않았고 관련된 하위 상태가 여전히 유효하다면, 모든 것을 다시 빌드하는 것은 의미가 없다. 재현 가능성이 매번 모든 것을 처음부터 다시 하는 것을 뜻하지는 않는다. 기존 상태가 왜 여전히 유효한지, 또는 왜 다시 만들어야 하는지를 정확히 설명할 수 있다는 뜻이다.

이 개념은 BuildEngine에서 가장 중요한 부분 중 하나가 되었다.

빌드 시스템에서 출발해 사용할 수 있는 생태계로

8월의 증명 프로젝트의 스무 개가 넘는 라이브러리는 이제 마흔 개가 넘는 라이브러리 스택으로 커졌다. 이 환경은 네트워킹, 암호화, 압축, 데이터베이스, XML 처리, 그래픽, PDF 처리, 그 밖의 인프라에 걸쳐 있다. 여기에는 해당 의존성과 지원 도구도 포함된다.

나에게 이런 폭넓음이 중요한 이유는 원래의 증명을 훨씬 더 실용적인 것으로 바꿔 주기 때문이다.

이 라이브러리들은 시연용 아티팩트로 남겨지지 않는다. BuildEngine 생태계는 자신만의 써드-파티 스택을 사용한다. Server는 그 전환을 보여 주는 가장 분명한 예일 것이다. Server 자체가, 프로젝트 전체가 쓸 수 있게 만들려고 시작한 바로 그 라이브러리들로 만들어졌기 때문이다.

이로써 순환 고리의 또 다른 부분이 닫힌다.

하지만 가장 중요한 부분은 아직 아니다.

라이브스트림에서 시작된 논의는 라이브러리를 빌드하는 일이 얼마나 흥미로운지에 관한 것이 아니었다.

C++Builder 개발자가 그 라이브러리를 어떻게 간단히 사용할 수 있느냐에 관한 것이었다.

그래서 StackBuilder가 등장하게 되었다.

간극 메우기: 빌드에서 출발해 바로 사용할 수 있는 패키지로

StackBuilder는 게시된 아티팩트들을 가져와서, 구체적인 프로젝트를 위해 정의된 써드-파티 스택으로 조립한다.

프로젝트는 필요한 라이브러리들만이 아니라, 자신의 빌드 환경에 속하는 정확한 버전까지 지정할 수 있다. 그렇게 만들어진 스택은 패키징하고, 배포하고, 저장소에 통제된 방식으로 통합할 수 있다.

이로써 처음 논의에서 나왔던 간극이 마침내 메워진다.

개발자는 더 이상 Boost, OpenSSL, PostgreSQL, Skia, 또는 그 의존성이 어떻게 빌드되었는지 알 필요가 없다. 어려운 작업은 이미 업스트림에서, 통제되고 재현 가능한 조건 아래 끝나 있다.

프로젝트에 도착하는 것은 바로 쓸 수 있는 패키지다.

저장소는 자신이 기대하는 써드-파티 스택이 무엇인지 알고 있다. 이 스택은 정의된 형태로 제공할 수 있고, 필요할 때 복원할 수 있으며, 빌드에 직접 통합할 수 있다.

이 지점에서 이야기 전체가 한 바퀴를 돌아 제자리로 온다.

8월 초의 질문은, Visual Studio 프로젝트에서는 검증된 C++ 라이브러리를 거의 자연스럽게 쓸 수 있는데 C++Builder에서는 같은 경험이 왜 없느냐는 것이었다.

첫 번째 프로젝트는 라이브러리를 빌드할 수 있음을 증명했다.

두 번째 프로젝트는 그 지식을 재현 가능한 인프라로 바꿨다.

Server와 Manager는 이 환경을 눈에 보이게 하고, 검사할 수 있게 하고, 관리할 수 있게 만들었다. 또한 중요하게도, 라이브러리들 자체가 이미 실제 애플리케이션의 토대가 될 수 있음을 보여 주었다.

이제 StackBuilder는 그 결과를 개발자가 실제로 필요로 하는 것으로 바꿔 준다. 완성되고, 정의되고, 직접 통합할 수 있는 써드-파티 패키지다.

나에게는 이것이 여전히 프로젝트 전체의 핵심이다.

C++Builder는, 그 세계로 들어가는 길이 마땅한 수준보다 어려웠다는 이유만으로 C++ 세계의 외부인으로 취급되어서는 안 된다. 컴파일러는 그 세계에 속한다. 라이브러리는 빌드할 수 있다. 인프라는 만들 수 있다. 남은 질문은 그 세계를 개발자에게 얼마나 자연스럽게 제공하느냐이다.

그래서 Embarcadero를 향한 처음의 행동 촉구는 여전히 유효하다.

이 작업을 모든 C++Builder 개발자가 각자 따로 반복해야 해서는 안 된다. 이 개발자들에게는 해결책이 필요하고, 그것을 얻을 수 있어야 한다.

지금은 우리가 우리만의 길을 만들어 두었다. 검증된 소스에서 재현 가능한 빌드로, 테스트를 거친 아티팩트에서 도움말 문서와 보안 메타데이터로, 게시된 라이브러리에서 저장소에 바로 올릴 수 있는 써드-파티 스택으로 이어지는 길이다.

이에 대한 더 많은 정보를 곧 전할 예정이다.

원문 정보 (최종 번역일: 2026년 10월 2일):

• 제목: Building MCP Servers in Delphi with MCPConnect
• 작성자: Paolo Rossi - 2026년 9월
• 링크 https://blogs.embarcadero.com/building-mcp-servers-in-delphi-with-mcpconnect/

MCPConnect는 Model Context Protocol(MCP) 서버를 만들기 위한 프레임워크다. 엠바카데로(Embarcadero) Delphi(델파이)와 C++Builder(C++빌더)에서 사용할 수 있다. 이 프레임워크는 애트리뷰트(attribute)를 사용해 기존 Delphi 클래스와 비즈니스 로직을 MCP 도구, 리소스, 프롬프트로 바꿔 준다(C++Builder에서는 함수 기반 등록 메커니즘을 사용한다). 그래서,  기존의 Delphi 클래스와 비즈니스 로직을 MCP 도구, 리소스, 프롬프트로 바꿔준다. 한편, MCP 프로토콜의 서버 쪽의 직렬화, 라우팅, 컨텍스트 관리를 이 라이브러리가 맡아서 처리해 준다.

MCPConnect는 Paolo Rossi와 Luca Minuti가 개발했다. 오픈소스로 공개되어 있으며 MIT 라이선스가 적용된다. 개발은 2025년 7월에 시작했고, GitHub 첫 커밋은 8월 12일이다. 그 후, 커뮤니티의 기여 덕분에도, 빠르게 성장해 왔다.

ℹ️ 공식 문서

MCPConnect의 전체 문서집은 mcpconnect.delphiblocks.dev에서 확인할 수 있다.

목차

• MCP 소개
• MCP 서버와 클라이언트의 아키텍처
• MCPConnect가 MCP 버전과 여러 MCP 스펙들을 다루는 방법
• 나만의 MCP 서버를 만드는 방법
• MCP 트랜스포트 프로토콜의 세부 사항
  • Stdio를 통해 Claude Desktop 그리고 다른 AI 엔진들을 내 MCP 서버에 연결하는 방법
  • MCP 통신에 Streamable HTTP를 사용하는 방법
• MCP 사용 예시: 글쓰기 도구 MCP 도구 만들기
• MCP 도구가 결과를 AI 모델에게 돌려보내는 방법
• 내 코드 안에서 MCP 세션 관리를 다루는 방법
• 맺음말 – MCP와 MCPConnect 도구에 대해 배운 내용 정리

MCP 소개

Model Context Protocol(MCP)은 2024년에 Anthropic이 도입한 프로토콜이다. 대규모 언어 모델(LLM, large language model)이 외부 시스템과 대화하는 방식을 표준화하기 위해 고안되었다. LLM은 그 자체로는 텍스트(토큰)만 만들어낼 수 있다. 외부 세계에서 직접 행동할 수 없다. 또한 학습 과정에 배운 내용만 가지고 답할 수 있다.

OpenAI는 이와 비슷한 문제를 풀려고 2023년에 "함수 호출(function calling)"를 사용하려고 했다. 대부분의 다른 벤더들도 그 아이디어를 따라 했다. 하지만 각 구현체는 자신만의 API에 묶였다. 그래서 둘 이상의 모델을 지원하려는 사람은 똑같은 통합 작업을 여러 번 반복해야 했다. MCP는 이 문제를 단일 프로토콜로 해결한다. 그래서 벤더에 중립적이다. 여러분이 서버를 한 번만 작성하면, 호환되는 모든 호스트들이 그 서버를 사용할 수 있다.

MCP의 대표적인 활용 사례는 다음과 같다.

• 데이터베이스: InterBase(인터베이스), PostgreSQL, Firebird, SQLite에게 질의해서 데이터를 분석하기
• 파일시스템: 로컬 파일을 읽고, 검색하고, 분석하기
• 브라우저 자동화: 웹 스크래핑, 자동화 테스트 수행, 웹 애플리케이션과의 상호작용
• 써드-파티(Third-Party) 서비스: Slack, GitHub, Linear, Jira 등등
• 내부 도구: LLM이 회사의 API와 시스템에 접근할 수 있도록 제공하기
• 데이터 처리: Excel, CSV, 기타 형식에 여러분만의 로직을 반영해 처리하기
• 기존 Delphi 애플리케이션: 이미 가지고 있는 코드(FireDAC 쿼리, 청구서 발행 모듈, 리포트 생성기 등)를 노출하기. 다른 언어로 다시 작성할 필요없음

MCP 서버와 클라이언트의 아키텍처

MCP 아키텍처는 세 부분으로 이루어져 있다.

• MCP 호스트: MCP를 사용하는 AI 애플리케이션이다. 예를 들면 Claude Desktop이 있다.
• MCP 클라이언트: 호스트 안에서 실행된다. 하나의 MCP 서버와 연결을 유지한다. 서버로부터 받은 데이터를 호스트로 전달한다. 호스트 안에서 여러 서버들에 연결되려면, 각 서버에 해당되는 클라이언트가 서버의 종류만큼 호스트 안에서 실행된다.
• MCP 서버: 컨텍스트를 제공하는 프로그램이다. 호스트가 클라이언트를 통해 요청을 보내면, 응답한다.

MCPConnect가 MCP 버전과 여러 MCP 스펙들을 다루는 방법

MCP는 버전이 있는 프로토콜이다. 스펙의 각 개정판은 발표일이 이름에 붙는다. 클라이언트와 서버는 연결할 때 어떤 버전을 사용할지 합의한다. 그래서 어떤 MCPConnect 버전을 고를지는, 여러분이 지원하고 싶은 스펙에 따라 달라진다.

• 2025-11-25: 엠바카데로 GetIt(겟잇)에 있는 패키지(RAD Studio의 Tools > GetIt Package Manager)는 2025-11-25 MCP 스펙을 구현한다. 안정 릴리스이며, 시작하기 가장 쉬운 방법이다.
• 2026-07-28: 2026-07-28 MCP 스펙 지원은, GitHub의 feature/mcp-2026-07-28 브랜치에서 개발되고 있다. 아직 프리릴리스 단계지만, 새 기능이 필요하다면 지금도 테스트하고 사용할 수 있다.

ℹ️ 참고

이 글의 예제는 GetIt 버전(2025-11-25)을 기준으로 한다.

나만의 MCP 서버를 만드는 방법

MCP 서버는 실제 작업을 수행하는 부분이다. 즉, 문서를 읽고, 데이터베이스 쿼리를 실행하고, 이메일이나 메시지를 보내고, 캘린더를 동기화한다.

이를 위해, MCP 프로토콜은 세 가지 빌딩 블록을 정의한다. MCPConnect는 이 세 가지를 모두 지원한다.

• 도구(Tools): LLM이 호출하겠다고 결정할 수 있는 함수들이다. 도구는 데이터베이스를 질의하거나, 외부 API를 호출하거나, 파일을 수정하거나, 기타 코드를 실행할 수 있다.
• 리소스(Resources): LLM이 요청할 수 있고, 자신의 컨텍스트 안에 추가할 수 있는 읽기 전용 데이터다. 문서, 파일, 기타 구조화된 데이터 등이 해당된다.
• 프롬프트(Prompts): 사용자가 호출할 수 있는 템플릿이다(보통 슬래시 뒤에 이름을 입력한다). 특정 작업을 위한 프롬프트를 생성한다.

만약 여러분에게 TDocumentService 클래스가 있어서, 몇 가지 도구를 구현한다면, 그 서버 구성은 다음과 같은 모습이다.

uses
  MCPConnect.JRPC.Server,
  MCPConnect.MCP.Server.Api, // 표준 MCP API를 등록하는 역할
  MCPConnect.Configuration.MCP,

  Demo.DocumentService; // 여러분의 MCP 클래스들이 담겨있는 유닛

// 해당 JSON-RPC 서버를 생성한다
FJRPCServer := TJRPCServer.Create(Self);
FJRPCServer
  .Plugin.Configure<IMCPConfig>
    .Server
      .SetName('delphi-mcp-server')
      .SetVersion('2.0.0')
    .BackToMCP
    .Tools
      .RegisterClass(TDocumentService)  // Register your tool class here
    .BackToMCP
  .ApplyConfig;

이 구성은 여러 섹션으로 나뉜다(.Server, .Tools, .Resources, .Prompts 등). .BackToMCP는 한 섹션을 닫고 MCP 구성으로 돌아간다. .ApplyConfig는 플러그인 전체를 닫고 서버로 돌아간다. 그래서 그 뒤에 또 다른 .Plugin.Configure<...>를 이어서 연결할 수 있다.

MCP 트랜스포트 프로토콜의 세부 사항

MCP 메시지는 JSON-RPC로 인코딩된다. 이 프로토콜은 두 가지 트랜스포트를 지원한다.

• Stdio: 서버가 콘솔 애플리케이션이다. 표준 입력에서 요청을 읽고 표준 출력에 응답을 쓴다. 예전 CGI와 다소 비슷하다.
• Streamable HTTP: 일반 HTTP다. 연결을 계속 열어둘 수 있는 옵션을 갖추고 있다. 그래서 서버가 폴링 없이도 클라이언트에게 알림을 보낼 수 있다.

ℹ️ 참고

2026-07-28 버전에서는, JSON-RPC 레이어가 더 이상 MCPConnect에 내장되어 있지 않다. 이제는 별도 라이브러리인 Delphi-JRPC다. Delphi-JRPC는 JSON-RPC 2.0(서버와 클라이언트 모두)을 구현한다. 더 이상, MCP에 의존하지 않는다. 그래서 MCP와 상관없이, 원격 API를 노출하거나 호출해야 하는 Delphi 애플리케이션에서 사용할 수 있다. MCPConnect는 이 라이브러리를 의존성으로 사용한다. 그리고 그 유닛들은 MCPConnect. 접두사를 잃었다(예를 들어 MCPConnect.JRPC.Server는 JRPC.Server가 된다).

MCPConnect는 둘 다 지원한다. 어떤 것을 사용할지는, 프로젝트의 종류와 개발 단계에 따라 달라진다. 예를 들어, HTTP 서버를 디버깅하는 것은 stdio 서버를 디버깅하는 것보다 훨씬 쉽다. 서버 구성은 트랜스포트에 의존하지 않는다. 그래서 같은 애플리케이션이 둘 다 지원하면서, 설정이나 커맨드라인 파라미터를 통해 하나를 고를 수 있다.

Stdio를 통해 Claude Desktop 그리고 다른 AI 엔진들을 내 MCP 서버에 연결하는 방법

stdio를 사용하면, 호스트(예를 들어 Claude Desktop)가 여러분의 실행 파일을 시작하고, 표준 입출력을 통해 그 실행 파일과 대화한다. MCPConnect 안에서 여러분에게 필요한 것은 오직 TJRPCStdioServer를 가진 콘솔 애플리케이션이다.

program DocumentServer;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  MCPConnect.JRPC.Server,
  MCPConnect.MCP.Server.Api,
  MCPConnect.Configuration.MCP,
  MCPConnect.Transport.Stdio,

  Demo.DocumentService;

var
  LServer: TJRPCStdioServer;
begin
  LServer := TJRPCStdioServer.Create(nil);
  try
    LServer.JRPCServer
      .Plugin.Configure<IMCPConfig>
        // ... 동일한 구성 (앞에 있는대로)
      .ApplyConfig;

    // 해당 클라이언트가 이 파이프들을 닫을 때 까지
    LServer.StartServerAndWait;
  finally
    LServer.Free;
  end;
end.

⚠ 경고

stdio 서버에서는, 표준 출력이 프로토콜의 몫이다. 뭔가를 로깅해야 한다면, ErrOutput이나 파일에 써야 한다. 절대로 일반 Writeln을 쓰면 안 된다.

가장 쉬운 방법은, Logify를 사용하는 것이다. MCPConnect는 이미 이 로깅 라이브러리에 의존하고 있다. Logify는 로깅 파사드(facade)다. 여러분의 코드(그리고 MCPConnect 자신도 자체 프로토콜 트레이스와 타이밍을 위해 Logify를 사용하고 있다)는 로그 기록을 단일 Logger에 한다. 실제 목적지는, 시작할 때 여러분이 등록하는 어댑터에 의해 결정된다. 예를 들어, 디버그 어댑터는 메시지를 OutputDebugString으로 보낸다. 그래서 디버깅하는 동안 RAD Studio 이벤트 로그에서 그 메시지를 읽을 수 있다. 표준 출력은 전혀 건드리지 않는다.

uses
  Logify, Logify.Adapter.Debug;

// 기동 시점: route all the log messages to OutputDebugString
TLoggerAdapterRegistry.Instance.RegisterFactory(
  TLogifyAdapterDebugFactory.CreateAdapterFactory('Debug log', TLogLevel.Debug));

// 여러분의 코드 안 어디에서든 (tools 도 마찬가지로)
Logger.LogDebug('Listing documents for category %s', [ACategory]);

디버거 밖에 로그를 남기고 싶다면, 다른 어댑터를 등록하면 된다(예를 들어 파일에 쓰는 어댑터). 로깅 코드는 그대로 유지된다. 레벨을 Debug 대신 Info로 설정하면, MCPConnect의 요청별 메시지가 숨겨진다.

MCP 통신에 Streamable HTTP를 사용하는 방법

HTTP의 경우, Indy(TJRPCIndyServer, 독립형 HTTP 서버)와 WebBroker(TJRPCDispatcher, 독립형·ISAPI·CGI WebBroker 애플리케이션용) 중에서 고를 수 있다. 다음은 Indy 버전이다.

uses
  MCPConnect.JRPC.Server,
  MCPConnect.MCP.Server.Api, // 표준 MCP API를 등록하는 역할
  MCPConnect.Transport.Indy, // TJRPCIndyServer
  MCPConnect.Configuration.MCP,

  Demo.DocumentService; // 여러분의 MCP 클래스들이 담겨있는 유닛

// 해당 HTTP server를 생성한다: it creates and owns its own JSON-RPC server
FServer := TJRPCIndyServer.CreateMCPServer(Self);

// 해당 JSON-RPC Server를 구성한다 (same code as before)
FServer.JRPCServer
  .Plugin.Configure<IMCPConfig>
    // ...
  .ApplyConfig;

// Start listening
FServer.DefaultPort := 8080;
FServer.Active := True;

CreateMCPServer는 Indy HTTP 서버를 그 TJRPCServer와 함께 생성하고, MCP 요청 처리를 연결한다. POST를 통한 JSON-RPC, 알림용 SSE 스트림, CORS, 세션, 인증이 여기에 포함된다. 서버가 활성화되면, 클라이언트는 그 주소로 연결할 수 있다. 예를 들면 http://localhost:8080/mcp다. TJRPCIndyServer는 Indy의 HTTP 서버를 상속한다. 그래서 일반적인 Indy 프로퍼티들(Bindings, DefaultPort, HTTPS용 IOHandler 등)을 모두 사용할 수 있다.

MCP 사용 예시: 글쓰기 도구 MCP 도구 만들기

MCPConnect를 사용하면, 프로토콜의 세부 사항을 다루지 않고도 MCP 서버를 작성할 수 있다. 특정 카테고리의 문서 목록을 LLM에게 제공하고 싶다고 해보자. Delphi에서는 다음과 같이 작성하면 된다.

TDocumentService = class
public
  function ListDocument(const ACategory: string): string;
end;

MCPConnect는 더 복잡한 반환 타입(TArray<TDocument>, TStringList, TImage 등)도 처리할 수 있다. 하지만 결과는 어차피 LLM의 컨텍스트 안으로 들어간다. 그래서 문자열 하나로 충분한 경우가 많다.

ListDocument가 결과를 어떻게 만드는지는 중요하지 않다. MCPConnect가 그 메서드를 LLM에게 설명해 주고, LLM이 언제 어떻게 그 메서드를 호출할지 결정한다.

하지만 그러려면, 그 클래스가 무엇을 위한 것이고 각 메서드가 무엇을 하는지 LLM에게 알려줘야 한다. MCPConnect에서는, 이 작업을 대부분 애트리뷰트(attribute)로 한다.

TDocumentService = class
public
  // 이 메서드는 published이다. 하나의 MCP tool이 된다
  [McpTool('doclist', 'List all the available documents')]
  function ListDocument(
    [McpParam('category', 'Document Category')] const ACategory: string
  ): string;

  // 이 메서드는 노출되지 "않는다" 왜냐하면 [McpTool] 애트리뷰트가 없기 때문이다
  procedure InternalStuff;
end;

McpTool과 McpParam은 두 개의 파라미터를 받는다. 이름과 설명이다. 이름은 LLM이 보는 값이다(예제에서는 doclist와 category다). Delphi 메서드나 파라미터 이름과 일치할 필요는 없다. 그래서 코드는 일반적인 Pascal 네이밍 규칙을 그대로 유지할 수 있다.

💡 팁 — 설명은 필수다

LLM은 도구나 파라미터가 무엇을 위한 것인지, 사용해야 할지, 어떻게 사용해야 할지 이해하기 위해 설명에 의존한다. 그러니 시간을 들여 잘 작성하자. 그 도구가 무엇을 하는지, 무엇을 반환하는지, 언제 사용해야 하는지를 적는다. "List all the available documents"(사용 가능한 모든 문서를 나열)도 작동은 한다. 하지만 "Returns the title and date of the documents in a category; use it before reading a document"(카테고리 안 문서들의 제목과 날짜를 반환한다. 문서를 읽기 전에 사용한다)는 LLM에게 훨씬 더 많은 것을 알려준다.

클래스가 등록되면, MCPConnect는 RTTI를 통해 이 애트리뷰트들을 읽어서, 클라이언트가 받아 LLM에게 전달하는 도구 정의를 만든다.

런타임에, LLM이 그 도구를 사용하기로 결정하면, 호출은 호스트에서 여러분의 Delphi 메서드로 갔다가 다시 돌아온다.

MCP 도구가 결과를 AI 모델에게 돌려보내는 방법

예제에서는 도구가 문자열을 반환한다. 이것으로 충분한 경우가 많다. 하지만 도구가 무엇을 하는지에 따라 달라진다. 대략적으로, 도구는 두 그룹으로 나뉜다.

• 작업형(Operational): 파일을 쓰거나, 데이터베이스 데이터를 변경하거나, 이메일을 보내는 등 무언가를 수행하는 도구다. 결과는 그 작업의 결과만으로 충분할 수 있다. 불리언 값이나, 오류를 설명하는 문자열이다.
• 정보형(Informational): 데이터를 조회해서 컨텍스트에 추가하는 도구다. 데이터에 따라, 문자열로 충분할 수도 있고, 구조화된 형식이 필요할 수도 있다.

MCPConnect가 변환을 대신 처리해 준다. 함수가 오브젝트를 반환하면, 알맞은 형식으로 자동 직렬화된다.

한 가지 경우는 자세히 살펴볼 만하다. TContentList 클래스다. 이 클래스는, MCP가 정의한 도구 결과 형식에 직접 대응한다. 그 형식에서는, 응답이 여러 부분으로 이루어질 수 있고, 각 부분은 자신만의 타입(텍스트, 이미지, 오디오, 링크, BLOB)을 가진다. TContentList는 각 타입마다 플루언트(fluent) 메서드를 가지고 있다(AddText, AddImage, AddAudio, AddLink, AddBlob).

function TDelphiDayTool.BuyTicket(AId, AQuantity: Integer): TContentList;
begin
  var LTicketStream := FCart.BuyTicket(AId, AQuantity);
  try
    // TContentList 해제는 이 프레임워크가 직렬화 후에 수행한다
    Result := TContentList.Create
      .AddText('Purchase completed successfully.')
      .AddImage('image/png', LTicketStream); // 이 스트림이 읽혀지고, base64로 인코딩된다
  finally
    LTicketStream.Free;
  end;
end;

내 코드에서 MCP 세션 관리를 다루는 방법

MCP에는 세션이라는 개념이 있다. stdio에서는 암묵적이고, Streamable HTTP에서는 명시적이다.

⚠ 경고

MCPConnect의 다음 버전(2026-07-28 스펙용)은 세션을 완전히 제거한다. 코드가 계속 작동하길 원한다면, 꼭 필요한 경우가 아니라면 고정 세션(sticky session)에 의존하지 말자. 도구를 상태 없이(stateless) 유지하고, 필요한 상태는 도구 파라미터로, 또는 여러분이 직접 저장하는 데이터를 가리키는 식별자로(예를 들어 이전 도구 호출이 반환한 카트 ID) 명시적으로 전달하자.

MCPConnect는 세션을 대신 관리해 준다. 모든 도구는 현재 세션의 데이터를 읽고 쓸 수 있다. 세션은 TMCPSessionData(데이터를 JSON으로 저장)일 수도 있고, TMCPSessionBase에서 파생된 어떤 클래스든 될 수 있다.

다음 코드는, 사용자가 주문을 만드는 동안 장바구니를 유지하는 커스텀 세션 클래스(TShoppingSession)를 구성한다.

uses
  ...
  MCPConnect.Configuration.Session,
  MCPConnect.Session.Core;

type
  TShoppingSession = class(TMCPSessionBase)
  private
    FCart: TObjectDictionary<string, TCartItem>;
  public
    constructor Create;
    destructor Destroy; override;
    property Cart: TObjectDictionary<string, TCartItem> read FCart;
  end;

begin
  ...
  FJRPCServer
    .Plugin.Configure<ISessionConfig>
      .SetLocation(TSessionIdLocation.Header) // 디펄트
      .SetHeaderName('Mcp-Session-Id') // 디펄트
      .SetTimeout(30)  // 타임아웃 30 분 (디펄트)
      .SetSessionClass(TShoppingSession)  // 사용자 정의 타입 세션(custom typed session) 사용
    .ApplyConfig;

도구 클래스 안에서는, [Context] 애트리뷰트가 붙은 필드에 현재 세션이 주입된다.

  TDelphiDayTool = class
  private
    [Context] FSession: TShoppingSession;
  public
    [McpTool('cart_clear', 'Removes all the tickets from the shopping cart')]
    procedure ClearCart;
  end;

//-----

procedure TDelphiDayTool.ClearCart;
begin
  FSession.Cart.Clear;
end;

맺음말 – MCP와 MCPConnect 도구에 대해 배운 내용 정리

MCPConnect는 아직 젊은 라이브러리다. 하지만 이미 많은 것을 다루고 있다. 이 글에서는 주요 주제들만 살짝 건드렸을 뿐이다. 전체 문서는 MCPConnect 문서에서, 소스 코드는 이 프로젝트의 GitHub 홈에서 확인할 수 있다. 저장소 안의 데모들은 다른 여러 사례를 다룬다. 각 요소들이 어떻게 맞물리는지 보기에 좋은 방법이다.

시작하려면, Demo/MCPServerSimple/Stdio에 있는 stdio 데모를 열고 Claude Desktop에 연결해 보자. 몇 분 안에, LLM이 여러분의 Delphi 코드를 호출하는 모습을 볼 수 있다.

이 글에서 다루지 않았지만 곧 다룰 예정인 MCPConnect의 다른 기능들은 다음과 같다.

• 리소스, 리소스 템플릿, 프롬프트
• MCP 앱(호스트가 렌더링하는 인터랙티브 HTML UI)
• 컨텍스트 주입(Context injection)
• 플루언트 구성(Fluent configuration)
• 가비지 컬렉션
• 도구 네임스페이싱(namespacing)
• 보안(토큰과 OAuth 인증)

이 글은 MCP Connect의 제작자인 MVP Paolo Rossi와 Luca Minuti가 기고한 게스트 블로그 글이다.

• RAD Studio 13.2 출시
• Kai 1.1.1 출시 (와 로컬 AI 구현 안내)
• Kai 1.1 출시: RAD Studio를 위한 더 연결되고, 더 유연하고, 더 강력해진 AI 경험

특집: RAD Studio 13.2

• RAD Studio 13.2 Florence 출시 웨비나 다시보기 (36min, 한국어)
• 13.2 핵심 새 기능 요약 비디오(6 min, 한국어)
• 13.2 What’s New (DocWiki 한글 번역)
• (13.2 기고 모아보기)

인기

[기고/백서] 인기글

• 여러분의 컴파일러가 LLVM 12년치 발전을 한 번에 뛰어넘는다면, 무슨 일이 벌어질까?
• RAD Studio 13.2에서 만날 새 기능: 일상적인 RAD Studio IDE 경험 향상시키기
• RAD Studio 13.2에서 만날 새 기능: 더 나아진 현대적 C++Builder Win64x 빌드 경험
• Markdown4D, 그리고 우리가 AI를 사용해 이것을 만든 방법

[인기 비디오]

• Kai 마이그레이션 데모: C++Builder 6.0 '파리잡기' 데모 게임을 13.1로
• RAD Studio 13.2 Florence 출시 웨비나 다시보기 (36min, 한국어)

[개발 사례]

• Kai Summer Wave 8월 수상작 5 개
• 믿을 수 없을 만큼 놀라운 실시간 모바일 앱이 Delphi로 탄생했다

[How to (팁, 트릭, 쇼츠 등)]

• Delphi로 만든 Linux 앱 실행 성능 비교: 13.1 vs 13.2

RAD Studio 프로모션: 데브기어에 문의하기

View full 엠바카데로 기술자료

• 제목: KAI 1.1.1: Supercharge Local AI in RAD Studio!
• 작성자: Landerson Gomes - 2026년 9월
• 링크 https://blogs.embarcadero.com/kai-1-1-1-supercharge-local-ai-in-rad-studio/

기술은 절대 멈추지 않는다. 생태계는 너무 빠르게 진화하고 있다! 오늘은, 엠바카데로가 Kai(카이)의 새 버전인 1.1.1을 출시했다는 소식을 살펴본다. 이 버전은 로컬 모델 사용을 더 향상했다. 이 글에서는, 두 세계를 어떻게 결합할 수 있는지 보여주고자 한다. 즉, '로컬 AI의 완전한 프라이버시와 제로 비용'을, 'RAD Studio 안에 직접 통합되어 있는 Kai의 강력함'과 결합하는 방법이다.

목차

• 영상: 실전 튜토리얼 전체
• 환경 설정하기: Ollama + RAD Studio
• Kai 1.1.1에서 무엇이 바뀌었을까? (기술적 업데이트)
• 실전 데모: "이 프로젝트를 설명해줘"
• 온프레미스 모델과 클라우드 모델의 장단점
• 업데이트 방법과 마무리

영상: 실전 튜토리얼 전체

"직접 해보면서 배우기"를 좋아하고, 클릭 하나하나와 설정을 눈으로 따라가고 싶은 사람들을 위해, 나는 이 모든 과정을 실제로 보여주는 상세한 영상을 준비했다. Ollama를 Kai와 함께 설정할 때 실수하지 않도록 도와주는 완전한 단계별 가이드다.

자세한 내용은 아래 영상을 참고하자.

영상에서는, 장비에서 Ollama 서비스를 실행하는 과정에서부터 그것이 RAD Studio 안에서의 실제 상호작용하는 것까지 모두 볼 수 있다. 이 영상에서 모델이 하는 일은 전체 프로젝트를 분석하고 정확한 정보를 반환하는 것이다. IDE가 로컬 모델과 함께 독립적으로 작동하는 모습을 보는 건 정말 환상적이다!

환경 설정하기: Ollama + RAD Studio

로컬 환경을 설정하는 일은 빠르고 쉽다. 지금 바로 IDE를 준비하는 방법을 보여주겠다.

1단계: Ollama 확인

먼저, Ollama가 실행 중인지 확인하자. Windows 메뉴에서 검색하거나, 시스템 트레이의 아이콘을 확인하면 된다. 확인하려면, 브라우저를 열고 다음 주소로 접속하면 된다.

http://localhost:11434

Ollama가 실행 중이라는 메시지가 뜨면, 다음 단계로 넘어갈 준비가 된 것이다!

2단계: IDE 설정

RAD Studio를 연 상태에서, 메뉴로 이동한다: Tools > Options > Kai > Chat.

3단계: 연결과 템플릿

Local Model 탭에서, 접속을 설정한다.

• 주소 입력란에 URL을 붙여넣는다: http://localhost:11434
• Test connection(연결 테스트) 버튼을 클릭한다.
• 연결되면, Kai가 설치된 모델 목록을 보여준다(내 예시에서는 Gemma 412B를 사용했다). 원하는 모델을 선택하고 저장을 클릭하면 된다. (팁: LM Studio를 사용하는 경우에도, 이 로직은 동일하다. 해당 프로그램이 제공하는 주소와 포트를 지정하기만 하면 된다!)

RAD Studio의 Kai Chat에서 Ollama 설정하기

Kai 1.1.1에서 무엇이 바뀌었을까? (기술적 업데이트)

버전 1.1.1은 비중 있는 유지보수 업데이트다. 안정성과 로컬 모델 사용 확대에 초점을 맞췄다. 새로워진 점을 살펴보자.

• 통합 강화: Ollama와 LM Studio 엔진 지원이 향상되었다. 그래서, IDE와 AI 사이의 통신이 훨씬 더 매끄러워졌다.
• 강력해진 "에이전틱" 흐름: Kai는 이제 더 긴 '도구 호출 연쇄'를 지원한다. 즉 AI가 여러 파일들을 읽고, 맥락을 분석하고, 순서대로 변경 사항들을 지능적으로 제안하는 등 복잡한 작업을 수행할 수 있다는 뜻이다.
• 향상된 신뢰성: 프로젝트 안에서 새 파일을 만들고 기존 유닛을 수정하는 작업이 크게 향상되었다.
• MCP 인터페이스 다듬기: MCP Tools 구성 페이지가 이제 긴 설명을 제대로 표시한다. "전체 선택/전체 해제" 동작도 다듬어졌다.
• 화면 조정: IDE에서 다크 테마를 사용할 때 MCP Tools의 열 머리글 표시 문제가 수정되었다. 이제 모든 것이 잘 읽히고 보기 좋다!

전문가 팁: 로컬 모델의 성능은, 하드웨어와 "컨텍스트 윈도우"에 따라 달라진다. 더 큰 모델은 더 많은 RAM/VRAM을 요구한다. 하지만 훨씬 더 깊이 있는 응답을 제공한다. 내 머신에 맞는 균형을 찾아보자.

실전 데모: "이 프로젝트를 설명해줘"

이 버전의 성능을 테스트하기 위해, 나는 놀라운 테스트를 하나 진행했다. "certificado client"라는 실제 프로젝트를 분석하는 테스트였다. 이 프로젝트는 Android용 FireMonkey 앱이다. 나는 Kai 채팅을 열고, Gemma 412B 템플릿을 사용하고 있는 로컬 세션을 선택한 다음, 다음 명령을 보냈다.

"열려 있는 프로젝트를 설명해줘. 뭐에 관한 건지 알고 싶어."

결과는 인상적이었다! 로컬 처리이기 때문에, 하드웨어가 한계까지 밀어붙여진다. 머신의 쿨러가 열심히 돌아가는 소리가 들릴 정도다! 내 테스트에서는, 처리하는 데 약 4분이 걸렸다. 클라우드와 비교하면 길게 느껴질 수도 있다. 하지만 기억하자. 이건 100% 오프라인으로 처리됐고, 코드는 완전히 비공개였으며, 토큰 비용은 0원이었다! Kai는 이 앱을 64비트 Android용 Delphi 앱이라고 정확히 식별했다. 그 기능들도 자세히 설명했다. 대단하지 않은가?

온프레미스 모델과 클라우드 모델의 장단점

아직 확신이 안 서는가? 아래의 빠른 비교표를 살펴보자.

업데이트 방법과 마무리

이 버전을 지금 바로 실행하려면, RAD Studio를 열고 GetIt 패키지 매니저로 이동하면 된다. Kai를 검색해서 버전 1.1.1을 설치하면 된다. 기억해 두자. 공식 출시일은 9월 15일이었지만, 일반 공개는 9월 25일부터 시작되었다.

이번 업데이트는, 데이터 보안을 희생하지 않으면서 AI의 장점을 최대한 누리고 싶은 사람들에게 좋은 진전이다.

이 새 기능이 마음에 들었기를 바란다. 마음에 들었다면, 어떻게 해야 할지 알 것이다. 좋아요를 누르고, 개발팀과 공유하고, Delphi 세계의 소식을 놓치지 않도록 구독하기 바란다!

큰 포옹을 보내며, 코딩에 행운이 있기를 바란다. 다음 글에서 만나자!

(원문 참고: 이 글의 원문은 브라질 포르투갈어로 작성되었다. 원문 보기(포르투갈어))

• 제목: Kai 1.1.1 Is Now Available
• 작성자: Marco Cantu - 2026년 9월
• 링크 https://blogs.embarcadero.com/kai-1-1-1-is-now-available/

목차

• 로컬 AI 엔진 지원 강화
• Kai 1.1.1의 기타 품질 개선
• Kai 1.1.1 받는 방법

오늘 엠바카데로(Embarcadero)는 Kai(카이) 버전 1.1.1을 출시했다. 이는 Kai 1.1을 기반으로 여러 개선 사항을 더한 유지보수 업데이트다. 특히 로컬 AI 모델을 사용하는 개발자들을 위한 개선이 두드러진다.

로컬 AI 엔진 지원 강화

Kai 1.1.1의 주요 초점은 Ollama와 LM Studio 연동을 계속 개선하는 데 있다.

Kai 1.1은 AI 제공업체와 로컬 모델에 연결하는 데 있어 훨씬 더 유연한 아키텍처를 도입했다. Kai 1.1.1에서는 테스트 범위를 더 다양한 로컬 모델과 구성으로 넓혔다. 로컬 모델 경험 향상도 추가로 진행했다.

또한, Kai가 지침과 사용 가능한 도구들을 로컬 모델에게 제공하는 방식도 개선했다. 더 긴 '도구 호출(tool call) 연쇄'도 지원한다. 이 향상은, 에이전틱 작업흐름에서 특히 가치가 크다. 즉 에이전틱 작업흐름 안에서, Kai는 프로젝트를 살펴보고, 파일을 읽고, 변경하고, 요청 하나를 완료하기 위해 필요한 여러 작업들을 해낼 수 있다.

그 결과, Kai를 Ollama와 LM Studio와 함께 사용할 때, 다양한 로컬 모델과 구성에 걸쳐 신뢰성이 향상되고 호환성도 넓어졌다. 우리가 테스트한 범위에는 여러 Ollama 모델들이 포함되었으며, LM Studio를 사용한 코드 수정 작업흐름이 성공하는지도 점검했다.

로컬 모델은 컨텍스트 윈도우 크기, 도구 호출 기능, 구성 면에서 크게 차이가 날 수 있다. 그래서 선택한 모델과 로컬 추론 환경에 따라 결과가 달라진다. 더 수준높은 에이전틱 개발 작업흐름을 원한다면, 충분히 큰 컨텍스트 윈도우를 가진 유능한 모델이 최상의 경험을 제공할 것이다.

백그라운드에 있는 LM Studio를 사용하고 있는 Kai 1.1.1 채팅창

Kai 1.1.1의 기타 품질 개선

로컬 모델 개선과 함께, Kai 1.1.1에는 여러 추가적인 품질·사용성 향상도 담겨 있다. 대부분은 1.1 버전에서 도입된 새 MCP 구성 페이지와 관련이 있다.

• 파일 생성과 유닛 수정 시의 신뢰성이 향상되었다.
• 긴 MCP 도구 설명 표시 방식이 개선되었다.
• MCP Tools 구성 화면에서 전체 선택/전체 해제 동작이 다듬어졌다.
• 다크 IDE 테마 사용 시 MCP Tools 열 머리글 표현이 향상되었다.

Kai 1.1.1 받는 방법

이전 Kai 업데이트와 마찬가지로, Kai 1.1.1은 RAD Studio의 GetIt 패키지 매니저를 통해 사용할 수 있다. 곧 my.embarcadero.com에서도 고객을 위한 별도 다운로드로 제공될 예정이다.

Kai를 Ollama나 LM Studio와 함께 사용하고 있다면, 1.1.1로 업데이트하기를 특히 권장한다. 이 패치는, Kai 1.1 출시 이후, 로컬 AI 모델을 사용하는 개발자들에게서 받은 피드백과 테스트 결과를 반영했다. 로컬 AI 엔진을 Kai의 에이전틱 작업흐름 안에서 사용하기에 훨씬 더 탄탄한 기반을 제공한다.

• 제목: Incredible Real-Time Mobile App Is Built With Delphi
• 작성자: Embarcadero Admin - 2021년 4월
• 링크 https://blogs.embarcadero.com/incredible-real-time-mobile-app-is-built-with-delphi/

목차

• 어떤 종류의 실시간 데이터를 캡처할 수 있을까?
• 웹사이트
• iOS 앱스토어
• Google Play
• 스크린샷 갤러리

OCEASet™ 실시간 모바일 애플리케이션은 OCEABridge™ Bluetooth®/클라우드 게이트웨이를 구성하기 위한 동반 도구다. OCEABridge™는 게이트웨이 장치다. 이 장치는 고객의 로컬 Emerald™ 또는 Atlas™ 데이터로거와 OCEASOFT 클라우드 서비스 사이를, 인터넷을 통해 투명하게 연결해 준다. 측정값은 데이터로거가 실시간으로 수집한다. OCEABridge™가 이를 무선으로, 자동으로 캡처한다. 이 측정값은 모니터링과 리포팅을 위해 클라우드로 전달된다.

어떤 종류의 실시간 데이터를 캡처할 수 있을까?

OCEASoft 웹사이트에 따르면, 이 앱들은 다음을 제공한다.

• Bluetooth를 통한 무선 데이터로거 통신
• 설정 가능한 데이터 로깅 시작 시간
• 지연 시간을 포함해 정의할 수 있는 상한값과 하한값
• 측정값, 이벤트, 알람에 대한 빠른 접근
• OCEASOFT의 보안 OCEACloud 플랫폼으로의 자동 데이터 전송
• °C 또는 °F, GMT 또는 현지 시간으로 표시되는 값
• 모든 정보가 담긴 CSV 파일을 첨부해 미션 리포트 이메일 생성
• PDF, XLS, CSV 형식으로 전체 리포트 다운로드

이 앱들은 RAD Studio의 Delphi와 FireMonkey(파이어몽키)의 크로스 플랫폼 기능을 사용해 작성되었다. 그래서 iOS와 Android 양쪽 모두에서 사용할 수 있다.

웹사이트

OCEASet

iOS 앱스토어

OCEASet on the App Store (apple.com)

Google Play

OCEASet

스크린샷 갤러리

더 많은 사례를 알고 싶다면, 아래 모아 보기를 활용하면 된다.

• 엠바카데로 공식 블로그(영어): 영어 개발 사례(showcase) 기고들 (https://blogs.embarcadero.com/category/showcase/)
• 데브기어 포럼(한국어): 한국어 개발 사례 기고들 (https://welcome.devgear.co.kr/tags/%EA%B0%9C%EB%B0%9C%EC%82%AC%EB%A1%80/)

• 발표자료 (한글, 슬라이드)

기타 RAD 13.0 주요 자료

• 13.2 플로렌스 출시 기고 (한글 번역)
• 13.2 새 기능 (DocWiki 한글 번역)
• 13.2 새 기능 요약 비디오 (6 min, 한국어)
• 13.2 관련 기고 모아보기 (한글)
• RAD Studio 기능 명세서 PDF(영어)

13.2 기준 새 브로셔 (한글)

• 13.2 새 기능(1쪽)
• RAD Studio 일반(2쪽)
• Delphi 일반(2쪽)
• C++Builder 일반(2쪽)
• Embarcadero 회사 일반(1쪽)

• 제목: What Happens When Your Compiler Jumps 12 Years of LLVM Evolution?
• 작성자: Antonio Zapater - 2026년 9월
• 링크 https://blogs.embarcadero.com/what-happens-when-your-compiler-jumps-12-years-of-llvm-evolution/

컴파일러를 업그레이드할 때 좋은 점 중 하나는, 애플리케이션 코드를 바꿀 필요가 없다는 것이다. 그냥 같은 코드베이스를 다시 빌드하기만 하고, 새 도구체인이 무엇을 만들어내는지 확인하면 된다.

Delphi 13.2는 그 비교를 특히 Linux에서 흥미롭게 만든다. Delphi 13.1(및 이전 버전들)은 LLVM 3.3에 의존했다. 반면 Delphi 13.2는 컴파일러 발전 10년치를 건너뛰어 LLVM 20.1로 넘어간다.

나는 이미 WebBroker 배포본 세 개를 내부 테스트용으로 가지고 있었기 때문에, 이런 생각이 들었다. 이 세 가지마다 각각 두 컴파일러 버전에서 빌드한 후에 동일한 부하 테스트를 돌려보면 어떨까? 실제로 해보고 나서 한 가지는 분명히 말할 수 있다. 그 결과는 미묘한 수준 차이가 아니었다. CPU 부하가 큰 워크로드에서, 처리량(throughput) 증가는 254%~390% 수준이었다. 한편, 단일 요청 지연 시간(latency) 단축은 71% ~78% 수준이었다.

하지만 늘 그렇듯, 이 수치들 뒤에는 중요한 단서가 하나 있다. 그 이야기를 해보겠다. 내가 처음 실행한 테스트부터 시작하겠다.

목차

• 너무 쉬워서 지루할 뻔한 첫 번째 결과
• 컴파일러에게 일할 공간을 주다
• 그다음 격차가 벌어졌다 – RAD Studio 13.2의 새로운 LLVM 최적화는 놀라웠다!
• 내 WebBroker와 하드웨어 구성은 어떻게 되어 있는가
• 문제가 생겼을 때 벌어지는 일
• LLVM 벤치마크를 직접 실행해 보는 방법
• 마지막으로 하나 더: rpmalloc은 어떨까?

너무 쉬워서 지루할 뻔한 첫 번째 결과

나는 처음 시작할 때 내가 이미 가지고 있던 테스트 프로젝트들의 가벼운 JSON 엔드포인트로 시작했다. 이 엔드포인트는 요청을 받으면, TJSONObject를 사용해 더미 응답을 만들고, 다시 돌려보냈다. 컴파일러가 최적화할 만한 커스텀 코드가 많지 않았기 때문에, 성능 향상 폭은 크지 않았다. 그래도 Apache 구성에서는 처리량은 약 12% 늘었고, 독립형(standalone) 서버에서는 약 9% 늘었다.

요청 시간 대부분이 소요된 곳은 여러분이 예상할 수 있는 곳이다. 프레임워크 처리, 소켓 핸들링, 네트워크 I/O 등이다. 그럼에도, 이 기준선은 유용했다. 이 결과는, WebBroker가 그저 재컴파일만으로 갑자기 전체적으로 4배 빨라지지는 않는다는 현실적인 기대치를 제시해 주었다. 하지만 이미 한 가지 가능성을 보여주었다. 코드를 단 한 줄도 건드리지 않아도, 이미 측정 가능한 수준으로 더 빨라진다는 것이다.

컴파일러에게 일할 공간을 주다

새 도구체인에게 실제로 할 일을 주기 위해, 나는 모든 요청에 작은 CPU 워크로드를 추가했다. 이 워크로드는 배열 안에 8,192개의 정수를 채우고, 그 합을 구한다. 내 테스트에서는, 이 과정을 400번 반복했다.

일반적인 백엔드 서비스에서는, 데이터베이스가 보통 주된 병목 지점이라는 것은 사실이다. 하지만 많은 서비스들은, 데이터가 도착한 뒤에도 메모리 안에서 상당한 작업을 여전히 수행한다. 예를 들면 다음과 같다.

• 데이터셋 행 전체에 걸쳐 합계를 계산하거나 규칙을 적용하기
• 들어오는 데이터 페이로드를 그룹화하거나, 정렬하거나, 검증하기
• 오디오/이미지 버퍼를 스캔하거나 텔레메트리 샘플을 처리하기
• 인메모리 캐시를 채우고 수학적 배열을 계산하기

문자열 할당이 많거나 분기가 예측하기 어려운 코드는, 타이트 루프(tight loop)와는 다르게 동작한다. 하지만 수학 연산이 많은 코드 생성이나 레지스터 할당은, 현대적인 컴파일러가 진가를 발휘하는 지점이다.

여러 옵션을 고민한 끝에, 내가 각 요청에 추가하기로 결정한 메서드는 다음과 같다.

function BusyWork(Passes: Integer): Int64;
var
  I, R: Integer;
  A: TArray<Integer>;
  Sum: Int64;
begin
  if Passes <= 0 then
    Exit(0);

  SetLength(A, 8192);
  Sum := 0;
  for R := 1 to Passes do
  begin
    for I := 0 to 8191 do
      A[I] := I * 17 + (R and 255);
      
    for I := 0 to 8191 do
      Sum := Sum + A[I];
  end;
  Result := Sum;
end;

그다음 격차가 벌어졌다 – RAD Studio 13.2의 새로운 LLVM 최적화는 놀라웠다!

이 CPU 루프를 적용하자, 13.1과 13.2 사이의 성능 차이는 커졌다. LLVM 20은 루프 벡터화(vectorization), 레지스터 할당, 불필요한 메모리 연산 제거에서 LLVM 3.3보다 훨씬 더 똑똑하다.

나는 이 비교를, Apache WebBroker 모듈, nginx 뒤에 있는 FastCGI, Indy를 사용한 독립형 WebBroker 서버 환경에서 각각 실행했다. 아래 표는, 두 빌드 모두 요청을 100% 깨끗하게 처리해낸 동시성(concurrency) 수준만을 다룬다.

Apache가 가장 깔끔한 결과를 보였다. 동시성 1부터 200까지의 모든 테스트 지점에서, 두 버전 모두 모든 요청이 성공했다. 13.2를 사용했을 때 처리량은 평균 371% 증가했다. FastCGI도 큰 폭으로 향상되었다. 다만 설정된 워커 프로세스 상한선 근처에서 평탄해지기 전에, 일찍 정점에 도달했다.

독립형 서버는 '요청당 HTTP와 Indy 오버헤드'가 더 컸다. 그래서 단일 요청 기준 향상 폭은 다소 작았다. 하지만 지연 시간은 여전히 71% 줄었고, 동시성 25에서 처리량은 297% 늘었다.

내 WebBroker와 하드웨어 구성은 어떻게 되어 있는가

나는 테스트 환경을 의도적으로 소박하게 유지했다.

• 하드웨어: Proxmox LXC, i5-13500 4코어, DDR5 RAM 4GB
• OS: Ubuntu – 커널 7.0.14
• 트래픽 드라이버: 로컬 LAN을 통해 Windows 머신에서 실행한 Bombardier
• 테스트 부하: 테스트 엔드포인트당 10,000개 요청. 동시성은 1, 5, 10, 25, 그리고 50에서 500까지(50 단위)로 늘려가며 테스트했다. 워밍업과 30초 쿨다운을 포함해 총 3회 전체 실행을 진행했다.

한 가지 유념할 세부 사항이 있다. 13.1 바이너리는 RTL 37.1에서 실행되었고, 13.2는 RTL 37.2를 사용했다는 점이다. 런타임 라이브러리도 컴파일러와 함께 업데이트되었기 때문에, 이 향상 전체를 LLVM만의 공로로 돌릴 수는 없다. 일부 향상은, Delphi RTL 내부에서 계속 이루어지고 있는 최적화에서 자연스럽게 나온 것이다.

문제가 생겼을 때 벌어지는 일

높은 동시성 부하는, 안정성에서도 눈에 띄는 차이를 드러냈다.

이 소박한 VM에서 독립형 서버의 동시성을 50 이상으로 밀어붙이자, 두 빌드 모두 결국 과부하 상태가 되어 5xx 오류를 반환하기 시작했다. 하지만 실패하는 양상은 같지 않았다. 심한 과부하 상태에서, Delphi 13.1은 요청의 20%에서 28%만 성공했다. 반면 Delphi 13.2는 성공률을 83%에서 99% 사이로 유지했다. Apache에서도 13.1은 동시성 250 근처부터 일부 연결을 끊기 시작했다. 반면 13.2는 모든 요청을 처리해냈다.

참고: 실패한 요청은 처리량에 포함되지 않는다. 그래서 이렇게 문제가 생긴 실행 결과는 위 표에 포함되지 않았다.

LLVM 벤치마크를 직접 실행해 보는 방법

여러분의 환경에서 이 테스트를 직접 실행해보고 싶을 수 있으므로, 나는 프로젝트 파일들의 단순화된 버전을 GitHub 저장소에 정리해 두었다.

코드 다운로드하기

이 저장소에는 다음이 포함되어 있다.

• linux-work-bench: HTTP 오버헤드를 완전히 제거하고 순수 실행 속도만 측정하는, CPU 루틴용 콘솔 타이머다.
• webbroker-standalone: Bombardier 테스트 실행을 자동화하는 PowerShell 스크립트가 포함된 독립형 WebBroker 서버다.

PAServer를 통해 Delphi 13.1과 13.2 각각에서, 프로젝트를 Linux64용 Release 모드로 빌드하면 된다. 이 코드는 체크섬을 자동으로 출력한다(또는 반환한다). 그래서 시간을 비교하기 전에, 두 빌드가 동일한 결과를 내는지 확인할 수 있다.

이 테스트 환경에서는, 내가 13.2로 옮기는 것만으로 CPU 부하가 큰 작업의 요청 지연 시간이 70% 넘게 줄었다. 코드는 단 한 줄도 바꾸지 않았다. Linux에서 Delphi 서비스를 운영하고 있다면, 13.2로 업그레이드하는 것이 올해 가장 빠르게 얻을 수 있는 성능 향상일 가능성이 높다.

마지막으로 하나 더: rpmalloc은 어떨까?

RAD Studio Delphi 13.2가 Linux와 Windows on Arm에서 rpmalloc을 선택해서 사용할 수 있도록 지원한다는 점을 언급하면 도움이 될 것 같다. rpmalloc은, 무거운 멀티스레드 할당에 특화되도록 튜닝된 메모리 매니저다.

우리의 BusyWork 메서드는 모든 요청에서 배열 메모리를 할당하기 때문에, 내 직감으로는 이 부하 상황에서 rpmalloc은 이 수치들을 한층 더 끌어올릴 수 있을 것 같다. 다만 메모리 사용량이 더 높고, 내장된 누수 리포팅 기능이 없다.

이번 테스트에서는, 깨끗한 기준선을 유지하기 위해 기본 메모리 매니저를 그대로 사용하기로 했다. 하지만 후속 테스트도 고려하고 있다.

rpmalloc 벤치마크를 다음으로 보고 싶은가? 관심 있다면 아래 댓글로 알려주기 바란다!

• 제목: Show Us What You Built With Kai – More Giveaways!
• 작성자: Ian Barker - 2026년 9월
• 링크 https://blogs.embarcadero.com/show-us-what-you-built-with-kai-more-giveaways/

목차

• Kai는 다른 AI 컴패니언과 어떻게 다를까?
• Kai로 무엇을 만들 수 있을까?
• 이번 달 수상자는 누구일까?

Kai(카이)에는 요즘 많은 일이 벌어지고 있다. 사실 RAD Studio(라드 스튜디오), Delphi(델파이), C++Builder(C++빌더) 전반에 걸쳐 많은 일이 일어나고 있다. RAD Studio 13.2 출시 웨비나를 놓쳤다면, 아래에서 다시 볼 수 있다. 그 행사에 사용한 스트리밍 플랫폼이 라이브 중에 말썽을 부렸다. 하지만 이 녹화본에는 전체 발표가 온전히 담겨 있다. 말썽꾸러기 웨비나 문제로 훼손되지 않았다. 이제 나는 조금 진정했다. 그 13.2의 흥분 속에서, 우리는 Kai 1.1 버전도 출시해냈다. 또한, 더 많은 것들이 앞으로 준비되어 있다!

Kai가 GetIt(겟잇) 패키지 관리자를 통해 배포된다는 점에는 한 가지 장점이 있다. 전체 RAD Studio보다 훨씬 더 자주 업데이트를 제공할 수 있다는 점이다. 전체 RAD Studio의 경우에는 엘프들이 지원하는 부대, 육중한 빌드 머신들의 노고, CI/CD 파이프라인과 그것이 뻗어 나가는 여러 CDN과 기타 TLA(세 글자 약어)이 필요하다. AI 세계는 빠르게 움직인다. 매주, 때로는 매일 그 모습을 바꾸고 진화하는 것처럼 보인다. 그래서 우리는 Kai를 업데이트하는 메커니즘이 최대한 민첩하도록 만들었다. AI 생태계가 이렇게 빠르게 움직이기 때문에 여러분은  12개월 내내 모든 기능을 한 번의 연간 구독료 지불을 통해 누릴 수 있도록 했다. 월간 구독이 아니라 연간 구독 방식이다. Kai가 발전하고 기능을 확장해 나가면, 여러분은 그것을 곧바로 GetIt을 통해 받을 수 있다. 출시 웨비나 영상에는 PM팀의 Nuno가 보여주는 훌륭한 Kai 데모도 담겨 있다. Nuno는 새로운 ACP 레지스트리가 실제로 어떻게 작동하는지도 보여준다.

(옮긴이: 한글 비디오는 데브기어 유튜브 또는 웨비나를 통해 따로 제공될 예정입니다)

Kai는 다른 AI 동반기술들과 어떻게 다를까?

Kai는 어떻게 사용할까? 그건 전적으로 여러분에게 달려 있다. Kai 1.1에는 ACP 목록이 추가되었다. 이 목록 덕분에, 거의 모든 주요 AI 제공업체를 선택지로 이용할 수 있다. 목록은 계속 늘어난다. 그 중에는 Grok, DeepSeek, 유럽에서 인기 있는 Mistral, Claude(클로드) 등도 포함된다. 사실, 여러분이 좋아하는 AI가 무엇이든, RAD Studio, Delphi, C++Builder와 함께 작동할 가능성이 높다. Kai의 큰 장점은 여러 AI 제공업체를 동시에 사용할 수 있다는 점이다. 예를 들어, Claude 사용 한도를 다 써버렸다면, 몇 초 만에 LM Studio나 Ollama 같은 곳에서 호스팅하는 로컬 모델로 전환할 수 있다. 하지만 그게 전부가 아니다. Antigravity나 Gemini 같은 다른 클라우드 제공업체와 동시에 새로운 채팅을 열 수도 있다. 선택은 여러분의 몫이다. 우리는 이것이 중요하다고 생각한다. 어떤 데이터를 누구에게 맡길지 – 또는 맡기지 않을지 – 는 여러분이 결정한다. IDE 안에서, 여러분의 방식대로 작동하게 만들 수 있다. 여러분 자신에게 AI가 맞지 않다고 생각할 수 있다. Kai와 우리의 또 다른 AI 도우미인 SmartCode Insight는 완전히 선택 사항이다. 그것들은 기본적으로 꺼져 있다.

Kai로 무엇을 만들 수 있을까?

코딩하는 동안 다양한 작업을 Kai에게 도움받을 수도 있다. 아예 모든 코드를 Kai에게 맡겨 만들게 할 수도 있다. 다만 우리는, Kai로 무엇을 할 수 있는지 보여주는 가장 좋은 방법은 실제 Delphi와 C++ 개발자들이 직접 보여주는 것이라고 판단했다. 그래서 Kai Summer Wave 이벤트의 일환으로 "Show what you built with Kai(Kai로 만든 것을 보여주세요)" 캠페인을 진행하고 있다. 이미 8월에 첫 증정품 수상작을 선정했고, 이번 달에도 훌륭한 응모작이 더 있다. 여러분이 AI로 만든 것들을 보면 정말 놀랍다. AI로 코딩하는 것이 모두의 취향은 아니라는 것도 안다. 하지만 그것을 즐기는 사람들에게는, LLM을 다루고 그 안에 창의력을 흘려보낼 때 얼마나 놀라운 것을 만들어낼 수 있는지 정말 대단하다.

이번에 새로 선정된 증정품 수상자들을 소개한다. 여러분도 참여하고 싶은가? 공식 응모 페이지로 가서 우리를 놀라게 하기 바란다! 아직 Kai를 써보지 않았다면, 다운로드해서 한번 사용해 보자. 평가판으로 만든 응모작도, 정식 버전으로 만든 응모작도 모두 받는다.

이번 달 수상자는 누구일까?

이번 달에 선정된 프로젝트를 더 자세히 보여주는 웨비나도 곧 이어서 진행할 예정이다.

그동안, 여러분도 Kai로 만든 것을 공유해 보는 건 어떨까?

• 제목: TDD Mini-Course – Theory
• 작성자: Landerson Gomes - 2026년 9월
• 링크 https://blogs.embarcadero.com/tdd-mini-course-theory/

나는 유닛 테스트 수행에 관한 정보를 접할 때면 거의 어김없이, 그 출처는 이미 준비가 완료된 상태의 자료들이었다. 그러다 보니, 뭔가 유닛 테스트 수행의 시작점이 무엇인지, 왜 필요한지, 한마디로 말해, 유닛 테스트 수행을 어떻게 시작하는지를 설명해주는 무언가가 필요하다는 생각이 들었다.

목차

• 신성한 사이클: 빨강-초록-리팩토링 루프(red-green-refactor)
  • 1. 빨강: 실패하는 테스트를 작성한다
  • 2. 초록: 테스트를 통과시킨다
  • 3. 리팩토링: 코드를 개선한다
• 왜 신경 써야 할까?
• TDD를 시작할 때 흔히 하는 실수
• 영상
• 핵심 정리

신성한 사이클: 빨강-초록-리팩토링 루프(red-green-refactor)

TDD의 심장은 세 가지 기본 단계의 리듬에 맞춰 뛴다. 이 중 하나라도 생략한다면, 그것은 TDD를 하는 것이 아니다. 그저 나중에 테스트를 작성하는 것일 뿐이다(그것도 중요하다. 하지만, TDD와는  다른 이야기다).

1. 빨강: 실패하는 테스트를 작성한다

시작은 구현하고자 하는 기능에 대한 테스트를 작성하는 것이다. 그 기능이 아직 존재하지 않으므로, 그 테스트는 당연히 실패한다.

• 목표: 여기서 목표는 그 테스트가 빨간색(red)으로 바뀌는 것을 확인하는 것이다. 만약 첫 시도에서 그 테스트가 통과한다면 뭔가 잘못된 것이다. 그 테스트는 쓸모가 없거나, 아니면 그 기능이 이미 구현되어 있다는 뜻이다.

2. 초록: 테스트를 통과시킨다

이제, 최소한의 실제 운영 코드를 작성한다. 그 코드는 테스트를 통과시키는 데 필요한 정도면 된다.

• 아직 신경 쓰지 않아도 되는 것들이 있다. 우아한 코드, 복잡한 아키텍처 패턴, 정교한 최적화 등이다. 집중할 단 하나의 목표는 그저 테스트를 통과시키는 것이다. 가장 빠르고 기본적인 해결책으로 충분하다면, 지금은 그것으로 충분하다.

3. 리팩토링: 코드를 개선한다

테스트가 그린 상태가 되었다면, 우리에겐 안전망이 생긴 것이다. 이제 집을 청소할 시간이다.

• 이제 할 수 있는 일들이 있다. 중복 제거, 변수 이름 개선, 디자인 패턴 적용, 코드 정비를 통해 읽기 쉽게 유지하기 등이다. 각 변경이 끝날 때마다 테스트가 초록색 상태 계속 유지되는지 확인한다.

왜 신경 써야 할까?

잠시 멈춰서 생각해보면, 전통적인 개발 작업은 대체로 다음과 같은 방식으로 진행된다. 몇 시간 동안 코드를 작성한다. 애플리케이션을 수작업으로 실행한다. 버튼 열 개를 여기저기 눌러보면서, 무언가 깨지지 않았는지 확인한다. 마지막에는, 실제 운영 환경에서 제대로 동작하기를 기도한다.

TDD를 적용하면, 다음을 얻을 수 있다:

• 즉각적인 피드백: 코드가 의도한 대로 동작하는지 몇 초 안에 알 수 있다.
• 실제 운영 환경에서의 버그 감소: 왜냐하면, 개발자는 엣지 케이스(극단적인 상황) 그리고 오류 상황에 대해 코드를 작성하기 전에 미리 생각하기 때문이다. 그래서 로직이 훨씬 더 탄탄해진다.
• 살아있는 문서: 테스트는 시스템의 실행 가능한 명세 역할을 한다. 누구든(6개월 후의 나 자신을 포함해서) 테스트를 읽는 것만으로 코드가 무엇을 하는지 이해할 수 있다.
• 리팩토링할 용기: 레거시 코드나 대규모 코드를 변경하는 일은 무서울 수 있다. TDD에 의해 잘 다져진 탄탄한 테스트 스위트(suite)가 있다면, 리팩토링을 자신 있게 할 수 있다.

TDD를 시작할 때 흔히 하는 실수

배우는 과정에서는, 몇 가지 전형적인 함정에 빠지는 것이 일반적이다:

1. 모든 것을 한 번에 테스트하려는 시도: TDD는 작은 단계에 관한 것이다. 테스트를 위한 설정(setup) 코드가 50줄이나 필요하다면, 너무 많은 것을 한 번에 해결하려는 것이다. 문제를 더 작은 조각으로 나눠야 한다.
2. 복잡한 테스트 작성: 간단한 로직을 실행하는 데 목(mock) 위에 목을 쌓고, 완전한 관계형 데이터베이스와 외부 API까지 필요하다면, 코드 설계가 지나치게 강하게 결합(coupled)되어 있는 것이다. TDD는 이런 문제를 찾아내는 데 도움이 된다.
3. 첫 번째 장애물에서 포기하기: 처음에는 TDD가 개발 시간을 두 배로 늘리는 것처럼 느껴진다. 사실이다. 초기 학습 곡선은 답답하다. 하지만 장기적으로는, 투자한 모든 시간은 디버깅에서 절약되는 시간을 통해 보상받게 된다.

영상

나는 미니 코스를 영상으로 녹화했다. 이번 첫 번째 파트에서는, TDD의 이론적인 측면을 공유한다. 설명되어야 하는 마땅한 방식을 따라, 맨 처음부터 시작한다!

나에게 영감을 준 코스는 ITA(항공기술원, Instituto Tecnológico de Aeronáutica)의 온라인 강좌인 TDD – Test-Driven Software Development이다. 이 강좌는 Eduardo Guerra가 가르친다. Coursera 플랫폼에서 볼 수 있다.

핵심 정리

TDD는 만능 해결책(silver bullet)이 아니다. 독단적인 종교처럼 받아 들여, 시스템의 100%에 반영해야 하는 것도 아니다. 하지만, 이론을 마스터하고 빨강-초록-리팩토링 사이클을 연습한다면, 소프트웨어 개발을 바라보는 방식이 완전히 바뀔 것이다.

'테스트 주도'로 코드를 작성한다는 것은 생각의 명료함에 관한 것이다. 자신이 어디로 향해 가는지 정확히 알고 나서, 첫걸음을 내딛는 것이다.

여러분은 어떤가? 이미 일상에서 TDD를 적용하고 있는가, 아니면 시간 낭비라고 생각하는가? 댓글로 여러분의 경험을 남겨주기 바란다!

"RAD 스튜디오 13 Florence(플로렌스) - 릴리스 2"를 정리한 Docwiki (원문 보기)를 번역한 글입니다.

도움말 메인 페이지(영문)로 이동 >>
과거 버전들의 새 기능 모아 보기(영문)로 이동 >>

RAD Studio 13 Florence(플로렌스) 업데이트 릴리즈인 13.2가 출시되었다 (2026년 9월 17일)

알아둘 점:

이 버전에 포함된 기능을 확인해 보자:

• 13 Florence(플로렌스)
• 13 Florence(플로렌스) - 릴리스 1

RAD Studio 13 Florence(플로렌스) - 릴리스 2(13.2라고도 부름)를 이제 설치할 수 있다. RAD 13.2는 RAD Studio 13의 기능을 바탕으로 한다. 그래서 기존 기능들을 제품 전반에 걸쳐 강화하고 새로운 기능들을 추가했다.

다음 섹션들은 영역별 주요 13.2 향상들을 보여준다. 주요 품질 초점 영역은 다음과 같다:

• IDE 및 IDE 도구들
• 써드-파티(Third-Party) 포매터를 위한 OpenTools API
• Delphi LLVM20 Linux 컴파일러
• Windows Arm64EC
• C++ Clang 20 컴파일러와 도구 체인
• 디버거
• Delphi Android
• 새 VCL 컨트롤들
• FMX 스타일 디자이너 확장
• FireDAC(파이어닥)
• WebStencils와 인터넷
• RAD Server(라드 서버)

목차

• 1. 13.2에서 강화된 점을 제품 영역 별로 보기
• 2. IDE 및 IDE 도구들
  • 2.1 Navigator 통합
  • 2.2 써드-파티(Third-Party) 포매터를 위한 OpenTools API
  • 2.3 재구성된 Code Insight 옵션 창
  • 2.4 IDE 향상들
    • 2.4.1 FMX Style Viewer 도구들의 HighDPI 지원
    • 2.4.2 IDE Insight 향상들
    • 2.4.3 에디터의 중괄호/괄호 짝맞춤 향상
    • 2.4.4 폼 상속(Form Inheritance) 향상들
    • 2.4.5 한 글자씩 밀리는 삽입 문제 해결
    • 2.4.6 새 컨트롤 힌트(Hint)
    • 2.4.7 기타 IDE 변경 사항
• 3. 컴파일러, 도구 체인들, 플랫폼들
  • 3.1 Delphi LLVM20 Linux 컴파일러
  • 3.2 Delphi Windows Arm64EC 향상들
    • 3.2.1 Windows Arm64EC용 동적 패키지
    • 3.2.2 FastMM4는 WinArm64EC의 기본 메모리 매니저이다
    • 3.2.3 Windows Arm64EC 품질 향상들
  • 3.3 WinArm64EC와 Linux64를 위한 병렬 코드 생성
  • 3.4 Delphi LLVM20 컴파일러의 코드 생성 향상들
  • 3.5 C++ Clang 20 컴파일러와 도구 체인 향상들
    • 3.5.1 IDE와의 더 좋은 BCC64X 통합
    • 3.5.2 품질 향상들
  • 3.6 Delphi Android
  • 3.7 iOS
  • 3.8 디버거 향상들
  • 3.9 기타 Delphi 컴파일러 변경 사항
• 4. 라이브러리
  • 4.1 새 VCL 컨트롤들
    • 4.1.1 TTabView 컨트롤
    • 4.1.2 TNavigationView 컨트롤
  • 4.2 FMX 스타일 디자이너 확장들
  • 4.3 FireMonkey 품질 향상들
  • 4.4 FireDAC(파이어닥)
  • 4.5 WebStencils(웹스텐실즈)와 인터넷
  • 4.6 RAD Server(라드 서버)
  • 4.7 기타 참고 (See Also)

1. 13.2에서 강화된 점을 제품 영역 별로 보기

아래 영역 별로 주요 13.2 향상들을 볼 수 있다.

2. IDE 및 IDE 도구들

다음 섹션은 IDE와 IDE 도구들에 대한 향상과 개선 사항을 상세히 다룬다.

2.1 Navigator 통합

RAD Studio 13.2 릴리스에는 navigator 플러그인이 통합되었다. 그리고 에디터 미니맵을 향상시켰다. 그래서 활성 줄이 표시된다. 또한 스크롤바 주석, 중단점, Error Insight 주석 등에 대한 지원도 추가되었다.

• Goto: 빠른 이동을 위한 내비게이션 대화상자다. 코드 기반 안에 있는 유닛, 타입, 메서드, 기타 심벌에 빠르게 접근하도록 한다.
• 구성(Configuration): Navigator 구성은 Tools Options 대화상자 안에 있다.
• 미니맵(Minimap): 현재 모듈의 미리보기를 제공한다. 코드 에디터 옆에 표시된다.

2.2 써드-파티(Third-Party) 포매터를 위한 OpenTools API

IDE는 새 OTA(OpenTools API) 인터페이스를 제공한다:

• IOTACodeFormatterServices
• IOTACodeFormatter

이 인터페이스들에는 포매터를 등록하고 등록 해제하는 함수(AddFormatter / RemoveFormatter)가 포함되어 있다.

2.3 재구성된 Code Insight 옵션 창

이번 릴리스는 Code Insight Options 페이지를 재구성했다. 그래서 각 언어별로 별도의 페이지를 추가했다.

2.4 IDE 향상들

RAD Studio IDE에는 그 밖에도 여러 향상과 관련 품질 수정 사항이 있다. 가장 관련성 높은 것들을 여기에 나열한다.

2.4.1 FMX Style Viewer 도구들의 HighDPI 지원

FMX Style viewer의 도구들은 DPI를 인식하지 못했었다. 그래서, 고해상도 디스플레이에서 스케일링 즉, 배율확대가 좋지 않았다. 이번 릴리스에서는 아래 도구들이 High DPI를 인식하도록 업데이트되었다. 그래서 Per-Monitor v2를 지원한다:

• FMXControlStyleViewer.exe
• FMXMetropolisUIStyleViewer.exe
• FMXMobileStyleViewer.exe
• FMXStyleViewer.exe
• FMXWinModernStyleViewer.exe

2.4.2 IDE Insight 향상들

이번 릴리스에는 다음과 같은 IDE Insight 향상들이 포함된다:

일치하는 결과가 없을 때(No Matches Found) 표시되는 대화상자를 향상시켜, 사용자 경험을 향상했다.

사용자가 원하는 IDE Insight 경험을 구성할 수 있도록 새로운 IDE Insight 옵션 창이 추가되었다.

IDE Insight 팝업 항목 화면을 향상시켰다. 간격이 개선되었고 IDE의 테마 인식 색상을 지원한다.

2.4.3 에디터의 중괄호/괄호 짝맞춤 향상

이번 릴리스는 Delphi와 C++ 양쪽 모두에서, 에디터의 중괄호와 괄호 짝맞춤과 관련된 기존 문제 몇 가지를 해결했다. 이 향상은 다음과 같은 시나리오를 고려한다:

• 짝 중 하나가 문자열이나 주석 안에 있다면, 마찬가지로 문자열이나 주석 안에 있는 다른 짝하고만 매칭한다.
• 짝 중 하나가 문자열이나 주석 안에 없다면, 문자열도 주석도 아닌 다른 짝하고만 매칭한다.
• 이미 문자열이나 주석 안에 있는 경우에는, 해당 중첩가능한 플래그를 무시한다.
• 암시적인 방향이 없는 짝의 경우, 양쪽의 구문 강조 표시를 살펴서 그것이 시작인지 끝인지 파악한다.

2.4.4 폼 상속(Form Inheritance) 향상들

이번 릴리스에는 폼 상속과 관련된 여러 향상이 포함된다. HighDPI IDE 안에서 기반 폼과 상속된 폼의 스케일링을 더 잘 반영한다. IDE 안에서 상속된 폼을 열 때 기반 폼이 자동으로 열리는 기능을 향상시켰다. 또한 관련된 몇 가지 오래된 문제들도 함께 해결했다.

2.4.5 한 글자씩 밀리는 삽입 문제 해결

이번 릴리스는 에디터에서 발생하던 몇 가지 오래된 문제를 해결했다. IDE CodeManager를 사용해 코드를 추가 즉 이벤트 핸들러나 프로젝트 파일 정보 등을 추가할 때 그리고, 소스 코드가 CRLF(캐리지 리턴 + 라인 피드) 대신 LF(라인 피드)를 사용하는 경우에 있던 문제들이 해결되었다.

이제 LF와 CRLF 모두, 에디터가 예상대로 동작한다. 실패하지 않는다.

2.4.6 새 컨트롤 힌트(Hint)

예전에, VCL 디자이너는 컴포넌트와 컨트롤에 힌트를 제공하는 방식으로 마우스 아래에 있는 컨트롤에 대한 핵심 정보를 표시했다. 아래와 같다:

Florence 13.2 릴리스는 표시 정보를 크게 확장했다. 그리고 가독성도 향상했다. 더 부드러운 서식과, 불리언(Boolean) 값 같은 특정 정보에 대한 시각적 지원 향상 덕분이다. 이제 버튼에 대한 힌트의 모습은 아래와 같다:

2.4.7 기타 IDE 변경 사항

• 이번 릴리스는 구성을 업데이트했다. 그래서 멀티라인 프로퍼티 에디터를 사용하도록 했다. 즉, 컬렉션 안에서 여러 줄로 된 문자열 값을 사용할 수 있다.
• 이번 릴리스에서 IDE는, C++ 기능에 대한 구문 강조 표시가 향상되었다. 이제 이진 리터럴, 숫자 구분 기호, raw 문자열 리터럴 같은 것들이 더 잘 표시된다.
• RAD Studio 버전 13.2는, Object Inspector에서 단일 문자열에 적용되던 2,000자 제한을 없앤다. 이 변경은 Object Inspector의 멀티라인 문자열 프로퍼티 에디터에는 영향을 주지 않는다.
• 새 에디터 옵션 "Reload Open Modules"가 추가되었다. 이것은 IDE 안에 열려있는 모든 모듈들을 다시 불러온다. 만약 모듈을 다시 불러올 수 없을 때는 경고가 표시된다.
• 메인 메뉴를 IDE 제목 표시줄에 배치하는 옵션이 포함되었다. 그래서 UI의 공간 효율을 더 높일 수 있도록 했다.
• C++에 있던 이슈 하나를 해결했다. 즉, 백슬래시(\)로 끝나는 줄 주석이 예상치 못한 결과를 낳던 문제가 해소되었다.
• 사용자의 clang-format 파일이 있을 때 C++ 포매터가 깨지던 문제가 더 이상 발생하지 않는다.
• IDE가 키보드 단축키를 렌더링할 때, 이제는 키 캡(Key Cap) 형태로 표현한다(모던 UI 스타일 사용).

3. 컴파일러, 도구 체인들, 플랫폼들

이 섹션은 컴파일러, 도구 체인, 플랫폼에 대한 향상을 상세히 다룬다.

3.1 Delphi LLVM20 Linux 컴파일러

13.2 릴리스는 중요한 업데이트들을 Delphi Linux 컴파일러에 제공한다. 여기에는 LLVM 20 지원도 포함된다. 그래서, RAD Studio 13.1에서 도입되었던 Arm64EC Delphi 컴파일러와 같은 수준이 되었다. 이 새 컴파일러 자체는 64비트 바이너리이다. 그래서 64비트 RAD Studio IDE에 통합될 수 있다.

이전에는, Linux용 Delphi 컴파일러인 DCCLINUX64는 LLVM v3.3을 백엔드로 사용했었다. 이제는 LLVM v20.1.8을 사용하도록 업그레이드되었다. 이것은 DCCARM64EC가 사용하는 것과 동일한 백엔드이다.

LLVM v20.1.8에서 나온 커스터마이징된 LLD 버전인, dcc-ld.lld.exe는 이제 공식 링커로 사용된다. 그래서 단종된 GNU gold 링커인 ld-linux.exe를 대체한다. 이는 DCCARM64EC가 사용하는 것과 동일한 링커 기술이다.

또한, 이번 릴리스는 DWARF v2에서 v4로 업그레이드했다. 그 결과 더 완전한 디버그 정보를 얻을 수 있다. 또한 프론트엔드 리팩토링도 포함되어 있다. 이는 디버그 메타데이터가 생성되는 방식을 향상시킨다.

이번 업데이트의 중요한 변경 사항은, 이제 애플리케이션이 glibc 2.31에 링크된다는 점이다. 그 결과, 애플리케이션은 Ubuntu 20.04 LTS보다 오래된 배포판 (예: Ubuntu 18.04)에서는 실행되지 않을 것으로 예상된다.

알아둘 점:
Ubuntu 20.04 LTS는 현재 동작한다. 하지만, 공식 지원 대상은 아니다.

이 새 Linux 컴파일러에는 또한 새로운 IR 최적화들도 포함된다. 이 최적화들은 런타임 성능에서 상당한 향상을 제공한다.

알아둘 점:
새 DCCLINUX64의 빌드 시간은 상당히 더 길다. 이제는 새 IR 최적화들이 활성화된 그 이유에 해당된다. 하지만 LLVM v20 백엔드 자체가 LLVM v3.3보다 훨씬 더 복잡하다는 것도 이유다.

DCCLINUX64의 32비트와 64비트 버전 모두, Delphi 애플리케이션의 Linux 64비트 타겟을 지원한다. Delphi용 64비트 IDE에서 이제 사용자가 타겟으로 삼을 수 있는 것은 이제 Win64, Arm64EC, Linux64이다.

3.2 Delphi Windows Arm64EC 향상들

이번 릴리스에서, Delphi Windows Arm64EC 컴파일러에는 런타임 패키지를 빌드하기 그리고 사용하기를 지원할 수 있게 되었다. 다음 섹션들은 이 주제 그리고 기타 이 플랫폼에 관련된 향상들을 상세히 다룬다.

3.2.1 Windows Arm64EC용 동적 패키지

이번 릴리스는 DCCARM64EC용 동적 패키지 구현이 들어갔다. DCCARM64EC는 WinArm64EC용으로 새로 추가된 Delphi 컴파일러이다.

WinArm64EC 애플리케이션은 이제 동적 패키지를 생성하기와 사용하기를 둘 다 할 수 있다.

패키지 지원은 이전에도 가능했다. .dcu, .o, .dcp 파일들이 정적 링크용으로 생성될 수 있었기 때문이다. 이번 업데이트를 통해, BPL에 의존하는 애플리케이션들 또는 Link with runtime packages(런타임 패키지를 통한 링크)가 활성화된 애플리케이션들도 이제는 예상대로 동작한다.

알아둘 점:
WinArm64EC의 주요 장점 중 하나는 x64 DLL을 로드하는 능력이다. 하지만, x64 BPL은 Arm64EC 애플리케이션이 로드하지 못한다. 이는 DCC64가 역사적으로 표준 ABI를 따르지 않았기 때문이다. DCCARM64EC에는 개별적인 ABI 불일치가 여전히 있을 수 있다. 하지만, 우리의 목표는 DCCARM64EC가 표준 ABI와 완전히 일치하도록 하는 것이다. 이런 이유로, 현재의 DCC64 컴파일러가 생성한 x64 BPL은 Arm64EC 애플리케이션에서 지원되지 않는다.

3.2.2 FastMM4는 WinArm64EC의 기본 메모리 매니저이다

13.2 릴리스에는 WinArm64EC를 위한 더 상세한 메모리 매니저(memory manager) 분석이 포함되어 있다. 바로 rpmalloc이다.

rpmalloc은 UCRT 메모리 매니저와 수준이 같은 할당 성능을 유지한다. 그러면서도, 재할당 속도를 크게 향상한다. rpmalloc은 더 빠르다. 하지만, 애플리케이션의 메모리 사용량을 증가시킨다. 그리고 메모리 누수 보고 기능을 제공하지 않는다.

이번 릴리스부터, Win32와 Win64용 메모리 매니저가 WinArm64EC로 포팅되었고, 새 기본값이 되었다. rpmalloc은 선택할 수 있는 메모리 매니저로 계속 제공된다. 활성화하려면, .dpr의 uses 절 맨 앞에 System.RPMalloc을 추가하면 된다.

새 유닛 System.RPMalloc은 WinArm64EC와 Linux64에서 사용할 수 있다.

3.2.3 Windows Arm64EC 품질 향상들

아래는 Delphi Arm64EC 컴파일러에서 가장 주목할 만한 수정과 향상 목록이다:

• WinArm64EC의 부동소수점 성능을 향상시켰다. 그러기 위해, 예외 처리를 최적화했다. 그 덕분에, Exp는 약 25배 빨라졌다.
• RPmallocMM.inc를 제공했다.
• 임포트된 가변 인자(variadic) 함수 호출을 추가했다.
• RTTI 기반 호출 로직을 추가했다.
• class var, class threadvar, 헬퍼, open array에 대한 디버그 정보를 추가했다.
• external 함수 선언에 지정하는 정적 라이브러리로, 기존 .a 파일에 더해 이제 .lib 파일도 지원한다.
• midas.dll의 Arm64EC 버전을 추가했다.
• 제네릭을 많이 사용하고 있는 코드의 빌드 시간을 향상시켰다. Spring4D에서 20% 향상이 측정되었다.
• YieldProcessor 빌트인을 구현했다.
• WinArm64EC용으로 리소스 문자열(.drc) 파일이 잘못 생성되던 문제를 수정했다.
• 다양한 링킹 오류들을 수정했다. 즉, .imp.o 파일 누락으로 발생하던 문제들이 해소되었다.

3.3 WinArm64EC와 Linux64를 위한 병렬 코드 생성

WinArm64EC와 Linux64용인 우리의 LLVM 기반 Delphi 컴파일러의 새 세대 버전이다. 이것은 더 최신 LLVM 버전과 새 최적화기를 통해 만들어졌다. 이제 병렬 코드 생성을 지원한다. 병렬 코드 생성은 빌드 시간을 현격하게 줄일 수 있다. 성능은 DDC64에 가까운 수준이다.

병렬 코드 생성의 효과가 가장 큰 곳은 유닛이 많은 프로젝트, 특히 Release 모드인 경우이다. 모든 FMX 유닛을 다시 빌드하고 얻은 테스트 결과, Debug 모드는 2배 더 빨랐고 Release 모드는 14배 더 빨랐다.

이 기능은 DCCLINUX64와 DCCARM64EC에서만 사용할 수 있다. 이것들은 기본적으로 활성화되어 있다. "메모리 부족" 오류의 위험을 줄이기 위해, 64비트 컴파일러 버전에서만 활성화되어 있다.

알아둘 점:
이 기능은 32비트 IDE와 32비트 명령줄 컴파일러의 Linux에서는 사용할 수 없다. 이 기능은 64비트 IDE와 64비트 컴파일러에서만 사용할 수 있다.

비활성화하거나 스레드 개수를 제한하려면, Compiling and Running IDE 옵션 안에 새로 추가된 Number of workers 필드를 사용하면 된다.

개별 프로젝트별로 병렬 코드 생성을 비활성화하는 것도 가능하다. Project > Options 메뉴의 Enable parallel codegen 필드를 사용하면 된다.

또한, 병렬 코드 생성은 다음 옵션들을 사용해 명령줄에서 제어할 수 있다:

--parallel-codegen:auto 워커 스레드 개수를 자동으로 선택한다.
--parallel-codegen:none 병렬 코드 생성을 비활성화한다.
--parallel-codegen:<N> 지정된 개수의 워커 스레드를 사용한다.

--parallel-codegen 옵션을 지정하지 않으면, 기본적으로 --parallel-codegen:auto가 사용된다.

3.4 Delphi LLVM20 컴파일러의 코드 생성 향상들

13.2 릴리스는 새로운 최적화를 도입했다. 그래서 Delphi의 LLVM 컴파일러 도구체인 안에 상당한 성능 향상을 얻을 수 있게 되었다. 이 변경 사항들은, 오직 LLVM 20으로 업데이트된 컴파일러(즉, Windows ARM과 Linux Intel) 안에서만 작동한다.

이전에는 이랬다. 해당 패스들에 적합한 IR을 활성화하기 그리고 LLVM 3.x는, IR의 선택된 부분에게 필요한 세밀한 최적화 제어를 제공하지 못했었다. LLVM 버전 20 업그레이드 그리고 이와 관련된 Delphi 프론트엔드 리팩토링을 통해, LLVM 최적화가 활성화될 수 있었다. 그 결과 상당한 런타임 성능 향상을 Linux와 Windows Arm64EC의 Delphi 애플리케이션에게 제공한다.

아래 이미지는 현격한 런타임 성능 향상을 Release 모드에서 얻는 것을 보여주는 테스트 결과다.

Windows:

Linux:

알아둘 점:
빌드 시간에 대한 영향이 주로 나타나는 경우는 Release 모드이다. 빌드 시간이 약 34%에서 42% 늘어난다. Debug 모드의 경우, DCCARM64EC에서 변화가 없다.

3.5 C++ Clang 20 컴파일러와 도구 체인 향상들

이번 릴리스에서는 C++Builder의 패키지 지원이 향상되었다. 우리가 집중한 영역은 패키지 기반 개발을 더 신뢰할 수 있고 더 예측 가능하도록 하는 것이다. 이 변경 사항들이 해소하는 문제들은 패키지 사용, 빌드 동작, 링킹, IDE와의 통합을 둘러싼 문제들이다.

또한, 이번 릴리스에는 Win64x에서 Delphi 메모리 매니저를 지원하는 기능도 추가되었다. Win64x(Modern) C++ 타겟은 MSVC와 호환되도록 설계되어 있다. 그래서, 기본적으로 UCRT 메모리 매니저를 사용한다. 그런데, 메모리 할당 관련 성능 문제를 완화하고 싶을 때 선택할 수 있는 경로도 추가로 제공한다. 그래서, 사용자는 C++를 Delphi RTL 메모리 매니저로 명시적으로 전환할 수 있다. 그러려면, 필요한 심벌을 메인 프로젝트 소스 파일 안에 정의해야 한다. 다음과 같다:

int __CppUseDelphiMemMgr = 1;

3.5.1 IDE와의 더 좋은 BCC64X 통합

RAD Studio 13.2 릴리스부터, BCC64X는 인프로세스(in-process) 컴파일러로도 제공된다. 즉, compclang201.dll이 제공된다. 그저 bcc64x.exe 명령줄 도구로만 제공되는 게 아니다. 따라서, 보다 정확한 파일과 줄 진행 상황, 소스 내비게이션이 가능한 Messages 창의 구조화된 진단 정보, 신속하게 반응하는 취소, 반응성 있는 UI 등의 효과를 얻을 수 있다.

기존 컴파일러 DLL들과는 달리, compclang201.dll은 병렬 컴파일을 지원한다. --jobs=N을 붙이면 된다. BCC32C와 BCC64에서 이것을 구현한 방법은 서브프로세스를 실행하는 것이었다. 그러려면 별도 프로세스에서 C++ 컴파일러 실행하기(Run C++ compiler in a separate process) 옵션이 필요했다. 즉, IDE 통합에서 벗어났다. BCC64X는 동일한 프로세스 안에서 스레드를 사용한다. 그래서 --jobs=N은 bcc64x.exe와 compclang201.dll 양쪽 모두에서 동작한다. 그리고 완전한 IDE 통합을 유지한다. 32비트 IDE는 Win64x 병렬 컴파일을 4개 스레드로 제한한다. "메모리 부족" 오류의 위험을 줄이기 위해서이다. 64비트 IDE에는 그런 제한이 없다.

빌드 중에는, Build 창에서 현재 컴파일 중인 파일을 볼 수 있다. 병렬로 컴파일되는 파일에는 (+N) 접미사가 붙는다. 모든 파일에 걸쳐 합산된 줄 수도 함께 표시된다.

3.5.2 품질 향상들

이 섹션은, C++ Win64x와 C++ 패키지에 대한 여러 품질 향상을 나열한다. 13.2 릴리스에 들어간 주요 품질 향상은 아래와 같다.

• 아이콘 리소스들을 담고 있는 여러 .res 파일을 링크할 때, 아이콘 그룹 리소스가 깨지던 문제를 수정했다.
• Project Options 변경 후, C++ Builder에서 과도한 재빌드가 발생하던 문제를 수정했다.
• 순환하는 __property 정의를 거부하도록 했다. 그래서 깨지지 않도록 했다.
• 리소스/dfm 파일 경로 해석 문제를 수정했다.
• 패키지 의존성 정보(.pdi) 파일을 자동 생성한다. 링크 시점에 이루어진다. 
• 64비트 타겟에서 디자인 타임 C++ 패키지 빌드 문제를 수정했다.
• 64비트 IDE용 C++ 디자인 타임 샘플 패키지 dclbcbsmp를 수정했다.
• Delphi 유닛을 담고 있는 C++ 패키지들을 빌드할 때 발생하던 문제를 수정했다.
• 다른 패키지에서 .pas 파일을 담고 있는 C++ 패키지를 사용하는 경우에 발생하던 실패를 수정했다(_init_record<UnitName> 익스포트 누락으로 인한 문제).

3.6 Delphi Android

RAD Studio 13.2 릴리스에 포함된, Delphi Android를 위한 주요 업데이트는 다음과 같다:

• manifest의 miniSdkVersion 속성 기본값을 23에서 24로 높였다.
• 설치 관리자와 NDK 통합이 동일한 버전을 사용하도록 업데이트했다.
• Google AdMob 라이브러리(plays-services-ads)를 버전 25.3.0으로 업데이트했다.
• Android Google Maps 라이브러리(plays-services-maps)를 버전 20.0.0으로 업데이트했다.
• Billing 라이브러리를 버전 9.1.0으로 업데이트했다.
• Android의 연령 확인(Age Verification)을 위한 '저수준 플랫폼 지원'을 추가했다.
• 플랫폼 연령 확인 API(버전 0.0.4)에 접근할 수 있는 새 유닛인 Androidapi.JNI.PlayAgeSignals 유닛을 추가했다.

알아둘 점:
Android에서 연령 확인 API를 사용하기 전에는, 반드시 Application > Entitlement List 옵션 페이지에서 새로운 'Age Signals Service' 옵션을 활성화해야 한다.

3.7 iOS

이번 릴리스는 iOS용 연령 확인(Age Verification) API를 도입한다. DeclaredAgeRange와 PermissionKit 같은 프레임워크들로 구현되어 있다.

3.8 디버거 향상들

13.2 릴리스는, C++과 Delphi 전반에 걸쳐 여러 디버거 향상을 포함한다. 집중한 영역은 값 시각화, Local Variables와 Watch 표시, 표현식 평가이다.
이 변경 사항들은 현대적인 C++ 데이터 구조들(std::optional, std::any, std::variant, std::tuple, STL 반복자 등)에 대한 검사를 향상시킨다. 이와 동시에, Delphi 64비트 디버깅 경험도 강화한다. 주로 Variants, 배열, 인덱스/기본 프로퍼티, 실행 지점의 신뢰성 등이 개선되었다.

또한, 디버거에는 여러 작업흐름들과 성능 향상들도 포함되었다. 예를 들어, Project > Options > Debugger 아래의 Symbol table 옵션은, 이제 사용자가 무슨 모듈을 디버깅할 것인지를 지정할 수 있도록 한다. 또한, 이번 릴리스는 Thread-name 예외 처리를 최적화했다. 그래서, 불필요하게 IDE 프로세스를 중단시키는 일이 더 이상 없다. 스레드 정보 수집을 각 스레드의 최상위 프레임으로 제한한다. 또한 프로세스 중단 중에 발생하던 중복되는 스레드 정보 호출도 없앴다. 사용자 정의 환경 변수도 이제 디버그 프로세스에 올바르게 전달된다.

심벌 정보를 읽어오는 메커니즘도 향상되었다. 그래서, 대규모 프로젝트에서 디버깅 성능이 높아졌다. 전반적으로, 디버거의 안정성도 향상되었다.

3.9 기타 Delphi 컴파일러 변경 사항

이번 릴리스는 Delphi 컴파일러에 선택적 컴파일러 최적화를 도입한다. 새 컴파일러 지시문을 도입해, 사용자가 특정 최적화를 활성화할 수 있도록 했다. 예전처럼 전부 아니면 전무(all or nothing) 방식이 아니다.

{$OPTIMIZATION <feature> ON|OFF}

현재로서는, 두 가지 최적화 즉 CMOV와 IFCONV에 대해서만 활성화된다. 다음 지시문을 사용하면 된다 :

{$OPTIMIZATION CMOV ON|OFF}
{$OPTIMIZATION IFCONV ON|OFF}

4. 라이브러리

이 섹션은 RAD Studio 라이브러리에 대한 모든 업데이트와 향상을 설명한다.

4.1 새 VCL 컨트롤들

이번 릴리스는 두 가지 새로운 현대적 VCL 컨트롤을 새로 도입했다. TTabView와 TNavigationView다.

4.1.1 TTabView 컨트롤

새 TTabView 컨트롤은, TTabSet 컨트롤(계속 사용 가능)의 새로운 현대적 변형이다. 이 컨트롤에는 고급 기능을 갖춘 탭 컬렉션이 포함되어 있다. 시각적으로 이 컨트롤은 TFormTabsBar 컨트롤처럼 보인다. 하지만, 다음과 같은 새로운 추가 기능을 갖추고 있다:

• 탭은 폼뿐 아니라 다양한 컨트롤을 호스팅할 수 있다.
• 각 탭에는 이미지, 여러 줄 텍스트, 닫기 버튼이 있다.
• 드롭다운 버튼이 있다. 이것은 탭의 전체 목록을 드롭다운 메뉴로 보여준다. 또한 새 탭을 추가하는 버튼이 있다.
• 스크롤 버튼이 탭의 왼쪽과 오른쪽에 배치된다.

이 컨트롤은 Microsoft의 WinUI TabView 컨트롤과 닮았다는 점을 참고하자. 이 컨트롤은 TTitleBarPanel과 함께 사용할 수 있다.

다른 컨트롤과의 상호작용은 TabIndex 프로퍼티,특정 이벤트들(OnInitTab, OnSelectTab 등), 그리고 아래에 있는 탭을 위한 특정 프로퍼티들을 통해 이루어진다:

• Data: TPointer
• Control: TControl
• Tag: Integer

4.1.2 TNavigationView 컨트롤

TNavigationView 컨트롤(WinUI NavigationView와 유사)은, 수직형 항목 컨트롤이다. 이것은 어떤 멀티페이지 컨트롤, TFrame, 페이지들을 담고 있는 써드-파티(Third-Party) 컨트롤과도 함께 사용할 수 있다.

TNavigationView 컨트롤에는 수직 항목 컬렉션이 포함되어 있다. 이는 고급 기능을 갖추고 있다. 항목은 특정 프로퍼티와 이벤트를 가진 컨트롤(예를 들어 TCardPanel 컨트롤)과 연결할 수 있다. 각 항목은 이미지와 여러 줄 텍스트를 포함할 수 있으며, 특정 이벤트에 맞게 시각적으로 커스터마이징할 수 있다. 항목은 스크롤할 수 있고, 드래그해서 순서를 바꿀 수도 있다. 컨트롤은 일반 너비 또는 컴팩트 너비 중 하나를 가질 수 있다.

아래 예시는 이 새 컨트롤을 사용하는 데모이다:

4.2 FMX 스타일 디자이너 확장들

이번 릴리스는, RAD Studio 13.1에서 도입된 FMX Style Designer 기능을 확장했다. 그러기 위해 방대한 새 기능 세트를 붙였다. 이제는 이 도구에 직접 접근할 수 있다. Tools > FMX Style Designer로 가면 된다.

새 기능들 중, 이것들이 가장 중요한 추가 사항이다:

• Bitmap Style Designer로 생성된 VSF 스타일 형식 파일을 로드한다. 그래서 기존 스타일을 시작점으로 놓고 거기에서부터 작업할 수 있다.
• Sizes 섹션의 이름을 변경했다. 이제는 Variables 섹션이다. 이것은 이제 소수 값을 지원한다. 이는 glow나 shadow softness 같은 효과 프로퍼티에서 유용하다.
• Search 탭을 사용하면, 대규모 프로젝트에서 이름으로 색상, 스타일, 기타 리소스를 빠르게 찾을 수 있다.
• 스타일 분석 도구는 프로젝트를 스캔해 다음을 표시한다 :
  • 사용되지 않는 색상, 글꼴, 효과, 이미지.
  • 더 이상 존재하지 않는 요소를 가리키는 깨진 참조.
  • 중복된 스타일 이름.
  • 빈 스타일 이름.
• 벡터 도형 요소에는 기존 Rectangle에 더해, Circle과 Ellipse가 추가되었다.
• 벡터 요소들을 위한 래스터화(Rasterize) 옵션. 비트맵 기반 스타일이 필요하거나 선호되는 경우를 위한 옵션이다.
• 기존 Shadow에 더해, 새로 Glow 효과를 추가했다.
• 여러 효과를 결합해 동일한 요소에 적용할 수 있도록 지원.
• 그라디언트 색상 리소스들.
• 효과는 스타일의 Text와 Icon 프로퍼티 바로 아래에서 구성할 수 있다.
• 워드랩, 정렬, 트리밍 등 텍스트 파라미터를 포함하는 완전한 텍스트 레이아웃 제어.

4.3 FireMonkey 품질 향상들

이번 릴리스의 FireMonkey 향상에는 아래와 같은 것들이 포함된다:

• Skia4Delphi를 버전 7.1.0에서 버전 7.2.0으로 업데이트했다. 이 업데이트는 Windows 7 지원을 복원하고, Linux 호환성을 넓힌다. 또한 렌더링 성능 수정들도 포함되었다.
• FireMonkey 애플리케이션의 반응성을 다시 다듬고 향상시켰다. Windows 플랫폼에서 애니메이션을 사용하는 애플리케이션을 위한 개선이다.
• 최소 지원 API 레벨을 24 이상으로 설정한 애플리케이션인 경우에는, classpath를 Android DEX 컴파일러에게 제공하지 않도록 했다(해당 도구를 호출할 필요가 없기 때문이다).

4.4 FireDAC(파이어닥)

이번 릴리스의 FireDAC 업데이트에는 아래와 같은 것들이 포함된다:

• PostgreSQL 18.4를 지원하도록 FireDAC를 업데이트했다.
• off 연결 파라미터(connection parameter)를 추가했다. 기본값은 off다.
• Linux에서의 Informix 지원을 추가했다. Connect to Informix 페이지를 참고하면, Linux에서 Informix ODBC 드라이버와 함께 FireDAC를 사용하는 방법에 대한 자세한 정보를 볼 수 있다.

4.5 WebStencils(웹스텐실즈)와 인터넷

다음 섹션은, 13.2 릴리스에 포함된 WebStencils와 인터넷 관련 업데이트 및 향상들을 나열한다:

• WebStencils는 이제 데이터셋의 TField 정보에 접근하는 명시적인 방법을 제공한다. 특정 패치(@dataset.fields.<fieldname>)를 사용하면 된다.
• ESocketTimeoutError 라는 특정 예외 클래스를 System.Net.Socket에 추가했다.
• IHTTPNativeAPI 인터페이스를 추가했다. 그래서 HTTPRequest의 원본 인증서 컨텍스트에 접근할 수 있도록 허용한다. Windows와 Linux 상에서 IHTTPRequest와 IHTTPResponse에 의해 구현된다.
• REST OAuth 지원에서, 이번 릴리스는 PKCE를 사용한 Authorization Code Flow를 추가했다. 이를 구현하기 위해, 새 프로퍼티가 추가되었다: TOAuth2Authenticator.UsePKCE / CodeVerifier.
• TWebFileDispatcher의 URL 매칭 로직(고정 경로 대 마스크 경로)이 향상되었다. 경로가 "/"이거나 빈 문자열인 상황에 대한 향상이다.

4.6 RAD Server(라드 서버)

이번 릴리스부터, 사용자 이름과 그룹 이름을 열 기준으로 정렬할 수 있는 기능이 RAD Server Management Console에 추가되었다.

또한, 이번 릴리스는 RAD Server Management Console을 업데이트 해 HiDPI를 인식하도록 했다.

4.7 기타 참고 (See Also)

• Installation Notes(영문)
• Release Notes(영문)
• New features and fixed issues(영문)
• 과거 버전들의 새 기능 모아 보기(영문)

View full RAD 스튜디오 버전별 신기능

• 제목: RAD Studio 13.2 Florence Is Here
• 작성자: Marco Cantu - 2026년 9월
• 링크 https://blogs.embarcadero.com/rad-studio-13-2-florence-is-here/ 

13.2 새 기능 한국어 더빙 비디오 링크: https://www.youtube.com/watch?v=3otvJYG21BQ

엠바카데로는 RAD Studio 13.2와 함께, Delphi 13.2 플로렌스(Florence), C++Builder 13.2 플로렌스(Florence)의 출시를 발표하게 되어 기쁘다. 이번 릴리스는, 컴파일러 기술과 성능, Linux와 Windows on Arm, 개발자 생산성, 현대적인 UI 개발, C++Builder, AI 통합, 제품 전반의 품질에 초점을 맞추고 있다.

이번 릴리스에는 담긴 내용이 상당히 많다. 여기서 모든 변경 사항을 하나하나 다루기보다는, 이번 릴리스의 핵심 향상들과 품질 향상의 주요 영역을 짚어보고자 한다. 개발자들이 가장 많이 체감할 부분을 중심으로 제시한다.

목차

• 새 Delphi LLVM 20 컴파일러가 Linux용으로 제공된다
• C++Builder Win64x는 계속 발전한다
• 훨씬 더 빠른 컴파일, 그리고 더 빠른 애플리케이션
• Navigator는 이제 RAD Studio 안의 한 부분이 되었다
• 새 VCL 내비게이션 컨트롤들
• 더 강력해진 FireMonkey Style Designer
• 런타임 패키지가 Windows on Arm에서 지원된다
• AI 컴포넌트들 그리고 MCP 개발
• 기타 대규모 품질 향상
• FireMonkey, Skia, Android, 데이터베이스, 웹
• RAD Studio 13.2 플로렌스 요약
• RAD Studio 13.2 플로렌스, 오늘 출시

새 Delphi LLVM 20 컴파일러가 Linux용으로 제공된다

13.2의 가장 큰 변화 중 하나는, Linux Intel 64비트용 새 Delphi LLVM 20 컴파일러와 도구체인이다.

전체 Linux64 도구체인이 LLVM 20으로 전환되었다. 여기에는 최신 링커와 더욱 풍부해진 디버그 정보가 포함된다. Linux 64비트용 컴파일러 자체는 32비트와 64비트 바이너리로 제공되므로, 32비트 IDE와 64비트 IDE 모두에서 사용할 수 있다.  즉, 64비트 IDE에서는 이제 Windows 64비트와 Windows on Arm뿐만 아니라 Linux64도 타겟 플랫폼으로 선택할 수 있다. 물론 기존 32비트 IDE에서도 Linux64 개발을 계속할 수 있다. 다만 대규모 Linux 프로젝트를 개발한다면 64비트 IDE를 사용하는 것이 유리하다.

이번 릴리스가 특히 중요한 영향을 주는 경우를 꼽자면, 만약, Delphi로 Linux 서비스, 미들웨어, 데이터베이스 애플리케이션, 또는 기타 서버 쪽 개발을 하고 있는 경우이다. 물론 FMXLinux 애플리케이션도 이 새 컴파일러의 혜택을 함께 누릴 수 있다.

(64비트 IDE에서, Linux 타겟 추가하기)

C++Builder Win64x는 계속 발전한다

C++Builder 개발자를 위한 중요한 작업도 함께 이루어졌다.

이제 현대적인 Win64x C++ 컴파일러는 이제  IDE 안에서 직접 실행되는 인프로세스(in-process) 컴파일러이다. 이를 통해 IDE는 정확한 파일과 줄 진행 상황을 얻을 수 있다. 구조화된 진단 정보를 통해 소스로 다시 이동할 수 있다. 빌드 취소가 신속하게 반응한다. 병렬 컴파일을 지원한다. 그러면서도 전체 빌드 과정을 IDE 안에서 통합적으로 관리할 수 있다.

우리는 또한, 패키지-기반 C++ 개발도 계속 향상시켰다. 디자인 타임 패키지, Delphi 유닛을 포함하는 패키지, 의존성, 리소스, 프로젝트 전반에 걸친 패키지 사용 등이 여기에 포함된다.

불필요한 재빌드도 줄었다. 또한, Windows Arm64EC와 Linux Intel 64비트용 Delphi에는 메모리 할당이 많은 애플리케이션을 위한 선택 사항으로 rpmalloc 메모리 매니저가 추가됐다.

64비트 IDE에서, 인-프로세스(In-Process) C++ 컴파일

훨씬 더 빠른 컴파일, 그리고 더 빠른 애플리케이션

우리는, Linux Intel 64비트와 Windows Arm64EC 양쪽 모두를 위해 LLVM 기반 Delphi 컴파일러들의 성능에 중요한 작업을 진행했다.

이제 이 LLVM 기반 컴파일러들은 여러 유닛의 코드를 여러 CPU 코어에서 병렬로 생성할 수 있다. 이는 대규모 프로젝트와 Release 빌드에서 특히 큰 차이를 만든다. 우리의 내부 테스트에서는 일부 대표적인 FireMonkey 프로젝트의 Release 빌드에서 컴파일 시간이 최대 14배까지 단축되는 결과가 확인됐다.

우리는 또한, 컴파일러 최적화에서도 새로운 세대를 실현했다. 우리의 내부 테스트에서는 코드에 따라 Release 애플리케이션의 실행 시간이 약 2~4배 단축되었다. 일부 테스트에서는 약 7배의 향상이 측정됐다.

또한, Windows Arm64EC에는 FastMM4 기반 메모리 매니저가 새 기본 메모리 매니저로 제공된다. 여기에 더해, 새 메모리 매니저 선택 사항으로 고성능 rpmalloc 메모리 매니저가 제공된다. 따라서 메모리 할당이 많거나 멀티스레드 작업이 많은 애플리케이션에서 다른 메모리 관리 전략을 선택할 수 있다.

다시 말해, 13.2는 단순히 최신 플랫폼을 지원하는 것에 그치지 않는다. 그 플랫폼들에서 Delphi를 현격하게 더 빨라지도록 하는 데도많은 노력을 기울였다.

 Navigator는 이제 RAD Studio 안의 한 부분이 되었다

지난 RAD Studio 13.1에서 Bookmarks를 통합한 데 이어, 이번 13.2에서는 다음 단계로 넘어갔다. 그래서, Navigator를 IDE 안에 직접 통합했다.

Navigator의 Goto 대화상자는, 매우 빠르게, 그리고 실시간으로, 유닛, 타입, 메서드, 기타 심벌에 접근할 수 있도록 한다. 특히 유용한 경우를 꼽자면, 대규모 코드 기반에서 작업하면서 찾고 있는 것이 무엇인지는 어렴풋이 알고 있지만 파일을 뒤지는 데 시간을 쓰고 싶지 않을 때이다.

에디터 미니맵도 향상되었다. 그래서 현재 소스 파일의 구조, 활성 줄, 중단점, 오류 주석을 보여준다.

이것은, 설명하기가 꽤 간단한 기능이다. 하지만, 대규모 애플리케이션을 탐색하며 하루를 보내는 경우라면, 놀라울 만큼 큰 차이를 만들어낸다.

Navigator 플러그인의 미니맵, 이제 IDE에 통합되었다

새 VCL 내비게이션 컨트롤들

Windows 개발자를 위해, 13.2는 두 가지 새로운 VCL 컨트롤을 추가했다. TTabView 그리고 TNavigationView다.

TTabView는 현대적인 탭 UI를 제공한다. 이미지, 여러 줄 캡션, 닫기 버튼, 탭 추가 버튼, 스크롤 기능, 열려 있는 탭을 선택할 수 있는 메뉴 등을 제공한다. 각 탭은 폼이나 다른 컨트롤과 연결할 수 있기 때문에 특정 콘텐츠 컨테이너를 강제로 사용하지 않아도 된다. 그래서 문서 방식 애플리케이션, 대시보드, 개발 도구, 기타 멀티뷰 인터페이스와 잘 맞는다.

TNavigationView는 현대적인 세로형 내비게이션 UI를 제공한다. 일반 모드와 컴팩트 모드, 이미지, 여러 줄 텍스트, 스크롤, 드래그 앤 드롭 순서 변경, 다양한 사용자 지정 기능 등이 포함된다.

이 두 컨트롤은, 더 현대적인 Windows 인터페이스를 더 쉽게 만들 수 있도록 설계되었다. VCL 프로그래밍 모델 안에 완전히 그대로 있으면서 구현할 수 있다.

다크 모드의 TNavigationView 컨트롤

더 강력해진 FireMonkey Style Designer

13.1에서 소개했던 FireMonkey Style Designer가, 13.2에서 대대적으로 업데이트되었다.

이제 이 디자이너를 IDE에서 직접 실행할 수 있다. 또한 Bitmap Style Designer의 기존 VCL Style Format 파일을 가지고 시작할 수도 있다. 또한, 검색·분석 도구들이 추가되었다. 그래서 사용하지 않는 리소스, 깨진 참조, 중복된 이름, 기타 잠재적 문제를 찾아낼 수 있다.

디자인 측면에서는, 새로운 그라디언트 리소스, Circle과 Ellipse 벡터 요소, 래스터화, 글로우 효과, 한 요소에 여러 효과 적용 지원, 더 완전해진 텍스트 레이아웃 옵션 등이 들어갔다.

목표는, 정교한 FireMonkey 스타일 만들기와 유지보수를 훨씬 더 쉽게 할 수 있도록 만드는 것이다. 특히 스타일이 크고 복잡해질 때 그렇다. FireMonkey Style Designer는 개발자가 직접 사용할 수도 있지만, 그래픽 디자이너가 스타일 작업을 담당할 수 있도록 설계된 도구이기도 하다. 사용자 경험은 널리 사용되는 디자인 도구와 유사한 방향으로 구성됐다.

FireMonkey Style Designer에서 스타일 분석하기

런타임 패키지가 Windows on Arm에서 지원된다

Windows on Arm 작업 중 또 하나의 중요한 조각이, 13.2에서 완성되었다. Windows Arm64EC용 Delphi 런타임 패키지다.

이제 Windows on Arm에서 동적 런타임 패키지를 만들 수 있다. 또한 사용할 수도 있다. 이는, Delphi의 패키지 아키텍처를 사용하는 애플리케이션을 Windows on Arm 이전할 수 있으며, 그 아키텍처를 포기하거나 모듈화 방식을 다시 설계할 필요 없다는 뜻이다.

이미 대규모 Delphi 애플리케이션을 가지고 있는 개발자들에게 이것은, Windows on Arm을 타겟으로 삼는 것을 방해하던 또 하나의 중요한 장벽을 없애준다.

AI 컴포넌트들 그리고 MCP 개발

또한, RAD Studio 개발자가 사용할 수 있는 AI 컴포넌트들에 들인 작업도 상당히 많았다.

SmartCore AI Components Pack도 대폭 리팩토링되었다. Delphi와 C++Builder 에서 사용할 수 있으며 GetIt(겟잇)을 통해 제공된다. OpenAI, Anthropic Claude, Google Gemini, Ollama의 API와 기능에 대한 접근의 폭이 훨씬 더 넓어졌다. 그러면서도, 기존과 변함없이 "특정 AI 제공업체에 종속되지 않는" 아키텍처를 그대로 유지한다. 이 기능은 앞으로 며칠 안에 GetIt을 통해 사용할 수 있게 된다.

이를 통해 여러분은 빌딩 블록을 얻을 수 있다. 여기에는 대화형 애플리케이션, 콘텐츠와 이미지 생성, 구조화된 응답, 데이터 분석, 애플리케이션 전용 어시스턴트, 기타 AI 기반 기능들 등이 포함된다. 각 AI 제공업체의 API 연동 코드를 애플리케이션에서 일일이 직접 구현하지 않아도 된다.

RAD Studio 13.2에는 Delphi와 C++Builder용 추가 GetIt 다운로드로 MCPConnect도 포함되어 있다.

MCPConnect는, Model Context Protocol(MCP) 서버 만들기 그리고 기존 애플리케이션의 기능, 비즈니스 로직, 데이터, 프롬프트를 AI 클라이언트와 에이전트에 노출하기 등의 일을 훨씬 더 쉽게 할 수 있도록한다. MCP 프로토콜 구현에 필요한 상당 부분을 대신 처리해 준다. 즉, 라우팅, 직렬화, 스키마 생성, 세션, HTTP와 표준 I/O 통신 등을 처리한다. 그래서 여러분은, 애플리케이션이 실제로 제공하는 것들에만 집중할 수 있다.

MCPConnect 겟잇 패키지 아이콘

기타 대규모 품질 향상

13.2와 같은 릴리스의 향상은, 눈에 띄는 새 기능들만이 전부가 아니다. IDE, 디버거, 컴파일러, 프레임워크, 데이터베이스, 플랫폼 전반에 걸친, 더 작지만 종종 눈에 띄게 체감되는 수많은 문제들도 계속 해소해 왔다.

IDE에는, 중괄호와 괄호 매칭, Linux 방식 줄바꿈, High DPI 폼 상속, C++ 구문 강조 표시, 모듈 다시 불러오기, Object Inspector, IDE Insight 등 여러 향상들이 들어 있다.

LLDB 기반 디버거는 최신 C++ 데이터 구조를 비롯해 Delphi의 Variant, 배열, 프로퍼티를 검사하는 기능을 강화했다. 또한 심볼 처리 속도를 높이고 디버거 오버헤드를 줄였다.

새롭게 강화된 LLVM 기반 플랫폼을 위한 다양한 수정 사항도 반영되었다. Linux 공유 라이브러리와 DataSnap 배포, Windows Arm64EC의 링킹, 디버깅, 예외 처리, 부동소수점, 제네릭, 임포트된 함수, 리소스, 정적 라이브러리 상호운용성 등이 여기에 포함된다.

FireMonkey, Skia, Android, 데이터베이스, 웹

프레임워크와 플랫폼 전반에도 업데이트가 있었다.

Skia4Delphi는 버전 7.3으로 업데이트되며, 다양한 수정 사항과 Linux 호환성 확대, Windows 7 런타임 지원, 렌더링 성능 향상 등이 포함된다. 또한, Windows에서 FireMonkey 애니메이션의 반응성도 개선했다. Per-Monitor v2 High DPI를 위한 스타일 뷰어 도구도 향상시켰다.

Android에서는, 기본 최소 지원 SDK가 이제는 API 레벨 24다. 이에 맞는 설치 관리자와 NDK 업데이트도 함께 진행되었다. 우리는 Google AdMob과 Google Maps 라이브러리도 새로 고쳤다. Android의 Age Verification API(연령 확인 API) 및 관련 애플리케이션 entitlement에 대한 저수준 접근도 추가했다. 이 Age Verification API는 iOS에서도 사용할 수 있다.

FireDAC은, PostgreSQL 18.4 지원, 구성 가능한 Oracle CLOB 프리페칭, Informix ODBC 드라이버를 통한 Linux에서의 IBM Informix 연결 등이 추가되었다.

웹과 인터넷 개발을 위해서, 우리는 PKCE를 사용한 OAuth 2 Authorization Code Flow를 추가했다. 소켓 타임아웃 처리, HTTP 인증서 정보, REST Debugger URL 검증, 웹 파일 디스패칭에 대한 향상도 함께 이루어졌다.

WebStencils(웹스텐실즈)는 이제 데이터셋 필드 정보에 대한 명시적 접근을 제공한다. 한편 RAD Server Management Console에는, 사용자·그룹 열을 정렬할 수 있고 High DPI 지원이 향상되었다.

RAD Studio 13.2 플로렌스 요약

RAD Studio 13.2에는, 훨씬 더 많은 내용이 담겨 있다. 그래서 이 발표 글 하나에서 다룰 수 있는 수준이 아니다. 하지만 이 글을 통해, 이번 릴리스의 전체적인 방향은 분명히 파악할 수 있을 것이라고 생각한다.

우리는 차세대 Delphi 컴파일러에 크게 투자했다. 이번 버전은 특히 Linux와 Windows on Arm에 집중했다, 이와 동시에 그 컴파일러들을 훨씬 더 빠르게 만들었다. 또한 우리는, 일상적인 IDE 경험, 현대적인 Windows UI 개발, FireMonkey 스타일링, C++Builder, 데이터베이스와 웹 개발, 개발자가 자신의 애플리케이션을 빠르게 진화하는 AI 생태계에 연결하는 데 필요한 도구들도 계속 향상시켰다.

RAD Studio 13.2 플로렌스, 오늘 출시

더 많은 정보는 다음에서 확인할 수 있다:

• 엠바카데로 웹사이트의 새로운 기능 페이지 (www.embarcadero.com/products/rad-studio/whats-new-in-13-florence)
• 13.2를 다루는 docWiki 페이지 (https://docwiki.embarcadero.com/RADStudio/Florence/en/13_Florence_-_Release_2)
• 13.2 관련 블로그 기고들 (링크)
• 이번 릴리스에서 수정된, 공개적으로 제보된 문제 목록을 담은 docwiki 페이지 (링크)

우리는 앞으로 며칠 안에 Quality Portal 항목들도 이 결과물과 동기화 할 예정이다.

우리는, 여러분이 RAD Studio, C++Builder, Delphi를 가지고 진행하는 일상적인 개발에서 이번 릴리스가 가치 있다고 느낄 것이라 확신한다.

RAD Studio 13 플로렌스(Florence) Update 2를 통해, 개발 경험을 한 단계 끌어올려 보자.

• 제목: Markdown4D, and how we built it with AI
• 작성자: Marco Geuze - 2026년 9월
• 링크 https://blogs.embarcadero.com/markdown4d-and-how-we-built-it-with-ai/ 

이 글은 Marco Geuze(엠바카데로 MVP이자 엠바카데로 기술 파트너인 GDK Software의 창립자)가 작성한 게스트 블로그 글이다.

GDK Software에서 우리는, 몇 년째 AI 도구를 개발에 활용해 오고 있다. 2년 전만 해도 가끔이었지만, 오늘날에는 모든 개발자가 AI와 함께 일한다.

AI로 많은 작업을 하다 보면, AI 시스템들이 마크다운으로 작업하는 것을 선호한다는 것을 알게 된다. 마크다운은 텍스트를 서식화하는 간단한 방법이다. 몇 개의 태그만으로 목록, 제목, 표를 만들 수 있다. 모든 현대적인 (웹) 시스템들이 이를 지원한다.

하지만 Delphi에는, VCL과 FireMonkey 둘 다에서 마크다운을 표시하고 렌더링할 수 있는 컴포넌트가 없었다. 마크다운이 스트리밍되는 도중에 표현할 수 있는 컴포넌트는 말할 것도 없었다.

그래서 우리는 직접 하나를 만들었다. 그리고, GitHub에 공개했다: github.com/GDKsoftware/Markdown4D

이 글은, 4만 줄이 넘는 이 라이브러리를 만들기 위해 우리가 Claude Code를 어떻게 활용했는지에 관한 것이다.

목차

• Markdown4D: 캔버스 위의 마크다운
• 이것을 개발한 방법
• 교육 프로그램

Markdown4D: 캔버스 위의 마크다운

Delphi에서 마크다운을 사용하고 싶다면, 지금까지는 두 가지 선택지가 있었다. 오픈소스 도구로 마크다운을 HTML로 변환한 다음, 그 HTML을 브라우저 컴포넌트에서 렌더링하는 방법, 그게 아니면, 서식을 제거하고 그냥 일반 텍스트로 보여주는 방법이다. 첫 번째 방법은 무겁고 다루기 번거로웠다. 두 번째 방법은 기능을 빼고 제공한다. 게다가 두 방법 모두, 텍스트가 아직 들어오는 중일 때(스트리밍) 렌더링하는 것은 불가능했다.

Markdown4D는 이 두 가지 문제를 모두 해결한다. 이것은 CommonMark와 GFM 라이브러리다. Delphi용으로 작성되었으며, 외부 라이브러리나 의존성이 없다. 이 라이브러리는 IMarkdownDocument를 제공한다. 이것은 사용하기가 아주 쉽다. 그리고 여러분에게 필요한 모든 작업을 할 수 있다. 증분(incremental) 파서들도 제공된다. 그래서 변경된 부분만 다시 읽을 수 있다. 우리는 TMarkdownViewer와 TMarkdownEditor를 제공한다. VCL과 FMX 양쪽 모두를 위한 것이다. 그것들이 사용하는 API는 동일하다. 기능은 폭넓다. 테마 지원, 선택, 검색, 코드 블록의 구문 색상 표시, 폼 디자이너에서의 미리보기까지 포함된다. 차트도 다룬다. 막대, 선, 파이, 산점도 다이어그램을 지원한다. 심지어, mermaid 다이어그램까지 네이티브로 들어가 있다.

시작하려면, 런타임에 컴포넌트를 간단히 생성하면 된다:

uses
 Markdown4D.Theme,
 Markdown4D.Vcl.Viewer;

const Viewer = TMarkdownViewer.Create(Self);
Viewer.Parent := Self;
Viewer.Align := alClient;
Viewer.ThemePreset := TMarkdownThemePreset.Dark;
Viewer.Text := '# Welcome'#10#10 + 'This is **Markdown4D**.';

렌더링은 네이티브 방식이다. 브라우저가 필요 없다. 레이아웃 엔진이 레이아웃을 처리한다. 그리고 페인터가 캔버스에 그린다. 이것이, Markdown4D가 매우 빠른 이유다. 이미 여러분이 Delphi에서 익숙하게 사용하는 방식이다.

그런 다음, 우리가 이 라이브러리를 만든 진짜 목적인 부분이 나온다:

procedure TAIForm.OnChunkReceived(const Chunk: string);
begin
 FViewer.AppendMarkdown(Chunk);
end;

만약 여러분이 AI로 작업해 봤다면(요즘 안 해본 사람이 있을까), 언어 모델이 텍스트를 조금씩 나눠 반환한다는 것을 알 것이다. 사용자 입장에서는, AI가 답변을 완전히 마칠 때까지 기다리고 싶지 않다. 무슨 일이 일어나는지 보고 싶어 한다. Markdown4D를 사용하면, 이것을 아주 간단하게 구현할 수 있다. 청크(chunk)가 완전할 필요도 없다. 단어의 일부일 수도 있고, 볼드 구간일 수도 있고, 표 전체일 수도 있다. Markdown4D의 증분 파서는, 청크가 들어오는 동안에도 렌더링이 정확하게 이루어지도록 보장한다.

내부적으로, 써드-파티(Third-Party) 코드는 전혀 사용되지 않는다. 안티앨리어싱 래스터라이저와, 뷰어 뒤에 있는 SVG 엔진까지 포함해, 모든 것이 네이티브 코드다. 그래서 설치는 매우 쉽다. 그저 검색 경로에 추가하기만 하면 된다. 디자인 타임 컴포넌트를 사용하고 싶다면, 패키지를 열어 설치하기만 하면 된다.

이것을 개발한 방법

Markdown4D 라이브러리는, Claude Code의 도움을 받아 만들었다. 이때 우리는, 방대한 스캐폴딩과 가이드라인을 사용했다. GDK Software 내부에서 도구 모음으로 개발해 왔던 것들이다. 이런 모든 도구들이 없이 Claude Code만 사용했다면, 우리가 스스로 세운 요구 사항을 충족하지 못했을 것이다. 완전한 컴포넌트도 결코 나오지 못했을 것이다. 하지만 우리가 개발해 온 모든 지식과 도구들을 가지고 있었기 때문에, 그리 많은 사람의 노력 없이도 이 라이브러리를 완성했다.

여러분도 직접 이런 것을 개발할 수 있게 되고 싶거나, 이 지식을 활용해 자신의 애플리케이션을 더 빠르고 더 좋게 확장하고 싶을 수 있을 것이다. 그래서 우리는 이 지식을 전달하기 위한 교육을 개발했다. 교육 프로그램은 아래와 같다.

교육 프로그램

이 교육, "Claude Code for Delphi"는, 1일 교육이다. 최대 수강 인원은 20명이다. 우리 GDK Software에서 AI와 함께 일하는 방식을 설명한다. 수강생은 그 모든 도구(tool)들과 스킬(skill)들을 각자의 코드 기반에 맞춰진 형태로 가져갈 수 있다. 참여하고 싶다면, 아래의 일정 중에서 선택하면 된다:

• 2026년 10월 26일 월요일, Utrecht(네덜란드어로 진행)
• 2026년 10월 29일 목요일, Frankfurt
• 2026년 11월 11일 수요일, London
• 2026년 12월 1일 화요일, Ruhr 지역
• 2027년 1월 12일 화요일, Leipzig
• 2027년 1월 26일 화요일, 독일 남부
• 2027년 2월 9일 화요일, Fredericia, Denmark

프로그램 및 등록: training.gdksoftware.com

• 영상 구성: 20분 = 12분 발표 + 8분 데모

이 데모의 마이그레이션 개요  

• 전환 대상: C++Builder 6.0에서 제공하던 '파리잡기' 데모 게임을 C++Builder 13.1로 업그레이드 마이그레이션
• 전환 목표: 기능을 동일하게 유지하면서 C++Builder 13.1 버전으로 이전하기 (세 가지 플랫폼 빌드 타겟 모두 성공: 32-bit, 64-bit, 64-bit Modern) 
• 사용 도구: Kai 1.1 + Claude
• 소요 시간: 20분 (실제 작업은 5분, 나머지 시간은 Kai가 분석한 내용을 파악하고, Kai가 제시한 계획을 검토하고, 3 가지 플랫폼에서 테스트 하는데 씀)  

이 Swat 게임을 마이그레이션 대상으로 선택한 이유

• 구하기 쉽다 (C++Builder 6.0 설치 CD 1번 안에 있는 Examples 폴더 아래 Games 폴더 안에 있음) 
• 매우 간단한 하다
• 대표적인 마이그레이션 기술 이슈들 즉, 유니코드 대응 이슈, 64-bit 대응 이슈, 오래된 BCB 라이브러리를 새 CLang 기반으로 대응 해야 하는 이슈들이 모두 한 두 가지씩 코드에 담겨 있다.

가장 중요한 프롬프트 (나머지는 작성된 계획에 따라 Kai와 함께 따라가면 완료됩니다)

"D:\Install\program files\Borland\CBuilder6\Examples\Games\swat 에는
C++Builder 6.0으로 만든 프로젝트의 모든 소스 코드가 들어 있어.
이 프로젝트를 C++Builder 13.1 프로젝트로 만들고 싶어.
기존 코드를 분석하고, 단계별 작업 계획을 수립해줘."

영상 보기 (20 min)

발표 자료 (PDF):

https://drive.google.com/file/d/1pRuisnfsEU1V78nkAOiJF_xGmBgVkYM9/view?usp=drive_link

• 제목: Coming in RAD Studio 13.2: A Better Modern C++Builder Win64x Build Experience
• 작성자: Maksim Menshikov - 2026년 9월
• 링크 https://blogs.embarcadero.com/coming-in-rad-studio-13-2-a-better-modern-cbuilder-win64x-build-experience/ 

우리가 진행하고 있는 작업들 중 Clang 기반 C++Builder Win64x 컴파일러와 프로젝트 시스템에 대한 것들을 미리 보기

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

몇 년 전에 비해, 현대 C++은 훨씬 더 많은 것을 가지고 있다. 그것의 발전 속도도 훨씬 더 빨라졌다. 현재 우리는 C++23을 지원한다. 승인된 표준 중 최신 버전이다. 하지만 우리는 이 언어 표준을 넘어, 포괄적인 계층을 제공한다. 소프트웨어 개발을 훨씬 더 빠르게 만들어주는 계층이다. 이것이 13.2에서 우리 작업의 초점이었다.

목차

• 패키지 향상
• 64비트 IDE에서의 컴파일
• 진단 정보와 취소
• 더 적은 재빌드 그리고 기타 변경 사항
• 디버거
• 맺음말

패키지 향상

우리 팀은 Win64x에서의 패키지 지원을 크게 향상시켰다. 여기에 포함되는 것들은 디자인 타임 64비트 패키지, Delphi 유닛을 담은 패키지, Delphi와 C++가 혼합된 패키지 사용하기, 도구체인에서 사용하는 패키지 디버그 정보 파일 만들어내기 등이다. 이 변경 사항들은, 컴포넌트 제공사들 그리고 이미 런타임 패키지를 중심으로 구성되어있는 애플리케이션들에게 중요하다. 또한 IDE에서 더 높은 성능과 안정성도 제공한다.

64비트 IDE에서의 컴파일

현재 버전의 Clang 기반 C++Builder Win64x 컴파일러는, 컴파일할 때마다 별도의 실행 파일로 동작한다. 우리는 프로세스 안에서 동작하는 즉, 인프로세스(in-process) 컴파일러를 추가하고 있다. 즉, DLL을 통해 노출되도록 하는 방식이다. 그러면 IDE가 컴파일러를 계속 로드된 상태로 유지할 수 있다. 그 상태에서 서로 직접 통신할 수 있다.

C++ Builder 13.2의 빌드 화면

이것은 중요한 아키텍처 변경이다. IDE에서 눈에 보이는 효과도 가져온다. 컴파일러는 정확한 파일과 줄 진행 상황을 보고할 수 있다. 구조화된 진단 정보를 Messages 뷰로 보낼 수 있다. 취소 요청에 더 신속하게 응답할 수 있으며, 외부 프로세스를 반복적으로 시작하는 데 드는 몇몇 오버헤드들도 피할 수 있다.

진단 정보와 취소

이제 컴파일러 오류와 경고는 구조화된 진단 정보로 전달된다. IDE가 나중에 따로 해석해야 하는 콘솔 텍스트 줄이 더 이상 아니다. 그 덕분에 Messages 뷰는 올바른 파일과 줄로 신뢰성 있게 이동할 수 있다. 또한 빌드가 진행되는 동안 더 좋은 정보를 IDE에게 제공한다.

취소는, 우리가 다시 작업한 또 다른 영역이다. 큰 빌드를 중지하면, 그 요청은 활성화된 컴파일러 작업에 직접 전달된다. 그래서, 남은 작업이 종료되는 동안에도 IDE는 계속 반응한다. 겉보기에는 사소해 보일 수 있다. 하지만 큰 의미가 있다. 특히, 잘못된 구성으로 빌드를 시작했을 때, 또는 첫 번째 오류로 인해 남은 작업이 불필요해졌을 때 더욱 그렇다.

더 적은 재빌드 그리고 기타 변경 사항

우리는, Project Options를 변경했을 때 실제 필요보다 더 많은 부분이 프로젝트에서 재빌드되는 경우를 줄였다. 그 밖의 수정 사항들로는, 리소스와 DFM 경로, 아이콘 리소스, 잘못된 순환 프로퍼티 정의 등이 있다. 개별적으로 보면, 이것들은 '프로젝트 시스템'의 세부 사항이다. 그런데 함께 합쳐지면, 일반적인 편집-빌드-디버그 세션에서 여러 가지 방해 요소들을 없애준다.

디버거

엄밀히 말해 C++에 국한된 이야기는 아니다. 13.2는 디버거에도 상당한 향상을 가져온다. 우리는 심벌 로딩 성능, 대규모 솔루션을 다루는 디버거 능력 등을 향상시켰다. 이는 업데이트된 C++ 패키지 관리와 함께 특히 잘 동작한다.

C++ Builder 13.2의 디버거 화면

맺음말

RAD Studio 13.2는, 일상적인 C++Builder Win64x 개발 경험에 대한, 집중적이고 실용적인 투자가 있었음을 잘 보여준다. 인프로세스 컴파일러로의 전환, 구조화된 진단 정보, 더 신속하게 반응하는 취소, 더 똑똑해진 재빌드 감지, 이 모든 것은 같은 목표를 향한다. 그 목표는 코드를 작성하는 것과 그것이 실행되는 것을 보는 것 사이의 방해 요소들을 줄이는 것이다.

패키지 개선 사항은, 컴포넌트 제공사들 그리고 더 큰 애플리케이션들이 Win64x 도구체인을 완전히 받아들일 수 있도록 문을 열어준다. 한편 디버거 성능 향상은, 프로젝트가 커지더라도 계속 관리 가능한 수준으로 복잡한 솔루션을 탐색하는 일을 유지할 수 있도록 한다.

종합해 보면, 이 변경 사항들은 단순히 C++ 표준을 따라가는 것을 넘어선 우리의 다짐을 보여준다. 그 다짐은 빌드-디버그 전체 주기를 더 빠르고, 더 예측 가능하고, 더 투명하게 만들겠다는 것이다. 13.2가 정식 출시(GA)되면, 여러분의 피드백을 듣고 싶다.

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

• 제목: Coming in RAD Studio 13.2: Improving the Everyday RAD Studio IDE Experience
• 작성자: Marco Cantu - 2026년 9월
• 링크 https://blogs.embarcadero.com/coming-in-rad-studio-13-2-improving-the-everyday-rad-studio-ide-experience/ 

IDE 변경 사항 모음: 각 개별 기능은 작지만, 일상적인 작업에서 눈에 띄는 것들.

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

다가오고 있는 RAD Studio 릴리스에서는, Navigator와 미니맵을 IDE 안에 통합한 작업 외에도, 여러 작은 향상들을 해냈다. 오랫동안 남아있던 여러 문제와 불편함도 해결했다. 이 모든 것이 합쳐져, IDE에 더 나은 경험을 가져다준다. 이 글에서 나는, 코드 에디터, 디자이너, Object Inspector, 파일 처리, IDE Insight에 걸친 여러 향상 영역을 모아보고자 한다.

이런 변경들은 사람들이 쉽게 알아차릴 수 있는 것들이다. 왜냐하면, 일상적인 작업에 직접적으로 관여하기 때문이다. 또한 하나의 헤드라인으로 요약하기 어려운 경향도 있다. 그러니 각 영역마다 살펴보자.

목차

• 파일, 폼, 디자이너 힌트
• 코드 편집
• Object Inspector와 IDE Insight
• 일상적인 작업 향상시키기

파일, 폼, 디자이너 힌트

새로운 Reload Open Modules 명령은, 디스크에서 변경된 파일을 다시 불러온다. 이는 브랜치 전환, 코드 생성 단계, 다른 도구로 수행한 편집 등이 발생한 후에 유용하다.

우리는 또한, IDE가 High DPI 모드에서 실행될 때의 폼 상속(form inheritance)을 향상시켰다. 또한 상속된 베이스 폼을 디자이너에서 더 쉽게 열 수 있도록 했다.

VCL 컨트롤용 디자이너 힌트는, 이제 더 유용한 정보를 보여준다. FireMonkey 뷰어에는 추가적인 High DPI 작업이 반영되었다. 이것은, 이번 릴리스 전체에서 내가 가장 좋아하는 작은 새 기능이다.

예전 디자이너 힌트(왼쪽)와 새 디자이너 힌트(오른쪽)

코드 편집

중괄호 매칭이 향상되었다. 그래서 문자열이나 주석 안의 중괄호가, 더 이상 에디터에서 헷갈리게 표현되지 않는다. 우리는 또한, Linux 줄바꿈 방식을 사용하는 파일 안에 있던 문제인 여러 코드 삽입을 바로잡았다. 이 문제들은 생성되거나 리팩토링된 코드를 넣을 때 의도한 위치에서 한 글자 벗어난 곳에 배치시키는 경우가 있었다. 이 수정들은, 관련된 약 20건의 고객 리포트들을 반영했다.

C++ 구문 강조 표시는, 이제 더 많은 C++11 형식을 인식한다. 이진 리터럴, 숫자 구분 기호, raw 문자열 리터럴 등이 해당된다. 이 변경 사항 중 어느 것도 컴파일러를 바꾸지 않는다. 하지만 여러분이 작업하는 동안, 에디터는 소스를 더 정확하게 표현해 줄 것이다.

Object Inspector와 IDE Insight

Object Inspector는 더 이상, 문자열 프로퍼티에 예전처럼 2,000자 제한을 두지 않는다. 더 긴 문자열 값을 가지는 컬렉션 항목들에도 여러 줄 에디터가 제공된다. 이는, 큰 값을 한 줄 안에서 편집하던 방식보다 훨씬 더 실용적이다.

IDE Insight에도 변경이 있었다. 옵션 항목들, 렌더링 방식, 결과가 없는 경우에 알려주는 방식 등이 해당된다. 우리는 또한, 메인 메뉴를 제목 표시줄 안에 배치하는 작업과, 키보드 단축키 표현을 더 분명하게 키캡(key-cap) 스타일로 표시하는 작업도 계속 진행해왔다.

"모던(modern)" 버전 IDE Insight가 화면 중앙에 대화상자 형태로 표시되고 있다
메뉴 항목과 IDE Insight 안을 보면, 단축키에 적용된 새로운 모습("key-cap 스타일")도 눈에 띈다.

일상적인 작업 향상시키기

타겟 플랫폼이나 새 컨트롤은, 새 기능이라고 쉽게 알아볼 수 있다. 하지만 IDE의 품질과 사용성을 좌우하는 것은 개발자가 매일 빈번하게 마주치는 작은 마찰 지점들에 대한 해결이다. 신뢰할 수 있는 코드 삽입, 정확한 중괄호 매칭, 긴 문자열 프로퍼티 편집 기능 등으로 인해, 여러분이 애플리케이션 코드를 바꾸거나 새로운 타겟 플랫폼을 고려할 필요가 없다. 이것들은 그저, IDE가 걸리적거리지 않도록 해줄 뿐이다. 나는, 이 작은 향상들을 Delphi와 C++Builder 개발자들이 반겨줄 것이라고 확신한다. 여기에는 오래 기다려온 개선 사항들도 있다.

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

• 제목: Kai 1.1 is Here: A More Connected, Flexible, and Powerful AI Experience for RAD Studio
• 작성자: Marco Cantu - 2026년 9월
• 링크 https://blogs.embarcadero.com/kai-1-1-is-here-a-more-connected-flexible-and-powerful-ai-experience-for-rad-studio/ 

Kai 1.1이 오늘 출시되었다. 이번 릴리스는 매우 중요한 새 릴리스다. Kai가 AI 공급업체 그리고 대규모 언어 모델에 연결하는 방식이 훨씬 더 유연하다.

Kai 1.1에는 방대한 피드백이 반영되어 있다. 기존 사용자들 그리고 자신의 작업흐름에 AI를 어떻게 도입할지 고민하는 개발자들 모두에서 제시한 의견들이 반영되었다. 새 버전은 여러분이 사용할 수 있는 AI 솔루션들의 범위를 크게 확장한다. 즉, 원하는 공급업체와 더 쉽게 작업할 수 있다. 그러면서도 데이터 주권, 프라이버시, 보안 요구 사항을 충족한다.

이는, 더 유연한 기반을 만들어낸다. 그 기반은 에이전틱 AI를 RAD Studio 개발 작업흐름 안으로 가져올 수 있도록 한다.

우리는 Kai를 GetIt(겟잇) 패키지 관리자를 통해 제공한다. 또는 고객 포털을 통해 별도 다운로드로도 제공한다. 그러므로, 릴리스가 준비되는 즉시 내놓을 수 있다. 즉, RAD Studio 전체 릴리스보다 훨씬 더 빠르게 제공할 수 있다.

목차

• AI 에이전트를 연결하는 새로운 방식
• 더 좋아진 Kai 경험
• 더 좋아진 로컬 AI 지원
• AI 보조 코딩을 위한 더 탄탄한 기반

AI 에이전트를 연결하는 새로운 방식

Kai 1.1의 가장 큰 변화는 ACP Registry 통합이다.

이전에는, 다양한 CLI AI 엔진들과의 통합이 Kai에 함께 포함되어 제공되었다. 1.1 버전에서, 이 통합들은 설치 후 공개 레지스트리에서 다운로드된다. 그래서 훨씬 더 폭넓은 그리고 계속 진화하는 에이전트 생태계에 Kai가 접근할 수 있게 된다.

ACP Registry는 AI 에이전트들의 공개 레지스트리다. JetBrains와 Zed Industries가 공동으로 소유하고 유지보수한다. Kai 1.1은 이 레지스트리를 사용해 통합을 관리한다. ACP Registry에는 현재 35개 이상의 에이전트가 포함되어 있다. 이미 지원되던 Claude, GPT-5, Gemini CLI 같은 에이전트뿐 아니라, Antigravity, Grok, Mistral, Cursor, Devin, Kilo Code, Junie 같은 새로운 옵션들도 있다. 사용자는 레지스트리를 검색하고, 에이전트를 필터링하고, Kai에서 직접 설치할 수 있다. 그리고 해당 업데이트가 있는지도 Kai 구성 화면에서 바로 확인할 수 있다.

이 아키텍처는 또한, 새 에이전트가 ACP Registry에 추가되기만 하면 곧바로 Kai에서 사용할 수 있게 된다는 뜻이다. Kai의 새 릴리스를 기다릴 필요가 없다.

ACP Registry 인터페이스 (Kai 1.1 설정 화면 안에 있다)

더 좋아진 Kai 경험

Kai 1.1은 또한, 폭넓은 UI·UX 개편도 함께 선보인다.

새로 디자인된 인터페이스에는 다음이 포함된다:

• 단색 아이콘(icon)들과 글리프(glyph)들
• 더 좋아진 여백
• 새로운 채팅 툴바
• 더 깔끔해진 구성 페이지
• 더 일관성 있는 채팅 에디터 영역
• 향상된 '불리언(boolean) 옵션' 컨트롤
• 그 밖에도 수많은 사용성 향상

이번 릴리스는 또한, 고객이 제보한 여러 채팅 관련 문제들도 해결했다. 원치 않는 팝업, 스크롤 문제, 긴 텍스트에서의 성능, 명령 팔레트 동작, UI 이벤트 처리 등이 해당된다.

업데이트된 Kai 채팅과 새 툴바

더 좋아진 로컬 AI 지원

Kai 1.1은 또한, 기존 로컬 AI 지원도 강화했다. 이를 위해, 새로운 Native LM Studio ACP 에이전트를 제공한다.

이름에 LM Studio가 적혀있지만, 이 에이전트는 LM Studio와 Ollama 양쪽 모두와 동작한다. 그래서 개발자는 더 매끄러운 방식으로 로컬 AI 모델들을 Kai를 통해 작업할 수 있다.

AI 보조 코딩을 위한 더 탄탄한 기반

Kai 1.1은, 이 플랫폼의 중요한 진화를 잘 보여준다.

계속 늘어나는 에이전트 레지스트리, 직접 설치와 업데이트, 향상된 로컬 AI 지원, 새로 디자인된 인터페이스, 수많은 품질 개선을 통해, Kai는 RAD Studio 개발 경험의 더 유연하고 확장 가능한 부분이 되어가고 있다.

Kai 1.1은 단순한 새 버전이 아니다. AI 보조 코딩을 위한 더 탄탄한 기반이다.

더 알아보고 Kai 1.1 받기

Kai 1.0.x에서 Kai 1.1로 업그레이드할 때는, 여기에서 마이그레이션 안내를 확인하면 된다.

• 제목: Football Playview Is An Outstanding Mobile Delphi App
• 작성자: Embarcadero Admin - 2021년 4월
• 링크 https://blogs.embarcadero.com/football-playview-quarterback-keep/ 

Football Playview을 사용하면, 코치와 선수들은 애니메이션으로 된 플레이, 드릴, 연습 계획을 휴대폰이나 태블릿에서 확인할 수 있다. 풋볼 플레이, 드릴, 연습 계획은, Jes-soft에서 만든 짝꿍 데스크탑 프로그램인 Football Playbook을 사용해 만들 수 있다. 이 프로그램은 무료로 체험할 수 있으며, http://www.jes-soft.com/football/index.html에서 받을 수 있다. 이 플레이북 프로그램은 최근 버전의 Windows와 모두 호환된다.

여러분의 플레이와 연습 계획을 데스크탑에서 만든다. 그것들을 클라우드 드라이브(예를 들어 gdrive, DropBox)에 저장한다. 그러면 클라우드 드라이브에서, 모바일 기기를 사용해 그 플레이와 연습 계획을 열어볼 수 있다.

웹사이트

Football Playview

스크린샷 갤러리

더 많은 사례를 알고 싶다면, 아래 모아 보기를 활용하면 된다.

• 엠바카데로 공식 블로그(영어): 영어 개발 사례(showcase) 기고들
• 데브기어 포럼(한국어): 한국어 개발 사례 기고들

• 제목: Coming in RAD Studio 13.2: Build Modern Windows User Interfaces with Two New VCL Controls
• 작성자: Marco Cantu - 2026년 9월
• 링크 https://blogs.embarcadero.com/coming-in-rad-studio-13-2-build-modern-windows-user-interfaces-with-two-new-vcl-controls/ 

TabView와 NavigationView 미리보기 정보 (VCL에 새로 추가하려고 하는 두 가지 컨트롤)

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

엠바카데로가 지속적으로 집중해오고 있는 영역은  고객이 현대적인 UI로 Windows 애플리케이션을 만들 수 있도록 하는 것, 그러면서도 고객들이 투자해 온 VCL 라이브러리를 계속 관리할 수 있도록 하는 것이다. 최근 몇 년 동안, 우리는 새로운 탭 컨트롤들을 추가해 왔다. 그것들은 폼을 다루는 데 초점을 맞추어져 있다 (MDI 폼들을 오늘날의 방식으로 옮기는 것도 포함). 이 노력은 앞으로 나오는 릴리스에서도 계속된다. 이번에는 내비게이션을 위한 두 가지 새 VCL 컨트롤이다. 즉 TabView와 NavigationView다. 이 컨트롤들은 오늘날의 Windows 애플리케이션들이 사용하는 패턴(그리고 WinUI3 사용자 인터페이스 패러다임)을 따른다. 그런데, 이것들은 일반 VCL 컨트롤다. 그리고, 기존에 가지고 있는 폼, 프레임, 페이지 컨트롤, 애플리케이션 코드와 함께 동작하도록 설계되었다.

우리는 이 두 컨트롤을 동시에 함께 작업했다. 서로 연관된 문제들을 해결하는 것들이기 때문이다. TTabView는 주로 문서나 뷰를 위한 수평 탭을 제공한다. TNavigationView는, 수직 내비게이션을 제공한다. 애플리케이션의 주요 영역에 흔히 쓰이는 것이다.

목차

• 새 TabView 컨트롤
• 새 NavigationView 컨트롤
• 스타일링과 커스텀 드로잉
• 계속 개선되는 VCL

새 TabView 컨트롤

TabView 컨트롤은, TabSet 컨트롤을 대신할 새로운 대안이다. 탭 하나는 폼 하나 또는 다른 컨트롤 하나와 연결할 수 있다. 그래서 특정 콘텐츠 컨테이너를 강제로 사용할 필요가 없다. 각 탭마다 여러분은 이미지, 여러 줄 텍스트, 닫기 버튼(선택사항)을 넣을 수 있다.

예전에는 탭 스트립을 쓸만 하게 하기 위해 상당한 커스텀 코드를 넣어야 했지만, 그런 기능들이 이미 이 컨트롤에 들어 있다. 즉, 탭 추가 버튼, 모든 탭을 나열하는 드롭다운, 탭이 더 이상 들어가지 않을 때 나타나는 스크롤 버튼이 구현되어 있다. TTabView는 TTitleBarPanel 위에 배치할 수 있다. 그러면 요즘 브라우저나 개발 도구와 비슷하게, 커스텀 제목 표시줄 안에 탭 넣어 사용할 수 있다.

새 NavigationView 컨트롤

NavigationView 컨트롤은, 수직 목록이다. 그 안에는 내비게이션 항목들이 나열된다. 항목 하나는 멀티페이지 컨트롤 안에 해당되는 페이지 하나, 프레임 하나, TCardPanel 안에 있는 카드 하나, 또는 써드-파티(Third-Party) 페이지 컨트롤에 의해 관리되는 콘텐츠를 가리킬 수 있다. 이것의 느슨한 연결은 의도된 것이다. 그래야, 기존 애플리케이션이 모든 콘텐츠를 새로운 컨테이너로 옮기지 않아도 이 컨트롤을 사용할 수 있기 때문이다.

이 컨트롤에는 일반(normal) 모드와 컴팩트(compact) 모드가 있다. 일반 모드는 이미지와 텍스트를 표시한다. 컴팩트 모드는 이미지는 유지하고 내비게이션 영역의 너비를 줄인다. 내장된 메뉴 버튼을 사용하면 두 모드를 전환할 수 있다. 항목 안에는 여러 줄 캡션과 힌트를 넣을 수 있다. 마우스 휠로 스크롤할 수 있으며, 드래그 앤 드롭으로 순서를 바꿀 수 있도록 하는 것도 선택적으로 가능하다.

스타일링과 커스텀 드로잉

여러 내장 선택 스타일들이 있다. 여기에는 테마 적용형, 컬러형, 사각형, 둥근 모서리형 등이 해당된다, 색상은 현재 활성화된 VCL 스타일을 따를 수도 있고, 직접 선택할 수도 있다. 더 세밀한 제어가 필요한 애플리케이션을 위해, 드로잉 이벤트들이 제공된다. 그래서 항목 전체 또는 항목의 콘텐츠만 따로 커스터마이징할 수 있다.

이 두 컨트롤은 함께 사용할 수도 있다. 예를 들어, NavigationView로 애플리케이션의 주요 영역을 선택하고, 그 영역에서 열린 문서를 TabView가 담당하도록 할 수 있다. 아니면 두 컨트롤을 각각 독립적으로 사용할 수도 있다.

계속 개선되는 VCL

우리는 새 UI 컨트롤을 계속 추가해 왔다. 그래서 기존 VCL 애플리케이션을 현대화하는 데 도움이 되어 왔다. 또한, 현대적인 모습의 새 애플리케이션을 만드는 데도 쓰일 수 있는 것들이다. 이번 컨트롤들도 그 방향으로 가는 또 하나의 발걸음이다. 우리는 이 방향으로 계속 갈 계획이다. 또한 다른 한편으로는, 상당한 노력을 스타일, HiDPI, 등 라이브러리의 여러 현대적인 기능에 대한 지원을 향상시키는데 집중하고 있다. 또한, 이 영역에서 고객이 제보하는 티켓들을 반영하고 있다.

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

• 제목: Coming in RAD Studio 13.2: Navigate Large Codebases Faster with the New Integrated Navigator
• 작성자: Marco Cantu - 2026년 9월
• 링크 https://blogs.embarcadero.com/coming-in-rad-studio-13-2-navigate-large-codebases-faster-with-the-new-integrated-navigator/ 

Goto, 에디터 미니맵, 현재 보고 있는 코드에 대한 더 많은 정보.

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

13.1 릴리스에서 우리는 향상된 Bookmarks 기능을 통합했다. 원래는 Parnassus가 개발했고, GetIt(겟잇) 패키지로 제공되던 것이었다. 이제 Navigator에도 같은 작업을 하고 있다. 새로 통합된 Navigator 덕분에 이제는, Goto 창과 에디터 미니맵을 RAD Studio 안에 들어간다. 설정은 일반 IDE 옵션에서 하면 된다.

Navigator는 대규모 프로젝트에서 가장 유용하다. 프로젝트가 크면, 많은 심벌의 이름과 위치를 찾아야 하고, 그것들은 여러 유닛들에 퍼져있다. 실제로, 우리 고객 대다수가 운영하고 있는 프로젝트들이 그렇다.

목차

• 유닛, 타입, 메서드로 이동하기(Goto)
• 미니맵
• IDE의 일부가 되다

유닛, 타입, 메서드로 이동하기(Goto)

Goto 창은 유닛, 타입, 메서드, 그 밖의 심벌을 검색한다. 또한 타이핑하는 동안 결과를 필터링한다. 심벌 이름 전체를 기억할 필요도, 프로젝트 트리를 일일이 각 유닛마다 훑어볼 필요도 없다. 결과에서 선택을 하면 IDE는 그곳으로 곧바로 이동한다.

이것은 조그마한 작업흐름 기능이다. 하지만 수십 번씩 사용하게 되는 기능이다. 호출 체인을 따라가거나 낯선 프로젝트를 익힐 때 주로 사용된다. GoTo 창은 미니맵과도 함께 동작한다. 그래서 도착하는 위치는 그저 고립된 한 줄이 아니다. 현재 소스 파일 안 어디에 있는지도 바로 확인할 수 있다.

Navigator 구성, Goto 대화상자, 에디터(배경에 미니맵이 함께 보임)

미니맵

미니맵은, 에디터 옆에 전체 소스 파일을 축소해서 렌더링한다. 그 축소된 크기로는 코드를 읽을 수 없다. 그런 목적이 아니다. 선언, 메서드, 빈 영역, 주석의 형태를 통해 긴 유닛의 특정 부분을 알아챌 수 있다. 그리고 그것들 사이를 빠르게 이동할 수 있다.

원래 제공되던 이전 플러그인과 다르게, 우리는 활성 줄 표시(active-line marker)를 추가했다. 그래서 미니맵에서 현재 위치를 확인할 수 있다. 또한 스크롤바 주석(Editor Scrollbar Annotations)도 확장했다. 그래서, 중단점과 Error Insight 결과를 표시한다. 예를 들어, 유닛 아래쪽에 여러 오류가 모여 있다거나, 현재 보고 있는 코드 근처에 중단점이 있다는 것을 확인할 수 있다. 게다가 파일을 직접 스크롤하지 않고도 그 위치로 바로 이동할 수 있다.

에디터 미니맵이 실제로 동작하는 모습

IDE의 일부가 되다

여기서 핵심적인 변화는, 이 탐색 도구들이 에디터의 일부가 되었다는 점이다. 그래서 상태를 공유할 수 있게 되었다. Goto가 담당하는 것은 "이 메서드는 어디에 있는가?"라는 심벌 관련 질문이다. 미니맵이 담당하는 것은 "이 유닛 안에서 나는 지금 어디에 있는가?"라는 시각적 질문이다. 이 도구들을 IDE에 통합함으로써, 이런 것들을 이루어냈다. 품질도 함께 향상시켰다. 별도의 설치 단계도 없앴다. 향후 개선을 위한 탄탄한 기반도 마련했다.

만약 여러분이 대규모 Delphi나 C++ 프로젝트로 작업하고 있다면, 이 기능을 몇 일 동안 직접 써 보면 그 가치를 더 쉽게 판단할 수 있다. 다음 릴리스에서 만나게 될 RAD Studio IDE의 관련 개선 사항은 이것 말고도 많다. 나는 그중 몇 가지를 다른 블로그 글에서 소개할 예정이다.

기능 미리보기: 이 블로그 글의 기반은 RAD Studio 소프트웨어의 사전 릴리스 버전이다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

• RAD Studio 13.2에서 만날 새 기능: Delphi의 LLVM-20 컴파일러로 더 빠른 빌드와 더 빠른 애플리케이션
• RAD Studio 13.2에서 만날 새 기능: Linux Intel 64비트용 Delphi 개발의 새로운 세대
• RAD Studio 13.2 새 기능 보기 웨비나에 등록하세요

특집: InterBase MCP 서버

• InterBase와 Agentic AI 연결하기: InterBase MCP Server 발표
• MCP 기반 작업흐름을 사용해, InterBase 데이터베이스 탐색하기
• (InterBase 기고 모아보기)

인기

[기고/백서] 인기글

• 하루 만에 FireDAC(파이어댁)로 마이그레이션하기: reFind(리파인드)와 Kai(카이)를 활용
• Kai Summer Wave 웨비나 시리즈 – 멋진 5일을 요약
• Delphi(델파이) 개발자를 위한 SBOM 작성 가이드

[인기 비디오]

• [한국어 더빙] Kai를 사용해 90분만에 게임 만들기

[개발 사례]

• RockQuest를 소개한다, Kai Summer Wave의 첫 번째 슈퍼 증정품 수상작!
• 5개의 Kai 프로젝트가 Summer 캠페인에서 첫 증정품 수상자로 선정되었다!
• 궁극의 수학 시각화 소프트웨어가 델파이 전체 소스 코드까지 제공한다

[How to (팁, 트릭, 쇼츠 등)]

• Kai Summer Wave에 "한국 생초보의 아마추어 무선 로그북 만들기"가 소개되었습니다

RAD Studio 프로모션: Keychron 키보드 무료 증정 등 데브기어에 문의하기

View full 엠바카데로 기술자료

오늘 엠바카데로(Embarcadero)가 자사의 주력 데이터베이스 엔진(Engine)인 InterBase(인터베이스) 15의 업데이트 버전을 출시했음을 기쁘게 알린다. InterBase는 강력하고, 관리가 필요 없고(zero-administration), 점유 공간이 적은(small footprint) 데이터베이스 엔진이다. 이 데이터베이스를 사용하면, 여러분의 데이터를 되는 모든 환경에서 사용할 수 있다. 서버(Server)로 실행될 수도 있고, 모바일 장치(Device)들에서 임베디드 데이터베이스로 실행될 수 있다.

InterBase 15 Update 1은 InterBase 15 사용자들을 위한 유지보수 업데이트이다. 이번 릴리스는 InterBase 15의 견고한 기반 위에 구축되었다. 따라서 강화된 암호화 및 보안 능력들을 포함하고 있다. 이 릴리스는 AI 기능이 강화된 IBConsole(아이비콘솔) 버전을 처음으로 선보인다. 또한, 여러 가지 품질 및 플랫폼 개선 사항들도 반영되어 있다.

이번에 IBConsole에 새로 추가된 Smart CodeInsight(스마트 코드인사이트)는, 사용자가 원한다면, AI 지원 기능을 직접 데이터베이스 관리 및 SQL 개발 작업흐름(Workflow) 안에 넣을 수 있도록 한다. 보안성이 뛰어난 BYOK(Bring-Your-Own-Key) 방식을 사용하기 때문에, 사용자들은 LLM 제공사들, 즉 OpenAI, Gemini, Claude 등을 연결할 수 있을 뿐만 아니라 추론 엔진들, 즉 Ollama(올라마) 및 LM Studio(엘엠 스튜디오) 등을 통해 오프라인 모델(Model)들에도 연결할 수 있다. 개발자들과 DBA들은 IBConsole의 Smart CodeInsight를 통해, 데이터베이스와 상호작용할 때 자연어를 사용할 수 있다. 그래서, SQL을 생성하거나 최적화하기, 쿼리(Query)를 설명하기, 데이터베이스 오브젝트(Object)들을 문서화하기, InterBase 안의 실시간 메타데이터에 기반한 맥락 인식 가이드 등을 활용할 수 있다.

IBConsole Smart CodeInsight는 AI를 직접 대화형 SQL 환경과 데이터베이스 관리 도구들에 통합하기 때문에 숙련된 DBA와 애플리케이션 개발자 모두의 생산성을 향상시킨다. 사용자는 개발 작업들을 간소화하고 반복적인 수작업을 줄이고 복잡한 SQL 작업들을 단순화할 수 있다.

AI 기능들 외에도, IBConsole의 UX(사용자 경험)이 상당히 향상되었다. 특히, 사이드 트리 뷰(Side tree view)와 탭(Tab)들을 활용하는 탐색 전반이 향상되었다.

이번 릴리스는 수많은 품질 향상들을 포함하고 있다. 전반적인 안정성, 사용성, 플랫폼 호환성이 더 높아졌다. 예를 들어, Windows Server 2025 및 Ubuntu Linux 24 설치에 대한 지원이 향상되었다.

목차

IBConsole Smart CodeInsight 상세 정보

이 기고에서 지금부터 나오는 내용은 IBConsole의 Smart CodeInsight 기능들에 대한 더 많은 정보들이다. 이 기능들은 RAD Studio(라드 스튜디오)의 SmartCore AI(스마트코어 AI) 컴포넌트들을 활용하여 구축되었다. 이는 IBConsole이 Delphi(델파이)로 작성되었기 때문이다. IBConsole은 VCL과 IBX 컴포넌트들과 AI 컴포넌트들을 사용해 개발되었다.
 

멀티-엔진(Multi-Engine) AI 지원

IBConsole의 Smart CodeInsight는 여러 가지 AI 엔진들과 모델들을 지원한다. 따라서, 기관(Organization)이 선호하는 AI 제공업체들과 구성들을 유연하게 선택할 수 있다. 지원되는 기능들은 다음과 같다:

• 구성할 수 있는(Configurable) AI 엔진(Engine)들
• 모델(Model) 선택
• API 기반 통합(Integration)들
• 연결 테스트
• 창(Window)별 엔진(Engine) 선택

IBConsole의 Smart CodeInsight 구성화면

만약 AI 사용이 여러분의 계획에 포함되어 있지 않더라도 걱정할 필요 없다. 왜냐하면, 이 통합 기능은 기본적으로 꺼져(Off) 있다. 그리고, 전적으로 여러분의 통제하에 있다. 이 아키텍처는 고객들이 자신들만의 보안, 규정 준수, 인프라 요구 사항들에 맞춰 AI 사용을 조정할 수 있도록 해준다. 위 그림은 Smart CodeInsight 구성 대화 상자의 이미지이다.
 

'AI가 파워를 더하는' SQL 보조

사용자들은 IBConsole 내부에서 AI와 직접 상호작용할 수 있다. 자연어 프롬프트(Prompt)를 사용하면 된다. 이 체계는 맥락에 맞는 SQL 생성, 쿼리 설명, 서식 적용(Formatting), 최적화, 저장 프로시저(Stored procedure) 생성 등을 지원한다.

기능 사례:

• SQL 쿼리 생성
• 쿼리 최적화 권장 사항(Recommendation)들
• SQL 포맷팅 및 정리
• 쿼리 설명
• SQL Dialect(방언) 변환
• SQL로부터 저장 프로시저 생성

예를 들어, 여러분은 쿼리(Query)의 텍스트를 선택할 수 있다. 그러면 그에 맞는 여러 가지 다양한 옵션들을 수행할 수 있다. 아래 그림과 같다.  IBConsole의 쿼리 에디터 안헤서 Smart CodeInsight 기능을 활성화하기
 

맥락 인식 데이터베이스 인텔리전스

가장 돋보이는 새 기능들 중 하나는 IBConsole Smart CodeInsight의 메타데이터-인식 AI 프롬프팅 체계이다. 사용자가 데이터베이스 구조(Structure)들을 기억하고 수작업으로 설명하지 않아도, IBConsole은 지능형 매크로(Macro)들을 사용하여 스키마 메타데이터를 프롬프트에 자동으로 주입한다. 이를 통해 해당 AI 엔진은 다음의 요소들을 이해할 수 있다:

• 테이블(Table)들
• 뷰(View)들
• 저장 프로시저(Stored procedure)들
• 트리거(Trigger)들
• 인덱스(Index)들
• 도메인(Domain)들
• 관계(Relationship)들
• 쿼리 플랜(Query plan)들
• 에디터 선택 영역

그 결과, 실무적인 데이터베이스 작업들을 수행할 때, AI로부터 훨씬 더 정확하고 관련성 높은 응답을 얻을 수 있다. 아래 그림과 같이, 엔티티가 선택된 상태에서 Smart-CodeInsight 명령을 선택하면 관련 AI 기능들을 사용할 수 있다. 이 예시는 테이블(Table)의 필드(Field)를 선택한 경우이다.

테이블의 한 필드에 대해 IBConsole의 Smart CodeInsight 기능을 활성화하기
 

내장된 메타데이터 매크로(Macro)들

IBConsole Smart CodeInsight에는 강력한 매크로 체계가 들어 있다. 이것은 AI 채팅 창을 사용할 때, 데이터베이스 오브젝트들의 메타데이터를 AI 프롬프트 안에 자동으로 확장한다. 지원되는 매크로(Macro)들은 다음과 같다:

• 테이블(Table)들
• 뷰(View)들
• 프로시저(Procedure)들
• 트리거(Trigger)들
• 인덱스(Index)들
• 함수(Function)들
• 테이블스페이스(Tablespace)들
• 암호화 메타데이터
• 선택된 SQL 텍스트
• 에디터 전체 내용

이 기능을 사용하면, 개발자들이 스키마 세부 사항들을 AI 도구 안으로 수작업으로 복사/붙여넣기를 할 필요가 없다.
 

'AI가 보조하는' 성능 최적화

이 플랫폼은 개발자들이 데이터베이스 성능을 개선하도록 돕는다. 지능형 분석을 통해 지원하는 영역들은 아래와 같다:

• SQL 쿼리(Query)들
• 쿼리 실행 플랜(Execution plan)들
• 인덱스 선택도(Selectivity)
• 테이블 구조(Structure)들
• 메타데이터 관계(Relationship)들

위 영역(Area)들에서, IBConsole Smart CodeInsight가 할 수 있는 것들:

• 인덱스 개선 권장
• 쿼리 플랜 분석
• 쿼리 최적화 제안
• 스키마 정규화 기회 파악
   

문서 생성 자동화

IBConsole Smart CodeInsight는 설명용으로, 메타데이터와 도움말 스크립트들을 자동으로 생성할 수 있다. InterBase의 `ALTER DESCRIPTION` 구문을 사용하여 구현되었다.

이는 이런 면에서 기관(Organization)들을 돕는다:

• 데이터베이스 유지보수성 향상
• 신규 직원 초기 정착(Onboarding)을 가속화
• 도움말 문서집 작성을 표준화
• 기관의 내부 지식을 보존
   

대화형 SQL 에디터 통합

이 AI 조수는 IBConsole 안에 대화형 SQL 환경으로 깊숙이 통합되어 있다.

개발자들이 할 수 있는 것들:

• SQL을 하이라이트(Highlight)하고 최적화를 요청
• 선택된 쿼리를 설명
• SQL 서식 적용을 자동으로 하기
• SQL 을저장 프로시저로 변환
• 레거시 Dialect 1 SQL을 Dialect 3으로 변환
• 스키마 오브젝트들을 직접 드래그-앤-드롭해 프롬프트 안에 넣기

이를 통해, AI 보조 개발 작업흐름이 자연스러워진다. 이 InterBase용 IDE를 벗어나지 않아도 된다.
 

추가 정보

IBConsole Smart CodeInsight에 대한 더 자세한 내용들은 제품 도움말 문서집에서 확인할 수 있다. 시작 페이지는 여기다:

https://docwiki.embarcadero.com/InterBase/15/en/CodeInsight_Main_Window

일반적으로, InterBase 15.1 정보들은 다음 링크들에서 찾을 수 있다:

• 엠바카데로 웹사이트 제품 페이지: https://www.embarcadero.com/products/interbase
• 제품 문서 사이트 메인 페이지: https://docwiki.embarcadero.com/InterBase/15/en/Main_Page 

활성 InterBase 15 라이선스를 보유하고 있는 고객들은 my.embarcadero.com으로 가서 설치 프로그램 링크들을 찾을 수 있다. 평가판(Trial) 버전과 무료인 InterBase 15 Developer-Edition(개발자-에디션)은 엠바카데로 웹 사이트에서 다운로드 할 수 있다.  https://www.embarcadero.com/products/interbase/developer/free-download 

• 제목: Coming in RAD Studio 13.2: Faster Builds and Faster Applications with Delphi's LLVM-20 Compilers
• 작성자: Marco Cantu - 2026년 8월
• 링크 https://blogs.embarcadero.com/coming-in-rad-studio-13-2-faster-builds-and-faster-applications-with-delphis-llvm-20-compilers/ 

병렬 코드 생성, LLVM 최적화, 메모리 관리자 변경이 Linux Intel 64비트와 Windows Arm64EC를 위해 준비 중이다.

기능 미리보기: 이 블로그 글은 RAD Studio 소프트웨어의 사전 릴리스 버전을 기반으로 한다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

이전 글에서 나는 Linux Intel 64비트용으로 새로 작업된 Delphi 컴파일러를 다뤘다. 그 컴파일러와 Windows Arm64EC용 Delphi 컴파일러는, 이제 동일한 LLVM 20 세대를 기반으로 한다. 그래서 우리 R&D는 두 플랫폼에 걸쳐 컴파일러 작업을 공유할 수 있다.

컴파일러 성능을 이야기할 때는, 서로 별개인 두 가지 질문이 있다. 1) 애플리케이션을 빌드하는 데 얼마나 걸리는가? 2) 빌드된 후, 컴파일러가 만들어내는 코드는 얼마나 빠른가? 최신 LLVM은 더 뛰어난 최적화를 제공한다. 하지만 그러려면 컴파일러가 더 많은 작업을 해야 하고, 시간도 더 걸린다. 우리 팀은 이 두 측면 모두를 다루기 위해 상당한 노력을 기울이고 있다.

목차

• 병렬 코드 생성(Delphi 최초)
• 이 새 최적화기가 바꾸는 것
• Arm과 Linux의 메모리 관리자
• 런타임 패키지 그리고 기타 Windows on Arm 작업

병렬 코드 생성(Delphi 최초)

이제 64비트 컴파일러 실행은, 여러 Delphi 유닛들의 코드를 병렬로 만들어 낼 수 있다. 기본적으로, 이 컴파일러는 사용 가능한 프로세서 코어 수를 기준으로 워커(worker) 개수를 선택한다. 여러분은 그 값을 직접 재정의할 수 있다. 전역적으로 또는 프로젝트별로 또는 명령줄에서 하면 된다. 그래서, 컴파일러 문제를 격리해야 하는 경우에, 병렬 생성을 직접 끌 수도 있다.

새 "Number of workers" 옵션. Tools Options 대화상자 안에 있다

알아둘 점이 있다. 이 기능은 32비트 버전의 컴파일러와 32비트 IDE에서는 지원되지 않는다. 더 많은 메모리가 필요하기 때문이다. 즉, 대규모 애플리케이션을 빌드할 때, 사용 가능한 메모리를 초과할 가능성이 크기 때문이다.

향상 정도는 프로젝트와 빌드 구성에 따라 크게 좌우된다. 우리가 진행한 내부 테스트에서는, 10코어 Intel Core i9-13900H 시스템에서 FireMonkey 유닛을 다시 빌드했을 때, Debug 모드에서는 약 2배, Release 모드에서는 약 14배 더 빨랐다. 이 수치가 모든 프로젝트의 기준이라고 볼 수는 없다. 하지만 이 수치는, 병렬 작업이 왜 특히 최적화된 Release 빌드에서 중요한지를 보여준다. Release 빌드에서는 LLVM이 처리해야 할 작업이 훨씬 많다. 그러니, 상당히 느릴 수 있다. 이 기능이 없다면 말이다.

이 새 최적화기가 바꾸는 것

Linux Intel 64비트와 Windows Arm64EC 양쪽 모두에서, 이 컴파일러 프론트엔드는 이제 Delphi 코드를 더 폭넓은 LLVM IR 최적화 패스 집합들에 통과시키는 것을 할 수 있다. 여기에는 예외 처리도 해당된다. 예외 처리라는 영역은 언어의 의미론과 범용 최적화기가 정밀하게 맞춰져야 하는 영역 중 하나다.

우리 테스트 중 다수는, 런타임이 2배에서 4배 범위로 향상되는 것을 보여주고 있다. 특정 Conway's Life 테스트에서는 약 7배에 도달했다. Arm64EC의 Release 컴파일은 새 최적화를 켠 상태에서 더 오래 걸릴 수 있다. 현재 테스트에서 봤을 때는, 병렬 코드 생성을 고려하기 전 기준으로, 약 34%에서 42% 더 오래 걸린다. 이는 합리적인 트레이드오프(tradeoff)다. 컴파일러 시간을 더 들임으로써, 더 빠른 코드를 만들어낸다. 그런 다음, 사용 가능한 CPU 코어들을 활용해 기다리는 시간을 줄인다.

Arm과 Linux의 메모리 관리자

우리는 또한, Delphi의 FastMM4 기반 메모리 관리자를 Windows Arm64EC로 포팅했다. 그리고 거기에서도 그것을 기본값으로 삼았다. 13.1에서 제공했던 플랫폼 할당자(platform allocator)가 특히 느렸던 건 일부 재할당 패턴이었다. 거기에는 반복적인 문자열 연결도 해당된다. FastMM은 더 균형 잡힌 동작을 제공한다. 또한 Windows Delphi 개발자에게 이미 익숙한 누수 보고 기능도 그대로 유지한다.

FastMM4에 더해, 우리 팀은 rpmalloc 메모리 관리자도 도입하고 있다. Arm64EC와 Linux Intel 64비트 양쪽에서 대안으로 사용할 수 있다. 우리 테스트에서는 안정적이었다. 게다가 스레드가 대량으로 몰리는 멀티 스레드 할당 부하에서는 매우 빠를 수 있는 것으로 나타났다. 테스트에 따라 2배에서 30배까지 빨랐다. 트레이드오프는, 메모리 사용량이 더 높다는 점, 흔히 2배 정도, 그리고, FastMM에 준하는 내장 누수 보고 기능이 없다는 점이다. 그래서 rpmalloc은 기본값이 아니라 선택 사항으로 남아 있다.

런타임 패키지 그리고 기타 Windows on Arm 작업

컴파일러 변경과 함께, 우리는 Windows Arm64EC 플랫폼을 계속 채워나가고 있다. 가장 중요한 개선 사항은, 13.1에는 포함되지 않았던 기능이다. 바로 런타임 패키지 지원이다.

런타임 패키지 구성 (Windows on Arm 플랫폼용)

Windows on Arm 플랫폼에서는 런타임 패키지만 향상된 게 아니다. Windows on Arm 플랫폼을 위해, 부동소수점, 제네릭이 많은 코드 처리, 정적 라이브러리 호환성, 리소스, 링킹, 예외 처리, 임포트된 함수, 디버그 정보에 대한 향상을 위해 작업했다. 이 항목들 대부분은 헤드라인급 기능은 아니다. 하지만 이것들이 합쳐지면, 기존 Delphi 애플리케이션이 이 새 플랫폼으로 이전할 때 예상치 못한 문제 없이 진행될 수 있는지를 결정짓는다. 

이번 글과 이전 글은, RAD Studio 13.2에서 새롭게 선보이는 Delphi 컴파일러 작업을 정리한 것이다. 하지만 물론, 이번에 컴파일러만 향상되는 것이 아니다. 나는 13.2의 다른 제품 향상들에 대해서도 더 다룰 예정이다.

기능 미리보기: 이 블로그 글은 RAD Studio 소프트웨어의 사전 릴리스 버전을 기반으로 한다. 엠바카데로의 특별 허가를 받아 작성되었다. 제품이 정식 출시(GA)되기 전까지는, 어떤 기능도 확정된 것이 아니다.

원문 정보 (최종 번역일: 2026년 8월 30일):

• 제목: Exploring an InterBase Database with an MCP-Driven Workflow
• 작성자: Rizzato Fernando - 2026년 8월
• 링크 https://blogs.embarcadero.com/exploring-an-interbase-database-with-an-mcp-driven-workflow/ 

이전 글에서 우리는 InterBase Model Context Protocol(MCP) 서버를 소개했다. Delphi로 만들어진 이 도구는, 대규모 언어 모델(LLM)과 InterBase 데이터베이스를 연결해 준다. 이번 후속 글에서, 우리의 플레이그라운드 노트북을 공개한다. 실제로 진행된, 단계별 세션이다. 나는 ChatGPT를 사용해, InterBase 데이터베이스 인스턴스와 직접 상호작용했다. InterBase MCP 도구와 에이전틱 스킬을 사용해서 할 수 있었다.

지금까지 시도한 것들 그리고 그 결과들은 아래에서 확인해 보자:

목차

• 1. 스키마 파악하기
• 2. 스키마 문서와 ER 다이어그램 생성하기
• 3. 고객 데이터 살펴보기
• 4. 매출액 기준 상위 고객 찾아내기
  • 결과
• 5. 데이터베이스 대시보드 만들기
• 6. 여러 테이블을 결합한 스트레스 쿼리 구성하기
• 7. 복잡한 쿼리 실행 계획 설명하기
• 8. 메타데이터 변경/최적화 적용하기

1. 스키마 파악하기

프롬프트: 이 데이터베이스 안의 모든 테이블들을 나열해. 그런 다음, 각 테이블의 커럼, 데이터 타입, null 허용 여부, 기본 키, 외래 키, 인덱스를 보여줘.

이 데이터베이스 안에는 10개의 사용자 테이블이 있다:

이 카탈로그를 검사한 결과, 13개의 외래 키 관계가 확인되었다. 중심이 되는 트랜잭션 테이블은 SALES다. CUST_NO를 통해 CUSTOMER를 참조하고, SALES_REP를 통해 EMPLOYEE를 참조한다. employee, department, job, project 테이블은 핵심 조직 모델을 이룬다. 전체 컬럼-수준 출력은 schema-document.md로 저장했다. 거기에는 데이터 타입, null 허용 여부, 기본값, 제약 조건, 인덱스, 관계 요약이 포함되어 있다.

2. 스키마 문서와 ER 다이어그램 생성하기

프롬프트: Markdown 스키마 문서를 생성해. 그런 다음, 계층적 ER 다이어그램을 만들어. 그 다이어그램은 모든 컬럼, 데이터 타입, null 허용 규칙, 기본 키, 외래 키 관계를 담고 있어야 해.

솔직히 말해, ER 다이어그램을 생성하는 첫 시도는 잘 되지 않았다. 생성된 다이어그램은 아키텍트가 기대할 만한 형식이나 상세 수준을 맞추지 못했다. 조사를 좀 해본 후에 나는 AI 에이전트에게 특정 모델링 스킬을 넣어주었다. 그 스킬은 이 프로젝트에서 얻었다: https://github.com/imxv/Pretty-mermaid-skills

이를 통해, 우리는 매우 유망한 결과를 얻을 수 있었다. 나는 밀어붙일 여지가 더 있다고 믿게 되었다. 아래를 확인해 보자:

• schema-er.mmd: Mermaid 소스
• schema-er.svg: 렌더링된 벡터 다이어그램

3. 고객 데이터 살펴보기

프롬프트: CUSTOMER 테이블 안에 저장된 데이터를 보여줘.

이 테이블에는 15명의 고객이 있었다. 아래의 간략한 표는, 이번 실험 동안 가져온 식별 정보와 위치를 담은 필드들을 보여준다:

두 고객 즉 "Dallas Technologies"와 "Max"은 현재 보류 상태라고 표시되어 있었다.

4. 매출액 기준 상위 고객 찾아내기

프롬프트: 총 매출액이 가장 높은 상위 10개 고객을 반환하는 InterBase 쿼리를 작성하고 실행해.

InterBase 쿼리는 다음과 같았다. 잘 작동했다:

SELECT C.Cust_no,  
       C.Customer,  
       Sum(S.Total_value) AS Total_sales_value  
FROM Customer C  
JOIN Sales S ON S.Cust_no = C.Cust_no  
GROUP BY C.Cust_no,  
         C.Customer  
ORDER BY Total_sales_value DESC ROWS 1 TO 10

결과

Signature Design이 확실한 선두였다. 2위 고객의 매출액보다 2배 이상 많았다.

프롬프트: 지금 본 그 결과를 차트로 보여줘.

이 차트는 top-customers-chart.svg라고 저장했다.

5. 데이터베이스 대시보드 만들기

프롬프트: 대시보드를 만들어. 이 데이터베이스에서 가장 중요한 운영·분석 데이터를 요약해 보여주는 대시보드야.

결과물인 database-dashboard.html에는, 스키마 개수, 매출 KPI, 주문 상태, 고객 지역 분포, 상위 고객, 직원 급여 통계, 부서별 인원수, 테이블별 행 개수를 한눈에 보여주었다.

6. 여러 테이블을 결합한 스트레스 쿼리 구성하기

프롬프트: 데이터베이스 성능을 점검할 수 있는 쿼리를 만들어. 실용적인 범위 내에서 최대한 많은 관련 테이블을 조인하는 복잡한 쿼리 하나를 만들어.

최종 테스트 쿼리는 10개 테이블 중 9개를 조인했다. SALES를 드라이빙 테이블로 사용했다. 그리고 고객, 직원, 부서, 직무, 프로젝트, 프로젝트 예산, 급여 이력, 국가 데이터로 이어지는 관계를 따라가는 것이었다:

SELECT S.Order_status,
       Co.Country AS Country_name,
       Co.Currency,
       D.Department,
       J.Job_title,
       P.Product,
       Count(*) AS ROW_COUNT,
       Count(DISTINCT S.Po_number) AS Order_count,
       Count(DISTINCT C.Cust_no) AS Customer_count,
       Count(DISTINCT E.Emp_no) AS Sales_rep_count,
       Count(DISTINCT P.Proj_id) AS Project_count,
       Sum(S.Qty_ordered) AS Total_qty_ordered,
       Sum(S.Total_value) AS Total_sales_value,
       Avg(S.Total_value) AS Avg_sales_value,
       Min(S.Total_value) AS Min_sales_value,
       Max(S.Total_value) AS Max_sales_value,
       Avg(E.Salary) AS Avg_sales_rep_salary,
       Avg(D.Budget) AS Avg_department_budget,
       Avg(B.Projected_budget) AS Avg_projected_budget,
       Avg(Sh.Percent_change) AS Avg_salary_change_pct,
       Max(Sh.Change_date) AS Last_salary_change
FROM Sales S
LEFT JOIN Customer C ON C.Cust_no = S.Cust_no
LEFT JOIN Employee E ON E.Emp_no = S.Sales_rep
LEFT JOIN Department D ON D.Dept_no = E.Dept_no
LEFT JOIN Job J ON J.Job_code = E.Job_code
AND J.Job_grade = E.Job_grade
AND J.Job_country = E.Job_country
LEFT JOIN Project P ON P.Team_leader = E.Emp_no
LEFT JOIN Proj_dept_budget B ON B.Proj_id = P.Proj_id
AND B.Dept_no = D.Dept_no
LEFT JOIN Salary_history Sh ON Sh.Emp_no = E.Emp_no
LEFT JOIN Country Co ON Co.Country = Coalesce(C.Country, E.Job_country)
GROUP BY S.Order_status,
         Co.Country,
         Co.Currency,
         D.Department,
         J.Job_title,
         P.Product
ORDER BY S.Order_status,
         Total_sales_value DESC,
         Customer_count DESC

7. 복잡한 쿼리 실행 계획 설명하기

프롬프트: 이 다중 테이블 쿼리의 실행 계획을 설명해 줘.

InterBase가 반환한 쿼리 플랜은 아래와 같다:

PLAN SORT (SORT (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN
(S NATURAL,C INDEX (RDB$PRIMARY22)),
E INDEX (RDB$PRIMARY7)),
D INDEX (RDB$PRIMARY5)),
J INDEX (RDB$PRIMARY2)),
P INDEX (RDB$FOREIGN13)),
B INDEX (RDB$FOREIGN18,RDB$FOREIGN19)),
SH INDEX (RDB$FOREIGN21)),
CO INDEX (RDB$PRIMARY1))))

이 계획은 다음을 보여준다:

• SALES는 자연 스캔(natural scan, S NATURAL)으로 읽었다.
• 조회 테이블들은 기본 키 또는 외래 키 인덱스를 사용했다.
• 두 번의 정렬 작업이 필요했다. 그룹화, distinct 집계, 최종 정렬을 위해서였다.

이 쿼리에는 선택적인 WHERE 절이 없었고, SALES 테이블 전체를 집계했다. 그러니 자연 스캔(natural scan, S NATURAL)이 합리적이었다.

8. 메타데이터 변경/최적화 적용하기

여러분의 구성에서 허용된다면, 이 도구를 통해 메타데이터에 변경 사항을 직접 적용하는 것도 가능하다. 이번 실험에서는, 먼저 다음 SQL 문의 실행 계획을 보여달라고 AI에게 요청했다:

프롬프트: 다음 문의 쿼리 계획을 보여줘.

SELECT S.Po_number,  
       S.Order_date,  
       S.Order_status,  
       S.Total_value  
FROM Sales S  
WHERE S.Order_date >= Cast('2023-01-01' AS DATE)  
  AND S.Order_date < Cast('2024-01-01' AS DATE)  
ORDER BY S.Order_date,  
         S.Po_number;

InterBase가 반환한 쿼리 플랜은 아래와 같다:

PLAN SORT ((S NATURAL))

InterBase는 SALES 테이블 전체 스캔(NATURAL)을 수행한 다음, 일치하는 행을 정렬한다. 인덱스는 사용되지 않는다.

프롬프트: 이제, 그 쿼리 실행을 최적화하기 위해 만들 수 있는 인덱스를 제안해.

이 특정 쿼리에 가장 적합한 인덱스는 다음과 같다:

CREATE INDEX IDX_SALES_ORDER_DATE_PO ON SALES (ORDER_DATE, PO_NUMBER);

이 인덱스는 다음을 지원한다:

• ORDER_DATE에 대한 범위 필터
• ORDER BY ORDER_DATE, PO_NUMBER
• 전체 스캔과 명시적 정렬을 피하기 또는 줄이기

프롬프트: 좋다, 제안된 인덱스를 생성해.

생성하고 검증했다:

CREATE INDEX IDX_SALES_ORDER_DATE_PO ON SALES (ORDER_DATE, PO_NUMBER);

계획 비교:

Before: PLAN SORT ((S NATURAL))
After:  PLAN (S ORDER IDX_SALES_ORDER_DATE_PO)

이제 InterBase는 인덱스를 사용한다. 더 이상 자연 스캔이나 명시적 정렬이 필요하지 않다.