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

니클라우스 비르트 상 수상 연설: 파스칼과 델파이의 역사에 대한 개인적인 견해


Recommended Posts

마르코 칸투 (Marco Cantu) 블로그에 게시된 "Niklaus Wirth Prize Acceptance Speech: A Personal View of the History of Pascal and Delphi" 을 번역했습니다. (원문 작성: 2023년 7월, 최종 번역: 2024년 3월)

이 블로그 글은 살라망카에서 개최된 국제 파스칼 학회(International Pascal Congress)에서 내가 했던 연설의 내용이다. 하지만, 나의 지극히 개인적인 관점에서 파스칼의 역사에 대해 본 나의 소회다.

연설을 시작하기 전에 이 이벤트를 위해 만들기 위해 수고를 아끼지 않은 국제 파스칼 학회 조직 위원회, 특히 Sergio에게 감사를 전한다. 그리고 내가 매우 뜻깊은 상을 받을 수 있도록 심사해 준 심사 위원단에게 감사의 말을 전하고 싶다.

수상 소감에 쓴 바와 같이, "니클라우스 비르트 상을 수상하게 되어 매우 기쁘게 생각한다. 내가 니클라우스 비르트 박사를 매우 존경하기 때문이기도 하고, 또 한편으로, 30년 이상 파스칼 언어 및 파스칼 개발자 커뮤니티와 함께 해왔기 때문이기도 하다.

내가 해 온 일들을 인정해 준 협회에 감사드린다. 그 동안 나는 저자, 컨퍼런스 연사로 활동했으며, 최근에는 파스칼 기반 컴파일러이자 IDE로서 가장 널리 사용되는 델파이의 제품 매니저로서 활동하고 있다. 이 상은 내 개인적인 업적을 인정받는 상인 동시에, 오랜 기간 나와 함께 일하고 협력한 많은 사람들의 업적에 대한 인정이라고 생각한다. 파스칼과 델파이에 열정을 가진 많은 사람들에게 감사의 마음을 전한다."

이번 수상 연설의 제목은 "파스칼과 델파이의 역사에 대한 개인적인 견해"로 정했다. "개인적인 견해"란 내 삶이 어떻게 영향을 받았는지, 그리고 오브젝트 파스칼 커뮤니티가 전반적으로 현재의 모습을 갖추는 데 조금이나마 내가 어떻게 도움이 되었는지를 뜻한다. 

다시 말해, 파스칼 언어와 도구의 역사를 살펴보는 동시에 내 경험도 함께 고찰 해보았다. 마지막에는 현재의 델파이 언어와 그 생태계에 대한 몇 가지 생각을 덧붙이려 한다.

면책 조항: 이 글의 일부 역사적 사실은 내 개인적인 기억대로 기술한 것이다. 세월이 많이 흐른 만큼 내 기억이 정확하지 않을 수 있다. 일부 내용은 혹시라도 사실이 아닌 것을 말하지 않기 위해 일부러 너무 자세한 내용까지 들어가지 않았다. 마지막으로, 이 글의 모든 내용은 내가 근무하는 엠바카데로의 공식 입장이 아니라 내 개인적인 관점이라는 걸 알아 두길 바란다.

1970년, 니클라우스 비르트 박사가 파스칼 언어를 공식적으로 소개했을 때 나는 어린 아이였다. 그리고 컴퓨터를 접할 기회도 없었다. 그때는 개인용 컴퓨터가 존재하지 않았고, 전화기는 여전히 벽에 플러그에 꽂아 사용할 때였다. 

520px-ZXSpectrum48k.jpg

(이 파일은 Creative Commons Attribution-Share Alike 2.5 Generic 라이선스 하에 사용했다.)

나의 첫번째 파스칼 컴파일러는 ZX Spectrum에서 사용한 UCSD 파스칼이었다. 여러분 중 젊은 세대를 위해 설명하자면, ZX Spectrum는 64K 메모리를 갖춘 Z80 프로세서 기반 컴퓨터였다. (하지만 RAM은 48K만 사용 가능했고, 나머지 16K는 ROM에 맵핑 되어 있었다.)

300px-UCSD_p-System.svg.png

(이 파일은 Creative Commons Attribution-Share Alike 4.0 International 라이선스 하에 사용했다.)

UCSD 파스칼은 "pcode"를 기반으로한 인터프리터였다. 초기 파스칼 언어 도구는 주로 컴파일러가 아닌 인터프리터였다. Java JVM과 별반 다르지 않은 아키텍처를 기반으로 했다. 이것으로 작성할 수 있는 프로그램들은 임베디드 베이직(BASIC) 언어보다는 훨씬 빨랐다. 그러나 Z80 어셈블리 코드를 사용하는 것만큼 빠르지는 않았다.  

우리 세대의 대다수가 그렇게 시작했고 나도 마찬가지였다. 코드를 작성해 (또는 잡지에 있는 코드를 복사해서) 좋은 그래픽과 괜찮은(물론, 당시 기준으로 괜찮은) CPU를 갖춘 작은 컴퓨터에서 실행했다.

Algorithms_+_Data_Structures.jpg

내가 대학교에 다니기 시작할 때엔, 파스칼은 프로그래밍을 배우기 위한 기초 언어로 여겨지고 있었다. 더 이상 그렇지 않다는 점이 안타깝다. 왜냐하면 파스칼은 학습하기에 훌륭한 언어이기 때문이다 (이에 대해서는 나중에 더 자세히 다루겠다). 당시 내가 참고했던 서적은 비르트박사의 언어 매뉴얼인 "파스칼 사용자 매뉴얼과 보고서(The Pascal User Manual and Report)"은 아니라, 1976년에 나온 그의 성공적인 저서인 "알고리즘+데이터 구조 = 프로그램 (Algorithms + Data Structures = Programs, Prentice-Hall Series in Automatic Computation)"이었다(https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs). 위키피디아에는 "이 책은 당시 가장 영향력 있는 컴퓨터 과학 서적 중 하나였고, 비르트박사의 다른 저서와 마찬가지로 교육에 광범위하게 사용되었다."라고 설명 되어있다.

그 당시 컴퓨터와 파스칼 언어를 둘러싸고 또 다른 일이 벌어지고 있었다. 80년대 초중반의 이야기다. 바로 PC 혁명이 시작된 것이다. IBM이 최초의 PC를 출시했고, 연이어 PC의 복제품들이 나타나기 시작했다.

Olivetti_M24SP_with_manuals.jpg

(Federigo Federighi - 본인 저작물, CC BY-SA 4.0)

나는 운이 좋게도 Olivetti M24를 소유하고 있었다.  이 컴퓨터에는 플로피 드라이브(바로 그 "플로피" 드라이브)가 두 개가 있었다. 나중에서야 나는 하드 드라이브로 업그레이드했다. 내 기억으로는 20MB였을 것이다. 이 컴퓨터는 IBM보다 훨씬 빠른 CPU를 탑재한 흥미로운 컴퓨터였다. Olivetti는 당시의 훌륭한 이탈리아 회사로, 현대적인 조직으로 운영되며, 직원들에게 실리콘 밸리 스타일의 혜택을 제공했다. (하지만 이건 이 주제를 벗어난 이야기다.)

내가 M24를 언급하는 이유는, 이 제품을 사용해 터보 파스칼을 실행할 수 있었기 때문이다. 버전 3이었던 것 같은데, 아마 이 IDE에서 가장 성공적인 버전이었던 것 같다. 나는 터보 파스칼 이야기를 좀 더 하고자 한다. 파스칼 사용자뿐만 아니라 전체 개발자 커뮤니티가 터보 파스칼로부터 받은 영향이 매우 크다고 생각하기 때문이다. 대다수가 잘 알고 있는 이야기를 또 다시 반복해 말하게 되어 미안하지만, 여러분 중 젊은 세대들이 당시 상황을 더 잘 이해할 수 있기를 바라기에 양해를 부탁한다.

CPM-86.png

(디지털 리서치 제공 - http://www.hampa.ch/pce/screenshots/index.html, 퍼블릭 도메인)

초창기에는, 하드웨어 공급업체들이 자신들의 OS를 설계했으며 그것을 위한 개발자 도구도 제공했다. 애플도 그랬고, 그 후에 사라진 다른 업체들도 마찬가지였다. 공개 옵션은 오직 CP/M 운영 체제뿐이었다. 이것은 Gary Kildall의 회사인 Digital Research에서 제공했다. IBM은 다른 방식을 채택했다. IBM은 너무나 큰 회사였고, 각 부분들을 모두 제작하려면 시간이 많이 필요했을 것이다. 그래서 IBM은 소프트웨어들 즉 운영체제와 프로그래밍 도구둘 모두를 라이선스하기로 결정했다. 원래 마이크로소프트는 그 중 프로그래밍 도구만 제공하기로 되어 있었다. 그리고 OS는 디지털 리서치에서 제공하기로 되어있었다. 하지만, 결국에는 마이크로소프트가 MS DOS를 IBM에게 제공했다. 거의 무료로 말이다. 그 프로젝트를 전체를 잡기 위해서였다. 재미있는 이야기이다. 하지만, 오늘 주제에서 약간 벗어난다.이 이야기는 디지털 리서치(또는 Intergalactic Digital Research)가 역사적인 기회를 놓친 것에 대한 이야기이기 때문이다.

2560px-IBM_PC-IMG_7271_(transparent).png

(Rama & Muse'e Bolo - 파일: IBM_PC-IMG_7271.jpg, CC BY-SA 2.0 fr)

IBM PC 이야기로 다시 돌아와서, IBM의 PC가 출시 될 때, 거기에는 마이크로소프트가 제공하는 프로그래밍 언어들 함께 들어있었다: BASIC C, 파스칼이 들어있었다. 정말일까? 그렇다. 파스칼이다.

같은 시기에, 취리히 폴리테크닉에서 수학을 전공한(음악도 전공) 어떤 프랑스 기업가가 있었다. 그는 덴마크의 어떤 사람이 CP/M 컴퓨터용 매우 빠른 파스칼 컴파일러를 만들었다는 사실을 알게 되었다. "컴파스 파스칼, Compas Pascal"이라는 컴파일러였다(버전마다 이름이 달라졌었음). PolyData라는 회사의 제품이었다. 그 제품은 주로 그 지역에 있는 사람들에게 유통되고 있었다. 언젠가, 수정된 버전의 카피를 구하러 Anders의 집까지 자전거를 타고 다녀온 개발자와 이야기를 나눈 적이 있다.

turboad.png

그 미국계 프랑스인은 그 덴마크 개발자와 그의 회사에 라이선스 계약을 제안했다. 파스칼 컴파일러를 유통하겠다고 말이다. 그 미국계 프랑스인은 그 당시에는 돈이 없었다. 그래서 Byte(그 당시 가장 유명한 컴퓨터 잡지였음)와 협상하여 선불 없이 광고를 게재하는 조건으로 광고 계약을 맺었다. 그 광고를 통해 발생한 매출로 비용을 지불하려 한 것이다. 그 뿐만이 아니었다. 그 미국계 프랑스인은 컴파일러를 49.99 달러에 판매하기로 결정했다. 그 당시 다른 유사한 도구들의 가격은 모두 300달러가 훨씬 넘었다. 그 제품도 처음에는 마찬가지였다. 그 덴마크 개발자가 이 사실을 알게 되었고, 자신이 로열티를 받기로 한 것을 고려할 때, 그 가격 정책은 정말 바보같은 아이디어라고 생각했다. 

터보 파스칼이 Byte 잡지에 게재되자마자, 터보 파스칼은 바로 히트를 쳤다. 볼랜드의 창립자인 Philippe Kahn은 지불해야 할 광고 비용보다 훨씬 더 많은 돈을 벌었다. 그리고 Anders Hejisberg는 덴마크에서 캘리포니아의 스코츠 밸리로 이사했고, 제품 개발에 전념했다. Hejlsberg가 쓴 것처럼 "그 이후의 이야기는 모두가 아는 대로"다.

아마 여러분은 이제 마이크로소프트 파스칼에 무슨 일이 생겼는지 궁금할 것이다. 마이크로소프트 파스칼은 터보 파스칼의 성공으로 인해 그 존재가 가려졌다. 그리고 나중에 단종되었다. 마이크로소프트 파스칼은 고가의 컴파일러였다. 나중에 마이크로소프트는 터보 파스칼에 대항하기 위해 "퀵 파스칼"을 출시했지만 결국 그 버전도 성공하지 못했다. 언어 자체의 문제는 아니었다. 시장에 원인이 있었다.  당시 많은 개발자들이 파스칼을 사용했지만 마이크로소프트의 도구를 사용하지는 않다. 

tp7-1.jpg

그렇다면 터보 파스칼의 대단한 점은 무엇이었을까? 물론 그 언어 자체가 위대하기 때문이다. 우리 모두가 좋아하는 바로 그 언어말이다. 하지만, 터보 파스칼은 역사 상 최초의 통합 개발 환경(IDE) 중 하나라는 이유도 있었다. 그 당시에 개발자들은 편집기을 사용하여 코드를 입력하고, 파일로 저장했다. 그리고 나서, 커맨드 라인 컴파일러를 실행했다. 출력를 주의 깊게 확인하여 오류가 나는 줄들을 파악했으며, 다시 편집기를 열고 해당 줄으로 갔다. 그리고 다시 저장하고, 다시 컴파일해야 했다. 모두가 알다시피, 프로그램은 한번에 하나만 실행할 수 있었다. MS DOS에서는 말이다. 마침내 그 프로그램을 컴파일했다면, 개발자들은 디버거를 실행할 수 있었다. 디버거 역시 또 다른 별도의 도구였다. 도구 하나 안에서 코드 작성, 컴파일, 디버깅을 모두 할 수 있다는 점은 그저 좋은 아이디어 정도가 아니었다. 시간을 엄청나게 절약해주었다. 

여러분은 아마 "그래 재미있긴 하네 하지만, 왜 40년이나 된 소프트웨어인 터보 파스칼 이야기에 이렇게 많은 시간을 쓰고 있는거지?"라고 생각할 수도 있겠다. 바로 그것이 이유다. 터보 파스칼이 40주년을 맞이하는 것이 올해 말이기 때문이다, 1983년 처음 출시었으니 말이다!

터보 파스칼에는 독특한 다른 특징들이 있다. 그 빠른 성능은 여러가지 요인들에 기인한다. 그 코드에서 많은 부분은 어셈블리로 되어 있다. 뿐만 아니라 싱글 패스(single pass) 컴파일러라는 사실도 큰 도움이 되었다. 싱글 패스 컴파일러의 경우에는, 사용할 수 있는 구문에 제한이 있다. 하지만, 빠르다. 오늘날에도 몇몇 컴파일러들은 여전히 싱글 패스 컴파일러다. 델파이 11 알렉산드리아 역시 그 중 하나다. 참고로, 명령줄에서 DCC를 호출하면 버전 번호를 확인할 수 있다. 그 델파이 컴파일러의 버전은 35이다. 이는 터보 파스칼 시절까지 거슬러 올라간다. 

spacer.png

터보 파스칼은 "말도 안되는 책-같은 라이선스"로 판매되었다. 우편 주문을 통해 직접 판매되었다. 볼랜드는 터보 파스칼 카피 약 25만 장을 첫 2년동안 판매했다. 1980년대 초반의 개발자용 도구 판매로는 어마어마한 수치이다. 볼랜드는 DOS용으로 첫 "TSR(terminate-and-stay-resident program)" 프로그램인 Sidekick과 다른 개발 도구들을 만들었다. 하지만, 여기서는 다룰 내용은 아니다.

니클라우스 비르트 이야기로 돌아가겠다. 그도 가만히 있지는 않았다. 파스칼 언어가 대학에서뿐만 아니라 기업에서도 성공을 거둔 후, 그는 그 뒤를 이러 모듈라(Modula)-2를 설계했다. 모듈라-2에 담긴 많은 아이디어들은 초기 터보 파스칼 버전에 반영되었다. 유닛이라는 개념이 바로 여기에서 시작되었다.

언어 측면에서 보면, 모듈라-2+와 모듈라-3도 있었다. 이 마지막 버전은 핵심 언어에 오브젝트 지향 기능을 추가한 것이다. 이는 Olivetti를 포함한 산업 연구소들에서 설계했다. 시기하게도, 나는 대학을 졸업하면서 Olivetti에서 근무하게 되었고, Modula-3 연구를 접했다. 그 연구 이야기는 너무 앞서 나가는 주제인 것 같다.

Turbo_pascal_30_cover.jpg

(공정 사용)

다시 내 얘기로 돌아가서, 나는 Olivetti M24에서 터보 파스칼 3를 사용했다. 후속 컴퓨터들과 후속 버전들이 출시되는 동안에도 나는 여전히 파스칼 언어를 계속 사용했다. 대학 시절, 파스칼은 나의 첫 프로그래밍 언어였다. 내 기억이 맞다면, 내 첫 프로젝트는 여러 지점 간의 최단 경로를 계산하는 그래프 분석 애플리케이션을 구축하는 것이었다. 그런데 그 대학에서 결국 나는 다른 프로그래밍 언어에 관심을 갖게 되었다. 운영체제 수업에서 나는 C 언어를 배웠다. 그리고 고급 컴퓨터 과학 수업에서는 프로그래밍의 새 트렌드들을 접하게 되었다. 당시는 오브젝트 지향 프로그래밍(OOP)가 걸음마를 시작하던 시기였으며, 스몰토크(Smalltalk) 역시 마찬가지 였다. 함수형 프로그래밍이 대세였고 LISP가 유명했었다. 논리 프로그래밍은 프롤로그(Prolog)가 이끌고 있었다 (볼랜드 터보 프롤로그도 있었다. 하지만 크게 성공하지는 않았다)

Smalltalk80book.jpg

(아마존 닷컴 도서 목록, 공정 사용)

물론, 스몰토크(Smalltalk)는 내 경력에서 가장 중요한 역할을 했다. 나는 Ada도 조금 공부했는데 왜 배웠는지는 잘 기억나지 않는다(Ada는 파스칼 문법에 뿌리를 두고, begin/end 같은 것들을 사용하는 언어이다). 또 상당히 낯선 언어인 에펠(Eiffel)도 배웠다. 이 언어는 소프트웨어 계약의 시초가 되었다. 클래스 불변식, 전제 조건, 후제 조건을 언어의 명시적 기능으로 만들었었다 (상당히 특이한 경우다). 에펠은 Ada에서 파생되었다. 그렇다. 80년대 후반과 90년대 초반에는 프로그래밍 언어들의 세계가 서로 상당히 달랐다.

spacer.png

(작성자 제공 사진, 공정 사용)

어쨌든, 이 모든 새로운 방향의 영향을 받아서 파스칼의 세계는 오브젝트에 관심을 갖기 시작했다. "오브젝트 파스칼"이라는 이름은 애플이 자신들이 사용하는 언어를 부르던 이름이다. 볼랜드에서 나온 제품은 "터보 파스칼 위드 오브젝트(urbo Pascal with Objects)"이었다. 이 제품은 큰 성공을 거두지 못했으며, 터보 파스칼은 계속 쇠퇴해갔다. 여러분이 아마 알고 있겠지만, 당시 코드들은 여전히 남아 있다. 여러분은 오브젝트 타입 선언을 델파이에서 할 수 있다. 델파이 모바일 컴파일러에는 그 타입이 없다보니, 버그 리포트와 불만이 우리에게 접수되고 있기도 하다.

재미있는 비화다. 스몰토크는 좋은 언어다. 하지만 사용하기에는 다소 실용적이지 않았다. 소스코드라는 개념이 없기 때문이었다. 개발자들은 그저 런타임에 메시지나 메서드를 추가하는데, 그것들 역시 오브젝트이다. 그 당시의 컴퓨터에게는 너무 무거웠다. 한 작은 회사가 윈도우 버전을 만들었는데, 아키텍처가 크게 최적화되어 있었다. 그리고 오브젝트를 통해 윈도우 API를 관리하기 위한 클래스 라이브러리를 개발했다. 이 언어의 이름은 액터(Actor)였고, 제조 회사는 "Whitewater Group"이었다. 이 클래스 라이브러리는 나중에 볼랜드에 인수되어 C++용 오브젝트 윈도우 라이브러리가 되었다. 또 내가 너무 앞서 가는 것 같다.

spacer.png

(공정 사용, 원본 표지)

내가 대학교를 졸업할 때쯤부터 커리어를 시작할 때쯤까지 집중하게 된 것은 사실 새롭게 도입된 C++ 언어였다. 처음에는 컴파일러를 찾기가 어려웠다. 학위 논문에서는 C++에서 C로 변환하는 변환기를 사용했다. 나중에 C 컴파일러를 사용하여 최종 코드를 작성했다. 당연히 디버깅을 할 수는 없었다. 볼랜드 터보 C++가 곧 출시되었고, 이어서 마이크로소프트 비주얼 C++가 나오면서 모든 것이 바뀌었다. 

내가 C++에 집중하고 있을 때였지만, 나의 첫 직장에서의 업무는 터보 파스칼 책을 영어에서 이탈리아어로 번역하는 일이었다. 그로 인해 나는 파스칼 언어와 라이브러리뿐만 아니라 책을 쓰는 과정에대해서도 많이 배웠다.

얼마 지나지 않아 나는 C언어로 윈도우 프래그래밍 하는 법을 배웠다. 이 때 윈도우 API 개발에 대한 정식 가이드의 가장 유명한 저자 Charles Petzold의 이름에서 따온 "Petzold 스타일"로 배웠다. C++와 클래스 라이브러리 사용법을 아는 것은 엄청난 보너스였다. 볼랜드는 방금 언급한 오브젝트 윈도우 라이브러리(OWL)라는 정교하고 방대한 클래스 라이브러리에 모든 노력을 총동원했다. 마이크로소프트는 매우 얇은 레이어를 사용하기로 결정했다. 그래서 오브젝트 구조를 활용하거나 많은 것을 추가하지 않고 API를 캡슐화했다. 기술적으로 봤을 때 이는 더 제한적이고 기능면에서 명백히 열등했다. 누가 이겼을까? 비주얼 C++와 MFC가 살아남았다. 여전히 얇은 레이어로. 여전히 비주얼은 아니다.

beta_cds_t.jpg

(작가 제공 사진)

앞서 말했듯이 나는 몇 년 동안 주로 볼랜드 C++와 OWL에 집중했지만, 비주얼 C++와 MFC에도 관심을 기울였다. 내가 볼랜드 이벤트에 참석하고 세션을 진행하기 시작한 시기가 있었다. 그 때 나는 볼랜드 C++와 OWL에 대해 3권의 책을 썼다. 나는 교육 및 컨설팅 일도 했는데, 주로 MFC를 위한 일이었다. 그러다 1984년 샌호세에서 터보 C++ 제품 관리자와 회의를 했던 날이 있었다. 라이브러리를 개선하고 사용하기 쉽게 만들기 위해 논의했다. 나는 GUI를 보다 쉽게 만들 수 있도록 시각적 레이어를 추가하는 것을 제안했다. 제품 관리자는 그의 동료인 Zack Urlocker에게 나를 소개했다. 그리고 나는 델파이의 첫 데모를 보게 되었다. 그 당시에는 아직 델파이라는 이름이 정해지지는 않았다. 

여러 이름들이 후보에 올랐다. 핫 하다는 뜻에서 와사비라는 이름 부터 VBKiller라는 뜻의 VBK라는 이름 등 다양했다. 이름 후보 중 하나인 델파이는 지금은 고인이 된 Danny Thorpe가 제안한 것이다. 오라클과 강력한 데이터베이스의 연결성 때문에 오라클과 대화하는 곳이라는 뜻의 이름이었다. 회사는 앱빌더로 결정하려고 했다. 그 이름은 여전히 제품에서 기본 IDE창 이름으로 사용되고 있다. 하지만 앱빌더라는 이름은 이미 사용되고 있었기에 결국 델파이가 선택되었다. 돌이켜보면 델파이가 훨씬 좋은 이름이었다.

신제품은 모든 면에서 입이 떡 벌어질 정도로 놀라웠다. 델파이는 OOP 및 컴포넌트, 시각적 간소함, 우수한 OOP 아키텍처 덕분에 그 이름이 찰떡 궁합이었다. (그 당시 기준이지만 지금의 기준으로도 여전히 훌륭하다.) OWL에 비해, 윈도우 API와 플랫폼 메시징 시스템의 깔끔한 맵핑 및 캡슐화 측면에서 상당히 발전했다. 단순히 VB에 대한 해답이 아니었다. 커다란 혁명처럼 보였다.  1995년 2월에 제품이 출시되기 전, 나는 그 회사를 그만뒀다. 그리고 델파이에 집중하기 위해 교육 및 컨설팅 회사를 창업했다. 또 델파이에 대해 책을 쓰기위한 계약도 맺었다.

spacer.png

(사진 출처 https://github.com/ahejlsberg)

델파이는 우리를 다시 Hejlsberg에게로 이끌었다. Hejlsberg는 오브젝트 모델과 언어 확장을 설계하여 델파이 성공에 중요한 역할을 했다. 이는 델파이와 델파이 생태계의 성공의 기반이 되었다.  그는 언어 천재였다. 대부분의 언어 전문가들은 일생 동안 하나의 훌륭한 프로그래밍 언어를 설계한다. 어떤 사람들은 일반적으로 같은 분야에서 두 개를 설계해서, 그에 대한 공로를 인정받기도 한다. 하지만 Hejlsberg처럼 델파이, C#, 타임스크립와 같이 서로 다른 분야에서 세 가지 서로 구분되는 언어를 개발 한 사람은 극히 드물다. 그 뿐만 아니라 그는 훌륭하고 겸손한 사람이며 매우 친근하고 사람을 편하게 해주는 사람이었다.

sd_delphilaunch.jpg

(작가 제공 사진)

어쨌든, 다시 1995년 2월 14일로 돌아가 보자. 샌프란시스코의 Moscone 센터에서 SD West(Software Development West) 컨퍼런스의 일환으로, 델파이가 공식적으로 출시된 날이다. 여담이지만, 몇 년간 우리 업계에서는 SD West 컨퍼런스를 잊고 있었다. 요즘에는 자바 원, MS 빌드, 애플의 WWWDC, 구글 이벤트, 페이스북의 개발자 컨퍼런스 등이 있다. 각 회사마다 자체적으로 이벤트가 있다. 그 시절에는 회사 컨퍼런스(예전의 대규모 볼랜드 컨퍼런스 같은)도 있었지만 개발자를 위한 업계 전반의 이벤트도 있었다. C++로 유명한 Stroustrup이나 파이썬으로 유명한 Guido van Rossum과 함께 마이크로소프트 개발자, 볼랜드 개발자, 오픈소스 커뮤니티와 유료 도구에 대한 컨퍼런스가 있을 수도 있다. 나는 일부 행사에 참석하고 연설할 수 있는 행운을 얻었다. 패널과 토론은 즐거웠다. 도구 공급업체들 사이에 진정한 경쟁이 벌어졌다. 각각의 도구가 동일한 프로그램을 작성하는 세션이 있었는데, 거기서 관객들이 환호성을 질렀다.

spacer.png
(동영상 보기 https://youtu.be/0q1BkHcZ5kE) 

얘기 중 딴 길로 새서 미안하다. 다시 델파이로 돌아가서, 런칭 이벤트는 인상적이었다. 데모를 본 사람들은 놀라서 할 말을 잃었다. 윈도우 UI를 쉽게 구축할 수 있었고, 예외 처리를 올바르게 수행하고, 백그라운드에서는 오브젝트 지향 프로그래밍이 이루어졌던 것이다. 데모 프로그램에서 액세스 위반이 발생했다. 그러나 갑작스럽게 충돌하지 않고 잘 처리하였다. 운이 좋게도 나는 그 이벤트에 참석했다. 내 기억에는 런칭 애프터 파티는 샌프란시스코에 있는 익스플로러토리움 이전 전 장소에서 열렸다. 그 곳은 Robert Oppenheimer의 동생이자 입자 물리학자인 Frank Oppenheimer가 설립한 실험 중심의 과학 박물관이었다.

델파이는 출시하자마자 업계에서 즉시 히트 했다. 몇 년 전의 터보 파스칼처럼. 비즈니스 세계는 DOS에서 윈도우(윈도우의 첫번째 실제 버전인 윈도우 95가 곧 출시되었다)로 넘어가고 있었다. DB 지향 도구(Clipper, 볼랜드 dBase, Paradox)를 사용하는 DOS 인터페이스에서 윈도우로 전환하는 것은 복잡했다. 델파이와 델파이의 강력한 데이터 지향성, 즉 DB 컴포넌트, BDE, DBGrid를 통한 데이터 인식 UI컨트롤, 디자인 시점의 라이브 데이터(모던 툴이 종종 제공하지 못하는 기능으로, UI가 데이터로 채워진 것을 확인하려면 복잡한 빌드/배포/디버그 주기가 필요했다) 이것이 부분적인 이유였다. 

또 다른 이유는 델파이로 컴파일된 코드가 빠르다는 것이었다. 데이터베이스 4GL언어보다 훨씬 빨랐다. 주요 경쟁 상대인 비주얼 베이직보다도 훨씬 빨랐다. 곧 출시될 자바 VM보다도 훨씬 빨랐다. 델파이의 속도는 빨랐다. 비용 문제 또는 정치적 이유로 하드웨어에 대한 접근이 제한된 국가에서 더욱 높이 평가되었다. 지금까지도, 델파이는 초기에 그 성능이 중요한 국가에서도 국제적으로 큰 성공을 거두고 있다. 

내가 앞서 자바를 언급한 이유가 있다. 자바도 1995년에 출시되었다. 1995년은 프로그래밍 언어의 해로 볼 수 있다. 자바, 자바스크립트, 루비, PHP 그리고 델파이. 이 모두가 거의 30년 전에 비슷한 시기에 시작되었다. 그때 파이썬도 있었지만 거의 사용되지 않았다.

  • 자바스크립트는 1995년 12월 4일 첫 등장을 했다.
  • 자바의 첫 등장은: 1995년 5월 23일
  • 파이썬은 1994년 1월에 1.0버전을 출시했다. (첫번째 출시는 1991년이었다)
  • PHP는 1995년 6월 8일에 도입되었다.
  • 루비는 1995년에 처음 등장했다.
  • 지금 이야기 중인 델파이는 1995년 2월 출시했다. 

그런데 이제 프로그래밍 언어를 둘러싼 논쟁을 보면, 자바와 파이썬은 새로운 언어, 델파이와 파스칼은 오래된 언어라고 한다. 어떻게 된 걸까?

델파이가 충분히 발전하지 않았나? 난 동의하지 않는다. 델파이는 많이 발전했다. 내 책이나 다른 많은 온라인 자료에서 전체적인 내용을 확인할 수 있다. 자바스크립트는 최근 몇 년 동안 무엇이 새로워졌는가? 파이썬 2와 비교하여 파이썬 3의 혁신적인 것은 무엇인가? 새 출시 작의 문서를 읽어보았다. (https://docs.python.org/3/whatsnew/3.0.html) 작은 확장 기능, 데이터 유형과 RTL의 변경같이 멋지고 중요한 변경이 많지만 언어면에서의 혁명은 아니다. 

그렇다면 델파이의 무엇이 오래되었나? 파스칼 언어이기 때문일까? RAD 모델이기 때문인가? 신기하게 최근 애플과 구글은 프리뷰 창에서 UI를 미리 보는 것이 좋은 생각이라고 인정한 것 같다. 오브젝트 파스칼을 사용하면 원하는 어떤 아키텍처로든 코드를 작성할 수 있다. 가비지 컬렉터가 없는 것이 낡은 방식인가? 아마 그럴 수도 있다. 하지만 메모리 사용을 제어하는 것 자체는 나쁜 생각은 아니다.

spacer.png
(화면 캡쳐 https://delphi.embarcadero.com/)

다시 델파이로 돌아가보면, 제품은 몇 년에 걸쳐 계속 발전해 왔다. 여러 회사들이(볼랜드, 코드기어 사업부, 엠바카데로, 현재에는 아이데라) 일을 이끌어 왔고, 다양한 제품 관리자들이 있었고, 다수의 훌륭한 전문가들이 R&D팀의 일원으로 일했다. 마지막으로 회사 측면에 대한 이야기를 하고싶다. 나는 이렇게 몇 년 동안 내가 한 일에 대해 잊고, 제품과 제품 생태계로 돌아가고 싶다. 

제품은 많은 변화를 겪었다. 델파이 2에는 윈도우 95용 32비트 컴파일러가 있었다. 언어는 초기 몇 년 동안 많이 발전했다. 델파이 6 시기에, 볼랜드는 리눅스 데스크탑 애플리케이션을 빌드하기 위한 리눅스 호스팅 IDE인 카일릭스(Kylix)를 만들 었다. 나중에 볼랜드는 .NET을 수용하여(어느 정도는 너무 과하게) 오늘날까지 살아남은 새로운 IDE 아키텍처 "갈릴레오(Galileo)"를 만들었다.

이전에 언급했듯이 델파이 1이 출시될 때 나는 나의 교육 및 컨설팅 회사를 설립했다. 동시에 책을 쓰기 시작했고, 프로그래밍 잡지에 많은 글을 기고하기도 했다: 델파이 인포맨트(Delphi Informant)와 델파이 매거진(Delphi Magazine)을 비롯해 윈도우 테크 저널(Windows Tech Journal)과 몇 권의 이탈리아 컴퓨터 잡지에 글을 게재했다. 내 말은, 모두 우편으로 보내는 실제로 인쇄되는 잡지였다. 

spacer.png
(작가 제공 사진)

내 책부터 시작하겠다. 파스칼 언어와 관련된 나의 첫 번째 책은 "마스터링 델파이 1(Mastering Delphi 1)"이었다. 나는 IDE와 언어뿐만 아니라 라이브러리까지 모두 다루겠다는 생각으로 시작했다. 이 책을 쓰는 데는 많은 시간이 걸렸다. 당시에는 미국 출판사와 협업하는 것도 복잡했다. 나는 우편을 통해 인쇄된 초고를 받아서 수정할 곳을 마크한 다음에 다시 캘리포니아에 있는 출판사에 우편으로 보내야 했다. 어쨌든 이 책을 쓰는 데 너무 오랜 시간이 걸렸다. 그럼에도 불구하고 훌륭한 투자이자 할 가치가 있는 일이었다. 1,500 페이지에 달하는 놀라운 양이었다. 그렇다. 엄청난 분량의 책이었다. 얇은 종이를 사용해야 할 정도였다. 그 책은 성공적이었지만 히트작은 아니었다. 책을 쓰는 데 많은 시간이 걸렸기 때문에, 델파이에 관한 첫 번째 책이 아니었다. 하지만 긍정적인 평가를 받았다. 여러 나라의 언어로 번역되었으며, 독자들 사이에서 칭찬이 자자했다.  나는 후속 작 "마스터링 델파이 2, 3, 4"을 계속 썼고, 책 판매량은 계속 증가했다. 이유는 알 수 없지만, 그 책은 브라질에서 대히트였다. 브라질의 일부 판본은 영어 판과 거의 비슷하게 많이 팔렸다.

all_v1.jpg
(작가 제공 사진)

전반적으로 마스터링 델파이의 여러 판본은 20개 이상의 언어로 번역되었다. 전체 목록이 있는지는 잘 모르겠지만, 내 웹사이트에 있는 목록은 최신 상태가 아니다. 몇 년 동안은 책을 쓰면서 대부분의 시간을 보냈다. 나머지는 시간 동안에는 교육, 컨설팅, 학회에서 강연을 했다.

오브젝트 파스칼에 대한 책을 몇 권 집필했는가?

  • 마스터링 델파이1, 2, 3, 4, 5, 6, 7, 그리고 2005
  • 중간에는 더 고급 주제를 다루는 델파이 개발자 핸드북(Delphi Developers Handbook)과 카일릭스에 관한 책을 썼다.
  • 나중에는 내가 직접 책을 출판하기 시작했다.  나는 델파이 2007 핸드북, 델파이 2009 핸드북, 델파이 2010 핸드북, 델파이 XE 핸드북을 썼다. 
  • 이후 오브젝트 파스칼 핸드북(인쇄본 2개)의 네 가지 버전을 출간했다. 

이로써 오브젝트 파스칼과 델파이를 다룬 총 16권의 영문 앤쇄 서적을 출간했다. 나는 Cary Jensen과 함께 3권의 Delphi Developer Days에 기고했다. 내 계획은 여기서 멈추지 않는다. 현재 두 개의 리뷰 프로젝트를 진행중이다. 곧 출시될 델파이의 다음 버전을 위한 언어 핸드북의 새로운 판에 관련해 참여하고 있다. 또 지금은 고인이 된 Pawel Glowacki가 쓴 매우 특별한 책, Expert Delphi의 업데이트 작업에도 참여중이다. 시간이 걸리겠지만, Pawel의 유산이 사라지지 않도록 참여하게 된 프로젝트다.

spacer.png
(Paolo Rossi가 촬영한 사진으로 추정)

몇 년 동안 나는 교육, 트레이닝, 컨설팅도 했다. 이탈리아. 유럽, 전 세계에서 일을 했다. 너무 많아 정확한 숫자는 세어보지 않았지만, 호주에서 브라질, 캐나다에서 싱가포르, 뉴질랜드에서 일본, 중동까지 많은 나라에서 세션을 진행했다. 중동에서는 델파이로 인해 교통 체증까지 발생했다. 북쪽으로는 노르웨이 남쪽으로는 몰타까지, 서쪽으로는 포르투갈, 동쪽으로는 폴란드까지 대부분의 유럽 국가에서도 세션을 진행했다. 독일, 프랑스, 영국은 자주 방문했다. 덴마크, 스웨덴, 노르웨이도 그에 못지 않게 방문했다. 컨퍼런스와 기타 다른 이벤트들을 위해 미국을 수 없이 방문했던 것은 말할 필요도 없다.

교통 체증 이야기로 돌아가보겠다. 들어 볼만한 이야기다. 쿠웨이트에서 재무부를 위해 델파이 교육 세션을 진행했다. 쿠웨이트에는 세금이 없는 나라라서 조금 이상한 일이긴 했지만 재무부가 있었다. 이야기를 나누던 중 개발자들이 나에게 말했다. 많은 사람들이 한 델파이 애플리케이션에 불만이 있다는 것이다. 교통체증을 불러오고 있다는 이유에서 말이다. 내가 여러 소프트웨어 문제를 들어봤지만, 이런 일은 없었다. 많이 이상했다. 대다수의 수도들이 그렇듯 도시 인구의 상당수가 정부 기관에서 일하는 것을 알게 되었다. 그 대부분이 8시에 출근한다고 했던 것 같다. 그러나 직원들은 8시를 넘겨 출근하기도 했고 때로는 9시 전에야 겨우 출근하기도 했다고 한다. 그래서 출입할 때 스캔해야 하는 배지가 도입됐다.  델파이 애플리케이션으로 작동했다. 이제 모든 직원들이 아무 시간에나 출근하는 것이 아니라 정시에, 동시에 출근한다고 했다. 그로 인해 교통 체증이 발생한다는 것이다. 파스칼로 작성된 프로그램때문에 발생한 교통체증이다.

speech_ddd.png
(작성자 제공 사진)

나는 Cary Jensen과 그의 아내 Loy와 함께 3년 간 Delphi Developer Days라는 교육행사를 진행했다. 나는 그 활동은 매우 좋아했다. 그것은 특별한 경험이었다. 유용한 정보가 가득한 이틀이었다.  유럽과 미국에서 4~5차례 반복해서 개최되었다. 3년 동안 진행했다. 청중과 소통할 수 있는 훌륭한 행사였다. 우리는 친구 및 지역 커뮤니티 방문도 주최했다.

spacer.png(작성자 제공 이미지)

가장 좋았던 이벤트는 초기 볼랜드 컨퍼런스였다. 5,000여 명의 개발자들 앞에서 "델파이의 재미있는 측면" 이라는 세션을 진행한 순간이 최고였던 것 같다. 온라인에서 다시 보기 할 수 있는 세션이다. 한 번 보길 추천한다. 그러나 실제로 현장에서 보는 것이 진짜 재미있다. 목표는 가장 복잡하고 어려운 방법으로 쓸데없고 이상한 작업을 수행하는 것이었다. 이 세션은 TNothing이라는 컴포넌트로 시작되었다. 정말 아무것도 아니었기 때문이었다. 컴퓨터를 감염시키거나 화면을 거꾸로 뒤집는 "홍역"이라는 앱을 만든다 거나 아니면 델파이 메뉴를 훨씬 더 멋진 알파벳 순서로 바꾸는 것 같이 말이다. 직접 봐야 하는데, 꽤 편리할 수도 있다. 그럴 수도 있다. 또 다른 아이디어는 윈도우 리소스를 고갈시키고 시스템을 일부러 충돌시키는 것도 있었다. (실제로는 쉬운 일이다) 어떤 버전에서는 도전 과제가 '윈도우 2000에서 2000개의 창(Windows) 만들 수 있는가' 였다. 정답이 무엇인지 짐작할 수 있는가? 때는 밀레니엄 버그의 시대였다. 청중들 중 일부 젊은 세대에게는 재미있는 일이었을 수 있다. 하지만 밀레니엄 버그는 소프트웨어 개발자들에게는 재미있는 일이 아니었다. 개발자들은 1999년 12월 31일 다음날이 1900년 1월 1일이 아니라 2000년 1월 1일이라는 걸 프로그램이 이해하도록 많은 노력을 기울였기 때문이다! 알겠지만 대부분의 소프트웨어들은 두 자릿수 연도 시스템을 이용하고 있었다.

(그 이미지를 보려면: https://lighttouchdesigns.com/project/borland-2/)

볼랜드 컨퍼런스로 돌아가서, 그 이벤트들은 정말 훌륭했다. 수 천명의 사람들이 참석했다. 놀이공원에서 밤을 보내고, 밤 늦은 시간에는 게임 연구소에서 보내는 등 정말 재미있었다. 오늘날 델파이 세계에서 그런 분위기를 느낄 수 있는 곳은 브라질의 컨퍼런스 뿐이다! 하지만 독일과 이탈리아를 비롯해 일본, 호주 등 전 세계 여러 나라에서도 100명이 넘는 인원이 모이는 행사를 개최하는 활발한 커뮤니티가 있다. 

델파이는 분명히 전성기는 지났지만, 여전히 제품은 건재하며, R&D투자의 타당성을 보여주는 좋은 비즈니스를 창출하고 있다. 델파이 커뮤니티는 여전히 전 세계 곳곳에서 모든 종류의 소프트웨어를 개발하고 있다.

회사 프레젠테이션을 위해, 델파이와 파스칼이 활발히 사용되고 있는 산업의 목록을 만들어 보았다. 이것은 단순히 생각속에만 존재하는 사례가 아니다. 나는 각 산업별로 회사 이름도 기억하고 있다. 하지만 대부분 이름을 밝힐 수 없는 경우가 많다.

  • 석유 및 가스
  • 항공 우주
  • 대용량 데이터 처리
  • GIS 애플리케이션
  • 회계
  • 키오스크 애플리케이션
  • 통신 소프트웨어
  • 측량
  • 자동차
  • 항공기 운용관리
  • 원격 컴퓨터 액세스
  • 건축
  • 헬스케어
  • 비즈니스 분석
  • 시스템 관리
  • 음악 편집기
  • 비디오 게임
  • 데이터 베이스 프론트 엔드
  • 농업 관리
  • IoT 관리
  • 전자 인보이스
  • 기차 및 철도
  • 모든 유형의 모바일 앱
  • 판매 시점 정보 관리(POS)
  • 정부
  • 공학 프로젝트
  • 생산 시스템 모니터링
  • 애니메이션 영화
  • 텔레비전
  • 완전한 ERP 시스템
  • 실시간 금융
  • 은행 시스템
  • 세금 신고
  • 제조업
  • 물류 창고 자동화
  • 개발자 툴
  • 광고
  • 회로 기판 설계
  • 배송 및 물류
  • 트럭 추적

사용 사례 중 일부는 정말 환상적이다. 파스칼로 컴파일 된 코드는 나이아가라 폭포를 비추고, 자동화 화물 항구의 컨테이너 크레인을 움직이며, TV에서 스포츠 경기의 실시간 3D 선수 정보를 표시한다. 또 세금 신고서를 작성하고, 정부에 전자 송장을 전송하며, CPU를 설계하고, 모두가 알다시피 델파이 자체를 구축하는 데 사용되고 있다! 커뮤니티는 훌륭하고, 써드파티 벤더와 오픈 소스 커뮤니티 모두가 그 생태계를 위해 큰 역할을 하고 있다. 그 중 일부는 이번 이벤트에도 참여하고 있다.

오브젝트 파스칼로 구축된 가장 성공적인 애플리케이션은 무엇일까? 비즈니스와 산업 혁신적 측면에서 나는 스카이프(Skype)를 꼽고 싶다. 마이크로소프트는 스카이프에 수십억 달러를 투자했다. 정확히는 85억 달러다. 여러 해에 걸친 시도 끝에 다시 만들었다. 그러나 이제는 더이상 많이 사용되지 않고 비즈니스는 활력을 잃었다.

speech_sv.png
(작성자 제공 사진)

내 얘기로 다시 돌아가서, 10여 년 전 Micheal Swindell이 나에게 전화해 일자리를 제안했다. 정말 좋은 자리였다. 이전 몇 년 동안 나는 엠바카데로와 협력해 신입개발자 교육(일부 새로운 지사에서)과 실제 개발 쪽에서 일했다. 마지막에 마이크로소프트가 변경한 윈도우 API에 묶이는 바람에 출시하지 못한 몇 안 되는 컴포넌트 중 하나를 작성했다. 엄밀히 따지면 제품과 함께 제공된다. 하지만 실제로 활성화되지는 않았다. 그 당시 나는 엠바카데로의 도구(그리고 일부 써드 파티벤더) 리셀러이기도 했다. 그래서 비즈니스 측면과 회사 운영에 대한 몇 가지 아이디어를 가지고 있었다.

델파이 제품관리자가 되어 보겠냐는 제안을 받고 나는 잠시 고민했다. 큰 변화가 생길 것 같았다. 나는 대부분 독립적으로 일을 해왔다. 그리고 가정에도 복잡한 일이 있던 시기였다. 하지만 내가 이 일을 하고싶다는 것을 곧 깨달았다. 그래서 나는 일을 함께 하기 위한 조건을 제시했다. 회사는 동의했다. 몇 주 안에 나는 스코츠 벨리에서 계약서에 사인을 했다. 나중에 나는 1년에 네 다섯번 캘리포니아로 출근했다. 요즘은 회사가 완전히 분산되어 있고 온라인으로 운영되고 있기 때문에 캘리포니아로 갈 일은 드물어졌다.

제품 관리자가 되는 것은 큰 변화를 가져왔다. 개발자를 위한 도구의 제품 관리자가 되기 위해서는 개발자가 되어야 했다. 하지만 소프트웨어를 작성하지는 않았다. 제품 관리자는 회사의 모든 부서에 관련되어 일을 해야 한다. 영업팀과 마케팅팀이 제품 판매량을 늘릴 수 있도록 도와야 한다. 동시에 그들의 의견을 평가하고, 궁극적으로는 고객의 의견도 수렴한다. 새로운 기능 계획을 수립하고, 무엇을 어떻게 할 수 있는지 알고 있는 아키텍트들과 논의한다. 또한 개발 계획에 따라 새로운 속성에서부터 알고리즘과 새로운 컴포넌트에 이르기까지 모든 것을 논의한다. 코드 리뷰를 돕고, 내부와 베타 빌드 테스트하고, 길고 자세한 베타 문서를 작성하고, 문서 팀이 그 문서를 제품의 공식 문서로 전환하는 것을 돕고, 프리젠테이션을 위한 런치 데크를 꾸몄다.

spacer.png
(David I의 구글 이미지 검색)

이 몇 년 동안 엠바카데로와 아이데라에서 나는 훌륭한 사람들과 또 개발자들과 함께 일할 수 있는 기회를 가졌습니다. David I라고도 부르는 David Intersimone에 대해 언급하려 한다. 그는 수 년 동안 델파이와 파스칼을 홍보하는 데 엄청난 역할을 해 왔다. 또한 R&D에서 함께 했던 훌륭한 개발자들과 여전히 함께 일하고 있는 많은 사람들, 이들과 함께 일할 수 있었던 것이 큰 기쁨으로 남아있다. 그리고 다른 PM, Dev Rel 직원, 전도사들뿐만 아니라 영업 및 기타 직군 역할의 사람들도 마찬가지다. 많은 사람들이 10년동안 나와 함께 일해왔다. 다정한 사내 커뮤니티가 있어, 많은 사람들과 친구로 지내며, 다른 곳으로 이직한 사람들과도 계속 연락하며 지내고 있다.

물론, 오브젝트 파스칼과 델파이 커뮤니티 및 그 생태계에서도 나는 즐겁다. 항상 감사하고 있다. 회사를 대표하는 얼굴 중 하나가 되어, 잘 알려진 사람이 되고 보니, 커뮤니티 일원이었던 과거와는 모든 게 달랐다. 나는 회사가 잘못한 일이나 하지 않은 일에 대한 비판의 대상이 되기도 했다. 당연한 일이다. 때로는 약간 좌절스러울 때도 있다. 하지만 대부분의 사람들은 나의 역할을 이해하고 지지해 주었다. 그리고 제품을 올바른 방향으로 유지하기 위해 하는 작은 노력들에 감사했다.

그렇다면 델파이는 어떨까? 다양한 오브젝트 파스칼 컴파일러들은 요즘 어떤 상태에 있을까? 델파이는 여전히 윈도우에서 강세를 보이고 있다. 나는 마이크로소프트의 많은 사람들과 연락하며 지낸다. 윈도우팀은 델파이가 진화하는 플랫폼을 지원하기 위해 하는 일의 진가를 알아주고 있다. 나는 이 분야에서 많은 일을 해왔다. WebView 2 제어 통합(Chromium Edge 브라우저 엔진)부터 MSIX 지원까지 내가 집중했던 몇 가지 분야를 이야기해보겠다.

spacer.png
(작성자 제공 이미지)

여전이 핵심 타겟은 윈도우다. 그러나 오브젝트 파스칼은 모바일분야에도 어느 정도 진출을 했다.   성공적인 모바일 앱이 몇 개 있다. 사실 나는 모바일 앱을 하나 만들었다. 그 앱은 구글 플레이 스토어에서 25만회 이상 다운로드를 기록했다. 그만두게 되어 안타깝게 생각한다. 정말 멋진 스토리다. 그 앱은 아들과 함께 재미로 작성했다. 그리고 아들 친구들이 설치할 수 있게 업로드했다.  요상한 작은 앱이었다. "대기 게임"이라고 하는 것인데: 약 30분 마다 어떤 것을 할 수 있는 게임이었다. 나는 그래서 그 게임을 아들을 위해 업로드했다. 곧 수천 건의 다운로드가 발생하면서 입소문을 타며 다운로드 수가 상승하기 시작했다. 우리는 앱에 광고를 추가했고, 약간의 돈도 벌었다. 레고와 관련된 앱이었다 그 회사에서는 그 앱을 좋아하지 않았다. 당연한 일이었다. 그래서 그만 둘 수밖에 없었다.

PM 업무 이야기로 다시 돌아와서, 나는 10년이 넘게 델파이 제품 관리자로 가장 오래 일하고 있다. 나는 팀과 함께 일하고 있고 다른 회사 제품도 일부 책임지고 있지만 말이다. 이 역할에서 어떤 성과를 이뤄냈을까? 골고루 성과를 내기란 쉽지 않다. 언어는 내 기대만큼 빠르게 발전하지는 않는다. 하지만 우리의 고객은 안정성과 성능을 매우 중요시한다. 때로는 사소한 기능 하나가 새로운 언어 패러다임을 도입하는 것 보다 더 큰 변화를 가져올 수도 있다. 또한 호환성은 제품이 갖추어야 할 특성이며, 핵심 원칙이다. 비록 어떤 때에는 새로운 개발 속도를 늦추는 방해요인이 되기도 하지만 말이다.

spacer.png(작성자 제공 이미지)

지난 10년간 우리는 이 언어에 좋은 기능들을 많이 추가했다. 이 내용에 대해 다루는 세션이 내일 있을 예정이므로 여기서는 많은 시간을 할애하지 않겠다. 내가 제일 좋아하는 기능은? 인라인 변수인 것 같다. 작은 구문 변경같이 보이지만 실제로 그 영향은 매우 크다. 블록 범위와 수명이 도입된 것이다. 타입 추론이 도입된 것이다. 작은 변화인 동시에 커다란 변화다.

제거된 기능도 있다. 실수를 인정하고 그것을 바로잡으려는 것은 일반적으로 어려운 결정이다.  기존의 결정을 뒤집는 것. 그 결정에 개입된 개인의 자존심을 건드리는 일이다. 회사 입장에서도 어렵기는 마찬가지다. 하지만 프로그래밍 언어와 그 생태계의 건강을 위한 결정이며, 길게 봤을 때 가장 좋은 선택인 경우가 많다.

고객이나 내부의 강한 압박에도 불구하고 무언가를 제거하거나, 무언가를 하지 않기로 결정하는 것이 새로운 기능을 추가하는 것만큼 중요할 때가 있다. 나는 윈도우 UWP와 윈도우 휴대폰을 지원을 위한 압박이 기억에 남는다. 우리는 지원하지 않기로 결정했고, 지금은 그럴 의미가 없어졌다. 하지만 가끔은, 추가해야 할 기능들을 추가하지 않고 기다리면 안 될 때도 있다. 결정은 늘 어렵다. 델파이는 좋은 웹 개발 사례를 얻지 못했으며, 이것은 큰 타격이 되었다.

spacer.png
(작성자 제공 이미지)

나는 10년 동안 엠바카데로에 있으면서 계속 책을 쓸 수 있었고, 오브젝트 파스칼 핸드북은 새로운 에디션을 출간했다. 파스칼 개발자들을 만나러 다니는 여행도 계속 할 수 있었고, 코드도 계속 작성했다. 나의 업무의 일부를 자동화하기도 했다. 새로운 기능들의 아키텍처를 디자인하고 정의하는데 도움을 주었으며, 데모와 내부 문서를 작성하기도 했다.

다시, 오브젝트 파스칼은 현재 어떤 상태일까? AI와 몰입형 현실, 메타버스, 암호화폐의 급변하는 세계에서도 그 가치가 있을까? 이 질문에 상세하게 답변하는 것이 쉽지는 않지만, 짧게 대답해 본다면, "예"라고 답을 할 것이다.

나는 중괄호 언어를 포기하면 안 된다고 생각한다. 중괄호 언어는 C 언어에서 파생된 수많은 언어들을 일컫는 것이다. 이들은 가독성보다는 간결한 표기법을 우선시한다. 왜 앰퍼샌드를 두개(&&) 사용하는 것이 and를 타이핑하는 것보다 좋을까? 한 글자 밖에 차이가 나지 않지만, 키보드에서 더 찾기 쉽고 읽기도 훨씬 편하다. 

더 나은 가독성을 요구하고 권장하는 것은 파스칼 커뮤니티만이 아니다. 파이썬도 여기에서는 또 다른 주요 선수다. 파스칼 개발자가 파이썬을 좋아하는 것은 놀라운 일도 아니다. 엠바카데로는 파이썬 개발자들이 파스칼과 델파이를 사용하기를 희망하고, 그렇게 되도록 노력하고 있다.

spacer.png
(이미지 제공 엠바카데로 테크놀로지스)

파이썬과 오브젝트 파스칼은 공통점이 많다. 둘 다 프로그래밍을 배우기 위해 좋은 언어로 시작했고, 업계에서도 한 자리를 차지하게 되었다. 대부분의 대학교들은 훌륭한 언어를 가르치기보다는 취업에 도움이 되는 언어를 가르치고 있다. 나는 이것이 좋은 아이디어가 아니라고 생각한다. 프로그래밍을 시작하고 나서도 사용하는 언어를 다른 언어로 바꿀 수도 있다. 하지만 하나의 언어에 대해서만 알고 있다면, 그 언어에 갇힐 수도 있다. 구체적인 예를 들어보겠다: 나의 첫 프로그래밍 수업은 파스칼에 기반을 두고 있었다. 오브젝트 파스칼은 그 당시 존재하지 않았기 때문에 그냥 파스칼이다. 작년에 내 아들이 대학교에서 처음으로 프로그래밍 수업을 들었다. 구문의 핵심 요소를 배우기 위해 C, 오브젝트와 메모리에서의 그 관리법을 배우기 위해 C++, 오브젝트와 클래스가 작동하는 방법에 대해 더 간단하면서 높은 수준의 자바를 혼합한 수업이었다. 그 어떤 모던 오브젝트 파스칼 컴파일러를 가져와 봐도: 3가지 목적을 모두 달성할 수 있었을 것이다. 복잡한 C++ 없이도 프로그래밍의 기초와 OOP를 제대로 수행하는 방법을 배우는 목적을 말이다.  제네릭, 예외 처리 및 다른 모던 프로그래밍의 핵심 원칙을 포함한다. 

대학에서의 이런 트렌드를 되돌릴 수 있을까? 쉽지 않을 것이다. 하지만 파이썬으로 시작하는 개발자가 더 많아진다면, 오브젝트 파스칼이 좋은 대안이 될 수 있다.

다시 묻는다. 오브젝트 파스칼 언어와 그 생태계의 강점은 무엇일까? 나는 수도 없이 말할 수 있다. 피해 갈 수 있는 문제를 복잡한 방법으로 해결하고, 나중에 처음 그 문제를 해결했던 복잡한 방법으로 인해 생긴 문제를 처리하기 위한 또다른 해결책을 만들어야 하는 요즘의 히스테리컬한 상황에도 나는 의문을 가진다. 

배포를 예로 이야기해 보겠다. 내 설명을 좀 더 쉽게 이해시키기 위해 조금 극단적으로 이야기하겠다. 현실은 약간 더 복잡하다. 우리 고객 중에는 최대 2천만 줄의 코드로 만들어진 대형 애플리케이션을 하나의 실행 파일로 구축한 경우가 있다. 단 하나의 파일로 말이다. 평균적인 모던 애플리케이션은 배포할 파일이 수천 개나 된다. 그리고 올바른 파일을 적절한 버전으로 배포하려면 꽤 복잡한 오케스트레이션 도구가 필요하다. 그리고 여러분의 코드에 따라 배포하기위한 적절한 파일은, 패키지 리포지토리에서 가져와야 한다. 개발자가 그 동안에 라이브러리를 삭제하지 않길 바라지만, 장담은 할 수 없다. 

오브젝트 파스칼의 장점으로 돌아가 보자. 빠른 컴파일, 네이티브 컴파일 코드(일반적으로 더 빠르고 더 안전함), 런타임과 배포 종속성이 매우 적거나 아예 없는 점이 장점이라는 건 우리 모두 알고 있다. 심지어 비주얼 C++ 마저도 배포하기 위해서는 런타임이 필요하다. 물론 올바른 버전이 필요하기 때문에, 어떤 윈도우 컴퓨터에서도 10개의 MSVC 런타임 DLL은 필요하다.

가비지(garbage) 컬렉션이 적어서, 애플리케이션이 빠르고 메모리 사용량이 적다는 것은 말했던가?  다른 면도 있다. 파스칼은 친환경적이다. 최근에 자주 언급되는 꽤 오래된 연구가 있는데, 파스칼과 C가 가장 친환경적인 언어에 속한다는 내용이다.

바로 이 점이 내가 연설을 마치기 전에 다루고 싶은 마지막 포인트다. 오늘날에는 심각한 양의 에너지가 데이터 센터와 클라우드 컴퓨터를 구동하는 데 사용된다. 엄청난 수치는 아니지만, 전 세계 전력의 3%가 클라우드 시스템에 사용된다는 추정치를 봤다. 그 수치는 계속 증가하고 있다. 1990년대 후반에는, 컴퓨터의 발전이 더딘 국가(예를 들어 브라질과 러시아와 같이, 여러 가지 이유로)에서는 컴파일된 파스칼을 베이직 인터프리터보다 선호했다. 지금도 마찬가지다. 메모리와 CPU 효율이 좋은 프로그램을 사용함으로써 에너지 소비를 줄일 수 있다. 단언하건대, C나 C++으로 서버 측 애플리케이션을 작성하고 싶어 하는 사람은 없을 것이다. 여러분은 아마 파이썬을 사용하고 싶을 수 있다. 하지만 오브젝트 파스칼을 사용하면, 훌륭하면서도 동시에 효율적인 언어를 사용하는 것이다.

휴대폰의 배터리 수명을 생각한다면, 자바를 덜 사용해야 한다는 것도 마찬가지로 중요한 사실이다. 오브젝트 파스칼 생태계가 유일한 답은 아니지만, 더 많이 인식되어야 한다는 점은 중요하다. 

비슷하게, 더 나은 코딩 스타일을 위해 준수하고, 견고하고, 가독성이 좋은 언어를 사용하여 프로그래밍 하는 방법을 배워야 한다는 인식이 널리 퍼지는 것도 매우 좋을 것이다. 내가 앞서 몇 번 언급했지만, 우리는 대학교에 다니고 있기 때문에, 이 주제는 우리에게 의미가 있다. 모든 것에 두루 적용되는 답은 없다. 중괄호 언어만 있는 것도 아니다. 경쟁의 장을 넓게 열어두고, 개발자들이 편견없이 각 작업에 적절한 툴을 선택할 수 있도록 해야 한다. 이미 이야기한 것처럼, 델파이 및 파스칼 애플리케이션이 아직 많은 비즈니스에 사용되고 있는 것에는 이유가 있다.

또한 훌륭하고 건강한 생태계도 있다. Spring4D, Skia4Delphi, 게임 엔진과 스레드 라이브러리, REST 서버, 마이크로서비스 아키텍처를 살펴보자. 처음으로 우리는 회사로서 이바지하고 있다. 우리는 델파이용 Bold를 오픈 소스로 출시했고, 최근에는 Octoid라는 헤더 생성도구를 출시했다. 앞으로 더 많은 기술이 공개될 예정이다. 관심 있는 사람들을 위해 일부 오래된 기술을 유지하는 것도 중요하다. 우리는 파이썬 생태계를 만들었다. 파이썬 개발자들에게는 VCL과 FMX의 서브셋을 무료로 사용할 수 있도록 했다. 델파이 개발자들에게는 파이썬 컴포넌트를 무료로 제공했다. 그리하여 오브젝트 파스칼에서 인기 있는 파이썬 라이브러리를 바로 사용할 수 있도록 했다. AI 라이브러리들도 포함된다. 그리고 이더리움 블록체인을 위한 암호화 라이브러리도 사용 가능하다.

많은 움직임과 변화가 일어나고 있다. 오브젝트 파스칼은 죽지 않았다. 개발자들은 가만히 멈춰 있지 않는다. 빠르게 움직이는 세상속에 우리도 함께하고 있다.

내가 최근에 쓴 책에 나오는 내용으로 마무리하겠다. 내가 쓴 책을 인용하는 게 멋지지 않다는 걸 알지만, 그래도 시도해볼 가치는 있다고 생각한다. 언어에 대한 내 세션 중 일부에 사용한 슬라이드인데, 계속 반복 사용하고 있다.

"강력함과 단순함, 표현력과 가독성, 학습과 전문 개발에 모두 탁월한 기능: 이것이 오늘날의 오브젝트 파스칼의 특징이다." 

"모바일 시대를 포용하는 컴파일러와 개발 도구를 갖춘 다재 다능한 도구” 미래를 위해 준비됨과 동시에 과거에 단단한 뿌리를 둔 언어

내가 전하고 싶었던 내용은 여기 까지다. 다시 한번 이 상을 받게 되어 영광이다. 파스칼과 델파이 그리고 내 인생에 대한 이 이야기가 여러분이 새로운 것을 배우는 데 도움이 되었기를 바란다.

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

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