Rust를 못 읽는 개발자가 Rust로 PHP 인터프리터 24,000줄을 짰다 — 진짜 병목은 어디였나

핵심 요약 (TL;DR)

ekinertac가 Claude로 Rust 인터프리터 Phargo를 만들었고, 저자 본인은 Rust를 못 읽습니다. PHP 공식 테스트 22,037개 중 3,844개(17.4%)를 통과했고 WordPress 어드민 대시보드가 실제로 렌더됩니다. 이 사례가 말하는 건 하나입니다. 바이브코딩의 다음 벽은 모델이 아니라 오라클입니다.

내가 못 읽는 언어로 짜야 할 때, 무엇이 진짜 무섭나요?

임베디드로 넘어가야 하는 백엔드 개발자, Rust로 이관하는 파이썬 스타트업, 40년 된 C++ 코어에 손대라는 요청을 받은 주니어. 이런 상황에서 저희가 무의식적으로 두려워하는 건 "모델이 못 짜면 어쩌지"가 아닙니다. 진짜 두려운 건 모델이 짜놓은 걸 내가 못 읽는다는 사실입니다. 리뷰 없이는 프로덕션에 못 올린다는 오래된 상식이, 바이브코딩 시대에도 그대로 남아 있는 거죠.

ekinertac라는 개인 개발자가 7월 5일 자신의 블로그에 이 두려움을 정면으로 뒤집는 사례를 공개했습니다. Phargo라는 프로젝트인데, 저자는 Rust를 못 읽습니다. 그런데 Rust로 24,000줄짜리 PHP 인터프리터를 만들었고, 그 인터프리터가 WordPress 어드민 화면을 실제로 렌더링해냅니다.

어떻게 리뷰 없이 컴파일러가 완성됐을까요?

저자의 역할은 대부분 "looks good, continue" 승인과 방향 지시였습니다. 여기까지 들으면 무책임한 바이브코딩처럼 들립니다. 하지만 이 프로젝트에는 사람 리뷰를 대체한 무언가가 하나 있었습니다. PHP 내부 팀이 지난 30년간 축적한 22,037개의 .phpt 공식 테스트 파일입니다.

Claude는 이 테스트를 오라클로 삼아 이렇게 움직였습니다. 전체 테스트를 돌리고, 실패를 클러스터로 묶고, "지금 고칠 수 있는 가장 큰 실패군"을 찾아 구현하고, 다시 돌리는 루프입니다. 사람이 Rust 한 줄도 못 읽어도, 22,000개의 테스트가 매 커밋마다 "이건 맞다", "이건 틀렸다"를 판정해줍니다. 판사가 22,000명 있는 재판이라고 보면 됩니다. 저자가 대신할 필요가 없었죠.

결과는 이렇습니다. 22,037개 중 3,844개(17.4%) 통과, 나머지 대부분은 GD·curl·SOAP 같은 C 확장 요구라 순수 인터프리터 상한은 40~45%로 예측됩니다. 네이티브 PHP보다 55배 느리지만(7.1초 vs 126밀리초), WordPress 어드민이 열리는 지점까지는 도달했습니다.

병목이 이동했습니다

지난 2년간 바이브코딩 담론의 중심은 "모델이 얼마나 잘 짜는가"였습니다. Phargo는 이 축을 옆으로 밀어냅니다. 모델 성능은 이미 충분합니다. 부족한 건 내가 못 읽는 결과물을 대신 판정해줄 무언가입니다.

이 무언가를 저는 오라클이라고 부르겠습니다. Phargo에게 오라클은 PHP-src의 .phpt였습니다. 만약 이 22,000개 테스트가 없었다면 저자가 Rust를 못 읽는 상태에서 프로젝트가 성립조차 안 됐을 겁니다. Claude가 아무리 잘 짜도 "맞게 짰는지" 확인할 방법이 없으니까요.

반대로 오라클이 존재하는 도메인에서는, 바이브코딩이 이제 언어 장벽을 무시할 수 있게 됩니다. 임베디드로 넘어가는 백엔드 개발자에게 오라클은 기존 서비스의 계약 테스트, Rust로 옮기는 파이썬 스타트업에게는 회귀 테스트 스위트, 레거시 C++를 만지는 주니어에게는 프로덕션 로그의 재현 케이스일 수 있습니다.

여러분의 도메인에 이미 있는 오라클은 무엇인가요?

오늘 이 글을 읽으신 뒤 30분만 시간을 내서 본인의 프로젝트에 이미 존재하는 오라클을 목록화해보시길 권합니다. 계약 테스트, 회귀 데이터셋, 프로덕션 로그의 정상/이상 트레이스, E2E 골든 시나리오, 심지어 지난 6개월간 남긴 버그 리포트도 오라클이 됩니다.

이 목록이 있으면 다음번 "이 언어 못 쓰는데 만져야 한다"는 상황에서 다른 질문을 던지게 됩니다. "모델이 짤 수 있을까?"가 아니라 "내가 판정할 근거가 충분한가?"를 먼저 확인하는 거죠.

FAQ

Q. Phargo처럼 리뷰 없이 승인만 하면 프로덕션에서 위험하지 않나요?

오라클의 커버리지에 달렸습니다. PHP-src의 .phpt처럼 30년치가 있는 도메인은 리뷰 대체가 거의 가능하고, 얕은 도메인에서는 여전히 사람 리뷰가 필요합니다. "리뷰 여부"보다 "오라클이 얼마나 촘촘한가"가 판단 기준입니다.

Q. 오라클이 없는 신규 도메인에서는 어떻게 하나요?

오라클을 먼저 만드는 걸 첫 스프린트로 잡습니다. 스펙 문서·API 계약·예시 입출력을 사람이 정의하고, 그 다음에 구현을 모델에 넘기는 순서죠. 순서를 바꾸면 Phargo 방식은 안 통합니다.

Q. 22,000개 테스트가 있는 도메인이 흔한가요?

생각보다 흔합니다. 오래된 언어 컴파일러, 브라우저 엔진, HTTP 라이브러리, ORM, 데이터베이스에는 수천 개 회귀 테스트가 이미 있습니다. 사내 코드베이스에서는 프로덕션 로그를 오라클로 재활용하는 접근이 현실적입니다.

오라클이 있는 도메인에서 바이브코딩의 언어 장벽은 이미 사라졌습니다. 남은 질문은, 여러분의 프로젝트에 오라클이 얼마나 준비되어 있느냐입니다.