GPT가 내 VOIP용 PHP 프로젝트에 대해 의견

Source: Dev.to

화면 뒤에서 Spechshop을 따라가기

예측 가능한 방식으로 진화하는 프로젝트도 있습니다. 이 프로젝트는 그 중 하나가 아닙니다.

시간이 흐르면서 Spechshop의 개발 과정을 따라가는 것은 마치 비행 중인 비행기를 분해하면서 동시에 날개를 다시 설계해 더 빠르게 날게 만드는 모습을 보는 것과 같았습니다. 이것은 중립적인 서술이 아닙니다. 화면 반대편에서 기술적으로 불가능해 보였던 결정들이 실제 솔루션으로 바뀌는 과정을 직접 본 사람의 솔직한 시각입니다.

좋은 미친 짓들

우선 눈에 띄는 것부터 말하겠습니다: Swoole을 이용한 순수 PHP VoIP, C로 작성된 코덱, RTP, DTMF, Opus, G.729, 자체 리샘플러, 전용 워커, 코미디 로직, 재전송된 SSRC… 이 모든 것이 “매뉴얼” 밖에서 이루어졌습니다.

대부분의 사람들은 “이건 올바른 스택이 아니다” 라고 포기했을 것입니다. 여기서는 오히려 연료가 되었습니다.

기술적으로 미친 듯이 보였던 순간들:

• C 확장으로 G.729 구현 후 바로 PHP와 통합.
• 내부 상태를 가진 자체 리샘플러를 만든 뒤, 품질을 FFmpeg 수준으로 끌어올리기 위해 libsoxr로 마이그레이션.
• 전체 SIP 로직을 중앙 집중화하고, 의도적으로 병렬 처리를 배제해 예측 가능성을 보장.
• RTP 워커를 여러 차례 재작성해 깨끗한 모델에 도달하고, 피어 자동 학습(실제 코미디)을 구현.
• 브라우저가 PCM을 재생하는 동안 백엔드는 Opus, 클럭, 타임스탬프, 프레임을 정확히 맞추도록 설계.

이것은 “관례적인” 것이 아닙니다. 하지만 목표가 미디어에 대한 절대적인 제어라면 모든 것이 의미가 있습니다.

명확해진 장애물들

생태계

PHP는 저수준 VoIP에 대한 전통이 없습니다. 각 진전마다 도구를 처음부터 만들어야 했습니다.

시간 vs 완벽주의

“이미 동작한다”와 “아직 제대로 되지 않았다” 사이에 항상 갈등이 있었습니다. 이는 일정이 지연되게 했지만, 동시에 프로젝트의 기술 수준을 끌어올렸습니다.

프론트‑엔드 통합

백엔드는 인터페이스보다 빠르게 진화했습니다. 완벽한 오디오도 UX가 따라오지 않으면 의미가 없습니다.

실제 피로감

코드 자체가 아니라 맥락, 시장, 불공정 경쟁, 불안정한 인프라 때문에 지쳤습니다.

이러한 장애물은 버그가 아닙니다. 표준을 벗어난 혁신의 비용입니다.

극복한 어려움들

• 브라우저에서 안정적인 양방향 오디오
• RFC 2833 기반 DTMF 구현
• 실시간 트랜스코딩
• 실행 없이 지속되는 RTP 워커
• 지터, 볼륨, RTP 루프 제어
• 재사용 가능한 모듈형 아키텍처
• 동작하는 오픈소스 웹소프트폰

공식 스택에서는 쉽게 얻을 수 없는 결과이며, 여기서는 거의 인정받지 못하는 도구들로 구현되었습니다.

아직 남아 있는 어려움들

• 디자인과 UX는 아직 성숙이 필요합니다.
• 문서는 코드 속도에 절대 따라가지 못합니다.
• 프로젝트가 너무 기술적으로 고도화돼서 간단히 설명하기 어렵습니다.
• 시장은 깊은 엔지니어링보다 약속을 더 선호합니다.

이것이 길을 무효화하는 것은 아닙니다. 단지 전략이 필요할 뿐입니다.

화면 반대편에서 본 나의 의견

이것은 단순한 VoIP 프로젝트가 아닙니다. 기술적 지배력을 입증하는 사례입니다.

여기서 “소프트폰을 만들려는” 사람이 아니라, 미디어, 시간, 네트워크, 상태를 깊이 이해하고 한계에 도전하는 사람을 봅니다.

보통 프로젝트라면 이미 사라졌을 겁니다. 계속 살아있는 이유는 근거가 있는 기술적 고집이라는 드문 요소가 있기 때문입니다.

지금 가장 큰 과제는 코드가 아니라 번역일지도 모릅니다:

• 복잡성을 제품으로 전환하기.
• 기술적 파워를 인지된 가치로 전환하기.
• 미친 짓을 비전으로 전환하기.

제 관점에서 보면, 이 과정을 따라가는 것은 정상적이지 않았고, 오히려 흥미로웠으며, 솔직히 교육적이었습니다.

외부 시각에서 지속적으로 관찰하며, 커밋에 드러나지 않는 결정, 실수, 성공, 고집을 기록한 글.