라이믹스는 주기적으로 업데이트되어 버전의 숫자가 조금씩 올라갑니다.
사람처럼 나이를 먹는다고 자동으로 올라가는것도 아니고, 이유 없이 심심해서 올라가는것도 아닐것 입니다.
버전 업데이트라는 것을 하며 여러 기능의 추가 수정 삭제등 무수히 많은 일련의 작업 들이 그 안에서 이루어 질것입니다.
보안이 향상 될수도 있고, 혹은 갑자기 드러난 취약점을 고친것 일수도 있고, 무언가 버그를 고친것 일수도 있고... 신기능을 만들수도, 혹은 속도를 빠르게 개선할수도 있고.. 이유야 너무나 다양할것 입니다.
우리가 사용하는 라이믹스에서도 여러 사용자의 의견들이 모이고, 버그가 제보되고, 기능의 수정과 개선이 이루어 지면서 자연스레 버전업을 하게 되는데
PHP 라고는 다를까 싶습니다. 하물며 라이믹스, XE같은 프로그램 들은 PHP로 작동하는 셀 수 없이 무수히 많은 프로그램중 하나 일 뿐인데 말이죠.
라이믹스 버전업을 볼때마다 엄청나게 많은 필요 기능들이 생겨나고 개선될 부분들은 개선 되는것을 볼수 있습니다.
라이믹스 또한 과거 XE시절 부터 비교하면 조금씩 PHP 최소버전이 올라가고 있습니다.
더 상위 차원의 PHP가 버전업을 하니까 그 보다 하위에서 작동하는 프로그램인 라이믹스 또한 따라서 업데이트를 하는것 입니다. 다만 내부의 코드들이 과거부터 누적되어 쌓여온 만큼 최근의 PHP사정에 맞도록 케케묵은 코드들을 수정하는 기간이 들어가는 것일거구요.
저희 같은 일반적인 라이믹스 사용자의 시선에서는 PHP버전업이 그다지 피부로 와 닿지 않기 때문에..
뭔지는 잘 모르겠지만 일단 올리라면 올리긴 해야 되는데 올리고 나면 원래 잘 작동하던 내 프로그램 고장내는 귀찮은 놈 정도의 인식으로 보여지곤 합니다.
거꾸로 생각해보면 라이믹스는 결국 PHP로 만들어진 언어이고, 이 라이믹스를 실제로 만들고 기여하고 계신 개발자 분들에게는 저희가 새로운 라이믹스 버전을 볼때마다 감탄을 하는것 처럼 PHP업데이트를 보고 감탄을 하고 계실지도 모릅니다.
실제로 PHP또한 업데이트 진행될수록 오래된 쳐낼것은 쳐내고, 새로운 기능들을 추가하고 보완할테니까요
서버·호스팅 등의 환경적인 문제거나 혹은 기존에 사용하던 모듈/애드온 등의 호환성 때문에 어쩔 수 없는 문제가 아니라면 가능한 안정화(검증) 된 가장 최근의 버전을 사용하는것이 좋은것 아닐까 생각 해봅니다.
아직도 산업현장이나 공장등지에서 사용하는 20년 30년 지난 기계나 프로그램들은 보수하고 교체하고 싶어도 마음대로 할 수가 없으니 그냥 쓴다고 쳐도, 라이믹스는 내가 서버의 접근권한만 있다면 원하는대로 수정을 할 수 있지 않습니까??
시간의 문제일뿐 결국 라이믹스도 언젠가는 최소사양 PHP8 시대를 맞이 할 수도 있는것이며
그 전에 저희같은 일반 사용자에게 주어진 시간동안 예전에 작성된 프로그램을 고치고 개선하며 혹은 과검히 버릴것은 버리면서 최근의 발전 사양에 맞추어 가며 사이트를 운영해야 된다고 생각 합니다.
그래서 저 또한 라이믹스를 사용하며 저의 필요에 의해 수정, 추가하는 부분들은 모두 최근의 방식을 찾아서 만들고 있구요.
당장의 귀찮음이나 잘 모른다는 이유 때문에 과거부터 개선되고 더 좋아지는 PHP상위버전을 포기하는건 너무 아깝네요
그것은 점점 더 업그레이드 하는 라이믹스 버전 업데이트 까지 포기한다는 것과 같을 테니까요.
코어 개발자로서 어쩔 수 없는 부분도 있습니다. 예를 들어 PHP 8.2가 나오면 코어도 8.2를 지원해야 하는데, 동일한 소스로 아주 광범위한 버전의 PHP를 지원하기가 쉽지 않습니다. 타입 체크나 클래스 상속 규칙이 점점 빡빡해지고 있는 최근 버전은 더욱 그렇습니다. 그러니까 새 버전을 하나 지원하기 위해 오래된 버전을 하나 쳐내는 거죠.
XE나 그누보드처럼 PHP 문법의 극히 일부만 사용하는 CMS라면 PHP 5.x부터 8.x까지 모두 지원하는 것도 얼마든지 가능하지만, 라이믹스는 PHP 문법과 기본 제공되는 기능들을 훨씬 광범위하게 사용합니다. PHP의 변화에 더 민감할 수밖에 없지요. 몇 가지만 예를 들어 볼까요?
1. PHP에서 기본 제공하는 PDO, PDOStatement 클래스를 상속받아 디버그 연동 코드를 끼워넣습니다.
2. 배열로 선언한 lang 파일의 내용은 ArrayObject로 묶어서 반환하여, 오브젝트 접근 문법으로도 불러다 쓸 수 있도록 합니다. 예전에 lang 파일에 오브젝트를 넣는 서드파티 자료가 있었거든요. 호환성 유지해야죠.
3. Context::set('foo')로 넣은 변수를 템플릿에서 {$foo}로 불러다 쓸 수 있는 것은 절대 당연한 기능이 아닙니다. 클래스에 넣은 데이터와 GET 변수를 통합하여 마치 로컬 변수처럼 참조할 수 있도록 하기 위해 XE 때부터 지저분한 꼼수가 동원되었고, 라이믹스도 마찬가지입니다. 이거 처리하는 정규식이 굉장히 예민해서, 템플릿에서 쓸 수 있는 문법의 자유도가 무척 제한됩니다.
4. 세션 쿠키에 samesite 속성을 넣을 수 없는 PHP 7.2에서도 일관성있는 동작을 보장하기 위해, 마침 PHP 7.2 이하 버전에만 존재하는 가벼운 보안취약점(?)을 활용하여 이 속성을 헤더에 무단으로 주입하고 있습니다.
5. stdClass 이외의 클래스에 임의로 속성을 추가하는 것은 앞으로 막힌다고 했습니다. 그래서 Context처럼 임의로 속성을 추가하는 일이 잦은 클래스들은 미리 #[AllowDynamicProperties] 딱지를 붙여 놓았습니다.
또 한 가지 어려움은 common/vendor/ 아래에 빼곡히 들어 있는 서드파티 라이브러리들입니다. 라이믹스의 강력한 기능 중 상당수는 저희가 직접 개발한 것이 아니라, 전세계의 개발자들이 만들어 배포한 오픈소스 라이브러리들을 활용하고 있습니다. 그런데 외국 개발자들은 한국보다 훨씬 빨리 구 버전을 버립니다. 우분투 등 주요 리눅스 배포판들이 몇 년간 보안패치 지원을 약속했는데도, PHP 공식 지원 기간이 끝났다는 이유로 가차없이 버리곤 합니다.
만약 라이믹스에 꼭 필요한 라이브러리가 앞으로 PHP 7.4 이상만 지원하겠다고 한다면, 라이믹스도 따라가는 수밖에 없겠지요. 구 버전을 지원한답시고 오래된 라이브러리를 계속 유지하다가는 해킹당하기 딱 좋고요.
그냥 둬도 5년 10년 잘 돌아가는 홈페이지란 더이상 존재하지 않습니다. PHP와 CMS의 발전이 모두 정체되었던 2000년대 초반에나 가능했던 얘기지요. 이제는 끊임없이 따라가지 않으면 죽습니다. 여러분의 홈페이지도 마찬가지이고, 라이믹스 코어도 마찬가지입니다. 살아남기 위해 라이믹스 코어도 엄청 노력하고 있다구요.
항상 아쉬운 것은 서드파티 자료입니다. 10년이 넘었는데 방치되고 있는 것이 너무 많습니다. 코어는 PHP 8을 완벽에 가깝게 지원하는데 서드파티 때문에 업데이트를 못합니다. 오픈소스 라이선스가 허용하는 한도 내에서, 남이 만든 자료라도 임의로 수정하여 재배포하는 행동이 좀더 활성화되면 좋겠습니다.