계약이 어긋나는 순간들 ( G7 CMS 예제 )

최근 운영 환경에서 몇 가지 문제를 연속으로 점검하면서, 다시 느낀 게 하나 있었다. 그누보드7은 단순히 "Laravel 위에 게시판을 올린 프로젝트"라기보다, 여러 계층이 서로 계약(contract)으로 연결된 런타임 플랫폼에 더 가까워지고 있다는 점이다. 이번에 확인한 문제들은 겉으로 보면 서로 달라 보였다. * 보호 API가 요청 헤더에 따라 500과 401 사이를 오가던 문제 * SEO/static renderer와 실제 React footer 상태가 달라진 문제 * 존재하지 않는 경로가 SPA shell 때문에 200으로 응답되던 문제 * bundled admin template 내부에 하드코딩된 visible text가 남아 있던 문제 하지만 실제로는 모두 비슷한 방향의 문제였다. "설계된 계약과 실제 런타임 동작이 조금씩 어긋나기 시작한 상태" 예를 들어, 404 하나를 바로잡는 작업도 단순 route 수정으로 끝나지 않았다. * catch-all route * template route resolver * SEO middleware * Googlebot static render * SPA 진입 정책 이 흐름 전체를 같이 확인해야 했다. 운영 환경에서는 결국 기능 자체보다: * 어떤 경로가 SPA로 진입해야 하는지 * 어떤 응답이 SEO renderer로 가야 하는지 * 어떤 요청이 JSON contract를 유지해야 하는지 이런 기준들이 끝까지 일관되게 유지되는지가 더 중요해진다. 이번 대응 과정에서 특히 인상적이었던 건, 그누보드7 내부에는 이미 이런 계약들이 꽤 강하게 존재하고 있다는 점이다. * layout JSON contract * i18n contract * bundled lifecycle * runtime driver override * template cache flow * SEO/static rendering contract 문제는 기능 부족이 아니라, 실제 운영 과정에서 이 계약들이 서로 조금씩 어긋나기 시작할 때 생긴다. 그래서 앞으로 더 중요한 건 기능 추가 자체보다: * contract parity * runtime observability * bundled source discipline * production-host verification 같은 영역일지도 모르겠다. 최근 진행한 대응들도 결국은 새로운 기능 개발보다, 런타임 전체가 같은 계약을 바라보도록 다시 정렬하는 작업에 가까웠다.