엠바카데로는 RAD스튜디오, 델파이, C++빌더의 성장에 집중하고 있습니다. 특히 곧 종료되는 윈도우7 지원에 맞추어, 개발자분들이 더 쉽고 빠르게 윈도우10을 지원할 수 있도록 더 좋은 기술을 제공하기 위해 고민하고 있죠.
얼마전에는 아타나스 포포브(엠바카데로 총괄 책임자)와 마르코 칸투(엠바카데로 RAD스튜디오 제품 매니저)가
VCL을 주제로 많은 대화를 나누었다며, 그 중 핵심적인 내용들을 정리해 공개했습니다.
엠바카데로가 생각하는 VCL의 역할과 나아갈 방향은 무엇일까요?
아타나스: 안녕하세요, 마르코! 윈도우 10 지원과 현대화를 고민하는 많은 개발자분들이 늘 궁금해하는 게 있어요.
"VCL로 가는 게 좋을까? 아니면 파이어몽키(FMX)? 아니면 웹으로 가야할까?" 우리가 VCL에 대한 정말 많은 자료들을 제공하고는 있지만, 사실 너무 기술적인 내용이거나 높은 수준의 자료들이에요. 그렇다보니 왜 VCL이 가장 좋은
선택이 될 수 있는지 명확하게 전달되지 않는 부분도 있는 것 같아요.
이 주제로 대화를 나눌 수 있는 가장 적합한 전문가는 마르코 칸투라고 생각했어요. 그래서 VCL에 대해 질문을 좀
하고 싶은데요.
우선 첫번째 질문. VCL의 정의가 무엇인가요?
마르코: VCL은 이름 그대로 비주얼 컴포넌트 라이브러리(Visual Component Library)에요. 그러니까 인메모리(in-memory) 오브젝트와 시각화된 비주얼 오브젝트 모두를 표현할 수 있는 클래스 라이브러리인거죠. 디자인 화면에서 컴포넌트를 끌어다놓으면 구현된 화면에서 어떻게 보이는지 바로 확인할 수 있어요. 시각적으로 확인이 가능한 컴포넌트
기반 기술이에요. 이건 이 분야의 초기 개발 도구들 중 하나인 비주얼 베이직에서 차용해온 거라고 생각해요.
하지만 다른 개발 도구들과의 분명한 차이점은 완벽한 객체지향이라는 거죠. 그래서 디자인 화면의 작업들(예를 들면 버튼 생성)은 런타임으로 객체를 생성해요. 디자이너 자체도 런타임이고 자체적으로 라이브러리를 사용하죠. 정말
특별하면서 강력한 기능이에요. 최근 다른 IDE에서도 이 방식을 따라했지만, 특히 윈도우에서 이 기능을 완벽하게
구현한 경우는 거의 없어요.
이 점은 RAD 스튜디오의 핵심 원칙 중 하나에요. 그래서 개발자들은 아주 쉽고, 빠르게 UI를 만들고, 쿼리와 SQL 구문으로 데이터베이스 테이블과 같은 논리적 컴포넌트를 추가한 다음 그것을 데이터 그리드나 비주얼 컴포넌트와 연결해요. 이 작업은 아주 순조롭게 이뤄질거예요. 애플리케이션이 커지면, 당신은 대부분의 애플리케이션 로직을 옮겨 더
멋지고 견고한 아키텍처를 가질 수 있게되요.
아타나스: 자바스크립트에서 비슷한 개발방식을 볼수 있어요. 드래그 앤 드랍 기반으로요. 그러나 그 중 대부분은 디자인 타임, 즉 개발 과정과 실제 배포 결과가 일치하지 않아서 큰 어려움을 겪는 것 같아요. 윈도우 개발자 측면에서 VCL은 이러한 대안들과 어떻게 비교할 수 있나요?
마르코: VCL은 윈도우 API를 위에서 감싸는 방식이었어요, 그런데 그 감싸는 수준이 굉장히 높았죠. 그 층이 두껍다고 해야할까요. API 위에 많은 개념들을 추가했어요. 여전히 대부분의 VCL 컨트롤들이 윈도우 핸들을 포함하고 있기는 해요. 그래서 API와 매우 근접하게 맵핑되어 있어요. 맵핑 방식은 정말 견고하구요. 예를 들면, 델파이는 윈도우 메시지에 매핑할 수 있는 키워드 메시지를 가진 유일한 언어예요. 이에 비해, 마이크로소프트의 다른 언어들은 더 복잡하고 많은 코드를 사용해 매핑해야 해요. 이러한 언어의 특징이 우리에겐 정말 특별하죠.
이와 비슷한 라이브러리는 유일하게 C#과 닷넷(.Net)의 WinForms 뿐이에요. 그러나 WinForms는 라이브러리 범위가 훨씬 작고 컴포넌트 수도 적어요. 또한 닷넷 기반으로 컴포넌트를 사용할때마다 닷넷을 호출하고, 닷넷은 네이티브 호출 후 반환하게 되요. 델파이는 네이티브로 모든것이 컴파일되고, 모든것이 API를 직접 호출하기 떄문에 더 빠르고 부드럽게 수행되죠. VCL 계층에는 더 복잡한 작업(action)들이 포함되어 있어요. 이 액션 매니저 개남은 UI를 추상화하죠. WinForms에서 이러한 기능은 애드온 기능을 통해 제공하지만 기본 기능으로 제공되지 않아요. VCL은 윈도우 API뿐 아니라 COM, 그리고 현재는 WinRT와 완전한 통합을 계속하고 있어요. 불행히도 WinForms 개발은 꽤 오래 전에 중단되었어요. 왜냐하면 전부 플랫폼 계층이자, 네이티브인데 C++로 작성되었거든요. 하지만 델파이는 그 모든 것들을 직접 연결할 수 있어요.
또 다른 대안은 Visual C++이에요. 하지만, Visual C++은 API 위의 정말 얕은 계층으로 생산성의 이점은 거의 없고 시각적이지도 않죠. 폼에 컴포넌트를 올려놓으면 안 돼요. 대화상자에서는 그렇게 안내하지만 폼 디자이너에 보여지는 것은 일반적으로 이해하기 어려운 수준일거에요. 뭐 네, 그리고 델파이처럼 API를 네이티브로 호출하죠, 하지만 라이브러리는 제한적이고 델파이에 비해 더 많은 코드를 작성해야만 해요. 그리고 C++은 유지와 업그레이드가 어려운 코드베이스이죠.
아티나스: 굉장히 명확한 설명이에요. 그렇다면 웹이나 모바일에서 나온 새로운 도구들은 어떨까요? 예를 들어 일렉트론은 네이티브 애플리케이션을 구축할 수 있는 멋진 자바스크립트 래퍼를 제공해요. 윈도우 앱 구축과 관련해 이 접근 방식에 대해서는 어떻게 생각하나요?
마르코: 모바일과 데스크탑에서 사용할 수 있는 자바스크립트 같은 단일 언어를 필요로 한다는 걸 충분히 알고 있어요. 하지만 우리가 마주하고 있는 건 정말.. 정말 그냥 메모리 덩어리인 새로운 애플리케이션이에요. 정말 많은 양의 메모리를 사용하고, 속도도 꽤나 느리죠. 저도 채팅이나 소셜 윈도우 애플리케이션들을 사용하는데요, 정말 느려요. 소셜 네트워크에서 메시지를 탐색하는데, 1기가바이트의 메모리를 모두 사용하지는 않을거에요. 논리적이지 않잖아요. 부팅에만 몇분이나 걸려요. 아마 연결이 오래걸리는 게 아니라 렌더링과 프로세싱에 많은 시간이 걸리는 것일거에요. 이 중 많은 프로그램들이 일렉트론(Electron)으로 작성되었고, 렌더링을 위해 웹서버, 노드JS 엔진, 브라우저 등을 캡슐화 한 것이에요. 그리고 어떻게 봐도 윈도우처럼 보이지는 않아요. 윈도우 UI는 윈도우 UI에요. 사용자 환경은 지켜주어야 해요. 우리가 iOS 처럼 보이지 않는 iOS 앱을 사용하지는 않잖아요. 플랫폼과 전혀 다른, 플랫폼과 무관해 보이는 윈도우 애플리케이션을 작성해야 하는 이유는 무엇일까요? 저는 하나의 랭귀지로 작성하는 이점을 이해는 합니다. 하지만, 성능과 품질면에서 그만한 가치가 있는지는 잘 모르겠어요.
또한, 자바스크립트 코드의 역공학(reverse engineering)과 코드 분석은 델파이보다 다루기 힘들고 복잡합니다.
왜냐하면, 더 많은 써드파티 컴포넌트에 의존하기 때문에 컴포넌트를 계속 업데이트해야 하거든요. 여기에 종속성이 있는데요. 종속성은 브라우저나 웹 서버의 경우 잠재적인 보안상 구멍이 있을 수 밖에 없어요. 그래서 시스템의 모든 모듈들을 지속적으로 업데이트 해야만 해요. 의존성이 높아질수록 제어력은 저하될 수밖에 없어요. 이미 최근에
그런 사례를 봤잖아요. 애플 iOS는 사용자의 API에 대한 설명이 잘못되었다는 이유로 앱 등록을 거절하기도 하잖아요. 오픈소스의 무분별한 사용은 위험이 따르기 마련이에요. 물론 장점도 있어요. 자바스크립트는 많은 개발자들이
사용하는 일반적인 언어이거든요. 하지만 품질, 성능, 안정성등은 네이티브 애플리케이션을 작성하는 델파이, C++빌더나 다른 직접적인 언어에 비해서는 약한 부분들이 있어요.
아타나스: 개인적으로 마이크로소프트 윈도우 10은 정말 훌륭한 결과물이라고 생각해요. 플랫폼의 룩앤필(look and
feel)만 봐도 매우 현대적이고, 애플리케이션들은 강력하고 빨라요. 그래서 사람들이 iOS와 안드로이드용 네이티브
애플리케이션을 개발하는 것과 같은 이유로, 마이크로소프트 용 앱을 만들지 않을 이유가 없다고 봐요. 훨씬 더 많은 UX 옵션과 더 큰 화면이 있잖아요. OS를 최대한으로 활용해야 한다고 생각해요.
마르코: 또다른 중요한 점은, 10년전을 생각해볼까요. 많은 개발자들이 네이티브로 개발하는 것은 리스크가 크다고
생각했을 거에요. 마이크로소프트는 지속적으로 “결국, 윈도우에서 실행되는 것은 .NET일거야.”라고 말했죠. 그래서 많은 고객들이 “무슨일이지? 나중엔 우리 애플리케이션을 실행할 수 없게되는거야?”라고 생각했을거에요, 그런데
그런일은 일어나지 않았어요. 5년 전에도 “여러분들은 유니버셜 윈도우 플랫폼(UWP)으로 옮겨야 해요. 왜냐하면
UWP이 아니면 윈도우에서 실행되지 않을테니까요.”라고 해서 우리 모든 고객들이 걱정했었잖아요. 하지만, 그 후
데스크탑 브릿지가 나왔고, 센테니얼(Centennial)을 통해 유니버셜 윈도우 플랫폼(UWP)을 원활하게 지원할 수 있었어요. VCL 애플리케이션은 손쉽게 윈도우 스토어에 배포할수 있어요. 오늘날 마이크로소프트는 그 입장을 완전히 뒤집었어요. 최근 새로운 윈도우 플랫폼 컴포넌트들은 네이티브에요. 더이상 UWP는 존재하지 않아요. 엣지 크로미엄
웹브라우저에 임베딩된 엣지 컨트롤 역시 네이티브 컨트롤입니다. 새로운 WinUI 버전3에는 여러개의 네이티브 컨트롤이 포함되어 있어요. 마이크로소프트는 UWP으로 모든 사용자를 유도하던 노력을 포기하고, “오케이, 네이티브로 갑시다"라고 하고 있어요. 그리고 보호(Protection), 보안을 위해 MSIX를 사용할 예정입니다. MSIX는 컴파일된 네이티브 애플리케이션과 매우 우호적인 기술이에요. 이건 정말 반가운 소식이죠. 델파이와 C++ VCL 애플리케이션은
더 많은 API를 제공할 수 있고 구현, 캡슐화까지 가능합니다.
아타나스: 마이크로소프트가 서피스(Surface) 전략이나 다른 여러 움직임을 통해 윈도우 플래폼에 활력을 불어넣는데 성공했다고 생각해요. 그래서인지 마이크로소프트에게는 물론이고 우리에게도 정말 좋은 방향을 제시하고 있다고 자신감에 가득차 보여요. 마지막으로, 윈도우 애플리케이션 구축과 관련된 마지막 의견 -- 또는 고객을 위해 말해주고 싶은 조언이 있나요?
마르코: 중요하다고 할만한 것보다, 우선 첫째는 어제가 아닌 오늘의 하드웨어와 아키텍처를 고려해야 해요. 윈도우
XP UI 말고 실제로 윈도우 10 UI를 사용하는 애플리케이션을 구축하도록 시작하세요. 스타일을 활용하는 게 중요해요. 스타일 사용은 약간의 수고로 네이티브 스타일을 갖는 애플리케이션을 만들 수 있고, 어떤 코드의 재작업 없이도 오늘과 내일 그리고 미래의 네이티브 애플리케이션을 적용할 수 있는 유연성을 갖게 됩니다. 따라서 플래그를 변경하는 것만으로 애플리케이션을 윈도우 7이나 윈도우 10으로 보일수 있다는 것은, 재작업 없이도 많은 부가가치를 제공할 수 있어요.
마이크로소프트에게 이 질문을 한다면 아마 이렇게 대답할 거에요. “새로운 최신 UI를 적용하려면, 처음부터 UI를
다시 작성하세요.” 솔직히, UI 구축에 몇년씩 투자한 회사가 UI를 다시 작성한다는 건 어렵죠. 하지만 제 대답은 달라요. “아니야, UI 위에 스타일만 입혀봐. 그러면 진짜 멋있는 애플리케이션으로 만들 수 있어요.”라고 말이죠. 좀 작업해야 할 것들이 있긴 할 거에요. 그래서 개발 작업의 극히 일부분에 불과할 거라고 봐요. 엠바카데로는 스타일이 모든 시나리오 상에서 완벽하게 작동하도록 하는데 가장 초점을 맞추고 있어요. 아직 4K 모니터에 작은 문제가 있지만,
그건 수정해야 할 항목들 중 하나일뿐이에요. 예를 들어, 이제 애플리케이션에 여러개의 DPI를 갖는 이미지를 사용할 수 있도록 지원하기 때문에, 4K 모니터에서도 고품질의 이미지를 표현할 수 있어요. 이런 기능을 제공하는 다른 윈도우 UI 라이브러리는 거의 없죠. 대부분 다른 윈도우 UI 라이브러리에서는 개발자 스스로 High DPI 모니터를 지원하도록 개발해야해요. 여기에는 바로 사용할 수 있는 컴포넌트가 없어요. 그러니 지금부터 4K 모니터, 스타일, UI에 대한 생각을 시작하는 게 중요합니다. “그래! 결심했어! 나는 체크박스를 사용하면 안돼. 토글로 체크박스를 대체하는 현대적인 컴포넌트를 사용해야해. 왜냐하면 바로 이 방법이 현대적인 룩앤필과 현대적인 스타일이기 때문이야!” 이렇게
생각하는거죠. 좋은 소식은 이 모든 것이 VCL의 일부라는 것이에요. 따라서 UI를 다시 만들기 위해 새로운 컴포넌트에 대해 학습하고, 그것을 적용하는 것보다 훨씬 적은 노력만으로 충분해요.
아타나스: 아주 멋져요. 고마워요, 마르코. 우리는 VCL에 대한 모든 것을 전달하기 위해 더 많은 것들을 해야할 필요가 있어요. 이미 멋진 VCL 케이스 스터디가 아주 많아요. 고객들은 늘 바쁘고, 항상 우리가 제공하는 정보들을 공유하지 않기 때문에 우리가 더 많이 설명할수록, 우리 고객들은 이러한 기능을 통합한 새롭고 강력한 앱을 구축하는데 더 많은 자신감을 갖게될 거에요.
마르코: 물론이죠. 저는 델파이와 VCL이 윈도우에 전념하는 유일하고 진정한 비주얼 개발 선택지라고 말하고 싶어요. 그리고 이건 지난 오랜 기간동안 증명된 사실이기도해요. 24년 된 델파이 응용 프로그램을 재작업하면 적은 노력만으로도 최상급 윈도우 10 앱으로 만들 수 있어요. Visual Basic(그리고 아마 Visual FoxPro)과 같은 다른 선택지들은 이미 사라졌죠. VCL에 대한 투자는 계속되고 있고, 앞으로도 그럴 거에요.
