파이썬 3.15, 프로파일링 오버헤드를 거의 0으로 만든다

프로파일러를 켜면 느려지는 역설

내 코드 어디가 느린지 알고 싶으면 프로파일러를 돌리죠. 프로파일링이 뭐냐면, 프로그램이 실행되는 동안 어떤 함수가 몇 번 불리고 시간을 얼마나 쓰는지 측정하는 작업이에요. 그런데 파이썬의 표준 도구인 cProfile에는 오래된 역설이 있어요. 프로파일러를 켜는 순간 프로그램이 두 배에서 많게는 몇 배까지 느려진다는 거예요. 측정하려고 켰는데 측정 자체가 결과를 왜곡해 버리니, 실제 서비스 환경에서는 사실상 못 쓰는 도구였죠.

CPython 코어 개발자 Ken Jin이 블로그를 통해 파이썬 3.15에서 준비 중인 초저오버헤드 프로파일링 모드를 소개했는데요. 핵심은 프로파일링 기능을 인터프리터 바깥에서 덧붙이는 게 아니라, 인터프리터 안에 아예 내장해 버린다는 거예요.

기존 방식은 왜 느렸을까요

파이썬의 전통적인 추적 방식은 sys.settrace라는 훅을 써요. 함수가 호출될 때마다, 심지어 코드 한 줄이 실행될 때마다 콜백 함수를 부르는 구조인데요. 그러니까 코드 한 줄을 실행할 때마다 '지금 이 줄 실행했어요'라고 보고하는 함수가 한 번 더 실행되는 거예요. 배보다 배꼽이 커지는 구조죠. cProfile은 이것보다는 낫지만 여전히 모든 함수 호출마다 C 레벨 훅이 개입해서, 함수 호출이 잦은 코드일수록 오버헤드가 커져요.

그래서 실무에서는 py-spy 같은 샘플링 프로파일러를 많이 썼어요. 이건 프로그램 바깥에서 주기적으로 '지금 뭐 하고 있어?' 하고 스냅샷만 찍는 방식이라 오버헤드가 거의 없는데, 대신 샘플과 샘플 사이에 일어난 일은 놓쳐요. 정확한 호출 횟수 같은 건 알 수 없는 거죠. 결국 지금까지는 '정확하지만 느린 방식'과 '빠르지만 대략적인 방식' 사이에서 하나를 골라야 했어요.

인터프리터를 두 벌 준비한다는 아이디어

새 방식의 아이디어는 이래요. 파이썬 인터프리터는 바이트코드라는 명령어를 하나씩 읽어서 실행하는 커다란 루프인데요. 이 루프를 두 벌 준비하는 거예요. 하나는 계측 코드가 전혀 없는 평소용 루프, 다른 하나는 실행 정보를 기록하는 코드가 심어진 프로파일링용 루프예요. 프로파일링이 꺼져 있을 때는 평소용 루프만 돌기 때문에 오버헤드가 말 그대로 0이고, 켜는 순간 프로파일링용 루프로 갈아타는 거죠. 계측 코드도 별도의 콜백 함수를 호출하는 게 아니라 인터프리터 내부에서 바로 기록하니까, 켜진 상태에서도 오버헤드가 몇 퍼센트 수준으로 뚝 떨어져요.

이 설계가 가능해진 배경도 재미있어요. 파이썬 3.12에서 sys.monitoring이라는 새 계측 API가 들어오면서 '필요한 이벤트만 골라 듣는' 기반이 마련됐고요, 3.14에서는 Ken Jin이 주도한 테일콜 인터프리터가 들어오면서 인터프리터 루프가 명령어별 함수들의 테이블 구조로 재편됐어요. 함수 테이블 구조가 되니까 '계측이 심어진 버전의 테이블로 통째로 교체'하는 게 자연스러워진 거예요. 몇 년에 걸친 인터프리터 개편이 차곡차곡 쌓여서 이번 결과로 이어진 셈이죠.

다른 언어들은 이미 가고 있는 길이에요

이 방향은 사실 다른 생태계에서는 표준이 된 흐름이에요. 자바에는 운영 환경에서 상시로 켜두는 JFR(Java Flight Recorder)이 있고, Go는 pprof를 프로덕션에서 켜두는 게 일반적이거든요. '프로파일링은 개발할 때만 잠깐 쓰는 것'이 아니라 '운영 중에 항상 켜두는 것'으로 인식이 바뀐 거죠. 이걸 지속 프로파일링(continuous profiling)이라고 부르는데, 파이썬만 오버헤드 문제 때문에 이 흐름에 제대로 못 타고 있었어요. 3.15의 변화는 파이썬을 이 대열에 합류시키는 작업이라고 볼 수 있어요.

실무에는 어떤 영향이 있을까요

당장 체감할 변화는 운영 환경에서의 관측이에요. 지금까지는 프로덕션 파이썬 서버가 느려지면 원인을 찾으려고 별도 도구를 붙이거나 재현 환경을 따로 만들어야 했는데, 오버헤드가 거의 없는 프로파일링이 표준 기능이 되면 운영 중인 서버에서 바로 데이터를 뽑을 수 있게 돼요. Datadog이나 Sentry 같은 APM 도구들도 이 기능 위에 올라타면서 파이썬 지원 품질이 좋아질 거고요. 성능 튜닝을 감이 아니라 데이터로 하는 문화가 파이썬 쪽에도 자리 잡기 좋은 조건이 만들어지는 거예요. 최근 몇 년 사이 파이썬이 GIL 제거, JIT 컴파일러, 테일콜 인터프리터까지 성능 관련 숙제를 하나씩 해치우고 있는데, 프로파일링 개선도 그 큰 그림의 한 조각이에요.

정리하면

파이썬 3.15의 프로파일링 모드는 '측정하면 느려진다'는 오래된 제약을 인터프리터 구조 개편으로 풀어낸 작업이에요. 여러분은 파이썬 성능 문제를 만났을 때 어떤 도구로 원인을 찾으시나요? 프로덕션에서 프로파일러를 상시로 켜두는 것에 대해서는 어떻게 생각하시는지도 궁금해요.