프로그래밍 언어의 미래, 루비 2.0
루비의 ‘킬러앱’이라 할 수 있는 ‘루비 온 레일스’의 등장과 함께 루비 프로그래밍 언어가 일반에 널리 소개된 지도 어느덧 4년에 가까운 시간이 흘렀다. 지난 2년 동안 미국에서는 무려 70권이 넘는 루비 책들이 쏟아져 나왔고, 국내에서도 10권 이상의 루비 책이 이미 출간되었거나 출간을 준비 중에 있다. 이 글에서는 오늘날 루비가 주목받는 이유를 분석하고, 루비를 비롯한 프로그래밍 언어의 가까운 미래를 한번 조망해 보기로 한다.
프로그래밍은 꽤나 복잡한 활동인 터라 공동 작업이 무척 어렵다는 특징을 가지고 있다. 소프트웨어 프로젝트의 실패율이 높고 결과물의 만족도가 대체적으로 낮은 이유도 바로 여기에서 찾을 수 있다. 근본적으로 협업이 애매한 활동을 억지로 소단위로 분담해 진행하다 보니 문제가 발생하는 것이다.
예를 들어 소설을 쓰는 일을 한번 생각해 보자. 혹시 두 명 이상의 저자가 공동으로 집필한 소설을 읽어본 일이 있는가? 이런 형태의 소설이 아주 없지는 않지만 매우 드문 것이 사실이다. 이는 아무리 의사소통이 잘되는 두 명의 소설가라 할지라도 소설 한 편을 나눠 쓰면서 등장인물들의 성격과 줄거리의 흐름 등에서 일관성을 유지하기는 어렵기 때문일 것이다. 이처럼 어떤 일들은 공동으로 작업하는 것이 적절치 못하다.
필자는 프로그래밍도 대체적으로 이런 부류에 속한다고 생각한다. 그래서 프로그래밍 업무를 분담할 때는 상대적으로 접합점이 적고 독립적으로 개발될 수 있는 부분을 구분해 내는 일이 무척 중요하다. 만약 코드가 복잡하게 얽힌 부분에서 업무가 여럿으로 나눠진다면 다양한 문제가 야기될 것이다. 코드의 구조는 필연적으로 그것을 개발하는 이들의 업무 분담 구조를 반영하기 때문이다.
새로운 프로그래밍 언어를 설계하는 일은 다양한 소프트웨어 개발 영역 중에서도 유난히 더 공동 작업이 여의치 않아 보인다. 열렬한 팬 층을 확보하고 있는 대부분의 프로그래밍 언어가 (적어도 초창기에는) 단 한 명의 프로그래머에 의해 설계되었다는 사실은 이러한 관찰을 뒷받침해준다. 존 매카시의 리스프, 앨런 케이의 스몰토크, 데니스 리치의 C, 래리 월의 펄, 구이도 반 로썸의 파이썬, 유키히로 마츠모토의 루비 등이 모두 이 경우에 해당된다.
위에 나열된 프로그래밍 언어들은 모두 그것만의 고유한 철학을 가지고 있다. 리스프는 ‘코드는 데이터이다’, 스몰토크는 ‘모든 데이터는 객체이다’, C는 ‘이식성이 뛰어난 어셈블리어’, 펄은 ‘문제를 해결하는 방법은 다양해야 한다’, 파이썬은 ‘문제를 해결하는 방법은 한 가지여야 한다’, 루비는 ‘프로그래밍 언어는 (컴퓨터가 아닌) 인간 중심으로 설계되어야 한다’ 등이다. 그래서 프로그래밍 언어를 선택하는 일은 어떤 면에서 프로그래밍 철학을 선택하는 일이기도 하다.
루비는 직관적이면서도 강력한 기능을 제공하는 덕분에 넓은 스펙트럼의 프로그래머들에게 어필하고 있다. 루비가 직관적이라는 것은 루비의 다양한 고급 기능에도 불구하고 언어의 구문(syntax)이 복잡하지 않고 일관성이 뛰어나다는 의미이다. 필자는 프로그래밍 언어의 직관성은 미래에도 지금의 루비 수준을 크게 벗어나기 어렵다고 생각한다.
프로그래밍 언어는 지난 50여 년 동안 나름대로의 발전을 계속해 왔지만, 기능적인 면만 보면 오히려 거꾸로 퇴보한 경우도 적지 않았다. 예를 들어 루비의 주요 기능인 다이내믹 타이핑, 블록, 가비지 컬렉션, 메타프로그래밍 등은 1960년대에 등장한 리스프가 이미 오래전부터 지원해온 기능들이다. C++와 자바를 통해 대중화된 객체지향 프로그래밍 또한 1970년대 초에 등장한 스몰토크가 주창한 개념을 오히려 절름발이 형태로 구현한 것에 불과했다.
즉, 오늘날에 효용성이 입증된 각종 프로그래밍 개념과 테크닉들은 컴퓨터산업의 초창기에 이미 그 기본 틀이 완성되어 있었다. 이들은 루비에 이르러서야 비로소 하나의 프로그래밍 언어 내에서 일반 프로그래머들이 쉽게 활용할 수 있는 형태로 통합되었다. 이러한 이유로 필자는 프로그래밍 언어의 기능적인 부분 또한 가까운 미래에 큰 발전을 기대하기는 힘들다고 예상한다. 이는 지난 30여 년 간 이뤄진 프로그래밍 언어의 발전이 대부분 앞서 존재했던 개념들의 재발견을 통해 일어났으며, 이제 이러한 재발견의 과정이 거의 마무리되었기 때문이다.
프로그래밍 분야의 이곳저곳에 흩어져 있던 기술과 테크닉, 그리고 노하우들이 비로소 정리되어 한곳에 모아졌다는 사실은 중요한 상징적 의미를 갖는다. 이는 앞으로의 프로그래밍 혁신이 언어가 아닌 다른 영역으로 옮겨갈 개연성이 높다는 것을 의미한다.
앞서서 필자는 프로그래밍이 기본적으로 공동 작업에 적합하지 않은 활동이라고 설명했다. 그럼에도 불구하고 대규모의 프로그래밍 인력이 투입되는 소프트웨어 개발 프로젝트는 끊이지 않는데, 이는 프로젝트 기간을 단축시키고자 하는 강력한 비즈니스 인센티브가 존재하기 때문이다. 프로젝트 관리자는 1명의 프로그래머가 12개월을 소요할 프로젝트에 4명의 프로그래머를 투입해 전체 일정을 3개월로 줄이고 싶어 한다. 문제는 이처럼 일정을 단축하기 위해 프로그래밍 업무를 분담해 프로젝트를 진행하는 것이 말처럼 간단치 않다는 데에 있다. IBM에서 OS/360 운영체제 개발 프로젝트를 이끌었던 프레데릭 브룩스는 다음의 비유를 통해 이 문제의 본질을 지적하고 있다.
"아이를 낳는 일에는 9개월의 시간이 걸린다. 아무리 많은 여자들이 동원된다 하더라도." - The Mythical Man-Month (Addison-Wesley, 1975)
이는 다소 과장된 비유이지만, 많은 종류의 프로그래밍 작업은 실제로 더 작은 업무 단위로 쪼개는 것이 불가능하거나 아니면 적어도 그것이 실용적이지 못하다. 이런 업무를 억지로 분담해 개발을 진행하면 일정의 지연, 버그의 증가, 코드 가독성의 저하 등의 문제를 초래할 뿐만 아니라 때때로 프로젝트를 실패로 이끌기도 한다.
바로 여기에 소프트웨어 개발 프로젝트의 딜레마가 숨어 있다. 필요한 소프트웨어를 적시에 개발하기 위해서는 공동 작업을 통해 개발 속도를 높여야 하지만, 프로그래밍에 있어서 공동 작업은 프로젝트 실패율을 높이는 경향이 있다. 따라서 프로젝트의 성공률을 높이고 싶다면 프로젝트에 참여하는 프로그래머의 수를 최소화해야 한다. 프로그래머의 수를 늘릴 수 없다면 대안은 한 가지이다. 프로그래머 한 사람 한 사람의 프로그래밍 생산성을 높여야만 한다.
프로그래머의 생산성을 높이는 가장 효과적인 방법은 좀 더 강력한 프로그래밍 언어를 사용하는 것이다. 실제로 어셈블리어에서 C 언어로의 전환은 프로그래밍 생산성을 획기적으로 높였고 C 언어에서 자바로의 전환 또한 비슷한 효과를 가져왔다. 많은 프로그래머들이 마치 성배를 찾듯이 ‘궁극의 프로그래밍 언어’를 찾아 헤매는 것도 바로 이러한 이유 때문이다.
루비 또한 이전의 언어들과 마찬가지로 프로그래밍 생산성을 획기적으로 높여준다. 하지만 필자는 루비의 등장이 프로그래밍의 역사에서 일종의 특이점(지속적으로 발전하던 기술이 어느 시점에서 갑작스럽고 근본적인 변화를 초래하는 현상)으로 기록될 가능성이 크다고 생각한다. 루비는 한 명의 프로그래머가 비교적 짧은 시간 안에 충분히 유용한 소프트웨어를 개발하는 것을 가능하게 해주기 때문이다. 여기에서 ‘비교적 짧다’거나 ‘충분히 유용하다’ 등은 물론 주관적인 표현이다. 하지만 과거의 소프트웨어 개발 프로젝트에서 공동 작업이 필수적이었던 이유는 개별 프로그래머의 프로그래밍 생산성이 형편없이 낮았기 때문이다. 한사람의 프로그래머가 의미 있는 규모의 소프트웨어를 단 기간에 개발하게 된다면 어떤 현상이 벌어질까?
우선 프로그래밍 팀의 평균 인원수가 줄어들 것이다. 장기적으로는 프로그래밍 회사의 크기도 작아지지 않을까 싶다. 우리보다 시장의 변화가 조금 더 빠른 미국에서는 지난 2년간 IT 분야에서의 창업이 빠르게 증가하고 있다. 특히 흥미로운 것은 두세 명의 창업자로 구성된 소규모 벤처의 수가 늘어났다는 점이다. 이들 벤처 회사들이 앞도적인 비율로 루비를 선택하고 있는 것이 단순히 우연만은 아닐 것이다.
하지만 루비의 발전은 여전히 현재진행형이다. 루비의 성공은 다소 갑작스럽게 일어났기에 루비에는 보완되어야 할 부분이 일부 남아있다. 직관적인 구문과 강력하고 사용이 편리한 기능이 루비의 강점이라면 루비의 약점은 그 구현에 있다. 루비의 창시자인 마츠모토는 독보적인 프로그래밍 언어 설계자였지만 전문적인 C 프로그래머는 아니었던 듯하다(루비는 현재 C 언어로 구현되어 있다). 이런 이유로 루비의 비판자들은 종종 루비의 실행 속도가 느리다는 점을 지적하곤 한다.
루비가 처음으로 널리 쓰였던 영역은 웹 프로그래밍이었다. 웹 애플리케이션에서 성능의 병목현상은 순수 실행 속도보다는 I/O에 집중되므로 지금까지 루비의 성능은 커다란 문제는 아니었다. 게다가 루비는 실행 속도가 중요한 부분만을 C로 개발할 수 있게 하는 C API를 제공해 왔다. 하지만 루비가 점점 더 다양한 분야에서 활용되기 시작하면서, 루비의 성능 문제를 근본적으로 해결할 것을 요구하는 목소리도 점점 커져만 갔다.
루비 2.0
루비의 성능을 개선시켜 달라는 요청에 오래도록 시달렸던 마츠모토는 2년 전에 차세대 루비의 개발을 도쿄대학교의 사사다 코이치에게 위임했다. 코이치는 지난 2년 동안 루비 1.9 버전을 자바와 같은 바이트 코드/가상머신 기반으로 개발해 왔다. 루비 1.9는 아직 베타 단계에 머물러 있지만 기존의 루비 해석기와 비교해서 이미 괄목할 만한 성능 개선을 이뤄내고 있다.
하지만 루비 커뮤니티에서는 기존의 오픈소스 프로젝트에서는 찾아보기 힘들었던 현상이 벌어지고 있다. 차세대 루비 개발에 여러 개의 팀이 경쟁적으로 뛰어들고 있는 것이다. 이들은 모두 독자적으로 차세대 루비 가상머신을 개발하고 있다. 이러한 현상은 과거에 루비 1.9의 개발이 더뎠던 점, 루비 1.9 개발 프로젝트가 언어 장벽으로 인해 일본 외부의 프로그래머들에게는 접근이 쉽지 않은 점, 그리고 언어 문제 등으로 초래된 마츠모토의 리더십 부재가 루비 플랫폼에 대한 주도권 경쟁으로 이어지는 상황 등이 종합적으로 작용한 결과로 보인다.
이들 가운데 주요 프로젝트로 이반 피닉스의 Rubinius, 썬마이크로시스템즈의 JRuby, 마이크로소프트의 IronRuby, 젬스톤의 MagLev 등이 있다. 루비 2.0의 자리는 코이치의 루비 1.9가 차지하게 될 개연성이 가장 높지만, 미국 내 루비스트들의 지지를 받고 있는 Rubinius와 스몰토크 환경에서 축적된 기술력을 가진 젬스톤의 MagLev 등도 만만치 않은 경쟁 상대이다. 썬의 JRuby와 마이크로소프트의 IronRuby는 각각 자바 플랫폼과 닷넷(.Net) 플랫폼에 종속된 솔루션으로 루비 2.0 후보가 되기는 어려울 전망이다.
어쩌면 이런 현상은 종전의 프로그래밍 언어 간의 경쟁이 이제는 하나의 언어 안에서의 가상머신 구현 경쟁으로 옮겨가는 것일지도 모른다. 결과야 어찌됐든 이는 그만큼 많은 이들이 루비에 미래를 베팅하고 있다는 것을 보여주며, 이런 경쟁들로 인해 루비는 더욱 더 강력한 개발 플랫폼으로 진화해 나갈 것이다.
웹 개발 프레임워크
최근에는 레일스에 이어 다양한 루비 웹 개발 프레임워크들이 속속 발표되고 있다. 이들 중 비교적 이름이 알려진 프레임워크에는 Merb, Camping, Nitro/Og, Ramaze, Sinatra 등이 있다. 이들 프레임워크는 각각 조금씩 다른 철학과 지향점을 가지고 있지만 이처럼 다양한 실험이 커뮤니티 내에서 일어나고 프레임워크 선택의 폭이 넓어지는 일은 환영할 만한 사건이다. 이들 중 Merb는 Rubinius의 스폰서이기도 한 Engine Yard의 에즈라 지그문토즈가 주도하는 프로젝트로, 레일스 외에 가장 주목받는 프레임워크이다.
이처럼 다양한 루비 기반의 웹 개발 프레임워크들이 있지만, 루비로 웹 개발 프레임워크를 직접 개발하는 것도 도전해볼 만한 일이다. 실제로 필자가 운영하는 웹 프로그래밍 전문회사인 페퍼코드에서는 모든 프로젝트에서 자체적으로 개발한 프레임워크를 사용하고 있는데, 프레임워크의 모든 부분을 회사의 필요에 맞춰 설계할 수 있다는 것도 꽤나 매력적인 일이다.
메타프로그래밍
메타프로그래밍이란 프로그래밍을 통해 코드 작성을 자동화하는 프로그래밍 기법이다. 메타프로그래밍은 리스프 등의 언어에서 오래 전부터 지원되어 왔지만 그 사용법이 까다로워 그동안 널리 사용되지는 않았다.
루비의 메타프로그래밍은 비교적 직관적인 특성을 지녀 메타프로그래밍을 널리 확산시켰다는 평가를 받고 있으며 특히 레일스 등의 프레임워크 개발에 많이 사용되고 있다. 메타프로그래밍에 관심이 있다면 필자가 IBM 디벨로퍼웍스에 연재 중인 ‘루비 메타프로그래밍’의 내용을 참고하길 바란다.
프로토타이핑
딱딱한 하드웨어와 구분해 소프트웨어라는 이름이 붙기는 했지만, 실제의 소프트웨어는 생각만큼 유연하지 못하다. 아니 유연하지 못한 정도가 아니라 고집이 세고 완고하다는 표현이 더 어울릴 것이다. 소프트웨어 시스템에 간단한 기능을 추가하거나 변경하는 일은 종종 놀라울 만큼 오랜 시간을 잡아먹곤 한다.
이렇게 완고한 소프트웨어이기에 한번 개발을 마치고 나면 결과물을 크게 변경하는 일은 가급적 자제하는 것이 좋다. 따라서 처음부터 완벽하게 계획을 세우는 것이 중요하다. 하지만 처음부터 완벽한 계획을 세우는 것 역시 그리 쉬운 일은 아니다. 이 문제를 해결하기 위해 소프트웨어를 개발할 때는 프로토타이핑이란 테크닉이 종종 사용된다. 프로토타이핑이란 실제의 개발 언어보다 좀 더 하이레벨의 언어를 사용해 실제로 완성될 소프트웨어의 골격만을 대강 한번 개발해 보는 일이다. 이런 과정을 통하면 시행착오를 줄일 수 있으므로 프로토타이핑은 소프트웨어 개발에서 종종 활용되는 테크닉이다.
루비는 비교적 하이레벨의 언어이기 때문에 프로토타이핑 작업에도 매우 적합하다. 따라서 다른 제약 조건으로 인해 루비가 아닌 다른 언어로 프로젝트를 진행한다 하더라고 프로토타이핑 단계에서는 루비의 사용을 고려해 보자.
임베디드 프로그래밍
임베디드 프로그래밍에서 가장 널리 사용되는 프로그래밍 언어는 C이다. 일반 컴퓨터와는 달리 임베디드 시스템에 사용되는 CPU는 그 종류가 다양하고 성능에 제약이 있는 경우가 많다. 따라서 임베디드 프로그래밍에 이식성이 우수한 로우레벨 언어인 C가 주로 사용되는 것은 어찌 보면 당연할 것이다. 하지만 임베디드용 CPU의 성능도 지속적으로 발전하고 있고 표준화 노력이 계속되고 있으므로 가까운 미래에는 임베디드 시스템에서도 루비와 같은 하이레벨 프로그래밍 언어가 보편화될 것이다.
실제로 스마트폰용 전용 운영체제인 심비안 OS에서는 이미 2년여 전부터 루비를 탑재해 왔고(심비안 OS의 루비 SDK 페이지), 미국 브리그햄 대학교의 정보통신학과 학장인 헵스 교수는 로봇 제작에서 ‘로봇 제작 랩에서 루비를 프로그래밍 환경으로 활용하기’란 주제로 논문을 발표하기도 했다.
기술 습득을 위한 조언
이미 다양한 프로그래밍 언어를 익혀본 경험이 있다면, 루비의 창시자인 유키히로 마츠모토가 데이빗 플래너건과 공동 집필한 『The Ruby Programming Language』(O'Reilly, 2008)를 권하고 싶다. 만약 튜토리얼 형식의 길라잡이를 원하거나 레일스 프레임워크를 익혀보고 싶다면 필자의 책인 『웹 개발 2.0 루비 온 레일스』(에이콘출판사, 2007)』를 참고해도 좋을 것이다.(참고로 이 책의 튜토리얼을 따라하기 위해서는 레일스를 설치할 때 구 버전인 1.2.2를 설치해야 한다).
필자의 경험상 프로그래밍 언어를 익히는 최선의 방법은 실력 있는 다른 프로그래머들이 작성한 코드를 많이 접하는 것이다. 루비의 소스 코드는 간결하고 함축적이므로 소스 코드를 읽는 일이 다른 프로그래밍 언어에 비해 수월한 편이다. 레일스 등을 포함한 각종 루비 라이브러리의 소스 코드를 뜯어보는 데 취미를 붙인다면 오래 지나지 않아 베테랑 루비 프로그래머가 되어 있을 것이다.
마지막으로 루비를 익히고 사용하는 과정에서 얻게 된 노하우, 팁 등을 블로그나 커뮤니티 등을 통해 다른 이들과 공유할 것을 부탁하고 싶다. 안타까운 일이지만 외국에 비하면 한국의 웹은 프로그래밍 정보와 지식의 양에 있어 아직 부족한 점이 많다. 조금 더 앞서서 공부하고 실력을 쌓은 이들이 자신의 지식을 남과 공유한다면 오픈소스를 비롯한 한국의 프로그래밍 산업이 그만큼 더 경쟁력을 갖게 되지 않을까?
노트: 이 글은 마이크로 소프트웨어 2008년 6월호에 "특집 3부: 프로그래밍 언어의 미래, 루비 2.0"이라는 제목으로 실렸습니다.
