@바보천사 님이 작성하신 글에서 @티프 님이 라라벨을 안 쓰고 PHP로 뭘 더 하기도 어려울 것 같다는 댓글에 제가 댓글을 길게 작성했더니 무슨 이유인지 글쓴이가 글을 삭제해버리셨네요.

댓글 열심히 썼는데 ???

그게 아까워서 브라우저에 열려있는 내용을 다시 정리해서 옮겨 적어봅니다.

라라벨 등의 덩치 큰 프레임워크를 사용하지 않고도 호환성을 유지하면서 라우터, PDO, 템플릿 시스템 등을 붙일 수 있고 개선할 수 있는 것이 많습니다.

1. 라우터

slim https://www.slimframework.com 을 가져다 써도 좋고, https://github.com/nikic/FastRoute 를 가져다 써도 좋습니다. slim을 사용하는게 어차피 구현해야 할 것들을 줄여줘서 저는 slim을 적용했었습니다. 덩치가 작지는 않지만 PSR 권장사항을 잘 준수하고 미들웨어 등으로 확장도 가능하고요.

REST API 유형의 API도 구현할 수 있고, bbs/board.php 같은 파일로 직접 접근이나 짧은 주소도 유지할 수 있습니다.

라우터에서 추가한 것은 기존 짧은 주소와 충돌만 없다면 자유롭게 추가하여 사용할 수 있겠고요.

될 것같은게 아니라 제가 그누보드의 플러그인으로 만들던 기능에서 이미 구현하고 동작했던 기능입니다.

플러그인으로 만들었던 것은 일부 하위디렉토리에서만 동작하는 보조적인 수단으로 사용했지만, 그 전에 그누보드 자체에 통합하여 실제 동작까지도 확인했던 부분입니다. 이걸 PR 보내봤자 받아들이기 어려울 것같아서 플러그인으로 한정된 기능에서만 사용하게 되었던 것이고요.

2. 템플릿

Twig 같은 유명한 것들을 가져다 사용해도 좋지만 덩치가 너무 크고 학습비용도 좀 크죠. 좀 더 쉬운 라라벨 Blade 문법을 사용할 수도 있습니다.

이것도 라라벨을 끌어다 사용하지 않아도 라이믹스가 이미 Parser를 만들어 blade 문법을 지원하고 있습니다.

https://rhymix.org/manual/theme/template_v2

https://github.com/rhymix/rhymix/blob/master/common/framework/parsers/template/TemplateParser_v2.php

라이믹스의 특화 기능들을 제거하면 저 코드의 2/3나 반으로 줄어 구현해야 할 코드량은 더 적어질 것같네요. 여기에 그누보드에 특화된 directive 추가해주면 사용성은 더 좋아지겠죠.

Blade 문법이 PHP와 유사해서 어렵지 않지만 이것도 어렵다 싶으면 Plates https://platesphp.com 를 사용해도 좋습니다. PHP 문법 그 자체이기 때문에 아무것도 새로 배울게 없습니다. 컴파일 과정도 없습니다.

필요하면 plates 가 제공하는 헬퍼 함수들을 사용할 수도 있고, 그누보드에 특화된 기능을 쉽게 확장해서 제공할 수도 있습니다.

plates 만 적용해도 그누보드의 오염된 전역변수 문제에서 벗어날 수 있습니다.

기존 테마와 스킨들과의 호환성? 그냥 그대로 사용하면 됩니다.

.php 파일은 기존 그대로 처리하고 .blade.php 나 .plate.php 파일을 템플릿 엔진을 거치면 됩니다. 기존 테마, 스킨은 그대로 사용하면서 새로운 템플릿 엔진을 사용할 수 있도록 선택지를 제공할 수 있죠.

이것도 이미 해봤고 잘 동작했습니다.

저는 최대한 기존 사용자들에게 친숙한 Plates를 사용해서 적용했었습니다.

3. DB

이것도 해봤습니다.

저는 그누보드의 플러그인 형태로 제작하느라 그누보드가 연결해둔 DB 커넥션을 그대로 이용하고, prepared stetement를 사용하기 쉽게 헬퍼를 하나 추가해서 사용했습니다. 200줄이 안 되는 간단한 클래스 였습니다.

이것만으로도 SQL Injection 문제의 근본적인 원인을 제거해나가는 큰 기반이 됩니다.

그누보드는 이 간단한걸 안 해서 그 오랜 세월동안 SQL Injection 공격에 땜질만하면서 버텨왔지만요.

저는 서드파티 플러그인일 뿐이라서 변경할 수 없었지만, 그누보드가 자체 지원한다면 PDO 전환도 가능합니다.

sql_query() 등의 함수가 내부적으로 PDO를 사용하도록 변경하면 됩니다. 기존 함수들의 사용성은 그대로 유지하면서 내부 동작을 바꿔 PDO 사용을 지원할 수 있습니다.

기존 sql_query() 등의 함수를 그대로 유지하면서 PDO로 전환하거나, PDO 전환 없이 기존 mysqli 커넥션을 유지한채로 헬퍼를 제공하여 prepared statement 사용을 좀 편리하게 제공할 수 있습니다.

PDO로 전환하면 ORM이나 쿼리 빌더를 적용하기 수월하지만, PDO로 꼭 전환할 필요도 없이 prepared statement를 사용 가능합니다.

4. 기타

회원정보나 게시판, 글, 댓글 등등의 명확한 API가 없어서 변수를 뒤적여가며 사용했던 것들도 헬퍼를 제공해서 명확한 API를 제공하면 에디터에서 자동완성 품질이 아주 크게 올라갑니다.

$is_admin 을 boolean 타입으로 오해하고 잘못 사용하는 일도 없고 변수명을 일일히 외우지 않아도 에디터에서 자동완성으로 제안해주죠. 코딩이 훨씬 편리해집니다.

이것도 없어서 직접 다 만들어 썼습니다.

---

이상. "라라벨 같은 덩치 큰 것들을 끌어오지 않고는 PHP 그누보드에서는 무언가를 더 할 수 있는게 없다"에 대한 댓글의 내용을 다시 정리해서 적어봤습니다.

옮겨 적다보니 내용은 훨씬 길어졌네요. 마지막에 썼던 내용이 있었는데 뭔가 기억이 다시 나질 않아서 누락됐네요. 

뭐 그렇다고 이런걸 왜 안하고 파이썬으로 전환했느냐를 따지자는건 아닙니다.
앞에 언급한 댓글에 대한 반박일 뿐입니다.

그누보드6이 파이썬을 선택한 것은...
아직 생각이 좀 오락가락하지만 저는 나쁘지 않은 어쩌면 좋은 선택이라고 생각하는 쪽으로 기울고 있습니다.

파이썬 버전 전에 라라벨로 다시 시도하고 계셨다는 루머도 있기는 한데,
라라벨로 하는 것보다 파이썬을 선택한 것이 확실히 더 나은 선택이었다고 생각합니다.

기존 사용자들을 이끌어 라라벨을 배우게하는 것은 정말 어려울 것같고, 파이썬으로 새로운 유저층을 공략하는게 훨씬 쉬운 방법이고 성공적으로 안착하는데 더 확률이 높은 선택일거라 생각합니다. 

한가지 너무 아쉬운건...

https://github.com/gnuboard/gnuboard5/issues/294

이런 문제에 대해 "메이저 업데이트에서 수정하겠다"라는 답변이 그누보드6을 계획중이고 거기서 고치려나보다 싶었지만, 웬걸 파이썬이 메이저 업데이트였고 PHP 버전에서는 앞으로도 고쳐질거라는 기대를 할수가 없게 되어버렸죠.