PHP 8.6, 클로저가 드디어 빨라진다 - 내부 최적화 RFC 들여다보기

왜 지금 클로저 최적화 이야기가 나올까요

PHP를 좀 써보신 분이라면 function() use ($var) { ... } 같은 클로저(익명 함수)를 한 번쯤은 만져보셨을 거예요. 배열 다루는 array_map, array_filter 같은 함수에 콜백으로 넘기거나, Laravel 같은 프레임워크에서 라우트 정의할 때 정말 자주 쓰이죠. 그런데 사실 내부적으로 PHP의 클로저는 생각보다 무거운 객체예요. 호출할 때마다 바인딩된 $this가 있는지 확인하고, use로 캡처한 변수들을 복사하고, 스코프 체크를 하느라 일반 함수 호출보다 훨씬 많은 일을 하거든요.

이번에 PHP 8.6을 향해 올라온 "Closure Optimizations" RFC는 바로 이 부분을 손보자는 제안이에요. 수년간 PHP는 JIT 도입이나 타입 시스템 강화 같은 굵직한 변화를 거쳐왔는데, 이번엔 아주 세밀한 내부 최적화에 집중한 느낌이라 오히려 재밌는 지점이에요.

어떻게 빨라지는 건가요

핵심 아이디어는 "불필요한 작업을 런타임이 아니라 컴파일 타임에 결정하자" 입니다. 예를 들어 static function() { ... } 처럼 static 키워드가 붙은 클로저는 $this를 절대 쓸 수 없어요. 그런데도 지금까지의 PHP 엔진은 이 클로저를 호출할 때마다 "혹시 $this가 바인딩되어 있나?" 하고 매번 검사했거든요. 이걸 미리 "얘는 static이니까 그냥 스킵" 이라고 판단하고 검사 코드 자체를 없애버리는 거죠.

또 하나 중요한 변화는 캡처 변수 처리 방식이에요. use ($x, $y) 로 변수를 빌려오면 지금까진 클로저가 만들어질 때마다 이 변수들을 해시 테이블에 담아서 보관했어요. 해시 테이블은 키로 값을 찾는 구조라 빠르긴 해도 공짜가 아닙니다. RFC에서는 캡처된 변수를 클로저 객체의 고정된 슬롯에 배열처럼 박아넣어서, 접근할 때 해시 조회 없이 바로 오프셋으로 읽도록 바꾸자고 제안해요. 이게 뭐냐면, 서랍에 라벨 붙여서 찾는 방식에서 "첫 번째 칸", "두 번째 칸" 하고 위치로 바로 집는 방식으로 바꾸는 거라고 보시면 돼요.

그리고 짧은 화살표 함수 fn($x) => $x * 2 같은 경우 자동으로 바깥 스코프 변수를 캡처하는데, 여기서도 실제로 본문에서 쓰지 않는 변수는 캡처 목록에서 빼버리는 최적화가 들어간다고 합니다. 지금은 보수적으로 다 가져오고 있었거든요.

실제 성능은 얼마나 개선될까

RFC에 첨부된 벤치마크를 보면 클로저를 집중적으로 호출하는 마이크로 벤치마크 기준으로 10~25% 수준의 속도 향상이 관찰됐다고 해요. 숫자만 보면 어마어마하진 않지만, PHP의 실무 코드베이스에서 클로저가 얼마나 깔려 있는지를 생각하면 무시 못 할 개선입니다. Laravel 컬렉션, 미들웨어 파이프라인, 이벤트 리스너, 큐 워커 같은 곳은 전부 클로저가 뼈대거든요. "전체 요청 처리 시간의 몇 퍼센트" 수준으로 직접 체감되진 않더라도, 대규모 트래픽 서버에선 CPU 사용률이 눈에 띄게 떨어질 수 있는 변화예요.

업계 맥락에서 보면

PHP는 JIT가 들어온 8.0 이후로 "이제 스크립트 언어가 아니라 컴파일되는 언어"라는 정체성을 꾸준히 강화해 왔어요. 근데 재밌는 건 Python(3.11의 specializing adaptive interpreter)이나 Ruby(YJIT)도 비슷한 시기에 비슷한 방향으로 움직이고 있다는 점이에요. 세 언어 모두 "호출 지점마다 타입을 추측하고 최적화 경로를 만들자"는 흐름을 타고 있고, 이번 PHP 클로저 최적화도 그 연장선에 있습니다. JavaScript의 V8이 10년 전부터 해오던 히든 클래스, 인라인 캐시 같은 최적화 기법들이 스크립팅 언어 전반으로 퍼지는 모양새예요.

한국 개발자에게 주는 의미

국내에도 커머스, 핀테크 쪽에서 PHP 기반 서비스를 운영하는 팀이 꽤 많습니다. 네이버 일부 서비스, 쿠팡 초창기 레거시, 그리고 수많은 쇼핑몰 솔루션들이 여전히 PHP 위에 있거든요. 이번 최적화는 코드를 한 줄도 고치지 않아도 런타임만 올리면 성능이 따라오는 변화라, 운영팀 입장에선 가장 좋아하는 종류의 업데이트예요. 다만 PHP 8.6은 아직 RFC 단계라 정식 릴리스는 2026년 말로 예상되니, 지금부터 8.3/8.4 기반으로 마이그레이션 계획을 잡아두는 게 현실적인 준비가 될 것 같습니다.

여러분 팀은 PHP 버전 업그레이드를 주기적으로 따라가시나요, 아니면 LTS 버전에 오래 머무는 편이신가요?