파이썬 3.15, 부담 거의 없는 '인터프리터 관찰' 방식 찾았다...JIT 컴파일용 실행 기록에 '이중 디스패치' 적용

[한국정보기술신문] 파이썬(Python) 3.15가 프로그램 실행을 빠르게 해 주는 기능을 준비하면서, 실행 과정을 거의 부담 없이 들여다보는 새로운 방식을 도입한 것으로 나타났다. 파이썬을 만드는 대표 구현체 시파이썬(CPython)의 코어 개발자 켄 진(Ken Jin)은 지난 7월 1일 자신의 블로그를 통해, 3.15에 들어갈 즉시 컴파일(JIT) 기능이 실행 흐름을 기록하기 위해 쓰는 이 관찰 방식을 소개했다. 켄 진은 2021년부터 시파이썬 코어 팀에서 파이썬의 성능과 JIT 개선을 맡아 온 개발자다.

파이썬은 사람이 쓴 코드를 컴퓨터가 이해하는 명령으로 바꿔 한 줄씩 곧바로 실행하는 '인터프리터' 방식으로 작동한다. 인터프리터란 프로그램을 미리 통째로 번역해 두지 않고, 실행하는 순간마다 코드를 해석해 처리하는 프로그램을 말한다. 이 방식은 다루기 편하지만 대체로 실행 속도가 느리다. 이를 보완하기 위해 최근 파이썬은 JIT라는 기능을 더하고 있다. JIT(Just-In-Time·적기 컴파일)란 프로그램이 돌아가는 도중에 자주 실행되는 부분을 그때그때 기계어로 바꿔, 그 대목을 더 빠르게 처리하도록 하는 기술이다.

JIT가 제대로 작동하려면 프로그램에서 어느 부분이 자주 쓰이는지, 실행이 어떤 순서로 흘러가는지를 먼저 알아야 한다. 이를 위해 시파이썬 3.15의 JIT는 프로그램이 실제로 실행되는 동안 명령어가 지나가는 흐름을 따라가며 적어 두는데, 이를 '추적 기록(trace recording)'이라 부른다. 추적 기록으로 모아 둔 실행 흐름을 JIT에 넘기면, JIT가 그 부분을 기계어로 바꿔 다음번부터 더 빠르게 돌린다.

문제는 이렇게 실행을 관찰하고 기록하는 일 자체가 프로그램을 느리게 만든다는 점이다. 실행을 지켜보려면 인터프리터에 관찰용 장치를 덧대야 하는데, 이 장치가 무거우면 정작 프로그램이 느려져 JIT로 얻는 이득이 사라질 수 있다. 프로그램의 실행 상태를 관찰·기록하는 이런 작업을 흔히 '프로파일링(profiling)'이라 부른다. 켄 진이 공개한 방식의 핵심은, 바로 이 프로파일링의 부담을 극단적으로 낮췄다는 데 있다.

켄 진에 따르면, 인터프리터를 관찰하는 데에는 그동안 크게 두 가지 방법이 쓰여 왔다. 첫째는 실행만 하는 인터프리터와 관찰만 하는 인터프리터를 따로 만들어 두고, 필요할 때 둘 사이를 오가는 방법이다. 하지만 이 방식은 사실상 인터프리터를 두 벌로 늘리는 셈이라, 프로그램의 덩치가 커지고 그만큼 속도가 떨어진다. 켄 진은 이 방법을 썼을 때 한 종류의 인터프리터에서 성능이 약 6% 낮아졌다고 밝혔다. 프로그램의 크기가 커지는 것 자체가 여러 이유로 속도에 나쁘게 작용한다는 것이다.

둘째는 하나의 인터프리터 안에 '관찰 모드'를 두고, 참(True)·거짓(False) 값 하나로 관찰 기능을 켜고 끄는 방법이다. 이 방식은 프로그램을 두 벌로 늘리지는 않지만, 명령어를 처리할 때마다 '지금이 관찰 모드인가'를 매번 확인해야 한다. 이렇게 갈림길에서 매번 조건을 따지는 것을 '분기(branch)'라 하는데, 켄 진은 요즘 컴퓨터가 이 분기를 거의 정확히 미리 맞힌다 해도 실행이 느려지고, 정상적인 인터프리터에 끼치는 방해가 지나치게 크다고 판단했다고 설명했다.

두 방법의 단점을 모두 피하기 위해 켄 진이 택한 것이 '이중 디스패치(dual dispatch)'다. 인터프리터는 명령어 하나를 처리한 뒤 다음 명령어로 넘어갈 때, 명령어의 번호를 그 명령어를 실제로 처리하는 코드의 위치와 연결해 찾아간다. 이렇게 다음에 실행할 곳으로 넘어가는 동작을 '디스패치(dispatch)'라 하고, 명령어 번호와 처리 위치를 짝지어 적어 둔 표를 '디스패치 테이블'이라 한다.

이중 디스패치의 발상은 이 디스패치 테이블을 두 개 두는 것이다. 하나는 평소 실행에 쓰는 정상 테이블이고, 다른 하나는 관찰에 쓰는 테이블이다. 다만 관찰용 테이블은 단순히 두 번째 인터프리터를 만드는 것이 아니라, 모든 명령어가 하나의 '기록 명령어'로 모이도록 짜여 있다. 어떤 명령어를 만나든 일단 이 기록 명령어로 흘러들어 필요한 관찰과 기록을 마친 뒤, 정상 테이블을 통해 원래 실행해야 할 다음 명령어로 다시 흩어져 나가는 구조다. 여러 갈래가 한 곳으로 모였다가 다시 퍼지는 이 방식 덕분에, 관찰 기능을 별도의 인터프리터로 통째로 복제할 필요가 없어진다.

이 구조에서 관찰 모드로 들어가는 일은 기록에 필요한 자료 공간을 마련한 뒤 쓰는 디스패치 테이블을 관찰용으로 바꿔 끼우는 것이 전부다. 관찰을 끝낼 때도 기록을 마무리하고 테이블을 정상용으로 되돌리기만 하면 된다. 명령어마다 '지금이 관찰 모드인가'를 따지는 분기가 아예 필요 없다는 것이 이 방식의 핵심 장점이다. 켄 진은 시파이썬 코어 팀의 마크 섀넌(Mark Shannon)이 앞서 제안한 '디스패치 테이블을 인터프리터에 꿰어 두 개를 두자'는 아이디어를 발전시켜 이 구조를 완성했다고 밝혔다.

켄 진은 이 방식이 얼마나 가벼운지를 직접 측정한 결과도 함께 공개했다. 시스템의 동작 주파수가 수시로 바뀌지 않도록 고정한 뒤 같은 시험을 40번 돌려 중간값을 잰 결과, 관찰 없이 인터프리터만 돌렸을 때는 약 0.0000017초가, 관찰과 기록에 JIT 컴파일까지 함께 수행했을 때는 약 0.0000075초가 걸렸다. 관찰과 컴파일을 모두 얹어도 부담이 최대 4.5배 수준에 그친다는 뜻이다.

켄 진은 이 수치를 다른 시스템과 견주기도 했다. 또 다른 파이썬 구현체인 파이파이(PyPy)에서 비슷한 추적 방식은 실행이 900~1000배까지 느려지는 것으로 알려져 있는데, 시파이썬의 이번 방식은 그에 비하면 대단히 가볍다는 것이다. 다만 그는 이 비교가 공정하지는 않다고 스스로 밝혔다. 파이파이는 프로그램뿐 아니라 인터프리터 자체까지 추적하는 방식이라 훨씬 많은 부분을 들여다볼 수밖에 없어, 애초에 조건이 다르다는 것이다. 그는 추적이 실제로 얼마나 느려질 수 있는지를 보여 주려고 예시로 든 것일 뿐이라고 덧붙였다.

이번에 공개된 관찰 방식은 시파이썬 3.15의 JIT를 뒷받침하는 바탕 기술이다. 시파이썬 3.15의 JIT는 기존 인터프리터보다 대체로 4~12% 정도 빨라진 것으로 보고되고 있으며, 그동안 실험 단계에 머물던 JIT를 정식 기능으로 삼자는 제안(PEP 836)도 함께 논의되고 있다. 이런 진전의 밑바탕에, 부담을 크게 낮춘 실행 관찰 기술이 자리 잡고 있는 셈이다.

켄 진은 이 방식이 추적 기록에만 쓰이는 것은 아니라고 설명했다. 인터프리터를 크게 뜯어고치지 않고도 가볍게 실행을 관찰하거나, 프로그램이 다루는 값의 유형을 실행 중에 기록하는 등 여러 곳에 응용할 수 있다는 것이다. 그러면서도 그는 이 방식이 우아하기는 하지만 그 작동을 머릿속에서 따라가기가 결코 간단하지 않다며, 시파이썬에 이런 정교한 장치를 두는 것이 그 복잡함을 감수할 만한 가치가 있는지 스스로 되묻게 된다고 털어놨다. 기술 지식을 기록해 두면 누군가에게 도움이 될 수 있다고 믿어 이 글을 쓴다는 것이 그의 설명이다.