언어의 사양과 구현

BOJ에서 Python으로 문제를 풀다보면 Python3로는 시간 초과로 실패하지만 PyPy3로는 해결에 성공하는 경우를 만나게 된다. 찾아보니 둘 다 Python이라고 한다. 그런데도 둘 사이에서는 메모리 사용량과 속도가 확연히 차이난다.(JIT 컴파일 등의 개념에 대해서는 나중에 포스팅할 기회가 있을 거라고 생각한다.) 왜 이런 시도들이 등장하게 된 걸까?

 

현대 프로그래밍 언어는 사양과 구현이 분리되어 있다. 언어의 사양(specification)이란 문법 따위의 해당 언어가 갖춰야 할 원칙과 요구사항에 대해 서술한 문서고, 언어의 구현(implementation)이란 그러한 사양을 실행 가능한 형태로 현실화한 것이다. 그러한 사양을 전부 지키며 구현하는 구현체가 있는가 하면, 최소한의 요건만을 충족한 채 실험적으로 기능하는 구현체도 있다.

 

처음에는 그런 구분이 없이 그저 난립하였다. 1970년대 미국에서는 PC가 보급되기 시작하면서 국지적인 요구(각 컴퓨터의 프로세서 작동 방식이 다르다거나, 특정 목적에 따른 최적화가 필요했다거나)에 따라 C언어의 수많은 변종이 나타났다고 한다. C언어의 제작자인 데니스 리치(Dennis Ritchie)와 그의 동료 브라이언 커니핸(Brian Kernighan)의 서적인 <The C Programming Language>가 일종의 레퍼런스 역할을 했지만, 다른 컴퓨터에서 작성한 코드나 실행 파일이 호환이 되지 않는 등의 문제가 일어났다. 미국 국립 표준 협회(American National Standards Institute, ANSI)에서 그러한 C를 표준화하고자 했고, 그렇게 탄생한 것이 ANSI C(혹은 C89/C90)이다.

 

이후로 언어의 표준이 되는 사양과 실제적인 구현이 명백히 구분되었다고 본다. 각자의 조건에 따라 마음껏 분화하는 언어 생태계는 매력적이지만, 호환성이라는 이름의 소통 또한 무시되어서는 안 될 지점이다. 사양이라는 명백한 기준선이 제시됨으로써 언어의 가능성은 보다 가지런히 통제되었고, 그 가운데서 여전히 여러 시도들이 이루어졌다. 즉 사양과 구현의 분리는 호환과 혁신 사이의 균형을 잡는 방법론인 셈이다.

 

그리고 조금 다른 이야기인데, 언어의 사양과 구현은 OOP와 닮은 구석이 있다. Java에서의 인터페이스와 구현체의 관계가 떠오른다. 사양은 추상적인 대상이고, 구현은 실제적인 대상이다. 여러 구현이 존재하며, 추상도가 복잡할수록 '더 나은 구현'을 정의하기 어려워진다. 우리는 사양이라는 인터페이스를 통해 언어의 구현체에 쉽게 접근할 수 있다. 그러나 실제 구현에 대해서도 알아야만 한다. 재밌는 지점이다.