1990년대, 당시에 프로그래밍을 한다고 하면, 대부분은 GW-BASIC, QBASIC, QuickBasic이거나, 아니면 당시의 ‘볼랜드’社의 Turbo-C, Turbo-Pascal이 보통이지 않았을까 한다.

베이직 계열은 접근하기 쉬웠지만 프로그램 코드길이제한이나 컴파일방식이 흔치 않은 단점이 있었다. 물론 퀵베이직, 파워베이직 같은 제품들은 진짜 네이티브코드로 컴파일을 해주고, 또 인라인 어셈블리를 지원해서 얼마든지 원하는걸 짤 수 있었겠지만.

그럼에도 조금이라도 더 구조적프로그래밍을 하거나 시스템에 접근하고 싶다면 씨언어나 파스칼을 사용하는게 더 일반적이었을 것 같다.

대중화된 IBM-PC호환 + MS-DOS 시스템을 위해, 꽤 괜찮은 프로그래밍언어에 컴파일러+링커, 그리고 Stepping debugger에 문서화까지 되어 있는 IDE/편집기가 모두 하나로 묶여 있는 터보씨, 터보파스칼 제품은 정말 쩔었던거 같다.

솔직히 2026년 현재에 봐도, 소프트웨어 제품으로서 정말 완성도가 높았던거 같다. 단순하게 문법강조 같은 것들이 없다고 평가절하하기엔 디버거가 제공하는 기능이나 실행시간 디버거가 갖춰야 할 요소들, 실제 CPU의 레지스터들을 확인하거나, 현재 실행중인 instruction-pointer 부근의 디스어셈블리를 보여주거나 등등은 완성도가 높다. (현대적이라고 생각할 수 있는 프로그래밍언어들중에 Stepping debugger을 지원하지 못하는 경우도 많다.)

언어, 개발환경, 라이브러리 함수 등에 대한 깔끔하고 읽기 좋고, ‘링크(Hyperlink)’이 걸려 있어서 따라가며 읽기 좋은 내장문서는 물론이고 함께 제공되던 BGI, Turbo Vision 같은 라이브러리는 완성도도 높고 사용하기도 좋은, 거기에 당장 내 애플리케이션을 만들 때에 필요한 UI, Graphics을 만들기 쉽게 해줬었다. 도스환경에서 그래픽을 직접 구현하거나 하는 것이 얼마나 까다로운지 안다면, 이게 얼마나 유리한지 알 수 있을 것 같다. 재미있게도, Turbo Vision의 후손격인 라이브러리나, BGI에 영향을 받은 그래픽 라이브러리나, 아예 그 방식으로 GUI을 구성하는 Immediate GUI 같은 패러다임도 2026년에 너무나 많다: Raylib, ImGui, TVision… 그리고 아이러니하게도 저런 라이브러리들이 훨씬 효과적이고 사용하기에도 직관적이다.

당연히 이런 제품을 만들고 판매한 당시의 볼랜드는 독보적이었던 것 같다. 그래서였는지, 언제부터 그런 경향이 있었는지 모르겠지만, 마이크로소프트의 제품들도 어느새 비슷해지는 경향을 보였었다. DOS환경이라는 점을 감안해서, 제약이 많은 환경에서 프로그래밍언어/IDE이라는 동일한 영역의 제품이기 때문에 그렇게 되었을까.

윈도95이 공개되고, GUI환경이 다 망해가던 애플의 매킨토시나 중형차 가격에 가까운 비싼 자체 하드웨어와 OS을 탑재한 워크스테이션이 아닌, 일반PC에서도 보편화되었다.

윈도API을 직접 사용하는 GUI프로그래밍이 얼마나 별로인지를 역설할 생각은 없다. 어차피 당시의 기준으로 Xlib을 직접 사용한 GUI프로그래밍이나 MacOS Classic의 Carbon API도 끔찍하기는 마찬가지였을테니까. 다만 차이점은 그 저수준의 API들을 어떻게 추상화해주고 쓸만하게 만들어 주는 상위라이브러리였으리라 생각한다.

NeXTSTEP/OPENSTEP의 경우에는 현재에도 OSX, iOS의 GUI와 기본API으로서 훌륭하게 생존+발전한 좋은 예 같다. 하지만, OPENSTEP도 AppKit이나 Foundation Kit이 동작하기 위해서, POSIX계층이나 libc, 혹은 “Display Server”와 직접 IPC하며 화면을 그리고 하는 정말 저수준의 조작을 아주 잘 추상화한 것을 함께 제공하는 경우라고 생각하는게 맞을 것 같다. OPENSTEP API, 혹은 현대의 Cocoa을 쓰더라도 직접 Display PostScript을 이해하거나 짤 필요가 없고, Quartz을 꼭 직접 쓰지 않아도 되는 이유겠다. …결국 윈도API와 OPENSTEP/Cocoa AppKit이 꼭 동일한 계층을 제공하는 API이라고 말할 수는 없다.

AppKit와 비슷한 계층이라면, 유닉스계열이었다면 Xt, Motif, FL등이었을 것 같다. 그리고 동시대의 윈도 GUI은 마이크로소프트의 컴파일러를 사용한다면, MFC/WTL이었을 것 같고, 볼랜드였다면 VCL이 압도적이었었다.

MS의 MFC은 “Visual C++ 6.0”을 기억하는 사람이라면 한 번 정도는 어떤 것인지 경험해봤으리라 생각한다. 그리고 지금 돌아보면 생각보다 정말 현실적이고 실용적인 접근이었던 것 같다. 당시의 C++ 컴파일러가 잘 최적화하기 어렵던 템플릿프로그래밍이나 RTTI 같은 것에 의존할 필요 없이, 단순하고 잘 동작하는 preprocessor macros 등으로 적당히 잘 동작하는, 그것도 꾸준히 계속해서 쓸만한 수준의 GUI프레임웍을 제공하긴 했었었다. 하지만 진입장벽이 꽤 높았었다. 그리고 GUI을 만드는데에 직관성도 많이 떨어졌었고.

WTL은 앞서 언급한 템플릿 메타프로그래밍을 이용하여 Windows API을 포장하고 “쓸만하게” 만들려는 시도였었다. 가볍고 쓸만했지만, 당시엔 이건 더 이해하기에 난해했다. 지금에야 Rust등을 통해서 사람들이 제네릭타입, 메타프로그래밍에 더 익숙해졌지만 당시엔 더 ‘dark magic’이었으리라 싶다.

MS제품군에 대한 추측은, 당시 MS이 조성한 생태계의 구조와 관계가 있지 않을까 싶다. Visual C++으로는 “컴포넌트”를 만들고, 이런 컴포넌트는 COM/DCOM으로 노출되고, 그걸 조금 쓰기 수월한 Visual Basic에서 가져와 사용하는 방식으로 유도하고 싶었으리라 싶다. …물론 별로 직관적이지도 않았었고, 그래서 이후에 .NET을 시작하는 계기가 되었으리라 싶다.

반면, 볼랜드는 Delphi이라는 기존의 터보파스칼을 확장한 Object-Pascal 언어와 VCL-을 통해 컴포넌트 기반으로 GUI을 그리고 개발할 수 있는 직관적인 환경을 내놓았다. 그 이전에 OWL이라던가 하는 접근법이 있었지만, VCL으로 델파이와 볼랜드의 C++ 컴파일러/IDE였던 C++Builder은 완전히 차별화에 성공했다.

단순히 GUI Control만이 VCL 컴포넌트인 것이 아니라, 현대에 우리가 기대하는 DataSource 연결이나 DataGrid와 같은 데이터베이스에 접근하고 하는 non-Visual, 혹은 더 “Enterprise”-환경에 필수적인 컴포넌트들도 제공을 했었다. (…예를 들면, HTTP Client도 VCL 컴포넌트으로 집어놓고 호출해 쓸 수 있다거나)

실제로는, 특별한 프로그래밍언어의 지원이 없이, 그냥 함수포인터의 연결을 통한 이벤트 콜백함수의 등록 등과 같은 것과 IDE, GUI Builder의 연동이 훌륭했었었다.

그리고 지금도 VCL 컴포넌트 시장이 존재하고, Delphi은 다른 회사에서 계속해서 개발하고 판매를 하는 중이다. (…물론 그렇게 인기가 많진 않다)

Visual Basic 6와 함께 델파이는 지금도 과거의 유산으로 남아 있는 경우도 많지만, 여전히 데스크탑, 중소형 ERP/기업용 애플리케이션을 유지보수/개발하는데 유효한 환경일 것 같다. (물론 현대의 다른 언어와 비교하면 좀 구닥다리로 느껴지지만)

하지만, 비주얼베이직과 함께 델파이는, DB에 접근하고 하는 클라이언트-서버 방식이나 단순한 DB+클라이언트 방식의 업무용애플리케이션을 만드는데 지금도 충분히 편리할 것 같다.

델파이는 그때 당시에도 확고한 충성스런 팬들이 있었던 것 같다. 그런데 어째서 볼랜드는 사라지게 되었을까?¹

• https://www.reddit.com/r/programming/comments/39rdb4/why_did_borland_fail/
• https://www.quora.com/Why-did-Borland-fail/answer/Danny-Thorpe?share=1&

…정리해보면:

1. 볼랜드에 충성스런 고객들은 자발적으로 구매를 했던 개인들이거나, 그런 개인들이 성장한 기업들이었다. 그리고 그 이유는 완성도가 높은 컴파일러와 개발환경 제품임에도 낮은 가격과 개인의 접근이 수월한 낮은 사양의 PC환경에서도 잘 동작하는 제품들이었다. (터보씨, 터보파스칼)
2. 그리고 델파이/볼랜드의 강점은 VCL이었었는데,
3. 그 다음에 “Enterprise” 제품군을 위해 제품타겟팅을 바꾸면서 충성고객층의 이탈이 일어났고, 반면 유입을 기대한 기업고객은 그렇게 많지 못했다. (…더 많은 지불능력이 있는 기업일수록 MS제품을 더 선호할 수 밖에 없었을테니까)
4. 그리고 그런 ‘선회’의 과정에서 지금으로선 짐작만 가능한 변화와 거기에서 회의를 느낀, 당시의 성공적인 볼랜드를 만들어낸 유능한 개발자들이 떠나가게 된다: 특히 Anders Hejlsberg-옹 같은 분들.

이런 흥망성쇠 이야기는 의외로 IT기업들에서 흔하지 않을까 한다. 황금알을 낳는 거위의 배를 가르려고 들거나, 기만만 일삼아서 하멜른의 피리부는 사나이의 이야기의 배경이 되어 버리거나 하는 기업은 흔하다.

이런류의 몰락은, 각 단계가 점진적으로 이뤄지는 것 같다. 단번에 무너져 버리는 경우는 오히려 드라마틱해 보이기는 할 것 같지만 흔치 않다. 조금씩 하나씩 하나씩 더 안 좋은 방향으로 위에 인용한 글에서 사용한 표현과 같이 나선을 그리며 하강하게 된다. 그리고 각 하강의 단계에서 되돌리기는 매우 어렵다.

어려운 이유는 그게 하강의 단계인지 인지하지 못하거나, 아니면 아예 착각에 의해서 그런 의사결정을 경영진이 스스로 내리기 때문이다. 그런 경우라면 더더욱 스스로 인지부조화를 강화하며 인정하기 어렵다. 당사자 개인 감정의 문제도 있고, 그 위치에서 결정과 판단을 내리는 스스로의 권력이나 그 유지에 위협이 되기 때문일 것이다. 설령 그게 잘못되었다고 하더라도, 그걸 적당히 포장해서 성공이고 실적인 것처럼 만들려고 하는게 대다수의, 그리고 그런 하강을 어쩔 수 없이 빠져나오지 못할 이들일 것이다. …이러한 자아에 사로잡힌, 근시안적인 실적주의가 일으키는 패턴은, 스스로 되돌이키지 못할, 이 하강의 매 단계에 동일하게 반복되어 간다.

… 나머지는 우리가 아는대로다(좀 더 정확하게 말하자면, 아무도 알지 못하게 사라져간 볼랜드…가 더 알맞겠지만), 현재의 델파이-는 여전히 팔리고 있지만 굳이 진입하려고 하지 않을 것 같다.

그리고 Hejlsberg옹의 그 이후의 작품들인 .NET/C#, TypeScript은 세상에 너무나 주류가 되어 버렸다.

당시의 Hype였던 객체지향/OOP을 더 맛보고 싶은 사람들은, 거기에 한참 대중화되어 가던 인터넷/웹을 위한 프로그래밍언어라고 마케팅하던, 자바에 나와 사람들은 열광했다.²

어느 정도는 사실이었던게, 실제로 자바는 지금도 윈도든 맥이든 리눅스든 잘 동작한다. 서버나 데스크탑이 아니어도, 웹브라우저에서도 지금이야 HTML5 등이 보편적이지만, 동적인 웹페이지를 만들기가 어려웠었기 때문에, 자바 애플릿 같은 것에 끌릴 수 밖엔 없었었다.

당시의 보수적인 사람들은, 자바는 메모리사용량이 너무 많고, VM이 인터프리터 방식이어서 느리고 무겁다며 절대 대중화되지 못할거라고 장담했었었다. 하지만, 지금에 와서 돌아보면, 하드웨어는 그보다 빨리 고사양화되었고, VM은 HotSpot기술이나 정밀한 JVM의 Garbage collector등을 탑재하고, (잘 쓰면) 꽤 빠른 언어에 속하게 되었다.

물론, 어느샌가 시간은 흘러서, 자바사용자가 보수층이 되고, 그 이후에 유행하는 다른 다이나믹언어들을 보면서 또 똑같은 비평을 하는 광경까지 벌어졌었다. 하지만 그건 한참 이후에의 일이다.

자바언어와 그 바이트코드의 Specifications이 표준화가 잘 되어 있고, 구현자가 달라도 거의 걱정을 할 필요가 없는 언어와 VM이다. 하지만, 당시에 자바의 이런 ‘표준성’을 무시하는, 혹은 무시하고 스스로가 시장에서 독점적인 위치를 차지하고 원래의 표준/자바를 대체하려고 하던 시도들이 조금씩 일어났었었다. …물론 시도뿐이고 크게 성공한 경우는 없다. 다행인지, 불행인지, 덕분에 자바는 아직도 어느 플랫폼에서나 비슷한 모양새로 적당히, 모든 플랫폼의 하한선에 맞춰진 GUI을 자랑하며 잘 동작한다.🙃

아직도 약간 그런 경향이 남아 있지만, Java “EJB”서버시장이나, 당시에 유행하던 객체지향에 편승한 UML설계도구 + 자바IDE 시장은 각 기업별로 조금씩 특성이 달랐다. 하지만, 그럼에도 자바표준을 잘 준수하고 그 안에서 동작하려고 노력은 해온 것 같다. 그리고 2000년대 초에는 자바표준을 지켜온 모범적인 예와 그와 정반대인 괴이한 변종들이 나타났었었다.

모범생🪿: Borland “JBuilder”

볼랜드도 이러한 자바 IDE을 내놓았었는데, 다른 C++ 제품과 같이 “Borland JBuilder”였었었다.

그리고 C++ Builder, Delphi 제품과 유사한 GUI에 Java 특유의 AWT/Swing GUI을 직관적으로 제작할 수 있었었다.

이후에 유행하는 Eclipse JDT, IDEA IntelliJ와는 조금 다른 모양새의 Java IDE으로 보이는데, 이는 전자들은 서버쪽에 자바를 응용하는 것에 집중하여 더 코드 자체에 집중하는 모습인데 비해, 이 시대의 자바 개발은 Java Swing, Applet 등 GUI에 더 주목하고 있기 때문일 것 같다.

Apple맛🍏 Java: Rhapsody, Yellow Box, WebObjects

그리고 흥미롭게도, 다 망해가던 애플은, 이 시점에 스스로 잘못 뽑은 경영진에 의해 배신 당했었던 스티브 잡스와 그의 회사 NeXT을 다시 불러들이고 인수한다.

새로운 OS, HW을 시작하려 준비를 하던 시기였다.

애플의 “MacOS Classic”은 이미 가상메모리 시스템, 멀티태스킹 등 안정성에 관한 한계에 다다른지 오래였었다. 그리고 그에 대한 대안으로 Be, Inc.의 BeOS 등이 NeXT와 경쟁을 했었었다. BeOS와 현재의 HaikuOS, NeXT와 GNUstep, 그리고 현재의 OSX에 대한 이야기는 흥미로운 역사와 그 결과인데, 언젠가 다른 포스팅에서 해볼까 한다.

👉 https://en.wikipedia.org/wiki/NeXT#1997%E2%80%932006:_Acquisition_by_Apple

그리고 바로 이 시대에, 애플은 NeXTSTEP을 새로운 MacOS의 기반으로 선택하며 “Rhapsody”이란 실험적인 시도를 한다:

Rhapsody은 스크린샷만 봐도, 애플의 MacOS스러움을 사실은 NeXTSTEP에 더한 느낌이다. 그리고 이게 현재의 MacOS X, 그리고 iOS의 전신이다.

이때에 “하위호환”을 위해, 과거의 MacOS Classic 애플리케이션을 실행하기 위한 가상화레이어가 내장되어 있었는데, 이를 “Blue Box”이라고 하고, 새로운 NeXTSTEP 계층을 “Yellow Box”이라고 불렀다고 한다.

NeXTSTEP/OPENSTEP은 이미 NeXT OS이 아닌, Sun社의 Solaris이나, 심지어 Microsoft Windows NT에도 이식되어 실행되었었기 때문에, Blue Box에 비해 이식은 수월했으리라 싶다.

그리고 이때에 애플은 차세대 OS의 프로그래밍언어로서, 전통적인 NeXTSTEP/OPENSTEP에서 사용하던 Objective-C만이 아니라, 당시 트렌드키워드였던 Java 또한 사용해서 애플리케이션을 만들 수 있다고 말하기 시작했다.

하지만 그다지 호응은 없었었다. 다행인거 같다. 어쩌면 당시 OPENSTEP의 부진이, 너무 다른 프로그래밍언어였던 Objective-C에 있다고 스스로 위축되어 있어서 이런 결정을 하지 않았을까 추측해본다.

실제로 Objective-C은 RTTI와 Message-passing 같은 C++이나 자바에 비해서도 훨씬 동적이고, 오히려 스몰톡이나 Ruby 같은 다이나믹언어에 가깝다. 그런 이유 때문에 Visual C++와 같은 다른 프로그래밍언어 IDE에 비해서 자동완성이 당시 기준으로는 구현하기 어려웠었었다.

..어떤 변수가 구체화된 클래스의 인스턴스를 타입으로 갖는 것이 아니라, 단순히 모든 객체를 나타내는 NSObject*-이나 더 극적으로 단순히 id-타입일 수 있는데, 그럼에도 원래 클래스의 인스턴스메서드를 ‘호출’해도 실행시간 message-passing이기 때문에 정상적으로 동작한다. 그런데 바로 이런 현재의 다이나믹언어와 같은 특성 때문에, IDE의 관점에서는 어떤 메서드를 호출할 수 있는 변수인지 추론하기 난해하다.

이 문제는 현대에 Xcode에 들어서, LLVM팀이 유입되고, 정적분석이 수월해지면서 비약적으로 개선된다. 또, 이 LLVM의 Chris Lattner을 통해서 이후에 현재 애플의 프로그래밍언어인 Swift이 설계되고 개발된다.

KHTML와 WebKit의 관계처럼, LLVM이란 오픈소스와 Xcode/Swift의 관계도 흥미롭다. 또한 LLVM JIT을 통해 현재의 JIT이 보편화된 시대의 이야기도 가능할 것 같다. 이런 이야기는 가능하면 다른 포스팅에서 더 이야기해보고 싶다.

결국, 자바 언급은 Objective-C만으로는, 사람들의 관심을 끌기 어려울 것 같다는 자신감 부족 때문이 아니었을까 싶다.

그렇지만, 이런 Apple + Java의 결합이 더 흥미로웠던 분야가 있었는데, 잘 알려지지 않은 애플의 제품중 하나였던 WebObjects-와의 결합이 그러했다.

웹오브젝츠는 애플의 이전, 넥스트社일 때 공개된 제품이었었다. 어쨌든 훌륭한 개발환경이었던 OPENSTEP의 개발도구와 API을 활용하여 웹개발을 할 수 있는 제품이었었다.

이미 2000년대 초에 ‘컴포넌트 기반’으로 웹개발을 할 수 있었었다. 그리고 흥미롭게도 아직도 그 영향을 받은 클론이나 웹프레임웍이 오픈소스로 공개되어 있다.

웹오브젝츠와 함께라면 자바의 결합이 더 유효해 보이기는 한다. 하지만 웹오브젝츠 자체가 성공적이지는 못했었다. 그리고 그 덕분에 애플과 자바의 결합은 어느 측면으로도 성공적이지는 못했던 것 같다.

위에 설명한대로, 마이크로소프트는 자바를 사실상 흡수하여, 그 VM와 언어 자체를 마이크로소프트스럽게 만들고 확장한 .NET와 C#을 공개한다.

그리고 그 이후에 Visual Studio 제품군은 Native 코드를 위한 Visual C++을 제외하고는 모두 .NET 기반이 계속된다. 그리고 심지어 C++ 또한 “Managed C++”으로 사실상 .NET을 위한 언어도 항상 함께 공개되어 왔다.

그리고 시장의 전체를 장악하지는 못했지만, 자바와 그 밖에 다른 오픈소스들의 영향, 리눅스 서버의 영향 등등으로 인해서, 그래도 꾸준하고 안정적인 시장을 다져온 것 같다.

웹개발의 측면 이외에, 윈도 데스크탑 애플리케이션을 만드는 분야는 분명히 기존 델파이를 써서 만들던 것만큼 쉽거나, 혹은 더 현대적으로 닷넷/C# 기반으로 많은 중소기업들이 이행했으리라 추측할 수 있다.

C#은 현재에도 계속해서 확장되고, 다른 어떤 오픈소스 언어보다 빠르게 새로운 프로그래밍언어 이론의 연구 등을 반영해주는 상업적인 언어라고 생각한다.

하지만, 몇 기가바이트나 하는 .NET 프레임웍을 함께 배포해야 하거나 하는 것 등은 가끔 아득해지게 만드는 요인이긴 하다.

그리고 물론 Hejlsberg옹의 작품목록에는 C#이 포함된다.

현대의 MS은 오픈소스에 매우 친화적이려고 노력하는 기업이 되었다. 예전의 ‘M$’이라며 오픈소스, 리눅스 지지자들이 혐오하던 MS와는 많이 달라진 모습이다.

심지어, MS제품에만 안목이 제한된 사람들은 눈치채지 힘들지만, 윈도에서 리눅스를 실행할 수 있는 환경인 WSL을 만들고 제공하기도 한다.

그리고 2026년 가장 트렌디한 프로그래밍언어 중 하나인 타입스크립트 또한 MS와 Hejlsberg옹의 작품이다. 흥미롭게도.

닷넷이 그 ‘프레임웍’을 함께 배포해야 했듯이, 타입스크립트로 만든 데스크톱 애플리케이션이 크롬을 내장한 Electron이 거의 그 정도 크기로 배포되어야 하는 것도 우습지만 흥미로운 점인 것 같다.

델파이나 터보파스칼은 구닥다리이고, 요즘 누구나 다 쓴다는 타입스크립트를 해야 하고, 시장에서 개발자를 구하려면 어쩌고 하는 정도인 수준의 이야기는 나 스스로가 부끄러울 수준의 이야기일 것 같다. 오히려 어떤 영향을 어떻게 주고 받았을지, 어떤 흐름에서 어떻게 발전, 파생되었는지를 이해할 수 있는 편이 더 나을 것 같다.

타입스크립트나 델파이, 혹은 씨샵의 공통점에 대해서는 언급할 필요가 없을 것 같다. 반면에, 이 포스팅에서는 드러나지 않은 역할자들을 조명해봤다. 오히려 닷넷이 있을 수 있도록 해준 공로는 자바에 더 크게 있다고 생각한다. 그리고 오히려 타입스크립트가 존재할 수 있던 이유에는 역설적으로 델파이에, 그리고 처음 프로그래밍을 접근할 수 있는 것으로 제공하던 터보파스칼에서부터 시작되지 않았을까 상상해볼 수 있다.