# 하이브리드 PHP의 부상: PHP와 Go, Rust의 결합 > Clean Markdown view of GeekNews topic #22857. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=22857](https://news.hada.io/topic?id=22857) - GeekNews Markdown: [https://news.hada.io/topic/22857.md](https://news.hada.io/topic/22857.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-09-02T11:07:31+09:00 - Updated: 2025-09-02T11:07:31+09:00 - Original source: [yekdeveloper.com](https://yekdeveloper.com/p/4-the-rise-of-hybrid-php) - Points: 14 - Comments: 5 ## Summary 최근 **PHP 모놀리식** 내에서 **Go**와 **Rust**를 FFI, 자체 확장, **FrankenPHP** 등을 통해 통합하는 하이브리드 아키텍처가 주목받고 있습니다. 복잡해진 **마이크로서비스** 분리 없이도, 적은 비용으로 **핫스팟 엔드포인트**의 성능을 대폭 개선하면서 **생산성과 고성능**을 동시에 확보할 수 있다는 점이 핵심입니다. PHP의 빠른 개발 환경을 유지하면서도, **Rust**의 **메모리 안전성**이나 **Go**의 **고속 API 처리** 같은 언어별 강점을 선택적으로 내부에 통합할 수 있어, 전체 재작성의 리스크를 피하면서 보다 효율적인 시스템 구축이 가능해집니다. ## Topic Body - 최근 **PHP 모놀리식 구조** 내에서 **Go**와 **Rust**를 확장 언어로 통합하는 하이브리드 방식이 주목받음 - 예전엔 **Go 마이크로서비스** 와 **PHP 8.3 모놀리식**의 조합으로 **생산성과 고성능**을 균형 있게 달성함 - **Pareto 법칙(80% 트래픽이 20% API에 집중)** 에 따라 핫스팟 엔드포인트 최적화가 필수였고, 과거에는 **캐싱·Go 서비스 분리**로 대응했으나 복잡성이 증가함 - 최근 PHP 생태계 발전으로 **FFI, Rust 확장, Go 확장(FrankenPHP)** 같은 기법이 등장해 모놀리식 내부에서 성능을 대폭 높일 수 있게 됨 - **Rust 확장**은 메모리 안전성과 속도를 동시에 제공하고, **FrankenPHP**는 워커 모드와 Go 기반 확장으로 최대 **4배 이상 성능 향상**을 보여줌 - 전체를 Go/Rust로 **재작성하는 비용·위험**을 피하면서, **하이브리드 PHP** 접근으로 **생산성과 속도 모두 확보** 가능 --- ### 배경 및 기존 아키텍처 - 기존에는 **DDD 모놀리식 애플리케이션**(mother)을 중심으로, 특정 기능의 최적화를 위해 **Go 기반 마이크로서비스**(children)를 별도로 개발함 - **Go 마이크로서비스**는 **고성능 트래픽 처리**를 담당했고, **PHP 8.3 모놀리식**은 작은 백엔드 팀 환경에서 **빠른 피처 개발과 배포 신뢰성**을 제공함 - 이런 구조는 **속도와 안정성, 생산성을 모두 확보**할 수 있는 균형점 제공 ### 성능 병목 지점과 기존 대응 방식 - 트래픽의 **80%가 20% API 엔드포인트**에 집중되는 **파레토 원칙**이 자주 관찰됨 - 성능이 가장 중요한 이 20% 구간을 위해, 최적화 코드 작성, **캐싱 계층 추가**, **Go 마이크로서비스 분리** 등 다양한 방법을 도입함 - 하지만 복잡성과 운영 부담 측면에서 한계가 존재함 ### 최신 PHP 생태계의 하이브리드 옵션 - 최근에는 **PHP 모놀리식 내부에서 직접 성능을 개선**할 수 있는 기술이 늘어남 - ## 1\. FFI (Foreign Function Interface) - PHP의 **FFI** 기능으로 PHP에서 **C 코드**를 직접 호출 가능 - 시스템 레벨이나 **성능 크리티컬** 로직도 PHP 프로젝트 내에서 구현 가능 - 단, **컨텍스트 스위칭 비용**을 고려해 적합한 상황에서만 사용 권장 - ## 2\. Rust 기반 확장 - **Rust**(또는 Zig)로 **PHP 확장** 개발 가능 - 고부하 처리 영역을 **메모리 안정성**과 **컴파일 성능**을 갖춘 Rust 확장으로 오프로드해, **신뢰성과 고속성** 모두 확보 가능 - ## 3\. Go 기반 확장: FrankenPHP - 최근 **FrankenPHP**로 전환 후 **worker mode**에서 동작시, 기존 대비 **4배 이상 빠른 성능** 확인 - 최근 릴리즈로 **Go로 PHP 확장 작성**도 가능해짐 - 이를 통해 **Go의 API 성능**을 PHP 모놀리식 내에서 바로 활용, **언어 분할 없이 생산성과 속도를 결합**할 수 있게 됨 ### 전체 Go 또는 Rust로의 완전 이관이 아닌 이유 - **전체 재작성 비용**과 위험 부담 높음 - 이미 크고 안정적인 애플리케이션을 완전히 Go나 Rust로 바꾸는 것은 리스크와 자원 소모가 큼 - **PHP 자체에 여전히 강점 존재** - 대부분의 업무에서는 PHP의 빠른 개발, 친화적인 생태계, 충분히 빠른 속도가 여전히 경쟁력이 됨 - **진정한 성능 한계**가 필요한 일부 영역만 Go, Rust로 하이브리드 구성하면 전체 이관 필요성 해소 가능 ### 결론: 하이브리드 PHP의 가치 - **현대 PHP 생태계**는 **빠른 개발 생산성**과 함께 고성능(C, Rust, Go) 확장 연동 옵션을 모두 제공 - 이런 하이브리드 구조로 **속도와 생산성 모두 확보** 가능 - PHP 중심의 개발을 유지하면서 **필요 시 언어 선택적 확장**이 가능한 새로운 아키텍처 패러다임 제시 ## Comments ### Comment 43267 - Author: naearu - Created: 2025-09-02T18:39:15+09:00 - Points: 1 뭔가 자바스크립트가 변해가는것 처럼 되어가는거같네요. ### Comment 43259 - Author: skageektp - Created: 2025-09-02T14:12:15+09:00 - Points: 1 nodejs에 rust면 몰라도;; 저는 php가 $같은게 계속 쓰이니 코드 치기가 불편해보이는데 잘 쓰시는 분들은 별로 불편함을 못느끼는 편인가요? ### Comment 43299 - Author: proinworks - Created: 2025-09-03T10:51:23+09:00 - Points: 1 - Parent comment: 43259 - Depth: 1 불편함을 느껴도 사용하다 보면 금방 익숙해지지 않나요? 인간은 적응하는 동물이에요. ### Comment 43263 - Author: nemorize - Created: 2025-09-02T14:43:49+09:00 - Points: 1 - Parent comment: 43259 - Depth: 1 저는 PHP의 변수/함수 개념 그 자체에 불편함을 느끼면 느꼈지, $ 표현법에 불편함을 느껴본 적은 전혀 없습니다. 달러 때문에 불편해서 못쓰겠다, ~~달러 표시를 쓰는 애들이라 돈을 많이 번다, 미국달러가 아니라 짐바브웨 달러라서 별로 못번다~~ 하는 이야기는 우스갯소리로 하는 이야기들 아니었나요... ### Comment 43248 - Author: neo - Created: 2025-09-02T11:07:32+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45077143) * 나는 범용적인 프레임워크(Spring, Laravel, Phoenix 등)에 점점 반감을 가지게 됨, 처음에는 정말 생산적이지만 레거시 프로젝트에서 항상 같은 문제가 반복됨 프로젝트마다 인프라 환경이나 비즈니스 조건이 달라서, 프레임워크의 권장 방식대로만 할 수 없으니 여기저기 추가적인 패치나 의존성 꼼수들이 늘어남 새로운 언어나 버전으로 업그레이드하려 하면 이런 커스텀된 부분이 모두 부서지기 때문에, 결국엔 아무도 업데이트 안 하다가 인프라에서 더는 돌릴 수 없을 때쯤 눈물의 대이동을 하게 됨 여러 라이브러리를 조합해서 직접 추상화를 만드는 방식이 시간이 더 걸릴 수 있지만, 부분적으로 유연하게 업그레이드할 수 있고 빠르게 방향 전환이 가능함 Go 생태계가 이런 점에서 이상적이라 생각하게 됨, 처음에는 낯설었지만 지금은 이 방식을 오히려 더 좋아하게 됨 * 웹 프레임워크에 대해선 “처음엔 정말 좋다가 어느 순간부터 불편해진다”는 느낌이 강함 간단한 앱을 만들 땐 Rails처럼 “15분만에 블로그 만들기” 같은 게 마치 마법처럼 느껴지지만, 복잡해지면 프레임워크가 오히려 장애물로 작용함 개인적으로는 Express + Node.js나 Vert.x + Java 같은 “중간 레벨” HTTP 세팅이 더 편함 * 파이썬에서는 microframework(Flask류)와 macroframework(Django)로 나눠볼 수 있음 나는 언제나 Django를 선택함, Flask는 거의 아무걸 제안하지 않으므로, 매 프로젝트가 매번 새롭게 꾸미는 스노우플레이크임 인증, 템플릿, 쿠키, 이메일 등 N가지 옵션 중에서 뭘 선택해야 할지 결정 피로가 발생함 특히 이런 라이브러리들은 대부분 1인 개발이라 유지보수/보안 품질도 들쭉날쭉함 반면 Django는 대부분의 프로젝트가 비슷하게 생기고, 거의 모든 기본 기능을 즉시 제공함 내가 굳이 확장 라이브러리를 쓸 이유가 있는 경우는 특수한 요구사항이 있을 때뿐임, 직접 관리되고 검증되는 부분이 많아 코드 신뢰도와 보안도 높다고 생각함 * Go에 거대한 프레임워크가 없는 이유는 언어의 타입 시스템이 많이 미완성된 탓임 서로 잘 어울리는 복잡한 라이브러리들을 만들기가 버거움 나는 제네릭을 쓸 수 있게 되기까지 9년이나 기다렸다가 Go용 데이터베이스 툴킷을 처음 만들었음 성공적이었지만, 예전에 Java로 이런 것 했을 때가 더 좋았다고 느낄 정도임 결과 타입을 다른 제네릭 타입으로 map/filter/reduce 할 수 있다면 완전히 다른 세상이 될 것임 union 타입 지정 기능만 있으면 any 타입 쓸 일도 없어질 것임 오버로딩 지원만 돼도 코드가 훨씬 깔끔해질 텐데, Go 타입 시스템은 아직 더 발전이 필요함 * 내 분야에서는 Go와 Rust만 쓸모가 있음 의견이 강한 프레임워크 문화는 잘 맞지 않음 Rails, Laravel, Django는 관계형 DB CRUD 작업이 명확한 상황에는 훌륭하다고 생각함 * 나는 최근 5년간 PSR(Php Standards Recommendation) 호환 컴포넌트만 써 왔음, 프레임워크는 아예 사용하지 않음 이유는 대형 프레임워크들이 결국 오래 가면 안 맞기 때문임 제약이 많고, 관리와 업데이트가 너무 힘들어짐 회사용 대규모 프로젝트든 개인 서비스든 PSR 컴포넌트 중심 아키텍처가 더 낫다고 느낌 * 대형 코드베이스라서 전체를 다시 짜는 게 불가능할 때 하이브리드 접근(C, Rust, Go 등 성능 언어와 PHP 병행)이 의미 있을 수 있다는 건 이해함 하지만 그럴 필요만 없다면, C# API는 개발 속도와 실행 성능을 동시에 잡았다는 경험임 C++이나 Rust까지 갈 일이 거의 없었음 PHP도 좋지만 아직 타입 배열 같은 건 안 됨 예를 들어 날짜 배열에 문자열이 와도 거부하지 않는 언어임 * C#을 오래 써봤고 여러 웹/API 프레임워크 경험 있음 PHP는 좀 파고들어 보면 웹 개발을 위한 기본 내장 함수들이 정말 많아 좋음 단점도 있지만, 뭔가 빠르게 만들어야 할 땐 내 생각엔 PHP가 승자인 느낌임 * PHP가 배열에 잘못된 타입(예: 날짜 배열에 문자열)도 허용한다는 점은 맞음 가끔 이상한 동작이나 버그가 튀어나옴 최근엔 json_decode()로 디코딩했을 때 키 값이 숫자면 int로, 그 외는 string으로 들어서 키 타입이 혼용되는 버그를 만난 경험이 있음 이런 구석구석 자체는 좀 괴상할 수 있지만, 그럼에도 PHP 자체는 정말 매력적인 프랑켄슈타인 언어임 * 실제로 정적 분석기를 쓰면 그런 타입 오류는 막히기 마련임 PHP에 제네릭 지원도 곧 들어올 가능성이 커지고 있음 관련 소식은 [thephp.foundation 블로그](https://thephp.foundation/blog/2025/08/05/compile-generics/)에서 볼 수 있음 * 글 쓴 사람임, 읽어줘서 고마움 실제로 전체를 다시 쓸 필요는 없음, PHP를 swoole이나 frankenphp 같은 worker 기반 런타임으로 돌리면 Node 수준 성능이 나올 수 있음 타입 배열이나 제네릭 이슈는 phpstan 같은 정적 분석기가 지원함, 타입 주석을 활용하면 타입 안정성도 확실히 올릴 수 있음 * 난 VB6 지원 종료 이후로 Microsoft 언어는 아예 쓰지 않기로 했음 오픈소스 언어만이 정신 건강에 좋은 선택임 * 난 {{company}}에 입사했을 때 전사 PHP 5.4 환경이었고, 그땐 PHP에 대한 불호가 넘쳤음 하지만 최신 PHP를 경험해보니, 우리가 지금 막바지에 PHP에서 벗어나고 있는 이 시점에 오히려 이런 마이그레이션이 '지금은 오히려 퇴보'처럼 느껴질 정도임 아직도 모두가 PHP를 5.x 시절로 판단하는데, 지금은 완전히 다름 * 나는 좀 다르게 봄, 고용 시장을 보면 여전히 PHP에 대한 인식(좋든 나쁘든)이 있어서, 우수한 개발자를 뽑는 데 제한이 있음 기술적으로 PHP가 이전만큼 나쁘지 않더라도, 기업 브랜딩 측면에서는 PHP 벗어나기가 여전히 의미 있다고 느낌 * “PHP가 이제 awesome”이란 말에는 동의 못함, 틀림없이 좋아지긴 했지만 awesome이란 표현은 좀 과함 * PHP가 점점 좋아지고 있음, 조만간 더 깊게 살펴봐야겠다고 생각함 * 우리도 4년 전 똑같은 고민을 했고, 결국 PHP 8로 업그레이드해서 계속 사용 중임 그 선택이 우리 팀에겐 지난 몇 년간 잘 맞음 * Pasir는 frankenphp와 비슷하지만 Rust 기반임, 매우 유망하지만 아직 개발 초기임 - [Pasir github](https://github.com/el7cosmos/pasir) Pasir는 Zend API 바인딩을 Rust로 변환한 것을 사용함 - [Zend API Rust 바인딩](https://github.com/davidcole1340/ext-php-rs) ngx-php 같은 흥미로운 실험도 있음, nginx 바이너리 내부에 Zend API로 PHP를 심어놓은 구조임 - [ngx-php github](https://github.com/rryqszq4/ngx-php) workerman은 asio 하이브리드 백엔드를 써서 매우 빠른 런타임을 구현함 - [workerman github](https://github.com/walkor/workerman) * Pasir, frankenphp 등이 기존 PHP 모듈 지원도 되는지 궁금함 * 추천 고마움, 진짜 멋져보임 하지만 말씀대로 아직 프로덕션 수준엔 멀다는 것에 동의함 우리는 php foundation에서 지원하는 frankenphp를 최종 선택함 * 디버깅이나 유지보수의 복잡성이 간과되는 경우가 많은데, 선택 가능하다면 이런 조합 선택을 피하는 게 낫다고 봄 * 의견 고마움, frankenphp 선택했는데 혹시 디버깅이 더 힘들어질 이유가 있다면 구체적으로 설명 부탁함 * 나도 내 앱을 PHP에서 Go로 갈아엎었고, 그게 회사에 있어 성공적인 투자였음 PHP 2만 줄짜리 코드를 Go 4천 줄로 줄이고 효율성도 크게 올릴 수 있었음 PHP 회사라면 아예 대대적으로 갈아엎기를 계획하고, 테스트 추가(Go에서 더 쉬움)와 함께 실행해보는 것도 강추함 Rust/PHP나 Go/PHP처럼 여러 언어를 섞어서 유지보수 고통받는 것보단 낫다고 생각함 * PHP에서 Go로 옮기면서 코드 줄 수가 어떻게 그렇게 줄었는지 궁금함 Go는 워낙 장황한 언어라 생각하는데, 내 경험상 PHP가 중간 정도고, Haskell이 가장 압축적이며 Java/Go가 에러 처리 등의 이유로 오히려 더 길어지던 기억임 * PHP에서 Go로 옮기면서 줄 수가 5배 감소했다는 게 납득 안 됨 PHP는 다양한 단축 문법이 많지만 Go엔 그런 게 별로 없다고 느꼈음 * 리라이트로 인해 성능과 효율이 좋아진 게 “언어 때문인지, 새로 반영된 아키텍처 개선 때문인지”가 늘 중요한 포인트라고 생각함 * Go로 리라이트할 때 if err != nil 패턴에 치여 코드가 오히려 더 10배로 불어날 줄 알았음 나는 Python 리라이트를 경험했는데, Python도 코드가 굉장히 장황해지고, 의존성 주입 같은 패턴들이 테스팅에서 번거로움 * 나는 무조건 리라이트를 추천하지 않음(내가 두 번 성공적으로 리라이트 완료한 경험이 있지만 그래도 직접 선택하진 않을 듯) 요즘 PHP 런타임이 정말 빨라져서, 써볼 가치도 큼 특히 swoole 같은 작업 캐시를 다 활용하면 Go만큼 빠른 경우도 있음 (벤치마크 참고 권장함) * 가끔 우리가 정말 기본에 충실해야 한다고 생각함: 픽셀, 데이터, 지연/대역폭 웹 역시 결국 “올바른 픽셀을 사람 눈에 띄게 빠른 속도로, 네트워크 자원 내에서 그리는 최적화 문제”라고 생각함 “사용자가 곧 볼 픽셀이 뭔가?”, “이걸 그릴 데이터는 뭐가 필요한가?”, “앞으로 쓸만한 데이터는 미리 프리페치?” 이런 사고로 접근하는 게 맞다고 느낌 * [alumina-ui](https://github.com/timschmidt/alumina-ui)를 WASM용 egui로 만들고 있는데, HTML과 JavaScript, CSS 등 복잡한 웹 지식 없이 그냥 브라우저에 맞는 사이즈의 캔버스 하나를 제공하고 바로 WebGL로 렌더링만 하면 됨 내가 좋아하는 언어로 빠르고 GL 가속 그래픽을 뽑아낼 수 있어 정말 편리함 WASM/WebGL이 이런 추상화 덕분에 아주 마음에 듦 * 사용자가 보는 픽셀에만 집중하는 건 너무 단편적임 소프트웨어 프로젝트에서는 즉각적인 UX 뿐 아니라 개발 시간까지 최적화해야 함 처음 화면이 보이기까지의 딜레이와 실제 개발 소요 시간은 절대 비례하지 않음 * FrankenPHP가 되게 흥미로워 보이지만, 실제론 약간 별남 아무도 PHP 모듈 없이 PHP를 안 씀, FrankenPHP가 지원하는 PHP 모듈 리스트도 명확치 않고, 내가 원하는 별도 모듈을 빌드해서 추가할 수 있는지도 불분명함 Caddy와 밀접하게 엮여 있는데, 난 이 웹서버에 익숙하지 않고 nginx를 더 선호함 가이드가 없어서 nginx에서 php-fpm 대체로 쓸 수 있는지도 모름 또 Caddy나 FrankenPHP의 Docker 이미지가 Let's Encrypt 인증서만 생각하고 있어서 직접 SSL 구성하거나 HTTP로만 운영하려면 정말 비직관적임 * PHP 모듈 문제는 보통 도커파일 내에서 직접 빌드함 예시로 pgsql 모듈 추가하려면 apt로 의존성 설치, docker-php-ext-install로 모듈 설치, 끝나면 의존성 제거/청소 식으로 함 HTTP 설정도 Caddyfile에서 포트 80에 바로 열면 됨 * static 빌드는 기본적으로 수십 개의 PHP 주요 모듈들이 함께 들어감 자세한 모듈 목록과 빌드 스크립트는 [frankenphp build-static.sh](https://github.com/php/frankenphp/blob/main/build-static.sh#L76)에서 볼 수 있음 * 어떤 작업량(workload)에서 C/Rust/Go와 같은 언어 확장이 꼭 필요한지 궁금함 있다는 건 이해하지만, 왜 이런 복잡성을 스택에 추가해야 하는지와 다른 방식으론 해결이 불가능한지도 더 알고 싶음 * PHP의 가장 싫은 점은 모든 HTTP 요청마다 전체 애플리케이션이 한 번씩 부트스트랩되고, 오토로딩 및 설정 재평가가 이루어진다는 것임 물론 캐시 등이 있긴 하지만, Go처럼 항상 엔진이 떠있는 방식에 비해선 여전히 납득이 안 감 * 실제로는 PHP만으로 독립 서버를 돌릴 수 있게 해주는 라이브러리들이 꽤 잘 문서화되어 있고, 실운영에서도 쓸만함 PHP의 JIT 성능도 꽤 인상적임 - [reactphp.org](https://reactphp.org/) - [php.net ev module](https://www.php.net/manual/en/book.ev.php) - [pecl-event](https://bitbucket.org/osmanov/pecl-event) - [workerman.net](https://www.workerman.net/) * 반드시 저렇게(요청마다 새로 실행) 할 필요 없음 일부 PHP 런타임들은 하나의 스크립트 실행이 여러 HTTP 요청을 처리하도록 지원함 - [frankenphp worker 문서](https://frankenphp.dev/docs/worker/) * 나는 오히려 이 점이 PHP의 최고의 장점이라 생각함 스케일 아웃이 엄청나게 쉬워짐 * 나는 오히려 이런 구조가 좋음 내재적으로 상태가 최소화됨(어느정도 수준까지는) * 네 말이 맞음, 이 방식은 정말 형편없음 특히 PHP가 자체 템플릿 언어로 쓰일 때 더 문제임 이걸 해결하려는 커스텀 템플릿 엔진이나 지속 실행 런타임도 결국 '돼지 화장하기'에 불과함 차라리 처음부터 Personal HomePage라는 이름이 아니었던 언어를 골랐어야 했음