Rusty Python

파이썬은 C와 C++를 이용해서 확장 라이브러리를 만들 수 있어요. C나 C++로 파이썬 함수를 작성하는 거죠. JNI(Java Native Interface)와 비슷한 개념이라고 볼 수도 있겠네요. 네이티브 코드로 만든 파이썬 함수는 일반 파이썬 모듈처럼 임포트한 뒤 바로 사용할 수 있습니다. 그런데 여기서 궁금증이 생겨요. 파이썬만 써서 프로그래밍할 수 있는데 어째서 C로 프로그램을 짜야 하는 걸까요?

한 가지 당연한 이유는 C/C++ 라이브러리를 사용할 때 필요하기 때문입니다. 물론, ctypes​의 힘을 빌리면 파이썬만 사용해서 C 라이브러리 함수를 호출하는 것도 가능합니다만… libc​의 함수 한두개만 사용한다면 모를까, Qt 같은 덩치 큰 라이브러리를 파이썬에서 사용하고자 할 때는 너무나도 번거롭죠. 만약 C로 파이썬을 확장한다면 Qt같은 덩치 큰 라이브러리도 얼마든지 파이썬으로 끌어와 쓸 수 있습니다. 거기다 타입 변환 걱정 없이 파이썬에 맞게 세세한 부분을 조정할 수도 있으니 훨씬 효율적이죠!

또 다른 이유는 파이썬의 속도​입니다. 파이썬은 인터프리터 언어다 보니 CPU에서 바로 실행될 수 있는 C보다 느립니다. 거기다 타입 체크도 필요하나 C보다 몇 배는 느릴 수밖에 없죠. 그 예시로, 데비안의 Computer Language Benchmark Game에서 이진 트리를 탐색하는 프로그램을 찾아볼게요. 여러 버전의 프로그램이 올라와 있지만, 파이썬과 C 모두 코드가 읽기 쉽고 적당히 병렬 처리를 하는 프로그램으로 가져와 봤어요.

  /* The Computer Language Benchmarks Game
   * https://salsa.debian.org/benchmarksgame-team/benchmarksgame/
   *
   * Contributed by Eckehard Berns
   * Based on code by Kevin Carson
   * *reset*
   */

  #include <stdlib.h>
  #include <stdio.h>
  #include <pthread.h>

  typedef struct node {
       struct node *left, *right;
  } node;

  static node *
  new_node(node *left, node *right)
  {
       node *ret;

  ret = malloc(sizeof(node));
  ret->left = left;
  ret->right = right;

  return ret;
  }

  static long
  item_check(node *tree)
  {
       if (tree->left == NULL)
            return 1;
       else
            return 1 + item_check(tree->left) +
                 item_check(tree->right);
  }

  static node *
  bottom_up_tree(int depth)
  {
       if (depth > 0)
            return new_node(bottom_up_tree(depth - 1),
                            bottom_up_tree(depth - 1));
       else
            return new_node(NULL, NULL);
  }

  static void
  delete_tree(node *tree)
  {
       if (tree->left != NULL) {
            delete_tree(tree->left);
            delete_tree(tree->right);
       }
       free(tree);
  }

  struct worker_args {
       long iter, check;
       int depth;
       pthread_t id;
       struct worker_args *next;
  };

  static void *
  check_tree_of_depth(void *_args)
  {
       struct worker_args *args = _args;
       long i, iter, check, depth;
       node *tmp;

       iter = args->iter;
       depth = args->depth;

       check = 0;
       for (i = 1; i <= iter; i++) {
            tmp = bottom_up_tree(depth);
            check += item_check(tmp);
            delete_tree(tmp);
       }

       args->check = check;
       return NULL;
  }

  int
  main(int ac, char **av)
  {
       node *stretch, *longlived;
       struct worker_args *args, *targs, *hargs;
       int n, depth, mindepth, maxdepth, stretchdepth;

       n = ac > 1 ?
atoi(av[1]) : 10;
       if (n < 1) {
            fprintf(stderr, "Wrong argument.\n");
            exit(1);
       }

       mindepth = 4;
       maxdepth = mindepth + 2 > n ?
mindepth + 2 : n;
       stretchdepth = maxdepth + 1;

       stretch = bottom_up_tree(stretchdepth);
       printf("stretch tree of depth %u\t check: %li\n", stretchdepth,
              item_check(stretch));
       delete_tree(stretch);

       longlived = bottom_up_tree(maxdepth);

       hargs = NULL;
       targs = NULL;
       for (depth = mindepth; depth <= maxdepth; depth += 2) {

            args = malloc(sizeof(struct worker_args));
            args->iter = 1 << (maxdepth - depth + mindepth);
            args->depth = depth;
            args->next = NULL;
            if (targs == NULL) {
                 hargs = args;
                 targs = args;
            } else {
                 targs->next = args;
                 targs = args;
            }
            pthread_create(&args->id, NULL, check_tree_of_depth, args);
       }

       while (hargs != NULL) {
            args = hargs;
            pthread_join(args->id, NULL);
            printf("%ld\t trees of depth %d\t check: %ld\n",
                   args->iter, args->depth, args->check);
            hargs = args->next;
            free(args);
       }

       printf("long lived tree of depth %d\t check: %ld\n", maxdepth,
              item_check(longlived));

       /* not in original C version: */
       delete_tree(longlived);

       return 0;
  }

먼저 C 프로그램입니다. 해당 프로그램은 깊이 21의 이진 트리를 모두 탐색하는데 18.32초가 걸렸어요. 현재 가장 빠른 C 프로그램이 깊이 21의 이진 트리를 탐색하는 데 3.59초가 걸렸다는 점을 생각하면 이 구현체도 가장 빠른 구현체라고 볼 수는 없겠네요.

# The Computer Language Benchmarks Game
# https://salsa.debian.org/benchmarksgame-team/benchmarksgame/
#
# contributed by Antoine Pitrou
# modified by Dominique Wahli and Daniel Nanz
# modified by Joerg Baumann

import sys
import multiprocessing as mp


def make_tree(d):
    if d > 0:
        d -= 1
        return (make_tree(d), make_tree(d))
    return (None, None)


def check_tree(node):
    (l, r) = node
    if l is None:
        return 1
    else:
        return 1 + check_tree(l) + check_tree(r)


def make_check(itde, make=make_tree, check=check_tree):
    i, d = itde
    return check(make(d))


def get_argchunks(i, d, chunksize=5000):
    assert chunksize % 2 == 0
    chunk = []
    for k in range(1, i + 1):
        chunk.extend([(k, d)])
        if len(chunk) == chunksize:
            yield chunk
            chunk = []
    if len(chunk) > 0:
        yield chunk


def main(n, min_depth=4):
    max_depth = max(min_depth + 2, n)
    stretch_depth = max_depth + 1
    if mp.cpu_count() > 1:
        pool = mp.Pool()
        chunkmap = pool.map
    else:
        chunkmap = map

    print('stretch tree of depth {0}\t check: {1}'.format(
        stretch_depth, make_check((0, stretch_depth))))

    long_lived_tree = make_tree(max_depth)

    mmd = max_depth + min_depth
    for d in range(min_depth, stretch_depth, 2):
        i = 2 ** (mmd - d)
        cs = 0
        for argchunk in get_argchunks(i, d):
            cs += sum(chunkmap(make_check, argchunk))
            print('{0}\t trees of depth {1}\t check: {2}'.format(i, d, cs))

    print('long lived tree of depth {0}\t check: {1}'.format(
        max_depth, check_tree(long_lived_tree)))


if __name__ == '__main__':
    main(int(sys.argv[1]))

다음은 파이썬 프로그램이에요. 위에서 나왔던 C 프로그램보다는 코드의 길이가 짧다는 것이 눈에 띄어요. 그런데 줄어든 코드의 길이 값은 못 하는 것 같네요. 아까와 같이 깊이 21의 이진 트리를 모두 탐색하는 데 80.82초가 걸렸습니다. 메모리 공간도 약 100,000바이트가량 더 썼네요.

파이썬은 인터프리터의 설계상 많은 계산이 필요한 작업에 적합한 프로그래밍 언어는 아닙니다. 하지만 데이터 분석과 같은 작업을 할 때에는 파이썬처럼 간단한 언어가 필수적이에요. 결국 사람들은 계산만 C 확장 프로그램에 맡기고, 알고리즘을 작성하는 작업은 파이썬으로 진행하는 방식을 택하게 됩니다. NumPy, TensorFlow와 같은 유명한 라이브러리도 이 방식을 사용하고 있어요. (실제로 NumPy 리포지토리에 들어가 보시면 거의 반 정도는 C 코드로 이루어져 있어요.)

이렇게 보니 C로 파이썬 확장 라이브러리를 만드는 건 엄청 좋은 것으로 보입니다. 로직은 파이썬으로 구현하고, 느린 계산은 C로 빠릿빠릿하게 실행할 수 있다니, 양 쪽 진영의 좋은 점만 가져온 것처럼 보이잖아요? 하지만 여기서 간과해서는 안 될 사실이 있습니다. 파이썬은 메모리 관리를 자동으로 해 주지만, C는 그렇지 않다는 거죠. 메모리 관리를 하지 않는 언어로 메모리 관리를 하는 언어의 확장 프로그램을 어떻게 만든다는 건가요?

C로 파이썬 확장 프로그램을 만들 때는 일반 C 프로그램처럼 malloc()​과 free() 함수를 통해서 메모리를 적절히 할당하고 해제해 주어야 합니다. 물론, 이는 확장 라이브러리 안에서만 사용하는 구조체에 한정되는 것으로, 만약 이후 파이썬 코드에서 사용할 객체를 쓸 때는 마음대로 메모리를 할당하거나 해제해서는 안 되겠죠? 자칫 잘못했다간 파이썬 인터프리터가 segmentation fault를 뿜으며 장렬히 전사할 테니까요. 그래서 우리는 파이썬 인터프리터에게 "우리 이 객체를 쓰고 있으니까 마음대로 지우면 안 돼!" 하고 이야기해 줄 필요가 있습니다.

모든 파이썬 객체에는 "레퍼런스 카운터"라는 이름의 변수가 하나씩 들어 있는데요, 이 변수에는 어떤 객체를 사용하고 있는 작업(또는 객체)의 개수를 저장하게 됩니다. 방금 "파이썬 인터프리터에게 알려 준다"고 하는 것은 사용하려는 레퍼런스 카운터의 값을 1 증가시키고, 사용이 끝난 뒤 레퍼런스 카운터를 1 감소시키는 것과 같죠. 이 작업을 하면 파이썬 인터프리터가 어떤 객체를 정리해도 되는지 쉽게 알 수 있어요. 레퍼런스 카운트가 0, 즉 이 객체를 사용하는 작업이 하나도 없다면 이제 더 쓰지 않는 객체라는 뜻이니까요.

이 작업을 레퍼런스 카운팅이라고 부르고, 파이썬 내부 소스코드에서는 Py_INCREF​와 Py_DECREF 매크로가 이 작업을 담당하고 있습니다. 그런데 이건 어디까지나 파이썬 C 구현체와 관련된 이야기예요. 일반적으로 파이썬을 사용할 때에는 별로 만날 일이 없는 이야기죠. 그런데도 레퍼런스 카운팅과 메모리 안정성을 고려하며 파이썬 라이브러리를 만들고 있자니 갑자기 자괴감이 듭니다.

이럴 거면 왜 파이썬으로 만들어? 차라리 전부 C로 만들고 말지.

네… 맞는 말이에요. 이렇게 고민할 거면 차라리 C로 만드는 게 더 빠를 텐데요. 이게 정말 최선인가요?

C로 파이썬 확장 라이브러리를 만들 때 발생하는 문제는 세 가지로 정리할 수 있을 것 같네요.

• C 자체의 메모리 안전성
• C에서 만든 객체를 파이썬에서 사용할 때의 메모리 할당과 해제
• 파이썬에서 만든 객체를 C에서 사용할 때의 레퍼런스 카운팅

C언어가 가지고 있는 고질병인 메모리 안전성도 고려하기 바쁜데, 레퍼런스 카운팅과 파이썬 메모리 할당과 해제까지 고려하자니 문제가 상당히 복잡해져요. 하지만, 이러한 문제는 러스트의 주요 기능 중 하나인 차용 검사​(borrow checking)로 해결할 수 있습니다. 차용 검사는 러스트의 "메모리 안정성"을 보장하는 데 필요불가결한 역할을 맡습니다. 음, 메모리의 차용에 대한 이야기를 하기 전에 메모리의 소유권에 대해 잠깐 짚고 넘어가 볼까요?

여러분은 보통 python.org에서 파이썬 인터프리터를 다운받거나 아니면 시스템에 설치된 패키지 매니저를 사용해서 파이썬을 설치하셨을 거예요. 그 파이썬 인터프리터가 바로 파이썬 재단에서 개발하는 레퍼런스 인터프리터인 CPython입니다. 이름에서 알 수 있듯이 C로 작성되어 있어요. 하지만 그 이외에도 많은 파이썬 인터프리터가 있다는 사실, 알고 계셨나요?

아니 이렇게나 많은데 우리가 또 러스트로 파이썬을 개발해야 할 필요가 있는 걸까요? 그 대답을 알아보기 위해 러스트로 파이썬을 구현하는 프로젝트인 RustPython의 개발자, Windel Bouwman의 이야기를 들어 봅시다.

"One of the reasons is that… I wanted to learn Rust."

"(RustPython 프로젝트를 시작한) 이유 중 하나는… 러스트를 배우고 싶어서죠."

아, 네. 새 프로그래밍 언어를 배우기 위해 프로그래밍 언어를 구현한다니 어나더 레벨이긴 하네요… 하지만 실제로 현재 RustPython은 40만 줄이 넘는 소스코드를 가지고 있지만 이 프로젝트의 시작은 굉장히 간단했어요. RustPython의 전신인 rspython의 리포지토리를 한번 보세요. 이 리포지토리에서 계속 발전하여 지금은 최소 파이썬 3.5 버전을 지원하는 파이썬 인터프리터가 되었습니다.

굳이? 왜? 하필? 어째서???

부만의 이야기는 RustPython 프로젝트를 시작한 계기는 설명해 주지만 RustPython이 다른 파이썬 인터프리터보다 왜 나은지, 아니면 러스트가 어째서 다른 언어보다 파이썬 인터프리터를 구현하기 좋은 언어인지 알려주지는 않습니다. 그러면 그에 관해서 이야기를 해봐야겠네요. 아래 코드를 보세요. 아래의 C 코드는 CPython을 이용하여 파이썬 코드 p[key]​를 구현한 부분입니다. 이 코드에서 변수 p​는 파이썬 dict 타입이라고 생각해 주세요.

/* (3) */PyObject *PyDict_GetItem(/* (1) */PyObject *p, /* (2) */PyObject *key);

위 코드의 특징 세 가지를 적어 보겠습니다.

• p​라는 PyObject​의 레퍼런스(1)에서 key​의 레퍼런스(3)에 따라 오브젝트를 찾은 뒤 그 오브젝트의 레퍼런스(3)를 반환함
• 만약 p​(1)에 key 엔트리(2)가 존재하지 않는다면 예외를 던지지 않고 NULL​(3)을 반환함
• p​(1), key​(2), 그리고 함수의 반환값(3)에 대한 레퍼런스 카운터는 모두 프로그래머가 직접 관리해야 함

자, 그리고 아래는 러스트에서 제공하는 기능 세 가지를 나열한 것입니다.

• 러스트에 존재하는 모든 레퍼런스 타입은 컴파일러가 차용 검사를 진행하며 안정성을 보장함
• 러스트의 표준 라이브러리는 "실패할 수도 있는 작업"을 나타내는 Result<T, E> 타입을 제공함
• 이 외에도 레퍼런스 카운팅을 자동으로 수행해 주는 Rc<T> 타입도 제공함

어때요, 어디선가 들어본 적 있는 기능 아닌가요? 이렇게 파이썬 인터프리터 구현체가 관리해야 할 기능의 대부분을 러스트는 언어 단에서, 또는 표준 라이브러리를 통해서 이미 제공하고 있어요. 거기다 아까도 잠시 언급했듯, 러스트는 설치할 때 cargo라는 패키지 매니저와 함께 설치되기 때문에 다른 사람이 만들어 둔 기능을 가져오는 것도 C에 비해 훨씬 자유롭죠! 거기다 요즘 핫한 WebAssembly까지 컴파일러가 기본으로 지원하니, 이게 바로 힙스터의 꿈이 아니면 뭐란 말인가요!

그러면 실제로 RustPython은 어떤 식으로 구현되어 있는지 간단하게 살펴봅시다. 파이썬을 포함한 대부분의 인터프리트 언어는 4가지 단계를 거쳐서 실행됩니다. 아래 그림을 보세요.

먼저 제일 실행의 제일 첫 번째 단계, 소스코드는 말 그대로 프로그램이 프로그래머가 작성한 텍스트 파일으로 존재하는 단계입니다. 그냥 파일 자체를 읽어들이가만 하는 거죠. 여기서 낱말 분석​(lexical analysis) 및 구문 분석​(syntax analysis, parsing) 단계를 거쳐 다음 단계인 추상 구문 트리​(abstract syntax tree)를 구성합니다.

추상 구문 트리는 프로그램의 구조를 트리 자료구조를 사용하여 표현한 것으로, 어떤 문법 구조를 부모 노드로 하고, 그 구조 안에 포함되는 토큰 등을 자식 노드로 갖는 트리예요. 예를 들어, 5 + 3​이라는 수식을 AST로 표현하면 '+' 부모 노드가 5와 3을 자식 노드로 갖는 트리가 되겠죠? 만약 소스코드에 문제가 있다면 이 단계에서 "Syntax error" 오류가 검출됩니다. AST가 완전히 구성되면 이제 컴퓨터가 프로그램을 실행할 준비가 완료된 거예요. 이제 인터프리터는 AST를 보고 컴파일 작업을 수행합니다.

인터프리트 언어라고 했으면서 컴파일 작업이 왜 나오냐고요? 사실 AST만 읽어서 바로 프로그램을 실행하는 것 역시 가능하지만, 그러면 속도가 잘 나오지 않아요. 또 소스코드를 해석하는 작업 자체가 느린 편에 속하기 때문에, 프로그램을 사용할 때마다 소스코드를 다시 읽어들이는 것도 별로 효율적이지 않고요. 그래서 인터프리터는 바이트코드(bytecode)라는 중간 언어(intermediate language)로 프로그램을 컴파일합니다. 이 바이트코드는 구조화가 잘 돼 있는 프로그램 소스코드보다는 CPU에서 실행되는 어셈블리 언어를 닮았어요. 그 쪽이 인터프리터가 이해하기 편하거든요. 이렇게 자기가 이해하기 편한 모습으로 프로그램을 변환시킨 인터프리터는 마지막으로 바이트코드​를 실행하는 거죠.

위 내용을 파이썬에 한정해서 생각을 해 볼게요. 먼저 구문 분석 이야기부터 시작할까요? 사실 파이썬 문법은 상당히 귀찮은 편입니다. 사람이 보기에는 올바른 들여쓰기 레벨을 강제하면서 한 눈에 들어오는 코드가 되었을지 몰라도, 이 들여쓰기라는 게 컴퓨터한테는 어렵거든요.

컴퓨터는 멍청합니다. 무언가를 기억한다는 행위가 컴퓨터에겐 어려운 일이에요. 그래서 컴퓨터가 좋아하는 형식의 정보는 언제 어디서나 해석해도 똑같은 결과가 나오는 정보입니다. 함수형 프로그래밍 언어: 헐 나네? 즉, "문맥에 좌우받지 않는[context-free]" 정보가 컴퓨터가 처리하기 좋은 정보라는 이야기예요. 다음 두 C 함수 선언을 보세요.

int func1(int a, int b) { return a + b; }

int func2(int a, int b)
{
     return a + b;
}

C에서는 단어의 구분만 될 수 있다면 공백 문자의 개수는 중요하지 않습니다. 따라서 위 두 함수 선언문은 똑같은 토큰 목록을 가지고 있고, 이 똑같은 토큰 목록은 코드의 어디에 등장하건 의미가 똑같아요. int형 매개변수 두 개를 받아 int를 반환하는 함수를 선언하고 정의하는 코드니까요. 하지만 다음 파이썬 코드를 보세요.

# (1)
c = a + b

    # (2)
    c = a + b

두 대입식 모두 눈에 보이는 글자는 똑같아요. 하지만 사람인 우리는 두 식이 서로 다른 것을 의미한다는 것을 아주 잘 알고 있어요. 첫 번째 식은 프로그램의 최상위에 위치하는 식이고, 두 번째는 어떤 블록 안에 속하는 식이라는 거죠. 우리야 눈으로 보면 두 번째 식이 안쪽으로 움푹 들어가 있다는 사실을 잘 알 수 있지만 컴퓨터는 이 "움푹" 들어간 걸 어떻게 해석해야 할까요?

중괄호를 사용해서 블록을 표시하는 다른 언어와 달리, 들여쓰기를 사용해서 블럭을 표시하는 언어는 기본적으로 문맥 자유 언어​[context-free grammar]가 아닙니다. 어떤 단어 목록을 제대로 분석해서 올바른 AST를 생성하기 위해서는 그 단어 목록이 얼만큼 들여쓰기가 되어 있는지 기억해 둬야 하거든요. 예를 들어, 2번 줄에 있는 식은 들여쓰기가 되어 있지 않으니 다른 들여쓰기가 없는 식과 함께 묶어야 하고, 5번 줄에 있는 식은 4칸 들여 썼으니 똑같이 4칸 들여 쓴 식과 함께 묶어서 블록으로 만들어야 하죠. 이 "기억" 문제를 해결하는 방법은 크게 두 가지가 있어요.

첫 번째 방법은 낱말 분석기와 구문 분석기 사이에 일종의 피드백 루프를 구현하는 거예요. 구문 분석기가 어떤 문법을 분석할 때마다 해당 구문이 얼마나 들여쓰기됐는지 낱말 분석기에게 물어보는 거죠. 이 경우 구문 분석기와 낱말 분석기 모두 현재까지 분석한 소스코드 정보를 개별적으로 저장하고 있어야 해요.

두 번째 방법은 낱말 분석기에게 "기억"하는 작업을 모두 떠맡기는 거예요. 즉, 들여쓰기를 분석해서 "들여 쓴다"와 "내어 쓴다"는 작업을 하나의 토큰으로 추상화시켜버리는 거죠. 이렇게 하니 무슨 말인지 잘 모르겠네요. 아래 파이썬 코드를 예시로 들어 볼게요.

def func(a, b):
    c = a + b
    if c < 10:
        c = 10
    return c

func(1, 2)

와, 엄청 기네요. 그래도 낱말 내용을 보시면 대충 왜 이런 식으로 분석되는지 보실 수 있을 거예요. 방금 목록에서 굵게 표시한 들여쓰기 "낱말"과 내어쓰기 "낱말" 사이를 잘 살펴보세요. 두 낱말 사이의 내용은 파이썬 코드 안에서 한 칸 들여 쓰여있는 것을 확인할 수 있습니다. 낱말 분석기는 이렇게 어떤 식 이전에 있는 공백 문자 개수를 세고, 그 문자 수가 달라질 경우 자동으로 들여쓰기와 내어쓰기 낱말을 생성해낼 수 있습니다. 결과적으로 이 들여쓰기 낱말과 내어쓰기 낱말이 코드 블럭을 표시하는 C언어에서의 중괄호와 같은 역할을 하는 것이죠!

이렇게 하면 낱말 분석 규칙은 (매 줄마다 얼마나 들여쓰기가 되어 있는지 확인해야 하므로) 문맥으로부터 자유롭지 않지만, 구문 분석을 할 때는 문맥에 구애받지 않고 컴퓨터가 이해하기 쉬운 규칙을 만들 수 있어요. 조금 더 자세히 설명하지만, 이렇게 만들어진 낱말 목록을 해석할 때, 구문 분석기는 현재 처리해야 하는 낱말에서 두 칸 앞만 미리 내다보고 와도 완벽하게 파이썬 문법을 이해할 수 있다는 거예요! RustPython은 이렇게 낱말 분석 단계에서 들여쓰기를 "토큰화"시켜서 구문 분석기를 간결하게 만듭니다.

보통 파이썬은 인터프리트 언어라고 다들 이야기합니다. 하지만 파이썬 가상 머신은 파이썬 소스코드를 이해하지 못 한다는 사실 알고 계셨나요? 그래서 비록 소스코드를 실행하는 파이썬이지만, 소스코드를 가상 머신이 이해할 수 있는 바이트코드로 컴파일하지 않는 이상 파이썬 가상 머신은 프로그램을 실행시킬 수 없어요. 이 바이트코드를 확인하는 방법은 간단합니다. 지금 파이썬 REPL을 켜서 다음 코드를 입력해 보세요.

Python 3.9.1 (default, Feb 13 2021, 10:22:50)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def hello(name):
...     print("Hello, world!")
...     print(f"Hello, {name}!")
...
>>> import dis
>>> dis.dis(hello)
2           0 LOAD_GLOBAL              0 (print)
            2 LOAD_CONST               1 ('Hello, world!')
            4 CALL_FUNCTION            1
            6 POP_TOP

3           8 LOAD_GLOBAL              0 (print)
           10 LOAD_CONST               2 ('Hello, ')
           12 LOAD_FAST                0 (name)
           14 FORMAT_VALUE             0
           16 LOAD_CONST               3 ('!')
           18 BUILD_STRING             3
           20 CALL_FUNCTION            1
           22 POP_TOP
           24 LOAD_CONST               0 (None)
           26 RETURN_VALUE

우리가 8번 줄에서 임포트한 dis 모듈은 파이썬의 "디스어셈블러" 모듈이에요. 이 모듈의 dis 함수에 방금 우리가 선언한 함수를 입력하니 어셈블리 코드처럼 보이는 무언가를 잔뜩 출력하네요. 이 무언가가 바로 파이썬 바이트코드입니다. 보통 이렇게 컴파일된 바이트코드는 메모리 안에 남아 있거나, 캐시 파일의 형태로 디스크에 저장됩니다. Python2의 경우는 소스코드 파일과 같은 경로에, Python3의 경우는 프로젝트 경로에 __pycache__​라는 이름의 폴더를 만든 뒤 그 폴더 안에 캐시 파일이 생기게 됩니다. 파이썬 가상 머신은 컴퓨터의 CPU가 기계어(어셈블리 코드)를 실행시키듯 이 파이썬 바이트코드 파일을 실행시키는 거예요.

그러나 CPU의 명령어 집합(instruction set architecture)과 달리 파이썬 바이트코드는 파이썬 언어 명세서에 포함돼 있지 않아요. 2즉, 파이썬 구현체에 따라 바이트코드가 달라질 수 있다는 거죠. 하지만 CPython의 경우 바이트코드에 관한 내용을 매우 상세하게 문서에 적어 뒀어요. 파이썬 공식 문서의 dis 모듈 레퍼런스를 보세요. 이 문서의 내용을 요약하면, 파이썬 바이트코드의 특징 몇 가지를 추려 낼 수 있습니다.

제일 먼저 알 수 있는 점은 파이썬 바이트코드는 파이썬 프로그램의 정보를 모두 담고 있어요. 즉, .py 파일이 없어도 그 파일을 컴파일한 .pyc 파일만 가지고 있으면 그 프로그램을 실행할 수 있다는 거예요! 하지만 파이썬 바이트코드 자체는 자바의 JVM 바이트코드나 .NET의 CIL처럼 소스코드를 거의 원본 그대로 복구할 수 있는 바이트코드라 코드 보호용으로는 큰 쓸모가 없지만요…

또 하나 알 수 있는 사실은 파이썬 바이트코드는 컴파일 단계에서 최적화를 거의 행하지 않는다는 점입니다. 즉, 파이썬 바이트코드는 코드의 속도보다는 파이썬 코드를 거의 그대로 옮기는 것에 더 집중한다는 거죠. 파이썬을 고안한 사람인 귀도 반 로섬의 이야기를 한번 들어 볼게요.

"Python is about having the simplest, dumbest compiler imaginable."

"파이썬은 사람이 상상할 수 있는 가장 간단하고 멍청한 컴파일러를 갖도록 만들었습니다."

최적화를 하지 않는다고 하면 부정적으로 들리지만, 사실 그렇게 나쁜 선택은 아니에요. 컴파일러가 간단한 덕분에 파이썬에 기능을 추가할 때 기술적인 부채가 크지 않아서 파이썬에 기능을 추가하기 수월해지니까요. 파이썬이 계속해서 발전하는 언어가 될 수 있었던 건 간단한 컴파일러 구조 덕이기도 해요.

RustPython은 CPython의 바이트코드를 기반으로 작성되었기 때문에, 컴파일러 구조 역시 굉장히 비슷합니다. 기본적인 기능은 똑같이 구현하되, INPLACE_* 명령어와 같은 속도 향상용 명령어는 제외하고 구현하고 있거든요. 또, RustPython에서는 CPython의 Peephole Optimizer와 같은 기능을 이미 구현하고 있기 때문에, 다음과 같은 기본적인 최적화는 실행합니다.

• 상수 접기 (constant folding)
• 불변 상수값 할당 최적화 (immutable allocation optimization)

하지만 이런 내용은 대부분의 경우 큰 속도 부스트를 내지 못합니다. 다른 컴파일 언어는 훨씬 더 복잡하고 적극적으로 최적화를 진행하기 때문이에요. RustPython이 진행하지 않는 최적화 중 속도에 큰 도움이 될 수 있는 것들은 다음과 같습니다.

• 미사용 변수 최적화 (unused variable optimization)
• 불필요한 중간 오브젝트 삭제 (unnecessary intermediate object elimination)
• 루프 펼치기 (loop unrolling)
• 꼬리 재귀 함수 최적화 (tail recursion call optimization)
• 기타등등…

파이썬 프로그램 실행의 마지막 단계는 Python Virtual Machine(PVM), 즉 파이썬 가상 머신에서 실행됩니다. 파이썬 가상 머신은 현재 등록된 빌트인 모듈, 전역 변수, 실행 중인 함수 프레임, 파이썬 커맨드라인 매개변수 등을 모두 저장하고, 그 정보에 따라 동작합니다.

사실, 가상 머신의 내부 구현을 보는 것 자체는 그렇게 재밌지 않아요. 비록 RustPython은 러스트에서 제공하는 강력한 패턴 매칭 구문과 열거형 기능을 사용하여 가상 머신의 디스패치 루틴을 간소화했다고 하더라도, 기본적으로 가상머신이 하는 일은 바이트코드를 읽고, 올바른 함수를 찾아서, 함수를 호출하는 일을 반복하는 것 밖에 안 되거든요.

오히려, RustPython 가상머신에서 눈여겨볼 부분은 빌트인 함수를 구현한 방식이에요. 러스트에서는 AST 레벨에서 코드를 바꿀 수 있는 강력한 메타프로그래밍 매크로 기능을 제공하는데, 이러한 매크로를 십분 활용해서 간결하게 빌트인 클래스와 함수 등을 구현하고 있어요. 예를 들어, 파이썬 사전 타입의 __getitem__ 매직 함수를 구현하는 부분을 보세요.

CPython에서는 이 함수를 구현하기 위해 따로 매직 함수 등록 루틴을 만들고, 이를 클래스에 등록하는 귀찮은 작업을 거쳐야 하지만 이 모든 작업을 러스트는 #[pymethod(magic)]​이라는 어트리뷰트 하나로 처리합니다.

사용자 입장에서는 파이썬 인터프리터에서 발생할 수 있는 메모리 관리 문제가 완전히 사라진다는 점에서 이득을 볼 수 있어요. 또, 러스트 언어 자체가 기본적으로 WebAssembly를 지원하기 때문에 요즘 발전하고 있는 웹 환경에 더 알맞은 언어라고 볼 수 있겠네요. 이러한 장점 덕에pyckitup 2D 게임엔진이나 codingworkshops.org 프로그래밍 교육 웹사이트는 웹 기반 파이썬 실행 환경을 제공하기 위해 CPython이 아닌 RustPython을 사용하고 있습니다.

또, 간결한 코드베이스 덕에 러스트를 배우고 싶어하는 사람들에게도 러스트 코드 작성법을 배울 수 있는 좋은 교재가 될 수도 있고요.

아까도 잠깐 언급했지만, RustPython에는 간결함을 위해 성능 향상용 바이트코드 명령어를 상당수 삭제했어요. 또, RustPython에서 사용하는 자료구조 역시 가장 효율적인 자료구조라고 할 수는 없습니다. 그래서 기본적으로 파이썬 코드를 실행시키는 속도가 CPython보다 16배 정도 느려요.

또, 처음 부분에 이야기했던 느려터진 파이썬을 보완하는 부분인 네이티브 확장 프로그램도 지원하고 있지 않으니 RustPython은 아직 프로덕션에서 사용하기는 힘든 것 같습니다.

이제 현실을 받아들일 때가 온 것 같습니다. 지금까지 러스트 찬양을 했지만, 러스트가 진짜 "최고의 언어"라고는 보기 힘들죠. 사실 메모리 관리를 잘 하는 코드는 숙련된 프로그래머라면 누구나 작성할 수 있는 거거든요. 거기다 메모리 사용에 대한 체크를 너무 신중하게 하는지라 컴파일 시간이 너무 오래 걸린다는 문제점도 있죠. 또, 일반적인 프로그래밍에 익숙해져 있다 보니 차용 검사라는 개념 자체가 매우 생소하게 다가온다는 것도 단점이라고 할 수 있습니다. 비록 패키지 매니저와 함께 설치되어 외부 라이브러리를 사용하는 것이 간단하다 하더라도, 이 모든 라이브러리를 정적으로 연결하기 때문에 컴파일 결과물이 불필요하게 커지기도 하죠. (그러면서 libc는 동적 링킹을 하네요. 어째서?)

그래서 러스트는 C를 대체할 수는 있어도, C++를 대체하기는… 힘들겠네요. 이미 모던 C++에서는 메모리를 관리하기 위한 많은 유틸리티가 포함되어 있고, 무엇보다 컴파일 속도가 빠르니까요. 또, 템플릿 기반 메타프로그래밍도 러스트의 매크로만큼은 아니더라도 상당히 강력합니다. 하지만 데이터 사이언스에서 러스트가 조금씩 지분을 넓혀가고 있습니다. 컴파일 속도도 버전 업데이트를 거듭하며 점점 빨라지고 있어요! 그래도 Golang보다는 러스트가 훨씬 낫잖아요?

반대로 파이썬도 "최고의 언어"라고 보기는 어렵습니다. 들여쓰기를 강제하는 문법 구조는 파싱하기도 힘들 뿐만 아니라, 조금만 로직이 복잡해져도 사람이 읽기 힘들어져요. 거기다 CPython 인터프리터에는 제대로 된 멀티스레딩 기능이 들어가 있지 않기 때문에, 병렬 처리를 위해서는 보통 Stackless와 같은 다른 인터프리터를 사용해야 한다는 단점도 있습니다. 실행 속도가 매우 느리다는 건 말할 것도 없고요.

그래서 파이썬은 간단한 CLI 유틸리티 등을 만들기에는 죄적의 언어입니다. 파이썬을 대체할 수 있을 만한 언어가 별로 없긴 하거든요. 루비와 펄은 잊혀졌고, 자바스크립트는 쓸데없는 종속성 지옥의 구렁텅이에 빠져서 헤어나오지를 못 하고 있는데다가 쉘 스크립트는 복잡도와 가독성의 관계가 비례도 아니고 지수함수를 따르니까요. 그래도 파이썬 역시 복잡한 로직을 구성할 때에 가독성이 바닥으로 치닫는 건 마찬가지이니 사용할 때를 잘 고려해봐야 할 것 같습니다.

자, 초심으로 돌아가 같은 질문을 한번 더 던져 봅시다. 힙했던 언어와 힙한 언어를 합치면 어떻게 되나요? 답은 간단합니다. 메모리 세이프한 힙 오버플로우​죠.