frankenphp 딥다이브
— Go의 문으로 들어와 PHP의 수명을 바꾸는 서버

1프로젝트 한줄 요약

FrankenPHP는 Go의 HTTP 서버 안에 PHP 인터프리터를 넣은 서버입니다. 일반적인 Nginx + PHP-FPM 구성에서는 웹 서버가 FastCGI로 별도 PHP 프로세스에 일을 넘깁니다. 여기서는 Go와 C의 연결 기능인 CGO를 통해 같은 프로세스 안의 PHP 실행 스레드에 요청을 전달합니다.

PHP를 Go 코드로 번역하는 도구는 아닙니다. PHP 코드는 PHP 엔진이 실행하고, Go는 요청 접수와 스레드 배치를 맡습니다. 이 저장소의 핵심은 언어를 바꾸는 것이 아니라, 요청과 PHP 실행기의 수명을 다르게 묶는 데 있습니다.

일반 모드에서도 요청마다 운영체제 스레드를 새로 만드는 것은 아닙니다. threadregular.go의 regularThread는 살아 있는 PHP 스레드를 재사용하면서 스크립트를 실행합니다. 워커 모드는 여기서 더 나아가 스크립트 자체를 끝내지 않고 여러 요청을 처리합니다.

짧은 코드로 보는 수명의 차이

다음은 구조를 설명하는 학습용 예제입니다. 실제 프레임워크의 초기화·종료 코드는 공식 통합을 따릅니다.

<?php
// 워커 스크립트 시작 시 한 번 준비한다.
$dictionary = ['hello' => '안녕하세요'];

$handler = static function () use ($dictionary): void {
    // 요청마다 달라지는 값은 콜백 안에서 읽는다.
    $word = $_GET['word'] ?? 'hello';
    header('Content-Type: text/plain; charset=utf-8');
    echo $dictionary[$word] ?? '등록되지 않은 단어';
};

while (frankenphp_handle_request($handler)) {
    // 실제 앱에서는 요청별 서비스 정리도 이 경계에서 수행한다.
}

frankenphp.c의 PHP_FUNCTION(frankenphp_handle_request)가 이 PHP 함수를 구현합니다. 워커 모드 밖에서 호출하면 예외를 던지므로, 단순히 기존 PHP 파일에 반복문만 붙여 실행할 수는 없습니다.

2왜 주목받는가

2026-10-23 GitHub Trending Go Weekly #11에 오른 시점의 스타는 11,454개, 포크는 500개입니다. 최신 릴리스 v1.13.2는 이틀 전인 2026-10-21에 공개됐습니다. 다만 순위와 릴리스 날짜만으로 유행의 원인을 확정할 수는 없습니다. 아래는 소스와 공식 문서에서 읽을 수 있는 주목할 만한 기술적 이유입니다.

2-1. 웹 서버와 PHP 실행을 한 배포 단위로 묶는다

caddy/frankenphp/main.go는 Caddy 표준 모듈과 FrankenPHP 모듈을 가져온 뒤 caddycmd.Main()을 호출합니다. 별도 웹 서버를 처음부터 구현하지 않고 Caddy의 설정·인증서·HTTP 기능을 확장하는 방식입니다. docs/migrate.md는 Nginx/Apache와 PHP-FPM을 하나의 FrankenPHP 실행 파일로 대체하는 구성을 설명합니다.

이 표는 실행 모델 비교입니다. 처리량 순위표가 아닙니다. 워커 모드의 장점은 앱 초기화의 반복을 줄이는 것이며, 실제 개선 폭은 초기화 비용이 전체 요청에서 차지하는 비중에 달려 있습니다.

2-2. PHP 개발자가 Go 시스템 코드를 읽을 연결점이 많다

PHP의 echo가 Go의 응답 쓰기로 이어지고, Go의 채널 대기가 PHP 함수의 요청 대기로 이어집니다. 익숙한 웹 요청을 출발점으로 다른 언어의 동시성 모델을 배울 수 있습니다. server.go는 서버별 설정과 워커를 묶고, internal/state/state.go는 스레드의 안전한 전환을 관리합니다.

README는 Symfony와 Laravel의 공식 워커 통합을 소개합니다. 이는 기존 생태계와 연결되는 장점이지만, 모든 앱이 수정 없이 워커에 적합하다는 뜻은 아닙니다. 공식 docs/worker.md도 앱을 워커 수명에 맞게 조정하고 메모리 누수를 관리해야 한다고 설명합니다.

2-3. 최신 HTTP 기능과 운영 기능을 함께 읽을 수 있다

README는 Early Hints, HTTP/2·HTTP/3, 자동 HTTPS, 실시간 기능, 핫 리로드를 소개합니다. 소스에서는 caddy/caddy.go의 모듈 등록, metrics.go의 Prometheus 계측, hotreload.go의 Mercure 업데이트 발행처럼 각 기능의 연결점을 확인할 수 있습니다.

3기술 스택 전체 지도

3-1. 백엔드: Go가 조율하고 C가 PHP 엔진에 연결한다

루트 go.mod와 caddy/go.mod는 모두 go 1.27.0을 선언합니다. 저장소 주소는 php/frankenphp지만 모듈 경로는 여전히 github.com/dunglas/frankenphp입니다. 예제의 import 경로를 저장소 주소에 맞춰 임의로 바꾸면 안 됩니다.

// caddy/go.mod의 핵심 관계
module github.com/dunglas/frankenphp/caddy
go 1.27.0

replace github.com/dunglas/frankenphp => ../

require (
    github.com/caddyserver/caddy/v2 v2.11.7
    github.com/dunglas/frankenphp v1.13.2
)

위 예제는 원본에서 관련 선언만 발췌한 것입니다. replace 때문에 Caddy 모듈을 이 소스 트리에서 빌드하면 릴리스의 코어 대신 상위 디렉터리의 코어를 씁니다. 의존성 표의 버전과 실제 빌드에 들어가는 소스가 언제나 같지는 않으므로, require와 replace를 함께 읽어야 합니다.

cgo.go에는 Unix의 -lphp -lm -lutil, Linux의 -ldl -lresolv 같은 링크 옵션이 있습니다. 따라서 이 코어는 순수 Go 프로그램처럼 CGO_ENABLED=0만으로 완성할 수 있는 구조가 아닙니다. PHP 라이브러리·헤더와 플랫폼별 네이티브 의존성을 함께 맞춰야 합니다.

3-2. 프론트엔드: 이 저장소에는 별도 SPA 제품이 없다

추적 파일에는 package.json, composer.json, Cargo.toml, pyproject.toml이 없습니다. React나 Vue 앱을 빌드하는 저장소가 아니라 PHP 앱을 실행하는 기반 서버입니다. 프론트엔드 프레임워크와 Composer 의존성은 그 위에 올리는 개별 PHP 애플리케이션의 선택입니다.

JavaScript 파일 7개는 testdata/load-test.js와 testdata/performance/의 부하 테스트입니다. 예를 들어 testdata/performance/hello-world.js는 k6/http를 가져옵니다. JavaScript 파일이 있다는 사실만으로 Node.js 프론트엔드 스택을 추정하면 안 됩니다.

브라우저와 연결되는 핫 리로드 설정은 caddy/hotreload.go에서 확인할 수 있습니다. configureHotReload()는 Mercure 허브가 없으면 오류를 반환하고, FRANKENPHP_HOT_RELOAD 환경 변수에 구독 경로를 전달합니다. 기본으로 모든 페이지가 자동 갱신되는 것은 아닙니다.

3-3. 인프라·빌드: 같은 서버라도 산출물의 조건은 다르다

Dockerfile은 FROM php-base와 golang-base라는 외부 빌드 문맥을 사용합니다. 실제 버전·운영체제 조합은 docker-bake.hcl까지 읽어야 알 수 있습니다. 또한 Watcher C 라이브러리는 Dockerfile에서 GitHub의 최신 릴리스를 조회하므로, Go 모듈 고정만으로 모든 네이티브 입력이 고정되지는 않습니다.

컨테이너 기본 명령은 --config /etc/frankenphp/Caddyfile --adapter caddyfile이고, Dockerfile이 PHP 엔트리포인트를 frankenphp run 호출로 바꿉니다. 상태 검사는 http://localhost:2019/metrics를 대상으로 합니다. 이 내부 상태 검사 주소를 외부 서비스용 API로 해석하지 않는 것이 중요합니다.

4아키텍처 심화 분석

4-1. 패턴 ① 어댑터: 서버의 요청을 PHP의 요청으로 바꾸기

caddy/caddy.go의 init()은 php와 php_server 지시어를 등록합니다. caddy/module.go의 parsePhpServer()는 PHP 처리기와 정적 파일 처리기를 함께 구성합니다. 기본 실행 확장자는 .php, 기본 인덱스 파일은 index.php입니다.

1. FrankenPHPModule.ServeHTTP()가 문서 루트·환경 변수·원래 요청 정보를 준비합니다.
2. Server.ServeHTTP()가 등록 상태를 검사하고 newContextFromRequest()로 요청 문맥을 만듭니다.
3. context.go와 cgi.go에서 서버 범위의 워커 매처와 파일 경로를 바탕으로 실행 대상을 결정합니다.
4. 요청 문맥에 워커가 있으면 worker.handleRequest(), 없으면 handleRequestWithRegularPHPThreads()로 갑니다.
5. PHP 엔진의 SAPI 콜백이 Go 함수와 연결되어 요청 본문을 읽고 응답을 씁니다.

연결의 실물은 frankenphp.c의 frankenphp_sapi_module입니다. 여기에 frankenphp_ub_write, frankenphp_send_headers, frankenphp_read_post 같은 함수가 등록됩니다. frankenphp.go의 go_ub_write() 등은 Go 쪽 요청 문맥과 응답 작성자를 사용합니다.

4-2. 패턴 ② 스레드 풀과 역압: 받을 수 있는 만큼만 실행하기

phpthread.go의 boot()는 C.frankenphp_new_php_thread()를 호출합니다. 실제 구현은 frankenphp.c에서 pthread_create()로 PHP 실행 스레드를 만듭니다. PHP 요청마다 goroutine 하나를 PHP 실행기로 삼는 모델이 아니라, Go가 네이티브 PHP 스레드들을 조율하는 모델입니다.

threadregular.go는 먼저 비어 있는 스레드의 requestChan으로 전달을 시도합니다. 바로 받을 스레드가 없으면 공유 regularRequestChan에서 전달 기회를 기다립니다. 이 채널은 버퍼 없이 만들어집니다. “요청 큐”는 거대한 채널 버퍼가 아니라 전달을 기다리는 요청들과 카운터로 표현됩니다.

// threadregular.go에서 분기 구조만 추린 의사 코드
select {
case regularRequestChan <- fc:
    // PHP 쪽 응답 완료 통지를 기다린다.
    <-fc.done
case scaleChan <- fc:
    // 증설을 요청한 뒤 원래 요청은 계속 대기한다.
case <-fc.ctx.Done():
    // 아직 배정되지 않은 취소 요청을 큐에서 뺀다.
case <-timeoutChan(maxWaitTime):
    // 대기 한도를 넘긴 요청을 거절한다.
}

이 의사 코드에서 생략된 실제 구현은 카운터와 메트릭도 모든 종료 경로에서 정리합니다. max_wait_time의 기본값은 비활성화이므로 설정 없이 대기 시간이 자동으로 제한된다고 생각하면 안 됩니다. 다만 증설 신호를 보내 루프를 반복하면 타이머가 다시 만들어지므로, 이 값이 전체 대기 시간의 엄격한 상한은 아닙니다. 또한 fc.done은 응답 완료 통지입니다. 조기 응답 종료 함수가 쓰이면 PHP 후처리와 스레드의 다음 요청 가능 시점은 그보다 뒤일 수 있습니다.

scaling.go는 최소 대기 5ms, CPU 관측 120ms, CPU 사용률 기준 0.8을 두고 증설을 판단합니다. 증설은 max_threads가 시작 스레드 수보다 클 때 활성화됩니다. 요청이 많다는 이유만으로 무조건 스레드를 늘리지 않는 설계입니다.

4-3. 패턴 ③ 상태 머신: 종료·재시작·역할 전환을 명시하기

internal/state/state.go는 Reserved, Booting, Inactive, Ready, ShuttingDown, RebootReady 등의 상태를 정의합니다. 현재 상태뿐 아니라 원하는 상태를 기다리는 구독 채널도 관리합니다.

phpThread.setHandler()는 기존 처리기가 안전한 전환 지점에 도달하기를 기다린 뒤 새 처리기를 설치합니다. ThreadState.WaitFor()는 상태 확인과 대기 구독 등록을 같은 잠금 안에서 수행합니다. 확인 직후 알림이 먼저 지나가 영원히 기다리는 경쟁 상황을 피하는 방식입니다.

phpMainThread.rebootAllThreads()의 긴 주석도 좋은 교재입니다. PHP의 TSRM 전역 자원을 정리하기 전에 모든 PHP 스레드가 종료되어야 하므로, 살아 있는 스레드를 남겨 두고 재부팅을 진행하지 않습니다. 이 지점에서 “빨리 복구하기”보다 메모리 수명 보장이 먼저라는 판단을 읽을 수 있습니다.

4-4. 패턴 ④ 수명 분리: 스크립트·요청·메모리는 같은 단위가 아니다

일반 모드의 frankenphp.c 내부 php_thread()는 php_request_startup() → 스크립트 실행 → php_request_shutdown()을 반복합니다. 워커는 그 스크립트 실행 안에서 frankenphp_handle_request() 호출을 반복합니다. 따라서 워커 스크립트의 종료와 개별 HTTP 요청의 종료가 서로 다른 사건이 됩니다.

threadworker.go의 waitForWorkerRequest()는 새 요청을 기다리고, go_frankenphp_finish_worker_request()는 요청 문맥을 닫습니다. phpThread에 포함된 runtime.Pinner는 C가 참조하는 Go 메모리의 수명을 유지하며, Unpin()은 다음 워커 요청 대기 등 정리 경계에서 수행됩니다.

요청이 끝났다는 사실만으로 워커의 객체와 외부 참조까지 모두 사라지는 것은 아니므로, 각 자원의 수명 경계를 따로 확인해야 합니다. 특히 docs/worker.md는 대부분의 슈퍼글로벌과 달리 $_ENV는 요청 사이에 초기화되지 않는다고 명시합니다. 앱 전역 변수와 정적 속성도 별도 정리가 필요합니다.

5디렉토리 구조 해부

중요한 보조 경로: 확장 코드 생성기

internal/extgen/generator.go의 Generator.Generate()는 선언을 분석하고, 스텁 → 인수 정보 → 헤더 → C → Go → 문서를 차례로 생성합니다. internal/extgen/funcparser.go는 parser.ParseFile(..., parser.ParseComments)로 Go 구문 트리와 주석을 함께 읽습니다. 함수 선언을 구문 트리로 분석해 연결 코드를 생성하는 작은 컴파일러 사례입니다.

이 기능의 API에는 EXPERIMENTAL 표시가 있습니다. 서버 요청 경로를 이해한 다음에 읽을 확장 주제이며, 처음부터 전체 생성기를 이해할 필요는 없습니다. 우선 caddy/frankenphp/main.go → caddy/module.go → server.go → 두 스레드 처리기를 읽으면 핵심 연결이 보입니다.

6학습 포인트 (기술별)

6-1. “요청 완료”를 한 번 더 정의해 보기

context.go의 frankenPHPContext에는 요청 문맥, 응답 작성자, done 채널, isDone과 클라이언트 연결 상태가 들어 있습니다. HTTP 핸들러 반환, 응답 전송 완료, PHP 후처리 완료는 언제나 같은 순간이 아닙니다. frankenphp_finish_request()가 있는 시스템에서 이 구분은 특히 중요합니다.

동시성 코드를 배울 때는 정상 경로보다 취소·종료·재시작에서 누가 마지막 정리를 맡는지 먼저 확인하는 습관이 유용합니다. threadregular_test.go의 TestCancelledRequestLeavesRegularQueue()는 취소된 대기 요청이 큐 카운터에 남지 않는지 확인하는 좋은 출발점입니다.

6-2. 테스트는 운영 사고의 압축된 설명서다

TestRegularRequestChanIsCreatedBeforeInitRuns()는 초기화 전후 틈에 요청이 도착해도 nil 채널에서 영원히 기다리지 않도록 채널이 미리 존재하는지 확인합니다. TestRequestsQueuedBeforeThreadsAreReadyAreHandedOver()는 준비 전 대기 요청이 실제로 전달되고 완료되는지 확인합니다. 함수 이름, 사전 상태, 마지막 단언을 차례로 읽으면 테스트가 막는 사고를 설명할 수 있습니다.

scaling_test.go는 증설 후 Ready 상태와 처리기 타입을 검사하고, 축소 후에는 inactiveThread로 바뀌는지 확인합니다. 축소를 “스레드가 즉시 완전히 사라진다”로 해석하지 않는 근거입니다. worker_internal_test.go와 requestbodytimeout_test.go는 재시작·느린 입력의 경계 사례를 확장해 줍니다.

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

7-1. 실행 파일 사용과 소스 빌드를 구분한다

문서가 요구하는 정상적인 병렬 실행 환경은 ZTS 빌드입니다. 소스의 Init()에는 ZTS가 없으면 시작 스레드 수를 1로 낮추고 경고하는 경로도 있습니다. 이는 문서의 권장·필수 빌드 조건과 구현의 방어적 처리 사이의 차이이며, NTS 환경의 모든 조합이 검증됐다는 보장은 아닙니다.

checkPHPConfig()는 ZTS와 Zend signals가 함께 활성화된 조합을 거절합니다. Linux에서 Zend Max Execution Timers가 없으면 실행 시간 제한이 동작하지 않는다는 경고도 있습니다. “PHP 8.x라서 된다”보다 빌드 기능까지 확인하는 것이 중요합니다.

7-2. 스레드 수 계산을 숫자로 이해한다

calculateMaxThreads()는 2 × runtime.GOMAXPROCS(0)를 기본 예산 계산에 사용합니다. 아래는 ZTS 환경에서 GOMAXPROCS=4인 예입니다. 운영체제가 표시하는 전체 코어 수와 Go가 사용하는 동시 실행 기준이 반드시 같지는 않습니다.

별도 주 PHP 스레드 등 관리용 실행 단위는 이 처리 슬롯 계산과 구분합니다. num_threads를 명시하면 일반 요청용 스레드에 워커 수가 더해지고, max_threads는 두 종류를 합친 처리 스레드 한도입니다. 따라서 “워커도 기본 두 배”라는 짧은 설명만으로 전체 메모리 사용량을 계산하면 틀리기 쉽습니다.

# 메모리 예산을 잡는 개념식이며 실제 RSS 보장식은 아니다.
필요 예산 ≈ PHP 동시 실행 메모리
          + 장기 보존 앱 상태·공유 캐시
          + Go·Caddy·네이티브 확장·연결 버퍼·운영체제 여유

예: 처리 슬롯 5개 × memory_limit 128MiB = 640MiB
    여기에 위의 추가 메모리와 여유 공간을 별도로 잡는다.

max_threads auto는 phpmainthread.go에서 시스템 메모리를 PHP의 memory_limit로 나눠 한도를 추정하며, 추정 불가 시 시작 스레드 수의 두 배를 사용합니다. Linux의 internal/memory/memory_linux.go는 syscall.Sysinfo()를 사용하므로 이 경로 자체가 컨테이너의 cgroup 한도를 직접 읽는 구현은 아닙니다.

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

앞부분은 소스 읽기만으로 따라갈 수 있습니다. 아래 실행 실습은 PHP를 포함한 FrankenPHP 실행 파일이 준비된 환경을 전제로 합니다. 예제 파일은 별도의 demo/ 프로젝트에 두고, 명령은 그 프로젝트의 루트에서 실행합니다. 외부 데이터베이스나 실제 사용자 데이터 없이도 수명과 대기 동작을 관찰할 수 있습니다.

<?php
header('Content-Type: text/plain; charset=utf-8');
echo '실행 환경: ' . PHP_SAPI . "\n";
echo '요청 경로: ' . ($_SERVER['REQUEST_URI'] ?? '') . "\n";

# 첫 번째 터미널
frankenphp php-server --root public --listen 127.0.0.1:8080

# 두 번째 터미널
curl 'http://127.0.0.1:8080/index.php?hello=1'

<?php
$handler = static function (): void {
    static $count = 0;
    ++$count;
    $name = $_GET['name'] ?? '익명';
    header('Content-Type: text/plain; charset=utf-8');
    echo "이 워커의 요청 수: {$count}\n";
    echo "이번 요청의 이름: {$name}\n";
};

while (frankenphp_handle_request($handler)) {
    gc_collect_cycles();
}

frankenphp php-server --root public --listen 127.0.0.1:8080 \
  --worker "$PWD/public/index.php,1"

# 다른 터미널에서 순서대로 요청한다.
curl 'http://127.0.0.1:8080/index.php?name=A'
curl 'http://127.0.0.1:8080/index.php?name=B'

{
    debug
    frankenphp {
        num_threads 1
        max_threads 2
        max_wait_time 100ms
        php_ini memory_limit 128M
        worker ./public/index.php 1
    }
}

http://127.0.0.1:8080 {
    root * public
    php_server
}

frankenphp run --config Caddyfile --adapter caddyfile

# 다른 터미널에서 요청 세 개를 겹쳐 보낸다.
for n in 1 2 3; do
  curl -s -o /dev/null -w '%{http_code}\n' \
    'http://127.0.0.1:8080/index.php' &
done
wait

실습의 성공은 빠른 응답 숫자 하나가 아니라, 요청 사이에 남겨도 되는 상태와 반드시 지워야 할 상태를 구분해 설명하는 것입니다. 성능을 비교할 때는 같은 PHP 버전·확장·앱·부하를 사용하고 초기화 구간과 정상 상태를 따로 기록합니다.

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

PHP의 함수·배열·클로저, Go의 구조체·인터페이스를 먼저 익히면 좋습니다. C 문법을 완벽하게 알 필요는 없지만 포인터·메모리 할당·콜백의 기본 뜻은 4주차 전에 정리합니다. 매주 실행 결과와 함께 “왜 이 결과가 나오는가”를 설명하는 산출물을 남깁니다.

다음 갈림길을 고르는 기준

• 백엔드 개발: Symfony·Laravel의 요청별 서비스 초기화와 종료 훅을 추적합니다.
• 서버·플랫폼 개발: 대기열, 자동 증설, 메모리 예산, 정상 종료 정책을 더 깊게 읽습니다.
• 언어·도구 개발: extgen의 구문 트리 분석과 PHP 인수 정보 생성으로 확장합니다.
• 품질·성능: 회귀 테스트를 먼저 이해한 뒤 동일 조건에서 일반 모드와 워커를 비교합니다.

파일을 끝까지 읽는 것보다 하나의 요청·하나의 실패·하나의 자원이 어디서 시작하고 끝나는지 설명할 수 있는 것이 더 좋은 학습 기준입니다. 스레드 수나 성능 수치를 외우기보다 그 값을 바꿨을 때 무엇이 함께 바뀌는지 예측해 보세요.

10핵심 키워드 사전

11참고 링크

공식 저장소·문서·관련 기술

• FrankenPHP 공식 저장소 · 기능 소개와 릴리스
• v1.13.2 릴리스 · 2026-10-21 공개 버전
• 내부 구조 문서 · 스레드·상태 머신·CGO
• server.go · 서버별 요청 배치의 실제 구현
• threadworker.go · 워커 준비·대기·종료·시작 실패 처리
• frankenphp.c · SAPI와 PHP 실행 루프
• 워커 모드 공식 문서 · 프레임워크 통합과 상태 관리
• 소스 빌드 공식 문서 · PHP 빌드 기능과 네이티브 의존성
• 성능 설정 공식 문서 · 스레드 수와 메모리 예산
• 기준 커밋의 알려진 문제 · 확장 호환성·메모리·플랫폼 차이
• 관측 공식 문서 · 메트릭과 운영 상태 확인
• Caddyfile 문서 · 서버 설정의 기본 문법
• CGO 공식 문서 · Go와 C 경계의 규칙
• runtime.Pinner 문서 · C가 참조하는 Go 메모리의 수명
• PHP 내부 구조 문서 · 엔진·확장 개발의 배경
• Prometheus 메트릭 유형 · 카운터와 게이지 읽기
• 확장 코드 생성기 · 여러 언어의 연결 코드를 만드는 실험적 경로

커밋을 포함한 링크는 이 글의 코드 기준을 고정합니다. 일반 공식 문서와 라이브러리 API 문서는 이후 바뀔 수 있으므로, 동작 차이를 발견하면 d138a78 시점의 구현과 설정 파일을 함께 대조합니다.

현재 상태 (2026-10-23 GitHub 기준)

줄 수는 Git 추적 파일을 확장자로 묶어 센 물리적 줄 수의 대략치입니다. 주석·빈 줄·테스트·픽스처·생성 헤더를 포함하며, 외부 의존성의 소스 줄 수를 더한 수치가 아닙니다. Go 줄 수의 약 63%가 _test.go에 있지만 이 비율은 테스트 커버리지나 품질 점수가 아닙니다. 제한된 커밋 스냅샷만으로 전체 커밋 수나 기여자 기여 비중을 추정하지 않습니다.