한빛출판네트워크

제공 : 한빛 네트워크
저자 : Kurt Cagle
역자 : 이대엽
원문 : Are Computer Languages Irrelevant?

이따금 나는 컴퓨터 프로그래밍의 드넓고 다양한 광경들을 바라볼 때마다 여러 개념들에 혼란을 느끼기 보다는 오히려 그것들을 즐기곤 하는데, 어느날 클라우드 컴퓨팅(cloud computing)과 웹 서비스(web services)를 비롯하여 우리 같은 프로그래머들을 깊게 빠져들게 하는 코드에 관해 생각하고 있을 때 “컴퓨터 언어는 과연 무의미한가?”라는 물음이 문득 들었다.

프로그래머들로 가득한 방에 “최고의 컴퓨터 언어는 어느 것인가”라는 질문이 던져진다면, 분명 여러분이 갖가지 언어 버전으로 세분화하지 않는 한 그 방에서 살아남기 위해 똑같이 피로 얼룩지고 상처입은 프로그래머 몇 명만이 남게 되는 결과를 초래할 것이다. 하지만 나는 아직까지도 그와 같은 특정한 언어 자체가 정말로 그만큼 중요한 것인지에 대해서는 의아할 따름이다.

한번 생각해 보자. 나는 업무 시간의 상당부분을 브라우저 안에 들어있는 웹 윈도 패널을 뚫어져라 쳐다보는데 보낸다. 지금은 그 브라우저가 C++로 작성되어 있을지도 모르지만(5년 전까지만 해도 확실히 그랬을 것이다), 점차 자바스크립트나 파이썬, 자바로 작성되고 있는 것 같다. 이런 언어들이 더 빨라서 그런 것은 아니며(자바스크립트에서 매우 놀라울 만큼의 성능 개선이 있다 하더라도, 아직까지는 10배 내지 20배 정도의 성능 차이를 보인다), 단순히 사용하기가 대개 더 쉽기 때문이다.

다시 말하면, 이것은 메모리 관리나 가비지 컬렉션(garbage collection)을 사용자가 섬세하게 제어할 수 있는 언어를 사용함으로써 얻게 되는 이점이 다른 언어의 단순함에 의해 상쇄되거나, 또는 스크립트 언어를 사용함으로써 얻게 되는 효용성이 코드 자체의 비효율성 보다는 개발 생산성과 애플리케이션의 유지보수 측면에서 일반적으로 훨씬 더 높기 때문이다. 따라서 성능 요인은 사실상 요인으로 작용하지 않는 셈이다.

성능이 중요한 요인임을 보여주는 이와 반대되는 사례도 분명 많지만, 시간이 흐를수록 그와 같은 사례는 대역폭이나 네트워크 지연시간과 같은 요소에 비해 점점 보기 드물어지고 있다. 오늘날 작성되는 대부분의 데스크톱용 애플리케이션은 웹에 직접 접근하여 상태를 갱신하거나, 개체를 저장하거나 서버나 사용자의 유효성을 보증함으로써 다른 이들과 통신한다. 이 같은 “웹이 가능한(web-enabled)” 애플리케이션의 상당수는, 비록 자체적으로 지역화된 데이터 저장소를 갖추곤 있지만 브라우저 안에서만 실행되도록 작성된 진정한 “웹 애플리케이션(web-app)”으로 간헐적으로 대체되고 있는 중이다.

컴퓨팅의 역사는 추상화(abstraction)와 가상화(virtualization)의 역사다. 대다수의 현대 프로그래머들은 아마 초창기 프로그램이 완전히 선형적으로 구성되어 있었다는 점을 알지 못할 것이다. 초기에는 절차적인 모듈의 개념이 코드 중복을 최소화하고, 주어진 일련의 명령(instruction)과 이름(그리고 거기엔 입력과 출력 매개변수를 나타내는 일련의 슬롯도 있었다)을 연관짓기 위한 편의성 연산에 불과했다.

객체지향 프로그래밍은 이 같은 과정의 다음 단계로 자주 여겨지곤 하는데, 대부분의 사람들은 실제로 “다음 단계”가 공통된 통합 표준에 따라 구체적인 특성과 메서드를 노출하는 개별 모듈화 컴포넌트의 배포라는 사실을 알아차리지 못하곤 한다. 이런 점에서 비추어 보면 아마 비주얼 베이직이 C++ 보다 더 중요했을 것이다. 비주얼 베이직은, 만약 여러분이 그와 같은 공통된 틀을 만든다면 그것을 여러분이 작성한 컴포넌트나 “기성(out-of-the-box)” 컴포넌트만이 아닌 어느 누가 작성한 컴포넌트와도 연동시킬 수 있다는 원칙을 가장 분명하게 확립했기 때문이다. 따라서 소프트웨어의 컴포넌트화(componentization)는 하나의 가상화 계층으로 볼 수 있다.

HTML은 오늘날까지 이러한 개념을 아마 다른 어떤 것보다도 더 잘 구체화하는데 이바지했다. HTML 문서는 그것이 웹 페이지로 실현되기 전까지는 HTML 문서에 관해서는 본질적으로 마법과도 같은 일은 아무것도 일어나지 않는다. HTML 문서는 순수한 추상화이며, 그와 같은 추상화를 어떤 실체로 바꾸는 메커니즘은 바로 브라우저를 작동시키는 특정한 컴퓨터 언어이다.

하지만 아직까지 이러한 HTML 페이지가 가진 불가사의는 대개 HTML 페이지가 가진 매우 사소한 불일치 현상을 제외하면 동일한 문서는 렌더링과 기능을 구현하는데 어떤 언어를 사용하든 대체로 같은 방식에 따라 페이지로 렌더링될 것이라는 점이다. 그렇게 되는 이유는 물론 사람들이 이와 같은 문서의 행위에서 예상되는 바를 표준화했기 때문이며, 렌더링 언어는 그 자체만으로는 대부분 무의미하다. 여기서 말하는 바는 이렇게 하는 것이 추세가 될 것 같다는 점을 나타내고자 하는 것일 뿐이지, 아직까지 모든 브라우저에서 이러한 표준을 준수하고 있지 않다는 점을 말하고자 하는 것이 아니다(그렇더라도 대부분 의미있는 시도는 해보고 있다).

이와 같은 표준 준수는 공통 자바스크립트 프레임워크를 이용하여 구축되어, 그에 따라 호스트 미디어 “플러그인”이 되어버린 AJAX 컴포넌트의 급부상에서도 찾아볼 수 있다. 중요한 사실은 10년 전 수많은 애플리케이션에 널리 사용되던 바이너리 플러그인 아키텍처가 종종 효율성 보다는 소유자의 제한 때문에 도저히 다른 방식(예를 들면, 비디오 및 오디오 컴포넌트, 플래시와 같은)으로는 렌더링할 수 없는 부분에만 사용되고 있다는 것이다. 다음 세대의 AJAX는 거의 확실히 플래시가 그 분야에서 점하고 있는 우위에 도전할 것이며, 갖가지 플래시 지향 컴포넌트 프레임워크(OpenLaszlo와 같은) 또한 동일한 행위를 제공하기 위해 AJAX 프레임워크를 구축하고 있다.

운영체제의 가상화도 일어나고 있다. 지난 10년간 작성된 대부분의 언어는 기저 시스템과 직접적으로 소통하지 않는다. 대신 그런 언어는 최하위 수준에서 수행되는 가상 머신(virtual machine)을 실행시킬 의도로 작성된 것이다. 마찬가지로 웹 브라우저도 이러한 전략을 활용하고 있으며, 웹 브라우저는 추상화 측면에서 점차 운영 체제와 구별하기 힘들 정도가 되어가고 있으며, 여러 플랫폼에 걸쳐 형성되는 추상화를 지원하기 위해서도 그래야 한다.

웹 서비스는 이러한 가상화의 또 다른 측면을 나타내며, 이 경우 네트워크 기반의 컴포넌트화를 의미한다. 지역화된 클라이언트 컴포넌트는 데이터 추상화로서 서버와 통신하는 애플리케이션에 포함된다. 물론 매쉬업도 이러한 원칙을 매우 명백하게 포함한 것이나, 컴포넌트화는 서버 컴포넌트를 통해서도 일어나 10여년 전 웹 개발의 무미건조한 “스크립트”를 선언적인 추상화(declarative abstraction)에 의해 종종 표현되기도 하는, 특징적인 컴포넌트로 대체하고 있다. 클라이언트와 서버를 통틀어 컴포넌트화는 내부 컴포넌트 코드와 접착제 코드(glue code)간의 경계를 명확히 구분짓는다. 컴포넌트가 급격히 늘어나면(그리고 이러한 컴포넌트의 연합을 통합하기 위한 표준도), 그에 따라 명령형 접착제 코드(imperative glue code)는 사라지지만, 때때로, 틀림없이, 그 방향은 확실히 있다. 컴포넌트 표준화를 통해 해당 컴포넌트를 작성한 언어는 해당 컴포넌트 자체의 기대되는 행위에 비해 덜 중요해지고, 이로써 컴퓨터 언어는 무의미해진다. 이와 동일한 과정의 가상화가 하드웨어 차원에서도 일어나고 있으며, 이는 클라우드 컴퓨팅의 원칙에도 매우 중요하다. 각 머신 인스턴스(machine instance)에 대해 하이퍼바이저(역자주: hypervisor, 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 가상 플랫폼)를 생성하면, 몇 분 이내에 가상 컴퓨터를 만들어 낼 수 있으며, 각각의 가상 컴퓨터는 자체적으로 적재된 것뿐만 아니라, 많은 경우 실행되는 애플리케이션도 포함하는 별도의 운영체제를 실행하게 된다.

머신(machine), 즉 하드웨어는 점점 더 무의미해지고, 추상화되어 간다. 따라서 개발자나 IT 관리자인 여러분은 물리적인 머신이 아닌 가상화된 머신에 관해 훨씬 더 관심이 있을 것이다. 이미 가상화 시장에서는 표준화가 일어나고 있으며, 이러한 표준화는 어떤 가상 컴퓨터가 X라는 회사의 메모리와 프로세싱 시스템을 이용하면서 그 회사의 인프라에서만 만들어 지는 것이 아니라, 또 다른 Y라는 회사의 인프라에서도 마찬가지로 동일한 웹 인터페이스를 활용하면서 그 회사에서 만들어질 수 있으면서, 동시에 최종 사용자에게는 X 회사에서 Y회사로 이전하는 것이 보이지 않게 만들어 주는 표준을 제공해 준다.

만약 이러한 모델이 익숙하게 들린다면, 그건 바로 이 모델이 공공 전력 설비에서 잉여 전력과 다른 곳의 전력을 끌어오는 일을 처리하는데 사용하고 있는 모델과 기본적으로 동일한 것이기 때문이다. 이를 통해 시스템 인스턴스를 생성하는 것이 가능해지고, 수요의 증감에 따라 충분히 이용되지 않는 컴퓨터 팜은 효율성을 제고할 수 있다.

하지만 이와 관련해서 여전히 기억해 둘 점은 이러한 10년의 시간을 거친 다음에는, 명령형 언어 A 대(對) 언어 B와 같이 지엽적이고 특화된 “일회성” 사례들도 언어가 아닌 행위가 표준화된, 표준화된 추상 선언적 설명(standardized abstract declarative description)으로 인해 사라질 거라는 점이다.

물론 이것은 언어가 “사라지는” 것을 의미하지는 않는다. 선언적인 상태 다이어그램(declarative state diagram)은 그와 같은 다이어그램을 어떤 정형적인(명령형) 행위로 바꾸는 능력 없이는 아무런 의미가 없다. 그러나 이러한 행위를 구현하는데 사용되는 특정 언어는 이러한 체계에 대한 전체적인 논의와는 무관하다.

이는 명백히 바로 가까운 미래의 기술 출판(마찬가지로 개발, 구직, 대학 커리큘럼, IT 전략에도)과도 관련이 있다. 컴포넌트화는 그 자체의 특성상 대규모의 유동적인 통합자(integrationist) 인력(매쉬업 예술가로도 알려진)과 함께 모든 수준의 추상화에서 컴포넌트 개발과 관련된 써드파티 산업이 존재하리라는 것을 의미한다.

뿐만 아니라 산업이 더 컴포넌트화되고 컴포넌트화 계층의 추상화 정도가 높아지면 높아질수록 이러한 통합자들은 굳이 프로그래머일 필요가 없어질 것이며, 대신 저마다 종사하고 있는 산업의 도메인 전문가이기도 한 “파워 유저(power user)”가 그 자리를 차지하게 될 것이다. 통합자들은 자신의 도메인에 특화된 언어(domain specific language)를 알아야 할 것이다. 이러한 도메인에 특화된 언어는 대부분 XML로 표현되겠지만, 그와 같은 마크업 언어로 드러나지 않는 경우도 있을 것이다. 대부분의 XML 컴포넌트 모델은 혼합되는 경향이 있는데, 이것은 그와 같은 모델들이 대개 얼마든지 “드래그 앤 드롭” 그래픽 UI나 폼/에디터를 통해 깔끔하게 렌더링될 수 있음을 의미한다. 따라서 여전히 사용자가 특정 도메인 모델을 알아야 할 필요는 있지만(사실 훨씬 더 필요하지만), 사용자가 프로그래밍 수준의 모델의 모델을 이해할 필요는 계속해서 줄어들 것이다.

이렇게 함으로써 장기적으로 얻게 되는 효과는 프로그래머 대신 “설계자”가 계속해서 성장하는 것이나, 애초부터 저마다의 도메인을 모델링하는 존재론자(데이터 모델러)의 급부상도 보게 될 것이다. 대부분의 현존하는 IT 업체에서 이러한 역할에 가장 근접한 것은 애플리케이션 아키텍트이지만, 아키텍처의 결과로 만들어지는 것은 코드 API가 아닌 도메인에 특화된 언어이다(비록 도메인에 특화된 언어가 본질적으로 다른 것의 초기 형태라고 주장할 수도 있지만 말이다). 이것은 분명 현재도 진행되고 있는 과정이다. 루비와 자바의 차이점이 오늘날 중요한가? 그렇다. 그런 차이점이 5년전 만큼이나 중요한가? 아니다. 그런 차이점이 지금부터 5년이 지난 후에는 덜 중요해질까? 거의 확실히 그렇게 될 것이다.

분산 서비스(distributed service), 컴포넌트화와 가상화는 프로그래밍의 신흥 세대가 가진 특징이다. 클라우드 컴퓨팅이 확실히 이러한 현상의 일부인 반면, “클라우드(cloud)”는 단순히 서버 계층만을 말하는 것이 아닌 모바일 기기와 랩톱, 지능형 개체(intelligent object)로 이루어진 끊임없이 변화하는 바다이기도 하다. 이러한 기기와 개체들이 클라우드를 비롯한 서로 다른 것과 통신하기 위해서는 특화된 컴퓨터 언어를 만드는 것은 무의미할뿐더러 잠재적으로 문제가 된다. 이것은 통신 메커니즘이 표준 프로토콜이기 때문이다. 그리고 나서 이를 통해 소프트웨어 개발 방법론이 만들어지고, 그리고 그때부터 산업계에서는 이러한 기술을 이용하게 된다.