글 내용을 정리하면 다음과 같은 논쟁입니다.

작성자(라엘)의 주장

• 그누보드5 SE는 그누보드5에서 fork되어 코드 대부분을 그대로 가져왔다
• 따라서 그누보드5에 있는 버그/취약점은 SE에도 동일하게 존재할 가능성이 크다
• 실제로 6월 9일, 6월 24일자 그누보드5 패치 커밋(주문 데이터 저장 관련, 메일 발송 테스트 관련) 2건을 확인해보니 SE 쪽 해당 파일에는 반영되어 있지 않음을 코드 링크로 직접 제시
• 결론: upstream(G5) 패치가 나올 때마다 SE도 호환 패치 및 테스트를 진행해야 한다

댓글(리자, 운영진으로 추정)의 반박

• 지원이 어려울 것 같다
• 이유: 개발진이 다르고, 완전히 동일한 코드베이스가 아니기 때문에 매번 그누보드5 패치를 SE에 그대로 적용할 수는 없다
• G5와는 별개 프로젝트로 진행 중이라는 입장

판단

이 논쟁은 "일반론"과 "구체적 근거"의 싸움이라 저는 라엘 님 쪽 주장이 더 설득력 있다고 봅니다.

1. 근거의 구체성: 라엘 님은 추상적으로 "패치를 적용해야 한다"고 주장한 게 아니라, 실제 커밋 해시(d419f43, 7783501)와 GitHub 링크를 들어 "이 두 개의 실제 보안/기능 패치가 SE에는 반영 안 됐다"는 것을 검증 가능한 형태로 제시했습니다. 이는 단순 의견이 아니라 재현 가능한 사실 확인입니다.
2. 리자 님 답변의 논리적 공백: "개발진이 다르고 동일한 코드가 아니라서 매번 패치할 수 없다"는 답변은 원칙론일 뿐, 라엘 님이 제기한 구체적 2건의 패치가 왜 SE에 필요 없는지, 혹은 실제로 SE 코드에는 해당 버그가 없는지에 대한 반박은 하지 않았습니다. "fork해서 코드를 거의 그대로 가져왔다"는 전제 자체를 반박하지 않은 채, "모든 패치를 다 따라갈 수는 없다"는 일반론으로 넘어간 셈입니다.
3. 다만 리자 님 주장에도 일리는 있습니다: 오픈소스 fork 프로젝트가 upstream의 모든 커밋을 실시간으로 추적하는 것은 현실적으로 리소스가 많이 드는 일이고, SE가 점점 독자적으로 갈라지고 있다면(다른 개발진, 다른 아키텍처 방향) "동일한 패치를 기계적으로 무조건 이식해야 한다"는 원칙은 유지보수 부담이 커질 수 있습니다.

종합: 원론적으로는 리자 님(운영진) 말도 이해되지만, 이 글의 핵심은 "전수 패치를 다 따라가라"가 아니라 "적어도 확인된 취약점/버그 패치는 검토해서 반영해달라"는 요청에 가깝습니다. 라엘 님이 제시한 것처럼 실제 결함이 방치되고 있다는 구체적 증거가 있는 이상, 최소한 해당 건들에 대해서는 "왜 반영이 어려운지" 또는 "반영할 계획이 있는지"에 대한 실질적 답변이 필요해 보입니다. 그런 점에서 라엘 님의 문제 제기가 더 근거 있고, 리자 님의 답변은 다소 원론적 회피에 가깝다고 판단됩니다.

결국 G7이 아닌 이상, 지금 G5SE는 점점 흐지부지될 가능성이 커 보입니다. 이유는 현재 리자님 혼자 개발을 진행하고 있고, 별다른 패치도 없는 상황이기 때문입니다. 수정된 부분도 사용자가 직접 이전 버전과 대조해서 알아서 수정해야 하는 구조인 것 같습니다. 보안 패치 알수 없는 이유 더구나 버그는 이용하면서 문제가 보이면 피드팩 하면 수정  ...................

솔직히 G7은 어제 사쿠라 호스팅에 업로드해서 설치를 시도했는데, 404 오류부터 시작해서 설치 자체가 되지 않는 문제가 있었습니다.

그래서 현재 선택지는 G5se 아니면 그누보드5 정도밖에 없는 것 같습니다. 그런데 G7은 설치 장벽이 너무 높고, 그누보드5는 앞으로 얼마나 오래 유지될지 걱정됩니다. 혹시 예전 그누보드4처럼 지원이 종료되어 사라지게 되면, 힘들게 구축한 사이트를 다시 새로 만들어야 하는 상황이 올 수도 있다는 생각에 마음이 조마조마합니다.

이것저것 고민이 많고, 어떤 선택을 해야 할지 쉽지 않습니다.

G5_SE 프로젝트와 유사한, 다른 G5 파생 프로젝트들 (아미나빌더/이윰빌더/리빌더) 살펴보면, G5와 개발자도 다르고 내부적으로 코드도 다른데, upstream patch를 꾸준히 따라가고 있습니다. (호환 패치 작성)

https://github.com/RebuilderDev/Rebuilder/compare/v2.2.6.1...v2.2.6.2
 

KVE 번호까지 발급되었다면, KISA에서 인정한 보안 결함입니다.

https://github.com/gnuboard/gnuboard5/commits/master/

사실, 이 글을 작성한 주된 이유는, SE 프로젝트 외부의 문맥을 제시하고, 피할 수 없는 이슈를 제시하면, 현재의 AI 개발환경에서 어떻게 대응할지 궁금했을뿐입니다.