managed language와 unmanaged language?

얼마 전 우연히 이런 글을 보게 됐다. 프로그래밍 언어를 managed language와 unmanaged language로 구분한 것인데 그 기준을 garbage collection(a.k.a. GC)을 하는가 아닌가로 잡았다. 난생처음 들어보는 기준이었다. 인생이 힘들어서 노느라 바쁜 사이 뭔가 새로운 논문이 나왔나 하고 찾아봤다.

역시나 이런 경우 대부분 그렇듯이 다른 나라에서는 안 쓰이고 다른 나라에서는 안 쓰이고 우리나라에서 작성된 블로그만 보였다. 그 블로그들이 공통으로 언급하는 것으로 보아 어떤 사람이 유튜브에서 처음 사용한 것 같다. 사실 다른 나라에서는 안 쓰이는 기준이라는 건 별로 중요하지 않다. 그보다 중요한 건 이 managed language라는 것이 잘못 붙여진 이름이라는 것이다.

일단 managed/unmanaged라는 용어 자체가 없는 것은 아니다. 이건 MS 진영에서 만든 용어다. MS는 managed language 대신 managed code라는 단어를 주로 쓰기는 했지만 말이다. MS에서 만든 managed code는 Common Language Runtime(a.k.a. CLR)에서 실행되는 코드를 의미한다. 반대로 CLR에 의존하지 않는 코드를 unmanaged code라고 부른다.

물론 CLR이 제공하는 기능에 GC가 포함되기 때문에 managed code는 GC을 사용한다. 하지만 GC에 초점을 맞추면 안 된다. 여기서 중요한 것은 virtual machine 위에서 코드가 실행된다는 것이다. virtual machine 위에서 돌기 때문에 컴퓨터 아키텍쳐에 따라 새로 컴파일할 필요 없다거나, 다른 머신에서도 같은 동작을 기대할 수 있다는 등 CLR의 장점에 주목해야 한다.

한때는 managed code를 생성할 것을 목표로 설계된 C#, Visual Basic 같은 언어를 managed language라고 부르기도 했지만, 요새는 잘 안 보인다. 안 쓰이게 된 이유는 모르겠다. 그저 C++을 이용해 CLR을 쓸 수 있게 해주는 C++/CLI 같은 프로젝트가 나오면서 구분할 필요가 없어진 것이 이유가 아닐까 추측할 뿐이다. 그렇다면 MS의 managed code는 둘째치고 GC를 사용하는가 아닌가를 기준으로 managed language라는 새로운 기준을 만들면 안 되는 것일까?

결론부터 말하면 오해를 줄 수 있기 때문에 안 된다. GC를 쓰는가 아닌가를 기준으로 언어를 나눌 수는 있다. 이건 의미 있는 기준이다. 하지만 그 기준으로 붙여진 이름이 managed language이면 안 된다. 이 이름은 메모리를 자동으로 관리하는 방법이 GC뿐이라는 오해를 주게 된다.

10년 전에는 GC를 사용하는 언어를 기준으로 managed/unmanaged를 나눠도 이상하지 않았을 것이다. 당시에는 메모리를 자동으로 관리하는 방법이 GC를 쓰는 것밖에 없었기 때문이다. 하지만 2002년 David Walker 교수가 정리한 linear type system이나 affine type system에 대한 개념을 기반으로 리소스를 안전하게 사용하는 방법에 대한 많은 연구가 있었고, 현대 프로그래밍 언어들은 이에 관한 개념을 적극적으로 반영하고 있다. 심지어 C++마저도 말이다. 특히 저 글에서 unmanaged로 구분하고 있는 Rust 같은 경우가 affine type system을 적극적으로 사용하여 메모리를 관리하는 대표적인 언어다. 즉, 이제는 GC가 메모리를 자동으로 관리하는 유일한 방법이 아니다.

분류는 새로운 개념을 쉽게 배우게 해주는 좋은 도구다. 분류라는 것은 추상적이고 많은 개체의 속성을 분명하고 외우기 쉽게 해준다. 하지만 이것은 어디까지나 기준이 명확하고 용어가 올바를 때의 얘기다. 잘못된 기준으로 분류하거나 잘못 도니 이름을 사용하게 되면 오히려 배움에 방해가 될 뿐이다.