안녕하세요. 홍민희 멘토입니다. 이번에 제가 자유 프로젝트를 멘티 여러분들께 제안해볼까 합니다만, 생각중인 것이 몇개 있는데 그 중 어떤 것이 주로 호응이 좋은지 모르겠어서 이렇게 설문을 할까 합니다. 아래 제가 제안한 프로젝트 가운데 가장 흥미로운 프로젝트가 무엇인지(만약 제가 제안한다면 함께 도전해볼 마음이 생기는지) 알려주셨으면 합니다.
(제가 제안하는 세 프로젝트 모두 자유 프로젝트이기 때문에 성공에 대한 부담은 없습니다. 따라서 제 개인적인 흥미 위주로 선정된 것들입니다.)
서비스 규모가 커지면 단일 노드가 물리적으로 감당할 수 있는 캐퍼시티를 서비스 크기가 초과하게 됩니다. 아무리 좋은 하드웨어를 구비해도 단일 노드로는 안정적인 서비스 운영을 감당하지 못할 뿐만 아니라, 그 형편없는 효율에 비해 비용이 지나치게 많이 들게 됩니다. 따라서 대용량 서비스는 필연적으로 같은 역할의 노드를 다중으로 구성하여 디플로이하게 되는데, 이 정도 규모가 되면 더이상 일일이 노드 하나 하나에 ssh로 접근하여 서비스를 디플로이하는 것이 불가능해집니다. 결국 다중 노드에 서비스 디플로이를 자동화하게 되는데, 세상에 존재하는 모든 대용량 서비스가 각자의 인하우스 디플로이 스크립트를 작성하는 것이 현실입니다.
다행히 Capistrano나 Fabric 같은 도구가 이미 세상에 존재하여 많은 대용량 서비스 개발에서 이용되고 있습니다. 하지만 최근에는 변화에 민감하게 대응하기 위해 AWS나 Rackspace 같은 API가 존재하는(즉, programmable한) 클라우드 서비스를 이용하여 요청이 많을 때는 추가적인 노드를 순식간에 투입했다가, 이용자가 많지 않을 때는 노드를 최소한으로 유지하는 식으로 유연하게 대처하는 쪽으로 설계하는 추세입니다. 실제 물리적인 서버를 IDC에 투입하던 시절에는 이용자가 갑자기 치솟아도 실제로 물리적인 서버를 구비하여 추가하기까지 시간이 많이 걸렸고 다시 이용자가 빠져도 한번 구매한 서버 비용은 보상받기 힘들었지만, 클라우드 환경은 그런 부분에서 훨씬 효율적이기 때문입니다. 하지만 이러한 클라우드 서비스 역시 제공하는 기본적인 API들을 엮어서 자동화를 하려면 결국 서비스 자체의 규모에 못지 않은 정도의 비용을 투자하여 디플로이 자동화 소프트웨어를 인하우스에서 구성해야 합니다. Capistrano나 Fabric 등은 이러한 클라우드 환경이 본격적으로 이용되기 이전에 설계된 도구들이기 때문에, 실제로 이러한 자동화 소프트웨어를 쓰더라도 문제 대부분은 직접 해결해야 합니다.
제가 제안하려는 프로젝트는 이러한 클라우드 환경에 맞는 서비스 디플로이 자동화 도구입니다. 명령어 한번으로 실제 서비스의 디플로이, 롤백, 스케일 인/아웃(scale in/out), 오토스케일(autoscale) 설정, 전체 스택 변경 등이 가능해야 합니다. 대용량 서비스 운영에 관심이 많은 멘티 분들은 함께하시면 많은 경험을 할 수 있으리라 생각합니다.
JavaScript는 90년대와 2000년대 초반에 걸쳐 지나치게 과소평가되던 언어였으나, 최근 몇년 사이에 이르러서는 오히려 웹의 눈부신 발전과 함께 과대평가되고 있는 언어이기도 합니다. 하지만 JavaScript는 W3C에 의해 웹 표준의 일부로서 정의되었고, 따라서 현재에 이르러서는 좋든 싫은 써야만 하는 언어가 된 상태입니다. 실제로 많은 사람들이 JavaScript를 현대의 어셈블리 혹은 C로 인식하고 있습니다. 표준이기 때문에 여러 브라우저마다 각자의 구현체를 가지고 있음에도 불구하고, 표준의 엄격함 덕분에 모든 구현체가 거의 동일한 시멘틱을 구현한 유일한 언어이기 때문에 더욱 웹의 포터블 어셈플리 언어(portable assembly language)로서의 가치를 갖게 되는 것입니다.
그럼에도 불구하고 JavaScript는 다른 웹 표준과 마찬가지로 발빠른 개선이 힘든 표준입니다. 사실상 새로운 표준은 최신 브라우저의 커버리지 문제 때문에 10년이 지나도 제대로 사용할 수 없습니다. (Internet Explorer 6는 출시 당시 웹 표준을 가장 잘 지키는 매우 훌륭한 브라우저 구현이었으나, 10년이 지난 지금 시점에서도 여전히 무시할 수 없는 존재입니다.) 따라서 언어 자체의 불편함이 존재하고 언어 디자이너인 Brendan Eich조차도 원죄를 인정하고 있는 구석이 상당히 많음에도 불구하고 현실적인 한계로 인해 개선된 디자인을 구현해도 당장 쓸 수 없는 것입니다.
그래서 최근에는 JavaScript를 어셈블리 언어로 보는 관점의 연장으로, JavaScript를 타겟 언어로 컴파일하는 언어들이 많이 등장하고 있습니다. 비교적 얇은 추상화로 JavaScript와 거의 모든 면에서 시멘틱을 유지하면서 문법적인 설탕(syntactic sugar)을 많이 추가한 CoffeeScript 같은 언어에서부터, 좀더 두꺼운 추상화를 하여 컴파일 시점에 부분 타입 검사(optional type check) 등을 추가하는 Dart 같은 언어, 공통의 언어를 정의하고 JavaScript, ActionScript, PHP와 같은 여러 타겟으로 컴파일하는 haXe와 같은 언어, 기존에 이미 존재하는 언어를 구현하되 타겟만 JavaScript로 하는 컴파일러 구현 위에 리치 웹 애플리케이션 개발을 위한 특수화된 런타임 라이브러리를 얹는 GWT, Pyjamas와 같은 도구들까지 매우 다양한 시도가 존재합니다.
제가 제안하려는 프로젝트 역시 JavaScript를 타겟으로 하는 컴파일러 구현입니다. 구현할 언어는 아직 정해지지 않았으나, 웹 환경에 맞게 새로운 언어를 직접 디자인하는 것부터, 기존에 널리 쓰이는 범용 하이레벨 언어의 디자인을 그대로 구현하는 것까지 모든 시나리오를 다 염두하고 있습니다. 아마도 프로젝트 기간을 고려하여 우리가 투자할 수 있는 시간 내에서 가장 도전적인 목표를 설정하는 균형 잡힌 결정을 하게 될 것입니다.
콘월드란 가상의 세계(fictional world)를 설정하는 것을 말합니다. J. R. R. Tolkien의 중간계(middle-earth), Lucas Arts의 Star Wars 프랜차이즈, Blizzard 사에서 개발한 Warcraft 시리즈 등이 모두 여러 작품 사이에 공유되는(shared) 하나의 가상 세계를 상정하고 있습니다. 전통적으로 콘월드란 장르 문학 작가나 게임 작가들의 영역이었기 때문에 기술이 개입할 기회가 지금까지 그리 많지 않았습니다. 여전히 작가들은 하나의 거대한 세계와 역사를 역악한 환경에서 워드프로세서와 위키 정도의 시스템만 가지고 관리하고, 버전이 올라가면서 생기는 설정 사이의 비정합성(inconsistency)도 많아지게 마련입니다.
이러한 상호 관계가 많은 설정들을 온톨로지를 통해 관리할 경우 설정의 비정합성을 줄일 수 있음은 물론, 재생성 가능한(regeneratable) 정보들을 필요 이상으로 중복적으로(redundantly) 보존할 필요가 없어집니다. 예를 들어 여러 인물 사이의 부모 자식 관계를 온톨로지로 표현하면, 족보는 계산되어질 수 있는 정보이므로 작가가 별도로 보존하거나 만들 필요가 없을 뿐만 아니라, 여러 인물 중 일부의 관계가 재설정된다고 해도 족보 트리는 자동으로 변경이 반영되게 됩니다.
또한 콘월드의 특성상 특정 시점으로부터 독립적으로 기술되어야 하는데, 이를테면 특정 인물의 신장이란 그 인물이 몇살이었을 때냐에 따라 계속적으로 변하는 값이므로 이러한 것들을 표현 가능해야 합니다. 특정 역사적 사건에 따라 지형이나 국경선은 바뀔 수 있으며, 그 이전과 그 이후에 관한 모든 정보는 통합된 방식으로 관리될 수 있어야 합니다.
하지만 이러한 시스템의 주요 이용자는 데이터베이스에 익숙한 공학자 혹은 과학자들이 아니기 때문에 엄밀한 온톨로지 시스템은 사용 가능하지 않습니다. 따라서 작가 등이 사용할 수 있는, 콘월드에 특화된 나이브한 온톨로지 시스템이 필요하게 됩니다.
일반적으로 온톨로지는 실제 세계의 사실(fact)들에 대해 기술하게 됩니다. 따라서 실제 온톨로지 시스템들은 최소한의 정보들로 더 큰 정보를 연역적으로 추론해내는 방식을 사용합니다. 예를 들어 A가 C의 할아버지라는 관계를 정의하는 대신, A가 B의 아버지이며, C가 B의 아들이라는 두 가지 작은 정보들만 정의하고, 그로부터 A과 C의 할아버지라는 연역적으로 추론할 뿐 실제로 그것을 저장하지는 않는 것입니다. 즉 물리적으로 존재하는 명제가 아니라 논리적으로만 존재하는 뷰(view)로 다루는 것입니다.
하지만 작가들이 가상의 세계에 대해 설정하는 방식은 때로는 불완전한 부분적인 정보만을 먼저 정의하는 방법을 선호합니다. 예를 들어 실제로 A가 C의 할아버지라는 정보가 중요할 뿐, A의 아들이자 C의 아버지인 모종의 캐릭터 B는 당장은 설정될 필요가 없을 때도 있습니다. 예를 든 조부 관계의 경우 중간에 필요한 노드가 하나뿐이므로 그럴 필요성을 느끼기 힘들지만, D와 D의 10대손 N에 대해서 설정하고자 하면 중간의 노드들을 모두 생성한 뒤 그들 사이의 연속적인 관계를 만들어서 연역적인 추론을 만들어내야만 한다면 작가들은 그런 시스템을 사용하려고 하지 않을 것입니다.
한편 저러한 추론 가능한 정보를 실제로 저장하기 시작하면 필연적으로 정보 사이의 비정합성이 나타날 수밖에 없습니다. 초기에는 D가 N의 10대손이라는 관계 정보만 필요했지만, 나중에 작품의 규모가 커지거나 해서 그들 사이의 노드들이 하나 둘씩 채워지다보니 그 가운데 노드가 9개보다 적거나 많아질 수도 있는 것입니다. 우리가 만들어야 하는 시스템이 엄밀한 온톨로지 시스템이 아닌, 조금 특수화된 나이브한 온톨로지 시스템인 이유는, 이러한 정보를 표현하기 위해서 일시적 비정합성 등을 허용하는 대신 비정합성을 자동으로 탐지하고 교정하는 기능이 필요하기 때문입니다. (엄밀한 온톨로지에서는 애초에 오류의 여지가 있는 정보는 입력을 못하도록 논리 검사기를 만들어야 합니다.)
마지막으로 이 시스템은 저작 도구이기 때문에 Git이나 Mercurial 같이 리비전 관리가 되어야 하고 변화를 추적하고 롤백할 수 있어야 합니다. 특히 게임 개발 등을 위한 콘월드 작업은 협업에 의해 이뤄지는 경우가 많기 때문에 더욱더 그렇습니다.
제가 제안하는 프로젝트는 이러한 시스템의 일부 핵심 기능입니다. 위에서 가장 자세히 설명한 부분인 일시적 비정합성(이해하기 힘들 수도 있지만 이건 기능입니다)을 구현하게 될 것입니다. 평소에 The Lord of the Rings나 Star Wars 등과 같은 큰 스케일의 장르 문학에 관심이 많았거나 게임의 세계관 설정 등에 관심이 있었던 멘티들이 참여한다면 재미있게 진행할 수 있을 것 같습니다.