오늘은 ThinkGround의 콘텐츠 구조를 조금 더 장기적으로 운영할 수 있도록 정리하는 작업을 진행했다. 지금까지는 백엔드가 WordPress 데이터베이스를 직접 조회해서 프론트엔드에 필요한 형태로 응답을 만들어주는 구조였는데, 이 방식은 초기 분리 단계에서는 빠르고 단순하지만 서비스가 커질수록 WordPress 스키마에 강하게 묶이는 한계가 분명하다. 그래서 오늘은 “현재 실제로 어떤 구조를 읽고 있는지”, “앞으로 ThinkGround 전용 스키마를 만든다면 어떤 형태가 적절한지”, “운영 중단 없이 어떻게 옮겨갈지”를 문서 기준으로 먼저 정리했다.

우선 현재 백엔드가 사용 중인 WordPress 테이블 범위를 다시 정리했다. 실제로는 wp_posts, wp_term_relationships, wp_term_taxonomy, wp_terms 네 개의 축이 핵심이었다. 게시글 본문과 메타 정보는 wp_posts 에서 읽고, 카테고리와 태그는 관계 테이블과 taxonomy 테이블을 통해 연결하는 구조다. 즉 ThinkGround가 지금 필요로 하는 WordPress 구조는 생각보다 좁고 단순하다는 점을 다시 확인했다. 이건 좋은 신호다. 전용 스키마를 만든다고 해도 WordPress 전체를 복제할 필요는 없고, 실제 서비스에 필요한 핵심 관계만 재구성하면 되기 때문이다.

그 다음으로는 ThinkGround 전용 콘텐츠 스키마 초안을 구체화했다. 중심은 posts, categories, tags, 그리고 각각의 관계 테이블인 post_categories, post_tags 다. 여기에 원본 추적을 위한 source_type, source_id, source_link 같은 필드를 두고, 기존 URL 호환을 위한 날짜 기반 legacy 필드도 함께 두는 방향으로 정리했다. 또한 추후 운영 안정성을 고려해서 동기화 이력을 남길 수 있는 content_sync_history, 필요 시 대표 이미지나 SEO 정보 같은 확장값을 담을 수 있는 post_metadata 도 선택 테이블로 초안에 포함했다. 아직 최종 스키마는 아니지만, 이제는 논의 수준이 아니라 실제 테이블 정의를 놓고 검토할 수 있는 상태가 됐다.

오늘 작업에서 특히 중요했던 부분은 “바로 완전 전환하지 않는다”는 원칙을 세운 점이다. 현재 서비스는 이미 운영 중이고, WordPress에는 누적된 글과 발행 흐름이 있기 때문에 한 번에 구조를 뒤집는 건 리스크가 크다. 그래서 운영 전략은 하이브리드 방식으로 보는 것이 가장 현실적이라는 결론을 정리했다. 단기적으로는 WordPress를 원본으로 유지하고, ThinkGround 전용 읽기 스키마를 별도로 만든 뒤, 배치 기반 동기화로 데이터를 채운다. 이후 목록, 상세, 카테고리 아카이브, 태그 아카이브, 검색 API 순서로 전용 스키마 기반 조회로 점진 전환한다. 이 과정에서 응답 정합성을 충분히 비교 검증한 뒤 WordPress 직접 조회 의존도를 줄이는 방향이다.

마지막으로는 다음 작업을 위한 데이터베이스 스키마 검토 체크리스트도 만들었다. 실제 운영 중인 WordPress 데이터에서 어떤 post_type 이 쓰이고 있는지, excerpt가 얼마나 비어 있는지, 다중 category 글이 존재하는지, 대표 이미지나 SEO 메타를 별도로 읽어야 하는지 같은 질문들을 정리했다. 이 체크리스트는 다음 단계에서 “정말 마이그레이션이 필요한가”, “지금 당장 필요한 테이블은 무엇인가”, “JPA 중심으로 갈지 조회 전용 쿼리 모델로 먼저 갈지”를 판단하는 기준이 될 것이다.

정리하면, 오늘은 기능을 하나 더 붙였다기보다 ThinkGround의 콘텐츠 구조를 앞으로 어떻게 가져갈지에 대한 기준선을 세운 날이었다. 프론트엔드와 백엔드를 분리한 데 이어, 이제는 데이터 모델도 WordPress 종속 구조에서 점차 분리해 나갈 준비를 시작했다. 다음 작업에서는 현재 데이터베이스 스키마를 실제 값 기준으로 검토하고, 오늘 작성한 체크리스트를 바탕으로 새로운 스키마와 마이그레이션 필요성을 더 구체적으로 판단할 예정이다.