오늘은 ThinkGround를 WordPress 중심 구조에서 조금 더 분리된 형태로 운영하기 위해 프론트엔드와 백엔드 구조를 계속 정리하고, 실제 배포 환경에서 동작을 안정화하는 작업을 진행했다.

이번 작업의 핵심은 세 가지였다.
첫 번째는 프론트엔드와 백엔드의 역할을 다시 분명하게 나누는 것이고,
두 번째는 CloudFront와 API 연동 구조를 운영 관점에서 더 자연스럽게 다듬는 것이며,
세 번째는 상세 글 라우팅 정책을 정리해 실제 서비스 동작을 더 예측 가능하게 만드는 일이었다.

기존에는 화면이 WordPress와 비교적 강하게 묶여 있는 형태였다면, 지금은 콘텐츠 원본은 WordPress에 두되, 화면과 사용자 경험은 별도 프론트엔드에서 책임지는 구조로 점차 이동하고 있다.
현재 백엔드는 Spring Boot + Kotlin 기반으로 구성되어 있고, WordPress DB를 직접 조회해 프론트엔드에 필요한 읽기 전용 API를 제공하는 형태로 동작한다. 프론트엔드는 이 API를 기준으로 화면을 구성하고 있다.

오늘 프론트엔드 쪽에서는 홈, 글 목록, 주제 페이지처럼 목록 성격이 강한 화면은 정적으로 배포하면서도, 실제 콘텐츠 조회는 API 기반으로 연결되는 현재 구조를 다시 점검했다.
특히 검색엔진 대응과 초기 렌더링 품질을 높이기 위한 방향을 검토했는데, 이 과정에서 상세 글 페이지를 배포 시점에 정적으로 생성하는 방식도 잠깐 실험했다.

하지만 이 방식은 운영 모델과 잘 맞지 않는다는 판단을 내렸다.
상세 페이지를 정적으로 만들면 초기 HTML 품질은 좋아질 수 있지만, 새 글이 추가될 때마다 배포 시점과 반영 시점이 다시 묶이게 된다. ThinkGround는 WordPress에 등록된 글을 비교적 빠르게 프론트엔드에서 반영하는 방향이 더 적합하기 때문에, 상세 글은 정적 생성 대신 실시간 API 조회 방식으로 유지하는 것이 더 자연스럽다고 봤다.

이 판단에 따라 상세 글의 정적 생성 라우트는 제거했다.
대신 홈, 토픽, 글 목록과 같은 목록성 페이지는 정적 배포의 장점을 살리고, 상세 글 페이지는 클라이언트 라우팅과 API 조회를 통해 실시간에 가깝게 동작하도록 정리했다.
이렇게 하면 운영 구조가 더 단순해지고, 어떤 페이지가 어떤 방식으로 만들어지는지 팀 내부에서도 이해하기 쉬워진다.

또 하나 정리한 부분은 상세 글 경로 정책이다.
실서비스를 확인해보니 /posts/{slug} 형식의 상세 경로는 실제 서비스 기준으로 불완전하게 동작하고 있었고, 반대로 날짜 기반의 기존 레거시 글 경로는 안정적으로 렌더링되고 있었다.
그래서 이번에는 상세 페이지 접근 경로를 레거시 날짜 기반 경로로 통일하고, /posts/{slug} 방식은 더 이상 유효한 상세 라우트로 해석하지 않도록 정리했다.

이 작업으로 얻은 가장 큰 수확은 “어떤 경로를 서비스에서 공식 경로로 볼 것인가”가 명확해졌다는 점이다.
홈과 아카이브는 정적 배포, 상세 콘텐츠는 API 기반 실시간 조회, 그리고 공식 상세 URL은 날짜 기반 레거시 경로라는 기준이 잡히면서 이후 작업의 기준선도 한층 분명해졌다.

배포 이후에는 실제 CloudFront 경로들을 직접 점검했다.
홈, 글 목록, 레거시 상세 글, 404 성격 페이지가 의도대로 동작하는지 확인했고, 깨져 있던 /posts/{slug} 계열 경로는 제거 방향으로 정리했다.
이제 ThinkGround 프론트엔드는 겉모습뿐 아니라 라우팅 정책과 운영 구조 면에서도 조금 더 서비스다운 형태를 갖추고 있다.

다음 단계에서는 남은 화면 품질을 더 높이고, API 응답 구조와 프론트엔드 문구/메타데이터를 더 정교하게 다듬는 작업을 진행할 계획이다.
특히 사용자가 직접 체감하는 상세 페이지 경험, 주제 탐색 흐름, 그리고 운영자가 글을 발행했을 때 반영이 얼마나 자연스럽게 이어지는지를 계속 점검해볼 생각이다.

오늘 작업은 눈에 띄는 기능 추가보다 구조를 정리하고 기준을 잡는 데 더 가까웠다.
하지만 이런 정리가 쌓여야 이후의 기능 확장도 흔들리지 않기 때문에, ThinkGround를 오래 운영할 수 있는 형태로 옮겨가기 위한 중요한 단계였다고 생각한다.