php-src 딥다이브
— 한 줄의 PHP가 실행되기까지

1프로젝트 한줄 요약

php-src는 PHP 소스 코드를 읽고 실행하는 인터프리터의 공식 구현입니다. 웹사이트의 게시판이나 로그인 화면을 만드는 애플리케이션이 아니라, 그런 애플리케이션을 실행하는 프로그램 자체를 C 중심으로 구현한 저장소입니다.

PHP는 실행할 코드를 먼저 내부 명령으로 컴파일한 뒤 가상 머신으로 실행합니다. 따라서 “인터프리터니까 컴파일 단계가 없다”고 생각하면 이 저장소의 절반을 놓칩니다. 어휘 분석기, 파서, 컴파일러, 실행기, 메모리 관리기가 모두 등장합니다.

1-1. 같은 언어가 여러 환경에서 실행되는 이유

예를 들어 CLI의 일반 파일 실행 경로는 sapi/cli/php_cli.c에서 php_request_startup()을 호출하고, php_execute_script()로 파일을 실행합니다. 웹 요청이 아니어도 엔진 내부에서는 “요청을 시작하고 끝내는 단위”를 사용합니다.

2왜 주목받는가

2-1. 최근 릴리스와 개발 브랜치를 동시에 볼 수 있다

선정 근거는 TrendShift Daily #23, 분석일 2026-10-23입니다. GitHub 메타에는 이틀 전인 2026-10-21의 php-8.5.12 릴리스와 2026-10-23의 최근 push가 기록되어 있습니다. 다만 이 정보만으로 어떤 기능이나 사건이 트렌딩을 일으켰다고 확정할 수는 없습니다.

학습 자료로서의 해석: 안정 릴리스가 배포되는 동안에도 다음 개발 버전의 코드가 움직이고, 여러 브랜치를 대상으로 CI를 운영하는 모습을 함께 관찰할 수 있습니다. “유명한 언어”라는 사실보다 성숙한 실행기를 계속 바꾸면서 호환성을 지키는 방법이 좋은 공부거리입니다.

2-2. 비슷한 실행기를 공부한다면 무엇이 다를까?

아래는 학습 관점의 구조 비교입니다. 처리량이나 메모리 사용량을 측정한 순위표는 아닙니다. 선택 기준을 “내가 설명하고 싶은 실행 모델이 무엇인가”에 두면 각 구현의 장점이 보입니다.

php-src의 장점은 언어 처리 파이프라인과 웹 실행 환경이 한 저장소에서 연결된다는 점입니다. 반대로 학습량도 큽니다. 처음부터 모든 확장과 JIT를 이해하려 하기보다 출력문 하나를 끝까지 따라가는 편이 시작하기 쉽습니다.

2-3. 23,655개의 실행 가능한 사례집

커밋 02207318의 .phpt 파일은 23,655개입니다. 그중 ext/에 16,675개, Zend/에 5,707개, tests/에 904개, sapi/에 369개가 있습니다. 이 숫자는 테스트 파일 수이며, 서로 독립적인 버그 수나 테스트 통과 건수를 뜻하지 않습니다.

큰 저장소에서는 설명 문서와 함께 작은 회귀 테스트를 읽어야 실제 동작의 경계가 보입니다. 문자열 길이 테스트만 보아도 빈 문자열, NUL 바이트, 공백처럼 쉽게 놓치는 입력을 만날 수 있습니다.

3기술 스택 전체 지도

3-1. 백엔드: C11로 만든 실행기와 C/C++ 확장

중심 구현 언어는 C입니다. configure.ac:124–126은 C11을 받아들이지 못하는 컴파일러에서 설정을 중단합니다. ext/intl/config.m4에는 C++ 소스 목록과 PHP_REQUIRE_CXX()도 등장합니다. 따라서 “전부 순수 C”보다는 C 중심이며 일부 확장에 C++를 사용하는 프로젝트라고 읽는 편이 정확합니다.

3-2. 프론트엔드: 서비스 화면과 컴파일러 앞단은 다른 뜻이다

이 저장소에는 React·Vue 같은 제품 화면용 프론트엔드 앱이 없습니다. 추적 파일 목록에서 package.json, Cargo.toml, go.mod, pyproject.toml, composer.json은 발견되지 않았습니다. 그렇다고 PHP 생태계 전체가 Composer를 쓰지 않는다는 뜻은 아닙니다. 이 저장소의 빌드 방식에 대한 관찰입니다.

컴파일러 분야의 프론트엔드는 별개입니다. Zend/zend_language_scanner.l이 글자를 토큰으로 나누고, Zend/zend_language_parser.y가 토큰을 AST로 묶습니다. 개발 문서 사이트는 docs/requirements.txt에 적힌 Sphinx와 테마로 생성합니다. 이 파일의 네 의존성은 버전이 고정되어 있지 않습니다.

3-3. 의존성 버전: 최소 요구와 번들 버전을 구분하자

이 값들은 빌드 검사에 명시된 요구 버전과 번들 소스의 버전입니다. 특히 >= 조건은 “이 버전 하나로 고정”을 뜻하지 않습니다. README는 최소 빌드에 Autoconf·Bison·re2c, 기본 빌드에 libxml2·libsqlite3가 더 필요하다고 설명합니다. 실제 활성화할 확장에 따라 추가 라이브러리는 달라집니다.

3-4. 인프라·빌드: 운영체제 차이를 설정 단계에서 처리한다

위는 Git 체크아웃에서 시작하는 Unix 계열의 대표 빌드 흐름입니다. Windows는 buildconf.bat, win32/build/config.w32 등 별도 경로를 사용합니다. buildconf의 설명대로 공식 릴리스 압축 파일에는 생성된 configure가 포함되어 있어 Git 체크아웃과 준비 단계가 같지 않습니다.

.github/workflows/test.yml은 브랜치별 행렬을 생성하고 .github/workflows/test-suite.yml을 재사용합니다. 확인한 설정에는 actions/checkout@v6, actions/cache@v5, alpine:3.22, clang-20, mysql:8.4가 나옵니다. ASan·UBSan, debug/release, ZTS/NTS 조합을 다루며 이 값들은 CI 설정값입니다.

ext/opcache/jit/Dockerfile.arm64.example의 기본 이미지는 ubuntu:20.04이고, benchmark/docker-compose.yml에는 mysql:8.0이 있습니다. 각각 JIT 실습 예시와 벤치마크용 보조 서비스입니다. 프로젝트 전체를 배포하는 단일 Docker 환경으로 해석하면 안 됩니다.

실행기의 의존성은 패키지 목록뿐 아니라 빌드 검사와 확장 선택 조건까지 읽어야 파악됩니다.

4아키텍처 심화 분석

4-1. 시스템 구조도: 입력에서 출력까지

위 그림은 대표 경로를 줄여 그린 것입니다. 그림의 외부 웹서버는 php-src 밖의 구성 요소이고, FPM은 웹서버와 FastCGI로 통신하는 PHP 실행 환경입니다. OPcache를 사용할 수 있는 상황에서는 저장된 컴파일 결과를 재사용합니다. 모든 요청이 항상 어휘 분석부터 다시 시작하는 것은 아닙니다.

4-2. 설계 ① SAPI: 환경 차이를 함수 포인터 표로 감싼다

main/SAPI.h:230의 sapi_module_struct는 출력·헤더·입력·로그 같은 동작을 함수 포인터로 받습니다. C에 클래스가 없어도 “공통 인터페이스 + 환경별 구현”을 만들 수 있습니다. 어댑터나 전략 패턴으로 이해할 수 있는 구조입니다.

// main/SAPI.h — 구조체 필드 일부 발췌
size_t (*ub_write)(const char *str, size_t str_length);
void (*flush)(void *server_context);
size_t (*read_post)(char *buffer, size_t count_bytes);
char *(*read_cookies)(void);
void (*register_server_variables)(zval *track_vars_array);

sapi/cli/php_cli.c:407의 cli_sapi_module은 여기에 sapi_cli_ub_write, sapi_cli_flush 등을 꽂습니다. 엔진은 “지금 출력이 터미널로 가는가, FastCGI로 가는가”의 세부 구현을 몰라도 됩니다.

main/main.c의 모듈 시작 코드가 Zend 쓰기 콜백에 php_output_write를 연결하고, main/output.c가 버퍼를 처리한 뒤 sapi_module.ub_write를 호출합니다. echo를 무조건 C의 printf() 한 번으로 설명할 수 없는 이유입니다.

같은 어댑터 위에서 지키는 수명 주기

sapi/fpm/fpm/fpm_main.c:1804는 fcgi_accept_request() 반복문 안에서 요청 시작·실행·종료를 호출합니다. 작업 프로세스는 여러 요청을 받을 수 있지만 각 요청의 상태는 따로 정리합니다. 이를 “매 요청마다 운영체제 프로세스를 새로 만든다”와 혼동하지 마세요.

4-3. 설계 ② 파이프라인: 문법과 실행을 중간 표현으로 분리한다

추적할 예제는 echo $message;입니다. 파서는 “문자열을 화면에 쓰는 C 코드”를 바로 실행하지 않습니다. 먼저 ZEND_AST_ECHO 노드를 만듭니다.

// Zend/zend_language_parser.y:1205 — 문법 규칙 발췌
echo_expr:
    expr { $$ = zend_ast_create(ZEND_AST_ECHO, $1); }
;

Zend/zend_language_scanner.l의 compile_file()은 파일을 스캐너에 연결한 뒤 zend_compile()로 들어갑니다. 그 안에서 zendparse()가 성공하면 zend_compile_ast_internal()이 zend_compile_top_stmt()를 호출해 AST를 명령 배열로 바꿉니다.

// Zend/zend_compile.c:6400 — 출력문 컴파일 함수
static void zend_compile_echo(const zend_ast *ast)
{
    zend_op *opline;
    zend_ast *expr_ast = ast->child[0];

    znode expr_node;
    zend_compile_expr(&expr_node, expr_ast);

    opline = zend_emit_op(NULL, ZEND_ECHO, &expr_node, NULL);
    opline->extended_value = 0;
}

앞의 표현식을 컴파일하고 ZEND_ECHO 명령을 추가합니다. 결과는 zend_op_array에 담깁니다. Zend/zend.c:1977의 zend_execute_script()를 보면 zend_compile_file()로 그 배열을 얻어 zend_execute()에 넘깁니다.

// Zend/zend_vm_def.h:1696 — ZEND_ECHO의 문자열 처리 분기 발췌
if (Z_TYPE_P(z) == IS_STRING) {
    zend_string *str = Z_STR_P(z);

    if (ZSTR_LEN(str) != 0) {
        zend_write(ZSTR_VAL(str), ZSTR_LEN(str));
    }
}

전체 핸들러에는 문자열이 아닌 값의 변환, 피연산자 정리, 예외 확인도 있습니다. 여기서는 파서의 의미 노드 → 컴파일러의 opcode → VM의 동작이 연결된다는 점을 먼저 봅니다. 중간 표현을 두면 문법을 해석하는 규칙과 실제로 실행하는 규칙을 따로 발전시킬 수 있습니다.

4-4. 설계 ③ zval과 쓰기 시 복사: 값의 의미와 저장 비용을 함께 지킨다

Zend/zend_types.h:341의 zval은 zend_value라는 값 저장 공간과 타입 정보를 함께 가집니다. 정수·실수는 직접 담을 수 있고, 문자열·배열·객체는 다른 구조체를 가리킵니다. “PHP 변수는 타입이 바뀔 수 있는데 C 코드는 어떻게 처리하지?”에 대한 출발점입니다.

이 방식이 쓰기 시 복사(copy-on-write, COW)입니다. 대입하자마자 큰 배열을 모두 복사하지 않고, 공유 중인 값을 바꾸어야 할 때 분리합니다. 핵심 조건을 SEPARATE_ARRAY에서 확인할 수 있습니다.

// Zend/zend_types.h:1560 — 줄 맞춤만 정리한 매크로 발췌
#define SEPARATE_ARRAY(zv) do { \
    zval *__zv = (zv); \
    zend_array *_arr = Z_ARR_P(__zv); \
    if (UNEXPECTED(GC_REFCOUNT(_arr) > 1)) { \
        ZVAL_ARR(__zv, zend_array_dup(_arr)); \
        GC_TRY_DELREF(_arr); \
    } \
} while (0)

참조 수가 1보다 크면 배열을 복제하고 기존 배열의 참조 수를 줄입니다. 실제 대입·변경 경로에는 추가 조건이 있으므로 이 매크로만으로 모든 PHP 값의 동작을 설명할 수는 없습니다. 객체 대입, & 참조, 배열 안의 객체는 별도로 구분해야 합니다.

4-5. 설계 ④ 컴파일 훅: 기존 동작을 감싸서 캐시한다

Zend/zend_compile.c:90에서 zend_compile_file은 함수 포인터입니다. 일반적인 초기화에서는 compile_file을 가리키지만, OPcache 시작 코드가 원래 함수를 보관하고 새 함수로 바꿉니다. 기존 구현을 보존하며 기능을 덧붙이는 데코레이터와 비슷한 방식입니다.

// ext/opcache/ZendAccelerator.c:3658–3659
accelerator_orig_compile_file = zend_compile_file;
zend_compile_file = persistent_compile_file;

persistent_compile_file()은 캐시 상태와 파일 정보를 확인합니다. 캐시를 사용할 수 없으면 원래 컴파일러에 위임하고, 재사용 가능한 스크립트를 찾으면 그 컴파일 결과를 이용합니다. 기본 경로의 일부는 공유 메모리를 사용하며 파일 캐시 경로도 따로 있습니다.

위 설정의 기본값은 ext/opcache/zend_accelerator_module.c와 ext/opcache/jit/zend_jit.h에 정의되어 있습니다. OPcache는 컴파일 결과를 재사용하고, JIT는 실행 중 일부 코드를 기계어로 만드는 기능입니다. OPcache가 켜졌다는 사실만으로 JIT도 켜졌다고 결론 낼 수 없습니다.

확장 모듈도 같은 수명 주기에 참여한다

ext/json/json.c:74의 json_module_entry는 함수 목록 ext_functions, 모듈 초기화 PHP_MINIT(json), 요청 초기화 PHP_RINIT(json) 등을 등록합니다. PHP_FUNCTION(json_encode)는 인자를 검사하고 내부 인코더로 연결합니다.

ext/json/config.m4는 PHP_NEW_EXTENSION에 ext/json/json_encoder.c, 생성 파일인 ext/json/json_parser.tab.c와 ext/json/json_scanner.c, ext/json/json.c를 묶습니다. 생성 규칙은 ext/json/Makefile.frag에 있습니다. 기능 등록과 빌드 등록을 함께 봐야 “C 함수가 PHP 함수가 되는 과정”을 이해할 수 있습니다.

5디렉토리 구조 해부

5-1. 궁금한 내용으로 파일을 찾는 법

파일명이 *.stub.php라면 PHP 쪽 함수·메서드 선언과 타입 정보를 먼저 볼 수 있습니다. build/gen_stub.php와 build/Makefile.global은 이를 *_arginfo.h 같은 C용 정보로 연결합니다. 생성된 결과와 사람이 수정하는 원본을 구분하는 습관이 중요합니다.

6학습 포인트 (기술별)

6-1. C: 포인터와 자료형 태그 읽기

zend_value는 여러 타입을 같은 저장 공간에 담는 union입니다. zval의 타입 정보가 현재 어느 값을 읽어야 하는지 알려 줍니다. C는 그 조합이 맞는지 항상 자동 확인해 주지 않으므로, Z_TYPE_P(), Z_STR_P() 같은 매크로가 중요한 경계가 됩니다.

실습 아이디어: zend_compile_echo()의 각 줄 옆에 “AST를 읽음 / 임시 결과를 만듦 / 명령을 추가함”을 적어 보세요. C의 모든 매크로를 펼치기 전에 함수의 책임부터 설명하는 연습입니다.

6-2. 컴파일러: 한 문법을 세 가지 표현으로 그리기

echo $message;를 토큰 목록, AST, opcode 단계로 나누어 적습니다. 파서가 만드는 ZEND_AST_ECHO와 VM이 처리하는 ZEND_ECHO는 이름이 비슷하지만 서로 다른 계층입니다. 이 둘을 연결하는 곳이 컴파일러입니다.

실습 아이디어: echo 1 + 2;의 의미 구조를 먼저 그린 뒤 Zend/zend_compile.c에서 상수 표현식 처리 경로를 찾아보세요. 문법에 덧셈이 있다고 실행 시 반드시 덧셈 opcode가 남는 것은 아닙니다.

6-3. 문자열: 바이트 길이와 사람 눈의 글자 수

Zend/zend_builtin_functions.c:376의 ZEND_FUNCTION(strlen)은 ZSTR_LEN(s)를 반환합니다. 문자열을 끝까지 훑는 대신 zend_string에 저장된 길이를 읽습니다. 이 길이는 바이트 수이므로 UTF-8 한글의 글자 수와 같지 않을 수 있습니다.

// UTF-8로 저장한 PHP 실습 파일의 예시
<?php
var_dump(strlen("가"));     // 예상: int(3)
var_dump(strlen("A\0B"));   // 예상: int(3), NUL도 문자열 내부에 포함

더 흥미로운 점은 C 구현 바로 위 주석이 이 함수가 보통 우회된다고 알린다는 것입니다. Zend/zend_compile.c:4400의 zend_compile_func_strlen()은 상수 문자열이면 길이를 상수로 계산하고, 그 밖의 처리 가능한 경우에는 ZEND_STRLEN 명령을 만듭니다. 인자 수 등 조건이 맞지 않으면 이 특별 처리에서 빠집니다.

함수 이름을 찾았다고 실행 경로를 다 찾은 것은 아닙니다. 컴파일러의 특별 처리도 확인해야 합니다.

실습 아이디어: 상수 문자열과 함수 인자로 전달된 문자열의 경로를 비교하고, “동작의 의미”와 “최적화 후 남는 명령”을 별도로 적어 보세요.

6-4. 테스트: 입력과 기대 출력을 한 파일에 둔다

PHPT의 --TEST--는 설명, --FILE--은 실행할 PHP 코드, --EXPECT--는 정확히 기대하는 출력입니다. --EXPECTF--는 일부 가변 출력을 형식으로 비교하고, --SKIPIF--는 실행 조건에 따라 테스트를 건너뛸 수 있게 합니다.

실습 아이디어: ext/standard/tests/strings/strlen_basic.phpt를 읽고 빈 문자열과 NUL이 포함된 문자열을 왜 따로 검사하는지 설명하세요. 테스트 파일 수가 많아도 무엇을 검증하는지 구분하지 않으면 학습 효과가 줄어듭니다.

6-5. 시스템: 프로세스·스레드·요청을 구분한다

main/SAPI.h의 SG(v)는 ZTS 여부에 따라 스레드별 자원 접근과 전역 구조체 접근으로 나뉩니다. TSRM/은 이런 스레드 안전 실행 환경의 자원 관리를 지원합니다. ZTS를 활성화한다고 PHP 애플리케이션의 코드가 자동으로 여러 스레드에서 병렬 실행되는 것은 아닙니다.

실습 아이디어: FPM의 여러 작업 프로세스와 ZTS의 스레드별 전역 상태를 서로 다른 그림으로 그리세요. “요청이 여러 개다”라는 표현만으로 어떤 동시성 모델인지 판단하면 안 됩니다.

6-6. 성능: 코드 재사용과 실행 속도 향상을 분리한다

OPcache 캐시 적중, opcode 최적화, JIT, 외부 데이터베이스 응답 대기는 각각 다른 문제입니다. 정수 연산을 빠르게 해도 데이터베이스를 기다리는 시간이 대부분인 프로그램은 개선 폭이 작을 수 있습니다. benchmark/의 결과를 읽을 때도 어떤 비용을 측정하는지 먼저 확인해야 합니다.

실습 아이디어: “첫 실행 / 반복 실행”과 “연산 중심 / I/O 중심”을 두 축으로 놓고 실험 표를 설계하세요. 성능 향상 배수는 같은 조건에서 측정한 결과로 판단하세요.

7하드웨어 / 시스템 요구사항

7-1. 소스 읽기와 소스 빌드는 필요한 자원이 다르다

README의 병렬 빌드 예시는 make -j4이고, 테스트 기본 병렬도는 탐지한 논리 CPU 중 최대 10개라고 설명합니다. run-tests.php의 기본 병렬 실행 수 계산에도 상한 10이 있습니다. 빌드 작업자와 테스트 작업자는 서로 다른 설정이며, 메모리가 부족하면 둘 다 줄여야 합니다.

debug 심벌, sanitizer, 선택 확장, 병렬도에 따라 필요한 RAM과 디스크가 늘어납니다. 위 예산만으로 전체 CI 행렬이나 모든 확장 테스트에 필요한 자원이 충분하다고 보장할 수는 없습니다.

7-2. 운영체제와 CPU에 관한 실제 코드 조건

저장소에는 Unix 계열 빌드 설정과 win32/의 Windows 구현이 함께 있습니다. CI에는 Linux x64, Alpine, ppc64 작업 등이 있으며, .github/workflows/windows-builds.yml은 태그에 맞춰 별도 Windows 빌더 워크플로를 호출합니다. CI의 플랫폼 목록은 설정된 검증 대상이며, 각 실행의 성공 여부는 CI 결과로 확인해야 합니다.

ext/opcache/config.m4는 JIT에서 x86 계열과 AArch64를 구분하고, 지원하지 않는 CPU에서는 JIT 지원을 끕니다. Apple Silicon의 ZTS 조합에는 pthread_jit_write_protect_np() 검사도 있습니다. 일반 PHP 실행 가능 여부와 JIT 사용 가능 여부는 구분해서 판단해야 합니다.

7-3. FPM 메모리를 생각하는 출발점

sapi/fpm/www.conf.in의 예시는 pm = dynamic, pm.max_children = 5, pm.start_servers = 2입니다. 이는 설정 템플릿 값으로, 내 서비스에 적절한 프로세스 수를 보장하지 않습니다.

8직접 해볼 수 있는 실습 과제

아래 PHP·PHPT 코드는 별도 실습 환경에서 사용할 예시입니다. PHP 예제는 UTF-8 파일로 저장하고, PHPT 초안은 cow-example.phpt처럼 별도 디렉토리에 두세요. 검색 명령은 php/php-src 저장소 루트에서 실행합니다. 실행 과제에는 예제 문법을 지원하는 PHP 환경이 필요합니다.

<?php
var_dump(strlen(""));
var_dump(strlen("가"));
var_dump(strlen("A\0B"));
// UTF-8 파일 기준 예상: int(0), int(3), int(3)

rg -n 'ZEND_AST_ECHO' Zend/zend_language_parser.y
rg -n 'zend_compile_echo' Zend/zend_compile.c
rg -n 'ZEND_ECHO' Zend/zend_vm_def.h
rg -n 'php_output_write|sapi_module\.ub_write' main/output.c
rg -n 'sapi_cli_ub_write' sapi/cli/php_cli.c

<?php
$a = [1, 2];
$b = $a;
$b[0] = 99;
echo $a[0], ":", $b[0], "\n";

$x = (object) ["value" => 1];
$y = $x;
$y->value = 99;
echo $x->value, ":", $y->value, "\n";
// 예상: 첫 줄 1:99, 둘째 줄 99:99

--TEST--
배열 대입 뒤 원소 변경은 원래 배열을 바꾸지 않는다
--FILE--
<?php
$a = [1];
$b = $a;
$b[0] = 2;
var_dump($a[0]);
var_dump($b[0]);
?>
--EXPECT--
int(1)
int(2)

9관련 기술 심화 학습 로드맵

PHP 문법으로 함수·배열·객체를 작성해 본 독자를 가정합니다. C를 처음 본다면 1주차를 늘려도 좋습니다. 각 주의 목표는 파일 통독이 아니라 하나의 동작을 근거와 함께 설명하는 산출물을 만드는 것입니다.

9-1. 다음으로 뻗어 갈 세 갈래

• 컴파일러 쪽: Zend/Optimizer/에서 상수 전파와 제어 흐름을 읽고, 이후 ext/opcache/jit/ir/의 중간 표현과 레지스터 할당으로 넘어갑니다.
• 자료구조 쪽: Zend/zend_hash.c와 zend_string 문서를 연결해 배열·문자열의 메모리 배치와 비용을 살펴봅니다.
• 운영 쪽: FPM의 작업 프로세스 관리, 출력 버퍼, INI 설정이 바뀌는 범위를 읽고 애플리케이션의 실행 환경과 연결합니다.

학습의 진도는 읽은 줄 수보다, 입력 하나가 결과가 되는 과정을 얼마나 정확히 설명하는지로 확인하세요.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 학습 안내

• php/php-src 공식 저장소 — 실행기 전체 코드와 개발 안내.
• PHP 한국어 매뉴얼 — 언어와 함수의 사용자 관점 설명.
• PHP 내부 개발 문서 — 엔진 자료구조·테스트·기여 학습의 출발점.
• PHP 릴리스 안내 — 배포 버전의 변경 내역을 별도로 확인할 곳.
• PHP RFC 목록 — 언어 기능을 제안하고 논의하는 절차와 기록.
• GNU Bison 매뉴얼 · re2c 공식 문서 — 파서·어휘 분석기 생성 도구 학습.
• CPython C API 안내 · Node.js 이벤트 루프 안내 — 실행 모델을 비교하며 읽을 공식 자료.
• TrendShift — Daily #23 선정 근거, 분석일 2026-10-23.

11-2. 본문의 소스 근거

아래 소스 링크는 모두 커밋 02207318을 가리킵니다. 기본 브랜치는 이후에 바뀔 수 있으므로 본문의 구현 설명은 이 커밋을 기준으로 읽으세요.

• configure.ac · build/php.m4 — 개발 버전, C11, 생성 도구와 외부 라이브러리 검사.
• sapi/cli/php_cli.c · main/main.c — CLI 진입과 요청 수명 주기.
• main/SAPI.h · main/output.c — 실행 환경 추상화와 출력 전달.
• Zend/zend_language_parser.y · Zend/zend_language_scanner.l — 문법과 AST 컴파일 진입.
• Zend/zend_compile.c · Zend/zend_vm_def.h — echo와 strlen의 변환·실행 경로.
• Zend/zend_types.h · Zend/zend_gc.c — 값 표현, 쓰기 시 복사와 순환 참조 수집.
• Zend/zend_string.h · 문자열 내부 문서 — 문자열 길이와 해제 동작을 대조한 근거.
• ext/opcache/ZendAccelerator.c · 설정 등록부 — 컴파일 훅과 기본 INI 값.
• ext/json/json.c · CI 테스트 구성 — 확장 등록과 플랫폼별 검증 설정.
• 참조 수 내부 문서 · 문자열 길이 테스트 — 개념과 기대 출력을 함께 확인한 자료.

현재 상태 (2026-10-23 확인)

11-3. 코드 규모 집계 기준

집계 대상은 git ls-files에 나오는 추적 파일이며, 확장자별로 묶어 줄바꿈 바이트를 셉니다. 빈 줄과 주석을 포함하는 wc -l 방식의 집계입니다. 아래 코드는 저장소 루트에서 같은 기준으로 파일 내용을 읽어 집계합니다.

python3 - <<'PY'
from pathlib import Path
from collections import defaultdict
import subprocess

root = Path('.')
paths = subprocess.check_output(['git', 'ls-files', '-z'])
stats = defaultdict(lambda: [0, 0])
for name in paths.split(b'\0'):
    if not name:
        continue
    p = root / name.decode()
    if p.is_file():
        stats[p.suffix][0] += 1
        stats[p.suffix][1] += p.read_bytes().count(b'\n')
for ext in ['.c', '.h', '.cpp', '.php', '.phpt', '.y', '.l', '.m4', '.sh']:
    print(ext, *stats[ext])
PY

이 수치는 사람이 직접 작성한 유효 코드만 세는 SLOC가 아닙니다. 자동 생성된 VM 코드, 문자 데이터, 외부에서 가져온 코드도 포함합니다. 코드 줄 수는 읽을 범위를 가늠하는 자료이며, 품질이나 성능을 증명하는 점수는 아닙니다.