Orion 프로젝트에 대하여

소개

오라이언 프로젝트는 다음 세부분으로 구성되는데,

IMA Libraries
Orion Framework
Orion End User Application

최종 단계인 응용 프로그램은, 개체들이 실시간으로 상호 작용하는 환경을 생성할 수 있는 도구를 제공하는 것이 목표입니다. 개체들이 실시간으로 상호작용하는 환경의 대표적인 예는 '게임'입니다. 그러므로, Orion 의 최종 응용프로그램은 게임 생성기로서의 역할도 수행할 수 있을 것입니다.

하지만, 게임이라는 분야에만 국한하지 않고, 개체들이 실시간으로 상호작용하는 환경이라는 좀 더 일반적인 개념으로 정의하는 이유는, 그러한 환경을 생성하는 일이 개념적으로 보다 폭넓게 적용될 수 있어서, 어떤 관점에서는 일반적인 응용 프로그램을 생성하는 작업으로까지 범위가 확대될 수 있기 때문입니다. 예를 들면 델파이같은 RAD 툴이 그런 개념을 가지고 있습니다. 하지만, 현존하는 소프트웨어들을 살펴보면 여전히 게임 생성기는 게임 생성기이고, RAD 툴은 RAD 툴일 뿐입니다. 하지만, 저는 그 작업들이 본질적으로 같다고 생각합니다. 마치 미사일에 맞아 추락하는 적군의 비행기는 마우스로 클릭 당하는 버튼과 다를 것이 없다고 생각하는 것입니다.

그런 생각들이 오라이언 프로젝트 최종 목표의 일부입니다. 그래서 Orion Framework 는 응용 프로그램을 위한 범용 아키텍쳐의 성격을 띠고 있고, 개체 환경, 네트워크 통신, 다중 스레드 환경, 스크립트 및 레코드 관리들을 총망라하고 있습니다. 그리고 이러한 구현이 PDA나 스마트폰 같은 소형 장치로부터 대형 워크스테이션까지 동일하게 작동할 수 있습니다. 그래서, 오라이언 소프트웨어의 아키텍쳐를 높은 호환성을 갖는 스크립트/레코드/컴포넌트 기반 비동기적 서버 클라이언트 아키텍쳐 라고 부릅니다.

이러한 프레임 워크 구현에 필요한 기능들을 뒷받침해주는 것이 IMA 라이브러리입니다. Coral은 기본적으로 각종 자료 구조를 구현하는 라이브러리이지만, MS COM 처럼 동적 로드되는 개체환경, 플렛폼 독립성을 보장하는 각종 입출력, 스레드 환경을 갖추기 위한 API 들을 정의합니다. IMAGE(발음은 I,M,A,G,E 로 합니다.) 는 Coral 에서 다루지 않는 그래픽적인 부분, 즉 사용자 인터페이스, 그래픽 렌더링, 멀티 미디어 등을 플렛폼 독립적으로 구현합니다.

이들 IMA 라이브러리들은, 그 자체로 독립적으로 이용가능하기 때문에, Orion 프로젝트에서만 쓰일 수 있는 것은 아닙니다. 그래서 Orion 프로젝트가 완성되기 전이라도, 이들 라이브러리가 좋은 역할을 할 수 있는 구현들이 있을 거라 생각합니다. 그래서, Coral 같은 경우는 오픈 소스 프로젝트로 공개를 했습니다. 하지만, 아직은 적절히 관리하지 못했기 때문에 결과물은, 새롭게 구현된 기능들이 업로드되지 않은채 아직 3년전의 상태로 머무르고 있습니다. 사람들의 관심이 적었고, 적은 관심이라도 있을때 바쁜 생활로 인해 적절히 대응하지 못했기 때문에, 아직까진 활성화되지 못했습니다. 아직 오픈 소스 프로젝트를 진행하는데 능숙하지 못한 것 같습니다.

Orion Framework 가 완성되면, 이것을 이용해서 다양한 응용 프로그램을 제작할 수 있을 것입니다. 개발을 진행 중인 지금도, 가능한 경우 개인적으로 참여하는 상용 프로젝트들에 적용하고 있습니다. 다양한 실제 프로젝트에 Orion Framwork 를 적용함으로써, 범용성과 안정성이 높아질 것으로 기대하고 있습니다. 실제로 오라이언 응용 프로그램 제작에 착수하기 전까지 개인적으로 10여개 이상의 서로 다른 프로젝트를 적용해볼 생각입니다. 그 사이에 협업 가능한 개발자들도 만날 수 있어야 하며, 만일 그 사이에 이 프로젝트가 유용하다고 판단하는 다른 개발자에 의해 새로운 프로젝트들이 진행될 수 있다면 아주 즐거울 것입니다.

현재 상황

현재는 그동안 작업이 중단됐던, IMA 라이브러리들을 보강하면서, Orion Framework 의 첫단계를 구현하는 중입니다. 이 작업이 만족할만큼 진행된다면 Orion 의 최종 목표를 위한 첫발을 디딜 수 있을 것이고, 아마 내년 중에는 가능하지 않을까 생각합니다.

지금 관심을 두고 있는 구현은, 동영상 처리와 범용 편집기 구현입니다. 이 구현은, 동영상 편집을 위해 선택된 지점에 다른 동영상을 삽입하거나, 동영상의 특정 구간에 특수 효과를 적용하는데 필요한 자료구조는 워드프로세서에서 문장의 특정 위치에 새로운 문장을 삽입하거나, 문장의 일부에 폰트 크기나 색상같은 효과를 적용하는 데 필요한 자료구조와 동일하다는 가정하에 진행되었습니다.

이 구현이 마쳐지면, Coral 에서 정의하는 계층적 Layout 자료구조를 이용하여 편집 가능한 형식화된 문서를 작성하는 기능을 구현할 수 있습니다. Layout 구현은 기본적으로 평면상에 IMA-GE 라이브러리가 정의하는 UI 요소들을 배치하기 위한 계층적 구조를 생성하는데 사용되는데, 더 나아가 이 구조는 워드 프로세서 문서에 상응하는 문서 구조로 적용될 수 있습니다.

Coral 의 Layout 자료구조를 이용한 간단한 계층 구조 예

궁극적으로 이 구조는 XUL 이나 MS 의 XAML 같은 기능을 포함할 수 있을 것이며 Orion Framwork 의 평면 UI 를 구현하는데 이용될 것입니다. 저는 몇몇 산업 분야의 분석용 소프트웨어를 작성하는 일에 참여한 적이 있는데, 워드 프로세서 문서처럼 편집 가능하도록 작성된 사용자 인터페이스가 필요하다는 것을 느껴왔습니다. 이러한 구현은 유용하지만, 구현이 매우 복잡합니다. 그래서 특정한 응용 프로그램에서 손쉽게 도입하고 그 프로그램의 목적에 맞도록 유연하게 기능을 추가할 수 있도록 작성된 라이브러리를 찾기가 어렵습니다.

다른 한편으로는 IMAGE 의 2nd Edition 을 마무리지어야 합니다. IMAGE 의 첫 릴리스는 소프트웨어 렌더링 라이브러리를 자체적으로 구현하는데 성공했지만, OpenGL 이나 DirectX 와 밀접하게 연동할 수 있는 것까지 고려되지 못한채, 1998년에 첫 릴리스를 마친 이후로 개발이 이루어지지 못했습니다. OpenGL 이나 DirectX 와 달리 IMAGE 는 자체적으로 UI API 를 지원합니다. 이 API 는 플렛폼 독립적이고, 그래픽 렌더링에 사용되는 API 들을 UI 요소를 렌더링하는데에도 사용할 수 있습니다. IMAGE 는 음성 입출력과 동영상 입출력또한 다루기 때문에, 초기에 IMA-Graphic Engine 이라 칭했던 것을 IMA Game Engine 으로 최종 확정 했습니다. 또한 이들 기능에서, OpenAL, DirectSound, FFMPEG, DirectShow 등을 선택적으로 이용하는 것이 가능합니다.

또 하나 구현을 고려하는 분야는 C 언어를 소스로 하는 바이트 코드 생성기 입니다. (대체물들이 현존하는 것은 사실입니다.) 바이트 코드를 실행할 수 있는 가상 머쉰의 용도는 아주 많고, Orion Framework 내에서도 중요한 역할을 할 수 있을 것입니다.

이러한 단계까지가 Orion Framework 의 첫 릴리스가 될 것입니다. Orion Project 는 제 삶에서 개발자로서 남기고 갈 최종 목표에 해당하기 때문에 범위도 큰 편이며, 시간도 많이 필요할 것이고, 특히 같은 뜻을 가진 사람들도 필요해질 것입니다.

공동 작업

나는 이러한 일들을 10년 가까운 시간동안 진행해오며, 여러 비판들을 겪기도 했고, 비슷한 구현들이나 대체품이 많다는 것도 잘 알고 있습니다.

하지만, 그런 여러 대체물들을 Orion 프로젝트의 목표를 위해 한데 모은다는 것은 마치 전 세계 사람들을 인류 공영을 위해 단결시키는 것처럼 어렵다는 생각을 갖게 합니다. 물론 Orion 프로젝트가 이용가능한 외부 라이브러리들을 모두 배제하는 것은 아니고 그럴 수도 없습니다. libc, zlib, ffmpeg, OpenGL, DirectX 등 수 많은 외부 라이브러리들을 사용합니다.

그럼에도 불구하고 어떤 기능들은 최종 목표를 위해서, 선택 가능한 기존 구현을 포기하기도 하고, 호환성을 유지하기 위해 새로운 형식으로 재정의하는 경우도 있습니다. 어떤 개발자에게는 이러한 구현이 독단적이며 지극히 개인적으로 느껴져서, 거부감을 갖기도 하는 것 같습니다. 제 구현은 널리 알려진 것이 아니며, 많이 쓰이고 있지도 않기 때문에, Orion 프로젝트의 최종 목표에 공감해서 참여하려는 개발자가 아니라면 그런 거부감은 어떤 면에서는 당연한 것이라고 봅니다.

예를 들어 Coral 라이브러리는 MS 의 COM 의 일부 구현에 상응하는 DL ( Dynamic Loader ) API 들을 제공합니다. 그래서 이 API 사용을 주장하면 항상 이런 질문을 받기 마련입니다.

"COM 으로 되는데 왜 그걸 사용하느냐?"

그럼 저는 우선 이렇게 되묻습니다.

"COM 을 윈도우즈가 아닌 플렛폼에서 사용할 수 있는가?"

그러나, 대개의 회사 업무는 윈도우즈상에서 행해지기 때문에 그 상황에서의 제 답변은 공허할 수 밖에 없습니다. 물론 다른 이유도 얘기할 수 있습니다만, COM으로 다된다는 사람들을 설득하려면, 개발의 철학적 문제들까지 거론되어야할 지도 모릅니다. 철학에 대한 토론은 매우 개인적일 가능성이 높기 때문에 감정적 싸움이 되기 쉽습니다. 이런 논쟁에서는 이겨도 얻을 게 없습니다.

이러한 장벽은 오라이언 프로젝트에 동조하는 개발자들을 제 주변에서 얻기 어렵게 만듭니다. 한가지 이해하기 어려운 것은, 회사에서 일하는 개발자들이, 자기와 멀리 떨어진 사람이 개발한 소스들을 인터넷을 통해 가져다 쓰는 경우와, 제가 만든 라이브러리를 가져다 쓰는 경우에 대해 공평한 기준을 적용하지 않는다는 사실입니다. 나는 그런 개발자들이 자기 중심적인 판단 기준을 사용하기 때문이라 생각합니다. 마틴 파울러의 리팩토링이라는 책에 다음과 같은 말이 나옵니다.

"컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다."

그런 개발자들은 아마도 이 말을 오해하여, 자기가 이해할 수 없는 코드를 나쁜 코드로 간주하고, 그것을 작성한 사람을 나쁜 프로그래머로 간주하는 어리석은 실수를 범하게 될 것이라 생각합니다.

개인적으로 오라이언 프로젝트에 전력을 다하는 것과 별도로, 이 부분 역시 큰 고민입니다. 우선 IMA 라이브러리들, 그중 우선 부족하나마 공개 소프트웨어로 되어있는 Coral Library 의 일부 기능이라도 제가 아닌 다른 사람에 의해 어떤 프로젝트에 응용 될 수 있는 기회들이 필요합니다. 저 또한 개인 프로젝트나 회사 프로젝트에 이용했기 때문에, 분명히 사용할 수 있는 분야가 있다고 생각합니다. 이것을 위해 문서화가 필요합니다. 하지만, 제 여력으로 양질의 문서를 만드는 것은 지금으로선 불가능한 일입니다.

IMA 라이브러리들의 사용예가 증가하면서 협업의 가능성은 높아질 것입니다. 만일 내 혼자 힘으로 오라이언 프로젝트를 완성하길 원한다면 나는 몇번이고 환생해서 이전 작업까지의 기억을 되찾기 위해 노력해야 될 겁니다. :-)

결론

많지는 않아도 국내 또는 국외의 익명의 개발자들이 제가 진행하려는 프로젝트의 전체나 일부에 대해 문의하는 경우가 있었지만, 이제까지 적절히 대응하지 못했다고 생각합니다. 우선 그 방법을 제 자신이 제대로 알지 못하는 것 같습니다. 또 하나는 마음의 여유를 갖고 일을 진행할 만큼 안정적인 개인 생활을 만들지 못한 것입니다. 금전적인 문제를 배재하고 개발할 수 있는 상황이 아닙니다. 현재는 Coral 만 부분적으로 공개됐지만, 하부 라이브러리들을 지속적으로 공개할 생각입니다. 하지만, 어디까지 공개할 수 있을지, 내 결과물이 그럴만한 가치는 있는건지 아직 잘 모릅니다. 프로젝트가 계속 진행되는만큼, 그런 고민도 계속됩니다.

2007.09.17

대문 | 이전 | 영어