오래된 소프트웨어를 현대 환경에서 다시 굴려 보는 일은 단순한 향수 이상의 실용적 가치가 있다. Thran이 2026년 9월 개발 로그에 공개한 작업은 2001년에 나온 게시판 스크립트 phpBB 1.4.4를 PHP5, 아파치, MySQL 4 조합 위에서 도커 컨테이너로 구동한 기록이다. phpBB 1.4.4는 이 소프트웨어가 유명해지기 직전의 마지막 릴리스로, PHP 3와 register_globals, 그리고 사용자 입력을 별다른 검증 없이 곧바로 SQL에 넘기던 '고신뢰 인터넷' 시대를 전제로 설계됐다. 20여 년이 지난 지금 그 코드를 그대로 실행하려면 여러 지점에서 마찰이 생길 수밖에 없다.
흥미로운 점은 그 마찰이 생각보다 크지 않았다는 것이다. 저자는 몇 가지 패치만으로 동작에 성공했다고 밝힌다. 첫째, 데이터베이스 초기 시딩 명령 일부가 MySQL 4에서 거부됐다. 예컨대 auto_increment 컬럼에 굳이 NOT NULL을 붙일 필요가 없어진 문법 변화 때문이다. 둘째, functions.php에서 로그인 쿠키가 설정되지 않는 문제가 있었는데, 이는 PHP5가 PHP3보다 타입 안정성이 높아져 빈 문자열 ""을 0으로 자동 변환해 주지 않은 데서 비롯됐다. 셋째, 게시글이 하나도 없을 때 인덱스 페이지가 마지막 게시 시각을 계산하려고 빈 문자열을 파싱하다 오류를 냈다.
언어와 DB의 세대 차이가 드러나는 지점
이 세 가지 버그는 레거시 이식 작업이 실제로 어디서 막히는지를 압축해서 보여 준다. 오래된 코드가 깨지는 이유는 대개 문법 자체가 폐기돼서가 아니라, 런타임이 조용히 봐주던 느슨한 동작이 사라졌기 때문이다. PHP3 시절의 암묵적 타입 강제는 '빈 값이면 알아서 0'이라는 편의를 제공했지만, PHP5는 그 관용을 거둬들였다. 겉으로는 엄격해진 것이지만, 그 관용에 기대어 작성된 코드 입장에서는 멀쩡히 돌던 로직이 갑자기 멈추는 셈이다. MySQL의 스키마 문법 변화도 마찬가지 성격으로, 예전에는 허용되던 중복·불필요 선언이 나중 버전에서 엄격해진 경우다.
실무자 관점에서 새겨 둘 지점은 여기다. PHP나 다른 언어의 메이저 버전을 올릴 때 진짜 위험은 '문법 오류'처럼 즉시 눈에 띄는 것이 아니라, 타입 강제·널 처리·빈 값 취급 같은 조용한 의미 변화다. 이런 변화는 컴파일 단계가 아니라 특정 데이터 조건에서만 드러나기 때문에, 게시글이 없는 초기 상태처럼 흔치 않은 경로에서 뒤늦게 터진다. 저자가 겪은 '빈 문자열 파싱' 문제가 정확히 그런 사례다.
도커가 해결해 주는 것과 그렇지 못한 것
도커로 이 조합을 감싼 이유도 분명하다. PHP5, 아파치, MySQL 4를 오늘날의 운영체제에 직접 설치하는 것은 사실상 불가능에 가깝고, 설치하더라도 시스템 전체를 오염시킨다. 컨테이너는 이 낡은 스택을 격리된 캡슐 안에 밀봉해, 현대 호스트를 건드리지 않고도 20년 전 환경을 재현하게 해 준다. 저자의 구성에서 데이터베이스 호스트 이름이 localhost가 아니라 db인 것도 이 때문인데, MySQL이 컴포즈의 별도 서비스로 떠 있어 서비스 이름으로 접근하기 때문이다. 이는 레거시 애플리케이션을 컨테이너화할 때 흔히 마주치는 전형적인 조정 지점이다.
설치 과정의 세부도 시대상을 그대로 드러낸다. phpBB 1.4.4는 설치 중 config.php에 쓰기 권한이 필요해 Dockerfile이 파일 모드를 666으로 열어 두며, 설치가 끝나면 다시 잠가야 한다. 원래 문서 역시 설치·업그레이드 스크립트를 삭제하거나 이름을 바꾸라고 권한다. 익명 사용자에게 관리자 권한을 부여하는 것마저 가능한, 그야말로 '자유로운' 게시판이다. 이 모든 편의는 곧 보안 취약점이라는 다른 이름이기도 하다.
그래서 저자가 가장 먼저, 그리고 반복해서 강조하는 경고가 핵심이다. 이 구성을 공개 서버에 절대 올리지 말라는 것이다. register_globals를 되살리는 php.ini 설정, 검증 없이 SQL로 흘러가는 사용자 입력은 당시엔 자연스러웠지만 지금은 교과서적 공격 표면이다. 이 프로젝트의 가치는 운영 가능한 게시판을 만드는 데 있지 않고, 격리된 환경에서 소프트웨어 역사를 관찰하고 언어·DB의 진화가 코드에 남긴 흔적을 학습하는 데 있다.
결국 이 작업이 주는 실무적 교훈은 노스탤지어를 넘어선다. 레거시 이식은 대개 대대적 재작성이 아니라 몇 개의 국소적 패치로 갈리며, 그 패치가 필요한 지점은 런타임이 관용을 거둬들인 자리에 집중된다. 격리 기술은 낡은 스택을 안전하게 되살려 주지만, 그 스택이 전제하던 보안 모델까지 함께 부활한다는 사실은 컨테이너가 결코 지워 주지 못한다. 옛 코드를 다시 켤 때 진짜 물어야 할 질문은 '돌아가는가'가 아니라 '어디에서, 왜 돌아가게 놔둘 것인가'이다.