프로그래밍 언어는 플랫폼을 채우는 저작 도구다

새 프로젝트를 시작할 때 어떤 언어를 쓸지 정하는 순간, 개발자들은 흔히 두 가지 착시에 빠진다. 하나는 함수형 패러다임이나 타입 시스템의 순수성 같은 '학문적 계보'를 떠받드는 태도이고, 다른 하나는 깃허브 스타 수와 커뮤니티의 열기에 휩쓸려 '유행'을 그대로 따라가는 태도다. 우아한 수학적 증명이나 세련된 문법이 제품의 생존을 보장할 것이라는 기대는 소박하지만, 한편으로는 이해할 만하다. 자신이 경력을 걸고 배운 언어와 그 세계관이 오래 살아남기를 바라는 것은 인지상정이기 때문이다. 그러나 어떤 언어의 성공을 그 언어의 설계 사상만으로 설명하려 하면 곧 벽에 부딪힌다.

원문 필자가 제시하는 관점은 명확하다. 프로그래밍 언어는 본질적으로 '플랫폼을 채우는 저작 도구'라는 것이다. 계산 가능성만 따진다면 고급 언어는 반드시 필요하지 않다. 같은 연산은 기계어나 어셈블리만으로도 표현할 수 있다. 그럼에도 역사는 수많은 고급 언어와 런타임이 등장하는 방향으로 흘렀다. 새로운 하드웨어, 운영체제, 브라우저, 스마트폰이 등장할 때마다 그 표면 위에서 작업할 언어와 도구가 뒤따랐다. 값비싼 문제가 '기계가 계산할 수 있는가'에서 '그 기계 위에 사람들이 얼마나 많은 프로그램을 올릴 수 있는가'로 옮겨갔기 때문이다.

플랫폼의 가치는 그 위에 쌓인 것으로 결정된다

필자는 IBM이 PC 플랫폼의 주도권을 마이크로소프트에 내준 사건을 같은 렌즈로 읽는다. IBM은 PC라는 하드웨어 표준을 만들었지만, 그 위에 쌓인 응용 소프트웨어와 개발자 생태계는 IBM의 기계가 아니라 MS-DOS와 윈도우 API에 묶였다. 호환 PC가 늘어나면서 하드웨어는 범용 부품이 되었고, 개발자가 프로그램을 작성하는 인터페이스를 쥔 마이크로소프트가 플랫폼의 실질적 주인이 되었다. 빈 플랫폼은 아직 제품이 아니다. 그 위에 게임과 생산성 애플리케이션, 콘텐츠가 쌓여야 비로소 사용자가 머무는 세계가 된다.

경제학에서는 함께 소비될 때 가치가 극대화되는 재화를 보완재라 부른다. 플랫폼과 애플리케이션이 바로 이런 관계다. 아무리 최신 음향과 조명을 갖춘 극장이라도 무대에 올릴 것이 없다면 관객은 오지 않는다. 게임 없는 게임기가 값비싼 거실 가구에 불과한 것과 같다. 그래서 플랫폼 운영자에게 개발 도구는 공장 설비에 가깝다. 컴파일러를 팔아 돈을 버는지는 중요하지 않다. 개발자가 더 싸고 빠르게 프로그램을 만들수록 보완재가 늘고 플랫폼 자체의 가치가 오른다. 조엘 스폴스키가 '보완재를 범용재로 만들라'고 표현한 전략은 언어와 SDK에도 그대로 적용된다.

언어가 실제로 줄이는 비용

"어셈블리로도 구현할 수 있다"는 말은 튜링 완전성, 즉 계산 표현력에 관한 답이다. 그러나 사업 일정 안에 만들 수 있는지, 몇 년 뒤 다른 팀이 수정할 수 있는지, 다음 기계로 이식할 수 있는지는 전혀 다른 문제이며 개발 비용과 실용성에 관한 물음이다. 튜링 완전한 언어들은 원리상 같은 연산을 표현할 수 있지만, 그것을 작성하고 검증하고 유지하는 비용은 언어마다 같지 않다. 언어 설계의 차이는 '무엇을 계산할 수 있는가'가 아니라 '비용과 책임을 사람과 컴파일러, 런타임 사이에 어떻게 분배하는가'에서 드러난다.

이 관점에서 언어의 역사는 각 시대에 가장 비쌌던 자원에 대한 응답의 연속으로 읽힌다. 하드웨어가 귀하던 시절에는 실행 효율이 지배적 제약이었지만, 소프트웨어가 커지고 개발 조직이 확대되면서 코드를 쓰고 검증하고 유지하는 인간의 비용이 그만큼 중요해졌다. 고급 언어는 인간의 기억과 주의가 짊어지던 일을 컴파일러, 타입 시스템, 가비지 컬렉터, 라이브러리로 옮긴다. 그런 의미에서 언어는 기계에 명령을 내리는 표기법이자, 인지 비용을 개인에게, 개발 비용을 조직에 배분하는 인터페이스이기도 하다. 앨런 펄리스가 1982년에 남긴 "프로그래밍에 대한 당신의 사고방식을 바꾸지 못하는 언어는 알 가치가 없다"는 경구는 이 배분의 문제를 사고 습관의 차원에서 짚은 것이다.

파이썬과 C가 공존하는 이유

필자는 이 논리를 파이썬에 적용한다. CPython은 C로 구현되어 있고 성능이 중요한 확장 모듈도 C나 C++로 작성되는 경우가 많다. 어차피 C가 실행한다면 처음부터 전부 C로 짜면 되지 않느냐는 반문이 나올 법하다. 그러나 두 언어가 놓인 세계는 다르다. C에서 라이브러리를 직접 호출하는 사람은 포인터, 버퍼 길이, 소유권, 오류 코드, 타입 변환, 링킹과 씨름해야 한다. 파이썬 확장 모듈은 그 작업을 import로 도달할 수 있는 함수와 객체로 바꾼다. 수치 계산의 내부 루프를 C·C++·포트란·BLAS가 처리하더라도, 사용자는 배열을 하나의 값으로 다루고 함수를 조합하며 결과를 노트북에서 바로 들여다본다. 메모리 주소를 훑는 구현의 세계와 행렬·데이터프레임·모델을 다루는 저작의 세계가 한 프로그램 안에 공존하는 셈이다.

결국 언어를 고른다는 것은 유한한 인지 자원을 어디에 쓸지 정하는 선택이다. 저수준 제어에 주의를 집중해야 하는 작업이라면 기계에 직접 명령하는 편이 맞고, 데이터 흐름과 업무 규칙을 모델링하는 데 에너지를 써야 한다면 메모리 관리와 스레드 동기화의 기계적 세부는 런타임의 블랙박스에 위임하는 편이 낫다. 같은 시스템 안에서도 안쪽 층은 기계에 가깝게 두고 바깥 층은 사람이 자주 고치기 쉽게 두는 분업, 곧 C가 계산 비용과 메모리 배치를, 파이썬이 실험 순서와 조립을 맡는 구도가 오래 살아남은 이유가 여기에 있다. 다만 이 글은 특정 언어의 우열을 가리지도, 구체적 데이터로 논증을 뒷받침하지도 않는다. 어디까지나 필자 개인의 렌즈이며, 학문적 분류가 무의미하다는 뜻이 아니라 그것만으로는 언어의 실제 역사를 다 설명할 수 없다는 문제 제기로 읽는 편이 적절하다.