ast.walk를 220배 빠르게: 파이썬 표준 라이브러리가 느린 이유

파이썬 표준 함수가 220배 빨라질 수 있다고?

파이썬으로 코드 분석 도구나 린터, 코드 변환기를 만들어본 분들은 ast 모듈을 써봤을 거예요. 파이썬 코드를 트리 구조로 파싱해주는 표준 라이브러리죠. 그 안에 ast.walk라는 함수가 있는데, 트리의 모든 노드를 하나씩 훑어주는 편리한 도구예요. 그런데 reflex.dev 팀이 이 ast.walk를 무려 220배 빠르게 만든 과정을 공개했어요. 표준 라이브러리가 어떻게 220배나 느릴 수 있는지, 그 이유가 꽤 교육적이에요.

ast.walk가 하는 일

먼저 AST가 뭔지부터요. AST(Abstract Syntax Tree, 추상 구문 트리)는 코드를 사람이 아니라 컴퓨터가 다루기 좋게 나무 모양으로 바꿔놓은 거예요. a + b * 2라는 코드가 있으면, "더하기" 노드 밑에 "a"랑 "곱하기"가 달리고, 그 밑에 다시 "b"랑 "2"가 달리는 식이죠. 린터나 포매터, 컴파일러는 전부 이 트리를 돌아다니면서 일을 해요.

ast.walk는 이 트리의 모든 노드를 빠짐없이 하나씩 꺼내주는 함수예요. 그런데 표준 구현이 좀 느려요. 왜 그런지 들여다보면 재밌어요.

왜 느리냐면: '범용성의 대가'

표준 ast.walk는 어떤 노드가 와도 동작하도록 아주 일반적으로 만들어졌어요. 노드 하나를 만나면 "이 노드에 어떤 필드들이 있지?"를 매번 조회하고, 각 필드를 꺼내서 "이게 또 다른 노드인가? 리스트인가? 그냥 값인가?"를 일일이 검사해요.

이게 뭐냐면, 파이썬에서 객체의 속성을 이름으로 찾아오는 작업(getattr)이나 타입을 매번 확인하는 작업(isinstance)은 생각보다 비싸요. 노드가 수십만 개인 큰 파일을 처리하면, 이 "매번 물어보는" 비용이 곱하기로 쌓여서 어마어마해지죠. 게다가 표준 구현은 제너레이터(yield)를 겹겹이 쓰는데, 이 제너레이터를 들락날락하는 비용도 티끌 모아 태산이 돼요.

핵심은 이거예요. 표준 라이브러리는 "모든 상황에서 무난히 돌아가게" 만들어졌지, "특정 작업을 최대한 빠르게" 만들어진 게 아니에요. 그 범용성이 곧 속도의 대가예요.

어떻게 빨라졌냐면

reflex 팀의 최적화 아이디어를 한마디로 줄이면 "매번 묻지 말고, 한 번 알아낸 건 기억해두자"예요. 노드 종류별로 "이 타입은 어떤 필드에 자식 노드가 들어있다"는 정보를 미리 계산해서 캐싱해두는 거죠. 그러면 같은 종류의 노드를 또 만났을 때 처음부터 다시 조사할 필요 없이, 캐시에서 바로 꺼내 쓸 수 있어요.

여기에 더해 불필요한 타입 검사와 중간 제너레이터를 걷어내고, 자식 노드를 모으는 경로를 짧고 직선적으로 다듬으면, 노드 하나당 처리 비용이 확 줄어요. 한 노드에서 아낀 비용은 작아 보여도, 수십만 노드에 곱해지면 220배라는 숫자가 나오는 거예요. 알고리즘 자체(트리 순회)는 똑같은데, "한 단계 한 단계의 상수 비용"을 깎아서 얻은 성과라는 게 포인트예요.

업계 맥락에서

사실 이건 "표준 라이브러리는 안전하고 범용적이지만, 핫 패스(자주 도는 핵심 경로)에선 직접 특화한 버전이 이긴다"는 오래된 교훈의 새 사례예요. 파이썬 생태계에서 ruff(러스트로 짠 초고속 린터) 같은 고성능 도구들이 빠른 이유도 결국 비슷해요. 범용 추상화를 걷어내고, 자주 도는 경로를 손으로 최적화하는 거죠. reflex처럼 파이썬 코드를 분석해서 웹 UI로 변환하는 프레임워크는 AST 순회가 그야말로 핫 패스라, 여기서 220배는 사용자가 체감하는 빌드 속도로 직결돼요.

한국 개발자에게

교훈이 두 가지예요. 첫째, 성능 문제를 만났을 때 "내가 자주 부르는 표준 함수가 사실 범용성 때문에 느린 건 아닐까?"를 의심해볼 만해요. 단, 먼저 프로파일링으로 진짜 병목인지 확인하고 손대야 해요. 안 그러면 안 느린 데를 최적화하느라 시간만 버려요. 둘째, "매번 계산하는 걸 한 번만 계산하고 캐싱하기"는 정말 자주 통하는 만능 카드예요. getattr, 정규식 컴파일, 반복되는 조회... 루프 안에서 매번 하는 일이 있다면 밖으로 빼낼 수 있는지 늘 살펴보세요.