여러 서비스 코드, 이제 정리했다
목차
지난 시간 발행 파이프라인은 여러 서비스의 코드가 한곳에 얽혀 있었다. 단일 리포지토리에서 운영하면서 서비스가 늘어나자 점점 더 복잡해졌고, 결국 이번엔 정리를 할 수밖에 없었다. 아울러 검색 최적화 메타데이터도 함께 추가하면서 두 가지 목표를 동시에 달성했다.
서비스 격리의 필요성
문제는 단순했다. 한때 운영했던 서비스(kpopdex)의 발행 로직이 여전히 메인 파이프라인 코드에 산재해 있었다. bot/_legacy_kpop/publish.sh는 이미 레거시로 표시되어 있었지만, bot/publish.sh와 bot/indexnow-ping.js 같은 현재 실행되는 스크립트에도 해당 서비스의 흔적이 남아 있었다. 이러한 "오염(contamination)"이 남아 있으면 여러 문제가 발생한다.
첫째, 유지보수 복잡도. 새 개발자가 코드를 읽을 때 어떤 로직이 현재 서비스에 필요한지, 어떤 게 레거시인지 구분하기 어렵다. 둘째, 배포 위험. 활성 서비스 코드를 수정할 때 실수로 레거시 로직을 건드릴 수 있다. 셋째, 기술 부채. 시간이 지날수록 제거 비용이 올라간다.
멀티 서비스 운영을 경험하면서 배운 게 있다면, 명확한 네임스페이싱과 폴더 격리가 얼마나 중요한지다. 처음부터 services/service-a/ , services/service-b/ 같은 구조로 갔으면 훨씬 깔끔했을 텐데, 나중에 합치거나 분리할 때는 항상 부채가 생긴다.
정리 작업의 범위
| 파일 | 역할 | 변경 내용 |
|---|---|---|
bot/_legacy_kpop/publish.sh |
레거시 발행 스크립트 | 격리 확인 및 정리 |
bot/publish.sh |
메인 발행 파이프라인 | kpopdex 관련 분기 제거 |
bot/indexnow-ping.js |
Bing IndexNow API 호출 | 서비스별 핑 로직 분리 |
public/robots.txt |
검색 로봇 지시 | 정책 통일 |
public/favicon.svg |
파비콘 | 브랜드 자산 업데이트 |
public/og.png |
SNS 공유 이미지 | 브랜드 자산 업데이트 |
발행 스크립트에서는 조건문과 분기를 제거했다. 예를 들면:
# Before: 레거시 로직이 섞여 있음
if [ "$SERVICE" = "kpopdex" ]; then
publish_kpop_legacy
elif [ "$SERVICE" = "main" ]; then
publish_main
fi
# After: 명확한 분리
publish_main
IndexNow 핑도 마찬가지. 검색 엔진에 컨텐츠 갱신을 알리는 이 API를 호출할 때, 이제는 서비스별로 정확히 구분된 엔드포인트와 설정을 사용한다.
SEO 메타데이터 추가
코드 정리와 함께 검색 최적화도 강화했다. 이는 단순 추가가 아니라, 방향성 있는 설정이다.
Canonical 태그: 중복 콘텐츠 문제를 방지한다. 같은 페이지가 여러 URL로 접근 가능할 때 검색 엔진에 "이게 정식 버전이다"라고 알려준다.
OG 메타 태그 (og:title, og:description, og:image): SNS 공유 시 미리보기 정보를 제어한다. 이번에 public/og.png를 새로 만든 이유다. 레거시 이미지를 물리면 구 브랜드가 공유될 수 있으니까.
JSON-LD: 구조화된 데이터로 검색 엔진이 콘텐츠를 더 정확히 이해하도록 돕는다. 뉴스 기사, 상품, 이벤트 등의 스키마를 지정하면 리치 스니펫으로 표시될 가능성이 높아진다.
robots.txt: 검색 봇의 크롤링 정책을 명시한다. 이제 통일된 정책으로 운영 서비스만 크롤링하도록 했다.
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /internal/
Sitemap: https://example.com/sitemap.xml
파비콘과 함께 이러한 메타데이터들은 "신뢰도"를 만든다. 검색 엔진도 사용자도 "이 서비스는 관리되고 있다"는 신호를 받는다.
팀 관점에서의 회고
이 작업을 하면서 느낀 건, 멀티 서비스 환경에서 코드 review와 배포 전략이 얼마나 중요한지다. 예를 들어, 누군가 bot/publish.sh를 수정할 때 코드 리뷰에서 "이건 kpopdex 구 로직인가?"라고 물을 수 있는 여지가 남아 있었다. 이제는 그런 질문 자체가 사라진다.
또한 기술 부채는 미루면 미룬 만큼 비용이 는다는 교훈. 작업량은 차라리 지금이 더 쉬웠을 텐데, 나중에 또 다른 서비스가 추가되거나 운영 체계가 바뀌면 그때는 훨씬 복잡해진다.
멘토링 차원에서도, 팀원들에게 "새 서비스 추가할 때는 반드시 네임스페이싱 먼저, 혼합하지 말 것"이라고 당부했다. 지금의 정리 작업이 그 이유를 잘 보여준다.
마지막으로 SEO 메타데이터는 "운영 품질"의 신호다. Canonical부터 JSON-LD까지 제대로 설정한 서비스는 그렇지 않은 서비스보다 검색 가시성이 높아진다. 기술적 정리는 곧 비즈니스 임팩트로 이어진다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.