검색 엔진 핑을 빌드 시스템으로 정식화

오래전부터 돌아가던 indexnow-ping 스크립트를 /opt/psy-build 라는 격리된 디렉토리에서 빼내 정식 빌드 파이프라인으로 옮기는 작업을 했다. 작은 변경으로 보일 수 있지만, 이 정식화 과정에서 배운 게 꽤 있어서 글로 남긴다.

격리된 코드의 대가

생각해보면 많은 팀에서 겪는 문제다. 검색 엔진 최적화 관련 기능(indexnow-ping)은 핵심 서비스 로직이 아니다 보니, 별도의 디렉토리(/opt/psy-build)에 격리해두고 필요할 때만 수동으로 유지하게 되는 경우가 잦다. 우리도 마찬가지였다.

근데 이게 문제였다:

• git 추적이 안 됨: /opt/psy-build 는 .gitignore 에 들어있었다. 즉, 누가 언제 뭘 바꿨는지, 왜 이렇게 구성했는지 히스토리가 없었다.
• 배포 파이프라인과 단절: publish.sh 같은 빌드 스크립트와 독립적으로 동작하니, 환경 변수나 호스트 설정이 꼬이기 쉬웠다.
• 재현성 저하: 신입이나 다른 팀원이 로컬에서 전체 빌드를 재현하려고 할 때, 이 부분은 매뉴얼 단계를 거쳐야 했다.
• 운영 부채: 시간이 지나면서 "어? 이 파일은 왜 /opt 에 있지?" 하는 의문만 쌓인다.

정식화로 얻은 것

이번에 build-ads/ 디렉토리로 옮기고 git 추적을 시작하면서:

특히 curiodot HOST 추가는 환경별 호스트를 간단히 전환할 수 있게 했다. 로컬/스테이징/프로덕션 환경에서 다른 호스트로 ping 을 보낼 때 설정 하나로 관리할 수 있게 된 거다.

왜 이런 정식화가 중요한가

팀 관점에서 생각해보면:

1. 의도의 명확화: "이 코드는 왜 기본 빌드 플로우에 포함되는가?" 하는 질문에 답이 생긴다. git 히스토리를 보면 언제, 왜 indexnow 를 도입했는지 알 수 있다.

2. 코드 리뷰 의존성: 스크립트가 수정되면 자연스럽게 PR 을 거친다. 팀원들이 검색 엔진 ping 로직 변경을 눈에 띄게 된다는 뜻이다.

3. 신입 온보딩: "우리 빌드 시스템이 뭘 하는가"를 설명할 때, 이제 "build-ads/ 에 있는 모든 스크립트가 publish 흐름의 일부"라고 간단히 말할 수 있다.

4. 운영 단순화: 누군가 긴급으로 indexnow 로직을 수정해야 할 때, /opt 의 숨겨진 파일을 찾느라 헤매지 않아도 된다.

한 번 더 생각해볼 점

이런 류의 정식화 작업은 보통 "그냥 이대로 둬도 되지 않나" 싶을 때 시작하는 게 좋다. 왜냐하면 시간이 지날수록, 코드가 많아질수록, 팀이 커질수록 기술 부채로 변하기 때문이다. 특히 검색 최적화, 모니터링, 배포 유틸리티 같은 "주변 기능"들이 그렇다.

이번 변경은 작아 보이지만, 앞으로 indexnow 관련 기능이 확장될 때 (예: 호스트별 전략 분화, 실패 로깅 추가 등) git 추적과 표준 빌드 디렉토리 구조 덕분에 훨씬 수월해질 거다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.