왜 오픈소스
Source: Dev.to
Introduction
이 문서는 제가 오픈소스 소프트웨어 프로젝트를 시작하게 된 과정을 설명합니다.
이유는 많고 흥미롭습니다. 이는 제 역사를 다룬 비기술적인 문서입니다.
요약하면, 오픈소스 프로젝트를 만들게 된 주요 이유는 제가 다른 오픈소스 프로젝트를 사용하면서 큰 혜택을 받았기 때문입니다. 그 가치를 이해하게 되었고, 저 역시 제 프로젝트를 오픈소스로 공개하기로 결정했습니다.
제가 자체 프레임워크를 시작하게 된 배경은 기업들이 제품을 중단하거나 제품 수명 주기가 특정 시점에 종료될 수 있다는 사실에서 비롯되었습니다. 이러한 수명 주기를 따라잡기가 종종 어렵기 때문에, 저는 오래된 제품을 더 오래 사용하는 편을 선호합니다.
이 문서는 필요에 따라 지속적으로 업데이트하며, 제 역사를 더 많이 채워 나갈 예정입니다(GitHub Pages 버전에서).
Lothar Behrens – 2024년 10월 20일 토요일
끝까지 읽으신 후 – MFC 코드 템플릿을 원하시나요?
이 글의 마지막에서 저는 다시 MFC 애플리케이션을 만들겠다고 결론짓습니다. 그 주요 이유는 여기서 설명됩니다.
이를 시작하기 위한 가장 가능성 높은 방법은 MFC 프레임워크를 기반으로 코드를 생성하는 템플릿일 것입니다. 제 주요 질문은: 그것을 원하시나요?
컴퓨팅 초기 시절
내가 교육을 시작할 때 구입한 첫 번째 컴퓨터는 512 KB RAM만 장착된 IBM‑PC‑호환 기계였으며, 당시로서는 충분한 사양이었습니다. MS‑DOS와 GEM을 실행했습니다.
학업 중에 찾을 수 있는 모든 책을 집어 들고 읽으며 컴퓨터의 구석구석을 배워 나갔습니다.
BASIC(이모의 C64)으로 프로그래밍을 배웠습니다. 교육 초기에 BASIC보다 더 나은 언어가 있다는 것을 깨달았기 때문에 Schneider PC의 BASIC 2(Locomotive Software)로는 아무것도 하지 않았습니다.
Programming 시작하기
앞서 언급했듯이, 저는 교육을 시작하기 직전(또는 시작과 동시에) 첫 번째 컴퓨터를 구입했고, 곧 객체 지향 언어를 접하게 되었습니다. 그 언어는 BASIC보다 더 매력적이었기 때문에, 저는 다음 컴퓨터를 그에 맞춰 구입했습니다.
학교에서는 BASIC이 우리가 배우는 언어였고, 저는 종종 반 전체보다 먼저 준비가 되어 있었습니다—아마도 C64에서 이미 BASIC을 사용해 본 경험이 있었기 때문인데, 이는 GW‑BASIC과 유사합니다.
나의 첫 번째 소프트웨어 아이디어
Turbo Pascal을 손에 넣었을 때, 나는 처음으로 소프트웨어 프로젝트 아이디어를 떠올렸다. 학업 중에 플로피 디스크를 많이 모았는데, 각 디스크에 어떤 내용이 들어 있는지 종이나 스티커에 메모해 두는 것이 번거로웠다.
나는 **dateiver**라는 디스크 카탈로그 시스템을 명령줄 UI로 만들었다. 오늘날에도 Linux에는 서로 연동되어 매우 유용한 명령줄 도구들이 많이 있지만, 내 애플리케이션은 다른 도구와의 상호 운용성을 염두에 두지 않은 독립 실행형 프로그램이었다.
Note: 폴더 이름은 그때와 달랐다. 나는 소스 코드를 잘 구조화하지 못했으며, 이것이 나중에 어려움을 초래했다.
dateiver는 이후 **Tvvt**라는 새로운 애플리케이션을 위해 복사되었다.
그 당시 나는 디스크 카탈로그에 필요한 프로그래밍 자료구조에 대해 많이 배웠다. 데이터베이스는 아직 익숙하지 않았기 때문에, 자료구조, 파일 I/O, 그리고 파일 시스템을 탐색해 디스크에서 데이터를 읽어오는 작업에 집중했다.
고객을 위한 첫 시도
학업을 마친 후, 잠재 고객이 특정 기능을 구현할 수 있는지 문의해 왔습니다. 저는 요구사항을 협의하고 첫 번째 솔루션을 제공했습니다.
하지만 고객은 만족하지 못했습니다. UI가 여전히 콘솔 기반이라서 그들에게 매력적으로 보이지 않았습니다. 저는 초보자였고 기대에 부응하지 못했습니다.
전문가들은 SAA를 사용한다
나중에 dateiver 를 셰어웨어 버전으로 판매하려고 시도했을 때, 현대적인 UI가 부족해서 제품이 팔리지 않을 것이라는 말을 들었습니다. 제가 찾아간 소프트웨어 판매점 주인은 이를 자신의 매장에서 취급하고 싶어 하지 않았습니다.
많은 고객(이 경우에만 해당되는 것이 아니라)이 콘솔 UI보다 그래픽 UI를 선호한다는 것을 알게 되었습니다. 셰어웨어 판매자는 저에게 화려한 SAA UI 툴킷을 살펴보라고 제안했고, 저는 그렇게 했습니다.
SAA를 사용하려면 최신 컴파일러를 구입하고 코드를 Turbo Pascal 5.5 에서 Turbo Pascal 6.0 으로 마이그레이션해야 했습니다.
나의 첫 모델‑구동 아이디어
SAA와 현대 UI 개념을 학습한 후, 책에서 대화 상자 디자이너를 발견했습니다. 이는 소프트웨어 제작에 도움이 될 것이라고 약속했습니다. 나는 곧 그것으로 더 많은 일을 할 수 있음을 깨닫고 첫 번째 모델‑구동 애플리케이션 개발 환경인 TVBuild를 만들었습니다.
After Pascal Came Windows and C++
시간이 흐르고, 나는 더 현대적인 컴퓨터가 필요했다. Schneider PC를 사용한 뒤, 다음으로 구입한 것은 서브‑노트북(초기 DIN A5‑포맷 노트북 중 하나)으로, 여전히 MS‑DOS 전용 기기였다.
그 후 나는 386 DX 40 타워 PC에 Windows 3.1과 무려 4 MB의 RAM을 장착한 모델을 구입했다. 이 기기와 함께 당시 가장 빠른 컴파일러 중 하나였던 Watcom 10.6도 구매했는데, 이 컴파일러는 Doom을 컴파일한 것으로 유명하다.
Watcom을 사용하면서 **C++**와 Windows 프로그래밍을 배웠다. 간단한 C API부터 시작해 곧 객체‑지향 프로그래밍으로 전환했고, MFC를 사용하기 시작했다.
그때 나는 아직 데이터베이스 프로그래밍을 해본 적이 없었기 때문에, 이전에 경험했던 자료 구조 작업을 다시 반복했는데 이번에는 MFC 안에서 진행했다. DrawCLI를 기반으로 실제 증기 기관차와 역사적인 열차를 운행하는 모델 철도 클럽을 위해 만든 애플리케이션을 개발했다.
Source: …
Trainres와 MFC를 통한 여정
새 컴파일러와 클럽 팀원들의 도움으로 나는 열차 예약 시스템을 만들었으며—정확히는 시도했지만—구현했습니다. 이해관계자는 역에 표시되는 지도와 유사한, 하지만 축소된 버전의 멋진 노선도를 원했습니다. 이는 16‑bit Windows 3.1 시절, 386 DX 40 MHz 머신을 사용하던 때였습니다.
그때 나는 가능한 한 최선을 다해 지식을 확장했습니다. 클럽을 위해 애플리케이션을 더 발전시키고 싶었습니다.
스크린샷(설명)은 두 개의 열차 운행 계획을 나타내는 빨간색 선이 있는 네트 리스트를 보여줍니다. 사용자가 계획을 입력하면 해당 표가 그려지고, 헤더 아래에 운행 시간표를 추가할 수 있게 애플리케이션이 반응했습니다.
이 그래픽 표현을 데이터 저장에도 활용하려는 계획이 있었습니다. 왼쪽 하단 창에 고객을 입력하고 열차 운행 001에 등록했습니다. 이 모든 것은 데이터 구조와 DrawCLI 기본 기능을 사용해 구축되었습니다.
Trainres – MFC 버전이 Windows 10까지 살아남다
이후 애플리케이션은 Windows 10 시대까지 살아남아 현재는 Visual Studio로 개발할 수 있습니다.
데이터베이스 배우기 시작
잠시 Watcom 10.6과 MFC를 사용한 뒤, 나는 훨씬 더 화려한 개발 도구인 Power++(Powersoft) 를 발견했다. Powersoft는 Watcom의 컴파일러 도구와 데이터베이스 컴포넌트를 인수했으며, 나는 그 사실을 아직 몰랐다.
Power++의 마케팅은 빠른 애플리케이션 개발(RAD)을 약속하고 내장 데이터베이스를 제공한다는 점에서 매력적이었고, 이를 통해 데이터베이스를 빠르게 배울 수 있을 것이라 생각했다.
나는 Trainres 포팅을 시작했다
당시 가장 작은 버전이었던 Power++ Developer 를 구입하고, 클럽 애플리케이션을 Power++ 클래스 라이브러리를 사용하도록 포팅하기 시작했다. 이 과정에서 나는 데이터베이스 자체보다 복잡한 다이어그램 기능을 만드는 데 더 많은 시간을 쏟았다. 뒤돌아보면, 전문 소프트웨어 개발자로서 가장 큰 문제 중 하나를 간과했는데—아직도 나는 프로페셔널하지 못했다.
다이어그램 기능은 흥미로웠다. 나는 사용자가 자신만의 기호를 설계할 수 있도록 자체 인터프리터를 작성했으며, 데이터는 데이터베이스에 저장되었고, 테이블에 간단한 고객 레코드도 넣어 두었다.
Sybase가 Power++를 중단했다
결국 Sybase는 Power++를 중단하기로 결정했다. 나는 실망했다—돈을 낭비했을 뿐 아니라 포팅 작업이 막다른 골목처럼 보였기 때문이다. 더 이상 의미가 없다고 판단해 개발을 즉시 중단했다. 클럽은 실행 가능한 애플리케이션을 전혀 받지 못했다.
이 경험을 통해 기업이 작은 고객을 항상 배려하지는 않는다는 것을 뼈저리게 배웠다. Power++가 왜 중단됐는지는 알 수 없었고, 놓친 최종 릴리스가 있었다. 몇 년 후 Sybase가 Enterprise 버전을 모든 등록 고객에게 제공했으며, 여기에는 Developer 버전만 보유한 고객도 포함돼 있었다는 사실을 알게 되었다. 나는 이후 Enterprise 버전으로 돌아갔다.
그때 나는 개발 접근 방식을 재고해야 했다. 같은 시기에 나는 새로운 트렌드인 Linux를 배우기 시작했다. Linux에서도 프로그래밍하고 싶어 API와 프레임워크를 탐색했으며, 무료이고 시간을 절약할 수 있다는 이유로 wxWidgets 를 선택했다.
Linux와 Windows를 병행해서 실험하면서, 나는 한 대의 머신에서 애플리케이션을 실행하고 다른 머신을 서버로 사용해 서로 통신하고 싶다는 것을 깨달았다. 클라이언트‑서버 프로그래밍이 다음 큰 과제가 되었고, 이는 이전에 했던 데이터베이스 작업을 기반으로 했다.
그때는 1999년이었다. 긴 이야기를 짧게 하면—나는 오늘까지도 작업하고 있는 새로운 프로젝트를 시작했다…
내 오픈‑소스 프로젝트의 탄생
내 새로운 프로젝트는 아직 오픈소스가 아니었다. 나는 특정 UI 프레임워크에 의존하지 않는 UI 래퍼를 만들려고 시도했다. 상용 제품이 벤더가 바뀔 때마다 재작성하게 만들었기 때문에, 나는 상업용 제품에 대한 신뢰를 잃었고, 직접 만든 CORBA와 유사한 무언가를 원했다.
그때 나는 소프트웨어 개발자로 일하면서 클라이언트‑서버 및 데이터베이스 프로그래밍 경험을 쌓고 있었다. 또한 버전‑관리 시스템인 CVS를 배웠다. 깊은 물에 뛰어든 것이 나중에 큰 도움이 되는 귀중한 경험을 제공했다. 나는 취미 개발자에서 전문 소프트웨어 개발자로 전환했으며—아직은 초보이지만, 그것은 또 다른 이야기다.
내 오픈‑소스 프로젝트 시작
Windows와 Linux 실험에서 진전을 이루고 큰 프로젝트에 대한 첫 시도를 한 뒤, 저는 한 걸음 물러서서 목표를 재고했습니다. 범위가 너무 커서 한 번에 모두 해결하기엔 무리였으며, 초기 시도가 제가 상상한 규모로는 성공하지 못할 것이라는 점을 깨달았습니다.
그럼에도 불구하고 전체 재작성 작업을 계속했습니다. 대부분의 부분은 재사용이 가능했으며, 새로운 설계에 맞게 호환성만 맞추면 되었습니다. 코드 스니펫은 여전히 CVS 프로젝트 히스토리에서 확인할 수 있습니다.
이제 저는 저장소를 Git으로 마이그레이션했으며, 히스토리를 보존했습니다. 이번 Git 마이그레이션은 긴 휴식 후 개발을 재개하려는 현재 노력의 일부입니다. 또 다른 큰 장애물인 CVS에 부딪혔지만, 그것은 또 다른 이야기가 될 것입니다.
오픈소스 프로젝트를 시작한 이유
제품들은 종종 자체 프레임워크를 제공합니다. 이러한 프레임워크는 다른 제품에서도 사용할 수 있을지 모르지만, 포팅 작업이 필요하지 않을 것이라는 보장은 없습니다.
제품에 MFC와 같이 공통 프레임워크가 없으면(예: Watcom 및 Microsoft Visual C++ 이후에 사용되는) 해당 제품의 독점 프레임워크를 사용하게 되고, 그 제품 라인에 종속될 위험이 있습니다. 이는 단순한 락인(예: Power++)이 아니라, Sybase가 해당 제품을 중단하기로 결정했을 때 치명적인 문제가 되었습니다.
내 자체 프레임워크를 사용하면 그 기업들이 하는 일을 동일하게 할 수 있지만, 내 통제 하에 할 수 있습니다. 계속 사용하면서 내 속도에 맞춰 결정을 내릴 수 있고, 여전히 공개적으로 제공할 수 있습니다. 이 프로젝트는 시작되고, 재작성되어 공개되었으며, 안정적인 상태에서 활발히 개발되고 있습니다. 나는 COM이나 CORBA와 유사하게 순수 추상 클래스(즉, 인터페이스)를 사용해 설계했습니다. 이러한 설계 선택이 프로젝트가 아직 살아 있는 주요 이유입니다.
현재 상황 및 아직 살아 있는 이유
오늘 이 프로젝트가 살아 있는 주요 이유는 두 가지입니다:
-
모듈형 설계 – 초기 단계에서 나는 초기 설계를 완전한 모듈형 소프트웨어 시스템으로 다시 작성했습니다. 나는 COM이 보여준 것을 이해했습니다: 인터페이스 설계 기법. COM의 인터페이스는 한 번 정의되면 절대 변경되지 않으며, 변경이 필요하면 새 인터페이스(종종 버전 접미사가 붙음)를 생성합니다. 나는 저수준 C 스타일 바인딩 기법 대신 C++ 순수 추상 클래스를 사용하여 유사한 접근 방식을 채택했습니다.
-
개인 이해관계자 – 나는 이 프레임워크의 주요 사용자입니다. 이 프레임워크는 macOS, Linux, Windows를 지원하는 크로스‑플랫폼 기능과 모델 기반 소프트웨어 프로토타이핑 접근 방식을 제공하여 데이터베이스‑소프트웨어 프로토타입을 빠르게 개발할 수 있게 해줍니다. 이 기능은 이전 Power++ 마이그레이션에서는 없었으며, 그 결과 제품이 미완성 상태로 남았습니다.
이제 나는 UML 모델(주 애플리케이션 자체)로부터 완전히 다른 언어와 프레임워크를 사용해 현대적인 외관의 애플리케이션을 생성할 수 있습니다.
MFC가 지금까지 살아남은 이유는?
MFC는 과거에 주요 UI 툴킷이었으며, 마이크로소프트는 이를 자사 주력 제품—“현금 젖소”라 불리는 제품들—에 사용했습니다. 해당 프로젝트들에 막대한 투자가 이루어졌기 때문에 마이크로소프트는 이 기술을 고수하고 있습니다.
- 방대한 레거시 코드베이스 때문에 마이크로소프트가 가까운 시일 내에 MFC를 포기할 가능성은 낮습니다.
- 개발자들은 기존 MFC 프로젝트가 깨지는 것을 방지하기 위해 종종 오래된 Visual Studio 버전을 사용합니다.
- 마이크로소프트는 MFC에 대한 UI 개선을 제공하는 벤더에 계속 의존하고 있습니다. 해당 벤더가 어려움을 겪을 경우 마이크로소프트가 인수할 수 있으며, 이는 MFC의 미래를 더욱 공고히 할 것입니다.
- 리본 UI와 같은 기능은 여전히 MFC로 개발되고 있으며, Office 자체도 이 프레임워크를 사용하고 있을 가능성이 높습니다.
왜 이 얘기를 하는가?
내 오픈‑소스 프레임워크(보다 정확히는 그 위에 구축된 메인 애플리케이션)가 Windows 기기에서 다소 구식으로 보인다. 나는 Windows 전용으로 상업적 스핀‑오프를 만들어 새롭게 디자인할 계획이다.
왜 다시 MFC를 사용하나요?
MFC가 현재 제공하는 최신 GUI 기능은 현대 애플리케이션에 필수적입니다. 또한 MFC 기반 애플리케이션의 프로토타이핑을 지원하고 싶습니다.
상업용 GUI 라이브러리 백드롭이 있나요?
예. 하지만 내 프레임워크는 락인(lock‑in)을 방지하도록 설계되었습니다. 아키텍처를 모듈식으로 유지함으로써 다음을 할 수 있습니다:
- 필요할 때 DevExpress와 같은 상업용 라이브러리를 통합할 수 있습니다.
- 기존 C++ 코드를 가능한 한 많이 재사용할 수 있습니다.
모듈식 설계 덕분에 단일 공급업체에 얽매이지 않고 최적의 UI 툴킷을 선택할 수 있는 유연성을 얻습니다.
결론
제가 오픈‑소스 개발을 시작하게 된 이야기와 프로젝트의 향후 전망, 그리고 현재 활동에 대한 간략한 개요입니다. 코드를 자유롭게 살펴보세요:
- lbdmf repository – 가능한 한 제 개발 워크플로우에 가깝게 유지하고 있습니다 (현재 Git으로 마이그레이션 중).
- Other repositories – 과거 작업의 스냅샷으로, 구조가 잘 잡혀 있지는 않지만 재미로 공유합니다.
읽어 주셔서 감사합니다!