PHP와 함께 해온지 벌써 10년이 다되가는것같다. 내가 처음 사용한 버전은 PHP5 버전대였는데 영원할것같던 5도 이제 역사속으로 사라지고 PHP7로 갈아탄지가 엊그제 같은데 부지런하고 똑똑한 PHP 연구원들덕에 빠르게 사라질 듯 싶다.
솔직히 PHP8은 작년에 개발서버에 설치만 해놓고 언젠간 해야지라는 믿을 수 없는 결심만 하고 지금껏 모른척 했지만 회사에서 PHP8을 고려해야한다는 청천병력 같은 지령이 내려졌다. 뭐 당장은 아니지만 그래도 향후 몇년안에 진행되지 않을까 싶다. 몇년이 길다고하면 길겠지만 회사 생활 하다보면 1년은 훅 지나간다. PHP8 마이그레이션 작업 하다가 머리카락도 훅 날라가는 수 있는게 PHP8은 마이그레이션 수준이 아니라 새로 개발해야하는 상황도 올 수 있기에 신중해야한다.
나 같은 경우 PHP7을 쓰면서 나름 규칙 잘 지켜가면서 프로그램 해왔지만 억울하게도 PHP8에서는 Class 부분과 변수 비교부분이 보완 수준이 아닌 그냥 바뀌어버린 수준이 되었다.
PHP8.0을 살펴보면 최초 2020년에 출시되었고 지금(2024년)은 8.2까지 나왔는데 혹시나 나중에 마이그레이션 하고 있으면 PHP9 버전대가 출실 될것같은 아주 안좋은 예감이 든다.
뭐 아직 PHP8 버전대를 사용해 본게 아니라 이번 포스팅에서는 고려사항에 대해 설명 할 수 없지만 검색하다 보니 JIT 머신 도입이 보여 조금 살펴보았다
PHP같은 경우 매번 소스코드를 해석하여 실행하기 때문에 컴파일러 시스템이 도입된 JSP 나 ASP보다 실행 속도면에서 느리다는 단점이 있었다. 하지만 서버가 좋거나 얕은 프로그램만 해왔다면 속도 차이는 크게 느끼지는 못하였을 것이다.
그럼 여기서 소스코드 해석과 컴파일러 차이가 무엇이냐 할 수 있는데 나 역시 지식이 얕은 편으로 전문적인 용어로 설명하기는 어렵고, 쉽게 설명하면 결과는 같으나 매번 소스코드를 해석하고 컴파일해서 결과를 뿌려주는 방식이 현재 PHP 방식이고 미리 컴파일(기계어로 해석된)된 코드를 바로 뿌려주는 방식이 JSP 나 ASP 방식이라고 보면된다.
다만 컴파일이라고 하더라도 웹에서는 일반 프로그램인 JAVA나 C언어와는 실시간 처리되는 과정이 다르다. C언어를 접해본사람은 쉽게 이해할 수 있는게 C언어는 소스코드를 만들고 컴파일을 통해 기계어로 번역하여 실행파일을 만들게 되는데 수정이 발생되면 다시 컴파일을 수동으로 해서 만들어야 한다. 웹에서는 이런 과정등을 처리하는 머신이 별도로 있다.
PHP는 8버전 이전에도 이와 비슷한 opcache 설정이 존재했는데 opcache는 PHP의 번역기를 통해 생성된 코드(OPCode) 를 메모리에 캐싱하여 다음번 실행때는 다시 번역하는게 아닌 메모리에 저장된 해석된 코드(OPCode)를 컴파일 하도록 도와주는 기능이다. 참고로 해당 기능은 php.ini 에서 설정이 가능하다.
다만 opcache는 실제 사용해보니 속도도 크게 차이를 못느꼇고, 개발 단계에서는 캐싱된 소스때문에 실시간 반영이 안되는 불편함이 있었다. 이렇게 되면 운영사이트에서 소스코드 한번 잘못만지면 바로 되돌릴 수 없어 서버를 재시작해야하는 불상사가 발생될 수도 있으니 주의가 필요하다.
아무튼 헛소리가 많았는데 결국 PHP8에 도입된 JIT가 무엇이냐인데, JIT도 결국 opcache와 같은 개념이긴 하나 메모리에 저장시 해석된 코드(OPCode) 가 아닌 기계어를 그대로 런타임중 실행할 수 있도록 도와주는 기능이다. 물론 설명상 보면 전체가 아닌 자주사용하는 코드를 자동으로 수집 및 분석 후 블록화 하여 불필요한 수행 빈도를 줄여주는 역활을 수행한다.
결론적으로는 JIT는 설정을 보면 캐싱을 계속 물고 있을듯 보이는데 이게 기존 opcache와 같이 사용했을때 캐싱되는 개념인지 아니면 JIT 자체는 실시간 이고 자체는 캐싱되지 않는지가 중요할것같다. 내가 원하는건 수정된 소스코드를 판별하여 다시 블록화 해주면 정말 좋을것 같다.
추후에 PHP8을 사용하게 되면 PHP7에서 마이그레이션시 중요한 포인트와 JIT 사용시 속도차이에 대해 포스팅을 해볼까 한다. 물론 그때쯤 징크스처럼 PHP9가 나오게 될듯 보이지만 그래도 이젠 마지막 단계가 아닐까 싶다.