트래픽이 갑자기 몰릴 때 PHP 서버의 CPU 점유율이 100%까지 치솟으며 웹사이트가 멈추는 현상을 경험해봤을까? 소스 코드나 SQL 쿼리를 대대적으로 수정하지 않고도 서버 성능을 단번에 끌어올릴 수 있는 방법이 있지만, 다만 정확한 원인이나 해결책을 모르는 경우가 많다. 이번에는 PHP OPcache가 정확히 뭔지, 왜 필요한지, 그리고 어떻게 설정하고 배포 이슈를 해결하는지 완벽하게 정리해서 소개하겠다.

PHP는 기본적으로 요청이 들어올 때마다 소스 코드를 읽어서 바이트코드(Bytecode)로 컴파일한 뒤 실행하는 인터프리터 언어입니다.
동일한 페이지에 10,000번의 요청이 들어오면 똑같은 PHP 파일을 10,000번 매번 컴파일하게 되며, 이 과정에서 엄청난 CPU 자원이 낭비됩니다.
OPcache(Zend OPcache)는 컴파일된 바이트코드를 공유 메모리(RAM)에 저장해 두고, 이후 동일한 요청이 오면 컴파일 단계를 생략하고 메모리에서 바로 바이트코드를 가져와 실행하는 PHP 내장 성능 최적화 모듈입니다.

PHP 7.0 이상부터는 OPcache 모듈이 기본 포함되어 있지만, 기본 설정값은 메모리가 부족하거나 타임스탬프 검증 주기가 비효율적일 수 있습니다.
서버 환경(Nginx + PHP-FPM 또는 Apache)의 php.ini 또는 opcache.ini 파일에서 주요 옵션을 아래와 같이 최적화해 주어야 합니다.

• opcache.enable=1 : OPcache 활성화 여부입니다.
• opcache.memory_consumption=256 : 바이트코드를 저장할 공유 메모리 크기(MB단위)입니다. 서비스 규모에 따라 128~512MB로 설정합니다.
• opcache.interned_strings_buffer=16 : PHP 내부 문자열(변수명, 클래스명 등)을 메모리에 버퍼링하는 크기(MB단위)입니다.
• opcache.max_accelerated_files=20000 : 캐시할 수 있는 최대 PHP 파일 수입니다. 프로젝트 내 파일 수보다 충분히 크게 설정해야 합니다.
• opcache.revalidate_freq=2 : 파일 변경 여부를 체크하는 주기(초 단위)입니다. 2초마다 파일 변경을 확인합니다.
• opcache.validate_timestamps=1 : 파일 수정 타임스탬프를 검증할지 여부입니다. 운영 환경에서 배포 시 자동 리셋 시스템을 갖춘 경우 0으로 두어 I/O 부담을 더 줄일 수 있습니다.

OPcache 적용 시 흔히 발생하는 문제는 코드 배포 후에도 이전 캐시가 남아있어 변경 사항이 즉시 반영되지 않는 것입니다.
아래 예제를 통해 잘못된 설정과 올바른 프로덕션 설정, 그리고 배포 웹훅에서 사용하는 캐시 리셋 스크립트를 확인해 봅시다.

✗ 잘못된 코드 (메모리 부족 및 캐시 갱신 미설정으로 배포 반영 불가능):

; opcache.ini - 잘못된 설정 예시
zend_extension=opcache.so
opcache.enable=1
; 메모리가 16MB로 너무 작아 캐시가 금방 차서 컴파일이 다시 발생함
opcache.memory_consumption=16
opcache.max_accelerated_files=500
; 타임스탬프 검증을 꺼두고 자동 리셋 처리도 없어서 배포 후 구버전 코드가 실행됨
opcache.validate_timestamps=0

✓ 올바른 코드 (운영 환경 권장 최적화 설정):

; opcache.ini - 프로덕션 최적화 설정 예시
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.fast_shutdown=1

✓ 올바른 코드 (CI/CD 배포 웹훅용 OPcache 리셋 PHP 스크립트):

<?php
// deploy_reset_opcache.php
header('Content-Type: application/json; charset=utf-8');

// 보안을 위한 비밀 키 검증
$secret_token = 'my_super_secret_deploy_key_2024';
$request_token = $_GET['token'] ?? '';

if (!hash_equals($secret_token, $request_token)) {
    http_response_code(403);
    echo json_encode(['success' => false, 'message' => 'Access Denied: Invalid Token']);
    exit;
}

if (function_exists('opcache_reset')) {
    if (opcache_reset()) {
        echo json_encode(['success' => true, 'message' => 'OPcache has been reset successfully.']);
    } else {
        http_response_code(500);
        echo json_encode(['success' => false, 'message' => 'Failed to reset OPcache.']);
    }
} else {
    http_response_code(400);
    echo json_encode(['success' => false, 'message' => 'OPcache module is not enabled.']);
}
?>

배포 웹훅 호출 시 출력 결과:

{
  "success": true,
  "message": "OPcache has been reset successfully."
}

OPcache를 운용하면서 실무 개발자들이 흔히 겪는 3가지 함정과 주의사항입니다.

• CLI와 Web(FPM) 프로세스의 차이점: 터미널 CLI에서 `php -r "opcache_reset();"`을 실행해도 PHP-FPM 웹 프로세스의 메모리는 리셋되지 않습니다. 웹 요청 형태(HTTP)로 호출하거나 `systemctl reload php-fpm` 명령으로 서비스 프로세스를 재로드해야 합니다.
• 메모리 부족 상태 방치: `opcache.memory_consumption` 용량이 부족하면 캐시가 비워지고 다시 컴파일되는 'Cache Miss'가 빈번하게 일어납니다. `opcache_get_status()` 함수로 주기적으로 메모리 사용량을 모니터링해야 합니다.
• 개발 환경에서의 OPcache 활성화: 로컬 개발 환경에서 `revalidate_freq`를 높게 잡거나 타임스탬프 검증을 끄면 코드를 수정해도 웹 브라우저에 바로 반영되지 않아 혼란을 겪게 됩니다. 개발 환경에서는 `opcache.enable=0`으로 끄거나 `revalidate_freq=0`으로 설정하세요.

PHP OPcache 설정 최적화는 서버의 CPU 부담을 대폭 줄이고 웹 애플리케이션의 응답 속도를 극대화하는 핵심 기술이다. 작은 최적화와 올바른 배포 습관이 모여서 서버 비용 절감과 서비스 안정성 향상이라는 큰 효과를 만든다는 점을 잊지 말자. 이 글의 php.ini 권장 설정과 배포 캐시 초기화 코드를 참고해 현재 운영 중인 PHP 서버에 직접 적용해보면, 현저히 빨라진 웹 응답 속도를 얻을 수 있을 것이다.