하이브리드 PHP의 부상: PHP와 Go, Rust의 결합

(yekdeveloper.com)

6P by GN⁺ 13시간전 | ★ favorite | 댓글 4개

최근 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 마이크로서비스 분리 등 다양한 방법을 도입함
하지만 복잡성과 운영 부담 측면에서 한계가 존재함

전체 Go 또는 Rust로의 완전 이관이 아닌 이유

전체 재작성 비용과 위험 부담 높음
- 이미 크고 안정적인 애플리케이션을 완전히 Go나 Rust로 바꾸는 것은 리스크와 자원 소모가 큼
PHP 자체에 여전히 강점 존재
- 대부분의 업무에서는 PHP의 빠른 개발, 친화적인 생태계, 충분히 빠른 속도가 여전히 경쟁력이 됨
- 진정한 성능 한계가 필요한 일부 영역만 Go, Rust로 하이브리드 구성하면 전체 이관 필요성 해소 가능

결론: 하이브리드 PHP의 가치

현대 PHP 생태계는 빠른 개발 생산성과 함께 고성능(C, Rust, Go) 확장 연동 옵션을 모두 제공
이런 하이브리드 구조로 속도와 생산성 모두 확보 가능
PHP 중심의 개발을 유지하면서 필요 시 언어 선택적 확장이 가능한 새로운 아키텍처 패러다임 제시

▲

naearu 5시간전 [-]

뭔가 자바스크립트가 변해가는것 처럼 되어가는거같네요.

답변달기

▲

skageektp 10시간전 [-]

nodejs에 rust면 몰라도;; 저는 php가 $같은게 계속 쓰이니 코드 치기가 불편해보이는데 잘 쓰시는 분들은 별로 불편함을 못느끼는 편인가요?

답변달기

▲

nemorize 9시간전 [-]

저는 PHP의 변수/함수 개념 그 자체에 불편함을 느끼면 느꼈지, $ 표현법에 불편함을 느껴본 적은 전혀 없습니다.

달러 때문에 불편해서 못쓰겠다, ~~달러 표시를 쓰는 애들이라 돈을 많이 번다, 미국달러가 아니라 짐바브웨 달러라서 별로 못번다~~ 하는 이야기는 우스갯소리로 하는 이야기들 아니었나요...

답변달기

▲

GN⁺ 13시간전 [-]

Hacker News 의견

나는 범용적인 프레임워크(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 블로그에서 볼 수 있음
- 글 쓴 사람임, 읽어줘서 고마움 실제로 전체를 다시 쓸 필요는 없음, 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 Pasir는 Zend API 바인딩을 Rust로 변환한 것을 사용함
Zend API Rust 바인딩 ngx-php 같은 흥미로운 실험도 있음, nginx 바이너리 내부에 Zend API로 PHP를 심어놓은 구조임
ngx-php github workerman은 asio 하이브리드 백엔드를 써서 매우 빠른 런타임을 구현함
workerman github
- 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를 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에서 볼 수 있음
어떤 작업량(workload)에서 C/Rust/Go와 같은 언어 확장이 꼭 필요한지 궁금함 있다는 건 이해하지만, 왜 이런 복잡성을 스택에 추가해야 하는지와 다른 방식으론 해결이 불가능한지도 더 알고 싶음
PHP의 가장 싫은 점은 모든 HTTP 요청마다 전체 애플리케이션이 한 번씩 부트스트랩되고, 오토로딩 및 설정 재평가가 이루어진다는 것임 물론 캐시 등이 있긴 하지만, Go처럼 항상 엔진이 떠있는 방식에 비해선 여전히 납득이 안 감
- 실제로는 PHP만으로 독립 서버를 돌릴 수 있게 해주는 라이브러리들이 꽤 잘 문서화되어 있고, 실운영에서도 쓸만함 PHP의 JIT 성능도 꽤 인상적임

reactphp.org
php.net ev module
pecl-event
workerman.net
- 반드시 저렇게(요청마다 새로 실행) 할 필요 없음 일부 PHP 런타임들은 하나의 스크립트 실행이 여러 HTTP 요청을 처리하도록 지원함
frankenphp worker 문서
- 나는 오히려 이 점이 PHP의 최고의 장점이라 생각함 스케일 아웃이 엄청나게 쉬워짐
- 나는 오히려 이런 구조가 좋음 내재적으로 상태가 최소화됨(어느정도 수준까지는)
- 네 말이 맞음, 이 방식은 정말 형편없음 특히 PHP가 자체 템플릿 언어로 쓰일 때 더 문제임 이걸 해결하려는 커스텀 템플릿 엔진이나 지속 실행 런타임도 결국 '돼지 화장하기'에 불과함 차라리 처음부터 Personal HomePage라는 이름이 아니었던 언어를 골랐어야 했음

답변달기

하이브리드 PHP의 부상: PHP와 Go, Rust의 결합

배경 및 기존 아키텍처

성능 병목 지점과 기존 대응 방식

최신 PHP 생태계의 하이브리드 옵션

1. FFI (Foreign Function Interface)

2. Rust 기반 확장

3. Go 기반 확장: FrankenPHP

전체 Go 또는 Rust로의 완전 이관이 아닌 이유

결론: 하이브리드 PHP의 가치

Hacker News 의견